图 1 简短描述了基于会议的测试。对于软件中的任何新更改，计划不同的测试会议，每个会议都有一个指定的目标和任务。测试会议期间，测试人员使用测试案例和/或执行探索性测试。测试会议结束时，会报告在会议期间找到的缺陷。

　　图 1. 基于会议的测试工作流

　　基于风险的测试

　　因为在开发流程中进行了一些更改(主要的或次要的更改)，开发团队通常拥有同一个软件的许多常用版本。一种重要的 QA 实践是在每个主要版本之后彻底测试软件。另一方面，在每个版本中都对整个软件运行全面的回归测试既耗时又很难实现。但是，仅测试更改的功能或笨拙地删减测试案例套件是不安全的。一段代码可能解决了一个缺陷，但也可能破坏了代码中的其他内容。

　　基于风险的测试方法采用了折中方式。它的基本理念是按降序对软件功能和失败模式排序，从重要或风险高到值得拥有的功能和简单的风险(一个类似工具是 FMEA：失败模式和影响分析)。如果测试人员在严格的时间限制下测试某个新版本时手头有这个列表，他可以集中精力确保新引入的更改不会破坏其他任何内容。然后可以轻松地确保更改不会破坏软件中的任何重要的功能，因而不会发生任何严重的风险。

　　回页首结束语

　　每家公司都希望在充满竞争的 IT 市场中飞得更高，而且在努力创造人们喜欢的软件。不幸的是，有时来自客户或不耐烦的管理层的压力可能导致团队绕开软件质量实践，终实现一个低于预期的产品。糟糕的软件质量只有在它发生故障时才会被注意到。

　　本文中讨论的实践和方法贯穿整个开发生命周期。它们涵盖需求分析、设计和开发，以及测试阶段。而且它们表明缺陷预防比在项目结束时再解决问题要简单得多，在项目结束时，更改带来的技术人情债和成本将会很高。

　　本文突出了软件质量角色和重要性，以确证忽略软件质量可能严重影响公司实现其业务目标。另外，本文还为读者介绍了一些更简单、更高效的实践，它们不但为团队节省了时间、金钱和精力，还提升了产品的质量。