今天和大家聊一聊关于如何设计测试用例，以及如何提高测试用例的覆盖度？

 

首先，写测试用例几乎是每一个测试工程师，无论你是功能测试还是自动化测试乃至测试开发工程师入行首先就要掌握的技能，也是很多测试工程师的日常工作。

 

可能你看过不少设计测试用例的网课或者帖子，一堆测试用例方法让人一脸懵逼。比如等价类划分法、边界值分析法、场景法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法......

 

但是从应付日常工作来讲，真正具有实用价值并且常用的只有前三种方法等价类划分法，边界值法以及场景法。边界值法和等价类划分法通常配合使用，等价类划分又分为有效等价类和无效等价类，下面举例来讲一下这三种方法：

 

以一个登录功能账号输入为例，要求只能输入字母，数字和下划线 ,位数要求6到19位。

 

首先，先说下有效等价类。拿到这个需求你不可能拿6到19位之间的位数去穷举，那是无穷无尽的。运用等价类的划分的思想我们就可以取6位，19位，7位，18位，同时还可以取一个中间位12位更具代表性。然后确定位数之后，就可以设计用例了，字母，数字，下划线，分别排列组合分散开即可。

 

再说下无效等价类，就是不满足条件的取5位和20位去验证即可。除此之外还要考虑输入为空以及非法字符这两种情况。

 

边界值法这个比较简单就是取边界去验证，以及验证这个边界附近的数据即可。场景法就是需要考虑到各种各样的场景，比如该账号未注册就去登录，以及各种异常场景都需要考虑。一般，写好测试用例，都会开案例评审会议，就是防止场景遗漏。

 

当然设计测试用例的方法就那么几种，但是不同水平的测试工程师设计出来的用例覆盖度有很大差别。就好比大家把数学公式都掌握了，但是具体到解题考试，不同人千差万别。

 

下面以一道大家经常遇到的面试题为例，如何设计用户登录功能的测试用例？看到这里，你可能会说这也太初级了吧，先别急，等把下面的文章看完再说......

 

如果你是一个刚入行没多久的初级测试，你可能设计出下面的测试用例：

 

1. 输入已注册的用户名和正确的密码，验证是否登录成功。

    

2. 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确。

    

3. 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确。

    

4. 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确。

    

5. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确。

    

6. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功。

    

7. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。

 

列出这些测试用例后，你可能已经觉得比较满意了，因为你感觉已经把自己的测试知识都用在这些用例设计中了。然而仔细思考一下，这些用例真的覆盖到所有场景了吗？

 

接下来，再看一下，一个有经验的中级工程师还会增加哪些场景呢？

 

1. 用户名和密码是否大小写敏感。

    

2. 页面上的密码框是否加密显示。

    

3. 后台系统创建的用户第一次登录成功时，是否提示修改密码。

    

4. 忘记用户名和忘记密码的功能是否可用。

    

5. 前端页面是否根据设计要求限制用户名和密码长度。

    

6. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用。

    

7. 刷新页面是否会刷新验证码。

    

8. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性。

    

9. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面。

 

看到这里，惊不惊喜，意不意外，没想到一个很简单的用户登录居然还能设计出这么多用例，原来自己开始想的，还有那么多场景遗漏。还有更刺激的请接着看，上面那些用例主要从功能层面进行考虑，安全考虑了吗？兼容性考虑了吗？性能考虑了吗？

 

接下来就是看大佬之所以成为大佬，凭什么他可以定级高级资深测试工程师，每月二三十k的原因......

  

安全角度考虑测试用例：

 

 

1. 用户密码后台存储是否加密。

    

2. 用户密码在网络传输过程中是否加密。

    

3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码，

    

4. 密码输入框是否不支持复制和粘贴。

    

5. 密码输入框内输入的密码是否都可以在页面源码模式下被查看。

    

6. 用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面。

    

7. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期。

    

8. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

    

    

性能压力测试角度考虑测试用例：

 

 

1. 单用户登录的响应时间是否小于 3 秒。

    

2. 单用户登录时，后台请求数量是否过多。

    

3.  高并发场景下用户登录的响应时间是否小于 5 秒。

    

4. 高并发场景下服务端的监控指标是否符合预期。

    

5. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

 

 

兼容性角度考虑测试用例：

 

 

1. 不同浏览器下，验证登录页面的显示以及功能正确性。

    

2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性。

    

3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性。

    

4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

   

看到这里，你还会觉得“用户登录”功能的测试非常简单、不值一提么？下次，面试的时候你如果从这些方面去回答，还怕拿不到offer吗？

 

当然这些都是需要经验积累的，但是并不妨碍我们在设计测试用例的时候可以从多个角度进行考虑，比如安全，性能，兼容性等等。那么，日积月累，从小牛进阶成为大牛便是指日可待了！