【软件测试】—— 测试用例篇

目录

0️⃣测试用例的基本要素

1️⃣为什么要设计测试用例

2️⃣测试用例的设计方法

基于需求进行测试用例的设计

功能需求测试分析

非功能需求测试分析

具体的设计方法

等价类

边界值 

错误猜测法

场景设计法

因果图 

正交排列

什么样的测试用例是一个好的测试用例？

3️⃣什么是测试用例的有效性？

4️⃣测试用例的粒度和评价

面试案例

---

0️⃣测试用例的基本要素

回顾测试用例的概念：

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

评价测试用例的标准：对比好坏用例的评价标准

• 用例表达清楚，无二义性；
• 用例可操作性强；
• 用例的输入与输出明确，一条用例只有一个预期结果；
• 用例的可维护性好；
• 用例对需求的覆盖率高；

---

1️⃣为什么要设计测试用例

1. 测试执行者的依据
2. 使得工作可重复，自动化测试的基础
3. 评估需求覆盖率
4. 测试用例有复用性（回归测试）
5. 积累测试的方法思路以供后续借鉴

• 使用中带来困扰：
  测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
• 解决如下问题：
  不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率

---

2️⃣测试用例的设计方法

基于需求进行测试用例的设计

       基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。

       在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；

在分析测试需求时，一般分为功能测试需求和非功能测试需求

功能需求测试分析

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面：

1. 系统各个功能界面的验证（从上到下，从左到右）
2. 借助业务把功能串起来进行测试（场景法）
3. 功能的一致性，交互性（多功能互操作）的测试
4. 系统的不同输入，结果输出的业务数据测试
5. 功能的错误操作，异常操作的测试（属于负面测试）
6. 功能实现用到的算法验证，有时需要用运代码评审（白盒测试）
7. 用户操作的易用性，用户体验，往往结合功能测试同时验证

下面以我们常用的百度云盘手机端为例进行分析功能：

非功能需求测试分析

       非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战；

       这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析；

1. 纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
2. 企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
3. 外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

具体的设计方法

等价类

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

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能；
• 无效等价类：根据需求说明书，不满足需求的集合；

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

超市买蔬菜
有效等价类：白菜，萝卜，辣椒
无效等价类：苹果、大米、面包，...

边界值 

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

案例： 

1. 输入框长度为1~12，取边界值为：0，1，12，13
2. 查询面页面有999行，每50行为一页，取边界值为：0行、1行、50行、51行、999行

错误猜测法

       错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

       错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

这个方法的缺点是难以系统化，并且过度依赖个人能力。
以注册为案例：

1. 校验中特殊字符空格的处理?
2. 密码校验中的大小写？
3. 姓名中的特殊字符？
4. 密码发送是否明文？

场景设计法

       把一个个孤立的功能串起来形成一个场景，每一个功能不同的输入会触发流程走向不同的场景，根据这些不同功能的不同输入触发形成的场景进行测试用例的设计；提取出场景中涉及的功能点，考虑每一个功能不同的输入；

ATM取款流程案例：

插卡 —— 输入密码 —— 输入取款金额，取钱 —— 退卡

因果图 

       因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

因果图的几种关系：

因果图法设计测试用例的步骤如下：

1. 分析所有可能的输入和可能的输出；
2. 找出输入与输出之间的对应关系；
3. 画出因果图；
4. 把因果图转换成判定表；
5. 把判定表对应到每一个测试用例；

正交排列

因果法设计用例太多怎么办？
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合；
根据正交性，从大量的实验数据中，选取最优的组合，根据最优的数据组合的结果来衡量整个测试的输出结果；

---

什么样的测试用例是一个好的测试用例？

3️⃣什么是测试用例的有效性？

1. 测试用例对应的功能已删除，不可操作了；

微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息；

2. 执行一条测试用例未发现BUG，实际该处有BUG

苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁；

3. 执行一条测试用例发现了BUG

苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现；

4. 执行一条测试用例未发现BUG，实际该处BUG已修改

苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁；

---

4️⃣测试用例的粒度和评价

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

粒度：指测试用例编写的详细程度；

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。
(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

但是不管用例怎么简化，都不应该省略

面试案例

某公司招聘测试工程师时，有一道这样的笔试题：”某手机软件有用TF卡导出数据的功能，请写出测试此功能点的思路”