Smart Testing

在Windows平台上，做了两年的软件测试，小有收获。用这篇日志小结一下通用的测试工具。

Notepad2
测试者需要一种可以在任何机器上立即部署、立即应用的编辑器，Notepad2就是一个很好的选择。它是一个小巧的编辑器，用不到1M的大小提供了丰富的功能。在查看方面，它可以语法高亮多种程序文件，可以显示空格、回车、换行等特殊字符（这对测试者了解文件内容的细节很有帮助），可以轻松的放大或缩小字体。在编辑方面，它提供了基本的缩进、注释、字符集转换等功能。目前，我使用它完成80%的程序开发任务。

Notepad++
有时，测试者或他的工作伙伴也需要多标签的、功能更加丰富的源代码编辑器。开源的Notepad++是一个不错的选择。它的二进制格式查看和编辑能力，是Notepad2所不具备的。

WinMerge
在测试过程中，测试者往往需要比较不同版本的源代码，比较两个文件或目录的内容。WinMerge是开源的比较和合并工具，界面友好、功能实用。

IronPython/Python
Python是一门成熟的动态语言，特别适合测试自动化工作。IronPython是基于.NET平台的Python语言实现，特别适合.NET程序的测试。例如，IronPython可以绑定到.NET对象的私有成员，可以直接测试对象的实现细节。更重要的是，IronPython提供了快速测试、快速反馈的便利性，符合软件测试的语境驱动方法的理念。目前，我使用IronPython完成80％的测试开发任务。

Windows PowerShell
Windows PowerShell是Windows Server 2008以及后续Windows平台的内建组件。越来越多的Windows Service（如SQL Server、IIS、Visual Studio Team Fundation Server、Hyper-V等）已经或即将支持PowerShell。作为测试自动化工具，PowerShell是测试工具箱中不可或缺的一员。

SQL Server
测试工作者需要管理测试数据、检查测试输出、汇报测试结果，这都需要数据管理、操纵、计算工具。如果数据规模大、保持时间长、需要供多种系统使用，那么数据库就是值得仔细考虑的测试工具。SQL Server不但提供了强大的存储引擎、便利的管理工具，还可以与Visual Studio、ASP.NET等系统平滑集成，有利于测试开发和维护。一般情况下，免费的SQL Server Express可以满足大多数测试工作的需要。

Microsoft Office
测试人员最重要的能力是思考和交流；Microsoft Office Suite可以帮助测试者更好的思考和交流。

• Word可以编辑测试文档、工作日志（Word 2007可以发布Blog）、Fit测试表格。它的批注功能便于团队成员之间的交流。
• PowerPoint不但是制作测试报告的利器，也是测试大纲、会议纪要的记录工具。
• Excel可以用于测试结果分析、测试图表生成。它还可以用ODBC连接数据库或其他的数据源，是方便的数据呈现和操纵工具。
• OneNote可以记录工作笔记、测试灵感、待办事项等多种信息，可以解放测试者的大脑。
• Outlook和Exchange是大型企业工作流的一部分，是每日必用的交流工具。当然，面对面的交流是远胜于邮件的协作方式。
• SharePoint提供了团队合作的基础，其Wiki功能对于分享团队知识非常方便。

Windbg
面对测试环境中的异常，测试工作者往往有两个选择：第一、用Windbg附着(attach)到目标进程进行调试；第二、用Windbg或其他工具（自动）生成内存映像文件(memory dump file)，然后用Windbg分析该文件。作为Windows平台上优秀的调试工具，Windbg是解决疑难杂症的好帮手。

Reflector
利用Reflector，可以方便地了解.NET程序集(Assembly)的实现细节，对于制定测试策略、编写测试用例很有帮助。它还支持多种插件，可以生成源代码文件、比较程序集异同、进行代码搜索，是.NET平台上必不可少的测试工具。

EPSnap
一图胜过千言万语，测试报告往往也需要图片来进一步说明。EPSnap是一个免费的绿色截屏工具，它可以自定义快捷键、抓取多种类型的区域、保持多种格式的图片。目前，我使用它完成所有的截图工作。

