目录
一、问题场景
当测试时间被缩短时，原有的测试计划明显已经不能满足上线的时间节点，应该如何应对此种情况呢？
二、问题产生原因以及解决办法
1. 出现原因
测试工作一般处于整个项目流程的最后一环，因此较为被动。当测试阶段之前的环节延误（可能是需求变更频繁、研发完成时间晚于计划等等），最后留给测试的时间变短的情况经常发生。
2. 应对方法
- 改变测试方法，使用技术手段提升测试效率
注：此方法的前提是项目已存在稳定运行的测试脚本
例如，可以更早的运行自动化测试脚本在前期发现问题：新功能是否影响旧功能等等； 测试周期紧张的情况下，借助脚本可以替代原本计划手工执行的部分回归测试任务；也可以让技术能力比较强的测试同学参与code review发现变更点与风险点：针对变更点与风险点更好的划分测试投入。
- 加班赶工
考虑适当安排人员加班的情况下是否能完成原计划的测试工作，包含工作日的加班和周末的加班；
注：请合理安排加班强度，超负荷的工作可能反而会导致工作效率降低。同理，若安排加班，采取一些相应的激励方式可能更能增强大家的凝聚力与工作效率，例如申请项目奖金、加班费/调休、安排下午茶、吃饭聚餐等；
- 申请/协调更多的测试资源
想办法在数量和质量上争取测试资源，一个方式是增加其他测试人员，或者申请开发、产品人员加入执行测试，这要注意测试用例的分配。
另一个方式是申请调配对该系统/模块最熟悉最有经验的测试人员加入项目，有可能原先该同学被安排在同时进行的其他项目中，如果遇到紧急情况可以尝试向上级申请，将有经验的同学调过来。
注：不能盲目增加测试资源，加入对系统不熟悉的人员、新人、临时聘请的外包人员反而拖慢原有的测试进度。所以平时分配需求时要注意，一个模块或者系统最好有两个以上熟悉的人，做好人员储备。
- 缩减测试范围
如果通过加班、增加资源的方式无法确保在既定时间完成既定任务，则考虑缩减测试范围。
这里不是指部分模块不进行测试直接投产，而是由项目经理评估优先级较低的功能模块，和业务沟通是否可以放到下一版本投产，优先确保重要的功能稳定上线。
比如针对电商系统，可以先将积分功能关闭，后期安排时间对积分功能进行充分测试后再投产。这要求设计时注意各功能的配置，可以实现自由开关。
- 明确测试用例优先级，进行取舍
如果测试时间紧张，则优先执行优先级高的测试用例，将特殊场景和异常场景遗留后期再安排时间执行，这就要求设计测试用例时注意对测试用例分层，并且在测试报告中要说明未执行的用例。
- 加强质量和进度把控和跟进
越是测试时间紧张，负责人越是要加强跟进和把控，及时监控测试质量和效率，规避和纠正问题，避免出现严重偏差。
- 记录相关风险和建议
在测试报告中明确测试范围、未上线功能、未覆盖的测试用例以及存在的风险和应对措施。如果有未执行的测试用例，需要后续安排测试时间和资源投入处理。
- 做好测试总结
最后的总结容易被遗忘。针对测试周期压缩的应对，有哪些做的好的和做的不好的地方，组内可及时总结，吸取经验教训，之后遇到类似情况才可以从容应对。
- 前期的把控
大家都知道测试不应该在系统测试阶段介入，在需求阶段、设计阶段、编码阶段等，测试同学要发挥测试的优势，提前发现可能存在的缺陷，规避相关问题和风险，提测质量上去了，测试过程才能高效。否则项目一团糟，代码质量一团糟，即使测试阶段投入再多的人力和资源，也无事于补。
三、总结
测试同学遇到测试周期压缩的情况时，要明确优先级。不仅是功能的优先顺序，还有用例的优先顺序，如果子弹少，就更要精准地打，集中主要精力处理重要任务，同时还要克服焦虑。
如何应对测试周期压缩也是如何平衡好时间、成本、范围、质量的关系，和在项目各阶段考虑投入产出比是一致的。
其次，从侧面可以看出，平时做好基础工作才能从容应对特殊情况，比如系统设计、单元测试、测试设计、自动化测试、人员储备等，大家总感觉项目紧张，这些不重要的工作可以放一放，规范可以缓一缓，殊不知其实是降低了交付效率，同时也让项目陷入一个恶性循环。
扫一扫
692
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
