大家经常会遇到这样的问题
在项目中，按照计划安排，开发未在指定的时间内提交测试，占用了测试的时间，那么在这种情况下，如何做好质量控制?
简单解释一下，就是按照计划，开发应该在10天内完成开发提测，结果由于各种问题，开发的周期变成了13天，比预期晚了3天提测，一般来说如果项目不延期的话，只能通过减少测试的时间来赶上进度。但如果测试周期变短，测试可能会不充分，从而导致项目质量出现问题，出现线上问题。
怎么解决这个问题呢？
解决这个问题之前我们先问自己另一个问题
开发周期中，测试人员在做什么？
一般来说当开发人员在进行开发的时候，测试人员大部分时间都在写测试用例，准备测试数据，做一些测试策略和计划的研究。这段时间内由于开发提交的代码不能跑通E2E测试，也就是大家所说的功能测试，所以测试同学很难在这个周期开展测试。
但测试有很多种类，功能测试做不了，我们是不是可以做其他类型的测试？
答案还是值得研究的，不能做全端的功能测试，我们其实还是可以做接口测试和单元测试。如果被测系统有独立的接口，我们可以先测这些接口的逻辑，接口开发往往比最终的功能完成要快，所以可以通过接口测试提前开始测试。
再看单元测试，按道理来说，只要有代码就可以做代码测试，但是一般的开发可能做不了单元测试，这是技能的缺失，同样也是项目周期和管理风格的共同决定。开发周期中，单元测试是可以做起来的，当然这很难，但是收益却很大。
回到正题，我们可以通过提前开始测试和开展更多类型测试的方式来缓解测试周期紧张的问题。总而言之，我们的策略是把开发的周期变成测试周期，也就是所谓的测试前移。
我们再往深处想一下，有没有一种手段可以在开发周期中自动化的做各种类型的测试呢？
持续集成可以闪亮登场
假设我们有自动化的接口功能测试用例和一些稳定的UI功能测试用例，那么开发周期中我们可以反复的跑这些用例，从而保证现有的功能不要因为新功能的加入而变得不可用。这种提前的反复回归，也可以非常有效的缓解测试时间不足的问题。
总而言之
- 测试前移：更多类型的测试
- 测试自动化： 减少人工投入
- 持续集成：每天每时每刻都在做测试