做网站分辨率多少七牛云wordpress 代码

做网站分辨率多少,七牛云wordpress 代码,哪个购物网站最便宜,月饼网站建设01.微服务为什么需要契约测试 首先我介绍一下公司的情况。我们使用的是微服务架构#xff0c;每个部分会负责其中的几个微服务的研发和维护。我所在的部门维护公司的支付服务#xff08;billing#xff09;#xff0c;这个服务需要依赖其他部门的几个服务。 当用户需要支…01.微服务为什么需要契约测试首先我介绍一下公司的情况。我们使用的是微服务架构每个部分会负责其中的几个微服务的研发和维护。我所在的部门维护公司的支付服务billing这个服务需要依赖其他部门的几个服务。当用户需要支付一笔订单时会调用 billing 服务同时携带很多参数为了方便我们先只考虑核心的两个参数用户 id 和支付金额。当 billing 接收到用户请求时会调用其他的依赖服务用户服务user是其中的一个。我们需要查询该用户是否有足够多的余额可以支付订单。def pay(uid, amount):付款user_host app.config.get(user_server_host)user_server f{user_host}/user/{uid}/payresp httpx.get(user_server)user resp.json()if user.get(balance) amount:return {msg: not enough money}return {msg: success, amount: amount, uid: uid}user 被很多服务调用而 billing 主要想消费它的 balance 字段校验余额是否足够。user 判断如果是 billing 请求的 /user/uid 接口则把余额给它。其他的消费者请求时返回的数据不太一样。 ​​​​​def user_info(uid, src):用户信息if src pay:return {id: uid,balance: 8000}elif src manage:return { id: uid, age: 19}...某一天用户直接反馈支付出错但是我们最近都没有对 billing 服务进行任何的修改显然这个突发情况可能不是由我们部门引起的。我们只能紧急的去线上排查问题通过一系列分析终于发现是 user 服务返回的余额字段由 balance 改成了 user_balance其他没有发生任何变化。user 服务修改了代码却没有通知我们。数据结构的轻微变化导致我们根本拿不到 balance 字段所以我们的支付服务无法继续。于是我只能立马给 user 部门发邮件。在微服务的维护过程中最简单有效的测试工具是邮件。因为一个服务往往依赖于其他多个服务又被另外的服务依赖导致最后的数据流向变得跟蜘蛛网一样。可是当涉及到跨部门协作的时候沟通起来也并不那么容易。我们来看一下这么简单的一处改动会涉及到的流程。首先user 服务收到需求更改修改代码之后user 的测试人员会对自己服务进行组件测试但是 billing 调用 user 的集成测试他们没有办法测因为他们根本不知道 billing 是怎么消费它提供的数据的。user 决定通知所有的下游服务凡是使用了我这个服务这个接口的通通发一遍邮件麻烦你们各自部门测试一下你们的业务我的 /user/id 接口进行了修改可能会引发你们的服务异常。其他部门收到通知以后再针对性的测试这个接口。这些下游部门会因为一处小改动浪费非常多的时间和资源。为什么呢billing 服务是受到修改影响的所以对我们来说是必要的。但是其他的服务虽然调用了 /user/id 这个接口却并没有消费 balance 这个字段balance 字段的改动对他们不会产生任何影响。但是他们在测试之前是不知道会不会有影响的是不是浪费时间呢还有一个问题billing 部门难道不可以建立对 user 服务的集成测试吗当然可以实际上我们有专门 mock user 服务的测试也有对 user 的集成测试偶尔也会进行手工测试。但是 mock 测试、集成测试和手工测试这些测试手段都不能及时发现问题。首先我们看看 mock 测试。mock 服务器是由我们自己掌控的他的结果是不可信赖的并不能完全代替真实服务我们之所以用 mock是因为快、可控、稳定性高而且能做到环境隔离。当真实的 user 服务发生变动时mock 的数据格式并不能及时更新所以这些测试用例并不会爆红而是继续通过。而集成测试和手工测试都有相同的缺陷他们太慢了。billing 部门的整套集成测试从构建到结束需要 5 个小时手工测试一轮就更久了。也就是说我们至少需要 5 个小时才能发现我们依赖的服务发生了变化而这个问题早就引发了我们的系统瘫痪长达 5 个小时之久。契约测试是融合了 mock 测试和集成测试的综合性测试手段他把消费者 billing 编写的测试用例形成契约文件contract file放到提供者 user 端去构建。当代码修改以后提供者 user 先针对所有的契约文件构建一次测试如果所有的契约文件都满足没有造成毁约现象就可以上线了。如果有毁约则需要和被毁约方协商解决再上线。附消费者和提供者示例代码以及 mock 测试和集成测试示例代码billing server:import httpxfrom flask import (Flask,request)app Flask(__name__)app.config.update(user_server_hosthttp://localhost:5001)app.route(/pay/uid/int:amount)def pay(uid, amount):付款user_host app.config.get(user_server_host)user_server f{user_host}/user/{uid}/payresp httpx.get(user_server)user resp.json()if user.get(balance) amount:return {msg: not enough money}return {msg: success,amount: amount, uid: uid }if __name__ __main__:app.run(port5000, debugTrue)user_serverfrom flask import (Flask, request)app Flask(__name__)app.route(/user/uid/src)def user_info(uid, src):付款if src pay:return {id: uid, balance: 8000}elif src manage:return {id: uid, age: 19}...if __name__ __main__:app.run(port5001)测试代码import unittestfrom billing_server import appclass TestBilling(unittest.TestCase):def test_mock_user_server(self):app.config.update(user_server_hosthttp://localhost:5002)with app.test_client() as client:resp client.get(/pay/1/100)assert bamount in resp.datadef test_real_user_server(self):app.config.update(user_server_hosthttp://localhost:5001)with app.test_client() as client:resp client.get(/pay/1/100)assert bamount in resp.dataif __name__ __main__:unittest.main()真实的 user 服务更新后bill 服务端的测试用例如果 mock 了依赖的 user 服务测试用例会继续通过因为 mock 服务是不可信赖的。如果使用集成测试方法直接调用远端的服务不可避免的会造成测试运行很慢如果整套测试运行需要 2 个小时则会造成用户无法使用 2 个小时后才能发现问题。感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取