改造功能测试用例需要思考的几个点

如果一个酒店业务线是一个页面一个页面一个功能一个功能写的，然后再跑了十几个业务流程。对于这种设计思路，软件测试人员可以有以下几点思考：

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

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

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

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

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

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

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

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

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

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

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

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

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

现在，在我的问题清单上，有了四个问题，分别是：

1、怎么确定功能与流程之间的关系，才能确保页面功能与流程都有比较充分的测试？

2、怎么安排和分配页面功能与流程测试，才能做到不重复不遗漏，不多不少？

3、怎么确定流程测试是充分的、少遗漏的？

4、从用例数量的角度，怎么平衡页面功能与流程的测试？分解开来，就是怎么确定各需要多少用例，才是相对比较合适的？

一个一个来解决吧。

首先，流程为纲，页面为内容，纲举目张。页面和功能是所有流程的基础，必须保证这一部分是相对比较充分的测试。这是一个一个零散的珍珠，一个一个捡，需要花费不少功夫，需要找根线，将它们串起来。而想来想去，只有流程是最合适的。总体来说：可以按照流程为主，在流程中穿插页面和功能测试，通过流程的主动流转，对页面和功能进行测试；而对于独立的页面和功能，则单独拧出来测试；在所有可能的页面功能都测试结束后，则对剩下的流程执行业务流程测试。当然，这里会产生一个问题，在这种设计思路中，怎么遵循用例设计中的独立性原则？留待后面解决。

其次，以流程为主，穿插页面功能测试，模块化设计。流程穿插页面，这个其实在前面基本上确定了，所以这里主要解决遗漏和重复的问题。从需求设计的角度来说，页面和功能是流程的基础，而同时也是依附于流程的，在流程中的独立页面（注意与独立的功能页面的区别），是没有意义的，也就是说，只要流程的测试足够充分了，那么页面和功能的测试也就充分了，不会遗漏了。这里的重复存在的可能性是很大的，无论流程怎么变，总体来说，页面数量大体是固定的，只是处理逻辑会略有不同，则肯定会在大量的流程用例中出现相同的功能和页面。对于随着流程不同，而略有变化的页面和功能，需要在后面的用例中将之前存在过的页面和功能用例省略并且过滤，比如房间数量随人数不同而变化的功能，在多次执行流程时，可以在后面省略该流程；对于固定的功能，比如担保功能这样的功能，不随审批与否而变化，可以作为独立功能，单独拧出来，作为功能测试用例中的担保模块存在，关于这样的功能，需要一个列表单独列出，并且根据流程中出现的情况，可以增减。

第三，采用科学的设计方法，来确保流程用例的充分完整。既然确定了流程为主线的用例设计思路，那么就要确保流程的用例是充分完整的，最好的办法，就是使用科学的测试用例设计方法。这个时候回过头来看学过的和常用的用例设计方法，等价类、边界值、判定表等这些方法，在针对某一个功能或某一个不大的模块的时候，是够用而且很适合的（当然，这个在后面的具体页面功能的用例设计中，依然是必须要用的），不过，在针对某一个业务线或产品的时候，却很明显不够用了，需要更加宏观更加有效的设计方法。在仔细分析过整体业务流程的规律、大量的比对后，结合我目前所掌握的知识和方法，最后，决定使用正交实验分析法为主要思路来规划整体流程用例，结合分层的测试设计思想，以等价类等方法来设计具体测试用例。

第四，关于具体的测试用例数量，目前还没法估计，等后面分析完再说吧。