我的测试之路（三）从产品测试到工具测试

在上个产品夭折之后，面临着两个选择，一是去其它的产品组里面继续做产品的测试，另一个是一个大数据迁移的工具，为公司内部开发的。前一个是自己熟悉的领域，是成熟的产品，后一个是刚刚组建的团队，工具才刚刚有点雏形，更谈不上测试了。虽然工具的受重视程度不如产品，但是我还是决定去工具开发的团队。因为去探索一个新的领域才是让自己提高的最好的办法。感谢曾经在IBM的实习，让我对linux系统还算熟悉，但是对于在linux下的测试，自己几乎没怎么接触过。其实对于一个测试人员，当对一个产品持续测试了一年以上的时候，很容易进入一个疲惫期和瓶颈期，变得缺少了开始的时候的激情。所以换换产品，接触一下新的领域并不是坏事，能让自己重新充满激情。

虽然只是一个工具，但却是我认为至今为止，面临的最难的测试项目，主要的难点问题在于，

1）             工具本身的复杂性，数据迁移涉及到公司的所有产品，也就是说我们测试并不能局限于工具本身，工具涉及到哪个产品我们就要对那个产品有所了解。每个产品组自己的测试人员只关注自己的业务，而我们却要关注更底层的数据库，文件，各种依赖关系。当迁移涉及到十几个产品的时候，一次迁移的任务有200多项，这对于测试是一个巨大的挑战。

2）             资源的有限，一个如此复杂的项目，国内国外的开发有20多个，几乎都是资深的开发人员，测试却只有5个，而且在这方面都没什么测试经验。当项目在快速迭代的时候，对于每个测试的压力是很大的。

3）             环境的复杂性，数据迁移是从一个数据中心迁移到另一个数据中心，每一个数据中心都是服务器的集群，客户的数据量巨大，在测试的环境中很难做到于真实的环境一致，在测试环境的模拟有时候也很难发现真实环境里面的潜在的问题。

其它的就不再列举了，这个最开始被公司内部很多人认为不可能完成的项目，在大家的努力下还是一点点的成型，并慢慢的开始工作了，目前我们还在继续的完善它。对于它的测试，目前个人认为做的还不够好。从整体上看，缺少一个清晰的测试策略，从细节上，在测试的设计上因为资源的有限也不够全面，这也都是希望领导们能够意识到，并且在14年里能够有所改进的。不过目前也还是有一点经验教训：

1）                 依赖别人是靠不住的。在迁移真实的客户时，因为涉及到产品众多，所以希望各个产品自己的测试人员从业务角度能够做一些端到端的检查（我们本身主要关注底层，对于业务并不如他们熟悉），这个想法也得到了上面支持。开始大家都达成了一致，迁移了真实的客户，产品组负责检查。最初实行的还好，但是渐渐的他们变得越来越敷衍，有时就拖着不干。我们只能自己去找他们学习，自己来检查。最终还是要依靠自动化来解决这个问题。

2）                 有效的自动化是解决人员不足的利器。这里我不想说自动化的好处，更重要的是强调的有效。现在一个无法解决的问题是，各级领导们最爱盯着自动化比率，他们不关注测试设计，测试策略，测试风险，天天想着自动化，为了自动化而自动化。这导致很多自动化并没有真的解决测试的问题，只是为了自动化而自动化。不关注测试本身，总是把关注点放在这些地方，才是测试的悲剧。