单元测试、集成测试、系统测试、验收测试
2. 按是否运行程序划分：静态测试、动态测试
3. 按是否查看源代码划分：白盒测试、黑盒测试
黑盒测试分为：功能测试，性能测试。A. 功能测试：逻辑功能测试 界面测试 易用性测试 安装测试 兼容性测试
B. 性能测试：一般性能测试 稳定性测试 负载测试 压力测试
回归测试 冒烟测试 随机测试
随机测试：随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分
（1）当前阶段的核心目的就是梳理清楚我们需要设计的点是什么。
（2）需求的来源：需求规格说明书、API文档、竞品分析、个人经验。
（1）用例就是用户为了测试软件的某个功能而执行的操作过程。
（2）设计用例是有方法的（等价类、边界值、判定表）
对当前的用例进行添加或者删除
4.配置环境：环境：指的是当前被测对象运行所需要的执行环境。作为测试人员需要具备配环境的能力。（一般情况都会使用一键安装的集成环境）
环境分类：操作系统+服务器软件+数据库+软件底层代码的执行环境。
（1）一般在执行用例之前我们会做一个冒烟测试，这种测试的核心就是快速的对当前软件的核心功能或者主体执行流程进行验证。如果冒烟测试阶段有问题，则可以将此版本回退给开发。
（2）如果冒烟测试通过那么才会开展全面测试。
（1）回归测试指的是当我们将某个软件缺陷提交给开发，由他们进行修复，修复完成之后需要测试人员对其再次进行测试。（回归测试）
（2）缺陷跟踪指的是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。
将当前的测试过程中产生的数据进行可视化的输出， 方便其他人查看。
8.测试结束将整个测试过程中产生的文档进行归档，方便后续版本使用。
三、测试用例设计方法边界值法、等价类划分法、场景法、因果图法、决策法、正交验证法和错误推测法。
边界值法和等价类划分法一般结合使用；
将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
思想：减少测试用例，解决输入无穷问题
使用场景：输入无穷
概念：无穷的测试分为N个类，然后从类里面取一个数据测试，只要这一个数据通过测试，那么这一类数据全部通过
（输入和输出的边界值）—确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），主要输入一些合法数据/非法数据，主要在边界值附近选取。
注意：取值有规则（开区间和闭区间）
闭区间（向外取值）【1,50】 0，1，50 ，51
开区间（向内取值）（1,50】 1，2，50 ，51
边界值是 等价类的补充方法，成对出现
使用场景：输入（原因）和输出（结果）之间的关系
输出依赖输入（多个）
第一步：理出所有的输入和输出
第二步：在画出输入与输出之间的关系
第三步：画因果图
第四步：画判定表（列数：输入->幂数 输出：底数）
第五步：从判定表提取测试用例
目的：减少测试用例条目
注意：和等价类思想不一样（等价类是分类，正交排列法是用正交表（抽样，抽满足正交表的数据））
两条性质：
A. 所有列中的数据的个数相同
B. 任何两列中的有序对数相同
步骤：比因果图多一个步骤（加上认为可疑的数据）
正交实验的次数：N=C*(T-1)+1
C:因素数=====变量
T:水平数
是基于一个基本流和多个备选流的方法。比如登录用例：“输入正确账号和正确密码”，属于基本流；“输入正确账号和错误密码”和“输入不存在的账号”等属于备选流
登录：
a) 判断用户名是否存在
b) 判断用户名和密码是否匹配
c) 判断用户的状态是否正确
d) 触发click
典型应用：业务流程
注意：一个业务流程图里面不一定只有一个场景
对下图编写测试用例（场景法）：
上图是一个入口三个出口，每一个场景只有入口和一个出口
场景一：基本流
场景二：基本流–备选流1–备选流2
场景三：基本流–备选流3–备选流1–备选流4
场景四：基本流–备选流1–备选流3–备选流4
…
只要不到备选流4和备选流2（结束用例）就可以继续循环下去
异常场景、异常操作等。
猜测来源：
1） 测试人员对项目测试时间长
功能，业务，复杂度了解；对开发人员的能力了解
2）用户反馈
3）缺陷（未发布），故障（发布上线）库
注意：错误推测法和无效等价类有一部分是重叠的，例如输入框的长度不够
但是对于测试人员测试时间长以及对研发人员能力的了解属于错误推测
题目：执行一条测试用例，但是测试完后没发现bug？ 有效的
原因：测试的目的——1）验证是否有bug 2）验证符合用户需求
误区：测试用例的有效性不是用是否发现bug来验证的，而是看是否可执行
- 在内容上：考虑软件的各类因素，包括流程、UI界面、提示语、交互、功能点，除了流程和功能点的描述外，UI界面、交互和提示语也需要用例编写，验证是否与UI界面设计相符合；
A. UI界面举例：登录界面中应该包含：输入文本框、密码文本框，验证码文本框，验证码图片，登录按钮，且布局正常
B. 提示语（对于前端的限制）举例：输入文本框只允许输入6-10位的字符
C. 交互（用户角度）：一般针对移动端，根据原型图设计，对滑动方向，页面返回和加载等设计用例 - 在测试流程上：优先考虑系统核心流程，再考虑系统的异常情况，合理安排测试工作时间和任务的分配
- 设计测试用例的优先级顺序：场景分析、边界值、等价类
- 用例的执行顺序：流程->UI界面->各类功能点
- 测试用例标题编写格式：执行了什么动作或者输入了什么条件，期望得到什么结果
例如：点击删除按钮后，所选记录被删除
- 需求说明书
- 项目测试需求功能点
- 测试工程师本人的理解程度
或者（需求说明书、UI图和原型图等）
- 模块名称
- 子模块名称
- 用例编号：唯一标识，与需求编号对应，为多对一关系
- 用例名词：对测试项简短的描述
- 优先级： 确定用例执行的级别
- 预置条件：执行用例时需要的预置条件
- 操作步骤：执行该动作需要完成的操作
- 预期结果：执行完该动作后程序的表现结果
- 实际结果：实际输出的结果
- 问题描述：执行该用例出现后系统显示的错误
- 验证结果：该测试用例是否执行通过
- 测试执行者：按照该用例执行测试的人员
- 系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系
- 连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯
- 全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备
- 正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合
- 符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规
- 可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果
- 修改的测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明 - 删除冗余的测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个 - 增添新的测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
- 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
- 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
- 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
- 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
- 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
- 效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
- 可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
