提到时间，大多测试人员内心是复杂的，精神是崩溃的。在测试工作中，测试时间是测试人员最为苦恼的事情，因为往往测试团队的时间是最难控制的，也是最容易被挤压的。测试人员经常被告知某某时间是生死成败之期；因为某某原因，开发转测试时间将延期，计划不变，这意味着测试时间被压缩；在测试过程中，突然又提出了新需求，需要赶在发布截止时间内加上并测试通过；等等。
测试应该怎么“抢”时间呢？
这里的“抢”肯定不是找开发经理、项目经理打一架，然后来决定各自的时间，相信没人会这样做。（如果你认为管用，可以试试，后果自负^_^）我们应该充分利用技术、管理手段来延展测试时间。目前常用的手段有：
- 通过Checklist和思维导图，快速设计出用例；
- 引入接口联调和集成功能测试；
- 对基本功能，接口的测试自动化。
然而，我们在学习软件测试之初，有提到“单元测试能发现软件中80%乃至更多bug”的单元测试，基本都交给开发去做了。然而，开发因为时间截止日期，或者自身角度原因，并没有做好单元测试。不做单元测试也不是少有的现象。
现在国外大佬，或者国内一些著名软件公司因为时间、质量等原因，又提出了：“让单元测试加入测试团队”的强烈呼声。
单元测试早于接口联调和集成功能测试，这也符合“软件测试应该尽早介入测试”的基本原则。更有之，单元测试是测试驱动开发的主要手段之一。所以，不管从软件质量的保证还是从测试时间的延展，让单元测试进入测试团队都是势必可行的。
到这里，可能测试的小伙伴们又担心了，如果测试人员要求做单元测试，那不是和程序员一样了？
我想说：是的，如果做到这步，那测试员确实已经具备了开发能力。测试开发的岗位也不是什么新的东西。当然，我认为测试开发也仅仅是测试团队的一部分，更多测试工作还得交给黑盒测试人员去做。毕经还有很多东西不是测试代码能发现的，比如业务、UI&UE等。
测试怎么和时间做赛跑，怎么抢在所谓的“生命线”完成测试，也需要从管理着手。
里面包含的问题可能有：
- 怎么有效合理的分配测试资源；
- 怎么让测试团队中每一个人员的测试工作高效、质量；
- 怎么激励团队，让其对工作保持持久的专注与激情；
- 怎么借用外部资源，解决测试资源的不足；
- ……
解决测试与时间的冲突应该是软件测试团队，乃至项目团队都需要研究的问题。如果你有更好的一些想法，不妨分享出来。