软件测试及常用的策略和方法

一.黑盒测试与白盒测试

1.黑盒测试：black-box testing：只关心软件的输入数据和输出结果。包括功能测试与性能测试。

2.白盒测试：white-box testing:研究源代码与程序结构

二.静态测试和动态测试

1.静态测试：不实际运行被测软件，只静态地检查程序代码，界面或文档中可能存在的错误的过程。

包括：代码测试（测试标准和规范），界面测试（实际界面与需求中的说明是否相符），文档测试（用户手册与需求说明是否真正符合用户的实际要求）

2.动态测试：实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符过程

三.单元测试，集成测试，系统测试和验收测试

1.单元测试：对软件中的最小可测试单元进行检查和验证。

A.单元测试需要在项目前期进行，在程序员编码之后，代码已经通过编译后进行；

B.由白盒测试员或者开发人员来测试，开发人员需要交叉测试，避免测试自己的代码

C.测试的依据是：源程序本身，包括代码和注释；还项目的《详细设计》文档

D.通过的标准：程序通过所有单元测试的用例。语句的覆盖率达到百分百；分支的覆盖率达到85%

E.需要检查代码是否符合规范，动态运行代码，检查其实际运行结果。 F.桩模块和驱动模块

桩模块：STUB指模拟被测模块所调用的模块

驱动模块：DRIVER指模拟被测模块的上级模块，用来接收测试数据，启动被测模块并输出结果

2.集成测试

A.integration testing:将通过测试的单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分

B.单元与集成同步进行。测试参数传递。 C.由开发人员或者白盒测试员测试

D.依据是单元测试的模块以及《概要设计》文档 3.系统测试与验收测试

A.系统测试：system testing将整个软件系统看做一个整体进行测试，包括对功能，性能以及软件所运行的软硬件环境进行测试

系统测试由黑盒测试员来完成，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及在不同的软硬件环境中的兼容性;主要依据是《系统需求规格说明》文档

B.验收测试

α测试：由用户，测试人员，开发人员共同参与的内部测试 β测试：内测后的公测，完全交给最终用户的测试 4.功能测试与性能测试

A.功能测试：function testing检查实际软件的功能是否符合用户的需求

逻辑功能测试(logic function testing):计算器

界面测试(ui testing)：窗口，下拉式菜单和鼠标操作，数据项 易用性测试（usability testing):合理性与方便性进行测试 安装测试（installation testing):安装与缷载

兼容性测试（compatibility testing)：包括硬件兼容性测试与软件兼容性测试。

5.性能测试（performance testing)

A.软件性能主要有时间性能与空间性能两种。一般需要用到自动化的测试工具。

B.软件测试分为：一般性能测试，稳定性测试（reliability testing)，

