51Testing软件测试论坛

标题: 功能测试实战【三】工作流测试 [打印本页]

作者: 没有如果 时间: 2010-4-24 08:01
标题: 功能测试实战【三】工作流测试
【三】工作流测试

随着数字化办公理念的普及，现在很单位投入资金定制数字化办公流程。一般办公流程会由一个具体办事员起草上报，由逐层领导审阅、审批，最后某一层面的大领导审批通过，审批后的结果返回到办事人手中，办事人执行结果。国字头单位这种情况尤为显著，我做过这类流程最牛的国字头项目审批要经过30多位领导审阅和审批（汗颜于政府机关制度之严谨）。

这种逐级审批的工作方式，通过一个流式的软件操作流程来实现，我们叫做工作流技术。

第一段提到“审批”、“审阅”两个词，首先明确一下：在实际工作流中，有些领导只会写个“阅”，或给出自己意见，不会做出批准和不批准的操作，对于测试而言，这样的节点在流程上不需要测退回，叫审阅。而审批就是要有明确的批准和不批准，在流程上会有退回。节点是审阅还是审批在测试执行之前要明确。

在进行工作流测试的时候，我们首先要确认的是审批流程图，图中要包括全部节点，各节点性质（审批还是审阅），正向流转和逆向流转规则，明确传输过程中查看权限等需求问题。整理好资料，我们开始测试：

1、确保流程通畅，符合流转规则。

正向规则最基本的一点是，按照流程走，到哪个节点哪个几点能够看到待办件，没传递到的节点不能看到待办件。现在很多工作流节点，调用的页面是同一个，在底层工作流应用中控制显示情况，有时设置错误，本来不应该看到该件的节点，有时候会看到。

比较常见的正向规则还有会签流转原则，如流程是A上报给B、C，B上报给D，C上报给E，D、E上报给F，这样的流程我们需要确认，在什么情况下，F应该看到待办件。是D、E都结束，还是有一方结束了，F就可以看到。如果是单个通过，F就可以看到，我们要尝试分别走2边的情况，流转结果是否正确。还要尝试F已经通过了，没审核的一方才审核（审核包括审阅、审批）是否影响流转。

逆向流转规则，检查是否每一部退回都退回到了需求定义的节点，收到退回件的人是否能够正确处理退回件。这个根据需求定义，有的要直接打回上报人，有的要打回到上一个审批人，有的要打回上一个节点。我们要检查每一个退回是否将待办件打到了需求定义的正确节点上。

以上三点我们当成单个场景的测试，测试的是每2个节点之间的流转是否顺畅，那么我们还需要从流程的健壮性考虑，来个复杂的综合场景。然而一个复杂的流程，即使是纯粹的串签形式，经过20多个节点，10个节点有退回功能，按照我不怎么好的数学基础，也能算出来符合全部路径的流转是不可能穷尽的。那怎样的测试方案才是相对较优的呢：
我一般会走一个相对复杂的流程，中间出现问题，再细化，找到问题所在。
介绍一个我喜欢第二个走的流程（第一个走的当然是一条数据审批到底），用一条数据，在每个节点审批通过，遇到一个退回就退回再审批，再次遇到过，再遇到第二个退回操作退回，每次第一次遇到退回的时候进行退回操作，如此继续。到最后一个退回，一直退到起草者，再逐级通过，完成流程。

2、状态查看，在每个节点显示正确的状态。

起草人上报了自己的待办件，他希望知道当前审批情况如何，各级已经审核过的人也关注上面领导是否同意。我们要在每一部操作后，关注已经经历过的每个节点，状态显示是否正确。尤其是多次退回和通过的情况，之前的节点可能会有显示状态不正确的情况。

3、信息传递正确完整

首先是待办件的基本信息，从起草人起草上报，每个节点可以正确看到（有特殊权限定义的除外）全部信息，要特别关注附件等特殊信息，在传递过程中较容易出现问题。另外一些字段也可能出错，我遇到过这样的问题，审核人看到的信息，手机号码显示在了传真里面，审核人的页面调用的数据库字段写错了（这里说个题外话，有时候我们测试执行，要填写的字段太多，我们可能会输入一些没有意义的信息，比如111111111111，这样。但是我每次都会跑一条我自己的真实数据，开始时觉得好玩----给自己的信息写在了一个局长的提干申请里面，后来发现这么干的好处很多，后期对字段我很容易看出来他们取数据错没错，或者完整不完整，尤其交互页面，如果用没有意义的字段，要对比可能需要2个页面都看，写自己的数据就简单很多。还有页面检查设定的约束是否能够容纳一个正常数据等，原来我上一家公司的邮件字段约束，不允许用数字开头，我输入我QQ邮箱，发现这样约束不符合逻辑，开发人员立刻取消了这个约束）。

