关于自动化测试系统的想法

自动化测试的个人见解

**
前几天，在世界银行上线的自动化测试平台有些问题，不得不继续加班。
问题是对test case 的存贮导致。因为前期代码是三哥的杰作，本来想将就用他们写的几千行的存储过程，但是问题不断。三哥的特点我想业界都很清楚。而主要的的差异其实对和传统的，其他的自动化测试系统的差异。
这就不得不说到个人对自动化测试的看法。

第一个是，谁是自动化测试用户。

很多人就想到是QA。
从现在的流程来说没错。但是从整体的成本考虑来说未必。有些自动化测试的逻辑很复杂，尤其是金融业务方面。按照传统的模式，QA未必懂业务，而且这样的场景在实际中比比皆是。所有，就形成了，业务—>BA—>测试需求---->QA的流程。众所周知，环节越多，出问题的可能性就越大。而其原因在于，每个环节需要不同的技能。如，BA是桥梁，需要了解业务，沟通和基本技术。QA则倾向编码或者编写测试用例。
那么，如果一个业务能够使用的系统是不是可以减少流程环节？或者一个平台将测试的要素更加贴近实际应用，是不是也可以降低成本？
这样，自动化测试平台不仅仅是QA的技术手段，而且还实现了BA的部分功能。

第二，测试用例的重用性

当BA环节优化后，现有自动化测试平台的一个重要问题就是重用。我用过UFT写了不少自动化测试脚本，但是一旦目标测试系统有些变动，对不起，那些脚本基本要修改。这对一个缺乏软件工程思想的QA来说，颇为麻烦。所以，我记得在纽约和一个大型的测试团队聊天时，他们的测试经理就抱怨，他们写了上万个测试脚本，但是经历的半年还无法实现完整意义上的测试。
这个问题几乎是所有的大型软件公司，在大型软件出厂都会碰到。要不延期，要不匆忙上马。或者QA一天工作25小时。
测试用例的重用问题主要是测试脚本能否灵活应对环境的变化。即，旧脚本如何适应新的系统，新的元素如何不影响现有脚本。
如果做了10年以上的开发，对上面的问题倒是有信心做到。而用严谨度不够的脚本语言，开发经验不做的QA要做到上诉目标就有些勉为其难。一旦测试用例无法重用，自动化测试的成本比人工测试，在前期基本是优化不了多少。甚至有可能更多。比如，做一个金融模块的UI人工测试可能只需要不到5分钟，而这个5分钟，自动化测试脚本甚至连对象都没有导出来。这时候，老板过来问，你们测试怎么样，你说还要2小时或者一天，老板心里一定十万个神兽跑过，还不如人工对吧？

还要加班，暂时搁笔。