如何做好测试用例执行 ？需要注意什么 ？这两点你需要知道。

提起测试用例的执行 ，可以说是一个简单到再不能简单的话题 ，很多刚入行的测试人员 ，因测试经验有限或对业务不熟悉 ，往往在刚开始的时候都是做测试用例的执行工作 。当然 ，也正是觉得这个工作简单 ，所以很多人也不觉得在这里面会有什么问题 。但是 ，实际情况是果真如此 ？本篇幅我们就重点来聊聊这个话题 。

对于测试用例的执行来说 ，一般都会在第一轮测试中进行执行 ，已确保所有的测试用例都能至少执行一遍 。但是，在用例的执行过程中，你是否考虑过它们执行的顺序 ，哪些用例应该优先被执行 ？ 哪些用例应放在后面去执行呢？ 可以想想这样一种场景 ，其中一条测试用例能发现一个重要且难以修改的bug ，如果你的这条测试用例被早早的就执行了，那么此bug被修改的时间就能大大的前置 。但如果你是在最后阶段发现该bug的话 ，那么此bug就会对你后面的测试产生影响 。所以，在测试用例执行的过程中，如何安排测试用例的执行顺序是很有必要的 。

1.测试用例执行

这里，我们就以一个需要执行5天的用例场景来说明 ，在执行的过程中主要考虑的是功能级别或者用例级别 ，若以功能级别为例 ，我们可以看到 ，虽然每个功能的重要程度各不相同 ，但是在第一天的时候我们还是让不同级别的功能都要得到执行，至少要每个功能的基础用例都要得到执行。这样做的目的就是为了尽早确认出各功能是否可用，是否会阻塞后面的测试。

从第二天开始往后基本就是按照计划执行 ，同时也要结合实际情况进行动态的调整 ，在执行的过程中主要注意以下几种情况 ：

• 出现阻塞性的bug ，要和开发明确修改时间 ，同时阻塞期间 ，停止该模块的测试 ，开始切入到其它模块的测试 。

• 出现bug较多的模块 ，若其中一个模块出现bug较多，可以先暂停该模块的测试 ，让开发尽快的修改一波bug ，后续再进行回测。

• 出现开发人员修改不过来的情况 ，若部分开发人员要修改的bug较多，暂时修改不过来，先暂停他负责模块的测试 ，测试bug较少的开发人员所负责的模块 。这样可以平衡进度 ，减少资源投入不合理 。

通过以上的策略调整，要做到不能因为某个模块的阻塞而停止测试 ，也不要因为开发的阻塞而影响测试 ，整体的策略是注重整体推进，优先重要模块测试，能快的尽快测(甚至让其尽快进入二轮)，不能快的即使反馈和跟踪状态 ，确保不影响其它的测试 ，要从整体上关注执行情况，而非聚焦在某个点上。

同时，在执行期间 ，还要注意回归测试的策略和频度 ，若是阻塞性bug ，修改后需要及时的回归 ；对于bug较多的情况，也需要每天下班前回归一部分，以免出现bug积累太多 ，影响后面的测试。

2.测试用例数据构造

在执行测试用例过程中 ，你也会遇到很多的问题 ，其中最主要的问题就是测试数据的准备 ，比如有的时候需要构造出为空的数据 ，而有的时候又要测试最大值的情况 ，如果单从功能上构造这些数据，效率就会很低下 。这时候我们就的借助于工具来构造 ，常见的两种方法就是使用数据库和调用接口 。

数据库构造数据

通过数据库构造数据通常是将要测试的用例所需要用到的数据状态通过修改数据库使其直接具备当前状态 ，这样的话我们就可以直接进行测试了 ，无需再做数据进行前提准备 。比如你要测试一个要具有5张轮播图的用例 ，你就将直接写好的SQL编写为存储过程 ，保存到函数中，后续就可以直接使用。

 

如果你的SQL语句写的足够好的话，并且和测试用例一一对应起来 ，那么它能起到事半功倍的效果 。

当然，我还建议你在使用数据库的时候 ，最好备份几个状态 ，比如在每个版本前做一个备份 ，随着后面进行的回归测试，保持原始状态对复现bug很有帮助 。

调用接口构造数据

有时候通过修改数据库时非常不方便，可能会出现修改不全的情况 。 为了能产生正确有效的数据 ，你可以通过调用接口产生数据 ，而且这种方式往往更加简单，直接通过工具调用即可 。若想要产生多条数据的话，你也可以自己编写脚本让其循环产生多条数据 ，并且也能做到每条数据随机生成 ，保证每条数据都是不同的 。而且这样一次性就能产生多条数据 ，对于初始化多条数据来说非常方便 。

这样对于测试大数据量的时候非常有用 ，因为很多bug只有在数据里大的情况才能发现 。所以 ，通过这种方式能很有效的解决这个问题 。

最后，做功能测试时数据构造是一个费事费力的工作 ，无论使用修改数据库还是调用接口 ，其实最主要的是让其能更好的复用 ，这样的话就能最大化提高测试效率 ，所以，设计时最好要从全局考虑 ，能将设计的脚本复用到不同项目上 ，能达到数据自动化的效果 。