1. 测试主流技能

功能测试、自动化测试、接口测试、性能测试

2. 常见测试分类

按阶段划分：单元测试、集成测试、系统测试、验收测试

按代码可见度划分：白盒测试、灰盒测试、黑盒测试

单元测试：针对程序源代码进行测试（开发）软件测试基础 (一): 单元测试 - 知乎 (zhihu.com)

集成测试：又称接口测试，主要针对模块与模块或系统与系统之间的接口进行测试软件测试入门系列之十：集成测试 - 知乎 (zhihu.com)

系统测试：针对软件全面进行验证（功能、兼容、文档）软件测试基础 (三): 系统测试 - 知乎 (zhihu.com)

验收测试：使用内测和公测来实现。内测：公司内部进行测试，公测：让玩家来进行测试。验收测试_程序媛_婷的博客-CSDN博客_验收测试

白盒测试：又称单元测试（针对程序源代码进行测试）软件测试入门系列之二十六：白盒测试 - 知乎 (zhihu.com)

灰盒测试：又称接口测试（看不见部分代码）软件测试 灰盒测试_w3cschool

黑盒测试：又称功能测试（完全看不见程序源代码，只针对功能进行验证）软件测试——黑盒测试_二十四弦的博客-CSDN博客_黑盒测试

系统测试和黑盒测试重点核心是功能测试

集成测试和灰盒测试又称接口测试

单元测试和白盒测试是对代码进行测试

自动化测试归属功能测试

性能测试、安全测试归属专项测试

扩展：测试策略

冒烟测试：大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性。

面试题：

        提测标准是什么？ --冒烟测试通过

        测试之前要怎么做？--冒烟测试

3. 质量模型

软件质量模型（ISO/IEC 25010）：质量模型提供测试设计的不同角度视野和验证方向。

        功能性、性能效率、兼容性、易用性、可靠性、信息安全、可维护性、可移植性

        功能性：软件功能是否满足需求

        性能效率：性能满足实际需求

        兼容性：软件能与主流硬件和软件兼容

        易用性：便于使用

        可靠性：性能和功能应用可靠

        信息安全：信息在传输或存储过程的安全程度

        可维护性：便于维护

        可移植性：具备迁移和便捷性

4. 测试模型

V模型

W模型

W模型优点：测试伴随整个产品开发周期，测试对象不仅是程序还有需求、设计文档，测试介入较早，尽早发现问题，降低修复成本。

W模型缺点：实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计要求较高。

开发流程：需求分析、概要设计、详细设计、编码、集成、实施、交付

测试流程：系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试

V模型和W模型_唐唐唐piong的博客-CSDN博客_v模型

5. 软件测试流程

需求分析、计划编写、用例设计、用例执行、缺陷管理、测试报告

6. 测试用例

用例：用户使用的案例

测试用例：执行测试的文档（用户使用的案例）

考虑点：质量模型（功能、性能、兼容、易用、安全）

作用：防止漏测、实施测试的标准

编写格式：用例编号、标题、项目/模块、前置条件、优先级、测试步骤、测试数据、预期结果

用例编号：项目+模块+编号

标题：预期结果+操作步骤

项目/模块：所属项目或模块

前置条件：要执行此条用例、有哪些前置操作

优先级：表示用例的重要程度或影响力P0~P4（P0最高）

测试步骤：描述操作步骤

测试数据：操作的数据，没有的话可以为空

预期结果：期望达到的结果

7. 等价类划分法

在所有测试数据中，具有某种共同特征的数据集合进行划分。

等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。

分类：

        有效等价类：满足需求的数据集合

        无效等价类：不满足需求的数据集合

步骤：

1. 明确需求
2. 确定有效和无效等价类
3. 提取数据编写测试用例

使用场景：

        针对需要有大量数据测试输入，但是没法穷举测试的地方：输入框、下拉列表、单选复选框

典型代表：

        页面的输入框类测试

8. 边界值划分法

选取正好等于、刚好大于、刚好小于边界的值作为测试数据

上点：边界上的点（正好等于）

离点：距离上点最近的点（刚好大于、刚好小于）

内点：范围内的点（区间范围内的数据）

边界值法设计用例步骤：

1. 明确需求
2. 确定有效和无效等价类（类型）
3. 确定边界范围值
4. 提取数据编写测试用例

需求：大于0小于等于30个字符

1. 明确需求：大于0小于等于30个字符
2. 确定有效和无效等价类：有效：大于0小于等于30的字符。无效：大于0小于等于30的数字
3. 确定边界范围值：上点：0、30，离店：1、29、31，内点：15位
4. 提取数据编写测试用例

优化：

        [-99,99]：-100、50、100、-99、99

        开内闭外，开区间考虑内点，闭区间考虑外点

