下载掌阅APP，畅读海量书库
立即打开
在1.1.4节讨论了测试的风险观点，测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这意味着软件测试有较高的风险，所以软件测试的风险分析非常重要。软件测试风险，就是要将测试范围、测试过程中的风险识别出来，确定哪些是可避免的风险，哪些是不可避免的，对可避免的风险要尽量采取措施去避免。
风险识别的有效方法是建立风险项目检查表，按风险内容进行逐项检查、逐个确认。对于测试的风险，可以给出如下一个风险项目检查表，如表2-8所示。
表2-8 软件测试风险项目检查表
在测试风险分析中，逐项检查，确认风险之后，要找出对策，以避免风险产生或降低风险所带来的影响。表2-9给出了软件开发中常见的风险，说明这些风险发生的可能性、对测试的影响和影响程度以及如何进行预防和控制。
表2-9 软件测试风险识别和控制措施
下面会针对本书的两个典型案例给出简单的风险分析。客户端软件的测试风险相对来说会低一些，所以不做讨论。而且本书对软件测试中普遍存在的风险也不做讨论。
● 如果基本功能方面的问题太多，将严重影响性能压力测试的进度。
● 在第二轮测试后，产品应该基本无大的问题。开发要在第三轮测试开始前保证修复好所有已发现的主要问题。
● 多语言版的测试要求测试人员前期准备充分，测试人员对所测语言有可能不太了解，对该语言国家的使用习惯也不是很熟悉。
● 开发人员拿出产品的第一版本时，要提供或与测试人员共同完成压力测试工具的开发。
（1）项目复杂度。由于开始对项目的复杂度估计不足，导致项目后期的产品代码不能按时完成，这样势必会影响到测试的环节。
（2）需求的变化。用户的反馈、市场需求的变化会导致项目后期增加一些新的产品功能，这样就会使产品不能按照原定的测试计划完成，以致测试人员处于等待状态中。
（3）服务器的升级。基于Web方式的产品，随着不断推出的新服务器产品（如Linux 和Apache的版本升级），其兼容性需要验证，而且其安全性、稳定性和性能等方面所受到的影响需要分析，在测试过程中更换第三方产品的新版本，就要面临这样一个问题——是否要重新测试已测试的范围。往往不会从头再来，而是根据已定义的策略进行选择性的测试。
（4）数据库的升级。基于Web方式的产品，后台一般都离不开数据库的支持。如果测试过程中遇到数据库表结构的变化、版本升级（例如Oracle 9i升级到Oracle 10G），都会给测试过程带来风险。例如，升级后的数据库变得不稳定，有可能退回到原来的版本，影响测试甚至导致测试的失败。
（5）测试环境的不稳定性。例如被测试的服务器不能被访问，需要重新启动和配置，这会占用一定的时间。一旦不能访问测试环境，测试人员不仅无事可做，还常常会抱怨。这种情况影响了测试人员的情绪，最终也影响了测试结果。
（6）国际化和本地化的影响。如支持哪些语言版本？国际化版本的测试策略和方法、翻译公司是否能及时完成任务，以及翻译是否准确也会带来风险。
（1）根据风险发生的概率和带来的影响确定风险的优先级，然后采取措施避免那些可以避免的风险。如测试环境不对，可以事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查。
（2）风险转移。有些风险带来的后果可能非常严重，能否通过一些方法，将它转化为其他一些不会引起严重后果的低风险。如产品发布前发现某个不是很重要的新功能给原有的功能带来了一个严重的Bug，这时处理这个Bug所带来的风险就很大。对策是去掉那个新功能，转移这种风险。
（3）有些风险不可避免，就设法降低风险。如“程序中未发现的缺陷”这种风险总是存在，就要通过提高测试用例的覆盖率来降低这种风险。
（4）为了避免、转移或降低风险，事先要做好风险管理计划。例如，把一些环节或边界上有变化、难以控制的因素列入风险管理计划中。
（5）对风险的处理还要制定一些应急的、有效的处理方案。例如，为每个关键性技术人员培养后备人员，做好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍可以继续下去。对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。
（6）在做计划时，估算资源、时间、预算等要留有余地，不要用到100%。
（7）制定文档标准，并建立一种机制，保证文档及时产生。对所有工作多进行互相审查，及时发现问题。
风险管理的基本内容有两项：风险评估和风险控制（如图2-8所示）。
（1）风险评估，主要依据三个因素：风险描述、风险概率和风险影响。可以从成本、进度及性能三个方面对风险进行评估，它是在建立在风险识别、风险分析和风险排序基础上的。通过评估可以确定这些风险的特点或可能带来的危害。
（2）风险控制，制定风险管理计划和风险应急处理方案，来降低风险和消除风险。
图2-8 风险管理的基本内容