一般需求评审后，开展测试执行前，我们需要对待测的需求进行分析，对技术方案进行评审，从而拆解出一个一个测试点，这里有测试重点，测试的深度，测试的广度，就像拨开重重迷雾一样，逐渐认清系统的真相，而测试用例就是承载测试点的一个很好具体的表现形式，那么面对一个新系统，我们又该如何进行用例设计呢？

对于一个新接手的系统，功能比较多，对于QA人员来说，就像一个黑盒，所谓的黑盒，就是对于盒子内部组件具体的组成不是很熟悉，比如表结构，代码结构等，如果这个盒子还比较大的话，这个时候就好封闭的盒子一样，既看到外部，看不到内部组成部分。

对于一个比较大的盒子来说，我们需要先了解盒子全貌，从盒子的不同角度的所具有的特性来拆分需要测试维度。

一种思路，基于行业里软件质量质量模型，从不同维度来衡量软件的质量，如下图所示，我们需要从8个维度去测试和评估软件的质量情况，一般我们关注的有：功能的适应性，效率，兼容性，可靠性，对于 易用性、安全性、可维护性、可移植性。

比如一个简单的只有用户名和密码的登陆页，我们的用例设计思路大概会从以下几个方面展开：

1. 功能

   a. 元素组件

      i.   用户名输入框：等价类、边界值..

      ii.  密码输入框：等价类、边界值..

   b. 业务逻辑

      i.   忘记密码

      ii.  登陆权限

      iii. 互踢逻辑

      iv. 不同角色

      v.  其他场景...

2. 性能

   a. 大量用户并发登陆

3. 兼容

   a. 不同厂商、不同操作系统，不同屏幕大小的设备测试

4. 可靠性

   a. 容错性

   b. 可用性

5. 可移植性

   a. 不同设备卸载、安装

6. 易用性

   a. 体验较好

7. 安全性

   a. 用户名/密码防暴力破解策略

   b. 用户/密码传输的安全性

可以看到，整体的思路是有了，我们从不同维度去覆盖这个需求，但是对于功能性测试、可靠性测试这两项似乎要设计的内容比较多，需要考虑更多的场景。

再来看一个例子，下面是一个PC端支持画笔在白板上进行书写的功能，画笔有粗有细，颜色可以切换。

参照质量模型，我们的设计思路大概类似这样：

     8. 功能

         a. 画笔持续书写

         b. 画笔粗细，切换粗细，书写笔迹粗细有变化

         c. 画笔颜色，切换颜色，书写颜色有变化

         d. 画笔数据，画笔数据保存功能

         e. 其他功能

     9. 性能

         a. 画笔的书写是否连贯，流畅

     10.兼容

         a. 不同设备，不同操作的系统的画笔是否兼容

     11.可靠性

         a. 网络环境较差，不稳定，画笔的数据是否有丢失

     12.可移植性

         a. 画笔是否需要安装在不同设备上

     13.易用性

         a. 画笔使用使用是否易用

     14.安全性

         a. 画笔的数据传输和保存是否需要考虑保密性

无论是登陆还是画笔，我们可以基于质量模型去设计每一块的用例，不至于有大维度上的缺失，但是，对于功能性的用例设计需要考虑内容仍然比较多，我们依然可以基于枚举的思路，一一列举出功能特性和业务逻辑，一般我们对系统的理解程度越高，一般我们枚举遗漏会更少，虽然不能保证每一个细节都能被枚举到，但是这样的思想可以让我们的设计思路更清晰，也整体Review我们的设计，这样每一个功能特性和业务逻辑，我们至少会有一条路径覆盖，不会造成较大的Case遗漏。

举一个例子，还是画笔功能，思路上可以做如下枚举：

书写特性：

• 粗细

• 大小

• 颜色

• 长短

• 重叠

• 连贯

擦除：

• 画笔痕迹擦除

业务逻辑：

• 数据记忆能力

• 数据关联关系

• 其他业务逻辑

所谓灰盒，是基于我们对系统内部了解程度来定的，我们了解的越多，系统对于我们越透明，对于用例的设计就会越方便，系统比较庞大的情况下，系统对于我们一般并不是完全透明的，而是一个灰度的状态，所以称为灰盒，如果我们能相对清楚的了解盒子内部主要逻辑，数据流动链路，那么我们对于盒子就会有更深的理解和认知，就可以结合不同分支(if... else..)的判定条件去枚举不同的路径了，慢慢会接近于白盒测试，测试覆盖也会更为全面。

随着需求的迭代，功能会越来越多，不再像之前仅仅几个功能，可能是十几个甚至几十功能，这个时候枚举单一功能还好，但是如果结合业务逻辑以及分支判定，可能就会有几百条组合路径，在这种情况下如何设计用例，以及如何执行这些用例都会是一个难题，这个时候，我们就需要一个更为抽象的模型来指导我们测试了，这个模型依然可以从枚举开始，枚举系统内不同的功能模块，每个功能模块，可以看作一个对象，基于面向对象的设计，每个对象有封装了自己的属性和行为，然后，基于用户业务逻辑，将不同功能用对应的行为动作组合起来，这样就组成一个由点(对象)和边(行为)组成的有向图，可以称为一个模型。

举一个例子：比如用户在App首页搜索->点击报名的功能，路径可以类似下面这样，每一个节点为结果状态，每一条边从一个状态到另一个状态的操作动作，这样就可以组成一个从一个状态到另一个状态的有向路径图

对于上面画笔的例子，将功能和擦除以及其他特性组合起来路径类似下面这样：

"穷尽测试"几乎是一件不可能的事情，而基于模型设计用例，可以为我们设计测试用例提供了清晰的参考，引导我们梳理出可靠的测试路径，随着AI的普及，这些测试路径将可以结合AI进一步细化生成更为细颗粒度的测试用例，结合测试覆盖率，我们的测试充分度将更高。