读书笔记之《有效软件测试的50条建议》

译者序和前言（推荐）

理由：翻译者讲述自己曾就职的某公司的软件工程环境的发展（不是个人历程而是公司），其中穿插软件测试部门随着环境发展其人员素质、地位、特点。作为测试人员阅读，很可能从公司发展不同阶段经历中找到共鸣。前言部分主要介绍本书的组织架构，指导阅读每一章节。

第1章 需求阶段                                                                                                   

第1条 测试人员及早介入

这一条，是测试人员进入测试行业接触到的软件测试原则之一“应当尽早地和不断地进行测试”，综合来说是由于成本，在软件开发生命周期中发现缺陷越早，那么修复缺陷的代价就越小。

1. 在需求阶段发现的错误，仅需要修改需求文档就可以，如果在后期发现错误，那么可能就需要修改程序、设计文档、需求文档、测试计划，影响预算、进度和士气。

2. 测试人员尽早介入，有充分的时间彻底充分地了解产品（避免对产品功能的不理解，了解应用程序的对最终用户而言最关键和哪些元素风险最大），才有可能设计出更出色更全面的测试计划、测试用例。

3. 对测试人员而言，要提高个人测试过程的质量和深度，就必须掌握更加深入的知识，而这种知识只有了解撰写产品功能说明书的思考过程才能获得。

第2条 验证需求(★★★，强烈推荐)

这条经验其实就是接上一条经验，在需求阶段及早地发现需求的缺陷，避免这些缺陷不会遗留到下一阶段。每条需求验证其正确性、完整性、一致性、可测试性、可行性、必要性、优先级、明确性、可追溯性。其中以可追溯性的印象更为深刻，“当某条需求发生变化，通过可追溯性能够保证受到这种变化影响的需求及系统的其他部分。当测试人员受到需求变更通知时，他们就能保证所有受影响的部分都能做适应性调整。”这在我们测试过程中可能经常会遇到，对我们工作有借鉴作用。

第3条 需求就绪后激励设计测试过程

这一条实质与第1条一致，“尽早介入测试”，不能推迟到软件版本交付测试以后再设计测试过程，而应该安排在项目过程中更靠近需求阶段的位置。因为在设计测试过程中，测试人员会用测试数据集合作为输入非常仔细第走查系统的每个交互操作，所以可能会发现需求文档中某些疏忽、遗漏、错误的流程和其他错误。

另外，在设计测试过程中，需要标记出那些不可验证的需求。一种可能是需求说明过于含糊不清导致，还有一种可能是需求不能马上得到验证，但是也需要坚持跟踪。

第4条 确保需求变化的传达

当需求发生变更必须公开进行评估（对变更带来的影响进行分析、讨论和处理），形成一致的意见并且传达给所有涉众，避免后期测试过程与程序不匹配，出现错误的缺陷报告，浪费时间。需求变更传达到测试人员后（1）评估变更后的需求的可测试性（2）以前确定的缺陷必须重新评估，因为需求的变化可能使她们不再成为问题（3）变更对应的测试计划、测试用例、测试脚本也可能需要更新

第5条 注意在现存系统上进行开发和测试

这个我感觉说的是可能是，软件公司初入从未涉猎过的行业，收购了某个现存的小软件进行后续开发。在现存的应用程序基础上进行软件的开发工作可能是困难的，难以估算软件开发生命周期的时间、预算和需要的人员。但是呢，这里也给出了一些值得思考的要点。A使用确定的应用程序版本B把现存应用程序文档化C对先用应用程序的更新也要形成文档D实现有效的开发过程。

第5章 测试设计和测试文档

第20条 分而治之

当我们接手一个项目，它的需求非常多，要开始测试过程的开发，开起来好像无从下手。这条经验提供了一种有效的分解测试任务的方法。分解测试任务之前，回答以下问题：

1. 测试什么？确定哪些内容需要测试，哪些不需要测试，作为测试范围的一部分写入测试计划

