测试策略
https://blog.csdn.net/onlyajok/article/details/95909800
1 理解测试策略
1.1 什么是测试策略？
“测试策略”通俗来讲就是6个字：“测什么”和“怎么测”。
具体来讲，就是答好和产品测试相关的六大问题：
测试的对象和范围是什么？
测试的目标是什么？
测试的重点和难点是什么？
测试的深度和广度？
如何安排各种测试活动（先测试什么，再测试什么）？
如何评价测试的效果？
1.2 测试策略等于测试方针？
测试方针是产品测试中的通用要求、原则或底线。
通用是测试方针的显著特点：它不针对某个特定产品，而是一个产品族，或是一个产品系列，并且在较长的一段时间内都是适用的。
测试方针举例：
产品的缺陷修复率要达到75%以上，才能发布。
开发转给测试的版本，需要进行自测，并出具测试报告。
对发布版本，无论代码修改了多少，都要对基本功能进行回归测试。
产品升级后发现有功能丢失了，这类缺陷的等级为严重。
试策略仅针对当前特定的产品版本而言，并不像测试方针那样具备通用性。反过来，我们倒是可以这样理解测试策略：循测试方针+项目实际情况=测试策略
试策略需要遵循测试方针，并不意味着我们不能根据项目的实际情况来对测试方针进行调整。
产品的缺陷修复率要达到75%以上，才能发布这条测试方针为例。如果当前某个特定产品版本，对产品质量的要求特别高，在制定测试策略的时候，我们可以考虑将这条测试方针调整为“产品的缺陷修复率要达到90%，严重以上的缺陷修复率为100%”。
1.3 测试策略等于测试计划？
测试策略也不是测试计划，它们之间的关系是：通过测试策略确定的测试活动，在测试计划中被拆解为一个个任务，并为每个任务确定工期、执行的先后次序和责任人，如图1所示。
图1 测试策略与测试计划的关系
表1 “测试计划”示例
此外，测试计划的制订者是测试经理，属于测试管理的范畴。而测试策略的制定者是软件测试架构师，属于测试技术的范畴。
1.4 测试策略等于测试方案？
1）测试方案主要解决的是特性在测试设计和测试执行方面的问题
测试策略要解决的是产品测试的六大问题。显然，测试方案要解决的问题没有那么“高大上”，就是如何对特性进行测试设计和如何安排这个特性的测试执行，具体包括：
对特性的需求、场景、设计进行分析，提取测试点。
对测试点选择合适的测试设计方法（如使用怎样的测试设计模型、测试数据的选择），生成测试用例。
自动化测试设计。
测试执行时需要按照怎样的顺序来执行这些测试用例。
举例如下：
测试方案模板（以一个“特性”为单位）：
1.××特性的场景
a）用户场景描述。描述用户会如何使用这个特性。
b）测试场景描述。描述测试时会怎样模拟用户的使用，模拟和实际的差别在哪里，是否会有风险，等等。
2.××特性设计分析
a）产品实现中的关键业务流程。
b）重要的算法（或实现技术）的分析。
c）其他需要注意的内容分析。
3.××特性测试分析
a）测试类型分析。
b）功能交互分析。
4.××特性测试设计
对测试点使用四步测试设计法，逐一得到测试用例。
以“树”形结构来组织这些测试用例。
为测试用例划分优先级。
5.××特性测试执行
哪些测试用例准备进行手工测试。
哪些用例计划进行自动化测试。
哪些地方可能还需要进行探索测试。
测试用例是否需要考虑测试执行顺序。
2）测试方案需要遵循测试策略
测试方案需要遵循测试策略对具体某个特性的测试深度和广度的要求。
例如，某测试策略对特性A和特性B的测试说明，见表2。
表2 测试说明
2 四步测试策略制定法
该在什么时候开始制定测试策略？如果在项目开头进行，你会发现很多和测试策略相关的内容根本就还不明了，无从下手；如果在项目后期进行，内容是明了，但是做测试策略的意义又在哪里呢？
可见，我们还是需要一套方法来指导我们制定测试策略的整个过程，“四步测试策略制定法”应运而生，如图2所示。
图2 四步测试策略制定法
2.1 明确“产品质量目标”
明确“产品质量目标”是我们在制定测试策略过程中十分关键的一个步骤。对我们而言，不仅需要关注操作层面的具体方法，更要理解其中蕴含的测试策略思想。
1）我们的测试目标就是让产品在发布的时候能够满足事先约定的质量目标
2）围绕产品质量目标进行刚刚好的测试
3）将目标—行为—评估形成闭环
图3 产品质量评估
如图3：
首先，我们将产品质量评估模型作用于具体的产品，得到产品质量目标。
其次，我们根据产品质量目标来制定测试策略，确定接下来的测试活动。
再次，执行各种测试活动。
最后，对测试效果进行评估，评估产品的质量目标是否达到。
2.2 进行“风险分析”
1）提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略
实际项目中真的有很多问题，都会让我们的测试变得举步维艰。
举例：实际项目中测试活动无法顺利开展的一些例子
例1：在需求阶段，需求工程师未能提供全面的产品需求文档，导致测试设计时场景缺失，无法达到测试设计的预期效果。
例2：在测试设计时，开发未能提供相关的设计文档，或是文档未能及时更新，导致测试设计遗漏或不准确，无法达到测试设计的预期效果。
例3：在测试执行时，发现一些测试用例因为缺陷或者代码提交的原因阻塞了，不能按照计划进行测试执行。
例4：在测试执行时，发现缺陷迟迟不能修改，缺陷分析的结果不能达到预期。
“骨感”的现实告诉我们，需要提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整我们的测试策略，增加一些测试活动或者质量保证活动。
2）基于风险来加强和降低测试投入
2.3 适配“产品研发流程”
何时开展测试策略的制定活动？制定测试策略是一次到位，还是要分几次完成？
这就需要我们将测试策略的制定和研发流程结合起来。
1）测试策略的结构
图4是一个传统研发流程示意图。针对这个研发流程，我们设计了总体测试策略—阶段测试策略—测试执行策略这样的测试策略结构。
图6-4 传统研发流程示意图
有了这样的结构，我们能够将当前的测试策略总是控制在“当下”，即项目的情况总是在比较确定的范围内，避免我们过于纠结“未来”。
2）根据研发流程来安排测试活动
测试策略中具体的内容，也需要和研发流程保持一致，确保测试和开发的节奏能够彼此吻合。
从大层面来说，测试在各个阶段的活动和开发的活动是能够配合起来的，如图6-5所示：
图6-5 测试人员职责
要达到这个大层面的吻合，是比较容易的。相对比较困难的是，是在版本测试阶段，开发活动和测试活动彼此配合的问题。简单地说，就是开发人员在做计划的时候是否考虑了测试活动：
是否只是提交了一个“中间层”而非最后用户可见的功能？提交的功能是否可测？
测试能否有足够的时间进行测试准备？
测试能否在下个版本提交之前完成测试？
这就需要软件测试架构师能够做好版本测试策略，能够和开发人员进行有效沟通，使得双方能够理解彼此的节奏，达到更好的配合。
除此之外，我们即将要介绍的测试分层，也能帮助我们更好地制定版本测试策略。
2.4 进行“测试分层”
到目前为止，我们已经能够综合考虑研发流程、风险，并基于产品质量目标来制定测试策略。通过上面的分析，我们可以得到很多测试活动，会发现有那么多要做的事情，现在的问题是我们该以什么策略去安排这些测试活动？
这个问题的最佳答案就是进行“测试分层”。
测试分层最大的价值在于：
通过测试分层，我们能够将一个大的测试目标，分到不同层次中分阶段去完成；
合理的测试分层，能够让测试目标SMART化。能够让我们将目标（产品质量目标）—行为（测试活动）—评估（质量评估）的闭环，真正在产品测试中落地。
2.5 “四步测试策略制定法”中的测试技术
通过前面的介绍，我们了解到在使用四步测试策略制定法来制定测试策略时，会使用到一些方式或者模型。总的来说，如图6-6所示。
图6 四步测试策略制定法中用到的方式或模型
3 产品质量评估模型
产品质量评估模型将用在测试目标的确定和评估上，它是整个测试策略的基础。在介绍这个重要模型之前，我们想先花一点笔墨来讨论一下一个优秀的产品质量评估模型应该具备哪些特征。
3.1 优秀的产品质量评估模型的特征
产品质量评估中的几个场景：
场景1：项目计划的时间到了，就发布产品。
场景2：将缺陷修复率作为产品的质量目标。产品必须达到一定的缺陷修复率，才能发布。
场景3：我们为产品建立了很多指标来作为质量目标，如缺陷修复率、测试代码覆盖率等。产品必须达到制订的质量目标，才能发布。
结果：
场景1说明测试团队当前还没有产品质量评估的具体办法
场景2和场景1相比，已经有了判断标准，可以说是有质的改变，但场景2也有“软肋”，就是评价的标准太过于单一
场景3看起来很好，但是在实际操作的时候，我们往往会发现，我们费时费力地对这些指标进行了统计、分析和跟踪，最后也都达到了，但是我们对产品质量的好坏依然感到心里没底
我分析出现场景3中的问题，主要原因有3点：
第一，这些指标覆盖的维度可能不全，我们可能遗漏掉了一些重要的考察项。
第二，“指标”本身比较容易被“聪明人”绕过去，变得形同虚设。
第三，整个质量评价体系中全是指标，缺少定性的分析
例如，我们以测试的代码覆盖度要达到90%作为一项质量目标。为了达到这个目标，我们可能会选择一些容易进行测试“覆盖”，但实际上风险并不大的地方进行测试。虽然最终能达到90%的测试覆盖目标，但是没有被测试到的10%那部分情况如何，是否真的不需要测试，可能会有哪些风险，对我们来说都是“未知”的。未知正是心里没底的源头。
如果我们将这个问题从评估引申到目标的层面，如果我们在制订目标的时候，考虑的不仅仅是指标，而能包含一些如“对重要特性，要达到100%的测试覆盖”“测试方法要包含语句覆盖、判断覆盖、路径覆盖”等的描述，以此作为要达到的质量目标，不仅能解决上述的问题，还能更好地帮助我们确定要进行的测试活动。
综上，一个优秀的产品质量评估模型，应该具备如下特质：
多维度：能够覆盖质量评估的各个纬度，能够帮助评估者全面分析和考虑。
定量+定性：指标和分析相结合，能够有效避免在只有指标的情况下，被“绕”过去，变得形同虚设。
过程+结果：不仅评估测试的结果，还对过程进行分析和评估。
3.2 软件产品质量评估模型
我们将从3个方面来建立软件产品质量评估模型，对产品质量进行分析、确定和评估（图7）：
图7 产品质量评估模型
测试覆盖度评估：对测试范围及测试的深度与广度进行分析和评估。（定量指标）
测试过程评估：对测试过程和测试的投入情况来进行分析与评估。（定量指标+定性分析）
缺陷分析：对测试结果进行分析和评估。（定量指标+定性分析）
4 测试覆盖度评估
表3 测试覆盖度评估的定义与属性
4.1 需求覆盖度评估
需求覆盖度的目标必须为100%，即测试保证对产品承诺要实现的需求都进行。
“需求覆盖度”中的“需求”，可以是“包需求”，也可以是“需求规格”“story”“user case”等可以代表项目中产品需求的内容，大家可以根据项目的实际情况来选择。
需求覆盖度评估有以下两种方法：
方法1：直接在需求表中确认测试情况
方法2：建立测试用例和需求的对应关系
方法2是在测试设计的时候，通过编号来建立需求和测试用例的对应关系。这样我们只要保证这些测试用例都被执行了，需求也就都被测试验证了，见表6-5。
方法2的优势是，测试能够从一开始就保证需求的覆盖，从源头上避免了需求遗漏的风险；还很容易通过不同的测试设计方法，让不同优先级的需求能够有不同的测试深度，更利于软件测试架构师对整个项目进行把控。
但是方法2也有一些需要注意的地方：
需要注意需求变化的部分：特别是在项目后期“增加”“修改”和“删除”的需求，避免遗漏。
方法2和测试设计的关系变得比较紧密，测试设计遗漏可能会影响对需求覆盖度的评估。
另外在实际项目中，需求和测试用例的对应关系，可能也并不像前面表格的例子中那样标准的一对一的关系，而是一对多、多对一或多对多这种比较混乱的情况，要想手工维护好这些关系并不是一件容易的事情，特别是当遇到需求发生变化了，或是通过缺陷来增加测试用例等情况的时候，要修改的地方就更多了。所以，方法2最好能够有工具支持，能够通过工具来维护这些对应关系。
4.2 路径覆盖度评估
表6-6 路径分析法总结
第一步：确定路径覆盖策略。
软件测试架构师可以以特性或者功能为粒度，根据该功能的质量目标来确定路径覆盖策略。在如何选择确定路径覆盖策略上，建议如下：
可以将最小线性无关覆盖作为一个基本的路径覆盖方式。
对优先级高的功能特性，可以在最小线性无关覆盖的基础上增加一些路径。
对优先级低的功能特性，可以在最小线性无关覆盖的基础上减少一些路径。
表7 路径覆盖策略的记录
第二步：使用路径分析法设计测试用例。
第三步：跟踪测试用例的执行情况。
当测试团队按照路径覆盖策略完成了用例设计后，对路径覆盖度的评估，就转换为了测试用例执行情况的评估。我们的目标是这些设计的用例能够至少被执行一遍，并且测试结果为“通过”。如果存在测试用例在产品发布的时候都被“阻塞”，无法执行的情况，我们就需要对阻塞的情况进行分析，评估当前的覆盖度是否能够满足测试的基本要求。
5 测试过程评估
5.1 测试用例评估
1.测试用例执行率
2.测试用例执行通过率
3.测试用例和非测试用例发现缺陷比
们希望“通过测试用例发现的缺陷”和“发散测试”，也就是非测试用例发现的缺陷”的比值能够在一个合理的范围内。
如果比值过低，即大部分缺陷都是通过发散测试发现的，可能的问题是：
随机测试投入过多。
测试设计水平不高，存在测试设计遗漏。
对产品的需求或者设计的理解不正确、不准确或者不深入，存在测试设计错误。
如果果比值过高，大多数缺陷都是通过测试用例发现的，可能的问题是：
测试人员不愿意进行发散测试（这样的测试团队可能也是一个比较沉闷、缺乏激情、只是完成任务的测试团队）。
测试投入不足，没有时间进行发散测试。
测试思路还没有打开。如果存在这种情况，说明测试设计可能也不够全面。
5.2 测试方法分析
图8 详细总结图
其中：
“分析测试设计是否和测试策略中的测试方法符合”，可以通过测试设计的过程跟踪、测试评审等方式去跟踪和分析。
“分析测试执行时的测试方法是否符合测试策略”，可以通过测试执行时的日报、周报，测试用例执行情况等方式去跟踪和分析。
“通过缺陷分析来确定测试策略是否需要调整”，主要是对缺陷进行缺陷触发因素分析，相关的内容将在6.6节中为大家详细描述。
5.3 测试投入分析
测试投入分析也是很重要的一项测试过程评估项目，在这里我们主要从测试人员安排和测试投入工作量来进行分析，确认重要的、高风险的特性能够保证测试投入，符合测试策略。
表8 测试投入分析
6 缺陷分析
但是如果我们仅仅把缺陷当成产品问题的记录，而不去挖掘缺陷数据背后隐含的和产品质量有关的信息，就显得太可惜了。
6.1 缺陷密度
缺陷密度是指每千行代码发现的缺陷数。我们在确定了缺陷密度后，还可以顺带得到缺陷总数。
对一个产品研发项目而言，确定、分析缺陷密度的重要意义在于：
通过缺陷密度，我们可以预测产品中可能会有多少缺陷。
通过缺陷密度，可以帮助我们评估当前已经发现的缺陷总数是否足够多。如果“缺陷密度”和预期偏差较大，原则上不应该退出测试，发布产品。
我们能够在产品测试之前，较为准确地预测产品的缺陷密度并将此作为一个测试目标，主要基于如下假设：
在系统复杂度、研发能力一定的情况下，由各个环节引入系统中的缺陷总数也会是基本一致的。
如果我们发现实际的缺陷密度值偏高，通常最可能的原因为：产品整体质量不高。此时，软件测试架构师可以：
提高缺陷密度的预估值。
对缺陷较多的地方增加测试投入，如增加测试人力、增加测试时间、使用更多的测试方法等。
考虑和研发经理、开发人员、系统工程师等一起进行一些质量改进和质量保证工作，如加强评审等。
如果我们发现实际的缺陷密度值偏低，通常最可能的原因为：
产品整体质量较好。
测试能力不足，未能充分暴露缺陷。
测试投入不足，未能充分暴露缺陷。
6.2 缺陷修复率
在每个测试分层（如集成测试、系统测试）开始的时候确定缺陷修复率目标。有时候产品的缺陷实在太多，为了保证重要缺陷能够被优先修复，我们可以对缺陷按照严重程度进行划分，然后按照不同的严重程度来确定缺陷修复率。
1.缺陷的严重程度
表9 缺陷的严重程度的定义与示例
6.3 缺陷趋势分析
缺陷趋势是指“随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势”。我们进行此项分析的重要原因在于：缺陷趋势分析能够帮助我们判断当前系统是否还能很容易地发现缺陷，进而帮我们确定是否可以退出测试，发布产品。
6.3.1 绘制缺陷趋势图
表10 缺陷趋势分析表
我们将表10绘成图，就得到了如图9所示的缺陷趋势分析图。
图9 缺陷趋势分析图
在绘制缺陷趋势分析图时，不要忘记去掉节假日、周末公休日等“没有工作的日子”。
6.3.2 缺陷趋势曲线的“凹凸性”和“拐点”
1）理想的“累积发现的缺陷趋势”曲线
图10 理想的变化趋势
2）“累积发现的缺陷趋势”的“拐点”出现得过早
“拐点”的出现，意味着测试团队在这个测试阶段里已经无法有效发现产品的缺陷了。出现这种情况，可能的原因有：
测试团队的投入发生了变化（如人员调动或者减少），并且已经影响了测试。
测试发生了阻塞（如产品质量差，存在会阻塞测试执行的缺陷），无法有效开展测试活动。
测试策略不当，当前的测试方法确实已经发现不了产品的缺陷了。
3）“累积发现的缺陷趋势”的拐点未出现
这说明在这个测试阶段里，测试团队依然可以发现产品大量的问题。出现这种情况，可能的原因是：
测试团队未按照测试策略进行测试，可能使用了更多、更复杂的方法来发现产品缺陷。
版本质量太差，缺陷密度高于预期。
出现第一种情况，这个团队的测试者水平应该比较不错（至少掌握的测试方法比较多）；也应该比较有测试激情（不是按照软件测试架构师要求的任务测完就结束了，而是自己主动去发现系统更多的问题）；另外版本的质量可能也不错（至少还能够使用各种测试方法来“折腾”系统），没有严重的测试阻塞。但这依然需要软件测试架构师和测试者仔细核对测试计划，确认测试者是在保证了测试计划的前提下才进行发挥的——核对的过程可能会让人感到有些尴尬，但我们的核心理念是：通过测试策略来进行“刚刚好”（我们必须保证对重点测试部分的确认）的测试，而不仅是为了发现产品的缺陷。
如果确认发现测试计划存在偏差，需要在下个版本中进行补充测试，并和测试者做好沟通。
出现第二种情况，软件测试架构师可以考虑从如下几个方面来更新后续的测试策略：
增加相关内容的测试用例执行次数。
加强相关内容的回归测试。
对发现的缺陷进行逆向分析，增加探索式测试。
6.3.3 缺陷是否收敛
我们在判断缺陷趋势是否收敛时，需要具备以下两个条件，缺一不可：
“累积发现的缺陷趋势”变为凸函数。
“累积发现的缺陷趋势”和“累积解决的缺陷趋势”两条曲线越来越靠近，最后逐渐趋于一点。
当我们发现缺陷不收敛时，做好代码改动方面的控制，是一个很好的思路：
严格控制代码改动，非必要不改动。
做好代码的静态检查。
做好和修改相关的功能自测，避免因为缺陷修改而引入新的问题。
6.4 缺陷年龄分析
表11 缺陷年龄的定义
进行缺陷年龄分析，能够帮助我们确认每个可能引入缺陷环节、可能引入的缺陷是否都已经被有效去除。具体操作时，我们通过以下简单的3个步骤来开展缺陷年龄分析活动。
6.4.1 确定缺陷的缺陷年龄
如果你的项目有缺陷的管理工具（如bugzilla），可以增加缺陷年龄的选项。在开发修复缺陷的时候，可以对缺陷年龄进行选择。
如果没有缺陷管理工具也没有关系，你可以使用类似表6-12的形式来确定缺陷年龄。
表12 缺陷年龄确定方法
6.4.2 统计出各类缺陷年龄的数量，绘制缺陷年龄分析图
表13 缺陷年龄的数量
图11 缺陷年龄分析图
6.4.3 进行缺陷年龄分析
我们在进行缺陷年龄分析之前，需要先理解一下理想的缺陷年龄应该具有怎样的特点。
1）理想的缺陷年龄分析图
理想的缺陷年龄分析图应该是如下这样的。
（1）在缺陷的引入阶段就能及时发现该类缺陷，缺陷不会逃逸到下个阶段，如图12所示：
图12 引入阶段
如果真能达到这样的水平，测试也就可以“光荣”失业了。但实际情况是，每个阶段都会有一些缺陷“逃逸”到下一阶段，需要“测试”来发现这些逃掉的缺陷。
我们已经了解到测试不应该想到哪里就测到哪里，而应该进行分层测试：在每个测试分层围绕不同的测试目标，使用不同的测试方法来进行测试。
（2）在特定的测试分层发现该层的问题，如图13所示。
图13 发现特定测试分层问题
对其他几类缺陷年龄，我们的期望是：
没有继承或历史遗留引入的缺陷。
没有新需求或变更引入的缺陷。
没有缺陷修改引入的缺陷。
2）没有在特定的测试层次发现该层的缺陷
例如，在集成测试阶段，我们希望发现在编码阶段和设计阶段引入的缺陷，但实际上却发现了大量的在需求阶段引入的缺陷。这说明：
产品需求的质量不高，需求存在不清晰或错误的情况。
系统架构设计的质量不高。
需求质量不高，产品功能的质量也不会太高。
系统架构设计的质量不高，产品在非功能属性方面的质量也不会太高。
这就需要测试或整个研发团队来有针对性地进行改进。例如：
对需求再次进行检测，确保尚未集成的功能对应的需求的正确性。
分析架构设计中的问题，找出对非功能属性方面的主要影响，调整测试策略，尽量提前并加大这些内容的测试力度。
调整测试策略，增加相关功能的测试力度和回归测试的规模。
3）继承或历史遗留引入的缺陷过多
当我们发现测试中出现了很多因为继承或历史遗留引入的缺陷时，这就说明产品还存在一些“旧账”尚未清理，这时我们需要：
进行或重新进行老功能分析（详见6.7.2节），更新测试策略。
对这些缺陷进行分析，由此更新测试策略，进行探索式测试。
如果被继承的版本处于维护阶段，考虑这些缺陷是否需要在维护版本中解决，并发布补丁或升级包。
确认被继承的版本在维护阶段发现的其他缺陷，是否需要同步到当前新版本中。
图14清理“旧账”
4）新需求或变更引入的缺陷过多
5）缺陷修改引入的缺陷过多
6.5 缺陷触发因素分析
缺陷的触发因素就是测试者发现缺陷的测试方法。缺陷触发因素分析，就是对测试中使用的测试方法进行分析。
对缺陷触发因素进行分析，能够帮助我们确认产品测试是否已经进行得足够全面和深入
和缺陷年龄分析方法类似，我们也可以通过下面3个步骤来进行缺陷触发因素分析。
6.5.1 确定缺陷的测试方法和测试类型
如果你的项目有缺陷的管理工具（如bugzilla），可以增加测试方法和测试类型的选项，在测试发现缺陷的时候来记录相关的信息。
果没有缺陷管理工具也没有关系，你可以使用类似表6-14的形式，来确定该缺陷的测试方法和测试类型。
表14 确定缺陷测试方法和测试类型
6.5.2 统计出各种测试方法发现的缺陷数目，绘制缺陷触发因素分析图
图15 缺陷触发因素分析图
6.5.3 进行缺陷触发因素分析
在理想情况下，我们希望做出的缺陷触发因素图和测试策略是吻合的。例如，当前版本我们的测试策略是：
对功能首先进行配置的遍历测试，需要保证新提交的命令行和以前已有的Web页面功能具有一致性；再进行基本功能测试，能够覆盖业务流程的基本路径；最后进行满规格的测试。
如果我们持续对产品进行缺陷触发因素分析，参考历史数据，结合自身的经验，我们还可以得到“不同的测试方法发现缺陷的大致比值和分布”。当然，这个比值可能不是很准，但是也可以作为软件测试架构师对数据进行分析时的参考。
6.6 组合使用各种缺陷分析技术
表15 产品质量评估表
7 风险分析技术
我们将风险分析技术用在保证测试策略的顺利进行和基于风险来加强或降低测试投入上，涉及的主要技术为风险识别、风险评估、风险应对和老功能分析。
7.1 风险分析
此处我们讨论的风险分析的对象是测试策略，目标是提前识别那些可能会阻塞测试策略顺利进行的问题，包括风险识别和风险评估两个部分。
7.1.1.风险识别
图16 风险识别的方法
举例：对测试设计进行风险识别
Step1：首先分析测试设计需要关注哪些内容。例如：
需要对某个重要的特性进行深入的测试，需要能够通过路径分析法来对开发人员的设计流程进行全面的覆盖，不遗漏基本的流程。
需要能够通过功能交互分析对功能间的相互作用进行深入的测试。
需要能够进行压力、稳定性和性能方面的测试。
Step2：分析上述内容都能够保质保量顺利地进行，需要哪些条件。例如：
条件1：开发能够提供相关的设计材料（如相关的概要设计文档），并且能够保证材料的内容是正确的。
条件2：有条件或者有机制能够保证开发人员和测试人员之间的有效沟通。
条件3：测试人员对产品的使用场景、多个特性都有一定的理解，能够进行全面的功能交互分析。
条件4：测试人员能够理解并掌握压力、稳定性和性能方面的测试方法，有能力结合测试方法和产品实现来进行测试设计。
Step3：逐一分析这些条件是否能够满足。假如条件1和条件4可能无法满足，那么识别出来的风险点就是：
风险1：开发可能会缺失重要的设计文档，或者一些设计文档更新不及时。
风险2：测试人员对压力、稳定性和性能方面的测试方法掌握不足，可能会出现测试设计遗漏。
需要特别说明的是，虽然此处我们进行风险分析的对象是测试策略，围绕测试活动能否正常展开，但并不等于我们只在测试内部识别风险点——我们依然要从整个项目的角度来进行风险识别。我们可以使用表6-16风险识别清单，来帮助我们进行风险识别。
表16风险识别清单
7.1.2 风险评估
风险评估的目标就是确定风险优先级。
1）风险优先级正交表
表17 风险优先级正交表
7.2 风险应对
表18 常见风险及应对思路
7.3 老功能分析
7.3.1 差异性分析
差异性分析是指找出老功能在新版本和老版本上的差异。这些差异包括需求、设计、平台、实现等各种差异。
7.3.2 历史测试情况分析
历史测试情况分析是对老功能在老版本中的测试情况（包括测试策略、测试用例、缺陷）进行分析，以此来确定老功能在新版本中需要采用怎样的测试策略。
1）确认老功能在新版本和老版本中的质量要求是否一致
2）进行测试方法分析
表19 分析角度
3）进行缺陷分析
表20 老功能历史缺陷分析点
4）对“组织和人”进行分析
表21 测试团队分析
8 分层测试技术
我们将分层测试运用在测试目标的SMART化上和测试活动的安排上。
对V模型而言，每个测试分层测试图测试的重点为：
8.1 V模型
单元测试：从产品实现的函数单元的角度，验证函数单元是否正确。
集成测试：从产品模块和功能的角度，验证功能模块和模块之间的接口是否正确。
系统测试：从系统的角度，验证功能是否正确，验证系统的非功能属性是否能够满足用户的需求。
验收测试：从用户的角度，确认产品是否能够满足用户的业务需求。
8.2 设计测试层次
1.某通信公司的测试分层
图17 某通信公司的测试分层
和V模型相比，集成测试在本例中被分成了MST和BBIT；系统测试被分成了SDV、SIT和SVT。
模块级系统测试（MST）：保证软件开发项目组各个单元/模块之间的接口正确，以及对项目组级别的功能进行验证。
Building Block Integrated Test（BBIT）：验证的是子系统之间的单元/模块的接口的正确性，也就是我们常说的开发“联调”。
系统设计确认（SDV）：从系统的角度来验证功能的正确性。
系统集成测试（SIT）：从系统的角度来验证功能交互和非功能方面的正确性。
系统验证测试（SVT）：验证场景、解决方案的正确性。
为什么此处的“测试分层”要这么复杂呢？这是因为在这个例子中，被测对象是通信产品。我们知道，通信产品需要包含硬件、驱动和软件，业务也比较复杂，还会涉及很多协议和规范。在设计上常常会包含多个子系统，涉及很多接口。用户不仅关注功能，还特别关注可靠性、性能等方面的质量，对产品质量整体要求很高。
2.某公司在敏捷环境下的测试分层
图18 某公司在敏捷环境下的测试分层
和前面的介绍的测试分层相比，本例就显得简单多了：
单元测试（UT test）：针对代码或者组件的测试。
功能测试（function test）：针对产品功能方面的测试。
非功能测试（non-functional test）：指非功能方面的其他质量属性的测试。
探索测试（Explore test）：基于任务的测试。
这时被测对象是一个纯软件产品，根据用户的业务需求进行迭代开发，但总体来说并不复杂，基本不涉及协议或规范。用户比较关注功能、易用性和性能，对可靠性方面的问题有一定的容忍性，总的来说对质量的整体要求并不算太高，希望产品能够快速交付。
在这样的背景下，快速评估产品是否能够发布，进行快速测试是有必要的。如果我们还是按照V模型中的测试分层来进行测试，就显得太重了。在这个测试分层中，我们在单元测试层中测试代码、接口的质量；提交给测试后，在功能测试层中集中测试功能；待功能相对稳定后，在非功能测试层中再集中易用性、性能和可靠性等方面的内容；在探索测试层，再结合缺陷，进行补充测试和回归测试。