Windows Sysinternals
Sysinternals提供了一组好用的工具用于管理、诊断、检查Windows系统和应用程序。目前，我使用的最多的工具是进程管理工具Process Explorer和桌面制作工具BigInfo。

Perfmon
Windows内建组件Perfmon可以监控并记录Windows系统和应用程序的性能参数，是性能测试和故障诊断的好工具。

Event Log
Windows内建组件Event Log可以记录Windows系统和应用程序的重要事件，是故障诊断的好工具。

Schedule Tasks
Windows内建组件Schedule Tasks可以定时启动指定的程序。目前，我使用它完成数据备份、启动每日测试(daily test)和循环测试(rolling test)、自动部署被测试系统等多项任务。

Visual Studio
Visual Studio是Windows和.NET平台上最强大的开发工具，也是测试人员开发测试程序、调试产品代码的利器。配合Team Foundation Server (TFS)，可以建立代码管理、缺陷管理、工作项管理、开发报告的集成环境，是团队协作的基础设施。目前，我所有的测试代码都签入(check-in)到TFS中。

持续集成是敏捷软件开发的核心实践。在我的项目中，我实践了一种与持续集成类似的测试活动：

Rolling Testing：每个小时，从源代码管理系统中获得当前版本，进行完整的构建（build）。在一台干净（clean）的机器上，部署新构建的系统，执行端到端（end to end)的系统测试。最后，用电子邮件将测试结果发送给开发团队。整个过程是无人值守的。

按照《持续集成》的定义，Rolling Testing不是严格意义上的“持续集成”（Continuous Integration）。不过，它所发挥的作用与持续集成非常接近。

Why

1. Rolling Testing可以尽快地发现集成错误。开发者在自己的开发环境中工作，他所看到的系统是他最后一次检出（check-out）的结果。他根据这一版本的“知识”来开发新的功能。虽然两个开发者的都基于相同的“知识”来进行开发，但是不能保证他们所构造的新“理论”是相互一致的。往往，两部分的代码都通过了单元测试，但是检入（check-in）之后却引发了集成错误。Rolling Testing用端到端的系统测试弥补了单元测试的不足，能够提供快速的系统级的测试反馈。
2. Rolling Testing可以节省大量的开发时间。集成错误往往会阻碍全面的系统测试。例如，模块A不能正确解释模块B的输出，它抛出异常并停止工作。这时，系统测试将无法覆盖模块A及其后续模块的代码。这将严重影响测试效率，甚至使得每日运行的全面回归测试变得毫无效果。Rolling Testing可以在检入之后的一个多小时内捕获到此类严重的错误，那么开发者就可以在第一时间修正错误，清除测试障碍（题外话：清除障碍并给予人们完成工作所需要的东西，是Scrum方法论的核心）。有时开发者的修正会引入的新的集成错误，Rolling Testing的安全网会再次捕捉到它，于是我们有机会保证：在下班回家的时候，没有明显的集成错误。
3. Rolling Testing可以发现环境错误。所有的开发者都应该听从John Robbins的忠告：不要在开发机上使用Administrator权限。不过久经世故的Cem Kaner也说过：本书介绍的测试，假定的前提是你的同伴现在没有、将来也不会并且也没有必要遵循这些规定。由于开发者在开发机上拥有Administrator权限，他们安装了各式各样的工具和运行库，我们无法保证所开发出的系统能够在其他环境中以合适的权限正常工作。Rolling Testing在干净的机器上部署被测试系统，能够发现许多在开发环境中无法发现的错误。所谓干净的机器，并不要求重新安装操作系统，只是要求完整地卸载了旧版本的系统。
4. Rolling Testing保证了被测试版本的基本质量，使测试团队更有信心进行大规模的功能测试和压力测试。

How

