问题是您说的这些:
感谢大家给我的回复,下边是我通过大家的回复总结的我个人想要研究的点
1、研发流程中的改进
2、如何挖掘测试人员的价值
3、为什么有的团体队还需要测试,怎么让他们成长的不需要测试
4、接口自动化
5、开发方案多参与,对于用例和测试能更全面
6、性能,安全
7、调研不需要测试的开发人员看看他们是如何做自测的,是否需要测试人员提供协助
哪个开发或者架构师不能做?放弃幻想吧,这个高水平的团队里面测试就要和开发开发能力相当才行。否则连他们讨论什么担心什么都不知道。
小公司测试开发比一般开发要求高了,往往面对的问题是:
所以做起来很累,小公司一般基础设施不太好,大公司可能也很累,系统繁多而复杂,各个组都是小山头,沟通很费劲,另外每个组的惯性思维方式也不一样,谈需求的时候需要尽可能的适应不同的说法,抽象不同说法里面的共性。嗨,苦苦苦。。。。
大部分问题不准备能回答出来,但是有啥用呢,年纪太大,不要。
突然发现这个和我很久以前的框架其实思路差不多的, http://testerhome.com/topics/3690
其实都不需要打包放 jenkins 的,直接使用 maven 命令就可以跑了.
有一点不明白,既然 UI 变化很大,不停的变,录制一边变化和实际做一次测试的区别是啥呢?
个人觉得 AI 测试也好,自动化测试也好,如果要真的要完全自动化,那么最终都会 AI。我举个例子来说,在测试行当很多人其实对 selenium 做自动化测试有很大的质疑,但是其实现在有些什么 RPA 工具也在用 selenium,可能都是用在实际商业流程中。目前的自动化实际上大体上把手工测试的内容用代码实现,如果和 AI 代表的自动化来说,这都不能算是自动化,AI 测试是推导,可以根据历史自运行,自己解决问题;但是如果 AI 能测试了,那么代码也都可以自动写了,个人观点. 这应该还是有很长的路好走。我觉得测试开发也好,测试也好,对于大部分从事这个工作的人来说,就一件代码熟练这件事情能达到的比例熟练这个程度的都不多。 我们大部分人都低估了代码熟练度这件事情;同样关于提效这件事情,我们也低估了沟通和协作的重要性,看着产品经理说的是一套语言,开发是另外一套说辞,测试也有一套语言,其实可能说的都是一件事情,你一份文档,我一份文档,写了很多文档,但是为什么一件事情要这么多文档,为什么写了这么多文档,还是很多人说没有文档,同样为什么开了那么多会议没有一个统一的,结构化的,清晰的需求也好,说明也好,指导也好;这是为什么? 反正我对我们团队的要求就是, 代码熟练度/沟通总结能力是不能少的,其他什么平台也好,工具也好,一点点加,需要就加;代码熟练了,加点功能就应该顺手写出来,代码熟练了,写接口调用的代码就应该顺手写出来;沟通顺畅了,抓到重点了,一件事情就不应该一遍又一遍的重复.
我觉得或许以后有议题说如何让忙碌的测试同样可以达到代码熟练这个简单又不简单的目标.
有很多的内容都不错,但是又是一看代码就觉得有时 ppt 说的是不是过头了。举个例子来说: https://github.com/alibaba/intelligent-test-platform 这个以前 alimama 分享出来的测试平台,但是代码质量真的......,如果开源出来的测试工具代表业界的一定水准,那么我觉得 alimama 这个代码,让我对所有分享的高大上内容产生了怀疑。
比如说对接能不能通?配置配的对不对等等等,大体就是这个事我做完了,配置也改了,对接也做了,但是不知道对不对。需要测试去测试下,当然自己还没有试过。
一般启动看到类似:
java.lang.NoSuchMethodError: org.yaml.snakeyaml.LoaderOptions.setAllowDuplicateKeys(Z)V
这种 NoSucheMethodError 错误基本上都是 java maven 依赖的问题.
可以使用 mvn dependency:tree > depenency.txt ,再仔细检查一下有没有重复依赖的包,同时版本又不一样的.
不抢 KPI,但是想分别人如果 KPI 获得的好处呢?
我很赞同你的想法 @hellohell ,多谢 @ 恒温 @ 陈恒捷 大佬,这块我自己也想到一些问题:
到底这中 Diff 平台带来了多大的提升?
继续请各位大佬帮助回答。
但是接口测试不是比 UI 自动化容易吗?
很多英语文档要看的,英语学好没坏处。看文档看的快,做事情就快。
“CBU的一次大促,运营人员至少需要配置千级以上的活动页面,而每一个页面上又包含几百上千个商品等活动元素,平均一个页面需要5到10分钟的人肉检测,同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来,我们至少需要十几人/日的测试资源才能保证会场的正确性。”
说实话不太明白为什么运营人员要和测试人员不断测试标准和 Bug 来回讨论,测试要是花 10 多天检查会场页面的显示的正确性,其实测试人员也很贵的。如果运营人员不够,没有办法支撑大型活动,那么要么产品还有很大改善空间(或者确实有很大难点不好突破,或者其实就是短期就是没办法突破了),要么就是通过流程,在短时间内增加外包人员。 但是和测试有多大关系?不过本人呆过的大部分公司其实也都是这样,缺人的时候就找测试帮忙。
这东西写的都很好,但是可能一看代码就把人吓死。就像 alimama 前面开源的一个什么智能引擎。这东西有点不明白的就是运营上传一个文件不能预览一下吗?这么费劲搞了一大堆,都不知道面对的具体问题到底什么
“CBU的一次大促,运营人员至少需要配置千级以上的活动页面,而每一个页面上又包含几百上千个商品等活动元素,平均一个页面需要5到10分钟的人肉检测,同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来,我们至少需要十几人/日的测试资源才能保证会场的正确性。”
这种东西到底是产品问题还是测试问题?实在是很难说。
另外这个架构要是追查什么实时质量数据能扛住,那是见鬼了。阿里一天的数据量要这个结构能扛住,我觉得有点不可思议。
自动化的难点就是这个,需要测试接口 8,结果需要把 1-7 的接口都调用一次。然后各种环境问题,各种团队合作的问题,各种不稳定的问题。不是自动化本身有多难,而是你需要把周边的各种事情安排的妥妥帖帖。生活是真艰难。
稍微杠一下,httprunner 和 unittest,pytest 这种其实不是在一个层面的框架,放在一起不合适
我现在遇到这种情况是没啥好抱怨的,抱怨没用,不如多沟通把文档自己整理出来了,大部分的公司都这样。换公司也是也好不到哪里去。测试的悲剧也在这里,做了很多没人看到的事情,测好了应该的,测不好就是你的问题,要么解决这个问题,要么就换换地方或者只职位。公司大部分人都是开发,开发就是不太想写文档,你要说服大部分人,那很难。
都很好就是公司倒闭了
讨论了这么多 我觉得关键一条 这是测试不是测试工程师这个完全不等同的 现有测试工程师如果不升级 路越来越窄 如果一个团队四个人三个开发 一个测试 那么测试的工作可以悄无声息的可以被三个开发人员平分 说到底那些价值可以不容易呗替代
其实大部分的 app,网站,后台服务等等,也就是这些吧
maven pom 文件里面添加 commons-math3 的依赖再看下
反正我不觉得反复看了几次语法就算入门了,至于说什么 1 年才能入门我也说不上,我主要意思是就是既然都想提高,又不在提高的方向上投入时间,那么只会越来越焦虑,而不会发生任何变好的情况。