导图社区 软件测试架构师知识能力模型
- 765
- 41
- 8
- 举报
软件测试架构师知识能力模型
此导图为软件测试人员必学必备的内容，适用想要提升自我不知如何下手，以及小白新手搭建模型或者测试遇到瓶颈的人员，希望能够有所帮助！
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- 测试架构师
- 测试必学
- 测试提升
- 相似推荐
- 大纲
软件测试架构师知识能力模型
1. 软件产品质量模型
1.1. 软件产品质量六属性
软件产品质量模型对产品设计时需要考虑的地方进行了高度概括。一个高质量的产品，一定是一个在质量六属性上都设计得很出色的产品;如果一个产品的设计在质量六属性上存在缺失，这个产品的质量一定不会太高。
1.1.1. 功能性
适合性
软件产品为特定的任务和用户目标提供一组合适功能的能力
准确性
软件产品提供具有所需精度的正确或相符的结果及效果的能力
互操作性
软件产品与一个或多个特性、系统相互配合的能力
安全性
软件产品保护信息和数据的能力，以保证未授权的用户或系统不能阅读和修改这些信息与数据，而合法用户或系统不会被拒绝访问
功能性的顺从型
软件产品符合和该功能相关的标准、规范、规则或特定的能力
软件产品质量属性中的功能性是指软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。从功能性的定义来看，产品的功能并不像表面上看起来那么简单一除 了满足“明确”的要求，还有更深- -层的“隐含”的要求。“明确”+“隐含”才构成了用户对产品真正的、完整的功能要求。
1.1.2. 可靠性
成熟性
软件产品为避免因软件故障而导致失效的能力
容错性
软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力
可恢复性
软件产品在失效发生的情况下，重建规定的性能级别并自动恢复受直接影响的数据的能力
可靠性的顺从型
软件产品遵循与可靠性相关的标准、约定或规定的能力
下面3个层层递进的句子，可以帮助我们来理解用户可靠性方面的要求: 第一层:设备最好不要出故障; 第二层:设备出现故障了不要影响主要的功能和业务; 第三层:如果影响了主要功能和业务，系统可以尽快定位并恢复。
1.1.3. 易用性
易理解性
软件产品使用户能理解软件是否适合以及如何能将软件用于特定的任务和使用环境的能力
易学性
软件产品使用户能学习其应用的能力
易操作性
软件产品使用户能够操作和控制它的能力
吸引性
软件产品吸引用户的能力
易用性的依从性
软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力
软件产品质量属性中的易用性是指用户在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。这个能力，简单地说就是10个字:易懂、易学、易用、漂亮好看。易用性对消费类的产品显得尤为重要。例如我们在购买手机的时候，手机的外观是否漂亮，界面是否漂亮、好用会成为影响我们购机的一个重要因素;再如我们在下载一个移动应用后，很少有人会去阅读它的手册，这个应用能不能被看懂、好不好用往往成了决定这个应用能否继续保留在移动设备上的关键因素。
1.1.4. 效率
时间特性
在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及流量（吞吐量）的能力
资源利用率
在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源能力
效率的依从性
软件产品遵循与效率相关的标准或约定的能力
软件产品质量属性中的效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。通常，效率就是我们常说的产品性能。一般性能测试考核参数：多（并发多少）快（速度多快）好（错误率多少）省（资源使用）。
1.1.5. 可维护性
可分析性
软件产品诊断软件中的缺陷、失效原因或识别待修改部分的能力
可修改性
软件产品能够被修改的能力
稳定性
软件产品不会因为修改而造成意外结果的能力
可测试性
很多朋友看到可测试性，就会望文生义，认为这个属性的对象是软件测试，和软件开发、和最终用户无关。这样理解是不准确的。可测试性关注的是软件的修改是否正确、是否符合预期。因此第-一个 和可测试性有亲密关系的是软件开发，接下来才是软件测试。对最终用户来说，他们可能也会让产品研发提供一些方法或证据来证明某个bug确实被正确修复了。因此，可测试性是产品质量重要的组成部分，需要设计。良好的可测试性不仅可以帮助开发、测试快速、准确确认修改结果，也能帮助研发和用户之间建立良好的信任合作关系。
软件产品已修改的部分能够被确认修复的能力
可维护性的依从性
软件产品遵循与维护性相关的标准或约定的能力
软件产品质量属性中的可维护性是指软件产品可被修改的能力。这里的修改是指纠正、改进软件产品，和软件产品对环境、功能规格变化的适应性。
1.1.6. 可移植性
适应性
软件产品无需采用额外的活动或手段就可适应不同指定环境的能力
可安装性
软件产品在指定环境中被安装的能力
共存性
软件产品在公共环境中同与其分享公共资源的其他独立件共存的能力
易替换性
软件产品在同样的环境下，替换另一个相同用途的指定软件产品的能力
可移植性的依从性
软件产品遵循与可移植性相关的标准或约定的能力
软件产品质量属性中的可移植性是指软件产品从一种环境迁移到另外--种环境的能力。这里的环境，可以理解为硬件、软件或组织等不同的环境。
2. 测试类型
2.1. 质量属性和测试类型的关系
2.2. 功能测试：验证产品能否满足用户特定功能要求并做出正确响应 安全性测试：验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击 兼容性测试：验证产品是否能够和其他相关产品顺利对接 配置测试：验证产品是否能够在推荐配置上流畅运行;验证产品为了完成特定功能的输人是否会出现故障 可靠性测试：验证产品在长时间运行下能否满足保证系统的性能水平;在存在异常的情况下系统是否依然可靠 易用性测试：验证产品是否易于理解、易于学习和易于操作 性能测试：测试产品提供某项功能时的时间和资源使用情况 安装测试：测试产品能否被正确安装并运行
3. 测试方法
3.1. 产品测试车轮图
正是因为软件产品有很多质量属性，这些都需要软件测试去验证，所以软件测试才会有如此多的测试类型。每一种测试类型又包含了很多测试方法，去验证确认产品的这种质量属性。这就构成了一个软件测试者要从哪些方面(测试类型) 用哪些方法(测试方法)去测试产品(质量属性)的关系图。
正是因为软件产品有很多质量属性，这些都需要软件测试去验证，所以软件测试才会有如此多的测试类型。每一种测试类型又包含了很多测试方法，去验证确认产品的这种质量属性。这就构成了一个软件测试者要从哪些方面(测试类型) 用哪些方法(测试方法)去测试产品(质量属性)的关系图 从“车轮图”中能够分析出产品测试的两个关键问题： 一是如何保证测试验证的“全面性”的问题。显然，只要我们使用的测试方法能够覆盖六大质量属性，我们的测试就不会出现大方向性的遗漏。 二是如何确定测试“深度”的问题。一般来说，测试团队使用的测试方法越多，对产品就测试得越深。这些都会影响测试的效果，影响测试对产品质量的评估。除此之外，“车轮图”还能帮助我们评估测试团队的能力。软件测试人员能够驾驭的测试方法越多，他的测试能力就越强;相应地，一个测试团队能够驾驭的测试方法越多，这个团队的测试能力就越强。这为我们如何提升团队能力，提供了思路。需要特别指出的是，测试团队的能力强，能够驾驭很多测试方法，不等于在测试中都要使用这些方法一测试不是越多越好，而是需要根据产品的质量目标、产品的风险分析来确定测试的重点和难点、深度和广度，这就是测试策略。
3.2. 功能测试方法
3.2.1. 单运行正常值输入法
3.2.2. 单运行边界值输入法
3.2.3. 多运行顺序执行法
多运行顺序执行法在和用户的操作习惯相关的地方使用非常有效。 例如，用户登录、用户选择商品、用户提交订单这几个运行，有的用户的操作习惯是先登录，再选择商品;有的用户的操作习惯可能是先选择商品然后再登录。这就需要我们先分析这些操作可能的先后顺序再来进行测试。
3.2.4. 多运行相互作用法
3.3. 可靠性测试方法
3.3.1. 异常值输入法
系统不允许输入的数值，或者不完整的数值
3.3.2. 故障植入法
把系统放在有问题的环境中测试，容错性和成熟性。
3.3.3. 稳定性测试法
稳定性测试法是在一段时间里，长时间大容量运行某种业务的一种可靠性测试法，它能够非常有效地测试到系统的“ 成熟性”，是非常重要的一种可靠性测试法。
多、并、复、异
与异常输人法和故障植入法相比，“异字诀”强调的是“持续”和“累积”。事实上，使用“异字诀”来测试往往还比较有效，这是因为，开发在编码的时候，容易考虑正确情况下资源的申请和回收，忽视异常情况下资源的回收。
3.3.4. 压力测试法
我们希望系统在突发的情况下不会像纸牌屋那样脆弱，而是有切实的应对措施，如不处理超过系统规格的负载、记录日志供用户分析突发原因等。不会因为突发情况导致死机、反复重启等致命问题，这才是我们进行压力测试的真正目的。
3.3.5. 恢复测试法
恢复测试法是指使用持续超过规格的负载进行了测试后，再将负载降到规格以内的测试方法。
3.4. 性能测试方法
前面我们已经讲到，性能测试的目的是测试产品真实规格是否和说明书中承诺的需求规格一致，我们实测出来的性能值，就是系统真正能够处理的最大容量或者能力。在性能测试中，我们除了确认性能规格是否满足外，还希望发现性能瓶颈，评估性能表现。
3.4.1. 性能瓶颈
3.4.2. 分析会影响性能的因素，测试它们对性能的影响
3.4.3. 以场景为单位来测试性能
3.5. 易用性测试方法
3.5.1. 一致性测试法
测试时可以对需要测试的设计规范制定简明的checklist(清查表)，让测试人员可以基于对设计规范的理解来进行测试，而不是机械地进行比对。如果抽测发现的问题很多，最好的办法不是加大测试量，而是反馈给UI的设计者和实现者，请他们进行改进。
3.5.2. 可用性测试法
我认为，适合进行可用性测试的人选，排序是专职验收测试者=需求工程师>售前/售后工程师>功能测试人员。即可用性测试最佳的人选是又懂用户又懂测试的人，如果能力不能兼具，懂用户、会使用的人更适合。
易用性测试法测试的是用户在理解、使用产品时产品的能力。在产品日益重视易用性的今天，易用性测试的现状却不容乐观。很多人都认为易用性测试并不是有严格标准的测试，而是带有很强的主观性。这使得开发和测试在问题确认上常会出现分歧。很多人会认为易用性测试发现的问题对产品质量来说是“锦上添花”，和开发新功能、修改其他的bug相比优先级被放得很低，得不到应有的重视。对于易用性测试来说，确定以些客观的测试验收标准，保证必要投入是非常必要的。
4. 测试设计技术
4.1. 测试点不等于测试用例
4.1.1. 而测试用例是在测试点“加工”的基础上得到的。首先把测试点“去重”(去掉重复的内容)、“合并”(把太细的测试点合并起来)、“细化" (把太泛的测试点说清楚、说具体),然后再确定各个测试点的测试条件、测试数据和输出结果。如果说测试点还只是一些散乱的测试思路的集合，那么测试用例就是一份真正能够指导测试的测试说明书。接下来我们就为大家详细介绍测试设计的方法。
4.2. 四步测试设计法
4.2.1. 建模
流程
对“流程”类，可以通过绘制“ 流程图”来建立测试模型。
参数
对“参数”类，可以通过“输入输出表”来建立测试模型。
数据
对“数据”类，可以通过“等价类分析表”来建立测试模型。
组合PICT
PICT(Pairwise Independent Combinatorial Testing)工具原是微软公司内部使用的一款自动生成成对组合测试用例的命令行工具，生成Pairwise testing所需的测试用例，并且可以将结果导出到excel，该工具可以从互联网上下载到。但是目前微软官方下载地址已经不能下载了。————————————————版权声明：本文为CSDN博主「Onesiphorus」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/zzhangsiwei/article/details/121159239
对“组合”类，可以通过“因子表”来建立测试模型。
4.2.2. 设计基础测试用例
为什么我们称此时的测试用例为基础测试用例呢?测试用例和基础测试用例最大的差别在于，测试用例确定了测试条件(类似“在xx情况下，进行xx的测试”的描述)和测试数据(就是输人的“参数值"或“数值" ),而基础测试用例只确定了测试条件。由于此时我们关心的仅是对模型的覆盖，得到的是一些测试条件，因此我们称此时的测试用例是基础测试用例。
4.2.3. 补充测试数据
补充测试数据，这时基础测试用例就升级成真正的测试用例了
4.2.4. 扩展
模型不是银弹，不能解决测试设计的所有问题。我们还需要根据经验，特别是对系统哪些地方容易发生缺陷的认识，补充- -些测试用例，增加系统的有效性。
把测试点加工为测试用例，就叫测试设计，在这个过程中使用的方法就叫测试设计方法。路径分析法、判定表、正交分析法、等价类、边界值等都是常见的测试设计方法。
4.3. 对测试点进行分类
4.3.1. 流程类测试点有哪些特征
4.3.2. 参数类测试点有哪些特征
第一，“参数值”的个数是有限的，可以通过遍历的方式来测试覆盖到;第二，系统会对不同的“参数值"作出不同的处理或响应。理解这两个特点，能够帮助我们区分参数类和数据类测试点。
4.3.3. 数据类测试点有哪些特征
和“参数”类相比，“数据"类的特点是: 第一，数据的取值是一个范围，通常不能用遍历的方式来测试覆盖。就拿“允许输人的用户名的长度为1 ~ 32个字符”来说，如果要进行遍历测试，就需要依次测试“1个字符长度的用户名”“2个字符长度的用户名”...直到“32 个字符长度的用户名”，这样的测试就显得很冗余。第二，系统对允许输人的“数据”作出的处理或响应往往是- -样的。例如，系统在处理“1个字符长度的用户名”和“2 个字符长度的用户名”时,往往是一样的。
4.3.4. 组合类测试点有哪些特征
在使用四步测试方法之前，我们首先要对测试点进行分类。分类的依据，就是看测试点是否有“流程”类的特征、“参数”类的特征、“数据”类的特征、“组合”类的特征。
4.4. 流程类测试设计：路径分析法
4.4.1. 通过绘制业务流程图来建模
对流程类的测试点，建模就是绘制这些测试点代表的业务流程图。在这个步骤中需要特别注意的地方是: 1.测试者要充分理解和测试点相关的功能业务流程，确保流程图的正确性。 2.测试者要和产品设计者充分交流，保证绘出的流程图能够正确覆盖产品的设计。 3.如果开发已经提供了该功能的流程图，测试者需要仔细审核流程图的正确性，如有必要可以重新绘制。
4.4.2. 路径分析法
使用路径分析法“覆盖”这个流程，设计基础测试用例所谓路径分析法，就是指对能够覆盖流程的各种路径进行分析，得到一个路径的集合。 在测试时，我们只需要按照这个路径集合进行测试即可。不同的覆盖策略，能够得到不同的路径集合。常见的覆盖策略有语句覆盖、分支覆盖、全覆盖和最小线性无关覆盖。
语句覆盖
语句覆盖是指覆盖系统中所有判定和过程的最小路径集合。
分支覆盖
分支覆盖是指覆盖系统中每个判定的所有分支所需的最小路径数。
全覆盖
全覆盖是指100%地覆盖系统所有可能的路径的集合。
最小线性无关覆盖
我们希望能有这样的一种覆盖方式，仅保证流程图中每个路径片段能够被至少执行一次，在这种覆盖策略下得到的最少路径组合，就是最小线性无关覆盖
4.4.3. 使用路径分析法来设计基础测试用例
主要使用语句覆盖或分支覆盖的方式来设计测试用例;在集成测试和系统测试阶段，我们会主要使用最小线性无关覆盖;而对其中一些特别重要的部分，使用全覆盖;对一些不那么重要的部分，使用语句覆盖或分支覆盖。
4.4.4. 确定测试数据，完成测试用例
4.4.5. 根据经验补充测试用例
是否要增加一-些需要覆盖的路径? 是否要增加一-些测试数据? 有哪些地方是容易出问题的，是否还需要补充--些测试用例?
4.5. 参数类测试设计：输入输出表分析法
4.5.1. 使用输入输出表来建模
“输入一输出表”是一张分析测试点在某种条件下，特定的“输人”会有怎样“输出”的表
4.5.2. 覆盖输入输出表，完成测试用例
由于我们在建立“输人一输出表”的时候，会充分考虑各个参数之间的关系和它们的约束条件，并据此进行了逐一的分析,所以在覆盖“输入一输出表”的时候，我们会进行100%的覆盖，即将“输人一输出表”的每一行作为一个测试用例。
4.5.3. 根据经验补充测试用例
是否需要考虑一些别的条件？
有哪些地方是容易出问题的，是否需要补充一些测试用例？
4.6. 数据类测试设计：等价类和边界值分析法
4.6.1. 等价类和边界值
使用“等价类”和“边界值”来进行测试设计的优势在于，它们既能控制测试的规模，还能有效地发现产品的缺陷一“边界值”本身就是基于开发在设计时对边界的处理容易出问题而提出的。但“等价类”和“边界值”也是一把双刃剑:“如果我们没有正确地划分等价类，或是为了减少测试用例的数量而过度划分等价类，都很容易造成测试遗漏，留下测试隐患。”因此，软件测试架构师需要在测试方案或测试用例评审中需要注意的地方。
等价类是指对输人值按照测试效果进行划分,将测试效果相同的测试数据归为一类,然后在测试时只需要在每类中选择一些测试样本来进行测试，而无须测试所有的值。边界值是参数在输人边界上的取值。 等价类和边界值常常结合在一起使用:我们首先对“输入”进行等价类划分，然后再将每个等价类的边界值作为测试的样本点。
4.6.2. 使用等价类分析表来建模
4.6.3. 覆盖等价类分析表完成测试用例
4.6.4. 根据经验补充测试用例
是否要在“等价类”中增加一些除“边界值”之外的测试数据? 有哪些地方是容易出问题的，是否还需要补充一些测试用例?
4.7. 组合类测试设计：正交分析法
4.7.1. 使用因子表来建模
4.7.2. 使用PICT工具来生成测试用例
4.7.3. 根据经验补充测试用例
4.8. 控制用例粒度：测试点的组合和拆分
软件测试架构师在测试设计中除了为整个团队在测试设计的方法上提供指导外，还有一项十分重要的工作，就是用例粒度。
4.8.1. 控制用例粒度
用例粒度总数维持在合理的范围内
不同的用例粒度，可能会发现产品不同层次的问题
(细粒度的用例可能更容易发现产品功能的设计和实现方面的问题，而粗粒度的用例可能更容易从系统的角度去发现一些功能交互或是需求方面的问题)，所以我们需要在不同的测试阶段，对测试点进行一些拆分或组合，以求可以从不同的层次去测试产品，发现问题
4.8.2. 策略覆盖
同等重要可以使用轮询
不同等重要按照内容的重要性分配
考虑到测试的便利性
4.9. 错误推断法
4.9.1. 错误推断法是测试者根据经验来判断产品在哪些地方容易出现问题，然后针对这些地方来设计测试用例的方法。 错误推断法是一种基于经验的测试设计方法。使用错误推断法来设计测试用例，优点是测试用例的有效性会比较高(所谓测试用例的有效性，就是指测试用例发现产品缺陷的能力)。但错误推断法的缺点也是显而易见的:这时测试专注于发现缺陷，可能会测试得很严苛，却忽视或遗漏掉对一些基本功能和场景的测试验证，造成测试遗漏。因此对软件测试架构师来说，在测试设计中控制错误推断法的使用，将其维持在一个合适的度上，是非常重要的一件事情。 将错误推断法用到四步测试设计法中的第4步，根据经验补充测试用例，是一个比较推荐的方法。在保证测试用例对功能、场景能够有一定的基本覆盖的基础上，再使用错误推断法来增加测试用例的有效性。
4.9.2. 错误推断法
5. 探索式测试
细粒度的用例可能更容易发现产品功能的设计和实现方面的问题，而粗粒度的用例可能更容易从系统的角度去发现--些功能交互或是需求方面的问题
5.1. 探索式测试的基本思想：CPIE
5.1.1. 探索式测试(exploratory testing) 最早由测试专家Cem Kanner博士在1983年提出，是一种强调测试人员同时开展测试学习、测试设计、测试执行，并根据测试结果反馈及时优化的测试方法。
5.1.2. 收集(Collection):收集所有关于测试对象的信息并去理解这些信息。 划分优先级( Prioritization):对所有需要测试的任务进行优先级的划分。 分析调研(Investigation): 对测试的任务进行仔细分析, . 预测可能输出的结果。 实验( Experimentation):进行测试实验，确认测试结果和预期是否符合。分析是否需要修改测试策略和方法。如有需要，进入“收集”阶段。
5.1.3. 在实际项目中，以传统式测试为主线，将探索式测试作为很好的补充是比较不错的方式，两种思想结合起来，能比较不错地将探索式测试的思想运用到各种测试活动中。
5.2. 选择合适的探索式测试方法
5.3. 开展探索式测试
6. 自动化测试
6.1. 需要知道的一些自动化测试真相
6.1.1. 自动化并不廉价，相反，自动化很贵
6.1.2. 自动化脚本往往没有想象中那么可靠
6.1.3. 自动化测试不是单靠测试就能搞定
6.2. 如何评估自动化的收益
6.2.1. 由于自动化是昂贵的，不是那么可靠的，也不是那么容易进行的，所以我们要有办法 对自动化的收益进行评估，通过评估帮助我们在产品中制定合适自动化测试部署的策略, 让自动化测试能够发挥最大的作用。
6.2.2. 自动化测试的实施成本=前期开发成本+后期的维护成本
6.2.3. 自动化测试的收益=自动化测试的运行次数%x
6.2.4. k——手工执行自动化用例所花费的时间成本; n——自动化测试用例执行的次数; c1——花费在自动化测试前期的成本(时间成本+人力成本+金钱成本); c2——花 费在自动化测试后期的成本(时间成本+人力成本+金钱成本)。 这个公式可以帮助我们评估当前自动化测试的收益，还可以帮助我们确定适合当前项目的自动化测试和手工测试比。
6.3. 自动化测试工具介绍
6.3.1. 子主题