全程软件测试之测试需求分析与计划（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版）》