测试管理过程包括：制定测试计划及用例、执行测试、发现并报告缺陷、修正缺陷、重新测试。

信息系统后评价一般包括：系统目标评价、系统过程评价、系统效益评价、系统可持续性评价。

测试监视的目的是为测试活动提供反馈信息和可视性。主要包括：

• 记录和管理测试用例的执行状态
• 根据当前的执行状态，判定测试用例的设计质量和效率
• 根据发现的缺陷分布，判定结束测试的条件是否成熟
• 评估测试软件的质量，根据缺陷的数量、严重程度和种来判断质量
• 评估开发过程的质量，根据缺陷的分布、修复缺陷的时间、回归测试中发现的缺陷数量来判断质量
• 评估测试工程师的表现，如是否按计划完成测试任务，发现缺陷的数量及质量

测试工作中的风险

有些风险难以避免，如缺陷风险等，应将风险降到最低水平。
有些风险理论上可以避免，但实际操作过程中出于时间和成本的考虑，也难以避免，如：回归测试风险等。

• 需求风险

  对软件的需求理解不准确，导致测试范围存在误差，遗漏部分需求或执行了错误的测试方式；另外需求变更导致测试用例变更，同步时存在误差。

• 测试用例风险

  测试用例设计部完整，忽视了边界条件、异常处理等情况，用例没有弯曲覆盖需求；测试用例没有得到全部执行，有些用例被有意或无意的遗漏。

• 缺陷风险

  某些缺陷偶发，难以重新，容易被遗漏。

• 代码质量风险

  软件代码质量差，导致缺陷较多，容易出现测试的遗漏。

• 测试环境风险

  有些情况下测试环境与生产环境不能完全一直，导致测试结果存在误差。

• 测试技术风险

  某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期。

• 回归测试风险

  一般不运行全部测试用例，可能存在测试不完全。

• 沟通协调风险

  涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期。
• 其他不可预计风险
  一些突发情况、不可抗力等风险因素，难以预估和避免。

测试原则

• 避免测试自己的程序
• 不断地软件测试，修改好要及时进行回归测试
• 对测试用例要有正确的态度：
  • 测试用例应当由测试输入数据和预期输出结果两部分组成
  • 设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件
• 充分注意软件测试中的群集现象，也可以认为是“80-20原则”
• 严格执行测试计划
• 应当对每个测试结果进行全面检查
• 妥善保存测试用例、测试计划、测试报告和最终分析报告

测试分类

可分为静态测试、动态测试。
GB/T 15532-2008 软件测试分类分为：单元测试、集成测试、确认测试、系统测试、配置项测试、回归测试。

静态测试

被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。

• 对文档的静态测试
  主要以检查单的形式进行。
• 对代码的静态测试
  桌前检查、代码走查、代码审查。

动态测试

按开发阶段

• 单元测试

  • 单元功能测试
  • 单元接口测试
  • 单元局部书籍结构测试
  • 单元中重要执行路径测试
  • 单元的各类错误处理路径测试
  • 单元边界条件测试

• 集成测试

  • 模块间接口测试
  • 模块间数据传递
  • 全局数据结构测试

• 系统测试

  测试对象是完整的、集成的计算机系统，目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。

  • 从用户角度对系统做功能性的验证
  • 非功能性的验证

• 验收测试

  • 对整个系统的测试与评审
  • 根据验收通过准则分析测试结果
  • 决定是否接收系统及测试评价

• 黑盒测试

  还适用于需求分析阶段的软件文档测试。

• 白盒测试

  还适用于软件具体设计阶段的软件稳定进行测试。

• 灰盒测试

确认测试

• 内部确认测试

  由开发组织内部按软件需求说明书进行测试。

• Alpha 测试

  由用户在开发环境下进行测试，并且在开发者对用户的“指导”下进行。
  不能由程序员或测试员完成。

• Beta 测试

  由用户在实际使用环境下进行测试。

• 验收测试

  针对软件需求说明书 SRS，在交付前以用户为主进行测试。

• 负载测试

  确定并确保系统在超出最大预期工作量的情况下仍能正常运行，还要评估性能特征，如：响应时间、事务处理速率和其他与时间相关的方面。

配置项测试

测试的兑现是软件配置项，目的是检验软件配置项与 SRS(软件需求规格说明书) 的一致性。

回归测试

测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。