功能测试学习笔记【资料来源：B站黑马测试】

链接：软件测试第一篇_测试理论_Linux数据库_超详细教程_哔哩哔哩_bilibili

一、测试的基本知识

1. 软件测试：通过手工或自动化的方式运行被测的软件是否正常（看预期结果和实际结果是否一致）。
2. 测试目的：保障软件的质量（尽可能多的发现系统中的错误，证明软件存在问题。）
3. 测试体现形式：通过找出bug的形式验证质量。

1.1、软件质量模型

软件质量模型的应用场景：提供对于软件产品从测试角度思考的一种思路。

1.1.1、软件质量

软件质量就是软件与明确的和隐含的定义的需求相一致的结果。

1.1.2、质量模型标准

对于测试作用：提供测试设计的不同角度和思路。

ISO/IEC 25010

1. 功能性：满足某种需求的一种属性或能力。
2. 性能效率：在规定条件下，相对应所用资源的数量，软件产品提供适当性能的能力。
3. 兼容性：在一定条件下兼容其他软硬件产品的能力。
4. 易用性：在指定使用条件下，产品被理解、学习、使用和吸引用户的能力。
5. 可靠性：产品在规定条件下，在规定时间内完成规定功能的能力。
6. 信息安全性：信息在传输或者存储过程的安全程度。
7. 可维护性：在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力。
8. 可移植性：从一种环境迁移到另一种环境的能力。 

其中，功能性、性能效率、兼容性、易用性是必须且主要考虑的方面。

二、软件的生命周期

软件的生命周期是软件从无到有再到消亡的过程。

软件生命周期也叫软件开发过程模型、软件生命周期模型。

1、模型介绍

在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，也展示出软件从无到有再到消亡的过程。

软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模式，以便找准自己在其中的位置，从而发挥自身的价值。

2、瀑布模型

瀑布模型是描述软件生产到消亡的过程模型图，该模型目前实际工作中已不常用，但是该模型是其他模型的鼻祖。

 瀑布模型的优点：

1. 每个阶段比较清楚，并且有相对应的文档产生。
2. 当前一个阶段完成后，才开始后面的阶段（一次性的）。

瀑布模型的缺点：

1. 发现问题的时机比较晚，失去提前纠错的机会。
2. 测试介入比较晚。

适应场景：

适用于需求不易发生改变的大项目。

3、敏捷开发模型

能够适用需求的变化，并且能够给出快速的响应。

• 小步快跑
• ACP

3.1、软件测试模型：V模型

V模型的作用：主要描述测试、开发之间的对应关系。

V模型的简介：

1. V模型具有代表意义的模型，最早由Paul Rool 在20世纪80年代后期提出，由英国国家计算机中心发布。
2. V模型是瀑布模型的变种，反应测试活动与需求分析、产品设计之间的关系。
3. V模型从左到右，描述了开发与测试过程之间的阶段对应关系。

 V模型的优点：每个阶段比较清楚，测试过程由底层（代码）到高层（应用）测试过程。

V模型的缺点：不适用于需求的更改。

3.2、W模型

W模型，简称“双V”模型，即以开发主导的一个“V”，和以测试主导的另一个“V”构成，为了克服V模型的缺点，引入了W模型。

W模型的优点：

1. 测试介入时间早，能够及时发现问题，降低修复成本。
2. 测试伴随整个软件生产周期，除了测试软件之外，还需要验证文档。

W模型的缺点： 

1. 该模型应用起来复杂度高（具备计算机技能、业务能力、管理能力、测试素质）

四、测试用例

4.1、目的

1. 方便测试验证（将需求大量描述拆分为小的测试点）。
2. 体现测试人员的思路，测试设计的全面性（后续测试可以直接使用）。
3. 测试的量化体现，能够反应测试进度。

4.2、定义

测试用例也叫Test Case，为了特定的目的而设计的一组测试输入，执行条件和预期结果构成的文档。

4.3、测试用例的八大核心要素

1. 用例编号：表示用例的唯一性，有时也叫用例ID。
2. 用例标题：表示要测试或验证的目的，通常一句话简要描述。
3. 测试项目：当前测试的功能所属范围。
4. 用例级别：表示用例的重要程度或者影响力。
5. 预置条件：验证该功能需要的前提条件。
6. 测试输入：必要的输入数据。
7. 执行步骤：验证该功能需要的先后操作步骤。
8. 预期结果：希望得到的结果。

