首页  思维导图  详情

软件测试架构师的核心技能

2021-11-23 17:27:58   4  举报





AI智能生成

如何才能制定好测试策略？测试策略实战攻略。版本测试策略和产品质量评估。

软件测试架构师的核心技能

如何才能制定好测试策略

测试策略实战攻略

版本测试策略和产品质量评估

软件测试

作者其他创作

大纲/内容

版本测试策略和产品质量评估

开始

根据版本计划，测试计划，制定测试执行策略

第一个版本测试策略

测试范围以及和计划相比的偏差

建议以是否可测作为判定标准

本版本的测试目标

以测试对象-测试方法-测试结果这样的方式来描述测试目标的好处是:强调了这个 版本测试的要求，比数字指标更易于被测试团队理解和执行。

需要重点关注的内容

测试用例的选择

测试执行顺序

配置测试→功能测试→功能交互测试→满规格测试

先执行高优先级特性的测试→再执行中、低优先级测试用例

先执行复杂、难的测试用例、再执行简单的测试用例

试探性的测试策略

这些全局因素对被测试对象究竟有多大的影响，谁都不太容易说清。如果把这些因素 全面测试-遍，测试工作量会呈指数级增加，如果不测试又总让人觉得不放心。对这种情 况，我们可以“策略性"地进行“试探测试”:

接受测试策略

回顾

跟踪测试执行

跟踪测试用例执行情况

测试团队的测试执行顺序是否和测试策略相符

测试内容和测试策略中确定的范围、深度和广度一致。 测试执行的顺序和测试策略一致。 计划测试的内容能够被顺利执行。

被阻塞的测试用例

测试人力不足。 测试时间不够。 测试环境不具备(包括测试工具、上下行配合的设备、软件等)。 由于其他缺陷导致该测试用例无法执行。

每日缺陷跟踪

每天跟踪缺陷非常重要，需要实时关注测试中的：

缺陷的趋势是否正常? 是否存在因为缺陷修改引入的缺陷? 在本版本中必须解决哪些缺陷? 在本版本中需要解决哪些缺陷?

调整测试策略

版本质量评估

使用软件产品质量评估模型来进行质量评估

记录需求和现实的偏差

我们很难在测试之前就知道系统中存在这样的错误一事实 上，出现这样的问题，往 往是开发人员对需求的理解出现了偏差;或是需求文档在描述这部分的时候没有说清楚, 导致开发人员的实现和测试人员理解的需求存在了分歧。

测试过程评估

方法回顾

投入回顾

测试用例

首次执行通过率、累积执行通过率、累积执行率

质量一测试用例首次执行通过率高，说明开发的版本质量不错(当然也有可能是测试用例 设计太差，不能有效发现问题);相反，如果开发需要多次修复，最后才能使得测试用例执 行通过，说明版本质量可能不高，产品在设计、编码方面可能存在一些问题，即便是修复 bug， 在修复时引人新bug的风险也会更大一些。

版本质量评估中的缺陷分析

密度评估

年龄分析

版本缺陷触发因素

调整测试策略

建立特性版本质量档案

后面的版本测试策略

回归测试策略

回归测试是一-种“确认”性质的测试，测试目标有: 1.缺陷回归:确认测试中发现的缺陷被开发人员正确修复了。 2.功能回归:确认老功能不会因为新合入的功能而失效。 3.阶段回归:确认产品当前的质量达到该阶段的质量目标。

探索式测试策略

这个策略最大的坏处是缺陷可能会在探索测试阶段再集中爆发一次，使得缺陷迟迟不 能收敛，造成测试项目延期。（考虑提前）

自动化测试策略

回顾

阶段质量评估

阶段质量评估项目

总体测试策略中的质量目标是否完成

重要的质量目标红线

测试覆盖度

测试过程

缺陷

未达到的一般性质量目标制定应对措施

非测试用例发现Bug的原因分析

组合缺陷分析

缺陷密度 缺陷修复率 缺陷趋势分析 缺陷年龄分析 缺陷触发因素分析

非测试用例发现缺陷的原因分析

组合缺陷分析

遗留缺陷分析

缺陷对用户的影响程度。

缺陷发生的概率。

有条件必然重现

有条件概率重现

无规律重现

无法重现

缺陷风险评估和规避措施。

不能遗留的缺陷

致命缺陷

没有规避措施的缺陷

临近发布时的缺陷修复策略

非必然重现bug的处理

在进行遗留缺陷分析时，我们讨论了缺陷发生的概率，对那些非必然重现的bug(指 “无规律重现"和“无法重现"的bug),也需要定期进行跟踪和处理。 在实际项目中，我们常常发现一些开发人员和测试人员对非必然重现bug的处理存在 问题，如: 1.一些开发人员认为问题不能复现，即使测试提交了bug也无法修改，提出来也没用, 需要测试人员找到复现的条件后才能提bug。 2.一些测试人员遇到非必然重现问题时，认为出现概率很小，可以不提bug。 3.一些开发人员认为非必然重现问题如果经过一两个测试版本都没有出现，就可以关 闭。 上面的这些处理方式都是错误的。这就需要软件测试架构师和测试经理、开发代表等 在测试团队、开发团队中对非必然重现的问题达成共识: 1.测试人员发现非必然重现的bug，也需要提bug。但是需要特别做好问题的记录，并 在问题出现的第--时间找开发人员定位。 2.Bug复现不仅仅是测试人员的工作，开发人员和测试人员可以一-起复现bug。 3.未复现的bug不应该随便关闭。 对最后一点，那些一直未能复现的bug,需要软件测试架构师定期将这些bug汇总，选 择优先级高的缺陷，组织开发人员和测试人员专门投人到复现问题，如果经过这样的专门 复现依然不能复现，可以降低问题的优先级，直到bug的优先级降至最低，该bug才可以 关闭。 在项目前期，对非必然重现bug的跟踪周期可以稍长一些，越到项目后期，越要加强 对非必然重现bug的跟踪、复现工作。

