如何记录一个Bug
一个Bug所包括的内容
Bug包括的基本信息点 各信息点的含义
Bug的摘要 写清楚每一个Bug的主要信息,一般一两句话
Bug的具体描述
Bug的严重程度 致命问题、严重问题、一般性问题、建议问题
Bug的优先级 立即进行处理、紧急处理、正常速度处理、延后处理
Bug指派给 解决Bug的开发人员
Bug的状态 激活、已解决、关闭
必要的附件(图片或日志)
Bug其他信息点
Bug记录的正确范例
Bug摘要:
Bug的具体描述:
Bug的严重程度: Bug指派给
Bug的优先级: Bug的状态
附件:
备注:
利用测试工具追踪Bug
对测试人员提交的Bug进行集中管理、转发和维护。
测试管理工具简介
目前主流的Bug管理工具有很多,如Test Director、Quality Center、JIRA、禅道、Mantis以及公司自行开发的Bug管理攻击等。
对Bug起争议时的处理
(1)对事不对人,不能因为Bug而激化了双方的矛盾
(2)测试人员提交的Bug单一定要描述清楚,并需要由充足的依据和理由。
(3)Bug单写清楚还是不愿修改的话,进行沟通。
(4)沟通无果后,由测试经理召开Bug评审大会,共同定夺。
(5)对待问题坚持原则。
(6)测试人员应和开发人员保持密切沟通。
回归测试的策略
什么是回归测试?就是开发人员把Bug修复后之后,测试人员需要重新验证Bug是否修复好了,同时在新版本中进行测试以检测开发人员在修复代码过程中是否引进新的Bug,此过程就称为回归测试。
回归测试的基本流程
测试->发现100个Bug,存在严重问题,达不到上线标准->修复->回归测试->还有15个Bug没有修复好,还引入了25个新Bug,存在多个严重问题,达不到上线标准->修复->回归测试->还有2个Bug没有修复好,新引入了10个Bug,存在一个严重问题,达不到上线标准->修复->仅有2个Bug没有被修复,建议性问题,达到上线要求和标准。
回归测试的基本策略
(1)回归测试时执行全部的测试用例
一般情况下,当第一轮测试发现Bug数量过多的情况下,第二轮回归测试应该执行全部的测试用例。
(2)选择重要的功能点、常用的功能点、与Bug相关联的功能点进行回归测试。
(3)选择性执行关键功能点的测试用例
(4)仅测试出现Bug的功能点