我的工作要求我编写自动化测试用例来测试系统。所谓自动化是指，测试的建立(set up)、执行(execution)、检查(verification)和拆卸(tear down)是无人值守的。这些测试用例被加入到每日测试(daily test)中，以测试每日构建(daily build)所生成的当日构建。这篇短文旨在总结我的测试实践，介绍如何用一种探索式的方法来开发测试用例，权当抛砖引玉。

　　在介绍具体的方法之前，需要明确自动化测试用例开发的目标。

　　1. 迅速找出重要的程序问题[Cem01]。尽快的发现项目的重大风险，有助于开发团队以较低的代价修正严重的错误。这要求，首先测试核心功能、常见场景、高风险区域，然后测试辅助功能、罕见场景、低风险区域。为了探测高风险的区域，需要对各个模块进行广泛的测试，以发现问题较多的模块；为了发现严重的问题，需要对一个模块进行深入探索，以发现隐蔽的错误。有时候，测试的广度和深度不可兼得，需要根据项目情况进行平衡。

　　2. 测试应该有助于提高质量[Gerard07]。测试用例可以看作“可执行的规范”，定义了各种场景中被测试系统的行为。这份规范应该是易读的，很容易理解测试了什么内容；它应该是尽可能完备的，规定了被测试系统大部分的行为。在回归测试中，这样一份规范可以防止引入缺陷，并尽快定位异常行为的原因。

　　3. 测试应该易于编写和维护[Gerard07]。软件测试是一个探索的过程，需要不停的增加、修改、删除测试用例，以反映对被测试系统不断深入的认识。当被测试系统发生变化时，自动化测试用例也需要随之修改。如果测试用例很难修改、很容易失败，那么测试者的时间往往耗费在测试维护上，而不是错误侦测上，这是得不偿失的。

　　测试用例开发不是线性的过程，需要不停的尝试，需要根据新的情况制定新的方向和策略。虽然本文用列表的方式介绍我的方法，但是在真实的测试过程中，它们是交错且迭代的。

　　1. 选择或开发一个适合的测试框架。测试框架提供了测试领域的可复用解决方案，使得测试人员可以专注于业务领域。xUnit家族、开源框架和商业产品都是很好的选择。如果没有适合当前项目的框架，也可以自己开发一个。例如，我使用IronPython作为测试开发语言。我没有使用Python标准库，因为它依赖于一些CPython的 module（需要部署CPython），而我只想要一个纯.NET的解决方案（只需要部署.NET framework）。我也没有使用NUnit或MSTest，因为它们要求编译出测试程序集，而我则希望没有“编译”过程。于是，我开发了 IpyUnit，用于自己的测试，效果颇佳：既利用了.NET framework的强大能力，也发挥了Python语言灵活快速的优点。这里的诀窍是，只开发当前需要的功能，不追求其他框架提供的高级功能。

　　2. 收集并理解规格说明。大多数项目没有规格说明，即便有也已经过期。测试者需要收集任何显式和隐式的规格说明[Cem01]，例如需求文档、会议纪要、相关产品、同一产品的老版本、邮件、wiki、聊天中的只言片语、实现代码等。在处理这些信息的过程中，会产生许多疑惑。这时，可以与同事交流，厘清头绪；也可以开发测试，让代码来提供答案。理解规格说明的目的是了解业务需求和技术实现，从而找出重要的功能和高风险的区域，为进一步的测试指明方向和策略。

　　3. 开发基本测试用例。基本测试用例用于检查系统的主要功能和常见场景。它们应该包括正面用例和负面用例，同时从快乐路径(happy path)和异常路径(exception path)来检查被测试软件。基本用例是最基本的“可执行规范”，定义了软件的基本行为。回归测试应该总是包括基本用例，以提供基本的安全网。

　　4. 阅读被测试软件的源代码。阅读源代码的主要目的有二。第一、找出高风险的模块。在大多数项目中，测试者的时间总是非常紧张的。通过阅读源代码，可以快速识别出低风险的模块，降低它们的测试优先级；同时发现高风险的、复杂的模块，针对它们的特点构思测试策略。这有助于制定出事倍功半的测试计划。第二、找出潜在的程序缺陷。静态分析是一种高效的错误检查手段，其中污染传播(taint propagation)分析尤其有效[Brian07]。所谓污染传播是指，程序的输入数据未经过检验（或未经过完备的检验），一直传播到持久性存储（如文件、数据库）或重要的操作（如将数据发送给用户）。测试者的任务就是构造输入数据，使得污染传播造成危害。阅读源代码是构造此类测试用例的捷径。

　　5. 困惑是一种测试工具[Cem01]。软件开发从来都不缺乏困惑：阅读规格说明，会觉得莫名其妙；阅读源代码，会觉得匪夷所思；阅读测试结果，会觉得不可思议；阅读错误报告，会觉得不知所云。困惑是指南针，它指出了在规格说明、用户文档、实现、测试中的缺陷。我承认我有时候会忽略我的困惑，转移到其他工作项上。但是，我还是在不断地提醒自己：不要放过任何一个困惑。对于代码和测试上的困惑，我的作法是用一个测试用例来复现令我疑惑的现象，然后用调试器和源代码来调查。这样做可以使“可执行规范”覆盖更多行为，避免测试遗漏。