一、测试用例基本概念

1.1 测试用例基本要素

1. 基本要素：测试环境、操作步骤、测试数据、预期结果等
   • 不是说就上面这四个，只是说只知道这几个也行
2. 测试用例的用处：
   • 可作为测试执行者的依据辅助测试
   • 可作为自动化测试的基础，把重复的工作简化
   • 评估需求覆盖率：
     • 覆盖率：用来计算测试的代码范围
       • 计算公式：测试的代码行数/没有测试的代码行数
       • 可由工具辅助计算
   • 用例的复用：当要更新一个软件时(由v1变为v2)，在git操作上，我们会在v1基础上创建一个dev分支，然后在该分支上迭代其为v2代码，最后合并到master分支上。对于测试用例而言，我们需要写v2新功能的测试用例，至于v1的老功能可以复用v1时的测试用例
     • 为什么还需要测试v1的代码：因为我们无法保证开发人员在开发v2时，没有更改v1的代码，或者说新功能不会影响到老功能

二、测试用例的设计方法

这些设计方法都是针对【黑盒测试】的

2.1 基于需求的设计方法

1. 根据需求来设计测试用例：设计出来的测试用例只是大概的，测试出来的软件也是不完善的。但不可以没有，因为它相当于是测试软件的思路，如果直接用什么等价类、边界值这种具体设计测试用例的方法，只会让人觉得很没有逻辑
   

2.2 等价类

1. 分类：等价类主要分为【有效等价类】和【无效等价类】
   • 有效等价类：满足用户需求的数据集合，使用这些数据，程序不会报错
   • 无效等价类：不满足用户需求的数据集合，使用这些数据，程序会报错
2. 如何通过等价类设计测试用例：
   • 充分理解需求
   • 将需求划分为【有效等价类】和【无效等价类】
   • 分别从【有效等价类】和【无效等价类】中抽取一个测试用例进行测试，只要被抽取的那个测试用例能够通过，则认为所代表的等价类测试通过
     • 理解：吃东西我们只要吃一口，就可以判断这道菜好不好吃了。此时，那一口就是被提出来的测试用例，整道菜就是该测试用例代表的等价类
   • 组合有效等价类和无效等价类
     • 组合规则：
       • 有效等价类：一条测试用例尽可能的覆盖所有有效等价类
       • 无效等价类：一条无效等价类与其他的有效等价类
3. 好处：可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题
4. 案例：

2.3 边界值

1. 场景：因为边界情况很容易出bug，所以我们要多测试
2. 上点、离点、内点：
   • 上点：对于开区间、闭区间、半开半闭区间来说，上点都是边界上的点
   • 离点：对于开区间、闭区间、半开半闭区间来说，离点都是边界内的点
   • 内点：边界左右的一个点，如果是闭区间，离点是范围外的点；如果是开区间，离点就是范围内的点
     
3. 使用边界值法设计测试用例：
   • 充分理解需求
   • 找上点、内点、离点
   • 针对上面这三点，结合等价类法去设计测试用例
4. 案例：
   

2.4 错误猜测法

1. 什么是“错误猜测法”：这个方法基本靠测试经验，测试人员根据经验猜测大概哪种情况下容易出错
2. 缺点：难以系统化，并且过度依赖个人能力

2.6 场景设计法

1. 如何利用场景设计法设计测试用例：
   • 定位主事件流：主事件流就是用户经常操作的步骤、行为，是个大模块
   • 定位次事件流：主事件流里面，大都都会有很多意外
   • 将上述两个事件流串起来形成场景：此时一个场景就是一个测试用例
2. 案例：
   

2.7 因果图

1. 为什么会有因果法：输入的数据也是有逻辑关系的，如输入的两个条件必须要同时满足才能通过测试，我们可以根据这个逻辑，去设计测试用例

2. 因果图VS判定表法：因为因果图最终会转为判定表，所以这里干脆从【判定表】的部分讲，跳过中间部分，所以实际我们要学的其实是【判定表法】

3. 逻辑关系种类：

   • 恒等：条件为真，结果一定为真；条件为假，结果一定为假
   • 与：条件全为真，结果才为真
   • 或：条件全为假，结果才为假
   • 非：条件为假，结果才为真

4. 如何根据判定表法设计测试用例：

   • 充分理解需求
   • 分析所有可能的输入和输出
   • 找出输入和输出的对应关系
   • 判定表
   • 把判定表对应到每一个测试用例上

5. 案例：
   

6. 缺陷：如果输入和输出十分复杂，制作判定表就十分麻烦，此时我们可以借助【正交表法】进行优化

2.5 正交排列

1. 名词解析
   

2. 正交表性质：
   

