对robot脚本设计，组织的简单思考

由于每个系统的差别都非常大，所以还是用一个流行的例子，一个最简单的erp系统，有新建账号，登陆，浏览消息等最基本的功能，我们来关注它的新建账号功能。
按照我现在实际运用的想法，脚本会分成两类，一种对功能验证，一种对业务逻辑验证。
脚本A 登陆
脚本B 浏览新建账号页面，对每个必填条件，输入格式，唯一性，提示信息进行验证
脚本C 退出
对别的模块也这样做，然后就可以在tm里组织起一整套单独模块的功能验证脚本。

脚本A 登陆
脚本B 新建一个设定账号
脚本C 退出
脚本D 用新建账号登陆
脚本E 浏览自己收到的消息（这里没考虑权限的问题，实际上的业务逻辑比这复杂的多）
这个可以看做是一个基本流，由于业务流程非常复杂，需要我们划分优先级

例子不一定恰当，要表达的意思到了就行，抛砖引玉，欢迎大家说出自己的心得。