测试用例的写作与规范
2024-10-31 14:33:05 0 举报AI智能生成
测试用例的写作与规范是软件测试领域的重要组成部分。编写测试用例时，需要关注功能性、性能性、兼容性、安全性和易用性等方面。测试用例应明确测试用例编号、测试项目、测试步骤、预期结果和实际结果等关键信息。同时，测试用例需要保证其可复用性、可维护性和可扩展性。一个优秀的测试用例应具备简洁、清晰、无歧义等特点，以便于测试人员理解和执行。遵循测试用例的写作与规范，可以有效提高软件测试的效率和质量。
作者其他创作
大纲/内容
企业现状
具备测试用例编写能力
公司研发流程不规范
没有用例，直接测试
需要用例，但是没有相关文档，不方便编写用例
后期接入项目团队，需要在短时间内上线
上线之后，遇到的紧急的用户问题，需要短时间修复
解决方案
不推荐不写测试用例，因为有弊端，而且测试用例就是拿来指导测试执行的
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 条评论
下一页
为你推荐
查看更多