其中，用例编号、用例标题、用例级别、执行步骤、预期结果是必备！！！ 

五、测试用例方法

5.1、等价类划分法

5.1.1、基本定义

1. 定义：在所有测试数据中，具有某种共同特征的数据子集。
2. 等价类划分为：
   1. 有效等价类：满足需求的数据子集。
   2. 无效等价类：不满足需求的数据子集。（需要注意的是，只要不满足其中一个条件即可）

5.1.2、等价类划分法设计用例步骤

1. 明确需求
   1. 测试目的
   2. 测试条件：长度、类型、规则这三面入手。
2. 确定有效和无效等价类
3. 提取数据编写测试用例

5.1.3、应用场景

1. 针对需要有大量数据测试输入，但是没法穷举测试的地方。（如：有输入框、下拉列表、单选复选框等，需要同时提交，对于每种输入都需要大量测试验证）。
2. 典型代表：页面级的输入框类测试

5.1.4、编写用例注意事项

1. 单模块测试中，用例标题具有唯一性。
2. 必要步骤尽可能清楚。
3. 预期结果尽量描述测试结论性的语句及现象（如果有具体现象最好描述）。
4. 用例编号和测试项目简称对应设置。

5.2、边界值分析法

5.2.1、适用场景

开发人员常常在边界的位置容易出现问题，此时需要针对边界位置再测试。

1. 是对等价类划分法的完善和补充。
2. 针对有边界范围的批量数据的输入类测试（重点关注边界）。
3. 典型代表：输入框（有边界范围区间）。

5.2.2、边界范围的确定

根据需求，将数据类型和边界确定，直接可以获取对应的边界范围值。

1. 上点：刚好等于边界的值（取值不考虑开闭区间）。
2. 离点：刚好大于/小于边界上的值（取值类型看需求）。
3. 内点：边界范围内的任何取值（取中间的值）。

5.2.3、边界值分析法设计用例步骤

• 明确需求
  • 测试目的
  • 测试条件
    • 长度
    • 类型
    • 规则
• 划分等价类
  • 有效等价类
  • 无效等价类
• 确定边界范围值（确定边界范围值之后，结合等价类进行合并补充）
  • 上点
  • 离点（可以优化）
  • 内点（可以和有效等价类的取值合并）
• 提取数据编写用例
  • 按照用例模板编写内容即可

5.2.4、离点优化

目的：减少用例数量，由7条数据变为5条数据。

注意事项：非必须，可以不优化。

优化口诀：开内必外

开区间：（-99,99）-99

闭区间：[-99,99] -99<=x<=99

优化后取值结果：

1. 上点：必选（不考虑开闭区间）。
2. 离点：开内必外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）。
3. 内点：必选（建议选择中间范围）。

5.3、判定表法

5.3.1、判定表法的引入

等价类边界值分析法主要关注单个输入类条件的测试，并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。

判定表：是一种以表格形式表达多条件逻辑判断的工具。

5.3.2、判定表的构成

1. 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
2. 动作桩：列出问题中的可能采取的操作，操作的排列顺序没有约束。
3. 条件项：列出条件对应的取值，所有可能情况下的真假值。
4. 动作项：列出条件项的各种取值情况下应该采取的动作结果。

重点：

假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方种规则。

5.3.3、判定表设计用例步骤

• 明确需求
  • 测试目的
  • 测试条件：根据需求列出
• 画出判定表
  • 列出条件桩和动作桩（根据需求来分析提取）
  • 在条件桩前面加判定词，根据条件数量进行组合得到所有取值（条件项）
  • 根据每种条件的组合得到动作项
  • 优化合并相同的条件
• 按照规则编写用例
  • 按照测试用例模板编写即可

5.3.4、判定表的试用场景

1. 针对需求中有多个条件，并且条件和条件之间有组合关系，条件和结果之间有制约（因果）关系的场景。
2. 常见词汇：如果……那么……；若……则……
3. 局限性：条件不易过多（不超过4个）
4. 注意： 超过4个条件的不常见，如果出现超过4个以上条件的，可以使用因果图。

