七、测试评估方法和测试误区（第8章和第9章）
良好的测试是无法确认的。但是我们可以通过很多方法，知道或估算出不好的测试是什么样的。识别出有关测试的主要误区，可以更好的进行测试。
测试的评估方法
1、永远无法确切地知道良好的测试
完美的测试具有如下特点：a)它会检测出一个系统中的所有缺陷；b)它永远不会将不是缺陷的情况判断为缺陷；3)它能让我们完全确信它完成了a和b；d)针对我们的需要，它可以足够迅速和廉价地实现a、b和c。你会发现完美的测试和很糟糕的测试具有惊人的相似性，一个很糟糕的测试也可能会满足a、b、c和d。
良好的测试是描述测试与某个实现之间的特定关系的属性。我们是无法知道测试是良好的，但是我们我们可以根据一些元信息知道测试是否糟糕。
2、根据事实来评估良好性
1）根据系统中缺陷的多少，来评估一组测试的良好性。
对这些缺陷进行追踪，分析他们的具体使用情况，可以得到一些信息。比如，测试有多好，以及好在哪些方面；将来可以如何对测试加以改进；测试会经常遗漏哪种缺陷。
2）根据长时间积累的缺陷，进行评估
3）其他评估方法
将测试覆盖范围和故障理论进行比较；随机改变测试来了解问题如何出现；对不同类型测试进行比较。
3、植入缺陷进行评估
插入已知的缺陷而不告诉测试人员，然后根据他们发现的这些已知缺陷来估算剩余的缺陷数量。插入的缺陷是系统中自然产生，但是已经被开发人员在代码审查或单元测试中解决了。
4、好的评估是统计性的
对良好性的估算只是一个估算。我们只能从统计意义上估算良好性，因为我们无法确切地知道特定系统中由或者曾经有多少缺陷。
很多经理根据测试人员发现缺陷的数量来评价他们，这意味着低质的系统会让测试人员看起来更好。这种缺陷的体系流行的原因是：1）测试人员在解释他们寻找缺陷的方法及他们的做法应该获得尊重的原因方面做得不够；2）经理和开发人员假定产品可以工作的时候，没有告诉测试人员关于产品的信息，比如应该从哪几个方面来评定产品可以正常工作。
5、其他的估算方法
1）测试是否在名义上能够提供需要的信息？
2）测试是否进行了文档记录？
3）测试是否是真实的？有人可以有意或无意的捏造测试数据和文档吗？
4）测试是否覆盖了那些最重要的部分？不可能对所有路径进行测试，但一组测试至少应该让每行代码都被访问一次。
5）是否可以看出测试和演示之间的区别？演示被设计用于让系统看起来不错。测试应该被设计用于让系统表现出它真实的样子。
6）测试报告是否表现出极强的可预测倾向，如果这样，测试可能就过于表面化，或者报告中可能遗漏了某些重要信息。
7）不同类型的测试活动之间是否有不一致的地方？比如性能测试发现了功能性缺陷，可能意味着某个过程出了问题。
8）经理是明察秋毫吗？测试常常会由于存在一名因为专心而出名的好奇经理得以改进。
6、相关常识
1）需要考虑最终的测试目标，并思考如何得知自己将会需要哪些其他信息。
2）不要已发现缺陷的数量来衡量测试人员，而要以获得信息的质量来评定。
3）了解正在测试的软件结构有助于确定要尝试的特殊用例、细节特性和范围，这些有助于缩小存在软件能做什么和它在实际使用中会做什么的推理缺口。
4）测试过于了解产品内部结构也不好，所以测试最好能模拟那些初级用户可能采用的行为方式。
5）说明缺陷的估算数据应给出一个范围（此版本中大约有30到40个缺陷），或者用统计分布图的方式。
6）发现大量缺陷会让测试人员看起来工作的不错，但会减缓测试的进度，降低测试的覆盖范围，或者同时导致两种后果。因为安装配置、缺陷调查和报告都会占用测试设计和执行的时间。
测试的主要误区
1、测试误区
错误的想法会毁掉一个测试项目，这些误区可能导致不良测试发生。
1）指责误区
一些经理认为，如果他们指责某个人，用责备的语气和音量来说话，就可以让问题更快、更有效，也更高效地解决。这是不对的。
2）穷举测试误区
经理认为的穷举测试是对所有可能性进行测试。而真正的“穷举测试”是指测试人员在测试方面已经筋疲力尽的时候。
3）“测试产生质量”误区
质量是整个开发过程的产物。而测试主要还是收集信息，产品质量的提高需要看经理对测试反馈的信息的态度。是立即进行修复还是进行忽视不管。
4）分解误区
开发人员对模块进行单元测试，测试人员对接口进行系统测试。如果开发人员认为对模块进行的测试，就代表测试了整个系统。就犯了分解误区。
5）合成误区
测试人员认为对系统整体进行测试，那么组成该系统的各个部分进行了测试。就犯了合成误区。
6）“所有测试都相同”误区
开发人员测试单个模块，测试人员测试系统。通过进行两种不同类型测试，可以确定需求，目的和实现之间是否一样。
7）“随便哪个笨蛋都可以测试”误区
开发人员对模块的测试总是探索性的，先前测试的结果会对将来的测试产生很大影响。测试人员应从开发人员那里了解测试背后的动机，测试人员可以根据有关产品和测试的最新信息来充实实际进行的测试。
2、相关常识
1）指责也许可以带来短期效果，但是它带来的长期后果可能不会有益的。
2）测试问题通常要求进行更多分析，尤其是你发现自己正在指责别人时。
3）如果要求进行“穷举测试”，得到的就是测试人员以不同方式进行欺骗，对他们的经理进行隐瞒，直至最终的反叛。
4）认为系统测试可以捕获所有缺陷，而将单元测试当作冗余的加以忽略。忽略了单元测试，后期可能花更长的时间和成本进行测试。
5）质量是整个开发过程的产物。不良的测试会导致不良的质量，但是良好的测试并不一定能导致良好的质量，除非整个开发过程的其他部分都是恰当的并且得到了正确的执行。
八、如何反驳测试就是敲键盘的行为（第10章）
敲击键盘的行为不是测试，那么什么样的行为才是测试呢？
测试的真正工作室脑力活动。如果你敲击键盘的时候没有思考，你就不是在进行测试。如果你在思考但是没有敲击键盘，你可能还是在测试。
作者给出总结：一种行为要成为测试，不管他是否包括了敲击键盘，都需要寻找会对行为产生影响的信息。
1、毫无目的的敲击键盘不是测试
如果只是收集关于某种特性的信息，并不知道对这些信息做什么用，那么就不是测试。
2、对公司进行测试（白手套测试）
去任意一家公司做测试工程师之前，都需要问问这个公司有没有对测试过程进行定义，有没有相关文档。
3、开发人员自己测试（狗食测试）
开发人员在发布软件之前，会有很多的方式对自己的产品进行测试。在编写软件时，查看是否有语法错误，是不是满足功能性需求。在编写软件后，应通过使用自己的产品进行测试。
4、对测试人员进行测试
对测试人员是否能够胜任工作进行测试，让两个人同时测试一个产品的相同部分，看最终结果。
5、无意识情况下的测试
生活中，我们可能对很多东西的使用进行测试。比如，喝一口汤，如果不好喝就不会再喝；当然你也会向，钱已经花了，难喝也要喝掉吧。只要你使用测试的结果，并做出与风险的决定，那么就是在测试。
6、演示不是测试
演示被设计用于让系统看起来不错。测试应该被设计用于让系统表现出它真实的样子。
7、相关常识
1）计算机只会做你要它做的事，而不会管这是不是你真正想做的事。
2）可以构建或者安装某些工具来得知系统的哪些部分从来没有被任何测试接触过。
3）代码覆盖测试不能表明所有功能都被测底测试过。要分析测试的相关性和全面性，才能确定是否已经进行了彻底的测试。即，要进行思考。
4）要清楚过程文档和测试过程：过程就是你实际上做的事，而过程文档则描述了某人希望你做的事，是理想情况。大多数过程根本没有任何文档，否则，我们会被无穷无尽的文档压垮。我们最好将宝贵的时间用于对过程，也就是对人们实际上做的事进行观察。利用节约下来的时间决定将少数的那几个过程用准确的文档备份下来。