最近老听一些测试的朋友抱怨，说制定出来的测试周期领导是如何如何的不满意。也有一些朋友私下问我如何来正确的评估测试周期。我告诉他们，办法是有的，但必须要做到三个前提条件。那就是：熟悉测试系统，明确测试资源，细化测试标准。

　　在讲这三个前提前，我们先来了解下什么是测试周期。测试周期是软件生命周期的一个阶段，他从测试的介入开始，到测试完成结束。更好理解的讲，更切合实际的讲，我们所说的测试周期，就是从领导下达测试任务开始，到测试达到测试通过标准为止，对产品来说是产品上线，对项目来说是项目通过验收。（请不要告诉我说是从需求开始，请问你们有几个见过可以根据需求来做测试的需求？）

　　作为领导他当然最关心测试周期了，因为他关心项目的进度和测试的成本，而时间正是他们所关心的中心问题，所以说只有合理的，紧凑的，饱满的时间安排才符合他们的要求，这就是我为什么说要作好测试周期的估算，必须做到三个前提条件，这是我们做测试周期估算的前提条件，也是说服领导我们的测试周期估算是合理的证据。

　　我们先来看一个例子，要建筑一栋大楼，那么在建造之前肯定要设计好建筑图纸，然后根据图纸能估算出需要多少耗材，需要多少人工和需要多少时间才能完成，从而就能估算出需要花费多少成本。我认为我们的测试周期估算也类似。

　　熟悉测试系统

　　这正是根据图纸来估算需要多少耗材和人工的时候。一个系统有多少模块，有多少功能点，甚至每个功能点要怎么来测试（设计多少测试用例才能覆盖），作为一个测试组长，测试负责人，你都要心中十分清楚。在目前大部分公司没有需求管理的情况下，这就要求测试负责人要付出更多的努力去熟悉测试系统。（可能有人会说，如果系统还没开发完成，那怎么来熟悉呢？ 哈哈，发挥你作为测试人员刨根问底的特长吧，反正这部分工作一定要作好）。设想，你前期能了解到系统共有六大模块，250个主要功能点，细化为1000个测试功能点，大约需要3000个用例来覆盖，那你还不知道有多少工作量吗？ 只要知道有多少测试资源（人工），那么就简化成一道小学应用题了。

　　明确测试资源

　　主要是指，要多少测试人员可以参加，他们的技术特长和测试经验及对该测试任务的熟悉程度。 我们要根据这些来给他们分配工作内容和工作量，并且根据这些来估算他们工作效率。（单位时间内所完成的工作任务）。现在有1000个工件需要做，有4个工人，甲每天做3个工件，乙每天做4个工件，丙每天做5个工件，丁每天做6个工件，那么问完成1000个工件总共需要多少天？问题就这么简单，前提条件是你要清楚内在的因素。

　　我知道问题远没有那么简单，有人肯定会问需求变更了呢？人员调整了呢？测试中间出现意外呢？要经过多伦次测试呢？其他不可预知的因素影响测试进度呢？。。。。。。。。疑问很多，但我们还是要面对。

　　细化测试准则

　　在测试开始之初，我强烈建议做好以下测试准则：

　　测试启动标准，要求开发方必须对主要功能做测试，保证提交过来的测试程序可以测试，不出现不可安装卸载，功能没实现或者存在重大功能缺陷的问题。

　　通过测试标准：测试达到什么程度，缺陷修复到什么程度，即可通过测试。一般从BUG的级别上来判断（要对BUG级别有个明确的定义哦）。

　　中止测试标准：如果测试过程中出现那些问题，就要中止测试。一般指出现不可安装，功能性重大缺陷导致测试无法进行下去。

　　进入下一轮测试标准： 如果一轮次测试没有通过，那么就要进入下一轮测试。就是什么情况下，有多少测试用例没有通过，需要进入下一轮测试。

　　我们在估算测试周期的时候，需要考虑进这些意外事件。我们通过表格简单说明下：

　　当出现以下情况时，该内容生效。

　　事件 细分需要时间测试周期 责任方

　　没有达到测试提交标准具体什么原因 开发方解决问题的时间顺延开发方

　　中止测试原因 同上顺延开发方

　　测试资源变更测试人员请假，调岗等  该测试人员剩余工作量的时间  顺延或其他人员顶替  测试方

　　多轮次测试  原因 下一轮测试时间  启用下一轮测试周期  开发方

　　注：有理由的变更前期的计划，这是你应该做到的。

　　说了那么多，还是没有说明具体怎么来做这个周期的估算，通过什么手段和工具来做。其实这个并不重要，象word ，project，excel等都可以，我都见过类似的摸板。无论你用表格还是树型图，还是梯状图，只要你能把 工作内容，测试资源，时间三者的关系表示清楚就可以了。

　　这方面我经验也不多，说的也不好，就算是抛砖引玉吧，希望专业人士能私下和我交流，也欢迎想了解这方面内容的一起探讨。