首页  思维导图  详情

软件测试架构师知识能力模型

2021-11-08 16:58:52   10  举报





AI智能生成

软件测试架构师知识能力模型

软件测试

测试架构师

软件测试能力模型

作者其他创作

大纲/内容

软件产品质量模型

软件产品质量六属性

功能性

适合性

软件产品为特定的任务和用户目标提供一组合适功能的能力

准确性

软件产品提供具有所需精度的正确或相符的结果及效果的能力

互操作性

软件产品与一个或多个特性、系统相互配合的能力

安全性

软件产品保护信息和数据的能力，以保证未授权的用户或系统不能阅读和修改这些信息与数据，
而合法用户或系统不会被拒绝访问

功能性的顺从型

软件产品符合和该功能相关的标准、规范、规则或特定的能力

可靠性

成熟性

软件产品为避免因软件故障而导致失效的能力

容错性

软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力

可恢复性

软件产品在失效发生的情况下，重建规定的性能级别并自动恢复受直接影响的数据的能力

可靠性的顺从型

软件产品遵循与可靠性相关的标准、约定或规定的能力

易用性

易理解性

软件产品使用户能理解软件是否适合以及如何能将软件用于特定的任务和使用环境的能力

易学性

软件产品使用户能学习其应用的能力

易操作性

软件产品使用户能够操作和控制它的能力

吸引性

软件产品吸引用户的能力

易用性的依从性

软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力

效率

时间特性

在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及流量（吞吐量）的能力

资源利用率

在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源能力

效率的依从性

软件产品遵循与效率相关的标准或约定的能力

可维护性

可分析性

软件产品诊断软件中的缺陷、失效原因或识别待修改部分的能力

可修改性

软件产品能够被修改的能力

稳定性

软件产品不会因为修改而造成意外结果的能力

可测试性

软件产品已修改的部分能够被确认修复的能力

可维护性的依从性

软件产品遵循与维护性相关的标准或约定的能力

可移植性

适应性

软件产品无需采用额外的活动或手段就可适应不同指定环境的能力

可安装性

软件产品在指定环境中被安装的能力

共存性

软件产品在公共环境中同与其分享公共资源的其他独立件共存的能力

易替换性

软件产品在同样的环境下，替换另一个相同用途的指定软件产品的能力

可移植性的依从性

软件产品遵循与可移植性相关的标准或约定的能力

测试类型

质量属性和测试类型的关系

功能测试：验证产品能否满足用户特定功能要求并做出正确响应
安全性测试：验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击
兼容性测试：验证产品是否能够和其他相关产品顺利对接
配置测试：验证产品是否能够在推荐配置上流畅运行;验证产品为了完成特定功能的输人是否会出现故障
可靠性测试：验证产品在长时间运行下能否满足保证系统的性能水平;在存在异常的情况下系统是否依然可靠
易用性测试：验证产品是否易于理解、易于学习和易于操作
性能测试：测试产品提供某项功能时的时间和资源使用情况
安装测试：测试产品能否被正确安装并运行

测试方法

产品测试车轮图

功能测试方法

单运行正常值输入法

单运行边界值输入法

多运行顺序执行法

多运行顺序执行法在和用户的操作习惯相关的地方使用非常有效。
例如，用户登录、用户选择商品、用户提交订单这几个运行，有的用户的操作习惯是
先登录，再选择商品;有的用户的操作习惯可能是先选择商品然后再登录。这就需要我们
先分析这些操作可能的先后顺序再来进行测试。

多运行相互作用法

可靠性测试方法

异常值输入法

系统不允许输入的数值，或者不完整的数值

故障植入法

把系统放在有问题的环境中测试，容错性和成熟性。

稳定性测试法

稳定性测试法是在一- 段时间里，长时间大容量运行某种业务的一种可靠性测试法，它能够非常有效地测试到系统的“ 成熟性”，是非常重要的一种可靠性测试法。

多、并、复、异

压力测试法

我们希望系统在突发的情况下不会像纸牌屋那样脆弱，而是有切实的应对措施，如不处理
超过系统规格的负载、记录日志供用户分析突发原因等。不会因为突发情况导致死机、
反复重启等致命问题，这才是我们进行压力测试的真正目的。

恢复测试法

恢复测试法是指使用持续超过规格的负载进行了测试后，再将负载降到规格以内的测
试方法。

性能测试方法

性能瓶颈

