全程软件测试之测试需求分析与计划（3）

2.6  测试风险分析

 

在1.1.4节 讨论了测试的风险观点，测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这意味着软件测试有较高的风险，所以软件测试的风险分析非常重要。软 件测试风险，就是要将测试范围、测试过程中的风险识别出来，确定哪些是可避免的风险，哪些是不可避免的，对可避免的风险要尽量采取措施去避免。

 

风险识别的有效方法是建立风险项目检查表，按风险内容进行逐项检查、逐个确认。对于测试的风险，可以给出如下一个风险项目检查表，如表2-8所示。

在测试风险分析中，逐项检查，确认风险之后，要找出对策，以避免风险产生或降低风险所带来的影响。表2-9给出了软件开发中常见的风险，说明这些风险发生的可能性、对测试的影响和影响程度以及如何进行预防和控制。

下面会针对本书的两个典型案例给出简单的风险分析。客户端软件的测试风险相对来说会低一些，所以不做讨论。而且本书对软件测试中普遍存在的风险也不做讨论。

 

 

 

1．Google Talk的几个测试风险

 

?  如果基本功能方面的问题太多，将严重影响性能压力测试的进度。

 

?  在第二轮测试后，产品应该基本无大的问题。开发要在第三轮测试开始前保证修复好所有已发现的主要问题。

 

?  多语言版的测试要求测试人员前期准备充分，测试人员对所测语言有可能不太了解，对该语言国家的使用习惯也不是很熟悉。

 

?  开发人员拿出产品的第一版本时，要提供或与测试人员共同完成压力测试工具的开发。

 

2．Google日历的测试风险

 

（1）项目复杂度。由于开始对项目的复杂度估计不足，导致项目后期的产品代码不能按时完成，这样势必会影响到测试的环节。

 

（2）需求的变化。用户的反馈、市场需求的变化会导致项目后期增加一些新的产品功能，这样就会使产品不能按照原定的测试计划完成，以致测试人员处于等待状态中。

 

（3）服务器的升级。基于Web方式的产品，随着不断推出的新服务器产品（如Linux和Apache的版本升级），其兼容性需要验证，而且其安全性、稳定性和性能等方面所受到的影响需要分析，在测试过程中更换第三方产品的新版本，就要面临这样一个问题——是否要重新测试已测试的范围。往往不会从头再来，而是根据已定义的策略进行选择性的测试。

 

（4）数据库的升级。基于Web方式的产品，后台一般都离不开数据库的支持。如果测试过程中遇到数据库表结构的变化、版本升级（例如Oracle 9i升级到Oracle 10G），都会给测试过程带来风险。例如，升级后的数据库变得不稳定，有可能退回到原来的版本，影响测试甚至导致测试的失败。

 

（5）测试环境的不稳定性。例如被测试的服务器不能被访问，需要重新启动和配置，这会占用一定的时间。一旦不能访问测试环境，测试人员不仅无事可做，还常常会抱怨。这种情况影响了测试人员的情绪，最终也影响了测试结果。

 

（6）国际化和本地化的影响。如支持哪些语言版本？国际化版本的测试策略和方法、翻译公司是否能及时完成任务，以及翻译是否准确也会带来风险。

 

 

 

3．测试风险的控制方法

 

（1）根据风险发生的概率和带来的影响确定风险的优先级，然后采取措施避免那些可以避免的风险。如测试环境不对，可以事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查。

 

（2）风险转移。有些风险带来的后果可能非常严重，能否通过一些方法，将它转化为其他一些不会引起严重后果的低风险。如产品发布前发现某个不是很重要的新功能给原有的功能带来了一个严重的Bug，这时处理这个Bug所带来的风险就很大。对策是去掉那个新功能，转移这种风险。

 

（3）有些风险不可避免，就设法降低风险。如“程序中未发现的缺陷”这种风险总是存在，就要通过提高测试用例的覆盖率来降低这种风险。

 

（4）为了避免、转移或降低风险，事先要做好风险管理计划。例如，把一些环节或边界上有变化、难以控制的因素列入风险管理计划中。

 

（5）对风险的处理还要制定一些应急的、有效的处理方案。例如，为每个关键性技术人员培养后备人员，做好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍可以继续下去。对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

 

（6）在做计划时，估算资源、时间、预算等要留有余地，不要用到100%。

 

