测试人员发现并提交缺陷,由开发人员进行处理。但是开发人员认为不是缺陷,则将该缺陷的状态置
为 Reject 状态并提交回测试人员。测试人员如果认为确实误报了缺陷,则直接关闭(Closed),如果经
过测试、开发沟通认为是 bug,则测试人员重新打开(Reopen)让开发人员继续修改,开发人员修复这
个缺陷置为 Fixed,提交给到测试人员进行回归测试,直到回归测试通过为止。
3.开发认为重复缺陷的处理
测试人员发现并提交缺陷,由开发人员进行处理。但是开发人员认为是重复缺陷,则将该缺陷状态置
为重复缺陷,作为测试人员一定要确认该缺陷是否确实有人处理(获取到重复的缺陷 ID),如果确实是
同一个缺陷,则将重复的缺陷直接关闭。如果不是同一个缺陷,则重新打开该缺陷,继续跟踪。
4.延迟缺陷的处理
测试人员发现并提交缺陷,由开发人员进行处理。但是因为项目和时间等因素,某些缺陷无法在项目
周期内完成,则需要进行延迟处理(备注:延迟处理的缺陷本身被确定为有效缺陷),对于延迟的缺陷需
要经过开发、测试、项目经理、客户代表共同认可方可延迟。对于延迟的缺陷,置状态为 Delay(测试人
员翻转该状态)到了下一个版本,测试人员就应该把所有 Delay 状态的缺陷重新置为 Reopen 状态,让
开发人员继续修复。
随机缺陷怎么测?
1. 先提交到缺陷管理库
2. 对第一次出现的缺陷要截图,尽量回想发现问题的步骤,进行步骤重现。
3. 喊开发人员先开启相关模块的日志,下次出现的时候有日志可查
4. 再次出现随机缺陷,保留现场,喊开发人员来看
5. 实在无法重现,在严重性也很低的时候,可以暂不处理,等到再次遇到该缺陷时修复。
版本上线前,Bug 的状态
版本关闭或延期解决的状态。后者留待下一个版本再测,打开和新建状态不存在
开发人员修复缺陷后,如何保证不影响其他功能
参考答案:
Bug 的修复以及新功能的添加都有可能对版本造成一些影响,为了避免,在新版本发布以后,首先
会对新版本做一个基础的流程测试也叫做冒烟测试,如果测试基本流程都顺利通过没有任何问题,那么测
试人员可以继续进行详细的测试,否则就将冒烟测试中出现 的问题以及问题有可能出现的原因反馈给开
发人员,由开发人员修正后再次发版,进行测试。这是一个迭代的过程。
我现在有个程序,发现在 Windows 上运行得很慢,怎么判别是程序存在问题
还是软硬件系统存在问题?
参考答案:
1、检查系统是否有中毒的特征;
2、检查软件/硬件的配置是否符合软件的推荐标准;
3、确认当前的系统是否是独立,即没有对外提供什么消耗 CPU 资源的服务;
第 8 页 / 共 39 页