🔥艾莉丝努力练剑：个人主页
❄专栏传送门：《C语言》、《数据结构与算法》、C/C++干货分享&学习过程记录、Linux操作系统编程详解、笔试/面试常见算法：从基础到进阶
⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平
🎬艾莉丝的测试开发博客简介：
目录
[1 ·> 测试用例](#1 ·> 测试用例)
[1.1 测试用例的概念](#1.1 测试用例的概念)
[2 ·> 设计测试用例没有思路：万能公式会出手](#2 ·> 设计测试用例没有思路：万能公式会出手)
[2.1 常规思考&&逆向思维&&发散性思维](#2.1 常规思考&&逆向思维&&发散性思维)
[2.2 设计测试用例的万能公式](#2.2 设计测试用例的万能公式)
[2.2.1 万能公式](#2.2.1 万能公式)
[1 功能测试](#1 功能测试)
[2 界面测试](#2 界面测试)
[3 性能测试](#3 性能测试)
[4 兼容性测试](#4 兼容性测试)
[5 易用性测试](#5 易用性测试)
[6 安全测试](#6 安全测试)
[2.2.2 弱网测试](#2.2.2 弱网测试)
[2.2.3 安装卸载测试](#2.2.3 安装卸载测试)
[2.2.4 使用万能公式对水杯进行用例的设计](#2.2.4 使用万能公式对水杯进行用例的设计)
[2.2.5 万能公式记忆图](#2.2.5 万能公式记忆图)
1 ·> 测试用例
1.1 测试用例的概念
什么是测试用例？ 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例原则一：
测试用例中一个必需部分是对预期输出或结果进行定义。
什么是要素？我们在编写测试用例的时候，每个用例需要给出这些要素对应的信息。
为什么需要测试用例呢，不写测试用例可以进行测试吗？
测试中可能会遇到很多问题，诸如：
（1）不知道是否较全面的测试了所有功能；
（2）测试的覆盖率无法衡量；
（3）对新版本的重复测试很难实施（即回归测试无法仅通过人工测试的方式进行历史功能的回归）；
（4）存在大量冗余测试影响测试效率。
测试用例的出现就是解决这些问题。另外，测试用例的作用还可以避免测试人员被迫背锅。
实际中产品出现问题，第一责任任首先想到的是测试为啥没有测到？
上面展示的是传统的编写测试用例的方式，我们在学习敏捷模型的时候已经了解到，如今大多数企业采用的都是思维导图的方式来编写测试用例。以下课程内容包括日常用例练习都是用思维导图/脑图进行编写。
2 ·> 设计测试用例没有思路：万能公式会出手
现在我们假设有一款产品，要求我们测试人员对"门锁"设计测试用例，那么博主这里问一下大家，如果您是测试人员，您会怎么设计测试用例呢?
可以看出，用例的设计最重要的一点是保证功能是正确的。上图给出的案例，在互联网企业中，这样去设计测试用例的非常少，缺乏经验的同学往往以这样的思路去设计。
2.1 常规思考&&逆向思维&&发散性思维
正确设计测试用例的思想：常规思维+逆向思维+发散性思维
设计测试用例的原则二：
1、测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况；
2、检查程序是否"未做其应该做的"仅是成功的一半，测试的另一半是检查程序是否"做了其不应该做的"。（是上一条原则的必然结果）3、计划测试工作时不应默许假定不会发现错误。
我们明白了设计测试用例光是思维、脑袋里面想想还往往不够。
若仅仅通过头脑风暴去设计测试用例，那么当我们面对面试官时，能够想出来的用例是寥寥无几的，所以在设计测试用例的时候需要有思路的去设计。
打开思维后，设计测试用例是想到一条就说一条，如果没有正确的引导，说出来的测试用例一定是有限的且数量不容乐观，比如现在让大家直接说说，家里有哪些电器？一时间可能会说不上来，但是，如果给点提示，比如"厨房里的电器有什么？"、"客厅里的电器有什么？"、"卧室里的电器有什么？"、"卫生间里的电器有什么？"，如下图所示------
2.2 设计测试用例的万能公式
2.2.1 万能公式
设计测试用例的万能公式------
功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试。
1 功能测试
功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。功能测试通常是一项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。然而，不仅是工作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？
（1）查找其他相关文档，来帮助理解所要测试的产品需要完成的目标；
（2）尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解；
（3）召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了;
（4）如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理；
（5）也可以去看历史bug，可以了解到一些需要关注的东西。
2 界面测试
对软件界面上所有的内容都需要进行测试。
要求：
（1）整体界面测试界面的实现与设计图要求一致。
（2）界面元素测试
1）控件操作验证。
3 性能测试
性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。
4 兼容性测试
软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动
端打开；移动端又分为IOS系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不
同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。
**问题：**既然市面上有众多版本的机器，那么在执行兼容性测试时难道所有的机型都需要全面覆盖吗？
选取标准：
（1）优先选择使用当前产品top级别的机型进行测试，实际在企业中，后台是可以获取到使用产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考；
（2）选择主流的浏览器/机型进行测试。
5 易用性测试
易用性测试的标准是检查产品是否具备简单易上手的属性。假如测试人员从来没有安装或使用过
该产品，作为一个新用户，对当前产品是否能够快速适用产品的使用流程。
6 安全测试
安全测试和性能测试一样都是比较大的领域。常见的安全问题如：
隐私数据明文显示；
参数未强校验导致SQL注入；
越权：普通用户也可以执行管理员权限的操作。
接下来继续尝试对门锁进行测试用例的设计，你能设计多少呢？快去试试吧！
除了万能公式之外，还有一个比较常用的测试类型：弱网测试、安装卸载测试。
2.2.2 弱网测试
弱网测试的目的就是尽可能保证用户体验，关注的关键点包括------
（1）页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等；
（2）页面呈现是否完成一致；
（3）超时文案是否符合定义，异常信息是否显示正常；
（4）是否有超时重连；
（5）安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等；
（6）大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。
弱网需要借助工具来构造弱网，这里推荐使用fiddler------
1）fiddler配置代理；
2）fiddler进行抓包（桌面/移动端）；
3）fiddler如何构造弱网条件。
在fiddler构造弱网条件------
2.2.3 安装卸载测试
针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载。
比如在【设置】这里能够顺利地卸载应用------
2.2.4 使用万能公式对水杯进行用例的设计
我们这里以水杯的测试用例为例------
或者可以这样设计------
这就是万能公式的妙用！一下子思维就打开了！
2.2.5 万能公式记忆图
下期预告
下一篇文章，博主会详细介绍设计测试用例的方法，从基于需求的设计方法开始介绍，并且会详细介绍落实到具体的几种设计方法，包括【等价类】、【边界值】、【正交法】、【评定表法】、【场景法】以及【错误猜测法】，然后我们会再来进行更多的用例测试------【命令行程序】（zip命令）、【web程序】，博主会借助【web程序】板块中的例子"博客系统"的博客详情页接口测试用例设计来引入一个常见的接口测试工具postman，并且会详细介绍postman的具体使用。
结尾
往期回顾：
**结尾：**本期我们学习了测试开发/测试内容中的用例篇，希望对学习测试开发/测试相关内容的uu有所帮助，不要忘记给博主"一键四连"哦！
🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡૮₍ ˶ ˊ ᴥ ˋ˶₎ა
