读《测试构架师修炼之道》-Chapter4 测试构架师的知识能力模型
1、概述
软件测试构架师所需要具备的能力，包括测试技术+综合能力（产品知识+沟通协作+书面表达）。
从测试技术来说，所需掌握的能力则如下图所示，包括5大模块，测试类型、测试方法、测试设计、探索式测试、自动化测试。
2、软件质量模型
为什么要先学习软件质量模型？因为测试的一个重要目标是“验证产品质量是否满足用户的需求”，软件质量模型就是帮助我们理解用户需求的。
用户除了明确的功能需求外，还有那些非功能的需求，还有哪些隐形需求？
2.1 软件质量六属性
国际上对于软件产品的质量模型标准是ISO/IEC9126，国内则是GB/T 16260，内容基本是一致的，引用图和描述如下
ISO9126软件质量模型是一个分层的质量模型，有6个影响质量的特性，模型中说明了质量特性及其子特性的关系。
标准的软件质量模型分为三个层次，第一层是6个影响软件质量的主要因素(即下面的质量的特性)，在标准中称为质量特性，而每个特性又可以通过第二层的若干个子特性来进行测量，而第二层的每个子特性在测量时又要定义并实施若干个度量。
此模型的出发点是使软件满足用户明确或潜在的需求，这六个特性最大可能的涵盖了其他早期质量模型中的所有因素，并且彼此交叉最小。
————————————————
版权声明：本文为CSDN博主「catch_dreamer」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/catch_dreamer/article/details/109139869
2.2 功能性
软件产品质量属性中的功能性是指软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。
这里暂时不展开讨论，功能性的要求相见上图的质量子属性描述，包括适合性、准确性、互操作性、安全性、功能顺从性。
2.3 可靠性
软件产品质量属性中的可靠性是指软件产品在指定条件下使用时，维持规定的性能级别的能力。
对应的质量子属性包括成熟性、容错性、可恢复性、可靠性顺从性。
2.4 易用性
软件产品质量属性中的易用性是指软件产品在指定条件下使用时，产品被用户理解、学习、使用和吸引用户的能力。简单来说就是10个字，易懂、易学、易用、漂亮好看。
对应的质量子属性包括易理解性、易学性、易操作性、吸引性和易用性的依从性。
2.5 效率
软件产品质量属性中的效率是指软件产品在指定条件下使用时，想用于所用资源的数量，软件产品可以提供适当的性能的能力。通常，我们会将其理解为产品的性能。
对应的质量子属性包括事件特性、资源利用率、效率性的依从性。
2.6 可维护性
软件产品质量属性中的可维护性是指软件产品可被修改的能力。这里的修改指的是纠正、改进软件产品，和软件产品对环境、功能规格变化的适应性。
对应的质量子属性包括可分析性、可修改性、稳定性、可测试性、可维护性的依从性。
这里就可测试性做一下说明，这里的可测试性其实和软件开发、用户都有关系。因为可测试性关注的是软件的修改是否正确、是否符合预期，对于一个改动，首先进行测试的就是软件开发，开发人员改完一个故障以后正常来说都要自测一把。紧接着，如果是用户关注的故障或者优化问题，用户也可能会要求使用一定的方法测试证明改动的生效。
2.7 可移植性
软件产品质量属性中的可移植性是指软件产品从一种环境迁移到另一种环境的能力的能力。这里的环境可以理解为硬件、软件或组织等不同的环境。
对应的质量子属性包括适应性、可安装性、稳定性、共存性、易替换性、可移植性的依从性。
3、 测试类型
质量属性更多是从产品设计的角度考虑，而测试类型则更多的是从产品测试和分析的视角出发。
常见的测试类型是可以和质量属性关联起来的，下面就按书中的思路整理一下。
功能性：功能测试、安全测试、兼容性测试、配置测试
易用性：配置测试、易用性测试
可靠性：可靠性测试（关注长期运行是否满足性能指标，以及异常状态下的系统可靠性）
可移植性：安装测试
效率：性能测试
4、测试方法
首先借用如下的产品测试车轮图，说明了不同的测试方法和软件质量模型的对应关系。在实际团队的任务执行过程中，掌握越多的测试方法越有益，但不代表全部都要使用。测试并不是越多越好，适度测试才是我们追求的目标，所以我们需要测试策略。
下面分别列举一些场景的测试方法。
4.1 功能测试方法
- 单运行正常值输入法
- 单运行边界值输入法
- 多运行顺序执行法（强调的是功能/操作组合，功能A、B、C，分别组合顺序执行）
- 多运行相互作用法 （强调的是单功能之间的交互，功能A会影响功能B）
4.2 可靠性测试方法
- 异常值输入法（测试软件对于异常输入的保护能力）
- 故障植入法（测试软件系统从故障中恢复的能力，这就要求软件系统具有容错性和成熟性，用当下微服务构架中流行的说法，也就是弹性系统）
- 稳定性测试法（顾名思义，长时间大量运行业务，验证系统的成熟性；强调“多、并、复、异”，即操作数量多，多用户并发操作，反复操作，异常操作）
- 压力测试法（在一段时间内使用超过系统规格的负载，希望系统能够正常处理要求规格内的业务；举例来说，系统支持并发1000，压力测试时并发1500，预期的是成功数量接近1000，而不是系统直接挂掉）
- 恢复测试法（进行如上的压力测试后，将负载降低到规格以内的方法，希望在恢复负载后系统能够自行恢复正常）
4.3 性能测试方法
同理于可靠性测试，性能测试也是一个非常大的专题，下面仅列举一些基本的方法。
- 测试出系统最好的性能
1）系统能够正确处理新业务的最大能力
即一定时间内建立新业务的能力，比如每秒能够新建多少个会话连接。
2）系统能够同时处理的最大业务能力
一般称为并发，比如系统能够支持多少用户同时在线。
- 分析会影响性能值的各种因素，测试他们对性能的影响
- 以场景为单位进行测试
4.4 易用性测试
由于易用性可能让人觉得难有明确的标准，主观性较强，作者给出了2个基本的原则供大家参考
- 一致性测试法（关注产品UI界面的一致性，风格、布局、元素是否一致）
- 可用性测试法（核心就是产品是否易懂、易操作，降低用户的学习成本并降低操作复杂度）
5、测试设计技术
开头需要先澄清一个概念，所以先举个例子。拿到一个如下这样的遥控器，如果让我们来测试它，大家会怎样考虑？
给我的话，我会想到一些如下可能的测试点，可能会和质量属性里面的一些条目对应。需要我们思考的就是，这些测试点就是测试用例吗？
| 测试点 | 测试点描述 |
| 1 | 每个单个按键功能是否可用 |
| 2 | 单个按键重复按下是否有保护 |
| 3 | 遥控器是否支持多个按键同时按下的组合功能，支持的话最多支持几个 |
| 4 | 遥控器的按键是否有误触保护，触发按下需要的力度是否合理 |
| 5 | 遥控器的红外发射模块是否可靠，最多支持多少米的传输距离 |
| 6 | 遥控器的外观设计是否美观，按键醒目且持握舒适 |
| 7 | 遥控器的按键最多支持多少次按压不损坏，电池续航能力如何 |
答案是否定的，测试点不是测试用例，但测试点是支持我们输出用例的内容。测试点存在一些明显问题：
（1）有些测试点可能过于零散，需要经过重组整理才能够变为用例，有些测试点可能又过于笼统，需要进一步拆分才能变成用例。
（2）测试点没有明确的操作步骤要求，同一个测试点给10个测试，可能就由10种测试流程
（3）测试点之间的关系是不清晰的，有可能重复，有可能有互相影响
最后由作者给出答案，如何能够得到测试用例？首先将测试点“去重”（去掉重复的测试点）、再“合并”（将零散的测试点整合）并“细化”（为太过宽泛的测试点补充细节），最后确认各个测试点的测试条件（预置条件）、测试数据（结合测试点的场景，就组成了输入）和输出结果（用例的核心，检查校验）
5.1 四步测试设计法
将测试点加工成测试用例，就叫做测试设计，在这个过程中使用的方法就叫测试设计方法。常见的测试设计方法包括：路径分析法、判定表、正交分析法、等价类、边界值。
作者推荐了四步测试设计法，用于支持输出一个合适的测试设计，下面就来看一下如何操作。
（1）建模
按照作者的说法，与其说是建模，不如说是选模。大部分的测试点都可以利用现有的模型进行覆盖，下面给出几个最常见的分类和建模方法。
“流程”类，可以绘制流程图来建立测试模型
“参数”类，可以通过输入输出表来建立测试模型
“数据”类，可以通过等价类分析表来建立测试模型
“组合类”，可以通过“因子表”来建立测试模型
（2）设计基础用例
主要关心的是测试条件、操作和检查点，比如在XXX的条件下，进行XXX操作，检查XXXX。
（3）补充测试数据
针对用例中的输入数据进行详细分析，比如用户名、密码、url，可使用等价类边界值等方法设计用例数据，再将对应的数据填入用例中，这样用例就完成了。
（4）扩展
这里就是根据个人经验进行发散，考虑测试点之间的交互、波及等因素。
6、探索性测试
这一块就贴一下书中的总结吧，探索性测试的执行人员没完成一个人物，都需要围绕如何有效地发现产品缺陷，立即给出总结：
- 总结那些方法能够更加有效地发现产品问题
- 总结本次探索性测试的教训
7、自动化测试
这也是一个非常庞大的话题，简单罗列下书中提到的几个重要观点，我也是非常认同的
（1）自动化不廉价，反之非常昂贵
自动化的本质是用一段程序去测试另一段程序，写代码脚本、维护代码脚本、维护自动化环境，都需要付出昂贵的代价
（2）自动化脚本没有那么可靠
脚本的检查规范是统一的，但检查的内容是否能够真的帮助大家发现缺陷，还是仅仅只是能够跑通过？用例跑失败真的是功能有问题，还是环境异常，还是性能可靠性问题，这些还需要人工分析。
（3）自动化测试不单是测试人员的事情
新做的需求，相关的测试用例能够被正确快速地被自动化，依赖于前端需求、方案、编码、文本用例的输出，有一个环节掉了链子，都可能导致用例写不完，写完了跑不过，跑过了发现没有校验到对的地方。所以，自动化是整个项目成员，包括SE、BA、DEV、TSE、TE共同完成的事情。
最后说一下，如何评估自动化的收益，自动化的收益=自动化运行的次数，如果写自动化花了2周，才跑了1周就下线了，那么就得不偿失了。
自动化实施成本比有一个公式：
自动化实施成本比= 执行自动化的时间成本*自动化执行的次数 /（编写自动化的成本+维护自动化的成本）
读《测试构架师修炼之道》-Chapter4 测试构架师的知识能力模型相关推荐
- 【测试人生】《测试架构师修炼之道》阅读笔记
<测试架构师修炼之道>一书,笔者入行一年多的时候拜读过.虽然这本书主要偏向业务测试.质量管理的方向,而并非技术测试.测试开发的方向,但只要是测试行业从业者,笔者认为都值得一看. 从笔者本人 ...
- 测试架构师修炼之道_学习笔记
测试工程师职业发展 管理路线 测试组长 测试经理.测试主管 测试总监 技术路线 产品测试技术 把产品测试的更好的技术 专项测试技术 不针对具体的产品,而是测试领域普遍适用的技术 产品测试专家(即测试架 ...
- 《测试架构师修炼之道》阅读总结
这本书是小编去年阅读的一本书,觉得很不错当时就将其中的一部分内容整理总结了一下,绘制了下图在团队内部进行了分享. 最近又温顾了一下,还是很受启发. 决定将总结分享给大家,也方便小编经常打开来回顾一下( ...
- 爆肝分享！什么样的架构师修炼之道文档，才能帮助大家修炼成为最最出色的架构师？不服就干！绝不怂！
前言 卓越的软件架构师从何而来? 所有程序员都有成为架构师的潜力,只要掌握了架构师的思维方式和工作方法,你也能成长为架构师. 本文教你如何像架构师那样思考问题.理解需求.设计架构.评估结果.编写文档. ...
- 【新书速递】解决方案架构师修炼之道
技术领域的发展日新月异,IT专业人员为了自身的职业发展,必须与时俱进地掌握新技能.然而,在过去的十年中,这种快速变化的趋势已经在云计算领域中占据主导地位,成为"新常态".现在,几乎 ...
- 【人工智能 AI 写书】《卓越架构师修炼之道》全书目录
帮我写一本书的目录,书名<卓越架构师修炼之道>,总共10章,每章5个小节,细化到3级目录.用markdown格式. 文章目录 <卓越架构师修炼之道> 第一章 架构概述 第二章 ...
- Java架构师成长之道之Java架构师技术栈
Java架构师成长之道之Java架构师技术栈 Java架构师成长之道 JavaSE篇 Java概述与开发环境搭建 Java数据存储 Java数据运算 Java程序流程控制 Java数组 Java面向对 ...
- 软件测试架构师知识能力模型
整理测试架构师修炼之道(第四章,软件测试架构师知识能力模型),希望对大家有所帮助,processon原图 https://www.processon.com/view/link/618a3a051ef ...
- 读《测试构架师修炼之道》-Chapter3 测试构架师应该做的事
第三章 软件构架师应该做和不应该做的事 1.软件构架师需要关注和不需要关注的事 不论是传统的瀑布式开发还是迭代.敏捷的开发模式,产品测试都可以概括为:测试需求分析.测试分析和设计.测试执行和测试质量评 ...
最新文章
- windows下如何正确使用Jconsole远程连接linux主机上的JVM
- TensorFlow------学习篇
- BeautifulSoup库之find_all函数_Python系列学习笔记
- CMD不能显示中文解决方案
- docker 保存 环境持久化_为什么 Docker 适合微服务架构？
- pb 数据窗口下拉表
- Java 8 Optional类深度解析（转）
- 【2013】将x插入有序数列
- MEMS惯性导航单元的标定与测试
- 【新知实验室】TRTC腾讯实时音视频动手实验
- android画笔大小,android之画板功能之橡皮擦 画笔大小和画笔颜色
- Word转pdf一个方法就可以完成~手机电脑都可以免费使用~办公必备
- python新手有手就会的100个代码
- BO 4.3支持微软的Azure Synapse Analytics 吗？
- 活在当下——一条狗的使命
- 后缀表达式、中缀表达式
- 物联网入门基础知识：物联网培训总结之物联网技术学习路线图
- matlab编根轨迹程序,matlab在根轨迹绘制中的应用
- pb 数据窗口更新mysql_如何在PB数据窗口中修改数据---设置数据窗口的更新属性...
- java加载pytorch模型,使用Dev Pytorch 1.0将Pytorch模型加载到C中