对于测试用例的复用，我想很多测试工程师都会非常有话说，系统变更频繁，业务变化大，工作流 不统一等等，很多现实存在的问题，都阻碍了测试用例的复用发展进程，但是金融风暴下，越来越多的IT公司都在为了降低成本而做不屑的努力，如解决方案的产品化、搭建软件系统的可复用平台、开发可复用的功能组件等等，毫无疑问的，这些都会为了我们能够提高测试用例的复用性打下了基础，抛开开发人员的因素不谈，而我们在这里也只针对如何从测试人员自身来提高测试用例的复用性来讨论吧：
这里需要首先区分一下，是手动测试用例还是自动测试用例？
一、对于自动测试用例，首先就是要改变脚本的开发方法，如：
1.数据驱动脚本：将测试数据从脚本中分立，保存在外部文件中，当数据发生变化时，就不再需要更改代码，脚本的维护成本也比较低
2.关键字驱动脚本：把脚本中的检查点和执行操作的控制都维护在外部文件中，同样的，数据也会与代码分离开，可以说是结合了数据驱动的脚本开发方法，提高了测试脚本的共享和复用，缺点就是脚本开发需要更多的编程经验和设计能力
二、对于手动测试用例，那么我们就需要解决如下问题：
1.测试用例管理工具：之前看到很多讨论，都没有提到这个，但我想说的是，工欲善其事，必先利其器，良好的测试用例管理工具，绝对会为测试用例的复用带来简单、方便和快捷，也比office文档更适用于测试用例库的建设和维护
2.测试用例的设计策略：测试策略无非有两种，基于功能和基于风险，之前也在论坛里提到过，还有筒子回贴说，测试策略就是基于功能的，这点我不敢苟同， 基于风险的测试用例，往往才是最能被复用的，对于任何同类型产品来说，无论如何进行功能升级，其失效模式也一定大同小异，比如：汽车的失效模式之一——刹 车失灵，这个不论是小汽车、三轮车、还是大卡车，都会存在同样的问题，但是功能和性能上，三者之间的差异就比较大了，所以我才会提到我们需要在测试开始前 考虑这样一种基于风险的测试策略
3.业务抽象：对于测试来说，同样需要跟研发的系统分析师有相当水平的测试设计师存在，他们的工作职责 是分析系统需求、抽象业务用例、设计测试方案来指导测试用例的进行，测试用例的复用也应该在这一环节被考虑，因为一条一条的去查找和审阅相同和相似的测试 用例，对于庞大的系统来说，由于海量测试用例的存在，无疑为大海捞针，但是从更高层次的业务用例中去寻找相似性，一定是更快捷的方法，但这也同时需要清晰 合理的、能够与分解后业务用例对应的、可跟踪可追溯的测试用例库结构，基于此，我才把管理工具放在了第一位
以上是我对于“如何提高测试用例复用性”的问题答案，其中不考虑“如何正确编写测试用例？”“如何进行测试用例设计”等问题。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
