1 软件测试基本概念
1.1 测试对象
（1） 软件包括程序代码
（2） 相关数据
（3） 相关文档
1.2 测试目的
（1） 评价一个程序或系统属性为目标的一种活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择与接受软件提供有力的依据
（2） 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
1.3 测试生命周期
（1） 测试计划阶段：确定测试范围、测试目标、资源、进度、风险、策略，产出测试计划文档
（2） 测试需求分析/测试设计阶段：分析用户需求、软件需求，写测试用例，测试规格说明。
（3） 测试执行阶段：搭建测试环境，执行测试用例，发现bug提交bug跟踪缺陷。
（4） 缺陷跟踪与管理阶段：提交bug，开发修复，回归测试。
（5） 测试评估和总结阶段：分析测试覆盖率、缺陷密度、版本质量。输出测试总结报告、测试报告。
（6） 运维回归测试阶段：上线后维护、改bug、版本迭代，做回归测试。
1.4 软件测试原则（8个）
（1） 溯源性原则：测试应该溯源到原始需求，而不仅仅只盯着眼前。
（2） 工程性原则：测试不是某个阶段的活动，而是贯穿软件生产的各阶段，需要以工程化的思想和方法来组织和实施。须尽早按计划开展测试，甚至进行预防性测试，以避免测试延迟带来的巨大代价。
（3） 独立性原则：应当避免开发工程师测试自己的程序，自己测试自己的程序会受到定势思维和心理因素的影响，测试质量将大打折扣，企业应设立独立的测试工程师岗位或测试部门去承担测试工作。
（4） 合理性原则：对软件进行完全测试是不可能的，基于有限的时间和有限的资源，无法对软件开展穷举式的测试。
（5） 不完全性原则：不管强度有多大，测试都不能暴露全部的缺陷，这是由测试自身决定了的。测试能做的是尽可能多地发现错误，但不能证明软件不再包含错误，因此，任何人或者机构对软件测试后的评价只能描述为"未发现错误"，而不能描述为"没有错误"。
（6） 可接受性原则：测试的直接目标是发现软件缺陷，但更进一步的目标是修复发现的缺陷，然而修复缺陷是有代价的，因为时间或修复风险等方面的原因，已发现的缺陷不一定全部修复，在各方面可以接受的前提下，可以允许某些缺陷遗留在软件中，当然这并不表明不披露一发现的缺陷，应该交由恰当的人员或会议进行决策。
（7） 相关性原则：基于大量的测试统计和分析，人们发现一个软件（模块）中被找到的缺陷越多，则这个软件（模块）中残留的缺陷也越多，或者说缺陷常常有聚集现象。
（8） 风险性原则：测试虽然是为了降低或化解软件质量风险，但必须认识到测试本身也是有风险的。
1.5 测试设计人员
（1） 指定测试用例
（2） 确立测试点
1.6 软件质量保证与软件测试
软件质量保证：SQA，贯穿软件全生命周期，监督流程、规范标准、审计过程、预防问题，以预防为主，管过程。面向整个团队、流程规范。关心软件开发活动过程、步骤和产物。
软件测试：对软件产品进行验证，发现已经存在的Bug、验证是否符合需求，事后发现，管产品。面向软件代码、功能、产品。关注过程的产物和开发出的软件。
1.7 软件测试的分类
（1） 施组织分类：开发方测试、用户方测试、第三方测试。
（2） 按阶段分类：单元测试、集成测试、系统测试、确认测试、验收测试。
（3） 按测试方法分类：静态测试和动态测试。
（4） 按测试技术划分：黑盒测试、白盒测试和灰盒测试。
（5） 按软件质量划分：功能性测试、性能效率测试、兼容性测试、易用性测试、可靠性测试、信息安全性测试、维护性测试、可移植性测试。
（6） 按测试工具重点对于的测试阶段分类：单元自动化测试工具、集成自动化工具、系统自动化测试工具
（7） 按测试对象所在操作系统平台分类：Web应用测试、安卓移动测试、IOS移动应用测试、Linux桌面应用测试、Windows桌面应用测试。
2 测试用例
2.1 测试用例三要素
（1） 输入
（2） 预期输出
（3） 执行条件
2.2 功能测试用例概念
业务流程测试用例：包括通过测试用例和失败测试用例。
功能测试用例：一般包括业务流程测试用例和功能点测试用例。
通过测试用例：验证需求是否能够正确实现，打通流程的一类测试。
失败测试用例：模拟一些异常业务操作，测试系统是否具备容错性。
3 测试覆盖度
测试覆盖度：测试用例覆盖测试需求的程度，可能存在一个用例可覆盖多个测试需求；一个需求对应多个测试用例的情况。
4 白盒与黑盒测试
黑盒测试：不看代码，只测功能。
白盒测试：看代码逻辑、分支、路径。
灰盒测试：既看接口又看功能（接口测试常使用）。
4.1 黑盒测试
黑盒测试用例设计：
（1） 等价划分法：把相同情况的分成一类，只测代表数据。
（2） 边界值分析法：最小值、最大值、中间值、略大最大值、略小最小值。（可以用于白盒也可以用于黑盒）任何情况下都必须使用该方法，因为发现错误能力最强。
（3） 场景法：模拟用户真是业务流程。场景法=基本流+备用流。可以贯穿整个测试案例过程。
（4） 错误推断法：按照经验、常识猜测bug出现位置补充用例。
（5） 判定表：多个条件组合，列出所有可能性。n个条件可以最多得到2^n个规则判定表。
（6） 因果图法：原因->结果的逻辑图，转化为判定表。根据输入输出的依赖关系设计测试用例，如果程序功能说明含有输入条件组合，一开始就要使用因果图法。
（7） 正交试验法：根据正交原理，从大量实验数据中挑选适量的，有代表性的点，合理地安排测试的一种科学实验设计方法，是研究多因素多水平的一种设计方法。就是造好了正交表来安排试验并进行数据分析的一种方法。
（8） 状态转移测试：测系统状态来回切换（锁定/未登录/已登录/异常态），适合有明显状态机的系统。
（9） 分类树法：将输入域划分为若干个独立的分类，每个分类再根据一定的准则再次划分类和子类，知道将整个输入域分割成一些不可再分的子类的组合为止。每次划分都会生成若干个独立而不重叠的类或子类，同时还保证分类集的完整性，即所有输入域都被识别且被包括在了某个分类中。这个划分过程可以用一个树状图进行表示，将分类、类、子类之间的层次关系塑造成一棵树，输入域作为树的根节点，分类作为分支节点，类或者子类作为叶子节点。可以将无限测试变为有限测试。
（10） 决策表：通过条件桩、条件项、动作桩、动作项组成。
因果图导出测试用例的步骤：
（1） 分析程序规格说明的描述中：原因和结果
（2） 分析程序规格说明描述中寓意的内容，并将其表示成连接各个原因和各个结果的"因果图"
（3） 标明约束条件
（4） 把因果图转化为判定表
（5） 为判定表中每一列表示的情况设计测试用例。
等价划分类的六条划分原则：
（1） 在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。
（2） 在输入条件规定了输入值的集合或者规定了"必须如何"的条件情况下，可以确立一个有效等价类和一个无效等价类。
（3） 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
（4） 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
（5） 在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
（6） 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类。
4.2 白盒测试
白盒测试用例设计 ：语句 < 判定 < 条件 < 判定条件 < 路径
（1） 语句覆盖SC（最弱）：每一行代码至少执行一次。
（2） 判定覆盖DC（分支覆盖）：每个判断，真假都要至少走一次。
（3） 条件覆盖CC：每个子条件都取真、取假。满足条件覆盖，不一定满足判定覆盖。
（4） 条件判定覆盖CDC：每个判断真假和子条件真假都覆盖。
（5） 修正条件判定覆盖MCDC ：分支条件覆盖，每个条件都能单独取真取假，每个条件都可以独立改变整个判定的结果。对于包含n个布尔条件的代码，只需要n+1个测试用例就可以实现100%覆盖。
（6） 条件组合覆盖MCC ：所有条件真假的组合排列全部覆盖。也叫分支条件组合测试。对于n个条件的程序，满足条件判定组合测试100%覆盖的用例数是2^n个。
（7） 路径覆盖（最强）：覆盖程序中所有可能执行的路径。
4.3 基于规格说明的测试
基于规格说明的测试：完全只看需求规格说明、业务说明书、需求文档，不看代码内部，只看功能规格设计用例，从需求/规格出发的黑盒测试。
测试方法：
（1） 等价类划分法
（2） 边界值分析法
（3） 因果图法/判定表法
（4） 分类树法
（5） 场景法（业务流程测试）
4.4 5种组合强度（黑盒测试）
组合强度：常见的组合强度包含单一选择、基本选择、成对选择、全组合和K强度组合等。
（1） 单一选择：只测每个参数单独自己，不做任何搭配。
（2） 基本选择：基准值打底，每次只变一个参数。
（3） 成对选择（两两组合）：任意两个参数所有取值互相搭配。
（4） K强度组合：在组合强度要求为K的组合中，任意K个参数取值范围的任意有效值的组合至少被一个测试用例覆盖。
- 当K=1，K强度组合就是单一选择。
- 当K=2，K强度组合就等同于成对组合。
- 当K等于所有参数数量时，K强度组合等同于全组合。
（5） 全组合：所有参数全部取值穷举，黑盒下的MCC条件组合覆盖。
5 单元测试、集成测试、系统测试、确认测试、验收测试
5.1 单元测试主要内容
（1） 模块接口测试
（2） 局部数据结构测试
（3） 路径测试
（4） 错误处理测试
（5） 边界测试
5.2 集成测试
主要内容：
（1） 把各个模块连接起来的时候，穿越模块接口的数据是否会丢失
（2） 一个模块的功能是否会对另一个模块的功能产生不利影响
（3） 各个子功能组合起来，时候达到预期要求的功能
（4） 全局数据结构是否有问题
（5） 单个模块的误差累积起来是否会放大，从而达到不能接受的程度
依据：概要设计说明书
组装方式：
（1） 自顶向下的增殖方式：可以较早地验证主要的控制和判断点，底层输入输出、复杂算法模块最后才发现，导致过多的回归测试。使用桩模块。
（2） 自底向上的增殖方式：对于输入输出模块、复杂算法能比较早期验证。使用驱动模块。
（3） 一次性组装（大爆炸集成）：所有模块开发完，一次性组装起来再测试。
（4） 三明治集成（混合集成）：自顶向下+自底向上同时进行，兼顾两者优点，效率高、定位故障快，中大型项目最常用。
（5） 增量式集成：不是一次性拼完，一部分一部分逐步增加模块组装测试，自顶向下、自底向上和三明治都属于增量式。
5.3 系统测试
主要内容：对完整系统整体测试（黑盒），包括相关的软硬件平台、网络以及相关外设的测试（功能测试、性能测试、界面测试、兼容性测试、安全测试、易用性测试、接口测试、文档测试、安装卸载测试、异常容错测试），验证系统是否符合需求。
依据：需求设计说明书、用户手册、规格说明。
5.4 确认测试
主要内容：验证软件的功能性能及其其他性能是否与用户的要求一致，对软件的功能和性能要求在软件需求规格说明书中明确规定。一般包括有效性测试和软件配置复查。由开发人员主导，也可以委托第三方测试机构实施。
（1） 有效性测试：在模拟环境下，运用黑盒测试的方法，验证软件是否满足规格说明书列出的需求。
（2） 软件配置复查：软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
依据：需求说明书（纯软件的功能/性能需求）
5.5 验收测试
主要内容：决定是否接受或拒绝系统。
依据：项目任务书、合同、约定的验收依据文档
*注意：是用户双方共同确认，用户主导，需要己方测试小组成员，用户方人员。
6 性能测试
性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。主要包括疲劳性测试、大数据量测试、负载测试和压力测试等。
选择测试业务：
（1） 高吞吐率的业务
（2） 高商业风险的业务
（3） 高服务器负载类型的业务
目的：
（1） 获得系统的性能表现
（2） 发现并验证和修改系统影响性能的缺陷
（3） 为系统性能优化提供数据参考
需要准备的测试数据：
（1） 识别数据状态验证案例
（2） 初始数据提供了基线用来评估测试执行的结果
（3） 业务数据提供负载压力背景
（4） 脚本中参数数据真实模拟负载
性能测试三大核心：并发用户数、响应时间、资源利用率。
6.1 性能测试类型
（1） 基准测试：测试环境确认以后，对业务模型中涉及的每种业务做基准检测。
（2） 并发测试：并发不同数目的虚拟用户执行检查点操作。
（3） 压力测试：测试系统在事先规定的某种饱和状态下，系统是否还具备处理业务的能力，或者系统会发生什么样的情况，是否会出现错误或系统宕机等情况。
（4） 负载测试：在被测系统上不断增加负荷，直到事先选定的性能指标变为不可接受或系统的某类资源使用已经达到饱和状态。
（5） 稳定性测试：正常业务负载，被测系统在特定硬件、软件、网络环境条件下，给系统加载一定的压力，使系统运行一段比较长的时间，以此检测系统是否稳定。测试的是可靠不崩。
（6） 极限测试：在过量用户下的压力测试，目的是确定系统的极限并发用户数。
（7） 场景测试：通过对系统体系架构和功能模块的分析以及对系统用户的分布和使用频率分析，来构造系统综合场景的测试模型，模型不同用户执行不同操作，最大限度模拟系统真实场景，使用户预知系统投入使用后的真实性能水平，从而对系统做出相应的优化及调整，避免实际情况中出现系统长时间不响应及崩溃的情况。
（8） 疲劳性测试（耐久测试）：比日常压力稍高、持续高频反复请求。采用系统稳定运行的情况下能够支持的最大并发用户数，或日常运行用户数，持续执行一段时间业务，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程。
（9） 吞吐量测试：模拟系统真实的使用情境，每隔一定时间段并发不同数目的虚拟用户执行检查点操作，持续运行一段时间，计算每单位时间（秒、分、时、日）系统处理的能力（事务数/单位时间），目的是计算系统的吞吐能力。
（10） 大数据量测试：单用户、数据量极大，测海量数据下的性能和可用性。
（11） 综合数据量测试：和压力测试、负载测试、疲劳性测试相结合的综合性测试。
6.2 监控性能指标
（1） 服务器硬件监控
CPU：CPU使用率、CPU负载、中断次数、CPU温度、CPU功耗
内存：物理内存使用率、缓存大小、内存占用
磁盘/存储：磁盘使用率、磁盘读写IOPS、磁盘吞吐量、磁盘响应时间
网络：网络连接数、丢包率、重传率、网络延迟、端口监听状态、带宽情况
（2） 操作系统级监控
进程数、线程数、系统日志情况、系统时间同步状况。
（3） 中间件监控
JVM/虚拟机：堆内存使用率、GC频率、GC耗时、线程池活跃线程数
Web服务：每秒请求数、响应时间、并发连接数、错误率、请求队列长度
数据库：连接数、慢查询数量、查询QPS、锁等待、死锁次数、缓存命中率、事务耗时
缓存：命中率、内存淘汰、阻塞次数、连接数
（4） 容器/云原生监控
Pod重启次数、容器CPU/内存限制与使用率、容器磁盘IO、节点资源利用率、容器网络带宽、HPA扩缩容次数
（5） 业务性能监控
接口成功率、接口耗时分布、队列积压长度、消息消费堆积、超时率、并发用户数、业务错误码分布
7 静态测试
静态测试 ：不运行代码的情况下，通过一组质量准则或其他准则对测试项进行检查的测试。运行速度慢等性能问题没法检测，性能测试需要运行代码。
8 文档测试
文档测试：检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性。
8.1 测试文档的重要性
（1） 验证需求的正确性
（2） 检验测试资源
（3） 明确任务的风险
（4） 生成测试用例
（5） 评价测试结果
（6） 进行回归测试
（7） 决定测试的有效性
8.2 文档测试要点
（1） 仔细阅读，跟随每个步骤，检查每一个图形
（2） 检查文档的编号是否满足文档编写的目的
（3） 内容是否齐全、正确
（4） 内容是否完善
（5） 标记是否正确
8.3 编制评价规格说明
（1） 分析产品的描述
（2） 规定对产品及部件执行的测量
（3） 按照评价需求验证编制的规格说明
8.4 规格说明
形式化定义方式的规格说明 ：用数学符号、逻辑公式、严格语法、状态机、谓词逻辑、集合论，来写需求规格，没有任何歧义、严谨、精确、无模糊描述。适合语法测试。这种最适合状态转移测试、判定表、因果图，而自然语言才使用边界值、等价类方法。比如：输入合法年龄，写作数学约束
8.5 概要设计说明书的评测内容
（1） 可追溯性：分析该系统的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确认的软件需求，软件的每一成分是否可追溯到某一项需求。
（2） 接口：分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义，模块是否满足高内聚低耦合的要求，模块作用范围是否在其控制范围内。
（3） 风险：确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
（4） 实用性：确认该软件设计对于需求的解决方案是否实用。
（5） 技术清晰性：确认该软件设计是否以一种易于翻译成代码的形式表达。
（6） 可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
（7） 质量：确认该软件设计是否表现出良好的质量特性。
（8） 各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。
（9） 限制：评估对该软件的限制是否现实，是否与需求一致。
（10） 其他具体问题：对于文档、可测试性、设计过程等进行评估。
9 缺陷报告包含内容
（1） 缺陷编号
（2） 对应的用例编号
（3） 缺陷标题
（4） 编写时间
（5） 缺陷描述（版本号、运行环境、前置条件、缺陷重现步骤）
（6） 严重等级
（7） 优先级别
10 测试停止的依据
（1） 测试用例全部执行结束
（2） 测试覆盖率达到要求
（3） 测试超出了预定时间
（4） 查出了预定数目的故障
（5） 执行了预定的测试方案
11 分层架构软件测试
分层架构：把单个应用内部按照职责分成几层，从上到下调用。比如表示层、业务逻辑层、数据访问层。
特点：
（1） 是跑在同一进程、同一台服务器上；
（2） 模块之间是方法调用；
（3） 目的是解耦、好维护、结构清晰。
性能：数据需要层层传递，性能会下降。
12 Web系统测试
与其他软件系统测试基本相同，只是测试重点不同。
主要测试内容：
（1） 恢复测试：检测系统的容错能力。
（2） 安全性测试：检测系统的安全机制、保密措施是否完善，主要是为了检验系统的防范能力。
（3） 压力测试：也叫做强度测试，是对系统在异常情况下承受能力的测试，时间差系统在极限状态下运行时，性能下降的幅度是否在允许的范围内。
（4） 性能测试：检查系统是否满足系统设计方案说明书对性能的要求。
（5） 功能测试：可靠性测试，可用性测试和可维护性测试。
（6） 安装测试、客户端兼容性测试
（7） 可用性测试：测试对用户的友好性，主要取决于系统最终端或客户的主观意见。
12.1 测试分类
（1） 按架构：客户端的测试、服务器端的测试、网络上的测试
（2） 按职能：应用功能的测试、web应用服务的测试、安全系统的测试、数据库服务的测试
（3） 按质量特性：功能测试、性能测试、安全性测试、见绕行测试、易用性测试等
（4） 按开发阶段：设计的测试、编码的测试、系统的测试
12.2 表单的测试点
（1） 每个字段的验证
（2） 字段的缺省值
（3） 表单中的输入
（4） 提交操作的完整性
12.3 与其他系统的异同
（1） 测试内容基本相同
（2） 某些项目的测试方法基本相同
（3） 测试手段基本相同
（4） 测试重点不一样
（5） 测试采用的工具有所不同
（6） Web应用系统迫切需要新的测试技术和方法
13 网络测试
网络测试的分类：
（1） 网络可靠性测试：在较长的时间内经受较大负载，然后监视网络中发生出现错误和故障，验证高强度环境下网络系统的存活能力。
（2） 网络可接受性测试
（3） 网络瓶颈测试：寻找导致系统性能下降的瓶颈的测试，类似于"木桶原理"。
（4） 网络容量规划测试：包括有效容量和最大容量的测试。
（5） 网络升级测试
（6） 网络功能/特性测试
（7） 网络吞吐量测试：测量网络的性能，检测每秒传输数据的字节数和数据报数。
（8） 网络响应时间测试：检测网络系统完成一系列任务所需要的时间。
（9） 衰减测试：测试贯穿整个通信或通道的信号衰减，在连接的一端发送一定长度的信号，在连接的另一端测试信号长度，确定衰减。
（10） 网络配置规模测试：通过反复比较不同的运行性能，选择最佳的运行性能配置的测试。
（11） 网络设备评估测试
网络测试对象（4个）：
（1） 网络平台：包括网络操作系统、文件服务器和工作站
（2） 应用层：指应用程序的客户端、桌面操作系统和数据库软件等
（3） 子系统：主要指路由器、集线器、交换机和网桥。
（4） 全局网路径：是整个网络系统中最重要的点对点路径。
基本技术指标：
（1） 吞吐量：被测试设备或被测系统在不丢包的情况下，能够达到的最大包转发速率。
（2） 丢包率：通过测试由于缺少资源而未转发的包的比例来显示高负载状态下系统的性能。
（3） 延时：测量系统在有负载条件下转发数据包所需的时间。
（4） 背靠背性能：通过以最大帧速率发送突发传输流，并测量无丢包时的最大突发长度（总包数量）来测试缓冲区容量。在全负载条件下生成突发传输流，如果所有的包都得到转发，就增加突发长度，并重新进行测试。但是如果某一对端口上出现包丢失，将突发长度减少一半再进行测试，然后利用二分法搜索查找无包丢失时的最大突发长度。
14 微内核架构（插件架构）
微内核架构：也叫插件架构，指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。通信效率低，插件通过内核实现间接通信，需要更多开销。
15 单元测试中路径测试不正确的计算
（1） 运算的优先次序不正确或误解了运算的优先次序
（2） 运算的方式错
（3） 算法错
（4） 初始化不正确
（5） 运算精度不正确
（6） 表达式符号不正确
16 事件驱动架构的测试
事件驱动架构：简称EDA，是重用的架构范式中的一种，其关注事件的产生、识别、处理、响应。
组件包括：
（1） 事件（通知）
（2） 事件队列
（3） 事件分发器
（4） 事件通道
（5） 事件处理逻辑
17 可靠度计算
17.1 串联
R=R1R2R3......Rn
17.2 并联
18 分支条件组合覆盖用例数计算
用例数=2^n（n=条件个数）
如，表达式（条件1||条件2||条件3），共有三个条件，需要2^3=8个用例才可以实现分支条件覆盖。
19 修正条件判定覆盖用例数计算
用例数=n+1
对于包含n个布尔条件的代码，需要n+1个用例实现100%修正条件判定覆盖。
20 n边界值测试用例计算
用例数=6*n+1
如果有一个n变量的软件输入域，使其中一个变量取略小于最小值、最小值、略大于最小值、正常值、略小于最大值、最大值、略大于最大值这样七种选择，其余的所有变量取正常值。对每个变量重复进行后，该n变量软件输入域的边界值分析会产生6n+1个测试用例。
21 最坏情况边界值分析的用例计算
用例数=5^n
最坏情况边界值分析：是在"多缺陷"假设的情况，即程序的失效是由于两个（或多个）变量值在其边界值取值共同引起的。在电子电路分析中，称为最坏情况测试。针对n个变量的输入域，最坏情况测试用例是元素集合的笛卡尔积，会产生5的n次方个测试用例。
如：在边界值分析法中，针对3个变量的输入域，最坏情况边界值分析下，会产生5^3=125个测试用例。
22 缺陷探测率计算
23 错误推断法-Seeding模型估算法
原理：设置A、B两组测试人员相互独立地对某个软件进行测试，记A组和B组人员测得的错误数量分别为i和j个，两组测试人员共同测试出的错误数量为k，软件错误数的估算值n与这三个量的关系：
n=(i*j)/k
24 测试用例覆盖率计算
25 缺陷修复率计算
26 测试过程模型
26.1 软件执行过程
（1） 细测期
（2） 系统测试期
（3） 回归测试期
（4） 验收测试执行
27 软件编码规范评测
（1） 源程序文档化
（2） 数据说明的方法
（3） 语句结构
（4） 输入/输出方法
28 软件失效分类与管理
软件失效：软件运行时产生的一种不希望或不可接受的外部行为结果。
软件失效机理：软件错误->软件缺陷->软件故障->软件失效。
（1） 错误：软件生存周期内的不希望或不可接受的人为错误。相对于软件本身是一种外部行为。软件缺陷的静态表现，存在于软件中的一种缺陷。
（2） 缺陷：存在于软件（文档、数据、程序）中不希望或不可接受的偏差，比如少写一个逗号。是软件运行在某一特定条件时出现的软件故障。
（3） 故障：软件运行过程中出现不希望或不可接受的内部状况。软件缺陷的动态表现。
（4） 失效：软件运行时产生的一种不希望或不可接受的外部行为结果。是因为软件缺陷导致的后果。
29 探索性测试风格
（1） 预感：基于以往的缺陷，探索新的变化
（2） 模型：架构图、气泡图、状态表、故障模型等
（3） 示例：用例、特性演练、场景
（4） 不变性：测试变更不会对应用程序产生影响
（5） 干扰：寻找中断或转移程序路径的方法
（6） 错误处理：检查错误处理是否正确
（7） 故障排除：错我分析，例如简化、澄清或加强错误报告，当缺陷修复后测试差异
（8） 小组洞察：头脑风暴、相关成员小组讨论、配对测试
（9） 规范：主动阅读，对照用户手册，启发式探索
30 缩短国内外软件测评的方法
（1） 企业提高对于软件测试环节的重视程度
（2） 需要有企业从业测试理论与技术研发的服务
（3） 作为行业管理者，要制定相应规范，严格控制软件开发的流程及标准
（4） 关注知识产权的利益，保障自身权益
31 测试工具
（1） Java单元测试工具：JTest
（2） 预测系统行为和性能的负载测试工具：LoadRunner
（3） 功能测试工具：WinRunner
（4） 负载压力测试性能工具： QALoad、WAS、Jmeter
（5） 大数据测试工具：Hadoop、HPCC、Cluoudera、Cassandra、Storm
（6） 自动化测试工具：UFT、Robot Framework、Selenium
32 可信软件验证工具
（1） Spin
（2） NuSMV
（3） Atelier
33 使用质量模型
（1） 有效性：指用户实现指定目标的准确性和完备性。准确性一般由软件产品的出错频率进行评价，完备性是指实现用户期望功能的完整性程度。
（2） 效率：指用户实现目标的准确性和完备性时相关的资源消耗。
（3） 满意度：指产品或系统在指定的使用周境中，用户的要求被满足的程度。
（4） 抗风险：是指用户或系统在经济现状、人的生命、健康或环境方面缓解潜在风险的程度。
（5） 周境覆盖：指在指定的使用周境中，产品或系统在有效性、效率、抗风险和满意度等特性方面能够被使用的程度。
34 测试管理组
测试管理组包括评审小组、测试小组、支持小组共3个小组。
（1） 评审小组：可以由业务人员、开发人员和用户等组成。负责定义评审，软件需求评审、详细设计评审、软件实现评审和软件验收评审。
（2） 测试小组：实行组长负责制，负责安排工作，对整个测试过程和产品质量进行总结和评价。
（3） 支持小组：负责网络管理、数据备份、文档管理、设备管理和维护，员工内部培训。