占个沙发。
最近这一年我越来越重视业务,回归业务,拥抱业务。直到现在我都是手动测试的一员。我们不区分手动测试和自动化测试,我们都是业务测试。让业务逼着我们优化工具,让业务逼着我们把自动化做的更好。
不能同意更多,自动化本身也只是质量保证环节里面的一个工具而已嘛~
1.令人尊敬的 Hacker 或技术专家,在应用开发或测试领域有丰富的经验;
好吓人
解码试试~
如果是 browserstack 之类的云测试平台的话,应该可以用启动多台实例的方式完成在不同机器上执行不同用例的功能。而且还外加各种浏览器和系统支持哟~
同意题主,单元测试用 CI 工具来保证执行,并且第一时间解决红掉的部分。
记得某厂同事曾分先过他们的单元测试覆盖率每到领导检查的时候,就启动单元测试覆盖率提高工具跑一遍,覆盖率过了领导检查就完了。
然而这样的测试意义有多大呢?另外产生大量的单元测试,执行时间过长的问题如何来解决呢?
所以我觉得还是需要一个有经验的 tester 来合作,单元测试以业务为导向来做,有些做,有些不做,取决于测试策略如何。
仿佛回到了过去的公司,原来我们大家都是这样子过来的。
奔泪。
那么问题出来了,记得以前在这个模式中用了大量的时间撕产品撕研发,成了典型的白天上班开会,晚上加班干活。
然后干活得过程中各种通不过打回去给研发,浪费了太多时间。
拍个砖,如何来减少时间浪费捏~?
不知道这个准不准
好贴~
#5 楼 @lihuazhang 不错不错,我喜欢主页上的 Koa 的字体~
#3 楼 @lihuazhang 还有啥好玩儿的推荐没..?
前来膜拜
年轻的时候也是北国大侠。。
刚开始的时候也觉得测试的方向应该面面俱全,什么都需要了解,但是不一定要深入理解 (那是研发的事儿),做这样的"全栈测试"。
后来发现这样的知识结构在项目刚启动的时候很好用,但是一旦到了需要解决问题的阶段了,你的价值就小了。
然后开始尝试走深入技术的路线,结果还是一头雾水:性能啊,安全啊,移动啊,从单元到 E2E 各种层次的质量保证手段啊。太多太杂太混乱,我好迷茫我好方。
接着发现做了这么久的测试,测试经验也在不知不觉中积累了起来。有的时候新需求过来,研发一确定方案,你就知道哪些地方会踩坑需要重点测试了。甚至有的时候需求提过来大家还在看需求的时候,你已经发现需求里面的坑了。
回过头来分析一下,发现这些经验之所以能积累起来,是因为我的技术经验和领域经验都在慢慢积累中,当这些东西积累到了一定程度,就能 “未卜先知” 了。
所以多了解技术重不重要?当然重要,不懂技术你怎么总结针对 xx 类型需求的解决方案哪儿有坑哪些是 best practice?
业务重不重要,我觉得对测试来说业务更加重要。测试的核心竞争力我觉得应该是保障这个业务是有"价值"的,所以对于需求你也是需要测试的。有些需求莫名其妙反架构反人类甚至,这种需求直接打回去。算了还是好好跟产品经理沟通一下吧。。
但是如果换了个公司之前积累的业务知识不就白积累了么?并不是。首先前面说的业务只的是领域知识,换公司不一定换领域吧?
就算换了领域,在之前积累业务过程中你积累到的除了业务,一定还有如何积累业务知识的经验。这些经验能帮你在新的领域快速建立你的知识体系。
现在这个阶段,有幸在一个敏捷团队中工作,享受着公司从上到下都信奉"质量是全员的事情"氛围,研发十分重视质量,UT,集成,E2E 一个都不少,部分项目坚持 TDD。我自己也参与到 UT/IT/E2E 各种 T 的 review 中,所以拿到手上的东西很少会出现 BUG。自己也有更多的时间去思考,去做探索性测试,去实践新的知识。
所以比起全栈测试工程师,我更赞同全站测试工程师,站起来多走动,多发挥你协调沟通的又是,推动全程和全员测试。
#5 楼 @seveniruby 明白了,下次注意~
正应了高中政治老师讲的那句话:所有不符合历史潮流的东西,不管他怎么挣扎,最后都会归到潮流中去。
感谢!
这总结写的好,从中我也找到一些方向,得到一些启示。
先收藏
感谢作者分享,好思路。
不过有个问题,就是最后"性能测试 - 时间"的图里面还没怎么看明白: 180 线程时,max time 差不多快到 80 了,min time 目测是 0,那 avg time 才不到 10?
#1 楼 @seveniruby 就知道这种帖子发到这里会被各种吐槽..选工具的code..