【IT168 评论】提到如何设计有效的测试计划?测试计划中应该注意哪些问题?听了大家很多的分享，会后自己也整理了一份，当然是按照我自己的思路整理出来的，可能每个人所关注的方面不一样，我最为关注的就是有什么简单、方便、易懂的方式轻松定位如何设计测试计划，是一个量化的方式，理论的内容过于抽象，有时候能力也并为达到能分析的地步，而这个时候我们需要通过什么方式达到分析后同样的效果呢?这是我一直在思考的……

　　目前测试计划中的内容，不知道哪些是大家最为关注的?绝大多数情况下，大家可能更为关注时间的安排，而比如风险、环境、策略就略显得淡些，可在测试计划中，风险、策略等都是极为重要的成分，以下为我主要想分享的观点，主要针对目前如何分析是否需要某类测试策略，当然也欢迎大家拍砖：

　　《ANSI/IEEE软件测试文档标准829-1983》中将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”

　　根据上述的论点&会中大家讨论的观点来看，在编写测试计划时，主要包含以下方面：

　　“What(做什么)” ——– 测试范围&内容

　　“Who(谁来做)” ——– 测试资源安排

　　“When(何时做)” ——– 测试时间计划

　　“How(如何做)” ——– 测试策略

　　“Strategies(风险)” ——– 预估风险&解决策略

　　知道了大致填写的内容后，可能大家更想知道如何去设计、如何去分析?

　　1)What(做什么)：即将项目中大致的功能点罗列出来，当然并非细化到用例阶段，个人认为可以采用MM图or Excel形式均能很直观清晰的体现出来。

　　这个活动可以让自己对项目涉及功能点进行系统的梳理，从另一个角度上来说也可以让项目组成员评估你是否已经理解项目的需求范围

　　2)Who(谁来做)：即将项目过程中的测试工作进行分解，每个阶段安排指定的人员进行。

　　提到这个话题时，又引出另外一层问题：如何分析项目需要多少测试资源?以及分析是否需要自动化测试&性能测试&单元测试?

　　A. 测试资源比例分配规则：

　　从目前淘宝的规模来看，正常情况下，当开发人员/测试人员=3：1情况下，测试时间/开发时间=4.5/5.5

　　B. 如何分析是否需要自动化测试?

　　a. 项目功能比较稳定，变更比较少

　　b. 项目和组织相对成熟，流程的变更带来的影响比较小

　　c. 测试用例得到很好的维护，测试用例本身的质量较高

　　d. 自动化投入产出/手工投入产出>1，这里的产出不是数量，而是质量&效率

　　有一些项目可以部分引入自动化测试，比如：

　　a. 项目部分模块功能已经稳定，可以针对相对稳定的模块引入自动化测试

　　b. 项目大流程比较稳定，可以先对冒烟测试引入自动化测试

　　C. 如何分析是否需要性能测试?

　　大体的分析方向为：天pv、逻辑复杂度、运营推广计划(该参考值是之前向悟石请教来的，不知是否适应目前的判断标准)

　　a. 天PV：即指当PV访问值多大时，对服务器造成的压力，比如：目前某A应用只有两台机器，原来访问A应用的只有功能1，而若项目决定在其余功能模块等访问量很高的页面也开放了入口，势必会对现有A应用产生更大的服务量，基于服务器本身就少而且PV值预估会剧增的情况下，将会对该应用进行性能测试

　　b. 逻辑复杂度：我目前所理解的一种情况为：一个应用可能需要很多应用的支撑，即或是很多应用调用到某一个特定应用等情况下时，又或是大批量访问应用时的情况。

　　c. 运营推广计划：这个就看需求方需要达到某一特定的目标，如访问速度等等。

　　D. 如何分析是否需要单元测试?

　　参考方向：

　　a. 看系统复杂度是否高，高则需要单元测试

　　b. 项目中会不会存在功能测试很难测到或者功能测试代价远高于单元测试代价的情况

　　c. 单元测试能给你的项目带来哪些价值，比如项目如果是持续改进的，那单元测试还是很有必要的

　　那么这里又可以引发出另一个问题，如何来衡量复杂度?可以从以下2种角度来判断：

　　a. 从宏观上来看，系统的调用层次是否很深

　　b.用工具来统计代码的复杂度(如clover工具)

　　而根据公司目前的发展情况，目前判断的标准是项目中是否包含4大中心的应用，若包含则可申请单元测试，但以后的发展趋势应该是往全网发展的。

　　3)When(何时做):这个阶段是与Who(谁来做)相互对应的，将测试整个阶段进行时间上的分解，并进行合理的时间安排，如何分配每个阶段的时间，对于初次设计者可能有些拿捏不稳，这个时候需要去问问有经验的人具体该以什么样的方式来计划。

　　个人认为一般来说是按照项目的复杂程度以及人员的工作量&熟练程度来安排，或许其中也掺杂了一些个人经验在其中，有了一定的经验评估时间安排就会容易的多。

　　4)How(如何做)：这个阶段主要是测试策略的问题，那么可以从两方面来考虑此类问题。

　　A.基于测试技术的测试策略：

　　具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。这些方法都是比较实用的，但在具体工作中要采用什么方法，需要针对项目的特点加以适当的选择。在实际高水平的测试中，往往需要综合使用各种方法以有效的提高测试效率和测试覆盖度。

　　以下介绍的是各种测试用例设计方法选择的综合策略，供大家参考。

　　(1)首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。

　　(2)在任何情况下，都必须使用边界值分析法。经验表明，用这种方法设计出的测试用例发现程序错误的的能力最强。

　　(3)可以使用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

　　(4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

　　(5)如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法和判定表驱动法。

　　(6)对于参数配置类的软件，要用正交试验法选择较少的组合方式达到非常好的效果。

　　(7)利用功能图法，我们可以通过不同时期条件的有效性设计不同的测试数据。

　　(8)对于业务流清晰的系统，可以利用场景法贯穿整个测试案例设计过程，在案例中综合使用各种测试方法。

　　B.基于测试方案的测试策略: 主要是基于测试方案的选择，面对如此多的测试类型，我们如何来选择、筛选，不可能每个项目都面面俱到。

　　最主要的原则：根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点;每一种测试方案都有一个侧重点，那么我们就需要依据项目需求的侧重点来考虑对应的测试方案。

　　5)Strategies(风险预估)：风险无时无刻存在于项目中，不论前期or后期，只是后期的成本比前期大而已，那么在项目过程中，就需要随时关注风险，并及时更新应对措施。

　　风险的预估&缓解措施很大部分依赖经验值，在周会中康亮提出可以建议一个风险文档库，个人觉得这个办法可行，文档库可提供给新人作为参考，当然有经验之人需要经常性的更新，另外借鉴者在借鉴之时也需要自我思考下，看是否真的适用?有没有更加优化的空间，如果中间过程没有完善好的话，估计又会形式一般，所以是需要大家很多的自觉性。