颠覆完美软件：软件测试必须知道的几件事（读书笔记4）

7、测试评估方法和测试误区（第8章和第9章）

　　良好的测试是没法确认的。可是咱们能够经过不少方法，知道或估算出很差的测试是什么样的。识别出有关测试的主要误区，能够更好的进行测试。　　

　　测试的评估方法　

　　一、永远没法确切地知道良好的测试

　　完美的测试具备以下特色：a)它会检测出一个系统中的全部缺陷；b)它永远不会将不是缺陷的状况判断为缺陷；3)它能让咱们彻底确信它完成了a和b；d)针对咱们的须要，它能够足够迅速和廉价地实现a、b和c。你会发现完美的测试和很糟糕的测试具备惊人的类似性，一个很糟糕的测试也可能会知足a、b、c和d。

　　良好的测试是描述测试与某个实现之间的特定关系的属性。咱们是没法知道测试是良好的，可是咱们咱们能够根据一些元信息知道测试是否糟糕。

　　二、根据事实来评估良好性

　　1）根据系统中缺陷的多少，来评估一组测试的良好性。

　　　　对这些缺陷进行追踪，分析他们的具体使用状况，能够获得一些信息。好比，测试有多好，以及好在哪些方面；未来能够如何对测试加以改进；测试会常常遗漏哪一种缺陷。

　　2）根据长时间积累的缺陷，进行评估

　　3）其余评估方法

　　　　将测试覆盖范围和故障理论进行比较；随机改变测试来了解问题如何出现；对不一样类型测试进行比较。

　　三、植入缺陷进行评估

　　　　插入已知的缺陷而不告诉测试人员，而后根据他们发现的这些已知缺陷来估算剩余的缺陷数量。插入的缺陷是系统中天然产生，可是已经被开发人员在代码审查或单元测试中解决了。

　　四、好的评估是统计性的

　　　　对良好性的估算只是一个估算。咱们只能从统计意义上估算良好性，由于咱们没法确切地知道特定系统中由或者曾经有多少缺陷。

　　　　不少经理根据测试人员发现缺陷的数量来评价他们，这意味着低质的系统会让测试人员看起来更好。这种缺陷的体系流行的缘由是：1）测试人员在解释他们寻找缺陷的方法及他们的作法应该得到尊重的缘由方面作得不够；2）经理和开发人员假定产品能够工做的时候，没有告诉测试人员关于产品的信息，好比应该从哪几个方面来评定产品能够正常工做。

　　五、其余的估算方法

　　1）测试是否在名义上可以提供须要的信息？

　　2）测试是否进行了文档记录？

　　3）测试是不是真实的？有人能够有意或无心的捏造测试数据和文档吗？

　　4）测试是否覆盖了那些最重要的部分？不可能对全部路径进行测试，但一组测试至少应该让每行代码都被访问一次。

　　5）是否能够看出测试和演示之间的区别？演示被设计用于让系统看起来不错。测试应该被设计用于让系统表现出它真实的样子。

　　6）测试报告是否表现出极强的可预测倾向，若是这样，测试可能就过于表面化，或者报告中可能遗漏了某些重要信息。

　　7）不一样类型的测试活动之间是否有不一致的地方？好比性能测试发现了功能性缺陷，可能意味着某个过程出了问题。

　　8）经理是明察秋毫吗？测试经常会因为存在一名由于专心而出名的好奇经理得以改进。

　　六、相关常识

　　1）须要考虑最终的测试目标，并思考如何得知本身将会须要哪些其余信息。

　　2）不要已发现缺陷的数量来衡量测试人员，而要以得到信息的质量来评定。

　　3）了解正在测试的软件结构有助于肯定要尝试的特殊用例、细节特性和范围，这些有助于缩小存在软件能作什么和它在实际使用中会作什么的推理缺口。

　　4）测试过于了解产品内部结构也很差，因此测试最好能模拟那些初级用户可能采用的行为方式。

　　5）说明缺陷的估算数据应给出一个范围（此版本中大约有30到40个缺陷），或者用统计分布图的方式。

　　6）发现大量缺陷会让测试人员看起来工做的不错，但会减缓测试的进度，下降测试的覆盖范围，或者同时致使两种后果。由于安装配置、缺陷调查和报告都会占用测试设计和执行的时间。

　　测试的主要误区

　　一、测试误区

　　错误的想法会毁掉一个测试项目，这些误区可能致使不良测试发生。

　　1）指责误区