总结

发布阶段

如何才能制定好测试策略

理解测试策略

什么是测试策略

“测试策略”通俗来讲就是6个字:“测什么”和“怎么测” 具体来讲，就是答好和产品测试相关的六大问题: 1.测试的对象和范围是什么? 2.测试的目标是什么? 3.测试的重点和难点是什么? 4.测试的深度和广度? 5.如何安排各种测试活动(先测试什么，再测试什么) ? 6.如何评价测试的效果?

测试策略等于测试方针？

测试策略并不等同于测试方针，但这是很容易被我们混淆的一对概念。 那么什么是测试方针呢? 测试方针是产品测试中的通用要求、原则或底线。 通用是测试方针的显著特点:它不针对某个特定产品，而是一个产品族，或是一个产 品系列，并且在较长的一段时间内都是适用的。 测试方针举例: 产品的缺陷修复率要达到75%以上，才能发布。 开发转给测试的版本，需要进行自测，并出具测试报告。 对发布版本，无论代码修改了多少，都要对基本功能进行回归测试。 产品升级后发现有功能丢失了，这类缺陷的等级为严重。 测试策略仅针对当前特定的产品版本而言，并不像测试方针那样具备通用性。反过来， 我们倒是可以这样理解测试策略: 遵循测试方针+项目实际情况=测试策略 测试策略需要遵循测试方针，并不意味着我们不能根据项目的实际情况来对测试方针 进行调整。 以产品的缺陷修复率要达到75%以上，才能发布这条测试方针为例。如果当前某个特 定产品版本，对产品质量的要求特别高，在制定测试策略的时候，我们可以考虑将这条测 试方针调整为“产品的缺陷修复率要达到90%以上，严重以上的缺陷修复率为100%”。

测试策略等于测试计划？

测试策略也不是测试计划，它们之间的关系是:通过测试策略确定的测试活动，在测 试计划中被拆解为-一个个任务，并为每个任务确定工期、执行的先后次序和责任人

此外，测试计划的制订者是测试经理，属于测试管理的范畴。而测试策略的制定者是 软件测试架构师，属于测试技术的范畴。

测试策略等于测试方案？

根据我的调查，很多公司并没有区分测试策略和测试方案，事实上测试策略和测试方 案并不相同。 1)测试方案主要解决的是特性在测试设计和测试执行方面的问题 测试策略要解决的是产品测试的六大问题。显然，测试方案就是如何对特性进行测试设计和如何安排这个特性的测试执行，具体包括: 1.对特性的需求、场景、设计进行分析，提取测试点。 2.对测试点选择合适的测试设计方法(如使用怎样的测试设计模型、测试数据的选择),生成测试用例。 3.自动化测试设计。 4.测试执行时需要按照怎样的顺序来执行这些测试用例。

2)测试方案需要遵循测试策略 测试方案需要遵循测试策略对具体某个特性的测试深度和广度的要求。 例如，某测试策略对特性A和特性B的测试说明

从责任人的角度来说，测试策略的责任人是软件测试架构师，而测试方案的责任人是 各个特性测试责任人。

<div>四步测试策略制定法 </div>

明确“产品质量目标”

1)我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标

2）围绕产品质量目标进行刚刚好的测试

3）将目标——行为——评估形成闭环

进行“风险分析”

1.想要顺利完成测试策略并不是一件容易的事情，总有各种问题会阻碍测试活动的进程。 2.我们要做的测试活动总是很多，整个测试策略感觉很笨重。 这说明我们在制定测试策略的时候，一定漏掉了一些重要的东西。没错，我们漏掉了“风险分析”。 1)提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略 实际项目中真的有很多问题，都会让我们的测试变得举步维艰。

例1:在需求阶段，需求工程师未能提供全面的产品需求文档，导致测试设计时场景缺 失，无法达到测试设计的预期效果。 例2:在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，导致测 试设计遗漏或不准确，无法达到测试设计的预期效果。 例3:在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按 照计划进行测试执行。 例4:在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。

2)基于风险来加强和降低测试投入 一般来说，我们的产品中会存在全新开发的功能和老功能。对一个新开发的版本来说， 老功能在老版本中已经被测试过，质量的起点相比全新开发的功能要高，失效的风险更低。 即使全新开发的功能和老功能的质量目标是一-样的，我们也没有必要等同投入资源一理 想的状态是测试能够基于风险来进行测试:

适配“产品研发流程”

通过前面的讨论，我们了解到制定测试策略需要围绕质量目标，充分考虑风险，根据 风险来对测试活动进行调整，但是有两个问题我们一直没有提及，就是: 1.何时开展测试策略的制定活动? 2.制定测试策略是一次到位，还是要分几次完成? 这就需要我们将测试策略的制定和研发流程结合起来。

1 )测试策略的结构 如果我们希望测试策略能够统领并指导后续的测试活动，制定测试策略的时间就应该 是在项目初期。据我所知，一些公司会要求在需求分析的阶段就开始投人准备测试策略的 制定工作。 但是制定测试策略投人得越早，项目的各种不确定的因素也就越多。软件测试架构师很 难在项目的需求分析阶段，就制定出一-份非常详尽的测试策略。如果测试策略的内容只是一 些大方向、大原则，那么到执行层面很容易就变形，也就违背了我们制定测试策略的初衷。 解决这个问题的方法是，按照产品研发流程，根据在哪个阶段项目能够确定到哪种程 度的实际情况，来为测试策略设计一个符合这种进程的结构。 上图是一个传统研发流程示意图。针对这个研发流程，我们设计了总体测试策略一 阶段测试策略一测试执行策略这样的测试策略结构。