其次是各级审核信息，每级审核领导会填写自己的意见，正项流转下一结点要看到上面结点所有人填写的意见，逆向流转收到退回件的人，也需要知道上面领导退回原因。给每级领导审核时能填写意见的都写上意见，这样在各级检查的时候能够保证检查的完整性。
有时候流转较复杂，像“1”中第四种，可能本级已经审批过了，退回去，给下级了，下级再次上报上来，本级再次审批，然后上报。上级拿到后，看到的审批信息，要是最新的，而不是上次退回的。尤其是上级看到的审批日期等信息，如果读取的是第一次审批的时间，领导会认为下级办事时间过长。

4、审核中可以对原件编辑的情况

有时候需求要求审核人有修改起草人起草原件的权利，这时候我们要注意需求未特殊定义情况下，字段和值的约束条件应该前后保持一致。起草人必填项到审核人修改处也必须是必填项，起草人约束必须填写数字，审核人修改时也必须如此。还要注意附件等信息，我遇到过候编辑的时候，没有操作附件，但是保存后，附件没了。
另外还要注意信息的统一性，审核人更新后，起草人处信息应相应变更，后面的审核人应该看到新的信息。

暂时想到这些，想到新的再补充。

【系列回顾】：

功能测试实战【一】动态可维护数据源应用测试 http://bbs.51testing.com/thread-191473-1-1.html
功能测试实战【二】数据迁移测试 http://bbs.51testing.com/thread-191928-1-2.html

[ 本帖最后由没有如果于 2010-4-30 00:13 编辑 ]

作者: xinzhen03 时间: 2010-4-27 17:22
新手~~~学习中

作者: 3396408 时间: 2010-4-28 09:52
very good !
搞这方面测试的完全值得参考这篇文章

作者: liangshi 时间: 2010-4-28 12:21
很好的文章，收藏了。

作者: cystctest 时间: 2010-12-20 11:39
不错，谢谢，但是，小问一下，测试用例应该怎么写呢？

作者: 小熊yyjj 时间: 2011-7-5 11:18
很有参考价值，谢谢

作者: 一直都很烦 时间: 2011-8-8 14:54
楼主有新的理解么？最近在做工作流测试，想做有关工作流性能测试方面的

作者: BigBC 时间: 2011-9-8 14:13
好文章啊

作者: Phoebe2012 时间: 2011-9-15 15:17
思路是很不错的但具体的测试用例怎么写呢？求指教

作者: brandxu 时间: 2011-10-5 15:06
是啊具体测试用例如何设计呢如何基于某个理论来写呢。。。

我也做了很多工作流的测试但现在回过头来想看看到底该如何科学的设计测试用例。。

作者: SariyaLee 时间: 2011-11-14 16:20
最近在做流程方面的测试，解释的很详细

作者: k1132 时间: 2011-11-16 17:05
确实写的很详细啊，不过我最近遇到一种情况，像我们公司工作流中审批人一般最多有3个人，所以数据库字段当时设计的时候就限定的长度不太大，，我一般按照实际情况来测试没发现这个问题，，后来开发人员随便点，发现如果选的人过多，流程发起失败。。。唉。。。伤不起

作者: 老秃瓢 时间: 2011-11-16 17:29
很专业！必顶！

作者: zhouyong9891 时间: 2011-11-17 11:00
好贴，必须要顶一下！谢谢楼主分享……

作者: ahwangwei85 时间: 2011-11-20 14:28
很早之前我们公司就准备开发一套工作流产品，如今两年过去了，还在开发阶段

作者: a5914361 时间: 2011-11-21 14:13
感谢分享

作者: 楠族开心果 时间: 2011-11-21 14:35
挺不错的文章

作者: janehost 时间: 2014-4-16 15:18
很不错的文章，楼主有关于测试用例的吗，我最近一直在做这块内容的，系统可以有比较系统的测试用例，之前都是打游击站，感觉很多地方都可能没有覆盖到的...总之先谢谢楼主了

作者: KillBill 时间: 2015-6-25 14:28
写得很好，是我想要的。过去了这么多年，居然只有这么一篇文章讲解工作流的测试，为什么

作者: 你看我笑 时间: 2015-7-10 17:22
mark!好贴哦

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)