探索式测试：基于测程的软件测试管理
探索式测试：基于测程的软件测试管理
为了有效地管理测试，测试领导需要评估测试团队的生存力、当前测试的进度、测试覆盖的范围、已经暴露的风险、测试人员是否需要帮助等因素。一个好的测试流程可以帮助测试领导和测试团队了解这些因素，并实施积极的管理。为了使探索式测试满足软件开发团队对可管理性的要求，Jonathan Bach和James Bach提出了基于测程的测试管理（Session-Based Test Management，简称SBTM）[Bach2000]。本文将介绍SBTM的概念与方法。
Session的翻译：测程
在翻译Session时，我遇到了困难，因为现有的中文表达难以传递出SBTM中Session的两层含义：
● Session是一段不受打扰的测试时间（通常是90分钟），是测试管理的最小单元。
● 一系列Session相互支持，有机地组合在一起，周密地测试了整个产品。
在如此语境下，Session的同义词是Term（学期、会期）、Period（时段、课时）、Semester（学期），但是直接使用这些同义词的中译并不适当。进过反复考虑，我将Session翻译为“测程”，原因有三点：
● 用专用术语“测程”指代SBTM的Session，与Session的其他含义或中译（如“会话”）做明显的区分，这有利于快速、清晰地传达语义。
● “测程”表达出Session的基本语义：一段专注于测试的过程。
● “测程”与“课程”有相似的词汇结构，暗示了一系列测程组合在一起研究了整个产品，正如课程通过一系列课时讨论了一个完整的领域。
测程的四个要点
测试专家Michael Bolton用一页幻灯片总结了SBTM的特征与内容[Bolton2006]。
如幻灯片的标题和右侧的图画所示，SBTM的重要特征是将测试过程分解为一组测程，从而提高整个测试项目的可说明性（Accountability）。为此，一个测程包含四个要点：主题（Charter）、时间盒（Time Box）、可评审的结果（Reviewable Results）和简报（Debriefing）[Bach2004]。
主题（Charter）是一个测程需要完成的任务。该任务应该是清晰且具体的，可以在90分钟的时间内完成，并提供有价值的简报。主题通常用一段简练的文字描述，其内容可以是测试一个功能、检查一个风险、测试一组用户情景（User Scenario）等。以下是两个实例[Michael2007]：
● Create a test coverage outline and risk list for DecideRight. （为产品DecideRight生成测试覆盖大纲和风险列表）
● Explore a decision created with QuickBuild – the wizard that guides the user through the options， criteria， and weights needed to calculate the best decision. （探索QuickBuild如何产生一个决策——用户向导应该引导用户使用选项、标准和权重来计算最佳决策）
时间盒（Time Box）是一段不受打扰的测试时间，其长度一般在60~120分钟，以90分钟较为常见。在此期间，测试人员不回答问题、不回复邮件、不应答即时消息，只专注地实施测试。从工程师的角度，时间盒使测试人员能排除干扰，全力应对测试的智力挑战。从测试团队的角度，固定且专属的时间盒使得测试规划和进度追踪变得更容易。
可评审的结果（Reviewable Results）是测程的产出，常见的形式是测程表（Session Sheet），其内容可以包括：
● 主题（Charter）
● 测试人员
● 测试所覆盖的区域
● 测试设计和测试发现
● 测试所发现的缺陷（Bugs）
● 测试所发现的问题（Issues）
● 测试所使用的数据文件
● 测试活动的时间统计：在产品安装、测试设计与执行、缺陷调查与报告、非测试活动中各花费了多少时间。
简报（Debriefing）通过面对面的交流将测试情况传递给测试领导。在一天的测程结束后，测试人员向测试领导当面汇报测试情况。领导查看测程表，提出一些问题，测试人员解释测试结果，并回答疑问。测试领导也可以召开小组会议，让测试人员轮流报告当天的测试结果，使测试团队对当前产品的质量形成较完整的认识。
测程表（Session Sheet）
传统上，测程表是一个文本文件，拥有固定的格式。这样，测试领导可以用一个文本处理程序从多个测程表中提取信息，形成聚合的测试报告。测试人员也可以用程序读取测程表，将其中的缺陷记录自动提交到缺陷管理系统。Michael Bolton曾经分享过两个测程表的实例[Bolton2007]，本文摘录一个实例如下。
该实例反映了测程表的几个特点：
● 测程表记录了一些任务分解（Task Breakdown）数据，如在测试设计和执行（Test Design and Execution）、缺陷调查和汇报（Bug Investigation and Reporting）、测程建立（Session Setup）等活动上花费的时间。这些数据配合简报有助于测试领导估算测试速度、评估测试效率。
● 测程表拥有固定的格式，该实例用特殊符号“#”标记了文本处理程序可以提取的数据。测试人员只要遵循简单的格式，就可以产生易于自动分析的测程表。一个简单的文本处理程序（或脚本）能够批量地处理测程表，产生测试报告和图表，并完成自动化任务（如提交缺陷记录到缺陷管理系统）。
● 测程表列举了测试所使用的数据文件（Data Files），为测试数据复用提供了基础。
● 测程表的核心是测试笔记（Test Notes），它简略地叙述了测试故事（Testing Story）：为什么测试，如何测试，为什么认为我们的测试是足够好的。
● 测程表记录了缺陷（Bugs）和问题（Issues），它们不但是测程的直接产出，还是规划未来测试的参考资料。
近年来，出现了更多的SBTM支持工具[Carvalho2011]，能够支持更富表现力的测程表。例如，RapidReporter可以方便的生成CSV和HTML格式的测程表，CSV格式便于进一步地自动处理，HTML格式则支持较复杂的排版和屏幕截图。
聚合测程表收集的数据，测试领导可以评估团队的测试速度。下图显示了已执行测程的总时间随日期的变化趋势，这有助于测试领导评估在项目结束前还可以执行多少测程[Jonathon2004]。如果余下的测试时间不足以完成测试使命，他需要采取措施，以避免项目失败。
SBTM是动态管理
在项目之初，测试团队对产品还不够了解，测试领导可以安排一些“侦查型”的测程去学习产品的各个区域。例如，上文提到的“为产品DecideRight生成测试覆盖大纲和风险列表”就侦查了产品的主要功能和风险。基于这些测程的测程表和简报，测试领导可以拟定测试项目的总体计划，并大致规划出测程的数目与主题。
在项目过程中，好的测试领导会通过测程表和每日简报，积极发现产品或测试的问题，实施有针对性的解决方案。例如，测试领导老王通过阅读测程表，发现测试人员小张常常花费过多的时间在缺陷调查上，他会与小张交谈以了解情况。面对面的交流使信息得到高效地传递，并有助于消除统计数据的误导和书面文字的歧义。如果小张是喜欢打破沙锅、追根究底，老王会告诉他：在调查缺陷时，可以设定一个最长用时（如15分钟），当时间用尽，应该停止调查，根据已知情况提交缺陷报告。此外，他还会安排一些有技术挑战的任务给小张，以帮助他的技术成长。如果小张是不了解产品而花费了过多的调查时间，老王会安排有经验的员工指导小张，或亲自传授一些知识和技能，以帮助他渡过难关。如果是糟糕的可测试性导致了过长的调查时间，老王会和开发团队联系，提出改进意见，以推动产品可测性的提高。
随着产品和项目环境的变化，测试内容与策略也要做相应的调整。测试领导会根据测程的结果来调整下一步的测试计划。他可以新增几个测程，以调查最新发现的风险；他也可以合并几个测程，将省下的时间分配给更重要的测程。一切调整的目标都是为了优化测试的价值。
由以上论述不难看出，SBTM与敏捷开发宣言[Agile01]是高度一致的。在原则上，他们都认同：
● 个体和互动高于流程和工具
● 响应变化高于遵循计划
在实践上，他们都认可：
● 围绕被激励起来的个人来构建项目。提供他们所需的环境和支持，并且信任他们能够完成工作。
● 在团队内部，最有效率与效果的传递信息的方法，就是面对面的交流。
可见，SBTM和敏捷开发虽然来自于不同的专家、实践和社区，但是他们拥有相似的核心，其思想和方法可以相互借鉴与补充。
SBTM是管理框架
测试专家Paul Carvalho指出SBTM一个管理框架（Management Framework），其基本元素是：设定清晰的主题、固定长度且不受打扰的工作时间、产生可检查的结果、利用评审和简报来驱动未来的Session [Carvalho2010]。该框架的合理名词也许不是Session-Based Test Management，而是Session-Based Task Management。个人或团队可以用它管理各种类型的（创造性）活动，如编程、写作、锻炼身体、整理房间等。
从这个角度，SBTM与SMART 原则（Specific, Measurable, Achievable, Relevant, Time-boxed）和番茄工作法有异曲同工之妙。
● Specific（具体的）：一个测程需要一个具体的主题，一个番茄钟需要一个具体的目标。
● Measurable（可度量的）：测程产出测程表以反映测试进展。番茄钟关注当前任务是否完成，并收集过程指标。
● Achievable（可实现的）：对于测程和番茄钟，主题和目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标，且每个小目标也是具体的、可度量的、可实现的。而且，追踪小目标的完成情况提供了整体进度的可度量性。
● Relevant（相关的）：测程要为测试项目服务，要切合当前情况，并优化产品价值。番茄钟要针对最重要的任务，以实现自我承诺。
● Time-box（有时间限制的）：测程和番茄钟都提供了一个固定的时间段以一心一意的工作。
版权声明：本文出自 liangshi 的51Testing软件测试博客：http://www.51testing.com/?298785
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
为了有效地管理测试，测试领导需要评估测试团队的生存力、当前测试的进度、测试覆盖的范围、已经暴露的风险、测试人员是否需要帮助等因素。一个好的测试流程可以帮助测试领导和测试团队了解这些因素，并实施积极的管理。为了使探索式测试满足软件开发团队对可管理性的要求，Jonathan Bach和James Bach提出了基于测程的测试管理（Session-Based Test Management，简称SBTM）[Bach2000]。本文将介绍SBTM的概念与方法。
Session的翻译：测程
在翻译Session时，我遇到了困难，因为现有的中文表达难以传递出SBTM中Session的两层含义：
● Session是一段不受打扰的测试时间（通常是90分钟），是测试管理的最小单元。
● 一系列Session相互支持，有机地组合在一起，周密地测试了整个产品。
在如此语境下，Session的同义词是Term（学期、会期）、Period（时段、课时）、Semester（学期），但是直接使用这些同义词的中译并不适当。进过反复考虑，我将Session翻译为“测程”，原因有三点：
● 用专用术语“测程”指代SBTM的Session，与Session的其他含义或中译（如“会话”）做明显的区分，这有利于快速、清晰地传达语义。
● “测程”表达出Session的基本语义：一段专注于测试的过程。
● “测程”与“课程”有相似的词汇结构，暗示了一系列测程组合在一起研究了整个产品，正如课程通过一系列课时讨论了一个完整的领域。
测程的四个要点
测试专家Michael Bolton用一页幻灯片总结了SBTM的特征与内容[Bolton2006]。
如幻灯片的标题和右侧的图画所示，SBTM的重要特征是将测试过程分解为一组测程，从而提高整个测试项目的可说明性（Accountability）。为此，一个测程包含四个要点：主题（Charter）、时间盒（Time Box）、可评审的结果（Reviewable Results）和简报（Debriefing）[Bach2004]。
主题（Charter）是一个测程需要完成的任务。该任务应该是清晰且具体的，可以在90分钟的时间内完成，并提供有价值的简报。主题通常用一段简练的文字描述，其内容可以是测试一个功能、检查一个风险、测试一组用户情景（User Scenario）等。以下是两个实例[Michael2007]：
● Create a test coverage outline and risk list for DecideRight. （为产品DecideRight生成测试覆盖大纲和风险列表）
● Explore a decision created with QuickBuild – the wizard that guides the user through the options， criteria， and weights needed to calculate the best decision. （探索QuickBuild如何产生一个决策——用户向导应该引导用户使用选项、标准和权重来计算最佳决策）
时间盒（Time Box）是一段不受打扰的测试时间，其长度一般在60~120分钟，以90分钟较为常见。在此期间，测试人员不回答问题、不回复邮件、不应答即时消息，只专注地实施测试。从工程师的角度，时间盒使测试人员能排除干扰，全力应对测试的智力挑战。从测试团队的角度，固定且专属的时间盒使得测试规划和进度追踪变得更容易。
可评审的结果（Reviewable Results）是测程的产出，常见的形式是测程表（Session Sheet），其内容可以包括：
● 主题（Charter）
● 测试人员
● 测试所覆盖的区域
● 测试设计和测试发现
● 测试所发现的缺陷（Bugs）
● 测试所发现的问题（Issues）
● 测试所使用的数据文件
● 测试活动的时间统计：在产品安装、测试设计与执行、缺陷调查与报告、非测试活动中各花费了多少时间。
简报（Debriefing）通过面对面的交流将测试情况传递给测试领导。在一天的测程结束后，测试人员向测试领导当面汇报测试情况。领导查看测程表，提出一些问题，测试人员解释测试结果，并回答疑问。测试领导也可以召开小组会议，让测试人员轮流报告当天的测试结果，使测试团队对当前产品的质量形成较完整的认识。
测程表（Session Sheet）
传统上，测程表是一个文本文件，拥有固定的格式。这样，测试领导可以用一个文本处理程序从多个测程表中提取信息，形成聚合的测试报告。测试人员也可以用程序读取测程表，将其中的缺陷记录自动提交到缺陷管理系统。Michael Bolton曾经分享过两个测程表的实例[Bolton2007]，本文摘录一个实例如下。
该实例反映了测程表的几个特点：
● 测程表记录了一些任务分解（Task Breakdown）数据，如在测试设计和执行（Test Design and Execution）、缺陷调查和汇报（Bug Investigation and Reporting）、测程建立（Session Setup）等活动上花费的时间。这些数据配合简报有助于测试领导估算测试速度、评估测试效率。
● 测程表拥有固定的格式，该实例用特殊符号“#”标记了文本处理程序可以提取的数据。测试人员只要遵循简单的格式，就可以产生易于自动分析的测程表。一个简单的文本处理程序（或脚本）能够批量地处理测程表，产生测试报告和图表，并完成自动化任务（如提交缺陷记录到缺陷管理系统）。
● 测程表列举了测试所使用的数据文件（Data Files），为测试数据复用提供了基础。
● 测程表的核心是测试笔记（Test Notes），它简略地叙述了测试故事（Testing Story）：为什么测试，如何测试，为什么认为我们的测试是足够好的。
● 测程表记录了缺陷（Bugs）和问题（Issues），它们不但是测程的直接产出，还是规划未来测试的参考资料。
近年来，出现了更多的SBTM支持工具[Carvalho2011]，能够支持更富表现力的测程表。例如，RapidReporter可以方便的生成CSV和HTML格式的测程表，CSV格式便于进一步地自动处理，HTML格式则支持较复杂的排版和屏幕截图。
聚合测程表收集的数据，测试领导可以评估团队的测试速度。下图显示了已执行测程的总时间随日期的变化趋势，这有助于测试领导评估在项目结束前还可以执行多少测程[Jonathon2004]。如果余下的测试时间不足以完成测试使命，他需要采取措施，以避免项目失败。
SBTM是动态管理
在项目之初，测试团队对产品还不够了解，测试领导可以安排一些“侦查型”的测程去学习产品的各个区域。例如，上文提到的“为产品DecideRight生成测试覆盖大纲和风险列表”就侦查了产品的主要功能和风险。基于这些测程的测程表和简报，测试领导可以拟定测试项目的总体计划，并大致规划出测程的数目与主题。
在项目过程中，好的测试领导会通过测程表和每日简报，积极发现产品或测试的问题，实施有针对性的解决方案。例如，测试领导老王通过阅读测程表，发现测试人员小张常常花费过多的时间在缺陷调查上，他会与小张交谈以了解情况。面对面的交流使信息得到高效地传递，并有助于消除统计数据的误导和书面文字的歧义。如果小张是喜欢打破沙锅、追根究底，老王会告诉他：在调查缺陷时，可以设定一个最长用时（如15分钟），当时间用尽，应该停止调查，根据已知情况提交缺陷报告。此外，他还会安排一些有技术挑战的任务给小张，以帮助他的技术成长。如果小张是不了解产品而花费了过多的调查时间，老王会安排有经验的员工指导小张，或亲自传授一些知识和技能，以帮助他渡过难关。如果是糟糕的可测试性导致了过长的调查时间，老王会和开发团队联系，提出改进意见，以推动产品可测性的提高。
随着产品和项目环境的变化，测试内容与策略也要做相应的调整。测试领导会根据测程的结果来调整下一步的测试计划。他可以新增几个测程，以调查最新发现的风险；他也可以合并几个测程，将省下的时间分配给更重要的测程。一切调整的目标都是为了优化测试的价值。
由以上论述不难看出，SBTM与敏捷开发宣言[Agile01]是高度一致的。在原则上，他们都认同：
● 个体和互动高于流程和工具
● 响应变化高于遵循计划
在实践上，他们都认可：
● 围绕被激励起来的个人来构建项目。提供他们所需的环境和支持，并且信任他们能够完成工作。
● 在团队内部，最有效率与效果的传递信息的方法，就是面对面的交流。
可见，SBTM和敏捷开发虽然来自于不同的专家、实践和社区，但是他们拥有相似的核心，其思想和方法可以相互借鉴与补充。
SBTM是管理框架
测试专家Paul Carvalho指出SBTM一个管理框架（Management Framework），其基本元素是：设定清晰的主题、固定长度且不受打扰的工作时间、产生可检查的结果、利用评审和简报来驱动未来的Session [Carvalho2010]。该框架的合理名词也许不是Session-Based Test Management，而是Session-Based Task Management。个人或团队可以用它管理各种类型的（创造性）活动，如编程、写作、锻炼身体、整理房间等。
从这个角度，SBTM与SMART 原则（Specific, Measurable, Achievable, Relevant, Time-boxed）和番茄工作法有异曲同工之妙。
● Specific（具体的）：一个测程需要一个具体的主题，一个番茄钟需要一个具体的目标。
● Measurable（可度量的）：测程产出测程表以反映测试进展。番茄钟关注当前任务是否完成，并收集过程指标。
● Achievable（可实现的）：对于测程和番茄钟，主题和目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标，且每个小目标也是具体的、可度量的、可实现的。而且，追踪小目标的完成情况提供了整体进度的可度量性。
● Relevant（相关的）：测程要为测试项目服务，要切合当前情况，并优化产品价值。番茄钟要针对最重要的任务，以实现自我承诺。
● Time-box（有时间限制的）：测程和番茄钟都提供了一个固定的时间段以一心一意的工作。
版权声明：本文出自 liangshi 的51Testing软件测试博客：http://www.51testing.com/?298785
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。