跟测试工程师打交道最多的可能就是测试用例了，先设计出一些测试用例，然后这些测试用例要经过评审，之后要执行这些测试用例，完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢?很多人可能第一时间想到了一些测试管理工具能帮上忙，例如Quality Center，Test Link;又或者是一些保存测试用例的工具，例如Word，Excel。
不过这些东西真的能帮助我们重用测试用例么?我想未必。测试用例的重用，应该是测试用例里面的设计思想的重用，而不是具体某个测试用例的，因为对于功能测试的测试用例来说，大多数的测试用例都跟某个具体的被测应用有想到大的关联性，例如要测试一个博客编辑器，对于MySpace的博客编辑器和 facebook的博客编辑器来说，它们的主要功能是相似的，都有发表博客，编辑博客，修改博客等……但是由于这是两个不同公司的产品，他们的具体功能或者UI是完全不一样的，所以拿到的两套测试用例，也应该是不一样的。如果分别提取出测试用例的核心思想(就是那些可以重用的部分)，应该能看到很多的共同点，或许会有这么一条共同的用例思想。
1. 打开博客编辑器
2. 点击插入视频的按钮
3. 粘贴视频代码
4. 点击保存，发布
期望结果是该视频能正确显示在博客上。
这条用例可以提取为“验证博客编辑器能够插入视频”，至于实现的细节，可能两家的处理不一样，可能前者用
举个例子
CRUD模式(创建，获取，更新，删除)
1. 选择并确定出一条记录或者一个字段
2. 产生一个随机的等价类item
3. 检查这个新产生的item是没有存在的
4. 添加一个新的item
5. 读取并且验证这个item的正确性
6. 修改该item并且验证item确是已经被修改
7. 删除该item并且验证item缺少已经删除
以上测试用例可以应用于不同的场景，例如MySpace中的一个帐号，也可以是一条歌单，还可以是一篇博客。这种类型的用例才是可重用的，而不是发布一篇博客，修改博客，删除博客……测试用例的重用，也就是测试用例的精华部分，其设计思想，而不是一些存在QC,TD中的 01010100101001。
文章来源于领测软件测试网 https://www.ltesting.net/