5.4、场景法

5.4.1、定义

场景法也叫流程法，通过流程图的描述用户的使用场景过程，验证整个产品的业务（用户使用过程）是否正常。

• 用户：用户使用更加关注整个系统的应用。
• 测试：测试不仅仅要关注单功能测试，还需要关注系统之间组合测试。

5.4.2、场景法意义

• 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用。
• 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。

5.4.3、场景法适用场景

• 一般在测试的后期，对于整个系统的模块功能进行全部的组合测试。
• 测试的依据：业务流程图

5.4.4、业务流程图图案代表的意义

1. 椭圆：表示流程的开始/结束。
2. 长方形：流程的处理或者操作。
3. 菱形：表示流程节点的判断（一般两种结果）。
4. 平行四边形：表示流程流转过程中数据的输入/输出。
5. 箭头线：表示流程的走向（箭头线上可以添加标记）。

5.5、错误推测法

5.5.1、定义

1. 要求：有实际项目测试经验的人使用。
2. 定义：通过直觉（经验）或者智慧推测系统可能出现问题的地方进行再次测试。

5.5.2、错误推测法适用场景

1. 时间紧迫：通过以往类似项目的经验，提取当前项目中核心模块（出现问题较多）进行测试。
2. 时间宽裕：在基础测试的基础上，将原有模块（存在问题较多）进行再次细化测试。

5.5.3、由错误推断法引出的问题

上述两种场景是否需要测试用例？

• 场景1：需要提取核心模块（按照用例的优先级）用例进行测试
  • 通过xmind思维导图先整理大概的测试点
  • 找相关项目经验的测试人员去测试
  • 通过自动化的技术或者能够提升测试效率的技术去实现测试
• 场景2：需要将原有用例细化完善后，按照用例依次测试即可。

六、软件缺陷

6.1、软件缺陷的定义

软件在使用（运行）过程中存在的任何问题（如：错误、异常、失效等），都叫做软件的缺陷，简称bug。

6.2、缺陷的判定标准

1. 软件未实现需求（规格）说明书中明确要求的功能 --- 没有做
2. 软件出现了需求（规格）说明书中指明不应该出现的错误 --- 做错了
3. 软件实现的功能超出需求（规格）说明书指明的范围 --- 做多了
4. 软件未实现需求（规格）说明书虽未明确指明但应该实现的需求 --- 没做完
5. 软件难以理解，不易使用，运行缓慢，用户体验不好 --- 不完美

扩展：

• 违反上述标准的1、2、3条件，基本上属于高严重级的bug。
• 违反上述标准的4、5条件，基本属于中低级别的bug。

6.3、缺陷产生的原因阶段

6.3.1、为什么需要分析缺陷的原因？

1. 能够帮助测试领导确定产品出现质量问题的具体阶段，方便后续软件产品质量的优化。
2. 能够帮助测试人员积累经验。

6.3.2、原因阶段

1. 需求阶段：需求描述不易理解，有歧义、错误等。
2. 设计阶段：设计文档存在错误或者缺陷。
3. 编码阶段：代码出现错误（语法、单词、标点符号等）。
4. 运行系统：软硬件系统本身故障导致软件缺陷。
5. 故障解决阶段：对于系统不熟悉修复问题时引入新bug。

6.3.3、缺陷的生命周期

6.3.4、引出的问题

问题: 你认为上述生命周期的阶段中，哪个阶段出现问题的比例最高？

答案：

• 需求阶段，出现问题比例高。
• 需求阶段文档编写不完善、需求容易发生变化等都是造成bug的根本原因。

6.3.5、缺陷报告的核心内容

• 缺陷的标题 --- 描述缺陷的核心问题 ---> 错误问题的结论+【现象】
• 缺陷的预置条件 --- 缺陷产生的前提 ---> 和测试用例的预置条件一样
• 缺陷的复现步骤 --- 复现缺陷的过程 ---> 和测试用例的测试步骤基本一致（含测试数据）
• 缺陷的预期结果 --- 希望得到的结果 ---> 和测试用例的预期结果一致
• 缺陷的实际结果 --- 实际得到的结果 ---> 实际的错误问题描述（结论+错误现象）
• 缺陷的必要附件 --- 图片、日志等信息（证据）---> 方便开发判定问题出现的具体位置

