测试用例编写规范小结

简介:

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

  二、测试用例制定的原则

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

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

  三、测试用例的填写

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

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

目录
相关文章
|
测试技术 数据安全/隐私保护
软件测试制度-新手小白如何制定测试管理工作规范?
软件测试制度-新手小白如何制定测试管理工作规范?
437 1
|
前端开发
14 # promise 规范测试
14 # promise 规范测试
127 0
|
数据可视化 测试技术
一文了解软件测试规范
软件测试规范是测试工作的依据和准则,在进行软件测试时,应在相关国标文件的要求和指导下完成测试工作,这样可以从根本上保证软件测试工作的质量,进而提升软件产品的质量。 一个完整的软件测试规范应该包括对规范本身的详细说明,例如规范的目的、范围、文档结构、词汇表、参考信息、可追溯性、方针、过程/规范、指南、模板、检查表、培训、工具、参考资料等。
1402 0
一文了解软件测试规范
|
安全 测试技术 数据库
测试流程规范--准入准出规则
为了加强测试部软件测试的质量控制及与测试相关部门、人员更好理解测试各阶段的准入/准出条件而建立的准入/准出规范。
2771 0
测试流程规范--准入准出规则
|
7月前
|
编解码 缓存 Prometheus
「ximagine」业余爱好者的非专业显示器测试流程规范,同时也是本账号输出内容的数据来源!如何测试显示器?荒岛整理总结出多种测试方法和注意事项,以及粗浅的原理解析!
本期内容为「ximagine」频道《显示器测试流程》的规范及标准,我们主要使用Calman、DisplayCAL、i1Profiler等软件及CA410、Spyder X、i1Pro 2等设备,是我们目前制作内容数据的重要来源,我们深知所做的仍是比较表面的活儿,和工程师、科研人员相比有着不小的差距,测试并不复杂,但是相当繁琐,收集整理测试无不花费大量时间精力,内容不完善或者有错误的地方,希望大佬指出我们好改进!
441 16
「ximagine」业余爱好者的非专业显示器测试流程规范,同时也是本账号输出内容的数据来源!如何测试显示器?荒岛整理总结出多种测试方法和注意事项,以及粗浅的原理解析!
|
消息中间件 测试技术
项目环境测试问题之规范执行器的异常处理如何解决
项目环境测试问题之规范执行器的异常处理如何解决
|
JavaScript 前端开发 安全
Cypress因其强大的端到端测试能力备受青睐,尤其与TypeScript结合,提升了测试的规范性和准确性。
【6月更文挑战第12天】前端开发日益复杂,测试成为保障代码质量和稳定性的关键。Cypress因其强大的端到端测试能力备受青睐,尤其与TypeScript结合,提升了测试的规范性和准确性。TypeScript使Cypress测试代码更易读、维护,通过类型定义、自定义命令和断言增强测试可靠性。Cypress能模拟真实用户操作,支持时间旅行和高效调试,全面测试前端应用功能。因此,TypeScript+Cypress是前端端到端测试的理想选择。
140 2
支付系统---微信支付14----创建案例项目---介绍,第二步引入Swagger,接口文档和测试页面生成工具,定义统一结果的目的是让结果变得更加规范,以上就是谷粒项目的几个过程
支付系统---微信支付14----创建案例项目---介绍,第二步引入Swagger,接口文档和测试页面生成工具,定义统一结果的目的是让结果变得更加规范,以上就是谷粒项目的几个过程
|
运维 Kubernetes jenkins
测试流程--测试发版规范
为了保证系统稳定性,对软件项目的上线过程进行规范,确保项目符合产品需求。对于已经开发完毕的系统,需要正式部署到生产环境前必须严格按照以下流程规范实施。 规范发版的流程,指定发版的相关输出,相关信息的收集,并通知相关业务方了解发版信息。防止或减少因发版造成的系统抖动对业务产生的影 响,并有利于追溯发版过程,方便后续优化迭代。
2003 0
测试流程--测试发版规范
|
测试技术
软件测试用例评审标准规范是什么?附模板
软件测试用例评审标准规范是什么?附模板
1196 1