测试计划
测试用例
测试用例的特性
1、有效性:测试用例的能够被使用,且被不同人员使用测试结果一致
2、可重复性:良好的测试用例具有重复使用的功能。(回归测试)
3、易组织性:好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)
4、清晰、简洁:好的测试用例描述清晰,每一步都应有相应的作用,有很强的的针对性,不应出现一些无用的操作步骤。
5、可维护性:由于软件开发过程中需求变更等原因的影响,常常对测试用例进行修改、增加、删除等,以便测试用符合相应测试要求。
1:测试用例包含什么类容
用例编号,所属模块,用例描述,前置条件,优先级,输入数据,操作步骤,预期结果,实际结果,测试人员,测试时间
2:测试用例的编写方法有哪些?
等价类划分,边界值,错误推测,因果图,场景法,正交表
应用的场景
等价类划分
多用于输入框:注册/登录
边界值(掌握上点和离点的取值)
多和等价类划分结合使用,有边界限制的:注册的密码长度,,
场景法
从基本流开始,再将基本流和备选流结合起来,可以确定用例场景
正交表
用于多个下拉框之间的组合,可以通过正交助手生成测试用例
错误推测
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误,有针对性地设计。只能作为一种补充
因果图
因果图法比较适合输条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出
3:测试用例的评审
包含:参与评审人员(需求人员,对应的开发人员,对应的测试人员,项目经理)
评审结束标准:在评审活动中会收集到用例的反馈信息,在此基础上进行用例更新,直到通过评审。


1. 测试计划
评审内容,评审的时间
4:测试计划
测试背景
测试目的
确定测试范围
制定测试策略(功能测试/业务测试..)
测试资源安排
测试时间安排
测试人员分配
风险评估
|
测试背景 |
测试目标 |
测试范围 |
测试输出文档 |
|
|
|
|
|
|
|
|
测试策略 |
测试规模工作量分析 |
测试进程 |
测试进度及时间安排 |
|
|
|
|
|
|
|
|
测试资源 |
人力,设备, |
风险管理 |
|

5:缺陷报告
所属产品,所属模块,当前指派(重要),bug类型,操作系统,重现步骤(重要),验证程度(重要),优先级(重要),附件等
6:测试报告
测试目标,测试的范围,测试环境,测试结果分析(多少轮测试,测试多少,失败多少,成功占比),遗留缺陷,测试结论(本次测试涉及xxx个功能点,发现xx个缺陷,其中,xx个已修复,xx个遗留。)测试过程完整有效,系统测试通过。
7:软件缺陷的种类划分
功能不正常:简单地说就是所应提供的功能,在使用上并不符合产品设计规格说明书中规定的要求,或是根本无法使用。
软件在使用上感觉不方便:只要是不知如何使用或难以使用的软件,在产品设计上一定是出了问题。所谓好用的软件,就是使用上尽量方便,使用户易于操作。
软件的结构未做良好规划:这里主要指软件是以自顶向下方式开发,还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件,在功能的规划及组织上比较完整,相反 以自底向上的组合式方法开发处的软件则功能较为分散,容易出现缺陷。
使用性能不佳:被测软件功能正常,但使用性能不佳,这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案,或使用了不恰当的算法导致的
边界错误:缓冲区溢出问题在这几年已成为网络攻击的常用方式,而这个缺陷就属于边界错误的一种。简单来说,程序本身无法处理超越边界所导致的错误。
计算错误:只要是计算机程序,就必定包括数学计算。软件之所以会出现计算错误,大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0
软件缺陷严重的属性
8:软件缺陷的严重程度
一般分为5个等级:
系统崩溃,严重,一般,次要,建议
按优先级分:高,中,低
1.1.1. Bug定级示例
|
1级,系统崩溃 |
|
2级,至关重要 2.数据丢失 |
|
3级,主要 2.功能实现逻辑覆盖不全面 |
|
4级,一般 |
|
5级,较小
4.复现率低于5%的闪退/崩溃和安全模式 |
|
|
|
6级,建议 |
1.1.1. 按照测试种类分:
逻辑功能类,性能类,界面类,易用性类,安装,兼容性类
1.1.2. 按照功能模块分:
注册,登录,购物车,分类,订单,个人信息
浙公网安备 33010602011771号