关于项目测试平缓期低效率的看法

个人认为项目测试过程中的测试效率总体趋势是随着项目进度的深入呈现先上升到达顶点，然后递减，再项目发布前达到最低点的规律。这个规律反映在活跃bug趋势图上尤其明显。测试过程进入稳定期后效率会非常低。主要表现为：

1.每天进行几遍几十遍主流程甚至核心流程的回归。

2.测试执行的用例数非常多，发现bug数非常少。

3.bug隐藏较深发现bug难度大。

4.bug的沟通交流的成本大。

5.开发修复bug进入迟滞期，一天每个人修复不了几个bug。

一般bug开闭数曲线呈现平缓期就开始进入效率低潮期。那么在这个阶段我们该做哪些措施提高我们的测试效率呢？我觉得可以从宏观和微观两个方面着手处理：

宏观上：

1. 多交叉测试：在执行完所有用例的前提下，我们测试同学可以频繁的进行交叉测试，尽可能的扫描到未涉及到的死角。
2. 测试手段的多样性：在平缓期采取探索性、随机测试等方法，甚至可以邀请部分同学来体验，当小白鼠，这个时期我们可以多重视用户体验性问题。
3. 风险检测：进入平缓期后再次检视下目前尚未关闭的风险问题，在功能稳定的同时及早的采取措施关闭风险，深度挖掘尚未发现的风险问题，防止风险触发引起的测试反复。
4. 测试计划实时性有效性：检查我们的测试计划是否已经匹配当前的测试过程，及时做出调整。

微观上：

1. 减少回归核心流程的次数，每天回归一遍基本就够了。
2. 深挖用例与功能，尽可能早的发现隐藏的功能，和未测试到的功能点。
3. 敦促开发调整修复bug策略优先修复教容易修复的bug。
4. bug描述到位，做到每个bug均可重现。
5. 提醒开发自测，1）这个阶段开发可能会发现很多我们发现不到的bug。2）开发修复bug完整性与正确性，防止牵连功能bug数反弹。

在项目测试过程中我们应该随时关注我们的测试效率，多快好省的完成测试工作。

注：我个人觉得测试执行过程中效率可以这样侠义量化定义：当天开闭bug数之和/当天执行的测试用例数。

VN:F [1.9.7_1111]