（7）制定文档标准，并建立一种机制，保证文档及时产生。对所有工作多进行互相审查，及时发现问题。

 

知识点:

 

风险管理的基本内容有两项：风险评估和风险控制（如图2-8所示）。

 

（1）风险评估，主要依据三个因素：风险描述、风险概率和风险影响。可以从成本、进度及性能三个方面对风险进行评估，它是在建立在风险识别、风险分析和风险排序基础上的。通过评估可以确定这些风险的特点或可能带来的危害。

（2）风险控制，制定风险管理计划和风险应急处理方案，来降低风险和消除风险。

2.7  制定有效的测试策略

为了最大限度地降低测试风险，尽早地发现各种潜在的软件缺陷，在测试实施之前，测试组必须确定合适、有效的测试策略，并以此为依据选定测试方法、测试工具和测试用例设计思想。通过制定测试策略来指导测试用例的设计、测试工具的选择和执行，特别是能解决测试当中经常碰到的一些问题。良好的测试策略必将给软件测试带来事半功倍的效果，可以充分利用有限的人力和物力资源，高效地完成测试目标。

测试策略描述当前测试项 目的目标和所采用的测试方法，针对某个应用软件系统或程序，具体的测试项目要达到的预期结果还包括在规定的时间内哪些测试内容要完成，软件产品的特性或质 量在哪些方面得到确认。测试策略还要描述测试不同阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法，以及每个阶段内所要进行的测试类型（功能 测试、性能测试、压力测试等）。其内容包括如下。

?  对测试的公正性、遵照的标准做一个说明，证明测试是客观的，软件功能要满足整体需求，实现正确，并与用户文档的描述保持一致。如声明测试完成的标准是95%的测试用例通过并且两个最高级别的缺陷全部被修正，用以计划、实施及通报测试结果。

?  描述测试用例是什么样的，如何执行，用了什么样的数据，又如何执行后续的回归测试。

?  选定要使用的测试技术和工具。如采用了什么工具，工具的来源是什么，是否60%用Rational Robot自动测试、40%用手工测试。

?  根据经验判断和头脑风暴，对以往测试中经常出现的问题加以考虑。又如采取一些发散性的思维，往往能帮助找到新的测试途径。

?  考虑影响资源分配的特殊情况。例如有些测试必须在周末进行，有些测试必须通过远程环境执行，有些测试须考虑与外部或硬件的接口。

为了更好地确定软件测试策略，可以试着问如下一些问题，在寻找这些答案的过程中，也就找到了最佳的测试策略。

?  回归测试的范围如何确定？

?  如何利用可重复性的测试？

?  测试缺乏可预见性，如何收集衡量测试结果的指标？

?  如何建立稳定的、模拟系统实际运行的测试环境？

?  如何从无穷的输入数据中选择合理的、有效的测试数据集？

?  如何加强静态测试——规格说明书、设计文档和程序代码等的审查？

?  如何处理单元测试和集成测试的关系？

?  如何处理手工测试和自动化测试之间的平衡，使它们的互补性得到发挥，使测试的效率和质量达到最佳状态？

?  如何衡量这种测试策略的有效性？

1．测试策略制定的三项基本要素

软件测试策略制定有三项基本要素：输入、输出和过程。

（1）输入，作为制定测试策略的依据，包括限制条件和已具有的资源：

?  所要求的软、硬件的详细说明，包括测试环境、测试工具等；

?  人力资源和测试进度的约束，包括测试组成员的角色和职责说明；

?  测试方法和衡量测试是否通过的标准；

?  被测软件组件或系统的功能性和技术性需求文档，及其变更请求的控制流程；

?  软件系统所受到的其他限制。

（2）输出，制定策略的成果，即最终对所制定策略的定义或说明：

?  通过/失败的准则和测试风险评估的结果；

?  已批准和签署的测试策略文档；

?  和测试策略相对应的测试计划、测试用例的设计思想和思路。

（3） 制定策略的过程。测试组分析需求，参与设计的讨论，要求开发、编写针对所有测试级别的测试策略，并和项目组一起复审测试策略和测试计划。测试策略应该覆盖 整个项目的生命周期，需要各类技术人员（系统架构师、数据库管理员、编程人员等）参与。各类技术人员相互之间应多交流、讨论，以保证制定正确的测试策略。

2．基于测试技术的测试策略

著名的软件测试专家Myers指出了使用各种测试方法的综合策略。

