四、测试计划管理

    a）测试计划

    测试计划用于明确测试思路，指导测试活动，是成功执行和管理测试项目的保证，通过测试计划可以提高可交流性，避免测试的随意性。测试过程一定要按测试计划来进行。

    系统测试计划分为两级管理：系统测试计划和系统测试方案。

    由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。制定测试计划需遵循以下原则：

    1．制定计划的人应该是最了解项目和测试资源的人。测试计划要经过项目组的评审，避免出现不合理的计划。

    2．计划安排要结合需求，执行优先级要体现需求的优先级。在同等优先级的情况下，要先安排技术难度高的测试项，增加计划的可调控性。

    3．测试一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。

    4．制定的计划应明确、可及、可度量、可追踪。

    5．计划表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。推荐微软50% 缓冲规则。

    6．由于内外部因素可能需要对测试计划进行调整，这时需要及时对测试计划进行变更和维护

    b）系统测试计划

    系统测试计划的内容应该包含以下几大部分：测试范围、策略、测试配置和环境、暂停和再启动标准、进度、人力资源、风险和应对等。

    系统测试计划属于项目计划的一个部分。项目计划是在项目生命周期里对项目资源、进度的一个规划，而测试计划是对里程碑范围内测试资源、活动、进度等的规划。测试活动的启动和暂停受控于项目进度计划。

    测试计划也应该和项目计划一起纳入配置管理，和项目计划同步进行更新

    c）系统测试方案

    因为系统测试往往是以版本迭代测试的方式开展，因此，针对每次测试，为了有效地规范测试执行的过程，所以还应当制定系统测试方案。

    一般来说，系统测试方案可以分为两个层面：测试负责人层面和测试人员层面，二者考虑的重点有所不同。

    系统测试方案在评审通过后应归档管理，它是系统测试执行的依据，系统测试的执行活动应遵照该计划执行。一般来说，参加系统测试方案评审的人员应包含但不限于以下人员：测试组组长，测试人员，测试申请中指定的本次系统测试的版本负责人

    五、测试风险管理

    a）测试风险和管理承诺

    了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和资源上的准备，用以规避风险，把风险的影响降到最低。

    测试风险可分为外部风险和内部风险：

    外部风险就是导致测试实际情况和计划不一致的外部因素。包括：需求项变更，项目进度调整，提交测试工作产品的质量不符合要求等。

    内部风险就是测试团队内的一些不确定因素。包括测试进度延误，测试工程师流失，测试工具不到位等。

    对风险的防范，高层的支持是很重要的，他能决定相关资源的保障，规避项目进度的失控情况，对需求项的更改也能起到控制作用。所以在测试管理里，风险管理和高层承诺都要考虑，高层管理的承诺其实也是一种风险

    b）测试常见风险

    测试常见风险：

    1. 测试计划过于乐观；

    2. 开发组没能按计划提交相应的测试工作产品；

    3. 测试计划要求的硬件和软件设备或资源未能满足；

    4. 测试工具的应用没能达到预期深度；

    5. 测试人员的流失，或因出差或休假造成的人力资源不足；

    6. 过多的临时任务；

    7. 重要测试数据丢失等

    测试计划阶段的典型风险有：

    1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划；

    2、测试计划的组织者可能缺乏足够的测试经验；
   
    3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制

    六、测试文档管理

    项目测试计划、测试方案、测试规程会因项目开发活动的变更而变更，应置于适当的管理和控制之下，测试活动相关的工作产品的变更依据变更管理过程的原则实施。

    测试规程作为组织测试活动的基础和有形财富，应当得到有效地积累、维护和管理。可以选择配置管理工具如SVN或QualityCenter。（主要采用QualityCenter管理测试规程）测试管理人员应确保测试方案中准备测试的条目都应有测试规程对应，测试报告中的测试记录和BUG记录都对应于某条或某组测试规程，如果测试中发现的问题不能与某条测试规程对应，测试规程应及时得到补充和完善。通过度量测试用例在测试完成之后对应的结果或状态（通过、失败）以及当次测试使用的测试用例数来辅助判断测试的结果