3.2静态分析工具
一提到软件测试，人们的第一印象就是填入数据、点击按钮等这些功能操作。这些测试工作确实是重要的，但它们不是软件测试的全部。与这种动态运行程序的测试相对应，还有一种测试被称为静态测试，也叫做静态分析。
进行静态分析时，不需要运行所测试的程序，而是通过检查程序代码，对程序的数据流和控制流信息进行分析，找出系统的缺陷，得出测试报告。
进行静态分析能切实提高软件的质量，但由于需要分析人员阅读程序代码，使得这项工作进行起来工作量又很大。对软件进行静态分析的测试工具在这种需求下也就产生了。现在的静态分析工具一般提供以下两个功能：分析软件的复杂性、检查代码的规范性。
软件质量标准化组织制定了一个ISO/IEC9126质量模型，用来量化的衡量一个软件产品的质量。该软件质量模型是一个分层结构，包括质量因素、质量标准、质量度量元三层。质量度量元处于质量模型分层结构中的最底层，它直接面向程序的代码，记录的是程序代码的特征信息，比如函数中包含的语句数量、代码中注释的数量。质量标准是一个概括性的信息，它比质量度量元高一级，一个质量标准由若干个质量度量元组成的。质量因素由所有的质量标准共同组成，处于软件质量模型的最高层，是对软件产品的一个总体评价。具有分析软件复杂性功能的静态分析工具，除了在其内部包含上述的质量模型外，通常还会从其它的质量方法学中吸收一些元素，比如Halstend质量方法学、McCabe质量方法学。这些静态分析工具允许用户调整质量模型中的一些数值，以更加符合实际情况的要求。
在用这类工具对软件产品进行分析时，以软件的代码文件作为输入，静态分析工具对代码进行分析，然后与用户定制的质量模型进行比较，根据实际情况与模型之间的差距，得出对软件产品的质量评价。
下图是一个商业静态分析工具得出的软件质量与质量模型之间的比较结果。
图3-1静态分析工具得出的软件质量与质量模型之间的比较结果
下图是一个商业的静态分析工具得出的程序中某一个函数的流程图。
图3-2静态分析工具得出的程序中某函数的流程图
具有检查代码规范性功能的静态分析工具，其内部包含了得到公认的编码规范，比如函数、变量、对象的命名规范，函数语句数的限制等等，工具支持对这些规范的设置。工具的使用者根据情况，裁减出适合自己的编码规范，然后通过工具对代码进行分析，定位代码中违反编码规范的地方。
以上就是静态分析工具所具有的功能。与人工进行静态分析的方式相比，通过使用静态分析工具，一方面能提高静态分析工作的效率，另一方面也能保证分析的全面性。
3.3单元测试工具
单元测试是软件测试过程中一个重要的测试阶段。与集成测试、确认测试相比，在编码完成后对程序进行有效的单元测试，能更直接、更有效的改善代码质量。
进行单元测试不是一件轻松的事。一般来讲，进行一个完整的单元测试所需的时间，与编码阶段所花费的时间相当。进行单元测试时，根据被测单元（可能是一个函数，或是一个类）的规格说明，设计测试用例，然后通过执行测试用例，验证被测单元的功能是否正常实现。除此之外，在单元测试阶段，我们还需要找出那些短时间不会马上表现出来的问题（比如C++代码中的内存泄露），还需要查找代码中的性能瓶颈，并且为了验证单元测试的全面性，我们还想了解单元测试结束后，我们的测试所达到的覆盖率。
针对这些在单元测试阶段需要做的工作，各种用于单元测试的工具就产生了。典型的单元测试工具有以下几类：动态错误检测工具、性能分析工具、覆盖率统计工具。
动态错误检测工具，用来检查代码中类似于内存泄露、数组访问越界这样的程序错误。程序功能上的错误比较容易发现，因为它们很容易表现出来。但类似于内存泄露这样的问题，因为在程序短时间运行时不会表现出来，所以不易发现。遗留有这样问题的单元被集成到系统后，会使系统表现的极不稳定。
性能分析工具，记录被测程序的执行时间。小到一行代码、一个函数的运行时间，大到一个exe或dll文件的运行时间，性能分析工具都能清晰的记录下来。通过分析这些数据，能够帮助我们定位代码中的性能瓶颈。
覆盖率统计工具，统计出我们当前执行的测试用例对代码的覆盖率。覆盖率统计工具提供的信息，可以帮助我们根据代码的覆盖情况，进一步完善测试用例，使所有的代码都被测试到，保证单元测试的全面性。
动态错误检测工具、性能分析工具、覆盖率统计工具的运行机理是：用测试工具对被测程序进行编译、连接，生成可执行程序。在这个过程中，工具会向被测代码中插入检测代码。然后运行生成的可执行程序，执行测试用例，在程序运行的过程中，工具会在后台通过插入被测程序的检测代码收集程序中的动态错误、代码执行时间、覆盖率信息。在退出程序后，工具将收集到的各种数据显示出来，供我们分析。
目前被普遍使用的单元测试工具中有Compuware公司的NuMega DevPartner Studio，Rational公司的Rational Suite Enterprise。这些软件产品都是一个工具套件，其中包含了我们前面所讨论的动态错误检测工具、性能分析工具、覆盖率统计工具等。
3.4功能测试工具
在软件产品的各个测试阶段，通过测试发现了问题，开发人员就要对问题进行修正，修正后的软件版本需要再次进行测试，以验证问题是否得到解决，是否引发了新的问题，这个再次进行测试的过程，称为回归测试。
由于软件本身的特殊性，每次回归测试都要对软件进行全面的测试，以防止由于修改缺陷而引发新的缺陷。进行过回归测试人都会深有体会，回归测试的工作量是很大的，而且也很乏味，因为要将上一轮执行过的测试原封不动的再执行一遍。设想一下，如果能有一个机器人，就象播放录影带一样，忠实的将上一轮执行过的测试原封不动的在软件新版本上重新执行一遍，那就太好了。这样做，一方面，能保证回归测试的完整、全面性，测试人员也能有更多的时间来设计新的测试用例，从而提高测试质量；另一方面，能缩短回归测试所需要的时间，缩短软件产品的面市时间。功能测试自动化工具就是一个能完成这项任务的软件测试工具。
功能测试自动化工具理论上可以应用在各个测试阶段，但大多数情况下是在确认测试阶段中使用。功能测试自动化工具的测试对象是那些拥有图形用户界面的应用程序。
一个成熟的功能测试自动化工具要包括以下几个基本功能：录制和回放、检验、可编程。
录制，就是记录下对软件的操作过程，回放，就是象播放电影一样重放录制的操作。启动功能测试自动化工具，打开录制功能，依照测试用例中的描述一步一步的操作被测软件，功能测试自动化工具会以脚本语言的形式记录下你操作的全过程。依照此方法，可以将所有的测试用例进行录制。在需要重新执行测试用例时，回放录制的脚本，功能测试自动化工具依照脚本中的内容，操作被测软件。除了速度非常快之外，通过功能测试自动化工具执行测试用例与人工执行测试用例的效果是完全一样的。
录制只是实现了测试输入的自动化。一个完整的测试用例，由输入和预期输出共同组成。所以，光是录制回放还不是真正的功能测试自动化。测试自动化工具中有一个检验功能，通过检验功能，在测试脚本中设置检验点，使得功能测试自动化工具能够对操作结果的正确性进行检验，这样，就实现了完整的测试用例执行自动化。软件界面上的一切界面元素，都可以作为检验点来对其进行检验，比如文本、图片、各类控件的状态等。
脚本录制好了，也加入了检验点，一个完整的测试用例已经被自动化了。但我们还想对脚本的执行过程进行更多的控制，比如依据执行情况进行判断，从而执行不同的路径，或者是对某一段脚本重复执行多次。通过对录制的脚本进行编程，可以实现上述的要求。现在的主流功能测试自动化工具都支持对脚本的编程。象传统的程序语言一样，在功能测试自动化工具录制的脚本中，可加入分支，循环，函数调用这样的控制语句。通过对脚本进行编程，能够使脚本更加灵活，功能更加强大，脚本的组织更富有逻辑性。在传统的编程语言中适用的那些编程思想，在组织测试自动化脚本时同样适用。
