在送测阶段测试时间未结束时,开发询问测试是否能提前更新测试环境,测试应该如何分析和决策?
首先,我们可以通过6w1h去分析这个问题
6w1h | 含义 |
---|---|
who | 提出这个问题的是开发 |
why | 为什么会提出这样一个问题? |
waht | 什么情况下会需要提出这样一个问题? |
where | 需要更新的是目前测试环境 |
when | 送测阶段,即测试正在测试中 |
whom | 开发向测试提出询问 |
how | 测试要综合各种维度的衡量,才去回答开发这个问题 |
感觉这两个问题差不多,所以就放一起说了
测试期间发现某些严重问题:譬如应用崩溃,某个功能一直报错,影响测试主流程的bug;需要及时更新测试环境,避免影响测试进度【测试主导】
版本紧急:需要压缩测试时间,提前结束送测【开发or产品主导】
被测应用需要对接内部第三方应用:在当前送测阶段(如:A1)没有送测第三方应用功能,测试期间第三方应用已上测试环境,开发在被测应用测试环境对接第三方应用时无法顺利完成,出现一系列问题,考虑到会影响下一轮送测(如:A2)前需要验收第三方应用的功能,还有下一轮送测时间【开发主导】
被测应用需要对接外部第三方应用:被测应用对接的第三方应用的主要功能点出现Bug,在送测阶段(如:A1)第三方应用改好Bug并已经上线了;因为是修改的是主功能点,为了不影响发布,开发可能会需要提前在测试环境联调这个功能点【开发被动&第三方主导】
大项 | 小项 |
---|---|
测试进度 | 送测功能是否已完成测试? 测试用例是否已执行完成? 还剩下哪些未执行? |
影响范围 | 下一个送测阶段的测试内容 会不会影响当前测试? 会压缩当前送测阶段多少测试时间? 下一个送测阶段的测试时间是否有增加? 更新之后多久能让我们介入测试? |
紧急程度 | 不及时更新会怎么样? 不更新会影响发布时间吗? 待更新功能的重要性 |
沟通相关 | 及时跟同组测试沟通,一起衡量和决定是否可以让开发更新环境 |
影响范围
紧急程度
沟通相关 及时跟同组测试沟通,一起衡量和决定是否可以让开发更新环境
1、测试超过预定时间
2、执行完了所有用例没有发现新的bug
3、单位时间内查出的bug数低于预定值
4、查出一定预定数量的bug