第一章

1、软件测试定义：

是为发现错误而执行程序的过程。是对软件需求，设计，编码的最终复查的一系列过程，是软件质量保证的关键步骤。

2、软件测试的目的:

1. 发现缺陷，提高质量；

2. 验证是否满足需求(功能及其性能)；

3. 建立软件质量的信心。

3、软件测试的原则：

1. 测试显示缺陷的存在；

2. 穷尽测试是不可能的；

3. 测试尽早介入；

4. 缺陷集群性；

5. 杀虫剂悖论: 采用同样的测试用例多次重复进行测试，最后将不再能够发现新的缺陷；

6. 测试活动依赖于测试背景；

7. 不存在缺陷（就是有用系统）的谬论。

4、软件测试工作最为重要的是：

1. 测试流程、方法；

2. 测试工具；

3. 测试人员素质。

5、软件测试流程

1. 制定测试计划和控制；

2. 测试需求分析和用例设计；

3. 实现（编写测试用例）和执行测试用例；

4. 评估出准则和报告（提交测试报告）。

5. 测试结束活动

第二章：测试用例执行

1、软件测试的执行包括： 

手动测试 自动测试

2、软件测试执行的内容（要决定怎样执行测试和测试什么），主要包括下面的任务：

1. 执行测试计划预定的测试，包括执行所有已设计的测试用例；

2. 记录原始测试数据；

3. 记录执行结果；

4. 记录缺陷；

5. 对所发现的缺陷进行跟踪、管理和监控。

3、软件测试执行影响因素：

1. 测试计划 

2. 测试环境准备 

3. 测试实现

测试执行进度计划的影响因素: 过程成熟度; 测试的时间; 测试的规模;

测试的资源; 产品的质量; 测试的文档

4、四个度量指标:

1. 测试覆盖率: 度量测试完整性；

2. 测试执行率: 实际执行过程中确定已经执行的测试用例比率；

3. 测试通过率: 度量测试执行结果；

4. 缺陷解决率: 某个阶段已关闭缺陷占缺陷总数的比率。

第三章 软件缺陷

1、软件错误或软件缺陷是软件产品的固有成分，是软件“生来具有”的特征，软件缺陷包括检测缺陷和残留缺陷

2、软件缺陷报告

（1）报告缺陷的基本原则：

• 尽快报告缺陷 

• 有效描述缺陷

• 报告缺陷时不做任何评价 

• 确保缺陷可以重现

（2）软件缺陷报告的编写原则 ：

Correct( 准确)，Concise( 简洁)，Clear( 清晰)，Consistent（一致），Complete（完整）

3、缺陷报告的主要要素：

1. 可追踪信息 — 缺陷 ID (唯一的缺陷ID，可以根据该ID追踪缺陷)

2. 缺陷基本信息

   
   

3. 附加信息- - 必要 的附件

4、缺陷生命周期

5、软件缺陷度量的主要方法有：

• 缺陷密度（缺陷在规模上的分布）

缺陷密度=已知缺陷的数量/产品规模

• 缺陷率（缺陷在时间上的分布）

缺陷率=一定时间范围内的缺陷数/错误几率

• 缺陷清除率

整体缺陷清除率=开发过程中发现的所有缺陷数/发现的总缺陷数

阶段性缺陷清除率=开发阶段清除的缺陷数/产品潜伏的缺陷总数

• 缺陷趋势通常用缺陷趋势图来表示

• 缺陷发现率

第四章：软件测试过程及其管理

1、软件测试过程模型

**：V 模型和W 模型的局限性：

1. 串行活动，无法更好适应变更：把软件的开发视为需求、设计、编码等一系列的串行活动，无法解决需求变更等变更调整。

2. 线性的前后关系，无法有效支持迭代：开发和测试保持线性的前后关系，上一阶段完成才能开始下一阶段，无法有效，快速支持产品迭代。

3. 测试完整性不足：顺序模型中没有很好体现测试流程的完整性。

2、C MMI I 的五个级别：

• 初始级、被管理级 、被定义级、 定量化管理级 、持续优化级

3、软件测试过程管理的理念：

1. 尽早测试：（降低成本，规避风险）（单元测试、集成测试、系统测试）

2. 全面测试：软件开发及测试人员（有时包括用户）全面地参与到测试工作中（测试内容包括：需求、设计文档、代码、用户文档等）（全方位把握软件质量，尽可能排除影响软件质量的因素，满足需求）

3. 全过程测试：测试人员关注开发过程，对各种变化做出响应。测试人员要对测试的全过程进行全程的跟踪，及时调整测试策略。（及时应对项目变化，降低测试风险）

4. 独立的，迭代的测试：强调了测试的就绪点，也就是说，只要测试条件成熟，测试准备活动完成，测试的执行活动就可以开展。（测试过程是独立的）（迭代的测试）

4、BUG 的跟踪和管理

1. 设计好每个bug 应该包含的信息条目、状态分类等；

2. 通过系统自动发出邮件给相应的开发人员和测试人员，使得任何bug 都不会错过，并能得到及时处理；

