通俗易懂的软件测试理论

最近老看到有人在讨论测试左右移，测试内卷，自动化测试vs业务测试。 诚然我们需要提高测试技术来提升效率。但是一味的追求自动化，追求测试技术，有点舍本求末。 业务测试才是根本。就如同武术里面的基本功，只有马步扎实了，下盘稳了，才能不容易被打倒。自动化只能锦上添花，写自动化测试的，也需要懂业务，不然是无法写出有用的自动化测试用例的。

为什么现在招聘的要求都需要懂自动化呢？因为领导觉得自动化测试高大上，可以节约成本。而且会自动化，也可以从技术方面来思考质量。

在快速迭代的时代，业务能够及时高质量上线就烧高香，很多公司根本就没有资源去自动化(大公司除外，大公司有专门的团队去自动化，去专项测试)。很多公司测试都是点点点，上线了，刚准备自动化一下，又来一个迭代。很多测试人员都是刚抽空写几行代码，得赶紧先去理解业务，或者赶紧去处理线上的bug，去点点点，周而复始。如果一个团队有资源，可以在业务无压力的情况下，适当加入一些自动化，就能解放一部分重复劳动，提升效率和质量。

别看业务测试简单，只是点点点。但是也比较考验基本功。考察的就是你对业务的理解能力，场景的设计能力，对质量风险的把控能力。

当项目紧的时候，留给测试的时间不多，又要质量，又要速度，所以测试得对流程的把握，对产品的理解，以及快速覆盖多的场景，不然就会漏测等引起事故。

好了，废话一箩筐，得谈点基本的测试理论了。

一

测试级别

单元测试：针对被测系统最小的组成单元实施的测试活动，一般是类或函数，也可能最小的功能单元 集成测试：针对组件/单元与组件/单元之间的接口实施的测试活动，验证接口设计是否与设计相符 （1）函数间集成 （也叫单元测试） （2）模块间集成 （也叫集成测试） （3）子系统间集成 系统测试：将通过集成测试的软件，部署在真实的用户环境下执行测试 验收测试：以用户为主的测试，验收组应该由项目组成员、用户代表组成 （1）α测试：受控环境下执行测试，由用户在开发环境下执行的测试活动，开发者在测试人员申报，发现问题及时沟通解决 （2）β测试：不受控环境下执行测试，开发者不在测试人员身边，发现问题由专人统一收集，再由研发人员进行修改 （3）UAT测试：用户接受度测试；一般商业用户验证系统可用性进行的测试

系统测试类型

功能性测试：验证被测对象是否满足用户显性或隐性需求 性能测试：验证被测对象是否满足预先设定的性能目标 安全性测试： 兼容性测试：

软件测试方法

黑盒测试：不关注被测对象内部结构，仅从用户需求考虑，是否满足用户显性或隐性需求 白盒测试：结构测试、逻辑驱动测试 灰盒测试：既关注被测对象的外部特性，又关注其内部设计 静态测试：不执行被测对象程序，不运行被测对象的测试方法 动态测试：执行被测对象的检测活动 手工测试 自动化测试：通过自动化工具，或脚本语言自动化完成测试过程

软件质量（测试的基本法则）

功能性 可靠性 易用性 效率性 可移植 可维护

测试流程

测试计划设计 测试需求分析：功能需求，性能需求，外部接口需求

测试策略

测试规程设计

测试需求变更控制流程 测试用例变更控制流程 测试环境搭建流程 缺陷管理流程

测试用例设计

执行测试用例

预测试阶段（冒烟测试）：快速的对被测对象实施测试活动 系统测试：经过预测试后，开展系统测试，过程中发现缺陷，及时记录，根据管理流程进行缺陷提交、跟踪处理

二

测试用例格式

用例编号 测试项 测试标题 用例属性：功能测试、性能测试、兼容性测试、安全性测试 重要级别 预置条件 测试输入 操作步骤

用例设计方法

（一）等价类：具有相同属性或方法的事物集合，集合中某个个体所表现的特征与其他个体 完全一致

等价类划分

有效等价类：合理的，有意义的，系统接收的输入 无效等价类：不合理，无意义的，系统不接收的输入

等价类划分规则

1.需求规定了输入域的取值个数或某个范围，如规定6~10位，在范围内则为有效等价类，反之无效等价类 2.规定了某输入域特殊条件，如字母开头 3.需求规定了输入域是一组值，则可确定若干个有效等价类及一个无效等价类，如普通用户和钻石会员，金牌会员享有的折扣

进行用例设计

1.根据需求，划分有效及无效等价类，有效等价类统一编号，无效等价类统一编号 2.设计一个新的测试用例，使其尽可能覆盖所有尚未覆盖有效等价类，直到所有有效等价类都被覆盖 3.设计一个新的测试用例，使其仅覆盖一个无效等价类，直到所有无效等价类都被覆盖（每一个无效等价类构成一个用例）

