11.4  功能测试的经验及注意事项

1. 获得有效的测试数据

（1）在建立详细的测试设计期间，测试用例中会加入对测试数据的需求，这样测试用例就成为测试过程的一部分。有效的测试策略要求细心收集和准备测试数据。如果测试数据很糟，就会影响测试的效果。反过来，好的测试数据有助于提高测试的质量。优秀的测试数据还能够帮助理解测试工作，提升可测试性。正确选择测试数据的内容还可以减少维护的工作量。如果需求不明确，那么准备高质量的测试数据可以在某种程度上拉近产品与用户实际需求之间地距离。

（2）在准备测试数据的过程中，软件产品的各种设计文档是非常有用的。它们有助于确定应用程序中数据的各种交互方式以及各个数据元素之间的关系。我们通常不可能针对所有可能的情况对输入和输出的各种组合和变化都加以测试，以确认应用程序的功能性和非功能性需求都能够满足所有条件。但是，可以通过各种各样的测试设计技术，减少数据输入和输出的组合和变化。数据流覆盖就是这样一种测试技术，它是为把数据流并入经过选择的测试步骤而设计的，它有助于在所有适用的测试路径中确定满足某些数据流特点的测试路径。

（3）边界条件测试是另一种测试技术。我们会为每个边界条件(数据的数量或者允许的内容有限制，它们是在需求陈述中列出并在软件设计中设置)准备测试数据。系统的行为经常在它们的边界上发生变化。错误集中在边界上发生，因此，在边界上测试系统的行为是一种非常有效的测试技术。

（4）边界条件应该在需求陈述中列出，如果系统需求中没有指定边界条件，必须将实际发现的边界测试加入到测试计划中。值得注意的是，这类测试非常普遍，因为在通过集中测试确定边界之前，开发人员经常也不知道边界是什么。

（5）理想情况下，确定需求的可测试性时，这些问题就应该已经解决。但是随着软件复杂度的不断提高，在需求阶段就确定系统的边界通常有很大的困难。确定边界的一个替代方法是开发软件测试的原型。

（6）测试数据的设计必须使得每个系统级的需求都能经过测试和验证。测试数据的需求评审应该关注数据的几个关键方面，其中包括：

（7）测试组必须考虑支持测试工作所需的数据库记录的数量和规模。测试组必须确定数据库中或者某一数据表中只存储了10条记录就已经足够，还是必须有10，000条记录才行。例如在单元测试和集成测试中，应该使用小规模和手工建立的数据库，这样可以最大限度地控制测试工作，并且测试的针对性最强。当测试工作的进程进一步深入，各个阶段和类型的测试已经基本完成的时候，为了适应某些特殊的测试，还必须适当增加数据库的规模。例如：如果实际工作环境中的数据库可能容纳1，000，000条记录，而实际执行测试时的数据库只包括100条记录，那么性能测试和容量测试就没有任何意义。

（8）测试人员必须研究数据数值的变化，例如： 10，000个不同的账目包含不同的数值，或者许多不同类型的账目包含不同的数据类型。一个精心设计的测试会考虑测试数据的变化，反之，所有测试数据都相似的测试，其输出结果是有限的。对于包含不同数值的数据记录测试人员需要考虑有些账目可能包含负的余额，或者100元的小额账目、1000元的中等额度、100，000的大额账目和10，000，000的超大额账目。而对于包含不同数据类型的记录，测试人员则需要考虑，把银行客户的账目分成几类，其中包括存款、支票、贷款、学生、联合和商业账目。

（9）测试数据的范围与数据的精确度、相关程度和完整程度之间是有关联的。例如：通过查询操作确定银行中各种总数大于100元的账户，要对这一查询进行测试时，测试数据中不仅应该包含大量符合上述标准的账户，而且测试也必须反映其他的数据，例如，相关历史和账目所有者的统计数据。使用完整的测试数据，可以使测试过程全面地验证和检查系统，并且支持对结果的评估。测试人员还必须验证，对于特定目的的查询，查询结果中记录的内容是否合法，并且还要验证查询结果是否有遗漏数值，是否包括错误的数值。

（10）在测试执行期间要关注测试数据的完整性。在执行测试的过程中，测试人员必须保持数据的完整性。测试组在测试过程中，必须能分离数据、修改所选的数据，并且能使测试数据恢复到初始状态。测试过程还要保证当几个测试人员同时执行测试时，任何一项测试不能干扰其他测试所需的数据。为了防止测试人员的工作影响其他测试人员，.可以采用为每个测试人员分配一个独立的测试数据存储空间。另一种办法是为每个测试人员分派不同的测试任务，使每个人集中测试一个特定的功能领域，不和其他人测试的领域发生交叉(这种方法可能会产生一些风险)。

