论软件测试计划的成功制定.docVIP

论软件测试计划的成功制定 　　摘要： 随着软件测试走向规范化管理，测试计划成为软件测试人员必须完成的重要任务之一。文章根据多年的教学及实践经验，提出如何制定出成功软件项目测试计划。 　　Abstract: As software testing goes towards standardized management, test plan becomes the important task that software tester must care for. Article put forward how to develop a successful software project test plan, based on years of teaching and practical experience. 　　关键词： 测试计划；变更；测试资源配置；问题跟踪报告 　　Key words: test plan；change；test resource allocation；issue tracking reports 　　 中图分类号：TP31 文献标识码：A 文章编号：1006-4311（2011）13-0172-02 　　0 引言 　　软件测试是一个极为复杂的过程。一个规范化的软件测试过程通常须包括以下基本的测试活动：拟定软件测试计划、编制软件测试大纲、设计和生成测试用例、实施测试、生成软件问题报告。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试计划应该作为测试的起始步骤和重要环节。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中。这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此成为测试工作展开的基础。 　　一个好的测试计划可以起到如下作用：首先避免测试的“事件驱动”，其次使测试工作和整个开发工作融合起来，最后资源和变更事先作为一个可控制的风险。 　　测试计划的模板在各个公司中都大同小异，在个人的实践中发现，测试计划制定中存在的问题具有相似性，下面就这些相似的问题谈谈如何制定软件项目测试计划。 　　1 测试阶段划分 　　就通常软件项目而言，基本上采用“瀑布模型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求－设计－编码－测试－发布－实施－维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。 　　合理的测试阶段应遵循下面划分方法： 　　照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。 　　2 系统测试阶段日程安排 　　划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可操作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1.1-1.5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编码阶段（包含单元测试和集成测试）1到1.5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太大，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下： 　　①计算需求文档的页数，得出系统测试用例的页数 　　需求页数：系统测试用例页数≈1：1 　　②由系统测试用例页数计算编写系统测试用例时间 　　编写系统测试用例时间≈系统测试用例页数×1小时 　　③计算执行系统测试用例时间 　　编写系统用例用时：执行系统测试用时≈1：2 　　④计算回归测试包含的时间 　　系统测试用时：回归测试用时≈2：1 　　基于以上方法的优点是，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现用一个例子加以说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000