[计算机]测试用例编写要点.doc

测试用例编写要点 前言:根据详细设计文档编写测试用例的目的不在于验证软件达到的功能,而在于验证软件应该达到的功能.这样可以去除软件开发过程中的随意性. 1. 目的：统一测试用例编写的规范，以保证使用最有效的测试用例，保证测试质量。 2. 范围：适用于公司对产品的业务流程、功能测试测试用例的编写。 3. 功能测试用例编写原则。 3.1 单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能,由于是单个模块所以无法检验关联性,可能会牵扯到数据库的操作,例如:删除时,需要查看数据库是否完全删除了数据. 3.2 集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时,模块的连接是否正确(及数据的传递是否正确).我们的软件中体现出来的是,是否正确调用界面,界面之间显示的数据是否正确,特别是财务方面的. 集成测试用例的编写过程中,经常将功能用例与业务流程用例混合编写,因为在集成测试时很难将两者分开. 4. 业务流程测试用例编写原则。 4.1 集成测试业务流程用例的编写目的 集成测试业务流程用例的目的与集成测试功能用例的目的基本一样,在于验证数据的正确性,及界面之间的数据传递的准确、无误. 4.2 系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性.我们的软件体现为,手工数据与报表数据的一直性.用例与用例之间有着一定的关系,目的性十分明确. 5. 测试用例设计的原则(系统测试业务流程用例可以参考) 5.1 全面性 指编写的测试用例应该覆盖所有的详细设计文档描述的功能. 5.1.1 数据库程序基本的增、删、改功能. 增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验.输入的数据可能有无限种组合,此时可以采用等价类划分和边界值法. 删除的测试用例比较简单,只有操作没有数据的输入,但是应该在备注中注明,删除的限制条件,以及数据库中应该删除的表的情况.有条件限制时,测试用例应该包含各种删除条件,必要时在添加或修改的测试用例后面或中见,紧跟删除的测试用例. 5.1.2 对于无输入的操作,应该详细描述其具体的操作步骤和结果.例如:选择商品,可以通过多种途径进行,此时应具体描述程序从何处进入,通过何种操作,达到商品界面.对于报表的测试用例,最好紧跟在输入数据的后面,并且应该给出报表输出的数据的界面图(含数据). 对于不便书写测试用例的情况,应该在备注中说明,并写出可能的操作步骤.例如:对于文件夹的拖动,说明左右拖还是上下拖,结果如何就可以了. 5.1.3 单元测试用例的书写是使用一条数据,多种可能的情况考虑.但是对于其余各阶段的测试用例,必须考虑多条数据时的情况.此时主用是针对新增多条数据后,进行删、改、拖等情况的考虑. 5.1.4 应考虑存在跨年、跨月的数据 5.2 正确性 包括数据的正确性和操作的正确性. 首先保证测试用例的数据正确,其次预期的输出结果应该与测试数据发生的业务吻合. 操作的预期结果应该与程序发生的结果吻合 5.3 符合正常业务惯例 测试数据应符合用户实际工作业务流程.实际就是测试用例的先后顺序,先新增,后修改或删除.不能将删除放在第一位. 5.4 仿真性 人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。 5.5 可操作性 测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果不同.达到的目的是,任何人,均可以根据测试用例,单独进行测试. 6. 测试用例设计的方法 6.1 等价类划分法 6.1.1 确定等价类的原则 6.1.1.1 如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。 6.1.1.2 如果输入条件规定了输入值的集合，或者规定了“必须如何” 的条件，此时可确立一个有效等价类和一个无效等价类. 6.1.1.3 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类 6.1.1.4 如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合 6.1.1.5 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则） 6.1.1.6 如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类 6.1.2 测试用例的选择原则 6.1.2.1 为每一个等价类规定一个唯一的编号 6.1.2.2 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过 6.1.2.3 设计一