建议统一技术栈会比较好,减低团队整体的学习成本。
这个好像比较难,ui 控件属于表现层,可以明确抓到 xml 结构,但是接口通常都是由各种事件触发,纯探索测试的话很难模拟业务逻辑的交互,导致抓不到接口。
另外接口的请求数据构造也是一件挺麻烦的事,光请求接口不起作用呀,要数据符合业务逻辑才行。
目前见过的压测大致分单接口压测和全链路压测,一般单接口都比较费时间了,全链路更是要耗费很多时间和资源,可见压测并不简单,先专注做一件事情可能会好一些。
大概写几点吧
一、 新人文档:
项目持续 5,6 年,积累了大量的文档但是发挥不了作用,问题点很明显:①文档太多,缺乏重点;②历史冗余、废弃文档,已经没什么用处;③业务知识太偏门,新人理解不了......
关键点就在于需要一份精简的文档,让刚来的新人能看懂,能理解,能消化,抓最重要的点之后,答案就很明显了,文档一定是要和业务主流程或者行业基础知识或者职业基础知识相关的。每个公司的业务和流程都不相同,我就举一些简单的例子,比如:创建客户,补充资料,调整额度;下订单、完单;用例、缺陷管理;测试流程;工作关键规章制度等。
新人入职前几天基本都是看文档,看完这些文档并有一定的尝试之后,后面做事虽然磕磕绊绊,但不至于完全卡住,就和写代码差不多,先搭个 demo 跑通,再来优化细节和微调架构。
二、新人导师:
对于新人,初入职场,可能什么业务、制度都不懂或者了解不够细致,稍不注意就会触碰红线。职级最低,没话语权,老油条一句不客气或者敷衍的话就能让他心里记挂几天。这种情况下如果没有专职导师,大多数新人遇到问题不敢多问,害怕暴露自己的缺点或者得罪人,所以就自己瞎琢磨,浪费时间,一些简单的任务到了 deadline 却发现主流程都还卡着。
所以有必要安排一个或者多个态度积极,有责任心的老员工带新人,快速解答新人的问题,同时让新人没有心里负担地去探索问题、提出问题、解决问题。还可以安排新老员工一起完成任务,新人能完成多少任务都是其次,最重要的是要让新人在和老员工一起合作的过程中学习老员工的经验、技能。老员工在完成日常工作的同时还要带新人,一定要有补偿,可以在评绩效或者职级晋升的时候加分。
三、培训制度:
有些企业不提倡开会,不提倡搞培训,觉得员工就应该像齿轮一样连轴转,这非常不利于员工的成长和职业发展。长期下来,员工疲于工作,有空闲时间就开始报复性娱乐,没心思去成长,逐步拉低自己的上限;长期从事重复性的工作,缺乏足够的自信和能力承接高难度挑战,不敢创新,不敢突破。先是员工的落后,再是团队的落后,一直到公司、集团,最后是一个行业的没落,我也待过传统企业,深有感触。
不管再怎么忙,一定要花时间搞培训,做分享,可以是业务知识、测试方法、工作流程等方方面面的分享,让员工有时间能停下脚步来拓展自己的眼界和思维,磨刀不误砍柴工,养兵千日,用兵一时。这一点很感谢我的第一任主管,他在我们业务不忙的时候让每个人都去讲自己分工部分的内容,包括基础概念,业务,测试方法等,我听得最认真,我作为一个刚入行的新人,大半年时间就在行业知识的广度和深度上超过了部门大部分人。他给我留下最深刻印象的一句话是 “不要让自己有不懂的”,当然人做不到全知全能,但是可以做到解决每一个遇到的问题,理解原理,搞清楚每一个遇到的知识点,我虽然履历并不出彩,但是面试从来都是裸面,熟悉的问题我能讲清楚细节和原理,不熟悉的问题也能答个大概。
解决方案太多啦,想一百步不如踏出一步,可以慢慢尝试去着手做这件事,方法总比困难多,人多力量大,多听听新人和老员工的反馈,多思考,多践行,体系慢慢就建立起来啦。
飞哥之前的 UI 自动化文章都仔细品读过,理论 + 实践完美结合,读完后理清了许多概念,了解了许多能解决痛点的解决方案。这次的文章也是一样,分层清晰,组件层有创新且能解决痛点,最难得的是能去改善传统的架构,总结经验并分享。这些优质文章,对于我这样写了几年代码,各方面都有涉猎但水平局限于熟练/精通的人来说,作用非常大,些微思想上的启迪和论证比写几个月的项目还有用。
最近自己也在写一个接口自动化 + 数据工厂结合的项目,分层也几乎差不多,传输层做各个系统的传参、鉴权等,对应组件层,接口层对应 PO,服务层差不多一样,之上还有测试用例层和数据脚本层。
组件层的主要功能已经讲解得比较清楚了,定位以及常用功能。是利用组件的特征以及传入关键参数去定位,常用方法的话就是避免在 PO 里面写太多控件操作的方法,就直接把操作方法写到组件层,比如一个 Form 的填充、提交,Table 的数据获取,排序,切换分页,筛选等等,把 PO 里面有关组件的属性获取和操作方法等下沉到组件层。
仔细读一下 error msg,报错是讲 desiredCapabilities 这个配置不对,里面的 noReset 字段只能为 boolean 类型。
每天的工作就是培训、学习、写用例、评审、测试、站会
投了多家简历后,最终去了一家外包公司做 SDET(测开)
10 多年前,能有这么完善的流程,又能找到测开岗,感觉前两份工作还不错。。至少让自己有机会见识更多的东西。
各个阶段的公司都待过,情况还是比较符合。
postman 可以写 js 代码呀,在 Pre-request Script 里面先清除 cookie 就行
没事,我也是早上没事写点片段热热身,能解决您的问题真是极好的。
格式怪怪的,如果没有特殊需求的话,建议直接用 json 库转,格式有略微不同的话,稍微调整下格式再转。
自己随便写了点转换的代码,不敢写下去了,再写就要造一个 json 库轮子了。。
import json
text = "Lindar = \"text=light, position = True\", num=10, check_condition=False, Timeout=1000"
def split_text(text: str) -> list[str]:
start = 0
pieces = []
is_in_string = False
for index, char in enumerate(text):
if char == "\"":
is_in_string = not is_in_string
if char == "," and not is_in_string:
pieces.append(text[start:index])
start = index + 1
# 添加最后一段
pieces.append(text[start:])
return pieces
def combine_key_value(pieces: list[str]) -> dict:
pairs = {}
for piece in pieces:
for index, char in enumerate(piece):
if char == "=":
key = piece[:index]
value = piece[index + 1:]
key = key.strip()
value = value.strip()
pairs[key] = value
break
return pairs
def type_convert(text):
pass
pieces = split_text(text)
pairs = combine_key_value(pieces)
print(json.dumps(pairs))
你想知道的是 max_loc...这几个参数是什么意思吧
这个是模板匹配方法,用小图在大图里面匹配最佳位置
loc 是 location,表示坐标,max_loc 是最佳匹配坐标,min_loc 是最不匹配坐标
val 是 value,也表示图片匹配度 (置信度),范围是 0~1,越接近 1 说明匹配度越高,这里最大是 1,也就是匹配出近似原图
你得到的返回值样式和参考样本区别不大的,取 max_loc 就行,前提是 max_val 至少大于 0.8,另外需要注意的是模板匹配得到的坐标是图片左上角的点,不是图片中心点,点击的时候需要注意一下。
随便贴一个模板匹配的帖子 => https://zhuanlan.zhihu.com/p/106906613
如果真要使用图像处理的方式来做 UI 自动化,建议先掌握 python 的 PIL 和 opencv
用自己最擅长的语言吧,不然会耗费很多时间在熟悉语言进阶知识、理解三方库和框架上。个人更偏向于 python,实现同样的功能,可以做到少一半代码且更简洁易懂,也更灵活。
啊喂,类里面的函数叫方法,init里面的变量叫实例属性>_<
是我的话可能会这样去做:
上面的图片简单,识别不了多半是背景太花哨,用二值化就可以搞定。文字是接近纯白,用二值化可以把图片处理成背景纯黑,文字纯白的图片,可以参考下面的文章
https://blog.csdn.net/bosszhao20190517/article/details/105837566
开放平台是指百度云、腾讯云等免费的 OCR 识别 api,一样的调接口,传入图片,然后识别结果,因为基于深度学习,数据集比 pytesserct 大,且是国内环境,中文支持更强,效果会更好一点
看你具体是要做什么操作,如果是找控件、点击之类的自动化操作,可以了解下模板匹配、airtest 之类的
能贴一下识别的图么,一般正常字是没什么问题的,识别不了的话可以调调 pytesseract 的配置参数或者对图片做预处理 (二值化、降噪等等)
另外要看具体使用场景,看是否需要使用 OCR,有可能其他的方式也能做
另外还有其他 AI 开放平台的 api 可以用,识别中文应该比 pytesseract 更好一些
是 bug,既然前端都做了删除禁用,业务逻辑上当然是不能删除订单的,后端也要保持一致,只是后端没有去做这样的校验而已。健康的系统是必须前后端都做好校验的,可以反馈给开发,看他改不改,正常来说改一下也没有多大难度。如果是内部使用的工具,他也不想改,风险可控的话,可以抛出来让研发组长之类的人去做决定,看是否需要修复。
楼上讲的取小数乘 1000 之后取整是 ok 的,另外还有一种办法,随机生成 0~N 的数,可以用随机数对 N 取余,这里是 (0, 1),数值比较小,就可以先扩大 10000 倍再对 1000 取余也是可以的。
通过调节模板图片尺寸的方法来适配不同分辨率并不好用,以前的团队几年前就试过这个方法了,当图像场景复杂时,很容易出现既没有匹配到目标元素,还因为改变了尺寸,匹配到了其他不相关的元素,更加影响报错分析。
通常不同图片在不同分辨率的变化是相同的,可能会有几种变化规律,只要对这几类变化规则进行总结,根据当前分辨率来对模板图片进行调整,就可以实现一张模板图用在不同分辨率上,比增加步长的方式更稳定。
总结来说就是寻找变化的规律比瞎猜更有用。不过近几年 CV 发展挺快的,特征匹配和物体检测同样可以对模板匹配进行补充。
没做过类似的测试,不过可以写写自己的思路。
1.可以实现翻译库到 xml 文件的自动生成,按理说翻译库和 xml 文件都是有固定规则和模式的,开发没必要全部手动写 xml,这样只要自动生成的工具没问题,那翻译库和 xml 就永远是对应的。不再需要测试 xml 文件,只需要关注翻译库。
2.同样利用翻译库和 xml 的规则,分别对翻译库和 xml 文件进行解析。再对比两边的数据,断言文本的个数、key,顺序以及对应的翻译值,和接口参数对比测试很像。
Template 类看起来像是读取本地图片然后转换成像素矩阵,也可以尝试重写 Template 类实现读取网络图片流,不过还是建议用本地文件夹来做缓存,全部从网络下载很容易受延迟的影响