软件测试的内容很多，就功能方面来说有界面，数据，流程，权限等。对于一般的管理软件来说，流程的测试是一个重点。如何对流程进行测试，是用例设计人员考虑的重心。下面就流程测试设计谈谈我自己的一些看法。

　　流程用例设计第一是要考虑流程的完备性。先要整理出要测试流程的节点和关系。确定节点和关系有几种方法，可以从流程图中得到，也可以从系统用例中得到，或者需求说明中整理出来，如果不幸这些都没有，你也可以自己找出来。如何寻找，请参见我的文章《没有文档如何测试》。

　　掌握资料后，首先，确定要测试流程的重点。在一个系统中，一个大流程有时会包含几个小流程，也有可能会出现流程相交的情况。这里的重点是指对于确定的一个独立的流程而言，它有一个明确的起点和一个明确的终点，它的分支点可能会接入其他流程，但我们只把那些当成接口考虑。

　　一个流程在通常情况下，有两个方面的内容：一是流程节点的移动，即功能的实现，主要与角色相关。二是节点间数据的流动，主要检查数据的完整性与正确性。对于以角色为重点的流程，第一个方面是重点；对于以业务实现为主要的流程，第二个方面是重点。下面分别进行阐述和举例说明。

　　测试流程的功能实现，第一步是确定节点，这些节点的特征就是要有一个独立的业务意义，其包含的业务数据也是不可再分的。常见的这类典型的流程就是公文流转。公文流转在很多办公软件中都会遇到。从新建公文开始，到公文传递审阅，到最后审阅完成。这种流程看起来很简单，实际上在程序设计实现的时候，仍会出现一些问题，其中包括流程设计的合理性。

　　设计测试用例的时候，分没有权限的测试和权限测试两种。没有权限的测试主要检查流程在实现方面的功能问题，往往是一个角色走到底。它的节点最大数和最小数往往已经定义。主要检查节点和节点之间的实现，如数据传递是否正确，流程是否会回退。这里重点要提到的是，不间断的，一气呵成的业务转移与退出再进入系统继续业务是有所不同的，这主要取决于程序在实现业务流程时才用的方式，是保存在缓存中还是及时读写。对于可以自定义流程的程序来说，则要考虑跨标准节点的一些流程定义和一些非业务常规的流程定义。这部分测试用例的设计，不但要检查流程的正确性，还要考虑是否存在其他可能在系统设计之外的暗含的流程。比如某些流程需要文件导入导出，但却没有对这些文件做出判断。

　　当加入权限进行测试的时候，首先测试用户实际使用的角色处理，保证需求的正确性。然后再设计自定义角色的处理，这部分往往内容很多，且不太可能进行完全测试。重点是将主要节点进行角色检查，设置最小权限和最大权限的组合，以检查是否会出现数据丢失，跨流程或角色越权的情况。如果考虑角色和流程定义的双重组合，如果没有工具软件支持，其工作量是难以想象的。当然我们仍然可以从其中只选择20%的用例实现设计，可以找出超过80%的流程权限的问题。其关键就是结合程序实现的方式，即进行灰盒用例设计。

　　使用灰盒用例设计的好处也体现在以数据为主的业务流程实现上。测试这样的业务流，往往是测试多个相关算法。它的测试重点在数据的选择上，有两类数据取值要考虑，一种是业务数据，一种是系统数据。业务数据的取值，主要考虑正确业务数据，边界业务数据和错误的业务数据；同时结合算法本身的特点还要考虑0，1，2，9，浮点数，最大值，最小值，小数位等的情况。考虑内存和中心处理器的能力，还要进行大数据量的测试，这时要结合测试工具进行设计。我曾遇到一个关于浮点数取值的问题，按照一般小数的算法，结果是0.01，但在算法实现时，机器中是0.009999….，按业务规定小数位后三位全部舍掉，入另一个帐。这种偏差的累计是很惊人的。除此外，还要考虑数据与数据之间的影响。有些算法在单独检查时没有错误，但当附加条件取值时（往往是特殊值），就会影响整个结果。

版权声明：本文出自 菜菜蝴蝶 的51Testing软件测试博客

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。