到了“时”了，这是计划测试过程中最让人纠结的地方了。计划本来就是一件很麻烦的事情，关键点就在于计划的时候很难拿捏准时间的长度。在一本称之为《软件工程中的事实与谬误》的书籍中，作者提到一条软件项目走向失败的两大因素中的一条就是估算不准，由此可见计划之难了。Aaron现在对于时间计划搞得也是没模没样。
初一的时候计划在十五月圆之夜一起赏月对饮，可是天有不测风云，到了十五那天天气转阴了，月亮连个影子都没有更不要提月圆了。在项目中也会经常遇到这种情况，我们预计某年某月某日我们实现某项功能，可是等真的到了那一天，才发现原来我们想象中的那项功能依然只能存在与想象之中了。
那我们怎么做时间计划呢？ 在Aaron看来，因项目性质而异，要知道我们从事的项目大致可以分为两种：产品性质的和外包性质的。这两种性质的项目对于时间的要求，对于测试强度的要求是大不一样的。
对于一般外包项目来讲，对于测试要求相对较低，而时间是固定的。当前大多数标榜使用螺旋开发的团队其实只是变相的甚至是变质的瀑布模型，对于测试的现状更是如此。测试先行，测试与项目同时启动在大多数项目中都只是一句口号而已，因为大家心里都明白，口号是不要钱的，所以空喊口号这种最廉价的朝脸上贴金的方式广受软件作坊主们的欢迎甚至推崇。废话不扯了，对于这种项目的测试工作来讲，一般是标准的段段式的，即计划测试，测试用例设计，测试用例执行及bug管理，测试报告提交等等阶段。这就好弄多了，根据经验（如果一点经验都没有，那还有直觉）我们把这几个阶段换算成比例，然后把测试总时间瓜分了，需要提醒大家的就是记得在瓜分之后留点“缓冲时间”来，否则到时候出了点意外就麻烦了，记住是在每段时间之后加上一个缓冲期，而不是最后加上一次。
对于产品来讲，测试要求会比较高，时间当然也是需要考虑的，套用IT界最常被引用的一句话，“在这个瞬息万变的时代”，把握时机对于一个产品来讲无疑是很重要的。不过，由于众公司都不愿意自己的产品一出生生了满身毒疮——bug。轻则产品销量受损，重则产夭折，甚至严重影响公司形象乃至导致公司运转等严重问题。这个时候我们还是先将测试分段，对于这种项目，我们首先站在测试质量的角度，实事求是按照功能点数目、难度，测试经验等来估计测试时间，然后将总时间加起来，如果时间充裕，我们考虑加入更多测试面，如果时间紧迫，我们考虑是否删除部分非核心功能，以降低开发和测试的时间成本，从而为测试质量保驾护航。
回到上面的“月圆之夜”的故事片段上来，这个片段提醒了我们在时间计划的时候还有一些问题需要注意。上面提到计划失败是因为“月圆”这个外界因素没有达到要求，这就提醒我们在计划的过程中，应当尽量减少对于外界的依赖，如果依赖是必需的，那么对于依赖可能导致的意外我们要多出几套应急方案。另外，在项目执行过程中，及时检查项目进度也是必要的，这可以避免我们跑在错误的道路上，那样只会越错越远，这部分不属于计划测试的范畴，因此不做考虑了，如果有兴趣可以看一下持续集成相关的资料。
相关阅读：
