快速测试-启发测试策略模型_软件测试面试必备.doc

_软件测试面试必备 启发法测试策略模型 启发法测试策略模型是设计测试策略的一套模式。这个模型的直接意图是提醒测试人员在创建测试时应该要想到的一些东西。最终，这套模型要根据实际情况来定制，并用来在专业测试人员中促进交流、自学、并且更充分的进行有意识的测试。 项目环境包括资源、约束、以及项目中有助于我们测试的其它强力因素，当然也包括阻碍我们做好工作的因素。当面对阻力时，先确认你是否利用了你所有可获得的资源。 产品元素就是你要测试的东西。软件是如此的复杂和不可见，以至于你要特别小心的确保你确实测试了产品中需要测试的所有部分。 质量标准是允许你作为一个测试人员来判断产品是否有问题的准则、价值观和来源。质量标准是多方面的，并且经常是隐藏的或者是自相矛盾的。 测试技术是创建测试时使用的策略。所有的测试技术都包括对项目环境、产品元素和质量标准的某种分析。 看得见的质量是测试的结果。你永远不可能知道一个软件产品的“实际”质量，但是通过对应用的各种各样的测试，你能对其质量做一个比较准确的评估。 常用测试技术 测试技术就是创建测试的方法。这都是些有趣的技术。下面列出了九种常用的技术。使用“常用技术”这个词，我是想说这些技术足够简单和普遍，并在各种不同的环境中都得到了广泛的应用。很多特殊技术都是基于这九种方法中的一种或者几种发展出来的。通过对一种或几种常用技术用覆盖的思想来组合，就可以构建成无数的特殊测试技术，这些覆盖的思想都是来自启发式测试策略模型中的其它列表中的。 功能测试（Function Testing） 测试系统能够完成的功能。 找出产品能够做的事情（功能和子功能）。 判断你将怎么才能知道一个功能是否能正常工作。 测试每个功能，一次测试一个。 看看每个功能是否做了应该做的，而没有做不应该做的。 域测试（Domain Testing） Divide and conquer the data。（与等价类划分＋特殊值的方法类似――译者注） 分析产品的输入输出数据集。 判断测试的特殊值。考虑边界值，典型值，常用值，无效值，以及最具代表性的值。 考虑需要在一起测试的数据的组合。 压力测试（Stress Testing） 征服产品。（在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为Flow Testing） 做完一件事再做另一件。 定义把具体的多个活动首尾链接起来测试过程或者高水平的用例。 在两个测试之间不要重置系统。 改变时间和顺序，并且尝试并发的线程。 场景测试（Scenario Testing） 作为一个强制性的故事来测试。 首先，思考与产品关联的每一件事。 设计把产品中有意义的和复杂的相互作用包括在内的测试。 一个好的场景测试是一个关于一些人或事可能对产品进行怎样的操作故事。 约束测试（Claims Testing） 验证每一条约束。 在产品的参考资料中辨识出其包含的约束（隐藏的或直接的）。 分析单个的约束，并明确比较含混的约束。 验证产品的每条约束是否是正确的。 如果你测试的依据是详细的规格说明书，就很值得使用这个技术，并且会把产品做的比较标准。 用户测试（User Testing） 涉及了用户的测试。 分清楚用户的类别和角色。 判断每类用户会执行什么样的用例，怎样来执行，以及这样做的价值。 获得真实的用户数据，或者让真实的用户来测试。 否则，就要系统地模拟一个用户了（当心――想像你是一个用户很容易，但是实际上你并不是）。 非常有效的用户测试应该要涉及各种各样的用户和用户角色。而不是仅仅一个。 风险测试（Risk Testing） 设想一个问题，然后去找到它。 这个产品会有哪些种类的问题？ 哪种问题是最要紧的？关注那些问题。 如果真有这些问题，你将怎样来侦测？ 做一个有趣的问题的列表，并特别设计一些测试来发现这些问题。 可能需要一些帮助，包括咨询顾问、设计文档、以前的缺陷报告、或者使用风险启发法。 自动化测试（Automatic Testing） 运行大量不同的测试。 寻找适合自动的生成大量的测试的机会。 开发一套自动化的、高速评估的机制。 写程序来生成、执行并评估这些测试。 项目环境 创建和执行测试是测试项目的核心所在。然而，在你决定要创建什么样特定的测试时，项目环境中有很多因素都是关键性的。对于下面的每个类别中的因素，都要考虑它们可能会怎样帮助或阻碍你的测试设计进程。试着利用好每一个资源。 客户。这个测试项目中作为客户的任何人。 你知道谁是你的客户么？谁的意见要紧？谁从你做的工作中受益或者利益收到损害？ 你同你的客户联系和交流过了么？可能他们对你的测试有帮助。 可能你的客户对你要创建和运行的测试有很强烈的想法。 可能客户之间对测试有相冲突的期望。你可能不得不帮着分析清楚并解决这些冲突。 信息。关于需要被测试的