1.1.3.3. 测试过程实施要点
测试人员应该尽早介入项目，而非开发完成后才进入项目。测试人员应该参与早期的需求和设计的讨论与评审，在需求的讨论和评审中要重点关注需求的可测性。
每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据，同时，开发人员不能把调试来代替测试。
80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错 测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试，所以在设置测试的出口条件。
测试应当动态的过程，要循序渐进，不要企图一次性干完，注意“欲速则不达”，特别是在迭代的开发模型下。
1.1.3.4. 测试计划
根据确认的需求规格说明书和相关设计文档，确定项目测试阶段的目标和策略，确保测试工作有序、有效进行。
测试计划包括以下工作内容：
确定系统的测试需求，如功能需求、性能需求、安全性要求、可使用性需求等需求说明书中说明的和潜在的需求；
测试负责人与项目经理协商，逐步确定测试项目的测试范围、测试粒度（覆盖标准）以及测试方案、测试阶段的出入口准则；
根据项目的复杂度和以往的测试数据初步估计测试项目工作量，制定测试计划的进度安排。逐步细化测试方案及测试规模估计；测试进度安排中要留有合理的测试BUG、用例管理时间；
形成测试计划书（可包括单元、集成、系统阶段）并提交测试负责人、项目经理或测试部门经理审核。批准人为项目经理。同时测试负责人可发起测试计划的评审；审核批准通过则放入开发配置库；
当项目开发计划或测试需求发生变更时，测试计划应考虑是否需要变更；
1.1.3.5. 测试用例
根据批准的需求规格说明书和相关设计文档，策划测试过程执行依据，确保测试范围有效并正确。
测试用例管理包括以下工作内容：
? 测试人员参与需求评审，正确理解系统需求并确认需求的可测性，获取
测试项目需求；
? 根据批准的测试项目需求，测试目标的逻辑实现和约束，测试工具及其
测试环境等限制条件，设计测试用例；测试用例的基本要素至少包括用例编号、用例名称、执行步骤、输入数据、期望输出等。
? 测试负责人发起组织相关人员进行测试用例评审，从而提高测试用例的
质量；系统测试用例审核人可以是测试负责人、项目经理、测试部门经理，批准人为项目经理；
? 测试负责人负责基于系统的详细设计，确定单元测试范围和粒度，有效
路径和值域等，组织开发人员进行单元测试中自动和手动测试用例的编写；并组织相关人员进行评审；
? 测试负责人负责进行阶段测试用例的实施、跟踪及用例统计分析工作、
改进测试用例等管理活动；
? 当软件需求或设计变更引起测试需求变更时，将变更测试用例文档； ? 测试负责人实时或定期根据Bug数据、状态和测试用例执行情况进行分
析，以确定是否需要对目前测试的模块设计新的测试用例，对不稳定的模块，测试负责人负责与项目经理讨论确定测试范围、粒度和执行方案等，并指定相关人员完成新增测试用例的编写；
1.1.3.6. 测试的开发
设计、编写和管理测试程序、测试脚本和其它辅助测试程序，以提高测试效率和测试质量。
测试开发的工作内容：
? 根据测试需求，设计测试程序和脚本；
? 选择相应的开发语言编写测试程序和脚本；除了完成测试所需的功能外，
还应考虑模块的重用和代码的简洁；
? 对于一些底层模块，在测试没有界面的接口时可以考虑用编写测试程序
或脚本实现；
? 没有现成工具可使用的性能测试也可以通过编写测试程序或脚本模拟
实际环境进行测试；
? 开发单元测试和集成测试所需的桩模块和驱动模块；
? 脚本必须在动态维护过程中，对于可重复利用的模块必须建立公共库，
以实现资源共享；
1.1.3.7. 测试的执行
测试执行是根据测试用例实施测试的过程。 测试执行的工作内容包括：
? 充分理解测试用例，按用例要求准备测试前置条件，并按用例要求的步
骤执行测试过程，把测试结果与预期结果进行比较，得出测试通过与否的结论；
? 详细记录测试结果，对于产生的BUG，还要认真记录BUG发生的具体情
况。
? BUG提交给开发人员修改后，需要验证BUG是否真正解决，对解决的BUG，
作关闭操作，没解决或全部解决的BUG，返回开发人员继续解决。 ? 不定期与开发人员讨论BUG的情况。
? 测试结束时，提交测试分析报告，评价系统的质量状况。
1.1.4. BUG管理
包括对所发现的BUG的记录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除等一系列活动状态的管理；
6.15.4.1 BUG管理流程
以上的状态迁移图遵循如下原则：
矩形表示的为状态名称，蓝色字体表示的为操作名称。 一个状态可以通过一个操作迁移到另外一个状态。
? 提交：提交新的BUG，没有起始状态，结束状态为“已提交”；组织内任
何人均可执行该操作；
? 无效：审核BUG为无效，起始状态为“已提交”，结束状态为“无效的”；
组织内测试负责人可执行该操作；
? 有效：验证BUG为有效，起始状态为“已提交”，结束状态为“有效的”；
组织内测试负责人可执行该操作；
? 延迟：将BUG进行延迟处理，起始状态为“有效的”，结束状态为“已
延迟”；组织内项目经理可执行该操作；
? 分配：将有效的或延迟的BUG分配给相应的开发员进行修改，起始状态
为“有效的”或“已延迟”，结束状态为“已分配”；组织内项目经理可执行改操作；
? 解决：将分配好的BUG进行修改处理，起始状态为“已分配”，结束状
态为“已解决”；组织内开发人员可执行该操作；
? 重新分配：把分配错误的BUG或需要延迟的BUG退回分配状态，起始状
态为“已分配”，结束状态为“有效的”；组织内开发人员可执行该操作； ? 拒绝：将已解决的BUG进行测试验证，测试不通过的进行拒绝操作，由
开发员重新进行修改，起始状态为“已解决”，结束状态为“已分配”；组织内测试人员可执行该操作；
? 关闭：将已解决的BUG进行测试验证，测试通过的进行关闭操作，起始
状态为“已解决”，结束状态为“已关闭”；组织内测试人员可执行该操作；
? 修改：修改操作可在任何状态进行，且只能修改BUG记录的内容，不进
行状态迁移；组织内测试负责人可进行该操作。
6.15.4.2 BUG分类 BUG级别 1类BUG：致命错误 说明 致命错误通常有如下情况： 1、需求书中的重要功能未实现； 2、造成系统崩溃、死机,并且不能通过其它方法实现功能； 3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。