进行“测试分层”

到目前为止，我们已经能够综合考虑研发流程、风险，并基于产品质量目标来制定测 试策略。通过上面的分析，我们可以得到很多测试活动，会发现有那么多要做的事情，现 在的问题是我们该以什么策略去安排这些测试活动? 这个问题的最佳答案就是进行“测试分层”。 测试分层是指将有共同测试目的的测试活动放在一起形成一个组，然后一组一组地逐 一进行测试。

分好层后，我们只要确定先测哪层，再测哪层，就能把各种测试活动安排下去了。对 软件测试架构师来说，这比一个个去考虑先做什么测试活动，再做什么，效率要高很多， 也能够让测试的整体思路变得更为清晰。 对测试团队来说，分层测试后，每层的测试内容、测试重点和测试方法都会有所不同， 可以减少测试团队总是感到在重复执行相同内容的困惑，增加新鲜感。 但是，这些都不是测试分层最大的价值。测试分层最大的价值在于:通过测试分层， 我们能够将一个大的测试目标，分到不同层次中分阶段去完成;合理的测试分层，能够让 测试目标SMART化。能够让我们将目标(产品质量目标)一行为(测试活动) 一评估(质 量评估)的闭环，真正在产品测试中落地。

产品质量评估模型

优秀的产品质量评估模型的特征

产品质量评估中的常见的几个场景： 场景1:项目计划的时间到了，就发布产品 场景2 :将缺陷修复率作为产品的质量目标。产品必须达到一定的缺陷修复率，才能发布。 场景3:我们为产品建立了很多指标来作为质量目标，如缺陷修复率、测试代码覆盖率等。 产品必须达到制订的质量目标，才能发布。

综上，一个优秀的产品质量评估模型，应该具备如下特质: 1.多维度:能够覆盖质量评估的各个纬度，能够帮助评估者全面分析和考虑。 2.定量+定性:指标和分析相结合，能够有效避免在只有指标的情况下，被“绕”过 去，变得形同虚设。 3.过程+结果:不仅评估测试的结果，还对过程进行分析和评估。

软件产品质量评估模型

测试覆盖度评估

需求覆盖度评估

需求覆盖度：已经测试验证的产品需求数和产品需求规格总数的比值定量指标 路径覆盖度：已经测试到的语句的数量和程序中可执行语句的总数量的比值定性分析

需求覆盖度的目标是100%

需求覆盖度评估有两种方法： 1.直接在需求表中确认测试情况 2.建立测试用例和需求的对应关系

方法2的优势是，测试能够从一开始就保证需求的覆盖，从源头上避免了需求遗漏的 风险;还很容易通过不同的测试设计方法，让不同优先级的需求能够有不同的测试深度, 更利于软件测试架构师对整个项目进行把控。 但是方法2也有一些需要注意的地方: 1.需要注意需求变化的部分:特别是在项目后期“增加”“修改”和“删除”的需求，避免遗漏。 2.方法2和测试设计的关系变得比较紧密，测试设计遗漏可能会影响对需求覆盖度的评估。 另外在实际项目中，需求和测试用例的对应关系，可能也并不像前面表格的例子中那 样标准的一对一的关系，而是一对多、多对一或多对多这种比较混乱的情况，要想手工维 护好这些关系并不是-件容易的事情，特别是当遇到需求发生变化了，或是通过缺陷来增 加测试用例等情况的时候，要修改的地方就更多了。所以，方法2最好能够有工具支持。

路径覆盖度评估

语句覆盖：覆盖系统中所有判定和过程的最小路径集合 分支覆盖：覆盖系统中每个判定的所有分支所需的最小路径数 全覆盖：100%地覆盖系统所有可能的路径的集合 最小线性无关覆盖：保证流程图中每个路径片段能够被至少执行- -次的最少的路径组合

1.可以将最小线性无关覆盖作为-一个基本的路径覆盖方式。 2.对优先级高的功能特性，可以在最小线性无关覆盖的基础上增加一些路径。 3.对优先级低的功能特性，可以在最小线性无关覆盖的基础上减少一些路径。 4.不建议使用全覆盖，也不建议使用语句覆盖。

测试过程评估

测试用例评估

测试用例执行率。 测试用例执行通过率。 测试用例和非测试用例发现缺陷比。

可能会有以下情况影响测试用例的执行率： 1.测试阻塞:指测试用例因为产品开发(一般是指缺陷)、测试(如测试环境不具备) 等原因，无法被执行的测试用例。 2.未执行:指可以执行，但是因为进度、人力或其他原因等还没有被执行的测试用例。 对“阻塞"这种情况，软件测试架构师需要提前识别这些问题，进行风险识别和控制， 如果这些问题已经是“缺陷”了，就需要要求开发人员优先解决这些问题。 此外，软件测试架构师还需要对测试用例划分优先级。这样在项目进行或者人力紧张 的情况下，就可以优先保证高优先级的测试用例执行率，不执行某些低优先级的测试用例。 有时，一个测试用例会被反复执行多遍，在统计测试用例执行率时，反复执行的测试 用例只用被记录一一次。例如我们需要执行的测试用例有2000个，已经执行的测试用例有 200个，其中有100个测试用例执行了2遍，此时的测试用例执行依然为200/2000=10%， 而非( 100x 2+100 ) /2000=15%。

