缺陷定义，处理缺陷的流程

错误猜测法:

根据以往的测试经验推断开发
可能出现的一些问题。

正交实验法

拆分测试点（不写测试用例情况），典型数据测试

执行测试用例

根据已有的测试用例，按照里面的步骤一步一步的执行，
查看预期结果与实际结果是否一致。

将BUG汇聚成一张表（缺陷报告）

！测试执行过程注意事项

搭建测试环境事项
注意前提条件和特殊说明
测试用例要逐一全部执行
不要忽视任何偶然现象
加强测试过程记录(备注comments)
详细对比预期与实际的不一致
提交缺陷时与开发的关系处理
提交一份优秀的问题报告单
及时更新测试用例

1： 功能测试怎么测试
2:如果接口依赖性,要怎么解决
3:添加一个学生,如何验证是否添加成功
4: fillder抓包，抓取的数据有哪些
5: http和https的区别
6:禅道提交bug要提交哪些内容
7: linux常用的命令
8: 自动化测试是如何测试的
9: 数据库的查询语句是什么？
10：如果发现问题，前端和后端都可以解决，优先选择哪一种
11： 文件上传如何测试
12： 常用的用例设计方法
13: 上一家公司离职原因
14.是否接受加班和短期出差

中软国际

缺陷的定义

软件未实现需求和规格要求的功能
软件出现了需求和规格指明不该出现的错误
软件实现了需求和规格未提及的功能
软件未实现需求和规格未明确提及但应该实现的内容
软件难以理解,不易使用,运行缓慢,或者最终用户(估计会)认为不好。
测试用例执行中发现的与预期结果不符的现象
缺陷又名为BUG（臭虫）

缺陷的分布特征

集结（二八定理）
缺陷往往喜欢扎堆,一个模块已经发现的缺陷比别的模块多,通常不
是代表这个模块已经把缺陷暴露完了,而是意味着这个模块还存在有同
样多的缺陷尚未被发现。这就是著名的二八定理: 80%的缺陷出现在
20%的模块。

缺陷的抗药性

测试进行得越多,新缺陷就越难被发现
因为之前一直使用同样的测试思路，同样的一套测试用例，没
有新的突破。
某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发

并非所有的缺陷都需要修复

有一些原因，使得有些缺陷我们不修复
没有足够的时间
不算真正的软件缺陷
修复的风险太大
不值得修复

缺陷的处理流程

当一个缺陷被发现了之后：
1.测试工程师填写《缺陷跟踪单》,提交测试经理审核
2,测试经理作出初步判断,将问题单转项目经理审核
3,项目经理确认问题单,转给开发人员定位问题
4,开发人员定位错误后修复缺陷转给项目经理确认
5,项目经理确认完转给转给测试经理确认并组织测试
6,测试人员对该修复进行验证,确认是否正确修复,确认是否有引发
新问题,是否影响了原有正常的功能

！图记

禅道的示例

【备注】:该账号密码已经完成,能够正常登录患者端。

测试用例跟缺陷和一一对应

Excel缺陷报告单：

！缺陷生命周期一状态

BUG报告---附带上所有你认为有价值的信息

一个好的缺陷单,是你提交之后就再也没人联系你,然后过了一段时间已经被完美地修复,转回到你手上进行验证测试这样的一个单子

要做到这样,你应该提供足够的信息,使得开发人员既能够明确如何重现故障现象,又有足够的信息定位到问题的根源

除了书写良好的重现步骤,你还可以考虑附上打印日志,抓图,网络抓包，等等。

合理地利用各种手段强调关键信息

假如你的缺陷跟踪单支持字体颜色
关键词强调
特殊标记

测试的报告(看文档)

缺陷的写作练习
1·当运行WORD程序时,如果输入字符SHUTDOWN,会导致程序自动关闭
2.QQ运行24小时左右,会占用大量内存,并有一定概率出现程序崩溃
3·某网络购物网站的密码修改功能的入口设计不合理,本应该在用户账户管理界
面下，但是却跑到系统设置界面下
4·某型号手机的方向键设计不合理,想要按“下”方向键时,经常误触到“2”
键。
5.HH08型号的无线Modem,在每天23:59分到0:00之间,无线网络会断开一分钟
无法响应