【IT168 技术文章】

　　启发法测试策略模型是设计测试策略的一套模式。这个模型的直接意图是提醒测试人员在创建测试时应该要想到的一些东西。最终，这套模型要根据实际情况来定制，并用来在专业测试人员中促进交流、自学、并且更充分的进行有意识的测试。

　　项目环境包括资源、约束、以及项目中有助于我们测试的其它强力因素，当然也包括阻碍我们做好工作的因素。当面对阻力时，先确认你是否利用了你所有可获得的资源。

　　产品元素就是你要测试的东西。软件是如此的复杂和不可见，以至于你要特别小心的确保你确实测试了产品中需要测试的所有部分。

　　质量标准是允许你作为一个测试人员来判断产品是否有问题的准则、价值观和来源。质量标准是多方面的，并且经常是隐藏的或者是自相矛盾的。

　　测试技术是创建测试时使用的策略。所有的测试技术都包括对项目环境、产品元素和质量标准的某种分析。

　　看得见的质量是测试的结果。你永远不可能知道一个软件产品的“实际”质量，但是通过对应用的各种各样的测试，你能对其质量做一个比较准确的评估。

　　1.常用测试技术

　　测试技术就是创建测试的方法。这都是些有趣的技术。下面列出了九种常用的技术。使用“常用技术”这个词，我是想说这些技术足够简单和普遍，并在各种不同的环境中都得到了广泛的应用。很多特殊技术都是基于这九种方法中的一种或者几种发展出来的。通过对一种或几种常用技术用覆盖的思想来组合，就可以构建成无数的特殊测试技术，这些覆盖的思想都是来自启发式测试策略模型中的其它列表中的。

　　1.1. 功能测试（Function Testing）

　　测试系统能够完成的功能。

　　? 找出产品能够做的事情（功能和子功能）。

　　? 判断你将怎么才能知道一个功能是否能正常工作。

　　? 测试每个功能，一次测试一个。

　　? 看看每个功能是否做了应该做的，而没有做不应该做的。

　　1.2. 域测试（Domain Testing）

　　Divide and conquer the data。（与等价类划分＋特殊值的方法类似――译者注）

　　? 分析产品的输入输出数据集。

　　? 判断测试的特殊值。考虑边界值，典型值，常用值，无效值，以及最具代表性的值。

　　? 考虑需要在一起测试的数据的组合。

　　1.3. 压力测试（Stress Testing）

　　征服产品。（在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为）

　　? 找出在挑战性的数据或者压倒性的资源面前对超载或者“破坏”敏感的子系统和功能。

　　? 辨识出与那些子系统和功能相关的数据和资源。

　　? 选择或生成测试所需的挑战性的数据或约束条件的资源：例如，大量或复杂的数据结构，高负载，长时间运行，大量的测试用例，低速存储器的情况。

　　1.4. 工作流测试（Flow Testing）

　　做完一件事再做另一件。

　　? 定义把具体的多个活动首尾链接起来测试过程或者高水平的用例。

　　? 在两个测试之间不要重置系统。

　　? 改变时间和顺序，并且尝试并发的线程。

　　1.5. 场景测试（Scenario Testing）

　　作为一个强制性的故事来测试。

　　? 首先，思考与产品关联的每一件事。

　　? 设计把产品中有意义的和复杂的相互作用包括在内的测试。

　　? 一个好的场景测试是一个关于一些人或事可能对产品进行怎样的操作故事。

　　1.6. 约束测试（Claims Testing）

　　验证每一条约束。

　　? 在产品的参考资料中辨识出其包含的约束（隐藏的或直接的）。

　　? 分析单个的约束，并明确比较含混的约束。

　　? 验证产品的每条约束是否是正确的。

　　? 如果你测试的依据是详细的规格说明书，就很值得使用这个技术，并且会把产品做的比较标准。

　　1.7. 用户测试（User Testing）

　　涉及了用户的测试。

　　? 分清楚用户的类别和角色。

　　? 判断每类用户会执行什么样的用例，怎样来执行，以及这样做的价值。

　　? 获得真实的用户数据，或者让真实的用户来测试。

　　? 否则，就要系统地模拟一个用户了（当心――想像你是一个用户很容易，但是实际上你并不是）。

　　? 非常有效的用户测试应该要涉及各种各样的用户和用户角色。而不是仅仅一个。