分析会影响性能的因素，测试它们对性能的影响

以场景为单位来测试性能

易用性测试方法

一致性测试法

测试时可以对需要测试的设计规范制定简明的checklist(清查表)，让测试人员可以基于对
设计规范的理解来进行测试，而不是机械地进行比对。如果抽测发现的问题很多，最好的
办法不是加大测试量，而是反馈给UI的设计者和实现者，请他们进行改进。

可用性测试法

我认为，适合进行可用性测试的人选，排序是专职验收测试者=需求工程师>售前/售后工程
师>功能测试人员。即可用性测试最佳的人选是又懂用户又懂测试的人，如果能力不能兼具，
懂用户、会使用的人更适合。

测试设计技术

测试点不等于测试用例

而测试用例是在测试点“加工”的基础上得到的。首先把测试点“去重”(去掉重复的内容)、
“合并”(把太细的测试点合并起来)、“细化" (把太泛的测试点说清楚、说具体),然后再确定
各个测试点的测试条件、测试数据和输出结果。如果说测试点还只是一些散乱的测试思路的
集合，那么测试用例就是一份真正能够指导测试的测试说明书。接下来我们就为大家详细介
绍测试设计的方法。

四步测试设计法

建模

流程

对“流程”类，可以通过绘制“ 流程图”来建立测试模型。

参数

对“参数”类，可以通过“输入输出表”来建立测试模型。

数据

对“数据”类，可以通过“等价类分析表”来建立测试模型。

组合PICT

对“组合”类，可以通过“因子表”来建立测试模型。

设计基础测试用例

为什么我们称此时的测试用例为基础测试用例呢?测试用例和基础测试用例最大的差
别在于，测试用例确定了测试条件(类似“在xx情况下，进行xx的测试”的描述)和
测试数据(就是输人的“参数值"或“数值" ),而基础测试用例只确定了测试条件。
由于此时我们关心的仅是对模型的覆盖，得到的是一些测试条件，因此我们称此时的
测试用例是基础测试用例。

补充测试数据

补充测试数据，这时基础测试用例就升级成真正的测试用例了

扩展

模型不是银弹，不能解决测试设计的所有问题。我们还需要根据经验，特别是对系统
哪些地方容易发生缺陷的认识，补充- -些测试用例，增加系统的有效性。

对测试点进行分类

流程类测试点有哪些特征

参数类测试点有哪些特征

数据类测试点有哪些特征

组合类测试点有哪些特征

流程类测试设计：路径分析法

通过绘制业务流程图来建模

对流程类的测试点，建模就是绘制这些测试点代表的业务流程图。在这个步骤中需要特别注意的地方是:
1.测试者要充分理解和测试点相关的功能业务流程，确保流程图的正确性。
2.测试者要和产品设计者充分交流，保证绘出的流程图能够正确覆盖产品的设计。
3.如果开发已经提供了该功能的流程图，测试者需要仔细审核流程图的正确性，如有必要可以重新绘制。

路径分析法

使用路径分析法“覆盖”这个流程，设计基础测试用例
所谓路径分析法，就是指对能够覆盖流程的各种路径进行分析，
得到一个路径的集合。在测试时，我们只需要按照这个路径集合进行
测试即可。
不同的覆盖策略，能够得到不同的路径集合。常见的覆盖策略有
语句覆盖、分支覆盖、全覆盖和最小线性无关覆盖。

语句覆盖

语句覆盖是指覆盖系统中所有判定和过程的最小路径集合。

分支覆盖

分支覆盖是指覆盖系统中每个判定的所有分支所需的最小路径数。

全覆盖

全覆盖是指100%地覆盖系统所有可能的路径的集合。

最小线性无关覆盖

我们希望能有这样的一种覆盖方式，仅保证流程图中每个路径
片段能够被至少执行一次，在这种覆盖策略下得到的最少路径
组合，就是最小线性无关覆盖

使用路径分析法来设计基础测试用例

确定测试数据，完成测试用例

根据经验补充测试用例

是否要增加一-些需要覆盖的路径?
是否要增加一-些测试数据?
有哪些地方是容易出问题的，是否还需要补充--些测试用例?

参数类测试设计：输入输出表分析法

使用输入输出表来建模

“输入一输出表”是一张分析测试点在某种条件下，特定的“输人”会有怎样“输出”
的表

覆盖输入输出表，完成测试用例

