渗透测试,会拿给测试工程师来做么,感觉大部分都是安全工程师的职责范围了。技术门槛太高,对于测试来说要学的东西太多了,假如想要深入渗透测试,不应该从测试入手而应该从安全入手哦。
API 自动化用例 3200+,核心项目覆盖率平均 85% 以上;
这个数据很给力啊,终于在用户案例看到有这么多量的了,希望后续案例能分享下具体的技术方案,给大家提供下方向。
excel,仍然是不太推荐的编写方式,尤其是对于 pytest 测试框架 来说。建议直接写代码更好(tep 提供了一套实践教程);如果想无代码,建议看下 HttpRunner。
1、接口用例直接写在代码里面,一个用例一个函数,这种能更多的使用 pytest 的功能
推荐采用这种方式,详细教程可参考:
https://dongfanger.gitee.io/blog/%E6%B5%8B%E8%AF%95%E5%B7%A5%E5%85%B7/000-%E3%80%90%E6%9C%80%E6%96%B0%E3%80%91tep%E5%AE%8C%E6%95%B4%E6%95%99%E7%A8%8B%E5%B8%AE%E4%BD%A0%E7%AA%81%E7%A0%B4pytest.html
开发一会发一个包一会发一个包
一:跟开发协商,每天固定时间发包,保证测试工作顺畅;二:隔离一套单独的测试环境,自己玩;
我都坐到开发旁边一个一个指着让他改
坐到开发旁边这个是常规操作,便于高效沟通。但是指着改的做法不是很可取,因为这样很容易让测试角色变成保姆,反而不利于提升质量。建议记录 bug,提出 bug,让开发修改 bug,开发自测,再做 bug 验证。
teprunner 测试平台 10 篇原创 PDF 教程发布
下载地址
链接失效的话请到公众号领取哦
应该没这么麻烦,我遇到几次都是因为打开了 charles。
@pytest.fixture(autouse=True)
def build_url(env_config):
def host_path(path):
return host + path
return host_path
把 build_url 也定义成 fixture,传参 env_config,再 autouse:
@pytest.fixture(autouser=True)
def build_url(env_config, path):
teprunner 的 model&serializer&view 设计说明/
录了个视频专门回答下这个问题:
def test(env_vars):
print(env_vars.domain)
pytest 的 fixture 必须作为函数参数才能被引用。
怎么引用的哇
可以看下我的这个视频,里面有演示:
下载 sqlite3.dll 文件替换下,就可以了。
视频演示 -- 接口自动化项目用例组织设计/
teprunner 测试平台视频演示及未来规划:
pytest+tep 测试工具 +teprunner 测试平台在我司落地效果良好,大家也可以试一下,欢迎技术交流,感谢支持。
teprunner 测试平台视频演示及未来规划:
pytest+tep 测试工具 +teprunner 测试平台在我司落地效果良好,大家也可以试一下,欢迎技术交流,感谢支持。
还有一个办法是用__FileToString
把文件读取成字符串,再 split 处理下。
你的需求是每个迭代都要一次性产生 2000 个 id 放到请求体的列表中进行请求;而 JMeter 组件参数化的逻辑是每个迭代取一行数据不能取多行。
需要区分下。
你这个是每次从第 n 列取第一行的数据
jmeter 组件没有能实现这个需求的,只能自己用 beanshell 写 java 代码。
测试瓶颈确实很低,这是客观存在的现实,也是对于大部分测试人员而言,无论从薪资待遇还是发展机会,都会切身感受到的。这跟自我要求无关。
为了突破瓶颈,提高天花板,测试行业目前就是在尽量往开发技术上靠,尤其近几年测试门槛在逐渐提高。测试厉害的人,一般会认为他技术很厉害,而不会说他测试思维很不错,测试很细致。技术成为了测试进阶的主要渠道,所以会有那么多的工具和平台,反复造轮子也乐此不疲。
测试计划、测试报告等流程性的产品,一般就是使用禅道、Jira、Confluence、Trello 等来做,测试流程一般是依托于研发流程的,敏捷开发追求的是小步快走,相比于传统行业的项目交付物,没有那么正儿八经的规范,自然这块要求就变低了,甚至有些团队都不想写这类文档,比如 Jira 看板就是测试计划,一目了然,没有必要再去写个多余的 Excel。