负载测试(load testing)和压力测试(stress testing） 6.回归测试，冒烟测试，随机测试

A.regression testing:对软件的新的版本测试时，重复执行上一个版本测试时的用例

B.smock testing:在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

C.random testing:在测试中所有的输入数据都是随机生成的，目的是模拟用户的真实操作，并发现一些边缘性的错误。也叫猴子测试。

功能测试常用的策略和方法

黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。 黑盒测试试图发现以下类型的错误： 1）功能错误或遗漏； 2）界面错误；

3）数据结构或外部数据库访问错误； 4）性能错误；

5）初始化和终止错误。

一、黑盒测试的测试用例设计方法 · 等价类划分方法 · 边界值分析方法

· 错误推测方法 · 因果图方法

· 判定表驱动分析方法 · 正交实验设计方法 · 功能图分析方法 等价类划分：

是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。

1） 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类：与有效等价类的定义恰巧相反。

设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。 2）划分等价类的方法：下面给出六条确定等价类的原则。

① 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

② 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

③ 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

④ 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

⑤ 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

⑥ 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

3）设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：

输入条件 有效等价类 无效等价类

然后从划分出的等价类中按以下三个原则设计测试用例： ① 为每一个等价类规定一个唯一的编号。

② 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。

③ 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。直到所有的无效等价类都被覆盖为止。 边界值分析法

边界值分析方法是对等价类划分方法的补充。 （1）边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

（2）基于边界值分析方法选择测试用例的原则：

1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。

3）根据规格说明的每个输出条件，使用前面的原则1）。 4）根据规格说明的每个输出条件，应用前面的原则2）。

5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

7）分析规格说明，找出其它可能的边界条件。 错误推测法

错误推测法： 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如， 在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等， 这些就是经验的总结。还有， 输入数据和输出数据为0的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。 可选择这些情况下的例子作为测试用例。 因果图方法

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。 考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。

因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

利用因果图生成测试用例的基本步骤：

（1） 分析软件规格说明描述中， 那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

（2） 分析软件规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系。 根据这些关系，画出因果图。

（3） 由于语法或环境， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。 为表明这些特殊情况，在因果图上用一些记号表明约束或条件。

（4） 把因果图转换为判定表。

（5） 把判定表的每一列拿出来作为依据，设计测试用例。

从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。

前面因果图方法中已经用到了判定表。判定表（DECision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。 判定表驱动分析方法

判定表通常由四个部分组成。

条件桩（ConDItion STub）：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。

动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。 规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。 判定表的建立步骤：（根据软件规格说明）

① 确定规则的个数。假如有n个条件。每个条件有两个取值（0，1），故有种规则。

② 列出所有的条件桩和动作桩。 ③ 填入条件项。

④ 填入动作项。等到初始判定表。 ⑤ 简化、合并相似规则（相同动作）。

B.Beizer 指出了适合使用判定表设计测试用例的条件： ① 规格说明以判定表形式给出，或很容易转换成判定表。 ② 条件的排列顺序不会也不影响执行哪些操作。 ③ 规则的排列顺序不会也不影响执行哪些操作。

④ 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

⑤ 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。 黑盒测试的优点

1、基本上不用人管着，如果程序停止运行了一般就是被测试程序CRASh了 2、设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点

1、结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴

2、没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

3、就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的tEStcase造成的问题。这些在堆的问题中表现的更为突出。

黑盒测试（功能测试）工具的选择

那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。

WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

WinRunner的特点在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试； 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差；此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成；它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用；它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

WinRunner的工作流程大致可以分为以下六个步骤： 1．识别应用程序的GUI

在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式： Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。 2．建立测试脚本

在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL（与C语言类似的测试脚本语言）。录制脚本有两种模式： Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。

只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

3．对测试脚本除错（debug）

在WinRunner中有专门一个Debug TOOlbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。 4．在新版应用程序执行测试脚本

当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

5．分析测试结果

分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。 6．回报缺陷（defect）

在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。 常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

1、页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

2、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

3、检查按钮的功能是否正确：如update， cancel， delete， SAve等功能是否正确。

4、字符串长度检查： 输入超出需求所说明的字符串长度的内容， 看系统是否检查字符串长度，会不会出错。

5、字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错。

6、标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。

7、中文字符处理： 在可以输入中文的系统输入中文，看会否出现乱码或出错。

8、检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出。，带出信息和添加的是否一致

9、信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。

10、检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理。

11、检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。

12、检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。

13、重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

14、检查多次使用back键的情况： 在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。

15、search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。

16、输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。

17、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

18、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

19、快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了。 20、回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。

再谈黑盒测试和白盒测试

黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。 黑盒测试试图发现以下类型的错误：

1）功能错误或遗漏； 2）界面错误；

3）数据结构或外部数据库访问错误； 4）性能错误；

5）初始化和终止错误。

一、黑盒测试的测试用例设计方法

·等价类划分方法 ·边界值分析方法 ·错误推测方法 ·因果图方法

·判定表驱动分析方法 ·正交实验设计方法 ·功能图分析方法

等价类划分:

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后

从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

无效等价类:与有效等价类的定义恰巧相反.

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2）划分等价类的方法:下面给出六条确定等价类的原则.

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

输入条件 有效等价类 无效等价类 ... ... ...

... ... ...

然后从划分出的等价类中按以下三个原则设计测试用例: ①为每一个等价类规定一个唯一的编号.

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

边界值分析方法是对等价类划分方法的补充.

（1）边界值分析方法的考虑:

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

（2）基于边界值分析方法选择测试用例的原则:

1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

3）根据规格说明的每个输出条件,使用前面的原则1）. 4）根据规格说明的每个输出条件,应用前面的原则2）.

5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

7）分析规格说明,找出其它可能的边界条件.

错误推测法

错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而

有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但

未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

利用因果图生成测试用例的基本步骤:

(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符. (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

(3) 由于语法或环境, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或条件.

(4) 把因果图转换为判定表.

(5) 把判定表的每一列拿出来作为依据,设计测试用例.

从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确. 判定表通常由四个部分组成.

条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.

动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列. 判定表的建立步骤:（根据软件规格说明）

①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则.

②列出所有的条件桩和动作桩. ③填入条件项.

④填入动作项.等到初始判定表. ⑤简化.合并相似规则（相同动作）.

B. Beizer 指出了适合使用判定表设计测试用例的条件: ①规格说明以判定表形式给出,或很容易转换成判定表. ②条件的排列顺序不会也不影响执行哪些操作. ③规则的排列顺序不会也不影响执行哪些操作.

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

黑盒测试的优点

1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash

了

2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点

1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG

的东西很值得借鉴

2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。

黑盒测试（功能测试）工具的选择

那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一

支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。

WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

WinRunner的特点在于: 与传统的手工测试相比，它能快速、批量地完成功能点测试; 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差; 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成; 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用; 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

WinRunner的工作流程大致可以分为以下六个步骤: 1．识别应用程序的GUI

在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。 2．建立测试脚本

在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL（与C语言类似的测试脚本语言）。录制脚本有两种模式: Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。

只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

3．对测试脚本除错(debug)

在WinRunner中有专门一个Debug Toolbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。 4．在新版应用程序执行测试脚本

当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

5．分析测试结果

分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。 6．回报缺陷（defect）

在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。

白盒测试作为测试人员常用的一种测试方法，越来越受到测试工程师的重视。白盒测试并不是简单的按照代码设计用例，而是需要根据不同的测试需求，

结合不同的测试对象，使用适合的方法进行测试。因为对于不同复杂度的代码逻辑，可以衍生出许多种执行路径，只有适当的测试方法，才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

白盒测试的概述

由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我

们经常相信某逻辑路径不可能被执行, 而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的，因此我们要进行白盒测试。

白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。 白盒的测试用例需要做到：

·保证一个模块中的所有路径至少 被使用一次 ·对所有逻辑值均需测试 true 和 false ·在上下边界及可操作范围内运行所有循环 ·检查内部数据结构以确保其有效性

白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。 白盒测试的实施步骤：

1.测试计划阶段：根据需求说明书，制定测试进度。

2.测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。

3.测试执行阶段：输入测试用例，得到测试结果。

4.测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。

白盒测试的方法：总体上分为静态方法和动态方法两大类。

静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。 白盒测试的优缺点 1. 优点

·迫使测试人员去仔细思考软件的实现 ·可以检测代码中的每条分支和路径 ·揭示隐藏在代码中的错误 ·对代码的测试比较彻底 ·最优化 2. 缺点 ·昂贵

·无法检测代码中遗漏的路径和数据敏感性错误 ·不验证规格的正确性

六种覆盖方法

首先为了下文的举例描述方便，这里先给出一张程序流程图。（本文以1995年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。 1、语句覆盖 1）主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。 2）用例设计：（如果此时将A路径上的语句1—〉T去掉，那么用例如下） 1 2 X 50 90 Y 50 70 路径 OBDE OBCE 3）优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。

4）缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句1—〉T去掉，那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支，那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在Do-While结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。

2、判定覆盖 1）主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。 2）用例设计： 1 2 3 X 90 50 90 Y 90 50 70 路径 OAE OBDE OBCE 3）优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。 4）缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。 3、条件覆盖 1）主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。 2）用例设计： 1 2 X 90 40 Y 70 路径 OBC OBD 3）优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加

了测试路径。

4）缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。 4、判定/条件覆盖 1）主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。 2）用例设计： 1 2 3 4 X 90 50 90 70 Y 90 50 70 90 路径 OAE OBDE OBCE OBCE 3）优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。 4）缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。 5、组合覆盖 1）主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。 2）用例设计： 1 2 3 4 X 90 90 90 70 Y 90 70 30 90 路径 OAE OBCE OBDE OBCE 5 6 7 30 70 50 90 70 50 OBDE OBDE OBDE 3）优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。 4）缺点：线性地增加了测试用例的数量。 6、路径覆盖 1）主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。 2）用例设计： 1 2 3 4 X 90 50 90 70 Y 90 50 70 90 路径 OAE OBDE OBCE OBCE 3）优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面

都广。

4）缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如： If （!A）B++； If （!A）D--；

这两个语句实际只包括了2条执行路径，即A为真或假时候对B和D的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的4条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。 总结

白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。 那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。 常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。 2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. 6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. 8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型. 12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。 18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了。 20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

白盒测试(White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。

白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。 \"白盒\"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。\"白盒\"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

如何挑选白盒测试工具

白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。

对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。

代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。

·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。

·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一

次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。

·条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。

·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。 ·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔条件，每个条件对于判定的结果值是的。

不同的测试工具对于代码的覆盖能力也是不同的，通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。

嵌入式软件的测试：对于嵌入式软件的测试，我们还需要一方面进一步考虑测试工具对于嵌入式操作系统的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等；另一方面还需要考虑测试工具对于硬件平台的支持能力，包括是否支持所有/32/16位CPU 和 MCU，是否可以支持 PCI/VME/CPCI 总线。 测试的可视化：白盒测试是工作量巨大并且枯燥的工作，可视化的设计对于测试来说是十分重要的。在选购白盒测试工具时，应当考虑该款测试工具的可视化是否良好，例如：测试过程中是否可以显示覆盖率的函数分布图和上升趋势图，

是否使用不同的颜色区分已执行和未执行的代码段显示分配内存情况实时图表等，这些对于测试效率和测试质量的提高是具有很大的作用的。