由于我们在建立“输人一输出表”的时候，会充分考虑各个参数之间的关系和它们的
约束条件，并据此进行了逐一的分析,所以在覆盖“输入一输出表”的时候，我们会进行
100%的覆盖，即将“输人一输出表”的每一行作为一个测试用例。

根据经验补充测试用例

是否需要考虑一些别的条件？

有哪些地方是容易出问题的，是否需要补充一些测试用例？

数据类测试设计：等价类和边界值分析法

等价类和边界值

等价类是指对输人值按照测试效果进行划分,将测试效果相同的测试数据归为--类,
然后在测试时只需要在每类中选择--些测试样本来进行测试，而无须测试所有的值。
边界值是参数在输人边界上的取值。
等价类和边界值常常结合在- - 起使用:我们首先对“输入”进行等价类划分，然后再
将每个等价类的边界值作为测试的样本点。

使用等价类分析表来建模

覆盖等价类分析表完成测试用例

根据经验补充测试用例

是否要在“等价类”中增加一些除“边界值”之外的测试数据? 有哪些地方是容易出问题的，是否还需要补充一些测试用例?

组合类测试设计：正交分析法

使用因子表来建模

使用PICT工具来生成测试用例

根据经验补充测试用例

控制用例粒度：测试点的组合和拆分

控制用例粒度

用例粒度总数维持在合理的范围内

不同的用例粒度，可能会发现产品不同层次的问题

策略覆盖

同等重要可以使用轮询

不同等重要按照内容的重要性分配

考虑到测试的便利性

错误推断法

错误推断法是测试者根据经验来判断产品在哪些地方容易出现问题，然后针对这些地
方来设计测试用例的方法。
错误推断法是一种基于经验的测试设计方法。使用错误推断法来设计测试用例，优点
是测试用例的有效性会比较高(所谓测试用例的有效性，就是指测试用例发现产品缺陷的能
力)。但错误推断法的缺点也是显而易见的:这时测试专注于发现缺陷，可能会测试得很严
苛，却忽视或遗漏掉对一些基本功能和场景的测试验证，造成测试遗漏。因此对软件测试
架构师来说，在测试设计中控制错误推断法的使用，将其维持在一个合适的度上，是非常
重要的一件事情。
将错误推断法用到四步测试设计法中的第4步，根据经验补充测试用例，是一个比较
推荐的方法。在保证测试用例对功能、场景能够有一定的基本覆盖的基础上，再使用错误
推断法来增加测试用例的有效性。

错误推断法

探索式测试

探索式测试的基本思想：CPIE

探索式测试(exploratory testing) 最早由测试专家Cem Kanner博士在1983年提出，是
一种强调测试人员同时开展测试学习、测试设计、测试执行，并根据测试结果反馈及时优
化的测试方法。

收集(Collection):收集所有关于测试对象的信息并去理解这些信息。
划分优先级( Prioritization):对所有需要测试的任务进行优先级的划分。
分析调研(Investigation): 对测试的任务进行仔细分析, . 预测可能输出的结果。
实验( Experimentation):进行测试实验，确认测试结果和预期是否符合。分析是否需要修改测试策略和方法。如有需要，进入“收集”阶段。

在实际项目中，以传统式测试为主线，将探索式测试作为很好的补充是比较不错
的方式，两种思想结合起来，能比较不错地将探索式测试的思想运用到各种测试活
动中。

选择合适的探索式测试方法

开展探索式测试

自动化测试

需要知道的一些自动化测试真相

自动化并不廉价，相反，自动化很贵

自动化脚本往往没有想象中那么可靠

自动化测试不是单靠测试就能搞定

如何评估自动化的收益

由于自动化是昂贵的，不是那么可靠的，也不是那么容易进行的，所以我们要有办法对自动化的收益进行评估，通过评估帮助我们在产品中制定合适自动化测试部署的策略, 让自动化测试能够发挥最大的作用。

自动化测试的实施成本=前期开发成本+后期的维护成本

自动化测试的收益=自动化测试的运行次数%x

k——手工执行自动化用例所花费的时间成本;
n——自动化测试用例执行的次数;
c1——花费在自动化测试前期的成本(时间成本+人力成本+金钱成本);
c2——花费在自动化测试后期的成本(时间成本+人力成本+金钱成本)。
这个公式可以帮助我们评估当前自动化测试的收益，还可以帮助我们确定适合当前项
目的自动化测试和手工测试比。

自动化测试工具介绍

子主题