3. 如何根据正交表法设计测试用例：通常是需要工具辅助我们生成一个正交表

   • 确定因素（变量）
   • 确定因素取值（水平）
   • 通过工具生成正交表
   • 将正交表转换成测试用例
   • 补充正交表

4. 案例：
   

三、综合：根据某个场景去设计测试用例（万能公式）

1. 设计思路：实际测试，我们不会专门去使用上面那些设计方法，而是使用【万能公式】
2. 万能公式：功能、界面、易用性、兼容性、安全性、性能、网络
   • 针对一个【物体】进行设计：
     • 功能：这个物体经常被用来干什么
     • 界面：物体的形状、颜色、大小……
     • 易用性：物体的设计符合人体工学
     • 兼容性：该物体除了本质功能，还可以做哪些事情
     • 安全性：物体不能对人的健康有损害
     • 性能：承受能力，如抗压力、耐热力、耐寒力等
   • 针对一个【软件】进行设计：

     • 功能：软件的基础功能(本职功能)是什么

     • 界面：界面的图片布局、图片大小、按钮颜色、文字字体……

     • 易用性：软件设计符合大众操作习惯，能让人操作流畅

       • 比如如果报警一般是红色日志，绿色一般表示通过，黄色则一般表示警告

     • 兼容性：软件可以在不同的平台去部署、运行

       • 兼容对软件十分重要，因为不同的用户会用不同的设备去使用该软件
       • 考虑到不同的设备（IOS、Android、PC）、以及对应的不同的版本(比如浏览器的版本、操作系统的版本……)
         • 苹果手机和苹果电脑的操作系统就是IOS，PC主要指电脑端，电脑的操作系统有Windows、Linux、Mac
       • 因为测试兼容多是重复性操作，所以我们可以用【自动化】来帮助我们提高测试的效率

     • 安全性：使用功能时，要防止黑客攻击，没有内存泄漏、SQL注入、xss漏洞等问题

       • xss漏洞：如果在输入框输入< script>代码< /script>，如果存在xss漏洞，程序就会执行里面的代码，如果代码涉及金钱，就会十分危险。如果没有，则是正常显示这段话
       • SQL注入：主要是字符串拼接问题，如数据库代码是select * from list where id = 10 or 1 = 1， 但是输入框输入的是xxx or 1 = 1，此时会搜出全部的数据

     • 性能：吞吐量(软件能够同时间承载多少个用户访问)、响应时间(软件渲染页面所需的时间)……
       

     • 网络：在不同网速下能否正常运行

3. 设计水杯的测试用例：利用万能公式有逻辑地求解，而不是想到什么测试点就说什么，每个部分至少能说出3,4个点
   • 注意：如果是大需求，就把其拆为小需求求解：如果是小需求直接用万能公式
     • 功能：能泡茶、能加热水、能保温、容量为500ml……
     • 兼容：能装酒、能装化学物质、能装饮料……
     • 易用性：便于携带、拿着舒服符合人体工学、水杯重量适中……
     • 安全：水杯的材质不会与水发生化学反应，从而产生有毒物质、杯盖足够紧，加热水时不会漏液……
     • 界面：水杯上的图案美观、图案不会褪色、容量刻度线明显……
     • 性能：防摔、防爆、保温效果好……
4. 设计【微信发布朋友圈】的测试用例：
   • 功能：能发送文本(再细分：能发送纯汉字、能发送纯英文、能结合、如果发送的文本过长超过了100字符，会有提示……)、能发送图片（支持发送9张及以内的图片、如果已经选中了9张图片不能再选中第10张、图片顺序能够调整……）、能发送视频、能进行分享操作……
   • 兼容：对于平板来说，无论是IOS还是Android都能发送(包含了各个版本)、对于PC电脑来说Windows和Mac不能发送朋友圈……
   • 易用性：软件操作流畅、软件操作简单
   • 安全：会自动过滤敏感词、防止SQL注入、防止xss漏洞、防止黑客攻击……
   • 界面：朋友圈页面布局好看、小部件符合大众习惯……
   • 性能：图片渲染时间短、支持大量用户同时发送朋友圈……

四、如何使用Fidder操作网络(测网速)

1. 概念：Fidder和Charles可以用来控制网络，实现测网速等操作
2. 方法：
   
   

五、测试接口

1. 测试方式：可以使用代码测试，也可以使用可视化工具postman测试
2. 测试方向：
   • 针对接口方法测试：post、get、put、delete……(注，get方法里不能用post)
   • 针对参数测试：选取符合要求和不符合要求的参数，分别进行测试，如参数的个数、参数为空……
   • 针对业务测试：根据返回结果，判断业务是否正确