测试用例编写
文章目录
前言
- 知识目录
- 这是平时学习总结的地方，用做知识库
- 平时看到其他文章的相关知识，也会增加到这里
- 随着学习深入，会进行知识拆分和汇总，所以文章会随时更新
- 参考的文章过多，所以参考会写不全，见谅
1.定义
对一项特定软件产品进行测试任务的描述，指定输入，预期结果和一组测试项的执行条件的文档
- 体现测试方案、方法、技术和策略
- 内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等
2.元素
-
测试目标：why—为什么而测？
功能、性能、可用性、容错性、兼容性、安全性
-
测试对象：what—测什么
被测试的项目：对象、函数、类、菜单、按钮、表格、接口、整个系统等
-
测试环境：where—在哪里测
测试用例运行时所处的环境，包括系统的配置和设定等要求。也包括操作系统、浏览器、通讯协议等单机或联网环境
-
测试前提：which—哪些数据
操作使各种可变化的数据，比如：数字，字符，文件等
-
操作步骤：how—如何测
执行程序和程序的先后次序步骤等，如打开对话框、点击按钮
3.重要性
- 是测试人员在测试过程中的重要参考依据
- 可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行无意义的测试操作
- 良好的测试用例可以重复使用，使得测试事半功倍
- 测试用例是一个积累的过程
- 是一个知识传递的过程，能保持一致、稳定的测试质量
- 测试用例的通过率是检验代码质量保证效果最主要的指标
- 测试用例也可以作为评估测试人员进度、工作量以及跟踪管理测试的工作效率的主要因素，从而更加合理作出测试安排和调整
4.写作说明
1.一些测试用例的模板
https://blog.csdn.net/shulei00/article/details/105613314
2.测试用例的写作说明
-
用例编号/序号
简单、唯一（常常是 项目号-例-编号 ，这个还要看具体的单位）
-
用例说明
- 也称为：测试点、检查点、测试概述、测试说明
- 一句话对测试用例进行概述
- 可以总结测试目的
- 可以用疑问句表示
- 最好看到这句话就知道如何测试
- 尽量唯一（决策表可能会有重复的测试说明）
- 用例执行多轮以后，执行会越来越快，写得好得好，直接看概述就行
- 用词：检查、验证、测试
-
初始条件
- 也称：预置条件、前提条件
- 是一个静态的状态，如登陆后台
- 是第一步操作之前的状态，不能太远，不用从头写到尾
- 很多项目都不写预置条件
-
操作步骤
- 若对数据要求高，需要把数据分离出来
- 步骤都要有需要
- 每一步用分号分开，最后一个用句号
- 每一步必须换行
- 参数前要加 冒号 ：如（密码：123）
- 设计按钮的界面用 【】“ ”成对间隔
- 功能的详细用例步骤4-6步
- 最后一步一步是个动作，不能写结果
5.预期结果
- 一个状态
- 如果参考文档中有描述，就原封不动抄过来
- 如果参考文档没有描述，则要点一致，可以有几个点。如：QQ默认安装，应能启动
6.用例状态
- 通过、失败、阻塞、未执行、搁置、无效用例
- 初始条件达不到时，一般用例状态设置为阻塞
- 看如何执行用例，执行完关心什么决定
7.优先级
就是用例的执行顺序
3.优先级
1.优先级分类
2.优先级的设置
- 考虑成本、时间、人员等因素，兼顾测试的充分性和效率
- 用例的关联性
- 用例的干扰性
5.评审管理
1.保证质量的办法
- 首先：要对客户需求、服务质量要求、产品特性有深刻且全面的理解
- 其次：采用正确恰当的方法进行用例设计
- 然后：按照测试用例的标准格式或规范的模板来书写测试用例
- 最后：对测试用例的审查、评审，也是提高测试用例质量的主要且有效手段
2.用例评审要点
- 根据检查单或检查表（check list）进行评审
- 用例“文字校对”：错别字、病句、语句不通、含义不清、语句有歧义、格式不一致、标点不一致、中英文混合
- 用例质量：遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例
- 确认用例的优先级
- 规划服务器和客户机
- 用例的分工执行和人员安排
- 记录评审过程，记录测试环境规划
6.测试用例维护
1.原因
通常情况下，测试用例需要更新，原因如下 ：
- 先前的测试用例设计不全面或不够准确。随着测试的深入和对产品规格说明书的深入研究，对某些、功能、特性、逻辑等的理解越来越清晰、深刻
- 所发现的严重的软件缺陷没有被目前的测试用例所覆盖
- 编写的测试用例不规范或语句错误
- 新的版本中新的功能的需求或原有的功能的增强而需要发生改动
- 旧的测试用例已经不再适用，需要删除
2.测试用例管理工具
- excel
- Bugfree
- ZenTao
- ALM/QC
7.用例设计与编写方法总结
1.通过测试
用于验系统和它陈述的需求一致，确认软件至少能做什么，一般通过分析需求说明书来设计测试用例
2.失败测试
纯粹为了破坏软件而设计和执行的测试案例，也称迫使出错测试。主要用于证明“一个软件不会去做不需要它做的事情”
3.随机测试
也称即兴测试，是指临时准备的、即兴的 bug 搜索测试过程
- 缺点：
- 无法度量随机测试的实际覆盖率
- 许多测试都是冗余的
- 测试数据因为是随机的，重复测试是不可能的
4.应用群效应
-
找到的软件的缺陷越多，说明那里的问题越多，
如：在测试中发现大量的上边界条件缺陷，则在测试时应注重上边界
-
程序员倾向于修复报告出来的问题，要保证除此之外可能存在的其他问题不会出现
5.探索性测试
1.含义
- 一种测试的思维技术
- 是一种精致的、有思想的测试
- 强调测试设计和测试执行的同时性
- 测试人员需要不断学习被测试系统，同时把学习到的关于软件系统的更多信息，通过综合整理进而分析，创造出更多关于测试的注意
- 测试设计、测试执行、测试日志的记录似乎是无关紧要的工作
- 测试人员必须根据测试章程在规定的时间内完成
2.适合的场所
- 没有或者只有少量有价值的文档
- 常用于在时间压力下
- 为补充合适的、正式的和形式化测试
8如何选择用例设计与编写方法
- 先：使用大纲法拆分功能
- 后：使用场景法、决策表设计测试用例
- 如果程序功能说明中含有输入条件的输入情况，则应在开始就选用决策表法
- 次：用等价类划分法、边界值分析法、错误猜测法 补充测试用例
- 执行测试时进行探索性测试或随机测试
- 后：执行测试用例后进行随机测试
参考
1.尚学堂课件
跳转
的、正式的和形式化测试
8如何选择用例设计与编写方法
- 先：使用大纲法拆分功能
- 后：使用场景法、决策表设计测试用例
- 如果程序功能说明中含有输入条件的输入情况，则应在开始就选用决策表法
- 次：用等价类划分法、边界值分析法、错误猜测法 补充测试用例
- 执行测试时进行探索性测试或随机测试
- 后：执行测试用例后进行随机测试
参考
1.尚学堂课件
跳转
知识目录](https://blog.csdn.net/shulei00/article/details/105611178)