3. 通过日报、周报等各类项目报告来跟踪目前bug 状态；

4. 在各个大小里程碑之前，召开有关人员的会议，对bug 进行会审；

5. 通过一些历史曲线、统计曲线等进行分析，预测未来情况。

软件测试文档的概念：软件测试文档描述要执行的软件测试及测试的结果，用来记录、描述、展示测试过程中一系列测试信息的处理过程，通过书面或图示的形式对软件测试过程中的活动或结果进行描述、定义及报告，记载了整个测试的过程和成果

软件测试文档的作用

• 提高软件测试过程的能见度

• 文档化能规范测试问题的反馈，提高测试效率

• 便于团队成员之间的交流与合作

• 测试文档是测试人员经验提升的最好途径

• 有利于项目测试的监控作用

• 有利于测试工作的开展

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试数据是在测试中使用的实际值（集合）或执行测试需要的元素。

测试脚本是自动执行测试过程（或部分测试过程）的计算机可读指令。

软件项目测试组织的人员

1、测试需求的特征：

1. 制定的测试需求项必须是可核实的；

2. 测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件；

3. 测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容。

2、为什么需要测试需求

1. 软件测试需求是开发测试用例的依据；

2. 有助于保证测试的质量与进度；

3. 测试需求是衡量测试覆盖率的重要指标。

3、测试需求评审

完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求。

准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。

评审人员组成：

1. 正式评审小组中，一般存在多种角色，包括协调人、作者、评审员等。

2. 评审员需要精心挑选，保证不同类型的人员都要参与进行来，通常包括项目经理、开发经理、测试经理、系统分析人员、相关开发人员和测试人员等。

第六章 测试用例设计

黑盒测试又称功能测试或数据驱动测试：

1. 把测试对象当作看不见内部的黑盒，在完全 不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性；

2. 站在使用软件或程序的角度，从输入数据与输出数据的对应关系进行的测试；

3. 在软件的接口处进行测试；

4. 通过导出执行程序所有功能需求的输入条件集，实现功能覆盖，需求覆盖。

黑盒测试主要回答这几方面的问题：

（1）如何测试功能的有效性：

• 何种类型的输入会产生好的测试用例

• 如何分隔数据类的边界

• 系统是否对特定的输入值特别敏感

（2）如何测试系统行为和性能

• 系统能够承受何种数据率和数据量

黑盒测试要求

– 每个软件特性或功能必须被一个测试用例或一个被认可的异常所覆盖

– 构造数据类型和数据值的最小集测试

– 对影响性能的关键模块，应测试模块性能

• 程序做了该做的

• 程序没有做不该做的

• 程序错误处理是否完整

什么是等价类划分

– 等价类，把所有可能的输入数据,即程序的输入域划分成若干部分,

– 划分，从每一部分中选取少数有 代表性的数据做为测试用例，代表性数据等同于该类中的

其他值

划分等价类的考虑因素: 输入数据, 输出数据

• 有效等价类：对于程序规格说明来说，是合理的，有意义的输入数据构成的集合

• 无效等价类：对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合

划分等价类的经验原则:

• 输入条件的取值范围, 可以划分出一个有效等价类和两个无效等价类；

• 如果输入条件规定了 输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类；

• 如果输入条件是一个 布尔量，则可以确定一个有效等价类和一个无效等价类；

• 如果规定了 输入数据的一组值(假设N个)，而且程序要对每个输入值分别进行处理。

–每个允许的输入值是一个有效等价类（即N个有效的）

–这组值确立一个无效等价类，它是所有不允许的输入值的集合。

• 如果规定了输入数据必须遵守的规则，则可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)

• 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为

边界值分析: 边界的含义: 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,稍高于其边界值及稍低于其边界值的一些特定情况。

边界值分析方法: 选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据的方法

因果图: 是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。

适用范围: 适合检查程序输入条件的各种组合情况

随机测试; 猜错法; 探索性

• 测试用例的作用？

指导测试执行者执行测试

告诉执行人员如何执行测试

• 测试用例的核心部分？

步骤名称、步骤描述、预期结果；

业务顺序；操作对象、操作方式、操作数据；操作完成之后期望的结果（重点的检查点）

• 测试用例的主要组成内容？

步骤名称；步骤描述；预期结果；

测试用例编号；模块；前置条件；

用例名称；实际结果；测试结果；

备注；优先级；设计人；

测试用例编号举例：（有的项目组会对测试用例名称进行如下规范要求）

规范1：项目名字_子系统_功能模块_测试点_ N_测试数据_顺序编号

YUM_餐厅管理_餐厅查询_权限检查_管理员登陆_101

YUM_餐厅管理_餐厅查询_权限检查_N_非管理员登陆_102

01_Test_Query_flight_CapicityTesting

测试用例主要元素:

测试环境

测试输入数据

测试执行步骤

测试预期结果

作者：Dear小七

原文链接：https://blog.csdn.net/qq_41389678/article/details/95986650