测试用例执行通过率是指“测试用例执行结果为‘通过’的测试用例数”和“已经执 行的测试用例数目”的比值。由于一个测试用例可能会被反复执行多次，按照测试用例是 在第一次执行时就通过的，还是在后续测试时通过的，我们将测试用例执行通过率细分为 如下两项: 1.测试用例首次执行通过率:指“第一次执行该测试用例的结果为‘通过’的测试用 例数”和“已经执行的测试用例数目”的比值。 2.测试用例累积执行通过率:指“测试用例结果为‘通过’的测试用例数”和“已经执 行的测试用例数目”的比值。 测试用例首次执行通过率可以帮助我们评估开发版本的质量一测试用例首次执行通 过率越高，说明开发的版本质量不错;相反，如果开发需要多次修复，最后才能使得测试 用例执行通过，说明版本质量可能不高，产品在设计、编码方面可能存在一些问题，即便 是修复bug,在修复时引入新bug的风险也会更大。 测试用例累积执行通过率可以帮助我们评估产品在发布时的质量。一般说来，测试用 例累积执行通过率越高，说明当前的版本质量可能已经达到了基本要求，可以考虑发布。

测试人员在按照测试用例执行测试的时候，也会抛开测试用例，自我发挥，做些随机测试。 显然，随机测试也能发现缺陷，有时候甚至比测试用例更能发现产品缺陷，而且“突 然一个灵感来了，然后去测试，并且真的发现了产品缺陷"的过程，会让人很有成就感。 因此在团队中，我们往往会鼓励大家在执行测试用例的时候适当进行--些发散测试，挖掘 bug，找找感觉。 我们希望“通过测试用例发现的缺陷”和“发散测试，也就是非测试用例发现的缺陷 的比值能够在一个合理的范围内。 如果比值过低，即大部分缺陷都是通过发散测试发现的，可能的问题是: 1.随机测试投入过多。 2.测试设计水平不高，存在测试设计遗漏。 3.对产品的需求或者设计的理解不正确、不准确或者不深人，存在测试设计错误。 如果比值过高，大多数缺陷都是通过测试用例发现的，可能的问题是: 4.测试人员不愿意进行发散测试(这样的测试团队可能也是一-个比较沉闷、缺乏激情、只是完成任务的测试团队)。 5.测试投人不足，没有时间进行发散测试。 6.测试思路还没有打开。如果存在这种情况，说明测试设计可能也不够全面。 软件测试架构师可以在测试之前先确定好-一个目标范围，并围绕目标来安排测试活动。 在项目过程中，如果出现偏差，需要对缺陷进行分析，更新测试策略。

测试方法分析

测试投入分析

测试责任人、能力、投入阶段、投入工时

缺陷分析

缺陷密度

缺陷密度是指每千行代码发现的缺陷数。我们在确定了缺陷密度后，还可以顺带得到 缺陷总数。对一个产品研发项目而言，确定、分析缺陷密度的重要意义在于: 1.通过缺陷密度，我们可以预测产品中可能会有多少缺陷。 2.通过缺陷密度，可以帮助我们评估当前已经发现的缺陷总数是否足够多。如果“缺 陷密度”和预期偏差较大，原则上不应该退出测试，发布产品。

缺陷修复率

缺陷修复率能够帮助我们确定当前产品发现的缺陷是否被有效修复，为当前的产品质 量是否达到测试质量目标提供最直接的判断依据。这需要我们: 1.在每个测试分层(如集成测试、系统测试)开始的时候确定缺陷修复率目标。 2.在每个测试分层结束时判断是否达到目标，是否可以进入下一阶段的测试。 3.如果最终的缺陷修复率不能达到预期，原则上不应该退出测试，发布产品。 有时候产品的缺陷实在太多，为了保证重要缺陷能够被优先修复，我们可以对缺陷按 照严重程度进行划分，然后按照不同的严重程度来确定缺陷修复率。

严重程度

致命

缺陷发生后，产品的主要 功能会失效，业务会陷入瘫痪 状态，关键数据损坏或丢失， 且故障无法自行恢复(如无法 自动重启恢复)

(1)产品主要功能失效/和用户期望不符，用户无法正常使用; (2)由程序引起的死机、反复重启等，并且故障无法自动恢复; (3)死循环、死锁、内存泄露、内存重释放等; (4)系统存在严重的安全漏洞; (5)用户的关键数据毁坏或丢失并不可恢复

严重

缺陷发生后，主要功能无法 使用、失效，存在可靠性、安 全、性能方面的重要问题，但 在出现问题后一-般可以自行恢 复(如可以通过自动重启恢复)

(1)产品重要功能不稳定; (2)由程序引起的非法退出、重启等，但是故障可以自行恢复; (3)文档与产品严重不符、缺失，或存在关键性错误; (4)产品难于理解和操作; (5)产品无法进行正常的维护性; (6)产品升级后功能出现丢失、性能下降等; (7)性能达不到系统规格; (8)产品不符合标准规范，存在严重的兼容性问题

一般

缺陷发生后，系统在功能、 性能、可靠性、易用性、可维 护性、可安装性等方面的一般 性问题

(1)产品一般性的功能失效或不稳定; (2)产品未进行输入限制(如对正确值和错误值的界定); (3)一般性的文档错误; (4)产品一般性的规范性和兼容性问题; (5)系统报表、日志、统计信息显示出现错误; (6)系统调试信息难于理解或存在错误

提示

缺陷发生后，对用户只会 造成轻微的影响，这些影响一 般在用户可以忍受的范围内

(1 )产品的输出正确，但是不够规范; (2)产品的提示信息不够清晰准确，难于理解; (3)文档中存在错别字、语句不通顺等问题;  (4)长时间操作未给用户提供进度提示

缺陷趋势分析

缺陷趋势是指“随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势”。 我们进行此项分析的重要原因在于:缺陷趋势分析能够帮助我们判断当前系统是否还能很 容易地发现缺陷，进而帮我们确定是否可以退出测试，发布产品。

