测试用例的设计方法和思路分析

作为新手入门，很多同学最顾虑的问题相信都是不知道如何开始书写测试用例，担心测试用例书写的不全面，不完整，生怕漏下的某一点非常重要，造成了自己在接下来的测试工作中存在隐患；

但迟迟不敢下手写测试用例的话，又担心影响整体的测试计划因为自己的延误而受影响。这种前怕狼后怕虎的心态，我相信所有刚刚开始做测试工作的人都有过。

在这里先给大家几点意见，首先，针对测试用例的书写，不管你能想到哪些方面，先把它写出来，不管想法如何，写出来的才是测试用例。

其次不要顾虑自己的用例好或者不好，因为测试用例执行之前，不管是刚入职的员工还是老员工，都需要参加用例评审的过程，在这个过程中，测试用例中的问题就被发现，同时也会给到每个人修改意见。所以，大家要安下心来写出自己想到的测试用例，这样才能帮助发现问题从而更好地解决。

再有就是，不管老员工还是新人小白，都是需要用例评审的，那就是说每个人的测试用例都不能说完美全面，都是在不断地评审过程中尽量的做到全面一些，覆盖率高一些。不过老员工毕竟经验和阅历要比小白多，所以在写测试用例的过程中，肯定有一套合适的方法。

接下来，我就以具体的场景分析方法给大家分享一下干货，让所有测试的“巧妇”有米为炊。

登录场景原始需求：

• 普通的登录页面，页面上有两个文本输入框，一个输入账户名；

• 一个输入密码（账号框展示输入的账号，密码框以黑色圆点显示）。

• 在两个文本框下方有两个按钮，一个是“登录”按钮。

• 输入一个已经注册成功的账户名+密码组合，点击登录按钮，登录成功后跳转到个人信息页面。

• 另一个是修改密码按钮，点击之后跳转到修改密码页面，修改之后需要使用新密码登录，原密码登录提示错误。（默认有一个账号已经注册成功，使用该账号进行登录；同时准备一个注销掉的账户，用来进行测试）

需求分析：

（1）作为一个原始需求的功能点，这个模块是比较简单的，首先来说，这是一个单一的模块，不存在功能交互的测试点。其次，页面UI比较简单，而且没有特殊的规范，只需要在查看的时候页面正常展示就可以。

（2）既然单个模块需要测试的比较少，我们的重点就要放在页面的输入框、按钮以及账号和密码的输入上来。

先停顿一下，自己想想能想到什么？

• 账户名和密码输入错误，能登录成功吗？

• 账户名或密码输入错误，能登录成功吗？

• 账号的中文或者英文名称都可以吗？

以上我相信大家都可以想得出来，但是这些远远不够，那么接下来，装米的容器先奉上。我习惯把场景中的测试点分为三种场景。

1. 常规场景

就是像刚刚几条，大家按照业务流程（即需求文档中描述的）或者生活经验都可以写得出来的测试用例，我把他定义为常规场景。

2. 偶然场景

偶然场景我分为了两种，一种叫做偶见型场景，另一种成为挑刺型场景。

• 偶见型场景

      是指生活经验中也可以见到，但是使用频率很低，甚至不使用，但是经过评审过程中的话，是可以考虑得到并能独立完成书写的场景

• 挑刺型场景

      与功能点要求的操作相反或者干脆背道而驰，有点儿像“鸡蛋里面挑骨头”的场景。

3. 专业场景

需要考虑到专业性，包括编程思想，数据库专业知识作为支撑才能掌握的测试用例场景。

OK，接下来我们开始看米了！

  

   针对原始需求的分析，登录场景中的常规场景总结了以下几条：

1. 输入账户名和密码，账户名正确，密码错误，点击登录，登录失败；

2. 输入账户名和密码，账户名错误，密码错误，点击登录，登录失败；

3. 输入账户名和密码，账户名错误，密码正确，点击登录，登录失败；

4. 输入账户名和密码，账户名正确，密码正确，点击登录，登录成功；

5. 输入账户名和密码，账户名或者密码输入中文，点击登录，登录情况;