　　　　一些经理认为，若是他们指责某我的，用责备的语气和音量来讲话，就可让问题更快、更有效，也更高效地解决。这是不对的。

　　2）穷举测试误区

　　　　经理认为的穷举测试是对全部可能性进行测试。而真正的“穷举测试”是指测试人员在测试方面已经筋疲力尽的时候。

　　3）“测试产生质量”误区

　　　　质量是整个开发过程的产物。而测试主要仍是收集信息，产品质量的提升须要看经理对测试反馈的信息的态度。是当即进行修复仍是进行忽视无论。

　　4）分解误区

　　　　开发人员对模块进行单元测试，测试人员对接口进行系统测试。若是开发人员认为对模块进行的测试，就表明测试了整个系统。就犯了分解误区。

　　5）合成误区

　　　　测试人员认为对系统总体进行测试，那么组成该系统的各个部分进行了测试。就犯了合成误区。

　　6）“全部测试都相同”误区

　　　　开发人员测试单个模块，测试人员测试系统。经过进行两种不一样类型测试，能够肯定需求，目的和实现之间是否同样。

　　7）“随便哪一个笨蛋均可以测试”误区

　　　　开发人员对模块的测试老是探索性的，先前测试的结果会对未来的测试产生很大影响。测试人员应从开发人员那里了解测试背后的动机，测试人员能够根据有关产品和测试的最新信息来充实实际进行的测试。

　　二、相关常识

　　1）指责也许能够带来短时间效果，可是它带来的长期后果可能不会有益的。

　　2）测试问题一般要求进行更多分析，尤为是你发现本身正在指责别人时。

　　3）若是要求进行“穷举测试”，获得的就是测试人员以不一样方式进行欺骗，对他们的经理进行隐瞒，直至最终的反叛。

　　4）认为系统测试能够捕获全部缺陷，而将单元测试看成冗余的加以忽略。忽略了单元测试，后期可能花更长的时间和成本进行测试。

　　5）质量是整个开发过程的产物。不良的测试会致使不良的质量，可是良好的测试并不必定能致使良好的质量，除非整个开发过程的其余部分都是恰当的而且获得了正确的执行。

8、如何反驳测试就是敲键盘的行为（第10章）

　　敲击键盘的行为不是测试，那么什么样的行为才是测试呢？

　　测试的真正工做室脑力活动。若是你敲击键盘的时候没有思考，你就不是在进行测试。若是你在思考可是没有敲击键盘，你可能仍是在测试。

　　做者给出总结：一种行为要成为测试，无论他是否包括了敲击键盘，都须要寻找会对行为产生影响的信息。

　　一、毫无目的的敲击键盘不是测试

　　　　若是只是收集关于某种特性的信息，并不知道对这些信息作什么用，那么就不是测试。

　　二、对公司进行测试（白手套测试）

　　　　去任意一家公司作测试工程师以前，都须要问问这个公司有没有对测试过程进行定义，有没有相关文档。

　　三、开发人员本身测试（狗食测试）

　　　　开发人员在发布软件以前，会有不少的方式对本身的产品进行测试。在编写软件时，查看是否有语法错误，是否是知足功能性需求。在编写软件后，应经过使用本身的产品进行测试。

　　四、对测试人员进行测试

　　　　对测试人员是否可以胜任工做进行测试，让两我的同时测试一个产品的相同部分，看最终结果。

　　五、无心识状况下的测试

　　　　生活中，咱们可能对不少东西的使用进行测试。好比，喝一口汤，若是很差喝就不会再喝；固然你也会向，钱已经花了，难喝也要喝掉吧。只要你使用测试的结果，并作出与风险的决定，那么就是在测试。

　　六、演示不是测试

　　　　演示被设计用于让系统看起来不错。测试应该被设计用于让系统表现出它真实的样子。

　　七、相关常识

　　1）计算机只会作你要它作的事，而不会管这是否是你真正想作的事。

　　2）能够构建或者安装某些工具来得知系统的哪些部分历来没有被任何测试接触过。

　　3）代码覆盖测试不能代表全部功能都被测底测试过。要分析测试的相关性和全面性，才能肯定是否已经进行了完全的测试。即，要进行思考。

　　4）要清楚过程文档和测试过程：过程就是你实际上作的事，而过程文档则描述了某人但愿你作的事，是理想状况。大多数过程根本没有任何文档，不然，咱们会被无穷无尽的文档压垮。咱们最好将宝贵的时间用于对过程，也就是对人们实际上作的事进行观察。利用节约下来的时间决定将少数的那几个过程用准确的文档备份下来。