?  在任何情况下都要使用边界值分析方法，因为为边界值分析方法所设计的测试用例能很有效地发现软件代码的缺陷。

?  等价类划分方法是对边界值分析方法的有效补充。

?  如果软件某些功能的输入数据/条件存在多种组合情况，则一开始就可选用因果图法。

?  错误推测法可以帮助追加一些比较特殊、不易直接推理出来的测试用例。

?  对照程序逻辑来审查已有测试用例的逻辑覆盖程度。如果没有达到要求的覆盖率，则应当再增加一些测试用例。

?  尽管用户更倾向于基于程序规格说明的功能测试，但是白盒测试能发现潜在的逻辑错误，而这种错误往往是功能测试发现不了的。

3．分阶段的测试策略

?  严格地执行代码复查，以保证在早期就发现问题，而不是在代码发布之后。

?  利用单元测试和集成测试，可以尽早地发现更多的问题，并准备好自动化测试的BVT（Build Verification Test，软件包验证测试）。

?  需要建立一个正规的且自动化的冒烟测试，只有100%通过冒烟测试，才能进入下一个阶段。

?  系统测试中，以每次发布用户基线为结束标志，用户基线会增长，同时也会逐渐地要求一些更为精确的性能测试。

?  不能忽略安全性测试、可用性测试、配置测试和数据完整性测试。

?  在功能性测试、安全性测试、配置测试中可进行一些探索性测试。

?  制定更为详细的UAT（用户验收测试）测试计划，将其与测试脚本和培训材料一起提供给用户，以帮助用户快速提高并完成任务。

4．基于测试方案的综合测试策略

（1）根据软件产品或服务特性对客户的使用价值以及特性失效所造成的损失，来确定相应特性的测试优先级。产品特性的优先级越高，其被测试的时间越早，测试的力度也越大。

（2）要使用尽可能少的测试用例，发现尽可能多的程序错误。一次完整的软件测试过后，如果程序中遗漏的（较）严重错误过多，则表明本次测试是不足的或失败的，这意味着可能让用户承担较大的利益损失风险。反过来说，如果过度测试，则又会浪费软件企业自身的宝贵资源。所以，需要在以上两点——风险和效率上进行权衡，找到一个最佳平衡点。

（3）测试策略应该尽量的简单、清晰，例如可以在有限的白板上通过2～3行字和1～2个图就描述出测试策略来，或者可以通过一个简短的会议（20～30分钟），就能把测试策略解释清楚。

（4）基于缺陷分析的测试策略。通过缺陷分析，可以更好地了解开发人员的习惯，找到容易犯错误的地方，可以更好地设计测试用例，更快地发现缺陷。也可以从缺陷出发，反推回去，找到合适的测试策略。

5．测试策略的示例

在Google日历的测试项目中，要考虑在浏览器和操作系统的不同组合下进行测试。最简单的办法就是完成所有组合的测试，如5个操作系统（Windows 2010 server、Windows 7、Windows 8、Mac 10.8、Linux）和7个浏览器（IE8、IE9、某个中文、Chrome、Firefox、Opera、Safari）的组合有近35种——因为有些组合是很少出现在实际的环境中。以前面所说的360个测试用例为基础，在各种环境上共要执行12 600多个测试用例，工作量太大。这时就需要根据操作系统和浏览器的市场占有率、对测试用例的影响程度、缺陷分析的结论和经验等，简化或优化组合。从表2-10可以看出，等价组合降到了8，只要执行大约2880个测试用例，测试的工作量大大减少。

针对Google日历这样的产品，还可以制定针对功能性和用户界面的测试策略。如按照Google日历的功能划分来设计测试用例，保证一系列的逻辑被有效地验证。

?  输入时间或活动的组合（不同长度和单双字节的字符串长度）。

?  在相同的时间或活动在不同日历里面的显示和跳转（用户界面）。

?  改变用户的不同设置。

测试上述的功能在不同的分辨率和上述操作系统、浏览器的组合。

概念

（1）冒烟测试（Smoke Testing）是在代码被检查进入（check in）代码库之前对代码修改进行验证的流程或活动。在代码复审（code reviews）之后，冒烟测试是识别和修正软件缺陷的最有效方法。它可以确认代码的修改符合要求和期望，且不会造成软件包构建的失败。冒烟测试和自动化回归测试的脚本集一起被用来测试那些高风险的功能或高容量的事务处理。