绘制缺陷趋势图

记录每天“发现的缺陷数”和“解决的缺陷数”，并由此算出每天“累积发现的缺陷数”和“累积 解决的缺陷数”即可，去掉非工作日。

缺陷趋势曲线的“凹凸性”和“拐点”

数学中对曲线趋势进行分析时，会用到“凹凸性”和“拐点”的概念。简单来说，拥 有凹函数特性的曲线，呈现出递增的变化趋势;反之，拥有凸函数特性的曲线，呈现出递 减的变化趋势;而拐点就是凹函数和凸函数中间的连接点，即函数的变化趋势出现改变的 点在这里，我们将借用数学中的“凹凸性”和“拐点”的概念，来对缺陷趋势进行定性 分析。

拐点的出现，意味着测试团队在这个 测试阶段里已经无法有效发现产品的缺陷了。 出现这种情况，可能的原因有: 1.测试团队的投入发生了变化(如人员调动或者减少)，并且已经影响了测试。 2.测试发生了阻塞(如产品质量差，存在会阻塞测试执行的缺陷)，无法有效开展测试活动。 3.测试策略不当，当前的测试方法确实已经发现不了产品的缺陷了。 显然，无论是上述哪种情况，只要我们“对症下药”，有针对性地更新测试策略，都能 有效地解决上述的问题。例如，第一种情况我们可以想办法调整测试的人力投人，使其更 为合理;第二种情况我们只需要确定并清除造成阻塞的原因即可。

这说明在这个测试阶段里，测试团队依然可以发现产品大量的问题。出现这种情况，可能的原因是: 1.测试团队未按照测试策略进行测试，可能使用了更多、更复杂的方法来发现产品缺陷。 2.版本质量太差，缺陷密度高于预期。 出现第一种情况，这个团队的测试者水平应该比较不错(至少掌握的测试方法比较多); 也应该比较有测试激情(不是按照软件测试架构师要求的任务测完就结束了，而是自己主动 去发现系统更多的问题);另外版本的质量可能也不错(至少还能够使用各种测试方法来“折 腾”系统)，没有严重的测试阻塞。但这依然需要软件测试架构师和测试者仔细核对测试计 划，确认测试者是在保证了测试计划的前提下才进行发挥的一核对的过程可能会让人感 到有些尴尬，但我们的核心理念是:通过测试策略来进行“刚刚好”的测试，而不仅是为 了发现产品的缺陷。 所以，我们的测试内容会包含一些不太容易发现缺陷，但很重要的项目。我们必须保 证对这部分内容的确认，尽管这可能影响我们发现的缺陷总数。 如果确认发现测试计划存在偏差，需要在下个版本中进行补充测试，并和测试者做好 沟通。 出现第二种情况，软件测试架构师可以考虑从如下几个方面来更新后续的测试策略: 1.增加相关内容的测试用例执行次数。 2.加强相关内容的回归测试。 3.对发现的缺陷进行逆向分析，增加探索式测试。

缺陷是否收敛

判断缺陷是否收敛根据以下二个条件，缺一不可： 1.“累积发现的缺陷趋势”变成凸函数 2.“累积发现的缺陷趋势”和“累积解决的缺陷趋势”两条曲线越来越靠近，最后逐渐趋于一点。

缺陷年龄分析

继承或历史遗留

需求阶段引入

设计阶段引人

编码阶段引入

新需求或变更引人

缺陷修改引入

缺陷触发因素分析

就是对测试中使用的测试方法进行分析

确定缺陷的测试方法和测试类型

统计各种测试方法发现的缺陷数目，绘制分析图

进行缺陷触发因素分析

组合使用各种缺陷分析技术

缺陷密度

(1)预测产品可能会有多少缺陷; (2)评估当前发现的缺陷总数是否足够多

缺陷修复率

发现的缺陷是否已经被有效修复

缺陷趋势分析

系统是否还能被继续发现缺陷

缺陷年龄分析

每个可能引人缺陷环节，可能引人的缺陷是否都已经被有效去除

缺陷触发因素分析

测试是否已经足够全面

风险分析技术

风险分析

风险识别

Step1:首先分析测试设计需要关注哪些内容。例如: 1.需要对某个重要的特性进行深入的测试，需要能够通过路径分析法来对开发人员的 设计流程进行全面的覆盖，不遗漏基本的流程。 2.需要能够通过功能交互分析对功能间的相互作用进行深入的测试。 3.需要能够进行压力、稳定性和性能方面的测试。 Step2:分析上述内容都能够保质保量顺利地进行，需要哪些条件。例如: 条件1 :开发能够提供相关的设计材料(如相关的概要设计文档)，并且能够保证材 料的内容是正确的。 条件2:有条件或者有机制能够保证开发人员和测试人员之间的有效沟通。 条件3:测试人员对产品的使用场景、多个特性都有一定的理解，能够进行全面的功 能交互分析。 条件4:测试人员能够理解并掌握压力、稳定性和性能方面的测试方法，有能力结合 测试方法和产品实现来进行测试设计。 Step3 :逐一分析这些条件是否能够满足。假如条件1和条件4可能无法满足，那么识 别出来的风险点就是: 风险1:开发可能会缺失重要的设计文档，或者一些设计文档更新不及时。 风险2:测试人员对压力、稳定性和性能方面的测试方法掌握不足，可能会出现测试设 计遗漏。 需要特别说明的是，虽然此处我们进行风险分析的对象是测试策略，围绕测试活动能 否正常展开，但并不等于我们只在测试内部识别风险点一我们依然要从整个项目 的角度 来进行风险识别。我们可以使用表6-17风险识别清单，来帮助我们进行风险识别。