等价类四则云算法

加：不考虑需求其他子项，细致分解当前测试点及详细需求，做累加 减：根据业务规则减少，排除相关不可能出现的规则，减少不可能出现的组合 乘：如果有效等价类中具有互斥条件的需求时，可进行相乘得到用例个数 除：排除所有具有重复特性的等价类，尽可能做到有效等价类之间交集为空，无效等价类之间交集也为空，有效及无效等价类的并集为整个输入域

（二）边界值

上点：边界上的点（若6-18，则为6和18） 离点：离上点最近的点（5，19），根据上点的精度确定 内点：边界有效范围内的任一点（10）

如何确定离点：

开区间，则离点在外：(6, 18)，上点6、18，离点7、17，内点10 闭区间，则离点在内：[6, 18]，上点6、18，离点5、19，内点10

边界值应用场景：

1. 若需求规定了取值范围或个数，可利用范围的边界内及边界附近的数据进行测试（上点，离点，内点）
2. 若需求规定了取值的个数，则少于个数一个，或多于个数一个的值进行测试（5件商品打折，则取4，5，6）
3. 若需求规定了一个有序集合的时候，可使用该集合的第一个和最后一个值进行测试（下拉列表有4个城市，选择第一和最后的城市）
4. 若程序中使用一个内部数据结构，则应从该数据结构的边界进行考虑（若int，取0和65535）

边界值方法应用步骤：

1. 根据等价类方法划分有效及无效等价类，确定上点、离点及内点，每个点统一编号
2. 设计一个新的测试用例，使其尽可能覆盖所有尚未覆盖的有效等价类，直到所有有效等价类完全覆盖
3. 设计一个新的测试用例，使其仅覆盖一个无效等价类，直到所有无效等价类完全覆盖

（三）判定表：分析和表述若干条件下，被测对象针对这些输入做出的响应，在遇到复杂业务逻辑时可以利用该表理清业务逻辑关系

条件：

1. 条件桩：需求规格说明书定义的被测对象的所有输入
2. 条件项：针对条件桩所有可能的输入数据的真价值

动作：

1. 动作桩：针对条件被测对象可能采取的所有操作
2. 动作项：针对动作桩，被测对象响应的可能取值

规则：

动作项和条件项组合一起，形成的业务逻辑处理规则

判定表应用步骤

1. 理解需求，确定条件桩、动作桩
2. 设计及优化判定表
3. 填写动作项
4. 根据判定表中输出结果的表现，进行判定表的合并（非必须）；如果输出相同，在其对应输入中，有且只有一个条件的取值对动作不产生任何影响则可合并（简化判定表）
5. 抽取测试用例

（四）因果图（判定表的前置，为更好得出判定表）

输入与输入关系

1. 异：所有输入条件中，最多有一个产生，也可以一个没有
2. 或：所有输入条件中，最少有一个产生，多个或所有
3. 唯一：所有输入条件中，有且只有一个条件产生
4. 要求：所有输入条件，只要有一个产生，其他也会出现

输入与输出关系

1. 恒等：输入条件发生时，结果一定会出现，当输入条件不发生时，结果一定不会出现
2. 非：输入条件发生时，结果一定不会出现，输入条件不发生时，结果一定会出现
3. 与：多个输入条件中，只有所有输入条件都发生，结果才会出现
4. 或：多个输入条件中，只要有一个发生，结果就会出现

（五）正交试验

1. 因子：所有参与试验的影响试验结果的条件
2. 水平：影响试验因子的取值或输入称为水平
3. 整齐可比：在同一张正交表中，每个因子的每个水平出现的次数完全相同，试验中，每个因子的每个水平与其他因子的水平参与试验的几率完全相同
4. 均匀分散：同一张正交表中，任意两列的水平搭配是完全相同的

1. 设计流程：分析需求获取因子及水平；根据因子水平选择合适的正交表；替换因子水平，获取试验次数；根据经验或其他因素补充试验次数；细化输出获取测试用例

（六）状态迁移：关注被测对象的状态变化，在需求规格说明书中是否有不可达到的状态和非法的状态，是否产生非法的状态迁移

状态：被测对象在待定输入条件下所保持的响应形式

方法流程：根据需求明确状态节点；绘制状态迁移图；绘制状态迁移树；抽取测试用例

（七）流程分析

场景设计法：

image

使用方法：

案例设计：

以前容易出题测试一个水杯，现在容易出题测试朋友圈。 掌握了测试的基本技能，就能快速设计更多的有效的测试用例了。这样产品的质量就更有保障，对客户负责，对领导负责，对公司负责。

软件工程是一个大的工程，质量是一个很重要的一环。简单的系统，可能点点就能保证质量，但是复杂的系统，不但要有专业的知识，敏锐的洞察力，细致的思考，还要不断的学习，总结经验。