软件测试风险分析-软件测试思维模式之我见（七）

风险分析是软件测试流程中需要考虑的要素，那么如何做风险分析呢？风险分析需要考虑哪些点呢？知道了这些风险后如何做预防呢？整理了一份资料供大家参考，欢迎一起沟通交流、补充。

风险项目检查表：

类别	内容	示例
人员风险	测试人员的状态、责任感、行为规范等。	因个人工作疏忽而漏掉缺陷；某个人生病、离职等，造成资源不足，使测试不够充分或缩小了测试范围。
环境风险	在多数情况下，测试环境是一个模拟环境，很难和实际运行环境一致。	用户数据量、运行环境的垃圾数据、十几年的运行时间等。
测试范围（广度）	很难完成100%的测试覆盖率，有些边界范围容易被忽略。	测试很难覆盖模块直接接口参数传递、成千上万的操作组合等。
测试深度	对系统容量、可靠性等测试深度不够。	对互联网上的应用、操作行为和习惯等研究不够，测试时达不到实际的用户数。
回归测试	回归测试，一般不会运行所有的测试用例，而是运行部分的测试用例。越到测试后期，回归测试执行的用例数越少。	修正一个缺陷之后，除了验证这个缺陷之外，测试人员往往根据自己的经验来确定回归测试范围，而且这个范围很小。
需求变更	软件需求变化相对较多，有时在后期还发生需求变更，从而影响设计、代码，最后反应到测试中来。	需求变更后，文档不一致，测试用例没有及时更新、回归测试不足等。
用户期望	测试人员不是用户，很难百分之百地把握用户的期望，这种差异也会带来风险。	适用性测试就是一个典型的例子，不同的用户对界面的喜好和操作习惯都会存在或多或少多的差异。
测试技术	借助一些测试技术完成测试任务，可能有些测试技术不够完善，有些测试技术存在一定的假定，这都会带来风险。	如正交实验法在软件测试中应用时，很难达到其规定的条件。
测试工具	测试工具经常是模拟手工操作、模拟软件运行的状态变化、数据传递，但可能存在和实际的操作、状态和数据传递的差异。	如性能测试工具模拟1000个并发用户同时向服务器发送请求，这些请求都从一个客户端发出。而实际运行环境中1000个用户从世界不同的地方，不同的机器发出请求，请求的数据也不同。

 

测试风险的预防：

风险	可能性	潜在的影响	严重性	预防/处理措施
软件需求不清楚，变更导致测试需求及范围发生了变化	高	导致测试计划、工作量等发生变化	较严重	和用户充分沟通，做好调研、需求获取和分析，调整测试策略和计划。
开发进度延长，包括项目计划的变更、各个环节的进度拖延	中	推迟系统测试执行的时间和进度	严重	设置更多的子里程碑，控制整体进度，做好沟通和协调。
由于设计时间不够，代码互审和单元测试不够，导致开发代码质量低	中	Bug太多，问题验证，反复测试的次数和工作量大	严重	做好软件测试、提高编码人员的编码水平，进行单元测试。严格控制提交测试的版本、调整测试策略和计划。
对需求的理解偏差太大。原因是缺乏原型、与客户沟通不足、需求评审不到位	中	对Bug设计的合理性等确认困难	严重	与用户、产品经理多沟通，并借助一些原型和演示版本来改进。
测试工程师对业务不熟悉，主要原因是业务领域新、测试人员是新人或介入项目太迟	低	测试数据准备不足、不充分、测不到关键点，同时测试效率难以提高	一般	测试人员及早介入项目，与产品经理、市场、设计等各类开发人员沟通，加强培训，建立伙伴、师傅带徒弟的关系
由于项目提交日期的变更导致测试周期变更，一般是由客户提出的	低	系统测试总时间缩短，难以保证测试的质量	非常严重	严格控制项目的时间变更，多与客户沟通并得到客户的理解。调整测试策略、测试资源及计划

转载于:https://my.oschina.net/ps22/blog/3049511