作为软件测试计划的一部分，软件测试风险的分析与控制是其中重要的环节。假如前期风险分析与控制比较充分，那么会使软件的测试成功性大大增加，且可将由风险异常引发的额外成本（如人力，时间等）降到最低。查阅了网上很多关于软件测试风险控制的文章，其中不乏精品之作。本文将此类知识进行了归纳，查漏补缺，并在思维导向性上给出了简单的实施步骤，以使得在实际应用中能得到更好的运用。 第一部分：软件测试项目级的风险分析 1. 从人、料、法、环、时等方面分析测试项目级的风险分布 探寻测试隐藏的风险时，应招集测试全组成员进行会议， 建议采纳头脑风暴和询问 5Why 的方式进行以集思广益和深度挖掘。下面就在鱼骨图中以 TQM （全面质量管理） 的人、机、料、法、环等五个方面来全方位的分析和排列项目级可能隐藏的风险 （注：考虑到在软件测试中“机”这一项更多的属于环境这一分类，故删除此类。另外时间对于软件测试是一个非常重要的属性，故添加之）。 下面对鱼骨图中的各个分支及子分支进行相应注解： 人，即测试人员：业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透侧、理解错误等。测试人员变动：离职，岗位调动，请假等。定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的。疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试显示出倦意和缺乏兴趣。同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出发的测试观察点。 料，即测试相关文档（在 TQM 中指的是生产原材料）：Spec （详细规格说明书）缺失：只有 PRD（项目需求概要说明书），没有 spec。笔者所在的公司，早些时候的产品更多的时候只有 PRD，没有 Spec。需求变更：这是最不想，但又最常常发生的事情测试用例/数据设计不充分：某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。质量标准不统一：如某些 Bug 的优先级方面，测试和开发的认同不一致。 法，即测试方法和实施：错误或缺失测试方法：对功能点没有采纳正确的测试方法，或某些测试方法没有被忽视，如边界测试等，导致测试不充分。场景的缺失或部分缺失：Spec 非常详细，所有的精力放在功能点的测试上，忽视了业务场景（Spec 中无定义）的全（100%）测试。测试用例实施不充分：...
