测试用例设计是测试活动中非常重要的一个环节，它和测试思维是紧密相关的。如何回答这个问题，才会更好地体现你的测试能力呢？笔者在面试中高级测试人员的时候，这个问题也是必问题。下面会根据我自己理解给出思考，欢迎交流。

测试用例设计的层次可以简单的分为以下三个层次：

基于页面：一问起测试用例设计，你能想到的第一个大概率是等价类、边界值，再多一点的可能会是正交表、判定表等等。这个是测试入门级的回答，这类思维更多的是基于某个页面或者输入框来说表达的。如果你在面试中高级的岗位时，这么回答，大概率是会被 PASS 掉的。因为你没有更多的思考。

例如，这个查询页面，根据等价类、边界值等，每个输入框架验证下是否能输出中文、正常的单号、超长或者超短的单号之类的，每个框都能写好多用例，然后点搜索，看能不能得出结果来，就完事了。这类的用例可以写多，但意义有限。

基于业务流：基于业务流程、数据流程来做测试用例的设计，一般会有场景法、状态机等方法，还有一些测试用例设计模型。如果你能想到这些方法，那么至少你对被测系统的业务架构和全链路的数据流转有一定的了解，知道关键节点在哪里，可以从更多的用户场景去考虑测试用例的设计，往往通过这类方法设计出来的测试用例，实用价值会是最高的，因为它更贴近用户的使用场景。

如上图，如果你能画出类似的业务流程图，有角色，有业务流，基本上代表了你对业务的了解程度，是会很受欢迎的。

基于技术架构：随着业务复杂度的提升和微服务的流行，只懂业务会比较吃力，因为有些场景通过业务并不好模拟，比如队列的堆积、缓存的失效、异步任务的准确性等，它需要你不但懂业务，还需要懂技术，能够在一些业务触摸不到的场景去做更多的思考。可以考虑、验证一些技术性的 BUG，这类 BUG 往往会在比较复杂的场景下才会触发，需要我们借助一些测试工具来模拟完成。

还是这张图，从技术架构的角度，你可以有的思考点是：这些数据是存放在哪里的？如果是数据库，那是从一张宽表里查的，还是从多张表聚合起来的，有没有索引。如果是 redis，那是用什么结构存储的，会不会有性能问题，什么时候做持久化。这些看着像交易的数据，也有可能是放在 ES 上的，那么对应的 index 是怎么样的，是否会产生跨 index 查询等等。这些从业务视角比较难覆盖到。

在面试的过程中，当面试官问到这个问题的时候，往往考察的就是你的测试思维以及对业务的熟悉程度。如果你不能从业务层次把用例设计的思路讲清楚，是件比较危险的事。很多测试人员喜欢写很多基于页面的测试用例，用例数量看起来非常可观，执行的时候每天的执行数也很好看。但是对业务的价值到底有多少，是值得管理者去思考的。当然，这并不是说这类用例不重要，但是整体的占比不应该过多。

在很多次的面试过程中，候选人无法清晰地描述被测系统的业务流程是什么样子的，更别提技术架构，这样的测试思维很难匹配中高级测试的岗位要求。熟悉系统并不是说你对某个功能点或者某个页面很熟悉，而需要对系统整体有个感知，知道对被测系统而言，什么是核心功能，什么是辅助功能，哪些业务是不能出错的，哪些业务与同边哪些系统有千丝万缕的联系。这将有助于你在测试执行过程中做好测试执行优先级的排序。

作为面试官，根据个人的经验，最好不要问诸如如何测试电梯、杯子、笔、桌子、洗衣机这样的问题了，这类问题的答案都烂大街了，候选人回答得好，你也看不出他的测试思维，因为完全有可能是背出来的。回答得不好，也不能太说什么问题，因为你的需求就非常不明确，比如，杯子的可用性，很多网上的资料里，会提到杯子是否会烫手，个人就觉得会烫手是个很好的可用性，因为烫手远远好过于烫嘴（烫手是不烫手了，你喝下去，它烫嘴啊，水的温度并不会因为杯子的可用性而降低）！烫手你马上可以感知，然后缩手，烫嘴你试试？基于不明确的需求，你的测试用例大概率会跑偏。需求需要实例化。

同样的，还有问比如微信红包有哪些测试点的。看起来高级一些，但本质上和上面的问题没什么区别。因为每个人对微信红包的需求并不会有很全面的了解，对它背后的技术也无法知晓，只能围绕功能的边界值和等价类来展开，最多再加上一些性能的思考。因为大家都不清楚他背后的整体业务流程和架构是什么样的。一些看似正确但无法确认的用例，对双而方都是尬聊。

这些问题的出现，只能说明你从候选人的简历和交谈的过程中看不什么端倪了。慎问，因为容易自己掉价。想要考虑候选人的测试思维，还是得从他的项目经历和对答的过程中去寻找契合点。

知道了面试官司的诉求了，也知道测试用例设计的不同段位了，亲爱的你，知道怎么办了吧。