6.3.6、缺陷报告的其他要素

• 缺陷的编号：能够唯一的表示一个缺陷
• 缺陷的状态：描述缺陷生命周期的过程
  • 新建（new）：表示缺陷的产生
  • 打开（open）：表示开发确认通过
  • 拒绝（rejected）：表示开发确认不通过
  • 进行中（inprogress）：表示开发正在修复缺陷
  • 已修复（fixed）：表示开发已经修复完成
  • 延迟修复（delay/postpone）：表示开发延迟修复
  • 测试通过（closed）：表示测试通过，已关闭
  • 测试不通过（reopen/open）：表示测试不通过，重新打开
• 缺陷的所属模块：类似于用例的所属项目，描述缺陷产生的模块范围
• 缺陷的优先级：告诉开发当前缺陷修改的先后次序（p1）priority
  • urgent priority：最高优先级
  • veryhigh prioity：次高优先级
  • high prioity：高优先级
  • mediun prioity：中优先级
  • low prioity：低优先级
• 缺陷的严重级：告诉产品当前缺陷对于整个产品的破坏程度（和优先级一一对应）（s1）serious
  • critical：致命的破坏
  • major：高的破坏性
  • medium：中等破坏
  • minor：低等破坏
  • tiny：微小的破坏
• 缺陷的类型：描述缺陷主要产生问题的原因
  • 功能问题
  • UI问题
  • 兼容性问题
  • 易用性问题
  • 架构问题
  • 安全问题

6.3.7、由此引出的问题：作为测试人员，一般什么时候提交缺陷报告？能否可以直接口头传达不写缺陷报告？

• 执行测试用例，并且失败的时候，就立即停止执行马上提交bug。
• 不能，防止忘记之后无法保留证据。

七、缺陷管理

7.1、缺陷的跟踪流程

 7.2、问题：开发能否直接关闭缺陷？

不能，因为留存证据，即使报错了，开发只能拒绝，不能关闭。

7.3、编写缺陷报告规范

• 可复现：确保当前发现的bug能够复现。
• 唯一性：确保一个缺陷报告中上报一个问题。
• 规范性：遵循公司规定的报bug的要求。

7.4、编写缺陷报告的注意事项

• 确保上报的bug是准确的。
• 描述尽可能简洁易懂具体。
• 不能使用感情色彩的词语。
• 不能使用模棱两可的词汇。
• 不能使用人称代词。

7.5、面试题：在实际测试中如果出现不可复现的bug怎么办？

• 经过多次复现后，还是没有出现，此时在本地记录当前的问题
• 回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或者环境临时故障引起
• 请开发协助（自己）查找当前测试模块是否有对应的日志信息（日志的位置可以问开发）
• 再考虑更换一套环境查看是否能够复现上述问题
• 在后续的版本中测试，此时需要关注当时测试该功能时是否还出现上述的问题
• 在后续版本还出现过，需要开发协助打印日志进行分析定位，同时测试需要提交bug

八、项目管理工具

禅道，除了禅道，还有：

• JIRA（澳大利亚收费软件，作用类似于禅道）
• Testlink
• QC
• bugzilla

九、案例

9.1、测试环境搭建思路

1. 知道项目环境的组成架构。
2. 知道项目环境的软硬件组成。
3. 知道项目环境的安装步骤。
4. 搭建出可用的项目测试环境。

9.2、B/S和C/S

1. B/S：浏览器（Brower）服务器（Server）
2. C/S：客户端（Client）服务器（Server）

9.3、组件说明

9.3.1、常见的web服务器

• Apache：稳定性比较好，对于PHP项目的支持非常好。
• Nginx：并发性（性能）比较好，常常和其他web服务器一起结合使用。
• Tomcat：针对Windows Server系统的web服务器部署。

9.3.2、Apache和Nginx区别

1. Apache的稳定性比较好，对于PHP项目的支持非常稳定。
2. Nginx的并发性比较好，用于性能要求较高项目中。
3. 在实际工作中可以配合一起使用。