往期回顾

上一期的话题谈到了自动化测试的 code 与 codeless 之争
深聊自动化测试 -- codeless 之争
核心议题是:自动化测试用例的开发设计是 “手动敲代码好” 还是 “使用无需 coding 的框架/工具/平台 “好
回帖讨论精彩纷呈, 有支持:纯手工 coding; 有反对: 还是 codeless 大法好;有中庸:不管如何,能解决问题提升效率就行。
里面很多回复都非常有价值,值得仔细品味。
当然,我个人观点依然是纯手工 coding 才是目前自动化的主流, 除非有革命性的测试方案出现。

大道至简,回归本质!

本期话题:自动化测试的框架&方案如何抉择

随着软硬件技术的发展,测试领域也涌现了很多新的东西:新的测试思想、新的测试方案...OCR、AI、图像识别、深度学习等技术也开始融合进我们的测试中协助测试、检测、验证。
无论上层应用多么的绚丽多彩,底层的逻辑和思想应回归本源,趋向大同。例如:

如果不了解背后的本源,是很难做好自动化的,也会影响你的方案和决策。在自动化测试这块,无论是小团队还是大的组织,一个很重要的难点是:不知道如何下手 (落地实施) 或者说不知道选择什么测试框架和方案,团队或组织自身也没能力去开发去解决这些问题。常见的方案 (不包含测试流程管理工具) 是:
1、pytest\unitest+allure+ 各种三方插件 +jenkins
2、junit\testng+allure+ 各种三方插件 +jenkins
3、Appium、selenuim、robotuim...
4、各种内部自研测试平台和测试方案
5、jmeter\Postman...

可谓百花齐放,各显神通。
现实却是:听说过很多道理,却依然过不好这一生; 撸过了很多框架和工具,依然不得要领。
1)配置太复杂,实施和维护成本都高
2)没有可持续性,测试平台和方案 换公司和业务后,就不适用了
3)测试实施方案掌握在少数人手中,每个 leader 都使用自己熟悉的方案,旧人辞职、新 leader 上任后又使用新的测试方案,推倒重来
4)团队内每个人的代码习惯都不一样,维护难...

What the fuss! What the fuck!
为什么我们没有测试界的 springboot?
你心目中理想的最佳的自动化框架或方案是啥?
目前有更好的自动化测试框架吗?
下期继续再聊...


↙↙↙阅读原文可查看相关链接,并与作者交流