你在用什么写用例

这段时间用例评审项目组三个成员：有用excel的，有用xmind的，有用禅道的。
而我关于用例用到xmind，后来用excel，后来用禅道一直到现在。

xmind是思路分析和整理的工具，在最开始做测试的前3年可以说很依赖这款工具；

后来，如果要做整个项目的把控及汇报工作，xmind工具无法量化及留痕，尤其是回测的时候，另外关于留痕这一点很重要，必要的时候要有图有真相，而xmind做不到，而xmind——>excel可以解决量化及痕迹的问题，并且可以及时汇总汇报领导进度。xmind——>excel这种模式组织测试用例持续了2年，可以量化但是不能留痕。

测试标准化的意义：留痕有据可查
留痕很有必要尤其是出了生产bug会追责的情况下。xmind——>禅道，目前这种模式基本可以解决遇到的痛点，量化及留痕。其实用专业化的用例管理工具有比这更重要的意义，就是可以进行用例的沉淀及复用。

测试标准化的意义：复用及速快构建新用例
像常规的功能检索、翻页、添加、删除等移动端或者PC端的测试点很类似，如果可以形成测试用例框架，那么每次就不用从头开始写了，而是可以直接从从用例库中导入进行必要的修改即可。

测试标准化的意义：快速回忆及投入项目
但是也并不是所有的项目或者测试点走标准化的测试用例工具会更高效，比如之前测试的评分卡项目，主要涉及数据测试及数据的边界值测试，用excel管理更高效，这时就可以用excel进行管理。但是有必要在标准化测试用例中留痕或者说明用例设计的思路，以便在后续迭代测试中快速投入项目。有很多时候中断参与本项目过今天突然又要完成项目的工作，这是完整、标准化的测试用例能够帮助自己快速投入项目，完成当下工作。

测试标准化的意义：高效地写bug报告
标准化测试用例设计还可以执行失败的用例直接关联用例转换成bug。可以去了解由用例生成bug的格式及在设计测试用例的时候尽量标准化步骤，这样执行失败的用例可以直接转换成bug，节省了很多从头写bug 的时间。很多同时提交的bug报告只有题，bug内容为空，估计是因为写一个完整的bug报告太费时间的原因吧。
执行失败的用例转bug，这是用例的写作格式及内容就要不耦合，其实本来每个用例都要是一个完整的测试点及完成一个测试目的。

测试标准化的意义：有利于自动化测试用例设计
开发自动化测试脚本时，清晰的手动测试用例设计及业务流程可以更专注于自动化测试用例的设计。并且即使是自动化测试用例也有必要保存手动测试用例的步骤及详细说明。由于是在项目中断再浸入时期间很可能修改了一些内容导致自动化测试脚本不能完整执行，有时说动测试可以更快的完成测试任务。在系统测试阶段自动化测试脚本可以提高效率。

所以，当你用xmind等快速的写出了测试用例时这还是最标准化的输出，也许是你还没有想那么多或者意识到这一步这样做对后续工作的影响。xmind只是测试分析的过程，而距离输出标准的测试用例还有一段距离。也许你会一直觉得这样挺好呀。
慢慢经历吧，想的多了做的多了就会意识到标准化做法的意义。