需求

产品的业务需求、用户需求、功能需求和系统需求是否完整、清晰? 开发人员在进行产品设计之前是否充分理解了产品的需求?

设计

是否使用了“新技术”? 系统中是否会存在一些设计“瓶颈"?如果存在，是否有应对措施? 产品是否设计得过于复杂，难以理解? ! 开发人员是否能够讲清楚产品设计? 开发人员对异常、非功能方面的内容是否考虑得足够全面? 开发人员在设计中是否存在一些比较担心的地方? 开发人员是否会考虑和设计一些可测试性或者易于定位的功能? 对一个需要多人(或多组)才能配合完成的功能，是否有人会进行整体的设计、协调和把关? 对有依赖或约束的内容，是否有充分考虑?

流程

项目是否使用了新的流程、开发方法等? 开发人员是否会进行自测?是如何进行自测的?测试的深度和发现问题的情况如何? 开发人员如何进行代码修改，是如何保证修改的正确性的? 开发人员是如何进行版本管理的?

变更

新版本在旧功能方面做了哪些修改?修改后的主要影响是什么? 在项目过程中，需求是否总是在变更?

组织和人

哪些模块是由其他组织开发的?他们在哪里开发?开发流程、能力如何? 、产品的研发团队(包括需求、开发和测试)是否存在于不同的地方?彼此分工如何?沟通是否顺畅? 团队人员能力如何?经验如何(包括需求、开发和测试团队) ? 团队是否稳定(包括需求、开发和测试团队) ? 团队的人手是否充足(包括需求、开发和测试团队) ? 测试环境是否具备(包括必备的工具、硬件设备) ?

历史

哪些特性在产品测试时就存在有很多bug? 哪些特性存在较多的客户反馈问题? 历史上哪些情况曾经导致过阻塞测试活动的问题?

风险评估

机会成本告诉我们，要想用有限的资源获得最大的收益，就需要我们优先处理最可能 会发生、影响(如损失)最大的事件。这就需要我们对识别出来的风险点进行评估，确定风 险优先级，然后优先处理高风险的问题。简言之，风险评估的目标就是确定风险优先级。

根据风险发生频率、影响程度

需求类风险

高级

设计类风险

高级

流程类风险

中级

历史类风险

高

风险应对

回避风险:指主动避开损失发生的可能性。转移风险:指通过某种安排，将自己面临的风险全部或部分转移给其他一方。减轻风险:指采取预防措施，以降低损失发生的可能性和影响程度。接受风险:指自己理性或非理性地主动承担风险。

“风险应对”举例:新需求在开发过程中不断被增加 1“回避风险”的做法:置之不理。 2“转移风险”的做法:将新需求外包。 3“减轻风险”的做法:寻求额外资源或裁剪其他优先级低的需求。 4“接受风险”的做法:将新需求加入项目范围，通过加班来完成新需求。

子主题

老功能分析

对老功能进行风险分析，确定老功能在新版本中的测试深度和广度，指定“刚刚好”的测试策略

1.差异性分析

在新版本中做好老功能测试金钥匙

差异性分析沟通提纲： 和之前相比，产品的“底层”或一些“公共模块"是否有修改?为什么要进行修改?修改的代码量有多: 大?据你所知，这些修改可能会影响哪些功能? 和之前相比，“x x功能”是否进行了功能、性能、可靠性、可维护性、易用性、可移植性、可维护性方 的优化?为什么要进行优化?修改的代码量有多大?这些修改会影响其他功能吗? 和之前相比，和“x x功能”相关的开源代码是否进行了版本升级? 和之前相比，“x x功能”的流程是否有所变化?变化有是哪些? 和之前相比，新版本在资源分配(如内存、CPU的分配)上有什么不同，是否会对“x x功能"造成影响?  针对修改，你(开发)准备做哪些自测(或已经做了哪些自测)? 有没有我(测试)需要特别关注的地方?

2.历史测试情况分析

1)确认老功能在新版本和老版本中的质量要求是否致

2）进行测试方法分析

进行功能、可靠性、性能、易用性、可维护性等测试时使用了哪些测试方法?深度如何?是否达到预期? 测试过程中使用了哪些测试工具?使用情况如何? 是否进行了探索性测试?效果如何? 回归测试情况如何? 场景测试情况如何? 自动化测试情况如何?

3）进行缺陷分析

老功能在老版本中存在哪些遗留缺陷?缺陷被遗留的原因是什么?哪些遗留缺陷必须在新版本中解决? 老功能在老版本中发现缺陷的数量是否符合预期?如果不符合预期，分析可能的原因。对此，是否需要在新版本中增加一些测试内容? 老功能在老版本中发现缺陷的手段是否丰富?哪些手段需要在“新版本”中加强? 从老功能在老版本中发现的缺陷来看，是否存在测试策略漏测、测试设计漏测和测试执行漏测?是否需要 在新版本中增加相应的内容?

4）对“组织和人”进行分析

测试团队人员经验如何? 测试团队是否稳定?例如，是否在测试过程中出现人员离职、被动更换测试人员的情况? 测试团队是否有一些测试总结或技术总结?如果有，这些总结一定要收集过来，会是很好的参考材料

分层测试技术

V模型

设计测试层次

我们将分层测试运用在测试目标的SMART化上和测试活动的安排上。对软件测试架 构师而言，可能需要根据实际情况来设计自己项目的分层测试，分层测试中的主要技术， 就是如何通过适当的分层，让测试目标变得“SMART"。

测试策略实战攻略

开始

<div>初次使用“四步测试策略制定法” </div>

产品质量等级

