软件测试的两种未来(2)

　　一条需求不是文档里的一行字或一个段落;那些东西只是表述方式-文字的表示方式-某人有什么和某人想要什么之间是有区别的。用统计需求文档数量的方式统计需求会忽略掉需求背后的一切含义，就如同把三轮车和航天飞机放在一起统计一样。
　　人们会说有测量总比没有好。那就像说安乐死比没有被枪毙要好。
　　政治性和感性决策比较强的领域，做一个决策总是基于谁的价值更相关，以及他们的感受如何。测量的目的不在于提供答案，而是提供更好的建议。
　　我们如何测量
　　Ÿ 一阶测量
　　Ÿ 减少琐事，直接观察，减少测量
　　Ÿ 应习惯于触发控制行为或者提示搜索更多提炼的信息
　　Ÿ “发生了什么?我们应该做什么?我们在哪里观察”
　　Weinberg建议，在软件开发中，我们往往执迷于三阶以及二阶测量，其实一阶测量可能已经满足我们全部的需要-并且无论从各个方面来说都要成本低廉
　　为什么倾向于一阶测量?
　　Ÿ 当你在开车时，你大部分精力花在
　　Ÿ 你的速度、加速度、汽车重量、牵引系数、摩擦力?(三阶)
　　Ÿ 你的引擎温度、转数以及瞬时油耗?(二阶)
　　Ÿ 看着窗口以防撞车?
　　控制测量 vs. 询问测量
　　Ÿ 一个控制测量是指促成决定的测量方法
　　Ÿ 任何你用的控制自知系统的测量方法将让系统控制你
　　Ÿ 一个询问测量是任何帮助你在正确的时间问正确的问题的方法
　　Ÿ 询问测量有赌博的意思，但是收益会非常低，所以人为操控的可能性几乎没有
　　测量，从定义上看，是现实的简化版，并且同样的数字能够表示出不同的现实场景。
　　任何包含人的系统都是自知的。任何你用的控制自知系统的测量方法将让系统控制你。
　　一个询问测量可能看起来像控制测量。区别就在于你如何用以及如何推断。
　　观察是在没有定量测量的情况下能够直接做出评估和控制行动的方法。这是一阶方法。要问碰到其他模型怎么办，除了数字类型的，你都可以使用这个方法。应该从你想要解决什么问题或你想要评估什么场景开始问起。与间接观察相比，更应做直接观察。确保你已经考虑了很多可能的解释，然后选择一种控制行为或者搜索以获取更详细的信息。如果你担心观察和评估是主管的(确实)，问相关的多个人。
　　光明未来
　　通过询问来测量，而不是控制
　　Ÿ 像通过/失败率以及缺陷发现率这样的度量标准忽略了几乎每个相关因素
　　Ÿ 需求和bug关联的因素
　　Ÿ 问题解决的困难程度
　　Ÿ 产品设计的质量
　　Ÿ 代码质量
　　Ÿ 发布时间
　　Ÿ 谁做出发布决定，为什么
　　Ÿ 客户采纳的时机
　　Ÿ 我们用这些虚假的度量标准去评估测试质量?
　　一行代码代表一个思想。一行代码既能简单到在CPU的寄存器中存放一个值，也能复杂到一个多分支、多条件的判定点。一个开发人员的任务是学习、解决问题，构造和重新构造解决方案。有时这意味着移除代码，而不是添加。评估开发人员做的事情远不止统计有多少行代码这么简单。代码行数的统计是同样愚蠢的测量方法。
　　什么是探索测试
　　Ÿ 我接受(也做了一定程度贡献)Kaner的定义，这个定义2007年经过多个会议中的修正。
　　探索测试是：
　　Ÿ 一种风格的软件测试方法
　　Ÿ 强调个体自主权和责任
　　Ÿ 是针对单个测试人员
　　Ÿ 为了持续优化他/她工作的价值
　　Ÿ 通过处理测试设计、测试执行、测试结果说明以及测试相关的学习
　　Ÿ 作为相互支持的活动
　　Ÿ 并行的执行
　　Ÿ 贯穿整个项目
　　为什么探索?
　　Ÿ 你不能用一个脚本
　　Ÿ 调查你已发现的问题
　　Ÿ 判断脚本是否有问题
　　Ÿ 避开你已识别出的脚本问题
　　Ÿ 识别产品中严重的风险
　　Ÿ 决定组织报告的最佳方式
　　Ÿ 弄清令人困扰的场景
　　即使是“脚本”测试人员也一直在探索!
　　是的，探索测试需要专业技能
　　探索测试是结构化的
　　Ÿ 我们已经学习了ET(探索测试)结构，我们已经写下来，我们知道如何教
　　Ÿ ET结构有很多来源(非过程化结构，是认知的结构)
　　Ÿ 测试设计启发
　　Ÿ 大纲
　　Ÿ 时间限制
　　Ÿ 觉察产品风险
　　Ÿ 具体测试的类型
　　Ÿ 待测产品的结构
　　Ÿ 学习产品的过程
　　Ÿ 开发活动
　　Ÿ 项目负担的限制和资源
　　Ÿ 测试人员的技能、才能和兴趣
　　Ÿ 测试全面的目标
　　探索测试是可说明的
　　精简的文档，最小的浪费
　　详细的过程文档非常昂贵，通常是不需要的。
　　教程似的文档也通常不需要，但是如果你做了，那么将它和工作文档区分开来。
　　探索测试是可说明的
　　基于会议的测试管理
　　Ÿ 大纲
　　Ÿ 每个测试会议有一个清晰简明的任务
　　Ÿ 时间限制
　　Ÿ 90分钟左右(+/-45)
　　Ÿ 审核结果
　　Ÿ 一份会议记录一份测试报告，数据可以被工具扫描、分析和编译。
　　Ÿ 任务汇报
　　Ÿ 测试人员和管理者或者测试主管之间的沟通
　　探索测试是可管理的
　　在实际测试和使用系统过程中，通过摸索不同的测试设计来提炼优秀的测试设计方案。
　　通过个别监督和简明的测试思路指导测试人员。同时，训练他们能够指导他们自己，能够考虑到可能增加的工作挑战。
　　探索测试是可管理的
　　注意检查的角色，尤其是当开发人员编写和维护代码后，需要增加额外的测试组件。

原文转自：http://www.ltesting.net