2. 何时测试？一旦得到需求，就应该马上开发测试过程。并且确定测试的优先级，一般优先级高的需求会优先开发，那么测试也应该优先测试这些内容。

3. 如何测试？根据系统的不同部分使用最有效的测试，定义对应的测试策略。

4. 谁来测试？确定好以上内容后，根据测试人员的配置，确定执行各种测试任务的人员。

第21条 使用测试过程模板和其他测试设计标准

测试设计的标准要形成文档、认真传达并付诸实施，文档中最好包含一个范例（如测试用例文档）。一是非常节省时间的，而是避免遗漏输出一些重要信息。

第22条 根据需求得到有效的测试用例

在实际工作中，测试人员拿到完美需求的情况是非常罕见的，所以要求测试人员必须对文档进行分析，一般来说测试人员必须分析每一部分应用程序的任何一种变化对应用程序其他部分产生的影响，只验证这种变化本身还不够，必须覆盖到这种变化所影响的其他所有部分。

建立有效的测试过程还需要确定和评审关键的和高风险的需求，尽早地安排对最重要的功能测试和深入测试。

第23条 把测试过程当成“动态”的文档

大多数软件采用的是迭代式和渐进式的开发生命周期，那么每一次交付测试版本中测试的内容也是不一样的，测试过程必须在开发流程的每个阶段不断发展，

1. 在有限的时间条件下，测试过程根据当前开发版本的需求来设计

2. 原有需求发生变化时，测试人员必须相应地调整测试过程

3. 系统增加新功能时，测试人员必须设计新功能的测试过程

4. 有时由于修正缺陷改变了系统的运作方式，也需要修改测试过程。

第24条 利用系统设计和系统原型

本条经验适用于快速原型法的软件，原型可以让用户预先看到某个功能的实现结果，通过原型用户可以出去反馈意见，用于改进是的最终产品满足用户需求。测试人员可以借助原型监测需求中不一致性的地方，帮助测试人员确定哪些自动测试工作会遇到兼容性问题。

第25条 设计测试用例场景时采用经过检验的测试技术

用于测试过程输入的测试数据的组合和变化是无穷无尽的，所以对数据进行穷尽测试是不可能的，所以必须利用有效的测试技术（如等价类划分、功能分析法、路径分析法、边界值法和正交试验法）来减少测试用例和测试场景的数量，以最小的工作量达到最大的测试覆盖率。而经验表明：综合使用多种测试技术比使用单一的测试技术更有效。

介绍一下每种测试技术的用法。

第26条 在测试过程中避免包含限制和详细的数据元素

测试用例中包含详细的测试数据不是一种好做法，对于每一个测试数据场景，都必须重复定义所有的测试过程步骤，其中唯一的不同是数据输入和预期的结果。这样不必要的重复对于维护工作来说是灾难性的。所以应该将特定的测试数据输入和相应的预期输出结果单独放在一个场景文件中，场景可以被测试过程引用，而具体数据限制可以查阅数据字典。

第27条 运用探索性测试

探索性测试是对测试的系统缺乏了解（缺乏功能说明书或者没有充分的时间）的情况下产生的，与经过深思熟虑的、计划好的测试过程有所不同，但是非常有效。有如下三种情况会应用到探索性测试：（1）当测试人员执行测试发现了一个错误并试图重新并分析的时候，会使用探索性测试（2）在发现缺陷时，探索该缺陷与应用程序其他部分之间的关系（3）测试人员确定某个特定功能的阀值（开发、需求甚至客户代表都没有明确答案）

可以在测试执行后把探索性测试文档话，并把它们加入回归测试。

最强有力的测试工作不仅包括计划明确、定义明确的测试策略，而且还包括通过功能分析和其他测试技术获得的测试用例，这些技术包括：等价类划分、边界测试和正交排列测试，此外，还要通过深思熟虑的探索性测试来进一步加强测试。