（续上文）

5.测试阶段

5.1项目组测试

项目经理把《项目组测试案例》分配给测试人员。如果组织资源不够，测试人员可以是开发人员，原则是自己的模块不能自己测试。测试人员根据《开发、测试、发布环境配置表》找到测试服务器来执行测试案例。

这里假定组织有缺陷管理和跟踪系统，例如Bugzero、TestDirector、JIRA等，凡不符合测试案例的正确结果的，在缺陷管理系统中报bug：

• 每个bug报告只能描述一个错误，如果在一个测试案例中找到五处错误，那么测试员要出五个bug报告，而不是集中报告。集中报告有时会发生信息错误传递或沟通障碍，例如开发人员A言语简单，A告诉测试人员B修复了；B再测，问题依旧，困惑地问A是怎么回事；A说修复其中一个；这种情景在现实中多次发生。
• 开发人员修复自己模块的bug后，通知测试人员再测；如果修复，测试员关闭bug，否则，不能关闭bug。

• 跑完所有的测试案例，修复完所有的bug，项目组测试才能宣告结束。通常，项目组测试报的bug要多于客户测试报的。这个阶段的bug类型有：真bug、重复报告的bug、无效bug等：

  • 真bug走上述流程修复。
  • 重复报告的bug是多个测试人员走相同的测试案例，发现一样或雷同错误，从而重复报告bug。开发人员择一修复，其余的bug说明原因关闭。
  • 无效bug，开发人员说明原因关闭。

  • 在测试期间，项目经理每天要多次查看缺陷管理系统中该软件的bug列表，关注测试案例执行情况和修复情况，督促进度不理想的。

    5.2客户测试

    项目组测试结束后进入客户测试。每个项目的客户不尽相同，每种客户的工作方式各有千秋，项目经理要引导客户进行测试，有时现实原因会让项目经理对客户测试进行调整或妥协。

    5.3安装客户处的软件平台

    客户测试结束后，项目经理派人客户方安装软件。

    5.4培训文档

    如果有培训，项目组根据《需求说明书》（若有《产品规格说明书》一并参考）、《系统设计》、《培训计划》编写《培训文档》。培训文档格式不限，最好询问客户接受哪种方式的培训和哪类型的文档，尽量配合客户的习惯，当然，如果客户习惯中有不好的地方，项目经理要进行引导。

    5.5系统产品指南

    如果有《产品规格说明书》，那么这阶段要把《产品规格说明书》丰富成《系统指南》，《系》跟《产》非常相似，只是增加详细的说明、操作步骤、截图等。

    6.变更阶段

    变更可以发生在项目的任何阶段，一般而言，它高发于设计、开发、测试阶段，任何人都有可能收到客户的变更要求，组织成员最好不要当场答应，而是告诉客户某时答复；项目经理获悉变更要求后，编写《变更要求书》通知甲乙双方高层和相关人员，必要时开会讨论；如果同意变更，双方高层签署文件，项目经理酌情调整已有的项目文档，一般是《项目总体计划》、《需求说明书》（若有《产品规格说明书》一并考虑）、《系统设计》、《美工UI页面》、《测试案例》等等。

    《变更要求书》例子见表8，格式不限于此：