终于开始写测试理论了。为什么前面写了那么多貌似与测试人员不相关的学习分享呢，因为我想做的是一个暂时不被时代淘汰的测试，一个懂代码的测试，一个薪资较多的测试，一个天花板较高的测试。

一、缺陷报告的组成

软件缺陷(Defect)，常常又被叫做Bug，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

缺陷编号（Defect ID）
提交bug的顺序，在一个项目中会统一编号；
缺陷标题（Summary）
简明扼要描述bug；
缺陷的发现者（Detected By）
一般是自己；
发现缺陷的日期（Detected on date）
一般是当天；
缺陷所述的模块（Subject）
在测试哪个功能模块时发现bug；
开发经理会根据bug的模块指派由谁解决该bug；
发现缺陷的版本（Detected in release）
在测试哪个版本时发现的bug；
指派给谁处理（Assingned to）
测试人员指派给开发经理，开发经理根据bug所在模块指派给具体的开发人员；
缺陷的状态（Status）
描述此时bug所处的状态，实际工作中，根据状态进行工作单流转。
（1）测试人员发现bug，提交bug给开发经理，把缺陷状态写成new（新提交的bug）；
（2）开发经理对bug进行验证，如果是bug，把缺陷状态改为open（新打开的bug，开发组承认的bug），开发经理会把bug指派给开发工程师进行修改；如果不是bug，就把缺陷状态改为rejected（开发组拒绝的bug）。
（3）开发人员看到指派给自己的bug以后，进行代码修改，修改完后，把缺陷状态给为fixed（已经修复的bug，待返测的bug）
（4）测试人员对修改完的bug进行返测，返测成功，状态改为closed（关闭的bug，返测成功的bug），如果返测不成功，把缺陷状态改为reopen（重新打开的bug,返测失败的bug）,需要重新提交给开发人员修改。
缺陷的处理流程或者叫缺陷的生命周期：new-open-fixed-closed；

缺陷管理流程.png

缺陷的严重程度（Severity）
该bug对用户造成的影响有多大。
（1）Urgent 死机重启等致命bug
（2）Veryhigh 非常严重的bug
（3）High 严重的bug
（4）Medium 中等程度的bug
（5）Low 小的bug
缺陷的优先程度（Priority）
测试人员希望程序员什么时间哪个版本修改该bug
（1）Urgent 立即修改否则影响开发进度
（2）Veryhigh 本版本修改
（3）High 下个版本修改
（4）Medium 发布前修改
（5）Low 允许发布中存在的bug
优先级考虑的因素：
A、严重程度：一般严重程度越高，优先级越高
B、缺陷影响的范围：一般影响范围越广，优先级越高
C、开发组的任务压力：压力越小，优先级越高
D、解决缺陷的成本（时间）：成本越低，优先级越高
缺陷描述（Description）
把发现缺陷的步骤，使用的数据等内容进行记录。