6. 输入账户名和密码，英文名称输入大小写，点击登录，登录情况。

   2.偶然场景

（1）.偶见型场景

   a.打开登录页面，查看登录页面展示正常，有无乱码现象；

   b.点击登录之后跳转到个人信息页面，查看个人信息与页面展示是否一致；

   c.账户修改密码后，输入新密码登录，登录情况；

   d.账户修改密码后，输入旧密码登录，登录情况。

（2）.挑刺型场景

   a.不输入账户名和密码，点击登录按钮，查看登录情况；

   b.不输入账户名或密码，点击登录按钮，查看登录情况；

   c.在文本输入框中输入特殊符号，点击登录，查看登录情况。

   3.专业场景

（1）.输入超长的账户名或者密码；

      文本框中传递参数如果选择固定位数传递的话，可能会存在登录失败的情况。如果你的用户名是八位，结果你输入了十位；这个时候如果文本框取到用户名的过程中只取了前八位，那么可以登录成功，但如果取到了十位，就可能会报错。

（2）.账户名和密码输入“’or 1 = 1--”；

     Oracle数据库曾经出现过的bug，是一个万能的账户，所以需要开发刻意写一个检查方法避免这个问题。

（3）.输入一个注销的账户名和密码组合，点击登录，查看登录情况。

     如果账户注销，他的状态在数据库中和正常的账户是不一样的，在点击登录之后，系统会给出对应的提示才好。

针对于以上这些场景分析，尤其是专业场景这几条，理解起来肯定有困难，所以，要求大家看到之后就可以整理下来。其余的场景分析希望能够在以后给大家带来一定的帮助。

　1、根据需求文档，完全按照需求文档框架/功能描述，根据自己的理解整理为用例。简单来说，就是将需求文档描述的内容，重新按照用例的格式编辑一次，把能想到的各种可能性添加进去。

　　2、搜索其他测试人员编写的同类型功能用例，先理解，再根据项目实际需求的较小差异，重新新增/删/改，组成满足需求的用例组。

　　快速掌握用例其实没有什么窍门，只有多看，多想，多写，多评审。

本文以最常见的几种测试场景来展开讨论如何设计出更为高效且覆盖面更为全的测试用例。

在讨论前，我们先来大概了解下目前行业里常用到的几种测试用例的设计方法，目前主流的测试用例设计方法有如下几种

1 主流测试用例常用设计方法

1.1 等价类划分法

此设计方法算是黑盒测试中用得最多的一个了，而且此方法常常与其他方法一起来设计测试用例，常用的组合就是与边界值划分法；

定义：等价类划分法是把所有可能输入的数据划分成若干部分，然后从每一个部分选取少数具有代表性的数据作为测试用例。

划分标准：

1. 完整性，即被划分的各个部分测试数据共同组成了所有可能输入的数据。

2. 排他性，即每个部分的测试数据原则上来说，不应该有重叠部分。

划分方法：

1. 在输入条件规定了取值范围或值的个数的情况下，则可以划分为一个有效等价类和二个无效等价类

2. 在输入条件规定了输入值的集合或规定了必须如何的条件下，则可划分为一个有效等价类和一个无效等价类

3. 在输入条件是一个布尔量的情况下，可划分为一个有效等价类和一个无效等价类

4. 在规定了输入数据必须遵守的规则情况下，可划分为一个有效等价类和若干个无效等价类（从不同角度违反规则）

5. 在规定了输入数据为一组值，每个值分别处理不同情况，则可确定n个有效等价类和一个无效等价类

6. 假如在已经确认已划分的等价类中各元素在程序处理中的方式不同情况下，则需将该等价类进一步的划分为更小的等价类

1.2 边界值分析法

        此方法根据也是特别常用的一种设计方法了，写过代码或者有丰富测试经验的同学应该知道，代码中的判断逻辑是非常多的，越是复杂的业务流程，判断逻辑就越多。就算有丰富经验的开发者，在进行判断逻辑代码的时候也会有所疏忽，尤其是哪些欠缺开发经验的同学来说，就更容易忽略某些边界问题了。

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

      分析：大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