（11）创建的数据集应该能够反映应用程序所在领域的特定"条件"，这就是说特定模式的测试数据并不需要等到特定时间之后才能通过执行特定的操作获得。

（12）当确认测试数据需求时，制作一张表格，一列是测试过程，另一列是测试数据需求，这一做法很有好处。在这些需求中，标明所需要测试数据的规模和产生测试数据所需要的时间非常重要。虽然一个小规模的测试数据子集已经足够用来进行功能测试，但是性能测试却可能要求模拟实际生产规模的数据库。获得这一数据库可能需要很长的时间，有时要长达几个月。

（13）测试人员必须设计获得、生成或者开发测试数据的方法。为使得包括回归测试在内的所有测试活动能够顺利进行，对测试数据进行初始化的机制或方法应该在测试计划中进行设计并文档化。测试人员必须确定要使用的测试数据和资料的名称和位置，这些测试数据和资料是检查和测试应用软件所必需的。

（14）测试数据通常必须在测试之前准备好。准备测试数据应该包括对原始数据文本或文件的处理、一致性检查和深入分析数据元素等过程，其中后者又包括定义数据到测试用例的映射标准、澄清数据元素定义、确定主键和定义可接受的数据参数。为了准备数据，也为了开发出环境的安装和试验脚本，测试组必须获得并修改所需的全部测试数据库。最理想的情况是使用客户现成的数据，因为它们是实际环境中出现的数据场景的真实组合和变化。使用真实的客户数据的一个好处是它们可能包含测试设计人员没有考虑到的数据组合或者使用模式。通过真实的客户数据测试应用程序，对应用程序来说是一种实用的真实环境下的检查。

2. 参考无经验用户的做法 

所谓无经验的用户，就是指普通用户或新用户。一个不熟悉软件的人面对程序时，会做出令人永远想不到的举动。他们会输入程序员无从想像的数据；会在中途变卦，退回去执行其他操作；在进入程序的某个界面以后，用鼠标单击不应该单击的东西：发现开发小组完全遗漏的软件缺陷。

软件测试员看到一个没有任何测试经验的人只花5分钟使用软件并使其崩溃，一般都会感到沮丧。这些无经验的用户都不遵循任何规则，也不做任何假定。

在设计测试用例或初次查看软件时，要设法像初级用户那样想问题。因此在测试的过程中有必要进行角色转换，抛开从逻辑和技术角度分析软件应该如何工作的思维方式。如果可能，找一个其他专业的朋友整理思路。然后把这些测试用例加入到已经设计好的测试用例库中，这样测试用例库将会更加全面。

3. 在已经找到软件缺陷的地方再查找

在已经找到软件缺陷的地方再找缺陷的原因有以下两个：

（1）如前所述，找到的软件缺陷越多，就说明那里的软件缺陷越多。如果发现在不同的特性中找出了大量边界条件方面的软件缺陷，那么明智的做法是着重对所有特性的边界条件进行测试。当然，多数情况下，实际环境或条件不允许做如此详尽的测试，但还是应该投入一些案例来保证这个问题不是普遍存在的。

（2）许多程序员倾向于只修复报告出来的软件缺陷。如果报告软件缺陷是启动-终止-再启动255次导致冲突，程序员就只修复这个问题。也许是内存泄露导致这个问题出现，程序员找 到症结并将其修复。当拿回软件重新测试时，一定要重新执行同样的测试，并测试256次以上。在这个范围之外极有可能存在其他的内存泄露问题。

4. 凭借经验、直觉和预感

要想成为真正的软件测试员，积累经验是不可替代的。

经验和直觉是不可言传的，必须经过长期的积累。运用现在学到的全部技术进行测试，仍有可能遗漏重要的软件缺陷，这是无法更改的事实。随着在实践过程中的逐步提高，学习测试不同类型和规模的产品，就会得到各种技能和技巧，以更加有效地找出软件缺陷。重新开始测试新软件就可以很快找出以前遗漏的软件缺陷。

记录哪些技术有效，哪些不行，尝试不同的途径。如果认为有可疑之处，就要仔细探究。按照直觉行事，直至证实这是否是错误为止。

小结

本章对功能测试的主要内容和测试策略做了简单介绍，重点介绍了功能测试的测试方法，如输入不同情况的数据、输出属性修改及其他典型操作等。