专访史亮：带你走进探索式测试-2
上一篇 / 下一篇 2012-08-27 11:24:08 / 个人分类：杂谈
例如，Fiddler是一个Web调试代理，能够记录并实时修改计算机与网络服务器之间的HTTP(S) 通信。Fiddler启动时将自身注册为Windows互联网服务的系统代理，因此能够监控所有Windows程序（包括Windows操作系统）的 HTTP通信。Fiddler还支持远程计算机连接，只要在移动设备上将代理设置为运行Fiddler的计算机，就可以使用Fiddler调试 Windows Phone、iPod、iPad等移动设备的HTTP通信 。
上图显示了Fiddler记录的浏览器与必应词典之间的通信，从区域A可知所查询的单词是testing，从区域B 可以获得服务器返回的JSON字符串。可见，测试人员利用Fiddler能够掌握被测产品与服务器之间的通信内容，有助于产生更多的测试想法。在测试过程 中，他可以修改客户端发送的请求，以测试服务器能否处理包含错误或攻击的请求；他也可以修改服务器返回的响应，以测试客户端能否处理包含错误或攻击的响 应。此外，Fiddler也可以用于错误定位。在客户端行为异常时，可以查看客户端与服务器的通信。如果客户端正确地发送了请求，但是服务器返回了错误的 响应，可以推断服务器发生故障；如果服务器返回了正确的响应，则可以推断错误发生在客户端。
探索式测试的实施与管理
51Testing：您是如何组织您的测试团队实施探索式测试的？请分享下这方面的实践经验。
史亮：我的博客文章“探索式测试：基于测程的测试管理”介绍了由测试专家Jonathan Bach和James Bach提出的基于测程的测试管理（Session-Based Test Management，简称SBTM）。这是目前最知名、也是应用最广的探索式测试管理方法。
51Testing：对于探索式测试的管理，您是否有一套自己独有的管理方法？
史亮：在测程之上，测试人员应该结合项目语境动态地调整测试策略和测试活动。例如，测试人员接到一个为期一周的测试任务：测试一个即将发布的产品补丁（或测试一个即将上线的新功能）。他可以考虑按如下方式组织测试。
周一，他安装补丁，并执行冒烟测试，目的是在第一时间发现严重的缺陷，如补丁无法安装、基本操作执行失败、基本情景 被阻塞等。然后，他会收集补丁相关的信息，例如被修复功能的规格说明和测试文档、缺陷描述和修复说明、互联网上相关的业务或技术文档等。他一边积极地学习 信息，一边“同情地测试”。测试的目的是检验信息的有效性，获得真实的反馈，并建立产品的测试模型，为进一步的测试做好准备。
周一下午，他会根据研究成果，编写一份1~2页的测试计划，列出已经执行和即将执行的测试想法，并发送给补丁开发人 员、资深测试同事、项目经理和测试领导，邀请他们对测试计划提供反馈。下班时，测试人员会对未来的测试充满信心，因为他已经验证了基本的功能，并根据多样 的信息源和真实的测试反馈拟定了有针对性的测试计划。
周二，测试人员会“积极地测试”，对补丁和被影响的相关功能执行深入的测试。在测试的间隙，他会将新的测试想法写入测试计划，使测试计划反映他对产品的最新理解。
周三，测试人员已经对补丁和产品有了深入的理解，他也陆续收到同事对测试计划的反馈。他会再次综合各方面信息，完善 产品的测算模型，从而“多样地测试”。他可以执行同事补充的测试想法，检查自动化测试的结果，利用测试工具执行压力测试，利用调试器检查产品代码的行为 ——他会运用一切手段去获取有价值的信息，直至新的信息不再出现。
周四下午，测试人员会将测试计划转化测试报告。这不是单纯的文档工作，而是再一次审视测试情况，梳理测试思路，以查漏补缺，为最后一天的测试做 好准备。如果测试情况显示测试人员需要更多的时间去完成测试，他可以立即将测试报告提交给测试领导，以说明情况，并申请更多的测试时间。
周五，测试人员也许会收到本周所提交缺陷的修复，他会“严谨地测试”。在发布前夕，对任何一行代码或配置文件的修改，都要做细致的、一丝不苟的 测试。测试内容往往是针对小范围代码的全面测试，包括简单的验证，也包括复杂的攻击。测试人员不会因为一周紧张的工作就放松懈怠，他会理解此时的细小的错 误将导致巨大的损失。最后，他会提交测试报告，在客观描述的基础上，给出他对补丁的评价和建议。
以上测试过程再次体现了探索式测试实施的一些特征。
● 明确的任务：测试一个产品补丁。
● 专注的测试：用一周的时间盒来实施测试。
● 可审查的结果：测试计划既是帮助测试人员的工具，也是测试报告的基础。
● 密切的交流：通过协作改进测试计划，通过测试报告建议进一步的测试行动。
● 根据产品的成熟度确定测试策略，并动态调整测试活动。
51Testing：以前的探索式测试工作中，遇到过哪些困难？您是如何解决的？
史亮：探索式测试强调测试学习、设计、执行、评估的相互支持，这潜在地要求动态变化测试设计。在许多测试团 队中，测试流程要求测试人员在项目之初编写测试计划，并接受团队评审。如何将探索式测试的动态测试设计纳入现有的工作流程，是一个探索式测试者需要面对的 问题。经过实践，我总结出以下测试计划编写与维护方法。
在项目计划阶段，我会编写简单的测试计划，包含产品概述、测试范围、测试风险、测试策略、资源分配和进度安排。编写文档的目的是建立对产品的整 体认知，根据风险提出相应的测试策略，并安排测试任务和日程。测试计划不必面面俱到，用精简的格式记录必要的内容即可。此时项目的不确定性较大，未知因素 较多，很可能不适合做出详细的测试决策。
测试计划初稿完成后，我会邀请项目关系人对测试计划进行评审。评审的形式可以多种多样，会议评审、桌面走查、邮件评审、在线文档批注、头脑风暴 皆可。评审的目的是发现“大图景”上的缺陷，并丰富测试策略。眼界开阔的项目经理、负责任的开发人员、经验丰富的测试同事能够提供很好的建议。
在测试阶段，我会根据测试进展持续更新测试计划，重点内容是产品模型、测试策略、覆盖大纲和风险列表等。测试计划应该是“活”的文档，能够反映 测试人员对产品和项目的最新认识。对测试范围、测试风险、测试策略和进度安排的重大变化应该写入测试计划，重要的测试用例（如发现严重缺陷的测试用例）也 应该及时融入测试策略。测试计划应该尽可能地精简，这有助于文档的持续更新，而冗长的文档将不利于阅读、增删和修订。
当测试计划相对完整之后，我会邀请项目关系人对测试计划进行评审。评审的目的是发现测试遗漏，补充测试策略，提高测试覆盖率。
以上方法有三个重要的特点。
第一，测试计划的编写与改进贯穿整个测试过程。在测试执行之前，对测试计划不必求全责备。在测试执行中，测试人员根据测试反馈，动态地调整测试范围、项目风险和测试策略，生成新的测试用例，并对测试计划做必要的更新。
第二，测试人员持续地收集对测试计划的意见，并将改进意见纳入测试实践。正式和非正式的测试计划评审可以识别潜在风险，丰富测试策略。在一些测 试流程中，测试计划评审只发生在测试开始之前。但是，我建议在测试流程的中期再次评审测试计划，目的是进一步丰富测试策略的多样性，并发掘可能的测试遗 漏。这时，测试团队对产品与风险拥有更深刻的理解，能够提出更具针对性和多样性的测试策略，也可以帮助测试人员发现测试盲点，从而提高测试覆盖率。
第三，测试计划侧重测试规划（一组指导测试过程的想法）和测试策略（一组指导测试设计的想法），而不是脚本化的测试用例，即测试计划用精简的格 式表达测试人员的测试想法，而不必详细记录测试用例的设置、步骤和预期结果。测试人员可以用文字、列表、表格、思维导图等任何合适的方式表达想法，目的是 激发测试灵感，并促进测试思想的交流。此外，他会利用发现缺陷的测试用例来完善测试策略，而不是让过去的测试用例控制未来的测试。
51Testing：您认为探索式测试为什么会获得成功？原因在哪？它的价值体现在哪里？
史亮：在第2个问题中提到了“敏捷测试”，其来源是“敏捷软件开发”。从术语的历史看，“探索式测试” （Cem Kaner提出于1983年）的历史比“敏捷软件开发”（敏捷宣言缔结于2001年）更悠久。近年来，探索式测试受到关注，其根本原因不在敏捷测试，而是 具有更深层次的原因。
第一、越来越多的测试人员意识到线性的（瀑布式的）需求评审、设计评审、测试计划、测试用例设计、测试用例执行、回归测试并不能很好地适应高速变化的软件开发，也不能准确地描述测试人员的真实工作方式。他们在积极地研究更好的测试思路和实践方式。
测试的本质是面向质量的技术调查，测试人员综合运用行业知识、测试技术、开发技术、批判性思维等多种知识，对产品质量进行采样、评判、分析和综 合。从这个角度，软件测试与犯罪现场调查相似。它们都面对众多且复杂的信息源，需要综合运用多种技术和工具，并随时追查可能的新发现和新猜想。侦探不会使 用预先编制的脚本去调查，他会收集尽可能多的证据，对其进行综合判读，然后选择有价值的证据进行深入研究，以发现更多的线索。在整个证据收集、判读、研究 的循环中，侦探会并行地展开多种调查活动，让它们相互支持。同样，测试人员会有机地组合信息收集、测试分析、测试设计和测试执行。虽然这些活动在理论上是 分离的，但是在实践中它们是相互交织、彼此支撑的。这是探索式测试之所以有效的根源——它的指导思想符合领域本质。
第二、探索式测试有助于“机动性”，该特性在现在比以往任何时候都更重要。随着互联网与Web应用席卷全球，软件竞争比以往更加激烈。开发组织 不仅要减少缺陷，还要跟踪不断变化的用户需求和市场需求，在紧迫的时间约束下交付赢得用户的产品。这要求软件企业在业务、研发、营销等方面均保持高机动 性。
探索式测试将许多测试决策置于更合理的时机，从而避免了浪费。面对高变动性的开发过程，测试人员需要将测试设计合理地分配到整个开发周期，根据 当前的开发进度和真实的测试反馈，做出恰当的测试决策。这有助于避免在信息不充分的情况下做出错误的决定，从而导致严重的浪费和返工。
此外，探索式测试不停地根据实际情况，调整测试计划，优化测试策略，因此能够更有针对性地测试。随着对业务领域的认识不断深入，随着逐渐了解产 品的设计和弱点，随着对测试技术和工具的更加熟悉，测试人员会不断调整测试策略，使得在整个产品开发过程中，重要错误的发现率都保持在比较高的水平。
史亮：人们研究探索式测试是为了“更好的软件测试”，探索式测试的发展应该针对软件测试所面临的使命与挑战。我认为以下几个方面会持续受到关注。
测试人员的教育。所有高效的测试都依赖于测试人员的测试技能和行业知识。在知识爆炸、行业高速发展的今天，如何培训测试新、如何培养测试专家、如何传承经验教训，将变得比以往更重要。探索式测试有助于测试人员的快速学习，在此领域会有更重要的作用。
测试建模。为了更好的测试，测试人员需要建立产品的模型，根据模型选择测试策略，并根据测试反馈，动态地调整模型。虽然，工业界和学术界已经积 累了一批模型，但是仍存在许多重要的问题值得研究。例如：在开发技术高速发展的情况下，如何分析新的平台、技术或产品，以高效地构建测试对象的模型 ；在测试资源有限、测试对象复杂的情况下，如何根据模型和其他信息选择测试策略；能否将分离的模型有机地组合起来，使得不同粒度的测试模型（模块级的模 型、子系统级的模型、系统级的模型、通用架构的模型）可以相互关联、彼此支持；能否建立测试策略的框架，使测试人员能够更全面地思考，并组合运用多种测试 策略。
测试自动化。近10年来，在测试驱动开发的推动下，自动化单元测试得到了长足的发展。但是，软件系统的复杂性要求更智能、更全面的测试，这使得 测试自动化存在巨大的创新空间。而云计算技术的出现，使得测试人员很容易（在短期内）获得几十台甚至上百台（虚拟）计算机。如何开发新的自动化测试以充分 利用这些计算机，不但是具有挑战的测试任务，也蕴含着巨大的机会。
测试工具集。测试工具会影响测试人员的思维，好的工具可以拓展测试人员的能力，坏的工具则束缚测试人员的手脚。目前，测试工具的发展尚落后于开 发工具的发展，特别是新开发技术出现时，测试人员常常没有对应的测试工具，甚至在一些开发技术很成熟的领域，测试工具的表现也不尽如意。
评估度量。项目决策依赖于一系列重要的信息：当前产品的质量如何、测试进度如何、当前测试方案存在哪些缺点、产品的哪些区域还需要深入测试、哪 些测试人员需要帮助等。现有的评估方法能提供一些初级的信息（如活跃缺陷曲线、缺陷分布图等），但并不能很好地回答这些问题，有时甚至会得出误导性的结 果。基于测程的测试管理是测试管理与评估的重要进展，但是测试行业还需要更多、更好的方法。
51Testing：给刚开始学习探索式测试的朋友一些学习建议吧。
史亮：第一，建议阅读我与高翔合著的《探索式测试实践之路》。这本书介绍了探索式测试专家们的理论与方法， 传达了正确的观念，回答了常见的疑问。阅读此书，有助于读者了解探索式测试全貌。对此，探索式测试专家James Bach给予了肯定：“此书是第一本总结了探索式测已发表工作的著作”。
第二，您不需要成为测试专家，才能开始探索式测试。探索式测试的核心实践是“学习”，即获取知识与应用知识的持续过程。在此过程中，测试人员不 但更加深入地理解产品，也更深刻地理解测试思想和测试技术。在学习探索式测试的道路上，动手实践并积极反思总是优于等待观望。任何一种方法都需要练习才能 纯熟，实战是迈向成熟的第一步。
第三，您不需要领导批准，才能开始探索式测试。也许您的团队要求详细记录测试设计，但这不妨碍您广泛地收集信息，通过简短的探索式测试或头脑风 暴，产生多样化的测试策略和测试用例。也许您的团队要求测试执行遵循脚本，但您总是可以在测试执行中引入新的变化，并根据新发现，即席设计测试用例，来触 发更多的变化。
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | 31 | ||||||
我的存档
数据统计
- 访问量: 3320923
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
