测试一

设计

测试目的

串行工作流中用户如果执行“退回”操作，那么工作流的实际行为如何？

测试结果

用户userd“推回”，用户userc得到执行点，用户userc推回，用户userb得到执行点，用户userb“批准”后，用户userc得到执行点，用户userc“批准”后，用户userd得到执行点，用户在“批准”后此工作流完成。

测试二

设计

测试目的

阶段（Stage）对于回退动作的影响

测试结果

测试结果与不加Stage相同，可以看出Stage并不会影响“推回”行为。

测试三

设计

测试目的

测试加入单Parallel节点后对于“推回”操作的影响

测试结果

当工作流执行到usere，然后用户usere“推回”（这里行为比较怪异，usere这个“推回”动作需要执行两次），执行点到userd，用户userd“批准”后，执行点到达usere，而非userb与userc。另外，当执行点到达userb与userc，用户userb与userc的操作列表中没有“推回”这个动作，也就是说并行节点中的用户不能“推回”。

测试四

设计

测试目的

上一次测试中，我们知道，如果有Parallel节点，那么需要点击两次“推回”才能到推成功。本次实验想试一下，如果并行节点上方有两个步骤点，那么当userf“推回时，是否还是会需要“推回”两次，以及会回到哪个执行点。

实验结果

同上一个实验结果类似。userf执行“推回”时，需要点击两次，并且执行点回到usere，当用户usere执行“批准”，那么执行点会直接到userf。

测试五

设计

测试日的

这次改用两个Single节点构成的并行块的执行效果。

测试结果

与测试三中的执行行为一样，这里不再复述。

测试六

设计

测试目的

测试三与测试五中，当并行节点下面的节点“推回”时，都要点击两次才能成功，如果并行节点是有三个Single块组成，情况是否相同？

测试结果

当用户userf“推回”时，还是需要点击两次才能将执行点推到userb

设计

测试目的

并行节点中再嵌套复杂工作流时的效果

测试结果

用户userg需要“推回”两次后，执行点到达userd，用户userd“批准”后执行点到userg。如果用户userh“推回”，则需要“推回”两次执行点到达userb，用户userb“批准”后执行点到达userh。可以看出，虽然工作流变得复杂，但是执行行为和测试五一样。

（完）