大家好，今天我们一起来聊聊，当我们在工作中尤其是快速迭代版本中测试版本的时间被压缩的很短，甚至不够完成用例执行时怎么去做好质量控制呢？
在我们的日常生活中导致软件测试时间不够的原因有很多，那么在这些不确定的人为因素中如何去做好呢？
1、需求层面：需求不明确模糊不清楚的、需求来回变动的会导致测试时间不够。
解决方案：在迭代版本开始前的需求澄清阶段就需要对本次迭代版本需求明确下来，对于需求模糊的需要会议澄清并书面给到产品、设计、开发、测试。在测试介入冒烟测试阶段，严控需求变更，对于不紧急、变动需求范围大的应予以拒绝加入本次迭代版本发布中，从测试的范围点来控制需求的不确定性影响到测试的时间。
2、用户层面：需要分析本次迭代上线的需求中哪种功能对用户最明显?，那哪些功能对运营及用户最为有用的？哪些功能是不是非常必要的？
解决方案：从测试策略方面来解决这个问题，优先是保证重点业务流程的功能正确、正常业务流程测试正常，对于那些非必要的或者功能关系不大的可以暂时的搁置一下避免花费更多的时间从而影响到整体主流程的测试进度， 从而保证测试版本的质量时间。
3、开发层面：开发需要评估本次迭代需求有哪些重点业务的改动、改动开发所需要的时间是否充分？开发是否有对自己开发的版本进行了自测试？在版本测试计划中开发是否能按照计划时间移交版本测试？
解决方案：在测试接到移测的版本时，需要开发提供本次迭代改动的点，影响的范围，测试针对改动大、影响的范围展开在重点测试。在移交测试前提供冒烟测试用例给开发进行自测试， 尤其是在计划时间范围内及时的催办开发按时移交版本测试，如果说开发拖延移交测试时间那么就需要及时的上报测试管理或开发管理风险。
4、测试层面：当版本移交到测试的时候，人力资源的变动、移测时间不准时等，测试时间发现不够了？怎么办？需要怎么做好版本质量？
解决方案：测试人力不足及人员变动影响到了测试进度，应及时添补人力资源及协调加班时间来弥补在人力安排这一块的不足，在人力有限的情况下，那么就需要对本次迭代需求中那些模块代码改动较大、影响范围较大的地方进行重点充分的测试，在用例执行优先执行优先级高的用例，筛选出重点用例执行，从影响范围、用户角度出发来保证迭代版本的最基本、最核心流程业务功能正常。
另外一个就是普遍大多数公司的 最笨重的方案，加班 加班 加班，996这样的模式解决测试时间不够的问题不是最有效的，也是最耗成本的一个方案，作为测试工程师应该需要去推动解决这个最不值得、最笨重的方式。
