演进并非革命——小谈自动化测试

　　“有足够的时间把每个案例都测试完整吗？”

　　“没有！” 我想，人们会异口同声地回答。

　　总有很多用例需要测试，或者需要在另一个平台或以其他配置再试一次。但是随着最终期限和产品交付日期的日益迫近，分配给每个测试周期的时间缩短了。那么，测试团队如何实现低成本高效率的测试呢？

　　有合理的机制防止测试设计时场景遗漏，力求正式版本Release之前找出瓶颈；引入合适的自动化测试工具，充分利用无人值守的夜间和假日；自主开发针对性强的测试框架。以上都是为了尽可能地减少项目维护阶段的投入，而采取的行之有效的测试策略。其中，自动化测试毫无疑问地在测试效率和彻底性方面使我们获益匪浅，帮助团队实现降本增效的目的。

　　对于“什么是自动化测试” ，人们往往理解得过于狭窄，只关心由工具或编程产生的测试脚本，但实际上自动化一词包含了更为广阔的含义。一个Quality Engineering团队在构建一套自动化测试准则时，对自动化测试是这样定义的：在我们的环境中，“自动化”指的是对策略、工具和工件的使用，它增加或减少了手工或人为参与或干预非技巧性、重复或冗长工作的需要。

　　自动化测试，或者说自动化测试策略及工具的实现，是测试人员工具箱里的一件利器。测试工作自动执行并记录测试结果，可以把测试人员从枯燥的重复性工作中解脱出来，将更多精力和时间专注于需要智能判断的复杂工作和其他新的测试用例。这样，不但可以有效提高测试效率、缩短测试特别是回归测试所需时间，还可以在晚上、周末等测试人员不在场的情况下充分利用测试服务器资源、提高测试覆盖率。尽管如此，我们要避免将自动化测试和测试人员等同起来，不要对自动化测试要求过高。我们要对自动化测试树立一个正确的观感，清醒地认识到自动化测试是人工测试的有力补充，而无法取代测试人员的地位。

　　没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。Frederick P. Brooks, Jr. 鼓励我们将技术和方法视作一种演进手段，而并非革命。将自动化技术引入测试工作时，我们倾向于支持相同的观点。“罗马城不是一天建成的。”自动化测试也是一个积累经验、循序渐进的过程，不要期望在短期内实现所有测试的自动化。成功的自动化测试需要制定相应的自动化测试计划，好的自动化测试策略是自动化测试实施是否成功的第一步。只有充分考虑到自身实施自动化测试的风险、资源和目标后，才能制定出适合自己的自动化测试策略，并最终达到提高测试效率，降低测试成本的目的。

专题入口：http://www.51testing.com/zhuanti/zdh/zdh.html

（一）软件自动化测试技术选择：驶入测试“快车道”

 　　软件测试，特别是测试自动化技术属于当前国际软件界最有争议，亟待发展的技术。所谓自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量,从而达到提高软件质量的目的。

　　测试工具

　　在进行测试活动时，采用合适的测试方法和相对应的自动化测试工具是至关重要的。

　　1．静态分析工具

　　静态分析工具的特点是一种直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件，从中寻找可能导致错误的异常情况的测试工具。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。

　　● 静态确认工具

　　对源程序进行静态分析和确认，从而发现某些常见的错误。这样的测试工具还能进行不可靠结构的检查，识别出可疑的易出错的结构，并进行危险变量的监视。

　　● 符号执行工具

　　以符号值作为程序的输入，使程序符号执行。系统可以“穷尽”测试符号的选择，以便能自动或者交互地检查符号执行树的每条路径，并自动对输出结果与输出断言进行比较，一般说来，这样的符号执行系统都具有交互式纠错功能，包括跟踪断点设置、状态存储等。

　　● 程序验证工具

　　交互式程序验证系统，是程序正确性证明的一个工具。输入源程序和程序断言；输出是对程序正确性的一个判断，即程序执行结果是否必定满足断言的要求。系统可自动产生程序中的断言，系统的内部实现基于符号逻辑变换和结构归纳。

　　2．动态分析工具