9. 判定表法

有条件依赖

等价类边界值没有考虑输入条件之间的各个组合

定义：以表格形式表达多条件逻辑判断的工具

条件桩：列出问题中所有条件，列出条件的次序无关紧要

动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束

条件项：列出条件对应的取值，所有可能情况的真价值

动作项：列出条件项的、各种取值情况下应采取的动作结果

假设有n个条件，每个条件取值有两个，全组合有2的n次方种规则

步骤：

1. 明确需求
2. 画出判定表
   1. 列出条件桩和动作桩
   2. 填写条件项，对条件进行全组合
   3. 根据条件项的组合确定动作项
   4. 简化、合并相似规则（有相同的动作）
3. 根据规则编写测试用例

使用场景：

        有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

        判定表一般适用于条件组合数量较少的情况

        多条件之间有依赖关系，使用判定表进行测试覆盖

10. 场景法

拿到项目应该先测什么：业务

流程图：使用标准图形和箭头来表达成武或业务走向

流程图对测试人员作用：能够看懂流程图，设计业务用例，当雪球文档信息不全是，能根据需求，梳理出流程

场景法可以叫流程图法，用流程图描述用户的使用场景，然后通过覆盖流程路径设计测试用例。

意义：

        用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用

        测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

        冒烟测试用例：就是流程中从开始到结束的那条正确的路径

11. 错误推荐法

        通过经验推测系统可能出现的问题

        场景：

                时间紧任务量大，根据之前项目类似经验找出易出错的模块重点测试

        实践宽裕通过该方法列出之间出现问题较多的模块再次测试。

        如果时间紧任务大，怎么办？

        答：会根据产品人员确定重要业务，先把主要业务进行正向覆盖，覆盖完之后再根据时间再去覆盖主要的模块，正向在逆向，按时间节点走，之后加班把测试点写完，然后用例之后再写。

        当项目用例都执行完毕，且BUG都修复完成，离上线还有一段时间可以用此方法覆盖未测任务。

12. 缺陷判定标准

缺陷定义：软件在使用过程中存在的任何问题都叫软件缺陷，简称bug

缺陷判定标准：

        软件未实现需求规格说明书中明确要求的功能-少功能

        软件出现了需求规格说明书中指明不应该出现的错误-功能错误

        软件实现功能超出需求规格说明书指明的范围-多功能

        软件未实现需求规格说明书中虽未明确指明但应该实现的要求-隐性功能错误

        软件难以理解，不易使用，运行缓慢，用户体验不好-不易使用

缺陷产生的原因：

1. 需求阶段：需求描述不易理解，有歧义、错误等
2. 设计阶段：设计文档存在错误或缺陷
3. 编码阶段：代码出现错误
4. 运行阶段：软硬件系统本身故障导致软件缺陷。

软件缺陷的生命周期：

        需求规格说明（缺陷）->设计（缺陷）->编码（缺陷）->测试->故障分类->故障隔离->故障解决（缺陷）

缺陷的核心内容：

        缺陷的标题（描述缺陷的核心问题）、缺陷的预置条件（缺陷产生的前提）、缺陷的复现步骤（复现缺陷的过程）、缺陷的预期结果（希望得到的结果）、缺陷的实际结果、缺陷的必要附件

        缺陷提交要素：缺陷报告编号、严重程度、缺陷优先级、Bug类型、缺陷状态

        严重程度：严重、一般、微小、建议（S1-S4）

        缺陷优先级：0,（24小时）1（发布前）,2

        Bug类型：代码错误、兼容性错误，性能问题、设计缺陷

        缺陷状态：新建，打开，关闭，延期

        缺陷类型：功能错误、界面错误、兼容性、数据、易用性、改进建议、架构

        工作流程：设计用例->执行用例（执行测试）->缺陷（提交、验证、关闭）

        拆测试点：1. 功能（正向、逆向） 2. 非功能（兼容性(5大浏览器内核)，布局：与原型图一致，图片文字准确无误与原型一致）

        图片验证码（正向：正确+未过期、逆向：为空、过期、错误）

        缺陷标题分析：作用是什么？（让人看明白哪里错了）如果让人看明白？（描述测试数据+实际结果（预期结果）、测试数据描述+预期结果（实际结果）、测试数据描述+实际结果（需求））

缺陷管理流程：提交、验证、关闭

13. 缺陷管理工具

        Excel，禅道

        禅道：国产、免费、开源、简单、轻量级

        禅道使用流程：管理用例->创建用例->评审用例->执行用例

        管理缺陷->缺陷创建->缺陷跟踪->缺陷验证

14. 明确需求后如何开测试

        分析需求、提取测试点、设计用例、用例评审、执行用例、缺陷管理、测试报告