有个测试技术交流群,写文章建的,遇到问题可以加我微信 dongfangpy 交流,也可以备注加群,一起学习讨论呀。
TesterHome 社区本身也提供了很好的平台,跟帖提问我也都会来看的,我也在这里学到了很多东西。
应该是后端改。我试了下用 requests 请求我写的 django 接口,也没有这个问题。
url 规定的编码为 ASCII 码,像中文等 gbk 字符需要编码为% 十六进制格式进行传参,如果参数里面直接写=,解析时会认为后面是参数值,导致后端报错,我是这么理解的。试一下把参数值里面的=转义,写成%3D
url 出现了有 +,空格,/,?,%,#,&,=等特殊符号的时候,可能在服务器端无法获得正确的参数值,如何是好?
解决办法
将这些字符转化成服务器可以识别的字符,对应关系如下:
URL 字符转义
用其它字符替代吧,或用全角的。
《学习版 pytest 内核测试平台开发万字长文入门篇》已发布,访问地址:
https://dongfanger.gitee.io/blog/chapters/teprunner.html
一共有 103 张截图,搬运有点麻烦,等有时间再同步到社区来。
源码前端 https://github.com/dongfanger/teprunner-frontend
源码后端 https://github.com/dongfanger/teprunner-backend
《学习版 pytest 内核测试平台开发万字长文入门篇》已发布,访问地址:
https://dongfanger.gitee.io/blog/teprunner/002-pytest 内核测试平台开发万字长文入门篇.html学习版
一共有 103 张截图,搬运有点麻烦,等有时间再同步到社区来。
为什么还需要有个 is_need 判断是否需要上个用例的返回数据?
比如check_results(r, expect, check_method=1)
,check_method=1
是什么意思并不清楚。你截图出来的这部分代码,看不到用例是如何组织的,也不知道为什么再调一次接口,还需要在 conftest.py 增加很多代码。如果能重新组织下用例,也许你的疑惑会迎刃而解。
一条自动化用例可以包含多个接口,上个接口的数据应用到下个接口是很正常的,可以了解下 JMeter 的 “关联”。
接口自动化本质上是用接口重新做一次手动执行的用例,只是方式变了下而已。如果 1 条用例是走主流程,相应的接口自动化用例,会包含主流程涉及到的所有接口。如果 1 条用例是某个模块的特定场景,那么就会涉及到这个模块的接口。
同一个接口,一般会重复存在于多条自动化用例中。如果复用率很高,可以抽出来,如果复用率不高,或者参数差异比较大,保留一定冗余,提高可读性和共享性,也是可以的。没有必要为了封装而封装。
建议别定义这么多中间函数,像这样平铺写法不是更直白么:
多个接口 -- 增删改查
import jmespath
from loguru import logger
from tep.client import request
def test(faker_ch, login, url):
fake = faker_ch
logger.info("新增")
nickname = fake.name()
phone = fake.phone_number()
response = request(
"post",
url=url("/api/users"),
headers=login.jwt_headers,
json={
"nickname": nickname, "phone": phone
}
)
assert response.status_code < 400
user_id = jmespath.search("id", response.json())
created_at = jmespath.search("createdAt", response.json())
updated_at = jmespath.search("updatedAt", response.json())
logger.info("查询")
response = request(
"get",
url=url("/api/users"),
headers=login.jwt_headers,
params={
"page": 1,
"perPage": 10,
"keyword": nickname
}
)
assert response.status_code < 400
logger.info("修改")
nickname_new = fake.name()
phone_new = fake.phone_number()
response = request(
"put",
url=url(f"/api/users/{user_id}"),
headers=login.jwt_headers,
json={
"id": user_id, "createdAt": created_at, "updatedAt": updated_at,
"phone": phone_new, "nickname": nickname_new
}
)
assert response.status_code < 400
logger.info(f"用户姓名手机 {nickname} {phone} 修改后 {nickname_new} {phone_new}")
logger.info("删除")
response = request(
"delete",
url=url(f"/api/users/{user_id}"),
headers=login.jwt_headers
)
assert response.status_code < 400
“让我不要东想西想把测试设计这块拿下,以后往管理岗位转。”
这句话非常有共鸣!在工作这些年,别人对我说过这句话,我也对自己说过这句话,最近有个技术 leader 试图跟我说这句话,被我拒绝了,因为我要转测试开发。我曾经相信了这句话,放弃了技术学习,专搞项目业务测试那一套,等到跳槽时才看到差距。视野内的管理岗很多也都是技术大牛担任的,不搞技术未来发展会越来越窄,这不是说业务不重要,业务是开发和测试共同的基础,只不过测试相对来说技术积累少很多,导致容易迷茫看不到成长,换家公司就没用了。千万不要被别人定性了,也千万不要听所谓过来人,尤其是非测试的项目管理者的言论,有时候他们只需要听话的工具人而已。我也喜欢东想西想,现在除了想还在做,多实践,多写代码,多看看机会,把视线从公司放到整个市场来。
实在不喜欢测试,完全可以转开发,身边就有个妹子,也是被调到做测试,结果实在受不了点点点,转 C++ 了。
从生态来看,Java 无疑是不会后悔的选择。
奥你的问题是,经过参数化后的多个子用例,在分布式执行时,如何按顺序执行?这个貌似没有办法吧,分布式本来就是并行的,并行又要保证先后顺序。
分布式执行用例的设计原则:
用例之间是独立的,用例之间没有依赖关系,用例可以完全独立运行。【独立运行】
用例执行没有顺序,随机顺序都能正常执行。【随机执行】
每个用例都能重复运行,运行结果不会影响其他用例。【不影响其他用例】
.py 文件内部的执行顺序就是从上往下的吧,具体问题能再描述下么?
分布式执行用例的设计原则:
用例之间是独立的,用例之间没有依赖关系,用例可以完全独立运行。【独立运行】
用例执行没有顺序,随机顺序都能正常执行。【随机执行】
每个用例都能重复运行,运行结果不会影响其他用例。【不影响其他用例】
开源估计要等到明年了,哈哈,到时候应该会写个系列文章来从头做个偏学习的版本。
其实现在就是用 Git 管理的,走的 Pull Request,审核后再合并到主干分支,要做成平台是因为每个人的本地环境同步会稍微有点麻烦,开发也有跑用例造数据需求,平台能忽略这些问题,上手就用。还有一个重要原因是公司需要,领导需要,就找了这个折中方案。1 条用例是放在 1 个 test_name.py 文件来写的,就是为了避免多个文件依赖混乱的情况,这一点借鉴了 httprunner 一个 yaml 文件一条用例的做法。如果要改别人的用例,可以先复制用例再修改用例,避免影响别人使用。
好的,我试试,感谢建议,哈哈。
是的,部署没有说,前后端代码是放在 BitBucket 上面的,Drone 是 CI 工具,会轮询 BitBucket 的 Pull Request,自动拉取代码打包成 docker 镜像,通过运维平台配置域名和 Nginx 路由后,部署 image 到 pod,这一套是直接用的公司流程。K8S 这块确实可以优化下。
转成字符串
感谢各位大佬指点。已经和几个负责人沟通了,先解决项目估时问题,把 Story 和 Bug 收敛起来,严格控制发版代码质量,借助 Jira 统计评估是否发版,当收敛到个位数,主流程回归 ok 情况下,出测试报告,澄清测试内容和遗留问题。
再试试这条命令
pip install --default-timeout=6000 -i https://pypi.tuna.tsinghua.edu.cn/simple tep
现在开发想法是测试出报告,线上有问题,报告没写就是测试担责,测试写了就是开发担责。这个做法很慌
是的,初创团队,问题一堆。
每次发版三十个 Bug 没改,十几个 UserStory 没有彻底开发完,你们应该不是这个情况吧
测试报告 测试总结 这是要写 2 份文档
这么夸张 好累