1.3 场景分析法（流程图法）

        随着系统功能越来越多，业务越来越复杂，这时候为了更好的进行测试，确保所有业务流程都能被覆盖测试到，这时候引入场景分析法就非常有必要了。

       定义：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

1.4 经验推断法

        随着测试人员对系统的不断熟悉，对业务的理解不断加深，对程序员的不断了解，有时候就可以有针对性的去验证是否存在某个问题。

1.5 因果图法

        等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

1.6 正交表（不常用）

不常用但是要知道设计原理

 常用正交设计表-举例

案例：字符属性设置程序
窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值

• 字体：仿宋、楷体、华文彩云

• 字符样式：粗体、斜体、下划线

• 颜色：红色、绿色、蓝色

• 字号：20号、30号、40号

步骤：
1、根据控件和取值数选择一个合适的正交表；

根据分析可知，该案例有4个控件，每个控件有3个取值。所以我们可以组合3^4 = 81个组合，那么在常用的正交表中，我们可以选择此表，那么本来要81个组合测试才能测得完的用例，根据正交表设计法，只需要进行9次测试即可。所谓，使用最小的测试过程集合获得最大的测试覆盖率。

2、列举取值并编号，生成取值表；
接下来对控件和控件的取值进行排序，生成取值表：
 

3、把取值表与选择的正交表进行映射；
根据取值表和所选择的正交表进行编号 进行映射，生成以下的实际测试用例：

定义：因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

其他几种方法不常用，就不介绍了，如有需要再去学习了解即可。

2 设计思路概况

上面我们大概了解了下各个测试用例设计方法，接下来就开始以实际例子来说明如何更高效的设计测试用例了。

2.1 web登录页面的测试

         分析：首先我们可以分析一下，该界面都有哪些哪些元素，每个元素又具备哪些规则要求，是否有其他特殊化要求，比如缓存，加密等；分析完毕后，我们就可以根据了解到的去选择合适的测试用例设计方法，对这个页面进行用例的编写。

原型图：

需求：

1. 支持工号密码和APP端扫一扫登录

2. 支持缓存账号密码信息，下次免输入登录

3. 密码不论是前端还是缓存还是传输过程中，需要加密处理

4. 支持验证码图片点击更换

5. 支持登录界面不同语言显示，且有记忆上次更换功能

6. 其他的要求就如同所示

拿到上述需求和原型图后，我们就可以开始着手分析然后去设计测试用例了。

2.1.0 UI界面测试

       首先对于用户来说，对一个系统的评价，首先从界面视觉方面去判断，就好比男女之间的第一次见面，嗯，你想的没错，就是相亲，第一印象基本上是从个人长相，精神面貌来的，我们都知道第一印象很重要，尤其是在如今这个快节奏的社会；

       对于一个用户来说，界面的风格，人机交互性，易理解性，易操作性等将直接印象用户的第一使用体验，假如第一使用体验都不好了的话，假如该产品不是不可替代性的产品的话，用户很有可能就此流失掉，假如该系统是用户已经付费了的，虽然不好看的页面，难于操作的页面，难于理解的页面不会马上导致客户退货，但起码会使该用户产生一种一点都不专业的感觉，接下来用户很可能带着一种不愉快的心情去操作了，这就很有可能导致各种各样的刁难挑刺，最终导致彻底对该产品失去兴趣，要不就是打回要求重新调整，要不就是退回退款。

      大部分产品开发过程中，在前期需求确定及评审过程中就会这方面进行一定讨论研究，所以建议测试同学在需求阶段就要介入进去，从界面风格，人机交互性，易理解性，易操作性等几方面去进行审视，给出比较不错的建议。

      然后接下来就是对系统的业务功能进行测试了，业务分析了下，就是个登录功能，二种登录模式，其中工号登录页面上有三个输入框，一个下拉框，一个图片按钮，一个文字按钮，一个登录按钮；扫一扫登录页面就上面就一个二维码。

       根据一般的测试套路，我们先是进行基本的功能测试，只有基本的功能实现了，我们才有意义去进行其他方面的测试。

