前一阵子在一本书上看到过了对于未来软件测试的设想，其中有一条就是测试用例的重用性。昨天在一个论坛上看到一个同学在问如何测试一个输入数字的文本框，结果有另一位同学回答了很多也很全面；然后今天我又刚好写用例，但是大多数都是重复的。本来测试人员就在每天的做重复的工作，但往往越是这样就越要避免那些不必要的重复工作。
所以今天就想起了测试用例模块化的问题，是不是真的就可以尝试使用测试用例的模块化划分呢？我觉得这个其实是可行的，尤其是在产品线脚多的公司，各个小组之间可能平常很少去沟通和讨论测试用例的具体设计细节部分，而且产品通常都不是一摸一样的，没法直接把用例拿过来就用。但我们转换一下角度的话，可以求其次，即能通用多少就通用多少，而当划分的粒度越细就越能应用广泛，类似与开发中的高内聚、低耦合的情况。
有这样想法是好的，再者就是如何去实施它，只有真正做了后才能知道这个设想是否是一个好的设想，让实践去验证。那么接下来应该就是如何去选择可模块化的测试对象。比如一个文本框，一个通用的用户场景【登录】，一个特定的测试类型【升级】。
在这里想说的是要想成功还需要另外的力量，领导和同事的协助，有了他们的协助和参与才能让这个设想更有实践的意义。设想是需要他们去充实和验证的。
首先是要得到领导的同意，因为这个一个流程的改进，所以它是有一定的风险的。毕竟在用例选取和重新构思上和之前是有很大的不同，所以还需要先小范围的试用，有成果出来在推广给各个小组使用。
其次是需要大家群策群力，贡献自己在某方面的测试经验，去维护一个面向共同的测试用例模块集。利用大家的实际工作经验来确定哪些是可以进行模块化的，然后在逐个让大家给每个可模块化的对象进行用例设计。所有人都参与到这个实施中来，这样一方面是利用大家的智慧来构建模块化用例集，另一个方面就是更利于大家来接受和实施这个改进的过程。
最后模块化后的用例需要公布和维护，可以申请一个内网来发布和管理这些模块用例，供各组进行使用；其次是维护这个模块用例集，有新的可模块化的用例后添加进去。若此方案执行的很好的话，就可以考虑对其进行管理化，即专门写一个工具去管理和使用这些用例，方便用例的选取和使用。