　　动态分析工具的主要功能是分析被测程序逻辑中每个语句的执行次数。动态分析工具与静态分析工具不同，动态分析工具一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据，其与静态分析工具最大的不同就是动态分析工具要求被测系统实际运行。

　　● 覆盖监视工具

　　这样的工具系统可在程序逻辑的适当位置安插一些“探测器”，以便对程序进行监视，产生带统计数字的报告。使用该工具可以测试出没有执行的语句，以便增加相应的测试数据。

　　● 驱动工具

　　采用自底向上渐增方式测试时需要编写许多虚构的驱动模块。驱动工具可以免除人们编写驱动模块的负担。它提供一种测试语言来写测试过程，表明要测试的模块、使用的测试用例、预期的输出等。这样不再需要人工编写任何驱动程序，系统能自动把输入数据传送给被测模块，并负责将实际输出结果与预期的结果相比较。

　　● 测试数据产生工具

　　这是帮助自动选择测试用例的工具。这样的系统利用一个存放程序各种“素材”的共用信息库，使测试人员能用命令方便地定义测试用例，并在适当的时候自动运行这些测试用例。而当被测程序修改后系统能自动个性测试用例，以保持这些测试用例的可用性。此种工具对于测试系统在实际环境中的性能以及测试一个数据库的管理系统时比较方便。

　　● 符号查错工具

　　此工具提供屏幕显示功能，显示程序的动态执行情况，或者在程序执行中断时，显示程序执行的当前状态的历史信息，以便进行检查和修改。这样的查错系统，实际上为程序提供了一个执行的环境，能够跟踪监视和控制程序的执行。系统界面以查错命令方式交互工作，系统实现依赖于程序执行的历史记录。

　　3．综合测试评估工具

　　把静态分析、动态分析、测试评估等综合在一起，测试人员可以用命令来控制系统执行不同的测试工具，各工具模块之间的通信通过数据库来实现。一个可行的简单办法是建立一组测试工具，或者叫做测试工具库。这些工具可能都是相互独立设计的，彼此间没有什么联系，但都能从某一侧面对程序进行测试，任由用户选择使用。

　　测试脚本

　　在测试过程中，测试脚本起着关键的作用。每种脚本技术在支持脚本完成测试事例的时间和开销上都有各自的长处和短处。对于软件测试来说，使用哪种脚本技术并不是最主要的，脚本所支持的实现测试事例体系的整体考虑才是最主要的。

　　1．线性脚本技术

　　线性脚本是录制手工执行的测试事例得到的脚本。这种脚本包括所有的击键、功能键、箭头控制测试软件的控制键及输入数据的数字键。如果用户只使用线性脚本技术，即录制每个测试事例的全部内容，则每个测试事例可以通过脚本完整地被回放。几乎任何可重复的操作都可以使用线性脚本技术实现自动化。

　　2．结构化脚本技术

　　结构化脚本类似于结构化程序设计，结构化脚本中含有控制脚本执行的指令，这些指令或为控制结构或为调用结构。所有测试工具脚本语言支持三种基本控制结构。第一种形式为“顺序”脚本（即前面介绍的线性脚本）。另外两种控制结构形式的脚本为“选择”或“叠代”。选择控制结构使脚本具有判断功能，最普通的形式是“if”语句判断条件为真或为假; 叠代控制结构可以根据需要重复一个或多个指令序列，有时也将这种结构称为“循环”。

　　除控制结构外，一个脚本可以调用另一个脚本，即将一个脚本的控制点转到另一个子脚本的开始，执行完子脚本后再将控制点返回到第一个脚本。这种机制可以将较大的脚本分为几个较小的易于管理的脚本。

　　结构化脚本技术的主要优点是健壮性更好；可以执行许多其他类似的功能，如需要重复的指令可以使用循环结构;还可以作为模块被其他脚本调用。其缺点是使用脚本变得更加复杂，而且测试数据仍然“捆绑”在脚本中。

　　3．共享脚本技术

　　共享脚本是指脚本被多个测试事例使用。这种技术的思路是产生一个执行某种任务的脚本，而不同的测试要重复这个任务，当要执行这个任务时只需在每个测试事例的适当地方调用这个脚本。这样将带来两个好处: 第一，可以节省生成脚本（编写或录制指定的操作）的时间。

下一页