备注：扫一扫登录页面由于过于简单就不在此进行阐释了

2.1.1功能测试

        结合我们所掌握到该页面的相关需求知识以及我们后期拓展到的隐性需求（最好在需求阶段就提出来），提炼出我们所需要的测试点，然后再结合我们所掌握的测试用例设计方法进行测试用例的编写。

以下就是提炼出的测试点：

                   1.输入框的空值登录

                   2.输入框的空格测试

                           a.账号密码输入框前后中间有空格是否有过滤处理处理

                   3.有效账号密码等信息登录

                   4.无效账号密码信息登录

                                 a.正确账号，错误密码

                                 b.不存在的账号，A账号的密码

                                 c. A账号，B账号的密码

                  5.密码特殊要求测试 

                                a.在输入框内是否密文展示

                                b.是否可从外部复制到输入框

                                c.是否可从密码输入框复制密码出去

                                d.密码防破解机制验证

                                e.密码在传输过程中及日志信息中是否做了加密处理

                                f.密码在数据库表中是否以加密形式保存

                                g.密码信息是否会被浏览器所记住并保存    

                    6.验证码测试

                                a.输入正确的验证码登录

                                b.验证码输入框置空登录

                                c.输入错误的验证码登录

                                e.输入过时的验证码登录

                                f.图片刷新机制是否合理

                     7.账号密码记忆保存测试

                                a.正确账号密码登录成功后记忆保存

                                b.正确账号错误密码登录失败后是否只保存账号信息

                                c. 错误账号登录错误密码登录失败是否会保存

                                d. 正确账号，密码置空登录，是否会保存账号信息

                                f. 记忆保存有效时间验证

                                g. 手动清除缓存是是否仍然保留登录信息

                    8.同时登录测试

                                a.一个账号能否在同一浏览器上同时登录

                                b.一个账号能否在同一台机器上不同浏览器同时登录

                                c.一个账号能否在不同机器上同时登录

                                d.一个账号能否在web端和移动app端同时登录

                               e.二个账号能否在同一浏览器上同时登录

                               f.二个账号能否在同一台机器上不同浏览器同时登录

                   9.默认语言的记忆测试

                              a.修改界面语言选项，成功登陆后，下次登录是否会记忆上次保存的语言

                              b.修改界面语言选项，登录失败后，当前页面是否会保存修改的语言

                              c.修改界面语言选项，登录失败后，关闭浏览器，下次打开登录是否保存上次的语言选项

                   10.输入框长度限制测试

                   11.输入框可输入类型测试

2.1.2 友好及易操作性测试

     1.在输入框内能否使用windows常用快捷键，比如复制粘贴，tab切换，回车等

     2.在输入框内能否切换大小写，输入法，且切换后是否有相应提示

     3.网络异常时，是否有友好加载页面提示

     4.各种登录失败情况下的提示是否友好，清晰，易懂。

2.1.3 健壮性测试

      1.对浏览器程序进程杀死，重新打开浏览器，已输入的登录信息是否还在

      2.登录页面与其他页面页签之间的切换以及缩小到后台，已输入的登录信息是否还在

      3.假如快速多次点击登录按钮界面是否仍然正常显示及提示

      4.假如快速进行多次刷新操作，界面是否仍然显

2.1.4 安全测试

      1.账号密码框是否屏蔽SQL注入攻击

      2.账号密码输入框是否禁止脚本输入（避免XSS攻击）

      3.登录是否有防破解机制

      4.密码的缓存信息是保存在cookies中还是session中

      5.密码在任何场所是否都是加密形式展示的

2.1.5 性能测试

      1.打开登录页面所花的时间是否满足要求

      2.点击登录按钮进入到登录成功后的页面所花时间是否满足要求

      3.支持多少人同时正常打开，同时正常登录操作

2.1.6 兼容性测试

      1.主流的浏览器及各版本，是否很好的兼容该页面

      2.不同的操作平台及各版本是否正常使用

      3.不同屏幕分配率是否合理的显示该页面

     4.放大缩小状态下界面显示是否正常