给用selenium做自动化测试的泼盆冷水
本人原打算用selenium做web端自动化测试，学习一段时间，总结一下看法：优点：
兼容多种浏览器，对应兼容测试优势明显。
缺点：
脚本化测试用例，维护成本高。
运行效率慢，
依赖容器，测试执行是顺序的，前置条件太多。
测试覆盖率低，检查点少了意义不大，发现不了啥问题。多了烦死人。
系统不稳定没办法执行，稳定了发现不了啥bug
以上不建议大家用这个做功能自动化测试，做做兼容测试就行了。
对于功能测试，建议大家还是从接口方面考虑，高效、覆盖率高。独立执行（登录后拿到服务器session每个模块都可以独立测试）。
安全性测试也可以在接口测试中进行（如sql注入、脚本注入） 就说几点：
运行效率慢 --- 完全可以用grid来做分布式测试，或是直接拓展，几十、上百个浏览器并行也不是问题
依赖容器，测试执行是顺序的，前置条件太多 --- 多平台运行，哪里需要依赖容器了，测试执行完全可以并行
每天和页面元素较劲也能说高效自动化 --- 每天页面元素较劲，只能说楼主的定位方式太差劲了，写出好的xpath和css可以有效做到change proof
我是来看回帖的 :o too young too simple @joykao，每天和页面元素较劲也能说高效自动化，无知。 回复 4# yanfei_wu
大神。。。sorry 我很无知。。。;P 同感。。。。。 本来selenium就是用来做验收测试的，另外用例能不能检出bug，要看你用例如何设计，校验点怎么设计
SE 可以用的很灵活，千万不要生搬硬套，用于不用，用在哪里，铺多大规模的摊子，都在乎于结合团队实际情况出发。只要明确目标就行了：在长期使用下是高效的，节省劳力的。
口水仗没必要打，所有接触的人，都有自己心里对SE 的一个看法，这个看法随着自己的知识，技术，深度，广度，会逐渐变化。
它现在活着，被广大的业内公司用这，就说明在当前的实力时期，它有活着的价值。
写一轮脚本，跑一周，就全报废，不在讨论范围内 无知了，，，不过先体会体会 用例维护看你怎么设计了，抽象对象再次封装方法，是的用例维护成本最低 就是自动化测试人员需要考虑的 回复 3# joykao
顶一下！ 回复 9# jia8162
顶！正解，维护UI Object，抽象操作，开发自定义对象，还是需要多花精力的。 楼主太年轻 接触了一下就有这种感觉，你可能不太适合做自动化测试吧。。。 自动化的目的主要是做回归, 保证功能的正确, 不是说一定要发现bug才有存在的意义, 它保证的是测到的地方是没有问题的 太年轻了，大家都懂得 楼主对自动化的了解太少了，楼主说的脚本化的测试用例，那是因为楼主只对selenium和unittest的使用有了解，还没有达到扩展的地步，就和我知道Java、C#一样，知道for循环，但是怎么用不知道。
工具只会提供基础的使用，任何人可以在上面通过自己的想法来进行扩展，比如，使用外部文件编辑步骤、用例，来达到驱动的效果，完全可以根据工具提供的基础方法来进行二次封装，根据步骤和测试数据，来执行测试。具体是辅助测试，还是做验收测试，根据你的步骤文件和测试数据来进行。 zzhengjian 发表于 2015-2-28 22:38
就说几点：
运行效率慢 --- 完全可以用grid来做分布式测试，或是直接拓展，几十、上百个浏览器并行也不是 ...
楼主看到了么。。。
页:
[1]
