软件测试知识体系图谱

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. 业务风险
业务场景前后矛盾
本期需求与原有需求存在矛盾但没有被重构
需求反认知
3.1.4. 排期风险
需要根据自己的有效判断，来提前提出风险预警
需要提示风险范围，以提前部署规避风险方案或应对方案
有风险不代表不可完成，有意识不代表不需要努力去做
3.2. 团队协作意识
3.2.1. 合理进行人员分工
3.2.2. 配合完成测试任务
3.2.3. 配合开发重现缺陷
3.2.4. 督促项目整体进度
软件测试小讲堂
35
3.2.5. 协助组员解决问题
3.3. 成本意识
3.3.1. 时间成本
3.3.2. 人力成本
3.3.3. 经济成本
3.4. 分享意识
3.4.1. 技术分享
3.4.2. 经验分享
3.4.3. 方案分享
3.5. 怀疑意识
3.5.1. 对产品的质量持有一颗敢于怀疑的心，质量不是开发人员说"我做完了而且也测过了"就可以保证的。直到你测完最
后一轮，最后一个用例之前，你都应该对产品的质量持怀疑态度。这个态度是混口饭吃的最基本技能
3.6. 责任意识
软件测试小讲堂
36
3.6.1. 自认为测试达到 100%的完美后，发起上线流程
3.6.2. 测试产出与时间成本成反比时，发起上线流程
3.6.3. 不能无休止的测试
3.6.4. 对于你测试的产品负责任
3.6.5. 测试没有真正的 100%，但是要有自己的 100%
3.7. 公因式意识
3.7.1. 合并可以合并的东西
3.7.2. 抽取一致性的东西
3.8. 杀虫剂悖论
3.8.1. 测试用例需要经常的评审和修改，不断增加新的不同的测试用例来测试软件或系统的不同部分，保证测试用例永
远是最新的，即包含着最后一次程序代码或说明文档的更新信息
3.8.2. 软件中未被测试过的部分或者先前没有被使用过的输入组合就会重新执行，从而发现更多的缺陷。软件测试人员
必须不断地编写新的不同的测试来检验程序的不同部分从而找出更多的 bug。让其他的人来测试你的程序将有助于打破”
杀虫剂悖论”
软件测试小讲堂
37
4. 能力
4.1. 测试核心能力
4.1.1. 测试策略设计能力
测试策略设计能力是指，对于各种不同的被测软件，能够快速准确地理解需求，并在有限的时间和资源下，明确测试
重点以及最适合的测试方法的能力。
4.1.2. 测试用例设计能力
测试用例设计能力是指，无论对于什么类型的测试，都能设计出高效地发现缺陷，保证产品质量的优秀测试用例。
要做好测试用例设计，不仅需要深入理解被测软件的业务需求和目标用户的使用习惯，还要熟悉软件的具体设计和运
行环境，包括技术架构、缓存机制、中间件技术、第三方服务集成等等。
测试用例设计能力要求你不仅仅局限于熟悉业务领域的测试用例设计，而是能够融会贯通，熟练地把系统性的测试设
计方法和具体业务有机结合，对任何被测软件都可以输出出色的测试用例。
要想提高测试用例设计能力，你平时就要多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，要不断地
总结、归纳，才能逐渐形成体系化的用例设计思维。
软件测试小讲堂
38
同时，你还可以阅读一些好的测试用例设计实例开阔思路，日后遇到类似的被测系统时，可以做到融会贯通和举一反
三。
4.1.3. 快速学习能力
对不同业务需求和功能的快速学习与理解能力
对于测试新技术和新方法的学习与应用能力
4.1.4. 探索性测试思维
探索性测试是指，测试工程师在执行测试的过程中不断学习被测系统，同时结合基于自己经验的错误猜测和逻辑推
理，整理和分析出更多的有针对性的测试关注点
4.1.5. 缺陷分析能力
对于已经发现的缺陷，结合发生错误的上下文以及后台日志，可以预测或者定位缺陷的发生原因，甚至可以明确指出
具体出错的代码行，由此可以大幅缩短缺陷的修复周期，并提高开发工程师对于测试工程师的认可以及信任度；
根据已经发现的缺陷，结合探索性测试思维，推断同类缺陷存在的可能性，并由此找出所有相关的潜在缺陷；
可以对一段时间内所发生的缺陷类型和趋势进行合理分析，由点到面预估整体质量的健康状态，并能够对高频缺陷类
型提供系统性的发现和预防措施，并以此来调整后续的测试策略。
软件测试小讲堂
39
4.1.6. 自动化测试技术
掌握自动化测试技术，可以把你从大量的重复性手工劳动中解放出来，这样你可以把更多的时间花在更多类型的测试
上
4.1.7. 良好的沟通能力
一方面，你需要对接产品经理和项目经理，以确保需求的正确实现和项目整体质量的达标；
另一方面，你还要和开发人员不断地沟通、协调，确保缺陷的及时修复与验证。
4.2. 基础测试能力
4.2.1. 理解一些流程相关的东西，如 需求分析、测试计划、缺陷跟踪等
4.2.2. 测试要具体执行到什么程度；
4.2.3. 测试需要借助于什么工具；
4.2.4. 如何运用自动化测试以及自动化测试框架，以及如何选型；
4.2.5. 测试人员资源如何合理分配；
4.2.6. 测试进度如何安排；
软件测试小讲堂
40
4.2.7. 测试风险如何应对。
4.3. 环境治理能力
4.3.1. 快速部署环境，保证测试环境的持续可用状态
4.3.2. 脏数据的处理
4.3.3. 环境切换导致的问题回退
4.4. 专项测试能力
4.4.1. 性能测试
4.4.2. 安全测试
4.4.3. 接口测试
4.4.4. 大数据测试
4.4.5. 人工智能测试
4.5. 工具开发能力
软件测试小讲堂
41
4.5.1. 自动化工具是提高测试效率的利器，将一些重复性的工作自动化掉，能够避免被繁杂的手工测试所拖累，专注于
更核心的测试工作上去
4.6. 沟通协调能力
4.6.1. 测试工作在项目中起到了承上启下的作用，在这过程中有很多资源需要协调，很多问题需要反复沟通，例如 测试
同学需要推动开发去做一些自测，这样才能提升交付质量，出现 bug 后，需要推动开发同学快速修复 bug。因此沟通协
调能力也是测试工程师不容忽视的能力
4.7. 用例设计能力
4.7.1. 作用
⒈指导测试的实施
⒉规划测试数据的准备
⒊编写测试脚本的"设计规格说明书"
⒋评估测试结果的度量基准
⒌分析缺陷的标准
4.7.2. 设计原则
软件测试小讲堂
42
(1)正确性。输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖
需求规格说明书中的各项功能，并且正常。
(2)全面性。覆盖所有的需求功能项;设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分
关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。
(3)连贯性。用例组织有条理、主次分明，尤其体现在业务测试用例上;用例执行粒度尽量保持每个用例都有测点，不能
同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。
(4)可判定性。测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。
(5)可操作性。测试用例中要写清楚测试的操作步骤，以及与不同的操作步骤相对应的测试结果。
4.7.3. 设计格式
预置条件
测试步骤
预期结果
测试数据
4.7.4. 设计方法
软件测试小讲堂
43
等价类划分法
边界值分析法
错误推测法
判定表法
正交实验法
4.7.5. 组织结构
业务需求
发散场景
接口分支
数据库表
4.7.6. 自动化测试用例
4.8. 质量管理能力
4.8.1. 原则
软件测试小讲堂
44
原则 1： 以顾客为关注焦点
原则 2： 领导作用
原则 3： 全员参与
原则 4： 过程方法
原则 5： 管理的系统方法
原则 6： 持续改进
原则 7： 基于事实的决策方法
原则 8： 与供方的互利关系
4.8.2. 管理方法
全面质理管理（TQM）
六西格玛
QC 七大手法
检查表
软件测试小讲堂
45
排列图
散布图
数据分层法
休哈特控制图
鱼骨图
直方图
4.8.3. 工具
1. 控制图
是用图形显示某项重要产品或过程参数的测量数据。在制造业可用轴承滚珠的直径作为例子。在服务行业测量值可
以是保险索赔单上有没有列出某项要求提供的信息。依照统计抽样步骤，在不同时间测量。控制图显示随时间而变
化的测量结果，该图按正态分布，即经典的钟形曲线设计。用控制图很容易看出实际测量值是否落在这种分布的统
计界线之内。上限叫"控制上限"，下限叫"控制下限"。如果图上的测量值高于控制上限或低于控制下限，说明过程失
控。这样就得仔细调查研究以查明问题所在，找出并非随机方式变动的因素。是制造轴承滚珠用的钢棒太硬？太
软？还是钢棒切割机上切割量调节值设得不对？
软件测试小讲堂
46
2. 帕累托图又叫排列图
，是一种简单的图表工具，用于统计和显示一定时间内各种类型缺陷或问题的数目。其结果在图上用不同长度的条
形表示。所根据的原理是十九世纪意大利经济学家维尔弗雷德.帕雷托（Vilfred Pareto）的研究，即各种可能原因中
的 20%造成 80%左右的问题；其余 80%的原因只造成 20%的问题和缺陷。为了使改进措施最有效，必须首先抓住造
成大部分质量问题的少数关键原因。帕雷托图有助于确定造成大多数问题的小数关键原因。该图也可以用于查明生
产过程中最可能产生某些缺陷的部位。
3.鱼骨图也称为因果分析图
它看上去有些像鱼骨，问题或缺陷（即后果）标在"鱼头"外。在鱼骨上长出鱼刺，上面按出现机会多寡列出产生生
产问题的可能原因。鱼骨图有助于说明各个原因之间如何相互影响。它也能表现出各个可能的原因是如何随时间而
依次出现的。这有助于着手解决问题。
4. 走向图有时也叫趋势图。
它用来显示一定时间间隔（例如一天、一周或一个月）内所得到的测量结果。以测得的数量为纵轴，以时间为横轴
绘成图形。走向图就象不断改变的记分牌。它的主要用处是确定各种类型问题是否存在重要的时间模式。这样就可
以调查其中的原因。例如，按小时或按天画出次品出现的分布图，就可能发现只要使用某个供货商提供的材料就一
定会出问题。这表示该供货商的材料可能是原因所在。或者发现某台机器开动时一定会出现某种问题，这就说明问
题可能出在这台机器上。
软件测试小讲堂
47
5. 直方图也称线条图。
在直方图上，第一控制类别（对应于一系列相互独立的测量值中的一个值）中的产品数量用条线长度表示。第一类
别均加有标记，条线按水平或垂直依次排列。直方图可以表明哪些类别代表测量中的大多数。同时也表示出第一类
别的相对大小。直方图给出的是测量结果的实际分布图。图形可以表现分布是否正常，即形状是否近似为钟形。
6. 分布图
提供了表示一个变量与另一个变量如何相互关联的的标准方法。例如要想知道金属线的拉伸强度与线的直径的关
系，一般是将线拉伸到断裂，记下使线断裂时所用的力的准确数值。以直径为横轴，以力为纵轴将结果绘成图形。
这样就可以看到拉伸强度和线径之间的关系。这类信息对产品设计有用。
7. 流程图
有时也称作输入-输出图。该图直观地描述一个工作过程的具体步骤。流程图对准确了解事情是如何进行的，以及决
定应如何改进过程极有帮助。这一方法可以用于整个企业，以便直观地跟踪和图解企业的运作方式。流程图使用一
些标准符号代表某些类型的动作，如决策用菱形框表示，具体活动用方框表示。但比这些符号规定更重要的，是必
须清楚地描述工作过程的顺序。流程图也可用于设计改进工作过程，具体做法是先画出事情应该怎么做，再将其与
实际情况进行比较。
4.8.4. 价值观
质量第一:
软件测试小讲堂
48
质量是企业的生命，质量是一切的基础，企业要生存和盈利，就必须坚持质量第一的原则，从始至终能够为顾客提
供满意质量的产品和服务，才能在激烈的竞争中利于不败之地。
零缺陷:
零缺陷是以抛弃缺点难免论，树立无缺点的哲学观念为指导，要求全体人员“从开始就正确地进行工作，第一次就把
事情做对”，以完全消除工作缺点为目标的质量经营活动。
源头管理:
质量管理应以预防为主，将不良隐患消灭在萌芽状态，这样不仅能保证质量，而且能减少不要的问题发生，降低变
更次数，使企业整体的工作质量和效率得到提高。
顾客至上:
现代企业掌握在顾客手中，对于我们企业而言，把顾客需要放在第一位，全心全意为顾客服务。企业要树立好“顾客
至上”的服务理念，把为顾客服务摆在第一位，想顾客之想，急顾客所急。
满足需要:
质量是客观的固有特性与主观的满足需要的统一，质量不是企业自说自话，而是是否能够满足顾客的需求，只有满
足了顾客需要，顾客才会愿意买单，企业才能实现盈利。
软件测试小讲堂
49
一把手质量:
企业一把手的一言一行从始至终受到全体员工的特别关注，他对质量的认知、观点与态度很大程度上决定了员工工
作质量的好坏，一把手应确保企业的质量目标与经营方向一致，全面推进质量工作的开展。
全员参与：
现代企业的质量管理需要全员参与，它不仅仅是某个人、几个质量管理人员或质量管理部门一个部门的事情，它需
要各个部门的密切配合，需要全员的共同参与。
持续改进：
持续改进整体业绩是企业永恒的话题，持续改进是质量管理的原则和基础，是质量管理的一部分，质量管理者应不
断主动寻求企业过程的有效性和效率的改进机会，持续改进企业的工作质量。
基于事实的决策方法：
质量管理要求尊重客观事实，用数据说话，真实的数据既可以定性反映客观事实，又可以定量描述客观事实，给人
以清晰明确的直观概念，从而更好的分析和解决问题。
下工序是顾客：
软件测试小讲堂
50
作为企业的员工，工作时不能只考虑自己的方便，要明确自己对上工序的要求，充分识别下工序的要求，及时了解
工序发来的反馈信息，把下工序当做顾客，经常考虑怎样做才能使下工序顾客满意。
规则意识：
规则意识是指发自内心的，以规则为自己行动准绳的意识。企业每个人都要树立规则意识，敬畏规则，规则不合
理，甚至不正确我们可以或者争取改变，从内心树立起规则意识，学习、遵循、监督和执行规则。
标准化预防再发生：
问题发生了，就要去解决，并且确保同样问题不会再因同样的理由而发生。问题解决后，要标准化解决方案，更新
作业程序，实施 SDCA 循环。
尊重人性：
很多时候，质量工作需要与人沟通，企业经营者为了持续发展和提升质量，就要充分尊重从事的工作人员，使员工
感受到工作的意义与价值，快乐工作才能更好地提供顾客满意的工作质量。
5. 流程
5.1. 测试执行流程
5.2. 缺陷提交流程
软件测试小讲堂
51
5.2.1. 提交人员
测试人员
研发人员
产品人生
项目人员
5.2.2. 缺陷依据
需求原型
UI 设计
测试用例
接口和数据库文档
用户体验
5.2.3. 定位缺陷
分析原因
软件测试小讲堂
52
定位代码
前端缺陷
后台缺陷
5.2.4. 生命周期
新建
活动
解决
激活
关闭
5.3. 工作监督流程
5.4. 问题收集流程
5.5. 性能测试流程
5.5.1. 需求分析
软件测试小讲堂
53
业务指标
对接产品方
技术方案
对接研发方
服务器架构
对接运维方
5.5.2. 测试计划
搭建测试环境
真实生产环境
等比测试环境
测试场景设计
关键链路设计
监控项列举
软件测试小讲堂
54
测试脚本选型
手动开发
自动录制
测试计划执行
数据准备
基础数据
存量数据
测试监控
业务指标监控
操作系统指标监控
应用中间件监控
前端提标监控
数据库指标监控
软件测试小讲堂
55
测试执行
单接口压测
串联链路压测
全链路压测
测试目标
容量测试
负载测试
压力测试
性能调优
硬件/规格上的瓶颈
一般指的是 CPU、内存、磁盘 I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈
中间件上的性能瓶颈
软件测试小讲堂
56
"①应用服务器、web 服务器等应用软件，还包括数据库系统。例如：中间件 weblogic 平台上配置的 JDBC 连接池
的参数设置不合理，造成的瓶颈
②防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品"
应用程序上的性能瓶颈
JVM 参数不合理，容器配置不合理，慢 SQL，数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串
行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等）
操作系统上的性能瓶颈：
一般指的是 windows、UNIX、Linux 等操作系统
其他调优
"①更换技术实现方案
②调整产品逻辑"
测试结果
分析
软件测试小讲堂
57
系统性能指标
资源指标
数据库指标
前端指标
稳定性指标
可扩展性指标
交付
测试报告
5.6. 复盘提升流程
5.7. 部门协作流程
6. 自驱
6.1. 专心
6.1.1. 要集中精力，不可一心二用。精力集中不仅能够提高工作效率，还能发现更多的软件缺陷。
软件测试小讲堂
58
6.2. 细心
6.2.1. 软件测试人员必须细致执行，不忽略关键详解。若不细心，有些软件缺陷将很难被发现。
6.3. 耐心
6.3.1. 软件测试会很枯燥，需要很大的耐心才需要做好。如果比较浮躁，也不会做到专心和细心，很多缺陷将从眼前逃
掉。
6.4. 责任心
6.4.1. 责任心是做好任何工作的必备素质之一，软件测试尤其如此。软件测试往往起到最后把关的作用，如果敷衍了
事，软件缺陷就会被放进发布版本或最终应用中，很可能造成非常严重的后果。
6.5. 自信心
6.5.1. 自信心是很多测试人员缺少的一项素质，遇到困难缩手缩脚，不敢上线。但具备了较强的自信心，才能更好地与
用户和开发方交谈，才能更好地开展测试工作和发现缺陷。软件测试人员必须建立起能解决一切测试问题的信心。
6.6. 自驱力
6.6.1. 不要轻易背弃你给自己定的目标，不要轻易抛弃属于你曾经的王者荣耀
7. 技术
软件测试小讲堂
59
7.1. 功能测试
7.1.1. 功能测试是能用
7.1.2. 性能测试是好用
7.1.3. 自动化测试是快点用
7.1.4. 安全测试是放心用
7.2. 接口测试
7.2.1. 什么是接口
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点，定义特定的交互点，然后通过这些交互点
来，通过一些特殊的规则也就是协议，来进行数据之间的交互
7.2.2. 接口类型
程序内部的接口
方法与方法之间，模块与模块之间的交互，程序内部抛出的接口
系统对外的接口
软件测试小讲堂
60
接口
webservice 接口
webService 接口是走 soap 协议通过 http 传输，请求报文和返回报文都是 xml 格式的，我们在测试的时候都用通过工
具才能进行调用，测试。
http api 接口
http api 接口是走 http 协议，通过路径来区分调用的方法，请求报文都是 key-value 形式的，返回报文一般都是 json
串，有 get 和 post 等方法，这也是最常用的两种请求方式
7.2.3. 本质
接口你可以简单的理解他就是 URL，工作原理就会说 URL 通过 get 或者 post 请求像服务器发送一些东西，然后得到一
些相应的返回值，本质就是数据的传输与接收
7.2.4. 接口测试定义
测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测
试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等
7.2.5. 为什么做
软件测试小讲堂
61
越底层发现 bug，它的修复成本是越低的。
前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1 元，但是通过接口可以传入-
1 元。
如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的
解决方案。
接口测试相对容易实现自动化持续集成，且相对 UI 自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短
测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
现在很多系统前后端架构是分离的，从安全层面来说：
(1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行
控制，在这种情况下就需要从接口层面进行验证。
(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份
证，银行卡等。
7.2.6. 测试点
软件测试小讲堂
62
目的：测试接口的正确性和稳定性
原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端
接收应答的过程
重点：检查数据的交换，传递和控制管理过程，还包括处理的次数
核心：持续集成是接口测试的核心；
优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显
（提高测试效率，提升用户体验，降低研发成本）
用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数
据流出系统接口（验证系统处理后的数据是否正常）；
7.2.7. 标准
业务功能覆盖是否完整
业务规则覆盖是否完整
参数验证是否达到要求（边界、业务规则）
接口异常场景覆盖是否完整
软件测试小讲堂
63
接口覆盖率是否达到要求
代码覆盖率是否达到要求
性能指标是否满足要求
安全指标是否满足要求
7.2.8. 知识点
了解系统及内部各个组件之间的业务逻辑交互
了解接口的 I/O（input/output：输入输出）
协议的基本内容
通信原理
三次握手
常用的协议类型
报文构成
数据传输方式
软件测试小讲堂
64
常见的状态码
URL 构成等
7.2.9. 接口测试工具
jmeter
loadrunner
postman
soapUI
fiddler
python 自动化
7.2.10. 接口文档要素
接口信息
接口调用方式，常用的 GET/POST 方式，接口地址
功能描述
软件测试小讲堂
65
简洁清晰的描述接口功能，比如：接口获取的信息不包括哪些
接口参数说明
每个参数都要和实际中调用的一样，包括大小写；参数的含义言简意赅的说明，格式，是 string 还是 int 还是 long 等
格式
返回值说明
最好有一个模板返回值，并说明每个返回参数的意义；
提供一个真实的调用接口，真实的返回值；
调用限制，安全方面
加密方式，或者自己公司一个特殊的加密过程，只要双方采用一致的加密算法就可以调用接口，保证了接口调用的
安全性，比如常见的 md5
文档维护
文档在维护的时候，如有修改一定要写上修改日期，修改人，对大的修改要有版本号变更
7.3. 兼容测试
软件测试小讲堂
66
7.3.1. 网络兼容性
弱网
断网
有网无数据
7.3.2. 机型兼容性
系统兼容
分辨率兼容
屏幕兼容
7.3.3. 浏览器兼容
Trident（也称 IE 内核）
webkit
Blink
Gecko
软件测试小讲堂
67
7.3.4. 新旧数据兼容性
数据类型转换
数据格式变换
文件格式转换
7.3.5. 软件兼容性
软件与软件
软件与硬件
7.4. 性能测试
7.4.1. 性能测试目的
验证改进性能效果，需要和以前的测试结果进行比对；
新的业务上线，验证新系统能够满足系统的上线指标。
验证系统稳定性；
验证系统的架构是否存在瓶颈。
软件测试小讲堂
68
7.4.2. 性能测试目标
1、 系统新上线、测试明确的数字标准对比情况下，验证系统是否可以上线。测试系统的极限，如：系统某些资源已
经耗尽，CPU、句柄、内存、数据库出现大量的 slow query、或者系统有些处理已经变量）或者证明系统能否根据硬件
水平扩展的。
2、 没有可以比较的测试结果，但是产品已经上线一段时间（一般 3 个月以上），有一些运营数据，则分析运营数据
来作为比对基准，只要测试系统达到 3 个月内系统并发峰值的 4 倍就可以认为是可以接受的。（如果是接口为测试对
象，则需要混合主要的接口来进行性能测试）
3、 有以往测试结果进行对比，只要证明类似的测试条件下，此次的结果比以往的测试结果更好即可（每秒处理个数
更多、单次请求的处理速度更快等）
4、 开发人员提供经验值作为对比的基准，则被测对象只需要证明满足开发人员提出的经验值。
7.4.3. 一般出现瓶颈点
硬件上的性能瓶颈
一般指的是 CPU、内存、磁盘 I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器
操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web 服务器等）、应用瓶颈（SQL 语句、数据库设
计、业务逻辑、算法等）
软件测试小讲堂
69
应用软件上的性能瓶颈
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。
例如：中间件 weblogic 平台上配置的 JDBC 连接池的参数设置不合理，造成的瓶颈。
应用程序上的性能瓶颈
一般指的是开发人员新开发出来的应用程序。
例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户方位
时性能低下而造成的瓶颈。
操作系统上的性能瓶颈
一般指的 Linux 等操作系统，我们用的是 CentOS
例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而
导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈
网络设备上的性能瓶颈
一般指的是防火墙、动态负载均衡器、交换机等设备。
软件测试小讲堂
70
例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动
态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相
应的作用，这时可以认为网络瓶颈。
7.4.4. 性能测试原则
情况许可时，应使用几种测试工具或手段分别独立进行测试，并将结果相互印证，避免单一工具或测试手段自身缺陷
影响结果的准确性；
对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；
3）查找瓶颈的过程应由易到难逐步排查：
服务器硬件瓶颈及网络瓶颈（局域网环境下可以不考虑网络因素）
应用服务器及中间件操作系统瓶颈（数据库、WEB 服务器等参数配置）
应用业务瓶颈（SQL 语句、数据库设计、业务逻辑、算法、数据等）
性能调优过程中不宜对系统的各种参数进行随意的改动，应该以用户配置手册中相关参数设置为基础，逐步根据实际
现场环境进行优化，一次只对某个领域进行性能调优（例如对 CPU 的使用情况进行分析），并且每次只改动一个设
置，避免相关因素互相干扰；
软件测试小讲堂
71
调优过程中应仔细进行记录，保留每一步的操作内容及结果，以便比较分析；
性能调优是一个经验性的工作，需要多思考、分析、交流和积累；
了解“有限的资源，无限的需求”；
尽可能在开始前明确调优工作的终止标准。
7.4.5. 测试环境
一个稳定、可重复的测试环境，能够保证测试结果的正确保证达到测试执行的技术需求保证得到正确的、可重复的以
及易理解的测试结果
生产环境
衡量的精准度较高，参考效果
更好，但是需要清理相关的测试数据（同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分
）或者 BI 统计的时候过滤，或者是全链路压测方式，生产环境的压测尽量挑选在
低峰期进行，避免对生产业务造成影响
测试环境
软件测试小讲堂
72
风险可控，难点在环境的构建上，规模和生产一致的成本也是最高的，所以一般而言有通过等比构建（1/2，1/4，
1/8 等），甚至是生产环境中部分应用独立部署测试集群，数据库共用的方式，此外测试环境需要从生产环境中导入
脱敏的基础数据，比如至少是最近半年或者 1 年的，保持其整体的数据关联性，这个对于压测的准确度和参考性也
很重要。
搭建环境
测试环境架构与生产环境架构完全相同
测试环境机型与生产环境机型尽量相同，云化的资源确保是同规格 ECS 或者容器
测试环境软件版本与生产环境软件版本完全相同，版本主要包括：操作系统、中间件相关、数据库、应用等
测试环境参数配置与生产环境完全相同，参数主要包括：操作系统参数、中间件参数、数据库参数、应用参数
测试环境基础数据量与生产环境基础数据量需在同一个数量级上。
只能减少测试环境机器台数，并且需要同比例缩小，而不能只减少某一层的机器台数。
理想的测试环境配置是生产环境的 1/2，1/4。
调研环境
系统架构：系统如何组成的，每一层功能是做什么的，与生产环境有多大差异，主要为后面进行瓶颈
软件测试小讲堂
73
分析服务和生产环境性能评估，这个很重要。
操作系统平台：操作系统是哪种平台，进行工具监控。
中间件：哪种中间件，进行工具监控和瓶颈定位。
数据库：哪种数据库，进行工具监控和瓶颈定位。
应用：启动多少个实例，启动参数是多少，进行问题查找和瓶颈定位。
7.4.6. 性能测试分类
负载测试
容量测试
压力测试
基准测试
在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考
7.4.7. 测试指标
资源指标
软件测试小讲堂
74
CPU 资源利用率
CPU 指标主要指的 CPU 利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。CPU 利用率要低于业
界警戒值范围之内，即小于或者等于 75%;CPU sys%小于或者等于 30%, CPU wait%小于或者等于 5%。单核 CPU 也需
遵循上述指标要求。CPU Load 要小于 CPU 核数。
。CPU Load: 系统正在干活的多少的度量，队列长度。系统平均负载
内存利用率
现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率 100%并不代表内存有瓶颈，衡量系统
内有有瓶颈主要靠 SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP 交换空间利用率要低于 70%,太
多的交换将会引起系统性能低下。
磁盘 I/O
指在无磁盘故障的情况下单位时间内通过磁盘的数据量
磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中
磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于 70%。
网络吞吐量
软件测试小讲堂
75
指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为 Byte/s。网络吞吐量指标用于衡量系统对于
网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络
设备。
网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的 70%。
内核参数
应用指标
空闲线程数
数据库连接数
GC/FULL GC 次数
函数耗时
前端指标
页面加载时间
网络时间
软件测试小讲堂
76
DNS
连接时间
传输时间等
业务指标
交易响应时间
指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间（ms 毫
秒）
系统处理能力
是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数
量来评价
HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。
TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。
软件测试小讲堂
77
对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 TPS=QPS=HPS，一般情况下用 TPS 来衡量整个业
务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器点击请求
并发用户数
指在同一时刻内，登录系统并进行业务操作的用户数量。并发用户数对于长连接系统来说最大并发用户数即是系
统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统
处理能力等各种情况相关
错误率
指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。稳定性较好的系统，其错误率应
该由超时引起，即为超时率
中间件指标
数据库指标
稳定性指标
最短稳定时间：系统按照最大容量的 80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时
间。一般来说，对于正常工作日（8 小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于 7*24 运行
软件测试小讲堂
78
的系统，至少应该能够保证系统稳定运行 24 小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长
时间运行，将会出现性能下降甚至崩溃的风险
批量处理指标
指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口
最重要的计算指标。关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同
一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。长时间批量处理将会对联机在线实时
交易产生重大的性能影响。
可扩展性指标
指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/
原始性能）/（增加资源/原始资源）*100%。扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力非常
好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好
标准
理想的扩展能力是资源增加几倍，性能就提升几倍。
扩展能力至少在 70%以上。
可靠性指标
软件测试小讲堂
79
双机热备
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
节点切换是否成功及其消耗时间
双机切换是否有业务中断
节点回切是否成功及其耗时
双机回切是否有业务中断
节点回切过程中的数据丢失量在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一
定的性能压力，保证测试结果符合生产实际情况。
集群
集群中某个节点出现故障时，系统是否有业务中断情况出现
在集群中新增一个节点时，是否需要重启系统
当故障节点恢复后，加入集群，是否需要重启系统
当故障节点恢复后，加入集群，系统是否有业务中断情况出现
软件测试小讲堂
80
节点切换需要多长时间在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对
应用保持一定的性能压力，确保测试结果符合生产实际情况。
备份和恢复
备份是否成功及其消耗时间
备份是否使用脚本自动化完成
恢复是否成功及其消耗时间
恢复是否使用脚本自动化完成指标体系的运用原则
指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也
不一样，考察的指标项也有很大差别。
部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。
软件测试小讲堂
81
7.5. 自动化测试
7.5.1. 接口自动化
7.5.2. UI 自动化
7.5.3. 机械自动化
7.5.4. 前提条件
需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更
新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要
修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的
项目周期足够长
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程
本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样
一个过程，那么自动化测试便不成立
自动化测试脚本可重复使用
软件测试小讲堂
82
7.6. 白盒测试
7.7. 安全测试
7.7.1. 失效的身份验证机制
只对首次传递的 Cookie 加以验证，程序没有持续对 Cookie 中内含信息验证比对，攻击者可以修改 Cookie 中的重要信
息以提升权限进行网站数据存取或是冒用他人账号取得个人私密资料（测试对象：可以进行传参的 URL，提交请求页
面，登录后的 Cookie）
7.7.2. 会话管理劫持
检测 Web 应用程序会话机制是否存在安全隐患，能否被非法利用（会话劫持，伪装成合法用户）而影响 Web 应用程
序的安全。
7.7.3. SQL 注入
注入攻击漏洞,这些攻击发生在当不可信的 SQL 语句作为命令或者查询语句的一部分,被发送给解释器的时候。攻击者
发送的恶意数据可以欺骗解释器,以执行计划外的命令或者在未被恰当授权时访问数据。
7.7.4. XPath 注入
软件测试小讲堂
83
XPath 注入攻击是指利用 XPath 解析器的松散输入和容错特性，能够在 URL、表单或其它信息上附带恶意的 XPath 查询
代码，以获得权限信息的访问权并更改这些信息。XPath 注入攻击是针对 Web 服务应用新的攻击方法，它允许攻击者
在事先不知道 XPath 查询相关知识的情况下，通过 XPath 查询得到一个 XML 文档的完整内容。
7.7.5. XSS 跨站脚本攻击
恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从
而达到恶意用户的特殊目的。
7.7.6. CSRF 跨站请求伪造
攻击者通过调用第三方网站的恶意脚本来伪造请求，在用户不知情的情况下，攻击者强行递交构造的具有“操作行为”
的数据包。（测试对象：网页中可进行输入的表单）
7.7.7. 不安全的直接对象引用
在具有导出/下载功能的页面参数中修改内容，WEB 服务器便会导出/下载程序源代码或者指定文件（测试对象：URL
中有用户参数的地址，可以进行下载操作的地址）或者当开发人员暴露一个对内部实现对象的引用时,例如,一个文件、
目录或者数据库密匙, 就会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时,攻击者会操控这些引
用去访问未授权数据
7.7.8. 安全配置错误
软件测试小讲堂
84
Config 中的链接字符串以及用户信息，邮件，数据存储信息等都需要加以保护，如果没有进行保护，那么就是安全配
置出现了问题。
7.7.9. 不安全的加密存储
未对需要保护的数据进行加密或者加密算法太弱都是不安全的加密存储
7.7.10. 没有限制 URL 访问
系统已经对 URL 的访问做了限制，但这种限制却实际并没有生效。攻击者能够很容易的就伪造请求直接访问未被授权
的页面（测试对象：需要身份验证的页面）
7.7.11. 传输层保护不足
在身份验证过程中没有使用 SSL/TLS，因此暴露传输数据和会话 ID，被攻击者截听。它们有时还会使用过期或者配置不
正确的证书。（测试对象：登录模块）
7.7.12. 未验证的重定向
（redirectUrl）和转发 攻击者可以引导用户访问他们所要用户访问的站点。而最终造成的后果，重定向会使得用户访
问钓鱼网站或是恶意网站。
7.7.13. 敏感信息泄露
软件测试小讲堂
85
许多 Web 应用程序没有正确保护敏感数据,如信用卡、税务 ID 和身份验证凭据。攻击者可能会窃取或篡改这些弱保护
的数据以进行信用卡诈骗、身份窃取或其他犯罪。敏感数据值需额外的保护,比如在存放或在传输过程中的加密,以及在
与浏览器交换时进行特殊的预防措施。
7.7.14. 功能级访问控制缺失
大多数 Web 应用程序的功能在 UI 页面显示之前,会验证功能级别的访问权限。但是,应用程序需要在每个功能被访问时
在服务器端执行相同的访问控制检查。如果请求没有被验证,攻击者能够伪造请求从而在未经适当授权时访问功能。
7.7.15. 使用含有已知漏洞的组件
组件,比如:库文件、框架和其他软件模块,几乎总是以全部的权限运行。如果使用含有已知漏洞的组件,这种攻击可以造
成更为严重的数据丢失或服务器接管。应用程序使用带有已知漏洞的组件会破坏应用程序防御系统,并使一系列可能的
攻击和影响成为可能。危害比较严重
7.7.16. 缓冲区溢出
当计算机向缓冲区内填充数据位数时超过了缓冲区本身的容量，溢出的数据覆盖在合法数据上。
7.7.17. LDAP 注入
软件测试小讲堂
86
利用 LDAP 注入技术的关键在于控制用于目录搜索服务的过滤器。使用这些技术，攻击者可能直接访问 LDAP 目录树下
的数据库，及重要的公司信息。情况还可能比这更严重，因为许多应用的安全性依赖于基于 LDAP 目录的单点登录环
境。
7.7.18. 篡改输入
利用一些命令或者工具等篡改一些字段的值，从而达到恶意的效果。例如，篡改商品的单价和数量等。
7.8. 大数据测试
7.8.1. 大数据是指无法在一定时间范围内用传统的计算机技术进行处理的海量数据集
7.8.2. 特性
大批量
实时性
可交互
7.8.3. 功能测试步骤
数据预处理验证
软件测试小讲堂
87
我们数据来源可能是关系数据库、日志系统、社交网络等等，所以我们应该确保数据能正确的加载到系统中
我们要验证加载的数据和源数据是一致的
我们要确保正确的提取和加载数据至 hdfs 中
Map Reduce 编程模型验证
Map Reduce 过程工作正常
数据聚合、分离规则已经实现
数据 key-value 关系已正确生成
验证经过 map reduce 后数据的准确性等特性
结果验证
验证数据转换规则是否正确应用
验证数据的完整性和是否成功持久化到目标系统
验证无数据损坏
7.8.4. 非功能测试步骤
软件测试小讲堂
88
性能测试
性能是评估一个大数据分析系统的最为关键的维度，大数据系统性能主要包括吞吐量，任务完工时间，内存利用率
等多个指标，可反应大数据分析平台的处理能力，资源利用能力等性能。可通过 hadoop 性能监控器来监测运行状态
性能指标和瓶颈问题，性能测试采用自动化化方式进行，测试系统在不同负载情况下的性能
容错性测试
可从部分失效中自动恢复，而且不会验证的影响整体性能，特别地，当故障发生时，大数据分析系统应该在进行恢
复的同时继续以可接受的方式进行操作，在发生错误时某种程度上可以继续操作，需根据应用场景来设计解决方案
和具体部署，然后手动测试
可用性测试
高可用性已是大数据分析不可或缺的特性之一，从而保证数据应用业务的连续性.大数据高可用性对很多应用非常关
键，需要严格进行测试和验证，以手动测试为主
扩展性测试
弹性扩展能力对于大数据时代的文件系统尤其重要，文件系统扩展性测试主要包括测试系统弹性扩展能力(扩展/回
缩)及扩展系统带来的性能影响，验证是否具有线性扩展能力,以手动测试为主
稳定性测试
软件测试小讲堂
89
大数据分析系统通常是不间断长期运行，稳定性的重要性不言而喻，稳定测试主要验证系统在长时间
(7/30/180/365*24)允许下，系统是否仍然能够正常运行，功能是否正常.稳定性测试通常采用自动化方式进行，LTP，
10ZONE，POSTMARK,FIO 等工具对测试系统产生负载，同时需要验证功能.
部署方式测试
大数据具备 scale-out 的特点，能够构建大规模，高性能的文件系统集群。针对不同应用和解决方案，文件系统部署
方式会有显著不同；部署方式测试需要测试不同场景下的系统部署方式，包括自动安装配置，集群规模，硬件配置
(服务器,存储，网络),自动负载均衡等，这部分测试不大可能进行自动化测试，需要根据应用场景来设计解决方案和
具体部署，再进行手动测试
数据一致性测试
这里的数据一致性是指文件系统中的数据与从外部写入前的数据保持一致，即写入数据与读出数据始终是一致的.数
据一致性能够表明文件系统可保证数据的完整性，不会导致数据丢失或数据错误，这是文件系统最基本的功能，测
试可用 diff,md5sum 编写脚本自动化测试，LTP 也提供了数据一致性的测试工具
压力测试
大数据分析系统的负载能力是存在上限的，系统过载时，系统就可能存在性能下降，功能异常，拒绝访问等问题。
压力测试是验证系统造大压力下，包括数据多客户端，高 OPS 压力，高 IOPS/吞吐量压力，系统是否仍然能够正常
运行，功能是否正常，系统资源消耗情况，从而为大数据运营提供依据
软件测试小讲堂
90
7.8.5. 数据格式
结构化数据
这指的是高度组织的数据。
密码、电子邮件、电话号码
它可以轻松地存储在任何关系数据库中。
这也意味着可以使用简单的查询轻松地检索/搜索它
半结构化数据
半结构化数据并不是严格按照一种便于访问和搜索的格式组织的。
CSV、XML 和 JavaScript 对象表示法(JSON
半结构化数据通常不存储在关系数据库中。
但是，经过一些处理后，它们可以存储在关系数据库中，并转换为结构化格式。
半结构化数据介于结构化和非结构化数据之间。
它们可以包含标签和其他元数据来实现层次结构和顺序。
软件测试小讲堂
91
在半结构化数据中，相同类型的实体可能具有不同顺序的不同属性
非结构化数据
非结构化数据没有任何预定义的格式。
图片、视频、word 文档、演示文稿、mp3 文件等
它不遵循结构化数据模型。
它没有组织成预定义的结构。
图像、视频、word 文档、mp3 文件可以被视为非结构化数据，即使它们有一个内部结构
这种结构的缺乏使得从关系数据库中存储和检索这样的数据变得很困难
在一个组织中产生的多达 80%的数据是非结构化数据
7.9. 流媒体测试
7.9.1. 业务测试
1.测试对流媒体点播，终端提供播放、暂停、继续、停止、退出操作
2.测试对流媒体点播，终端提供定位播放（即快进、后退）操作
软件测试小讲堂
92
3.测试对流媒体点播，终端提供音量控制和静音操作操作
4.测试对流媒体直播，终端提供播放、停止、退出、音量控制和静音操作
5.测试对于视频下载，终端提供本地回放功能（包括：播放、暂停、继续、停止、退出、定位播放、音量控制和静音
操作。
6.测试对于流媒体播放过程中，若当前速率不能满足流媒体播放时，终端应自动暂停播放并对流媒体内容进行缓存，
在收到足够信息后继续播放
7.测试流媒体播放结束后，终端不能保存流媒体文件的部分或者全部的内容，并且播放器的缓存不可以被访问，视频
下载的文件可以保存在终端
8.测试如果终端支持所选媒体格式，终端应给出相应的提示，有用户选择是否继续播放其中可支持部分
9.测试在流媒体直播、点播和视频下载过程中，如果突然出现关机情况，是否正常响应
10.测试在流媒体直播、点播和视频下载过程中，如果应用程序出现异常，是否正常响应
11.测试在流媒体直播、点播和视频下载过程中，如果浏览器出现异常，是否正常响应
12.测试在流媒体直播、点播和视频下载过程中，如果网络出现异常，是否正常响应
13.测试在流媒体终端收到视频图像的尺寸如果大于播放器屏幕尺寸时，播放器是否正常响应
软件测试小讲堂
93
14.测试在流媒体终端收到视频图像的尺寸如果大于播放器屏幕尺寸时，播放器是否正常响应
15.流媒体窗口全屏和正常之间的切换是否能够实现
16.测试上传文件最大值
17.测试上传文件是否支持中文名称
18.测试删除上传成功的文件
19.测试文件名称的最大值、最小值
20.测试文件名称是否支持特殊字符(包括空格)
21.测试上传过程断网，等网络恢复后，是否支持断点续传
22.测试上传时网速很慢
23.测试上传文件支持的格式
24.测试增加部分功能后系统运行是否正常
25.测试删除部分功能后系统运行是否正常
26.测试缺陷修改后系统运行是否正常
软件测试小讲堂
94
27.流媒体的播放窗口是否可以单独从浏览器窗口中拖拽出来
28.内存不足时，是否有相应的内存不足的提示
29.当前浏览器最小化后，是否停止流媒体的下载过程以节约网络资源
30.在流媒体的播放定位过程中，是否能够出现一个小的视频窗口，以便用户确认定位位置
31.流媒体播放过程中是否有记忆功能，以便中断恢复或下次打开后，从上次浏览处继续查看
7.9.2. 性能测试
码率
指数据传输时单位时间传送的数据位数，单位为 kbps。码率的大小决定视频文件的清晰度、流畅度和大小。码率越
高，画质越好，文件也越大
帧率
帧率用于测量显示帧数的量度，单位为每秒显示帧数（FPS）。高的帧率可以得到更流畅、更逼真的动画。FPS 越
多，显示的动作就会越流畅。一般来说 60FPS 可以明显提升动画的交互感和逼真感，超过 75FPS 流畅度则不会有明
显的提升
丢包率
软件测试小讲堂
95
丢包是网络中数据传输的时候出现数据丢失的现象，丢包率是指丢包数据占总传输数据的百分比。网络丢包率越
高，网速越慢，一般丢包率小于 1%属于正常
平均下载速度
指播放器播放视频过程中下载视频资源的速度。平均下载速度=总下载字节数/吞吐用时。建议值：优秀 >180 KB/s，
一般 >70 KB/s，差 ≤ 70KB/s
视频首包用时
从获取视频真实地址到获取视频资源第一包之间的时间间隔。建议值：优秀 ≤1s，一般 ≤2.5s，差 >2.5s
视频首帧用时
从获取视频真实地址到开始播放视频第一帧之间的时间间隔。其中视频秒开指的是视频页面首屏在 1s 左右快速的展
现出来，视频秒开直接影响着用户体验
页面首屏用时
从开始浏览到页面被渲染出指定高度范围之间的时间间隔。参考值：优秀 ≤3.5s，一般 ≤7s，差 >7s。
卡顿时间
软件测试小讲堂
96
指视频在开始播放后出现的卡顿（缓冲）状态的累计时长（首次缓冲不计算在内）卡顿时间=总缓冲用时-首次缓冲
用时。参考值：优秀 ≤ 6s，一般 ≤12s，差 >12s
St-load
7.10. WEB 测试
7.10.1. 功能测试
跳转测试
页面是否有无法连接的内容
页面是否存死链接
图片是否能正确显示
视频是否能够正常播放
是否有无用的链接
图片链接
点击图片上的链接是否跳转到正确的页面
软件测试小讲堂
97
文字链接
点击文字上的链接是否跳转到正确的页面
点击文章标题的链接
是否可进入相应的文章的详细页面
一侧导航链接
是否可按栏目级别跳转到相应的页面
点击链接本身
是否在另一侧重新加载相应页面
表单测试
注册、登录功能
能够正常注册、登录
密码显示密文
注册成功、登录成功有相应的跳转流程
软件测试小讲堂
98
提交、清空按钮
能够正常提交数据
输入内容与输出内容保持一致
能够正常清空当前输入
再次输入后提交的输出内容与输入内容保持一致
提交的数据是否能正确保存到后台数据库中（后台数据库中的数据应与前台录入内容完全一致，数据不会丢失或被
改变）
表单提交，删除，修改后是否有提示信息
toast 提示
提示后自动消失
弹框提示
提示后可以手动关闭
提示后可以自动关闭
软件测试小讲堂
99
跳转提示
跳转页面正常
浏览器的前进、后退、刷新按钮，是否会造成数据重现或页面报错
提交表单是否支持回车键和 Tab 键；Tab 键的顺序与控件排列顺序要一致，目前流行总体从上倒下，同时行间从左
到右的方式
下拉列表功能是否实现和数据是否完整
省市区匹配一致
年月日时分秒（大月，小月，尤其是 2 月份的天数）匹配一致
24 小时 12 小时制
表单提交数据的完整性校验
输入测试
对于手机、邮箱、证件号等的输入是否有长度及类型的控制
输入 html 语言的，是否能正确显示
软件测试小讲堂
100
是否有必填项的控制
不输入提交数据时有明显示提示信息
非必填项与必填项有明确的标识区分
输入控制
输入超长字段，页面是否被撑开
分别输入大于、等于、小于数据表规定字段长度的数据，是否报错
输入中文、英文、数字、特殊字符（特别注意单引号和反斜杠）,enjoy 符号及这五类的混合输入，是否会报错
输入全角、半角的英文、数字、特殊字符等，是否报错
输入空格、空格+数据、数据+空格，是否报错
人名输入框对小数民族名字的支持（中间点）
输入非数据表中规定的数据类型的字符，是否有友好提示信息
在文本框中输入回车键，显示时是否回车换行
非法的输入或操作应有足够的提示说明
软件测试小讲堂
101
验证输入输出信息的一致性
输入框前面的文字提示是否正确
日期控件开始时间和结束时间的逻辑校验，开始时间必须小于等于结束时间
分页测试
当没有数据时，首页、上一页、下一页、尾页标签均不可点击，不可触发点击结果和效果
在首页时，“首页”“上一页”标签置灰；在尾页时，“下一页”“尾页”标签置灰；在中间页时，四个标签均可点击，且跳
转正确；
翻页后，列表中的数据仍按照指定的顺序进行了排序；
显示控制
各个页面的分页标签样式一致；
是否支持回车键的监听
分页的总页数及当前页数显示正确；
分页控制
软件测试小讲堂
102
各个分页标签是同一水平线上；
在分页处输入非数字的字符（英文、特殊字符等），输入 0 或超出总页数的数字，是否有友好提示信息；
能正确跳转到指定的页数；
搜索测试
搜索按钮功能是否实现；
输入网站中存在的信息，能否正确搜索出结果；
输入键盘中所有特殊字符，是否报错；特别关注：_？’.•\/--；特殊字符
系统是否支持键盘回车键、Tab 键；
搜索出的结果页面是否与其他页面风格一致；
在输入域输入空格，点击搜索系统是否报错；
本站内搜索输入域中不输入任何内容，是否搜索出的是全部信息或者给予提示信息；
精确查询还是模糊查询，如果是模糊查询输入：中%国。查询结果是不是都包含中国两个字的信息；
焦点放置搜索框中，搜索框内容是否被清空；
软件测试小讲堂
103
搜索输入域是否实现回车键监听事件。
交互性数据测试
前台的数据操作是否对后台产生相应正确的影响（如：查看详细信息时，需扣除用户相应的授权点数）；
可实现前后台数据的交互（如：在线咨询，能否实现数据的交互实时更新）；数据传递是否正确；前后台大数据量
信息传递数据是否丢失（如 500 个字符）；多用户交流时用户信息控制是否严谨；
用户的权限，是否随着授权而变化；
数据未审核时，前台应不显示；审核通过后，前台应可显示该条数据；
小并发连点测试
提交按钮
连续点击只能生成一次记录
后台接口校验
前端增加防连点，但同时需考虑用户体验
注册按钮
软件测试小讲堂
104
同一账号只能注册成功一条数据
后台校验后进行接口拦截
前端增加防连点操作
7.10.2. 用户界面体验测试
图形测试
要确保图形有明确的用途，图片不堆在一起，可以正常显示，不会出现裂图
验证所有页面字体的风格是否一致.
背景颜色与字体颜色和背景色相搭配.
图片的大小和质量，清晰，容量越小越好.
各类型的图片、视频可以上传，下载，播放，展示
界面体验测试
界面图标
风格一致
软件测试小讲堂
105
背景（颜色，图片）一致。
操作习惯一致
各个界面布局是否合理：控件，文字，线条位置，数量，颜色是否合理，跟整体风格是否搭配。
界面文字是否有错别字。各界面文字大小，颜色，位置是否一致。比如：标题文字
图片
清晰度展示
不可出现模糊效果
大小展示符合设计
注意边距
各个界面同种图标是否一致
各种提示框风格是否一致。
提示语是否友好，简明。
列表型界面是否有上上滑动效果。
软件测试小讲堂
106
功能入口明显，易找（布局突出主要功能，用户要找到某个功能很快就能功能，操作简单）。
UI 界面测试要点
标题栏
检查标题栏文字描述的正确性。
比较各个界面的标题栏效果是否一致。
文字
文字是否有错别字。
检查文字描述正确性。（跟软件功能相符）
文字的颜色，大小，位置符合 UI 设计效果
文字用语一致。功能相同的地方，检查使用的文字是否符合产品原型
控件
控件对齐了没有。
并排关系控件－－左右对齐
软件测试小讲堂
107
同行关系控件－－横向对齐
控件状态：选中，未选中，可用，不可用
日期控件
设置完成后提交数据
查看接口输入输出数据是否保持一致
页面布局检查
字体、颜色、风格是否符合设计标准；
页面的排版、格式是否美观一致，是否符合一般操作习惯；
不同的浏览器中，显示效果是否符合设计要求。（需要在需求文档、测试用例文档 中，明确支持哪些浏览器。如：
某些用户只需支持 IE7,IE8，有些用户需支持 IE6-IE8 及 FIREFOX）；
不同分辨率下，显示效果是否符合设计要求。（如果项目中有分辨率的要求）； 页面在窗口变化时显示是否正确、
美观（在调整浏览器窗口大小时，屏幕刷新是否 正确）；
页面特殊效果显示是否正确，各个页面的链接情况是否准确，页面元素是否存在容 错性。
软件测试小讲堂
108
7.10.3. WEB 兼容性测试
操作系统/平台兼容性测试
常见的操作系统有 Windows,Unix,Linux 等。
最常用的是 Windows 操作系统。
在确保主流操作系统版本兼容性测试通过的前提下，再对非主流操作系统版本进行测试，尽量保证项目的操作系统
的兼容性测试的
不同浏览器之间的兼容性测试
常用的浏览器有谷歌、火狐、IE、360 浏览器等，
这些浏览器同样存在各个版本。在确保主流浏览器的兼容性测试通过的前提下，在对非主流浏览器（含版本）进行
测试
尽量保证项目的浏览器的兼容性测试的完整性。
分辨率兼容性测试
对于需求规格说明书中规定的分辨率，测试必须保证测试通过
软件测试小讲堂
109
于需求规格说明书中没有规定分辨率的项目，测试应该在完成主流分辨率的兼容性测试的前提下，尽可能进行一些
非主流分辨率的兼容性测试，在一定程度上保证大部分的分辨率显示正常
网络兼容性测试
断网
提交按钮和各类功能按钮保持数据静止
增加必要的提示
断网下的数据修改
网络恢复后提交
应保证数据为最后修改的数据
弱网
增加接口超时回馈
数据保持原子性
提交数据保持整体有效
软件测试小讲堂
110
防止出现重复提交
7.10.4. 安全测试
用户权限测试
用户权限控制
用户权限控制主要是对一些有权限控制的功能进行验证
用户 A 才能进行的操作，B 是否能够进行操作（可通过窜 session，将在下面介绍）
只能有 A 条件的用户才能查看的页面，是否 B 能够查看
直接敲 URL 访问时是否被拦截
页面权限控制
必须有登陆权限的页面，是否能够在不登陆情况下进行访问
必须经过 A——B——C 的页面，是否能够直接由 A——C？
URL 安全测试
URL 参数检查
软件测试小讲堂
111
对 URL 中参数信息检查是否正确
如：URL 中的订单号、金额允许显示出来的话，需要验证其是否正确
对于一些重要的参数信息，不应该在 URL 中显示出来
如：用户登陆时登录名、密码是否被明文显示出来了 ，
Session 测试
Session 互窜
用户 A 的操作被用户 B 执行了。
验证 Session 互窜，其原理还是基于权限控制，如某笔订单只能是 A 进行操作，或者只能是 A 才能看到的页面，
但是 B 的 session 窜进来却能够获得 A 的订单详情等。
Session 互窜测试方法：
多 TAB 浏览器，在两个 TAB 页中都保留的是用户 A 的 session 记录，然后在其中一个 TAB 页执行退出操作，登陆
用户 B，此时两个 TAB 页都是 B 的 session，然后在另一个 A 的页面执行操作，查看是否能成功。预期结果：有
权限控制的操作，B 不能执行 A 页面的操作，应该报错，没有权限控制的操作，B 执行了 A 页面操作后，数据记
录是 B 的而不是 A 的
软件测试小讲堂
112
Session 超时
基于 Session 原理，需要验证系统 session 是否有超时机制，还需要验证 session 超时后功能是否还能继续走下去
测试方法：
打开一个页面，等着 10 分钟 session 超时时间到了，然后对页面进行操作，查看效果。
多 TAB 浏览器，在两个 TAB 页中都保留的是用户 A 的 session 记录，然后在其中一个 TAB 页执行退出操作，马
上在另外一个页面进行要验证的操作，查看是能继续到下一步还是到登录页面。
接口安全检查
证书对接
数据泄漏
7.10.5. 接口测试
模块接口测试
它主要测试模块的调用与返回
检查接口返回的数据是否与预期结果一致。
软件测试小讲堂
113
检查接口的容错性，假如传递数据的类型错误时是否可以处理。例如支持整数，传递的是小数或字符串
接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
接口的性能，接口处理数据的时间也是测试的一个方法。牵扯到内部就是算法与代码的优化。
接口的安全性，如果是外部接口的话，这点尤为重要。
web 接口测试
服务器接口测试
是测试浏览器与服务器的接口
外部接口测试
第三方登录
请求是否正确，默认请求成功是 200，如果请求错误也能返回 404、500 等。
检查返回数据的正确性与格式；json 是一种非常创建的格式。
接口的安全性
鉴权
软件测试小讲堂
114
认证
第三方调用
解密
接口性能
返回时延
上传超时
7.11. 移动端测试
7.11.1. 兼容测试
机型兼容性
系统兼容
android
大版本升级
IOS
软件测试小讲堂
115
大版本升级
HarmonyOS
其他系统
分辨率兼容
高分辨率
低分辨率
屏幕兼容
刘海屏
水滴屏
开孔屏
全面屏
非常规宽高比屏
新旧数据兼容性
软件测试小讲堂
116
接口传参新旧版本兼容
新口返回的新旧版本兼容
网络兼容性
弱网
接口重加载
断网
友好页面提示
续网自动重连
有网无数据
网络切换
wifi 切换到移动数据
有数据提示
移动数据切换到 wifi 数据
软件测试小讲堂
117
无数据提示
有网切换到无网
缓存
停止加载
友好页面提示
无网切换到有网
恢复正常
图形兼容
不同格式的图片显示
不同格式的视频播放
加载时长控制在允许范围内
人机接口测试
返回键保持可用
软件测试小讲堂
118
不可屏蔽设备物理按键功能
7.11.2. 性能测试
CPU
查看 CPU 占用率
使用命令 adb shell top -m 10 -s cpu（-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m
显示最大数量）
通过 proc 获取 CPU 信息
adb shell cat /proc/stat | grep cpu > totalcpu0
Android Studio 自带 CPU 检测功能
内存
adb shell dumpsys meminfo 或 adb shell dumpsys meminfo
Android Studio 中对应进程的 Heap
内存泄露工具 LeakCanary
软件测试小讲堂
119
电量
电量的测试方法
adb shell dumpsys batterystats
初始化 batterystats 数据
adb shell dumpsys batterystats --reset
上面的操作执行完毕后，拔掉手机，操作你的 App，操作完成后，重新连接手机，执行下面的命令，收集 Battery
数据:
adb shell dumpsys batterystats > batterystats.txt
dumpsys batterystats
命令里面会输出各个应用的耗电情况，但该命令对手机的系统版本有要求，且应用内使用时需要有 root 权限。
流畅度测试
Android Studio 自带 GPU 测试功能
FPS Meter
软件测试小讲堂
120
系统自带功能，GPU 呈现模式分析
7.11.3. 数据安全测试
敏感信息加密
接口采用加密传输，不可被拦截，不可被抓取
身份证、手机号采用半覆盖展示
反编译
安装包具备加壳加固，不可被反编译，可使用反编译工具，解壳工具
APP 前端不可以出现代码类数据提示，以防数据泄漏
手动设置手机的时区和时间，检查接口校验
尤其是在一些活动中
按钮的 enable 属性与时间挂钩时，要注意使用服务器时间
7.11.4. push 测试
开关机
软件测试小讲堂
121
关机情况下推送，开机后可以收到
APP 活动或进程死亡
杀死 APP 且禁止后台运行，启动 APP 后可以收到
网络断开及接续
网络断开情况下推送，恢复网络后可以收到
通知权限
开启后可以收到 push 推送
关闭后，按系统行为收到或不通知
7.11.5. 权限测试
存储权限
开
关
网络权限
软件测试小讲堂
122
是否允许网络
是否允许移动网络
移动网络时，对于大流量数据交换是否有相应的提示
定位权限
默认地图中展示位置正确
关闭定位权限
仅一次使用
在 APP 内使用
始终允许使用
先允许后关闭
关闭定位后的缓存位置使用
通信权限
涉及到的隐私协议相关说明
软件测试小讲堂
123
不同意时不影响 APP 功能的正常使用
同意时需要拿到相应的手机信息
录音权限
不同意
不能启动相应的录音功能
不能展示录音权限开启时才能展示的页面
同意
录音功能正常使用
个别机型需要注意状态栏里的录音提示图标
相机权限
关
正确提示用户无法使用相机
个别机型读取相册功能
软件测试小讲堂
124
开
照片、录像的清晰度
可以使用相册
通讯录权限
默认为关
关闭
不能读取通讯录
开启
通读录可读
剪切板权限
7.11.6. 传感器测试
光敏感应器
软件测试小讲堂
125
通常用于调节屏幕自动背光的亮度，白天提高屏幕亮度，夜晚降低屏幕亮度，使得屏幕看得更清楚，并且不刺眼。
也可用于拍照时自动白平衡。还可以配合下面的距离传感器检测手机是否在口袋里防止误触。
视频亮度的自动调整
直播亮度的自动计整
AI 识别时的智能增强
距离传感器
检测手机是否贴在耳朵上正在打电话，以便自动熄灭屏幕达到省电的目的。也可用于皮套、口袋模式下自动实现解
锁与锁屏动作
视频播放类的距离检测的自动暂停与播放
AI 识别类的体位校正提示（一般通过语音提示）
陀螺仪
体感、摇一摇（晃动手机实现一些功能）、平移/转动/移动手机可在游戏中控制视角、VR 虚拟现实、在 GPS 没有信
号时（如隧道中）根据物体运动状态实现惯性导航
重力感应器
软件测试小讲堂
126
手机横竖屏智能切换、拍照照片朝向、重力感应类游戏
全屏半屏的自动切换
磁场传感器
指南针、地图导航方向、金属探测器 APP
加速度传感器
计步、手机摆放位置朝向角度
GPS
地图、导航、测速、测距
指纹传感器
加密、解锁、支付
霍尔感应器
翻盖自动解锁、合盖自动锁屏
气压传感器
软件测试小讲堂
127
GPS 计算海拔会有十米左右的误差，气压传感器主要用于修正海拔误差（将至 1 米左右），当然也能用来辅助 GPS
定位立交桥或楼层位置
心率传感器
运动、健康
血氧传感器
运动、健康
紫外线传感器
运动、健康
7.11.7. 交互测试
人机操作交互（系统级交互）
APP 切换到后台，再回到 app，检查是否停留在上一次操作界面。
APP 切换到后台，再回到 app，检查功能及应用状态是否正常、
软件测试小讲堂
128
App 切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自
动更新的时候。
手机锁屏解屏后进入 app 注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时
候。
当 App 使用过程中有电话进来中断后再切换到 app，功能状态是否正常
当杀掉 App 进程后，再开启 App，App 能否正常启动。
出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框
的缺陷。
对于有数据交换的页面，进行前后台切换、锁屏的测试，
视频、音频播放中音频交互
外放类
来电铃声（包含来电，视频软件来电等）的交互
闹铃（包含手机闹钟，日程提醒等）
免提通话（包含语音通话，视频通话，视频软件通话）
软件测试小讲堂
129
消息通知类提醒（短信，邮件，消息等）
各类提示音（触摸，截屏，锁屏，拨号等）
视频类软件播放视频（当前软件后台）
语音类
通话（包含语音通话，视频通话，视频软件通话）
蓝牙通话，耳机通话
优先级（产品必须明确需求）
通话：语音通话和视频通话（手机自身而不是第三方软件）
铃声：来电铃声，通知提醒
通话类软件如微信，QQ 等
流媒体之类
交互方式
多语音同时在前端触发
软件测试小讲堂
130
按语音优先级进行覆盖或中断
后到先播序列
暂停，打断，灭屏，亮屏
7.11.8. 内容测试
输入框说明文字的内容与系统功能是否一致
是否有错别字
是否有敏感性词汇、关键词
是否有敏感性图片，如：涉及版权、专利、隐私等图片
内容检查，不能用反党，反国、台独、第一、最好等敏感词汇
后台服务器异常时，APP 前端应该给予正确的提示和引导，不要出现代码类词汇，更不能出现泄密性内容
覆盖安装后的帐号不能掉线
确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试
7.11.9. APP 更新测试
软件测试小讲堂
131
非强制升级
可跳过
退出后每次进入都会提示
本次浏览过程中不再提示
强制升级
不可跳过
退出后每个进入都会提示
覆盖升级
登录状态不发生改变
已保存数据不会丢失
7.11.10. 流媒体测试
业务测试
测试对流媒体点播，终端提供播放、暂停、继续、停止、退出操作
软件测试小讲堂
132
测试对流媒体点播，终端提供定位播放（即快进、后退）操作
测试对流媒体点播，终端提供音量控制和静音操作操作
测试对流媒体直播，终端提供播放、停止、退出、音量控制和静音操作
测试对于视频下载，终端提供本地回放功能（包括：播放、暂停、继续、停止、退出、定位播放、音量控制和静音
操作。
测试对于流媒体播放过程中，若当前速率不能满足流媒体播放时，终端应自动暂停播放并对流媒体内容进行缓存，
在收到足够信息后继续播放
测试流媒体播放结束后，终端不能保存流媒体文件的部分或者全部的内容，并且播放器的缓存不可以被访问，视频
下载的文件可以保存在终端
测试如果终端支持所选媒体格式，终端应给出相应的提示，有用户选择是否继续播放其中可支持部分
测试在流媒体直播、点播和视频下载过程中，如果突然出现关机情况，是否正常响应
测试在流媒体直播、点播和视频下载过程中，如果应用程序出现异常，是否正常响应
测试在流媒体直播、点播和视频下载过程中，如果浏览器出现异常，是否正常响应
测试在流媒体直播、点播和视频下载过程中，如果网络出现异常，是否正常响应
软件测试小讲堂
133
测试在流媒体终端收到视频图像的尺寸如果大于播放器屏幕尺寸时，播放器是否正常响应
测试在流媒体终端收到视频图像的尺寸如果大于播放器屏幕尺寸时，播放器是否正常响应
流媒体窗口全屏和正常之间的切换是否能够实现
测试上传文件最大值
测试上传文件是否支持中文名称
测试删除上传成功的文件
测试文件名称的最大值、最小值
测试文件名称是否支持特殊字符(包括空格)
测试上传过程断网，等网络恢复后，是否支持断点续传
测试上传时网速很慢，上传中传测试
测试上传文件支持的格式
测试增加部分功能后系统运行是否正常
测试删除部分功能后系统运行是否正常
软件测试小讲堂
134
测试缺陷修改后系统运行是否正常
流媒体的播放窗口是否可以单独从浏览器窗口中拖拽出来
内存不足时，是否有相应的内存不足的提示
当前浏览器最小化后，是否停止流媒体的下载过程以节约网络资源
在流媒体的播放定位过程中，是否能够出现一个小的视频窗口，以便用户确认定位位置
流媒体播放过程中是否有记忆功能，以便中断恢复或下次打开后，从上次浏览处继续查看
性能测试
码率
指数据传输时单位时间传送的数据位数，单位为 kbps。码率的大小决定视频文件的清晰度、流畅度和大小。码率
越高，画质越好，文件也越大
帧率
帧率用于测量显示帧数的量度，单位为每秒显示帧数（FPS）。高的帧率可以得到更流畅、更逼真的动画。FPS 越
多，显示的动作就会越流畅。一般来说 60FPS 可以明显提升动画的交互感和逼真感，超过 75FPS 流畅度则不会有
明显的提升
软件测试小讲堂
135
丢包率
丢包是网络中数据传输的时候出现数据丢失的现象，丢包率是指丢包数据占总传输数据的百分比。网络丢包率越
高，网速越慢，一般丢包率小于 1%属于正常
平均下载速度
指播放器播放视频过程中下载视频资源的速度。平均下载速度=总下载字节数/吞吐用时。建议值：优秀 >180
KB/s，一般 >70 KB/s，差 ≤ 70KB/s
视频首包用时
从获取视频真实地址到获取视频资源第一包之间的时间间隔。建议值：优秀 ≤1s，一般 ≤2.5s，差 >2.5s
视频首帧用时
从获取视频真实地址到开始播放视频第一帧之间的时间间隔。其中视频秒开指的是视频页面首屏在 1s 左右快速的
展现出来，视频秒开直接影响着用户体验
页面首屏用时
从开始浏览到页面被渲染出指定高度范围之间的时间间隔。参考值：优秀 ≤3.5s，一般 ≤7s，差 >7s。
卡顿时间
软件测试小讲堂
136
指视频在开始播放后出现的卡顿（缓冲）状态的累计时长（首次缓冲不计算在内）卡顿时间=总缓冲用时-首次缓冲
用时。参考值：优秀 ≤ 6s，一般 ≤12s，差 >12s
St-load
7.11.11. 帐号切换测试
注册
密码需要以密文展示
重复注册需要给出明确提示
验证码发送次数限制
验证码有效期限制
验证码输入次数限制
验证码输入正确与否判断
验证码验证后失效性
登录
软件测试小讲堂
137
是否有次数限制
使用已经登陆的账号登陆系统是否正确处理
单点登录
使用禁用的账号登陆系统是否正确处理
有效登录
一键登录
人脸识别登录
7.11.12. 按钮连点（小并发）专项
提交订单按钮的连续点击
允许重复订单
库存足够时
不允许重复订单
库存不足时
软件测试小讲堂
138
支付按钮的连续点击
同一订单不允许重复支付
重复支付后的订单处理
注册按钮的连续点击
是否有正确的拦截方式
后台对于重复注册有正确校验
关注类按钮的连续点击
是否同时生成两条关注记录
后台的正确处理
前端防连点
有上限条件的提交按钮
人数上限
达到人数时的提交逻辑处理
软件测试小讲堂
139
库存上限
多余订单的处理
8. 技巧
8.1. 沟通技巧
8.1.1. 技术沟通
平等待人，以理服人
8.1.2. 产品沟通
可以提意见，不要做决定
8.1.3. 会议沟通
言简意赅，总结领悟
8.1.4. 向上汇报
事情，原因，解决
8.1.5. 向下沟通
软件测试小讲堂
140
以理服人，以德服人，以权压人
8.2. 控制技巧
8.2.1. 控制测试是为了验证控制是否按照设计要求被一贯和有效执行的一种测试程序
8.2.2. 测试集中在关键控制上
8.2.3. 询问
即通过口头或书面形式确认控制存在，并且应该询问多人以确定结果一致
8.2.4. 观察
即观察员工执行控制步骤，该方法可能需要其他跟进测试，并且需要结合突袭检查，在员工无准备的情况下获得控制
活动执行的真实记录
8.2.5. 检查
这种方法是获得资产存在证据的最简单的方法，主要是通过审阅相关文档记录或报告来对控制活动执行情况进行判
断，需要注意的是，在这种方法中需要员工提供详细内容从而可以重复测试步骤并检验结果
8.2.6. 重新执行
软件测试小讲堂
141
如采用独立的数据重新进行对账，按系统的计算公式重新计算，在系统中输入测试数据来查看结果等
8.3. 偷懒技巧
8.3.1. 学会使用一切可以为测试服务的工具
8.3.2. 学会利用一些集合简单命令的脚本，并不一定需要什么编程基础
8.3.3. 学会提取公因式-不仅仅指操作，更是一种测试意识
9. 标准
9.1. 缺陷关闭标准
9.1.1. 正常缺陷的生命周期
创建
解决
回归
关闭或激活
9.1.2. 需要评审类的缺陷的生命
软件测试小讲堂
142
提交无法正常关闭的理由
提交评审会议
三态
关闭
待定
迭代
9.2. 用户体验标准
9.2.1. 功能测试
定义
根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求
功能测试只是由 QA 验证是否满足功能的设计要求，是否能完成当初的功能设计，满足功能即可
倾向于站在开发的角度
9.2.2. 用户体验测试
软件测试小讲堂
143
ISO 定义
用户在使用一个产品或系统之前、使用期间和使用之后的全部感受，包括情感、信仰、喜好、认知印象、生理和心
理反应、行为和成就等各个方面。该说明还列出三个影响用户体验的因素：系统，用户和使用环境
测试人员在将产品交付客户之前处于用户角度进行的一系列体验使用，如：界面是否友好（吸引用户眼球，给其眼前
一亮）、操作是否流畅、功能是否达到用户使用要求等
用户体验涵盖的面更广，良好的用研不仅仅只是满足用户提出的功能，而且还要设法满足用户的潜在需求，达到良好
的生理（视觉，操作）以及心理体验（易用性，可感知，可学习，可记忆性等等），同时也要兼顾效率以及开发成
本，是一个比较全面性的指标系统
倾向于站在用户的角度
满足用户需求，超出用户期望
测试过程（中间可能随需求和开发的不断修改）会花费部分成本，用户体验测试也不例外（用户体验环境从时间耗时
和资源上都能体现）。考虑实际收益，用户体验测试的设计需要慎之又慎，他需要对测试的目的、介入时间、测试的
周期、场景、人员的选型都要做出深入的分析和界定
用户体验测试介入时间一定要尽可能的早，试想如果在系统快要发布前才进行该项测试，非常可能因为在用户体验测
试时发现页面结构不合用户操作习惯，或有些功能对于用户而言需要强化，或操作步骤过繁，在不推迟发布时间的情
况下，此时对代码进行修改和优化，谁都知道这样的行为无疑是危险的。因此，较为合理的做法是当页面的 demo 定
软件测试小讲堂
144
稿时我们就需进行用户体验测试，不过由于此时的测试是静态的，所以还不足以确保用户实际的操作感受，我们还需
要在系统提交功能测试后，当功能测试人员验证主流程已能正常流转，用户体验测试就能再次介入进来，此时的用户
体验测试不必像功能测试那样关注细节的实现，更重要的是收集用户的操作习惯和使用感受。
9.2.3. 本质上用户体验差和缺陷等级较低的 bug 没有什么区别。
9.3. 性能测试标准
9.3.1. 前端性能
系统启动时长
流畅度检测（FPS）
流量测试分析
用户等待时长
系统能耗
电池
发热
软件测试小讲堂
145
设备兼容
分辨率
系统操作
9.3.2. 接口性能
用户等待时长
网络切换
弱网
断网
wifi 和数据切换
9.3.3. 服务器性能
TPS
QPS
error
软件测试小讲堂
146
HPS
CPU
内存
网关
负载均衡
容量
限流
扩容
9.4. 风险评估标准
9.4.1. 生死线
9.4.2. 风险预判
9.4.3. 漏洞
9.5. 成本管理标准
软件测试小讲堂
147
9.5.1. 业务逻辑是否存在不合理的费用支出
9.5.2. 业务逻辑是否存在可以节省的费用支出
9.5.3. 测试阶段需要花费的财力
10. 过程
10.1. 测试计划和控制
10.1.1. 识别测试任务、定义测试目标以及为了实现测试目标和任务确定必要的测试活动
10.1.2. 测试控制是持续进行的活动：通过对测试实际进度和测试计划之间的比较，报告测试的状态，包括与计划之间存
在的偏差。测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。需要在项目的整个生命周期中对测试
活动进行监督，以达到控制测试过程的目的
10.1.3. 测试计划的制定也需要考虑测试监控活动的反馈信息
10.2. 测试分析和设计
10.2.1. 将概括的测试目标转化为具体的测试条件和测试用例的一系列活动
10.2.2. 评审测试依据(比如需求、软件完整性级别(风险等级)、风险分析报告、系统架构、设计和接口说明)
软件测试小讲堂
148
10.2.3. 评估测试依据和测试对象的可测性
10.2.4. 通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定其优先级
10.2.5. 设计测试用例并确定优先级
10.2.6. 确定测试条件和测试用例所需要的测试数据
10.2.7. 规划测试环境的搭建和确定测试需要的基础设施和工具
10.2.8. 创建测试依据和测试用例间的双向可追溯性
10.2.9. 软件完整性级别：为了向软件利益相关者反映软件重要性所定义的软件遵守的或必须遵守的一系列利益相关者选
定的软件和/或软件系统特性的级别。(例如，软件复杂度、风险评估、产品安全性级别、产品防止对程序和数据未授权
访问的能力级别、预期性能、可靠性、成本)
10.3. 测试实现和执行
10.3.1. 测试实现和执行阶段的主要活动包括：通过特定的顺序组织测试用例来完成测试规程和脚本的设计，并且包括测
试执行所需的其他任何信息，以及测试环境的搭建和运行测试。
10.3.2. 测试实现和执行阶段的主要任务：
10.3.3. 测试用例的开发、实现并确定它们的优先级。(包括识别测试数据);
软件测试小讲堂
149
10.3.4. 开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本;
10.3.5. 根据测试规程创建测试套件，以提高测试执行的效率;
10.3.6. 确认已经正确搭建了测试环境;
10.3.7. 确认并更新测试依据和测试用例间的双向可追溯性;
10.3.8. 根据计划的执行顺序，通过手工或使用测试执行工具来执行测试规程;
10.3.9. 记录测试执行的结果，以及被测软件、测试工具和测试件的标识和版本;
10.3.10. 将实际结果和预期结果进行比较;
10.3.11. 对实际结果和预期结果之间的差异，作为事件上报，并且进行分析以确定引起差异的原因(例如：代码缺陷、具
体测试数据缺陷、测试文档缺陷、或测试执行的方法有误等);
10.3.12. 缺陷修正后，重新进行测试活动。比如通过再次执行上次执行失败的用例来确认缺陷是否已经被修正(确认测
试)。执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有对软件未修改的部分造成不良影响或对于缺陷的
修正没有引发其他的缺陷(回归测试)。
10.4. 评估出口准则和报告
软件测试小讲堂
150
10.4.1. 评估出口准则是将测试的执行结果和已经定义的测试目标进行比较的活动。这个活动在各个测试级别上都需要进
行。
10.4.2. 评估测试出口准则的主要任务：
10.4.3. 按照测试计划中定义的测试出口准则检查测试日志;
10.4.4. 评估是否需要进行更多的测试，或是否需要更改测试的出口准则;
10.4.5. 为利益相关者提供一个测试总结报告。
10.5. 测试结束活动
10.5.1. 测试结束活动就是从已完成的测试活动中收集和整合有用的数据，这些数据可以是测试经验、测试件、影响测试
的因素和其他数据。在以下几种情况下需要执行测试结束活动，例如：当软件系统正式发布、当一个测试项目完成(或取
消)、当达到一个里程碑或当一个维护版本完成时。
10.5.2. 检查提交了哪些计划的可交付产品;
10.5.3. 事件报告是否关闭、或对未关闭的事件报告提交变更需求;
10.5.4. 记录系统的验收;
10.5.5. 记录和归档测试件、测试环境和测试基础设备，以便以后的重复使用;
软件测试小讲堂
151
10.5.6. 移交测试件到维护部门;
10.5.7. 分析和记录所获得的经验教训，用于以后的项目和测试成熟度改进;
10.5.8. 使用为测试成熟度的提高所收集的信息