|
|
【三】工作流测试
随着数字化办公理念的普及，现在很单位投入资金定制数字化办公流程。一般办公流程会由一个具体办事员起草上报，由逐层领导审阅、审批，最后某一层面的大领导审批通过，审批后的结果返回到办事人手中，办事人执行结果。国字头单位这种情况尤为显著，我做过这类流程最牛的国字头项目审批要经过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 编辑 ] |
|
/1 
关于我们
发表于 2010-4-24 08:01:46
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
发表于 2011-11-21 14:35:55
