小白学测试入门之测试概论2

• 知识点回顾

 

• 测试用例的写作
•  
• 什么是测试用例（Test Case）

1. 测试用例：是测试工程师进行测试执行工作的指导性文档。（告诉测试执行工程师，怎么去测试，前提准备，具体的步骤是什么，完成步骤之后的结果应该如何）
2.  

• 为什么编写测试用例？

1. 防止测试的遗漏；
2. 防止重复的测试；
3. 能够发现测试依据中存在的一些缺陷和漏洞；
4. 能够复用；
5. 能够更合理的分配测试工作任务，估算测试工作量；
6. 能够根据测试用例进行各种数据分析，需求的规模大小；需求的用例密度；

• 如何编写测试用例？

1. 思路（如何：设计----测试分析设计方法）
2. 格式（具体的内容：格式）

要素	说明与作用	举例
测试用例编号（Test ID）	唯一性、可识别性；计算工作量。 系统测试（ST）用例编号：产品（项目）--测试阶段--测试特性（功能、性能）--测试模块--测试子模块--序列号 集成测试（IT）用例编号：产品（项目）--测试阶段--接口名--序列号； 单元测试（UT）用例编号：产品（项目）--测试函数（类）--序号	微信朋友圈系统测试： Wechat--ST--Func--Friends--Share-01 微信支付的集成测试： Wechat--IT--Pay--Called--01 微信登录的单元测试： Wechat--UT--Log--01
测试项（Test Subject）	分类的作用，便于测试执行的时候创建测试用例执行集。（多个层次） 需求名；接口名；函数（类）名	系统功能测试； 集成支付接口测试 登录函数测试
测试用例标题（Test Title（name））	说明测试用例的目的，方便区分每一个对象。 尽量做到唯一（测试项+测试标题）
重要级别（Test Level）	在时间、资源、成本受到限制的时候能够更合理的对测试用例进行一个取舍。 高中低；1,2,3 高级别：基本功能或者核心业务功能、使用频率比较高； 中级别：备选的非主流、非核心的业务 低级别：使用频率不高，对系统业务影响很小的	微信 高：通信；朋友圈共享 中：支付；卡包 低：漂流瓶；看一看
预置条件	用例执行时的一些依赖（环境） 如果所有的用例都需要同样的依赖 可选的（特殊的情况）	手机真机弱网发送微信信息 预置条件：弱网（。。。。。） 手机5G网络 预置条件：5G网络
输入	执行操作步骤时的数据信息；必须的； 要求一定要具体量化的信息，不可以总结输入信息（X：几个；一些；随便几下）	具体是哪些字符；数量是几个；
操作步骤	执行的动作，用动词去表示（输入；点击；鼠标左键单击；选择；勾选鼠标左键双击；鼠标右键单击）； 不能存在分支（如果你双击鼠标左键，或者你单击鼠标右键：X）
预期结果	根绝测试依据文档确定的执行完步骤之后应有的表现；尽量用一些描述状态（登录成功；正确显示）的词汇。 和输入的要求是一致的（具体的信息；数据；量；顺序）	在某银行系统查询糖糖的银行卡信息 预期结果：糖糖的银行卡信息显示正确（X） 预期结果： 姓名    性别   卡号        余额 糖糖     女    62****4229  5000.00

 

1. 案例

QQ登录

测试用例编号	QQ-ST-Func-log-01
测试项	QQ登录功能
测试用例标题	已存在的QQ账号正确的密码的登录
重要级别	高
预置条件	QQ账号是已存在的
输入	参数1:1390059189；参数2:12345678；参数3：空；参数4：空
操作步骤	运行PC端QQ软件； 在账号输入框中输入参数1； 在密码框中输入参数2； 在自动登录勾选框中输入参数3； 在记住密码勾选框中输入参数4； 点击登录按钮
预期结果	登录成功；显示头像；好友列表

 

• 缺陷报告与缺陷管理

1. 什么是缺陷？

与预期有偏差不一致（问题，故障，bug）

1. 什么是缺陷报告？

对发现的缺陷进行描述形成一个文档记录

1. 为什么编写缺陷报告？

1. 便于跟踪和记录；
2. 所有人员对缺陷的描述理解是一致的；
3. 对缺陷进行统计分析，知道问题的所在，问题引起的原因，问题的分布的区域，可以做预防。

1. 如何编写缺陷报告？（缺陷报告属性）

属性	说明
摘要（Summary）	用最简洁的语言直接说明问题的所在（实际结果）
缺陷提交人（发现人）	提交缺陷和发现缺陷的人员（任何人）
缺陷发现时间	主要是和缺陷的优先级有关系
缺陷的严重程度	从用户的角度（一旦发生问题对软件使用造成的影响有多大） 致命的（Critical）：基本功能无法用；数据的丢失；程序崩溃； 高（High）：主要功能不能用，有替代的方式（通讯录无法使用可以通过搜寻号码，通话历史）； 中：不常用；性能低 低：文字错误；表述不精确
缺陷的优先级	从开发人员的角度（一旦缺陷发生，缺陷修复的应对时间）； 非常紧急：马上修复（热修复）； 紧急：当天修复（下一个版本修复） 中：三天； 低：一周；。。。。
测试版本	在哪一个版本测试的
测试阶段	系统测试；集成测试；单元测试
开发阶段	需求；设计；编码
操作系统
浏览器
手机型号
重现	能否重现（一个缺陷至少重现三次）
重现步骤	描述缺陷经历了哪些操作可以复现
附件	截图；日志；视频（更清晰的说明缺陷）
状态	不同的生命周期，状态不同由不同的人去处理和跟踪
需求	可以分析需求的缺陷问题
用例	可以回归测试准确定位哪条用例需要回归

 

 

1. 缺陷跟踪流程（缺陷管理流程）