测试自动化

前言Postman 版本 10.13.6qbit 将 RSAForPostman 压缩拷贝到了码云便于国内拜访Postman 脚本示例Pre-request Script if (!pm.collectionVariables.has("forgeJS")) { pm.sendRequest("https://gitee.com/qbitoy/public/raw/master/forge_rsa_min.js", function (err, res) { if (err) { console.log(err); } else { pm.collectionVariables.set("forgeJS", res.text()); } })} else { var moment = require('moment'); eval(pm.collectionVariables.get("forgeJS")); const prikey = pm.collectionVariables.get("prikey"); console.log("prikey:" + prikey); var priv = forge.pki.privateKeyFromPem(prikey); const md = forge.md.sha256.create(); var ts = moment().valueOf(); pm.collectionVariables.set("ts", ts); console.log("ts:" + ts); var message = "/subject/eduSubject-" + ts; console.log("message:" + message); md.update(message); const data = md.digest().bytes(); const sign = forge.util.encode64(priv.sign(md)); pm.collectionVariables.set("sign", sign); console.log("sign:", sign);}Postman 内置库官网文档：https://learning.postman.com/docs/writing-scripts/script-refe... ...

启动服务端java -jar luckyFrameWebV3.5.jar//或者双击启动命令start.cmd 客户端//或者双击启动命令start_service.cmd

AREX 是一款开源的测试工具，提供测试用例治理和无代码侵入的流量回放性能。 本文带来对于 AREX 的实际分享，次要集中在流量回放性能，被测利用是在官网提供的 community-test 利用上进行了肯定的功能扩充，实现了一个简略的书店生成订单性能，为特定用户生成某本书的订单，过程中会依据营销政策计算书本价格，也会调用扣库存服务扣除对应书本的库存。 该服务提供两个接口：order（生成订单）和 updateInventory（扣库存），其中 order 执行过程中会调用 updateInventory。 论断文档比拟长，先给出试用论断： 用例治理方面：整体相似 Postman，提供了 Postman 的大部分性能，如：脚本、环境变量、WorkSpace 等，本文演示中不波及。无代码侵入的流量回放性能：其外围原理能够参考官网提供的介绍。 接入不便，根本是无老本的数据采集和主动 Mock 能力十分强，反对 Http 服务、数据库、Redis、本地缓存、以后工夫的全自动 Mock，通过配置也能够反对内存数据的 Mock写服务反对良好，例如下单服务，在测试时对所有的依赖都进行了 Mock，所以齐全不须要放心生成脏订单，而且重要的是，即便进行了 Mock，也能够对订单后果进行验证（例如写到订单库的数据，看测试后果时会拿回放时的 SQL 和采集的测试用例里的 SQL 进行比对）验证点比较完善，测试时不只是对服务响应进行验证，还会对输入数据进行验证，像写到数据库、Redis 里的数据，发送给内部服务的申请也都能够进行验证美中不足： 对于性能比较复杂的利用，因为后果验证是全比对的，为了比拟好的体验，须要进行一些配置对后果降噪。疾速装置AREX 反对两种应用模式，上面别离进行介绍。 Standalone 模式Standalone 模式指的是 AREX 在本地环境中独立运行，也能够称之为命令行模式，应用非常简单。从：https://github.com/arextest/arex-standalone/releases 下载 arex-standalon-all.zip 文件后间接运行 arex-cli.bat(sh) 即可，启动后会列出以后机器上正在运行中的 Java 服务，抉择对应的服务，工具会主动将 Agent attach 到指标服务上，如下： 有以下几个次要命令： ls：列出指标服务上曾经采集的用例， 刚启动还没有任何数据，须要给服务发送一些申请后再执行该命令。 replay：将采集的用例在以后服务上进行回放，并给出回放的后果，执行后果会展现在一个弹出的网页上。 点击 Detai 按钮会显示对利用例的执行后果，也能看到运行过程中采集的所有数据，以扣库存接口为例，流程中相干的数据都进行了采集。 接口的响应： 拜访 DB 更新库存： 拜访 DB 获取书本的具体数据： 如果执行失败又不能简略判断失败起因，能够点击 Debug 按钮，间接进行代码的 Debug，这个性能能够了解成把采集到的申请发送给本地服务，从而能够在 IDE 中进行代码 Debug。在申请执行时，利用自身依赖的服务、DB等也不会产生真正的拜访，而是用采集的数据进行 Mock。 ...

背景在整个软件开发生命周期中，软件测试工作始终贯通其中，包含开发过程中、代码合并前的集成测试以及上线后的继续集成测试。为保障软件品质的全面性和稳定性，开发和测试人员都须要一直反复执行以下测试工作： 接口调试接口调试是开发人员在实现开发后进行疾速自测的一种无效形式，通常能够应用一些接口调试工具，如 Postman、ApiFox 等向接口发送申请并察看返回后果，调试和解决接口实现中呈现的问题。 接口自动化测试由测试人员筹备测试数据、编写测试用例并应用 JMeter 等工具编写自动化测试脚本，自动化执行测试用例，以确保代码的品质和稳定性。 接口数据 MockMock 在英文中含有模拟的意思，顾名思义，数据 Mock 就是通过结构假数据来达到测试的目标。采纳 MockJS 等工具 Mock 接口数据，能够节俭数据结构的工夫，这对前期进行回归测试工作的效率晋升至关重要。 接口回归测试回归测试旨在确保软件在通过批改、增加新性能、优化性能等后依然可能失常工作，在软件的疾速迭代开发中尤为要害。在接口回归测试中，通常须要结构数据、保护数据、测试用例及接入 CI/CD 流程。 对于一个产研团队来说，若要实现上述研发过程中所有环节的需要，至多须要应用四五种不同的工具能力满足，在理论工作中带来的问题也可想而知： 复杂性减少：应用多个工具可能会导致研发流程变得更加简单，须要更多的工夫和精力来协调和治理，团队无奈在同一套零碎中进行合作，导致各种沟通不及时、配合低效。高风险：应用多个工具也意味着须要将数据从一个工具同步到另一个工具，这可能会减少出错的危险。高老本：每个工具都有本人的应用办法和特点，须要破费工夫来学习和把握，前期也须要破费更多的工夫来保护和更新工具，特地是在长期的我的项目中。回归测试复杂度减少：对于须要疾速迭代的简单零碎，须要频繁地保护数据和用例，无论是脚本化保护还是手工保护，都须要破费大量的精力。业务复杂度高时，回归测试的复杂度可能会日益增高，这可能须要更多的工夫和资源来实现。“自动化”测试侧重于“自动化”执行，但保护工作仍旧是“手工”，工作量十分大。试想一下，如果有一款工具能够实现上述所有性能，那不是能够大大简化研发流程，进步测试效率，升高保护老本和出错率？明天咱们要介绍的就是这样一个工具：AREX。 什么是 AREXAREX 是一款开源的自动化测试平台，联合了 Postman + Mock + 比对测试，不仅提供了接口测试性能，更是通过 Java Agent 字节码注入技术，在生产环境录制和存储申请、应答数据，在测试环境回放申请和注入 Mock 数据，并存储新的应答，以此来达到主动录制、主动回放、主动比对，为接口回归测试提供便当，实现了从接口调试到接口数据 Mock，再到接口自动化测试和接口回归测试的闭环工作流。借助 AREX，开发和测试人员能够各取所需，协同单干，实现更高效的软件开发和测试。 接口调试（Postman）AREX 不仅能反对 Postman 大部分的接口调试性能，还提供了接口用例性能。 接口用例性能AREX 能够为同一个接口申请保留多个场景下的接口用例，每个用例都将主动继承以后接口申请下的配置，如 URL、申请形式及 Parameters、Header、Body 及前置脚本（Pre-request Script）等。通过继承父节点的接口申请配置，测试用例不须要一一从新定义接口的申请参数及前置脚本，后续再次调试时可间接运行接口用例，从而缩小测试用例编写的工作量和工夫。 AREX 还提供了测试用例治理性能。目前能够对测试用例增加标签（Add Tag）进行分类，前期将减少通过标签搜寻用例的性能，方便管理。另外能够为用例增加形容，进步用例可读性，让协作者更容易了解测试用例的目标和预期后果，并且能更好地把握测试内容。 导入、导出用例（开发中）各个测试团队都有本人的测试习惯，强制迁徙到一个新的测试工具，有很大的迁徙老本。AREX 后续将陆续反对各种格局的测试用例导入、导出，届时旧工具中的泛滥用例能够一键迁徙到 AREX，无需再次新建我的项目，同时也能够将 AREX 录制到的用例导出，帮忙测试团队升高迁徙老本。 目前 AREX 正在反对 Postman 导出的用例导入，如需反对其余格局的用例导入，能够在 Github 上提交 Issue，与社区共建。 固化的测试用例也反对导出，目前反对 Postman 格局的用例（JSON格局）。 接口回归测试（Mock + 比对测试）AREX 采纳 Java 的 instrument 技术实现了无代码侵入的数据采集和自动化 Mock，在进行回放时会应用录制过程中采集到的数据进行 Mock，代替真正的数据拜访，并不会产生真正的内部交互（如 DB 的写入、其余第三方服务的调用），防止了回放测试中脏数据的写入。同时反对各种支流技术框架的主动数据采集和 Mock，包含数据库 redis 等，并且反对了本地工夫、缓存等数据的 Mock，回归测试时能够在测试环境完满还原生产执行时的数据环境。 ...