虽然我们已经有了产品质量评估模型，但该模型只能告诉我们该从哪些角度去评估产 品质量，并没有告诉我们，怎样的评估结果可以被认为是好的质量，怎样的结果又是不好 的质量。换句话说，我们还缺少一个评价质量的“刻度”，即产品质量等级。

从最终用户使用的角度，我们将产品质量分为如下4个等级。 第1级完全商用:特性完全满足用户的需求，有少量(或者无)遗留问题，用户使用时无任何限制。 第2级受限商用:特性无法满足用户的某些特定场景，有普通以上的遗留问题，但有规避措施。 第3级测试、演示或小范围试用:特性只能满足用户部分需求，有严重以上的遗留问题，且无有效的规避措施，问题一旦出现就会影响用户的使用，只能用于测试(如Beta)或演示，或者小范围试用。 第4级不能使用:特性无法满足用户需求，存在严重以上的遗留问题，会导致用户基本功能失效，且无规避措施，产品根本无法使用。

确定项目中各个特性的质量等级

对项目整体进行风险分析

确定测试策略的结构

对软件测试架构师来说，此时的主要目标就是确定测试策略的结构，明确我们的测试 策略要分几次输出，何时输出，每次输出的关注点是什么。

1.总体测试策略:确定产品质量目标，进行项目整体的风险识别，从产品层面来确定测试重点和测试难点、测试深度和测试广度，是测试策略的纲。 2.阶段测试策略:确定测试设计策略和测试执行策略需要达到的质量目标(产品质量目标的分解)以及能够进行这些测试活动的入口条件。 3.测试执行策略:确定每个版本的测试目标、测试内容和每个版本的入口条件。

初步确定测试分层

测试分层、研发流程和测试策略结构的对应关系

回顾

1.明确了特性的质量等级，并且和各个研发核心团队的成员就质量目标达成一致意见。 2.从项目整体角度进行了风险分析，有了需要做哪些质量保证活动的初步计划。 3.确定了测试策略的结构为总体测试策略一阶段测试策略一-测试执行策略。 4.初步确定了测试分层，并且梳理出了测试分层、研发流程和测试策略结构的对应关系，初步建立了一个测试的框架。

制定总体测试策略

分解产品质量目标

分解质量等级

1.根据质量等级来分解产品的质量目标

定量指标分级标准

2.为每个测试分层确定测试目标

完全商用示例表

使用老功能分析法来对特性进行分类

1.哪些特性是新开发的。 2.哪些是从老版本上继承而来的。 3.哪些特性的改动估计会比较大。 4.从老版本继承而来的特性的历史测试情况。

基于质量和风险来确定测试深度与测试广度

1.测试深度是指在测试过程中需要使用的测试方法。 2.测试广度是指测试的范围。 例如，特性A包含了三条需求，每个需求又对应了两条用例。测试广度就是指这三条 需求以及这三条需求对应的六条用例。而测试深度是指我们会用怎样的测试方法来测试验 证这三条需求和六条用例

1.使用产品质量评估模型来初步确定测试深度

2.考虑用老功能分析来更新测试深度

3.基于老功能分析来初步确定测试广度

确定测试优先级

确定测试优先级的一一个简单的方法是使用评分表。我们 首先对质量目标和分类分别设置一定的分值

质量目标分值表

完全商用

受限商用

测试、演示或小范围试用

分类分值表

全新特性

老特性变化

老特性加强

老特性不变

优先级的分数范围

高

6~8

中

3~5

低

1~2

确定优先级特性后估算测试深度和广度

测试投入策略

高

(1 )中级或中级以上的测试工程师; (2)保证足够的测试投人工时; (3)尽量不在项目中途更换测试责任人

中

(1)初级或中级测试工程师; (2)尽量保证足够的测试投人工时，不排除减少投人工时的情况

低

(1 )初级测试工程师或实习生; (2)尽量保证足够的测试投人工时，不排除减少或不投人工时的情况

确定测试的总体框架

策略层

活动层

保证层

回顾

总体测试策略

测试投入策略

制定阶段测试策略

使用测试分析设计表来保证测试设计符合测试策略

测试设计策略

测试用例等级

1.基本功能类测试用例

功能测试一单运行顺序执行 (对流程类的测试点一对应的测试路径为 最短路径)

2.单功能类测试用例

功能测试一单运行顺序执行 功能测试一单运行边界值输人

3.功能交互类和非功能类的测试用例

功能测试一多运行顺序执行 功能测试一多运行相互作用 可靠性测试一故障植人法 可靠性测试一稳定性测试法 易用性测试一一致性测试法 易用性测试一可用性测试法 性能测试法 可维护性测试法 可移植性测试法

4.一些操作或是输入上比较严苛的测试用例

可靠性测试一异常值输入法 可靠性测试一压力测试法 可靠性测试一恢复测试法 功能测试一多运行顺序执行 功能测试一多运行相互作用

四步测试设计法和测试广度

集成测试策略

集成

使用黑盒测试的方法来确认新合人的功能是否正确。 验证功能集成后系统功能的正确性。 确认原来的系统功能没有被新合人的功能所破坏。

何时可以开始进行集成测试

条件1:第一个集成计划中的功能开发完成，并完成了单元测试 条件2:第一个集成计划中的功能集成完成，并可测 条件2的重点在于“可测”，即开发需要提供基于用户的输入输出接口，而不能是内部 的函数接口，确保测试能够进行系统级的黑盒测试。 条件3:测试团队已经做好了测试准备。 这里的测试准备，主要包括: 1.测试用例已经输出，并通过了评审。 2.测试资源已经到位。 3.测试环境已经准备好。

测试用例选择

