软件测试知识体系图谱

1. devops
1.1. QA，QC，QM
1.1.1. QA
概念
Quality Assurance (质量保证)
QA：为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计
划和有系统的活动
职责
QA：最重要的职责在于系统层面的完善，侧重于问题的防范及对已发生问题的根源的探究及其对策的实施，从而降
低不良的产生。创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷
技能要求
QA：具备必要资质的 QA 是组织中的高级人才，需要全面掌握组织的过程定义，熟悉所参与项目所用的工程技术。
软件测试小讲堂
5
组织架构
职能结构
在职能结构中，各个职能部门设立自己的 QA 岗位，位于高级经理之下，独立于项目组。QA 直接对高级经理负
责，但业务上需要向项目经理汇报，属于项目成员。这种组织结构的优点是 QA 容易融入项目组，易于发现实质性
的问题，解决问题也很快捷。缺点是各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过
程、方法和工具研究的重复性投资。在这种组织结构下，由于高级经理专注于业务的发展，QA 的职业发展容易受
到忽视，难于接受到应有的培训和提升。
矩阵结构
在矩阵结构中，设立了专门的 QA 部门，与各业务职能部门平级。QA 隶属于 QA 部，行政上向 QA 经理负责，业务
上向业务部门的高级经理和项目经理汇报。在这种组织结构中，由 QA 部经理对 QA 考评和授权，有利于保证 QA
的独立性和评价的客观性，也有利于确保组织的长期利益与项目（或个人）的短期利益之间的平衡。QA 资源为所
有项目所共享，可按照项目优先级动态调配，资源利用更充分，但也可能出现资源竞争冲突。此外，QA 部门对
QA 流程的改进、QA 知识的管理、QA 人员的发展负责，并可集中资源进行 QA 平台的建设，以防止重复性的投
资。但另一方面，在矩阵结构中，QA 难于融入项目组，发现的问题也很少能得到及时有效的解决。
柔性结构
柔性结构是职能结构和矩阵结构的混合形态，在职能结构的基础上建立了 QA 组。
软件测试小讲堂
6
专业组
QA 组是一个专业组，不是一个行政机构。QAG Leader 可由质量管理部委派人员担任或由某业务部门的 QA 兼任。
与职能机构一样，QA 直接对高层经理负责，但在业务上向项目经理和 QAG Leader 汇报。柔性结构吸收了职能结
构和矩阵结构的许多优点，既便于 QA 融入项目组，又便于部门之间经验的分享，还利于 QA 能力的提高。QAG
Leader 可以从各部门 QA 汇报中提取出各项目的共性问题，用于组织级过程的改进。企业还可以通过授予 QAG
Leader 不同的权利，比如按照 20/80 原则与高级经理分配 QA 的管理，来促进 QA 专业研究与应用的结合。QA 可
以协助评审和组织会议；在存在外包的情况下，可能需要 QA 在监控外包方方面发挥作用。
QA 工程师
1) 相关体系的认证及完善 （ISO、GMP、CMMI 等等，不同性质企业要求不同 ）。
2）主管技术措施和技术、质量、安全的交底工作。
3）一般性品质工作 。
4）质量培训工作。
5）做品质就像在给病人看病 ，高手总是能在不良发生之前就解决它 。所以 ，QA ，最重要的是一个预防性作用。
工具
软件测试小讲堂
7
层别法、柏拉图、特性要因图、查检表、直方图、控制图和散布图
关联图、KJ 法、系统图、矩阵图、矩阵数据分析法、PDPC 法以及箭条图
1.1.2. QC
概念
Quality Control (质量控制)
Qc：为达到品质要求所采取的作业技术和活动
职责
QC：最重要的职责在于对制成品的监控。尽可能早的找出软件缺陷，确保得以修复
技能要求
QC：既包括软件测试设计员等高级人才，也包括一般的测试员等中、初级人才。
步骤
（1） 选择控制对象；
（2） 选择需要监测的质量特性值；
软件测试小讲堂
8
（3） 确定规格标准，详细说明质量特性；
（4） 选定能准确测量该特性值或对应的过程参数的监测仪表，或自制测试手段；
（5） 进行实际测试并做好数据记录；
（6） 分析实际与规格之间存在差异的原因；
（7） 采取相应的纠正措施。
1.1.3. QM
概念
Quality Manage (质量管理)
QM：确定质量方针、目标和职责，并在通过诸如：质量策划、质量控制、质量保证和质量改进等，使其实施的全
部管理职能的所有活动。
职责
QM：最重要的职责在于从组织层面上保障质量工作环境。
技能要求
软件测试小讲堂
9
QM：不仅要具备 QA、QC 的技能，还需具备专业管理才能。
实现手段
1. 标准管理--此项是依赖一个统一的标准, 保证质量有个唯一的依据. 这个依据主要定义了一些宏观的、指标的、框架
性的质量约定。
2. 流程管理--此项是用来保证质量的一个重要手段。如国外有从热衷于质量体系到管理体系认证的转变，这就反应了
一种意识，纯粹的质量体系（无流程管理）是费时费力但效果不一定好的方式。
3. 产品测试管理--产品测试是保证质量的一个最重要手段，所以对测试的管理又是 QM 的一项核心工作。
4. 产品发布管理--产品发布是产品质量的依附，不同版本的产品可能存在不同的瑕疵，质量管理的一个重要管理部分
就是要清楚这些不同版本产品的质量情况。
1.1.4. 关系
SQA 指产品和过程保证人员，通过过程的方法保证质量达到要求；
SQC 指测试人员，通过验证的方法提供产品满足需求的证据；
SQM 指质量管理人员，一般为负责质量方面的管理者，通过制定过程、协调资源等一系列的手段为 QA、QC 工作创造
良好的环境和条件。
软件测试小讲堂
10
如果说质量就意味一个组织"第一次就把事情做对"的能力的话，那么，这种能力需要三个方面的修炼，缺一不可：
一是"控制系统"，
二是"保证系统"，
三则是管理思想。
1.2. Development 和 Operations
1.3. 开发
1.3.1. 规划
1.3.2. 编码
1.3.3. 构建
1.4. 测试
1.4.1. 软件测试基础
测试定义
软件测试小讲堂
11
通过人工或自动的手段，对被测对象进行检测的活动，目的在于发现被测对象是否实现用户的需求，或者弄清实际
结果和预期结果之间的差距
需要理解什么软件
源代码
用户手册
配置数据
测试目的
发现被测对象与用户需求之间的差异---俗称找 bug
通过测试活动，获取被测对象的质量信息，为决策提供数据依据通过测试活动，预防缺陷，从降低项目或产品的风
险
通过测试活动，获取被测对象的质量信息，为决策提供数据依据
通过测试活动，预防缺陷，从降低项目或产品的风险
测试原则
软件测试小讲堂
12
测试证明软件存在缺陷
不可能执行穷尽测试
测试应尽早启动，尽早介入缺陷存在群集现象
不同的测试活动依赖不同的测试背景
杀虫剂悖论
不同的测试活动依赖不同的测试背景
不存在缺陷的谬论
测试对象
软件源代码
与软件源代码匹配的文档
支撑软件源代码运行的配置数据
需求阶段
需求阶段
软件测试小讲堂
13
测试需求文档是香正确实现了用户的需求
系统设计阶段
概要设计文档
详细设计文档
是否有设计或逻辑上的错误
编码阶段
测试源代码
发现编程上的错误
系统测试阶段
被测对象是否满足用户需求
1.4.2. 软件测试级别
单元测试
针对被测系统最小的组成单元实施的测试活动，一般是类或函数，也可能最小的功能单元
软件测试小讲堂
14
集成测试
针对组件、单元与组件、单元之间的接口实施的测试活动，验证接口设计是否与设计相符
分 3 种集成
数间集成
模块间集成
子系统间集成
系统测试
将通过集成测试的软件，部署在真实的用户环境下执行测试
验收测试
由用户在开发环境下执行的测试活动，开发者在测试人员身边，发现问题及时沟通解决
α 测试
由用户在开发环境下执行的测试活动，开发者在测试人员身边，发现问题及时沟通解决
在受控环境下执行测试
软件测试小讲堂
15
β 测试
开发者不在测试人员身边，发现问题由专人统一收集，再由研发人员进行修改
在不受控环境下执行测试
UAT 测试
用户接受度测试
一般商业用户验证系统可用性进行的测试
维护测试
1.4.3. 系统测试类型
功能测试
在指定使用条件下，使用被测对象，验证其是否满足用户显性或隐性需求
测试关注点
是否有不正确或遗漏或多余的功能
满足系统显性或隐性需求
软件测试小讲堂
16
是否对输入输出做出了正确的相应，输出结果能否正确的显示
性能测试
通过模拟被测对象运行业务压力或使用场景，验证被测对象是否满足预先设定的性能指标
了解测试系统典型场景，并具有确定的性能目标
验证系统是否具有宣称的能力
要求在真实环境下实施
安全性测试
测试被测对象的安全保护机制保护系统不受非法侵入，能够接受正确授权的操作
兼容性测试
测试被测对象的安全保护机制保护系统不受非法侵入，能够接受正确授权的操作
1.4.4. 软件测试方法
黑盒测试
不关注被测对象内部结构，仅从用户需求考虑，是否满足用户显性或隐性需求
软件测试小讲堂
17
白盒测试
结构测试、逻辑驱动测试
灰盒测试
既关注被测对象的外部特性，又关注其内部设计
静态测试
不执行被测对象程序，不运行被测对象的测试方法
动态测试
执行被测对象，进行的检测活动
手工测试
通过测试工程师试用、验证被测对象是香满足用户需求
自动化测试
通过自动化测试工具，或脚本语言自动化完成测试过程
1.4.5. 软件质量
软件测试小讲堂
18
质量定义
质量是物体本身的属性，物体的质量与物体的形状、物态及其所处的空间位置无关，质量是物体的一个基本属性
软件产品满足用户或规定显性需求或隐性需求的程度
内部质量
过程质量
外部质量
使用质量
质量特性
功能性
定义
软件在指定条件下使用时，满足用户明确和隐含需求的功能的能力
适合性
软件为指定的任务和用户目标提供—组合适功能的能力
软件测试小讲堂
19
准确性
软件提供具有所需精确度的正确或相符的结果或效果的能力
互操作性
软件与一个或更多的规定系统进行交互的能力
保密安全性
软件保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系
统对它们的访问
功能性依从性
软件遵循与功能性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准、国家标准、行业标
准、企业内部规范等
可靠性
定义
软件在指定条件下使用时，维持规定的性能级别的能力
软件测试小讲堂
20
成熟性
软件为避免由软件中错误而导致失效的能力
容错性
在软件出现故障或者违反指定接口的情况下，软件维持规定的性能级别的能力
易恢复性
在失效发生的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力
可靠性依从性
软件遵循与可靠性相关的标准、约定或法规的能力
易用性
定义
在指定条件下使用时，软件被理解、学习、使用和吸引用户的能力
易理解性
软件使用户能理解软件是否合适，以及如何能将软件用于特定的任务和使用环境的能力
软件测试小讲堂
21
易学性
软件使用户能学习其应用的能力
易操作性
软件使用户能操作和控制它的能力
吸引性
软件吸引用户的能力
易用性依从性
软件遵循与易用性相关的标准、约定、风格指南或法规的能力。这些标准要考虑国际标准、国家标准、行业标
佳、企业内部规范等。
效率
定义
在规定条件下，相对于所用资源的数量，软件可提供适当性能的能力
时间特性
软件测试小讲堂
22
在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能力，即完成用户的某个功能需要
的响应时间
资源利用性
在规定条件下，软件执行其功能时，使用合适的资源数量和类别的能力
效率依从性
软件遵循与效率相关的标准或约定的能力
可维护
定义
软件可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变定义化的适应性
易分析性
软件诊断软件中的缺陷、失效原因或识别待修改部分的能力
易改变性
软件使指定的修改可以被实现的能力
软件测试小讲堂
23
稳定性
软件避免由于软件修改而造成意外结果的能力
易测试性
软件使已修改软件能被确认的能力
维护性依从性
软件遵循与维护性相关的标准或约定的能力
可移植
定义
软件从一种环境迁移到另外—种环境的能力
适应性
软件无须采用有别于为考虑该软件的目的而准备的活动或手段，就可以适应不同指定环境的能力
共存性
软件在公共环境中同与其分享公共资源的其他独立软件共存的能力
软件测试小讲堂
24
易安装性
软件在指定环境中被安装的能力
易替换性
软件在同样环境下，替代另一个相同用户的指定软件产品的能力
可移植性依从性
软件遵循与可移植性相关的标准或约定的能力
1.4.6. 系统测试流程
测试报告输出
测试日报
(1)方便测试工程师学握测试进度和测试情况，用于整条下一天的工作计划
(2) 测试工程师对被测对象每天给出评估结果，用于调整后续工作中的测试策略
(3)测试经理通过测试日报了解每个测试工程师的工作进度，把握测试整体进度，发
软件测试小讲堂
25
(4)测试经理通过测试日报，了 解各模块缺陷发展趋势，判断测试是否可以退出，通常可利用缺陷管理 T 具的统计
分析功能了解缺陷发展状况
(5)开发经理根据测试日报了解被测对象质量情况，并可以调整缺陷修改人力资源
(6)如果产品有多个测试组并行测试，测试日报可以提供彼此测试交流的手段
测试报告
(1)软件测试工程师评估当前被测对象的质量，并对下一阶段的测试工作给出建议
(2)测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量
(3)软件开发项目经理通过软件测试报告了解开发产品的质量情况，并在下阶段的开发工作中采取应对措施
(4)在测试报告中，测试工程师给出的产品质量评估可以作为软件产品是否商用发布的重要参考依据
测试结束活动
(1)检查在测试过程中测试计划中定义的输出物
(2)缺陷管理是否完成。是否经进入缺陷管理流程
(3)测试实施过程中产生的风险报告需要记录
软件测试小讲堂
26
(4)测试报告是否给出，相关的经验教训是否总结并分享
(5)是否需要移交测试对象
1.5. 运维
1.5.1. 发布
1.5.2. 部署
1.5.3. 维护
1.6. 全员质量共建
1.6.1. 从需求出发
我们只有在全面、深入了解需求的基础上，才能设计全面、有效的测试用例来进行测试，以满足对于软件产品满足需
求的基本质量保证
1.6.2. 测试依据
测试设计的依据是对于软件产品需求的全面和深入分析
因为我们不仅要验证需求，而且要验证设计
软件测试小讲堂
27
我们根据对需求的全面深入分析和对设计实现的了解，两相综合产生的测试设计
1.6.3. 测试人员不只是验证质量
测试人员无法保证软件产品的质量，软件产品的质量是通过参与软件过程的各方联合共同保证的
由于软件测试人员不是产品设计人员和开发人员，所以无法做到比他们更了解产品需求和产品设计，如果他们都无法
保证需求和设计没有问题，那么测试人员就更无法保证了
软件测试位于软件开发生命周期的末端，如果依靠测试人员来发现所有的 bug 来保证质量的话，那么风险就会后置，
导致问题修复的成本增加，同时也增加了修复问题带来新问题的风险，因为在项目末端是不可能投入过多的成本来进
行那怕接近全面覆盖的测试的。
测试人员只能根据前期分析的结果，设计出测试用例，来验证软件产品在事先设计或后续补充的测试用例上不存在问
题
实际上，如果最终发布的软件产品出现了问题，那么无论如何我们肯定是有责任的。
1.6.4. 测试的内容一定是确定的
软件测试只能验证质量，那么所要验证的内容必然是确定的，或者说是概率确定的，否则也就无从验证了
软件产品的可测性判断是我们进行需求评审和设计评审时是一定要保证这个基本点的
软件测试小讲堂
28
1.6.5. 测试的目标不是没有 bug
软件测试的目标不是通过测试使得软件产品不存在 bug（这是不可能达成的），而是我们根据确定的需求、确定的设
计和确定的测试用例验证出的结果不存在 bug
而是运用测试思维，使用一定的测试方法，尽可能早地在需求阶段、设计阶段将所有的 bug 找出来，真正测试执行阶
段只是验证不存在用例所描述的那样的 bug，而不是通过用例去发现 bug
2. 思维
2.1. 整体思维也叫框架思维
2.1.1. 从整体的高度去设计测试用例
2.1.2. 首先验证主流程是否通畅
2.1.3. 五原则
连续性原则
即当思维对象确定后，思维主体就要从许多纵的方面去反映客观整体，把整个客观整体视为一个有机延续而不间断
的发展过程
立体性原则
软件测试小讲堂
29
即当思维对象确立之后，思维主体要从横的方面，也就是从客观事物自身包含的各种属性整体地考察它、反映它，
使整体性事物内在诸因素之间的错综复杂关系的潜网清晰地展示出来
系统性原则
即是从纵横两方面来对客观事物进行分析和综合，并按客观事物本身所固有的层次和结构，组成认识之网，逻辑再
现客观事物的全貌。
动态稳定性原则
系统的稳定是相对的
必须会受到外部因素的干扰而变得不再稳定，如政策调整，热度冷却，市场条件，财务因素、物理环境等
发散性原则
由一个功能联想到其他可能存在关联的功能，由一而二，由二而三
2.2. 逆向思维
2.2.1. 对接口做测试，通过输入验证输出，如果我们使用各种输入都无法得到接口设计中某一种输出的情况时，就需要
从输出来逆向推导输入
2.3. 两极思维
软件测试小讲堂
30
2.3.1. 在事情的两个极端
常说的边界值问题
2.4. 拆分思维
2.4.1. 拆分成一个个的最小单位去执行测试
2.5. 创新思维
2.5.1. 了解不知道的业务流程
2.5.2. 学习有可能用得上的测试技术
2.5.3. 丰富测试用例
2.5.4. 优化测试方法
2.6. 架构思维
2.6.1. 架构对测试的影响
软件测试小讲堂
31
首先是稳定性。稳定性可以降低在版本更新时扩展系统功能的重复老师，并减少实施过程的总成本。它巩固了开发团
队的基础，使其专注于开发更大价值的特性，而并非浪费精力关注在经常变更的问题上。对于良好的系统架构，会使
测试设计更稳定，减少因变更带来的测试工作量。
对变更的度和性质。架构决定系统中发生变更的性质。有些变更很容易被察觉，而察觉另一些则很难。在我们为吸引
更多客户而需要提高客户满意度或增加功能时，如果能够简单实现预期的变更，那么各种架构通常被认为是好的。系
统的功能需求变更，使系统受影响的部分最小，避免大量的回归测试。
边界的决定。在架构的设计过程中，团队会就哪些应该被加入到系统中，而哪些不应该被加入到系统中做出很多决
定。例如，是团队自己写数据库访问层，还是购买许可？团队是使用开源的 Web 服务器还是购买许可？那个子团队应
该负责用户界面的设计？成功的解决方案确实能够创建技术边界来支持业务的特殊需求。这些边界选择可直接影响我
们的测试，例如，服务器监控、服务器性能参数调优等。
可持续的、不可替代的优势。这一点可以概括前面的几点，但是一个好的架构能够使系统在市场竞争由于难于复制而
占据优势地位。例如在性能和易用性方面获得优势。这对于我们测试来说，可以减少缺陷，性能更能达到目标而减少
系统调优后反复测试的过程。
2.6.2. 测试方向
了解并熟悉开发使用的技术及开发框架
理解研发设计的架构及设计思路，并考察开发设计是否满足业务需求
软件测试小讲堂
32
Review 技术方案时，考察是否满足易维护性，易扩展以及对性能和安全的要求，并且在关键业务出现异常时是否添加
报警等
2.6.3. 对系统架构的理解
逻辑视图。它提供了系统开发中对象间或实体间相互关系的静态快照。这种视图实际上可能有两个或更多的表现层。
一个概念模型，另一个是数据库模式中模型的实现。往往现在数据库架构师使用 PowerDesigner 描述实体的逻辑关
系，所以需要我们测试工程师学会查看数据库实体描述，从而了解系统中的数据库设计，例如关键字，索引、表实体
之间的关系等。
过程视图。过程视图描述设计的并发性和同步性因素。我们了解过程视图，从而会了解系统中各个模块之间的时间、
空间关系。原来的结构化编程中经常用流程图来表示，而现在面向对象的编程经常用一些建模工具描述对象实体。例
如，架构师经常使用 Rose 等建模工具，建立实体的序列图、状态图等来描述过程。而我们测试工程师应该学会看懂序
列图或状态图等
物理视图。物理视图描述软件到硬件的映射，其中包括实现高可用性、可靠性、容错性和性能等目标的处理部件的分
布情况。常用 Rose 部署图来描述物理视图，也可以使用 Visio 等绘图工具绘制系统架构图来描述。
开发视图。开发视图描述软件在开发环境中的静态组织结构。研发团队通常用 Rose 等建模工具绘制实体关系图，描述
各个实体之间的静态关系。
2.7. 用户思维
软件测试小讲堂
33
2.7.1. 别让我等
2.7.2. 别让我想
2.7.3. 别让我烦
2.7.4. 别让我找
3. 意识
3.1. 风险意识
3.1.1. 人员风险
现有人员技术不足以支撑新的业务测试模型
人才资源无法满足新的业务测试需求
3.1.2. 技术风险
技术方案存在风险
开发人员对业务需求理解不到位
开发人员对业务场景认知不完整
软件测试小讲堂
34
3.1.3. 业务风险
业务场景前后矛盾