进入正题前，我先说过小故事。

我们家老大留了个马尾辫，所以晚上洗完头发都要吹干才行，这种体力活当然是我来做了。

有一次洗完之后，我看到蓬蓬乱乱的，就想着给梳顺了再吹，谁知道这梳子一下去怎么也梳不动，稍微使劲又拽着头发痛，我就犯嘀咕了，这不是刚洗完的头发应该丝滑般顺柔的么？

既然梳不动，那就不管了，先吹干再说吧，数完 600 个数后（我家的习惯，老大嫌吹头发时间长，我就告诉她数完 600 个数准好，效果特别好），终于完事了，这时候才发现，都不用梳就已经是丝滑般柔顺了，拿起梳子一梳，简直顺畅的不得了。

我突然恍然大悟，有些事情的顺序是不能颠倒的，倒行逆施事倍功半，顺势而为事半功倍。

好了，故事讲完了，你可能要疑惑了，这和今天的主题有什么关系呢？

那我再讲过故事好了。

团队新接了个项目，这个项目有两个文件，一个文件负责 UI 实现，另一个文件负责功能实现，功能实现文件提供接口给 UI 文件来同步功能的开关状态，二麻子主要负责项目中 UI 部分的测试，三胖子负责功能接口文件的测试。

前期开发已经同步了接口的设计规格，所以项目实施过程中，两条线就按各自的进度进行推进了。

开发提测后，二麻子很忙，每天都能提十来个 UI 的 Bug，不过有一些是开发还没来得及实现，有一些是产品还没给定明确的需求。

测试进行到第三天，终于可以做接口的联调测试了，才发现好像哪儿不对劲，开关明明关闭了，为啥功能还生效着呢？原来功能开关是实时变化的，但是功能实际的开启和关闭则必须等系统重启后才生效。

现在怎么办？要么接受现在的方案，毕竟进度已经推进的差不多了，要么推翻现在的方案，毕竟目前的结果并不是用户需要的。

如果是有如果的话，优先确认需求合理性是不是能发现这个问题？优先推进实际场景测试是不是可以提前发现这个问题？

这个例子稍微有点极端，因为过程中的漏洞太多了，但是不排除实际没有这样的事情发生。

为了更准确的说明，我就再讲个故事好了。

二麻子今天的工作目标是在一个主流平台上完成一个项目的用例执行，大概 100 条测试用例，看起来时间紧任务重，二麻子一刻也不敢放松。

麻溜的搭建完测试环境，二麻子就开始马不停蹄的进行用例执行了，半天时间跑了 40 条，看起来再努力一把，下班前完成任务是没啥问题的。

可是二麻子并没有按照用例优先级的顺序跑，因为想着反正今天都要跑完嘛，从上到下比较好计算进度，免得跳来跳去的。

结果还真就出问题了，因为这个项目是有驱动文件的，最后几条用例写的是要加驱动校验。

一方面，功能测试要带上校验器来执行，也就是说，今天的用例可能白跑了，另一方面，二麻子加上校验器之后发现系统蓝屏了……屏了……了……

你说二麻子冤不冤，累死累活的忙活了一天，最后系统却用一个蓝屏来回报他，当然了，也怪二麻子自己没有搞清楚用例执行的优先级，才会导致前功尽弃。

好了，上面几个例子都在说优先级的重要性，那既然这么重要，有没有啥明确遵守的规则呢？

我大概总结了这么几条原则，仅供参考：

1、优先完成用户实际场景的测试，其他再按需各种测等；

2、优先保证需求的合理性，再验证实现的正确性；

3、优先验证实现方案的合理性，再验证实现的正确性；

4、优先测试容易出现问题的地方（哪些地方容易出问题？看之前的反馈和问题单），再做常规测试；

5、优先功能验证，再做 UI 验证；

6、尽早联调、尽早联调、尽早联调；

以上，我通过三个小故事说明了优先级在做事（测试）过程中的重要性，同时提供了几个优先测试的原则，不知道你是否有类似的经历？你当时是如何处理的？欢迎你给我留言。