From http://blog.csdn.net/zzzmmmkkk/article/details/8962990
有时候项目很紧，我们没有时间来把用例都设计好并写到用例管理系统中，使用思维导图是一种比较好的方式，而且越来越受到人们的追捧。但是在实施过程中，可能会有一些问题，比如A同学设计的用例只有他能看明白，B同学就很难看懂，这也不难理解，因为它就像人的大脑，他的思维是独一无二的，脑子里怎么想，这个就是怎么设计的。但是既然是用例，我们就需要保证其可读性及重用性，便于评审以及给他人复用。今天我就把自己工作中的一些经验分享出来给大家。
使用思维导图设计用例的注意事项：
1. 分级：
第一级：按测试的类型划分，如功能测试，交互测试，性能测试(可以是如懒加载，异步加载等内容涉及到性能改进的)，异常测试(也可以放入功能测试下)等。对于功能涉及面广的一定要严格区分出来，并且需要特别重视异常测试的内容；
第二级：按照需求的测试点划分，一般可以划分为多个测试点；
第三级：如果测试点可以细分到测试子项，就把测试子项作为第三级，否则直接在测试点后面写用例。
2. 对于功能测试下的分级：
可以按照组件，功能流程，数据层面，UI层面及异常情况等来进行分级。
3. 对于具体测试用例的编写，注意逻辑性及条理性：
1） 如果好几条用例是在某个条件下完成的，是属于控制和被控制的关系，则可以放入该条件的节点下；
2） 如果用例是属于某个功能点下的，属于包含与被包含的关系，那也放到它下面；
3） 如果用例之间执行有顺序要求，则标记好序号1,2,3；
4） 保证同级之间的用例是相互平行，互不影响的，如果有相互间的影响，那肯定得有层级关系；
5） 书写用例时每条最好是说明一件事情，而且得出的是肯定或否定的结论，不要出现“是否，有可能，可否”等等 字样，结果必须确定；
6） 用例中最好不要出现操作步骤，这个属于具体用例中的内容，但如果不多可以使用括弧备注。
总之，思维导图是指导我们的思维过程，但是所有的思维发散都要有一个模型，在模型基础上进行发散思维，这样子，我们思考时候才是有条理的，进行测试时也才有条理性，没有条理性的用例迟早会出乱子，有遗漏。
我画了个示例图。以简单的邮件订阅为例：
以这张图来说，会比较有条理性，即使给其他人看也能明白，当然，这里面对邮箱格式的测试，其实不用这么啰嗦，可以直接对开发人员使用的正则表达式进行测试即可，关于正则表达式如何帮助我们更高效的测试，不是本文的重点，以后可以找个专题来说。