速成测试接口达人测试流程.pptVIP

重开缺陷的定义 Jira中重开缺陷的标识 重开缺陷标识 测试人员在回归测试中，对于要重开的缺陷，会增加如下注释：$$reopenN-开发工程师邮箱前缀-tM(N为该bug在该轮回归测试中被重开的次数，M代表第几轮测试，如t2:代表第二轮) 例如：$$reopen1-fangjie-t3 含义：方杰修正的缺陷在第3轮中被重开了一次 关闭缺陷标识 测试人员在回归测试中，对于验证无误的缺陷，会增加如下注释： $$reviewN-开发工程师邮箱前缀-tM(N为该bug在该轮回归测试中被验证的次数，M代表第几轮测试，如t1:代表第一轮) 例如：$$review3-fangjie-t1 含义：方杰修正的缺陷在第1轮中被验证了3次 请回答： $$reopen2-fangjie-t2是什么含义？ 重开缺陷的定义 重开率的计算公式 开发工程师重开率 个人被重开Bug总数/个人被验证Bug总数 每轮重开率 本轮重开缺陷/本轮验证的总缺陷数 项目重开率 所有测试轮次中总的重开缺陷/总验证缺陷数 产品线重开率 所有项目中总的重开缺陷数/所有项目总验证缺陷数 重开缺陷的定义 重开缺陷的关注点 以下缺陷，不会计入重开缺陷内 执行了重开操作但是未加注释$$reopenN-开发工程师邮箱前缀-tN的缺陷，不计入重开缺陷内 在验证缺陷A时，发现存在由于修改该缺陷引发的新缺陷，此时会关闭A缺陷，新增缺陷B，不会出现重开缺陷A的情况 关注： 对于出现争议的重开记录，需开发提交给测试主管审核，确认后再加重开标识，这一点要求开发工程师及项目负责人及时关注项目中加有$$reopenN-开发工程师邮箱前缀-tN的缺陷 兼容性缺陷，必须在缺陷中标注浏览器版本，开发需按照标注的浏览器版本有针对性的修改，如果测试工程师又在其他浏览器中出现相同问题，会新建提案，不会在原已经修改正确的提案中重开 缺陷等级的定义 按照测试类型分类 B/S结构(Web)测试的缺陷等级定义 C/S结构(Client)测试的缺陷等级定义 服务器及接口测试的缺陷等级定义 缺陷等级分类 A、致命 B、严重 C、较严重 D、一般性问题主要为：界面类、容错类缺陷 E、易用性和建议类缺陷 备注：具体内容详见所有类型测试的缺陷等级定义.docx 线上遗漏缺陷表的填写方法 线上遗漏缺陷表： 遗漏缺陷记录表.xlsx 填写完整后请发送给给产品线责任测试主管 测试项目管理案例分析 一个产品人员的困惑： 10月初期领导安排了一个项目，周期一个月的时间，从11月1日开始到12月1日上线。接到任务后，终于完成了需求文档的编写，提交到开发那里，被告知需求编写不详细，经过了多次会议的沟通，开发工程师们终于明白了要做成什么样子，询问什么时候可以开发完成，被告知11月26日。我的工作终于可以告一段落了，开始等待开发完成的时间点26日… 26日，开发提交了可测试的版本，我给测试主管打电话，被告知没有测试资源安排，需要等到12月1日，郁闷…与领导沟通后，终于项目可以拖延一周的时间，于是找到测试主管，告知这个好消息，产品可以12月8日上线，测试主管却反馈说一周的时间无法完成测试，测试用例的编写时间需要3个工作日，测试执行一轮需要2个工作日，如果按照常规的项目来执行，则需要3+2+0.5+3+0.5+1=10个工作日…延期开始 测试项目管理案例分析 12月1日，测试人员通知我参与需求评审会议，会议上发现确实有些地方设计的不够全面，于是虚心接受，更改了需求，并提交给了测试部门，测试部门得到需求后开始编写用例，终于用了3个工作日编写完成，但完成时间点却是12月6日下班前，而不是12月3日下班前，困惑中，为什么会拖延了1个工作日？ 因为上线时间紧迫，测试部门发给我和开发编写完成的测试用例后，通知我们用邮件的方式反馈用例评审结果。为了节约时间，测试部门直接进入了测试执行阶段，问题出现了，冒烟测试没有通过…真是雪上加霜，测试刚刚开始就收到了风险预警邮件…测试被迫暂停 为了争取测试快速启动，开发说需要1.5个工作日完成缺陷修复，我苦口婆心的与开发沟通，压缩成0.5个工作日完成影响测试执行的缺陷修复，并及时通知了测试方。测试方在0.5个工作日后反馈给我，告知缺陷未被修改完成，无法进入测试…为什么受伤的总是我 测试项目管理案例分析 开发又花费了1个工作日的时间修改缺陷，这次冒烟测试终于通过了，但是在执行过程中，太多缺陷被开发建议放弃处理，问询原因：你的需求变更了，为什么测试还按照原始需求进行测试？报告了很多缺陷？无奈下，我一一过缺陷，把因为需求变更的缺陷均修改为放弃处理，并通知测试，这部分有需求变更，测试人员反馈，需要把必威体育精装版需求发给他们，以便他们更正测试用例，更正测试用例的时间需要0.5个工作日…可是我根本没有时间给你们啊，老板也