现在的位置: 首页 > 综合 > 正文

测试用例编写规范

2013年10月10日 ⁄ 综合 ⁄ 共 2291字 ⁄ 字号 评论关闭
 一、测试用例编写准备

从配置管理员处申请软件配置:《需求规格说明书》和《设计说明书》;根据需求规格说明书和设计说明书,详细理解用户的真正需求,并且对软件所实现的功能已经准确理解,然后着手制订测试用例。

  二、测试用例制定的原则

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试;基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面:

1、    正确性测试:输入用户实际数据以验证系统是满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。

2、    容错性(健壮性)测试:程序能够接收正确数据输入并且产生正确(预期)的输出,输入非法数据(非法类型、不符合要求的数据、溢出数据等),程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户,在进行任意操作。

3、    完整(安全)性测试:对未经授权的人使用软件系统或数据的企图,系统能够控制的程度,程序的数据处理能够保持外部信息(数据库或文件)的完整。

4、    接口间测试:测试各个模块相互间的协调和通信情况,数据输入输出的一致性和正确性。

5、    数据库测试:依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

6、 边界值分析法:确定边界情况(刚好等于、稍小于和稍大于和刚刚大于等价类边界值),针对我们的系统在测试过程中主要输入一些合法数据/非法数据,主要在边界值附近选取。

7、 压力测试:输入10条记录运行各个功能,输入30条记录运行,输入50条记录运行。。。进行测试。

8、等价划分:将所有可能的输入数据(有效的和无效的)划分成若干个等价类。

9、错误推测:主要是根据测试经验和直觉,参照以往的软件系统出现错误之处。

10、效率:完成预定的功能,系统的运行时间(主要是针对数据库而言)。

11、可理解(操作)性:理解和使用该系统的难易程度(界面友好性)。

12、可移植性:在不同操作系统及硬件配置情况下的运行性。

13、回归测试:按照测试用例将所有的测试点测试完毕,测试中发现的问题开发人员 已经解决,进行下一轮的测试。

14、比较测试:将已经发版的类似产品或原有的老产品与测试的产品同时运行比较,或与已往的测试结果比较

说明:针对不同的测试类型和测试阶段,测试用例编写的侧重点有所不同。

1、 其中第1、2、6、8、9、13项为模块(组件、控件)测试、组合(集成)测试、系统测试都涉及并重点测试的方面。

2、 单元(模块)测试(组件、控件)测试:重点测试第5项。

3、 组合(集成)测试:重点进行接口间数据输入及逻辑的测试,即第4项。

4、 系统测试:重点测试第3、7、10、11、12、14项。

5、 其中压力测试和可移植性测试如果是公司的系列产品,可以选用其中有代表性的产品进行一次代表性测试即可。

6、 GMPS基础测试用例设计完成后,其他的测试项目只编写设计与之不同部分的测试用例。

7、 对于每个测试项目测试的测试用例不是一成不变的,随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时,可以不断的补充完善测试项目的测试用例。

  三、测试用例的填写

一个软件系统或项目共用一套完整的测试用例,整个系统测试过程测试完毕,将实际测试结果填写到测试用例中,操作步骤应尽可能的详细,测试结论是指最终的测试结果(结论为:通过或不通过)。

用例编号
001
编制时间
2007-1-20
相关的用例
 
功能特性
投料
测试目的
把车间物料台账存放库位调整与实物的投料地点相同
数据准备
5条 物料流水码
预置条件
车间物料台账中存在 5条物料流水码,并已登记存放库位。
测试项
操作描述
测试数据
期望结果
测试结果
1输入库位号
输入新的库位编号,回车(投料)
02
页面跳转到下一页面,并显示刚输入的库位编号信息
 
 
没有输入库位编号,回车(投料)
空值
提示输入库位信息才能投料
 
 
输入长度超过4位的数字编号或不存在的库位编号,回车(投料)
020202或abc
提示没有当前库位编号
 
2输入流水码
扫描(输入)物料流水码,回车(加至投料清单)
QM0600011
把输入的物料流水码添加到投料清单表格中
 
 
没有输入流水码,回车
空值
提示物料流水码不能为空
 
 
输入长度超过9位的编号或随意输入值
QM060001121或abc
提示物料流水码不正确 信息
 
3投料
检查清单,需投的物料全部录入后,选择 投料
 
提示投料成功
 
 
检查清单,需投的物料全部录入后,选择 投料
 
如果投料操作失败,提示错误信息
 
测试人员
 
开发人员
 
 
                 
 
四、   提交BUG报告
通过前边的测试,把得出的错误信息,以BUG报告的形式展现出来,转发给开发部门相应人员,以例开发部集中修改系统错误信息。下边说一下BUG报告的内容:错误序号、发现日期、子系统名称、二级模块名称、三级模块名称、发生页面、错误描述、发现者、是否修改状态、修改人意见、修改人、修改日期、确认人、确认日期。按着上边这几项内容,将错误信息以BUG报告的形式列表出来,转发给相应的部门修改。
五、   回归测试
BUG修改完毕后,更新ERP系统,更新完毕后,对已往的错误信息进行二次测试,以确保错误信息的正确修改。
通过以上五个步骤,把我们销售部当前进行的测试工作,做了一个完整的总结,这就是我们目前采用的简单的测试方法和步骤,经过我们的测试,系统性能得到了一定的提高,当然不否认系统还可能存在一些潜在的问题,这需要我们在后期维护中不断的改进,今天写到这里,希望有测试经验的朋友能提出更好的测试建议,我们一同提高!!

抱歉!评论已关闭.