什么是TestCafe？TestCafe是一个基于Node.js，反对多平台（Linux，Windows，macOS）的端到端web测试框架 装置指南最简略的形式是通过npm包管理工具进行装置，以下命令会在电脑上全局装置testcafe npm i -g testcafe形成TestCafe测试基于Node.js脚本执行，可通过新创建TypeScript或JavaScript文件开始进行测试用例编写，TestCafe的测试文件由fixtures和tests组成，一个fixture是一组共享初始URL的test函数组成的倡议：在每一个test文件中仅应用一个fixture，如用例集中蕴含不同初始URL的测试，最好将其调配至不同的测试文件中——通过初始URL进行分类 通过如下形式进行fixture的创立： fixture("Getting Started")而后应用page办法为fixture指定初始的URL： fixture("Getting Started").page("https://devexpress.github.io/testcafe/example")最初，通过应用test方面进行测试用例的申明： fixture("Getting Started").page("https://devexpress.github.io/testcafe/example") test("My first test", async (t) => { // Test code here })测试动作testcafe以后反对的页面操作： Click（点击） 点击操作又可分为：Click、Double Click、Right Click，示例： import {Selector} from 'testcafe'; fixture `Interact With the Page`.page`example`; test("Click Test", async (t) => { const btn = Selector("button").withText("Test") // await t.doubleClick(btn) // await t.rightClick(btn) await t.click(btn) })Press Key（键盘输入）Type Text（输出文字）Select Text （抉择文本）Hover（高亮）Scroll（滑动）Drag Element（拖动元素）Upload FilesWork with iframestestcafe以后反对的浏览器操作： ...

背景携程机票从2018年年中正式引入BDD，至今已3年多，成为外部首选的麻利开发技术。 Flybirds 是一套基于BDD模式的前端UI自动化测试框架，提供了一系列开箱即用的工具和欠缺的文档，当初逐渐稳固，成为机票外部首选的BDD-UI-Testing测试框架。 为什么开源分享咱们的BDD技术计划期待业内应用BDD技术的同行通过开源社区与咱们进行更深刻的交换本文将从个性介绍、环境搭建、应用帮忙、自定义扩大、继续集成、发版打算这几个方面对框架进行介绍。 Flybirds基于Behave，实现BDD中“自然语言测试用例文档”和“自动化测试代码”关联须要用到反对BDD工具。基于Airtest，实现BDD中“测试用例能在自动化测试平台上执行”须要用到UI自动化测试框架。基于Multiple-cucumber-html-reporter，实现可视化的测试报告 个性应用Flybirds你可能实现大部分的手机端自动化操作，以下是一些帮忙入门的个性形容： 基于BDD模式，类自然语言语法反对自动化APP操作、表单提交、UI元素校验、键盘输入、Deeplink跳转等默认反对英文、中文两种语言，反对更多语言扩大插件式设计，反对用户自定义自动化扩大提供cli脚手架，疾速搭建我的项目提供html报告环境搭建应用pip装置flybirds框架，过程中会主动装置所需的 依赖包pip3 install flybirds在Mac/Linux零碎下，须要手动赋予adb可执行权限 for mac cd {your_python_path}/site-packages/airtest/core/android/static/adb/macchmod +x adbfor linux cd {your_python_path}/site-packages/airtest/core/android/static/adb/linuxchmod +x adb应用脚手架创立我的项目flybirds create 疾速上手运行演示为了帮忙应用，我的项目创立时，会生成中英文的Android、iOS演示feature，不便用户参考。 features/test/features/test/androidfeatures/test/android/cn/everything.featurefeatures/test/android/en/everything.featurefeatures/test/iosfeatures/test/ios/cn/everything.featurefeatures/test/ios/en/everything.feature以“Android”为例 执行命令 adb devices , 查看设施列表中是否蕴含测试设施开始运行 cd {PATH_TO_PROJECT_FOLDER}flybirds run -P features/test/android框架会通过flybirds_config中配置的packagePath主动下载测试包并装置（请确保手机曾经关上”容许装置未知起源“ ） 运行后果如下 11 features passed, 0 failed, 0 skipped, 0 untested23 scenarios passed, 0 failed, 0 skipped, 0 untested117 steps passed, 0 failed, 0 skipped, 0 undefined, 0 untestedTook 5m21.300s===================================================================================== Multiple Cucumber HTML report generated in: /Users/test/my_first_project/report/7eb9162a-9d42-4fde-a5d7-d8d4bca7a8d8/index.html=====================================================================================接下来，理解下更多我的项目细节 ...

本文偏重介绍如何应用 python 和 mitmproxy 实现拦挡数据包、重发数据包，以及解析 protobuf 数据内容，对于相干依赖的装置不做介绍。 一、游戏协定平安测试内容参考https://testerhome.com/topics...，这篇文章讲的很分明。 二、实现原理想间接应用的同学能够跳到第三局部。 mitmproxy 作为代理，能够获取客户端与服务端通信的数据，并且能够拦挡、批改和自主发送数据。当配合其证书应用时，还能够解密 wss 连贯中的 websocket 数据。 Websotcket 数据处理源码剖析在 http 代理的过程中若发现 upgrade websocket 申请，则创立 WebSocketLayer 实例，并调用其_call_办法。# mitmproxy/proxy/protocol/http.py"""以下为Httplayer的_process_flow办法的局部代码"""if f.response.status_code == 101: # Handle a successful HTTP 101 Switching Protocols Response, # received after e.g. a WebSocket upgrade request. # Check for WebSocket handshake is_websocket = ( websockets.check_handshake(f.request.headers) and websockets.check_handshake(f.response.headers) ) if is_websocket and not self.config.options.websocket: self.log( "Client requested WebSocket connection, but the protocol is disabled.", "info" ) if is_websocket and self.config.options.websocket: layer = WebSocketLayer(self, f) else: layer = self.ctx.next_layer(self) layer()WebSocketLayer 初始化时会创立用于此次 websocket 通信的编解码器。 ...

CasePlayer2 : 实用于嵌入式软件的说明书制作及解析工具动态解析C/C++源代码主动生成流程图等文件实用于各种嵌入式微机用汇编代码具备合乎编程规范MISRA-C 1998/2004的标准查看性能，Code Metrics计测性能实用于把握以往程序的内容，审阅会议时评估程序等，有利于改善软件品质的工具 产品概要CasePlayer2是通过解析ANSI C语言，C++，嵌入式C语言（非ANSI），以及汇编语言的源代码，制作包含流程图等的程序说明书的工具。不论是对以往的程序进行逻辑剖析，还是为新开发的程序制作说明书，都提供了强有力的声援。作为程序动态剖析性能，包含内部变量参照/代入的列表性能，以及C语言的编程规范[MISRA-C]的标准查看性能。 只需将程序注销，能够主动生成各种说明书CasePlayer2是通过剖析ANSI C语言，C++，嵌入式C语言（非ANSI），以及汇编语言的源代码，制作包含流程图等程序说明书的逆向CASE（computer aided software engineering tool）工具。利用GAIO的次要技术也就是编译技术，不须要追加其余代码就能够解析代码结构，制作各种流程图。而其余公司的CASE工具往往须要追加代码能力实现流程图生成。而且，只需几秒钟就能够将数万行C语言程序转换成流程图，具备引以为豪的压倒性性能。[制作的说明书]・流程图・模块（函数）说明书・模块结构图・模块（函数）表・structure说明书，structure表 依据动态解析性能，生成内部变量对照表，typedef表，各种参照表具备通过动态剖析制作内部变量表和内部变量对照情报表的性能。能够用来确认整个Project中的外部变量在那里被参照，在那里被写入。也能够通过列表跳到绝对应的代码所在行。可能在晚期发现不正确的写入及读取，发现那些意想不到的谬误，领有强有力的性能。[依据动态解析制作的说明书]・内部变量表・typedef表・#define表・内部变量参照表・函数参照表・structure参照表・structure成员参照表 反对ANSI C语言，非ANSI嵌入式C,嵌入式汇编语言[CasePlayer2]也反对嵌入式汇编的源代码。程序包(Package)提供了近60种微机的参数（parameter）文件，简直笼罩了目前应用的各种微机。即便须要对个别的微机或个别微机的机型减少新的命令语，用户只有在参数文件中减少新命令语的定义，就能够立刻应用。对于C语言代码，不仅反对ANSI C语言，也反对#ifdef这样的设定编译条件的预编（preprocessor）代码。另外，也反对应用near，far一类非凡代码的程序。 可能设置最佳打印布局防止不必要的用纸不仅能够打印Word文件，也可能打印HTML文件[CasePlayer2] 提供流程图打印的最佳化性能，防止打印不必要的空白节约用纸。在打印布局性能方面，相比其余公司的CASE工具有着压倒性劣势。只需扭转打印倍率，即可失去用纸起码，布局最佳的打印。流程图之外的说明书也能够用同样的办法打印。另外，打印出的说明书还能够生成为HTML,Word（doc）格局的文件，生成比例能够自在设置。 具备[MISRA-C]的标准查看性能，合乎MISRA-C1998、MISRA-C2004规范MISRA-C是MISRA(Motor Industry Software Reliability Association)针对汽车工业畛域的C语言软件制订的规范。MISRA是以汽车工业畛域为核心无关软件可靠性的非营利机构。最近，MISRA也开始被汽车软件以外的畛域所采纳。[CasePlayer2]包含合乎[MISRA-C]规范的程序结构解析性能。GAIO的代码解析技术是从开发编译技术造就起来的，可能发现不同用户编写的不同程序中的不符合规范的局部，同其余公司的标准查看工具相比，CasePlayer2以其解析的”深度”，失去高度评价。查看的标准我的项目能够任意抉择。※MISRA标准查看性能不反对C++。只有Code Metrics情报输入性能反对C++。[次要性能]●MISRA-C 1998 : 可能对127项标准中的124项进行谬误查看 ●MISRA-C 2004 : 可能对141項标准中的138项进行谬误查看 ●点击HELP能够阅览标准讲解，举例说明容易了解（日语） ●对代码的测试，代码的重复使用，代码的保护有很高利用价值的Code Metrics测试 ・门路复杂度・Myer's Interval ・NET深度・代码文件的大小・注解（行数/比率）・动态pathcounterCasePlayer2利用实例CasePlayer2是能够随时随地将源代码变换成视觉形象的风行图的工具。能够在开发的各种环节灵便利用，例如源代码的解析，程序说明书的制作等。[A]开发初期的根本设计及探讨阶段，须要对现有的源代码进行考察解析对现有源代码，无论是资源中的源代码还是其余工程师编写的源代码，都须要在短时间内了解它们的逻辑内容，确认将它们插入时须要的批改规定等事宜。模块结构图以及流程图可能提供强有力的声援。CasePlayer2具备在几秒钟转换几万行的C语言程序的能力，能够即刻将代码变换成图形，进步源代码的解析效率。[B]程序编程前期的源代码审阅会议，进步软件品质进步软件品质首先要在开发团队中开展相互审阅查看，发现自己未能觉察的谬误，总结提出更无效的编程办法。 能够随时将源代码变换成流程图和模块结构图，将情报视觉化，使在短时间内对代码做出明确的评估成为可能。[C]开发实现后的开发内容记录，制作标准化程序说明书书面化的开发内容将成为今后的重要资源。通过CasePlayer2可能主动制作各种书面文件。与手编写相比，能够戏剧性的削减说明书制作工作。同时，不同于手编写容易造成各自格局的不同，可能制作对立格局对立编写办法的说明书，为开发project的文件格式通用化标准化提供无力的声援。次要性能●反对C/C++言語（V5.0之后）●说明书的综合化制作[说明书浏览器]・各种说明书之间任意挪动（从各种参照表挪动到绝对照的源代码的中央等）●从程序主动生成各种说明书・流程图・模块说明书・模块结构图・模块表 ・structure表・内部变量表・typedef表・#define表・成员函数说明书・内部变量参照表・函数参照表・structure参照表・class表 ・class说明书・class参照表・成员函数参照表 （←V5.0之后）●ANSI C言語、嵌入式C语言（非ANSI）、以及汇编●「MISRA-C」的标准查看性能合乎MISRA-1998、MISRA-2004规范●说明书的MS-Word格局转换性能●任意设定放大率，防止不必要的用纸，最佳布局的打印性能●HTML格局变换性能●印刷时格局布局的客户化性能●目录主动追加性能●流程图，模块结构图的图像文件（BMP,PNG）的输入性能动作环境●操作PC/OS ・IBM PC/AT 兼容机 ・Windows XP，Windows Vista， Windows 7（32bit）（※Windows 95/98/Me/NT/2000 未反对） ●License Key・USB Board Hardware Key (Dongle) ●装置须要的HDD容量・起码30MB以上的容量●须要的其余利用性能・HTML格式文件浏览：Microsoft Internet Explorer 5.5以上・MS-Word格式文件生成：Microsoft Word 2000以上

因为我最近在分享自动化测试技术，常常被问到： 功能测试想转自动化，请问应该怎么动手？有没有好的资源举荐？ 那么，接下来我就联合本人的经验聊一聊我是如何在工作中做自动化测试的。（学习路线和网盘资源放在文末了） 测试新人我的职业生涯开始和大多数测试人一样，刚开始接触都是纯性能界面测试。那时候在一家电商公司做测试，在这个吃技术的IT行业来说，一直学习是至关重要的。然而我之前做的是最根底的业务工作，随着工夫的消磨，让我产生了对自我价值和岗位意义的困惑。 一是感觉本人在浪费时间，另一个就是做了快2年的功能测试，感觉每天过得糊里糊涂，薪资也从不见涨，岗位也始终得不到晋升，身边的许多共事要么升职加薪，要么跳槽去了更好的公司工作，特地感觉本人碌碌无为。 抉择Python不得已开始思考怎么去改变现状。过后最简略的想法是挤出工夫去学习各种测试技术和工具，进步本人的价值，也就是外围竞争力。起初被主管偶尔发现，给了我一些资源和文档，倡议我去钻研下自动化测试。 过后来说，我还没有接触过自动化测试，然而通过主管给我的资源，让我意识到开发常识对于测试工作的帮忙，编程语言的能力会决定你测试技术的深度。当然也能带来支出的高度。 那时候正是脚本语言开始流行起来，因为过后我的项目的起因跟Python结缘，开始用Python和Selenium来尝试做自动化测试。那时，对于Python版的Selenium并不多，在学习的同时我开始发表相干博客。 分享是学习新技术的驱动力，大多数时候咱们很难保持学一个新技术的起因就在于短少反馈，不论是做外部分享或者是博客都是很好的反馈机制。当然，也很有成就感。 2015年的时候，因为我的项目的起因，开始应用Robot Framework测试框架，正因为有Python的根底，所以很快就了解了Robot Framework框架的工作原理，并能够依据我的项目的须要开发零碎关键字。 把握自动化工具的原理应用起来才会更加熟能生巧，而这也须要你有肯定的编程根底的起因。 2016年随着挪动App越来越风行，趁着换工作的间隙，我开始学习了一个月的appium自动化工具，但工作中用不到起初就没在持续了。 起初，我开始针对另一个社区我的项目编写Web UI自动化测试，前后做了好几个月，积攒了一些教训，开始尝试设计Web自动化框架，过后次要还是针对Selenium API的封装。 自动化测试过后因为公司的规模和产品的局限性，导致自动化测试始终未能利用到公司实战我的项目中。我感觉里面的世界有更多机会，自动化曾经风行而且越来越遍及，我想要冲破本人的测试技术瓶颈，我毅然决然的跳槽一家公司专职做自动化测试的工作。 起初的机缘巧合，敌人举荐我去一家金融公司做测试开发，负责开发公司定制化的测试品质平台。 这对于我来说是一个挑战，新的畛域，测试开发在一线城市十分吃香。过后的待遇比初、中级开发工程师要高。 到岗后就是顶住压力，一直的学习测试开发技能，而且学以致用。技术架构采纳的是前后端分享，包含Python的后端开发框架Flask,前端框架vue，elementUI组件等 保持做了几年的测试开发，实在的领会到测试开发等于测试全周期的工作，包含产品性能业务相熟，测试平台的需要设计，平台前后端研发，平台的自测，给到测试部门几十号人的推广、培训产品应用、经营。 所以测试开发的大前提是功能测试经验丰富，接口自动化，UI自动化十分纯熟，不然很难以发展自动化测试开发工作。 行业内卷最近聊到软件测试的行业内卷，越来越多的转行和大学生进入测试行业。想要取得更好的待遇和机会，一直晋升本人的技能栈成了测试老人火烧眉毛的问题。 不论是面试哪个级别的测试工程师，面试官都会问一句“会编程吗？有没有自动化测试的相干教训？” 所以还停留在手工功能测试层面，如果不去晋升技术，不仅要面临长江后浪推前浪的压力，还要顶住当下行业的内卷之势。不然就只能承受困境，最初甚至是面临淘汰。更别说升职涨薪了 如何从高级功能测试到高级自动化测试开发，达到技术晋升和待遇进步的目标，是很多高级测试人必经的一个阶段。作为一个过来人，对学习过程中的艰难深有体会。 所以我热衷于收集整理资源，记录踩坑到爬坑的过程。心愿能把本人所学，理论工作中应用的技术、学习办法、心得及踩过的一些坑，记录下来。也心愿想做自动化的你一样，通过我的分享能够少走一些弯路，能够造成一套本人的办法，并利用到理论中。 学习指南如果你也在往自动化测试开发方向倒退 在适当的年龄，抉择适当的岗位，尽量去施展好本人的劣势。 我的自动化测试之路，一路走来都离不每个阶段的打算，因为本人喜爱布局和总结，所以，我和敌人特意花了一段时间整顿编写了上面的《自动化测试工程师学习路线》，也整顿了不少【网盘资源】，须要的敌人能够关注公众号：程序员二黑，获取网盘链接。心愿会给你带来帮忙和方向。 自动化测试学习路线1. 自动化测试必备Python编程内容 2. Web UI 自动化测试根底内容3. Web UI 自动化测试实战内容4. APP UI 自动化测试根底内容 5. APP UI 自动化测试实战内容 6. API 接口自动化测试根底内容7. API 接口自动化测试实战内容 8. CI/CD继续集成专项技术 9. 自动化测试框架实战技术 网盘资源关注公众号：程序员二黑，获取上方网盘链接！最初也祝大家早日拿到称心的offer ~ 如果你不想再体验一次自学找不到材料，问题得不到帮忙，保持几天便放弃的感触的话，能够退出咱们的QQ群：642830685，大家能够一起探讨交换，外面会有各种软件测试材料和技术交换。 明天次要是和大家分享我的学习路线和网盘资源，后续我会分享一些面试攻略，有被帮忙到的敌人，大家能够点赞反对一下~

应用python3时，以file = open(os.getcwd() + "/report.html","w")的形式生成报告会报write() argument must be str, not bytes错，如图。解决办法时把"w"改为"wb"。 生成的html报告

CoverageMaster winAMS : 实用于嵌入式指标机代码的单元测试/集成测试工具全面反对嵌入式微机！验证嵌入式C/C++软件 施行以模块为单位的自动化单元测试工具不须要HookCode 间接应用指标机代码进行单元测试联结动态解析工具[CasePlayer2]，提供C0（语句）,C1（断定）,MC/DC覆盖率报告，优化测试用例制作已获得第三方认证机构TUVSUD对实用于汽车机能平安ISO26262软件工具的认证产品概要[Coverage master winAMS]是以嵌入式软件的函数为单位，施行模块单元测试以及C0/C1/MCDC覆盖率测试（coverage test）的嵌入式软件自动化单元测试工具。指标机源代码通过穿插编译器生成指标机执行代码，通过跟理论处理器同样的模仿处理器环境进行单元测试，不须要对执行代码做任何变动，使高信赖性的模块测试成为可能。在汽车控制软件这样的对安全性要求极高的畛域，单元测试曾经成为不可短少的一部分。应用指标机代码进行单元测试也是为了合乎汽车行业中ISO26262性能平安认证规范。产品专长全面反对嵌入式微机！验证嵌入式C/C++软件 施行以模块为单位的自动化单元测试工具作为可能测验出仅凭零碎测试以及整体测试无奈发现的[潜在谬误]的检测办法，[单元测试]在嵌入式开发畛域受到宽泛器重。同时，单元测试也是汽车用软件性能平安（ISO26262）畛域中要求施行的认证我的项目之一。 [Coverage master winAMS]间接应用通过穿插编译生成的指标机代码，在模仿处理器环境下进行单元测试。既能实现C语言程序的逻辑上的单元验证，又可能对嵌入式微机组装为产品后可能产生的问题等进行具备高信赖度的白盒（white box）测试。不须要HookCode 使间接应用指标机代码进行单元测试成为可能的业界惟一的工具有些公司的单元测试工具往往采纳在被测试对象的源代码中追加测试用代码或者测试用驱动器的办法，导致测试时所用的代码与组装为产品后的指标机用代码不同。尽管[实践上运行性能应该是雷同的]，然而从嵌入式开发的角度思考，这样就如同对穿插编译所生成的通过优化解决的代码进行了加工，无奈确保最终产品的品质。Coverage master winAMS是业界惟一的，具备[不须要对被测试对象做任何加工]施行单元测试性能的工具，特地是在安全性要求高的畛域中失去很高的评估。不需建设单元测试专用的环境，能够在开发用穿插编译环境进行单元测试Coverage master winAMS不须要追加任何测试用驱动器或测试用代码，能够间接应用将组装成产品的指标代码进行单元测试。单元测试可能与软件开发应用独特的穿插编译环境，不再须要对测试资源进行专门治理，也不再须要建设其余专用环境。因而，既不便程序资源管理，又可能缩短筹备测试环境所需的工夫。合乎汽车性能平安规范（ISO26262）[不做加工间接应用指标机代码施行单元测试]这一要求的最佳工具ISO26262是从IEC61508衍生进去的实用于汽车制作畛域的性能平安规范。其中的Part.6-9[软件程序单元测试]包含了对于软件程序的结构覆盖率测试以及无关的规定我的项目。依据汽车平安规范（ASIL），提出了测试语句覆盖率（statement coverage），分支覆盖率（branch coverage），MC/DC覆盖率的推荐性事项。其中的另一个推荐性事项是[尽可能使单元测试的环境与指标环境雷同]的规定。如果在与指标环境不同的环境下进行单元测试，必须表明源代码与指标代码的差异，以及指标环境和测试环境的差异。因而，对于那些应用与指标微机不同的电脑进行编译和单元测试的其余公司的工具而言，这个要求很难满足。 还有些公司的单元测试工具尽管包含穿插编译环境及编译性能，而且也可能在与指标环境雷同的环境下进行测试，然而所有的测试都须要插入测试用代码，进行再次编译，因而测试也只能在与指标环境不同的环境下施行。GAIO提供的单元测试工具Coverage master winAMS具备●采纳全面反对嵌入式微机的微机化功能测试平台环境●不须要插入测试用代码间接应用指标机代码进行测试的特色，提供合乎ISO26262规范要求的必须性能。GAIO提供的Coverage master winAMS是合乎ISO26262规范[间接应用整装用代码施行单元测试]这一要求的业界惟一的工具。对于汽车机能平安ISO26262的对应以及认证的取得已获得第三方认证机构TUVSUD对实用于汽车机能平安ISO26262软件工具的认证2012年6月28日，「Coverage master winAMS / General」测试工具取得由德国TUVSUD第三方认证机构，在汽车机能平安规格的ISO26262软件工具方面的认证，包含日本在内亚洲地区首次取得该项认证。通过此项认证，阐明本公司的单元测试工具「Coverage master winAMS / General」，以及程序剖析工具「CasePlayer2」，在动态剖析和单元测试畛域，是合乎所有平安度水准的工具，并由TUVSUD认证机构失去了保障。ISO 26262对于不同的开发用软件工具在工具置信水平（TCL），都须要开发者提供开发软件工具的认证书。此项认证实用于在工具认证当中，最为简单的TCL3工具认证规范。因而，导入本公司的单元测试工具之后，不须要对TCL的局部进行认证，进而能够缩减手续跟工夫。次要的单元测试性能采纳SSTManager治理单元测试projectSSTManager是Coverage master winAMS的利用性能，用于治理单元测试project，制作测试数据（test data）。从设定测试环境开始，到报告测试后果为止，均由微机化功能测试平台（ISS）施行综合治理。采纳通用便当的CSV文件治理测试数据的输入输出Coverage master winAMS不须要插入测试用代码，间接应用指标机代码进行单元测试。采纳通用便当的CSV文件治理函数测试时应用的输入输出数据。测试完结后，输入的测试后果和输入的期待值也将以雷同的格局显示在CSV文件之中。C0/C1覆盖率报告的自动化制作性能（规范性能）依据测试的输入输出数据主动报告相应源代码的C0/C1测试覆盖率后果。包含通过图形（viewer）显示测试数据，以及与其相应的被测试的源代码门路的性能，用于分析测试后果。作为选项性能也包含MC/DC覆盖率测试性能。MC/DC覆盖率的自动化测试性能（选项性能）作为选项性能提供MC/DC覆盖率测试性能。C0/C1覆盖率测试不须要加工即可间接应用指标机代码。然而，MC/DC覆盖率测试对于复合式的条件式，须要主动插入HookCode将复合式的条件式合成，能力对各条件式进行测试。这样就有可能导致测试用代码与指标机用代码的不同。为了验证HookCode的得当性，在MC/DC覆盖率测试的同时，运行指标机代码，确认运行后果与期待值的一致性。注:右图举例显示，第2个if句的复合条件式中，[gbc>30]为false时的分支没有被测试到。以C1覆盖率测试来说，它的测试后果是OK；而对于MC/DC覆盖率测试来说，它的后果是NG。注: MC/DC覆盖率测试性能不反对C++程序。单元测试的效率化性能联结程序解析工具CasePlayer2，实现代码参照解析作业的效率化利用CasePlayer2生成的流程图表以及模块结构图（调用函数的结构图）与源代码的连贯（link）性能，使单元测试用源代码的解析工作效率化。可能自动检索被测试函数的内部变量，使测试条件设定效率化联结程序解析工具CasePlayer2，自动检索被测试函数所应用的内部变量。缩短了以往必须对源代码进行搜寻找出输出条件的变量所需的工作。而且，可能避免人工操作导致的相似变量指定脱漏的的谬误。依据代码解析自动化制作C0，C1，MC/DC 覆盖率测试计划联结程序解析工具CasePlayer2，自动化制作合乎覆盖率测试要求的条件分支if,switch,for,while等的测试数据。能够将被测试函数中含有的条件式（if以及switch等）在数据制成图形(Viewer)上列表显示。点击其中的条件，工具将主动开始检索与之相干的变量，进而从所设置的条件的境界值中主动生成覆盖率测试所须要的数据。为了达到C1/MCDC覆盖率，测试时须要对各函数的数据进行组合。利用CasePlayer2提供的解析后果，剖析条件式的net结构，在重复性限度在最小限度下生成C1/MCDC覆盖率测试用数据。反对MPU　CoverageMaster winAMS Supported Processor List(English)动作环境・操作PC/OS・IBM PC/AT 兼容机・Pentium(相当) 2GHz 以上的CPU・存储器 512MB 以上（推荐值）・显示器分辨率 XGA(1024*768)以上（推荐值）・Windows XP, Windows Vista, Windows 7（32bit/64bit）（※Windows 95/98/Me/NT/2000 未反对）

之前分享了一系列的文章，别离从原理，运行，断言，执行，测试套件，如何跳过用例来解说unittest，如何初始化一次，那么咱们持续分享丑陋的html测试报告。   在之前咱们的测试报告中，咱们有测试报告，然而原生的给咱们带的比较简单，咱们要想进去丑陋的html测试报告，是否能够呢，答案是能够的，这里我展现两个丑陋的unittest的测试报告，简洁慷慨。         github地址：https://github.com/easonhan00...         下载后，咱们间接复制BSTestRunner.py到我的项目目录下，咱们在代码中演示下 import unittestfrom BSTestRunner import BSTestRunnerclass TestDemo(unittest.TestCase): def setUp(self): pass def tearDown(self): pass def testEqual(self): self.assertEqual("12","122")def suite(): suite = unittest.TestSuite() suite.addTests(unittest.TestLoader().loadTestsFromName("testdemoone.TestDemo")) return suiteif __name__ == "__main__": report="test.html" suitone=suite() openone= open(report,'w+') bstest=BSTestRunner(title="演示",description="演示测试报告",stream=openone) bstest.run(suitone)咱们展现下 运行的后果。 上面在举荐一个产生测试报告的框架，个人感觉也很棒开源地址：https://github.com/Testerlife...，这是有mock大佬开源。咱们下载后间接复制BeautifulReport.py，template到我的项目门路下。创立一个门路report。咱们复制到本地所以，我略微改变了 PATH。 class PATH: """ all file PATH meta """ config_tmp_path = os.getcwd() +'/template/template'咱们如何组织用例呢。 import unittestfrom BeautifulReport import BeautifulReportclass TestDemo(unittest.TestCase): def setUp(self): pass def tearDown(self): pass def testEqual(self): self.assertEqual("12","122")def suite(): suite = unittest.TestSuite() suite.addTests(unittest.TestLoader().loadTestsFromName("testdemoone.TestDemo")) return suiteif __name__ == "__main__": report = "test.html" suitone = suite() result = BeautifulReport(suitone) result.report(filename='test.html', description='测试deafult报告', log_path='report')咱们看下最初的执行的后果 ...

Netflix应用了灰度部署进行混沌试验，但仍会有小局部用户可能会受到影响。灰度黑洞，为混沌工程测试的安全性提供了现实的环境，对用户的影响则齐全为零。 一、又快又稳的新挑战人总有完美主义偏向，而事实是：写的代码不会没有Bug，所有的测试不可能齐备，生产的构建部署不会没有缺点，用户永远都会遇到问题。不过，咱们变革和扭转的能源，往往来自惨痛的生产事件： 2019年7月CloudFlare的大宕机，是由谬误配置的Web利用防火墙造成的。Facebook的反垃圾邮件零碎，意外地折叠了指向非法起源的链接。因为临床记录管理系统的软件更新，谬误地为超过10,000名的患者开了药。 采纳DevOps实际曾经成为共识，公布周期的缩短，新性能推向生产的速度比以往更快。同时，微服务和云原生架构正在减少利用的复杂性。当速度和复杂性减少时，软件缺陷进入生产的机会也在减少。 为了解决这一危险，咱们须要增强在生产中的测试实际，这一过程经常称为“测试右移”。 测试右移，从前期生产阶段开始测试工作。这些测试是为了确保稳定性、性能和可用性规范。这样，就能够从指标用户那里收集反馈和评论，以理解在事实世界中的利用行为。这有助于进一步提高品质。 二、生产中测试的迫切性在新产品投产之前，单元测试、功能测试、集成测试和非功能性测试等多种测试类型，对品质保障至关重要。上面这个图十分有意思，从测试对象的范畴（从单个组件到零碎层面）以及是否取得新常识这两个维度，对上述测试类型进行分类。 ( “混沌工程”在图的右上角) 一般而言，测试都在隔离的环境中进行。这些环境尽可能复制生产，以便为测试人员提供相当的测试环境，而不在生产环境间接测试，防止用户因为测试面临危险。 然而，仅进入生产之前的测试不足以解决所有问题，起因有以下几种： 2.1 生产是一个独特环境生产不可代替。咱们能够构建测试环境，应用与生产雷同的基础设施和数据（基础设施即代码的办法等等），然而永远无奈齐全复制生产。环境具备其独特的配置，这会影响利用的行为形式，而且难以重现。当咱们须要投入大量的工夫和金钱，来达到环境之间的均等性。随着生产的一直变动，这种希图简直是痴心妄想。 2.2 生产是用户在的中央生产之前的测试受到工夫、资金和人员技能的影响，无奈做到齐备测试。生产中的测试为测试人员提供了额定的机会来发现缺点，免得对用户体验产生负面影响。 三、生产中测试的危险在测试环境中进行测试的一个益处是，测试人员能够平安地运行侵入性测试，例如压力测试、压力测试和劫难复原测试。 在生产中运行这些测试存在以下危险： 影响性能或稳定性，侵害用户体验；产生用户数据透露、批改或失落；影响营销剖析和经营指标，例如用户流量或错误率；引起违反法规或规范的事件（遵循GDPR、PCI、HIPAA等规范的个人身份信息 PII的应用）。因而，与在测试环境中进行测试相比，在生产中进行测试须要一种更加受控的办法。 四、生产中平安的部署策略许多利用部署策略非常适合生产测试： 测试在生产的基础设施上上运行；将危险管制在绝对较少的用户中；在重大缺点或故障的状况下回滚。4.1 蓝绿部署蓝绿部署(Blue/Green Deployment)是一种公布策略，实质上就是并排运行两个雷同的生产环境。一个环境（蓝色）托管利用的以后版本，而另一个环境（绿色）托管新版本。绿色环境开始放弃闲置状态，不提供任何用户访问量，逐渐将用户流量从蓝色环境切换到绿色环境中，不会产生停机工夫。 蓝绿部署的次要益处是，可助力DevOps团队验证生产中的更改，不会给用户带来危险。通过将用户路由到以前的版本来回滚任何有问题的变更，DevOps团队始终领有牢靠平安的生产环境。最大的问题是，在切换流量之前，绿色环境没有用户流量，很难测试利用刚上线时的行为。此外，保护两个独立的生产环境会减少老本和经营开销。 4.2 灰度部署在灰度部署(Canary Deployment)中，新的更改最后会部署到一小部分用户，而后逐步推广到所有用户。蓝绿部署由两个独自的生产环境组成，灰度部署则是一个生产环境，托管着利用的两个不同版本。稳定版会持续解决大部分用户流量，而灰度所占的用户流量比例要小得多。灰度部署的次要益处是： 在理论的生产零碎上运行；面向大量用户，缩小缺点带来的潜在影响；便捷地向所有用户推出经灰度验证的新版本。例如，Netflix应用灰度部署来进行混沌试验、负载测试和回归测试。其中一个试验可能波及部署一个API生效的服务版本，将一小部分用户路由到该服务，随着失败申请的减少，察看零碎行为。测试实现后，能够删除灰度部署，并将这小局部用户从新路由到该服务的稳固版本。 不过，灰度部署仍可能存在有问题的服务，有影响小局部用户的危险，然而这种危险绝对较小。 4.3 黑洞启用在黑洞启用(Dark Launch)中，实时用户流量将被复制并发送到利用的稳固版本和新版本中。稳固版本将持续响应用户申请，而新版本将没收其所有响应，不让用户可见，相似只进不出，俗称“黑洞启用”。 黑洞启用，可全面测试新版本的端到端性能，以及在理论负载下的性能。和灰度部署相似，黑洞部署能够逐步扩充规模，以解决随着时间推移一直增长的流量，所以有时候也称之为“灰度黑洞(Dark Canary)”。 上图中，服务A领有多个实例来接管用户申请，并调用服务B检索必要的信息。这是一个典型的分层零碎，其中服务A是中间层服务，服务B是后端服务。而服务A是咱们要验证的服务，则须要启用服务A的灰度黑洞群集。 LinkedIn应用Rest.li中的动静发现(D2)服务发现机制，D2库装置在每个服务实例中，向Zookeeper查问领有该服务的集群，负责将服务A中的申请转发。灰度黑洞群集的流量就是这么来的。（https://linkedin.github.io/re... ） 灰度黑洞集群的响应会疏忽，不会返回给用户。 一旦对新版本进行了残缺的测试并进行了审核，如果要公布该新版本，只需启用新版本的返回响应，并禁用原始版本的响应即可。 当然，这须要一次运行两个版本的利用，会有老本的开销，但这比蓝绿部署要低得多。 灰度黑洞，为混沌工程测试的可靠性提供了现实的环境。Netflix应用了灰度部署进行混沌试验，但依然会有小局部用户可能会受到影响。如果是灰度黑洞的办法，咱们能够在与生产雷同规模上运行这些试验，而对用户的影响则齐全为零。 咱们能够在基础架构的不同点引入故障，掂量对理论用户申请的影响，并解决间接影响用户的危险点。同时还能够发现，测试环境中的功能测试或端到端测试无奈发现的问题。灰度黑洞，能够做到这一点而不会影响任何用户。 五、论断白璧无瑕的利用是一种奢望，咱们不得不面对现实，在任何可能呈现问题的中央查看利用行为。在生产中测试，助力DevOps团队更好地理解利用行为及其基础设施，升高故障危险，改善用户体验，这是有微小价值的。 蓝绿部署、灰度部署和黑洞启用，能够从只在测试环境中的查看，扩大到生产中的测试，应用受控的办法，管制用户危险。我置信，它们会使你的零碎变得更加牢靠，生产缺陷率将继续降落，用户体验将变得更好。 起源：混沌工程实际作者：码六贾申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 6月每周四晚8点，【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址 0603 无敌哥 《IDCF人才成长地图与5P》（《端到端DevOps继续交付(5P)精品课》第1课）0610 冬哥 《带你玩转翻新设计思维》0617 无敌哥 《麻利项目管理到底是个啥》0624 冬哥 《VUCA时代的麻利领导力》

CODING 为您的企业提供从概念到软件开发再到产品发布的全流程全周期软件研发管理，为您的研发团队提供全程助力，帮助研发团队捋清需求、不断迭代、快速反馈并能实时追踪项目进度直到完成。同时 CODING 还为研发团队中每个角色根据其工作的性质设定了相应的工作流程，帮助每一个人快速上手，助力研发团队，提高研发效能，更高效更快速地进行软件交付。 什么是测试管理软件开发项目中的一项关键工作就是测试，通过创建和执行测试并管理测试结果，从而制定高效的开发决策。然而在技术日新月异的今天，传统瀑布流式的交付形式已经不能满足业务的需求，企业的敏捷转型迫在眉睫。而测试管理的改革是企业能否实践 DevOps 实现小步快跑的关键。传统的软件开发团队的开发流程是先把功能开发完，然后再交付给测试团队进行测试，开发和测试是相对独立的两个过程，导致中间会有大量时间和效能的浪费。而在 DevOps 的理念中，测试应该随着版本迭代速度的加快而提速，因此把测试集成到开发的过程中来，成为开发过程中重要的一个环节是实现敏捷的重要步骤。CODING 秉承着一站式 DevOps 解决方案的理念，将测试管理集成研发管理系统，通过敏捷测试缩短软件交付周期，让测速和研发同步迭代，帮助企业实现数字化转型，用更高效的方式为客户带来价值。 点击观看《使用 CODING 进行测试管理》实操视频 测试人员权限设置随着数字化转型浪潮的开始，越来越多的企业开始使用信息化的管理系统取代传统办公工具。在转型的过程中最大的挑战之一就是如何给相应信息设置权限管理，确保不同职能部门的员工只能使用特定的功能，浏览与自身业务相关的信息，不能擅自查看或修改超越权限的内容，保证企业数字资产的准确性、保密性、安全性。 测试人员默认权限： 创建测试用例在进入 CODING 的测试管理模块后，即可开始创建测试用例。除了直接创建测试用例以外，CODING 的测试管理模块还支持从 Excel 和 TestLink 直接导入用例库，同时也支持从用例库直接导出 CSV 文件，方便测试工程师进行数据迁移。 点击右上角创建用例按钮，进入创建测试用例页。 创建测试用例依次操作如下： 输入标题；输入测试前置条件；选择测试步骤类型并输入相应的测试步骤内容或文本用例内容；点击保存并关闭按钮，则完成一个测试用例的创建。创建测试计划在项目首页点击测试计划图标进入测试计划列表页。CODING 测试管理中的测试计划可以与迭代管理相关联，方便项目负责人进行全局统筹。 页面左侧展示所有测试计划列表，右侧展示选中测试计划的测试任务列表。点击上方 + 号按钮，弹出创建测试计划窗口。 创建测试计划依次操作如下： 输入测试计划标题；输入描述信息；选择是否包含全部用例：若选择包含全部用例，则项目下所有用例都将成为当前测试计划下的测试任务；若选择手动圈选用例，则需点击圈选范围按钮选择需要纳入测试计划的用例；点击创建计划按钮，则完成测试计划的创建。执行测试任务在测试计划列表页，从左侧选择一个测试计划，点击右上角的开始测试按钮，则进入测试任务执行页。 记录测试结果步骤如下： 点击记录结果；选择结果状态，可选择通过、受阻、重测和失败；输入备注信息，若测试用例为步骤用例，则可输入每个步骤的实际结果和测试状态；点击添加结果按钮，则完成该测试任务的一次测试。生成测试报告CODING 测试管理可自动生成定制化的大师级测试报告，涵盖了测试结论、图表、工作分布、耗时等关键信息。帮助项目负责人对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下坚实的基础。 立即点击使用 CODING 快速上手，高效交付！

作者：张文博 Kubernetes（K8s）是一个开源容器编排系统，可自动执行应用程序部署、扩展和管理。它是云原生世界的操作系统。 K8s 或操作系统中的任何缺陷都可能使用户进程存在风险。作为 PingCAP EE（效率工程）团队，我们在 K8s 中测试 TiDB Operator（一个创建和管理 TiDB 集群的工具）时，发现了两个 Linux 内核错误。这些错误已经困扰我们很长一段时间，并没有在整个 K8s 社区中彻底修复。 经过广泛的调查和诊断，我们已经确定了处理这些问题的方法。在这篇文章中，我们将与大家分享这些解决方法。不过，尽管这些方法很有用，但我们认为这只是权宜之策，相信未来会有更优雅的解决方案，也期望 K8s 社区、RHEL 和 CentOS 可以在不久的将来彻底修复这些问题。 Bug #1: 诊断修复不稳定的 Kmem Accounting关键词：SLUB: Unable to allocate memory on node -1 社区相关 Issue: https://github.com/kubernetes/kubernetes/issues/61937https://github.com/opencontainers/runc/issues/1725https://support.mesosphere.com/s/article/Critical-Issue-KMEM-MSPH-2018-0006问题起源薛定谔平台是我司开发的基于 K8s 建立的一套自动化测试框架，提供各种 Chaos 能力，同时也提供自动化的 Bench 测试，各类异常监控、告警以及自动输出测试报告等功能。我们发现 TiKV 在薛定谔平台上做 OLTP 测试时偶尔会发生 I/O 性能抖动，但从下面几项来看未发现异常： TiKV 和 RocksDB 的日志CPU 使用率内存和磁盘等负载信息只能偶尔看到 dmesg 命令执行的结果中包含一些 “SLUB: Unable to allocate memory on node -1” 信息。 问题分析我们使用 perf-tools 中的 funcslower trace 来执行较慢的内核函数并调整内核参数 hung_task_timeout_secs 阈值，抓取到了一些 TiKV 执行写操作时的内核路径信息： ...

前言在前几天的博客中，我转载了一篇文章，其中介绍了契约测试和pact是怎么实施的，的确很有帮助。但我经过研究，其实是pact本身也是有缺陷的，结合我近期在使用的服务型工具和我的实际情况，觉得实现契约测试其实有更有效率的解决方案，本文就通过我的视角看看我是如何快速实现契约测试的。契约测试为前后端对接的过程中会出现信息不对称，以及工作进度不一致的情况，因此希望通过事先约定好API返回数据的文档，根据文档来开发后端代码，以及生产可以被前端调用的虚拟的API，帮助前后端能够同时开展工作并且保持前后端代码的正确性，加快后期的系统集成测试甚至是取消系统集成测试。我们将以上的做法称之为契约测试。契约测试最开始的概念由 Martin Fowler 提出，它又被称之为：消费者驱动的契约测试（Consumer Driven Contracts），简称CDC。这里的契约是指软件系统中各个服务间交互的数据标准格式，更多的指消费端（client）和提供端（server）之间交互的API的格式。契约测试带来的变化主要是：1.将前后端测试解耦，前后端可以分别在对方还没有完成工作的时候就开展测试；2.将测试过程前移，加速或者取代集成测试；3.保证数据的一致性，让后端服务返回的数据就是前端想要得到的。我做了一张图方便大家理解CDC的概念：上图经历了三个步骤：1.消费者（广义的前端）根据业务需要编写好契约文件，契约文件里面编写了需要返回的数据；2.消费者（广义的前端）向契约文件（实际上是一个API服务）发起请求，得到预期的结果，验证前端业务逻辑是否正确；3.契约文件（实际上是一个API服务）向提供者（广义的后端）发起请求，得到后端真实的返回结果并且与契约文件中的数据规则进行校验，判断后端返回的数据是否满足契约的要求。如果无法通过校验，说明提供者的服务发生了改变，或者是没有按照契约所规定的来进行开发。如果通过了上面的三步，我们可以认为前后端对于契约的理解和实现是一致的，等到真正集成之后也不会出现问题。Pact 契约测试框架之前业内较为常见的做法是通过Pact（一个契约测试框架）进行契约测试：通过前端开发人员编写代码进行测试并生成Pact契约文件，后端通过Pact Brocker等服务管理契约以及调用等。但是Pact也存在一些缺点：1.需要引入Pact的相关文件以及正确搭建服务，用起来需要一定的时间成本2.生成的返回数据不够灵活，无法编写代码生成复杂的随机数据；3.无法判断请求参数来返回不同的结果；4.需要开发人员额外编写代码，增加了工作量；5.存在代码入侵的情况，并且目前支持的语言较少；6.模糊了开发与测试人员之间的界限，管理不当容易导致重复劳动；由于有以上的不足之处，Pact 在实际应用的效果往往并不理解。因此我们提出了通过 Mock API 以及测试用例实现更快速、更有效地契约测试。通过 EOLINKER API Studio 实现契约测试EOLINKER API Studio（https://www.eolinker.com） 提供了UI实现的 Mock API，配合API Studio 的测试用例与自动化测试，可以帮助研发团队更快速、更有效地实现契约测试。什么是Mock API？通过 Mock API，您可以事先编写好 API 的数据生成规则，由 API Studio 动态生成 API 的返回数据。开发人员通过访问 Mock API 的 URL 来获得所需要的数据，完成对接工作。在 API Studio中，同一个项目中的 Mock API 的地址前缀是相同的（如mock.eolinker.com/uasyd1/…），因此可以在代码中将 Mock API 的地址前缀作为全局变量，项目上线时仅需替换变量的值即可改变整个项目的 API 请求地址前缀。创建Mock API，实现前端的契约测试在EOLINKER API Studio中，创建 Mock API 之前需要先创建API文档（或者导入Postman、Swagger等数据），API文档可以作为前后端对接的依据。这里我创建了一个简单的用户登录API文档：创建好API文档之后，点击 Mock API 标签进入Mock API的管理页面，在这里可以快速创建多个Mock API，并且根据不同的请求参数返回相应的数据：创建一个 Mock API 期望，我们希望当传递user_name=和user_psw=112233时，Mock Server返回登录成功的数据，这里返回的数据类型选择Json，填写好Json的格式以及内容即可：点击预览按钮可以看到是我们希望得到的返回数据，然后确定保存即可：通过这种方式可以创建多个Mock API，并且通过请求红框处的 Mock API URL 得到返回结果：API Studio 中也提供了强大的 API 测试的功能，我们直接在平台上对刚才的登录成功的 Mock API 发起请求，可以看到当我们传递正确的参数时，可以得到预期的返回结果，至此契约测试的前端契约就已经完成了：创建测试用例，实现后端的契约测试：传统的契约测试其实并不能够保证测试的覆盖率，因为前端开发人员提供的契约文件很可能无法覆盖所有的请求情况，导致出现漏测的情况。因此 API Studio 建议将后端的契约测试交给测试人员负责，这样可以提供更完善的测试用例，并且可以结合各类CI工具实现自动化测试。由于 API Studio 基于 API 文档来实现契约测试、API用例测试、API自动化测试等功能，因此可以将前端、后端、测试人员解耦，工作的流程可以进一步改进为下图所示，前后端、测试人员可以同时开展工作，并且测试用例可以导入到自动化测试中成为长期的定时测试任务。由于测试用例与自动化测试所包含的内容较多，如有需要可以前往 EOLINKER API Studio 官方网站（https://www.eolinker.com）或者是查阅 API Studio 帮助文档，在此不再赘述。 ...

由于工作的原因，最近一直在研究API接口测试问题，因为前后端开发经常遇到进度不一致、信息不对称的情况，最近正在找寻能完美解决这个问题的方案。尝试寻找了一下，发现这其实是一个契约测试问题，在找到之前的一些文章，看完觉得对我理解契约测试有很大帮助，转过来记录一下。现在我已经有一些思路了，后续会专门写一篇文章来记录这部分的内容。测试金字塔模型测试是软件流程中非常重要，不可或缺的一个环节。一般的测试分为单元测试，集成测试，端到端的手工测试，这也是构成测试金字塔的三个层级。我们今天将要讨论的话题是契约测试，它是处于单元测试和集成测试中间的一个环节。这三个层级分别测试的场景如下：单元测试：测试单个service集成测试：测试由多个services组成的系统端到端测试：测试从用户到各个外部系统的整个场景什么是契约测试？契约测试最开始的概念由Martin Fowler 提出，请参见这篇文章， 它又被称之为：消费者驱动的契约测试（Consumer Driven Contracts）。这里的契约是指软件系统中各个服务间交互的数据标准格式，更多的指消费端（client）和提供端（server）之间交互的数据接口的格式。为什么要存在契约测试？系统工程中存在这样的理论：线性系统（即复杂性随规模线性增长的系统）的可靠性等于组成它的各个组件的可靠性之乘积。这容易理解，因为整个系统正常工作的条件是必须每个组件都同时正常工作。如上图所述，三个组件共同支撑的系统，如果每个组件的可靠性是90%，那么整个系统的可靠性就是 90%×90%×90%=72.9%，我们可以看到系统整体的可靠度是低于任一组件的可靠性的。如果一个系统由100个组件组成，每个组件即使能达到99%的可靠性，那么整个系统的可靠性也会降到36.6%左右。我们常说复杂性是软件工程的最重要的特性，一个完善的软件系统必然是靠很多的子系统，组件共同撑起来的。根据上面的理论，如果是一个复杂的软件系统那么每一个组件的可靠性都对系统整体的可靠性有着非常重要的影响，排除组件本身的可靠性的因素，各个组件之间的相互依赖和调用关系也将会对系统的稳定性有着决定性的影响。随着业务的复杂度越来越高，整个系统也变得越来越庞大和错综复杂，在今天的软件工程开发中微服务已经不是一个新名词，在微服务的架构下通常一个client会与多个service相互交互，可以想象一下如果某一个服务的接口发生变化将会影响整个系统的运行。如下图展示的传统的大服务与微服务的区别。那么在微服务模式下如果保证各个服务端与消费端之间以及服务与服务之间能够可靠的交互呢？这就回到了到我们要聊的契约测试的话题。如下图，在服务端接口发生变化的情况下通过契约测试可以很容易的测试出契约不匹配，可以在集成测试之前就能发现问题，尽早解决。契约测试和单元测试，集成测试，端到端测试区别是什么？单元测试：通常是测试单个类，方法的可靠性它的价值在于快速的反馈某一个很小的功能点是否能准确的工作通过单元测试能够更明确的剖析你的实现逻辑如果用TDD的开发模式，能够做代码重构以及改善代码整洁度集成测试：关注的是各个服务之间交互测试接口连通性和流程的可用性端到端测试：从用户的角度验证整个功能的准确性和可用性测试的是端到端的流程，会加入用户数据验证功能是否可用不会关注在某一细小的功能点的实现关注的是整个业务流程，产生的业务价值大契约测试：测试接口和接口之间的正确性验证服务层提供的数据是否是消费端所需要的将本来需要在集成测试中体现的问题前移，更早的发现问题更快速的验证消费端和提供端之间交互的基本正确性契约测试解决能解决什么问题？可以使得消费端和提供端之间测试解耦，不再需要客户端和服务端联调才能发现问题完全由消费者驱动的方式，消费者需要什么数据，服务端就给什么样的数据，数据契约也是由消费者来定的测试前移，越早的发现问题，保证后续测试的完整性通过契约测试，团队能以一种离线的方式(不需要消费者、提供者同时在线)，通过契约作为中间的标准，验证提供者提供的内容是否满足消费者的期望。一般契约测试是在单元测试之后，集成测试之前要进行的，首先在保证各自功能正确的前提下测试消费者和提供者的契约是否相匹配，然后再进一步的测试功能的完备性和整个业务流的正确性。写在最后本文主要浅显的介绍了契约测试是什么以及它的重要性，后续将会继续介绍契约测试的框架以及相关实践。

过去的几年中，软件测试与质量保障行业悄然间发生了很大变化，TesterHome 社区作为行业见证人，通过 MTSC 大会记录了测试行业技术趋势与人才结构的变革历程。2018 年，MTSC2018 大会共邀请了 50 多位测试行业国内外顶级专家，与来自近 500 家业界领先企业的 1600 余位测试开发工程师、测试架构师与质量管理者交流分享了一线企业软件质量保障体系建设经验、测试研发新技术与最佳实践案例，助力企业技术选型、工程效率提升和业务升级转型。现在，MTSC 组委会决定公开 MTSC2018 测试开发大会视频（含 PPT 资料），作为献给 TesterHome 社区用户和测试从业人员的年度大礼，期待推进行业进步。MTSC2018 大会视频公开《腾讯手游自动化测试方案和 AI 实践》 by 蔡怡峰，腾讯 IEG 品质管理部测试开发负责人 & 李德元，腾讯 IEG 品质管理部高级测试开发工程师《基于分层快速反馈的金融 App 质量防护方案及实践》by 王小丽，TestBird 测试架构师《大疆互联网的一站式自动化测试解决方案（基于HttpRunner）》 by 李隆，大疆高级测试开发工程师《2 个人如何保证 2 亿用户 App 的质量》by 唐巧，小猿搜题产品技术负责人《ebay 自动化测试基础架构的最佳实践》 by 茹炳晟，eBay 中国研发中心测试基础架构技术主管《AirtestProject-次世代UI自动化测试解决方案》by 李翔，网易游戏测试专家《大船好调头京东测试团队从业务到技术转型实践》by 贾瑞卿，京东高级测试经理《基于用户视角的Android页面性能评测体系》by 林紫嫣，优酷 Youku 高级测试专家《玩转58场景下的自动化测试》by 吴明浩，58 集团测试架构师《探测小程序的机密》by 甄晓龙，转转高级测试工程师《千万级支付系统稳定性测试实战》by 范勋伟，美团点评智能支付测试团队负责人《大众点评APP：Mock自动化的专项应用》by 李洁，美团点评资深测试工程师《以高效共享、复用、传承为目标的测试用例管理思路&工具实践》by 顾利萍，360 QTest 团队测试主管《基于AI的APP自动化测试》by 胡平，华为资深技术专家《性能解析：互联网银行项目实践和两则实际性能定位案例》by 高楼，北京千倍科技有限公司，7D Group 创始人《汽车之家新车电商精准测试解决方案》by 闻小龙，汽车之家高级测试开发工程师大会视频及 PPT 获取方式视频资料：识别上图二维码或者访问 TesterHome 社区https://testerhome.com/topics…大会 PPT： 请访问百度网盘链接: https://pan.baidu.com/s/1ca9r… ，提取码为【apvv】。MTSC2019 启动，热点议题征集中MTSC2019 大会购票地址：https://www.bagevent.com/even…MTSC2019 大会议题申请：topic@testerhome.comMTSC2019 大会商务赞助：bd@testerhome.com关于 MTSC 大会MTSC 中国移动互联网测试开发大会（Mobile Testing Summit China）是由国内最大的测试开发技术社区 TesterHome 主办的年度技术盛会，聚焦于软件测试及应用质量保障，邀请国内外顶级技术专家分享测试行业最前沿技术创新发展、业界工程最佳实践经验等。自 2015 年举办以来，近万名有从业经验的测试开发工程师、测试经理和质量管理人员参加了 MTSC 大会，好评如潮。MTSC2019 大会议题涵盖移动端测试、服务端测试、Web 测试、IoT 智能硬件、持续集成／持续交付、DevOps 等领域，以及大数据、人工智能 AI 技术在测试领域的应用。MTSC 大会从专家邀请到内容评审都严格把关，力求务实、能落地、有深度、高质量。很多一线互联网企业如腾讯、阿里、百度、美团、华为、小米、360 等公司都专门组织研讨会来学习分享 MTSC 大会内容。2019 测试行业技术栈有哪些创新发展？如何更好的落地自动化测试技术，提升质量管理效率？人工智能 AI 与测试技术结合会产生怎样的火花？物联网测试体系搭建有哪些注意事项？在经济寒冬和行业人才结构大变革的双重背景下，测试从业人员面临怎样的职业技能挑战？… 期待与你相约 MTSC2019 大会现场（6月28-29·北京国际会议中心），共同探讨精彩议题！更多信息，访问 MTSC2019 大会官网地址：https://testerhome.com/mtsc/2019 。 ...

前言　大家好，这里是@IT·平头哥联盟，我是首席背锅官——松鼠，今天要分享的是最给一些还没入门的同学或需要提升的同学一些指引,详细说明自己这几年来经历怎么一步一步转型,给大家一个参考,希望可以少走些弯路写在最前：由IT平头哥联盟 - 测试同学整理！作者：首席背锅官∙松鼠交流群：912594095、公号：honeyBadger8，本文原创，著作权归作者所有，转载请注明原链接及出处。　这是@IT·平头哥联盟的第一篇测试文章,所以写篇针对小白迷茫或刚培训完入职后想提升迷茫不知道该怎么做的同学,我在15年的时候也培训过,也很清楚从培训或自学到入门转型的整个过程,也清楚工作后的提升过程.　说说整体计划,以后我们会分享自动化,性能,基于安全一些技术文章,会结合现在工作中所用到的技术来进行分享,目前工作中有用到jmeter做性能,rf,BDD(lettuce)做自动化,Appscan做安全,当然还有最基本的功能测试(黑盒).当然,有兴趣写博客的大牛,欢迎加入我们@IT·平头哥联盟一起写技术博客,一起带动大家学习进步,快乐你我他，欢迎投稿哦～ ～～～言归正传～～～引言很多小白会问的问题：我是做*外行的,跟IT没任何关联能做测试吗?做测试加班多吗?会不会很难呢?学历要求高吗?测试难还是开发难,哪个比较好入门,我应该转型哪个呢?我不知道要怎么自学,不知道要怎么入手,有种不知所措的感觉,是不是要培训呢?黑盒测试和白盒测试哪个工资高?我做测试应该要学哪个语言呢?java好还是python好?测试以后发展前景怎么样呢?我年纪大了,27,28,30岁了,做测试还来的及吗?我要是培训了,找不到工作,那岂不是亏了学费又浪费了时间?已转型做功能的同学可能会问:我功能做一年,两年了,还只会功能,我要怎么提升呢?整天工作点点点,想提升又不知道怎么做?我应该学那门语言呢?总感觉我工资提不上去了？反反复复,来来回回都是这些问题,这次我详细说说!仅仅个人观点提供参考!以下关于我的一小段转型历程～～～～～～　这里简单说明我转型的经历,以前做的行业就不说了,跟IT一点关联都没有,哈…　三年前的某一天决定要转行到it行业,想转型到it的想法都是认识一个后台开发的小哥,健身房认识的,当时处于迷茫期的我只要认识一个朋友就会问些行业之类的话题,当然不是直接问了,毕竟有点不好,会先说自己不知道要做什么,然后再问他做的行业之类的.　当时他跟我说后台开发,那时的我并不知道后台开发是什么东西,他说些代码的,我回了什么是代码,哈哈哈,他也不知道怎么回答我. 后面他也说这行业工资会高点,当时我并没有很注意这个,因为对我来说都不知道是干什么的,也没去了解,是经过别的行业洗礼后才想到这小哥哥,然后就打电话问他这行业情况,再各种查资料,他最后给我的建议就是去培训,说我这情况只能培训,说了个机构叫我自己去了解,最后我就去很多家机构了解对比啥的,就报名了. 是的没错,直接报名了～～ 想都没想万一转型不成功会咋办的问题…. ,这里培训的是安卓开发,现在想想胆子也挺大的.　培训的过程很辛苦,4个月时间,现在想想都不知道怎么熬过去的.是不是很好奇为什么培训开发做测试呢?当时开发学完入职了一家公司两个月,一直加班好累,每天感觉头脑在冒烟,当时就一个想法,这生活不是我想要的,请原谅没出息的我! 然后就想转型测试.　转型测试一开始我在网上了解才知道测试分好多种,功能测试、自动化测试、性能测试、安全测试，当时就想怎么一个测试也有那么多种,还以为直接转很简单,网上看了那么多感觉都没接触过….,当时想法先用开发简历投测试试下,边投简历边自学,一直认为有开发的经验测试应该会很受欢迎,没想到一个电话都没有. 有开发经验测试领域很受欢迎这观点是没有错的,但是测试零经验就没有人要了.我记得当时投简历好几天有个电话叫我去面试,我问了下测试工资能给我多少,对方说最高8k,我回了相对我现在的工资差别有点多,我接受不了,然后就没去面试了.　这时候我也好好思考了,要顺利转型我是不是又要培训测试?这样我又要花费好多时间,金钱也要投入,当时松鼠我很穷,生活费都是刷信用卡和支付宝的网商贷里面拿出来的…..,我选择自学,当时我就辞掉这份工作了,然后网上买了一些测试的视频,整套完整的很便宜,视频看了两三天实在是看不下去,这时很清楚自己不适合自学,然后就去走了好多家机构进行对比,了解机构的过程还是挺逗的,很多机构以为我是小白老是要忽悠我,总是说那些什么小机构,不出名的机构怎么样没保障,找工作也没保障之类的,当时好想笑,找工作不就是简历给外包面试吗?有什么不保障的,又不是进自研.当时什么51,川石,泽林,怀谷(这个名字有点忘记了),有同学在泽林培训过,当时我也打算去了,还好群里遇到另一个机构去看了学费好便宜还是不贷款找到工作后再自觉给学费的,当时觉得好神奇,直接就定下来了,去那边租房学了两个月,有开发的基础学测试真的是太简单了,哈哈哈哈 ～～ 学完果然都在我的预算之中,顺利拿了很多的of.～～～～～～～以上是我的一个转型过程,比较麻烦,还花费很多的时间,不过到现在没后悔过～～～～～～～～问题观点:转行其实就是看一个字 —— 胆量!很多人转行都犹豫这犹豫那的,怕这做不了怕那做不了,我当时都没犹豫过这个,刷信用卡当时有个大胆的想法…就算我转行没成功这几千块钱的生活费我去餐厅洗碗也能还上…… 哈哈哈哈,现在想想还挺逗的it学历确实要求比较高,这是行业的硬性要求没办法,身边有很多高中毕业的,虽然也是高薪就业,但肯定是用了些办法进公司的,低学历首先肯定的是跟大公司无缘.这个要切记,现在本科以下自研的公司很难进,大专外包很容易,外包要求比较低不管以前你学习怎么样,测试这个绝对是能上手的,这点倒不用担心,因为测试太简单了(功能测试),至于自动化,性能都是要后续自己提升,这就看自己了还要注意一点:测试学习两个月就够了,开发学习起码要4个月(如果培训的话)自学的,测试给自己3个月时间,开发一般需要8个月左右,自学效率不高,能在这个时间内完成那是很了不起加班问题,太过于执着加班的人,可能真的有点不适合it,这行业不加班的公司还真的很少,不想加班的单位其实是有的,但你本身要有这条件,一般不怎么加班的公司比较多的领域就是银行单位(带编制岗位),金融行业的技术不加班的还是挺多的,当然加班的也不少,我所知道的金融公司不加班的比较多(这里不加班的概念是加班比较少),外包的话,像bat华为等类似大公司都是加班特别厉害的,身边有华为外包的真的是996上班形式的…..,还有一种公司不加班的,那就是外企年纪问题,年纪大了做it确实是有点不合适,这是个人观点.身边很多年纪在30+的才去培训,这个年纪培训有个点事你要学好点,因为你找工作这经验需要包装挺多的,要懂的比别人多,一个三十多岁总不能说才工作一两年吧,半路转行的很多公司不会要的,外包还是很好近的.年纪大也确实比较不好找工作,我们公司一般面试接到32以上的一般就不怎么会要了…..,个别公司吧!语言方面:现在测试领域java和python用的都比较多,python是一个趋势,现在测试很多都在转型python,测试方面这两个语言已经不相上下了,新人建议学python,因为python相对好入手点测试的前景,前景这个心态还挺重要的,首先你进入这行业,总不能一直只做功能不去提升吧,一辈子只做功能的话,那你的前景就真的很窄,不过功能做的好的话转产品那前景又扩大了一步,拿我自己来说吧!我到现在我都很担心自己哪天失业,所以只能经常看看书,视频来提升自己.也有计划转型产品但是感觉技术还不错,还想多做两年,当然只是一个计划而已.只要你技术好,就不用担心前景问题小白怎么入门?一般it入门方式也就三种,校招进入企业,自学和培训,转行的也只有自学和培训两条路,有能力自学的优势就是省了挺多钱的,培训就需要培训费和生活费,我个人不排斥培训,毕竟经历培训也都找到工作,工资也还好,个人建议找个便宜的机构培训. 原因:培训出来一半工资会比自学的工资高,假设自学6k,培训8k,那培训出来年薪就会多两万多,这两万多足够付这培训的费用了,最后还是赚了.需要注意的是,年纪太小,培训需要小心,年纪小培训工资都不会高到哪里的工作后要怎么提升呢? 工作后提升两种方式: 1.最快的就是利用公司项目提升 2.业余时间提升(看书,视频等),业余提升可以说是相当难,亲身体验的,因为工作后有点惰性,下班后就不想动了,哈哈哈.要是公司有需求做自动化参与什么的,提升是最快的.我提升的几乎都是公司需求自己摸索自己做的.业余都是担心做不出来查资料学习,只要有需求都会去补知识的.!> 我个人想到的目前是这些问题,还有其他问题的可以留言,我会一一回复的,当然有不懂的也可以问我,如果我会的问题,知无不言.也可以加群,在下方有群号,测试的加测试群,前端加前端,也可以加q9617 101 68写文章目的:一方面逼自己学习提升,一方面提升自己文采,还有最重要想积累下自己的名气,不然就不会辛辛苦苦写博客了,需要能帮助大家,来给我个赞吧!????下一步文章计划列表:用例设计方法详解mysql入门(测试必备技术)Linux入门(测试必备技术)什么是接口测试python-lettuce介绍基本安全测试知识python基础学习jmeter性能测试性能优化策略(难度较大)robotframwork 讲解接下去先写这些文章吧! 慢慢来,一个一个写,哈.感觉要好辛苦,留个言给个赞吧! 一个人可能记不住那么多,有漏的欢迎指点.有大牛要写博客的可以加入我们@IT·平头哥联盟,一起写博客!热门推荐如何规范化测试流程，看这篇就够了～小程序项目如何设置资源的防盗链～如何给localStorage设置一个有效期？作者：松鼠 - 首席背锅官原文链接：https://www.susouth.com/theor…交流群：912594095、公众号：honeyBadger8本文原创，著作权归作者所有。商业转载请联系@IT·平头哥联盟获得授权，非商业转载请注明原链接及出处。