测试用例的写作与规范
2024-05-14 16:32:44 0 举报
AI智能生成
测试用例(Test Case)是软件测试中的基本单元,用于描述特定输入、操作步骤和预期输出。规范地编写测试用例有助于提高测试的准确性、有效性和可维护性。一份高质量的测试用例应当包含以下核心内容: 1. 测试目标:明确测试用例的测试目的,即要验证的软件功能或特性。 2. 前置条件:描述在执行测试用例之前必须满足的各项条件,如系统状态、配置设置等。 3. 测试步骤:详细描述执行测试用例所需的操作步骤,应尽可能清晰、简洁,便于理解和执行。 4. 预期结果:明确测试用例执行后应出现的结果,包括输出内容、界面显示等。 5. 测试数据:提供测试用例所需的输入数据,包括参数值、文件内容等。 6. 重要级别:标识测试用例的重要程度,有助于安排测试优先级。 7. 编写人员与日期:记录测试用例的编写者和编写日期,便于追踪和维护。 在编写测试用例时,还应遵循一定的规范,如使用简洁、规范的语言,确保测试用例的可读性和可维护性。同时,要确保测试用例的完整性和准确性,避免遗漏重要的测试场景。
作者其他创作
大纲/内容
企业现状
具备测试用例编写能力
公司研发流程不规范
没有用例,直接测试
需要用例,但是没有相关文档,不方便编写用例
后期接入项目团队,需要在短时间内上线
上线之后,遇到的紧急的用户问题,需要短时间修复
解决方案
不推荐不写测试用例,因为有弊端,而且测试用例就是拿来指导测试执行的
checklist表,做校验,相当于简易的测试用例(针对测试点的校验);13;可对checklist做改善,测试输入、预期结果、操作步奏加在checklist里面,时间不够一般用checklist
以软件测文档
操作软件+用户手册
28原则(80%的用户只会用到20%功能模块),(不能一上来就测,要分析checklist,做分解,看由哪些模块组成,13;然后对模块进行分级,分为核心模块,基本模块,辅助模块,然后再依据28原则来操作软件,用户手册)
测试点,记录下来,边测试边补充完善测试用例
以文档测软件
上线
上线时间:午夜
3*24小时,项目组(如果遇到问题都会在短时间内解决,用于遇到问题,13;就会在自己的环境中确认问题,然后修改问题,再进行测试,再发布上线)
依据经验+相关模块用例的分析+开发,测试完成后,补充用例
非用例发现的bug(维护、更新用例)
没有用例或记录来与之对应,用例一般都涵盖不全;13;非用例发现的bug,这个是很正常的现象,但是要控制比例
在项目后期(间歇期),在空闲时间就要去维护更新测试用例
用例发现bug
有用例来与之对应的bug
测试用例架构(组成),按照架构编写测试用例
不规范
规范
用例标题
用例编号
输入数据
操作步奏
前置条件
预期结果
执行结果
作者
执行人
测试时间
测试思路
测试点
平台
环境
版本
优先级
测试项
测试子项
用例元素
基本元素
标题
一般建议不超过20个字
不能重复
可以适当的在标题里面加上一些预期结果,可避免重复
可以适当加入结果和操作步奏
让执行人通过标题,知道用例是干嘛的
预期结果
UI的结果
数据库的结果
模块与模块之间有交互,还要写出相关交互的结果
涉及到日期差看的结果,还要查看日志log
预置条件
在做某一个操作步奏之前,需要达到什么要求
优先级
进度、时间紧、任务重
是不是所有的用例都需要执行?
先执行哪些?后执行哪些?
标识符:非常高、高、中、低,1,2,3,4
扩展元素
用例编号
编写规则
编号的作用
通过编号和测试项可以分配工作、分配模块,方便管理
用例可以覆盖需求,根据编号也可以建立和用户需求的追踪表,编号可以和需求建立追踪;
根据编号可以发现用例缺陷,在缺陷单中写出用例编号,13;通过编号找到测试用例方便做回归测试。编号可以和缺陷建立追踪;
测试完成后,测试报告可以依据编号统计,找到相应的数据。
编写规则
借鉴测试阶段,UI,IT,ST
借鉴产品或者项目的名称
不同的测试项给不同的编号
如果是几百条从001开始,几十条从01开始
操作步骤
操作:怎么操作
在每一步中都体现出是如何操作的
不清晰?
测试项(测试项目)
测试项就是模块
一级测试自相
二级测试子项
三级测试子项
输入数据
需求+数据设计
这个元素可有可无
用例评审
0 条评论
下一页