改造功能测试用例时的一点思考（一）

最近公司的酒店业务线要增加一个新的分类，跟原来的分类相差不大，不过由于从供应商、服务器架构、接口等都有较大的改动，因此还是需要对新增加的这个分类进行全量测试。

同时，由于整体流程和功能与原来的与原来的分类大致相同，在综合考虑后，决定沿用之前分类的测试用例，于是，需要对之前的用例进行增、删、改，根据新的需求和新版本，即时更新之前的用例。

在仔细的看过之前的用例之后，发现用例是从一个页面一个页面一个功能一个功能写的，然后再跑了十几个业务流程。

对于这种设计思路，有以下几点思考：

（1）、这种设计思路整体上来说是先功能、后流程，以功能为主，流程次之，功能和业务流程用例有区分，在执行时，能够让测试人员专注于某一个页面或某一个功能进行测试，不至于因为测试过程中频繁的去关注功能和流程直减的切换而分心。

（2）、单独功能和页面有充分测试。对于每一个页面、每一个功能都有测试用例，对于功能和页面的测试比较充分，这方面遗漏比较少，充分保证了功能测试的全面。

（3）、对编写人员和新人深入了解所有页面和功能有较大的促进作用。根据每一个页面的每一个功能来编写的用例，所以对于所有可能存在的页面和功能都有着比较可靠而完整测试，无论是对于编写用例的老员工还是新人，在促进深入了解功能方面，都有很大的帮助。

（4）、对编写人员对于业务流程的理解要求非常高，学习成本相对较高，而对于编写的整个过程，是相对比较简单流畅的。用例编写的时候，需要编写的人对整体业务流程、每种可能出现的页面都要有非常深入的了解，这一般需要一段相对较长的时间，学习成本相对比较高，对于新人快速了解整体业务流程和用例的设计思路有较大的阻力。不过，只要对页面和功能有足够的了解，在编写用例的时候，则是相对比较简单流畅的。

（5）、频繁切换测试入口，增加执行成本和步骤，导致执行时间无法准确有效评估。每一个页面或功能相关的用例都是相互关联的，而与其他流程之间的用例，则相对过于独立，所以经常就会出现前面一个用例测完离提交订单只有一步之遥了，而到下一个用例的时候，就莫名其妙的跳到了另一个分类的提交订单页面，而步骤却少的可怜，只有预置条件中说了一句处于某个分类的填写订单页面，而且用例之间还相互关联，甚至依赖。这样频繁的切换入口，无形中增加了测试用例的执行难度和执行步骤，对于根据用例数量来评估执行时间进而评估整体测试时间是不利的。

（6）、流程测试相对不够充分。在算上为了进行功能测试而同时执行过的业务流程，再加上专门执行的业务流程用例，一共执行了20来个业务流程用例，而在根据整体业务流程各个条件进行组合后发现，若将所有条件都考虑进来，则有上千个业务流程组合，在尽可能压缩条件的情况下进行交叉组合，也存在一百来个业务流程，即使去掉重复或不存在的流程，也至少存在大几十甚至上百的可能组合。很明显，之前的用例对于业务流程的组合情况考虑的不够充分，存在业务流程的遗漏。

（7）、在执行流程测试的时候，难免会存在对功能测试的重复执行。

为了避免流程遗漏，执行时间可控，决定花时间对用例进行整体改造。

最初的想法比较简单，既然之前的用例是以功能为主，流程次之，那么就想当然的认为改成流程为主，功能次之。不过存在以下几个问题：

（1）、业务流程会比较充分的测试了，不过对于页面和功能，则难免会存在遗漏，尤其是有些出现机会很少的例外页面以及功能。而且，对于页面和功能的测试则难免会不够充分。如何确定两者之间的关系？

（2）、对于页面和功能的测试，是单独拧出来，还是穿插着测试？单独拧出来，会不会出现重复执行，会不会遗漏？

（3）、怎么去筛选流程，才能尽可能的保证流程测试比较充分？怎么确定流程就充分测试了？

（4）、怎么平衡用例数量和测试的充分性？如果要充分的、全量测试，光流程都有上千了，量太大，执行起来更加要怀疑人生了。对于数量和充分的平衡点，怎么确定？