第八点: 场景通常发生在 H5 页,需求只有前端页面(大部分是旧页面改皮活动),后台数据拿的旧接口或者其他项目组的。转测只有前端页面,开发转测时会附带 mock 数据模板 eg:
{
"user": {
"id": 1,
"name": "test",
"years": 25
}
}
实际上旧的接口可能已经发生了变化,新的返回数据是
{
"person": {
"userId": 1,
"fullName": "test",
"age": 25
}
}
前端这边按照旧的数据进行调试,告诉你也是旧接口,如果没有踩坑经验的就会用他给的这个旧数据模板去测试。那上了体验服或者现网就会因为结构不同,产生代码错误、页面显示问题、逻辑错误
是不是你本地的 adb 和模拟器的 adb 冲突了
import os
import fnmatch
def find_files_key(keyWord, dicretory='.'):
matching_files = []
for root,dirs,files in os.walk(dicretory):
for file in files:
if fnmatch.fnmatchcase(file, keyWord): # 不区分大小写用fnmatch
file_path = os.path.abspath(os.path.join(root,file))
matching_files.append(file_path)
return matching_files
#test
keyword = "1.py"
directory_to_search = "./"
result = find_files_key(keyword, directory_to_search)
if result:
print("匹配到的文件:")
for file_path in result:
print(file_path)
else:
print(f"未找到包含关键字 '{keyword}' 的文件。")
os.path.abspath(path) 该方法返回指定路径的绝对路径
有个和自己磨合至少一年的开发很重要
卧槽,真的他们可以接收进去学习的人吗? 哪个地区的公司,有 JD 看下吗
机会和风险并存,虽然看起来是坑
不会的,Java 的不知道怎么弄,但是普遍是用 pytest 的话,fixture 是可以创建测试环境的前置条件和后置条件,确保每个测试用例都在独立的环境/测试数据中运行。pytest.mark.dependency 和 pytest.mark.dependency(depends) 标签,可以指定测试用例的依赖关系。至于维护,其实也是用 yaml 写的测试数据,差不多的
不是纠结于哪种语言,只是看到原来用 Java 实现的接口自动化和 python 实现的差不多,但是代码居然能多出这么多感到惊讶
你应该反过来说
学习了,好强
肯定的 毕竟你永远也想不到会遇到什么性格的开发/产品/领导/老板,有个过了磨合期的开发/产品,才可以少踩坑。否则真的防不胜防
类似一个最基础的项目结构和配置。类似 “npx create-react-app react-basic” 的指令,就会生成一个基础的 react 项目结构文件,你可以直接去上面写和改
java 我只是略懂,虽然看结构图感觉很高大上,但是细看下是不是就是比较通用的【yaml 数据驱动方式自动化测试】: 用 python 可以省至少一半的代码
只看了 Demo 的 testcase,你的思路大概是 先创建了一个 Request 实例,用于发起请求。然后,通过 doRequest() 方法发起请求,获取响应。接着,从响应中获取一些信息,如 HTML、请求头和 Cookie。然后,创建了一个新的 Request 实例,用于发起另一个请求。通过 addHeaders() 和 addCookies() 方法向请求中添加请求头和 Cookie。最后,通过 doRequest() 方法发起请求,并使用 assertThat() 方法进行响应状态码的校验
在参数化测试方法中,也是先创建了一个 Request 实例,用于发起请求,通过 setParameter() 方法向请求中添加参数。接着,通过 doRequest() 方法发起请求,并获取响应。最后使用断言方法进行响应状态码的校验 中间还有使用读取 excel 文件作为参数数据源。
如果用性价比平替的方式,我建议还是用 pytest ,第一种方式使用 python Request 的 Session 对象发送请求。第二种用 pytest 的@parametrize装饰器为数据提供参数化测试,然后还是用 assert 语句断言检查。数据驱动的方式也是 yaml 文件,就用 pyyaml,测试报告用 allure
不需要吧,一个吐槽帖,没啥技术含量
感觉可以按照一条回归用例 1 分钟的执行速度算,多少条自动化用例就减少多少分钟
是的,有前端基础上手是挺快,但是很多人争着要,转行还能要的 20K.。。。。就这个太离谱了,我了解了下市场,boss 上没多少 qt 的岗位。。。。。
需求量大吗?
她说的 qml 查了下,的确是用的前端技能可以快速入手,但是她说能拿到 20K+ ,我就觉得挺魔幻的
不是呀,刷脉脉看到的,想着是不是信息差,生怕错过这等好事
我也感觉,看底下评论,感觉这个楼主好像煞有其事一样。真的挺扯的,qt 基本嵌入式开发都会学,但是专门岗位给一个 31 岁转岗的前端 20 几 K,怎么想都离谱
老开发写时会比较鸡贼,有些产品没提,虽然他知道但是他不写,新开发比较积极去对业务 但是因为理解不同,导致功能实现跟测试理解的很不一致。测试这边测试时,要么背用户投诉 bug(业务点遗漏),要么就是跟新开发不断吵
测试工作中大部分难题都是这个,重大技术 bug 现在还没遇到过,大部分感觉都是边角料 bug
自动化除了你写了多少条自动化用例拿来生成个柱形图外,基本没法量化吧? 根本不指望它能发现多少 bug 的。我工作价值就比较容易写,直接写了全年写了多少测试用例,发现多少 bug,测试了多少项目........虽然很多大佬看不上这个指标,但是的确是量化的好数据
只有一个前端一个后端,加我一个测试,没项目,就干杂活,有测试项目了,只需要点点点,不需要用到深圳那么多技术,也不需要数据库命令,更不需要自动化
好羡慕这种状态,这才是工作的本质
这个工具除了证书不好用之外,其实已经是能满足大部分需求了