公文流转的性能测试用例应该怎么设计（重点是用户需要参数化）

wangliwei2002

这周有个项目很急，要做公文流转的压力测试，难点在用户需要参数化。
随机的参数化用户登录没问题，拟稿，然后把公文发送给下一个人，问题在于发送给的这下一个人是否也可以参数化，如果可以，那么参数化了后，我又应该怎么设定让这指定的第二个人登录进行第二步操作呢。

大家帮助思考思考吧

兰兰

参数化和关联必不可少！
在每个节点录制不同的脚本，在脚本中查找关联，然后根据业务做必要的参数化；
在场景中进行分组运行，根据业务流设置运行顺序。

[ 本帖最后由 兰兰 于 2008-9-3 12:02 编辑 ]

断寒

只要关联做好了,参数化后就不会有太大问题,流程转换中每一个流程都会只对应一个工作流号的,每个人获取各自的那个号码,即处理自己的那个文书,就OK了,如果存在功能上的问题,如A发起文书,B和C都能看到,那就比较麻烦了.呵呵

wangliwei2002

原帖由 Zee 于 2008-9-2 21:25 发表
你说的“发送给下一个人”，这个过程具体是什么样的。
分析好业务后才确定是否要参数化吧。我觉得业务流和参数化、关联都分不开。

大概过程是这样的：用户A登录，拟稿了一个公文，然后发送给了用户B,A退出，用户B登录，对公文做补充修改后，把公文发给了用户C,B退出，用户C登录，对公文做补充修改后，把公文发给了用户D,C退出.这是一个完整的过程。
现在需求是要虚拟出几十个这样的过程，但不要每次都是A-B-C-D这样，可能是E-F-G-H.B-Y-C-A等。
应该是需要把第一个登录的用户参数化，问题在于第一个用户A把公文发送给第二个用户后退出后，怎么控制这个由第一个用户指定好的第二个用户B登录。

Zee

你说的“发送给下一个人”，这个过程具体是什么样的。
分析好业务后才确定是否要参数化吧。我觉得业务流和参数化、关联都分不开。