测试用例，是测试过程中很重要的一部分内容，用例的编写也是一项很考验测试人员对业务知识的理解和分析能力的工作，所以编写用例的水平也能一定程度上反映出测试人员的测试水平，而很多测试人员特别是刚进入测试行业的测试人员，往往都忽视了测试执行的重要性，不屑于做测试的执行工作，觉得测试执行没什么技术含量。

    我在之前的两家公司，因为人员结构或者测试组织方面的原因，没执行过别人写的用例，都是自己写好了自己执行。来到现在公司后，由于项目已经进入了尾声，用例也已经比较完整了，所以安排我先做用例的执行工作。一方面在不熟悉业务的情况下，执行用例相对编写用例会简单点，另一方面也可以通过执行用例来熟悉业务。

    我执行的用例是我们部门主管写的用例，所以也算是用例交叉执行的一个过程。在用例的执行过程中，一方面是对我业务理解能力的检验，另一方面也是对用例编写者所编写的用例的检验。用例的执行环境、前提条件、操作步骤、和预期结果都会影响到用例能否顺利的执行，这些如果都写的清晰了，用例执行的效率也更高，对业务的理解也更容易。

    对于业务逻辑简单的用例，对着用例的输入步骤和预期结果可以较顺利的执行，对于业务逻辑比较复杂的，加上一些前提条件可能也没有在用例中说的很完整，需要通过用例编写人员给予业务逻辑的讲解才能理解，而讲解业务的过程，又是对业务更进一步理解的过程。

        我现在参与的项目是OA系统，执行用例过程中，发现在执行多部门协调性要求比较强的业务的用例时，往往需要频繁的登录和退出系统，在用户多的时候，可能容易出错，也不太好保持测试的连贯性。通过一段时间的用例执行工作，也总结了点经验，和大家分享。

    以下是从工作中抽取的用例，为了简便，只取了编号、输入、预期结果和测试结果四个部分内容，具体数据略有修改。两个用例分别对应两个环节，首先是填写表单，然后分别提交给张三、李四、王五（对应编号1），如果提交成功，这三个用户分别登录系统填写意见，第三个用户填写意见并提交后，系统发送待办信息给赵六（对应编号2）。

 

PS：1.张三、李四、王五是独立操作的，互不影响；2.一次只能登录一个用户。

    执行这两条用例的时候，可能会有两种执行方式，一种是在用例1输入完成数据并提交后，用张三的账号登录系统，确认是否收到待办信息，退出系统；然后用李四的账号登录系统，确认是否收到待办信息，退出系统；再用王五的账号登录系统，查看是否收到待办信息，退出系统，然后分别根据执行情况记录到“测试结果”。如果三个用户都收到了待办信息，接着分别用张三、李四、王五的账号登录系统，进行用例2的输入以及预期结果的验证，也是说，在这两个用例的执行过程中，每个用户都进行了两次系统登录操作。

    另外一种执行方式，在用例 1完成输入后，用张三的账号登录系统，如果收到待办信息，在“测试结果”记录为“张三：pass”，同时，不用退出系统，继续执行用例2的输入操作，并进行预期结果的验证，这样可以减少用户的重复登录。另外，用例1的“测试结果”，因为有可能三个用户的实际结果和预期结果不一定都是pass，所以在测试结果填写的时候，对三个用户的测试结果分别注明，便于有针对性的做回归测试。

    在执行用例的过程中，也有发现用例本身有缺陷的时候，比如有的bug提交给开发的时候，开发拒绝了，经沟通确认后，发现是用例编写人员对业务理解有偏差，导致预期结果写的不准确。

总结来说，通过执行用例，我们可以：
1.学习别人编写用例的方法和规范；
2.学会思考，如果是自己写，会如何去写，以及如何提高用例的可读性和可执行性。
3.了解业务。如同写代码，看一百遍例题不如手动写一遍代码，了解业务也是一样，看N遍的操作手册或者相关说明文档，还不如执行一遍用例来的效果好。