软件测试组织与管理计划.docVIP

软件测试组织与管理计划 　　中图分类号：TP 文献标识码：A 文章编号：1007-0745（2013）06-0140-01 　　作为软件的重要环节，软件测试越来越受到人们的重视。随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可能多地找出中的错误，生产出高的软件产品，加强对测试工作的组织和管理就显得尤为重要。 　　从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可作相对较强。但是，由于测试的依据是规格说明书、文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的表示。 　　为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。 　　软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。 　　一个好的测试计划可以起到如下作用 　　1. 避免测试的“事件驱动” 　　2. 使测试工作和整个开发工作融合起来 　　3. 资源和变更事先作为一个可控制的风险项目经理圈子 　　测试计划的模板在各个公司中都大同小异，在个人实践中发现，测试计划制定中存在的问题具有相似，下面重点就这些相似的问题谈谈如何制定软件项目测试计划。 　　问题一：测试阶段划分 　　就通常软件项目而言，基本上采用“瀑布型开发方式，这种开发方式下，各个项目主要活动比较清晰。整个项目生命周期为需设计编测试发布实施维护。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常*???到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。 　　相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。 　　问题二：系统测试阶段日程安排 　　划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1.1～1.5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编*阶段（包含单元测试和集成测试）1到1.5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下：项目管理者联盟文章 　　1. 计算需求文档的页数，得出系统测试用例的页数 　　需求页数：系统测试用例页数≈ 1：1 　　2. 由系统测试用例页数计算编写系统测试用例时间转自项目管理者联盟 　　编写系统测试用例时间≈系统测试用例页数×1小时 　　3. 计算执行系统测试用例时间 　　编写系统用例用时：执行系统测试用时≈ 1：2 　　4. 计算回归测试包含的时间项目经理博客 　　系统测试用时：回归测试用时≈ 2：1 　　注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据 　　基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。 　　项目管理培训 　　（测试经理在