1.针对功能确认的测试，可以选择相关功能level 1的测试用例。 2.针对“测试新功能集成”的测试，可以选择相关功能level 2的测试用例和部分level 3 的测试用例。 3.针对“确认原系统”的测试，可以选择相关功能中level 1的测试用例。 其中“部分level3的测试用例”是指在集成测试后期，系统已经相对比较成熟和稳定 的时候，也可以适当选择-一些性能、稳定性和压力方面的测试用例来进行测试，以避免这 些“非功能”方面的问题在系统测试阶段密集爆发。

出口准则

系统需要集成的功能已经全部开放、集成完成。 计划执行的测试用例已经完成。 缺陷分析的结果符合预期。 达到了集成测试阶段的产品质量目标。

系统测试策略

入口准则

测试用例选择

现在我们来回答本节开头提的问题:我们在集成测试中执行了的测试用例，在系统测 试中还需要再执行一遍吗? 答案是，系统测试和集成测试的测试用例肯定会有相同的部分，但并不是简单地重复 一遍，而是存在一定的选择策略。 1.针对“系统角度的功能测试":可以选择levell和部分level2的测试用例。 2.针对“非功能的质量的正确性”:可以选择level3的测试用例和level4的测试用例。

测试执行顺序

测试执行顺序是指先执行哪些测试用例，再执行哪些测试用例，或者说先使用哪些测 试方法，再使用哪些测试方法。 我们在集成测试中并没有讨论测试执行顺序，是因为集成测试的测试对象很单一，就 是“功能”。虽然后面我们提到在集成测试的后期，可以考虑增加一些“非功能方面”的测 试，但是总的来说这并不会给测试带来先执行什么再执行什么的困扰。 和集成测试不同，系统测试需要对功能、可靠性、性能、易用性等各方面进行测试， 如果不考虑测试执行的顺序，很容易遇到阻塞，影响测试的顺利进行。

如果有两种测试方法，都能对测试对象进行测试，先进行复杂的，再进行简单的。 或者说，尽量先执行复杂的、难的测试用例，再进行简单的测试用例。这样考虑的 原因是，希望缺陷能够尽量在测试的前期发现，另外先执行难的测试用例也能保证 这些测试用例有充足的测试时间。 可以考虑组合多种测试方法，或者说让测试者想办法把一些测试用例放在一起执行。

计划执行的测试的用例已经完成。 缺陷分析的结果符合预期。 达到了系统测试阶段的产品质量目标。

验收测试策略

验收测试是产品在发布前的一种测试，它是对用户需求的确认。事实上，我们进行验收 测试已经不再是为了发现产品的问题，而是为产品能够正常发布建立信心。

Alpha测试

测试人员模拟用户进行的测试

谁来进行Alpha测试

理想的Alpha测试人员，应该是不太了解产品实现细节，但是对用户非常了解的人。 按照这个标准，市场人员、系统工程师或是技术支持人员都可以是理想的Alpha测试人员， 他们可以站在用户的视角，对产品质量再次进行审视。 该功能的测试责任人并不适合作为Alpha测试人员，因为他们对自己测试的系统多半 已经出现了“审美疲劳”， 这会阻碍他们再进行有效的Alpha测试。 让测试组员相互进行交叉验收，似乎是个不错的选择一这 确实可以消除“审美疲劳”， 发现一些问题，但是交叉验收却很难达到从用户的角度再去审视一一次产品的效果。与交叉 测试相比，更有效的方法是，测试部专门成立-一个“验收测试组”，由测试部中比较有经验、 测试能力强，且对行业、对用户都有一-定了解的测试人员来担任，让他们来作为产品发布 前的最后-道防线，这无疑是最能保证Alpha测试效果的做法。

Alpha测试策略

下面的清单也许可以帮助我们进行Alpha测试分析，找到产品在Alpha测试中需要关 注的重点内容: 1.用户将会如何学习产品? 2.产品提供的资料(如手册、指南、视频)是否能够对用户提供切实的帮助? 3.用户会将产品安装部署在怎样的环境中(包括用户会使用到的硬件、操作系统、数 据库、浏览器等)。 4.在用户的环境中能否正确升级?升级对业务的影响是否在用户容忍的范围内?升级 对已有功能的影响是否符合用户需求( 如升级后不能丢特性) ? 5.产品在用户的环境中能否被正确移除? 6.产品在用户环境中的上下游设备是什么?在这样的环境中，产品能否正常使用? 口用户环境中可能会有哪些业务?哪些业务是我们产品需要关注的，哪些业务是我们 产品不需要关注的?对那些我们不需要关注的业务，我们的产品会怎么处理? 7.用户的环境中可能会有哪些故障?对这些故障，我们的产品会怎么处理? 8.用户会怎么管理、配置产品? 9.用户会如何使用产品的日志、告警、审计、报表等和运维相关的功能?

Beta测试

由用户参加的测试

1.在产品正式发布之前将产品提前发给用户，收集用户的反馈。 2.在产品开发完成后，交由用户对产品进行验收。 第一种方式下的Beta测试的困难之处在于确定测试的时间和参与者。对测试者来说， 倒不需要对上面两个问题做出决策，而是分析、复现参与者发现的问题，将问题整理为bug 报告，直至确认bug被解决。 第二种方式下的Beta测试，需要保证产品能够通过用户的验收测试，能够交付给用户 使用，这时的测试需要围绕用户的验收方案进行，并结合用户的使用习惯和用户所在的行 业特点，做好充分的准备。

3.入口准则一何时开始进行验收测试 验收测试的人口准则，就是系统测试的出口准则再加上:   a.Alpha测试的人员、方案已经选好。   b.Beta测试的用户已经确定。 4.出口准则一何时可以退出测试， 发布产品 当我们根据产品质量评估模型，确认产品已经达到总体测试策略中的产品质量目标后， 就可以退出测试。

回顾

子主题