测试技能总结.docVIP

测试用例的设计方法 1. 等价类划分：根据输入域或者输入条件，分为有效等价类和无效等价类。在等价类中选取test data。做到覆盖完整。一个无效等价类为一个case2. 边界值分析：来自等价类的边界。分析来自输入输出范围的边界值，选取刚好等于，刚好大于，刚好小于的值。也就是注意两侧。3. 错误推测： 凭借经验和直觉推出所有可能发生错误的情况-必要时用等价类划分方法补充一些测试用例-用错误推测法再追加一些测试用例-对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例-如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法测试用例的设计步骤：-构造根据设计规格得出的基本功能测试用例（UIfunction）-边界值测试用例（function）-状态转换测试用例（function）-错误猜测测试用例（function）-异常测试用例 （non-function）-性能测试用例（non-function）-压力测试用例（non-function）优化测试用例的方法：－　利用设计测试用例的8种方法不断的对测试用例进行分解与合并－　采用遗传算法理论进化测试用例－　在测试时利用发散思维构造测试用例 软件测试用例设计的基本原则 在测试用例设计时，除了需要遵守基本的测试用例编写规范外，还需要遵循些基本的原则。 　　1、尽量避免含糊的测试用例 　　含糊的测试用例给测试过程带来网难，甚至会影响测试的结果。在测试过程。测试用例的状态是惟一的，通常情况下，在执行测试过程。良好的测试用例一般会有二种状态：通过(PAss)、未通过(Failed)以及未进行测试(Not Done)，如果测试术通过，一般会有测试的错误(bug)报告进行关联：如未进行测试，则需要说明原因(测试用例本身的错误、测试用例目前不适用、环境因素等)，因此，清晰的测试用例使测试人蚰在测试过程中小会出现模棱两可的情况，不能说这个测试用例部分通过，部分未通过，或者是从这个测试用例描述中小能找到问题，但软件错误应该出现在这个测试用例巾。这样的测试用例将会给测试人员的判断带来团难，吲时也不利于测试过程的跟踪。 　　例如，还用上断的例子来说明，对用户登录的页面校验测试进行测试用例设计： 　　● 输入JF确的用户和密码，输入错误的用户和密码，程序会弹出对话框。 　　在L而这样的测试用例设计，未能清楚地描述什么样是程序正常工作状态，什么样是程序不正常工作状态，这样含糊不清的测试用例必然会导致测试过程问题的遗漏。 　　2、尽量将具有相类似功能的测试用例抽象并归类 　　一直强调软件测试过程是无法进行穷举测试的，因此，对相类似的测试用例的抽象过程显得尤为重要，一个好测试用倒应该足能代表组或者一系列的测试过程。 　　3、尽量避免冗长和复杂的测试用例 　　这样做的主要目的是保证验证结果的惟一性。这也是和第一条原则相一致的，为的是在测试过程执行过程th确保测试用例的输出状态惟性，从而便于跟踪和管理在一些很长和复杂的测试用例设讨过程中，需要将测试用例进行合理的分解，从而保证测试用例的准确性。在某些时候，测试用例包含很多类型的输入或者输乩或测试过程的逻辑复杂而币连续，此时需要对测试用例进行分解。张实际的测试用例设计中，需要将前述的基本原则和考虑凶素结台起来，遵循基本的测试用例编写规范。按照实际测试的需求灵活地组织设计测试用倒。 在测试例设计监考虑白盒测试用例年u黑盒测试用例。 　1、软件Bug少不代表质量高。 2、测试人员无法保证软件的质量。 3、质量是双方一定价格下的一个妥协（这个就像我说的买卖衣服一样）。 用例检查清单： 　　1）测试用例是否按照公司定义的模板进行编写的； 　　2）测试用例的本身的描述是否清晰，是否存在二义性； 　　3）测试用例内容是否正确，是否与需求目标相一致； 　　4）测试用例的期望结果是否确定、唯一的； 　　5）操作步骤应与描述是否相一致； 　　6）测试用例是否覆盖了所有的需求； 　　7）测试设计是否存在冗余性； 　　8）测试用例是否具有可执行性； 　　9）是否从用户层面来设计用户使用场景和业务流程的测试用例； 　　10）场景测试用例是否覆盖最复杂的业务流程； 　　11）用例设计是否包含了正面、反面的用例； 　　12）对于由系统自动生成的输出项是否注明了生成规则； 　　13）测试用例应包含对中间和后台数据的检查； 　　14）测试用例应有正确的名称和编号； 　　15）测试用例应标注有执行的优先级； 　　16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等； 　　17）每个测试用例步骤应=15 Step； 　　18）自动化测试脚本必须带有注释（注释应包括：目的