话说
这段时间，专注搞测试，几乎不写代码了，甚是惴惴不安。不过，笔者对测试也是有了一些理解，这里暂且总结下禅道编写用例和测试用例的个别注意事项吧。
其实官网的说明文档是很详实的。笔者上上周层大致扫描了一遍，还是实际过程反哺文档好，这样看起来很有针对性。如果读者未实际操作过禅道用例，那么看这个会很无聊很枯燥的。
目录
1、理论
2、截图
3、总结
难度系数：★★☆☆☆
建议用时：看情况
1、理论
1）可以单个执行用例，也可以测试单批量执行用例，还可以测试单单个执行用例。
听起来很绕，每种方式的效果都是不一样的。
这里把握2点即可：
1、单个执行用例的用例结果，不会体现在测试单里，测试单中的用例执行状态依旧是未执行，那么刚才明明执行了啊？对了，执行结果只是针对单个用例的。
2、测试单批量执行用例和测试单单个执行用例的区别在于：测试单单个执行用例，测试失败后的结果栏，可以写很多内容，是一个textarea，可以拉大；批量执行测试用例，跟执行单个用例一样，结果体现不到测试单，并且失败后的结果内容填写有限，看起来也不够宽敞。
2）每个用例如果修改，需要确认更新用例。
禅道这点设计非常好。每个用例有变更，禅道会把每个用例的版本很直观的表现出来，测试单中关联的用例默认版本就是你关联用例时候的版本；如果用例改变，请务必确认用例修改，否则在测试单中无论单个执行用例还是批量执行用例，执行的都是当时关联的版本，而不是更新后的版本。
这个和需求变更设计思路一样。
知道这些有卵用？很有用的。
想象一下：开始测试，我们会指定几个测试单，把测试单分配不同的童鞋去做；每个测试单关联不同的用例，这些用例可以有很多关系，也可以割裂开来，测试单只是测试的一种组织形式罢了。
假若你是经理，需要掌控测试状态，只需要登录测试单板块，查看数量不多的测试单，就可以看到每个测试用例的执行情况和结果——所以执行测试单里的用例，而不要执行单个用例。
还有，需求中途变更。用例执行了一次，那么用例自然也变更，这个时候就需要确认已经变更的用例，测试单中组织的用例同步变化，然后可以执行多次。
3）用例可以执行多次。
这不是废话么？不是的。用例可以执行多次，除了可以反复测试之外，个人觉得有这样的设计理念在里面。
测试时间有时候会很紧，这个时候，用例是在需求一旦沟通确定后就可以准备了的，这个时候用例步骤可能会很详细，也就是测得很细，如果全部按照用例走一遍，会有抓不住重点的感觉，小问题发现了一大推，大流程半天没走完。这种情况下，就可以按照主要功能，快速执行第一遍用例，把核心场景过一遍，在jira或者禅道上提Bug，督促3端人员及时修复，这个空档，可以回头在把这些用例过一遍，这个阶段把控细节。
这样，测试工作就做的有的放矢，重点细节都会把我。既不会因小失大，也不会放过细节。
2、截图
一图胜千言。以下截图反应了上面总结的核心场景。
3、总结
当然，官方文档都有的。笔者这是实践出真知咧。
http://www.zentao.net/book/zentaopmshelp/38.html
1、工具熟练与否，关键就是考验对工具细节和深度理解透彻，那么这个工具就得心应手拉；
2、注意总结。每天零碎的事情很多很多，如果不把这些零碎串联起来，那么堆积起来的，将是一堆琐碎。