前一段时间一直在写单元测试，主要针对被测试系统的底层的一些类的基础方法和公用的业务数据算法的方法进行测试。这段时间，开发已经将系统的各个部分的框架基本完成，各个WebServices已经搭建，工作重心开始要测试WebServices的功能，进行集成测试了。因为前期对系统的不甚了解（本系统是公司自主研发的系统，没有具体的详细的需求说明书，只有可行性调研报告和概要说明书，且都已经比较陈旧。刚好借单元测试的机会，更细致的了解的一部分业务逻辑，不敢说全部甚至不敢说一半，是真的因为这个系统太大了。），准备了几个都还是比较不错的WebServices测试辅助工具，以为就可以更多的趋向于测试设计，更快速的测试系统功能了。但得到项目负责人的测试要求并沟通确认过后，才发现此项目的特殊性，其成型的辅助工具真的很难灵活的对其测试要求进行灵活的集成测试。如，要修改模拟的服务器的IP地址，要修改加密算法的位数，加密算法的层级，公钥，证书的设置等。更重要的是，各种返回信息也都是加密过的信息，辅助工具无法明文显示（负责人也拒绝了我前期先不集成机密功能进行测试的要求），很难判断返回信息的正确与否。所以还是得用写调用WebServices的代码单元，再在JUNIT的测试方法中同时解密然后再以JUNIT的assertEquals进行比较判断继而进行测试。以前只用JUNIT进行单元测试，集成测试都是用辅助工具和初步界面测试进行的。现在至少颠覆了我的一个观点就是：其实JUNIT也是可以做集成测试的，而且集成测试其实和单元测试其实没有很明显的分界点，只是对象的大小和包含多少等区别了。
有时候发现现在对测试工作的理解有点越来越模糊了，就好像小时候就知道红，黄，蓝，白，绿，黑等，但现在颜色多的你都不敢说它是红色还是紫色更或者褐色？！
