发布时间 : 星期日 文章测试用例设计方法更新完毕开始阅读
500)this.width=500\2、根据因果图建立判定表。
按条件的各种组合情况产生对应的动作。原因1和原因2不能同时成立，故可排除这种情况。
从判定表可设计出测试用例：6个测试用例是所需的数据。
前言:根据详细设计文档编写测试用例的目的不在于验证软件达到的功能,而在于验证
软件应该达到的功能.这样可以去除软件开发过程中的随意性.
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 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一
步，直至所有的无效等价类都被覆盖为止
6.2 边界值分析法 6.2.1 测试用例的选择原则
6.2.1.1 如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超
越这个边界范围的值作为测试输入数据 6.2.1.2 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最
小的小1的数作为测试输入数据
6.2.1.3 根据详细设计说明书的每个输出条件，使用前面的原则
6.2.1.4 如果程序的详细设计说明书给出的输入输出域是有序集合，则应选取集合的每
一个元素和最后一个元素作为测试用列 6.2.1.5 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上
的值作为测试用例
6.2.1.6 分析详细设计说明书，找出其他可能的边界条件
7. 测试用例编写格式细则
7.1 测试用例内容
7.1.1 具体实施可以采用EXCEL和图形相结合，可用EXCEL编写测试用例的同时插
入图形来加以说明。测试用例设计的内容可由：模块名、功能说明或图形说明、测试用例输入、应输出结果、实际输出结果、结论、BUG编号、BUG级别8部分组
成
7.2 测试用例表格格式 7.2.1 表格内容的字体为宋体 7.2.2 表格内容的字型为12号
8. BUG级别 致命、严重、一般
测试用例的设计一般从分析需求设计说明书开始，了解开发人员设计这个项目的思路、设计的要求、实现的功能等（最好有use case，这样看起来更清晰）。软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。每个公司都有适合自己公司用例编写的模板，各有各的特点。测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。