【软件测试】设计测试用例

本文主要是介绍【软件测试】设计测试用例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

📕引言

本文章重点目标：

测试用例的概念

设计测试用例的万能思路

设计测试用例的方法

◦ 基于需求的设计方法
◦ 具体的设计方法

▪ 等价类 ▪ 边界值 ▪ 判定表法 ▪ 正交法 ▪ 场景法 ▪ 错误猜测法

🍀测试用例

🚩概念

什么是测试用例？

测试用例（TestCase）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

在很早之前，通过excel表格来编写测试用例，现在用的比较少，现在使用脑图或者思维导图。

注意：笔试的时候编写测试用例题，使用excel表格（会涉及到测试用例的要素）的方式来答题，而面试的时候回答测试用例题（不会涉及到测试用例的要素），按照思维导图的方式一一道来即可。

使用思维导图（现在工作中和面试的时候）：

🚩设计测试用例的万能公式

案例：给门锁设计测试用例

可以看出，用例的设计最重要的一点是保证功能是正确的。上图给出的案例，能设计出来的测试用例整体上来说数量是合格的，但是说出来的测试用例不够具体，在笼统了，无法作为测试工作的参考依据，在互联网企业中，这样去设计测试用例的非常少，缺乏经验的同学往往以这样的思路去设计。

🏀常规思考+逆向思维+发散性思维

正确设计测试用例的思想：常规思维+逆向思维+发散性思维

设计测试用例的原则二：

1.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。

2.检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”。（是上一条原则的必然结果）

3.计划测试工作时不应默许假定不会发现错误。

明白了设计测试用例是思维的正确还往往不够。

若仅仅通过头脑风暴去设计测试用例，那么当我们面对面试官时，能够想出来的用例是寥寥无几的，所以在设计测试用例的时候需要有思路的去设计。

比如突然让你说出家里的电器，你可能说出电冰箱，电视机，空调......脑袋突然就想不起来了，明明家里的电器很多，但怎么就想不起来，如果有了引导（厨房的电器，客厅的电器，卧室的电器）

🏀万能公式

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

简单了解各个公式：

各个公式的具体说明：

功能测试

功能测试是⼀个试图发现程序与其外部规格说明之间存在不⼀致的过程。外部规格说明是⼀份从最终用户的角度对程序行为的精确描述。功能测试通常是一项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。然而，不仅是工作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？

◦ 查找其他相关文档，来帮助理解所要测试的产品需要完成的目标;

◦ 尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解;

◦ 召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了;

◦ 如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理;

◦ 也可以去看历史bug，可以了解到一些需要关注的东西。

界面测试

对软件界⾯上所有的内容都需要进⾏测试。

要求：

◦ 整体界面测试界面的实现与设计图要求一致。

◦ 界面元素测试

▪ 控件操作验证

性能测试

性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。

兼容性测试

软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动端打开；移动端又分为IOS系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。

问题:既然市面上有众多版本的机器,那么在执行兼容性测试时难道所有的机型都需要全面覆盖吗？

选取标准：

• 优先选择使⽤当前产品top级别的机型进⾏测试实际在企业中，后台是可以获取到使⽤产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考。

• 选择主流的浏览器/机型进行测试

易用性测试

易用性测试的标准是检查产品是否具备简单易上手的属性。假如测试人员从来没有安装或使用过该产品，作为一个新用户，对当前产品是否能够快速适用产品的使用流程。

安全测试

安全测试和性能测试一样都是比较大的领域。常见的安全问题如：

• 隐私数据明文显示。

• 参数未强校验导致SQL注入。

• 越权：普通用户也可以执行管理员权限的操作。

接下来针对水杯进行测试：

除了万能公式之外，还有一个比较常用的测试类型：弱网测试、安装卸载测试

弱网测试

弱网测试的目的就是尽可能保证用户体验，关注的关键点包括:(为了覆盖更多的网络景,wifi,2G,3G)

• 页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。

• 页面呈现是否完成一致。

• 超时文案是否符合定义，异常信息是否显示正常。

• 是否有超时重连。

• 安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。

• 大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

如何进行弱网测试：弱网需要借助工具来构造弱网，这里推荐使用fiddler

1）fiddler配置代理

2）fiddler进行抓包（桌面/移动端）

3）fiddler如何构造弱网条件

首先，当前电脑连上的是手机热点（5G），此时访问一个网站时速度是非常快的。接下来通过Fiddler设置弱网来访问某个网站。

1.打开弱网设置选项（勾选上）

2.打开设置弱网脚本

3.打开弱网设置（crtl+F进行查找）当打开设置的时候，此时的if条件为真，就会执行if里面的代码; 代码一:上行速率,指客户端发送请求给服务器传输1KB需要多少毫秒,设置数值越大传输速率越慢代码二:下行速率,指服务器返回给客户端传输1KB需要多少毫秒,设置数值越大传输速率越慢

安装卸载测试

针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载，一般用于移动软件和客户端软件

注意：在面试和笔试中设计出来的测试用例一定要越多越好，在工作中则不一定，要求测试用例的质量高，用较少的用例覆盖更多的功能。

🎄设计测试用例的方法

🚩基于需求的设计方法

基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。

测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。

以该注册邮箱账号需求为例，我们来设计测试用例。

基本事件流：也就是通用流程，绝大多数用户的操作流程/主流程

扩展事件流：可能出现的流程

🏀明确需求中的功能点

账号注册，账号登陆

🏀结合万能公式设计测试点

🚩具体设计方法

上面根据需求文档先设计初步的测试用例，而部分用例还需要细化，就需要借助具体的设计方法。

🏀等价类

上述设计的测试用例用例，存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样一个具体的需求该如何来设计测试用例呢？

测试的时候通过穷举法来测试6位、7位、8位......14位，15位是否测试通过，这样的方法能够满足测试的要求吗？这只是测试了软件是否做了其应该做的，还要测试是否其做了不应该做的，例如小于6的和大于15是否都要测试？试想一下这样一个简单的测试点需要测试多久呢，显示是不符合企业测试要求的。

而等价类法的出现就解决了穷举法不能解决的问题

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

借组等价类：有一个等价类，里面有很多数据，从里面选一个数据进行测试，若这个测试通过，则代表等价类中的数据集全部通过。

等价类分类：

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。（例如上述的6-15位）
无效等价类：根据需求说明书，不满足需求的集合。（例如小于6和大于15的）

根据等价类设计测试用例的方式：

1.确定有效等价类和无效等价类（有效等价类:6~15,无效等价类：小于6和大于15）

2.编写测试用例，设计具体测试数据

例如：

缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

🏀边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界值包含：边界值+次边界值

边界值即给定范围的左数据与右数据
选择次边界值的时候需要根据边界值的有效无效情况来定： 1）若边界值为有效等价类中的数据，则次边界值为无效等价类中的边界 2）若边界值为无效等价类中的数据，则次边界值为有效等价类中的边界

上述的边界值：6 15 ；次边界值：5 16；

继续将上述用例通过边界值补充完整：

🏀

🏀场景法

现在的软件几乎都是用事件触发来控制流程的(比如步骤一走完才触发步骤二，步骤二走完才会触发步骤三),事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型（一般不关注）：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

读完上面的概念是不是一脸懵，场景法就是一个常规的流程中，某些阶段可能会出现一些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法比较考验同学们的发散思维。

以逛街买衣服为例，讲讲场景法的使用方法：