浅谈软件测试自动化测试 自动化测试框架
我们先看三个小故事：
1、某1整天加班为了一个自动化测试项目，所有的事情都是他自己做，他得不到一个测试工具，但是最后软件部门给他帮助派个工程师一起工作，很多个月过去了，但是某1拒绝使用自动化测试了
2、年轻能干的某2接管了这项工作，做自动化测试有趣吗？然后他做了个很大的库和复杂的测试系统，然后使用这个测试工具也能发现bug了，但是最后某2因为能力突出离开这个职位到一个开发的职位了。
3、最后某3接管了这个测试集，他费了九牛二虎之力才搞懂怎么去运行测试，但是由于项目改变让自动化搁浅了，大部分的测试都失败了，某3得到帮助，测试集被修复，这些测试最终都通过了，但是忽略了很多软件问题，因此最后客户恼怒了，项目失败了。
从第一个故事中我们看到故事123中，所有的自动化测试项目都是一个人搞，第一个因为缺乏经验，而不愿意使用自动化测试，第二个有热情和能力去搞，但是他的作用没有留下任何有意义的东西，他没能使他的才能和智慧得到保留和传承，第三个问题是忽略了自动化测试的目的。
所以从上面的例子来看我们必须重视：自动化测试是个团队行为，比如我现在做的东西，我很怕会失败，因为领导没有给我那么多人，我的培训还没有时间去执行，不能传承目前，还有我的自动化测试的很多会失败，但是后来人如果把我的延时改动的话完全对我的脚本曲解。
所以：1、要有测试团队；2、要传承；3、要保证测试的有效性，不是pass率。
测试自动化不能从根本上代替测试人员，更无法保证产品的质量。那么自动化测试能做什么？产品的质量又是如何保证的？自动化测试的主要应用范围是回归测试，也就是说测试曾经正常的功能在产品加入新功能或者有了bug fixing以后是不是依然能够工作。这是自动化测试的主要目的，而自动化测试的Case依然需要测试人员的智慧来编写，所以可以说自动化测试只是一个辅助性的工具。当然，在某些软件的压力测试上也需要自动化测试工具。产品质量其实在设计之间就已经被决定了，这其中的决定因素就是团队本身的素质和团队成员在这个具体项目上的经验。测试只能帮助一个设计良好的产品不会因为小的bug而大幅度的降低可用性，而无法挽救一个设计就很差的产品成为优秀的产品。
并不是所有的测试都能用或者必须用自动化测试，有时候自动化测试会吃力不讨好的,我们要评估某些测试的频度，和自动化测试的不足，然后人工测试的case要弥补这些不足，比如哦某些测试频度很少，case又多，难于开发这样就不用去做自动化测试，因为维护需要很多工作量，项目不断的前行，特别是以GUI操作的测试工具来说尤为是这样。任何一处改变都会带来很多case失败。
每个人、每个工具谈论自动化的时候都在说如何真实模拟用户使用产品的情况，这很好，绝对需要关心。不过我得问一句：测试的最后结果是什么？如果你回答“各种使用产品的场景已经运行过“就嘎然而止的话，你就漏掉了一大块：最起码还得加上“产品能工作/不能工作“！所以模拟用户使用产品的各种情况，只是解决上述问题的第一部分；如何得出测试通过/不通过的最终结论，才是解决问题第二部分的基础部分，还有详细缺陷描述、上下文数据收集等没做到呢！
所以让机器像人一样使用产品，并没有解决全部问题，剩下的事情还有多少，这是需要视情况而定的。如果只是解决了第一个问题就认为万事大吉，那简直就是在赌运气——有些时候自动验证是小菜一碟，但很多时候不是。
令事情恶化的是，自动验证了产品的一些指标，并不能反映产品的真实质量。有时验证过的指标通过了，其实其他地方暴露了问题却没有检查
自动化测试需要规划和管理不能乱了章法，比如几个版本后需要改动的话代价有多少（别有哗哗的跑了很多人），投入产出比是多少，我们要看到效果，测试有效性有多高，过程可控吗？回答了这些问题其实就把自动化测试项目管理搞懂一部分了。
不要津津乐道于某个版本的辉煌，适应新的软件才是有价值的：
要了解啥能用上，啥用不上，它是做什么的是否能为我所用，找些零件对付一个新的老爷车，别中途散了架，旧的不是不能用，要关注测试有效性，别走上了我们的故事3中的后果！切记！
文章来源于领测软件测试网 https://www.ltesting.net/
