自己总结的建立监控流程的一般思路，如果公司没有自动化的流程，可以参考这个思想和工具实施。如果有现成的工具，其本质也应该是相通的，即识别、查询和控制对象的状态变迁。这里用一般任务生命周期为例叙述这个过程。
1最好用分角色的流程图（viso里的跨职能图、rational rose中的活动图）。这样做比单纯流程图能多反映出“执行角色”这个维度。流程图一定要不能遗漏各种异常情况处理。对于一般的业务理解，可能主干流程是最重要的，异常流即使有所缺失，对业务的理解影响不大（这也是相对的，严谨的说，是流程就应该全覆盖）。但现在这是做监控流程，如果异常状况没覆盖到，就等于发生异常状况没监控到，正好丢掉了“监控”的核心价值，因此一定要全面考虑这个流程。
下图是一个“任务”从发布到关闭的整个生命周期，监控的对象系统是“任务执行系统”。
[attach]67925[/attach]
2根据业务流程图中的过程，识别出监控对象的状态，一般是在执行动作之后，会有状态的变化，如上图所示的黄色圆圈里面标识的。注意这个对象必须逻辑上是一个事物。物理上逻辑上统一的是大多数情况，比较好理解。比如上图所示的“任务”，或者“缺陷跟踪系统”中的“缺陷”，“风险管理系统”中的“风险”等等；物理上逻辑上不统一的，比“甲乙丙三方通讯协议互相认证系统”中甲乙两方是联动的，因此“甲&乙”成对出现作为一个逻辑对象，关注的状态也是双方联动的状态，而不是各自的独立状态。
以上两个过程其可以互相映照调整：流程图中动作之后要考虑是否有状态的变化；状态机设计后要看是否有对应的动作触发。这样互相调整，使二者都能做到完善。
3基于以上的流程，单独提炼状态变化，形成有限状态机。如下图所示。
[attach]67923[/attach]
将要监控的对象具体化，并将各种要素列出，整理成如下所示工具化的列表。
| 监控对象 | 角色 | 状态 | 备注 |
| 对象1 | 角色1 | 状态1 | xxx |
| 对象2 | 角色2 | 状态2 | xxx |
| 对象3 | 角色3 | 状态3 | xxx |
| 对象4 | 角色4 | 状态4 | |
| … | … | … | … |
| 对象n | 角色n | 状态n | xxx |
实际实施的效果如下图所示：
[attach]67924[/attach]
这里如果没有专门的工具，用excel也是可以的，不过要兼顾效率和效果的话，需要多一些使用技巧，比如表头“筛选”，会令整个跟踪过程的状态根据查看着需要显示；将“任务状态”栏用用“数据有效性-序列”的方式固定，可以避免该表格在不同人手中流转的过程中，对任务状态定义实施非法修改，等等
5经过一段时间的试运行，项目和组织已经通过几轮的跟踪和关闭的过程，对于一开始制定不合理的流程和状态已经进行了调整，那么说明组织的流程已经比较固定。如果这时候恰逢一些OA系统上线，一定会有类似的跟踪系统，那么根据组织已经成熟的“软流程”，部署到新工具、新系统上不会太难；相反，如果组织还运行成熟整个过程，中间还有很多问题，比如“不通过”的状态是由项目经理说了算还是由QA说了算一致争执不下，那么这样的流程即使部署到更先进的工具中，还是没有执行力的。自动化的工具只能解决效率效果的问题，解决不了理论基础问题。一定要分清我们缺的的是什么，再按需要上工具，否则花了大钱，还是没做好。
因此在这还要说点题外话算是结尾，在质量工作中，工具不是万能的，不要迷信工具，真正的工具是我们人的思维。思维工具的强大足以克服任何工具的缺陷。想想如何调动我们的思维工具吧—头脑风暴或许是很好的一个思维工具，跑题了，打住。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |