测试用例的策略不能一概而论。看产品类型,看产品所处的阶段。
互联网 To C 的产品,迭代快,发布时间不可妥协,明知一堆 bug 还发布的情况太常见了。 业务不一样,用例策略也不一样。每次发布前回归主流程,不必事皆巨细。监控和 troubshooting 的速度很重要。就算你用例做的特别好,特别细,也是跑不完的。
产品前期,堆功能的时候。连用例都可以不写。 所处的阶段不一样,用例策略也不一样。这时候业务不稳定,产品能活多久还不一定,所以没必要投资源写用例。
以上两种情况都是弱化用例策略的。因为修复成本低,监控做的好,trouble shooting 快。要快速发布抢占市场,出问题直接线上一修就行了。所以互联网才高度重视监控,高可用,trouble shooting 机制等等。如果在这里用例设计的特别全,特别细。恐怕测试没跑完呢市场已经让别人占了。很可能大家都是在用 excel 写用例,连用例管理平台都没有
相反如果是 TO B 的业务,尤其进场部署困难。升级困难的。一定是高度重化用例策略的。这种项目发布周期长,有足够的时间进行全覆盖的验收测试。并且是一锤子发布,一旦发布几乎没什么后悔药,你没机会玩监控。所以这种项目在发布前搞个一两周的测试时间都正常。测试流程极其严谨,用例管理平台里堆积着大量的 case。这种产品弱化监控,trouble shooting。重视自动化,CI,流程和文档。
不同种类的业务,测试策略是不一样的。
#35 楼 @lingcizhisheng 这个都得看你 case 的重复执行度。如果平均人家一周变动一次页面,但你一天就必须得执行一次 case。那即使不太稳定我也会选择去自动化它。一切都是权衡的。如果改变的成本低于每天执行用例的成本。 还是有自动化的价值的
#32 楼 @dancingcat_ 可能每个人的目的和预期都不一样吧。有的人为了学习,有的人听说自动化了就要在自己的团队里搞。各有各的目的
#2 楼 @blackcherry 看你用的 idea,加 sdk 了么。idea 默认不添加 sdk 的
#10 楼 @seveniruby 加了
#6 楼 @caikaibai 谢谢~
#8 楼 @wyb199026 嗯,你说的有道理
#2 楼 @jiazurongyu 问题是很多人连最基本的封装都不在意了。
首先自动化是为了节省成本的。不论你在做什么自动化之前都要问自己,你做了自动化会节省多少成本?即便是简单的 UI 自动化,即便根本没发现几个 bug。但是你每次是不是要花时间去手动执行这些用例?心中做好权衡利弊以后,你就会有答案的。 其次,自动化仅仅在于测试。环境搭建,打包,部署,监控等等等等。如果你搭建一个环境要一天,但是如果你花一周的时间搭建好了自动化部署。以后你每次搭环境都只有 5 分钟。 权衡下利弊你会有答案的
#11 楼 @seveniruby 额。。。原谅我的懒惰。 一忙起来就有惰性了,一有时间就想歇着。。
#9 楼 @seveniruby 嗯,以后多交流。说不定以后就有好的方案了
#6 楼 @seveniruby 请教一下,研究了 spark 之后怎么应用到测试中呢? 因为我们的产品也用到了 spark,我一直没有什么好的方案。虽然知道了原理但是感觉测试上还是得从上层调用 API。现在除了调用 yarn 的 API 以外我没想到什么好的方式辅助测试了
#6 楼 @seveniruby 嗯~ 暂时不搞
#4 楼 @seveniruby 其实如果 scala 普及起来了的话,我觉得我会用 scala 的。现在换成 scala 的话实在是担心写出来的东西只能自己用。