最近加入了一家主要以web系统测试为主的公司，上面特别看重测试输出物，而测试用例作为主要输出物之一，要求的较细。
小酋特意画了一个思维导图来理清用例设计思路，以免遗漏：
小酋在查阅新团队历史用例集时，也发现了一些问题：
1、用例标题为简报形式，缺少明确目的
这种方式有好有坏，好处是测试点一目了然，坏处是目的不明确，需要查看预期结果才能了解。（个人更偏向于用例标题为用例的摘要，需点明目的）
2、步骤和预期结果不对应
建议步骤和预期结果一一对应，哪怕日志输出内容作为预期结果之一，也对应“查看日志”的步骤。
3、预期结果中代入了步骤
预期结果是操作后，呈现出的数据、状态或页面。不应该带入动作，如提交登录提示失败，典型的“步骤+结果”。
4、用例冗余
测试用例建议以最小的用例集尽可能覆盖测试点，需要剔除无效用例（去掉无效等价），不应该过多去堆砌用例，数据好看但并不利于执行。
5、用例编写后导入禅道，缺少必要的组织关系
用例导入工具，如果没有好的组织关系，必然为后续提取、执行用例带来困难，所以编写用例之前就得考虑好用例导入工具后的组织关系。
最后，加入一个公司，先要适应规则，然后取长补短，后面再影响和推动规则的改进。
-- End --
文末寄语： 最强壮的狼也有它脆弱的地方，要想做到最好，仅仅靠自己是不行的。只有不断地取长补短，才会不断地进步。