（2）BVT（Build Verification Test）是软件包构造之后由测试工具（脚本）完成的验证测试，用以确认基本功能正常，没有出现严重的缺陷。BVT通过后，才进行手工测试，或者进一步的自动化测试。

2.8  完整生成测试计划书

在软件测试需求和测试范围分析、工作量估计、测试资源和进度安排、测试风险评估、测试 策略制定等工作做完之后，测试计划也就基本大功告成了。测试计划本身就是为了解决测试目标、任务、方法、资源、进度和风险等问题，所以当这些问题被解决或 找到相应的对策和处理措施之后，测试计划剩下的工作就是写好这个文档，将上述内容描述清楚。有一点必须在这里说明的是，测试计划是一个过程，不仅仅是“测 试计划书”这样一个文档，测试计划会随着情况的变化不断进行调整，以便于优化资源和进度安排，减少风险，提高测试效率，并及时修改“测试计划书”。

在计划书中，有些内容是介绍测试项目的背景、所采用的技术方法等的，这些内容仅仅作为 参考，但有些内容（如人员组成、日程安排）也可以看作是一种结论，或者承诺，是必须要实施或达到的目标，如测试小组的结构和组成、测试项目的里程碑、面向 解决方案的交付内容、项目标准、质量标准、相关分析报告等。测试计划内容的焦点则集中在下列内容上。

（1）目标和范围：包括产品特性、质量目标，各阶段的测试对象、目标、范围和限制。

（2）项目估算：根据历史数据和采用恰当的评估技术，对测试工作量、所需资源（人力、时间、软硬件环境）做出合理的估算。

（3）风险计划：对测试可能存在的风险进行分析、识别，以及对风险的回避、监控和管理。

（4）进度安排：分解项目工作结构，并采用时限图、甘特图等方法制定时间/资源表。

（5）资源配置：人员、硬件和软件等资源的组织和分配包含每一个阶段和每一个任务所需要的资源。人力资源是重点，而且与日程安排联系密切。当发生类似到了使用期限或者资源共享的时候，要及时更新这个计划。

（6）跟踪和控制机制：包括质量保证和控制、变化管理和控制等，明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者，问题发生的频率，是用什么样的测试用例测出该问题的，以及明确问题产生时的测试环境。

测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织。为每一个阶段制定一个计划书，还可以为每个测试任务/目的（安全性测试、性能测试、可靠性测试等）制定特别的计划书。

同时，可以为上述测试计划书的每项内容制定一个具体实施的计划，如将每个阶段的测试重点、范围、所采用的方法、测试用例设计的思想、提交的内容等进行细化，供测试项目组的内部成员使用。对于一些重要的项目，会形成一系列的计划书，如测试范围/风险分析报告、测试标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。对于更为详细的要求，可以参考国家标准《测试计划（GB8567—88）》中制定的测试计划通用模板。

2.9 小结

本章主要讨论测试需求和如何创建有效的测试计划。测试需求包括功能测试需求和非功能性 测试需求，而非功能性测试需求包括性能、安全性、可靠性、兼容性、易维护性和可移植性等测试需求。对于非功能性测试需求，既要独立考虑它们各自的特点和各 自的测试需求，也要考虑它们之间的关系和相互影响，例如安全性和可靠性密切相关，越安全越可靠，越可靠越安全。而安全性会增加许多保护措施，往往会降低性 能。在整个系统测试需求分析时，不仅要考虑来自整体系统的测试需求，还要考虑系统数据、外部接口等测试需求，如图2-9所示。

在测试计划过程中，主要做好下列各项工作。

 

?  确定软件功能性、非功能性的测试需求，以及各个阶段的测试任务。

 

?  进行测试范围分析，从而对测试工作量进行估算。工作量估算方法主要介绍工作分解结构表方法，并给出了实例。

 

?  测试资源需求、团队组建，包括培训。

 

?  测试里程碑和进度的安排。

 

?  对测试风险进行分析。

 

?  制定有效的测试策略。

 

最后完整地生成测试计划书，进行计划书的评审、跟踪和及时修改，测试计划是一个过程，不仅仅是“测试计划书”这样一个文档，测试计划会随着情况的变化不断进行调整，用以优化资源和进度安排，降低风险，提高测试效率。

——————本文节选自《全程软件测试（第2版）》