这个方案对 “上游” 和 “下游” 具体是怎么定义的?
这是个娱乐至死的时代。
社会公共话语权的特征由曾经的理性、秩序、逻辑性,逐渐转变为脱离语境、肤浅、碎化,一切公共话语以娱乐的方式出现。
通过电视和网络,一切都以娱乐的方式呈现;人类心甘情愿成为娱乐的附庸,最终成为娱乐至死的物种。
本条回复不符合娱乐精神。
确保团队和管理层同意并理解自动化方案的预期结果,这样大家才能达成共识!
接口用例的设计也是一项非常重要的测试活动。通过一定的接口用例设计,让我们编写的脚本更有目的性、更可靠,才能体现接口测试的价值的意义
来自一个测试小白的质问:调试前后端代码是开发的职责,要测试直接告诉你们哪里写错了,要改成什么样子,这样你们才能解决问题吗?
三人行,必有我师焉
你要再戴副墨镜,就更难认了,哈哈哈
在 k8s 的支持下,流量回放 + 全链路监控,做接口回归,压力测试都是一件很简单的事情。
并不是简单的事情,至少目前业内还没成功案例。
无论是学习 Java 还是 Python,学成之后前景都是非常好的,做做 UI 自动化,接口测试等等都可以信手拈来。
是要负责的。修改者要根据业务规则修改就能保证基础数据正确。
还是不太理解,能稍详述下或举个栗子吗?
疑难杂症:某个项目有几百个接口,需要进行接口冒烟,时间紧任务重,如何在 2 天内完成?
解决方案:用 Jmeter 编写数据驱动框架,轻松实现接口冒烟。
数据驱动框架不适用这种情况吧?
辛苦
别把面试官不当人看,问题就迎刃而解了
若认真 (或较真) 地思考,去数据库捞数据这种结果验证手段是经不起推敲的。
我第一次遇到这种事,是关于供应商信息修改接口测试的验证,几个同事采用的是根据供应商 ID 查询数据库,检查对应列是否已被正确更新。我当时陆续提出以下质疑:
仅检查修改对应列就行了吗?若其他列被意外更新了呢?
同事 A:哦,要考虑,我现在就加上!
同事 B:不需要考虑,那不可能发生!
仅检查该 ID 对应字段就行了吗?若其它字段 (对应其它供应商信息) 被意外更新了呢?
同事 A:哦,要考虑,我现在就加上!
同事 B:不需要考虑,那不可能发生!
其它已有字段也检查了就行了吗?若意外多出一条字段呢 (比如多了条空的供应商信息)?
同事 A:哦,要考虑,我现在就加上!
同事 B:不需要考虑,那不可能发生!
仅检查这张表就行了吗?若关联表未被更新或被意外更新呢?
同事 A:哦,要考虑,我现在就加上!
同事 B:哦,是有可能,但考虑那么多干嘛!
关联表也检查了就行了吗?若非关联表被意外更新了呢?
同事 A:哦,要考虑,我现在就加上!
同事 B:哦,这倒是,那是不是就不该检查数据库?!
上述 5 种情况,包括 B 认为不需要考虑的事情,后来都发生了,他的态度是逐步转变的。
所以,我个人倾向认同 20 楼观点。
Pytest 是一种基于 python 的测试框架,用于编写和运行测试代码。pytest 主要用来测试 API,但也可以进行一些复杂的测试,像测试数据库或 UI 等。
个人倾向认同@fnngj 观点:
是不是写接口自动化的时候验证数据库就万事大吉了? 数据库没问题就一定 OK ?
所以,分层自动化测试是多维度的。
UI 自动化有自己就应该 从用户的维度写考虑用例的设计。
接口自动化也应该只通过接口的调用去验证数据。
单元测试验证代码的处理逻辑覆盖。
手工(功能)测试、探索测试 也是非常重要的手段。
希望虫师参与讨论,发表高见。
@fnngj
接口测试需要验证数据库么?
https://www.cnblogs.com/fnng/p/7494682.html
接口自动化模拟的是开发的代码操作,A 开发写的接口给 B 开发去调用,A 系统的接口给 B 系统去调用,假设我是一个开发,我调用了微信的接口去做获取用户头像,有个用户获取不到,来!微信团队,你让我查查你们的数据库呗!微信肯定不答应。(数据库不是你想查,想查就给你查!)
@fnngj
接口测试需要验证数据库么?
https://www.cnblogs.com/fnng/p/7494682.html
写到哪个用例手工操作哪个,这样做比较好。一次性把所有操作手工走完,不现实。
那个工具叫 VS Coded UI
外卖骑手学编译原理的意义是什么?学了编译原理才能修够学分,修够学分才能毕业,毕业了才能肝软件,肝到 35 岁地中海才能送外卖,送外卖就能维持孩子读好学校,读好学校就能选好专业,选好专业就不用再肝软件
没必要