如果你是电影迷，那么可能听说过《豪勇七蛟龙》或《十二金刚》。好吧，我谈谈听起来不太吸引人的“测试8板斧”。测试8板斧并不是最新好莱坞大片的名称，而是指八项测试基础，其原理可以应用于任何开发方法，以确保其交付成果的质量。
如今，开发方法在不断变化，新的流行语和定义不断涌现。DevOps、Scrum和Kanban的敏捷和精益方法结合了传统的瀑布模型和V模型。随着向敏捷开发的转变以及人们对这些方法的误解，人们倾向于将注意力聚焦在交付速度上，这有时会损害质量。显然，对于任何软件开发而言，高效交付和按时交付都是至关重要的，但我们不应忽略有助于确保交付的产品符合目的的基本原则。
与普遍的看法相反，质量保证不必费力或费时。就如古老的谚语所说——“一针及时省九针。” 从长远来看，在开发生命周期的早期使用基本的QA技术将节省大量的时间、痛苦和精力；毕竟，就项目而言，尽早清除问题要比在生命周期后期修复相同的问题更经济。这听上去很简单，但是考虑到当前对精益和敏捷的需求，要如何实现这一点呢？
如果这是一部牛仔电影，那么“测试8板斧”将横空出世。
1、明确测试范围
都应知道要计划进行的测试，这似乎不是问题！但实际情况是不总是像你期望的那么清楚，因为某些功能可能由于测试团队无法控制的各种原因而进入和退出开发范围。试图确保交付质量时，明确范围至关重要。如果不清楚交付的内容，则无法衡量成功，因此需要在项目团队内部商定测试范围的摘要，并形成文档以供参考。
2、分享和评审
还记得小时读书交作业之前让父母检查一遍吗？当应用于IT开发时，相同的做法也会带来好处。无论采用哪种开发方法，对需求、设计、测试需求和测试用例的评审都应作为标准。在需求收集阶段识别和解决需求问题要比让问题渗透到设计中并成为后来由测试确定的软件缺陷廉价得多。评审还可以促进项目团队内部的协作和知识传递，使不同的团队对彼此的成果有更好的了解和欣赏。
3、测试可追溯
一旦确定了范围并提取了测试需求，就必须证明测试的可追溯性。这可以通过简单地在每个测试和其来源之间提供可追溯性来实现。这可能是需求、设计或原型图。测试的可追溯性很重要，因为它证明测试范围覆盖了测试需求。项目团队对可追溯性文档进行审查可以突出显示任何遗漏或不应测试的区域。
4、测试排优先级
任何有经验的测试专家都会告诉你，测试时间总是会被挤压。即使不是这种情况，采用基于风险的方法对测试进行优先级排序也很有意义，这使你对重要功能的测试更有信心。抽取测试用例后，从失败风险和失败影响的角度对它们进行评级很重要——高、中或低测试优先级。可以通过与开发团队讨论来确定失败的风险，而失败的影响则需要业务或技术支持团队参与评估。高优先级，高影响力的功能测试应优先考虑，以识别潜在问题，并尽早在测试时间内对这些功能建立信心。
5、计划执行工作
一旦为测试用例分配了优先级，并且通过了评审，下一步就是做测试计划。计划执行高、中、低优先级用例的顺序。计划好测试日程需要交付的成果物，并预留好处理紧急问题和重新测试的时间。该计划还将提供一种度量，一旦开始执行测试，就可以据此报告进度。
6、了解测试入口标准
输入标准详细说明了能够启动测试所需满足的条件。这些标准将包括外部依赖性，例如批准的需求/设计文档，范围定义，测试环境，测试数据，测试用户以及测试团队的活动，例如测试准备、完成和审查。入口标准应作为测试执行的质量门，以确保在开始执行之前已满足所有要求的条件。通常会与相关的交付利益相关者举行一次入口会议，以审查这些标准并做出明智的决定，以确定是否满足所有入口标准，让各方意见统一。
7、知道测试退出标准
建立并统一退出标准对于测试的任何阶段都是至关重要的。退出标准列出了测试旨在达到的目标以及成功的情况。作为计划的一部分，需要确定测试需要完成的工作，然后才能将测试视为完成。这些标准通常是测试覆盖率以及缺陷数量和类型的度量。例如，你的条件可以是：
所有高优先级和中优先级的测试100％执行。
没有严重性或优先级为1或2的缺陷。
只要定义了可接受的解决过程和时间表，严重性或优先级为3的缺陷就可能很严重。
8、传达测试报告
报告可以分为进度报告和完成报告：
进度报告：在测试执行过程中准确、高效地报告进度至关重要，因为它为测试中交付物的质量提供了晴雨表。现在，许多测试工具都可以方便出进度报告，但简单来说，报告应提供针对计划的测试、已执行的测试和正执行的测试，通过、失败、阻塞等情况进行度量，并对缺陷的数量和优先级/严重性进行统计。报告应足够详细，以突出显示任何潜在的问题；因此，有必要在各个功能区域以及每个功能区域的高、中和低优先级测试的状态上提供粒度。通常每天生成报告，以便向感兴趣的干系人提供更新。
完成报告：简短的完成报告总结了在测试执行期间完成的测试。这也应该足够细化，以提供测试覆盖范围和测试各个功能区域的结果，并总结在执行结束时发现、解决和未解决的缺陷。理想情况下，此报告还将提供对已发现缺陷的根本原因分析，以便用于解决今后出现的问题。该文档将使开发团队和干系人了解所测的可交付成果的质量，并让他们判断是否达到预期。
“测试8板斧”不会出现在电影屏幕上，而是被用来提高应用或IT系统的质量！如你所见，其中一些基础知识取决于项目团队内部的协作，并适合于交互式会议和研讨会。讨论和意见统一是好的，但是如果不记录讨论的结果，则可能会丢失重要的项目决策，因此质量保证取决于一定程度的文档。
现在，尽管“文档”一词可能会引起许多在敏捷或精益开发环境中扎根的IT专业人员的恐惧，但其实无需如此。可以采用一种常识性的方法来确保支持这些基本原理的细节被捕获和记录，以补充而不是抑制正在使用的开发方法。这些细节可能包括关键需求、决策、项目资产和测试用例等等。通过简短的文档或电子表格可以很容易地记录这些信息。这些内容记录分发给干系人进行审批时，只需清晰易懂即可，但必须保证这些记录已达成统一。
质量保证要记住的重要一件事是在管理与开发速度之间取得适当的平衡。正确的管理级别可以确保你的组织所依赖的系统的质量而不会造成繁琐的工作，使大家充满信心，提供你和你的客户需要和期望的功能。
-- End --
文末寄语：人生就是一场醒悟，不要昨天，不要明天，只要今天。有些事，不是不在意，而是在意了又能怎样。人生没有如果，只有后果和结果。成熟，就是用微笑来面对一切小事。