1. 基本方法是利用Windows Schedule在每个整点触发流程，从源代码管理系统中获得完整的最新版本，然后利用构建工具执行完整的构建。如果构建失败，则无需继续：构建失败（build break）要求更紧急的修复。如果构建成功，在一台干净的机器上部署整个系统。然后，调用测试工具或测试框架执行系统测试。最后，汇总测试结果，生成测试报告，并用邮件发送给负责Rolling Testing的测试和开发人员。
2. 自动化是Rolling Testing的关键。从以上流程可以看出，Rolling Testing所使用的工具无非是：操作系统自带的服务、源代码管理工具、构建工具、自动化测试框架、内部邮件系统，这些都是开发团队的常备工具（如果没有源代码管理和构建工具，那么立即部署合适的工具是开发人员的第一要务）。因此，用合适的方法将工具连接起来，构建出完整的流程，是架设Rolling Testing的主要任务。在Windows平台上，DOS Shell是最常用的脚本技术，可以满足大部分的要求。此外，PowerShell和IronPython能够直接利用.NET framework的强大功能，往往能事半功倍。
3. Rolling Testing要能够在30分钟内完成（在我的项目中，Rolling Testing大约持续25分钟）。如果Rolling Testing发现了错误，开发人员需要在Rolling Testing环境中调查故障原因。为了不影响下一次的Rolling Testing，一般要留下30分钟的时间给开发人员进行诊断。

Tips

1. 要部署完整的系统。对于一些分布式系统而言，将所有的子系统部署在一台机器上有些“不合情理”。但是，部署所有的子系统可以测试到所有的子系统的部署功能，也能够检查出由于子系统冲突造成的部署失败。部署是任何系统的核心功能，是Rolling Testing必不可少的测试内容。此外，在部署最新版本之前，Rolling Testing会反安装旧版本的系统。这也测试了系统的反安装功能。
2. 测试用例集包含最重要的端到端系统测试。Rolling Testing的主要目的是发现集成错误，因此测试执行应该能够“从输入到输出”覆盖到所有的子系统。考虑到用户价值，测试用例应该能够体现最重要的用户情景（main user scenario)。由于Rolling Testing的时间有限，测试用例应该“贵精不贵多”，用较少的用户情景覆盖所有的子系统。
3. 测试应该覆盖所有的子系统。有些子系统难以用常见的用户情景来覆盖，这时可以构建独立的测试来检验它不存在严重的错误。Rolling Testing的目的不是检查出所有的错误，而是发现那些会阻碍进一步测试的错误（blocking bug)。因此，不需要构建完备、严厉的测试用例集，只需要验证子系统的基本功能可以工作即可。
4. 确保所有的测试用例是正确的。有时系统的设计会发生变更，这会导致部分测试用例需要更新。更新测试的工作有可能需要几个工作日才能完成。这时，应该将这些测试用例从Rolling Testing中排出出去。否则，当Rolling Testing报告测试执行失败时，测试人员不能立即判断是被测试系统的问题还是测试的问题，这将严重降低Rolling Testing的报警作用。特别是，如果测试人员“默认”测试失败是测试本身的问题，那么他有可能会漏过严重的集成错误。
5. 及时地维护Rolling Testing测试用例集。系统会增加新的子系统、用户情景会发生变化、测试工具也需要更新，这都要求Rolling Testing的负责人及时地维护Rolling Testing的测试用例集，以确保：测试用例集可以覆盖到所有的子系统，且不包含错误的测试用例。
6. 及时地响应测试报告。Rolling Testing的威力在于根据测试结果采取及时的行动。如果对于每小时一次的错误报告采取漠视的态度，那么之前所花费的精力将毫无价值。我的做法是利用Outlook的邮件规则，对测试报告邮件生成一个通知（alert）。当测试报告到达时，Outlook会弹出一个对话框，我只需要按一下“回车（Enter）”，就可以看到报告内容。如果有问题，则进行调查；如果没有问题，按两下”取消（Esc）”就可以关闭邮件、关闭对话框。此外，我还设置了另一条邮件规则，将所有的测试报告归档到一个单独的文件夹中。