好漂亮的用例文档！
好漂亮的用例文档！而且用的是XLS，我在51testing学习的时候我就想用它作为测试用例写作工具，原因就是XLS统计功能强大。当然，实践证明拿它用来写文档的话是怎么看怎么不舒服。今天看到一反例，与自己设计的那个XLS文档相比，恩，自己真是差多了。对照自己的用例文档，反省了一下，此文档值得我学习的的地方有：文档格式方面
1.有设计单独的一页做用例总目录，重点突出，脉络清晰
2.利用左侧收缩内容的Excel功能，在某种程度上可以解决用例过长、使用不方便的问题
3.文档设计考虑了一些统计要素，比如时间、用例步骤、三轮回归测试（起码三轮？）结果记录
4.或许是英文写的关系，整个用例表的内容看上去真的很清爽，简约而不简单。（努力学英文真的是利远大于敝啊~）
文档结构设计方面
1.Data Required这列以前没想过，每次都是把所需测试数据结构放在用例最上面。这样不看完整个用例，别人就不能知道这些数据用在什么地方。（在此基础上改造成数据驱动用例应该也会很清晰明了吧？）
其他方面
1.在看这个文档时想到的，大项目的测试往往分工合作，用例文档不仅是一个人在使用，因此用例文档中注明作者很重要。
2.它有页面设计方面的内容，比如配色、布局。这也是让我觉得它“漂亮”的原因之一。
在浏览整个帖子的时候，也看到了对此用例文档的评论。回头总结一下它的缺点~
[ 本帖最后由 暗冷夜空的风 于 2009-10-27 14:39 编辑 ]
此用例文档的缺点
1.与直接写测试点的用例相比，写这样的文档花费的时间很多。2.用英文写用例虽然使整个文档页面风格显得舒服，但是在非外企的公司写这样的用例别人会看不懂。另外，若是描述那些复杂过程的句子，要简洁同时还要概括地用英文表达是需要一定的英语功底的。
3.Excel表格天生不是写阅读类文档的料。这在较长的用例中尤其明显。比如，右侧太长、下方太长、单元格内的内容太多等
4.此用例文档不适合大型软件的测试需要。
a.缺少了一些关键字段（当然字段定义的话因项目、公司而异的）比如，Test Ojbective、Priority，是否要自动化等。
b.这样的用例用于单个控件的功能测试用例设计可以，但是要对付ERP那样的业务系统就会很吃力。ERP系统的测试用例一般不会一次写完。由于业务太复杂了，需求会不时地修改、补充。因此，对这样的系统写测试用例需要考虑用例设计上的可复用、易修改要求了。
5.测试用例文档不易管理。比如共享用例如何安排、测试数据如何组织、控件功能与业务逻辑需要分开等。
忽然发现有些优点同时也是缺点，如何取舍只能因地制宜了。总之，此文档真的很值得学习，但不能照搬。
[ 本帖最后由 暗冷夜空的风 于 2009-10-27 14:35 编辑 ] 貌似比较规范，哈哈 感谢分享啊！ 很不错的资料，谢谢LZ了 歇息 谢谢，学习啦！ 下载学习了 谢谢共享:) 呵呵~一片赞誉之声哇 谢谢。不错的东东 我也来看看~~~ 先下来看看 谢谢楼主分享！！:handshake 不会见过吧！ 先回复，后下载 多写多谢 看看··
