软件测试用例篇

为什么软件测试人员要写测试用例

1. 测试用例是测试执行的依据
2. 测试用例可以复用，再进行回归测试的时候不用重新编写
3. 衡量需求的覆盖率
4. 后人可以借鉴
5. 测试用例是自动化测试的依据

测试用例的基本要素

设计测试用例的万能公式： 界面+功能+性能+易用+安全+兼容

1. 分析需求，验证需求的正确性和合理性，逻辑自洽，无二义性
2. 细化需求，提取出测试项目，从每一个测试项目中提取出测试点
3. 功能性测试
   • 界面功能的全面性测试（上至下，左至右）
   • 按照业务的场景把一个个独立的功能串起来进行测试
   • 验证功能之间的交互性和一致性，不能有冲突
   • 功能的不同输入有相应不同的输出
   • 异常功能的测试
   • 功能用到的算法验证
4. 非功能性测试
   非功能测试就是测试在软件本身有的功能之上做的一些限制【易用，兼容，性能，安全，可移植，可靠，可维护】
   • 客户端：对性能，安全性要求不高，但是对于兼容性，可移植性稳定性要求高【画图板，office，xmind】
   • 企业端：对兼容性，性能要求不高但是对功能性，可靠性要求高【飞Q，飞书】
   • 大型商用软件：对性能，兼容，可靠，可移植，安全【微信，QQ】

测试用例的设计方法

基于需求的设计方法

需求是测试人员进行测试的依据，测试人员验证需求的合理性和正确性，无二义性。从需求当中提取出测试项，根据测试项进行进一步的细分，提取出测试点，编写测试用例

等价类

根据输入（特殊情况下才考虑输出），把输入划分成若干个等价类，从每一个等价类当中选择测试用例进行测试，如果这个测试用例通过，我们就说这个测试用例代表的等价类测试通过

等价类帮助我们解决测试用例无法穷举的情况

有效等价类：符合需求数据规格说明的数据集合
无效等价类：不符合需求规格说明的数据集合

边界值

错误猜测法

根据测试人员的经验，知识积累，猜测某一块可能有问题，有针对性地进行测试用例的编写
探索性测试，针对性较强，比较依赖测试人员个人水平

场景设计法

很多软件的不同场景是基于不同事件的触发，不同事件的触发导致场景走向不同的事件流，不同的功能点串起来形成一个场景，不同的功能点又有不同的输出，不同的输出导致不同的测试场景

• 需要有基本事件流和备用事件流

判定表

因果图

是一种逻辑图：恒等、与、或、非。用因果图来设计测试用例，叫做因果图法

场景：当我们有很多输入，不同的输入或者不同的输入组合针对有不同的输出，这个时候我们可以用因果图法来进行测试用例的设计

因果图设计测试用例步骤

1. 分析出所有的输入和输出
2. 找出输入和输出之间的关系
3. 根据关系画出因果图
4. 根据因果图画出判定表
5. 根据判定表写测试用例

正交排列（用的少）

从大量的实验中挑出适量的、有代表性的点，依据“正交表”从而合理的设计出测试用例
特性

• 每一列中，不同的数字出现的次数相等
• 任意两列中数字的排列方式齐全而且均衡

生成正交表步骤

1. 因素和水平数
   1.1.
2. 使用allparis生成正交表
   2.1.
3. 根据正交表编写测试用例
   3.1. 正交表中的case1，2，3，4，5，6 就是测试用例
4. 补充可能存在遗漏但是非常重要的测试用例
   4.1. 全部不填写姓名、电子邮箱、密码、确认密码、验证码