测试用例定义
测试用例又叫 test case,是为某个特殊目标而编制的一组测试输入,执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定的需求
测试用例的特征
有效性
测试用例能够被使用,且被不同的人员使用测试结果一致
可复用性
良好的测试用例具有重复使用的功能,如:回归测试
易组织性
好的测试用例会分门别类的提供给测试人员参考和使用
可评估性 / 可管理性
从测试管理的角度,测试用例的通过率和软件缺陷的数目是软件质量好坏的测试标准
测试用例的要素
测试用例的编号
一般由数字和字符组成的字符串,用例编号具有唯一性、容易识别
测试项目 / 模块
测试的项目属于哪个项目 或者 被测试的需求、被测试的模块、被测试的单元等等
预置条件
执行当前测试用例需要的前置条件,如果条件不满足,则后面的测试步骤不能进行或者达不到预期的结果
测试输入
测试用例执行过程中需要加工的外部信息,根据测试用例的具体条件又手工输入、数据库等
预期输出
测试用例的预期输出结果包含返回值内容,界面响应结果等
操作步骤
执行当前测试用例需要经过的操作步骤,需要明确的给出一个步骤的描述,测试用例执行人员可以根据该步骤完成测试用例的执行
测试用例标题
对测试用例的描述,用概括的语音描述测试用例的测试点
级别
测试用例的重要程度的区分
高级:保证系统的基本功能、核心业务、重要特性、实际使用频率较高的
中级:介于高级和低级之间
低级:使用频率不是很高,对业务功能影响不大的模块
其他要素
用例的设计者
用例设计日期
对应的开发人员
测试结果
测试类型
测试用例的设计原则
明确性
测试人员要避免测试用例存在含糊因素
代表性
尽量将具有相似功能的测试用例抽象合并,功能相似的也合并
简洁性
可读性良好,测试过程目的明确,测试结果唯一。不要加修饰
测试用例的设计方法
https://www.cnblogs.com/laowenBlog/p/16550148.html
测试用例的力度
简单
仅仅是测试的纲要,可能只包含测试的内容。
简答的测试用例其实并没有进行设计,而仅仅是记录
只是提醒测试人员主要功能有哪些
复杂
包含具体的输入项、每一个步骤、期待的结果
中庸
过于简单,会导致测试有遗漏,而且根据测试执行人员的水平不同导致偏差较大
过于复杂,会导致效率太低,维护成本太高,限制测试人员的思维
一般在工作中介于两者之间
总结
本质
理解需求、反映需求、忠于需求
需求会变化,测试用例也应该是活的,变化的
原则
根据程序的重要性和发生故障带来的损失,来确定测试等级和测试重点
认真选择测试策略,用尽可能少的测试用例发现尽可能多的错误
方法选择
先关注主要功能的业务流程,业务逻辑是否正确实现,考虑场景法
需要输入数据的地方,考虑等价类划分法
在任何情况下,都是用边界值法
如果程序中包含输入条件的组合情况,则考虑选择因果图和判定表法
对于配置类软件,需要考虑参数的组合清理,则考虑使用正交排序列法
对找程序逻辑,如果发现没有达到要求的覆盖标准,则适当的补充更多的测试用例
采用错误推断法,追加其他测试用例
评审
同行评审
个体和交互比过程和工具更有价值
由测试小组内部进行评审,达到思想的碰撞,通过探讨,协作完成测试用例的设计
用户评审
顾客的协作比合同谈判更有价值
声明
本人博客的所有东西,部分源于网络书籍和视频,其他的是个人的理解感悟,经过自己整理撰写成博客。
本人博客均只用于个人学习、复习,不作为商业用途,如有侵权,请联系我修改或删除。
联系邮箱:itlaowen@163.com