自动化测试

任何行业的公司都可能会经验重大的财务窘境，这种窘境往往导致供应链中断、劳动力短缺和经营成本增加。 通货膨胀压力、利率回升和地缘政治不确定性的压力减轻了企业的资产负债。企业须要适应一直演变的消费者需要和数字化转型，加上面临着强烈的竞争，利润空间收到压缩。 这些财务窘境迫使企业摸索翻新的办法，在高度不稳固的经济环境中放弃弹性并降低成本。 应用ReadyAPI就是其中一种办法。借助ReadyAPI，企业能够在放弃软件公布品质的同时节省开支。您的组织能够简化测试流程，发现能节约老本的潜在机会，并确保您的软件放弃一流水准。 为您提供实质性帮忙的几种办法自动化测试手动测试既耗时又低廉，还可能产生人为谬误，缩短公布周期。ReadyAPI提供了弱小的自动化性能，您能够编写脚本测试用例并主动执行它们。通过主动执行反复的测试，能够 开释贵重的资源、缩小人为干涉并减速测试。晚期发现并解决缺点在开发周期的晚期进行彻底的API测试。如果您能在初期阶段发现潜在问题，就能大大降低开发前期修复bug的老本。缩小了应急解决问题的工夫，您就有更多的工夫专一在构建新性能上。虚拟化API，实现具备老本效益的测试在理论我的项目中，API通常依赖于内部服务，这在开发和测试阶段可能难以获得。这有几率导致延误，减少额定的费用。ReadyAPI的虚拟化性能让您能够模仿一个API，因而不须要内部的依赖项。通过虚拟化 API，即便内部服务不可用，您的团队也能够持续测试，从而缩小停机工夫，升高内部服务应用的老本。负载测试对于任何一个胜利的软件应用来说，可扩展性都是要害的因素。从久远来看，在正式公布之前发现问题能够节俭大量老本。ReadyAPI 提供负载测试性能，因而您能够模仿一个重负载环境，并在其中对API和应用程序进行压力测试。通过分析测试后果，您能够优化零碎的性能和基础架构，防止在最蹩脚的状况下呈现问题。促成合作，放慢上市ReadyAPI促成了开发、测试和经营团队之间的合作。借助其用户敌对的界面，所有相干人员都能够轻松地参加测试。这种合作不仅确保大家领有统一的指标，而且减速了开发和测试周期，从而实现更快上市，升高总体开发老本。测试数据治理生成测试数据既繁琐又低廉。ReadyAPI通过各种性能简化了测试数据治理，例如数据驱动的测试和数据源集成。通过无效地复用测试数据，您能够节俭贵重的资源，并在测试场景中放弃较高的准确性。继续集成和继续交付（CI/CD）工具集成ReadyAPI与风行的CI/CD工具无缝集成，如Jenkins、TeamCity和Bamboo。这意味着您能够将自动化的API测试纳入CI/CD流水线，确保在投入生产之前，每次代码更改都通过全面的测试。尽早发现潜在问题能够显著为您节省成本。不要让估算限度障碍您交付高质量的软件通过将ReadyAPI纳入软件开发生命周期，您能够在节约老本和交付高质量的软件公布之间获得均衡。 自动化、晚期谬误检测、API虚拟化、负载测试、协同开发、高效的测试数据治理和CI/CD集成只是ReadyAPI提供的局部弱小性能。 有了松软的测试根底，您就能够专一于翻新，创立出超过用户冀望的卓越软件产品，同时将老本管制在预算内。 文章起源：https://smartbear.com/blog/balancing-your-budget-with-excelle...

起因是看到stf（设施治理平台）有开源了adbkit这个精简的adb交互库，又感觉部署stf太麻烦了，就想着用adbkit实现一个精简的设施治理，用于自动化测试先提供一个思路 后期首先这是一个node我的项目，先引入adbkit npm install adbkit --save监听设施把多个android手机插入同一台电脑，如果每次都用adb devices去查问，未免有些太过麻烦，而adbkit提供了监听的办法 const client = AdbInteraction.getInstance().getClient()client.trackDevices().then((tracker) => { tracker.on("add", async (device) => { console.log(device.id) }}其中的device.id就是设施的serial号（即adb devices中的id） 设施治理当设施连贯后，能够在监听事件中对设施调配一个端口，并绑定端口 const client = AdbInteraction.getInstance().getClient()const bridge = {}client.trackDevices().then((tracker) => { tracker.on("add", async (device) => { // 指定一个端口，或者能够写一个办法去调配 const availablePort = 3000 // 创立一个adb usb连贯 bridge[serial] = client.createTcpUsbBridge(serial, { auth: () => Promise.resolve() }) // 绑定端口 bridge[serial].listen(availablePort).on("error", (e) => { console.log("err" + e) }) // 设施信息写入数据库 // 如serial号，port号 }}这里咱们假如调配3001端口给刚刚连贯到的设施，间接执行命令 ...

AREX 是一款开源的基于实在申请与数据的自动化回归测试平台（我的项目地址：https://github.com/arextest），利用 Java Agent 技术与比对技术，通过流量录制回放能力实现疾速无效的回归测试。同时提供了接口测试、接口比对测试等丰盛的自动化测试性能，无需编程能力也可疾速上手。 在应用 AREX 流量录制性能时，AREX Java Agent 会记录生产环境中 Java 利用的数据流量和申请信息，并将这些信息发送给 AREX 数据存取服务（Storage Service），由数据存取服务导入 Mongodb 数据库中进行存储。当须要进行回放测试时，AREX 调度服务（Schedule Service）将会依据用户的配置和需要，通过数据存取服务从数据库中提取被测利用的录制数据（申请），而后向指标验证服务发送接口申请。同时，Java Agent 会将录制的内部依赖（内部申请/DB）的响应返回给被测利用，指标服务解决实现申请逻辑后返回响应报文。随后调度服务会将录制的响应报文与回放的响应报文进行比对，验证零碎逻辑正确性，并将比对后果推送给剖析服务（Report Service），由其生成回放报告，供测试人员查看。在整个过程中，AREX 的缓存服务 Redis 负责缓存回放过程中的 Mock 数据和比对后果，以进步比对效率。 本文以 community-test 工具为例，从 AREX Agent 配置到录制回放、问题定位，残缺展现 AREX 接口自动化回归测试的全过程。 community-test（https://github.com/arextest/arex-community-test）是一个由 AREX 提供的用于测试和验证 AREX 零碎性能的工具，它是一个 Java 应用程序，依赖于 MySQL 和 Redis，用于模仿业务服务。 AREX 运行环境笔者在应用环境申请了 Linux 服务器，这是由 OPS 提供的设施。 服务器的 IP 地址是 10.5.153.1，领有 128GB 内存和 32 Core。该服务器能够通过公司办公网进行拜访，但其余外部环境无法访问。次要目标是在该服务器上安装 AREX 服务和部署 community-test 的测试环境。 为了确保服务器可能拜访公网，须要进行一些设置。在装置过程中，须要下载 AREX 的安装包，并获取 community-test 的代码进行编译和公布。如果你的服务器能够间接拜访公网，则能够跳过设置代理的步骤。否则，须要设置代理以确保服务器可能拜访公网。 ...

新增性能反对发送、录制 Dubbo 3.x 申请相干 PR：https://github.com/arextest/arex-agent-java/pull/76 Apache Dubbo 是一款高性能的分布式服务框架，在提供高可用性、可伸缩性、服务主动注册和发现、负载平衡、容错、调用链追踪、服务治理等方面提供反对。新版本中 AREX 反对对 Dubbo 3.x 版本的申请进行录制和回放。 发送 Dubbo 申请须要填写 Dubbo 服务的地址。Dubbo 服务的地址通常包含三局部信息：协定、服务地址和服务端口。例如，Dubbo 服务的地址为：dubbo://{{本机ip}}:20880/com.xxx.service.XXXService。 协定：Dubbo 反对多种协定，包含 dubbo、rmi、hessian、http 等等。在填写 Dubbo 服务地址时须要指定应用的协定，例如 dubbo。服务地址：Dubbo 服务提供者的 IP 地址或者主机名称。服务端口：Dubbo 服务提供者的监听端口。新增录制用例详情页面为了不便查看和治理录制到的用例，新版本中在回放报告中的录制用例列表中新增了一个录制详情页面，该页面中展现了申请的详细信息，如申请参数、申请头、响应内容等。 为被测利用新增 Agent 状态显示在利用设置页面新增了显示被测试利用的 AREX Agent 状态的性能，不便测试人员查看以后服务的 Agent 是否失常运行，从而及时发现和解决问题，保障测试过程的可靠性和稳定性。 相干 PR：https://github.com/arextest/arex/pull/119 arex-agent-java 版本升级为 v0.2.01.欠缺动静类性能a. 反对 Spring @Cacheable相干 PR：https://github.com/arextest/arex-agent-java/pull/123 新版本中 AREX 反对 Spring 框架中的 @Cacheable 注解，能够将办法的运行后果缓存到指定的缓存中，下次再调用该办法时，能够间接从缓存中获取后果，防止数据库拜访等操作，更加不便地实现缓存的治理和应用。 b. 反对应用配置形式和代码注解形式配置动静类相干 PR：https://github.com/arextest/arex-agent-java/pull/114，https://github.com/arextest/arex-agent-java/pull/133 配置动静类 Mock，可间接在下图所示的界面进行配置： 以下是 AREX 中反对动静类配置的示例，用于模仿内存中的类数据。 ...

作者：京东批发 杜兴文 随着前端技术的一直倒退和应用程序的日益简单，前端自动化测试也在一直演进。 Web 前端 UI 自动化测试发展史能够追溯到 2000 年，过后最早的 Web 应用程序越来越简单，开发人员开始应用自动化测试工具来确保应用程序的正确性和可靠性。 在晚期，自动化测试是通过应用脚本或脚本来模仿用户的操作来实现的。这些测试工具通常基于 JavaScript 编写，并且须要对 Web 应用程序的交互方式进行深刻理解。 随着 Web 应用程序变得越来越简单，自动化测试的需要也越来越高。2005 年，Selenium 开始风行，它是一种基于 Java 的自动化测试框架，能够用于模仿用户操作并进行 Web 应用程序的自动化测试。 Selenium 和其余自动化测试工具的呈现使得 Web 前端 UI 自动化测试变得更加容易和高效。随着 Web 应用程序的一直演变，自动化测试工具也在不断更新和倒退。现在，自动化测试曾经成为 Web 利用程序开发过程中不可或缺的一部分，它们能够帮忙开发人员更快地发现和修复谬误，进步应用程序的性能和可靠性。 上面是前端自动化测试经验的阶段:手动测试：晚期的前端开发过程中，开发人员须要手动测试代码的正确性，这须要大量的工夫和精力。2.单元测试：随着前端技术的一直倒退，单元测试开始呈现。单元测试是一种自动化测试方法，它测试代码中的最小可测试单元，例如函数或模块。单元测试能够帮忙开发人员更快地发现和修复代码中的谬误。 集成测试：集成测试是单元测试的进一步倒退，它将单元测试集成到整个应用程序的测试中。这种办法能够更疾速地发现整个应用程序中的谬误。端到端测试：端到端测试是一种自动化测试方法，它测试从输出到输入整个端到端应用程序的过程。这种办法能够帮忙开发人员更快地发现和修复应用程序中的整个端到端谬误。继续集成和继续交付：继续集成和继续交付是一种自动化测试方法，它将测试集成到整个开发周期中，包含代码提交、构建、测试、部署等环节。这种办法能够帮忙开发人员更快地交付高质量的应用程序。自动化测试框架和库：随着前端自动化测试的一直倒退，呈现了许多自动化测试框架和库。这些框架和库能够帮忙开发人员更疾速地编写和运行测试用例，进步测试效率和品质。人工智能和机器学习：最近这些年来，人工智能技术和机器学习办法逐步利用于前端自动化测试中。这些办法能够帮忙开发人员更疾速地辨认和修复谬误，进步测试效率和品质。总之，前端自动化测试是一个一直倒退的畛域，随着前端技术的一直倒退和应用程序的日益简单，测试人员须要一直地学习新技术和办法来跟上变动。 同时呢，咱们在做前端自动化的时候又会随同着一些挑战编写 UI 测试脚本可能会很耗时，因为这部分工作须要测试循环之前就要做好。但这份辛苦是值得的；只不过，UI 脚本实质上是软弱的。大多数测试是通过 Selenium 测试脚本实现的，这些脚本能够用多种语言编写，例如 Java、Python 和 C++。 上面列举一些挑战事项：重常识。编写脚本的人必须具备该方面的技术常识和教训。耗时。因为流程的起因，一项测试可能须要 5 – 10 多分钟能力运行。加载浏览器 > 执行工作 > 设置和解析测试 > 数据加载等等。保护。古代应用程序具备动静前端 UI。当同一页面从新加载时，其中的元素定位器和链接可能会在后盾更改它们的定义形式。期待条件可能会毁坏测试。如果页面加载工夫更长，则会返回一个损坏的测试。解决多个谬误。简单的场景意味着微小的数据量。筛选这个可能很麻烦。故障排除。依据问题的频率和修复它所破费的工夫，找出是什么毁坏了测试可能很艰难。动静利用。因为麻利开发，Web 应用程序以及应用程序自身始终在发生变化。测试必须从保护角度和后果角度来思考。前端自动化测试最佳实际又是什么呢，上面列举一些： 因为用户界面是用户触摸和看到的，因而实现自动化测试以缩短公布周期至关重要。与开发一样，所有团队都能够遵循一些相似的最佳实际，以确保从他们的自动化投资中取得丰富的投资回报。 1. 遵循统一的命名约定。 2. 查看哪些测试用例应该自动化。 3. 创立品质测试数据。 4. 放弃测试独立。 5. 不要只依赖一种类型的测试。 ...

作者：vivo 互联网服务器团队- Liu Yanjiang月光宝盒是一个基于流量录制回放的自动化测试平台，通过录制回放取代编写脚本进行自动化回归，晋升测试效率和覆盖率。因为其解决方案具备很强的通用性，所以咱们把这它开源进去，心愿能帮忙到有须要的用户。 一、月光宝盒 是什么？Moonbox（月光宝盒）是 JVM-Sandbox 生态下的一款流量录制回放产品。所谓流量录制回放是服务端通过挂载agent探针主动注册到服务端，拦挡服务端调用，将所有内部调用依赖的内容（如数据库、分布式缓存、内部服务响应等）进行残缺记录造成录制流量。其外围价值是通过录制流量数据，将流量数据转化成可复用、可执行的自动化用例，疾速在测试环境中进行回放比对接口返回值和内部调用依参数（见下图）。Moonbox（月光宝盒）提供了大量的罕用插件，可能对常见的两头调用进行录制回放，同时也提供了十分牢靠、高性能的数据存储、计算能力。 二、月光宝盒 有哪些劣势？正如结尾所说月光宝盒是一款面向测试、研发工程师应用的低门槛、高性能、更易于应用的自动化测试工具。这款产品曾经在vivo运行了2年多了，通过咱们继续优化、打磨领有很多实用、易用性能。它的长处次要体现在上面几方面： 2.1 全面可视化视操作（局部性能）(1）基于工作、接口维度的流量治理能力 (2）具体的流量展现细节（申请、响应、子调用） (3）基于工作、接口维度的回放数据管理，叠加各种维度统计、查问能力 (4）易于人工剖析的回放比对后果和差别展现 2.2 丰盛的插件反对月光宝盒反对十分多组件录制和回放能力，基本上能满足绝大多数人诉求。 2.3 多种部署形式Docker：这种形式简略、牢靠，让您能够摒弃简单的环境配置和装置，疾速在本地体验咱们我的项目。惯例形式：这种形式简单、步骤繁琐，须要依照步骤创立ES和MySQL数据库，初始化数据表，更新好利用配置，装置好前端node服务。此外月光宝盒是前后端拆散我的项目，当您应用该我的项目须要别离部署前端、后端，十分有助于您后续将我的项目部署到生产环境。 2.4 性能安全可靠平台对性能进行了长期优化，在vivo外部历经多个高并发系统验证。咱们对agent端录制流量进行了一系列平安防护，例如对雷同接口同时只能有一个进入采样中，限度并行录制接口数量。服务端应用了ES贮存流量，无效晋升了数据贮存规模。 三、月光宝盒 实现原理3.1 整体架构月光宝盒平台分为2个局部，别离为moonbox-agent 和 moonbox-server（整体架构如下图所示） moonbox-agent 应用Java-attach技术(理论的动静字节码加强由JVM-Sandbox实现)动静代理到指标过程上，提供流量录制和回放的加强。moonbox-server Agent端应用接口，提供配置查问、录制流量保留、流量查问、回放后果保留等服务录制工作/回放工作的配置，agent工作远程管理能力和治理后盾操作界面(前后端拆散部署) 3.2 流量录制&回放流量录制 外围逻辑是将agent散发到用户填写的机器上(本地、近程机器），而后将agent attach到用户填写利用所对应的正确过程下来。而后通过JVM-Sandbox的BEFORE、RETRUN、THROW事件机制拦挡要害调用地位获取流量入参、出参。整体流程见下图整体流程见下图： 流量回放 外围逻辑是将agent散发到用户填写的机器上(本地、近程机器），而后将agent attach到用户填写利用所对应的正确过程下来，agent启动后从服务端一直拉取流量去散发到对应接口做回放，整体流程见下图： 心跳治理 Agent启动后会独自开启线程固定间隔时间通过http申请给服务端上报心跳 3.3 Agent启动过程执行脚本将sandbox agent attach到指标java过程上，sandbox 启动jetty服务，加载moonbox module，而后从服务端拉取moonbox配置，加载流量录制和回放插件。 四、 和 jvm-sandbox-repeater 关系？Moonbox是基于jvm-sandbox-repeater从新开发的一款流量回放平台产品。在jvm-sandbox-repeater根底上重写了很多模块，并提供了更加丰盛性能，同时便于线上部署和应用，和jvm-sandbox-repeater差别如下： 五、为什么要开源？流量录制回放技术简单，挑战较高，开源社区尽管有很多相似产品然而在易用性方面都有一些欠缺，咱们心愿通过开源月光宝盒帮忙对该方向有趣味的开发者疾速构建本人的自动化工具，同时能够基于咱们这款产品制订个性化诉求。此外，月光宝盒自身也借鉴了jvm-sandbox-repeater设计和计划，是开源的受害方，当初咱们将本人思考和摸索回馈给开源社区，丰盛流量回放开源技术生态。除此之外通过社区中开发者的应用，也能够帮忙咱们更好的改良咱们的工具，取得更多的需要场景输出，也能让该工具取得更加久远的倒退。 六、Roadmap月光宝盒曾经实现V1.0.0版本开源，初步实现了各项重要性能开源，后续咱们会持续性的实现平台性能、体验优化工作，同时踊跃收集社区应用反馈的性能需要，将一些好的需要纳入咱们版本打算外面。2023年咱们布局了一些迭代版本，如下图所示： 七、写在最初明天月光宝盒的开源只是咱们迈出的一小步，后续咱们会继续依照打算向社区奉献版本和个性。如果您对月光宝盒有趣味，欢送体验咱们开源产品。如果您有问题或者更好的计划，欢送向咱们开源我的项目奉献反馈ISSUE和奉献PR，这将是咱们莫大的荣幸。 GItHub我的项目地址：https://github.com/vivo/MoonBox

重构回放测试剖析性能，可视化调用差别之前的版本中回放测试的差别剖析界面如下所示： 在 0.2.7 新版本中，回放测试报告中将录制回放过程中的主体及第三方调用差别进行了可视化展现，帮忙使用者更直观地理解录制回放之间的差别。如下图，表明回放测试中呈现两个差别： 回放时 HttpClient（Http 客户端库）对第三方依赖 /posts/2 呈现调用缺失（call missing），即回放过程中 HttpClient 没有正确地收回针对 /posts/2 的申请调用。回放过程中 HttpClient 对第三方依赖 /posts 的调用后果绝对录制后果呈现差别（value diff）。 表明比对后果无差别，如上图示例中，回放后主接口 /httpClientTest/okHttp 的返回后果与录制无差别。 减少测试用例标签配置和形容配置新版本中，对测试用例增加了更多治理性能。目前能够对测试用例增加标签（Add Tag）进行分类，前期将减少通过标签搜寻用例的性能，方便管理。 另外能够为用例增加形容（description），进步用例可读性，让协作者更容易了解测试用例的目标和预期后果，并且能更好地把握测试内容。 减少比对测试及批量比对性能当咱们须要比对新老零碎两个接口响应报文的差别时，能够应用 AREX 比对测试，将雷同的申请报文发送至不同环境的两个接口地址，比对响应报文的差别。如后端系统重构（或架构降级）时，通过比照新零碎和旧零碎接口返回的数据是否完全一致，来确保零碎重构没有没有带来接口问题。 在日常测试工作中，同样的两个接口之间的比对测试通常须要涵盖多种场景，如果每个场景或用例都须要一个一个手动执行，测试的效率是很低的。新版本中减少了批量执行比对测试的性能，能够自动化测试过程，大大提高测试效率。 如果须要比对两个接口在多种状况下的响应报文差别，只须要将所有的状况保留为比对测试用例，批量运行即可。 抉择测试用例汇合下拉菜单中的 Batch Compare 批量运行比对测试用例。 或将鼠标移至 Collection 右侧的批量运行图标，点击 Batch Compare 批量运行测试用例。 在关上的标签页左侧抉择要执行的测试用例，点击右侧 Run Compare 运行。 运行完可查看所有 Case 比对后果。 将鼠标移至呈现差别点的节点上，显示的是该节点在响应报文中的具体位置： 测试用例默认继承父节点接口申请配置0.2.7 版本中，在接口申请下新建的测试用例将主动继承以后接口申请下的配置，如 URL、申请形式及 Parameters、Header、Body 及前置脚本（Pre-request Script）等。 通过继承父节点的接口申请配置，测试用例不须要一一从新定义接口的申请参数及前置脚本，从而缩小测试用例编写的工作量和工夫。 下载 AREX 0.2.7应用 Docker 装置：git clone https://github.com/arextest/deployments.git cd deploymentsdocker-compose up -d部署 Agent：详见文档。AREX 文档：http://arextest.com/zh-Hans/docs/intro/ ...

AREX 是一款开源的自动化测试工具平台，基于 Java Agent 技术与比对技术，通过流量录制回放能力实现疾速无效的回归测试。同时提供了接口测试、接口比对测试等丰盛的自动化测试性能，无需编程能力也可疾速上手。 AREX 能够通过 Docker-Compose 一键装置所有的根底服务组件。除此之外，AREX 也同步提供了在线试用平台 AREX Demo，与官网公布的最新版本保持一致，无需部署所有的服务组件即可试用，大大减少了试用费力度。 本文将介绍试用 AREX Demo 平台中接口测试性能及回放测试性能的具体操作步骤。心愿通过本文，为大家提供一种实现高效自动化回归测试的新思路。 拜访 AREX Demo 环境应用 Chrome 浏览器拜访 AREX Demo 环境：http://demo.arextest.com/，首次登录须要进行注册。 输出邮箱后，点击 Send Code 按钮， 稍后邮箱将接管到 AREX 发送的登录验证码，如下图，将验证码填入即可登录。 登录后，进入 AREX Demo 的前端页面，如下图所示： 页面包含 Work Space 治理区域、接口测试（Collection）、回放测试（Replay）、环境配置（Environment）和利用配置（AppSetting）、用户操作配置等局部，详见 AREX 官网文档。 Chrome 插件装置因为浏览器拜访跨域名服务受限，在应用 AREX 接口测试性能前，须要装置 Chrome 插件，通过插件实现对外申请接口。 拜访 Chrome Web Store，在搜寻框中输出 AREX，增加 Arex Chrome Extension。如下图： 如无法访问 Web Store，能够间接下载最新的插件包到本地进行装置，以后最新的插件版本是 v1.0.45。 至此，所有的后期筹备工作实现，接下来将介绍如何应用 AREX 的接口测试及录制回放性能。 应用 AREX 进行接口测试本文中验证性能应用的是由官网提供的模仿服务 AREX-Community-test，Demo 环境中该服务接口裸露地址是 demo.arextest.com:18080。 ...

AREX 官网 QQ 交换群：656108079本文将具体为大家介绍一下如何在本地进行 AREX 的编译和配置。 背景AREX 是一款由携程开源的自动化测试工具， 基于 Java Agent 技术，录制生产环境实在用户的申请，并在测试环境回放，同时智能比对剖析回放后果，从而实现疾速无效的回归测试。除此以外，也提供了用例治理、接口测试（脚本验证、双环境比对）等丰盛的自动化测试性能，是一个不须要编程技术，也可疾速上手的自动化测试工具平台。 目前你能够通过 Docker-Compose 命令，一键缺省装置 AREX 所有根底服务组件，包含前端 UI，MongoDB 数据库，Redis 缓存，数据存取服务（Storage Service）， 调度服务（Schedule Service），剖析服务（Report Service）等（如上图所示）。这种形式不须要手动装置和配置每个服务，大大简化了装置过程，进步部署效率。（详见文档） 当然，你也能够通过在本机上构建 Docker 镜像的形式在本地对各个服务组件进行编译和装置。这种形式实用于须要对单个服务进行开发和测试的场景，能够防止装置不必要的依赖项，同时也实用于须要在离线环境下部署的场景。 本文将具体为大家介绍一下如何在本地进行 AREX 的编译和配置。（如果你有其余非凡的部署需要或倡议，也能够在 GitHub Issue 中提出） 本地构建 Docker 镜像首先，创立 github-arex 目录，用于寄存 AREX 各个服务组件。倡议将 AREX 各个我的项目放在同一个目录下，Deployment 仓库中 Shell 脚本都是以相对路径来进行拜访的，如果目录门路产生变更，也须要同步批改 Shell 脚本中的相干配置。 下载 AREX Deployment 仓库Deployment 仓库中蕴含编译命令、Dockerfile（用于构建镜像，蕴含了构建镜像所需的指令和依赖项） 和 Docker-Compose file（用做容器编排进行环境部署）等文件，编译时须要切换至 dev 分支。 cd github-arexgit clone https://github.com/arextest/deployments.gitcd deploymentsgit checkout dev # 切换到代码仓库的 dev 分支，并将当前工作目录中的代码更新为 dev 分支的最新版本下载编译 AREX 前端 UIAREX 前端 UI，是交互组件，次要负责用户配置执行的交互界面。 ...

近日，寰球当先的软件开发和可视化工具提供商SmartBear进行了首届合作伙伴评比，并向寰球不同地区的9个合作伙伴颁发了首个年度合作伙伴奖。DevSecOps解决方案提供商龙智是惟一一家来自中国的获奖合作伙伴，取得 “最具能源营销团队”名称。 SmartBear国内销售和渠道高级副总裁Darin Welfare示意：“祝贺咱们优良的合作伙伴，他们凭借各自杰出的成就而取得了奖项，这在咱们宏大且一直增长的合作伙伴生态系统中是一项微小的成就。SmartBear合作伙伴在帮忙软件开发团队提前发现问题、缩短交付杰出软件的过程中施展着关键作用。” 龙智自与SmartBear建设合作伙伴关系以来，就致力于为中国企业用户引入其主动UI测试工具TestComplete和主动API测试平台ReadyAPI，并围绕着这些工具提供征询、销售、施行、培训、技术支持等一站式服务，助力企业进步软件开发的测试效率与品质，帮忙中国企业落地更平安、更自动化的DevSecOps实际办法。 在2022年12月6日，龙智与SmartBear联结举办了“如何通过自动化测试实现降本增效与提质”网络研讨会，分享如何在晋升研发效率、确保公布品质的同时节俭研发老本。 对于龙智 龙智是一家DevSecOps解决方案提供商，专一于软件开发经营一体化畛域十多年，集成DevSecOps、ITSM、Agile治理思路及该畛域的优良工具，提供从产品布局与需要治理、开发，到测试、部署以及运维全生命周期的解决方案，通过业余征询、计划定制、施行部署、专业培训、定制开发等一站式服务，帮忙企业实现软件开发经营一体化，并确保安全防护融入软件研发的整个生命周期中。龙智与寰球DevSecOps畛域的许多出名厂商放弃合作伙伴关系。咱们是SmartBear受权合作伙伴 ，同时也是Atlassian寰球白金合作伙伴、云业余搭档，Perforce, CloudBees, Mend（原WhiteSource）的受权合作伙伴。 除了上海之外，龙智还在中国香港、日本东京、加拿大滑铁卢设有分支机构，服务寰球客户。凭借继续深耕、不断创新的精力，龙智的解决方案先后取得了金融、汽车、通信、游戏、互联网、芯片等行业1000多家企业的认可与信赖，被评为“高新技术企业”、“上海市‘专精特新’中小企业”。 对于SmartBear SmartBear提供了一系列值得信赖的工具，通过测试治理和自动化、API开发生命周期和应用程序稳定性，使世界各地的软件开发团队可能理解端到端品质，确保每个软件版本都比上一个版本更好。旗下屡获殊荣的工具包含SwaggerHub、TestComplete、Bugsnag、ReadyAPI、Zephyr和Pactflow等。SmartBear失去了32,000多个组织的超过1600万开发人员、测试人员和软件工程师的信赖，其中包含像Adobe、JetBlue、FedEx和微软这样的创新者。通过一个沉闷的P2P（端对端）社区，SmartBear满足客户的需要，让技术驱动的世界变得更美妙。SmartBear致力于恪守企业道德实际和社会责任，在服务的所有社区中促成善举。

RunnerGo反对自动化测试性能，其工作流程是：接口治理-场景治理-性能测试-自动化测试，所以自动化测试的运行内容为场景下的用例，咱们能够在“场景治理”中事后配置好该场景下的用例，也能够在自动化测试中创立用例。 打算治理在左侧导航栏抉择：自动化测试-打算治理-新建打算，创立自动化测试计划。 新建场景或导入场景自动化测试计划创立好之后能够间接导入场景或者新建场景 测试用例设计场景导入后能够在场景下创立测试用例，能够依据需要创立不同的用例，执行测试计划时会按程序执行每个场景下的测试用例。 工作配置RunnerGo自带定时工作配置，配置好测试用例后能够抉择定时工作配置，反对抉择每周、每天、每月执行，能够抉择程序执行或者同时执行每个场景。 增加收件人能够在右上角增加收件人，自动化测试完结时会发送邮件到指定收件人。 测试报告在报告治理页面点击查看按钮即可查看测试报告详情。能够点击某个场景查看这个场景下的用例执行状况。

在自动化测试工作中，有两个痛点始终困扰着很多团队： 每次测试都要专人从新编辑脚本，内容反复造轮子，费时费力，甚至不如人工测试不便；提前写好多个不同性能的脚本，编辑格调导致脚本间差别微小；大量调试批改升高了脚本复用性，脚本保护困难重重。如果将各类脚本中大量重复性内容固定下来，用对立的规范来标准脚本的编辑，那么团队只须要破费大量工夫精力，根据工作需要批改大量的内容，就能够疾速复用脚本，迅速开展自动化测试。这就是自动化测试框架能实现的事件： 代码复用率高标准规范，保护不便用例全面，应用灵便、便捷广州天纵的测开团队很早就留神到了这点，他们在自动化测试框架的设计和应用上积攒了丰盛教训。接下来咱们就一起和大家分享下天纵团队应用UWA Pipeline实现自动化测试框架的设计教训。 一、自动化测试框架天纵团队通过设计这套自动化测试框架，在每次发展测试工作时，都能依据需要，灵便配置对应的测试用例，将游戏内简单的GM操作简单化，实现了UI按钮的截图生成与配置。这些都极大中央便了自动化测试工作的发展。 1. 执行步骤的切分与组合 1.1 拆到不同的脚本中在框架中，应用动静导入所有的用例文件，通过动静model对象去调用用例中的指定函数来执行对利用例，例如model.Run()，代码逻辑写在run()外面。 #用os库，获取用例文件下所有用例返回列表list#遍历列表，应用importlib库，动静导入所有模块import os, importliblist = os.listdir('./示例/用例')for case in list: mod = importlib.import_module(f'示例.用例.{case}') mod.run()由此就将我的项目的测试内容拆分为一个个小的模块，在抉择执行用例时，就能够进行灵便的拼接组合。 1.2 依照ID与分类进行划分个别我的项目的老手流程中工作会很多，而且更改也很频繁，如果不对工作做一个分类，间接上代码，那么当有某个工作流程有调整时，前面可能全副都要跟着调整，导致耗费大量的人力和工夫。 因而，天纵团队对工作做了分类，每类工作对应1个工作ID。例如对话工作的工作ID为1，那就写一个办法task1()，对话工作的流程就写在task1()外面。多个对话工作，都是调用task1()办法，当前，不论对话工作有新增或缩小，都不须要改代码，若是流程有扭转，只须要改task1()外面的逻辑。 2. 通过RPC调用客户端接口 在Unity集成的Poco SDK中，客户端程序人员减少了“接管Python通过Poco收回的音讯”的性能，而后能够依据接管到的不同音讯内容去执行对应的性能。 目前已实现的性能有“返回游戏中Lua的配置表数据”、“关上指定界面”，以及上图的“调用GM命令”，本来须要人工关上GM界面手动进行配置的各种GM调试工作，当初在自动化测试过程中间接代码调用就能实现。 在此天纵团队揭示大家：对于用Poco去读取Lua配置取得数据的操作，尽量放在游戏工作流程前，或者说放在开始收集性能数据前。因为Poco读表会带来肯定的性能开销，大家须要防止这个开销对游戏性能剖析的影响。 3. 按钮的配置 自动化测试中，各类按钮的点击，是相当广泛和频繁的。天纵在框架中保护了两套按钮的点击形式，别离是“图片”和“字符串”，前者通过Airtest的图像识别进行按钮定位和点击，后者通过Poco的UI层级信息执行点击。 但随着我的项目迭代，UI的改变会很大，图片资源会被替换，UI元素名字也会更改，导致脚本也要频繁批改。为了解决这个痛点，于是在框架中将数据拆散，把按钮依照名称进行索引，把索引关系保留在配置表外面，在执行用例时，从表格中获取按钮来执行点击。 对于通过Poco的UI层级信息执行点击的计划，揭示大家在游戏开发后期就要同步好构造，把按钮的name写在配置表里，客户端程序人员通过读取按钮的name生成UI树，这样就能通过读取配置表来生成Poco的配置。 而对于通过Airtest的图像识别进行点击的形式，次要是思考到低端机，用图片可进步框架兼容性。 4. 测试异样主动告诉 为了应答大批量设施进行自动化测试且没有人员在现场值守的状况，天纵团队实现了测试状况的主动同步：在脚本报错后捕捉异样，将相干的截图和报错信息等，主动地通过沟通工具实时发送音讯到群里揭示对应成员，不便大家及时同步音讯和进行解决。 这里能够依据大家日常办公的沟通工具进行抉择，比方企业微信、飞书等，简略一点也能够用发邮件的形式。以飞书为例，先建个群，退出飞书机器人，建群实现后，获取webhook地址。 import json， requests# webhook地址url = "https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxxxxxxxxxxx"payload_message = { "msg_type": "text", "content": { "text": "你要发送的音讯" }}headers = { 'Content-Type': 'application/json'}response = requests.request("POST", url, headers=headers, data=json.dumps(payload_message))通过这样的形式，大家对异常情况可能进行及时的记录和干涉，不便后续解决相应的问题。 5. 在UWA Pipeline上运行 天纵团队将自动化测试工程打成zip包后，能够在UWA Pipeline上失常运行。在UWA Pipeline中创立定时工作，联合UWA Pipeline提供的云真机系统，实现日常的自动化测试。 ...

自动化测试模块是针对测试人员的简单业务的测试服务。咱们能够在测试用例中建设一个或多个“测试计划”，“测试计划”由接口和控制器组成，创立一个测试用例通常须要如下步骤：1、在API设计或API调试内保留接口。2、关上自动化测试-测试用例，新建一个测试计划。3、在右侧的API增加器内增加接口，从下方的控制器菜单里增加控制器。4、设置好执行条件（测试环境、测试数据、执行次数、间隔时间、遇到谬误是否继续执行、是否开启沙盒模式），点击保留并执行。5、查看返回的测试接口以及断言详情。 执行条件：a.测试环境可在自动化测试中切换我的项目下所有环境，并按该环境进行测试。 b.测试数据作为一名测试人员，最辛苦的阶段大略就是接口测试执行阶段，针对于某一个接口，有大量的测试数据须要批量验证，一个一个的更改申请参数太耗时耗力，应用参数化批量解决数据会比拟高效。 在 Apipost 6.1.3 版本的流程测试中，咱们推出了批量导入测试数据性能，反对内部导入文件实现参数化。目前反对json、txt、csv三种模式导入，能够很不便的导入流程测试的数据进行测试，这对测试人员的工作来说几乎就是锦上添花。 在Apipost7.0.0版本中，反对独自配置每个环境的测试数据，当切换到某环境并关上测试数据时，则应用该环境配置的测试数据。 上面就来给大家具体介绍下如何通过Apipost实现接口数据参数化导入验证。b-1.API调试内设置变量b-2.在想要测试的数据文件里，增加想要测试的变量所对应的值。每个数据文件能够蕴含多个参数，接口运行时，应用接口中援用变量的中央，就会读取文件内对应的值。b-3.关上测试数据，呈现“抉择文件”上传入口。b-4.点击“抉择文件”，抉择想要导入的txt/csv文件。b-5.能够预览所选文件b-6.查看申请中文导入后乱码的问题因为 window 零碎导出的 csv 是 GBK格局，并且旧版本的 Excel 2016 前会不保留 Bom。 Windows 能够应用记事本关上 csv 文件后另存为 utf-8 格局。 Mac 上能够应用 iconv -f GBK -t UTF-8 demo.csv > utf-8.csv。 c.执行次数指该测试流程须要执行的次数，能够自定义次数。如应用测试数据，则执行次数默认展现以后环境中测试数据的执行次数，同时反对自定义批改。 d.流程距离每次流程测试之间的间隔时间。 e.遇到谬误继续执行默认勾选遇到谬误（接口出错）继续执行，如未勾选，当测到出错接口时将会进行测试流程。 f.沙盒模式开启沙盒模式时此流程测试产生的变量和参数不影响全局的参数和变量；敞开沙盒模式则相同。 流程配置：在流程里增加接口、增加条件（条件控制器、循环控制器、期待控制器、事务控制器、全局断言、脚本）以模仿实在的业务场景，点击保留并执行，就会依照流程执行接口。 a.增加接口点击“API增加器”，右侧弹出与APIS模块同步的目录，反对点击抉择接口复制至以后流程配置中。 b.条件控制器作用：判断一个变量是否满足某个条件，由此决定该控制器下接口是否运行。 c.循环控制器作用：按指定循环办法，循环该控制器下的所有接口，可选次数循环、foreach循环、while循环三种循环形式。 d.期待控制器作用：在流程配置间插入一个期待的工夫。 e.事务控制器作用：测试该控制器下所有子步骤所破费的总工夫，即相当于用户进行一系列操作的测试，只有整个事务控制器定义的事务胜利，才算胜利。 f.全局断言作用：对整个测试计划进行断言，校验测试后果是否合乎预期。 g.脚本作用：反对自定义脚本，Apipost提供罕用的脚本。 h.导出jmx作用：反对导出至JMeter。 保留并执行在配置好测试流程后，点击“保留并执行”，则会展现该流程配置中未禁用步骤的运行过程及后果，运行过程中咱们能够看到进度条和曾经测完的接口，也能够手动进行运行。整体的执行后果会在运行完结后展现，咱们能够抉择保留该报告至“测试报告”板块中，也能够不予保留，未保留的测试后果能够在“测试记录”中查找（每个测试计划/组合测试只保留近100条记录）。反对收起后接口持续运行，即运行过程中可切换页面，并反对多个测试计划同时运行。 测试记录测试用例和组合测试都会记录以后测试计划/组合测试的近100条执行记录，咱们能够点击具体测试计划/组合测试的“查看详情”，查看该记录的测试后果。

1 定义把以人为驱动的测试行为转化为机器执行的一种过程。 简略讲：比方应用自动化测试框架、脚本、工具等主动关上测试对象（援用），主动去执行测试用例（此过程中蕴含自动化查找元素、控件等），主动输出测试数据、主动生成测试报告等一系列的自动化过程；艰深讲：用机器来模仿用户的理论行为，如键盘、鼠标等操作，来达到预期。2 做自动化的目标是什么？测试工作量比拟大，应用自动化来实现一部分工作；测试过程有大量反复的工作，应用自动化来进行晋升效率；手工测试难以笼罩的场景，须要自动化造数据等来实现；有些测试后果，可能自动化比手工更为准确。3 自动化测试的优缺点长处毛病反复执行、频繁操作不能100%代替人工测试模仿手动测试无奈笼罩的场景不能达到100%覆盖率利用闲暇工夫执行须要工夫去剖析后果开释一部分测试人员精力对软件品质依赖大（前提是软件稳固、改变小等）测试后果主观公正须要业余的工程师投入专门的工夫开发/投入老本可能会大一些4 自动化测试的前提条件（重要）即做自动化前先对软件进行剖析，是否满足或者要不要做自动化，有几个前提条件须要留神。 4.1 需要变动不频繁脚本的稳定性最直观的决定因素是需要的变动，如果需要变动大，隔三差五的进行需要更改，那脚本势必也要进行同步更新，这样投入的保护老本就很大，得失相当，还不如不做。4.2 我的项目周期比拟长自动化测试和一般的测试一样，须要后期的布局、框架设计、脚本开发、人员抉择、脚本执行、前期保护以及后果跟踪剖析等，是一个比拟全的且投入较多的一个过程，如果我的项目周期很短，就不适宜做自动化，其实也没必要；另外我的项目周期短，手动测试都无奈保障的前提下，更不必谈及做自动化了。4.3 脚本的反复使用率高咱们投入了较大的人力、物力、财力等最终实现了一套比拟完满的自动化脚本、框架或者平台，然而复用率很低，只能在单个产品独自应用，那么这样的代价就太大了。此时咱们须要评估是否必须要进行自动化测试，如果非必须，能够不做；相同的，如果自动化的一系列货色都能迁徙到其余的产品测试，那这样的投入是值得的，也是必要的。咱们也应该投入更多的精力进行测试开发。4.4 团队实力做自动化，不是轻易摘抄一些代码拿来用，他是一个专项测试，须要投入专门的人力去钻研及测试，那么咱们要想做好自动化，先要对本人的团队进行评估，团队的人员、技术能力等是否满足要求；另外，自动化须要一直的进行迭代和优化，不能拿着脚本运行看看后果，那其实很多时候，并不能给产品带来主观的价值。咱们须要进行不定期的降级保护，针对我的项目业务要进行优化，依据测试过程和后果的数据反馈要进行稳定性的降级等等。所以这也须要专门投入人力进行钻研。4.5 部门的布局和下级的反对这个是我加的，依据集体的教训的总结； 部门的布局：如果自动化是在部门布局中，以及有考核指标，那必定是要做的。如果不是布局，也没有纳入计划，那就要依据理论状况定，毕竟这不会间接影响你团队的理论考评。你的重点应该是在其余的中央，优先保障工作重点内容的实现；下级的反对：这个很重要，做自动化无非是为了晋升效率和品质，然而如果没有失去应有的成果，领导看不到问题，也无感知，那么做自动化兴许不会短暂。这个得缓缓领会了，哈哈。5 利用场合自动化测试次要利用在以下场合，具体还要依据我的项目以及自动化的理论开发状况开定： 场景阐明测试周期我的项目周期长，轮次较多的软件数据量级须要制作大量的测试数据软件稳定性应用稳固和成熟阶段的产品测试回归测试须要进行简略回归的测试冒烟测试主线性能的冒烟巡检测试线上环境的定期巡检公布验证主线性能的公布验证测试6 自动化意识误区（重点）6.1 自动化可100%笼罩概率不大，要使得自动化的测试覆盖率达到100%，须要投入专门的人力、物力、财力等，老本比拟大；某些业务的特殊性，或者场景的复杂性，用自动化是无奈进行笼罩的；我的项目的周期限度，不容许投入更多的精力去开发；6.2 自动化可代替人力领导的口头禅：你就通知我，自动化能干掉多少人力？！====每次听到这样的话，不晓得你们怎么想的，反正我是很无奈。但从领导的角度来思考，也不为错；这里存在一些误区，自动化测试是辅助功能测试的，或者说是为了解决某些人工不能笼罩的场景；另外，不存在完完全全的自动化，都是须要人工参加的；遇到相似的意识，倡议自动化测试人员须要进行解释，不能任由这个观点滋生，不然===你猜会咋办！！6.3 自动化很牛逼任何的事件，都是看谁先晓得而已，与其说牛逼的技术，不如说牛逼的人。自动化只是一门技术，咱们不能脱离业务搞自动化；很多人认为自动化很厉害，就脱离了工作的重心，天天喊着自动化、自动化，最初到头来啥也不是，啥也没失去。当然如果是业余、专门搞自动化测试开发的那就另说了。因为他们的工作就这，就是转、精。6.4 万物皆可自动化这个其实和前边的提到的统一，搞自动化，先要合乎一些前提条件以及明确他的利用场景，不是所有软件都要搞自动化。自觉的自动化，只会事与愿违。6.4 自动化很简略这是一个很简单的然而又简略的话题，对自动化的方向、工具、技能等钻研的水平不同，对他的意识就不一样；如果只是解决一些简略的问题，你把握他很简略。如果是简单的一些货色，可能须要深入研究；自动化方向也是很多，不论是性能、性能，还是面向接口、UI、GUI、协定，更或是自动化工具开发等，都须要不同的技能和常识，入门或者简略，要做的很专一，还是须要点积攒的。6.5 自动化尽早做不肯定。不同的自动化，染指工夫可能有差别，比方 UI的，倡议软件略微稳固或者需要变更不频繁的时候再去开发；接口的，能够在开发阶段同步进行；7 自动化测试工具太多了，举个例子，不代表所有的。事例而已：

1 阐明pytest中应用assert进行断言，和unittest是有区别的，后边具体列举；pytest中的assert后能够为表达式，为True示意用例通过。2 Uinttest中的断言2.1 局部断言咱们写一个class，代码中就能够看到所有的断言： 罕用断言：办法查看assertEqual(a, b)a ==bassertNotEqual(a, b)a !=bassertTrue(x)bool(x) is TrueassertFalse(x)Bool(x) is FalseassertIs(a, b)a is bassertIsNot(a, b)a is not bassertIsNone(x)x is NoneassertIsNotNone(x)x is not NoneassertIn(a, b)a in bassertNotIn(a, b)a not in bassertIsInstance(a, b)isinstance(a,b)assertNotIsInstance(a, b)not isinstance(a,b)2.2 局部举例# -*- coding:utf-8 -*-# 作者：NoamaNelson# 日期：2021/11/26 # 文件名称：test_unint.py# 作用：unittest断言# 分割：VX(NoamaNelson)# 博客：https://blog.csdn.net/NoamaNelsonimport unittestclass TestU(unittest.TestCase): def setUp(self) -> None: self.a = 3 self.b = 4 self.c = 3 self.d = 0 def tearDown(self) -> None: pass def test_o(self): self.assertTrue(self.c, msg="后果为False") def test_t(self): self.assertEqual(self.a, self.c, msg="a和c不相等")if __name__ == "__main__": unittest.main()3 Pytest断言3.1 罕用断言断言阐明assert a判断 a为真assert not a判断 a不为真assert a in b判断 b 蕴含 aassert a == b判断 a 等于 bassert a != b判断 a 不等于 b3.2 示意办法# -*- coding:utf-8 -*-# 作者：NoamaNelson# 日期：2021/11/26 # 文件名称：test_assert.py# 作用：assert断言# 分割：VX(NoamaNelson)# 博客：https://blog.csdn.net/NoamaNelsonimport pytestclass TestU(): def test_f(self): a = 3 b = 4 s = a + b return s def test_func(self): assert self.test_f() == 7, "计算结果不是7"if __name__ == "__main__": pytest.main()输入为：(venv) F:\pytest_study\test_case\test_d>pytest test_assert.py============================================ test session starts =============================================platform win32 -- Python 3.7.0, pytest-6.2.4, py-1.10.0, pluggy-0.13.1rootdir: F:\pytest_study\test_case\test_dplugins: allure-pytest-2.8.12, cov-2.8.1, forked-1.1.3, html-2.0.1, metadata-1.8.0, ordering-0.6, xdist-1.31.0collected 2 itemstest_assert.py .. [100%]============================================= 2 passed in 0.31s ==============================================3.3 异样断言能够应用 pytest.raises 作为上下文管理器，当抛出异样时能够获取到对应的异样实例；目标是断言抛出的异样是不是预期想要的；比方如下，断言1 / 0的异样是不是ZeroDivisionError，其中ZeroDivisionError是异样类型，用type从异样信息中获取；division by zero是异样的值，应用value从异样信息中获取。 def test_a(self): with pytest.raises(ZeroDivisionError) as e: 1 / 0 assert e.type == ZeroDivisionError assert "division by zero" in str(e.value)

1 需要整顿1.1 实现目标基于CS架构，模仿用户（鼠标、键盘）操作，达到疾速、反复执行测试用例；便于回归测试，疾速笼罩主线用例或性能；线上或线下巡检测试，联合继续集成，及时发现运行环境存在的问题；晋升集体自动化测试技术能力，为业务提供强有力的测试伎俩。1.2 性能需要基于Unittest，封装、调用和组织所有的测试用例，进行批量或指定用例运行；反对邮件服务，可增加任意团队成员邮箱，及时告诉团队成员自动化运行后果；反对log日志，保留运行过程所有或须要记录的数据；反对HTML测试报告，直观展现测试后果和数据；反对用例设计和测试后果拆散，便于数据管理；反对用户登录封装，后续所有的用例登录专用一个办法；反对任意批改Beautifulreport，可定制测试报告模板；反对测试报告多语言（英文和中文）；反对截图性能；反对Jenkins继续集成。1.3 其余要求实用Windows XP(SP3),Windows Vista, Windows 7, Windows 8、8.1、10自动化测试；模块化设计，我的项目框架模式组织代码；公共办法封装，对立调用；数据和后果离开，清晰明了；反对邮件自定义；代码正文清晰。1.4 实用人员有肯定测试根底的软件测试人员；有肯定的代码（Python/Java）功底；致力于学习WindowsGUI自动化测试的所有人员。1.5 学习周期两个星期到一个月，可达到独立进行WindowsGUI自动化测试；1.6 学习倡议倡议依照文章程序，一步一步进行学习和实际；文章是从根本的环境搭建到最终框架齐全搭建的一个过程，相对来说还是比拟具体的；文章偏差于我的项目实战，未有太多的实践介绍和名词解释，所以对0根底的人员来说，可能须要额定的工夫去补充一下常识。2 具体设计2.1 需要剖析对 实现需求 进行详细分析，次要有下： 性能阐明应用Unittest框架开源自动化测试框架，间接应用批量或指定用例运行Unittest框架可反对此性能log日志应用Python的logging库即可生成HTML测试报告应用BeautifulReport模块可实现此性能用例设计和后果拆散PO模式用户登录封装间接把登录性能模块化，应用Unittest框架中的setup，teardown即可定制测试报告模板应用BeautifulReport模块报告多语言应用BeautifulReport模块截图性能应用UIAutomation的CaptureToImage办法2.2 技术栈技术版本及阐明PythonV3.x（本文为3.7）===编程语言撑持UIAutomation控件的辨认、定位及操作BeautifulReport生成Html测试报告LoggingPython自带===生成log日志UnittestPython自带===自动化测试框架SmtplibPython自带===邮件服务emailPython自带===邮件服务osPython自带===零碎模块PyCharmCommunity 2020.2汉化版操作系统Windows10旗舰版64位其它后续补充3 框架设计 3.1 框架阐明 3.2 框架执行流程 4 预期后果4.1 测试过程log日志 4.2 测试报告html格局 4.3 测试报告邮件格局

1 测试需要模仿操作windows10自带的计算器，计算简略的后果数据。 2 测试步骤关上计算器；输出10*52查看计算结果，并进行判断是否计算OK；敞开计算器。3 实现脚本# -*- coding:utf-8 -*-import unittestimport timeimport uiautomationimport os# @unittest.skip("跳过")class TestFaultTree(unittest.TestCase): def setUp(self) -> None: # 初始化 os.system("calc") # 关上计算器 time.sleep(2) self.calc = uiautomation.WindowControl(Name="计算器") self.calc_list = ["一", "零", "乘以", "五", "二", "等于"] self.result = "520" def tearDown(self) -> None: time.sleep(1) self.calc.ButtonControl(Name="敞开 计算器").Click() def test_toolbar(self): time.sleep(1) for i in range(0, len(self.calc_list)): self.calc.ButtonControl(Name=self.calc_list[i]).Click() calc_result = self.calc.TextControl(foundIndex=3).Name print("计算器运行后果为：", calc_result) print("预期后果为：", self.result) self.assertIn(self.result, calc_result)if __name__ == "__main__": unittest.main()4 实现成果

1 测试需要模仿用户操作，关上记事本进行内容输出 2 测试步骤2.1 用例1关上记事本；窗口最大化；输出"人生苦短，我用Python！";敞开窗口；不保留间接退出。2.2 用例2关上记事本；窗口最大化输出： Python之禅！柔美胜于俊俏（Python 以编写柔美的代码为指标）明了胜于艰涩（柔美的代码该当是明了的，命名标准，格调类似）简洁胜于简单（柔美的代码该当是简洁的，不要有简单的外部实现）简单胜于凌乱（如果简单不可避免，那代码间也不能有难懂的关系，要放弃接口简洁）扁平胜于嵌套（柔美的代码该当是扁平的，不能有太多的嵌套）距离胜于紧凑（柔美的代码有适当的距离，不要奢望一行代码解决问题）可读性很重要（柔美的代码是可读的）即使假借特例的实用性之名，也不可违反这些规定（这些规定至高无上）不要容纳所有谬误，除非你确定须要这样做（精准地捕捉异样，不写 except:pass 格调的代码）当存在多种可能，不要尝试去猜想而是尽量找一种，最好是惟一一种显著的解决方案（如果不确定，就用穷举法）尽管这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）做兴许好过不做，但不假思索就入手还不如不做（入手之前要细思量）如果你无奈向人形容你的计划，那必定不是一个好计划；反之亦然（计划测评规范）命名空间是一种绝妙的理念，咱们该当多加利用（提倡与号召）"敞开窗口；不保留间接退出。3 实现脚本# -*- coding:utf-8 -*-import unittestimport timeimport uiautomationimport subprocessclass TestNotePad(unittest.TestCase): def setUp(self) -> None: # 初始化 subprocess.Popen("notepad.exe") # 关上记事本 time.sleep(1) self.notepad = uiautomation.WindowControl(Name="无标题 - 记事本") time.sleep(1) print("===============", self.notepad) self.notepad.ButtonControl(Name="最大化").Click() def tearDown(self) -> None: time.sleep(1) self.notepad.ButtonControl(Name="敞开").Click() time.sleep(0.5) self.notepad_1 = uiautomation.WindowControl(Name = "记事本") self.notepad_1.SetTopmost() self.notepad_1.ButtonControl(Name="不保留(N)").Click() def test_notepad(self): self.notepad.SetTopmost() time.sleep(1) text_content = "人生苦短，我用Python！" self.notepad.EditControl(Name="文本编辑器").SendKeys(text_content) def test_notepad_text(self): self.notepad.SetTopmost() time.sleep(1) text_content_1 = ' '*47 + "Python之禅！\n\ 柔美胜于俊俏（Python 以编写柔美的代码为指标）\n\ 明了胜于艰涩（柔美的代码该当是明了的，命名标准，格调类似）\n\ 简洁胜于简单（柔美的代码该当是简洁的，不要有简单的外部实现）\n\ 简单胜于凌乱（如果简单不可避免，那代码间也不能有难懂的关系，要放弃接口简洁）\n\ 扁平胜于嵌套（柔美的代码该当是扁平的，不能有太多的嵌套）\n\ 距离胜于紧凑（柔美的代码有适当的距离，不要奢望一行代码解决问题）\n\ 可读性很重要（柔美的代码是可读的）\n\ 即使假借特例的实用性之名，也不可违反这些规定（这些规定至高无上）\n\ 不要容纳所有谬误，除非你确定须要这样做（精准地捕捉异样，不写 except:pass 格调的代码）\n\ 当存在多种可能，不要尝试去猜想\n\ 而是尽量找一种，最好是惟一一种显著的解决方案（如果不确定，就用穷举法）\n\ 尽管这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）\n\ 做兴许好过不做，但不假思索就入手还不如不做（入手之前要细思量）\n\ 如果你无奈向人形容你的计划，那必定不是一个好计划；反之亦然（计划测评规范）\n\ 命名空间是一种绝妙的理念，咱们该当多加利用（提倡与号召）" self.notepad.EditControl(Name="文本编辑器").SendKeys(text_content_1)if __name__ == "__main__": unittest.main()4 实现成果 ...

2022年12月6日，龙智与软件测试自动化“领导者”SmartBear联结举办了主题为“如何通过自动化测试实现降本、增效与提质”的在线研讨会。此次研讨会中，龙智技术工程师邱洁玉现场演示了应用UI自动化测试的过程，并简要介绍了API的自动化测试。软件测试是DevSecOps中必不可少的一环，而自动化软件测试可确保每次推送代码时都实现所需的平安测试步骤，按时交付高质量代码。龙智通过与软件测试自动化测试领导者SmartBear单干，引入其主动UI测试工具TestComplete和主动API测试平台ReadyAPI，助力企业进步软件开发的测试效率与品质，帮忙中国企业落地更平安、更自动化的DevSecOps实际办法。在线研讨会“如何通过自动化测试实现降本、增效与提质”内容回顾《UI自动化测试演示及API自动化测试简介》（节选）演讲嘉宾：邱洁玉（龙智技术工程师）明天我次要给大家介绍一下UI自动化测试，以及接口自动化测试，并围绕SmartBear的UI自动化测试工具TestComplete进行演示。 咱们先看一下目前UI测试面临的一些挑战。首先是无奈在短时间内实现大量测试用例。通过自动化测试，您能够利用早晨或周末的工夫运行自动化测试脚本。第二个挑战，无奈正当利用资源。自动化测试工具能够优化资源，比方在运行测试脚本的同时，测试人员可进行其余工作（波及测试用例的工作等）。第三个挑战是重复性的测试，例如机械性的回归测试。此类测试工作量较大，减少了测试人员的累赘。第四个挑战是由人工执行的手动测试产生的问题，那就是人为的疲劳或忽略导致测试后果不牢靠，而自动化测试可防止此类问题。最初一个挑战是手工测试无奈实现的工作只能用自动化测试来实现，比方利用性能和软件速度等稳定性测试。 为什么抉择TestComplete 您须要抉择一款适合的工具帮忙克服下面提到的这些挑战——龙智为大家引进TestComplete这款UI自动化测试工具，它能够进行桌面、Web和挪动测试。 桌面测试方面，TestComplete反对.Net和WPF利用。Web测试方面，它反对React和Angular等框架，也反对跨浏览器测试、挪动测试。您也能够在物理机或虚拟机上进行iOS或安卓的利用测试。 TestComplete的另一个长处是代码和无代码测试。它反对应用7种脚本语言来编写测试代码，也反对关键词测试等无代码测试，对于没有代码编程教训的测试用户来说非常敌对。 此外，TestComplete弱小的GUI对象辨认性能能够辨认比较复杂的空间（包含图片、PDF等）、更改的测试元素，无效升高测试保护老本，并无缝集成CI/CD、版本治理等工具，进步测试效率。 SmartBear还提供收费的培训视频、社区资源，让您可能轻松、疾速地上手。 ReadyAPI接口测试 ReadyAPI是一款接口自动化测试工具，它将功能测试、平安测试、性能测试和API虚拟化等性能集成在同一平台，防止了不同工具之间的来回切换，不同的测试之间能够共享测试用例、测试数据，进步了测试效率。并且，ReadyAPI反对大多数支流的API协定和范式，如Open API/Swagger和AsyncAPI等。 ReadyAPI可通过导入API协定、录制的形式来创立测试项目，也能够通过图形界面来批量创立断言。通过拖拽内置组件的形式来轻松构建简单的测试步骤，升高了测试人员的应用门槛。它还能够和Git等CI/CD工具集成，融入现有的流水线中，实现可继续化的测试。 另外，ReadyAPI能够从Excel、CVS数据库里导入测试数据。它内置了较为实在的测试数据，比方电话号码、不同国家的电报号码，测试人员无需依据不同的格局来本人创立模仿数据，节俭了输出数据的工夫。 ReadyAPI提供了详尽的剖析报告，报告可能以HTML和CVS格局导出。 接下来，我为大家演示如何应用TestComplete进行自动化测试。 △回顾视频：龙智专家邱洁玉现场演示应用TestComplete进行自动化测试 除了龙智技术工程师邱洁玉，还有SmartBear亚太渠道经理何平康、龙智总经理杨林晶与龙智技术总监李毅作为演讲嘉宾参加了此次研讨会，就以下主题进行了分享： SmartBear及其软件品质与测试现状调研龙智与SmartBear策略单干扩大DevSecOps解决方案中国企业在品质和测试中面临的挑战以及自动化测试实际现状与瞻望 咱们将会议进行了全程录制，立刻点击下方按钮获取完整版回顾视频。 点击此处，观看研讨会视频回顾

1 总体需要1.1 实现目标基于BS架构，模仿用户（鼠标、键盘）操作，达到疾速、反复执行测试用例；便于回归测试，疾速笼罩主线用例或性能；线上或线下巡检测试，联合继续集成，及时发现运行环境存在的问题；晋升集体自动化测试技术能力，为业务提供强有力的测试伎俩。1.2 性能需要基于Unittest，封装、调用和组织所有的测试用例，进行批量或指定用例运行；反对邮件服务，可增加任意团队成员邮箱，及时告诉团队成员自动化运行后果；反对log日志，保留运行过程所有或须要记录的数据；反对HTML测试报告，直观展现测试后果和数据；反对用例设计和测试后果拆散，便于数据管理；反对Json、conf、excel等配置文件读取，提供灵便的配置文件操作方法；反对用户登录封装，后续所有的用例登录专用一个办法；反对任意批改HTMLTestRuner，可定制测试报告模板；反对测试报告多语言（英文和中文）；反对截图性能；反对Jenkins继续集成。1.3 其余要求实用所有bs架构自动化测试；模块化设计，我的项目框架模式组织代码；公共办法封装，对立调用；数据和后果离开，清晰明了；反对邮件自定义；代码正文清晰。1.4 实用人员有肯定测试根底的软件测试人员；有肯定的代码（Python/Java）功底；致力于学习web UI自动化测试的所有人员。1.5 学习周期两个星期到一个月，可达到独立进行web UI自动化测试；1.6 学习倡议倡议依照文章程序，一步一步进行学习和实际；文章是从根本的环境搭建到最终框架齐全搭建的一个过程，相对来说还是比拟具体的；文章偏差于我的项目实战，未有太多的实践介绍和名词解释，所以对0根底的人员来说，可能须要额定的工夫去补充一下常识。2 具体设计2.1 需要剖析对 实现需求 进行详细分析，次要有下： 性能阐明应用Unittest框架开源自动化测试框架，间接应用批量或指定用例运行Unittest框架可反对此性能log日志应用Python的logging库即可生成HTML测试报告应用HtmlTestRunner.py模块可实现此性能用例设计和后果拆散应用配置文件如excel、json等组织用例数据反对Json、conf、excel等配置文件读取这里先应用excel进行页面元素的驱动用户登录封装间接把登录性能模块化，应用Unittest框架中的setup，teardown即可定制测试报告模板应用HTMLTestRuner.py模块报告多语言应用HTMLTestRuner.py模块截图性能应用Selenium的save_screenshot办法2.2 技术栈技术版本及阐明PythonV3.x（本文为3.7）===编程语言撑持SeleniumV3.141.0 ===UI元素、控件的辨认、定位，以及浏览器管制等HtmlTestRunnerPython3版本===生成Html测试报告LoggingPython自带===生成log日志XlrdV1.2.0===excel读取办法UnittestPython自带===自动化测试框架SmtplibPython自带===邮件服务emailPython自带===邮件服务osPython自带===零碎模块PyCharmCommunity 2020.2汉化版操作系统Windows10旗舰版64位其它后续补充3 框架设计 3.1 框架阐明 3.2 框架执行流程 4 预期后果4.1 测试过程log日志 4.2 测试报告html格局 4.3 测试报告邮件格局 5 特地阐明代码根本实现，如果有好的倡议，可交换学习心得。 6 第一个WebUI自动化测试程序在开始自动化框架搭建之前，咱们先写一个简略的自动化测试脚本，来领会一下什么是web UI自动化测试，以及元素的基本操作，为后续的框架搭建鉴定根底。 6.1 Selenium根本实践6.1.1 Selenium装置间接关上cmd窗口，输出以下命令在线装置：pip3 install selenium 装置完后，在cmd窗口中输出以下命令，能够看到selenium曾经装置了pip list 6.1.2 WebDriverAPIselenium提供了很多的WebDriverAPI，能够来进行： 元素的辨认、定位元素的单击、双击滚动条的拖动浏览器管制如窗口大小、后退后退、刷新、表单切换、多窗口切换、文件双传下载、cookie操作、验证码等等详情请参考以下： Selenium WebDriver API 学习笔记（一）：元素定位 Selenium WebDriver API 学习笔记（二）：浏览器管制 Selenium WebDriver API 学习笔记（三）：浏览器管制6.2 浏览器驱动装置要想应用selenium来操作浏览器上的元素，必须装置浏览器驱动；这个要依据具体的浏览器版本来定义；本文应用的是Chrome浏览器，版本为88.0.4324.182（正式版本） （32 位）；6.2.1 Chromedriver下载下载地址：Chrome浏览器各版本对应的驱动 6.2.2 Chromedriver装置下载下来后是一个chromedriver.exe，如果是w7零碎须要把chromedriver.exe放在chrome浏览器的装置目录，而后在零碎环境变量中退出chrome浏览器的装置目录即可；如果是w10零碎，须要chromedriver.exe放在Python的装置目录即可，如本文是： 6.3 代码设计思路6.3.1 pycharm新建脚本关上之前创立的我的项目【Automated-UITest-demo】，在我的项目上右键，新建python文件即可，这里新建一个名为test_baidu的python文件 创立完后，如下多了一个test_baidu的py文件 6.3.2 自动化需要这里咱们做以下UI自动化测试：1、主动关上chrome浏览器2、输出百度网址3、关上百度首页，输出helloworld4、最大化浏览器窗口5、搜寻helloworld.并回车6、浏览器窗口大小放大为640*4807、先进行浏览器后退，再次输出csdn进行搜寻8、清空输出的内容9、判断是否进入csdn官网6.3.3 需要剖析需要剖析主动关上chrome浏览器须要用到webdriver.Chrome()输出百度网址用到driver.get()办法关上百度首页，输出helloworld用到send_keys()办法最大化浏览器窗口应用maximize_window()办法搜寻helloworld.并回车用到send_keys()办法浏览器窗口大小放大为640*480用到 set_window_size()办法浏览器后退back()办法清空输出的内容clear()办法判断driver.current_url办法来判断以后的网址以上办法具体应用，参考【1.2 WebDriverAPI】6.3.4 元素定位以上需要曾经搞清楚了，那么接下来要进行元素定位，这里大略能够对需要再拆解下，须要哪些元素？元素阐明定位形式百度输入框用来输出helooworldfind_element_by_id搜寻csdn后点击csdn官网用来模仿点击进入到csdn官网find_element_by_xpath那如何定位元素，晓得应用哪种定位形式？A、咱们关上百度首页，而后按【F12】关上浏览器的调试模式 B、点击调试模式窗口左上角的小三角 C、鼠标挪动到百度搜寻输入框 D、点击一下即可，而后看到搜寻输入框的元素属性，即要应用的元素定位办法 ...

@TOC 1 需要起源获取网页指定区域数据，并进行保留；简略说就是pa chong的需要了。2 需要细节留神：请文化上网，本文仅作为学习用。讲述的是思路和办法，所以对被测试网站要害数据进行暗藏。如有须要，可学习思路后自行找测试对象进行学习。 某网站，进入后如下，有很多数据分类： 进入某个分类后有很多小分类，如电阻器中的页面： 而每个小类又有很多数据，那咱们就是要把这些数据下载下来进行保留： 3 设计剖析依据以上【需要细节】，咱们曾经大略明确须要做啥，就是要下载一个大的分类下的小类中的内容： 要申请对应页面数据，那咱们须要用到的requests.get办法；申请完数据后，要获取对应元素的html，要用到etree.HTML和tree.xpath办法；因为这些大类或小类，其实实质上都是不同的链接，从页面看咱们可能须要获取a标签，那么须要应用BeautifulSoup进行页面解析；下载下来的数据，咱们要进行保留到html格局的文件中，那咱们要用到根本的数据写入，比方open和write办法；想把下载下来的html原格局保留到excel中，那须要对html和excel格局进行解析，须要应用pandas进行解决；这个两头过程中，须要对文件和门路进行解决，所以还须要用到Path办法；最初咱们把脚本打包成exe不便运行和应用，那须要用到打包工具Pyinstaller解决。4 技术栈从【3 设计剖析】来看，咱们须要用到以下工具环境。工具版本用处PythonV3.7.0脚本设计beautifulsoup4V4.11.1html页面数据解析lxmlV4.6.3etree.HTML、tree.xpath获取对应元素的htmlpandasV1.1.5excel数据处理requestsV2.24.0页面数据申请复制以下内容命名为 requirements.txt，间接应用pip install -r requirements.txt 即可装置须要的包；beautifulsoup4==4.11.1lxml==4.6.3pandas==1.1.5requests==2.24.05 设计实现先引入所有须要的包：import requestsfrom lxml import etreefrom bs4 import BeautifulSoupimport pandasimport osimport timefrom pathlib import Path创立基类Tools：class Tools(object): """公共办法（工具）作为基类被后续调用"""5.1 封装公共办法类Tools5.1.1 封装数据申请办法get_category创立办法get_category，传入四个参数： def get_category(self, curt_url, curt_xpath, curt_list, curt_headers): """ 申请办法封装 :param curt_url: 申请地址 :param curt_xpath: 对应table xpath :param curt_list: 寄存列表 :param curt_headers: 申请头 :return: 无返回 """为什么要这么做？为了防止代码冗余，后续有很多中央用到数据申请和获取，所以进行了封装。而传入的四个参数，根本是变动的，所以用到时候，传入须要的参数即可；在每次申请前加个提早：time.sleep(1)，防止申请太过频繁；应用requests.get办法，获取指标地址数据，其中要退出两个参数，次要防止申请报SSl谬误：res = requests.get(curt_url, verify=False, headers=curt_headers) 应用etree.HTML办法返回的数据进行html转换：tree = etree.HTML(res.content) 应用tree.xpath办法获取该页面中指定元素的内容：div = tree.xpath(curt_xpath) 应用以下办法进行格局转换，获取的数据是byte字节，转换成str类型；div_str = etree.tostring(div[0]) div_str1 = str(div_str, "UTF-8") 应用BeautifulSoup办法解析页面html，获取a标签的所有链接内容，就是大类或小类的名字对应的链接了；soup = BeautifulSoup(div_str1) for k in soup.find_all('a'): curt_list.append(k['href']) get_category办法源码： def get_category(self, curt_url, curt_xpath, curt_list, curt_headers): """ 申请办法封装 :param curt_url: 申请地址 :param curt_xpath: 对应table xpath :param curt_list: 寄存列表 :param curt_headers: 申请头 :return: 无返回 """ time.sleep(1) res = requests.get(curt_url, verify=False, headers=curt_headers) # 接口数据申请办法 tree = etree.HTML(res.content) # 获取返回数据的内容 div = tree.xpath(curt_xpath) # 获取以后页面须要的table xpath对应的内容 div_str = etree.tostring(div[0]) # 格局转换 div_str1 = str(div_str, "UTF-8") # byte转为str # print(div_str1) soup = BeautifulSoup(div_str1) # BeautifulSoup解析页面html for k in soup.find_all('a'): # 获取a标签 curt_list.append(k['href'])5.1.2 封装html数据写入办法write_html就是把以上获取的内容存入html格局的文件中；这个简略，间接上代码： def write_html(self, file, txt): """ 公共办法：把获取的数据写入文本内容到文件【html格局】 :param file: 文件名 :param txt: 文本内容 :return: 返回胜利或失败 """ try: with open(file, 'w', encoding='utf-8') as f: f.write(txt) time.sleep(3) f.close() return f"{file}写入: 胜利" except: return f"{file}写入: 失败"5.1.3 封装html转excel办法html_to_excel简略说，就是把html文件转换成excel格局；传入五个参数： def html_to_excel(self, base_dir, big_dir, small_dir, full_path, new_file_path): """ 将html文件转换成excel格局的文件 :param base_dir: 文件寄存基地址，默认脚本的上一层目录 :param big_dir: 大类目录 :param small_dir: 小类目录 :param excel_dir: 寄存excel目录 :param sheet_n: 寄存sheet的名称=小类 :param full_path: 所有sheet合并目录 :param new_file_path: 最终合并的某个小类的excel :return:无返回 """大略思路是：①关上指定目录下的html格式文件；②循环遍历所有的html格式文件，应用pandas.read_html进行数据读取；③应用pandas.ExcelWriter办法写入excel；④写入excel后是每个html寄存在每个sheet中；⑤合并所有的sheet为一个excel。间接上代码： def html_to_excel(self, base_dir, big_dir, small_dir, full_path, new_file_path): """ 将html文件转换成excel格局的文件 :param base_dir: 文件寄存基地址，默认脚本的上一层目录 :param big_dir: 大类目录 :param small_dir: 小类目录 :param excel_dir: 寄存excel目录 :param sheet_n: 寄存sheet的名称=小类 :param full_path: 所有sheet合并目录 :param new_file_path: 最终合并的某个小类的excel :return:无返回 """ excel_dir = base_dir + "\\" + big_dir + "\\" + small_dir + "\\" sheet_n = small_dir # sheet_n = "1-陶瓷电容器" os.chdir(excel_dir) for filename in os.listdir(excel_dir): print(filename) try: with open(excel_dir + filename, 'rb') as f: df = pandas.read_html(f.read(), header=1, encoding='utf-8') bb = pandas.ExcelWriter(excel_dir + filename + ".xlsx") df[0].to_excel(bb, index=False) bb.close() except Exception as e: print("异样：" + e) time.sleep(3) workbook = pandas.ExcelWriter(full_path) folder_path = Path(excel_dir) file_list = folder_path.glob('*.xlsx*') for i in file_list: stem_name = i.stem data = pandas.read_excel(i, sheet_name=0) data.to_excel(workbook, sheet_name=stem_name, index=False) time.sleep(2) workbook.save() workbook.close() time.sleep(2) data2 = pandas.read_excel(full_path, sheet_name=None) data3 = pandas.concat(data2, ignore_index=True) # new_file_path = "合并.xlsx" data3.to_excel(new_file_path, sheet_name=sheet_n, index=False)5.2 两个全局变量寄存获取的数据名称category_list = [] # 寄存所有大类category_list_small = [] # 寄存所有小类5.3 创立数据处理和获取类DataBase5.3.1 初始化类 def __init__(self): # self.tools = Tools() self.url = 'xxxx' # 指标网站 self.headers = {'Connection': 'close'} # 申请头，防止ssl报错 # self.big_num = 3 # 第几个大类，从0开始 # self.small_num = 0 # 第几个小类，从0开始 self.net_xpath = '/html/body/div[5]/div/div[2]' # 网站所有大类的table xpath self.xpath_big = ['/html/body/div[3]/div[2]'] # 对应大类中的小类的table xpath self.xpath_small = ['/html/body/div[4]/div'] # 对应小类的内容table xpath5.3.2 获取所有大类名称存入列表 def get_big_category(self): """获取网站中所有的类别，寄存列表中""" self.get_category(self.url, self.net_xpath, category_list, self.headers) print(f"1========={category_list}")5.3.3 获取所有大类中小类的名称存入列表 def get_small_category(self, big_num): """获取某个大类中小类所有的类别，寄存列表中""" self.get_category(f'{self.url}{category_list[big_num]}', self.xpath_big[0], category_list_small, self.headers) print(f"获取的大类是： {category_list[big_num]} ，如下：")5.3.4 获取小类中页面的内容 def get_small_content(self, i, small_num): """获取小类中所有内容""" print(f"获取的大类对应的小类是：{category_list_small[small_num]}") time.sleep(1) url_1 = f'{self.url}{category_list_small[small_num]}?page={i}' print(f"申请的小类的域名为：{url_1}") res = requests.get(url_1, verify=False, headers=self.headers) tree = etree.HTML(res.content) div = tree.xpath(self.xpath_small[0]) div_str = etree.tostring(div[0]) div_str1 = str(div_str, "UTF-8") time.sleep(2) return div_str15.4 办法调用main设计5.4.1 输入输出规定def main(): print("*" * 20) print("在运行前请所相熟下规定：\n" "1、依照网页显示，大类名称输出 数字-大类名称，如1-电阻器\n" "2、小类名称输出 数字-小类名称，如1-固定电阻器\n" "3、大小类前边的数字示意第几个\n" "4、如果输错不做判断，只是寄存的门路须要本人查找，倡议一次性输出正确\n" "5、！！！！！程序执行过程请勿敞开任何窗口！！！！！") print("*" * 20)5.4.2 对以后脚本门路进行解决 base_file = os.path.dirname(os.path.abspath("test_database_final.py")) print("#" * 20) print("程序将开始执行，请稍后......\n" "程序曾经启动~\n" f"程序启动目录为：{base_file}\n" "初始化数据......") print("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&\n" "1-电阻器 2-连接器 3-连接器支架 4-电容器 5-振荡器 \n" "6-晶体/谐振器 7-电源电路 8-开关 9-传感器/温度传感器 10-光电 \n" "11-光纤 12-二极管 13-电路爱护 14-存储 15-信号电路 \n" "16-电感器 17-端子 18-插座 19-微控制器和处理器 20-射频和微波 \n" "21-逻辑 22-晶体管 23-继电器 24-转换器 25-过滤器 \n" "26-触发安装 27-RC网络 28-可编程逻辑 29-电信电路 30-驱动程序和接口 \n" "31-放大器电路 32-耐热撑持安装 33-变压器 34-生产电路 35-电池 \n" "&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&")5.4.3 从键盘输入要获取的数据信息 big = input("请输出大类的名称(如1-电阻器): ") small = input("请输出小类的名称(如1-固定电阻器): ") num = int(input("请输出小类的页数(如50,须要从网站查看): ")) b_n = int(input("请输出该大类对应的序号，共35个大类，从左到右数从0开始，比方0： ")) m_n = int(input("请输出该小类对应的序号，从0开始，比方0: ")) print(f"通过输出，咱们要获取的数据为:第{b_n + 1}个大类中的第{m_n + 1}个小类\n" f"即：{big}中的{small}")5.4.4 数据调用 data_base = DataBase() data_base.get_big_category() data_base.get_small_category(b_n)5.4.5 循环换入每页中的数据 for i in range(1, num+1): get_content = data_base.get_small_content(i, m_n) print(f"第{i}次获取：获取的数据开始写入文件，文件名为：第{i}页.html") file = f"{base_file}\\{big}\\{small}" if os.path.exists(file) is False: os.makedirs(file) data_base.write_html(file=f"{file}\\第{i}页.html", txt=get_content) time.sleep(1)5.4.6 获取的数据合并存入最终的excel data_base.html_to_excel(base_file, big, small, f"{small}sheet.xlsx", f"{small}.xlsx")5.4.7 main办法源码def main(): print("*" * 20) print("在运行前请所相熟下规定：\n" "1、依照网页显示，大类名称输出 数字-大类名称，如1-电阻器\n" "2、小类名称输出 数字-小类名称，如1-固定电阻器\n" "3、大小类前边的数字示意第几个\n" "4、如果输错不做判断，只是寄存的门路须要本人查找，倡议一次性输出正确\n" "5、！！！！！程序执行过程请勿敞开任何窗口！！！！！") print("*" * 20) base_file = os.path.dirname(os.path.abspath("test_database_final.py")) print("#" * 20) print("程序将开始执行，请稍后......\n" "程序曾经启动~\n" f"程序启动目录为：{base_file}\n" "初始化数据......") print("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&\n" "1-电阻器 2-连接器 3-连接器支架 4-电容器 5-振荡器 \n" "6-晶体/谐振器 7-电源电路 8-开关 9-传感器/温度传感器 10-光电 \n" "11-光纤 12-二极管 13-电路爱护 14-存储 15-信号电路 \n" "16-电感器 17-端子 18-插座 19-微控制器和处理器 20-射频和微波 \n" "21-逻辑 22-晶体管 23-继电器 24-转换器 25-过滤器 \n" "26-触发安装 27-RC网络 28-可编程逻辑 29-电信电路 30-驱动程序和接口 \n" "31-放大器电路 32-耐热撑持安装 33-变压器 34-生产电路 35-电池 \n" "&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&") big = input("请输出大类的名称(如1-电阻器): ") small = input("请输出小类的名称(如1-固定电阻器): ") num = int(input("请输出小类的页数(如50,须要从网站查看): ")) b_n = int(input("请输出该大类对应的序号，共35个大类，从左到右数从0开始，比方0： ")) m_n = int(input("请输出该小类对应的序号，从0开始，比方0: ")) print(f"通过输出，咱们要获取的数据为:第{b_n + 1}个大类中的第{m_n + 1}个小类\n" f"即：{big}中的{small}") data_base = DataBase() data_base.get_big_category() data_base.get_small_category(b_n) for i in range(1, num+1): get_content = data_base.get_small_content(i, m_n) print(f"第{i}次获取：获取的数据开始写入文件，文件名为：第{i}页.html") file = f"{base_file}\\{big}\\{small}" if os.path.exists(file) is False: os.makedirs(file) data_base.write_html(file=f"{file}\\第{i}页.html", txt=get_content) time.sleep(1) data_base.html_to_excel(base_file, big, small, f"{small}sheet.xlsx", f"{small}.xlsx")5.5 主程序调用if __name__ == "__main__": main() input('Press Enter to exit…')6 残缺源码# -*- coding:utf-8 -*-# 作者：NoamaNelson# 日期：2022/10/11# 文件名称：test_database_final.py# 作用：xxx# 博客：https://blog.csdn.net/NoamaNelsonimport requestsfrom lxml import etreefrom bs4 import BeautifulSoupimport pandasimport osimport timefrom pathlib import Pathclass Tools(object): """公共办法（工具）作为基类被后续调用""" def get_category(self, curt_url, curt_xpath, curt_list, curt_headers): """ 申请办法封装 :param curt_url: 申请地址 :param curt_xpath: 对应table xpath :param curt_list: 寄存列表 :param curt_headers: 申请头 :return: 无返回 """ time.sleep(1) res = requests.get(curt_url, verify=False, headers=curt_headers) # 接口数据申请办法 tree = etree.HTML(res.content) # 获取返回数据的内容 div = tree.xpath(curt_xpath) # 获取以后页面须要的table xpath对应的内容 div_str = etree.tostring(div[0]) # 格局转换 div_str1 = str(div_str, "UTF-8") # byte转为str # print(div_str1) soup = BeautifulSoup(div_str1) # BeautifulSoup解析页面html for k in soup.find_all('a'): # 获取a标签 curt_list.append(k['href']) # 循环获取href链接 def write_html(self, file, txt): """ 公共办法：把获取的数据写入文本内容到文件【html格局】 :param file: 文件名 :param txt: 文本内容 :return: 返回胜利或失败 """ try: with open(file, 'w', encoding='utf-8') as f: f.write(txt) time.sleep(3) f.close() return f"{file}写入: 胜利" except: return f"{file}写入: 失败" def html_to_excel(self, base_dir, big_dir, small_dir, full_path, new_file_path): """ 将html文件转换成excel格局的文件 :param base_dir: 文件寄存基地址，默认脚本的上一层目录 :param big_dir: 大类目录 :param small_dir: 小类目录 :param excel_dir: 寄存excel目录 :param sheet_n: 寄存sheet的名称=小类 :param full_path: 所有sheet合并目录 :param new_file_path: 最终合并的某个小类的excel :return:无返回 """ excel_dir = base_dir + "\\" + big_dir + "\\" + small_dir + "\\" sheet_n = small_dir # sheet_n = "1-陶瓷电容器" os.chdir(excel_dir) for filename in os.listdir(excel_dir): print(filename) try: with open(excel_dir + filename, 'rb') as f: df = pandas.read_html(f.read(), header=1, encoding='utf-8') bb = pandas.ExcelWriter(excel_dir + filename + ".xlsx") df[0].to_excel(bb, index=False) bb.close() except Exception as e: print("异样：" + e) time.sleep(3) workbook = pandas.ExcelWriter(full_path) folder_path = Path(excel_dir) file_list = folder_path.glob('*.xlsx*') for i in file_list: stem_name = i.stem data = pandas.read_excel(i, sheet_name=0) data.to_excel(workbook, sheet_name=stem_name, index=False) time.sleep(2) workbook.save() workbook.close() time.sleep(2) data2 = pandas.read_excel(full_path, sheet_name=None) data3 = pandas.concat(data2, ignore_index=True) # new_file_path = "合并.xlsx" data3.to_excel(new_file_path, sheet_name=sheet_n, index=False)category_list = [] # 寄存所有大类category_list_small = [] # 寄存所有小类class DataBase(Tools): def __init__(self): # self.tools = Tools() self.url = 'xxxxx' # 指标网站 self.headers = {'Connection': 'close'} # 申请头，防止ssl报错 # self.big_num = 3 # 第几个大类，从0开始 # self.small_num = 0 # 第几个小类，从0开始 self.net_xpath = '/html/body/div[5]/div/div[2]' # 网站所有大类的table xpath self.xpath_big = ['/html/body/div[3]/div[2]'] # 对应大类中的小类的table xpath self.xpath_small = ['/html/body/div[4]/div'] # 对应小类的内容table xpath def get_big_category(self): """获取网站中所有的类别，寄存列表中""" self.get_category(self.url, self.net_xpath, category_list, self.headers) print(f"1========={category_list}") def get_small_category(self, big_num): """获取某个大类中小类所有的类别，寄存列表中""" self.get_category(f'{self.url}{category_list[big_num]}', self.xpath_big[0], category_list_small, self.headers) print(f"获取的大类是： {category_list[big_num]} ，如下：") def get_small_content(self, i, small_num): """获取小类中所有内容""" print(f"获取的大类对应的小类是：{category_list_small[small_num]}") time.sleep(1) url_1 = f'{self.url}{category_list_small[small_num]}?page={i}' print(f"申请的小类的域名为：{url_1}") res = requests.get(url_1, verify=False, headers=self.headers) tree = etree.HTML(res.content) div = tree.xpath(self.xpath_small[0]) div_str = etree.tostring(div[0]) div_str1 = str(div_str, "UTF-8") time.sleep(2) return div_str1def main(): print("*" * 20) print("在运行前请所相熟下规定：\n" "1、依照网页显示，大类名称输出 数字-大类名称，如1-电阻器\n" "2、小类名称输出 数字-小类名称，如1-固定电阻器\n" "3、大小类前边的数字示意第几个\n" "4、如果输错不做判断，只是寄存的门路须要本人查找，倡议一次性输出正确\n" "5、！！！！！程序执行过程请勿敞开任何窗口！！！！！") print("*" * 20) base_file = os.path.dirname(os.path.abspath("test_database_final.py")) print("#" * 20) print("程序将开始执行，请稍后......\n" "程序曾经启动~\n" f"程序启动目录为：{base_file}\n" "初始化数据......") print("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&\n" "1-电阻器 2-连接器 3-连接器支架 4-电容器 5-振荡器 \n" "6-晶体/谐振器 7-电源电路 8-开关 9-传感器/温度传感器 10-光电 \n" "11-光纤 12-二极管 13-电路爱护 14-存储 15-信号电路 \n" "16-电感器 17-端子 18-插座 19-微控制器和处理器 20-射频和微波 \n" "21-逻辑 22-晶体管 23-继电器 24-转换器 25-过滤器 \n" "26-触发安装 27-RC网络 28-可编程逻辑 29-电信电路 30-驱动程序和接口 \n" "31-放大器电路 32-耐热撑持安装 33-变压器 34-生产电路 35-电池 \n" "&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&") big = input("请输出大类的名称(如1-电阻器): ") small = input("请输出小类的名称(如1-固定电阻器): ") num = int(input("请输出小类的页数(如50,须要从网站查看): ")) b_n = int(input("请输出该大类对应的序号，共35个大类，从左到右数从0开始，比方0： ")) m_n = int(input("请输出该小类对应的序号，从0开始，比方0: ")) print(f"通过输出，咱们要获取的数据为:第{b_n + 1}个大类中的第{m_n + 1}个小类\n" f"即：{big}中的{small}") data_base = DataBase() data_base.get_big_category() data_base.get_small_category(b_n) for i in range(1, num+1): get_content = data_base.get_small_content(i, m_n) print(f"第{i}次获取：获取的数据开始写入文件，文件名为：第{i}页.html") file = f"{base_file}\\{big}\\{small}" if os.path.exists(file) is False: os.makedirs(file) data_base.write_html(file=f"{file}\\第{i}页.html", txt=get_content) time.sleep(1) data_base.html_to_excel(base_file, big, small, f"{small}sheet.xlsx", f"{small}.xlsx")if __name__ == "__main__": main() input('Press Enter to exit…')7 Pyinstaller打包间接应用以下命令打包：pyinstaller -F test_database_final.py打包后生成两个文件夹： ...

环境根本介绍环境阐明应用Python+Selenium+Webdriver集成开发软件列表1、Python（脚本语言）2、SetupTools、Pip工具（安装包管理工具）3、Selenium包（网页自动化测试）4、浏览器（IE、Chrome、Firefox）5、浏览器驱动（IEDriver、ChromeDriver等）6、Selenium IDE插件7、Firebug插件（获取元素属性，如id、name、xpath等）8、HTMLTestRunner.py（生成测试报告）9、xlrd、xlwt（对配置文件execl表格进行操作）非凡阐明本文应用的软件状况如下： Python（2.7.12/10版本）浏览器（Chrome）浏览器驱动（ChromeDriver）环境搭建装置Python（举荐应用2.7.x版本）exe文件运行装置即可，装置后环境变量中增加 python的装置目录。1、Python下载https://pan.baidu.com/s/1boIfCPD 明码：xlhg2、Python环境变量设置以下以我的Python装置目录为例：①顺次点击：计算机--邮件--属性，关上如下界面：②点击“高级零碎设置”，再点击“环境变量”，如下： ③在零碎变量中找到path，双击关上path，而后再门路的最开端退出：Python的门路，要以“;”隔开，即可：D:\Python27; D:\Python27\Lib; D:\Python27\Scripts;④验证Python是否装置胜利，开始---输出“cmd”，回车关上命令行，输出：Python，看到如下界面就示意Python装置胜利。 装置Python的SetupTools 1、SetupTools下载 https://pan.baidu.com/s/1skPKBq1 明码：5m97 2、SetupTools装置 下载 安装包，解压后在windows命令行中进入其所在目录下，应用：python setup.py install来实现工具装置。具体如下：找到解压后的文件，在空白处，按住“shift”并鼠标右键，如下图，点击“在此处关上命令窗口”，输出：python setup.py install回车装置即可 3、验证是否装置胜利 关上命令行，输出easy_install，如果看到上面的提醒，阐明你装置胜利 装置 pip 1、办法一 在装置setuptools后咱们能够通过上面的一个命令来装置pip：easy_install pip 2、办法二 下载文件后，pip-x.x.tar.gz文件进行解压，进入windows命令提醒下执行setup.py，如:X:\pip x.x > python setup.py install 没有报错示意装置胜利。切换到X :\Python27\Script，目录下输出: X:\Python27\Scripts > easy_install pip 没有报错示意装置胜利。 下载门路： https://pan.baidu.com/s/1dEWUEul 明码：dihq 装置 Selenium1、办法一下载selenium x.xx.x ,并解压把整个目录放到X:\Python27\Lib\site-packages目录下，进入 windows命令提醒下执行setup.py，如: X:\Python27\Lib\site-packages\selenium-x.xx.x >python setup.py install 没有报错示意装置胜利。2、办法二间接应用 pip install selenium命令来装置 装置Chrome浏览器驱动 1、下载 https://pan.baidu.com/s/1slJVq8H 明码：mjad2、设置浏览器驱动调用把下载的浏览器驱动放在退出谷歌浏览器的装置目录下，而后进行调用即可，如下： ①复制下载的chromedriver.exe，放在谷歌浏览器装置目录下（在谷歌浏览器快捷菜单上右键，点击属性，就能够关上浏览器的装置目录），如下： ②设置以上目录在环境变量中，在path的最初退出以上门路 验证Selenium是否装置胜利"""Author:NoamaNelsonDate:2019-11-08Purpose:验证Selenium是否装置胜利Function：关上百度网主页，在搜寻栏输出“1234567”"""from selenium import webdriverfrom selenium.webdriver.common.keys import Keysimport timedriver = webdriver.Chrome() # 关上Chrome浏览器driver.get("http://www.baidu.com") # 输出百度网址time.sleep(1)driver.find_element_by_id("kw").send_keys("1234567") # 输出“1234567”driver.find_element_by_id("kw").send_keys(Keys.ENTER) # 回车进行搜寻time.sleep(2) driver.maximize_window() # 最大化以后窗口time.sleep(2) driver.set_window_size(640, 480) # 管制浏览器显示尺寸为640*480 time.sleep(2) driver.quit() # 敞开浏览器selenium-ide脚本的录制和脚本写作1、脚本录制步骤①关上火狐浏览器，在地址栏上输出被测网页的URL. ②菜单栏：工具-selenium-ide 关上后，在的selenium-ide地址栏输出雷同的URL. ③点击开始录制④在浏览器中进行相应的操作⑤点击完结录制，查看并回放Selenium IDE 录制的后果⑥脚本导出（抉择导出须要的语言脚本：Python2 /Unittest/webdiver ）2、IDE录制脚本存在局限和问题①脚本不稳固，回放常常出错（局部操作捕捉不到）②浏览性差，不晓得自动化测试执行了具体哪些操作和实现什么性能。（正文）③如果web页面中的个别元素产生了变动，所有波及该元素的脚本须要批改。④元素的id或局部文字是动静的，即每次执行的脚本都是不同的。（参数化）⑤短少对理论后果进行判断的语句。（断言） ...

目前自动化测试堪称是人人在提，而且自动化工具和一些开源框架也是层出不穷。截止当初，我也接触了一些自动化的常识，分享下。 一、WebUI自动化1. 工具或框架 Unittest框架，Selenium+Webdriver+Python集成开发劣势： ①应用脚本间接来写，能够锤炼测试的代码能力 ②对于一个团队中人才的吸引也是有很大帮忙的 ③能够更不便的退出一些断言或者错误处理 ③对于一些数据处理可能更灵便些劣势： ①对测试人员的代码功底可能要求略微高一点 ②对脚本的健壮性要求比拟高2. 框架阐明 【对应的截图见步骤3-框架截图】 ①：截图性能。保留所有截图的图片，次要是用于简单的页面，开发成本大的时候，能够把运行过程中的某些页面截图，保留现场，不便问题查找；②：报告日志。把运行的过程和后果数据，全副保存起来，并且以Html的格局显示，比拟直观，利于问题剖析；③：测试用例集。次要是所有的测试用例的集中管理，测试用例名称必须以test结尾，这样unitetest能力辨认到用例；④：工具集。次要蕴含配置文件的调用、工程初始化、配置文件读取、邮件发送（设置对应的收发邮件人，能够把测试报告以邮件附件的形式发给我的项目组成员，不便大家查阅）⑤：业务单元模块。次要是要实现的业务单元功能模块，蕴含具体的业务性能和操作；⑥：框架入口。就是运行整个框架或者脚本的入口，此入口可实现一键操作就能够运行该工程下的所有测试用例。也能够独自制订运行某一条用例；⑦：配置文件。所有的配置文件，蕴含execl、conf、json等格局的配置文件。次要用于参数化，数据驱动，配置信息等。3. 框架截图 二、Web接口自动化1. 工具或框架 Unittest框架，Selenium+Request+Python集成开发劣势： 同WebUI自动化劣势： 同WebUI自动化 间接应用接口工具，如postman、Jmeter等2. 框架截图 ①间接用脚本的话，其实和UI差不多，如下： ②如果应用工具的话，当然也很不便，postman如下：①：接口申请的形式，如post、get、put等②：接口的URL③：接口申请的Body格局及内容 三、Web服务性能测试1. 工具或框架 LoadRunner+Nmon2. 工具阐明 LoadRunner： ①能够提供脚本录制； ②反对多种协定； ③局部版本是能够破解的； ④可设置多种测试场景； ⑤软件自身能够给出一些性能指标，如：谬误数、事务均匀响应工夫、每秒点击次数、吞吐率等 Nmon间接装在被测服务器上，能够监控服务的CPU、IO、过程、线程、内存等信息 3. 工具截图 LR： NMON： 四、挪动端自动化1. 工具或框架 UI自动化：Appium+Python/Java安卓零碎兼容性：Google CTS2. 框架阐明 次要内容能够查看如下图：APPIUM： GOOGLS CTS： 五、桌面端自动化1. 工具或框架 Ranorex+C#/VBS劣势： 抉择Ranorex，次要是因为能够进行破解，而且反对的平台比拟多，最次要目前的本人的我的项目是基于QT集成开发。貌似qtp不反对qt控件，具体没怎么钻研。2. 框架阐明 桌面端这个，后边会独自出一章比拟具体的内容，当做是本人的学习笔记了。

2022年12月6日，龙智与软件测试自动化“领导者”SmartBear联结举办了主题为“如何通过自动化测试实现降本、增效与提质”的在线研讨会。此次研讨会中，龙智技术总监李毅为大家分享中国企业在品质和测试中面临的挑战，以及自动化测试实际的现状与瞻望。在线研讨会“如何通过自动化测试实现降本、增效与提质”内容回顾《中国企业在品质和测试中面临的挑战以及自动化测试实际现状与瞻望》（节选）演讲嘉宾：李毅（龙智技术总监）大家好，欢送加入龙智和SmartBear联结举办的网络研讨会。明天我会从以下四个方面分享：首先是中国软件测试行业现状剖析；其次是中国软件测试行业面临的挑战，为了应答这些挑战，引入了自动化测试；再者，看看自动化测试的现状与痛点；最初是自动化测试的将来倒退方向。 首先咱们看一下中国软件测试行业的现状。钻研报告显示，整个软件测试的市场规模在逐年稳步增长中。目前的市场规模曾经达到约2,000亿，并且增长速度十分快，每年的均匀增长速度靠近20%。 其次，咱们看到软件测试从业人员次要散布在中东部地区以及南部的一线城市，还有中部和西部等软件研发核心集中的中央。这和软件研发的发达水平放弃正相干，软件测试从业人员次要是集中在软件研发比较发达的城市和地区。 同时，咱们也看到软件测试人才处于紧缺的状态。软件测试的工程师非常紧缺，相较于寰球，中国软件测试人才的数量以及能力都偏弱，整体程度落后于寰球倒退。中国大概有150万软件测试从业人员，其中真正能担当起软件测试职位，真正做软件测试的不超过10万人，具备多年工作教训的测试人员还有余5万。国内30万的软件测试人才缺口每年还以20%的速度增长。从报告数据显示来看，中国软件测试人才缺口十分大。 软件测试面临的挑战随着软件的倒退，整个中国的软件测试面临着许多挑战。 首先是软件状态逐步多样化。大家熟知的PC、手机、平板都有很多应用软件，还有越来越多的智能设施、自助终端、可穿戴设施以及工业传感器，这些介质也集成了十分多的软件。这些多介质展现状态会给软件测试减少难度。 第二点是软件协定的多样化。大家相熟的互联网传统协定占比拟大，其余的例如物联网软件通信协议、工业互联网软件通信协议，包含车联网软件通信协议也纷纷涌现，这些协定自成体系，领有本人的协定内容。多协定为测试工作带来了更高的学习老本或者说进步了门槛，对于测试人员来说是一种挑战。 再者是始终提到的软件迭代速度放慢。刚刚SmartBear的何平康（Ken）老师分享了随着DevOps开发理念的广泛应用，很多互联网公司的软件迭代速度变得越来越快，国内也是如此。他提到，当初约40%的企业是以周为单位进行公布。而像亚马逊这样的国内大型互联网公司的迭代周期是每天屡次公布。这样的迭代速度给如何保障软件测试品质带来了十分大的挑战。 还有软件架构的复杂度。最近几年很多新技术一直被利用于软件设计，比如说大数据、人工智能、区块链和云计算等。这些技术可能还会叠加应用，使得软件架构越来越简单。在软件架构逐步简单的状况下，如何保障软件品质也是对测试人员的考验。 很多软件开发人员都有过这种经验。公司重大的我的项目需横跨多个部门和多个合作伙伴，要和上游合作伙伴建立联系，比方须要他们发送交易申请等，以及和上游的合作伙伴、渠道方沟通，须要他们提供后端的领取或金融类服务。像这样的大型软件开发我的项目，要做好测试协调，比方联结测试数据的筹备、联结测试环境的搭建，这类的协同比拟艰难。 软件安全性要求也为测试人员带来了挑战。无论是政治平安危险还是商业平安危险，企业都面临敏感数据和用户信息被泄露、窃取的危险。安全性测试的挑战不仅存在，并且工作十分艰巨。 最初是软件弹性和可靠性要求带来的挑战。所谓的弹性业务是指电商的促销流动，双11、双12等忽然减少的弹性业务，或是12306购票软件在国庆节、春节迎来一些业务爆发性的增长。为了应答这些弹性的业务增长，很多软件系统会采纳微服务的架构设计和基于云部署的基础架构。这样能够应答疾速迭代，以及轻易伸缩扩大，以应答忽然增长的业务所要求的机器资源。 正是因为这样架构设计，以及基础架构的部署架构，软件测试变得越来越简单。零碎间的调用，或是集群公布新老版本时，测试人员须要关注新老版本是否兼容了数据和程序，还须要保证质量。 可靠性要求次要针对局部行业，尤其是互联网、金融企业，它们须要7x24小时不间断提供服务。针对这种可靠性要求高的软件测试，咱们须要留神异样解决，以及限流、垄断等机制是否能够很快复原。或者通过切换劫难备份、数据中心、利用核心等实现不间断服务。可靠性要求对于测试来说也是很大的挑战。 自动化测试的现状与痛点正是因为上述提到的软件测试行业面临的挑战，所以企业在很多环节中引入了自动化测试，来进步软件测试的有效性和效率。 首先与大家分享自动化测试现状，Selenium 4处于基于web自动化测试的外围位置。它是一个开源的自动化测试框架，能够轻松应用Java、Python、C#等开发语言撰写自动化测试的脚本，以及针对多种浏览器撰写自动化测试脚本，达到自动化测试的目标。 其次，无代码/低代码的自动化测试工具再度风行。Selenium 4框架须要编码或开发技巧，为了打消学习老本，无代码和自动化测试工具流行起来。 而后是自动化测试在软件测试的各个档次都有体现。 大家所熟知的自动化测试金字塔模型，底层的是大量的单元测试，中间层是设施以及接口自动化测试，顶层是UI用户界面的测试。越上层的测试老本越低，无论是执行速度、稳定性还是解决问题老本。随着档次往上叠加，越下层效率越慢，发现问题后定位问题、解决问题的老本越来越高。所以倡议更多地把自动化测试投入到底层，会更加划算。 这只是一个指导性模型，具体投入多少、怎么样去投入，还是要和公司的人员组织架构状况，开发和测试的合作模式等多种其余因素相干。要联合人员的学习老本，历史上测试遗留的合作模式等再做考量。 再者，自动化测试成为DevOps开发实际的重要支柱。如果没有自动化测试的接入，那么想要真正实现DevOps是十分艰难的。方才提到的迭代速度需要，也要求将冒烟测试或回归测试阶段中的大量重复劳动由自动化测试来撑持，缩小工夫老本。 最初，人工智能、机器学习和自然语言解决这些前沿技术已被宽泛使用到自动化测试当中。 除了龙智技术总监李毅，还有SmartBear亚太渠道经理何平康、龙智总经理杨林晶与龙智技术工程师邱洁玉作为演讲嘉宾参加了此次研讨会，就以下主题进行了分享： SmartBear及其软件品质与测试现状调研龙智与SmartBear策略单干扩大DevSecOps解决方案TestComplete UI自动化测试演示及ReadyAPI简介咱们将会议进行了全程录制，立刻点击下方按钮获取完整版回顾视频。 点击此处，观看研讨会视频回顾

2022年12月6日，龙智与软件测试自动化“领导者”SmartBear联结举办了主题为“ 如何通过自动化测试实现降本、增效与提质”的在线研讨会。会上，SmartBear亚太渠道经理何平康深刻解读了《2022年SmartBear软件品质与测试报告》，并从寰球品质测试的现状与趋势动手，剖析为什么企业须要自动化测试。 在线研讨会“如何通过自动化测试实现降本、增效与提质”内容回顾《SmartBear及其软件品质与测试现状调研》（节选） 演讲嘉宾：何平康 大家好，我是SmartBear亚太区渠道经理，负责协调SmartBear与龙智这样的地区合作伙伴。 简略介绍一下SmartBear。咱们成立于2009年，是通过集资与合并组成的一个寰球公司，目前有14个寰球办公室，亚太区的驻点别离在澳洲和印度，在北美、欧洲地区咱们也有办公室。 与龙智达成单干，是因为SmartBear心愿为中国客户带来更好的解决方案以及本地反对。目前在寰球范畴内，咱们领有32000+企业客户。在开源框架方面，我须要特地提出的是，可能有很多人也听过Swagger、SOAP、Cucumber，最近，SmartBear收买了一家叫Pactflow的公司，专门做合约合同测试。SmartBear始终反对4种开源框架，除了市场上的商用工具之外，咱们也会为开源社区的开发人员提供很多常识，给客户提供不同选项的参考。 SmartBear的使命与愿景是心愿给各种规模的软件开发与测试团队提供他们所需的工具。SmartBear不仅是一个提供测试工具的厂商，更能为整个软件开发生命周期的不同阶段提供相应的解决方案。咱们在UI测试、接口测试方面有绝对应的解决方案，但整个生命周期不是只有测试阶段。在设计、建构，最初的部署、监督阶段，以及测试治理或代码审查局部，其实都须要给开发人员一些对应的工具。就像刚刚杨总提到的好马配好鞍，要有对应的工具去进步开发团队本人测试团队的生产力。 这是2020年的考察，数据局部来源于IDC做的寰球开发者预测（2020-2025）。往年，对于开发人员的需要在这个季度有所降落，大家在新闻上能够看到很多大型科技公司在改选，缩小团队规模。然而，对于开发人员的需要总体还是呈上升趋势，其中，开发人员当然包含了有测试责任的开发人员。 当初寰球有2,700万开发人员，依据预测，到2025年，也就是两、三年之后，会有靠近两倍的增长，你能够设想这个市场的重要性。目前，因为疫情关系，很多企业都心愿部署、公布得更快，给企业客户和个别消费者交付高质量软件。当初不仅要求软件开发的速度越来越快，工作量也越来越大。 业界对高质量软件的需要已达到至高点咱们来看另一个数据，谷歌公布的2021年DevOps状态考察。 首先是错误率，当然并不是每个企业均实用，因为企业规模不同，报错率跟出错率也不同，但均匀来讲，每1,000行代码可能就有100到150个谬误，错误率十分高。 其次，咱们预估接口测试和接口调用的市场至多会增长30%。57%的企业采纳了至多三种不同类型的接口。为什么是三种不同类型的接口？因为测试的形式不一样，反对的工具不一样，有些工具可能只反对特定协定的接口，这时就须要其余工具反对。这将造成两个或多个不同团队，或不同工程师之间沟通不良的情况，在测试阶段无奈无效会集。 最初一个比拟乏味的数据。大家留神这里不是6.57，而是6,570，顶级的软件团队从故障中复原的工夫比竞争对手缩短6,570倍！设想您明天与另一家公司竞争，要公布相似的产品，如果比竞争对手慢了几百、几十倍，他们就会比您更早地实现debug和谬误革除，更早地推出目前市场所须要的产品，也就会先你一步涉及市场。所以，这个流程对整个公司十分重要，品质不只是测试团队或开发团队的责任，更会影响到整个公司的业务。 SmartBear软件品质与测试现状调研，2022最新趋势与洞察SmartBear最近公布了《2022年SmartBear软件品质与测试报告》，报告的后果次要来源于咱们对科技业和金融业的考察。 本次演讲，我会筛选几个重要的局部出现，如果心愿失去具体的报告，请各位分割龙智获取。此报告经验了五个周期，考察了世界不同地区的开发、测试人员，共61道问题，都与软件品质无关。 《2022年SmartBear软件品质与测试报告》理解2022年软件测试行业的新兴趋势，以及世界各地的团队对于测试行业将来倒退的见解。分割龙智，立刻获取>>>给大家总结一下报告中的7大次要发现。 第一点，自动化测试覆盖率在去年（2021）年中降落后，于年底反弹，并放弃增速至今，其背地的起因可能在于寰球疫情情况的重复。 第二点，网页软件测试跟接口测试依然占比最大。目前，挪动软件的测试始终处于回升中。大家当初习惯应用手机，国内手机的挪动软件倒退曾经十分先进了，国外也在缓缓追赶。比方手机领取，或用手机解决业务等，所以寰球针对挪动端的软件测试也逐步减少。 第三点是公布频率，企业采纳按季度和年度公布频率的状况已大量缩小，更多的是按周、按天公布。 第四点是不足工夫。在这方面，咱们的很多团队，包含国内外交换过的客户都示意，目前工夫和人力的资源不足是阻止他们实现执行软件我的项目测试的最大挑战之一。 第五点是对于开发团队的责任。目前很多开发团队开始左移，提前帮忙整个我的项目团队做第一步测试，所以生成测试用例成为开发团队的重要责任之一。 第六点对于功能性测试，在接口生命周期测试方面，很多客户会询问我这个问题，那就是他们有很多不同协定的API，给很多不同厂家去应用，有些是同步API，有些是异步API，用于反对不同架构的接口。如何去做接口生命周期的综合测试，是很多企业遇到的痛点。 最初一点可能让大家比拟意外，那就是目前很多UI测试目前在云上执行，因为要跨浏览器或设施进行测试。我晓得很多亚太地区或国内的客户还是心愿在本地执行，把测试用例放到云上对于平安团队来说无奈承受。但在海内，越来越多的企业将他们的测试搬到云上，做跨浏览器、跨设施、跨运行零碎的执行。 除了SmartBear亚太渠道经理何平康，还有龙智总经理杨林晶、龙智技术总监李毅与龙智技术工程师邱洁玉作为演讲嘉宾参加了此次研讨会，就以下主题进行了分享： 龙智与SmartBear策略单干扩大DevSecOps解决方案中国企业在品质和测试中面临的挑战以及自动化测试实际现状与瞻望TestComplete UI自动化测试演示及ReadyAPI简介咱们将会议进行了全程录制，立刻点击下方按钮获取完整版回顾视频。点击此处，观看研讨会视频回顾

2022年12月6日下午2:00-3:20，被Gartner魔力象限列为软件测试自动化“领导者”的SmartBear将联结其中国受权合作伙伴龙智举办首场针对中国用户的ZOOM在线研讨会，以“如何通过自动化测试实现降本增效与提质”为主题，探讨寰球品质测试的现状与趋势、中国企业面临的挑战以及自动化测试的最佳实际参考，并深刻解读《2022年SmartBear软件品质与测试报告》。 应用自动化测试工具，实现降本增效援用许多中国企业曾经引入了自动化测试工具，因为它可能保障产品质量、缩小测试老本、缩短测试周期、满足继续测试。立刻报名研讨会“如何通过自动化测试实现降本增效与提质”企业研发迫切需要降本、增效与提质华为要“活下来”，腾讯要“断舍离”。在经济逆全球化、新冠疫情重复等多重因素的独特影响下，宏观环境不景气，软件行业天然深受影响。面对“寒冬期”，以及本来曾经十分强烈的竞争环境，企业纷纷把活下来作为次要纲领。而在研发畛域，如何晋升效率、确保公布品质同时节省成本，曾经成为企业的重要课题。 自动化测试成趋势，市场持续增长企业研发部门须要缩短软件开发生命周期，能力疾速交付，最终实现降本、增效与提质。其中，自动化测试凭借保障产品质量、缩小测试老本、缩短测试周期、满足继续测试的构建需要等泛滥长处，越来越受到企业器重。只管大环境寒意阵阵，自动化测试市场在寰球范畴内仍然呈扩张趋势。Business Market Insights在近日公布的报告中称，自动化测试市场在2022年已冲破252.5亿美元大关，预计到203年将达到813.6亿美元，在预测期内的复合年增长率为17.3%。 如何胜利施行自动化测试国内有很多企业早已开始实际自动化测试，但他们选用了开源或自研的工具，或多或少遇到了工夫老本投入有余、人员缺乏经验、短少专家编写脚本、难以保护等问题。 同时，市场需求决定了对自动化测试工具的要求越来越高，例如UI测试须要在不同网页、浏览器或者手机型号上进行测试，所以光凭开源或自研的工具是不够的，企业须要怎么的测试解决方案和实际办法能力实现降本增效，省时省心？ 2022年12月6日，下午2:00-3:20，退出龙智DevSecOps系列在线研讨会——自动化测试专场，您将深刻自动化测试畛域，并与行业专家——寰球出名的自动化测试厂商SmartBear亚太区副总裁李永陞、SmartBear中国战略性合作伙伴龙智总经理杨林晶以及龙智技术工程师邱洁玉独特探讨： 从寰球品质测试的现状与趋势，剖析为什么企业须要自动化测试。以及分享《2022年SmartBear软件品质与测试报告》；中国企业在品质和测试中面临的挑战，以及对自动化实际状况的察看；自动化测试最佳实际参考及演示。

当初的企业从以往一年、一个月、一周交付，逐步转变为开始关注两到三天甚至一天内交付。软件自动化测试的呈现及其与手动测试的联合使得这种时长的交付成为可能。 及时的软件测试会发现问题，在性能达到用户之前对其进行纠正。软件测试是最沉闷的探讨之一，而软件旨在为其用户提供便当，并且是软件开发的一个组成部分。 然而须要遵循某些实际以最大限度地应用自动化测试。本文将探讨测试自动化中要遵循的一些实际。 理解自动化测试的阻碍想要建设测试团队，第一步就要理解是什么组织了这个团队转向自动化测试。很多状况下，须要学习一门新的编程语言是一大妨碍。一个团队能够学习一门新的编程语言并施行一个胜利的测试自动化我的项目吗？这些都是团队必须克服的阻碍。为了克服这种恐怖，团队能够尽量从小处着手，一步一步学习。 抉择适合的工具和框架次要思维是让整个团队都对心愿所应用的工具和框架感到称心。实际上，自动化工具的抉择起着至关重要的作用。抉择的工具能够是开源收费的，也能够是须要购买但具备所需性能提供更好反对的商业工具。与工具相干的性能应合乎须要测试的软件应用程序的测试要求。它最好能够与多种编程语言、操作系统兼容。 自动化什么首先，团队必须优先思考哪些测试要自动化。能够自动化测试≠自动化所有测试，自动化测试并不意味着它能够利用于所有事务。自动化简单和不罕用的测试是相对的失败，那不值得破费精力。另外，还能够创立一个对特定测试套件至关重要的浏览器和设施列表。 为自动化调配和分工不同测试的创立能够反映出 QA 工程师的技能程度。因而，确定每个团队成员的教训和技能至关重要。而后须要依据团队成员的技能来划分测试工作。例如，编写测试脚本须要深刻理解脚本语言，那么要执行这些工作时，就应该让 QA 工程师理解自动化测试工具提供的脚本语言。测试自动化打算的效率取决于依据测试计划、业余人员的专业知识和测试团队规模对人员进行正确的任务分配。 划分成更小的功能模块创立模块使项目经理更容易无效地跟踪测试覆盖率并理解缺点或谬误的确切地位。测试人员也更容易为较小的模块编写测试脚本。 自定义测试环境创立一个无效的定制测试环境只能通过生产环境的准确复制来实现。因而，测试环境须要包含用于开发具备定制配置的软件的测试自动化零碎和工具。 尽早并以更高的频率进行测试尽早且频繁地进行测试有助于显着缩小缺点或谬误的周转工夫。此外，在软件开发的不同阶段进行频繁的测试也使其可能以更高的准确性运行。 测试后果剖析的指标在不同的软件开发周期中取得正确的指标来评估和监控品质指标是无效软件测试自动化打算的另一个要害方面。 强调错误报告实现的错误报告的品质与周转工夫之间存在间接关系。此外，关于软件中存在的谬误的清晰、具体和精确的信息的可用性有助于更快地打消它们。 关注正文的重要性大多数时候，你不会是惟一一个致力于自动化的人。因而，通过对本人的代码保持良好的正文来帮忙共事和将来的本人。大家不是读心者，也不会了解他人的思维过程。因而，为了共事和将来的本人，有必要在绝对凌乱的局部增加十分具体的正文！ 代码可重用性自动化中最常见的操作之一是为每个操作查找元素，例如单击、输出等。代码的可重用性很重要，因为为每个操作查找雷同的元素会浪费时间。相同，创立一次并一直在须要的中央重复使用雷同的内容就能够大大提高效率。 高质量软件或应用程序的交付取决于其软件测试打算的有效性和效率。因而，只有遵循某些最佳实际，测试自动化能力帮忙实现高质量的软件并缩短上市工夫。

事件是这样的，女朋友昨天跟我吐槽说她闺蜜玩“羊了个羊” 刷到朋友圈榜前10，而她连第二关都过不了，曾经开始狐疑本人了。于是我拿起了她的手机关上了羊了个羊小程序，关上了Charles和Apifox，并且联合了Apifox的自动化测试性能不小心把她刷到榜一！ 筹备工作抓包工具：Charles 获取token接口管理工具：Apifox 地址：apifox.cnCharles 抓包1.获取PC的IP地址 2.配置代理 这里以iPhone手机为例： 在iPhone的设置 -> 无线局域网 -> 局域网信息 -> 配置代理 -> 手动中配置代理，服务器输入框中填写PC的IP地址，端口输入框中填写Charles的代理端口（个别是8888） 3.装置证书 在浏览器中拜访 http://charlesproxy.com/getssl能够下载证书并装置。 更多对于Charles抓包配置能够参考：iOS的http/https申请——十分钟学会Charles抓包 4.关上羊了个羊小程序抓包 抓包cat-match.easygame2021.com域名下的接口，获取 token 能够看到以下界面 咱们将token信息复制寄存起来 Apifox 自动化测试弱小的网友把羊了个羊通关接口公布到Apifox平台，地址：apifox.cn 文档地址：yangyang.apifox.cn （才发现原来Apifox曾经上线了自定义域名性能 ）Apifox在线运行:https://www.apifox.cn/web/project/1630884/apis/api-40162839-run接下来咱们依照文档指引 首先克隆这个Apifox我的项目 把上文抓包获取的token放到这里 而后创立一个自动化测试用例，循环调用接口。 这里配置循环1w次，肯定要让女朋友当第1！ 实现上述操作后咱们执行这个测试用例 跑完我让她关上了小程序看了一眼，卧槽真的第1了！ 地址：apifox.cn

近年来，随着DevOps和麻利过程越来越宽泛地被采纳，软件测试、特地是自动化测试失去了迅速的倒退。 《软件自动化测试金字塔模型》将可自动化的测试自底而上分为单元测试、服务接口测试和界面自动化测试三个局部。正立的金字塔构造倡议咱们发展更为宽泛的单元测试，以期取得更早发现问题和更高执行效率带来的收益，但一直减少的单元测试也会显著进步开发资源的投入。随着趋于顶部更多的UI层面自动化测试的发展，咱们能够取得更高的累积测试覆盖率，但频繁的用户界面调整会带来更高的脚本保护工作量，自动化测试的投入产出比也将逐渐收敛。 近年来，随着挪动利用的遍及、微服务和Web前后端拆散模式的广泛应用，客户端的体现层交互同服务端的业务解决之间，在零碎架构层面做了更为清晰的逻辑划分。因而，在接口层面领有了更多的测试机会，借助接口测试，咱们能够： 模仿客户端用户操作引发的全副业务场景解决调用；领有更为明确和稳固的协定层输出到输入的对应关系；实现必不可少的向前兼容老版本服务API的回归测试；适当缩小过多单元测试带来的开发技术资源投入老本；躲避产品界面频繁调整带来的UI测试脚本的保护老本。专题目录

在后面的文章中，咱们介绍了自动化测试框架设计无关的内容。理论工作中，咱们通常没有必要从头开始造轮子，而是能够基于一些开源我的项目，实现适宜本人公司业务的测试框架。 禅道团队在设计ZTF开源自动化测试框架时，咱们心愿他能够满足以下几个指标： 学习成本低，一节课工夫即可上手；尽量减少对公司现有测试资产的侵入；免装置，下载后解压即可用；反对风行的各种脚本编程语言；兼容支流的自动化测试框架；丰盛的命令行参数，以不便在继续集成工具中应用；自带一个简洁、易用的客户端；反对各种支流操作系统；能够和公司现有研发管理系统很好地集成。ZTF做到了同编程语言的无关性，引入ZTF开发测试脚本时，您能够确保以往的绝大部分代码资产依然可用。相似风行的商业自动化测试工具HP QTP，ZTF举荐以文件和目录的模式，来组织测试用例的脚本，并应用Git等工具来实现脚本的版本控制。通过在脚本中编写正文，定义测试案例的编号、步骤和期待后果，以达到同禅道测试用例对应和同步的目标。 ZTF由Golang语言编写，交付的命令行和客户端工具都是无需装置、解压即用的可执行文件，可运行在支流的Windows、Linux和Mac操纵零碎上。客户端工具提供了脚本治理、用例同步、测试执行、后果剖析、报告上传等易用的自动化测试无关的性能。 近些年，随着继续集成和DevOps被越来越宽泛地承受。为了满足同Jenkins、GitLab CI等工具的集成，实现自动化的编译、打包、部署、测试、公布等一整套流水线作业，ZTF提供了丰盛的命令行指令，可驱动各种脚本语言、单元和自动化测试框架，实现业务的自动化测试，剖析后果并提交到禅道。 ZTF和禅道我的项目管理系统深度集成，在禅道端造成了对立的研发过程和品质度量报告，实现了用户心愿从繁多入口掌控包涵了软件测试和质量保证的整个研发流动的欲望。 目前，禅道和ZTF的近程测试执行调度的性能正在缓和的开发中。将来联合禅道ZenVM开源我的项目，能够提供按需启动、用后即焚的虚拟化测试环境调度性能。 像目前市场上的其余优良的开源自动化测试工具那样，ZTF并没有打算囊括自动化测试的方方面面，而是给与用户联合其余工具一起应用的可能性，以取得诸如RobotFramework关键字驱动、TestNG数据驱动和并发用户、Playwright浏览器驱动引擎等各自低劣而成熟的个性。 专题目录

禅道是一款国产的开源研发项目管理软件，基于麻利和CMMI治理理念进行设计，残缺地笼罩了项目管理的外围流程。依据国内权威测试网站51Testing的《2021软件测试现状调查报告》显示，禅道已间断七年在"罕用的测试管理工具”中排名第一。 在后面的专题文章中咱们认为，随着继续集成和DevOPS的风行，自动化测试曾经成为了研发流动中的不可或缺的一个重要环节。甚至能够说，没有成熟的自动化测试，继续集成和DevOPS都不堪称之为胜利。 本文给大家介绍如何将第三方的自动化测试工具同禅道进行集成，打造一个一站式的残缺研发治理平台。内容基于禅道16.5版本，更早的版本请参照这里装置RestAPI后持续。 首先，您能够将公司现有的自动化测试脚本和禅道中的用例相关联，据此能够统计禅道测试用例的自动化率。通过调用禅道testcases接口，能够在禅道和自动化零碎间，同步测试步骤和期待后果等信息。在禅道开源的自动化测试框架ZTF中，咱们反对ZTF自治理的测试脚本到禅道用例的映射和同步。 #!/usr/bin/env php<?php/**title=the simple demo for ztfcid=0pid=01. step1 >> expect 12. step2 3. step3 >> expect 3*/print("expect 1\n");print("expect 3\n");您能够应用禅道的继续集成个性，在流水线中执行单元或自动化测试。执行实现后，将输入的测试后果，应用ciresults接口提交到禅道，由禅道中集中地展现测试报告。在禅道开源的自动化测试框架ZTF中，咱们反对把脚本执行后果、单元测试后果和第三方通用报表工具Allure Report的报告同步到禅道中去。如果ZTF脚本正文中设置了禅道用例的编号cid，或者在Allure通过标注（正文）或代码的形式设置了单元测试用例的编号，具体的测试后果在同步后会挂到指定的禅道用例上。 在测试执行中产生用例失败时，能够应用bugs接口向禅道提交缺点。缺点的形容能够从ZTF脚本的执行步骤、期待后果、理论后果，或单元测试的输入信息中获取。具体能够参照ZTF开源我的项目的cb提交缺点指令的实现。 借助您研发管理系统中所维系的需要、用例、脚本、执行、后果和缺点等工作件之间的关系，您能够在项目管理层面，失去需要的用例设计覆盖率、用例的自动化覆盖率、某次迭代中的用例或需要的执行覆盖率等度量指标。 以下列出您可能须要应用到的禅道接口，供大家参考。 登录POSTapi.php/v1/tokens 列出所有产品GETapi.php/v1/products 列出产品的用例模块GETapi.php/v1/modules?type=case&id=<product_id> 列出产品测试套件GETapi.php/v1/products/<product_id>/testsuites 列出产品测试套件GETapi.php/v1/testtasks?product=<product_id>&limit=1000 依据模块获取用例api.php/v1/products/%d/testcases?module=%d 依据套件获取用例api.php/v1/testsuites/%d 依据工作获取用例api.php/v1/testtasks/%d 获取用例详情GETapi.php/v1/testcases/%d 更新用例内容PUTapi.php/v1/testcases/%d 提交测试后果POSTapi.php/v1/ciresults 提交缺点POSTapi.php/v1/products/<product_id>/bugs 上述接口，能够在禅道“文档->接口库”中找到其API的具体介绍，在ZTF开源测试框架我的项目中，咱们已应用Golang做了实现，具体可参考这里。 专题目录

尽管从本人的谬误中学习也不错，但从他人的谬误中学习总是更好的。 作为一个自动化测试人员，分享常见的容易犯的10个谬误，能够从中吸取教训，引以为鉴。 一、必要时才自动化新人小王接到为Web应用程序自动化测试脚本的工作时，既快乐又缓和，因为这是他进入团队的第一个工作。第一印象至关重要，他也心愿给团队留下完满的第一印象。小王被要求自动化Web应用程序其中的一个模块，但他想体现得更好、做更多的自动化，于是抉择了另外的模块。然而后果是他撞进了死胡同，没有实现。其实小王想做些新尝试并没有错，错在没有征询前辈就试图自动化该模块。事实证明，这个模块用不着自动化，因为集成的零碎可能会导致多重误报。 我在新的自动化测试人员身上看到过很屡次这种状况。毕竟，好奇心能够引领后退。当学习自动化测试时，会想尝试在每个我的项目中引入自动化，但这是不必要的。可能有足够的能力自动化某件事，但这件事是否足够可行？尽管家喻户晓自动化能够节省时间和精力，但答复以下问题十分重要：“为什么要将此我的项目自动化？”失去了确切求实的答案后，再为自动化开绿灯。 二、定义范畴定义将要执行的测试的范畴是十分必要的。作为老手自动化测试人员时，总是试图测试所有的货色，并使每个测试都自动化。问题是只管能够胜利地自动化所有测试，但这既不实用也不可行。 首先，代码中有很多局部并不需要频繁的测试，但可能须要占用大量工夫为其开发框架或脚本。比方当测试一个网站时，自动化网站的每个元素并在其上运行脚本是没有用的，这不值得花工夫和精力。 其次，自动化所有的货色会减少测试自动化百分比，这会提供书面上很好的数据，让本人感觉实现了一项杰出的工作，然而实际上并非如此。 定义测试的范畴，只思考可能及时提供理论价值的自动化测试的可行代码，做出理智抉择。 三、精确抉择自动化测试工具自动化测试人员最常见的另一个谬误是没有抉择正确的自动化测试工具。一个我的项目蕴含许多专一于不同测试指标的组件。这些指标应分为不同的工具，以帮忙更无效地实现这一指标。 例如，如果想测试一个网站的API，最好应用Postman；但如果你想确保Web应用程序在不同浏览器间的完满出现，那么在线Selenium Grid将是自动化跨浏览器测试的最佳抉择。 四、与其余测试人员良好协调测试团队中有很多人，大家具备不同的技能。例如，有人可能善于业务测试，而其他人可能善于功能测试。然而，这不是不与他们探讨工作停顿的理由。协调是减速产品交付的要害。理解谁在做什么、应用什么工具、对测试自动化的编程语言是否称心。 这有助于帮忙排除自动化测试脚本的故障，万一事件不顺利，就会晓得该寻求谁的帮忙，理解团队也能够帮忙本人在须要的时候进行协调。正如在最初一点中所探讨的，一个我的项目可能须要不同的工具来实现组合的指标，能够让善于不同工具的测试人员施展本人的作用。 五、查看投资回报率仅仅将测试人员的工资作为与整个测试过程相干的老本思考进去是一个十分老手级的谬误。显然，状况并非如此。 例如心愿对网站执行跨浏览器测试，测试人员的工资当然是老本的一部分。但如果团队不晓得这种类型的测试或与之相干的任何工具，那么还须要通过培训来晋升他们的技能，这会产生额定老本。此外，还须要有适合的自动化测试工具或者框架来执行自动化浏览器测试。当然，也能够思考开源框架。 这只是一个例子。同样，在对Web应用程序执行自动化测试的过程中，您还会遇到其余投资。然而，他们必定会呈现。因而，应认真思考测试老本，并牢记您将取得的这些投资回报。如果回报率较低，则须要更改策略并再次计算。但最终，您须要在整个测试过程中取得良好的投资回报率。 六、适度依赖无代码测试尽管无代码自动化测试工具的学习曲线很短，很容易入门，但它们不会帮忙构建自动化测试人员配置文件所需的相干技能集。作为初学者，它们很好地帮忙老手起步，但随着本身技能的倒退，就会意识到它们并不像冀望的那样有用。如果决定用无代码自动化工具的智慧加入自动化测试人员的面试，或者始终独自用无代码自动化来自动化简单的web应用程序，那么将经验一段艰巨的时光。 可靠性是这类工具的另一个大问题。在一天完结的时候，须要理解代码，以便调试本人的自动化测试套件执行出错的中央。此外，如果面对一个简单的网站，那么就不会发现无代码自动化测试工具能够像你想的那样灵便。倡议不要回避代码，而是要熟练地学习它。最重要的是，这将是个人简历上的一大魅力。因而，作为自动化测试人员，请确保防止这种常见的谬误。 七、保护测试设计测试设计是将个别测试指标转换为无形测试用例和条件的过程。作为开发人员，咱们偏向于认为既然测试须要编码，为什么开发人员不能实现这项工作？如果是这样的话，那么测试这个岗位也就不存在了。 作为初学者，不了解测试设计的重要性可能是作为自动化测试人员最大的谬误。任何时候测试任何货色都是荒诞的想法。为了无效地进行测试，测试人员须要设计测试，而后对其进行编码。设计测试有助于创立有意义的测试，并使整个测试过程十分高效。 八、关注代码重用性测试用例对它所利用的代码并不是惟一的。在一个我的项目中，会呈现许多相似的组件，它们须要相似的测试设计和测试套件。比方，在应用Selenium进行跨浏览器测试时，咱们发现Web页面的四个元素都是输出字段，并且须要相似的测试用例。在这里，能够通过仅为第一个元素编写测试来复制粘贴代码。尽管这将给出预期的后果，但问题是未来开发人员可能会以某种形式更改元素。当初，要更改测试用例，就须要更改所编写的每个测试套件中的代码。所有的工夫都将节约在寻找和批改这些测试代码上。 为了防止这种状况，应该始终关注代码的可重用性。与其一次又一次地粘贴代码，不如用适当的参数结构一个函数，并在每个元素上调用该函数。这样，如果未来有任何更改，只须要批改函数，就能够开始了。 九、100%自动化是一个神话跟计算机领域经典的“人月神话”一样，这里的“神话”同样指不可能达到的天方夜谭。 不要置信这种神话，因为作为一个自动化测试人员，这将是一个重大的谬误。作为自动化测试畛域的老手，对于将自动化引入到我的项目中都会很兴奋。但这会让人犯错误，认为自动化测试能够齐全取代手动测试过程。随着工夫的推移，咱们将晓得这是不可能的。百分之百用自动化测试取代手动测试是一个神话，它永远不可能实现。 作为这方面的初学者，不要试图实现这样的指标。又回到第一条，只有在必要时才进行自动化，并且只对那些须要自动化的我的项目进行自动化。 十、遵循从头开始在测试时，会遇到不同类型的问题。须要设定指标并对这些问题进行分类。一种根底办法是用较小的模块而不是大模块开始自动化测试。 作为自动化测试人员，最大的谬误之一是开始自动化时应用更大、更简单的模块。可能不足对每个用户交互中波及的入站和出站流程的意识；甚至可能不足解决辣手的测试用例的熟练程度；可能最终会节约大量的工夫，但却满载而归。所以从小处开始，从根底的办法中减少自动化测试的覆盖率。 第一次踏入自动化测试畛域，不免犯一些谬误，这些谬误会造成工夫、金钱、精力的节约。心愿这篇文章能对自动化测试新人有所帮忙，帮大家防止踩这些不必要的坑。

软件测试行业在我国的倒退工夫并不长，因而目前比拟常见的测试岗位人员也大都是手工测试，然而随着现在科技的倒退，自动化测试必然是将来倒退的趋势，它能够很好地节省时间老本和人力老本，进步工作效率。因而学习自动化测试曾经火烧眉毛，那么python自动化测试课程哪个好？  Python的自动化测试，学计算机语言，不仅要学习语法，最次要的是应用。把握了语法和软件的性能后，更要进到我的项目中去练习。在我的项目的练习过程中，再去把握和了解语言和语法。无论做什么测试，都要搞清楚我的项目的业务流程，而后进行录制，录制后，再依据非凡的状况，或者跑不通的中央，进行编程语言的调整。 至于哪里的课程好，小编依据身边敌人的反馈得悉，有个叫柠檬班的线上培训机构就还挺不错的。他当初自身是做技术客服的，因为疫情被裁员在家待业，而后刚好有个做测试的敌人给他说目前测试岗位人口紧缺，让学习下相干课程，转行做测试算了，之后就全网搜寻相干的信息，有一次在B站晃荡，看到了柠檬班华华老师的课程，内容夯实，知识点清晰，讲课格调深入浅出，人不知;鬼不觉就听进去了感觉还不错，就报了名，因为自身就做过3年技术客服，有一点底子，所以学得也还挺快的。  所以刚学完根底就去找工作，因为那时候疫情才完结，再加上各行各业都缺人，所以很快就找到了根底的测试工作。前面等工作稳固了点后，又立即报名了柠檬班的Python自动化课程，并且在课程上完后，他就快马加鞭地跳槽换了一份薪资更高的工作。 当初小编还不了解，明明前一个公司干的好好，为啥学了点货色就要从新换呢，但当现在理解到软件测试每个阶段的薪资差之后，我才明确，这学货色本就是冲着涨薪去的，有更高薪的中央不去那才是真的想不开。  

自动化测试是高质量软件交付畛域中最重要的实际之一。在明天的麻利开发方法中，简直任一软件开发过程都须要在开发阶段的某个时候进行自动化测试，以减速回归测试的工作。自动化测试工具能够帮忙测试人员以及整个团队专一于自动化工具无奈解决的各自工作，但艰难的局部就是抉择自动化工具。事实上，测试人员最常见的问题就是，如何抉择合适的自动化测试工具？ 在本文中，咱们将具体探讨在抉择自动化测试工具时如何进行抉择。但在持续之前，让咱们强调一下自动化测试工具的重要性。 抉择最佳自动化测试工具的重要性如果想对我的项目进行胜利的自动化测试，辨认正确的自动化工具至关重要。为我的项目自动化测试抉择适合的工具是取得我的项目所需后果的最佳办法之一。让咱们以web利用程序开发为例，更好地理解自动化测试工具的重要性。 假如您正在为业务开发一个网站。当初，在一开始，如果你是在低水平上守业，你不须要任何自动化测试。所有测试都能够用手动办法实现。然而，当您的业务开始增长并开始取得宽泛受众的认可时，您可能须要自动化一些流程，如web利用的跨浏览器测试，以确保它为所有用户提供相似的体验。 假如正开发一个网站。如果初期是处在较低水平，那不须要任何自动化测试，所有的测试都能够用手工办法实现。然而当业务开始增长，并宽泛取得用户的认可时，就可能须要自动化一些流程，如跨浏览器测试这个web利用，以确保它为所有用户提供相似的体验。 此外，如果须要回归测试，那么也须要执行自动化测试。这就是为何抉择一个可能提供所有这些性能的自动化工具是必要的。 自动化测试工具的品种通常有三种类型的自动化测试工具可供选择。以下是每种类型的简要阐明： 1. 开源自动化测试工具开源工具基本上是收费的平台，容许您拜访和应用源代码，也能够批改其原始设计。应用开源工具没有任何老本或费用。 此外，开源工具能够用于测试过程的任何阶段，如测试用例治理、bug跟踪、调试等。当然，一般来说，与商业测试工具相比，开源自动化工具的性能更少。 2. 商业自动化测试工具商业测试工具是专门为商业目标而设计和生产的。诸多大型企业会抉择应用商业自动化测试工具，因为它们具备可扩大个性和来自技术团队的反对。 3.定制工具或自研工具对于小众测试项目，测试环境和测试过程有一些非凡的特色，这是开源或商业自动化测试工具无奈实现的。因而，测试主管须要思考定制工具的开发。这些类型的工具很少被多数组织应用，因为它们须要明确地开发。 抉择自动化测试工具时要思考的因素抉择正确的自动化测试设置取决于多个因素。每一个测试设置在开始时举世无双，随着我的项目的倒退可能演变成齐全新鲜的货色。抉择将随着我的项目规模而扩充的正确设置与抉择用于开发应用程序的正确技术堆栈等同重要。以下是影响决策的几个因素： 该工具是否反对您的测试流动，以及是否在市场上可用。哪个自动化测试工具最适宜您的我的项目需要和估算。团队是否具备应用该工具所需的技能，如果没有，那么在您购买测试工具后，谁将应用该工具。自动化工具对于您正在应用的我的项目环境和技术是否精确。该工具是否有收费试用版，以便购买前剖析其性能。随着我的项目的增长，扩大测试平台所波及的老本和开发工作是什么。保护和治理旧的测试以在我的项目中应用更新有多艰难。只管在抉择自动化工具时蕴含许多因素，但咱们置信这些是您在寻找自动化测试工具之前须要思考的根本因素。让咱们更深刻地探讨抉择最佳自动化测试工具的概念。 自动化测试工具的抉择规范无论您的我的项目对自动化测试工具有什么要求，总是有一种简略而无效的办法来为您的项目选择最佳的自动化测试工具。 1.全面剖析我的项目需要通过提供无缺点的产品来放弃我的项目的品质对于我的项目的胜利至关重要。自动化测试是进步任何我的项目品质以及减少测试深度和范畴的最佳办法。然而，在施行自动化测试之前，请分明地理解您的我的项目需要，例如： 我的项目类型是什么？它是web/桌面/挪动应用程序还是其余类型我的项目？我的项目公布后的范畴是什么？在流程开始之前，分析测试团队在代码语言方面的实力。一般来说，没有齐全好或坏的自动化工具，然而如果心愿该工具具备良好的ROI，这齐全取决于我的项目须要，例如理论须要自动化什么以及有多少测试用例须要自动化测试。 对于大多数我的项目，普遍认为手动和自动化测试对于web、挪动和桌面应用程序的测试都是必不可少的。因而，能够抉择可能与我的项目布局和测试管理工具无缝集成，而且学习速度快、使用方便的工具。 2.将现有的自动化工具作为基准进行比拟如果您正在应用像Selenium测试自动化这样的开源自动化工具，那么能够将其作为评估和确定我的项目最佳自动化测试工具的基准。为此，就须要理解Selenium自动化工具的长处和毛病。 例如，Selenium是一种开源的收费工具，容许用户测试其web应用程序和网站。它还为自动化测试提供了独特的性能，如记录回放以创立记录回放测试脚本，以及对多种语言的语言反对。然而，Selenium WebDriver并不能提供良好的客户反对。 Selenium是相熟编码技术并通过用户界面测试其网站的测试人员的首选。此外，Selenium套件的保护并不容易，尤其是对于常常监督手动和自动化测试的测试人员来说。应用Selenium可能面临的另一个挑战是web利用的浏览器兼容性测试，因为不可能跨浏览器、操作系统和设施的多种组合主动进行跨浏览器测试。 因而，抉择以后的测试工具作为基准并将其与决定购买用于自动化测试的工具进行比拟是至关重要的。 3.验证适宜我的项目的要害规范在确定我的项目的最佳自动化工具之前，须要思考以下要点： 对于任何我的项目成员来说，测试执行都必须简略，以便成员都可能在须要时高效地运行测试。此外，对于技术常识很少的非技术用户来说，这也应该是容易的。该工具生成的测试报告对于治理团队来说必须直观、简略，以便他们可能了解测试过程。自动化测试工具必须反对所有三种平台，包含web、桌面和挪动应用程序。测试脚本的开发和保护必须缩小人力和工夫资源管理。当波及到web应用程序的跨浏览器测试时，自动化工具必须反对多种浏览器和平台。反对关键字驱动测试，因为它充当了数据驱动测试框架的扩大。自动化工具必须反对我的项目所需的语言，以便测试人员能够轻松地编写代码。在抉择自动化测试工具时，技术支持和帮助是首要任务，请确保该工具能够取得继续的技术支持。如果蕴含其余性能是加分项，如屏幕截图测试、视觉外观测试、实时测试等。比拟不同自动化工具的这些关键因素，而后从中抉择最佳因素。 4.在购买工具前思考估算在根据上述规范比拟了不同的自动化工具之后，最初要确认估算。估算是要害的问题之一，这个最好了解，不论根据上述选的工具如何称心，超过组织估算的话都无奈实现。 如果组织已最终确定购买该工具，则倡议下载并应用该工具的试用版，以剖析其性能，以及是否值得投入这么多资金。在试用之后，如果发现该工具有任何问题，那么不要花太多工夫在它下面，而是寻找另一个自动化测试工具。只有确定工具的性能和性能时，才购买该工具。 陈哥卖瓜，自卖自夸，遵循以上各种规范，免去筛选自动化测试工具的懊恼，间接为您举荐禅道自动化测试解决方案。该计划由禅道项目管理软件+ZTF自动化测试框架+ZenData通用数据生成器形成，从测试框架、测试数据和测试环境方面解决测试治理问题。

自动化测试框架AutoTestFramework( 简称:ATF)是能够提供自动化测试执行和治理性能的架构的综合自动化测试框架，能够集成根底自动化测试工具，用于组织、治理和执行那些独立的自动化测试用例，测试实现后统计测试后果。目前该框架能够集成的根底自动化测试工具有自动化测试工具AutoRunner，挪动端自动化测试工具MobileRunner，进而实现界面性能自动化测试、挪动端界面自动化测试。除此之外，该框架还能够建接口测试组件进行多种类型接口自动化测试。 AutoTestFramework面向的用户是所有须要进步软件开发品质的软件公司、软件内部企业，以及提供测试服务的部门。应用ATF能够帮忙用户进步测试效率， 框架融入多种用例设计技术，无效的帮忙用户在线用例设计，进而进步用例品质；ATF框架在执行工作时采取多种工作执行形式，能够帮忙用户对执行工作的资源进行正当调配；ATF框架的全面的缺点治理，使整个的测试生命周期得以欠缺，帮忙用户品质控制点上进行严格把关；全面的自动化测试报表能够帮忙用户对整个测试过程进行针对性评估，将测试行为具体指标化。 自动化测试框架AutoTestFramework硬件环境 Pentium 2.4GHz CPU 2G Memory 至多5G的硬盘空间 自动化测试框架AutoTestFramework软件环境 反对的操作系统： windows xp/windows2000/windows2003/windows2008/windows7/windows10 举荐的操作系统： Windows xp/window2003/windows7 JDK1.7以上版本 IE9.0以上的浏览器 零碎的分辨率，倡议应用1024*768

AutoRunner自动化测试工具，自2008年推出以来，在自动化测试畛域反对宽泛的各种技术框架，反对录制创立beanshell脚本，帮忙大量的客户实现了软件自动化测试。 随着技术的倒退，品质团队不再限于测试团队，很多运维团队、业务团队也退出了自动化测试的行列。于是，如何应用beanshell编写测试脚本，就成了一个跨不过来的门槛。编写测试脚本对于没有编写代码教训的人，太难了！ 为了帮忙宽广不足编码技术的工程师发展自动化测试，AutoRunner行将推出无代码化的新版本！！！从此，实现自动化测试不再须要编写代码！ 那么，咱们看看，AutoRunner的新版本为咱们带来了什么新的性能： 保留了录制性能。咱们依然能够通过点击“录制按钮”来录制你的操作，取得测试脚本。录制始终都是一个“很炫目”的性能，因为它自身就什么都不须要做，依照失常的操作就能够了。录制的后果，就是这个样子： 咱们能够看到，原来的脚本，变成了中文的形容，这下子大家都能够看懂了！ 每一个操作，都由两行组成，第一行是咱们做了什么操作，比方“点击”、“输出”等，第二行形容对那些内容做了操作。 参数化。咱们晓得对于自动化测试而言，参数化是必然的技术。咱们在“参数设置”区域，点击须要进行参数化的输出或者输入内容，就会提醒你能够抉择一个参数。抉择实现，参数化就实现了！非常简单吧！ 编辑自然语言脚本。尽管咱们还是把它叫做“脚本”，然而只是一种习惯。如果须要扭转程序，咱们是采纳“拖拽”的形式，即：选中你须要扭转程序的行（单行或者多行），而后鼠标拖拽到你须要的中央，开释即可实现。 如果咱们须要减少一个检查点，怎么办？咱们能够从“内置函数”面板上“拖拽”一个对应的查看点函数到自然语言视图面板上，而后设置对应的参数，就能够减少检查点了。 如果咱们须要从对象库中创立一个操作的步骤，咱们只须要把这个对象从对象库面板“拖拽”到自然语言主面板，就能够实现了。当你拖拽实现，会依据这个对象的类型主动给一个动作。比方你拖了一个按钮，动作默认就是“点击”。如果不是你想要的，那么能够通过鼠标右键点击，来从新抉择可能的动作，来扭转。 如果我的脚本比较复杂，比方有循环10次这样的操作怎么实现？咱们只须要在“控制流”合格节点上，拖拽一个“for循环”的节点过去，而后设置循环次数就能够实现循环了！也反对其余的循环，以及分支判断语句等等。 AutoRunner为了防止用户设置浏览器等操作，还会内置自带一个chrome的浏览器。用户在这个浏览器上能够做录制。执行的话，能够在任何一个其余chrome、firefox浏览器上都能够实现。 以上只是对行将公布的AutoRunner新版本做一个预览。这个版本的预期，就是心愿越来越多不相熟、不足编码技术的工程师等，可能进入自动化测试。自动化测试以往因为代码门槛，带来的“遥不可及”，行将变成历史。 敬请期待吧！ AutoRunner产品官方网站：http://www.spasvo.com/autorun...

一、AutoRunner自动化测试工具新建我的项目、导入我的项目 形式一： 新建我的项目，弹出新建我的项目对话框 如果我的项目限定了录制程序，为使限定无效，必须在录制前通过本性能运行录制程序，如果未执行本性能，录制被视为不限定录制程序。留神：限定了录制程序，用户只能对该程序录制，即便该程序运行了另一程序B，B程序也是不可录制的。 导入我的项目 形式二：在我的项目管理器空白区域点击鼠标右键，在弹出的菜单中选中新建/导入我的项目 ● 排除我的项目、删除我的项目、批改我的项目 办法：选中一个我的项目，鼠标放在我的项目上点击右键，弹出菜单 ● 批改我的项目 选定你要批改的项目名称，右键菜单批改： 点击批改，可对项目名称从新设置。 长处是，能够为没有指定录制程序的我的项目给予指定录制程序，或者给予指定好了录制程序的我的项目，对录制程序进行从新指定，和不指定操作。

AutoRunner4.0自动化测试工具中的菜单栏如上图所示，主菜单别离蕴含文件、编辑、录制、执行、设置、工具、许可证、帮忙等菜单项，上面小编对AutoRunner4.0自动化测试工具中的菜单栏中的每一项做一个简略的介绍。 一、首先是文件菜单 如图所示，所有对工具脚本的治理操作都能够在文件菜单下实现，包含对脚本的新建，导入，保留，另存为，敞开，扭转工作空间，最近关上，退出等等。下边具体介绍各性能的用处。 ● 新建：可抉择新建我的项目或者新建脚本； ● 导入：可抉择导入我的项目或者导入脚本（导入的我的项目/脚本存在工作空间但不在零碎列表内显示时）； ● 保留：保留脚本内容； ● 另存为：将抉择的脚本另存为； ● 敞开：敞开以后选中的脚本； ● 敞开全副：敞开所有关上的脚本文件； ● 扭转工作空间...：批改AR的工作空间门路； ● 最近关上：显示最近关上过的我的项目脚本名称；以上就是文件菜单下的性能介绍，上面说一下编辑菜单 二、编辑菜单 如上图所示，所有对脚本的编辑操作都能够在编辑菜单下实现，包含对脚本的撤销，重做，查找，替换，剪切，复制，粘贴，循环参数表，对象库，以及对属性、数据库、音讯框、矩形文本、文件文本、excel文件、正则表达式等各种需要的校验。 三、录制菜单 如上图标所示，录制菜单就比较简单了，只有一个“开始录制”菜单项，只需点击开始录制按钮，就能够启动脚本录制性能。 四、执行菜单 如上图所示，执行菜单蕴含三个菜单项，开始执行菜单启动回放脚本性能，在回放过程中如果工夫比拟长或是遇到问题须要提前敞开回放。以后行开始执行菜单指定的以后行启动回放脚本性能，同样，在回放过程中如果工夫比拟长或是遇到问题须要提前敞开回放。能够点击进行执行以提前终止。 1，以后行开始执行 能够通过执行菜单的以后行开始执行性能，实现从脚本编辑器光标所在行开始进行回放操作。如下： 五、设置菜单 如上图所示，设置菜单中蕴含了零碎、语言设置、扫描JDK/JRE、字号、QT程序、显示录制选项及网络许可模式等的设置，软件当初反对简体中文和英文和台湾繁文设置，在程序首次启动时，会依据零碎默认语言选择初始语言类型和字号，当用户手动抉择语言类别和字号时，软件再次启动才会失效。本软件自带JRE1.6，如果用户电脑上在装置了AutoRunner后又装置了其余的JDK版本，则能够点击此按钮，将AutoRunner自动化测试工具所须要的相应文件写入JDK中，省去了用户重装AutoRunner的麻烦。 1，对于零碎设置选项： 2，回放设置，可设置某些属性，如:设置播放速度，单个命令执行超时工夫等。 对于QT程序设置选项： 则可设置抉择须要被测的QT程序。3，对于网络许可模式选项设置： 可通过对服务器IP地址和服务器端口号的设置来设置网络许可模式。 六、许可证菜单 如上图所示，许可证菜单是AutoRunner4.0自动化测试工具新增的菜单，不便用户在软件中实现许可证的生成和导入工作，因为收费的许可证试用期为15天，当试用期过后再次应用软件后会提醒LIC过期的提醒，此时能够点击“申请许可证”菜单项，依据须要产生req文件，取得我公司为您配置的LIC文件后，能够点击“导入许可证”菜单项将其导入即可。 七、帮忙菜单 如上图所示，帮忙菜单为您提供软件应用帮忙和公司产品介绍。 举荐浏览: web自动化测试工具有哪些 如何学习自动化测试 自动化测试工具有哪些

一、第一步关上网址:http://www.alltesting.cn/jsp/...，找到AutoRunner365自动化测试工具，而后点击产品下载。 二、第二步关上下载的软件安装包开始装置产品，依照装置步骤操作实现即可，而后关上软件界面。 三、关上软件后，点击“注册”按钮，会呈现两种类型选项，依据本身状况间接点击注册Alltesting众测平台注册账号（或者测试工程师或开发者，都能够），注册实现即可。 第四步、注册实现后，回到AutoRunner365自动化测试工具产品登录界面，即可登录应用。 好了，本次AutoRunner365自动化测试工具装置教程就到这里，大家在应用过程中如有不明确的中央，能够在网站上与咱们的客服沟通哦。 举荐浏览: web自动化测试工具有哪些 如何学习自动化测试 自动化测试工具有哪些

Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区独特发动的开发者互动翻新实际流动。透过工程师视角的技术分享、交换碰撞、我的项目共建等多种形式，汇聚开发者的力量，开掘和传递最具价值的技术内容和我的项目，全面开释技术的创造力。 本文为专栏系列内容，作者为声网音视频实验室工程师孙勇男。 什么是测试自动化框架测试自动化框架是为自动化测试用例或者脚本提供执行环境而搭建的基础设施。自动化测试框架为用户提供了各种益处，可帮忙他们无效地开发、执行和报告自动化测试用例。自动化测试框架更像是专门为自动化测试而创立的一套零碎。用一种非常简单的语言，也能够说框架是各种编码标准、测试过程、工作实际、我的项目层次结构、模块化、报告机制、测试数据注入等反对自动化测试的性能的极大交融。 自动化测试框架的类型当初咱们对自动化框架有了根本的理解，让咱们看一下当初风行的各种类型的测试自动化框架。这些框架可能基于对不同关键因素（例如驱动类型、可重用性、易于保护等）进行自动化的反对而彼此不同。 ● 基于模块的自动化测试框架 ● 仓库架构自动化测试框架 ● 数据驱动自动化测试框架 ● 关键字驱动自动化测试框架● 黑盒混合自动化测试框架 ● 行为驱动自动化测试框架 为什么选用黑盒混合自动化测试框架测试 SDK所谓黑盒，即提供给业务测试人员无需思考程序内部结构和外部个性的状况下，在程序接口输出测试的参数并抉择输入项，通过程序外部混合测试框架失去相应的后果，使用者只需关怀输出与输入。 场景设计初衷"自动化是为了更好的解放双手，谋求更高的效率"与互联网软件(app、web)的测试有所不同的是，简略来说实时视频SDK测试简直不须要点点点，根本是通过自研自动化工具实现端与端间通过自定义网络伤害后的视频通信，并采集端上 SDK log 作为测试产出数据，主观测试数据即主观测试后果。围绕并以此通过结合实际业务需要，去离"Code based automation"，依据业务测试以平台化、模块化来提供解决方案，从而提供更多的测试维度、缩小反复体力劳动和效率瓶颈问题。 01 解决方案架构简述根底建设计划● 采纳 CI 集群+测试工具及自动化测试框架 +数据平台化 撑持 daily、发版测试、开发自测的测试工作 ● 具体模块性能简述 落地机房实景● 多套测试节点撑持整个视频主观发版业务线 02 基于自动化测试维度的思考简述逐步完善自动化闭环通常咱们在做自动化测试过程中通常先实现“执行测试”这一步骤，然而这只是绝对自动化的一部分，我集体了解的自动化闭环长处不局限于"输出便捷性灵、测试覆盖性全、测试避障性强、输入聚合性高"，更多的站在整个链路逐渐冲破测试精准性和效率瓶颈。 上面是咱们在测试避障性和输入聚合性模块中的举例: 举例1 时段网络稳定影响在生活中应用聊天软件视频时，往往会因为网络突发稳定造成忽然的卡顿或者或者画面含糊，稳定幅度和工夫都具备不确定性，对于实时视频 SDK 的测试也会遇到这样的问题，尽管咱们尽力保障网络环境的稳固，然而在长时间的测试过程中也常常会遇到诸如此类问题，影响咱们的测试数据。 如何在测试过程中升高因网络稳定造成的数据误差？ ● 利用漏斗式重跑筛选形式，简要构造如图所示 即循环求值保障在设定误差内无效升高因为网络稳定影响 SDK 版本测试数据。 举例2 版本数据稳定影响力采据在实现自动化测试后对于测试版本间或者与 release 版本各项体验指标数据上，个别是通过报告间数字的差别，但随着体验指标的减少，往往咱们更迫切需要多个版本准确到端到端上某个指标上的差异性感知品质可视化。 ● 后盾管理系统-主观报告模块 反对多版本报告比照的case、devices、体验指标等求值动静视图 ...

随着测试技术的倒退，从手工测试缓缓转变成自动化测试，用例覆盖率，决定了测试颗粒度，也是测试质量保证的前提。自动化测试用例与手工测试用例之间有什么区别。 1、手工测试用例 a、能通过人为的逻辑判断校验以后步骤的性能实现是否正确。能较好的解决异样场景。 b、执行测试用例具备肯定的跳跃能力。 c、人工测试能够步步跟踪剖析，可能粗疏的定位问题。 d、次要用来发现产品缺点。 1、自动化测试用例 a、所有的判断校验都须要编写脚本来实现。 b、测试用例步骤之间须要关联关系。 c、次要用来保障产品主体性能正确残缺和让测试人员从繁琐反复的工作中解脱进去。 d、目前自动化测试阶段定位在冒烟测试和回归测试。 举荐浏览： 自动化软件测试是如何做的？ 接口自动化用例设计的准则 自动化测试工具该怎么抉择？ 测试项目都须要发展自动化吗？浅谈自动化测试的利与弊 自动化测试工具有哪些

传统的自动化测试工具，都是先编写测试用例、编写测试脚本，而后做参数化、检查点，通过批量执行来发现问题。 传统形式的问题在于： 1，对测试工程师要求比拟高。大多数的测试工程师并不会编写测试脚本，从而导致自动化测试发展比拟艰难； 2，测试的投入很大。咱们须要搭建自动化测试平台，一次执行海量的自动化测试用例，才会比拟有成果。然而这样做会导致投入很大。 3，测试用例的覆盖率有余。因为编写测试用例的代价比拟高，因而导致自动化测试的用例绝对比拟少，造成覆盖率有余。从实际的状况来看，往往只可能笼罩到次要的、正确的流程，对于比拟少的分支，比拟难以笼罩。 有没有其余的办法，来晋升自动化测试的范畴？ 咱们晓得，自动化测试的劣势在于：1）执行的代价小，执行速度快；2）适宜海量执行用例，比拟可能笼罩到各个分支。然而，因为测试用例设计的问题，以及执行形式的问题，从而导致自动化测试应用的成果不佳。 因而，咱们是否能够参照appscan等测试工具的做法，来解决以上的问题？大略的想法是： 1，测试脚本依然须要，因为没有测试脚本，就无奈进行自动化执行； 2，参数化，以及在参数化之后，对各个输出字段的输出范畴进行形容和束缚； 3，容许用户定义各种规定，用来生成海量的测试用例； 4，海量执行。生成的测试用例，可能达到几万到几十万条。如果应用接口测试，可能须要执行几个小时，甚至十几个小时，执行所有的主动生成的测试用例； 5，可能主动断定是否执行失败。这就须要事后定义规定，对执行的后果，应用规定进行断定，来决定测试用例是否执行失败。 6，人工复核。人工来筛选和查看测试用例，看是否存在漏测、误报的状况。 咱们心愿通过这样的办法，来单个的执行，生成海量的自动化测试用例，并且同步进行执行。当执行实现，咱们也能够从中筛选出无效的、典型的测试用例，退出到罕用的测试用例库中，用来执行回归测试。 举荐浏览： 自动化测试的根本流程 接口自动化用例设计的准则 目前次要的自动化测试框架有哪几种？ 自动化测试实在我的项目工作流程，5个重要阶段和产出物 自动化测试根本流程七个步骤

软件测试简略辨别能够分为手工测试和自动化测试。手工测试执行效率慢，容易出错。然而能够进行探索性测试和发散性测试。自动化测试则是和手工测试对抗互补。 施行自动化测试的根本步骤 首先，须要曾经实现了功能测试，此时测试版本稳固，属性、性能稳固。 依据我的项目的特点、抉择适合的自动化测试工具，并搭建测试环境 提取手工测试的测试用例转化为自动化测试用例 通过测试工具、代码实现自动化的结构输出、自动检测输入后果是否满足预期 生成自动测试报告 继续改良、脚本优化 举荐浏览： 企业抉择自动化测试计划的几点倡议 自动化测试工具有哪些？举荐两个好用的自动化测试工具 自动化测试根本流程七个步骤 自动化测试过程中遇到的零碎验证码问题怎么解决？

　软件测试倒退到今日，曾经逐步标准化且能力更强，其流程每天都在倒退。测试人员的技术熟练程度对于整个测试阶段的胜利来说至关重要。测试不再意味着仅仅发现错误；它的范畴曾经扩充，从任何开发我的项目开始就能够看出它的重要性。　当议论起自动化测试生命周期（Automation Testing Life Cycle）时，大多数人认为这只是 SDLC 的一部分，但它远不止于此。有必要理解自动化测试应该是自动化测试策略的突出局部，并且具备生命周期。企业必须对其进行调整以进步其软件产品的品质。　随着持续推动，须要可能答复以下问题：什么是自动化测试生命周期，以及自动化测试生命周期中的有哪些阶段。　自动化测试生命周期的各个阶段　测试的自动化应该失去弱小的测试计划的反对。流程的预约义构造有助于设计测试计划并制订自动化测试工具的抉择策略，从而设置测试环境、设计测试用例并编写脚本。它进一步定义了测试自动化、测试筹备、施行、测试验证和报告的范畴。　自动化测试生命周期中的这六个阶段与软件开发周期并行运行。以下是各阶段：　阶段1：确定自动化测试的范畴　阶段2：抉择适合的自动化工具　阶段3：定义自动化测试的打算、策略和设计　阶段4：设置测试环境　阶段5：测试脚本和执行　阶段6：测试剖析和报告　1. 确定自动化测试的范畴　这是自动化测试生命周期的第一步。在此步骤中，测试团队须要确定自动化测试的可行性。可行性剖析对于每个阶段都是必不可少的，以查看其可操作性，并帮忙测试团队设计测试脚本。本阶段须要思考的事项包含：　●应用程序的哪些模块应该自动化，哪些模块不应该自动化。　●哪些测试用例能够或须要自动化。　●如何自动化这些测试用例。　●思考到自动化与测试指标的适应性，抉择哪些自动化工具。　●估算、施行老本、可用资源和可用技能。　●测试用例和自动化测试可行性剖析应在开始测试自动化之前进行。　2. 抉择适合的自动化工具　这是ATLC最要害的阶段之一，因为自动化测试依赖于工具。要审慎地思考和抉择正确的自动化工具来自动化UI组件。抉择工具可能须要实现另一个档次的剖析。在抉择工具之前，应该始终牢记估算和老本。除此之外，团队还应剖析资源是否具备技术技能，以及工具是否反对我的项目所需的技术。此外，该工具应提供弱小的技术支持，以答复应用中可能存在的疑难。　3.自动化测试的打算、策略和设计　这是自动化测试周期中的另一个关键步骤，次要解释实现测试自动化策略的办法。这个阶段的次要步骤是决定应用哪个测试自动化框架。在为项目选择适合的工具时，必须记住软件我的项目所需的技术。因而，对产品进行深入分析十分重要。　在执行自动化测试计划时，测试人员为测试过程创立、测试环境的硬件、软件和网络需要、测试数据先决条件、测试时间表、谬误跟踪机制和工具等建设规范和指南。测试人员还负责决定测试体系结构、测试程序的构造和测试程序治理。　●测试管理策略涵盖以下几点：　●测试管理工具将捕捉所有手动测试用例。测试人员须要收集手动测试用例并确定哪些须要测试。　●必须进行彻底的钻研来确定测试框架并理解自动化测试工具的优缺点。　●此外，测试人员还须要理解工具和应用程序之间的所有相干威逼、背景和依赖关系。　●团队还必须在测试管理工具中为自动化测试用例构建一个测试套件。　●未经利益相关者和客户批准，无奈施行或执行制订的测试策略。　4. 搭建测试环境　在此阶段，测试团队必须设置、跟踪和安顿测试环境。换句话说，这意味着在这个阶段，建设了一个机器/近程环境来执行测试用例。须要虚拟机是因为并非所有用户都应用雷同的机器来拜访 Web 应用程序。因而，咱们须要察看用户应用的各种设施、浏览器和版本。如果未正确验证其在不同设施-浏览器-操作系统组合之间的兼容性，网站成果跟用户看到的可能不一样。为了实现这一点，跨浏览器测试成为首要任务，以确保您的 Web 应用程序按预期提供杰出的用户体验。　此阶段须要具体布局以解决尽可能多的场景并减少测试覆盖率。在测试团队负责任的参加下，必须保护所有环境设置流动的正确跟踪和时间表。除此之外，设置测试环境、安顿网络和硬件资源、执行测试数据库清理、开发测试平台和环境脚本等所有都必须解决。　执行跨浏览器测试并不像听起来那么容易。它波及设置不同的浏览器、不同的版本、不同的设施等，这对团队来说是个不小的累赘。　保护浏览器实验室并不是一件容易的事，因为从头开始建设和保护基础设施老本昂扬，而且并非所有企业都能负担得起。因而，倡议采纳基于云的测试基础设施，为测试人员提供一个平台，以测试虚拟机托管的多个挪动和桌面设施的各种浏览器设施操作系统组合。　以下是测试环境设置的几个方面：　●确保有一个能够进行负载测试的前端运行环境，以查看其是否有能力解决高负载的Web流量。　●有时，设置的测试环境没有提供与生产数据类似的数据，使产品容易受到生产环境中任何代码更改的影响。　●须要进行测试的所有零碎、模块和应用程序的列表应该进行保护查看。　●测试尽可能多的浏览器及其版本。　●跨多个客户端操作系统进行测试。　●须要用于登台环境的独自数据库服务器。　●确保在不同网络条件下测试 Web 应用程序，以理解理论的网站渲染工夫和整体外观。　●在地方数据库中保护用户手册、装置指南和其余文档也是为将来需要设置测试环境的要害。　5. 测试脚本和执行　配置测试环境设置后，下一步就是执行测试脚本。测试人员在开发测试脚本之前应该思考以下几点：　●依据我的项目要求创立脚本。　●在整个过程中应用通用的办法。　●确保脚本可重用、简略且结构化，以便任何人都能了解它们。　●执行适当的代码审查和报告以取得更好的见解并在整个过程中放弃品质。　脚本开发实现后，须要牢记以下几点以确保脚本无障碍运行：　●依据测试用例，它们应该包含所有性能方面。　●它们应该涵盖执行测试脚本的所有平台和环境。。　●它们必须批量解决以节省时间和精力。　●要始终练习编写错误报告，以防呈现任何性能谬误。　评估和记录测试后果以供进一步参考，并在 ATLC 的这一部分创立测试后果文档。　6. 测试剖析和报告　它是自动化测试生命周期的最初也是最要害的阶段，只保留数据而不进行剖析并没有帮忙。捕捉所有测试后果后，要执行所有类型的测试，测试团队剖析并辨认有问题的性能。这些报告有助于理解团队是否须要附加程序，并提供无关遇到的不同谬误的信息。筹备一份详尽的报告，并与在此阶段对我的项目至关重要的利益相关者、客户、员工和团队共享。这些报告对于理解 Web 应用程序在不利状况下的行为至关重要。　论断　毫无疑问，软件自动化测试是SDLC 不可或缺的一部分，是实现测试指标的最无效办法之一。但软件测试也有其本人的一组阶段，必须认真遵循这些阶段能力取得这种技术的益处。它容许应用任何可用资源在规定的工夫内实现测试指标。遵循自动化测试生命周期的每一步都有助于获得最佳后果，无需任何人工干预并缩小估算和时间表。精心布局的自动化测试生命周期会带来胜利的自动化测试。 ...

软件测试倒退到今日，曾经逐步标准化且能力更强，其流程每天都在倒退。测试人员的技术熟练程度对于整个测试阶段的胜利来说至关重要。测试不再意味着仅仅发现错误；它的范畴曾经扩充，从任何开发我的项目开始就能够看出它的重要性。 当议论起自动化测试生命周期（Automation Testing Life Cycle）时，大多数人认为这只是 SDLC 的一部分，但它远不止于此。有必要理解自动化测试应该是自动化测试策略的突出局部，并且具备生命周期。企业必须对其进行调整以进步其软件产品的品质。 随着持续推动，须要可能答复以下问题：什么是自动化测试生命周期，以及自动化测试生命周期中的有哪些阶段。 自动化测试生命周期的各个阶段测试的自动化应该失去弱小的测试计划的反对。流程的预约义构造有助于设计测试计划并制订自动化测试工具的抉择策略，从而设置测试环境、设计测试用例并编写脚本。它进一步定义了测试自动化、测试筹备、施行、测试验证和报告的范畴。 自动化测试生命周期中的这六个阶段与软件开发周期并行运行。以下是各阶段： 阶段1：确定自动化测试的范畴阶段2：抉择适合的自动化工具阶段3：定义自动化测试的打算、策略和设计阶段4：设置测试环境阶段5：测试脚本和执行阶段6：测试剖析和报告 1. 确定自动化测试的范畴这是自动化测试生命周期的第一步。在此步骤中，测试团队须要确定自动化测试的可行性。可行性剖析对于每个阶段都是必不可少的，以查看其可操作性，并帮忙测试团队设计测试脚本。本阶段须要思考的事项包含： 应用程序的哪些模块应该自动化，哪些模块不应该自动化。哪些测试用例能够或须要自动化。如何自动化这些测试用例。思考到自动化与测试指标的适应性，抉择哪些自动化工具。估算、施行老本、可用资源和可用技能。测试用例和自动化测试可行性剖析应在开始测试自动化之前进行。 2. 抉择适合的自动化工具这是ATLC最要害的阶段之一，因为自动化测试依赖于工具。要审慎地思考和抉择正确的自动化工具来自动化UI组件。抉择工具可能须要实现另一个档次的剖析。在抉择工具之前，应该始终牢记估算和老本。除此之外，团队还应剖析资源是否具备技术技能，以及工具是否反对我的项目所需的技术。此外，该工具应提供弱小的技术支持，以答复应用中可能存在的疑难。 3.自动化测试的打算、策略和设计这是自动化测试周期中的另一个关键步骤，次要解释实现测试自动化策略的办法。这个阶段的次要步骤是决定应用哪个测试自动化框架。在为项目选择适合的工具时，必须记住软件我的项目所需的技术。因而，对产品进行深入分析十分重要。 在执行自动化测试计划时，测试人员为测试过程创立、测试环境的硬件、软件和网络需要、测试数据先决条件、测试时间表、谬误跟踪机制和工具等建设规范和指南。测试人员还负责决定测试体系结构、测试程序的构造和测试程序治理。 测试管理策略涵盖以下几点： 测试管理工具将捕捉所有手动测试用例。测试人员须要收集手动测试用例并确定哪些须要测试。必须进行彻底的钻研来确定测试框架并理解自动化测试工具的优缺点。此外，测试人员还须要理解工具和应用程序之间的所有相干威逼、背景和依赖关系。团队还必须在测试管理工具中为自动化测试用例构建一个测试套件。未经利益相关者和客户批准，无奈施行或执行制订的测试策略。4. 搭建测试环境在此阶段，测试团队必须设置、跟踪和安顿测试环境。换句话说，这意味着在这个阶段，建设了一个机器/近程环境来执行测试用例。须要虚拟机是因为并非所有用户都应用雷同的机器来拜访 Web 应用程序。因而，咱们须要察看用户应用的各种设施、浏览器和版本。如果未正确验证其在不同设施-浏览器-操作系统组合之间的兼容性，网站成果跟用户看到的可能不一样。为了实现这一点，跨浏览器测试成为首要任务，以确保您的 Web 应用程序按预期提供杰出的用户体验。 此阶段须要具体布局以解决尽可能多的场景并减少测试覆盖率。在测试团队负责任的参加下，必须保护所有环境设置流动的正确跟踪和时间表。除此之外，设置测试环境、安顿网络和硬件资源、执行测试数据库清理、开发测试平台和环境脚本等所有都必须解决。 执行跨浏览器测试并不像听起来那么容易。它波及设置不同的浏览器、不同的版本、不同的设施等，这对团队来说是个不小的累赘。 保护浏览器实验室并不是一件容易的事，因为从头开始建设和保护基础设施老本昂扬，而且并非所有企业都能负担得起。因而，倡议采纳基于云的测试基础设施，为测试人员提供一个平台，以测试虚拟机托管的多个挪动和桌面设施的各种浏览器设施操作系统组合。 以下是测试环境设置的几个方面： 确保有一个能够进行负载测试的前端运行环境，以查看其是否有能力解决高负载的Web流量。有时，设置的测试环境没有提供与生产数据类似的数据，使产品容易受到生产环境中任何代码更改的影响。须要进行测试的所有零碎、模块和应用程序的列表应该进行保护查看。测试尽可能多的浏览器及其版本。跨多个客户端操作系统进行测试。须要用于登台环境的独自数据库服务器。确保在不同网络条件下测试 Web 应用程序，以理解理论的网站渲染工夫和整体外观。在地方数据库中保护用户手册、装置指南和其余文档也是为将来需要设置测试环境的要害。测试脚本和执行配置测试环境设置后，下一步就是执行测试脚本。测试人员在开发测试脚本之前应该思考以下几点：依据我的项目要求创立脚本。在整个过程中应用通用的办法。确保脚本可重用、简略且结构化，以便任何人都能了解它们。执行适当的代码审查和报告以取得更好的见解并在整个过程中放弃品质。脚本开发实现后，须要牢记以下几点以确保脚本无障碍运行： 依据测试用例，它们应该包含所有性能方面。它们应该涵盖执行测试脚本的所有平台和环境。。它们必须批量解决以节省时间和精力。要始终练习编写错误报告，以防呈现任何性能谬误。评估和记录测试后果以供进一步参考，并在 ATLC 的这一部分创立测试后果文档。 6. 测试剖析和报告它是自动化测试生命周期的最初也是最要害的阶段，只保留数据而不进行剖析并没有帮忙。捕捉所有测试后果后，要执行所有类型的测试，测试团队剖析并辨认有问题的性能。这些报告有助于理解团队是否须要附加程序，并提供无关遇到的不同谬误的信息。筹备一份详尽的报告，并与在此阶段对我的项目至关重要的利益相关者、客户、员工和团队共享。这些报告对于理解 Web 应用程序在不利状况下的行为至关重要。 论断毫无疑问，软件自动化测试是SDLC 不可或缺的一部分，是实现测试指标的最无效办法之一。但软件测试也有其本人的一组阶段，必须认真遵循这些阶段能力取得这种技术的益处。它容许应用任何可用资源在规定的工夫内实现测试指标。遵循自动化测试生命周期的每一步都有助于获得最佳后果，无需任何人工干预并缩小估算和时间表。精心布局的自动化测试生命周期会带来胜利的自动化测试。

Testerhome社区爱好者合力编写了《2021接口测试白皮书》，并于往年2月底公布。本文节选自其中的的「平安测试」章节。点击链接可下载完整版《2021接口测试白皮书》。01 前端交互测试前端页面与后端代码之间的交互测试，能够了解为接口功能测试的一个子集。  测试筹备在进行交互测试前，首先要对前端性能有明确的认知，可能明确辨别：  什么性能属于前端页面逻辑性能 什么性能又属于前端与后端交互性能 前端性能与后端是通过什么接口方式进行交互 前、后端，单方有什么样束缚  在这里提到了束缚这个概念，在理论我的项目研发过程中，功能测试阶段所产生 的 bug，有很大一方面是因为前、后端沟通不彻底，需要确认含糊导致。在进入研发前，单方将各自 后续因为 bug 导致的反工工作量。  测试方法 能够应用抓包工具来进行交互层面测试，查看每个交互性能，对应的接口是否正确 （蕴含申请头、申请参数、响应以及其余束缚项），确保前端依照后端的要求正确地进行了调用。 在交互过程中，针对一个接口也会有多个场景，前端会依据不同的入参来调 用不同的场景，依据不同响应后果， 进行响应数据的改写，来取得不同响应，验证不同响应下前端的展现成果。在这里咱们也能够应用一些 不同场景的交互测试。  举荐 Mock 工具：  moco 框架：https://github.com/dreamhead/... easy-mock: https://github.com/easy Metersphere 一站式测试平台上也能够定义 02 后端逻辑测试接口后端逻辑测试仍然遵循“输出—解决—输入”这样的模式。用户输出一串数据，而后让这个接口或者让这个后盾性能来解决，查看输入后果跟冀望是否一 致。 接口测试用例设计应该满足需要文档，且对异样场景进行敌对解决；且测试 这个接口是否装置接口文档进行开发 测试用例设计思路从输出参数进行思考设计1）优先级-针对所有接口  1、裸露给其余零碎、第三方调用的接口2、零碎外部调用的外围性能接口3、零碎外部调用的非核心性能接口 2）优先级-针对单个接口 1、正向测试用例优先，逆向测试用例次之（通常状况下是这样）； 2、是否须要满足前提条件 > 是否携带默认值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限度校验 > 参数数据类型本身的数据范畴值 限度校验。 3）设计剖析  从接口测试后端业务逻辑来讲，设计接口测试用例须要思考以下几方面：  1、是否满足前提条件 有的接口须要首先满足肯定条件，才可胜利获取数据。最常见的就是需 要用户登录信息的接口（用户 token） 逆向用例：设计不满足前置条件的用例。 2、是否携带默认值参数 正向测试用例：存在默认值的参数都不填写、不传参，必填参数都填写正确并且存在正 确的惯例值，这方面思考设计测试用例。 3、业务逻辑、性能需要 这个环节须要依据具体的业务需要，后果接口定义文档，可设计出多条 正向用例和逆向用例。 4、参数是否必填 针对每个必填参数，设计一条或多条参数值为空的逆向测试用例。 5、参数之间是否存在关联 可依据参数之间的互相关联关系设计一条或多条用例。 6、参数数据类型限度 针对每个参数类型设计与定义的类型不符的逆向测试用例。 7、参数本身的数据范畴值限度校验 针对所有参数，设计每个参数在数据范畴内为最大或者最小的正向测试用例； 针对所有参数，设计一条或者多条参数值超过或者小于数据范畴的逆向 测试用例；总结一下，如果以上几个方面思考全面的话，根本可笼罩以下三点： a、主流程测试用例：失常的主流程业务需要校验  b、分支流程测试用例：失常的分支流程需要校验  c、异样流程测试用例：异样业务场景的容错校验 从输入参数进行思考设计1、输入构造是否与接口文档定义的统一  2、输入的各个字段类型是否与接口文档定义的统一  ...

引言与UI相比，接口一旦研发实现，通常变更或重构的频率和幅度绝对较小。因而做接口自动化的性价比更高，通常使用于迭代版本上线前的回归测试中。 手工做接口测试，测试数据和参数都能够由测试人员手动填写和更新。 因而咱们在思考将接口用例实现自动化的时候，次要思路就是在单个接口申请的测试用例曾经实现的前提下，咱们如何解决以下问题： 业务测试场景会调用不止一个接口，下一个接口的申请依赖于上一个接口的数据，须要解决接口依赖问题token等鉴权数据有过期工夫，多个接口用到该参数，须要解决一次批改，多处失效的问题一个接口要用到多个测试数据做笼罩批量测试下，须要晓得某个接口返回的参数/数据是否合乎预期本文应用的自动化接口测试工具为Apifox,官网下载地址：www.apifox.cn间接下载注册装置后即可应用。接下来顺次解说下上述问题如何应用apifox解决。 注释一.接口传参举一个常见的场景阐明。查问接口申请获取数据的时候，须要带一个access_token的参数，而access_token参数须要另外的鉴权接口获取。因而须要鉴权接口将获取到的token参数传递给查问接口，查问接口能力发动申请。 另一个常见的场景是，用户须要先登陆，能力将选中的商品退出购物车。这个接口顺利发动申请依赖于上一个接口获取数据。手动测试的状况下，间接人工复制即可。 解决方案：须要将上一个接口返回的数据进行辨认提取出指标参数，保留为全局变量，下一个接口间接调用参数。 步骤：1）在apifox的接口tab-后置操作tab，抉择提取变量2）填写变量名称，变量类型和提取的表达式。提取表达式合乎json path 语法。在本接口数据中因为返回数据只有一层，因而采纳$.指标参数的形式提取。如果有多层参数，能够点击提取表达式旁边的问号，查看具体的json path语法。 获取到的参数以变量的模式存储，点击接口tab右上角的设置图标，能够查看到获取到的环境变量的值。接着就能够在下一个接口，以参数的形式调用： 二. 内部数据源一些post数据给后盾解决的接口，须要对上传不同的数据来测试接口的返回和异样兼容，一个接口参数须要屡次应用不同的数据。手动状况下咱们能够间接在参数里填数据，之后每次手动改。 但如果实现自动化的话，像上述的测试形式难以实现。罕用的解决方案是先编辑好csv文件，将测试数据一一写好保留，最初传入到接口申请参数中。Apifox在这个问题上提供的解决方案为：a.对于大量的测试数据，可在界面内填好测试数据集供接口每次调用；如果是大量的数据，才应用csv文件；更大量的数据则能够间接写在全局变量中。 以全局变量的形式导入和上节讲到的接口传参相似，区别只在于测试数据不是从上一个接口获取到而是的咱们本人填进去的。若是应用内部测试数据集，在测试治理tab>用例界面右侧，有一个测试数据的开关项，关上即可导入测试数据。当然首先须要先把用例导入到测试步骤中来。 如图所示，我曾经将OCRtest（文本辨认接口，性能为辨认图片上的文字）接口导入用例步骤中，启用了内部测试数据， 接着点击治理测试数据，跳转到测试数据tab：在这个界面开始 新建/导入测试数据。此处数据集名称是给测试人员辨认的，不会传入到接口里，一个数据集（1行）代表该次运行中所有须要传入的测试数据，列名作为接口参数，接口每次发动申请，会顺次调用该列下的其中一个值。 运行时，每一条测试数据都会当成一条测试用例来运行。 在下面讲到的“接口参数传递”和“传入测试数据”两个的思路是一样的，依赖于apifox提供的参数化性能，上传的数据参数以内部数据集的模式与接口分隔开来，将关键字段，一直变动的数据抽取进去独立于单个接口； 配置实现之后，接口每次运行都可能自行生成，传递和导入要害数据，如果须要批改，只须要在一个中央，一个文件内批量批改就可能全局失效。这其中有软件工程中的形象和封装思维，而接下来会讲到的断言是另一种思路。 三. 测试断言手工运行测试人员能够自行看接口申请是否胜利，数据是否失常，但在自动化实际中，咱们则须要代码帮咱们判断理论返回和冀望返回是否匹配。 http响应文本是高度结构化的，因而咱们的冀望返回无非是header和body中的响应状态码，关键字段，和要害值应该为某个值。只须要判断这些字段是否咱们想要的即可。 断言是专门用来验证输入与冀望是否匹配的工具，在测试实际中，咱们个别通过比拟理论输入值和输出值来校验的，即咱们要判断返回数据“是否存在”“是否蕴含”“数据是否等于”“文本是否等于”。 因而判断用例申请后果的实现计划可分为三个因素：判断对象，校验办法，校验值与期待值。 思路明确了，接下来看如何用脚本/性能实现。Apifox的断言性能面板（门路：接口tab>运行>后置操作>断言）的可断言对象包含了响应数据中的JSON，html和xml，header，cookie，基本上能够满足咱们的要求。 校验的办法为断言对象的值是否合乎测试人员规定的值范畴 被校验的值可通过json path 表达式提取 那么像对状态码的判断，某个确定返回值的校验这个，能够间接应用apifox提供的性能面板进行操作就行了。如果测试人员想要更加灵便的断言形式须要在后置操作里抉择自定义脚本。 对于不太熟悉脚本的测试人员，能够应用Apifox右侧提供的代码模板，点击就会增加到左侧的脚本编辑面板里，基本上只须要批改断言的期望值就行了，难度不大。 如果是对单个接口做测试，断言后果会间接在响应tab返回 如果是批量测试，在测试后果里会显示断言后果： 这样咱们构建接口自动化用例中的“后果判断”的问题就解决了。 四. 环境切换接口在测试服测试通过之后还须要一轮线上验证，测试工作才算实现。 通常测试服和正式服的的区别只在于前置URL不同。为了让线上验证环节不消耗太多反复流动，咱们这里能够在自动化我的项目开始构建的时候就先利用apifox提供的性能进行配置。将我的项目里所有接口共用的http协定和域名配置到前置URL中，接口地址只填资源门路和参数。 进行线上验证时，将参数配置和数据配置同步更新/切换为线上数据配置之后，只须要在运行环境里切换环境，就能够进行线上验证。 五. 批量测试1.用例组织模式apifox里，用例是以测试用例--用例组--测试套件的模式组织的。一个测试用例可包容多个测试步骤，一个接口申请为一个步骤。接口用例可间接从接口用例导入。如果设置和接口同步，那么接口一旦变更，测试用例这边也会同步变更。 一个惯例用例步骤如下，波及多个接口，接口之间存在参数传递，多个接口实现一个业务场景的测试。 接口用例导入结束之后，进行测试参数配置，点击运行即可主动运行。 2.用例执行程序 在一条测试用例里，接口申请的程序由上到下顺次执行，如果须要变更接口申请的步骤，只须要拖动接口挪动到新的地位下来即可。 3.测试套件运行一个接口用例实现一个业务场景/一个业务流程的测试，一个测试套件蕴含多条用例，可将雷同模块的用例集中到一起执行。这种用例组织模式和测试人员罕用的用例管理软件testlink的组织形式本质是一样的。这样只有点击运行，就能够一键实现一个业务模块的接口测试。 测试结束后会显示用例测试后果，上方面板为整体执行状况，下方分条列出具体用例执行后果。 如果须要导出测试报告，点击按钮可一键生成html格局的文件。 总结一.接口自动化的工具思维和测试思维 咱们这个接口自动化我的项目的搭建和执行根本都是围绕Apifox提供的性能进行的。和postman相比，用起来的感觉是特地棘手，用例的组织和测试的思维模式基本上也是几个大中厂都在用的，也合乎国内测试组的工作流程，程，是工具来适应人，而不是人去适应工具，在了解门槛和思维切换这点上老本大大降低。 ...

什么是sonic-ios-bridgesonic-ios-bridge（以下简称sib），用于pc与ios通信的工具，以后版本蕴含以下根底性能1、跨平台启动wda2、app列表、装置、卸载、启动3、设施高低线监听4、设施详细信息5、主动挂载开发者镜像Github地址 只有你的ios有wda包，能够应用sib唤起之后，用appium等框架间接连贯对应url，就能实现跨平台（Linux、Win、Mac）自动化，能够不依赖mac和xcode（当然打wda到ios的时候须要xcode，后续跑自动化就不须要了） Sonic为什么思考替换tidevicetidevice是一个十分优良的工具，然而这边如果单因为tidevice让用户部署python环境无疑是微小的节约，以往不少用户部署Agent的时候都是在python环境踩了坑。而go语言打包的可执行二进制文件能够不须要部署额定的环境运行，并且go语言天生的性能与速度都是十分优的。援用网上一篇文章的话 Go 语言的特点表明它具备轻量级线程实现（Goroutine）、智能规范库、弱小的内置安全性，且可应用最简语法进行编程。所以，如果你本人是Sonic平台层面的用户，那么这个新技术带来的成果兴许是不痛不痒，最显著收益是部署时不须要py环境。如果你是python语言为主做iOS自动化，那么还是举荐持续应用tidevice如果你是java或其余语言为主做iOS自动化，那么能够思考应用sib，不要搭建py环境啦~ 尝试本人造轮子过后查找了大量usbmuxd、lockdown的文章，也有参考了tidevice的代码。用本人的形式实现了跨平台与usbmuxd的通信与iOS的lockdown通信，做出了 获取设施详情监听设施高低线设施端口转发，相似iproxy停顿还是挺顺利，接下来搞启动wda 发现宝藏前面着手进行启动wda这最难的性能的时候，testmanager等等一系列恶心人的逻辑让我痛不欲生，启动wda简直围绕了整个iOS协定走了一圈，偶然逛github的时候发现原来有小伙伴用go实现过ios通信了，叫gidevice，也有伴生了cli版。然而因为没有主动挂载开发者镜像的性能，还不能间接接到sonic外面，加上某些数据根底还是要联合sonic业务来开展。于是放弃之前本人做的轮子，间接基于gidevice的根底上，来做一层sonic的cli与辅助扩大 扩大性能如下几点： 1. 获取设施型号的中文名称，如iPhone14,5 -> iPhone 13整顿的映射表次要从apple的wiki爬取下来的 2. 自定义输入json数据格式与格式化格局这个次要用来联合sonic业务做的 3. 主动挂载开发者镜像这里参考了tidevice的做法，在仓库下载对应版本号的开发者镜像并进行挂载操作 func downloadZip(url, version string) error { if versionMap[version] != "" { version = versionMap[version] } _, errT := os.Stat(fmt.Sprintf(".sib/%s.zip", version)) if errT != nil { _, err := os.Stat(".sib") if err != nil { os.MkdirAll(".sib", os.ModePerm) } client := http.Client{ Timeout: DownLoadTimeOut, } res, err := client.Get(fmt.Sprintf("%s/iOSDeviceSupport/raw/master/DeviceSupport/%s.zip", url, version)) if err != nil { return err } defer res.Body.Close() r := bufio.NewReaderSize(res.Body, 32*1024) newFile, err := os.Create(fmt.Sprintf(".sib/%s.zip", version)) w := bufio.NewWriter(newFile) io.Copy(w, r) abs, _ := filepath.Abs(newFile.Name()) errZip := unzip(abs, ".sib", version) if errZip != nil { os.Remove(newFile.Name()) return errZip } } return nil}4. 设施离线后填充对应序列号到对应字段离线后只能拿到deviceID，这个id是连贯时候通过自增定义的，并不是设施的序列号，须要本人做解决 ...

本文作者：程胜聪 - CODING 测试域产品总监在业内热火朝天的 DevOps 转型过程中，自动化测试始终是热点之一，毕竟提供疾速品质反馈是达成 DevOps 指标的要害。于是，作为测试畛域的“皇冠”，自动化测试的落地施行始终为人们所关注。然而落地当中产生了种种问题甚至是争执，经久不衰，无形中给自动化测试体系建设蒙上了层层迷雾，让人纳闷。上面咱们就一些踩过的“坑”进行探讨，冀望这些教训分享可能有助于揭开迷雾、看清方向。 要不要做自动化测试？在软件工程实践当中，测试绝对开发来说是个“辅助”的角色，而软件交付的产物也不用包含测试的产出。随着软件研发过程的复杂度晋升，尽管还是辅助角色，而且其价值依然难以独自掂量，然而测试对品质保障的作用曾经深入人心，以至于从 10 多年前开始，曾经没有人会挑战测试作为研发体系中根本角色的存在了。 然而相似的，作为“辅助的辅助”，测试畛域中的自动化测试又开始面临着同样的质疑：自动化测试到底有没有价值？这个问题在 10 多年前开始被频繁提出，而且难以答复。作为处于辅助位置的投入，人们必定会亲密关注其老本大小以及跟收益的比照。自动化测试最开始呈现，是为了代替重复性的手工操作，从而节约回归测试的人力老本，于是要获取正向收益的前提是执行的次数够多：自动化收益 = 迭代次数 x（手工执行老本 – 用例保护老本）- 用例编写老本 所以，在 DevOps 时代的频繁公布测试场景下，自动化测试的价值失去了充沛展示。要不要做自动化测试的问题现在曾经不会造成困扰，因为当下业内曾经造成了统一的意识：自动化测试是继续测试的根底，是 DevOps 时代中不可或缺的实际。此外，因为自动化测试的执行效率很高，体现进去的工夫老本劣势更是显著，甚至比老本劣势更能戳中这个疾速公布时代的痛点：因为不这样做的话，咱们会越来越难以应答短周期公布所须要的疾速无效验证。 有策略地发展自动化测试测试体系建设须要分层策略指引、接口测试往往最优先罗马不是一天建成的，为了达成自动化的指标，进行自动化测试体系的建设是须要投入资源和人力的。因此在具体落地过程中，咱们须要充分考虑 ROI，来设计符合实际状况的指标达成门路。自动化测试的确有很大价值，但不代表咱们应该无节制地投入到各种类型的自动化测试当中：自动化测试是为了验证既定逻辑是否合乎预期，在需要变更频繁的场景下，自动化代码的保护老本不可小觑。所以咱们须要适合的策略，来指引自动化测试的施行——金字塔模型。 不少人对金字塔模型的第一印象，是其给出在 3 种测试上的投入占比倡议：单元测试最多、接口测试居中、UI 测试起码，比方 70%、20%、10%。但更为重要的是，Mike Cohn 提出了对测试进行分层的理念，以及给出了每个层级的测试优缺点：越靠近用户应用界面的高层次测试，粒度越粗，效率越低，写的测试应该越少；反之越靠近底层代码的测试，粒度越细，效率越高，应该写的更多，也应该执行得更频繁。 而在实际当中，每个企业面临的场景不同，投入状况也不一样。比方现实情况可能并不是金字塔而是纺锤形状的，两头的接口测试占比最高。种种实际表明：在自动化测试建设的初期，接口测试往往是团队发展自动化测试的首选。这是因为接口测试兼备执行效率和体现业务价值两方面的长处，在这个畛域进行资源投入较为容易被技术团队和业务团队独特承受。而且因为接口定义的稳定性也较高，其保护老本也是可控的。所以绝对单元测试和 UI 测试来说，接口测试的投入产出比能够说是最高的。 接口测试以接口定义治理为根底，契约变更的同步揭示和 Mock 是要害接口测试通过调用接口来达成测试验证的指标，既包含零碎与零碎之间的接口，又包含同一零碎外部各个子模块之间的接口。接口测试的重点是查看零碎/模块之间的逻辑依赖关系，以及进行交互的数据传递的准确性。接口测试是黑盒测试的一种，却是最靠近白盒测试的黑盒测试，故而在较早发现缺点和执行效率上也靠近于单元测试，往往被称为“灰盒测试”。 接口测试的用例个别包含单接口用例和基于业务场景把不同接口集成到一起的多接口用例。单接口用例是根底，而且也是开发调试过程所需。业内比拟风行的是用 Swagger 进行接口文档治理，Swagger 预约义了支流编程语言相干的代码注解，能够在接口实现代码变动之后获取接口文档的更新，主动反映接口变更的性能对自动化用例的保护来说十分重要。 多接口用例则是测试人员依据对需要性能的了解所设计进去的，这部分用例就充沛展现了自动化测试的业务价值。因为这部分用例绝对简单，团队会须要为之筹备根底框架，甚至打造脚手架来进步编写效率。在实现上个别会包含接口标准定义、接口间调用的代码治理、测试数据的存储管理、执行调度平台、结构化统计报告这几个局部的能力。于是在业内也呈现了不少在这个畛域的效率工具，比方 Postman、ReadyAPI！、Robot Framework，以及“低代码”的平台 apifox、Eolinker 等。 有了接口的契约定义，就能够对未上线的接口实现 Mock（测试替身或者挡板），这样就能够不必依赖于具体的开发实现而构建场景测试用例，有利于测试开发之间或者不同开发者之间的并行合作。当初搭建 Mock 解决曾经有很成熟的框架，比方 Mockito、EasyMock 等，或者平台型工具 postman、apifox 都可能很不便的搭建 Mock Server。 总的来说，有了能够遵循的接口定义标准、加上接口变更的信息同步、以及提供对接口的 Mock 服务，在团队中就能够基于 API-first 的形式实现并行开发、调试和测试了。 高效编写自动化用例有没有“捷径”可走？现今零碎的性能越来越弱小，也越来越简单，写好自动化测试用例不是简略的事件，这一块也是不可漠视的投入。于是在自动化建设的实际中，咱们自然而然会谋求更高效的办法。谋求高效之路没有问题，只是如何能力防止走歪呢？上面咱们对一些常见的“提效工具”进行探讨，冀望能够对事实的实际起到借鉴作用。 编码方式向左，低代码平台向右？现今零碎的接口往往盘根错节，要做好接口测试，既须要对业务层面的零碎/模块之间的逻辑关系有深刻理解，又须要把握好技术层面的各种测试框架和相干编码技术。能够说，接口测试自动化的建设依然面临着较大挑战，人们天然会寻求高效的形式进行施行，相应的就呈现了对自动化用例低代码平台的需要。于是出于“对测试同学技术能力的事实思考”，研发 Leader 往往会“以负责任的态度”，寻求“入坑”去谋求低代码平台。低代码的概念在近两年如此之火，更是导致这个话题重复被提起。那么咱们在写自动化测试用例的时候，到底应该是遵循老老实实写代码的形式，还是应该大胆采纳低代码平台去疾速晋升覆盖率呢？ ...

1、前言公司的一个后盾管理系统我的项目比拟宏大，模块多，性能多，角色多，每个角色的权限不同，可进入的页面也就不同，页面中的按钮也不同，这样一个零碎如果遇到一次大的降级革新那么就须要投入大量的测试精力去测试每个页面及页面中按钮的权限是否正确，此时Leader就有想法了，能不能用node打造一个自动化测试的工具呢？，于是一个神圣而又艰巨的工作就派给我了。 因为之前没接触过自动化测试，忽然让我用node写这样一个工具，我必定是不晓得从何下手的，于是本能的去Github上搜寻看有没有相似产品，找到了以下这些，但都不满足我的需要： Autoline 国内大牛用Python写的一个工具，他把python的性能转化成了UI，而后咱们在自动化测试工具的治理后盾就能够一步一步增加测试步骤，但它有个致命问题--测试步骤不能调整程序，后面一步错了前面所有的步骤都徒劳Autotest_platform 一款基于 POM 模式开发的 Web UI 自动化测试平台UI Recorder UI Recorder是由阿里开发的一款面向多端的 UI 自动化录制工具，相似于Selenium IDE 但比Selenium IDE 更加弱小! 这个工具属实是弱小，最开始就想用它的，最初发现它还是不能满足我的需要我想要的成果到底是怎么样的呢，请看上面这张Gif图（我靠近3个月的成绩）： 2、技术栈主栈：node.js+puppeteer其余依赖： lowdb 存储测试后果数据log4js 写日志desktop-screenshot 屏幕截图，只在启动浏览器时应用到，用来屏幕的宽高，在关上浏览器时依据屏幕大小设置浏览器大小image-size 获取图片大小，与【desktop-screenshot】联合应用cheerio 用来向测试报告模板的html中插入数据为什么抉择Puppeteer？简略来说就是：因为Puppeteer是Chrome开发团队开发保护的并且基于nodejs的包 Puppeteer的性能： 能够操作鼠标、键盘输入、点击事件等行为能够向页面插入js、css代码能够向页面执行函数（任何页面中js能执行的代码都能够执行）能够拦挡页面中的申请能够截图（只能截取以后页面）3、难题怎么获取页面的数据？ 如用户信息、页面中的列表数据等怎么监听页面跳转了？ 比方正在执行A页面中的测试，忽然认为的跳到B页面去了，此时应该完结A页面的测试怎么判断元素是否存在？怎么操作dom？怎么点击元素？解决了上述问题，接下来就是如何编码的事件了。 4、实现原理待我编写完开发手册后再来编写，嘻嘻... 5、测试报告、日志测试报告（测试报告是用html写的，比word、excel更灵便）： 日志

引子很多敌人始终从事功能测试，想要学习自动化测试。但因为网上的材料大多表面化，内容雷同，短少联合我的项目的实际，看完之后仍对自动化测试较为含糊。鉴于此，在本篇内容中， 先介绍自动化测试人员能力阶梯，目标是让初学者明确成长路线。随后举例一个自动化我的项目，来阐明在面对一个理论业务测试需要时，是如何设计、实现、落地并产生价值的。 一、自动化测试人员能力阶梯根本自动化测试工具利用可能应用相熟的语言，编写简略的测试脚本、应用罕用的自动化测试框架自动化测试模块开发自动化测试框架设计定制零碎业务级自动化计划如上所列，自动化测试人员的能力阶梯分为五个阶段，自上而下能力要求递增，大家依据本人的能力进行对标，可明确本人下一步晋升的方向。 留神：下面内容是我的敌人总结而成，与“业界规范”等标签无关，内容属于阅读者沟通交流领域 二、一个误区以前面试的时候，会问面试者一个问题：您的接口自动化测试是怎么做的？ 有一些答案是这样的：postman呀。 持续问：假如您公司的产品是T3出行，当初有一个测试需要，咱们要求在任何新性能上线之前，咱们的 叫车→ 乘客下单 → 司机应答 → 实现订单 → 订单核算 → 处分发放 ->领取 这一外围业务要齐全自动化回归，这个需要如何通过postman实现？ 答复：把下面波及的几个接口串联起来就行了。 持续问： 1）订单数据是从kafka生产而来，存在漏单状况 2）处分发放为每天定时计算 3）领取接口返回胜利，但仍存在用户未收到的状况 针对上述理论业务场景和实现，如何通过postman实现保障？ 答复：唔～ 读到这里，敌人们应该能了解到我想表白的意思：postman无疑是一款十分便当的接口测试工具，它有肯定的接口串联能力和肯定的断言能力。 暂且不从自动化测试要求的低耦合、高灵便、高保护等几个方面来谈，上述举例的业务流程较理论业务曾经是简化过的，单用postman工具曾经无奈保障。 postman是一款十分便当的接口测试辅助工具，但 postman利用 != 接口自动化测试 心愿打消 工具利用 == 自动化测试，这一个误区。 三、实际我始终感觉最好的学习形式，就是实际。当初拿我以前做过的一个我的项目，以 业务背景 -> 测试痛点 -> 解决抓手 -> 计划选取 -> 方案设计 -> 我的项目实现 -> 我的项目落地和产生业务价值 这一思路来给大家举例。 1、业务背景广告投放是营销业务的伎俩。广告投放的曝光渠道流量最大的app是微信、抖音、今日头条等等。投放频率在顶峰周期会打高一周三次。 这代表着，测试人员如果要保障投放成果，须要在每次上新之前测试 var 次 ，var = 数个投放渠道 乘以 数个手机品牌 乘以 每个品牌不同手机型号 靠人工来测试var次，无疑是低效的。对测试人员来说，这种反复的、大量的、机械的测试是很头痛的（我个人感觉是很苦楚的） 这时候，大家天然会说：这用市面上的一些UI自动化测试工具，不就能够解决吗？ 上面要介绍的痛点就在这个疑难中。 2、测试痛点在说痛点之前，先简略谈一下UI自动化测试工具的底层实现原理，获取页面元素坐标、path -> 模仿用户点击元素 -> 判断断言 -> 生成后果 ...

古代软件工程和麻利开发强调拥抱变动，除了对软件系统设计和实现的高质量要求之外，继续集成(Continous Integration)也成为高质量交付的重要一环，这对于包含测试工程师在内的开发团队而言极具挑战性。本文将分享测试工程师如何拥抱将来，与时俱进，继续晋升自我涵养。PART 01 测试工程师面临的新挑战麻利开发概念从提出到当初曾经有二十年左右的历史了，它的外围是“疾速响应，继续交付价值”。软件开发过程十分强调人的重要性，开发团队要能做到团结合作。人与人的交换、沟通要面对面，而非制订具体的文档，按预约的打算逐个进行开发、测试。变动是麻利开发过程中惟一的不变。 开发疾速提交可测试的代码，也必然要求测试可疾速地验证提交代码的可用性及稳定性，简略的手工测试曾经无奈满足需要了。 在麻利初始，测试开发阶段环境的保护部署根本是QA或开发自行实现的，这些工作也根本都是手动去操作的。同时，每个Scrum团队所偏重的点不同，因此容易疏忽其余服务，导致测试环境与线上运行环境有些许的差别，上线后就可能存在兼容性或完整性的问题。 在整个开发及测试阶段，咱们要不停地反复一些工作，如批改bug、部署新包、验证bug、记录新bug等，全线环境也要放弃同步的批改部署。由人手动去部署环境可能会破费比拟多的工夫，也可能会因为人为操作失误引起不必要的问题，造成整个团队无奈进行工作而影响我的项目周期。 咱们面临的问题是：1、跨域跨部门单干，而不只面对面；2、如何提高效率，做到疾速交付；3、如何升高人的干涉升高出错的可能性。 PART 02 DevOps的利用咱们认为，DevOps可解决如上问题。 什么是DevOps？维基百科给出的定义是：DevOps（Development和Operations的组合词）是一种器重“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通单干的文化、静止或常规。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、公布软件可能更加地快捷、频繁和牢靠。 DevOps外表上是开发与运维的联合，理论它是一个过程、办法与零碎的统称。 DevOps过程周期： 现实的DevOps周期开始于：1、开发编写代码；2、自动化编译出包并主动部署到测试环境；3、执行自动化测试用例并公布；4、自动化部署到产线环境。 很显然，DevOps过程中十分强调构建、部署和测试的自动化，在DevOps周期中应用继续集成工具、自动化测试工具。 在DevOps中测试角色也会发生变化： 传统模式下，测试人员的次要工作是执行他们的性能及回归测试。在测试人员正式验收结束测试包前，构建人员个别会跟测试人员坐在一起工作一段时间，在DevOps中这将会产生扭转： 1、由原来的手工测试转为自动化测试，要尽量将所有的用例都自动化，并可达到100%代码笼罩；2、要确保测试环境与产线环境统一，并可自动化部署；3、测试前工作，清理工作及测试后工作都已自动化并可调配到继续集成的过程中。 DevOps中须要高度的合作，各个角色职责边界也变得含糊，激励每个人作出本人的奉献，开发人员能够配置部署工作，部署人员能够增加测试用例到QA的用例库中，测试人员能够配置批改DevOps链路中的用例。 当初及将来对测试人员的要求会越来越高，简略的黑盒测试将无奈达到冀望。 DevOps是将来，而自动化是DevOps胜利的外围。作为一名测试人员要把自动化作为职业倒退的重要方向，专项常识加上自动化技能才能够更好地服务于产品的疾速迭代。 PART 03 自动化测试实际从下面的剖析咱们能够看出自动化测试在整个产品周期中起的作用，那么咱们应该如何发展？ 自动化测试金字塔 从图能够看出，除了单元测试外，API级的自动化测试能够达到比拟高的测试覆盖率。所以咱们从API测试自动化动手，一是利用它咱们能够实现场景用例，更靠近用户的应用；二是绝对UI自动化测试，它更稳固。拍乐云的测试工程师开发了一套API自动化测试框架，咱们用该框架做如下自动化的开发： 1、性能用例自动化2、模仿用户调用接口习惯3、性能测试4、品质测试 拍乐云API自动化框架 拍乐云是为用户提供实时音视频服务的，咱们志在为用户提供易用、高质量的产品。咱们不局限用户调用接口的形式，用户可按本人的习惯及了解去应用服务，这对产品的鲁棒性要求就更高。 咱们的测试工程师基于对外API层来做自动化测试，通过理解产品接口就模仿用户应用习惯方面设计接口测试用例，次要从如下几个方面思考： 1、变动接口参数2、变动接口调用程序3、变动接口调用条件 自动化的目标之一是节俭人力老本，利用接口测试来做性能用例的自动化也是这个目标。在这个场景下，咱们次要侧重于回归测试用例。随着性能的减少，回归的老本会越来越高。故性能回归集也会随着性能的减少一直的扩充。咱们把回归用例集分为两局部： 1、根底用例，保障基本功能2、具体用例集，包含更多的性能逻辑 这两局部各有不同的作用，根底用例用于构建pipeline，验证新代码是否影响基本功能的应用，这样既不脱漏性能，又可减轻pipeline的负载。具体用例集用于验证更简单的用户应用场景，次要利用于测试环境的功能测试，以达到肯定的覆盖率，进一步保障性能的可用性。 在咱们的日常公布中，会有肯定的性能测试，如媒体服务器的并发能力，音视频在特定设施上的性能体现等。性能数据是产品稳定性的体现。性能测试的重点在于场景定义,在场景肯定的状况，确定性能瓶颈。如一个Media Server能够反对多大规模的大会；肯定配置的MediaServer能够同时开多少个六人会议，这六人中一人发送一路720p及接管5x180p ，其他人都发送1路180p接管1路720p+4路180p等，咱们会依据本人的需要获取相干场景的性能数据作为基准，也会依据少数用户理论应用场景或用户需要来定义性能场景。 六人会议一人发送720p+接管5路180p，其余五人发送180p接管1x720p+4x180p 媒体服务性能指标咱们会关注CPU、Memory及网络吞吐量。 还有端的性能，这个数据除了跟场景相干外还和设施自身的配置无关，如雷同场景iPhoneX与iPhone13 Pro的体现必定不同，iPhone13 Pro 能够稳固并长时间编码720px30f及解码1路720px30f，而iPhoneX雷同的场景可能继续不了1小时甚至更短就会呈现编码降帧率或分辨率的状况。故设施上的性能咱们除了关注CPU、Memory的应用外，还会关注设施上所能反对相应视频规格的时长，当然还有耗电状况等。 通过性能用例，模仿用户调用场景，性能及品质测试的自动化，咱们能够达到大概50%的覆盖率。除了接口自动化，咱们还利用了UI自动化，次要利用到咱们对外app的产品状态上。 API级自动化测试将是咱们自动化的重点，咱们会持续晋升它的作用，将来咱们会增强如下工作： 1、及时增加接口用例，咱们心愿能够做到Test Driven Development；2、攻克难点性能，如白板，因为白板会波及到交互操作性能，故导致咱们目前有些自动化无奈全副实现；3、联合接口自动化实现品质测试的自动化。

有人说：“横七竖八的自动化只会带来更快的凌乱。”不仅更快，而且是更重大、更大的凌乱。如果应用切当，自动化能够成为测试团队中令人惊叹的生产力助推器和零碎的品质增强器。自动化测试的要害是要正确使用，这是初始最艰难的局部。上面，咱们会理解最常见的自动化测试挑战以及应答措施。 挑战 1：取得管理层的批准跟任何公司部门一样，员工总要晓得估算容许和不容许的货色。测试人员可能曾经晓得自动化在商业和技术两方面的劣势（缩短上市工夫、减少测试覆盖度和准确性、升高每小时的测试老本、更快发现错误等），然而测试人员怎么压服财务部门和软件开发负责人，为自动化测试争取必要的工夫和资金？ “自动化测试能进步生产力和准确性，这是必须制订商业案例的中央。单个缺点的老本……能够对消一个或多个工具受权的价格。” ——Randall Rice 咱们批准 Randall Rice 的观点，即自动化能够发出老本。为了向管理层证实财务收益是可观的，能够向他们展现对自动化测试投资回报率所做的简略细分。对其他人、其余利益相关者坦诚公开也很重要，不要瞒哄自动化前期工作和资源需要大的事实。 挑战 2：抉择并应用适合的工具因为种种原因，许多团队没能胜利通过这个阶段。他们可能是不理解特定工具的专业知识、找不到现实工具、工具集笼罩不够广等等。如果在怎么应用工具这方面没有足够基础知识，能够有以下几个抉择： 加入在线课程让工具的制造者来进行培训延聘参谋以更好把握外包如果现有的工具不能满足你的需要，那就思考找一个多工具的解决方案。 记住，不可能齐全测试所有内容，但能够应用工具去测试最重要的局部。 最初，如果工具破费超出预算，就疾速进行老本与收益剖析并展现进去。这样能够掂量之前谬误造成的损失，并能展示如果应用该工具能够省下多少工夫和金钱。 挑战 3：确定启动策略好的，当初曾经领有了能够开始自动化的所有工具及反对，然而到底把什么货色自动化了？又是怎么做的？这些工具自身并没有通知你要自动化什么，就像老手父母发现他们的小孩没有带着育儿手册诞生一样叫人丧气不安。是会造就出一代优良的自动化测试，还是会被它所毁坏再无奈治理？当然了，咱们必定心愿是前者！但实际上基本没有方法把所有事件都自动化，所以必须具备战略眼光。能够应用两种办法来帮忙解决此问题：基于危险的测试和自动化金字塔。 基于危险的自动化测试它优先测试最有失败危险的元件，如果产生所述失败，这些元件也会带来最大的负面结果。在此处须要思考： 潜在谬误的经济影响失败的概率服务级别协定 (SLA)有无财产危险这应该为你提供了一个好办法来确定自动化测试用例的优先级别。 自动化测试金字塔强烈推荐的另一种办法是遵循自动化金字塔。在最近的一篇文章中，对这个主题有了更宽泛的探讨，这里进行简略概述。 冰淇淋蛋筒尝起来甘甜迷人，但采纳冰淇淋蛋筒办法可能会毁坏自动化的过程！遵循冰淇淋蛋筒办法将导致高度的错误率，因为它强调 UI 级别的自动化，而UI级别应用的是更易被毁坏的测试。但如果把精力投入于自动化单元测试，那么在软件开发过程中，简直能够马上发现错误、打消谬误。 挑战 4：设定对自动化的事实冀望无论你的工具和流程如许杰出，要记住测试永远不会实现。自动化测试不是解决漏洞百出的零碎的灵丹妙药，不应该代替非自动化测试，而该当与非自动化测试联合应用。有一些测试根本无法自动化，但也有一些自动化测试能够发现其余办法无奈发现的谬误。 自动化测试实际上只是主动查看零碎，而依然须要人工进行非自动化测试。此外，请记住，测试的价值来自它提供的信息，而不是执行的测试数量或频率。咱们最关怀的取得正确信息，以便在进步零碎品质时做出最佳决策。 确保团队和管理层批准并了解自动化计划的预期后果，这样大家能力达成共识！

通过上篇文章，能够意识到自动化的重要性和劣势，必须确定能够自动化的用例。为此，必须思考所谋求的指标，以及这个指标在测试金字塔中处于什么档次。 尝试答复以下问题： 指标是什么？须要确认的第一件事是始终以更高水平的软件品质为指标，并剖析自动化是否适宜我的项目。要答复这个问题，倡议对指标进行可行性剖析。以下是最有可能实现自动化的一些场景： 有技术债权须要打消；回归测试十分耗时；该我的项目非常复杂且长期。应该自动化哪些测试用例？并不是所有的事件都能够在上下文中自动化，这就是理解哪些案例合乎咱们的目标的相干起因。从代码级别和开发人员方面思考，单元测试是最容易编写脚本的。在测试人员方面，咱们通常致力于在 UI 和 API 级别自动化回归案例，首先思考最要害和最简单的流程。以下是可自动化的测试用例： 回归测试鉴于咱们曾经有了一个必须在每次产品公布后定期执行测试套件，手动运行这些套件的工作变得反复，此外还须要从其余不可自动化的工作中抽出工夫，能够在这些工作中取得更多价值。这些回归测试用例高度自动化，特地便于集成到CI/CD模型中。这减少了执行其余工作所需的老本和工夫，因为在执行其余流动时，脚本能够在无人参加的状况下执行。 高风险测试这些案例通常由利益相关者约定，重点放在查看高优先级和要害性能上，如果它们失败，将极大地影响商业模式。这就是为什么这种办法被称为“基于危险的测试”。自动化测试这些性能的案例有助于在每次公布后立刻发现可能阻止公布、或必须迅速解决的风险性事件。 简单或耗时的测试在一个我的项目中，可能会有一些简单的状况须要手动复制，所以如果咱们将其转换为脚本，那么以自动化的形式执行它们会更容易。如果是一个蕴含大量数据的表单，那么测试人员可能更容易出错，尤其是当必须应用多种数据变体测试同一表单时。这时就能够通过自动化来升高出错的概率。 反复测试用例正如回归测试成为一项重复性工作一样，在某些一些非凡状况下，能够不便地实现自动化。例如，手动测试同一流程的大量数据，须要破费大量的工夫，必须反复测试则让过程更加乏味。然而，通过自动化这个流程，咱们能够参数化这些数据，而无需手动测试每个值。这也被称为数据驱动测试，其中自动化测试被参数化，并从数据源（如文件或数据库）获取数据。 工具抉择既然咱们晓得了要自动化什么，咱们就能够持续抉择要应用的工具了。在给定可用工具数量的状况下，该流动可能是最简单的剖析之一，该决策将不得不思考波及的我的项目、估算、常识和教训。有几种开源、商业和定制工具，它们的局限性和可用性各不相同。要抉择正确的工具，你必须分明必须满足哪些要求能力持续对其应用进行老本效益剖析。 以下是一些测试自动化工具的简要概述： Selenium：一种开源工具，在世界范畴内被宽泛承受，用于在不同浏览器战争台上测试 Web 应用程序。Appium：另一个开源框架（基于 Selenium），次要用在 iOS 和 Android 的挪动设施上实现测试自动化。Cucumber：这个工具是 BDD（行为驱动开发）办法的一部分。Cucumber 的次要长处是它的易用性，因为它十分直观，提供了宽泛的性能，而且还是开源的。ZTF：Zentao Testing Framework，是一款开源自动化测试治理框架，聚焦于自动化测试的治理性能，能够解决用例信息管理、测试脚本执行、测试后果比对、缺点Bug提交等问题。ZenData：ZenData是一款使用方便的通用数据生成工具，次要领有两大性能：数据生成和数据解析。反对一键生成海量数据用于性能和压力测试，实用于大规模、工程化的自动化测试。须要留神的是，没有实用于所有状况的最佳工具。依据被测应用程序和决策制定规范，能够更灵便地在不同软件之间进行抉择。

10 月 22 日，2021 届 DevOps 国内峰会在北京顺利召开，来自国内外的顶级技术专家独特畅谈 DevOps 体系与办法、过程与实际、工具与技术。CODING 测试及研发流程治理产品总监程胜聪（Diego）在大会现场承受了 CCTV《态度》栏目组的专访，也在 DevOps 最佳实际及解决方案专场为大家分享了他的主题——DevOps 时代的高效测试之路。 测试正在成为继续交付的最大瓶颈业界对于测试的焦虑由来已久。从 2017 年开始，行业开始对测试窘境造成共识，即测试不够快成为导致交付延期的次要起因。之后，行业开始强调自动化测试，提出打造疾速反馈环、流水线工作流和工程文化等理念。 在这种背景之下，Diego 认为，继续测试是 DevOps 时代的高效测试之钥。测试作为一项根底的、继续的流动，理当贯通于整个软件交付周期之中。继续测试扭转的是传统测试后置的工作模式，让测试流动延长到 SDLC 的每个阶段。 高效测试须要以自动化为实际基石从一项对于测试工夫破费的调研中能够得悉，测试执行占了总工夫的四成。因而如果要晋升整体测试效率，首要的就是通过自动化来晋升测试执行的效率。然而，测试团队发现即便在 CI 中配置好自动化代码库，因为待执行的用例汇合是固定的，随着自动化测试覆盖率晋升、自动化代码越来越多，运行工夫越来越长，于是运行频率却越来越低，成果并不如人意。 Diego 指出，只是默默地写自动化代码是不够的，自动化测试须要"更聪慧地执行"。如果可能人工地将需要（Req）、用例（Case）以及自动化函数（Func）关联在一起，灵便确定测试子集会让测试变得更加自在。如果某个自动化函数运行失败，则能够迅速定位到某个有问题的需要，团队再依据问题的优先级和影响，来断定是否可能持续公布。 新的时代，新的流程在新的时代，提倡新的流程。继续测试并不仅仅只是自动化测试、还有对流程的全局优化，这须要咱们从单点（执行）效率的晋升延长到全局效率的晋升。工具/技术改良过程效率（efficiency），而流程会指向正确的后果（effectiveness）。 那么，DevOps 时代须要什么样的测试流程？ 首先，Diego 认为麻利宣言的四个“高于”清晰的指出了研发应该关注于为用户带来价值的行为和后果，而不是过程中的产物。 然而只管合作很重要，却不意味着流程、文档、打算不重要。只有软件的复杂度还在，有助于软件顺利交付的流程、文档、打算都是必要的。只是须要相应变动、与时俱进——转为轻流程、简洁文档、尽早打算，或“演进式”的流程/文档/打算。 DevOps 须要更轻，更强调角色合作的流程。测试团队首先须要围绕需要发展测试，策略性定义子集，并且确定基于危险的测试策略。其次，团队须要推动测试左移，让测试与开发并行工作。在这个阶段，须要实现的工作包含单元测试、测试评审、代码扫描，以及基于接口定义的开发和自动化测试。最初，还须要实际测试右移，让“测试永不退出”—— 在部署之后，还须要进行线上的实时监控，保障问题失去疾速发现和解决。 此外，DevOps 还须要强壮的标准和疾速的反馈。Diego 认为：研发“一致性”是效力晋升的根底，标准可能升高合作中的人为产生的主观复杂度、防止不必要的上下文了解。而疾速反馈不仅仅是缩小手工操作的“劳力破费”、更重要的是缩小成员的“心力损耗”，让成员能够专一于本人的工作，不必要在不同平台之间来回切换。软件开发的艺术成分应该被关进笼子里，而在软件开发中并不需要艺术的局部，例如机械的判断抉择、和协同所需操作，应趋向于科学化和量化。 腾讯云外部落地实际的分享最初，Diego 向现场观众分享了腾讯云 CODING 团队外部的落地实际，展示研发一体化的高效测试是如果实现的。 在研发过程中，存在各种各样的流动。研发团队中的不同角色，如产品、开发、测试以及运维个别都只关注本人所负责的流动，而后不同角色流动之间也存在关联，合作产生的流动便造成一个残缺的工作流。在此基础之上，退出准入准出标准能够让合作更加强壮，而主动操作则让流动更加高效。CODING 正是基于这样的逻辑，来为研发流程的高效治理设计出 CODING Compass 这一产品。 然而，DevOps 不应该只是研发团队自嗨的畛域，咱们还须要跟业务价值连接起来。通过把研发流动映射到业务人员所相熟的阶段：打算、开发、测试、部署，并且放弃对 Lead Time（前置工夫）、Process Time（解决工夫）、% of Completeness &Accuracy（实现&精确百分比） 等指标的关注和继续改良，造成价值流治理。 接下来，Diego 向大家介绍了腾讯云 CODING 团队是如何将测试流动嵌入其中的。 首先，迭代布局阶段会围绕着需要发展测试，策略性的定义测试子集。测试与开发严密合作，同时认领同一需要工作。而当迭代 Backlog 确定下来之后，也就示意测试范畴定下来了，测试计划就能够创立，而需要的验收规范也就能够间接转换为性能点用例。 ...

测试覆盖率是什么？测试覆盖率（test coverage）是2018年颁布的计算机科学技术名词，它是测试品质的度量规范之一，通知咱们测试了多少代码。它定义了零碎的某些实体，目标是用测试笼罩它们。这是一种用来批示咱们什么时候进行了充沛的测试，并通知咱们还须要测试什么（从而扩充了覆盖范围）的办法。 如果把测试比喻为清扫房子，那些不罕用的房间总会被脱漏，咱们总会遗记诸如次卧卫生间这样的区域，所以清扫的覆盖范围不包含就那个卫生间。 设想一下，如果咱们的清扫规范只包含清扫卧室。依照这个规范，如果清扫了所有的卧室，就意味着整个房子都是洁净的吗？ 并非如此，因为咱们齐全疏忽了厨房、餐厅、卫生间等房子内的其余局部！因而，务必要粗疏精准地度量测试覆盖率。具备肯定水平的覆盖率是测试品质的一项指标，但它从来不是零碎品质的指标，也不能保障所有内容都通过测试。测试覆盖率通知咱们测试代码的百分比，但这并不意味着它在每种状况下都被测试过。 测试覆盖率有什么劣势？仍然是以清扫屋宇为例，测试覆盖率能够：● 度量清扫的品质；● 批示何时该进行清扫；● 揭示咱们还有其余中央须要清理。 某些规范可能比其余规范更弱小。理解它们能够让咱们晓得测试的深度以及何时利用某个或其余规范。例如，如果涵盖规范A的任何测试用例集TS也涵盖规范B，则能够说规范A包含另一个规范B。 依照上述准则，清洁屋宇就能够遵循以下规范： 清扫每个卧室；清扫房子的每一部分（包含卧室、厨房、卫生间等）；清扫每一个小中央，甚至是角落，因为它们很可能会积累灰尘。不言而喻，规范3包含2，而2又包含1，关系是传递的，即3包含1。如果咱们为规范3设计一个测试用例，它也应该包含前两个规范。对于测试软件，规范通常包含程序中的各种门路、条件、语句、函数等。 另一个实在的例子可能是等价类划分，先划分若干个等价类，而后从每个局部中选取具备代表性的数据当做测试用例进行正当的分类，这样就笼罩了所有类。如果思考白盒测试，又有语句覆盖率、分支覆盖率、门路覆盖率等，特地是对于状态机，咱们有批示笼罩所有节点、所有转换等的规范。 自动化测试如何实用？当初就能够设想一下扔掉扫帚，换成一个超高速的扫地机器人。它能够解放双手、更快地清理地板、缩小被脱漏的区域，还能够让本人在工作中专一于更重要的事件。 至此，咱们能够得出结论：测试自动化=更高的测试覆盖率。

咱们相熟的规范HTML输出控件包含input,select,textarea等；比方通过扭转input的value属性值，就可输出内容到文本输入框中。有些网页表单为了实现非凡的成果和性能，能够不应用这些控件，通过客户端脚本生成非凡的输出形式。手工填表不受影响，如果主动填表就须要应用非凡的形式。非标准下拉列表框填写示例.png (102.22 KB, 下载次数: 0) 办法一：手工填表后，察看源码变动，发现填写的内容呈现在<span>a5</span>元素中。那么咱们填表的思路就是间接批改这个元素的值。获取span元素，“填写”它的text文本内容为a3，能够看到网页也对应的发生变化。但提交表单时，如果是非input元素，可能无奈提交填写的值，需进一步测试。 计划二：应用主动点击操作，齐全跟人工填表步骤一样，先点击下拉箭头，期待0.1秒，而后在选项中点击对就的选项元素。简直所有下拉列表控件都能够用这种办法填写。

本文作者：程胜聪 - CODING 产品经理继续测试带来的改革继续测试（或者麻利测试）要求测试作为根底流动贯通于软件交付的整个过程中。相比起在 DevOps 时代陷入困境的传统测试模式，继续测试首要扭转的是“测试后置“的情况，强调测试前置，通过尽早定义测试、测试与开发并行、在过程中放弃严密合作，从而实现疾速反馈业务危险的目标。继续测试的实际改革是对于人、流程和技术的全面工程：既须要技术上的撑持，比方继续集成、继续部署的根底能力，也须要人员自动化代码能力的晋升，同时对流程的改良也是其中不可或缺的一环。 正如麻利宣言开篇提出的四个外围价值，团队应该聚焦在为客户带来价值的行为和后果、而不是传统的循序渐进实现既定我的项目的事项和生产过程交付物，这对测试的要求也是一样： 个体和互动高于流程和工具；工作的软件高于详尽的文档；客户单干高于合同会谈；响应变动高于遵循打算。然而，对于上述宣言中的“四个高于”字面上的了解，大家往往容易产生困惑：合作很重要，那么是不是流程、文档、打算就不再须要了呢？其实不然，毕竟软件的外在复杂度还在，那么为了更好地交付软件而进行的打算和文档阐明就依然有着重要的价值。只不过咱们须要扭转原来过于臃肿的流程、文档、打算，让其不再成为团队疾速响应指标的解放。所以，“轻流程”、“适合粒度”、“尽早打算”才是咱们应该作出的适当的扭转。如果说自动化测试和精准测试是在测试执行这个单点上对效率的晋升，那么迭代内测试则是在整体流程上的对测试效率进行晋升。 如何实际迭代内的继续测试测试过程个别包含打算、设计用例、执行这几个环节，下图就是在麻利模式的迭代中的测试视角的经典工作流。让咱们从麻利模式下测试视角的经典工作流登程，探讨一下如何在一个迭代中实际继续测试。 基于上述场景，咱们能够依据如下步骤发展测试流动，达成与开发的工作同步、拓宽测试工夫窗口的指标： 首先，在迭代布局会上，产品经理就需要故事与团队一起进行解读、剖析和工作量评估。在工作认领时，开发和测试（或者充当此角色的另外的开发）结对负责某一个需要故事。当迭代布局实现时，其实就能够创立迭代对应的测试计划，打算内应该包含迭代故事列表以及相应的验收规范（Acceptance Criteria，简称 AC）。 而后，在迭代过程中，应该以代表业务价值的需要故事作为一个整体进行交付。也就是说，结对的开发和测试应该以同样优先级解决某一个需要故事，尽可能快地实现故事的端到端交付后，再解决下一需要故事。因而在开发实现编码的同时，测试也应该同步编写该故事的测试用例——少数状况下是对 AC 进行细节性的开展和编写补充残缺。当用例编写结束后及时进行评审，甚至在接口契约失去保障的状况下实现接口自动化测试的编码。这样每个故事都是开发实现后马上测试通过，处于可交付的状态。 最初，在迭代实现后，甚至能够执行一遍笼罩了以后迭代的需要故事所对应的测试用例集，根据测试报告反映的整体测试状况进行回顾，以待继续改良。 CODING 如何助力实际迭代内的继续测试基于上文提及的场景，CODING 以【测试计划为测试流动的主体】为理念，设计并打磨产品，力求给用户带来“沉迷式”的测试体验。接下来将演示如何在 CODING 测试治理中发展一个残缺迭代的测试流动： 迭代布局会上：首先，从我的项目协同中布局好的迭代开始，查看/创立团队的测试计划、并关联对应迭代。 而后在团队测试计划创立实现后，打算中会展现迭代的需要故事。接着为需要故事创立相应的性能用例，内容上可能只是带上布局会中达成统一的验收规范（AC），把相干的用例任务分配给对应的测试同学，就造成了一个测试团队视角的迭代看板。这些操作齐全能够在布局会上或会后的短时间内实现，测试计划包含了迭代故事列表以及相应的 AC 作为内容的用例，暂且称之为“测试计划 alpha 版”。 迭代进行中：开发同学实现编码的同时，测试同学同步编写该故事的测试用例，用例逐渐补充残缺的测试计划能够称为“测试计划 beta 版”。当用例编写结束之后及时进行评审，甚至在接口契约失去保障的状况下实现接口自动化测试的编码。这样的节奏也就实现了测试与开发的工作同步。 需要故事提测后，执行测试用例，对照用例步骤验证性能是否失常。在这样“小步快走”的模式下，迭代在任何时候完结都能够交付有业务价值的需要故事，而不是一批“半成品”。如此通过开发测试的严密协同工作，逐渐靠近体现业务价值的继续交付。 公布的时候：在迭代最初需要故事都实现后，咱们就能够取得蕴含残缺测试用例内容的“测试计划正式版”。由此生成测试报告，依据通过率和报告反映进去的危险来判断是否能够公布到下一个环境（如 STG）。 总结CODING 迭代视角的测试工作流的核心理念是疏导测试的前置，在过程中加强了测试与其余角色的合作和反馈。目标是通过产品能力来帮忙团队固化良好实际，从而实现高效的测试： 首先，尽早布局了测试。从需要布局会开始，在充沛了解需要并认领工作之后，咱们就能够圈定测试范畴，并由此产生简略版本的测试计划、并疾速制订验收规范和实现初步用例的编写。 其次，通过建设需要和用例的关系，对高优先级（业务价值）的需要所需测试做到高深莫测，为基于危险的测试策略（Risk-based Testing）打下基础。 再次，迭代进行过程中实现测试和开发工作的并行发展。在开发工程师进行业务代码实现的同时，测试工程师能够对测试用例作进一步细化补充残缺，甚至实现测试的自动化代码实现。通过严密协同、“小步快走”，每次交付的都是残缺业务价值的“成品”。 最初，测试过程中的操作以及产生的数据并记录下来，可能疾速的反馈给团队，而这些积淀下来的数据，将成为工程实际继续改良的指引。

本文作者：程胜聪 - CODING 产品经理自动化测试是继续测试的根底在 DevOps 的高频交付场景下，团队容易陷入在速度和品质之间“二选一”的窘境：为了拥抱需要变更，采纳较短的交付周期，而后变更频繁导致问题变多，于是开发提测提早，最初导致测试工夫被压缩、难以进行充沛的测试。面对这样的状况，团队该如何晋升测试的执行效率呢？大家第一个会想到的应该就是自动化测试——通过自动化测试来代替重复性的手工测试，执行更快从而节俭测试工夫。此外，因为自动化每次执行工夫绝对固定，而且程序预设的测试行为带来了高一致性，让测试的稳定性和可重复性达到很高的规范，可能很好的实现“疾速重现软件缺陷”的指标。 如果说在测试工夫绝对短缺的传统瀑布模式下，针对回归测试场景而投入的自动化测试所体现的最大价值是在节约人力老本方面，那么在麻利和 DevOps 时代，自动化测试的更大价值则体现在频繁验证并且提供疾速反馈方面。能够说继续测试实际的根底就是自动化测试，只有自动化水平足够高，才可能满足继续交付的高频发版需要。 自动化测试策略自动化测试有很重要的价值，但不示意咱们应该无限度投入到各种类型的自动化测试当中。自动化测试是为了验证既定逻辑是否合乎预期，在需要变更频繁的场景下，自动化代码的保护老本微小。所以，咱们须要适合的策略来指引自动化的实现——金字塔模型。 出自《The Test Automation Pyramid: Your essential guide for test automation》 自动化测试金字塔最早由 Mike Cohn 于 2009 年在《Succeeding with Agile: Software Development using Scrum》中提出，过后从上到下的三层别离是 UI、Service 和 Unit。之后随着麻利测试实际的落地，业内逐步造成的认知是从上到下别离为用户界面测试（UI Tests）、接口集成测试（API Tests）、单元测试（Unit Tests），再加上顶部的手动探索性测试，进一步丰盛为测试金字塔（包含自动化和手工）。这个上窄下宽的三角形为咱们在各层的自动化投入提供了形象的指引：底层的单元测试最多，接口测试居中，UI 测试起码。 如金字塔模型所示，上层的单元测试/接口测试比起下层的 UI 测试长处有：因为更靠近生产代码所以更容易编写并定位到代码的缺点；因为测试对象的粒度更小、依赖更少，所以执行效率更高；因为测试对象更加稳固所以保护的老本更低等等，当然越靠近下层的测试的长处就在于，因为更加反映业务需要，所以更容易让人看到测试的价值。那么在 DevOps 时代，基于对速度和品质的均衡，中间层的接口集成测试因为既能放弃绝对低的保护老本，又能兼具反映业务逻辑的价值，应该成为咱们重点投入的局部，尤其是在自动化各方面还处于初级阶段的时候。 测试金字塔发祥于麻利实际，以之作为参考对咱们的自动化测试投入进行继续的调整，团队的测试用例和执行情况就会逐步形成良好的均衡。 精准测试的价值尽管从近几年行业的调查报告能够看出，随着对 DevOps 的认可，企业对自动化测试的投入在继续晋升，带来的间接后果就是自动化测试的代码越来越多。然而有了数量疾速减少的自动化代码，自动化就能达到咱们预期的成果吗？ 从事实成果来看，企业并没有因为自动化测试覆盖率的晋升而取得预期中的价值，因为自动化代码的执行并没有咱们设想中的那么“自在”，往往在于两方面的起因： 个别团队会把自动化代码执行当作 CI 的一个环节，也只是被作为回归场景应用，然而全量回归的耗时过长限度了执行的频率不会太高；搭建流水线和在这根底上搭配相应的工具还是存在技术门槛，再加上这些操作自身须要的工作量，也导致了难以做到每个人都能随时执行自动化测试。这就导致随着自动化覆盖率的晋升，回归测试的执行工夫反而变得越来越长，于是自动化测试的执行频率只能升高，最初自动化代码的价值受到质疑。其实除了晋升自动化覆盖率之外，咱们还须要扭转“每次测试执行笼罩的用例越多越好”的理念：咱们不应该因为“不释怀”而让测试集变得过分冗余，而是须要基于业务危险优化测试覆盖范围，以期在无限的范畴内实现较高的测试投入产出比，实现精准测试。 CODING 让测试执行更加自在为了让测试执行更加“自在”，CODING 打造了云端自动化执行的能力，冀望解决自动化测试的“最初一公里”问题，从而实现： 每次执行都有灵便抉择用例子集的自在；所有人都领有执行测试的自在。接下来，让咱们看看如何在 CODING 测试治理实现“自在”地执行测试： 首先，在 CODING 自动化用例库中进行自动化代码注销，确定自动化代码曾经存在于代码托管中，对曾经存在的自动化代码库进行注销，并设置相干的语言/框架。 解析自动化代码库的测试函数列表，并建设用例治理中的性能用例与自动化函数的匹配关系，得出自动化覆盖率。通过匹配自动化代码和性能用例，能够帮忙咱们对自动化代码产生的价值建设直观感触，做到“心里有数”。 创立执行形式为自动化执行的测试计划，圈选用例。选取适宜的自动化测试子集是须要业务测试常识的，而执行固定范畴的全回归测试耗时过长，或者重复机械性执行冒烟测试并不能及时反映新需要的测试状况，这是自动化测试覆盖率的晋升之后依然未能达到预期中的价值的起因。CODING 提供按需圈选测试子集的形式来创立测试计划，精准执行相干的自动化代码子集、疾速反馈后果，从而解除了自动化运行时长的顾虑，让团队致力生产的自动化代码价值失去最大化。 执行该测试计划，曾经匹配上的自动化用例在后盾执行并更新对应性能用例的执行后果。自动化执行结束后，能够对未测或者未通过的用例进行手工验证、并更新用例工作状态。 ...

本文首发于：行者AIAirtest是一款基于图像识别和poco控件辨认的UI自动化测试工具，用于游戏和App测试，也广泛应用于设施群控，其个性和性能不亚于appium和atx等自动化框架。 说起Airtest就不得不提AirtestIDE，一个弱小的GUI工具，它整合了Airtest和Poco两大框架，内置adb工具、Poco-inspector、设施录屏、脚本编辑器、ui截图等，也正是因为它集成许多了弱小的工具，使得自动化测试变得更为不便，极大的晋升了自动化测试效率，并且失去宽泛的应用。 1. 简略入门1.1 筹备从官网下载并装置AirtestIDE。筹备一台挪动设施，确保USB调试性能处于开启状态，也可应用模拟器代替。1.2 启动AirtestIDE关上AirtestIDE，会启动两个程序，一个是打印操作日志的控制台程序，如下： 一个是AirtestIDE的UI界面，如下： 1.3 连贯设施连贯的时候要确保设施在线，通常须要点击刷新ADB来查看更新设施及设施状态，而后双击须要连贯的设施即可连贯，如果连贯的设施是模拟器，需注意如下： 确保模拟器与Airtest中的adb版本统一，否则无奈连贯，命令行中应用adb version即可查看adb版本，Airtest中的adb在Install_path\airtest\core\android\static\adb\windows目录上面。确保勾选Javacap形式②连贯，防止连贯后呈现黑屏。 1.4 UI定位在Poco辅助窗抉择Android①并且使能Poco inspector②，而后将鼠标放到控件下面即可显示控件的UI名称③，也可在左侧双击UI名称将其写到脚本编辑窗中④。 1.5 脚本编辑在脚本编辑窗编写操作脚本⑤，比方应用百度搜寻去搜寻Airtest关键词，输出关键字后点击百度一下控件即可实现搜寻。 1.6 运行运行脚本，并在Log查看窗查看运行日志⑥。以上操作只是简略入门，更多操作可参考官网文档。 2. 多线程中应用Airtest当我的项目中须要群控设施时，就会应用多过程或者多线程的形式来调度Airtest，并将Airtest和Poco框架集成到我的项目中，以纯Python代码的形式来应用Airtest，不过仍需Airtest IDE作为辅助工具帮忙实现UI控件的定位，上面给大家分享一下应用Airtest管制多台设施的办法以及存在的问题。 2.1 装置纯python环境中应用Airtest，需在我的项目环境中装置Airtest和Poco两个模块，如下：pip install -U airtest pocoui 2.2 多设施连贯每台设施都须要独自绑定一个Poco对象，Poco对象就是一个以apk的模式装置在设施外部的一个名为com.netease.open.pocoservice的服务（以下统称pocoservice），这个服务可用于打印设施UI树以及模仿点击等，多设施连贯的示例代码如下： from airtest.core.api import *from poco.drivers.android.uiautomation import AndroidUiautomationPoco # 过滤日志air_logger = logging.getLogger("airtest")air_logger.setLevel(logging.ERROR)auto_setup(__file__)dev1 = connect_device("Android:///127.0.0.1:21503")dev2 = connect_device("Android:///127.0.0.1:21503")dev3 = connect_device("Android:///127.0.0.1:21503")poco1 = AndroidUiautomationPoco(device=dev1)poco2 = AndroidUiautomationPoco(device=dev2)poco3 = AndroidUiautomationPoco(device=dev3)2.3 Poco治理下面这个写法的确保障了每台设施都独自绑定了一个Poco对象，然而下面这种模式不利于Poco对象的治理，比方检测每个Poco的存活状态。因而须要一个容器去治理并创立Poco对象，这里套用源码外面一种办法作为参考，它应用单例模式去治理Poco的创立并将其存为字典，这样既保证了每台设施都有一个独自的Poco，也不便通过设施串号去获取Poco对象，源码如下： class AndroidUiautomationHelper(object): _nuis = {} @classmethod def get_instance(cls, device): """ This is only a slot to store and get already initialized poco instance rather than initializing again. You can simply pass the ``current device instance`` provided by ``airtest`` to get the AndroidUiautomationPoco instance. If no such AndroidUiautomationPoco instance, a new instance will be created and stored. Args: device (:py:obj:`airtest.core.device.Device`): more details refer to ``airtest doc`` Returns: poco instance """ if cls._nuis.get(device) is None: cls._nuis[device] = AndroidUiautomationPoco(device) return cls._nuis[device]AndroidUiautomationPoco在初始化的时候，外部保护了一个线程KeepRunningInstrumentationThread监控pocoservice，监控pocoservice的状态避免异样退出。 ...

本文首发于：行者AI自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员依据测试用例中形容的规程一步步执行测试，失去理论后果与冀望后果的比拟。在此过程中，为了节俭人力、工夫或硬件资源，进步测试效率，便引入了自动化测试的概念。 1. 前提条件1.1 需要变动不频繁测试脚本的稳定性决定了自动化测试的保护老本。如果软件需要变动过于频繁，测试人员须要依据变动的需要来更新测试用例以及相干的测试脚本，而脚本的保护自身就是一个代码开发的过程，须要批改、调试，必要的时候还要批改自动化测试的框架，如果所破费的老本不低于利用其节俭测试老本，那么自动化测试便是失败的。我的项目中的某些模块绝对稳固，而某些模块需要变动性很大。咱们便可对绝对稳固的模块进行自动化测试，而变动较大的仍是用手工测试。 1.2 我的项目周期够长自动化测试需要的确定、自动化测试框架的设计、测试脚本的编写与调试均须要相当长的工夫来实现，这样的过程自身就是一个测试软件的开发过程，须要较长的工夫来实现。如果我的项目的周期比拟短，没有足够的工夫去反对这样一个过程，那么自动化测试便成为笑谈。 1.3 自动化测试脚本可重复使用如果费尽心思开发了一套近乎完满的自动化测试脚本，然而脚本的反复使用率很低，以致其间所消耗的老本大于所发明的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试伎俩了。另外，在手工测试无奈实现，须要投入大量工夫与人力时也须要思考引入自动化测试。比方性能测试、配置测试、大数据量输出测试等。 2. 应用场合通常适宜于软件测试自动化的场合： （1）回归测试，反复繁多的数据录入或是击键等测试操作造成了不必要的工夫节约和人力节约； （2）测试人员对程序的了解和对设计文档的验证通常也要借助于测试自动化工具； （3）采纳自动化测试工具有利于测试报告文档的生成和版本的连贯性； （4）自动化工具可能确定测试用例的笼罩门路，确定测试用例集对程序逻辑流程和管制流程的笼罩。 3. 实用工具目前适宜初学者接触的自动化测试软件便是Airtest IDE。 AirtestIDE 是一个跨平台的UI自动化测试编辑器，实用于游戏和App。自动化脚本录制、一键回放、报告查看，轻而易举实现自动化测试流程反对基于图像识别的 Airtest 框架，实用于所有Android和Windows游戏反对基于UI控件搜寻的 Poco 框架，实用于Unity3d，Cocos2d与Android App，可能运行在Windows和MacOS上。 启动Android模拟器或者用PC连贯一台手机。通过adb命令查看挪动设施。 >adb devices List of devices attached emulator-5554 device 在Android模拟器中操作时，Airtest IDE右侧的界面是同步的，这一点比很多挪动测试工具做的优良，例如，appium desktop必须手动刷新能力获取最新的界面。 Airtest IDE反对Airtest脚本的录制，用法非常简单，你甚至能够先不必看它的API，通过录制来相熟它的API。右侧Airtest窗口以及API，点击右上角录制按钮，而后，就能够在映射的Android模拟器界面上点点点了。 这种脚本更适宜游戏，因为游戏界面很难定位，图片辨认（截图）的形式的确是不错的抉择。 上面将介绍一下罕用控件函数： （1）touch 这个函数是一个进行点击的函数，能够设置本人须要点击的图片，次数，长按工夫和右键点击。 （2）wait 这个函数的意思就是期待，依照肯定条件期待某样货色。这里能够设置等待时间，等待时间中的每次匹配距离，图片没找到时能够调用的函数以及自身函数返回的值。 （3）swipe 这个函数是一个进行滑动的函数，从图片1滑动到图片2，咱们须要设定好两张图片来进行滑动。在swipe函数中有一个值为duration，该值决定了滑动的时长，有的滑动操作对滑动的速度有肯定的要求，快和慢会有不同的后果。在理论应用swipe函数时，设置多少个插值点，想要多快的滑动就成了这个函数应用的调试重点。 （4）exists 这个函数是一个判断存在的函数，判断一个图片是否存在，返回一个布尔值，不便判断的一个函数。 （5）keyevent 这个函数是一个进行手机控件点击的函数，例如手机上的“home”、“back”、“power”。 （6）text 这个函数是进行文本输出的函数，能够在被关上的输入框内输出文字。 （7）snapshot 这个函数是进行截图作用的函数。 （8）sleep 这个函数是进行提早进行设置的函数。 （9）assert_exists 断言截图是否存在于以后页面，了解为如果这个截图内容存在，让他再测试报告中生成出什么文案。 （10）assert_not_exists 断言截图是否不存在于以后界面，了解为如果这个截图内容不存在，让他再测试报告中生成出什么文案。 （11）assert_equal 断言以后页面中是否蕴含设置好的文案，如果蕴含就通过。 （12）assert_not_equal 断言以后页面中是否不蕴含设置好的文案，如果不蕴含就通过。

本文首发于：行者AI游戏我的项目研发时，须要搭建一个自动化测试的平台，以冀望场内战斗应用自动化来测试，发现局内bug，防止重复劳动、进步测试效率以及防止人为的操作谬误。其中环境要求应用我的项目须要应用Airtest、poco对接强化学习的服务器，实现Airtest将状态信息发送给服务器，服务器返回下一步的决策。 1. 后期筹备工作理解Airtest、poco、强化学习agent的决策形式。 1.1 Airtest介绍Airtest基于图像识别的自动化测试框架。这个框架外围不在实现形式和技术上，而是理念！这个框架的理念借用是MIT（麻省理工）研究院的成绩 Sikuli ，他们构思了一种全新的UI测试模式，基于图像识别控件而不是具体内存里的控件对象。 （1）Airtest特点 反对基于图像识别的可程式化测试工具跨平台生成测试报告反对poco等SDK内嵌，进步UI辨认精度（2）Airtest界面（蕴含点击、滑动、判断、截屏等接口） （3）Airtest成果演示 以上演示的是Airtest与间接通过图像识别对界面产生交互。如若须要与界面指定元素交互，是须要Poco提供的办法对界面上的元素进行操作 （4）Airtest局限性 然而在理论工程中，图像不会变化无穷，咱们须要捕捉我的项目的动静节点，针对动静节点进行点击、挪动等操作（比方商店买旗子的地位节点） 咱们须要另一个工具Poco。 1.2 Poco介绍目前Poco只反对原生Android和ios的接口调用，其余平台均须要接入对应平台的sdk （1）Poco获取UI树的形式 从根节点开始向下遍历子节点 在unity我的项目中，须要在unity中装置Poco的SDK （2）Poco调用办法 （3）Poco调用举例 poco = UnityPoco()poco('btn_start').click()Airtest通过接口调用unity中的pocosdk，SDK对整个ui树进行遍历，将dump后的json信息传回Airtest。 Airtest在失去的UI树中找到‘btn_start’的元素地位信息，通过adb进行点击操作。 1.3 强化学习的简述 Environment 通常利用马尔可夫过程来形容，Agent 通过采取某种 Policy 来产生Action，和 Environment 交互，产生一个 Reward。之后 Agent 依据 Reward 来调整优化以后的 Policy。 用上图更形象的解释，state是环境的一个状态，observation是Agent察看到的环境状态，这里observation和state是一个意思。首先Agent察看到环境的一个状态，比方是一杯水，而后Agent采取了一个行为，这个行为是Agent把杯子中的水给打碎了，这样环境的的状态曾经产生了变动，而后零碎会对这个行为打一个分数，来通知Agent这样的行为是否正确，而后依据新变动的环境状态，Agent再采取进一步的行为。Agent所谋求的指标就是让Reward尽量的大。 2. 我的项目执行过程：2.1 背景通过将训练好的一个Agent部署到服务器上，其他人通过拜访服务器，流程如下：a. 测试端收集信息->测试端将信息转成约定好的state格局->测试端将state发给服务器->服务器返回一个Agent的决策->测试端收到信息执行决策-> b. 测试端收集信息(新一轮循环的开始)... 在这个过程中，测试端收集信息耗时最为重大，针对我的项目需要决定对其局部进行优化。 2.2 具体问题poco首次调用dump接口时会启动大量mincap等诸多可执行文件，导致7秒左右的提早。 Airtest操作遇到的提早过于重大，导致游戏每回合可操作工夫30秒内，只能进行4-5个动作。 然而本地训练的agent前期每回合操作数能达到16个左右，导致前期agent动作不能齐全在客户端上做完。 2.3 解决方案提前加载poco的click事件 定位到dump耗时重大，决定从sdk的接口登程，缩小dump出的json文件大小。 a. 在unity的接口中，退出tagfilter、blacklist、propertylist参数，来管制json的文件大小。其中tagfilter用于针对指定tag的unitygameobject的筛选，能够去除除UI和Default以外的所有物体。 blacklist用于针对unitygameobject名字的筛选，能进步dump效率50% propertylist用于缩小单个unitygameobject的参数写入，默认单个物体有10多个参数，筛选后能够省下6个左右的参数。可进步dump效率33% b. 在python的接口应用对应接口参数 该办法完满解决了操作提早的问题，目前客户端单回合30秒能够实现20个左右的动作。 2.4 具体步骤：layerfilter 在本次我的项目中，有13个layer。只对tag为UI和Default的UGO进行递归写入子节点信息，剔除掉场景、特效等层级，能够大幅缩小开销。 ...

本文首发于：行者AI目前，在自动化测试的理论利用中，接口自动化测试被宽泛应用，但UI自动化测试也并不会被代替。让咱们看看二者的比照： 接口自动化测试是跳过前端界面间接对服务端的测试，执行效率和覆盖率更高，保护老本更低，整体而言投出产出比更高，因而在我的项目上的应用更宽泛。而UI自动化测试则是模仿用户在前端页面中的操作行为进行测试，尽管在执行过程中易收到其余因素的影响（如电脑卡顿，浏览器卡顿，网速等）而导致用例执行失败，且前期保护老本较高，然而UI自动化测试更贴近用户应用时的真实情况，也可能发现一些接口自动化无奈发现的bug。因而，在理论我的项目的自动化测试中，通常采纳以接口自动化为主、零碎稳固后通过UI自动化对重点业务流程进行笼罩的计划。而UI自动化的根底，就是元素定位。只有实现了元素定位，才能够操作定位到的元素，模仿手工测试进行一系列的页面交互，比方点击、输出等。 1. 罕用的元素定位形式对于web端的UI自动化测试，元素定位通常应用selenium提供的以下8种定位形式： id：依据id定位，是最罕用的定位形式，因为id具备唯一性，定位精确快捷。name：通过元素的【name】属性定位，会存在不惟一的状况。class_name：通过class 属性名称进行定位。tag_name：通过标签名定位，个别不倡议应用。link_text：专用于定位超链接元素（即a标签），须要齐全匹配超链接的内容。partial_link_text：同样用于定位超链接元素，但能够含糊匹配超链接的内容。xpath：依据元素门路进行定位，分为绝对路径和相对路径，能够定位到所有指标元素。css_selector：selenium官网举荐的元素定位形式，比xpath效率更高，但须要把握一些css根底。在理论的我的项目中，更举荐应用xpath和css定位形式，这两种能够定位到页面中的所有元素，应用限度较小。如果对css没有理解的话，举荐应用xpath的形式，上手更快；如果对css有肯定根底的敌人，更举荐应用css进行元素定位。 接下来，以百度首页为例，在理论应用中对各种定位形式进行具体介绍。 2. 元素定位的理论利用以百度首页的搜寻框为例，介绍id、name、class、tag_name四种元素定位形式。 2.1 id定位通过id属性对百度首页的的输入框进行定位。 # 通过input标签的id属性进行定位find_element_by_id('su')2.2 name定位通过name属性对百度首页的输入框进行定位。 # 通过input标签的name属性进行定位find_element_by_name('wd')2.3 class_name定位通过class属性对百度首页的输入框进行定位。 # 通过input标签的class属性进行定位find_element_by_class_name('s_ipt')2.4 tag_name定位通过标签名称来定位，这种形式很少会应用，因为页面中的同一个标签通常都会反复。 # 通过input标签名进行定位find_element_by_tag_name('input') 接下来，以页面底部的“意见反馈”为例，介绍linkText和partialLinkText两种定位形式。 2.5 linkText定位通过a标签的文本信息进行定位，仅用于定位超链接a标签。 # 通过a标签的文本信息进行定位find_element_by_link_text('意见反馈')2.6 partialLinkText定位通过对a标签的局部文本信息含糊匹配进行定位。 # 通过对a标签的局部文本信息含糊匹配进行定位find_element_by_partial_link_text('反馈')2.7 xpath定位xpath定位形式是通过页面元素的属性和门路进行元素定位，实践上能够对页面中所有的元素精选定位。上面介绍xpath的几种定位形式。 首先，介绍一下xpath的门路节点表达式，如图： （1） xpath绝对路径定位 仍已百度首页的搜寻框为例进行介绍。 find_element_by_xpath('/html/body/div[1]/div[1]/div[5]/div/div/form/span[1]/input')通常状况下，不会抉择应用xpath绝对路径进行元素定位，起因有二：一是绝对路径繁琐简短，影响运行速度；二是波及的层级较多，任何一个层级发生变化都会导致定位失败，须要从新进行批改，不利于前期保护。 （2） xpath相对路径和元素属性联合定位 若指标元素的某个属性具备唯一性，则可间接对指标元素进行定位；否则，须要在指标元素左近寻找一个具备唯一性的元素，而后通过二者的层级关系进行定位。 接下来，仍然以百度首页的页面元素为例，对xpath定位的形式举例说明。 # 通过元素属性定位百度首页的搜寻框find_element_by_xpath("//input[@id='su']")find_element_by_xpath("//input[@name='wd']")find_element_by_xpath("//input[@class='s_ipt']")find_element_by_xpath("//input[@autocomplete='off']")# 通过文本信息定位(和text_link办法不同，不局限于a标签)find_element_by_xpath("//a[text()='意见反馈']")find_element_by_xpath("//span[text()='设置']")# 通过父级定位子级元素，举例百度首页搜寻按钮find_element_by_xpath("//span[@class='bg s_btn_wr']/input")# 通过子级定位父级元素，举例百度首页百度热榜的换一换find_element_by_xpath("//span[text()='换一换']/..")# 通过contains办法含糊匹配定位，举例百度首页搜寻按钮find_element_by_xpath("//input[contains(@class,'s_btn')]")find_element_by_xpath("//a[contains(text(),'反馈')]")（3） 浏览器复制xpath 除了上述两个办法之外，还有一个简略的办法，就是在浏览器的F12开发者工具中找到指标元素，鼠标右键进行复制即可，如下图。 但复制的xpath门路可能会很简短，还是举荐大家依据需要本人写指标元素的xpath门路。 2.8 css_selector定位（1） css定位简介 css_selector定位（下文简称css定位），它的定位形式，利用选择器进行的。在CSS 中，选择器是一种模式，用于抉择须要增加款式的对象。通过css进行元素定位，实践上也是能够定位到页面中的所有元素的。 和xpath相比，css的语法更简洁、定位速度更快，然而css的语法比xpath较为简单一些，绝对难记。 （2） css定位实例 上面，仍以百度首页搜寻框为例，对css定位形式举例说明。 # 通过id定位，id名前加# find_element_by_css_selector("#kw")# 通过class定位，class名前加. find_element_by_css_selector(".s_ipt")# 通过标签定位find_element_by_css_selector("input")# 通过其它属性定位 find_element_by_css_selector("[name='wd']")# 标签和属性组合定位 find_element_by_css_selector("input#kw")find_element_by_css_selector("input.s_ipt")find_element_by_css_selector("input[name='wd']")find_element_by_css_selector("[name='wd'][autocomplete='off']")# 通过父级定位子级元素 find_element_by_css_selector("from#form>span[@class='bg s_ipt_wr']>input")3. 小结以上，就是selenium的各种元素定位办法的简略介绍。我的项目的理论应用中，在定位办法的抉择上，比拟举荐大家采纳“id > name > xpath/css > 其它”的程序进行抉择。 ...

崎岖的2020学软件测试容易，找工作难！2020年是崎岖的一年，对于咱们每个人来说，衰弱地活着比什么都重要。 现状1-疫情&裁员潮到来 ➢起因: ➢疫情影响寰球经济,波及大多数行业 ➢大环境预测不好导致企业勒紧裤腰带(中美贸易战) ➢投资环境收紧影响大量守业公司 ➢企业人力成本上升 ➢供大于求 可能在五年前的样子，咱们的软件测试岗位能够说是一个风口。然而当初的话呢，曾经开始缓缓趋于一个均衡的状态了，不再是像十年前五年前，就算你不懂技术，也可能找到一个软件测试的岗位，也可能拿到一个还算不错的薪资。 其实当初这样的一个机会曾经十分的少了，供求关系基本上是缓缓达到一个均衡规范了。 现状2:手工测试衰败 ➢纯手工测试的生产力曾经跟不上时代要求 这个是大家都深有体会的，第一个，因为手工测试曾经跟不上时代的生产力要求。但并不是说，要淘汰手工测试。（只有有软件测试行业的存在，手工测试就不会被淘汰）这个和自动化测试不会代替手工测试是一个情理。 不论咱们的自动化测试、人工智能做得有多好。手工测试它还是会存在的，只是说它占据的比例会越来越少，而且当初的手工测试并不能和十年前的手工测试去相比。因为当初的技术要求越来越高，当初的手工测试市场额度越来越小。 所以如果你是零根底转行，肯定要慎思。 每一行你做到了28定律的2，前（钱）景都是很可观的。 当然不得不抵赖的是，咱们大部分都是普通人，包含我。 可能有一份稳固的工作，过着本人舒心的日子，所以星爷在电影里说到：人嘛，最重要的就是开心！ 还是比拟传统，认为元旦才是真正的过年。 本文次要分享8个点，可按需来浏览： Share1：今日头条/腾讯各类大厂软件测试岗面试题 Share2：想拿到年薪二十万，须要具备哪些技能？ Share3：挑战自动化测试 Share4：自动化测试心得 Share5：对于测试开发 Share6：测试行业的现状 Share7：小米测试三年，我如何积攒教训？ Share8：如何晋升企业面试通过率？ Share1：今日头条/腾讯各类大厂软件测试岗面试题（1）软件测试习题参考答案 （2）测试面试题及一些材料 （3）用友自动化测试面试题和局部答案 （4）软件测试一些根底面试问题 （5）软件测试面试题（软通能源/博彦科技/奇虎/瑞星/中软） （6）阿里巴巴和华为口试和面试题 （7）哔哩哔哩软件测试工程师面试题 （8）美团网软件测试面试题回顾版本 （9）拼多多软件测试校招面试题 （10）瑞星软通测试工程师口试题 （11）搜狗软件测试工程师口试题 （12）腾讯近三年78道软件测试面试题（蕴含答案） （13）字节跳动测试工程师口试题 （14）5个重要的面试题（含金量高，分水岭能Pass掉很多人） （15）华测软件测试面试题解析 （16）软件测试真题试卷 （17）实践根底到测试开发面试题（视频精讲） （18）其余局部（次要解说一些综合性的问题） 资源有一部分来源于网络收集与在企业中的测试敌人，感激前辈的答疑解惑！Share2：想拿到年薪二十万，须要具备哪些技能？因为历史起因，大部分测试人员，最开始接触都是纯性能界面测试，随着工作年限，会接触到一些罕用测试工具，比方抓包，数据库，linux等。 我大学学的计算机专业，有肯定的编程根底。我的软件测试职业开始和大多数测试人员一样，一开始在一家电商公司做软件功能测试。 有人留言问到我，在一线城市做功能测试，如果定个小指标，想拿到年薪二十万，须要具备哪些技能？ 首先必须纯熟整个产品的业务流程、业务是根底，这样保障产品在疾速迭代时、不仅保障新性能的完整性，而且疾速回归原有性能不受影响。 而后须要把握一些罕用测试工具来辅助测试： Web端测试：浏览器开发者工具应用，network、console控制台、兼容性测试 挪动端app测试：（安卓/IOS/ipad端）测试全流程，兼容性测试、稳定性测试，晦涩度测试、adb常用命令 服务端：把握接口测试、抓包工具应用、如何校验接口的完整性 Linux：罕用shell命令，查看谬误日志 数据库测试：相熟数据库表构造，把握罕用增删改查sql语句，便于分析测试后果。 常用工具应用：SVN/git版本控制工具 、postman、jenkins利用打包和构建 换句话说，如果你拿到一个新的产品测试性能，你如果能通过数据库的表构造，和剖析系统日志来疾速的相熟产品业务，阐明你的测试思维，功能测试能力曾经十分优良了。 过后我把握了以上技能点，在公司将工作效率进步了，绝对比拟轻松，这就导致我有短缺的工夫，拾起编程语言，最后用的java语言，而后学习各种自动化测试技术，过后感觉自动化测试特地有意思，而且挺神奇，激发了我浓重的趣味。 起初发现Python语言越来越火，而且我发现python来做自动化和对于编程根底比拟单薄的测试工程师来说特地的适合， python还能用来爬虫，用python还能写一些定时脚本，数据库脚本，效率十分高 ...

作者：张静文爱可生上海研发核心成员，测试工程师，负责 DMP 以及 DTLE 自动化测试。本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。工作：测试开源产品 dtle（https://github.com/actiontech...），对 mysql 字符类型，表构造的支持性。 测试需要如下：1. 测试 dtle 对 mysql 所有的字符类型支持性2. 测试 dtle 对表构造的支持性3. 等....... 测试步骤大抵为：设计表构造，数据类型。应用 dtle 迁徙表/数据。比照应用 dtle 迁徙的源数据库和指标数据库的数据、表构造是否有差别。起初，我开启了 2 个窗口一条条的比照，然而当我比对到第 100 条数据的时候，我发现眼花了，仿佛有些数据“如同不一样”。我还有好几万条数据要这么比照呢，而且每次发新版本，我都要这么来一次......这不是人能实现的艰巨工作！ 所以我寻找是不是有什么工具能帮我做这部分工作，搜寻后发现一部分私人写的小工具（具体的就不列举了），然而通过应用后，发现很多工具本身就带有一部分 BUG，如果我用这些工具做数据比照必定会脱漏 BUG。 通过几天的搜寻试用，发现 mysql 官网提供了一个十分不错工具mysqldiff/mysqldbcompare，所以想着分享给大家。 以下就间接说说应用办法： (零碎：Ubuntu 18.04) 1. 软件下载，地址如下： https://cdn.mysql.com/archive...2. 解压到当前目录 mysql-utilities-1.6.5 下： tar -zxvf mysql-utilities-1.6.5.tar.gz3. cd 到 mysql-utilities-1.6.5，执行装置： apt install mysql-utilities如下图： 4. 演示 mysql-utilities 中的 mysqldiff 应用和成果： 首先咱们能够通 过 mysqldiff --help 命令查看用法： 接下来我要测试通过 DTLE 数据迁徙的 2 个数据库，而后验证： 1. 是否有表构造扭转 ...

测试平台技术博客

问题描述项目需要使用jest+puppeteer 实现对Antd组件库中的Select组件进行操作，选中其中的某一项的值。测试页面为Antd Select 使用puppeteer Recorder录制出来的测试代码如下所示 const puppeteer = require('puppeteer');(async () => { const browser = await puppeteer.launch() const page = await browser.newPage() await page.goto('https://ant.design/components/select-cn/') await page.setViewport({ width: 1154, height: 586 }) await page.waitForSelector('.ant-select-focused > .ant-select-selection > .ant-select-arrow > .anticon > svg') await page.click('.ant-select-focused > .ant-select-selection > .ant-select-arrow > .anticon > svg') await page.waitForSelector('div > .ant-select-dropdown > #\31 55fc83a-09de-47b7-a57e-a6042a0e3a5b > .ant-select-dropdown-menu > .ant-select-dropdown-menu-item-active') await page.click('div > .ant-select-dropdown > #\31 55fc83a-09de-47b7-a57e-a6042a0e3a5b > .ant-select-dropdown-menu > .ant-select-dropdown-menu-item-active') await browser.close()})()使用这段代码进行E2E测试，经常会在这段代码timeout ...

7月25日晚8点，线上直播，【AI中台——智能聊天机器人平台】，点击了解详情。 一、什么是AngularJS ?1、AngularJS是一组用来开发web页面的框架、模板以及数据绑定和丰富UI的组件； 2、AngularJS提供了一系列健壮的功能，以及将代码隔离成模块的方法； 3、AngularJS于2009年发布第一个版本，由Google进行维护，压缩版94k。 二、AngularJS的核心思想 1、在AngularJS中通过数据视图双向绑定实现视图与业务逻辑解耦，这将提高代码的可测试性； 2、遵循MVC模式开发，鼓励视图、数据、逻辑组件间松耦合； 3、将测试与应用程序编写放在同等重要的位置，在编写模块的同时编写测试。因为各组件的松耦合，使得这种测试得以实现； 4、 应用程序页面端与服务器端解耦。两方只需定义好通信API，即可并行开发。 三、简单的栗子问题：假设我们需要编写一个手机列表，支持对手机信息进行模糊搜索，且按指定字段排序，要怎么实现呢？ 如上图所示，几乎没有DOM操作，更专注于业务逻辑！ 下面编写HTML 编写控制器Controller PhoneListCtrl 控制器。例子中注入了$scope(数据模型)、$http(封装了ajax的服务)这两个服务都是angularjs内置服务，服务是可以自定义的。 $scope.phones = data; 在这个地方后台返回的数据应用到了数据模型中，这时前台UI会自动响应更新。 四、指令4.1 什么是指令？指令是AngularJS用来扩展浏览器能力的技术之一。在DOM编译期间，和HTML关联着的指令会被检测到，并且被执行。这使得指令可以为DOM指定行为或者改变DOM的结构。例如ng-controller、ng-src、ng-model等。 4.2 AngularJS的编译 4.3 简单的AngularJS指令写法自定义指令的一般格式： angular.application(‘myApp’, []).directive(‘myDirective’,function(){//一个指令定义对象return{ }; //通过设置项来定义指令，在这里进行覆写});下面我们来看一个简单的自定义指令的例子： module：这个方法将新建一个模块。AngularJS以模块管理代码。directive：在模块中新建指令，指定的方法在编译步骤会被执行，执行后返回一个自定义的链接函数，这个链接函数在完成双向绑定后执行。Restrict：它告诉AngularJS这个指令在DOM中可以何种形式被声明。E（元素）, A（属性，默认值）, C（类名）。scope ：可以被设置为true或一个对象。默认值是false。当scope设置为true时，会从父作用域继承并创建一个新的作用域对象。有三种绑定策略@ = &。Template：一段HTML文本，或一个可以接受两个参数的函数，参数为tElement和tAttrs，并返回一个代表模板的字符串。4.4 使用指令 ng-app="MyModule":在angularjs启动时指定初始化的模块(module)。当前指定的是自定义的模块。drink water="{{pureWater}}":调用自定义的drink指令，将$scope中的pureWater属性赋值给指令中的water属性。drink可以是一个属性，也可以是一个标签。五、模块和服务在AngularJS中，模块负责组织、启动、实例化应用。 模块的两个部分，一个是配置块，另一个是运行块。 配置块：在实例工厂（provider）注册和配置阶段运行。只有工厂、常量才可以注入到配置块中（常量的配置要放在前面）； 运行块：注入器(injector)被创建后执行，被用来启动应用。实例和常量、变量等都能被注入。 AngularJS应用中的服务是一些用依赖注入捆绑在一起的、可替换的对象。这些对象可以提供一些封装好的逻辑操作，以供调用。 AngularJS内置了很多有用的服务，例如前面提到的$timeout、$http等，我们可以通过使用内置服务完成大部分业务逻辑。但很多时候我们还需要自定义服务： 服务的使用 上图的代码中定义了一个服务notify，它依赖另外一个服务$window。$window中封装了window对象的方法，定义了一个控制器myController，并为这个控制器注入了notify服务，同时在控制器的scope中定义了一个方法callNotify来调用服务。$inject是依赖注入的一种方式，请参看下文依赖注入章节。 六、依赖注入我们可以将需要的服务比作一件工具，比如一把锤子，那我们要怎么获得锤子呢？ 第一种方法：自己打造一把锤子。如果锤子的工艺改变了，我们就需要重新制造。相当于我们在程序中new了一个服务，服务的实现改变时，只能修改代码，这将产生风险。 第二种方法：我们找到一间工厂，告诉工厂锤子的型号，然后工厂为我们制造。这时候就不需要关系锤子是怎么做的，我们只管使用。但是这种方式还是很麻烦，我们需要知道工厂在哪。类似于在代码中通过工厂方法获取我们想要的服务。这种方会对工厂产生依赖。 第三种方法：我们在门前贴张单子，声明我们需要一把什么型号的锤子，第二天就有人默默地送来了一把锤子。这在现实生活中简直是痴心妄想，但这种方式确实很轻松，不需要考虑任何东西，我们只关注使用锤子。这就是程序里的依赖注入。只要声明了需要什么，在使用的时候就可以得到什么。 6.1 AngularJS中的依赖注入第一种方式：通过方法参数名声明依赖。这种方式不推荐使用，因为js文件压缩后方法参数名会改变。 第二种方式：声明一个数组，依赖列表放数组的前部，注入目标放数组最后一个元素。推荐使用这个方法。 第三种方式：通过$inject属性来声明依赖列表。 ...

简介Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用；常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。 今天我们介绍一种更快速的安装方法，那就是通过URLOS一键安装jenkins。urlos是什么？ URLOS是一个云主机管理软件，基于Docker容器技术打包和运行应用，包含负载均衡和故障转移等高级功能，可自动识别机器和云应用的故障并将云应用转移至可用的机器上，单机故障并不影响业务开展。 你可以使用以下命令安装URLOS： curl -LO www.urlos.com/iu && sh iu在此不讨论URLOS的使用方法，感兴趣的朋友请自行搜索，我们直接来看URLOS如何快速安装jenkins： 安装流程1.登录URLOS系统后台，在应用市场中搜索“jenkins”，找到之后，直接点击安装按钮 2.填写服务名称、选择运行节点、服务端口、选择智能部署 然后点击“提交”按钮，等待部署完成； 3. jenkins初始化向导访问http://IP:8080（其中的IP是你的服务器的IP） 这里需要填写初始密码，创建服务完成后，可在当前服务的文件管理中找到密码文件，路径为jenkins_home/secrets/initialAdminPassword 找到密码，将密码填入后继续步骤： 选择安装社区流行的插件还是自定义安装插件 我们选择自定义安装插件： 可以看到已经默认选择了一些插件，我们可以选择自己需要的来安装。 选择“install”进行下一步： 创建管理员账户： 登录后： jenkins的详细使用方法请查考官方文档：https://jenkins.io/zh/doc/

一、当前软件开发的趋势开篇我们先简要介绍一些近几年在企业开发中出现的重要概念，以便引入持续测试的主旨。这些概念中最重要的两个便是DevOps和微服务。两者都是目前软件开发中的最佳实践和方法论，旨在为企业提供更高的灵活性，提升运营效率。 1.1 DevOps DevOps是一套实践方法论和文化，提倡打破原有组织和限制，职能团队开始拥抱和接受DevOps所倡导的高度协同，研发、测试、运维及交付一体化的思维。随着DevOps和敏捷热度的不断提升，无论是互联网企业还是传统软件企业都开始拥抱敏捷，实践DevOps。持续集成CI（Continuous integration）、持续交付CD（Continuous delivery ）作为DevOps的最佳实践，越来越受到重视。 1.2 微服务架构 Microservice Architecture微服务架构源起于DevOps意识形态和实践中，是一种软件架构风格。微服务架构带来了一系列好处，例如可部署性、可靠性、可用性等等。虽然原则上可以使用任何架构来实践DevOps，但微服务架构正在成为构建持续部署 (CD)系统的标准架构风格。由于每项服务的规模都很小，它允许通过连续重构来实现单个服务的体系结构，因此减少了对大型项目前期设计的需求，允许尽早发布软件并且持续交付。微服务和DevOps是天然的共同体，结合起来共同实现软件开发行业的变革。 二、自动化测试 Test Automation随着敏捷和微服务架构的引入，CI/CD成为构建和部署的标准，即使在没有采用微服务架构的项目中也是如此。为了保证已定义的流程和事务按照预期运行，测试必不可少。而在应对现代软件产品频繁的变化和发布上，传统的手工测试方式在人员和效率上都存在严重不足，因此自动化测试已经成为现代软件研发过程中一个关键组成部分。自动化测试是打通持续集成和持续交付的核心，没有有效的自动化测试保证，持续集成和持续交付就仅仅是一个没有灵魂的躯壳。 2.1 测试分类测试按照不同的维度可以进行多种分类。 按测试手段是否手工，可划分为自动化测试和人工测试；按照测试目的划分，可分为功能测试、性能测试、负载测试等。本文采用Martin Fowler按照层级分类的方式对测试进行分类。 Martin Fowler描述测试金字塔分为单元、服务和UI三个层级。尽管大家对此的具体描述各不相同（有人将三层分别定义为单元、接口、集成测试；也有人将整个金字塔划分为4-5个层级），但金字塔自底向上的结构是大家公认和遵循的。 1)单元测试 单元测试是针对代码单元（通常是类/方法）的测试，单元测试的价值在于能提供最快的反馈，在开发过程中就可以对逻辑单元进行验证。好的单元测试可以帮助改善既有设计，在团队掌握 TDD的前提下，单元测试能辅助重构，帮助提升代码整洁度。 2)接口（服务/API）测试 接口测试是针对业务接口进行的测试，主要测试内部接口功能实现是否完整。比如内部逻辑是否正常、异常处理是否正确。接口测试的主要价值在于接口定义相对稳定，不像界面或底层代码会经常发生变化，所以接口测试比较容易编写，用例的维护成本也相对较低。在接口层面准备测试的性价比相对较高。 3)集成（UI）测试 集成测试从用户的角度验证产品功能的正确性，测的是端到端的流程，并且加入用户场景和数据，验证整个过程是否健康流畅。集成测试的业务价值最高，它验证的是一个完整的流程，但因为需要验证完整流程，在环境部署、准备用例及实施等方面成本较高，实施起来并不容易。 2.2 微服务架构为测试带来的挑战微服务架构在解决了应用大小、应用开发规模等问题之后也带来了一些新的问题，比较突出的有微服务数量增多、服务间调用关系复杂等等。复杂的依赖导致即使项目资深开发人员也不能一下子梳理出所有关系。 微服务和传统的单体应用相比，在测试策略上会有一些不太一样的地方。简单来说，在微服务架构中，测试的层次变得更多，需要测试的服务和应用也会变得更多。手动执行所有的测试是低效的，无法跟上互联网快速迭代的要求。这时有必要引入自动化测试来减轻测试团队的压力，提高测试效率和测试质量。 2.3 自动化测试说起自动化测试，功能测试人员可能会将其想得很高端复杂。 先来看一般的功能测试如何进行：设计并编写用例文档，描述测试步骤和预期结果；测试人员根据测试用例描述按步骤操作，然后判断实际结果与预期是否一致。如果一致，测试通过；如果不符，测试失败。 自动化测试要做的事情与功能测试是一致的。分层理论和自动化测试方法结合，出现了三个层面的自动化：单元测试自动化、接口测试自动化和UI测试自动化。当然，不同层面的自动化关注点是不一样的。所以，从测试的行为本质上来看，功能测试与单元自动化测试、接口自动化测试和UI自动化测试并没有区别。唯一的区别是，一个由人来执行，一个由代码或工具执行。 2.4 自动化测试分层1)单元自动化测试 单元测试自动化，指对软件中最小的可测试单元进行检查和验证，调用被测服务的类或方法，根据类或方法的参数，传入相应的数据，得到一个返回结果，最终断言返回的结果是否符合预期。如果相等，测试通过；如果不相等，测试失败。 所以，单元测试关注的是代码的实现与逻辑。单元测试是最基本的测试，也是测试中的最小单元，它的对象是函数对象，也可以包含输入输出，针对的是函数功能或者函数内部的代码逻辑，并不包含业务逻辑。 该类测试一般由研发人员完成，需要借助单元测试框架，如java的Junit、TestNG，python的unittest等。 2)接口自动化测试 接口自动化测试，主要验证模块间的调用返回以及不同系统、服务间的数据交换。接口测试自动化一般在业务逻辑层进行测试。根据接口文档是RESTful还是RPC？调用被测试的接口，构造相应的请求数据，得到返回值，是成功或者失败。不管输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。 所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。 常见的接口测试工具有postman、jmeter、loadrunner等。 3)集成（UI）自动化测试 UI层是用户使用产品的入口，所有功能通过这一层提供给用户，目前测试工作大多集中在这一层，这种测试更贴近用户的行为，模拟用户点击了某个按钮、在输入框里输入了某些指令。有时可能用户看到登录成功了，但UI自动化并不知道它刚才的点击有没有生效。所以要找“证据”，比如登录成功后页面右上角会显示“欢迎，xxx”，这就是登录成功的有力“证据”。当UI自动化登录成功后，就去获取这个数据进行断言，断言如果相等，测试通过；如果不相等，测试失败。 所以，UI自动化的关注点用户操作形为，以及UI上各种组件是否可用。常见的测试工具有UFT、Robot Framework、Selenium、Appium等。 4)分层占比最佳实践 每种自动化测试都有自己的侧重和优劣势，在实际工作中不可能做到均分，因此我们需要制定合理的测试策略对其进行组织和分配，包括每部分测试投入多少、测试用例比例是多少等。 测试金字塔还有另一个维度的信息，如上图所示。 越往上，越接近QA、业务/最终用户，越往下，越接近开发；越往上，测试执行越慢，越往下，测试执行越快；越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪），越往下，测试成本越低。按照测试金字塔模型以及投入/产出比，我们得知越向下回报率越高，所以应该使用大量的单元测试和全面的接口测试来覆盖产品提供的基本逻辑和功能，使用少量的集成（UI）测试来进行前端界面的功能验证。 都说业内最佳实践看Google，Google的自动化分层投入占比是：单元测试（Unit）：占比70%；接口测试（Service）：占比20%；集成测试（UI）：占比10%. 三、自动化测试最佳实践对现阶段公司大部分团队来说，更符合实际测试模式是纺锤模型。新项目中，可能由于时限原因或者开发人员习惯问题，一开始并没有把单元测试准备得很完善；而某些遗留老项目，可能原本就没有多少单元测试。 在上述情况下，一般的做法是先将重心放在中间层的测试上，原因有以下两点： 第一，中间层投入产出比较高，可以实现较高的自动化率；第二，可以帮助加强开发跟测试人员之间的协作，提高测试质量。这一层需要开发跟测试人员共同定义，因为开发知道内部实现的细节，测试掌握业务场景。 3.1 纺锤型向金字塔型过渡当项目进行一段时间以后，各层测试占比有必要向理想型的金字塔型过渡，这时需要关注以下三个方面： 开发与测试互相传递能力；全员关注产品设计跟代码的质量；让用例逐步下沉，最后逐步过渡到理想型。 3.2 测试质量评估关于度量，不要用单一的指标去评估测试和产品质量，比如用例通过率、代码覆盖率等都无法独立地评估产品质量。 评估测试质量时要关心以下几个方面： 第一是用例比例，即每一层的用例比例是多少。第二是测试覆盖率。第三是测试总运行时间，因为经过优化以后，总运行时间一定是越来越少。第四是代码质量指标，反映代码的质量和整洁度。四、自动化测试面临的挑战引入自动化测试可以为团队带来很多好处，当然自动化测试也有其自身的缺点和挑战。面临的最大挑战就是变化，因为变化会导致测试用例运行失败，所以需要对自动化脚本不断debug。如何控制成本、降低成本是对自动化测试工具以及人员能力的挑战。 另一个值得注意的是，自动化测试不能完全代替人工测试，一定的人工探索测试也是必不可少的。我们一直在不懈努力和探索，本文为自动化测试最佳实践系列文章的第一篇，重点介绍了自动化测试的现状和金字塔模型，接下来的系列文章中会继续为大家介绍我们的自动化测试实践，包括自动化测试平台的核心功能、持续测试的方法与工具等。 ...

摘要： 本文将从支付宝业务特性出发，深度解析无线实验集群在支付宝的演进与发展，并探讨 IoT 与人机如何交互并提供真正落地的时间方案。作者：周力（问瑾），蚂蚁金服技术专家。本文将从支付宝业务特性出发，深度解析无线实验集群在支付宝的演进与发展，并探讨 IoT 与人机如何交互并提供真正落地的时间方案。 现场视频（复制地址到浏览器中打开）：http://t.cn/AiKDZg5G 0. 背景作为国民级 App，支付宝客户端需要为亿级用户提供多元化的服务，因此应用的稳定性与可靠性面临巨大的挑战，需要不断地完善和优化。 今天，让我们站在服务质量的全方位监控与优化的角度，从蚂蚁终端实验室的演进之路展开探讨，从借助使用开源的自动化方案，到自研并逐步完善无线实验集群技术体系，支付宝内部经历了怎样的业务场景演练，以及相应的技术架构如何借助移动开发平台 mPaaS 对外输出。 1. 发展历程 总的来说， 蚂蚁终端实验室从诞生到现在，一共经历过三个阶段（工具化、服务化以及中台化），其每个阶段都有特点和意义： 工具化阶段：该阶段主要以使用市面上主流开源软件为主，如客户端开源软件 Appium， 其覆盖的端为 Android 和 iOS；通过这种开源工具和 App 测试流程结合的方式，快速满足业务方的提测需求，从而帮助业务方完成一般意义上的自动化测试工作（如基本的功能测试、兼容性测试等）。 服务化阶段：服务化阶段存在一个重要的背景：支付宝着手前后端研发流程分离，并逐步沉淀出独立的 App 端研发流程系统（研发协作流程与 App 构建流程）。在独立的 App 研发流程和系统的基础上，终端实验室以一种服务化的形式支撑 App 的研发和协作， 处理满足日常用户自动化工作外，同时还担当着持续集成、日常发布前自动验包工作等； 另外在日常发布发布提供质量数据支持，如客户端代码覆盖率统计等。 中台化阶段：伴随着终端实验室的能力不断提升优化以及测试规模的逐步扩大，服务上不仅需要满足蚂蚁金服体系 App（支付宝、口碑、网商银行等）日常测试需求，而且还需要将能力扩散覆盖到整个阿里巴巴集团的业务。 随之而来的是实验室需要面临多样化的业务方需求和定制化功能，如何在多元复杂的业务环境中，与业务方或者说上游系统完成能力共建？带着这个问题，终端实验室逐步沉淀并着手建设中台化平台：一方面让通用服务不断下沉，另一方面抽象出标准 SDK 的方式，让业务方根据自身业务特点建设特定的能力。 此外，在建设平台化的同时，终端实验室贴合支付宝业务场景的发展，构建如网络实验室、扫码实验室等一系列真实实验室的能力。 经历了几年的不断发展，终端实验室逐步完成了中台化的转变，其端上覆盖了 Android、iOS 以及 IoT 设备，服务上覆盖了通用能力、小程序准入、研发流程建设、真机租用以及用例管控等。 2. 技术生态在了解完终端实验室的历程之后，我们能够对其提供的服务有一个全面的认识。当我们去总结和分析这些服务时，可以把这些具体能力分为三大块：平台服务能力、客户端SDK 以及 实验室能力。 平台服务能力平台服务能力的目标是聚焦“如何把蚂蚁实验室构建成一个更为开放的平台”，因此我们需要考虑到如何让更多的业务方和上游系统一起参与能力共建，从而将平台的建设思路分为 2 大部分：设备实验集群和开放SDK。 1. 设备集群 蚂蚁实验室不仅包含数以千计的公用终端设备，覆盖市面绝大多数手机终端，帮助业务同学完成日常自动化测试工作，而且提供了用户自建实验室的方式：用户只需要根据自身业务场景特性进行设备采购、实验室部署，便具备在自有平台上运行自有设备的能力。 从平台的开放性与部署动态化角度看，目前设备集群能保证设备归属和业务场景做到充分隔离，保证各业务在平台使用上能相互独立。另外，面对阿里巴巴集团众多研发中心，设备集群在部署上也支持多地部署、相互隔离。 2. 开放SDK 为了给上游系统和用户提供更为开放的能力，帮助业务方根据自身需求完成能力建设。终端实验室提供开放的 SDK 能力：上游系统只需在自己服务上接入 SDK，就能够完成任务构建链路，从用例管理、设备选择、任务执行，到执行结果回调，在此基础上用户就能够根据自身业务特点将业务数据进行多维度组合，形成自己的能力输出。 ...

阿里妹导读：业务的快速发展，需要我们更快速地响应，和更高质量产品的交付。如何从原来大(xiao)迭(pu)代(bu)的开发模式切换为精益开发模式？以 2-1-1（2周需求交付周期，1周需求开发周期，1小时集成时长）为愿景驱动改进，达到持续交付价值，响应业务要求成为我们的目标。今天，闲鱼工程师琪钰为我们分享：闲鱼是怎样朝着这一目标前进的？切换为精益开发模式后，又面临了哪些问题和挑战？名词解释：精益开发模式，团队基于看板组织协作，以持续地交付需求为目标，需求按优先级，逐步进入开发、提测。由于在项目协作中，采用看板泳道来管理需求，因此在闲鱼，同学们习惯称之为泳道模式。 1、我们面临的要求和挑战业务对交付响应时间要求越来越快。闲鱼业务正处于高速发展中，反摩尔定律告诉我们，交付越迟，商品价值打折得就越厉害。速度为王，为了满足业务快速迭代和试错对技术团队能否快速交付需求提出了更大的挑战。团队规模变大，项目沟通成本越来越高。随着闲鱼业务和技术的快速发展，交付的环境也越来越复杂，协作的角色越来越多。整个研发过程包含需求管理、开发、测试、发布、回归等关键活动，涉及aone（研发协作平台，主要是需求、bug管理等）、代码库、打包平台、自动化测试平台等多个系统，沟通协同的成本越来越高。多分支并行开发增加额外成本。项目开发切换为精益开发模式最核心的改变就是各需求是独立的互不影响，可以分别独立进行测试和集成，保持主干的稳定，随时拉发布分支进行灰度发布。但多分支并行开发，也带来了新的问题，原来打包配置、手动打包、安装测试包等人工成本，都成倍的增加。随时来的提测都能够测。之前客户端发布版本时间固定，批量开发、批量提测，测试介入比较晚。项目开发切换为精益开发模式对技术质量团队提出了更高的要求，面对多需求同时提测的情况，如何更快地响应测试。所以，构建一个贯穿从需求到代码开发，再到测试整个过程的流程，并将其工具化、自动化就显得十分必要和紧迫，而持续集成就是这一流程的重要形式体现，构建一个高效的持续集成系统摆在我们面前。这将一定程度降低开发过程中的沟通成本，流程工具化，加速自动化。 现在针对服务端的集成发布有很多可以参考的实践，但对客户端的集成发布来说，我们依然面对如下难点。 2、客户端持续集成的难点如何将研发过程中各环节关联起来，一个需求从创建到发布的关键活动如下：创建需求->创建代码分支->创建打包项目->提交代码->打包->提交测试->修复->提交集成->发布如何做到需求和代码分支关联，确保代码可追溯； 如何做到代码分支和打包项目关联，代码变更可自动触发打包； 如何做到代码范围和测试范围关联，确保测试回归范围。 多分支并行，如何有条不紊的进行集成。并行需求分支越多，意味着提交集成时，可能的冲突的概率就会越大。如何降低集成的冲突，以及集成后主干的稳定性，确保集成质量；如何做到一提交代码就触发测试，测试进一步左移；如何降低自动化测试的成本，提高测试效率；而要解决上面的这些难点，缺少一站式的工具平台支撑（集团内平台对服务端的发布有很好的支持，但对于客户端的集成发布来说，涉及平台工具比较多）。 3、怎么做客户端持续集成为了解决从需求创建到发布整个项目研发过程中协同、构建、集成和测试等遇到的问题，提高团队的持续交付能力。针对客户端集成发布，我们的整体方案的目标是首先是拉通整个需求交付流程中各个环节，简化持续交付工作，提供及时的质量反馈机制，让开发同学关注在业务的开发；有效提高集成成功率及缩短集成发布周期，让版本能够按时上线大家能够按时下班；建设可视化、自动化、智能化的持续集成流水线，让业务需求真正的可持续交付。 空谈误国，实干兴邦。在谈论更多的改进之前，我们先把基础本的流程通过工具先串起来，只有先看到整体，然后再发现问题逐步改进。 流程化 我们的核心流程是这样的，一旦创建需求分支，交付通道就已建立，直到需求发布。 首先开发按照规范创建需求分支后，自动将分支和需求进行绑定，同时创建打包项目后，自动将需求和打包地址进行绑定，这样开发同学一旦提交代码，就可以根据需求、代码提交内容等，给出影响范围，同时自动触发打包，开发和测试同学不用再担心最新的包中是否有刚提交的内容，每次变更都会触发打包；打包成功后，根据 merge request、push 定时等不同的触发方式，及分支类型，自动触发相应的测试件，进行一系列的自动化测试；测试件执行完后，执行结果将被及时反馈出来，确保每次代码变更都是经过测试验证的，测试进一步左移，并将问题在团队项目协作看板上将问题标示出来，帮助团队在项目协作中能够持续的发现问题从而提高集成质量，降低发布风险，保证业务更快更顺畅的交付。当完成了第一步，将整个流程打通之后，我们发现，在整个流程中，依然有很多是依赖人工操作的地方，这是最容易出错，并且极低地影响效率的地方，对我们来说，这是改进的机会，所以，第二步我们的重点就是做好无人化和自动化。 无人化 为了支撑持续集成流水线的运行，以无人化、自动化、可扩展为目标，及基于最小研发成本原则，我们做得事情主要分为精益开发流程协同支撑无人化及测试验证自动化两部分。 fish CI 主要是研发流程支撑，如需求绑定、监听变更、触发打包、触发测试等，fish guard 主要测试件调度、执行，结果通知，及后续测试件接入扩展部分。目前已接入的测试件主要有 UI 遍历、UI 识别、monkey、单元测试等。后续计划按照分层测试的原则，接入更多的测试件，如代码静态扫描、weex 自动化测试、服务端测试件等，增强测试件覆盖度，拓展自动化测试边界。关于这一部分，我们将在后面的文章中做更深入的分享。 数据度量 管理学之父彼得德鲁克说：“如果你不能度量它，你就无法改进它”，其实也是我们整个持续集成流水线的自检，我们到底做得怎么样，持续交付的能力如何，我们定义了如下指标用于后续统计。 指标主要分为响应能力、效率、质量三个维度，通过响应能力的这些指标，可以反应出打包变快了，质量反馈变快了，集成变快了，集成频率变高了；有效率的指标，反应出流水线工作的有效性，成功率越高说明流水线越稳定；最后质量，主要从代码质量和项目测试质量来度量，通过修改的文件数，模块分布可以反映出代码的拆分、依赖等情况；通过项目测试中 bug 的分布和库存，可以反映出项目质量情况，是否及时发现及时修复，是否达到发布标准等。 4、效果闲鱼从3月中旬开始试运行精益开发模式（持续交付模式）到现在，闲鱼所有的业务需求全部走精益开发模式，我们交付的速度，由一个月一个版本到两周一个版本。这离不开我们在流水线各个环节中的改进，如打包变快了，需求分支构建次数越来越多，集成频率越来越高，以及自动化测试验证及时反馈集成质量情况。此外，闲鱼在精益开发模式下质量获得了明显提升，如下图所示： 绿色分割线左半部分，是之前未切换到泳道模式前的一个版本，bug 趋势看，前面编码阶段，测试基本未介入，大量的代码批量集成后集中测试，在缺陷充分被移除后，才能交付，无法持续交付。绿色分割线右半部分，是某个业务线的缺陷趋势图，小批量的持续集成、及时测试和发现问题、及时修复，可以快速持续交付。 5、总结与规划简单总结下，我们做的事情，第一步是拉通整个交付过程，有一个稳定的交付过程，第二步保证交付的效率，即响应变快了，集成变快了，质量反馈变快了，第三步持续交付，关键词是“持续地”，频次上提出了更高的要求，集成的频率变高了，以前一个月集成一次，现在每天都能集成，从一个月一次，到 nightly build，再到随时集成。即相比以前，让开发同学“更”有信心集成一次变更并发布。 因此，我们的终极目标就是7*24随时发布，没有发布窗口限制，真正做到交付流水线自动化无人化和全自动化测试，降低持续构建成本，拓展自动化测试边界。 本文作者：琪钰阅读原文 本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

闲鱼Flutter技术的基础设施已基本趋于稳定，就在我们准备松口气的时候，一个Crash却异军突起冲击着我们的稳定性防线！闲鱼技术火速成立侦探小组执行嫌犯侦查行动，经理重重磨难终于在一个隐蔽的角落将其绳之以法！ 幽灵Crash问题要从闲鱼Flutter基础设施上一次大规模升级说起。2018年我们对闲鱼的Flutter基建作了比较大的重构，目标在于提高基建的稳定性和可扩展性。这个过程当然是挑战重重，在上一次大规模的重构集成发版后，我们虽然没有发现非常明显的异常问题，但是Crash率却出现了一个比较明显的增长。虽然总体数值还在可控范围之内，但这一个Crash却占据了几乎一大半。这个问题引起了我们警觉，我们立刻成立专项小组重点进行排查。 一般Crash Log能够为我们定位Crash提供主要信息，我们一起看看这个Crash的Log: Thread 0 Crashed:0 libobjc.A.dylib 0x00000001c1b42b00 objc_object::release() :16 (in libobjc.A.dylib)1 libobjc.A.dylib 0x00000001c1b4338c (anonymous namespace)::AutoreleasePoolPage::pop(void*) :676 (in libobjc.A.dylib)2 CoreFoundation 0x00000001c28e8804 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ :28 (in CoreFoundation)3 CoreFoundation 0x00000001c28e8534 __CFRunLoopDoTimer :864 (in CoreFoundation)4 CoreFoundation 0x00000001c28e7d68 __CFRunLoopDoTimers :248 (in CoreFoundation)5 CoreFoundation 0x00000001c28e2c44 __CFRunLoopRun :1880 (in CoreFoundation)6 CoreFoundation 0x00000001c28e21cc _CFRunLoopRunSpecific :436 (in CoreFoundation)7 GraphicsServices 0x00000001c4b59584 _GSEventRunModal :100 (in GraphicsServices)8 UIKitCore 0x00000001efb59054 _UIApplicationMain :212 (in UIKitCore)9 Runner 0x0000000102df4eb4 main main.m:49 (in Runner)10 libdyld.dylib 0x00000001c23a2bb4 _start :4 (in libdyld.dylib)这是一个很典型的野指针Crash Log，是其中一种俗称的Over released问题。但是具体是哪个对象和方法，很难直接从Log上面得知，况且ARC下面的野指针更令人费解。 ...

移动应用安全近几年越来越被重视，目前针对移动端的应用也越来越多，每天有大量的数据从移动端发出，部分数据在移动端进行处理，移动应用安全在今天显得尤为重要，那么如何能及时发掘移动APP的潜在漏洞，以免被攻击者利用造成破坏呢，渗透测试是目前发掘漏洞的有效方法。一、交叉测试 又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。 例如通话过程中接收到短信或闹铃触发，应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。另外，还需要注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级较低的事件吊死。 交叉事件测试非常重要，一般能发现应用软件中一些潜在的问题。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题（这个主要针对手机应用软件支持语言自适应功能），这一点通常会被测试人员忽略。 二、易用性/用户体验测试 易用性（Useability）/用户体验是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力，是交互的适应性、功能性和有效性的集中体现。 手机操作主要依赖拇指，所以交互过程中不能设计的太复杂，交互步骤不能太多，应该尽量设计多点快捷方式，易用是对终端软件（推而广之是交互类软件）最基本、最重要的要求。 不好用的软件很难吸引用户，更别提提升用户对软件的忠诚度了。 易用性体现在：所见即所得、一用便知、一学就会，方便快捷的完成预期功能。易用的软件能让一个新用户快速学习、使用我们的软件，并在使用软件过程中体现我们的贴心服务，超出用户预期的体现是我们追求的目标。 三、功能测试 首先应分析功能模块的功能项，测试每个功能项是否能够实现对应的功能。一般根据测试用例（Test Case）或软件本身的流程就可以完成基本功能测试（相对简单，故障也较容易发现、解决）。 **获取最新测试相关资料，视频，工具等你来领百度云获取资料点他????链接: 提取码: esyd** 四 、压力测试又叫边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功能的最大容量、边界值或最大的承载极限，仍然对其进行相关操作。例如连续进行短信的接收和发送，超过收件箱和SIM卡所能存储的最大条数，仍然进行短消息的接收或发送，以此来检测软件在超常态条件下的表现，进而评估用户能否接受。　对手机可以施加的压力测试类型主要有： 1）存储压力由于手机采用的是栈式存储，所以当一个存储块满了之后，如果程序员不做相应处理或者处理不好的话，很容易造成其他存储区被擦除，从而在UI上出现问题（比如其他功能无法正常使用，出现异常）。　2）边界压力边界处理一直是程序员最容易忽略的地方。 3）响应能力压力有时候某个操作可能处理的时间很长，在处理期间如果测试者再不断地进行其他操作的话，很容易出现问题。　4）网络流量压力执行较大数据流量的功能的同时，再进行其他功能操作，使得网络流量始终处于很高的状态（如视频通话时再进行短信等其他功能操作），验证各功能是否依然能正常工作，是否存在因网络流量瓶颈而引起某功能异常。　压力测试用手工测试可能很繁锁，可以考虑自动化测试。遗憾的是，目前还没有较为大量使用的工具，一般都是由开发人员配合开发出的工具，或者高级的测试人员编写出的脚本。　五、兼容性测试也就是不同品牌、款型的手机（针对目前我们产品来说，主要是针对不同品牌、款型的手机上的测试），不同网络，不同品牌和不同容量大小的SIM卡之间的互相兼容的测试。不同型号的手机支持的图片格式、声音格式、动画格式不一样，需要选择尽可能通用的格式，或者针对不同的型号进行配置选择。以短消息为例：中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息，需要验证显示和回复功能是否正常等。再比如，应用软件分别在OPPO R7、OPPO A3手机上运行，各功能是否均能正常使用，界面是否均显示正常等。**获取最新测试相关资料，视频，工具等你来领百度云获取资料点他????链接: 提取码: esyd** 六、暴力测试断电，重启，断网等意外情况发生时，处理是否正确 七、容量测试即存储空间已满时的测试，包括手机用户可用内存和SIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试，如果软件在极限容量状态下处理不好，有可能导致死机或严重的花屏等问题的出现。 以上建议仅供参考！【乐搏软件测试】【乐搏学院】如有侵权请联系，立即删除

结合了工作经验，写出了这篇文章，是从功能测试转向自动化测试的学习过程。用您5分钟时间阅读完，希望能对您有帮助！ 什么是自动化测试？ 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。 为什么做测试自动化？ 1）对个人来说随着时代科技的进步，越来越多的工作偏向于了自动化，软件测试当然也不例外。从发展的趋势来说，只有不断的提升自己，面对各种变化，才可以追上科技的进步。手动测试虽然是基础，但是企业不会在乎你的过程。只有高效率的工作才会让企业觉得你更有价值。自动化测试是软件测试的主流，也是软件测试的高薪专场！ 2）对企业来说为什么企业做自动化测试，从现在的情况来看，互联网需求迭代非常快，人员流动性非常大，所以工作时间比较紧迫，要在规定时间内提高工作效率，所以一个需求从提出到上线时间比较紧急，同时对于其影响的范围也可能不太清楚，在上线之前必须对原有功能进行回归测试。不管是接口还是从客户端，都需要大量的测试工作，而且在大数据时代，测试用例量也是非常庞大的，如此繁复单调的工作让人工来测试的话，根本不能保证效率和质量，所以必须要借助于非人工手段来实现。 怎么才能算合格的测试工程师呢？ 自动化测试工程师细分可以有UI自动化测试工程师，APP自动化测试工程师、接口自动化测试工程师等等。 首先，掌握一门编程语言，应该以Java或者python为主，虽然什么语言都可以用来做自动化测试，但毕竟这个两个是最流行的，如果想成为自动化测试工程师里，最主流的测试工程师，还是强烈推荐大家选择这两门语言。 然后，掌握主流的框架，如：selenium，appium，monkey，monkeyrunner之类的，基本上掌握了这个几个APP和UI自动化都可以玩的转了。 自动化测试工具有好多种，分享给大家这些，希望对你能有帮助！ **获取最新测试相关资料，视频，工具等你来领百度云获取工具点他????链接: 提取码: esyd** 1、SoapUI-接口测试 SoapUI是一个非常流行的用于SOAP和REST的开源API测试自动化框架。它还支持功能测试、性能测试、数据驱动测试和测试报告。 2、QTP-WebUI自动化测试 QTP是一种自动测试工具。使用 QTP 的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。QTP针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。 3、Postman-接口测试 Postman 提供功能强大的Web API和HTTP请求的调试，它能够发送任何类型的HTTP请求 (GET, POST, PUT, DELETE…)，并且能附带任何数量的参数和Headers。不仅如此，它还提供测试数据和环境配置数据的导入导出，付费的Post Cloud用户还能够创建自己的 Team Library用来团队协作式的测试，并能够将自己的测试收藏夹和用例数据分享给团队。**获取最新测试相关资料，视频，工具等你来领百度云获取工具点他????链接: 提取码: esyd** 4、Monkey-稳定性测试 软件附带在sdk中，适用于android和ios，通过adb shell，生成用户或系统的伪随机事件。压力测试结果：崩溃crash，无响应anr，基本命令：adb shell monkey 1000。 5、Jmeter-接口测试，性能测试 Apache JMeter是一个开源的Java桌面应用程序，主要用于web应用程序的负载测试。它还支持单元测试和有限的功能测试。它有很多好的特性，比如动态报告、可移植性、强大的测试IDE等，并且支持不同类型的应用程序、协议、shell脚本、Java对象和数据库。 6、Robot Framework-WebUI自动化测试，接口测试 Robot Framework是一个开源自动化框架，它实现了用于验收测试和验收测试驱动开发（ATDD）的关键字驱动方法。Robot Framework为不同的测试自动化需求提供框架。但是，通过使用Python和Java实现其他测试库，可以进一步扩展其测试功能。Selenium WebDriver是Robot Framework中常用的外部库。测试工程师可以利用Robot Framework作为自动化框架，不仅可以进行Web测试，还可以用于Android和iOS测试自动化。对于熟悉关键字驱动测试的测试人员，可以轻松学习Robot Framework。 7、LoadRunner-性能测试 LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。 以上建议仅供参考！【乐搏软件测试】【乐搏学院】如有侵权请联系删除

结合了工作经验，写出了这篇文章，全是干货和经验分享。用您5分钟时间阅读完，希望能对您有帮助！相信很多人都喜欢用浏览器看网页，虽然网民不是专业人员，但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会就会明白的。 Web界面设计中，对各种元素（如按钮、单选框、复选框、列表框、超连接、输入框等等）的设计是非常重要的。一、搜索功能 若查询条件为输入框，则参考输入框对应类型的测试方法 1、功能实现： （1）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到 （2）比较长的名称是否能查到 （3）输入系统中不存在的与之匹配的条件 （4）用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明。 2、组合测试： （1）不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错） （2）测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错。 二、添加、修改功能 1、特殊键：（1）是否支持Tab键 （2）是否支持回车键 2、提示信息： 不符合要求的地方是否有错误提示 3、唯一性： 字段唯一的，是否可以重复添加，添加后是否能修改为已存在的字段（字段包括区分大小写以及在输入的内容前后输入空格，保存后，数据是否真的插入到数据库中，注意保存后数据的正确性） 4、数据 正确性： （1）对编辑页的每个编辑项进行修改，点击保存，是否可以保存成功，检查想关联的数据是否得到更新。 （2）进行必填项检查（即是否给出提示以及提示后是否依然把数据存到数据库中；是否提示后出现页码错乱等） （3）是否能够连续添加（针对特殊情况） （4）在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没（注意要添加和修改规则是否一致） （5）对于有图片上传功能的编辑框，若不上传图片，查看编辑页面时是否显示有默认的图片，若上传图片，查看是否显示为上传图片 （6）修改后增加数据后，特别要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新。 （7）提交数据时，连续多次点击，查看系统会不会连续增加几条相同的数据或报错。 （8）若结果列表中没有记录或者没选择某条记录，点击修改按钮，系统会抛异常。 三、删除功能 1、特殊键：（1）是否支持Tab键 （2）是否支持回车键2、提示信息：（1）不选择任何信息，直接点击删除按钮，是否有提示（2）删除某条信息时，应该有确认提示3、数据 实现：（1）是否能连续删除多个产品（2）当只有一条数据时，是否可以删除成功 （3）删除一条数据后，是否可以添加相同的数据（4）如系统支持批量删除，注意删除的信息是否正确 （5）如有全选，注意是否把所有的数据删除（6）删除数据时，要注意相应查询页面的数据是否及时更新 （7）如删除的数据与其他业务数据关联，要注意其关联性（如删除部门信息时，部门下游员工，则应该给出提示）（8）如果结果列表中没有记录或没有选择任何一条记录，点击删除按钮系统会报错。 四、输入框 1、字符型输入框 （1）字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。 （2）长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。 （3）空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格 （4）多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示） （5）安全性检查：输入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）输入脚本函数(<script>alert("abc")</script>)、doucment.write("abc")、hello） 2、数值型输入框 （1）边界值：最大值、最小值、最大值+1、最小值-1 （2）位数：最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数 （3）异常值、特殊字符：输入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]:"<>?;',./?;:'-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等。输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字，数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）。 （4）安全性检查：不能直接输入就copy 3、日期型输入框： （1）合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入30、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13] （2）异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&*（）{}[]等可能导致系统错误的字符 （3）安全性检查：不能直接输入，就copy，是否数据检验出错？ 4、信息重复在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理. 10G海量软件测试相关资料，视频，工具等你来领 百度云点他????链接 提取码: esyd 五、Web测试注意事项都有哪些！1.页面提示信息 主要是对页面操作结果成功或失败的提示信息，还有用户在做一些关键操作或者是涉及敏感操作时系统是否会有提醒。 2.页面功能部分 （1）页面初始数据是否显示正确 （2）页面数据处理功能是否被正确执行并返回正确结果 （3）对模块的功能测试时可以列出该模块的所有实现功能进行排列组合，比如页面基本的增删改查功能： 增加-->增加-->增加（连续增加测试）；增加-->删除-->增加（之前删除内容）；修改-->增加（修改之前内容） 3.页面中元素显示 ...

从事测试开发那么长一段时间，一直不知道怎么去评价和衡量这个职业的目标是什么，超高的自动化测试覆盖率？或者超稳定超包容的自动化测试框架？ 怎么才算得上是一个优秀的测试开发人员？上周有机会去听了阿里2天的公开课，好像明白了一些，拿来跟大家分享一下。 内建质量在微软有一句名言：“质量是设计出来，而不是测出来的。” 当然，这是理想情况，如果产品经理都这么优秀，这个世界早就和平了。 今天我们不说产品经理，我们从测试和开发的角度看，怎么内建质量。 让测试内建质量为了内建质量，测试同学就要尽可能早地干预开发写bug，让bug死在摇篮里。换句话说就是让开发不要写出可以避免的bug： 产品，开发，测试应该同时参与需求评审会议，澄清需求，达成共识将关键测试点作为需求的一部分，让开发同学交付需求时完成自测让开发内建质量从开发的角度看，要提高代码的质量可以有很多种方式： 提高自测意识，借助单元测试或者质量分析工具真正理解需求和技术架构，进行Code Review或者结对编程评估代码质量或者bug数量，跟绩效挂钩排除开发的自身能力问题，80%的bug都是需求理解不准确的问题，如果开发不愿背这个锅，那就甩给产品经理吧。 由此可见，如果测试不想看见这些bug，那么你就要帮产品表达需求，帮开发理解需求。 测试左移上面我们说内建质量其实已经涉及到了测试左移，例如让QA在参与需求研讨时提出问题，列出测试点其实已经开始在进行测试了。 为什么我们要测试左移呢？因为发现问题的时间越晚，修复的成本就越高。 图中橙色线条代表了传统测试发现缺陷的时间，大多数bug都是在功能测试和集成测试时发现的，最后导致的结果就是发布前加班加点，祈祷不要有bug漏到生产环境。 如果我们能把测试活动向左移动，那么就意味着修复成本大幅下降。 但是谈何容易？想要把大部分测试点放在单元测试环境完成，非常依赖成熟的开发环境和极其资深的开发人员。 在阿里是这样实践的，让测试给开发赋能。 开发赋能从字面上解释就是，测试同学给开发赋于一定的能力，让他们有能力去完成测试，比如： 降低测试门槛使用测试工具（自动化）获取测试数据培养测试意识举个例子，开发同学在完成需求代码后，可以点击一个按钮得到测试数据，再点击一个按钮验证测试覆盖点，喝杯咖啡后就可以看到测试报告。 从上面这个例子看，开发同学其实他并不需要懂测试数据的设计，自动化测试的开发，测试报告的编排，但是他依然可以快速完成需求测试（门槛低），只要他养成习惯（培养意识）。 那么你就会说，这对测试的同学要求是不是很高啊？对啊，回到开篇的问题，如何评判一个测试人员的能力？在我看来就是评判他给开发和团队赋能的能力。在阿里是这样，在微软和谷歌也是这样。 一个优秀的测试人员将测试左移时，并不会将负担转移给开发。相反地，而是帮开发写出更高质量的代码，更高效率地交付需求。 那么测试能左移到什么程度呢？比如让开发在Coding时就发现问题，或者还没Coding就发现问题，那应该是极好的。 怎么做到呢？刚才已经说过了，测试即需求，把bug扼杀在摇篮里。 实践方法想实践测试左移可以有很多种方法，每个组织需要根据实践情况进行裁剪和调整。 参与需求评审，帮助开发理解需求参与架构、设计分析，提早预防问题践行BDD，TDD单元测试提案，接口测试提案提供模拟数据能力，测试工具制定提测标准，拒绝低质量代码回归测试自动化静态代码分析，单元测试覆盖率测试左移的概念给整个测试角色带来了巨大的转变。软件测试不仅仅是“发现bug”，而是致力于“尽可能早的检测和预防bug”。 参考资料培训课件： 阿里Devops体系和实践.svg参考文章：What is shift-left testing?关于作者：Toby Qin, Python 技术爱好者，目前从事测试开发相关工作，转载请注明原文出处。 欢迎关注我的博客 https://betacat.online，你可以到我的公众号中去当吃瓜群众。

大学是学经济贸易的，由于对测试行业的强烈兴趣，毕业后选择了一家线上教育机构培训软件测试技能。在工作不到两年的时间里，已经从测试员升职到测试主管了。这两年也戒掉了对烤肉类食物的痴迷，从小胖胖锻炼成马甲线女神，这段经历很充实也让我觉得很有成就感。对于学习、工作，积累了许多点点滴滴的自己的经验，希望能帮助到大家走入测试行业：兴趣、知识说实话，我做测试工作的时间不是很长，学完软件测试工程师的课程后，到现在也就是两年多的时间吧，不过，我愿意自己学习和工作中积累起的这些点滴与大家分享。我走入测试行业完全是因为兴趣，兴趣产生学习和工作的热情，真的是一点都不假。从我选择走入这个行业，学习、工作，从测试员到测试主管，我都是快乐的，也很充实，很有成就感。我觉得，在决定走入测试行业后，就要在这方面多做准备和积累，首先要有坚实的测试理论基础，这些知识不仅是学习的时候要学的扎实，在以后的工作中还要继续不断的完善。其次，要有一定的行业知识。毕业后找工作时，有做手机测试的，也有做外包测试的。我做的是ERP产品。大家都知道，ERP (Enterprise ResourcePlanning)就是企业资源计划系统，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。我在学习测试专业前曾接触到ERP，所以，在毕业的找工作的时候就往这方面发展了。说到找工作，我觉得精心制作简历是一方面，同时还要有灵活的面试技巧。有时还要把在生活中学到的东西应用到面试中去。我记得我第一次去面试的时候比较凑巧，面试前的头天晚上我在电视里刚好看到一个和面试有关的节目，结果，第二天在我自己去面试的时候就被我用到了。当时是在问到薪金待遇时。我觉得这是很多人包括我自己在面试时都会觉得是比较头疼的问题，因为，说的多了，不行；说的少了，也不行。这时，你就要用一些技巧了。这时你可以先试探性的询问对方公司在招聘这个职位的时候是怎么规定的？等你了解了这些后，你再就自己的技术能力来衡量相应薪金的比价，另外就是看这个公司的实力，还有一点就是行业内这个职位的大致待遇情况。这样的话，在你说出你对薪金的要求的时候，如果，应聘的公司较小，但是还是存在一定发展空间而且你也想试试的情况下，你要得工资低，对方会考虑到可能是你已大致了解了公司的实力所以才开出这样的条件，而不是你自己的技术不行；如果你看到这个公司的状况还是比较好的，是家有一定实力的公司，这时，你可以适当抬高自己的身价。我的应聘还是比较顺利的，第一天应聘，第二天就上班了。我记得当时面试的时候大约谈了两个半小时，就一次性面试过关。另外我自己也比较引以自豪的是我是我们公司唯一一个在两个月之内转正的。初来乍到：熟悉环境，尽快融入开始进入公司的时候首先要熟悉公司的环境。在一些大的公司可能会给大家熟悉环境的时间，还会安排一些相应的培训什么的。我当时进的那家公司比较小，没有什么相关的培训，当初只是我们部门经理拿来一些相关的资料，文档，让网管给配置工作环境。不过小公司有小公司的好处，他会很快让你介入到工作当中，给你分配任务。所以，你必须尽快的在一到两周之内熟悉公司各个方面的环境，尤其是人员环境。我觉得人际关系在整个公司里面也是很重要的一方面，夸张一点说甚至是比你的本职工作还要重要的。因为，掌握技术是你智商方面的问题，而与人交往就不是那么简单，因为我们的兴趣、爱好可能差别很大，性格也有内向和外向的，所以在进入社会步入工作岗位后与人交往真的是很考验一个人。如果你在公司人际关系搞得好的话，工作各方面的协调顺利，工作的进展也会很顺利。还有就是要尽快的熟悉公司的测试环境，操作系统、开发语言、平台，接着就是要了解公司的产品，掌握产品相关的知识。像我们公司是自己研发的经销群、财务这样的一个系统。你要了解公司产品的时候，可以向产品研发部，或设计部要些相关的说明文档，尽快的介入这个行业，熟悉自己要做的测试项目。说实话，我是学习经贸专业的，不是学计算机的，所以我当初的时候有点晕，我就直接拿着产品自己在那儿摸索，自己写出一个产品使用说明。向这样的事情，可能在大的公司会有专门的配选，在小公司可能就要自己学习产品了。不过，我觉得这样是挺锻炼人的，又发掘了你另一方面的潜能呢。尽可能多的参加研发部的会议员工间的技术交流。在我们公司像这样的会一周大概要有一到两次，大家相互交流工作进展情况，或者是一些相关的技术方面的交流。不一定是非常正式的，但我感觉这样的会议是非常有必要的。还有就是公司研发部召开的会议，你也要一定要也应该的介入、参加。我当初介入最早的是他们的研发意向，然后他的一些需求调研啊，还有其他的一些设计啊等等一些会议。像这样的会议我觉得是一定要抽出时间来参加的，因为这确实是对你的工作有很大的帮助的。因为在立项会议上，你可以了解项目的可操作性，以及项目的特点；在调研会议上，了解需求，市场需求是开发的依据，也是测试的依据。同时一定要参加需求更改会议，以便你更好的进行测试工作。在这些都做到位后，我们就开始写测试计划了。测试计划写测试计划就像我们在课堂上学到的那些，测试计划、测试用例，开始我们的测试流程。这时就是具体应用的时候。写测试计划的时候要跟研发部要详细设计文档、产品规格说明书和需求调研的说明（产品使用说明）这样的相关文档。如果在大公司的话，他的设计部会写产品使用说明或者是一些测试规约。还有就是一定要他的开发计划，因为你做每一步测试是根据开发进度来进行的，开发计划是必不可少的。最后根据上述的文档，从时间、内容、资源、所用工具，还有人力安排，这样一份简单的测试计划已经成形。像一般小的公司，他会对哪个人在哪天完成那项工作是很关注的，像我们原来学的那种比较完整的文档，在这样小的公司是需要变通的，因为他们也没有很多的人力物力没有很多的时间去看那样的文档。编写测试用例首先要根据产品的特点编写。你的产品的特点在产品没有成型之前，你肯定不是特别了解也不是特别清楚，但是你可以根据它的框架大概的给搭出来，你能想到的尽量给细化写到文档里面，然后在测试过程中不断的完善。如果在测试执行的过程中突然间发现一个比较好的测试用例，一定要及时给补充进去，你不给它补充上去是你的一大损失，因为你以后的工作中可能还会需要这样的文档，或者以后接手你工作的人，他可能会看到这个文档，这对他以后的工作也会有很大的帮助。在大的公司有专门的测试设计人员来编写这些东西，在小公司就是测试主管或者测试员编写。像我们公司从测试用例、测试计划、测试执行什么的都是我来做的。当初是因为公司比较小，我自己做，本来是给我招了一个助手，也就用了大概一两个月吧。我个人的感觉是除非你招特别熟练的，对行业，对测试技术各方面都比较熟悉的，一来就能上手工作的还行。如果不这样，招一个刚毕业的应届生，他对测试行业不是很了解，而小公司人手本身就少，你根本就没有时间给他做培训，而你还要工作，也没有那么大的精力去手把手的教人家。在设计测试用例的时候要考虑周到，不要重复。就我的工作来说做ERP产品就是注意各个模块的借口以及数据测试。有好多的接口，比如说销售模块是和财务模块在测试时是会发生重复的部分，这个要自己注意。行业性比较强。接下来说执行测试。要按照测试用例来执行。你不能说做了测试用例而在工作的时候根本就不看，这样对你的工作是没有帮助的。因为你按照测试用例来执行的话基本就是按照自己的思路来做，这样你走到哪一步心里都非常的清楚。这样最大的好处就是减少重复的工作，可以提高工作效率。我想这点无论是在小公司还是大公司，还是就我们工作的本身都是很重要的。然后，最好是做测试日记录，目的就是明确自己测试到哪里，以免重复工作。就我自己来说，我在做测试的时候每天都会做测试日记，一个是记录我今天发现了多少个bug，工作到哪一步了？做了哪些工作。我发现这个做测试日记录是很有意思的。每天测出了多少各bug，我虽然在那个bag管理工具上录了一遍，但是我还是要把它记录下来。我当初第一天去上班的时候，第一次接触到这个执行测试的时候，我记得特别清楚，我是找出了65个bug。我觉得这说明两个问题，一个是我工作特别认真，一个是研发部有问题确实是有问题。所以，你不要觉得搞研发的都很厉害，很牛啊，你会有点怵。当初我们公司也是联想、方正、惠普的这三个主力支柱，但是我没有觉得怵，虽然他们很自负。基本上很小的错误都能提出来，他们认为那根本不是bug。但是你到了讨论会或技术交流会、评估会的时候可以提出来，因为这是你作为一个测试员最基础的必须的工作，也是你对工作认真负责的态度。和开发人员的沟通。这个是对测试人员很重要的。这个我在前面提到过，每个人不是独立的在做事情，工作中都是需要相互的配合，特别是测试工作，有问题，你需要及时的和研发人员沟通。如果你连沟通都做不好，那么，你的测试工作根本就没有办法进行。在这当中，你要坚持自己的原则，就是对事不对人，因为，这个产品有问题，它就是存在bug，那么，就要有人负责去修改。你不能说，对方是部门领导你就不敢坚持自己提出的问题。第二，就是要坚守其他的测试原则，这就是我们在学习理论的时候所掌握的一些知识。因为，我们学习时的课程设计就是根据项目来设置的，很多东西基本和实际工作中相吻合。作为测试负责人，在测试工作中我给自己订了一个基本的工作流程，现在也就当作是部门的规章制度在执行。就是录入bug以后，我会在下面做bug描述，开发人员是否要修改，为什么要修改，大概时间是多少，这样督促对方的话，会有利于工作的进度。不然，如果工作没有完成，就会出现相互推诿的现象。查出bug后就是督促开发人员修改bug。同时也要注意bug管理工具。自己要用好bug管理工具，也要督促开发人员用好bug管理工具。因为，有很多开发人员还都是比较懒的，他当时会跟你说，都有什么bug，你到我的机器上演示给我看不就行了吗？这是一个不好的习惯，也很费时间。所以，你一定要督促他们使用bug管理工具。这是我深有体会的，而且，还在两次较大的公司会议上提出，最终是被大家所接受认同。大家都知道，一般开发的男同事较多，做测试的女孩子较多，你在提出问题的时候态度不要太强硬，在日常的工作中委婉的提醒他，大家一般都不会太为难你的。不但工作解决了，同事间的关系也很融洽。接着就是测试报告的编写。这些我们在就业班的时候都学过，就是测试背景、内容、测试通过率。以及产品的优点、缺陷，还有你对项目的建议。这一切都做好了就是开测试评估会了。关于自动化测试我的个人意见现在是自动化热门期，现在的很多公司，无论大小，无论是否正经接触或运行自动化测试，都会在面试的时候问你是否接触过自动化，用过哪些测试工具等。我当时去面试的时候，也遇到这个问题，当时我首先问他的是，咱们公司做过除手工以外的其他测试么？他们回答说没有。那只需要手工测试的公司，为什么还要询问自动化测试相关内容呢？如果手工测试都做不好，是坚决不能使用自动化去替代的。他们却告诉我，公司在手工测试部分，现在已经进入非常成熟的阶段了，为了提升公司的工作效率和降低工作成本，自动化手段是公司现阶段考虑的首要方案，即便初期所做的依旧还是手工测试，但是公司规划会在一定时间内推行自动化测试技术，如果等到开始推行的时候再招聘，是非常不现实的。而且我们也希望招聘到掌握自动化测试技术的人才为公司的自动化测试提出合理的建议，避免公司在接触新的技术领域时进入太多弯路。由此我才对自动化技术为何如此热门有了认知。很多公司可能在现阶段还是延续相对传统的手工测试能力在进行着功能测试，测试人员还是用延长工作时间来确保工作任务的完成，可这也只会是短时间内的现象了，随着行业技术的提升和公司的发展速度加快，大家所关注的永远都是如何更为高效而又低成本地达到目标，以往的加班保障进度的模式已经不再是新兴企业的观念了，同等时间内，往往自动化可以实现更高的价值产出，这是手工测试完全不可比拟的。所以可以明显预见往后的软件测试行业中，自动化测试技术的核心占比只会越来越高，无论企业现在是否在做自动化，在极短的时间后是一定会进入到自动化的。所以现在的企业在招聘人员时提出自动化的需求，我也不会再感到惊讶了，毕竟这是行业在发展的最直观证明。虽然我们总说自动化测试永远替代不了手工测试，但手工测试永远也达不到自动化测试的效率，这也是毋庸置疑的。一不小心就整理了这么多点滴出来，还真没想到自己还是很能写的嘛。估计这和我在公司除了做测试工作，还做些其他工作有关。我说过，因为我们是小公司，所以，一些产品的使用说明、产品的安装说明，包括客服培训，都是由我来写的。在测试之余，一些和测试无关的工作我也会去做，比如测试制度的编写，OA 产品管理员，售前咨询顾问这样的工作。我想我就是这么锻炼出来的。有什么问题可以加群交流，希望对大家有所帮助。如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以273462828，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。扩展阅读学软件测试最好的几本书，这8本书能帮你很多软件测试7年的工程师，讲述当初是怎么突破的瓶颈？少走弯路

概述回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他的代码出现错误。传统的自动化回归测试需要手动编写脚本获得页面元素的视图树，与原有的元素视图树进行比对。当功能进行频繁迭代时，测试同学维护这些视图元素验证点比较繁杂。因此在自动化回归测试过程中，直接比较代码修改前录制的页面和代码修改后回放的页面差异，可以快速定位代码产生的缺陷，从而提高测试同学的工作效率。以闲鱼应用举例，录制和回放页面差异检测存在的一些难点包括：图像上，闲鱼页面由顶部固定区域、中间可滚动区域、底部固定区域组成，需要对页面进行版面切割，之后分别对每一个区域进行处理。另外录制和回放页面中一些图标或者图片纹理复杂的区域往往像素值分布不同，但是语义层面又是同一个物体，因此需要从语义层面进行检测识别。业务上，两张页面中间区域因为滚动带来的差异不需要检测出来，并且一些特殊的标记差异(比如一张页面某个位置有光标，另一张页面同一位置没有光标)不需要检测出来。如上图四组录制和回放页面所示，其中每组图左边为录制页面，右边是回放页面。a)中因为中间区域的滚动带来了文字和图标的差异，b)中价格组件“¥69”右边的光标带来了差异，c)中输入框里的文字不一样，d)中“库存”那一栏的图标具有语义差别。其中a)和b)中的差异不需要检测出来，c)和d)中的差异需要检测出来。方法算法流程整个算法流程如下图所示：输入的录制和回放页面图像灰度化后进行版面切割，提取顶部区域、中间区域、底部区域两张页面的中间滚动区域进行对齐两张页面的每个区域分别进行相似度计算并排除无效的差异框两张页面中分别标记最终的差异框版面切割闲鱼大部分的页面是由顶部固定区域、中间可滚动区域、底部固定区域组成，版面切割的目的是找到中间可滚动区域的上下边界，即将页面切割为三块区域，之后对每块区域分别进行处理。版面切割只针对中间区域有滚动的情况，对于中间区域无滚动的情况即可用整张图进行后续处理。考虑到录制和回放页面在滚动区域上下边界处会产生明显的差异，因此分别从图像的第一行和最后一行开始进行比较，比较对应行的结构相似度指数(SSIM)，当对应行的结构相似度指数小于给定的阈值，则终止。结构相似度指数是一种衡量两幅图像相似度的指标，其从图像组成的角度将结构信息定义为独立于亮度、对比度的反映物体结构的属性，用均值作为亮度的估计，标准差作为对比度的估计，协方差作为结构相似程度的度量。具体公式如下：其中(x,y)分别为录制和回放图像，ux,uy,x2,y2,xy分别表示图像的均值、方差和协方差，c1,c2,c3为小的正常数，避免分母为零而出现不稳定，利用参数,,调整三个成分所占的比重。在实际工程中，一般设定===1，以及c3=c2/2，可以将SSIM简化为：SSIM为介于0到1之间的一个值，值越大表明两幅图越相似。下图a)b)为高2001像素、宽1125像素的录制和回放页面图像，选取SSIM阈值为0.95，计算得到的滚动区域的上边界为192，下边界为1832，如c)所示。滚动区域对齐对齐录制和回放图像的滚动区域后便可对比同一位置的差异，本文采用基于特征点的图像对齐方法， 即检测录制图像的一组稀疏特征点来匹配回放图像的一组稀疏特征点，通过两组特征点的匹配来计算一个转换矩阵，这个转换矩阵能变换对齐两幅图像的滚动区域。由于滚动区域只在垂直方向有位移，因此采用一般的刚性配准方法，如下式:录制图像坐标(x,y)通过一个3x3的位移矩阵转换到回放图像坐标(x’,y’)。位移转换矩阵可以通过对齐两幅图像的特征点来求取。在计算机视觉中，常见的特征点描述方法有SIFT、SURF、ORB等等，本文采用ORB方法，因为相比于SIFT和SURF方法，ORB在满足足够高的准确性前提下，速度更快并且使用不受专利约束。ORB全称是Oriented FAST and Rotated BRIEF，即是由FAST特征点检测和BRIEF特征点描述组成，并且在两者基础上加入了图像金字塔和图像重心方向等改进措施使得ORB对尺度和旋转不敏感。滚动区域对齐的具体步骤为：1. 输入录制和回放滚动区域。当上一步版面切割没有计算出滚动区域时，输入整幅图像的中间部分<br>2. 检测特征点。使用ORB检测两幅图像的角点。工程实现时可以设置每幅图像最多需检测出的特征点数<br>3. 匹配特征点。利用hamming距离来衡量两组特征点的相似性以及Brute Force暴力法尝试所有特征点来找到最佳匹配。基于匹配的特征点距离值进行排序，选取距离值较小的一部分特征点<br>4. 计算转换矩阵。输入两组特征点坐标位置通过最小二乘求解最优的转换矩阵<br>5. 对齐图像。应用转换矩阵将回放图像滚动区域映射对齐录制图像滚动区域<br>下图为匹配的两组特征点，计算出来的转换矩阵中tx=0，ty=-96相似度计算及后处理对录制和回放页面的顶部区域、底部区域和对齐的滚动区域分别计算结构相似度SSIM(如果图像不存在滚动区域，则对整图计算SSIM)，差异的地方用矩形框标识，后续通过一定的后处理排除掉无效的差异。具体步骤如下：差异检测。对顶部区域、底部区域和对齐的滚动区域每个像素在一定的领域范围内计算SSIM，得到同等尺寸的SSIM结果图；再对SSIM结果图用大津法得到二值化的SSIM结果图，其中有差异的地方为1，没有差异的地方为0；接着提取二值化SSIM差异部分的外接轮廓；之后再计算轮廓的最小外接矩形框。得到的结果如下红框所示：后处理。上图红框显示的是对齐滚动区域带来的差异，通过判断每个框是否落到特定区域范围内来进行排除，这个特定区域在垂直方向上以滚动区域上边界起始，向下移动ty行结束或者以滚动区域下边界起始，向上移动ty行结束。另外对于一些噪声点带来的差异，可以通过限制差异框包含的面积进行排除。对上图使用以上两步后处理后，红框全部被排除。其他一些录制和回放图像中的特殊标记(比如光标)差异在业务层面需要排除，或者一些纹理丰富的图标/图像虽然像素层面存在差异，但语义层面属于同一类，即使SSIM计算不相似，也需要排除。上图a)显示光标差异模式，b)显示纹理丰富的图标/图像差异模式，c)显示其他差异模式。这些差异模式是对应位置差异框绝对差得到的结果，其中a)和b)需要排除，c)需要保留。分析这几种不同模式类型，设计了一种如下图所示CNN二分类网络。图像缩放到64x64大小，然后输入到三层conv+pooling+relu的卷积结构中，后接128个节点和2个节点的全连接层，以softmax作为类别判定输出。通过分类网络便可将业务层面或像素层面的差异进行排除。结果一些差异检测的结果如下，其中红框标示的是在录制和回放页面中存在差异的部分。a)只有中间区域滚动带来的差异，业务上不需要检测出来； b)和c)能将页面中存在语义差异的部分检测出来并且没有误检和漏检； d)两张页面不存在语义差异，但底部有个文字区域出现了误检，分析原因是页面在没有滚动的情况下，误检区域没有上下严格对齐，导致计算的SSIM值偏小，认为此处存在差异。总结本文以闲鱼自动化回归测试应用举例，实现了一种版面切割、滚动区域对齐、相似度计算及后处理的录制和回放页面差异检测方法。这种方法在使用过程中达到了检出语义差异的预期，并且方法具有普适性，对其他app的自动化回归测试具有一定的参考意义。当然本方法也存在着一些不足，对于像素分布不同但语义相同的差异模式会有一部分误检，这是由于SSIM在计算相似度时对于局部像素值的变化比较敏感，未来可对页面中的文字和图片独立提取出来进行进一步的语义分析优化。本文作者：闲鱼技术-深宇阅读原文本文为云栖社区原创内容，未经允许不得转载。

上一篇文章发布后，竟然收获到一些同学的注意，实在是意外之喜。不过我也发现，很多同学对 E2E 测试不够了解，正好我厂的产品也没做到能作为商用版发布的程度，所以这篇再来聊聊 E2E 测试吧。本文的测试均指自动化测试。E2E，是“End to End”的缩写，可以翻译成“端到端”测试。它模仿用户，从某个入口开始，逐步执行操作，直到完成某项工作。与单元测试不同，后者通常需要测试参数、参数类型、参数值、参数数量、返回值、抛出错误等，目的在于保证特定函数能够在任何情况下都稳定可靠完成工作。单元测试假定只要所有函数都正常工作，那么整个产品就能正常工作。相对来说，E2E 测试并没有那么强调要覆盖全部使用场景，它关注的是 一个完整的操作链是否能够完成。对于 Web 前端来说，还关注 界面布局、内容信息是否符合预期。比如，登陆界面的 E2E 测试，关注用户是否能够正常输入，正常登录；登陆失败的话，是否能够正确显示错误信息。至于输入不合法的内容是否处理，没有很大的关系。Web 前端 E2E 测试的现状Web 前端 E2E 自动化测试开展得不好。在我从业的这十几年里，大部分产品的前端 E2E 测试都交给测试人员手工完成。我们稍稍分析一下，大概有三个原因：1. 测试环境不好搭单元测试也好、接口测试也好，测试环境都很容易搭建。然而 Web 前端测试如果想达到目的，需要完整的桌面操作系统和浏览器环境，这种面向普通用户的软件对自动化工具并不友好。对系统要求也比较高，很难整合到开发测试工具链档中。解决方案当然是有的，目前最流行的应该是 Selenium WebDriver。不过对于小公司、小团队来说，在并不丰富的资料中摸着石头过河实在不够经济，而且，还有接下来的两个问题。2. 测试不好写。目前的 Web 前端 E2E 测试工具局限于 XPath 技术栈。大家用选择器查找 DOM 节点，校验其属性和内容，接着进行交互。这样做导致一个必然后果：写测试的人员对页面的 DOM 结构必须了如指掌，才能用准确目标元素。同时，在这个技术环境下写就的测试用例，一旦 DOM 结构出现变化，就要大规模的修改，甚至重写。工作量很大，而且存在一些不稳定因素。跟某团队 Leader 聊天，他就很担心漫长的迭代过程中，DOM 结构变化导致测试用例失效，继而引发项目排期混乱。结果，Web 前端 E2E 测试用例的只能由前端用 JS 写，工作量大，维护负担重，且存在一些风险。大家都不愿意写。3. 有些东西不好测随着用户对产品的要求水涨船高，页面逻辑越来越复杂，功能越发依赖 Ajax，甚至和后端彻底分离，成为单页应用（SPA）。这类产品与传统的静态页服务不同，我们没法侦听 DOMReady 事件，也就难以找到合适的时间点启动测试。早些时候，我们只能依靠 setInterval() 轮询。如今，通过 Puppeteer 或者浏览器扩展都可以监听网络连接，可以根据当前保持的连接数来判断请求是否完成。不过这些做法仍然存在不小的实施难度。4. 预期收益一般我跟很多技术老大聊过。大家的回答都是：没写，没空，招测试。在加班成为常态的今天，在“看得到”的工作之外，再去做这些“看不到”的工作，实在有些吃力不讨好。另一方面，测试写得少，覆盖率跟不上，还是得招测试，人工测试。恶行循环就此产生：不想写导致没测试；那就招测试人员；有了专职测试我还写什么测试……所以大家都不写测试了。对于中等以上规模的技术团队，招几个测试也还行。对于整个公司就只有几个人的创业团队来说，大多数时候只能裸奔……更好的 Web 前端 E2E 测试工具行文至此，结论就很明显了：我们需要全新的、更高级的 Web 前端 E2E 测试工具。这个工具需要同时满足：1. 有效可以准确地描述 UI 的结构可以尽量全面的模拟用户真实操作覆盖多种操作系统、适配各种浏览器2. 使用成本低测试用例应该尽量简短，用最少的代码描述出 UI，完成交互。测试用例应该和 DOM 实现解耦，用的尽量久，能不改就不改。测试用例应该让所有人都学得会，写得通3. 提高开发效率应该提供方便易用的编写、测试环境，让用户可以轻松上手需要能够和常见的 CI 系统集成我厂的解决方案最后回到我厂。我们设计了一个全新的语言用来描述 UI，叫做 Navlang。我们可以用它描述各元素的相对位置，操作元素进行交互。它是一个描述性语言，只包含很简单的逻辑——实际上 E2E 测试也不需要多复杂的逻辑，跑不通就是挂了，跑通了就没问题。这样一来，任何人，只要经过简单的培训，都可以写出正确的测试用例。（HTML 就是最好的例子。前端很多都是页面仔出身，比如我，相信大家对这类语言的易学易用都有所了解。）因为是语言，所以它可以写成代码，可以被版本管理；因为是新的抽象，所以它不跟 DOM 实现耦合，可以被反复使用，几乎没有维护成本。（只有界面变化才需要修改测试用例，此时无论如何都要修改测试用例）目前这个工具已经在我厂的开发体系中工作将近一年，为我厂产品的稳定做出了非常重大的贡献。功能化之外，我们也在作产品化和商品化的努力。目前已经基本完成浏览器扩展功能，让普通用户可以通过浏览器扩展编写和运行测试。接下来，我们还会提供基于 Node.js 的测试工具框架，帮助大家将测试集成到现有的 CI 系统当中。未来，这款产品会服务广大小型公司和小型团队，帮助大家提升 Web UI 测试的效率。好了，敬请期待下周的 Navlang 介绍吧。 ...

作者：腾讯WeTest商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/444.html一分钟读懂兼容报告：测试过程视频复现，问题定位很轻松上一期《一分钟读懂兼容测试报告（一）：概况篇》，介绍了WeTest兼容测试报告的概况信息，包括测试通过率、机型聚类、测试场景截图等功能。随着用户使用的不断深入，用户对报告产生了更多的诉求。在查看报告时，用户在了解了问题概况和分类情况之后，都会进入“问题定位”的环节，用户在进行问题定位的时候会提出新的问题：1. 问题出现前用户进行了什么操作？问题发生后的状况是怎么样的？问题优化后产品表现有什么区别？针对用户的需求，WeTest兼容测试报告进行了优化。优化一：复现操作过程视频，迅速定位问题WeTest之前的适配兼容测试报告，在报告中能看到所有操作步骤的截图，如下图：根据截图可以看到测试的过程是如何点击的，定位问题出现操作节点，但是在对部分产品进行测试的时候，因为截图具有间隔时间，中间有5秒左右是空白的，开发测试人员无法查看。为了更全面展现测试情况，WeTest为测试报告提供视频播放功能，在截图上做补充，播放测试过程录像。（目前已经支持应用及部分类型手游）提测人可以从入我的报告-设备详情页，进入设备详情；或者进入问题列表-问题详情查看视频。视频连接地址：https://v.qq.com/x/page/r0845…以上是部分测试的视频片段，测试过程中在系统跳出提示“请输入账号”点击确认后，屏幕出现黑屏。视频里包含从拉起应用到结束过程，全程操作一目了然，帮助开发者们清晰定位问题出现的前后操作，复现问题。功能二：报告对比对于APP来说，版本迭代的速度和质量尤为重要，快速处理优化上线问题，保障和提升用户体验，是重点核心。厂商需要迅速对上个版本的适配问题做修复，在为了帮助开发者们更方便地纵观历史版本的适配情况，WeTest在报告中右上角添有“历史版本对比”功能，可直接勾选历史测试版本进行对比。600报告对比图示报告中包含：1) 基础数据2) 通过率3) 问题数4) 测试机型数5) 性能数据：安装耗时、FPS、CPU、内存占用，流量等数据报告通过图表显示，可直观观察历史版本数据情况。_目前“版本对比”功能在各项兼容测试服务报告中均已支持；“报告视频”功能在深度兼容测试服务可用，欢迎体验！传送门：https://wetest.qq.com/cloud/deepcompatibilitytesting腾讯WeTest （wetest.qq.com）是由腾讯官方推出的一站式品质开放平台。十余年品质管理经验，致力于质量标准建设、产品质量提升。腾讯WeTest为移动开发者提供兼容性测试、云真机、性能测试、安全防护、企鹅风讯（舆情分析）等优秀研发测试工具，为百余行业提供解决方案，覆盖产品在研发、运营各阶段的测试需求，历经千款产品磨砺。金牌专家团队，通过5大维度，41项指标，360度保障您的产品质量。

本文首发于泊浮目的专栏：https://segmentfault.com/blog…背景最近项目在测试阶段陆陆续续的测出了一些bug.这个情况刚出现的时候,让笔者很困惑——平时我们的每个feature代码都是跟随着大量看起来考虑很周全的case进入代码仓库的,然而事实还是打了我们的脸.故在本文,笔者将会从最近的所学所想来谈谈编写测试的时候我们应该注意什么.AIR原则与BCDE原则前阵子看了一本书,里面提到了单元测试的一些原则:宏观上,单元测试要符合AIR原则微观上,单元测试的代码层面要符合BCDE原则AIR原则AIR即空气,单元测试亦是如此。当业务代码在线上运行时,可能感觉不到测试用例的存在和价值,但在代码质量的保障上,却是非常关键的。新增代码应该同步增加测试用例,修改代码逻辑时也应该同步保证测试用例成功执行。AIR原则具体包括:A: Automatic (自动化)I: Independent (独立性)R: Repeatable (可重复)简单的解释一下三个原则:单元测试应该是全自动执行的。测试用例通常会被频繁地触发执行,执行过程必须完全自动化才有意义。如果单元测试的输出结果需要人工介入检查,那么它一定是不合格的。单元测试中不允许使用System.out等方法来进行人工验证,而必须使用断言来验证。为了保证单元测试稳定可靠且便于维护，需要保证其独立性。用例之间不允许互相调用,也不允许出现执行次序的先后依赖。BCDE原则编写单元测试用例时,为了保证被测模块的交付质量,需要符合BCDE原则。B: Border,边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等。C: Correct,正确的输入,并得到预期的结果。D: Design,与设计文档相结合,来编写单元测试。E: Error,单元测试的目标是证明程序有错,而不是程序无错。为了发现代码中潜在的错误,我们需要在编写测试用例时有一些强制的错误输入(如非法数据、异常流程、非业务允许输入等)来得到预期的错误结果。在ZStack白盒集成测试中实践原则之前提到的原则是基于单元测试的,但在ZStack的白盒测试中也可以作为有价值的参考.戳此了解ZStack的白盒集成测试:https://segmentfault.com/a/11…由于ZStack的整套测试框架也是基于Junit扩展而来,因此也是一定程度上遵循了上面提到的AIR原则.除了A原则,I和R原则在一定程度上打了折扣:I: 如果上一个测试没有清理干净状态,则会影响下一个测试R: 基于上面提到的I,很有可能导致可重复性大打折扣当然,出现这些问题时则表示当前的代码中有bug.但单元测试则不会受到这样的影响——它能测出bug,AIR原则也得以保证.在本次示例中,我们将以VmInstance的创建API即——APICreateVmInstacneMsg作为测试对象.如果读者不是很了解上下文,也可以简单的看一下这个Case:OneVmBasicLifeCycleCaseBorder Test && Error Test边界测试是用来探测和验证代码在处理极端的情况下会发生什么.而错误测试为了保证ZStack在一些错误的状态下做出我们所期待的行为.那么我们该如何编写这样的测试呢?我们先来简单的理一下创建Vm的流程:VmImageSelectBackupStorageFlowVmAllocateHostFlowVmAllocatePrimaryStorageFlowVmAllocateVolumeFlowVmAllocateNicFlowVmInstantiateResourcePreFlowVmCreateOnHypervisorFlowVmInstantiateResourcePostFlow而其中每一个步骤可以分成好几个小步骤,以VmAllocateHostFlow为例:我们可以看到,根据不同的策略,allocateHost里还会有好几个flow.而由于松耦合架构,我们可以在测试中轻易的模拟极端问题的出现,如:找不到合适的BackupStorageHostCapacity的不够Agent返回的回复在某一个时刻与管理节点的状态不同…….以此类推,以上创建vm的8个flow都可以轻易模拟各种边界条件及错误情况.Correct Test && Design Test正确性测试听起来应该会很简单,(比如调用一个API,然后看结果返回是否正确)但如果放到集成测试中,我们还是可以拓展出一些额外的关注点的.还是以上面提到的createVm为例子,我们看到了8个flow,然后里面可能还嵌套着好几个子flow.如图所示:在编写正确性测试时,我们可以考虑额外关注以下几点:APIParam在各个Flow间中转时是否如预期关注管理节点内的服务:Flow之间调用的时序是否符合预期Flow之间流转时,业务目标状态是否符合预期关注管理节点外的服务:对于agent的请求是否符合预期在API调用完后,相关资源的目标状态是否符合预期而与文档结合的测试用例,则应当由团队的测试人员来定义.可以确定的是,这类的测试更加关注于API(即输入输出),而不是内部的状态.

1.背景当前闲鱼在精益开发模式下，整个技术团队面临了诸多的能力落地和挑战，尤其是效能方面的2-1-1的目标(2周需求交付周期，1周需求开发周期，1小时达到发布标准)，具体可见 闲鱼工程师是如何构建持续集成流水线，让研发效率翻倍的 ，在这个大目标下，就必须把每个环节都做到极致。自动化的建设是决定CI成败的关键能力，今天分享一下闲鱼Android客户端性能自动化环节的实践。2.面临的问题2.1 主要是两个方面的问题工具缺失：目前淘宝系，对于线上性能水位的监控有一套完善的体系，但是针对新功能的性能测试，每个业务团队都有对应的性能专项小组，产出的工具都是根据自己业务特点的定制开发的，闲鱼客户端目前使用Flutter做为客户端主开发语言，对于Flutter性能数据的获取及UI自动化测试支撑工具目前是缺失的，同时业界对Flutter自动化和性能相关的实践几乎没有；测试工作量翻N倍(N=一个版本周期内的分支数)：原先的开发模式是功能测试集成测试一起进行的，所以性能测试只需要针对集成后的包进行测试即可，到现在转变为泳道的开发模式，一个版本内会一般包含十几个左右的泳道分支甚至更多，我们必须确保每个泳道的分支的性能是达标的，如果有性能问题需要第一时间反馈出来，如果遗留到集成阶段，问题的排查(十几个分支中筛查)，问题的解决将会耗费大量的时间，效率很难得到大的提升；2.2 问题思考体系化解决，要让每个泳道分支都得到有效测试覆盖，测试件能够自动化执行，持续反馈结果3. 解决方案综合上述问题，梳理如下解决方案：针对Flutter性能数据的获取(比如，Flutter有自己的SurfaceView，原有Native计算FPS的方式无法直接使用)针对Flutter UI自动化的实现(Flutter/Native UI混合栈的处理)性能自动化脚本 / 性能数据自动采集、上报 融入CI流程性能问题的通知 / 报表展示 / 分析3.1 性能数据[FPS]解析处理 adb shell dumpsys SurfaceFlinger –latency 的数据，详细请见文末参考链接(该方式兼容Flutter及Native的解决方案，已在Android4.x-9.x验证可行)，处理SurfaceFlinger核心代码如下：dumpsys SurfaceFlinger –latency-clear#echo “dumpsys SurfaceFlinger…“if [[ $isflutter = 0 ]];then window=dumpsys window windows | grep mCurrent | $bb awk '{print $3}'|$bb tr -d '}' # Get the current window echo $windowfiif [[ $isflutter = 1 ]];then window=dumpsys SurfaceFlinger --list |grep '^SurfaceView'|$bb awk 'NR==1{print $0}'if [ -z “$window” ]; then window=“SurfaceView"fiecho $windowfi$bb usleep $sleep_tdumpsys SurfaceFlinger –latency “$window”|$bb awk -v time=$uptime -v target=$target -v kpi=$KPI ‘{if(NR==1){r=$1/1000000;if(r<0)r=$1/1000;b=0;n=0;w=1}else{if(n>0&&$0==”")O=1;if(NF==3&&$2!=0&&$2!=9223372036854775807){x=($3-$1)/1000000/r;if(b==0){b=$2;n=1;d=0;D=0;if(x<=1)C=r;if(x>1){d+=1;C=int(x)r;if(x%1>0)C+=r};if(x>2)D+=1;m=r;o=0}else{c=($2-b)/1000000;if(c>1000){O=1}else{n+=1;if(c>=r){C+=c;if(c>kpi)o+=1;if(c>=m)m=c;if(x>1)d+=1;if(x>2)D+=1;b=$2}else{C+=r;b=sprintf(”%.0f”,b+r1000000)}}};if(n==1)s=sprintf("%.3f",$2/1000000000)};if(n>0&&O==1){O=0;if(n==1)t=sprintf("%.3f",s+C/1000);else t=sprintf("%.3f",b/1000000000);T=strftime("%F %T",time+t)".“sprintf(”%.0f",(time+t)%11000);f=sprintf("%.2f",n1000/C);m=sprintf("%.0f",m);g=f/target;if(g>1)g=1;h=kpi/m;if(h>1)h=1;e=sprintf("%.2f",g60+h20+(1-o/n)*20);print s",“t”,“T”,“f+0”,“n”,“d”,“D”,“m”,“o”,“e”,“w;n=0;if($0==”"){b=0;w+=1}else{b=$2;n=1;d=0;D=0;if(x<=1)C=r;if(x>1){d+=1;C=int(x)*r;if(x%1>0)C+=r};if(x>2)D+=1;m=r;o=0}}}}’ >>$file[CPU]使用的是top的命令获取(该方式获取性能数据时，数据收集带来的损耗最少)export bb="/data/local/tmp/busybox"$bb top -b -n 1|$bb awk ‘NR==4{print NF-1}’[内存]解析 dumpsys meminfo $package 拿到 Java Heap,Java Heap Average,Java Heap Peak,Native Heap,Native Heap Average,Native Heap Peak,Graphics,Unknown,Pss 数据do_statistics() { ((COUNT+=1)) isExist="$(echo $OUTPUT | grep “Dalvik Heap”)" if [[ ! -n $isExist ]] ; then old_dumpsys=true else old_dumpsys=false fi if [[ $old_dumpsys = true ]] ; then java_heap="$(echo “$OUTPUT” | grep “Dalvik” | $bb awk ‘{print $6}’ | $bb tr -d ‘\r’)" else java_heap="$(echo “$OUTPUT” | grep “Dalvik Heap[^:]” | $bb awk ‘{print $8}’ | $bb tr -d ‘\r’)" fi echo “1."$JAVA_HEAP_TOTAL “2."$java_heap “3."$JAVA_HEAP_TOTAL ((JAVA_HEAP_TOTAL+=java_heap)) ((JAVA_HEAP_AVG=JAVA_HEAP_TOTAL/COUNT)) if [[ $java_heap -gt $JAVA_HEAP_PEAK ]] ; then JAVA_HEAP_PEAK=$java_heap fi if [[ $old_dumpsys = true ]] ; then native_heap="$(echo “$OUTPUT” | grep “Native” | $bb awk ‘{print $6}’ | $bb tr -d ‘\r’)” else native_heap="$(echo “$OUTPUT” | grep “Native Heap[^:]” | $bb awk ‘{print $8}’ | $bb tr -d ‘\r’ | $bb tr -d ‘\n’)” fi ((NATIVE_HEAP_TOTAL+=native_heap)) ((NATIVE_HEAP_AVG=NATIVE_HEAP_TOTAL/COUNT)) if [[ $native_heap -gt $NATIVE_HEAP_PEAK ]] ; then NATIVE_HEAP_PEAK=$native_heap fi g_Str=“Graphics” if [[ $OUTPUT == $g_Str ]] ; then echo “Found Graphics…” Graphics="$(echo “$OUTPUT” | grep “Graphics” | $bb awk ‘{print $2}’ | $bb tr -d ‘\r’)” else echo “Not Found Graphics…” Graphics=0 fi Unknown="$(echo “$OUTPUT” | grep “Unknown” | $bb awk ‘{print $2}’ | $bb tr -d ‘\r’)" total="$(echo “$OUTPUT” | grep “TOTAL”|$bb head -1| $bb awk ‘{print $2}’ | $bb tr -d ‘\r’)"}[流量]通过 dumpsys package packages 解析出当前待测试包来获取流量信息uid="$(dumpsys package packages|$bb grep -E “Package |userId”|$bb awk -v OFS=" " ‘{if($1==“Package”){P=substr($2,2,length($2)-2)}else{if(substr($1,1,6)==“userId”)print P,substr($1,8,length($1)-7)}}’|grep $package|$bb awk ‘{print $2}’)“echo “Net:"$uidinitreceive=$bb awk -v OFS=" " 'NR&gt;1{if($2=="wlan0"){wr[$4]+=$6;wt[$4]+=$8}else{if($2=="rmnet0"){rr[$4]+=$6;rt[$4]+=$8}}}END{for(i in wr){print i,wr[i]/1000,wt[i]/1000,"wifi"};for(i in rr){print i,rr[i]/1000,rt[i]/1000,"data"}}' /proc/net/xt_qtaguid/stats | grep $uid|$bb awk '{print $2}'inittransmit=$bb awk -v OFS=" " 'NR&gt;1{if($2=="wlan0"){wr[$4]+=$6;wt[$4]+=$8}else{if($2=="rmnet0"){rr[$4]+=$6;rt[$4]+=$8}}}END{for(i in wr){print i,wr[i]/1000,wt[i]/1000,"wifi"};for(i in rr){print i,rr[i]/1000,rt[i]/1000,"data"}}' /proc/net/xt_qtaguid/stats | grep $uid|$bb awk '{print $3}'echo “initnetarray”$initreceive”,"$inittransmitgetnet(){ local data_t=date +%Y/%m/%d" "%H:%M:%S netdetail=$bb awk -v OFS=, -v initreceive=$initreceive -v inittransmit=$inittransmit -v datat="$data_t" 'NR&gt;1{if($2=="wlan0"){wr[$4]+=$6;wt[$4]+=$8}else{if($2=="rmnet0"){rr[$4]+=$6;rt[$4]+=$8}}}END{for(i in wr){print datat,i,wr[i]/1000-initreceive,wt[i]/1000-inittransmit,"wifi"};for(i in rr){print datat,i,rr[i]/1000-initreceive,rt[i]/1000-inittransmit,"data"}}' /proc/net/xt_qtaguid/stats | grep $uid echo $netdetail>>$filenet}3.2 性能自动化脚本基于Appium的自动化用例，这个技术业界已经有非常多的实践了，这里我不再累述，如果不了解的同学，可以到Appium官网 http://appium.ioFlutter和Native页面切换使用App内的Schema跳转Flutter页面的文本输入等交互性较强的场景使用基于Flutter框架带的Integration Test来操作An integration testGenerally, an integration test runs on a real device or an OS emulator, such as iOS Simulator or Android Emulator. The app under test is typically isolated from the test driver code to avoid skewing the results.Flutter的UI自动化及Flutter/Native混合页面的处理在测试上的应用后续单独开文章介绍，原理相关可以先参考 千人千面录制回放技术3.3 性能自动化CI流程3.4 性能数据报表FPS相关Framediff: 绘制帧的开始时间和结束时间差FPS: 每秒展示的帧数Frames: 一个刷新周期内所有的帧jank: 一帧开始绘制到结束超过16.67ms 就记一次jank，jank非零代表硬件绘制掉帧，和屏幕硬件性能及相关驱 动性能有关jank2: 一帧开始绘制到结束超过33.34ms 就记一次jank2MFS: 在一个刷新周期内单帧最大耗时（每两行垂直同步的时间差代表两帧绘制的帧间隔）OKT: 在一个刷新周期内，帧耗时超过16.67ms的次数SS: 流畅度，通过FPS，MFS，OKT计算出来，流畅度 = 实际帧率比目标帧率比值60【目标帧率越高越好】 + 目标时间和两帧时间差比值20【两帧时间差越低越好】 + (1-超过16ms次数/帧数)*20【次数越少越好】CPUMemory4. 成果展示4.1 指定泳道分支性能监控泳道分支出现了性能问题再报表上一目了然4.2 性能专项支撑1、Flutter商品详情页重构 14轮测试2、客户端图片统一资源测试 4轮测试5. 总结性能自动化只是整个CI流程中的一个环节，为了极致效率的大目标，闲鱼质量团队还产出了很多支撑工具，CI平台，遍历测试，AI错误识别，用例自动生成等等，后续也会分享给大家。6. 参考https://testerhome.com/topics/2232https://testerhome.com/topics/4775本文作者：闲鱼技术-灯阳阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

导语发布app后，开发者最头疼的问题就是如何解决交付后的用户侧问题的还原和定位，是业界缺乏一整套系统的解决方案的空白领域，闲鱼技术团队结合自己业务痛点在flutter上提出一套全新的技术思路解决这个问题。我们透过系统底层来捕获ui事件流和业务数据的流动，并利用捕获到的这些数据通过事件回放机制来复现线上的问题。本文先介绍flutter触摸手势事件原理，接着介绍里面怎样录制flutter ui手势事件，然后介绍怎样还原回放flutter ui手势事件，最后附上包括native录制回放的整体框架图。为了便于理解本文，读者可以先阅读我之前写的关于native录制和回放文章《千人千面线上问题回放技术》背景现在的app基本都会提供用户反馈问题的入口，然而提供给用户反馈问题一般有两种方式：直接用文字输入表达，或者截图直接录制视频反馈这两种反馈方式常常带来以下抱怨：用户：输入文字好费时费力开发1：看不懂用户反馈说的是什么意思？开发2：大概看懂用户说的是什么意思了，但是我线下没办法复现哈开发3：看了用户录制的视频，但是我线下没办法重现，也定位不到问题所以：为了解决以上问题，我们用一套全新的思路来设计线上问题回放体系Flutter 手势基础知识如果要录制和回放flutter ui事件，那么我们首先必须了解flutter ui手势基本原理。1. Flutter UI触摸原始数据Pointer我们可以把Flutter中的手势系统分两层概念来理解。第一层概念为原始触摸数据(pointer)，它描述了屏幕上指针（例如，触摸，鼠标和触控笔）的时间，类型，位置和移动。 第二层概念为手势，描述由一个或多个原始移动数据组成的语义动作。一般情况下单独的原始触摸数据没有任何意义。原始触摸数据是由系统传给native，native再通过flutter view channel传给flutter。flutter接收native传来的原始数据接口如下： void _handlePointerDataPacket(ui.PointerDataPacket packet) { // We convert pointer data to logical pixels so that e.g. the touch slop can be // defined in a device-independent manner. _pendingPointerEvents.addAll(PointerEventConverter.expand(packet.data, ui.window.devicePixelRatio)); if (!locked) _flushPointerEventQueue(); }2. Flutter UI碰撞测试当屏幕接收到触摸时，dart Framework会对您的应用程序执行碰撞测试，以确定触摸与屏幕相接的位置存在哪些视图（renderobject）。 触摸事件然后被分发到最内部的renderobject上。 从最内部renderobject开始，这些事件在renderobject树中向上冒泡传递，通过冒泡传递最后把所有的renderobject遍历出来，从这个传递机制可想而知，遍历出来renderobject列表里的最后一个是WidgetsFlutterBinding（严格来讲WidgetsFlutterBinding不是renderobject），后面会介绍到WidgetsFlutterBinding。 void _handlePointerEvent(PointerEvent event) { assert(!locked); HitTestResult result; if (event is PointerDownEvent) { assert(!_hitTests.containsKey(event.pointer)); result = HitTestResult(); hitTest(result, event.position); _hitTests[event.pointer] = result; assert(() { if (debugPrintHitTestResults) debugPrint(’$event: $result’); return true; }()); } else if (event is PointerUpEvent || event is PointerCancelEvent) { result = _hitTests.remove(event.pointer); } else if (event.down) { result = _hitTests[event.pointer]; } else { return; // We currently ignore add, remove, and hover move events. } if (result != null) dispatchEvent(event, result); }上面代码以 histTest()检测当前触摸 pointer event 涉及到哪些视图。最后通过dispatchEvent(event, result)来处理该事件。void dispatchEvent(PointerEvent event, HitTestResult result) { assert(!locked); assert(result != null); for (HitTestEntry entry in result.path) { try { entry.target.handleEvent(event, entry); } catch (exception, stack) { } } }上面的代码就是用来分别调用每个视图（RenderObject）的手势识别器独自处理当前触摸事件（决定是否接收此事件）。entry.target是每个widget对应的RenderObject,所有的RenderObject都需要实现（implements）HitTestTarget类的接口，HitTestTarget里面有就有handleEvent这个接口，所以每个RenderObject都需要实现handleEvent这个接口， 这个接口就是用来处理手势识别。abstract class RenderObject extends AbstractNode with DiagnosticableTreeMixin implements HitTestTarget除了最后一个WidgetsFlutterBinding外，其他视图RenderObject调用自己的handleEvent来识别手势，其作用就是判断当前手势是否要放弃，如果不放弃则丢到一个路由器里（这个路由器就是手势竞技场）最后由WidgetsFlutterBinding 调用handleEvent统一决议这些手势识别器最终谁胜出，所以这里WidgetsFlutterBinding.handleEvent其实就是统一处理接口，它的代码如下： void handleEvent(PointerEvent event, HitTestEntry entry) { pointerRouter.route(event); if (event is PointerDownEvent) { gestureArena.close(event.pointer); } else if (event is PointerUpEvent) { gestureArena.sweep(event.pointer); } }3. Flutter UI手势决议从上面的介绍可以得出一次触摸事件可能触发多个手势识别器。框架通过让每个识别器加入一个“手势竞争场”来决议用户想要的手势。“手势竞争场”使用以下规则来决议哪个手势胜出，非常简单在任何时候，任何识别器都可以自己宣布失败并主动离开“手势竞争场”。如果在当前“竞争场”中只剩下一个识别器，那么剩下来的就是赢家，赢家意味着独自接收此触摸事件并做出响应动作在任何时候，任何识别器都可以自己宣布胜利，并且最终就是它胜利，所有剩下的其他识别器都会失败4. Flutter UI手势例子下面示例表示屏幕window由ABCDEFKG视图组成，其中A视图是根视图，即是最底下的视图。红圈表示触摸点位置，触摸落在G视图的中间位置。根据碰撞测试，遍历出响应此触摸事件的视图路径：WidgetsFlutterBinding <— A <— C <— K <— G (其中GKCA是renderObject)遍历路径列表后，开始调用各自的视图（GKCA）entry.target.handleEvent来把自己识别器放到竞技场里参加决议，当然有些视图由于根据自己的逻辑判断主动放弃识别该触摸事件。这个处理过程如下图按G->K->C->A->WidgetsFlutterBinding顺序分别调用handleEvent()方法，最后通过WidgetsFlutterBinding调用自己的handleEvent()接口来统一决议最终哪个手势识别器胜出。胜出的那个手势识别器通过回调方法回调到上层业务代码，流程如下Flutter UI录制从上面的flutter手势处理可知，我们只需要在手势识别器回调上包装回调方法，即可拦截到手势回调方法，这样我们就可以在拦截过程读到WidgetsFlutterBinding <— A <— C <— K <— G链路的这棵视图树。我们只需要把这个棵树，树上的节点相关属性和手势类型记录下来，那回放时，通过这些信息去匹配到当前界面上的对应视图即可回放。下面是tap事件的录制代码，其他类型手势的录制代码原理一样，这里略过。 static GestureTapCallback onTapWithRecord(GestureTapCallback orgOnTap, BuildContext context) { if (null != orgOnTap && null != context) { final GestureTapCallback onTapWithRecord = () { if(bStartRecord) { saveTapInfo(context, TouchEventUIType.OnTap,null); } if (null != orgOnTap) { orgOnTap(); } }; return onTapWithRecord; } return orgOnTap; }static void saveTapInfo(BuildContext context, TouchEventUIType type, Offset point) { if(null == point && null != pointerPacketList && pointerPacketList.isNotEmpty) { final ui.PointerDataPacket last = pointerPacketList.last; if(null != last && null != last.data && last.data.isNotEmpty) { final ui.Rect rect = QueReplayTool.getWindowRect(context); point = new Offset(last.data.last.physicalX / ui.window.devicePixelRatio - rect.left, last.data.last.physicalY /ui.window.devicePixelRatio - rect.top); } } final RecordInfo record = createTapRecordInfo(context, type, point); if(null != record) { FlutterQuestionReplayPlugin.saveRecordDataToNative(record); } clearPointerPacketList(); }录制流程图如下：Flutter UI回放ui回放分两部分，第一部分通过录制的相关信息match到当前界面相应视图，第二部分是在此视图上进行模拟相关手势动作，这部分是个难点，也是重点，其中涉及到怎样生成原始的触摸数据信息，里面有时间，类型，坐标，方向，如果这些信息设置不合理或者错误会导致crash，还有滚动距离不符需要补偿，怎么补偿等等。下面是滚动事件回放流程图，其他类型手势的回放原理一样。上面的预处理，识别消耗指的是在滚动开始时，手势识别器要判断是否符合滚动手势所需要滚动的距离。所以我们为了让其控件滚动首先要生成一些触摸点数据，让手势识别器识别为滚动事件。这样才能进行后续的滚动动作。下面是滚动处理逻辑代码，如下： void verticalScroll(double dstPoint, double moveDis) { preReplayPacket = null; if (0.0 != moveDis) { //此处计算滚动方向，和滚动单元像素偏移，由于代码太长略过 int count = ((ui.window.devicePixelRatio * moveDis) / (unit.abs())).round() * 2; if (count < minCount) { count = minCount; //保证最少偏移50/2=25 小于这个数 可能没反应，因为被其他控件检测滚动消耗掉了 //还有就是如果count太小，count被scroll view消耗完前并没有滚动，这是就触摸结束了（ui.PointerChange.up），那可能引起cell //点击事件跳转事件 } final double physicalX = rect.center.dx * ui.window.devicePixelRatio; //376.0; double physicalY; final double needOffset = (count * unit).abs(); final double targetHeight = rect.size.height * ui.window.devicePixelRatio; final int scrollPadding = rect.height ~/ 4; if (needOffset <= targetHeight / 2) { physicalY = rect.center.dy * ui.window.devicePixelRatio; } else if (needOffset > targetHeight / 2 && needOffset < targetHeight) { physicalY = (orgMoveDis > 0) ? (rect.bottom - scrollPadding) * ui.window.devicePixelRatio : (rect.top + scrollPadding) * ui.window.devicePixelRatio; } else { physicalY = (orgMoveDis > 0) ? (rect.bottom - scrollPadding) * ui.window.devicePixelRatio : (rect.top + scrollPadding) * ui.window.devicePixelRatio; count = ((rect.height - 2 * scrollPadding) * ui.window.devicePixelRatio / unit.abs()) .round(); } final List<ui.PointerDataPacket> packetList =createTouchDataList(count, unit, physicalY, physicalX); exeScroolTouch(packetList,dstPoint); } else { new Timer(const Duration(microseconds: fpsInterval), () { replayScrollEvent(); }); } }上面代码大概处理逻辑：1.计算滚动方向，每个生成的触摸数据偏移单元 2.计算滚动的开始位置 3.生成滚动原始触摸数据列表 4.循环发射原始触摸数据，并计算是否滚动到指定的位置，如果还达不到指定的位置，则继续补给生成滚动原始触摸数据列表代码如下：第一数据是down触摸数据，其他都是move触摸数据。up数据在这里不需要生成，当滚动距离到目标位置后才另外生成up触摸数据。为什么这样设计？此处留给大家思考！List<ui.PointerDataPacket> createTouchDataList(int count,double unit,double physicalY,double physicalX) { final List<ui.PointerDataPacket> packetList = <ui.PointerDataPacket>[]; int uptime = 0; for (int i = 0; i < count; i++) { ui.PointerChange change; if (0 == i) { change = ui.PointerChange.down; } else { change = ui.PointerChange.move; physicalY += unit; if (i < 15) //前面几个点让在短时间内偏移的距离长点 这样避开单击和长按事件 { physicalY += unit; physicalY += unit; } } uptime += replayOnePointDuration; final ui.PointerData pointer = new ui.PointerData( timeStamp: new Duration(microseconds: uptime), change: change, kind: ui.PointerDeviceKind.touch, device: 1, physicalX: physicalX, physicalY: physicalY, buttons: 0, pressure: 0.0, pressureMin: 0.0, pressureMax: touchPressureMax, distance: 0.0, distanceMax: 0.0, radiusMajor: downRadiusMajor, radiusMinor: 0.0, radiusMin: downRadiusMin, radiusMax: downRadiusMax, orientation: orientation, tilt: 0.0); final List<ui.PointerData> pointerList = <ui.PointerData>[]; pointerList.add(pointer); final ui.PointerDataPacket packet = new ui.PointerDataPacket(data: pointerList); packetList.add(packet); } return packetList; }循环发射原始触摸数据，并判断是否继续补给代码如下：我们以定时器不断的往系统发送触摸数据，每次发送数据前都需要判断是否已经达到目标位置。void exeScroolTouch(List<ui.PointerDataPacket> packetList,double dstPoint){ Timer.periodic(const Duration(microseconds: fpsInterval), (Timer timer) { final ScrollableState state = element.state; final double curPoint = state.position.pixels;//ui.window.physicalSize.height*state.position.pixels/RecordInfo.recordedWindowH; final double offset = (dstPoint - curPoint).abs(); final bool existOffset = offset > 1 ? true : false; if (packetList.isNotEmpty && existOffset) { sendTouchData(packetList, offset); } else if (packetList.isNotEmpty) { record.succ = true; timer.cancel(); packetList.clear(); if (null != preReplayPacket) { final ui.PointerDataPacket packet = createUpTouchPointPacket(); if (null != packet) { ui.window.onPointerDataPacket(packet); } } new Timer(const Duration(microseconds: fpsInterval), () { replayScrollEvent(); }); } else if (existOffset) { record.succ = true; timer.cancel(); packetList.clear(); final ui.PointerDataPacket packet = createUpTouchPointPacket(); if (null != packet) { ui.window.onPointerDataPacket(packet); } verticalScroll(dstPoint, dstPoint - curPoint); } else { finishReplay(); } }); }问题回放整体框架图下图包括native和flutter，包括ui和数据。总结本文大概介绍了flutter ui手势问题回放，核心部分由四部分组成，一是flutter手势原理，二是flutter ui录制，三是flutter ui回放，四是整个框架图，由于篇幅有限，这四分部都介绍比较笼统，不够详细，请谅解！flutter录制回放代码其实很多，我这里只是附上比较重要，而且易于理解的代码。其他不重要或不易读懂的代码都省掉了。如果对里面的技术点感兴趣，你可以关注我们的公众号。我们后续会单独对里面的技术点详细深入的分析发文。如果觉得上面有错误的地方，请指出。谢谢后续的深入到目前为止，我们现在的flutter ui录制回放已经开发完成，但我们后续还需要继续优化和深入。我们后续从两个点来深入优化：1.如何在回放时模拟的触摸事件更逼真，比如滚动加速度，一次的滚动其实是一个曲线变化的过程 2.解决手势录制和回放不一致性。举个例子，在键盘里输入123，我们录制时截获到了手势123，但是由于业务上层的bug导致了当时输入3没有响应，输入框里只显示12，我们回放时模拟手势123，最终回放完后输入框显示123，所以这样导致录制和回放不一致性，这个问题怎么解决？这是个麻烦的问题，我们后续会解决。而且已经有这解决方案。本文作者：闲鱼技术–镜空阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

与其它自动化测试不同，前端的e2e测试一直是个老大难问题，难点主要在于 如何描述测试。自动化测试的核心是检查特定输入能不能得到符合预期的结果。对于单元测试和 API 测试来说，“特定输入”就是函数或者接口的参数，结果也是当前语言的数据类型或者通用的比如 JSON，二者一方面好描述，另一方面好验证。写起来就没什么难度。比如sum(a, b) { return a + b;}要验证输入 1 和 2，返回 3，则可以写成：const assert = require(‘assert’);describe(‘sum’, function() { it(‘should equal’, function() { assert.equal(sum(1, 2), 3); });});这里输入输出都很容易描述，所以自动化测试就没什么难度。但是 UI 测试并非如此。UI 是做给用户看的，所以，一个 UI 测试应该写成这种形式（这里拿一个类似于活动行的应用来举例子）：打开应用首页呈现出活动列表点击列表中的任一项进入活动详情页点击报名按钮登记个人信息点击付费按钮完成付费看到报名成功的信息这个过程当中用户的操作，很难和程序当中的抽象产物，比如按钮、列表等产生关联。操作的结果，“进入下一页”，也很难进行进一步的校验。所以在之前的生产实践中，大家喜欢用选择器来进行 E2E 测试，代表产品有 Cypress 和 Nightwatch。我觉得，这里一方面有 jQuery 带来的使用习惯延续和思维定势；另一方面，借助 XPath，找到特定元件，进行交互操作和校验元素几乎是大家唯一的选择。使用 CSS 选择器的方案并不完美，比如：选择器本身，和 UI 视图可能并没有强关联，写出来的测试可读性不强，一段时间之后回头去看，很可能会看不懂。HTML 的 DOM 结构并不稳固，随着功能增减版本迭代经常发生变化，这个时候我们就要跟着修改测试用例。DOM 结构不能反应视图的真实状态，很可能会出现虽然测试通过，但实际上在用户眼里仍然是错误的表现。那么，说了这么多不容易、其它方案的不完美，我的解决方案又是怎么样的呢？这里请容许我卖一下关子，下次再介绍由我厂 OpenResty Inc. 打造的前端自动化工具 Navlang。大家好，我是 Meathill，目前在 OpenResty Inc. 负责前端开发工作。今年我会利用业余时间，介绍我厂在前端方面的工作，包括各种垂直领域，比如自动化、DevTool protocol、插件开发、Vue、CodeMirror、组件化等等，内容包括进展、经验、心得、踩坑、产品等。欢迎大家关注本专栏，也欢迎大家光临我的博客：山维空间。如果你有任何疑问问题都可以在 SF 和我的博客上向我发问，我一定尽量答复。

WebDriver是一个浏览器远程控制协议，是一个既定标准，它本身的内容非常丰富，本文不可能全部介绍，本文仅粗略带大家了解一下WebDriver的部分内容以及一个小的实际应用。想深入了解的请参考W3C文档WebDriver.问题背景开发的同学都知道公司为了便于开发和测试都会有多套环境，比如dev开发环境、qa测试联调环境、pre预发模拟线上环境、online线上环境。经常切环境也是一个比较繁琐的事情，简单来说，作为一个前端开发，频率最高的操作路径是：1.通过SwitchHosts切换host2.选择目录和网关（由于环境不够用，但是又需要部署多套代码。为了解决这个问题，我们利用nginx来在一台机器上配置多个目录，每个目录对应不同的代码，当你访问这个页面的时候，网关会记住你所选择的目录，进而对你的请求进行相应的转发）3.登录网页进行ui调试和接口联调SwitchHosts切换host还算方便，但是选择目录、选择网关、打开网页输入用户名密码然后点登录，这个过程操作频率比较高，有点繁琐。能不能自动化这个过程呢？熟悉自动化测试的同学对这个就非常了解了，端到端测试就是利用自动化测试套件模拟用户访问网页的过程。这里我采用selenium-webdriver这个库，通过node来执行自动化脚本，代码如下。那么selenium-webdriver到底是如何与浏览器进行交互的？如何与不同的浏览器进行交互呢？下面就要引入主角了—— WebDriver, WebDriver是W3C的一个标准，它是一个标准，所以不同的浏览器都会有自己的实现，而selenium-webdriver是通过WebDriver协议与浏览器进行交互的。WebDriver是什么WebDriver是W3C的一个标准，是一个远程控制协议，它提供了跨平台和跨语言的方式来远程操控浏览器，它提供了一系列接口来访问和操作DOM，进而控制浏览器的行为。它使得web开发者能写一些自动化脚本来测试网页。WebDriver的工作过程（主要参考：https://blog.csdn.net/ant_ren…）浏览器在启动后会在某一个端口启动基于WebDriver协议的Web Service，接下来我们调用WebDriver的任何api时，都需要借助一个ComandExecutor发送一个命令（也就是给监听端口上的Web Service发送一个http请求），这个命令会告诉浏览器接下来要做什么。WebDriver的实际应用selenium-webdriver这是一个浏览器自动化库，它提供了许多浏览器自动化接口，用于测试web应用。除了通过npm安装selenium-webdriver之外，还需要安装浏览器相应的驱动。它相应的api和用法selenium-webdriver在我们new一个WebDriver的过程中，selenium首先会确认浏览器的native component是否存在可用而且匹配的版本，然后就在目标浏览器里启动一整套Web Service，这套Web Service使用了selenium自己设计定义的协议，名字叫做The WebDriver Wire Protocol。这套协议非常之强大，几乎可以操作浏览器做任何事情，包括打开、关闭、最大化、最小化、元素定位、元素点击、上传文件等等。参考资料https://www.cnblogs.com/linbo…https://cloud.tencent.com/dev...http://www.cnblogs.com/sunada…

作者：WeTest小编商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/433.htmlWeTest 导读中国移动视频用户规模越来越大，各类移动视频APP也百家争鸣， B站作为国内知名的年轻人文化社区，bilibili在推出移动端时，除了坚持自身的独特定位以外，对其APP的质量也十分重视。18年中旬，WeTest深度兼容测试团队和B站的故事就此开始。“弹幕发送”“视频分辨率” “直播间送礼”是主要关注点作为视频弹幕类APP，通常会关注其使用频率最高的场景，bilibili测试的主要场景如下：1.用户常用场景，如登录界面、推荐页、相关视频、首页搜索等。2.作为弹幕视频APP，bilibili十分关注直播间/播放器场景的兼容问题，如弹幕发送、弹幕举报，调整视频分辨率。社交场景，如发布个人动态，直播间送礼等。可以发现，弹幕发送，视频分辨率，直播间送礼是bilibili app在兼容测试过程中的核心关注点。WeTest的兼容测试方案一、测试用例设计根据bilibili的测试需求，WeTest与bilibili团队共同设计了详尽的测试脑图，尽可能的覆盖尽可能多的场景：bilibili测试用例脑图而部分重点场景，为了保证其兼容性质量，WeTest进行了反复的测试，保障外网质量的稳定。部分场景测试过程展示：1. 模拟真人发布动态成功输入一条“哔哩哔哩”动态2. 视频播放的UI界面功能包括全屏播放视频，调整视频分辨率，关闭/开关弹幕等等。3. 在视频详情页发送实时弹幕调出弹幕输入框，输入文字“bilibili”。针对bilibili的特殊情况，比如调用相机拍照功能、视频播放的UI界面显示，直播时赠送礼物等，WeTest团队也逐一攻克。二、24小时高效测试执行在确立测试排期后，WeTest从执行方案到产出报告，再从产品报告到人工复查，最多需要花费24小时。APP质量问题刻不容缓，将APP兼容性适配交付给WeTest，24小时内便能够收到一份高质量、精准定位兼容性问题的报告。三、专业报告产出，精准定位问题通过WeTest兼容测试报告，用户可以迅速了解到每款设备的测试过程，准确定位测试问题。所有测试设备的测试过程都有单独的截图和性能数据时间轴，可以在设备的测试详情里查看。测试过程中常见的问题具体包含：APP Crash、拉起失败、安装失败、进程退出等问题左侧是测试步骤概览问题列表里是本次测试过程中所有出现的问题，可以根据不同维度筛选。测试完成后，WeTest平台会自动生成测试报告，在报告中可以详细看到每台设备的测试运行情况，测试发现的问题在报告中都有对应的日志截取，以方便客户查找原因。深度兼容测试的服务优点还体现在人工复测上。WeTest专业测试人员会检查每一台机型的截图，并对一些平台无法检测的问题进行复查。四、覆盖各类主流机型、新老机型，涵盖各层级用户在每一次为bilibili提供兼容测试服务过程中， WeTest专业测试人员都会对测试重点、测试时长、测试资源以及测试额度多个方面内容都进行了专业评估。WeTest基于腾讯大数据统计，提供实时更新的主流机型，覆盖苹果、华为、oppo、vivo、小米等品牌几乎所有品牌，同时兼顾老机型、低配设备，精准覆盖90%以上的用户，高效助力bilibili发现目标机型兼容性问题。为客户省去测试技术、人力成本、设备数量等各类成本投入，综合折算下来， WeTest深度兼容测试服务可以为用户节约70%的测试成本。效果显著，bilibili兼容问题影响范围降低93%WeTest深度兼容测试团队针对bilibili APP的特性，定制了个性化的自动化测试脚本，深入覆盖了核心场景，完成多轮次的深度兼容测试服务。在整个测试过程中，WeTest累计为bilibili诊断出上百个兼容问题，影响的用户范围下降了93%左右。WeTest助力bilibili APP进行适配优化，降低版本上线质量风险，共同提升bilibili用户的使用体验。bilibili表示，为了保障大体量用户的使用体验，需要足够的机型覆盖到足量的手机用户规模，WeTest很好的帮助我们实现了这点，WeTest之前积累的一些视频行业APP测试的经验，也在这次测试中的用例设计和执行中很明显的体现了出来，帮助我们覆盖了最核心的用户场景，在新版本上线前起到了有效的支持和保障。“深度兼容测试”现已对外，腾讯专家为您定制自动化测试脚本，覆盖应用核心场景，对上百款主流机型进行适配兼容测试，提供详细测试报告。点击：https://wetest.qq.com/cloud/deepcompatibilitytesting 即可体验。如果使用当中有任何疑问，欢迎联系腾讯WeTest企业QQ：2852350015

API 测试的基本步骤通常来讲,API 测试的基本步骤主要包括以下三大步骤：1、准备测试数据；2、通过通用的或自己开发的API测试工具发起对被测API的request；3、验证返回结果的response。常用的API测试工具有命令行工具cURL、图形界面工具Postman或SoapUI，支持API性能测试的JMeter等。API复杂场景举例通过使用基础的测试工具，可以做简单场景的API测试；而项目进行过程中，为了解决实际的一些问题，我们会设计更加复杂的测试场景，下面列举几个实际项目中的典型场景。场景一：API串联调用以协议支付为例，我们知道，三方公司接入网联后，用协议支付取代代扣，而协议支付的流程中需要用户输入银行返回的验证码完成绑卡。从接口层面上看，顺序是先调用协议签约API，返回状态成功且获取到短信验证码后，再使用此短信验证码作为输入参数调用代扣API。协议签约和代扣两个API是顺序调用，而且在两次调用中间有获取手机上的短信验证码，这些过程都需要通过程序自动化实现以提高效率。场景二：API接口加密为保证API接口安全，系统间和系统内模块间互相访问需要进行加密处理，常用的加密方式有DES、AES、RSA、MD5等，各系统的加密方式并不一样（接口调用方和接口提供方约定好即可），意味着API测试需要支持多种自动化加密方式程。某些系统还会返回加密的响应报文，也需要识别并解密。场景三：异步API测试异步API指请求发出后后收到一个同步响应，但并不是最终处理结果，最终结果通过回调或者主动查询获得。对于这样的API，同步响应的验证只是第一步，后续还得继续验证DB中的值、MQ中的值、以及异步回调是否成功等。对于异步回调，我们可以模拟回调地址来验证成功与否；而对于主动查询，我们就得通过查看DB中的状态值来验证了，但是查询到结果的时间点不确定，几分钟到几小时都有可能，这就得有一个定时DB查询任务去验证。场景四：API测试中的外部依赖APIA调用APIB且B不可用，此时如何测试APIA需要考虑。比如支付系统对三方支付通道、对银行的依赖，并不是所有的三方都支持测试环境，解决此问题的核心思路是搭建MockServer，而且尽量做到通用性，我们开发了一套Mock系统 -aMock，通过页面录入接口信息，保存在数据库内，通过Nginx访问配置好的Mock接口，后台统一处理请求信息，然后通过URL和报文特性去匹配特定的响应信息。API测试平台我们的API测试平台是要基于业务场景的，即要支持各业务的共性需求，又要针对不同业务的个性特点加以开发来丰富API测试能力；而且，对用例也要有很好的规划，结果有清楚的展示，测试平台架构如下图：BIT：业务接口测试（BusinessInterfaceTest）SUT：被测系统（SystemUnderTest）TestCaseManagement：测试用例管理，包括从测试用例到测试用例集，再到测试任务的数据关系的建立和维护。测试用例是最小单位，测试用例集是从某一维度对用例进行的归集，测试任务即测试执行，可立即触发也可定时执行，只能执行测试用例集。Util：工具类封装，主要提供数据加解密，数据类型转换，配置文件读写，数据字典的缓存服务等。Validator：接口响应字段和数据库字段的验证封装。RiskManagement：风控处理，因为会涉及支付真实资金，需要内置风控规则来保证资金安全，风险可控。Timer：定时任务服务，包括1）串联API用例中，前置用例的状态判断；2）异步API的数据库校验；3）超时API用例的失效状态判断；4）定时执行的任务计划。MockServer：用例依赖的外部系统Mock服务。Portal：API测试平台门户网站，包括测试用例的录入，维护，测试任务的执行，结果查看，导出等都通过门户进行操作。DB：存储测试用例数据以及相应的测试任务、测试报告数据，还有项目配置等。目前API测试平台上各项目维护用例总结1200多条，以回归用例为主，且还在不断增加中，随着用例的不断添加，平台也历经了一系列优化，下面就谈谈这个过程中的一些思考。测试数据准备对于大量API用例的执行，需要数据驱动测试，也就是说可以将测试数据和测试代码分离解耦，这样便于测试数据的维护同时也保证了数据的准确性，用例设计格式是这样<accountName>${accountName}</accountName><accountNo>${accountNo}</accountNo><identNo>${identNo}</identNo>几个关键数据节点由DataProvider提供，为了增加测试覆盖度，数据库相似的测试数据有多条，比如多条四要素（银行卡号、手机号、身份证号、姓名）数据，当大量用例需要读取时，可采用缓存方式存储并读取到cList里面，通过循环遍历，使每条测试数据都可以被均匀读取，下面是替换关键数据节点的一段代码，将cList数据依次赋给对应变量。测试执行的逻辑控制很多情况下的测试是场景化API测试，涉及用例的顺序调用。如下图，“签约-成功-kftn-协议”依赖于“签约-成功-kftn短信”的执行；在添加用例时配置好关联关系。执行时，会根据用例属性将此两条依据有无前置条件划分为两类，分别存放于两个list里，无前置条件的用例可以马上执行，有前置条件的用例，设置TestStatus为0，等待定时任务轮询触发执行。分类执行代码如下图定时任务每分钟执行一次，下面一段是判断前置API的执行状态，只有“0000”代表成功，当前API才能执行，执行时，需要读取前置用例的结果数据并传入；如果前置API失败，则停止任务执行，多条API用例顺序执行也是同样的道理；即使有外部依赖的用例，比如短信验证码，我们也可以通过写一段手机APP程序自动上传短信验证码到服务器，然后触发延迟获取验证码，得到后通过DB记录用例执行的状态和结果，并传给下一个API使用，就完成了多用例的顺序执行。此外，测试任务的执行封装成restful接口，可以更加灵活地和目前团队正在开发中的CICD系统结合一起。测试结果的验证通过分析业务，API的结果校验大致分为两种类型，响应校验和数据库校验。响应校验是针对response报文字段的校验，可精确匹配也可通过正则表达式模糊匹配；数据库校验是基于定时任务的，需要在用例里面根据约定格式设置校验方法，比如下面的sql检验条件，会在准生产环境通过指定单号以及其他条件去查询返回字段，并判断status是否为7，从而判断用例是否成功。PreOnline.3|,|SELECTtb.outer_batch_no,tb.status,bs.send_statusFROMbs_outpay.trans_batchtbleft joinbs_outpay.es_business_sendbsontb.business_batch_no=bs.entity_uuidandbs.entity_status<>2 WHEREtb.outer_batch_noin (?) order bytb.CREATED_TIMEDESC|,|{“status”:“7”}用例状态分为成功、失败、处理中、超时四种状态，分别通过配置相应SQL查询条件去映射，成功和失败是终态，处理中则是需要定时任务继续查询，超时，是我们内部设定的一个状态，目前是超过一个小时未返回终态设为超时，此API用例失效并报警，需要人工参与查看。所有这些规则都是在用例建立和编辑的时候添加的，如下图，一条用例包括了响应校验（值校验、key校验）和数据库校验，通过这种比较灵活的设计，基本能够满足复杂API测试场景。需要指出一点是，很多应用不允许外部测试平台直接访问数据库，我们的解决办法是写一个数据查询服务部署在系统环境中，只提供查询功能，并且有加密验证保证通讯双方（测试平台和数据查询服务之间）可信。通常来说，测试平台或框架可以从某种层面上理解为工具链的串联，开发此平台的过程中，我们使用的技术栈有springmvc+herbinate做逻辑控制、amazingUI做用例管理、echart做结果展示，还使用Jenkins做任务调度等，用户就是各业务线测试人员，他们不需要了解具体代码的实现，但是需要对系统结构以及用例规则有很好的理解，这样才能设计出符合测试场景的用例。任何测试平台的设计还是要基于业务的，后续我们对API平台的推进策略是，继续增加场景化功能以支持更多业务类型的测试，比如清结算系统中日终、日间的跑批任务，对账文件的数据检验等，增加大并发能力并和性能测试工具相结合。-END-作者：孙鹰 宜信技术学院官网：http://college.creditease.cn/…

软件测试工程师是一个历史很悠久的职位，可以说从有软件开发这个行业以来，就开始有了软件测试工程师的角色。随着时代的发展，软件测试工程师的角色和职责也在悄然发生着变化，从一开始单纯的在瀑布式开发流程中担任测试阶段的执行者，到敏捷开发流程中QA（Quality Assurance）角色，为整个团队和产品的质量负责，测试工程师的职责和边界不断的扩大。近年来互联网行业的很多测试工程师被称为是测试开发工程师，也就是要具备自动化测试和测试工具开发能力的测试工程师，可以说是对测试工程师的能力要求达到了一个新的高度。相信有过测试工作经验的同学都会深有体会，不管是瀑布式还是agile模式，测试人员的工作总是被压在产品发布的最后阶段，整个团队的压力似乎都压在测试工程师身上，没有人会理会开发过程中产生的延误，因为那已经过去，可以在retro meeting的时候diss，但是目前最重要的问题是完成产品的发布上线。所以在寻找测试工程师需要什么技能之前，测试工程师的核心问题是什么，这是我们要搞清楚的。测试工程师面临的核心问题如何以最小的投入，最大程度保证产品的质量这个问题相信大家都有所体会，商业社会追求的就是效率，甚至是极致的效率。测试工程师也不能例外，不管是叫测试工程师，QA，或者是听着高大上的测试开发工程师，其实老板们的目标是一致的，就是在尽可能少的投入，最大程度保证产品的质量。说得现实一点，你的薪资水平就取决于你能解决这个核心问题的能力。明确了我们的目标，我们所需要的能力，也是围绕着这一个目标来设定的。概述按照笔者的经验和理解，一个软件测试工程师需要具备以下的技能：测试设计能力代码能力自动化测试技术质量流程管理行业技术知识数据库业务知识测试设计作为一名测试工程师，最基础的能力应该就是根据产品来设计测试用例的能力。最基础的能力往往也是最难做到精通的能力。要设计好的测试用例，需要对产品的特性和业务非常的熟悉，对用户的使用场景有着系统化的思考。除此之外，还有一些科学的测试用例设计方法可以帮助我们设计规范化的用例，而不是仅仅根据经验或者天马行空的想法来设计用例。业界有一些经典的测试用例设计方法需要测试工程师掌握：边界值分析等价类划分因果图判定表正交实验设计上述的这些方法并不是教条，而是帮助我们理清测试用例设计的思路和提高效率的工具。代码能力在传统的思维中，对测试人员的代码能力要求似乎不是很高，在业界确实也是这样的。很多测试工程师基本上不具备代码的能力，更多是测试的执行者。但是在当今这个时代下，要想突破传统功能测试人员的天花板，代码能力是必须的。具备代码能力的测试工程师有这样两个优势：阅读开发代码如果能够具备阅读开发代码的能力，对于提高测试人员的效率是很有帮助的，它可以帮助我们做到这些一些事情通过开发修改的代码预估影响的范围，即测试的范围参加技术评审，预估测试的风险，难点，重点通过代码的逻辑设计测试用例，强化测试用例的覆盖程度对缺陷进行初步的定位其实可以做到的事情还有很多，体现在测试过程的很多细节当中自动化测试的开发自动化测试是测试发展的方向，也是提高效率的有效方法。具备了代码能力，你可以轻松的驾驭各种流行的自动化测试框架和用例开发。自动化测试接着上面关于自动化测试的讨论。在目前的热门公司的招聘中，自动化能力已经是必备的能力，也是大家很关注的一个领域。目前可以粗略的把自动化测试分为这么几类：UI自动化UI自动化实现的目标是模拟人在产品UI界面上的操作，从而观察结果来完成测试的执行。UI自动化也可以从客户端的形态上分为PC端和移动端的自动化测试，有这样一些著名的自动化工具需要我们掌握：SeleniumSelenium是一个很经典的WEB端产品的UI自动化工具，针对不同的开发语言都有很好的支持。它的原理简单来说就是通过WebDriver把脚本产生的操作指令传递到浏览器，执行我们需要的操作并且获取相应的反馈，在脚本中完成校验。Appium从这个名字就可以看出这个工具和Selenium的相似之处。其实Appium可以理解为就是移动端的Selenium。同样也是在移动端模拟人的操作来实现执行测试用例的目的。随着移动互联网时代的到来，更多的业务已经从PC的WEB端转移到了移动端，移动端的自动化测试越来越重要。其实UI的自动化实现的原理都是很类似的，基本的逻辑都是：定位元素操作元素获取反馈最后通过某种测试用例框架来管理测试用例，例如python的unittest，JAVA的TestNG，Ruby的respec等等。所以说了解了某一种UI自动化的框架和工具，很容易的就能触类旁通的学习新的框架和工具。接口自动化在目前SaaS成为主流的情况下，API，即接口，成为了支撑业务的核心部分。前端页面和App里面的业务数据都是通过各种API与服务器进行通信，从而实现业务功能。目前大多数的接口都是基于HTTP协议的，其中Restful的接口又占大多数。而很多语言，例如Python和Ruby都有很好的库来支持HTTP协议的请求，这就为我们设计接口自动化提供了很好的基础。回到我们的核心问题，投入产出比的衡量。UI的自动化无论是从实现的成本还是维护的成本来说都是巨大的，所以业界越来越把重心放到了接口层的自动化实现上。接口的自动化具备这样的优势：运行效率高开发成本低维护成本低可以与开发代码同步开发接口自动化的实现思路也是简单明了的，那就是模拟浏览器，发送HTTP请求来实现对接口的调用，然后比较返回与期望值，达到验证结果的目的。当然，要设计一套真正高效的接口自动化框架也是不容易的。这里面涉及到如何提高用例的开发效率，降低开发维护成本等关键问题。同时还可以把接口测试与性能测试结合起来，丰富接口自动化测试的内涵。质量管理流程在敏捷开发的流程中，测试工程师有了一个新的定义：Quality Assurance Engineer。而测试的执行仅仅是职责中的一部分，更为重要的是要为整个团队的产品质量负责。从整个sprint的周期来看，QA工程师都要始终如一的贯彻质量保证的意识，与开发的关系也从早期的发现bug，转变为如何帮助开发团队一起提高产品的质量。同时还要和产品团队密切的合作，在需求的分析阶段就介入，分析质量保证工作如何规划和设计，而不是在产品发布前的测试执行阶段才介入。这个里面还包含很多Soft skill的要求，包括如何与团队合作，沟通等等，这也是敏捷开发模式的关键之一。行业技术知识这一部分内容其实涵盖的内容是非常丰富的，就以互联网行业举例吧。对于一个互联网产品，测试工程师需要了解的甚至是精通的知识是很多的，从前端页面的技术栈，API的设计，后端服务器的设计，后面会专门提到的数据库，还有整个服务的架构等等，测试工程师都需要有所了解。针对这个问题，其实有一个非常好的问题可以帮助大家去梳理涉及到的知识，这就是：从在浏览器的输入框输入一个网址，到看到网页的内容，这个过程中发生了什么？回答这个问题的深度和广度，基本就能反映一个测试工程师对于互联网产品技术的掌握情况。在这里呢，我简单的罗列一些涉及到的技术和概念，这些内容对于我们测试产品，都是非常有帮助的。DNSTCP/IPHTTPSSLRestfulHTMLDOMCSSRenderXpath服务器nginxSQLCookie&SessionXSS，CSRF这里仅仅是涉及到一部分内容，具体的内容可以根据工作中遇到的场景去深入学习和了解。数据库之所以把数据库单独列出来，是因为数据库的知识对于当今的很多产品都是非常核心的内容。不管是在手动测试还是自动化测试中，都有需要到数据库进行数据校验的时候。目前主要使用的数据库可以分为两类：关系型数据库非关系型数据库关系型数据库关系型数据库是最常见的数据库类型，这类数据库通过RDBMS数据库程序来进行管理和使用，常见的有SQL Server, MySQL等等。关系型数据库中强调一个事务（Transaction）的概念。所谓事务是用户定义的一个数据库操作系列，这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。例如在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。持久性（Durability）：一个事务一旦提交，他对数据库的修改应该永久保存在数据库中。对于实际的应用来说，SQL语言是必须要掌握的。能够通过SQL语句在数据库中找到需要的数据，是测试工程师必备的技能。SQL语句的语法大体上比较类似，在一些细节上不同的RDBMS会有些许的差别。对于自动化实现来说，在自动化测试中通过访问数据库来获得期望值也是很常见的场景。不同的语言都有访问数据库的库，整体来说应用也很简单。非关系型数据库随着互联网中大量的非结构化数据的产生，例如社交网络等等应用，用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经正在以几何级数的速率增加，同时还面临大量的数据挖掘工作，传统的关系型数据库已经无法满足。所以NoSQL渐渐的发展了起来。NoSQL最突出的特点就是数据的非结构化，通俗的讲，就是数据不再是以列和行这样的形式存储的。NoSQL存储数据的方式很多：值对存储，列存储，文档存储。例如比较常见的MongoDB就是将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。RDBMS vs NoSQLRDBMS高度组织化结构化数据结构化查询语言（SQL） (SQL)数据和关系都存储在单独的表中。数据操纵语言，数据定义语言严格的一致性基础事务NoSQL代表着不仅仅是SQL没有声明性查询语言没有预定义的模式：键 - 值对存储，列存储，文档存储，图形数据库最终一致性，而非ACID属性非结构化和不可预知的数据CAP定理高性能，高可用性和可伸缩性业务知识对于测试工程师来说，所测试产品的业务知识也是非常重要的。一个测试工程师可能已经具备了上述的所有技能，但是怎么把这些技能用来解决我们最先提到的软件测试的核心问题呢？这个里面的关键，或者说中心点，就是你所测试的产品的业务。测试的方法，规划，实施方法都是多种多样的，如果在这些方法中进行选择，所依赖的正是对产品的业务的深刻理解。这里的产品业务不仅仅指产品的特性，同时还包括了产品的用户特征，用户的使用习惯，以及由此带来的对产品的流量趋势。也可以说，测试人员必须要站在用户的角度来分析产品，而不是产品开发人员的角度。测试人员还需要找到产品的核心功能和核心业务，通过这样的分析来进行测试优先级的划分，以及缺陷的定级。同时对于自动化测试的规划和架构也有着重要的影响。例如在自动化测试中要首先覆盖那些核心的业务和功能，同时根据业务的特性，用自动化的方法去模拟用户的使用场景，把有限的自动化资源投入到最关键的部分。这一块技能听起来可能很虚，好像没有什么具体的知识点，但是在不断的工作和总结中，优秀的测试工程师是能够总结出一套符合某一类产品的测试方法的，甚至还可以提炼出一些更具备通用性的best practice，用到不同的产品中。说在最后或者这样一篇短短的文章无法涵盖软件测试的内涵，但是笔者也只是想抛砖引玉，让读者能够通过这样一种不能算全面的梳理，结合自己的工作经验，对自己所从事的软件测试工作有一个更深的理解。笔者计划根据这篇文章所列出的技能树，分别写文章进行更加细致的梳理和总结，希望能够和各位同行一起学习，一起进步，同时非常欢迎大家指正我的错误和不足。

传统的测试用例需要测试或者开发人员将用户的操作用代码表示出来，通过断言判断是否和预期一致，写测试用例也占用了部分时间，加上版本迭代测试用例的维护成本也较高，于是基于无埋点的需求相结合自动化测试来检测埋点，及时告警，提高准确率和代码质量，为了减少测试用例的开发维护时间，诞生了自动生成测试用例的方案，另外不因为出错而中断代码的执行测试框架https://github.com/Tencent/FA…测试框架使用FAutoTest,可以测试小程序，H5,对比曾经用过的selenium，代码运行要稳定很多，wait的时间也都很稳定，对比phantom截图像素对比，可以细化测试用例的行为，基于x5内核的driver能测试微信环境，能覆盖到现业务的使用场景，具体使用，可以参看上述链接如何自动生成测试用例1.首先在后台配置测试用例,具体思路获取点击位置xpath，该测试用例预期文案或者样式请求接口将测试用例数据配置写入表，并提供接口拉取所有测试用例数据2.配置完测试用例，python请求接口获取测试用例配置的入参(in字段)，出参（out字段），，in里边的字段是入参，url是点击行为所在的页面，xpath是点击的位置，out里边的字段是出参，url是预期要跳转的页面，xpath是预期页面的标记位置，带text是预期的文案，带class是预期的样式，把用户行为尽量拆分成入参，出参能够表达的行为3.python请求接口，遍历接口数据生成前缀为test_case_xxx的测试用例，自动生成测试用例而不是在一条测试用例里边执行完所有的行为，避免出错而中断代码执行，代码如下生成测试报告1）安装HTMLTestRunnerHTMLTestRunner 是 Python 标准库的 unittest 模块的一个扩展，它可以生成 HTML的 测试报告。首先要下 HTMLTestRunner.py 文件，将下载的文件放入…pythonLib目录下python2版下载地址：http://tungwaiyip.info/softwa…python3版下载地址：http://pan.baidu.com/s/1dEZQ0pz2）测试脚本中引入from HTMLTestRunner import HTMLTestRunner3）定义测试报告的路径，调用HtmlTestRunner# 按照一定的格式获取当前的时间now = time.strftime("%Y-%m-%d %H_%M_%S")# 定义报告存放路径filename = “../report/” + now + “.html"fp = open(filename, “wb”)# 定义测试报告runner = HTMLTestRunner(stream=fp, title=“测试报告”, description=“测试用例执行情况：")runner.run(suite())4）执行测试脚本，打印测试报告，生成html，但是测试报告中有乱码，参考网上解决方法：https://testerhome.com/topics…，测试脚本引入代码import sysreload(sys)sys.setdefaultencoding(‘utf-8’)修改HtmlTestRunner.py中的编码“latin-1”修改为“utf-8”后保存5）再次执行测试脚本，生成测试报告如下：

什么是API　API是Application Programming Interface的简写。　- 实现了两个或多个独立系统或模块间的通信和数据交换能力。什么是API测试　API测试是不同于UI级自动化测试，其主要关注在系统架构的业务逻辑层，所以其主要关注不在于UI操作或用户感观上，更重调用逻辑关系。如果你想学习软件测试的，我给你推荐个群：903217991，里面有从基础开始学习的软件测试学习视频讲解，还有大牛帮你解决疑惑。　与UI级自动化测试通过控制键盘输入和鼠标等操作不同的是：API测试，我们是通过工具或代码方式去调用特定的API，获取输出，并记录系统的响应。　API测试需要与应用程序的API进行交互，为了测试这些API，我们可以：　· 使用测试工具来进行测试　· 自己写代码的方式进行测试API测试准备工作　首先你得获取目标测试系统的API相关文档，例如API对应的参数格式、期望返回结果等（一由开发提供文档，二自己抓包分析）　就我们所处国内的实际情况，在大部分情况下，开发都没有成型的文档。所以作为测试人员，你应该具备以下技能：　· 优先去推动开发生成一份合适的API说明文档　· 掌握抓包分析工具，能够自己去抓包分析形成API文档　· 至少把http协议掌握，了解其报文结构　· 对用户业务熟悉，能把API级业务逻辑和用户业务结合起来API主要测试什么　API级测试至少应该覆盖以下测试要点：　· 验证API所暴露的资源是否恰当的列出、创建、修改、和删除　· 验证API是否功能可用以及用户友好，是否便于与其他平台集成　· 安全测试，验证API是否包含了必要的认证以及敏感数据是否做了脱敏处理，是否支持加密或明码的http访问　· 自动化测试，将API高度业务场景化，实现自动化测试　· 文档，形成足够的文档，确保API质量的可维护行API测试要注意什么　在API测试过程中要重点关注什么呢？　· API测试用例要进行分类分组　· 每个API测试用例都应该参数化　· 在测试执行时，优先执行API测试　· 测试用例应该尽可能做到可独立执行　· 为了确保覆盖率，应该为API的所有可能输入进行测试数据规划API测试能发现什么bug　在API测试时，一般会发现哪类型的bug呢？　· 无法正确处理错误的深入条件　· 缺少或重复功能　· 可靠性问题　· 安全问题　· 多线程问题　· 性能问题　· 响应数据结构不规范问题　· 有效参数值不能正确处理API测试有哪些工具　· SoapUI　· JMeter　· PostMan　· 自己写代码　其他工具不推荐了，笔者首推SoapUI或自己写代码API测试你可能遭遇哪些大坑　· 无效的测试数据规划，导致你的参数穷举组合　· 因为没有界面，开发又不提供文档的情况下，大部分人无从下手，会一脸懵逼　· 平时测试大都关注正常的正常的情况，但要注意异常处理API必须进行测试，你懂的　· 代码你要会点代码，会点HTTP协议，不然没法沟通交流总结如果你想学习软件测试的，我给你推荐个群：903217991，里面有从基础开始学习的软件测试学习视频讲解，还有大牛帮你解决疑惑。 ...

前言：希望你能喜欢，不为别的，只为这份坚持。【背景】最近有些同学因为工作需要，看了我之前的学习笔记，然后跑来问我，说领导让他负责产品的性能测试，但他买了几本书，也安装了相关的工具，看来看去觉得太复杂了，觉得无从下手，就跑来问我：“性能测试是不是很难做？”【你问】性能测试是不是很难做？【我答】我从零距离接触性能测试到今天，也才一年多的时间，在这上面走过的路崎岖蜿蜒，个中滋味只可意会，不可言传。虽然我已经从入门到“放弃”了，但是我一直在思考和寻找，怎么样才能让性能测试不再看上去那么难，不再那么看着“高不可攀”。性能测试其实就是测试的一种类别，那么相应的，它也是有一套标准流程的，无外乎就是需求分析、测试计划制定、测试执行、结果分析等几个环节。所以，针对性能测试流程里的几个环节，我把自己换位到当初的小白，去思考自己当时最希望得到什么样的支持和帮助，再结合产品化的思维，思考出下面这样一个可以被拿来主义“的性能测试框架或指导性体系。1、是什么？性能测试里的常用基本概念、测试方法和标准流程的定义和解释；2、做什么？性能测试需求的分析方法，可以采用 checklist 的问题形式来帮助使用者得出对应需求所需要采用的性能测试种类，是压力测试，是稳定性测试，还是健壮性测试等等；3、怎么做？3.1 对应着上述第2步，得出来的具体的测试种类，每一种都有相应的测试方法说明，包括需要准备什么样的数据、步骤和如何选取相应的脚本进行修改或组装；3.2 有一套对应的样例库，包含脚本（.usr）、参数化文件（.dat）、场景（.lrs），虽然说不可能百分之百通用或者套用，但至少在同类产品的性能测试中都能套用，它们都是相对独立、结构清晰的一个一个的数据包，便于更新和管理；4、怎么样？性能测试完成后，系统都会生成一个报告。针对常用的单分析图和组合分析图，有样图与我实际的图做对比，并告诉我这些数据图，分别代表着性能的哪些指标，这些指标的值，又分别代表着性能是好还是坏；5、怎么办？对于常见的性能问题，罗列出通用的解决方案，比如是应该检查并优化 SQL，还是应该修改服务端 Tomcat 的连接数大小等等。如果你想学习软件测试的，我给你推荐个群：903217991，里面有从基础开始学习的软件测试学习视频讲解，还有大牛帮你解决疑惑。如果能有这样一套产品化的性能测试框架，那么我想，性能测试这种大山对于大多数测试工程师来说，也就不那么”高不可攀“了，对吧？具有指导性的作业文件、测试计划模板、独立的测试数据和测试脚本、分布式测试环境搭建脚本或手册、测试报告和相应的分析模板，能支撑一套完整的性能测试框架迅速落地，快速适应不同的项目，并且能让测试工程师以最小的学习代价完成性能测试任务。不过，这么一套框架不是一朝一夕就能建立起来的，它必须是在性能测试工程师对理论有了很深入地理解，并通过多个项目的实战，从中总结、归纳而形成的一套方法论体系，再辅以相对独立的数据和脚本、计划模板、分析步骤和模板等相关工具。不断地打磨、优化和改进，才能形成一套不论是入门级的小白，还是进行中的老鸟，都可以轻松利用它登上高峰的这样一个产品。

什么是TestCafeA node.js tool to automateend-to-end web testingWrite tests in JS or TypeScript, run them and view results抓几个重点词语：1. E2E Web Testing 2.JSTypeScript 3. Node.js Tool。简单说就是Node.JS编写的Web端UI自动化测试框架。官网：http://devexpress.github.io/t…TestCafe VS Selenium这时我想你跟我都有个疑问，跟Selenium 有啥区别？这里个人简单阅读了下官方文档，写几个粗浅的对比。Selenium毕竟已经是Web自动化测试的W3C标准了，它有非常多的优势，但TestCafe 作为后起之秀我这还想夸夸Demo使用过程的几点优于Selenium的感受。TestCafe 不再像Selenium 通过各个浏览器提供的Driver来驱动浏览器，而是有点类似Selenium RC直接往页面注入JS来操作页面，所以使用过程中再也不用担心因为浏览器版本和Driver版本以及Selenium版本不匹配而照成的Case执行失败。TestCafe是一整套完整的自动化测试框架，不仅提供了Cases的管理，运行，失败自动重跑，错误自动截图，并发等，对页面和页面元素的等待也封装完善而且使用简单，不像Selenium需要借助其他框架或者二次封装智能等待或者使用隐示/显示等待而有点复杂。TestCafe 可以控制整体的执行速度，甚至可以细到某个操作的执行速度（这个有点类似慢放，用起来大家可以感受下，非常魔性）TestCafe 因为只要你的浏览器支持JS，所以支持桌面，移动端平台。TestCafe debug模式，通过代码配置或运行时设置，可以控制执行过程中失败时进入调试模式。PS：当然以上的感受并没有经过项目的积累，纯粹Demo过程中的总结，也不晓得真正用到项目中会有哪些坑得踩。跟大家推荐一个学习资料分享群：903217991，里面大牛已经为我们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！人生是一个逆水行舟的过程，不进则退，咱们一起加油吧！TestCafe 快速入门安装因为是Node.js 项目，可以直接通过npm安装，全局安装如下npm install -g testcafe快速Demo一个baidu.jsfixture baidu demo .page https://www.baidu.com;test(‘baidu search’, async t=>{ await t.typeText(’#kw’,“hao123”) .click(’#su’)});通过Chrome运行testcafe chrome baidu.js上面代码看不懂没关系，感受下TestCafe就行。Cases管理自动化测试，终归还是测试，是测试就离不开测试用例，那TestCafe如何组织管理测试用例？fixture 和 test一个js文件可以包含多个fixture，一个fixture可以包含多个test。 我们可以理解为fixture是个集合，test标注的每个函数模块是一个case。语法fixture(“测试集描述”)fixture 测试集合描述test(‘用例描述’，fn(t))Demofixture(“cases manage”).page(“https://www.baidu.com”);test(’this case 1’, async I => { console.log(“this is case 1”);});test(’this case 2’, async I => { console.log(“this is case 2”);});test(’this case 3’, async I => { console.log(“this is case 3”);});fixture(cases manage 2).page(https://testerhome.com/#gsc.tab=0);test(’this case 1-1’, async I => { console.log(“this is case 1-1”);});test(’this case 2-1’, async I => { console.log(“this is case 2-1”);});test(’this case 3-1’, async I => { console.log(“this is case 3-1”);});运行结果：其中你会发现每个test 执行之前都会执行fixture打开页面的操作，但只会启动一次浏览器。那这时又会一个新的问题，除了打开页面的前提条件，是否框架自带了更多的前提/后置条件的处理了，也就是各种beforexxx。当然！fixture 的前置条件fixture.beforeEach( fn(t) )：每个test执行之前都会被运行fixture.afterEach( fn(t) )：每个test执行之后都会被运行fixture.before(fn(t))：比beforeEach更早运行，且每个fixture只运行一次fixture.after(fn(t))：比afterEach更晚运行，且每个fixture只运行一次Demojfixture(beforeeach test1) .page(https://www.baidu.com) .beforeEach(async I => { console.log(’this is beforeEach’) }) .before(async I => { console.log(’this is before’) }) .after(async I => { console.log(’this is after’) }) .afterEach(async I=>{ console.log(“this is afterEach”) });test(“test beforeAndafter”,I=>{ console.log(“1111”)});test(“test beforeAndafter”,I=>{ console.log(“2222”)});运行结果：test的前置条件test.before(fun(t))：该test运行之前运行test.after(fun(t))：该test运行之后运行Demofixture(beforeeach test1) .page(https://www.baidu.com) .beforeEach(async I => { console.log(’this is beforeEach’) }) .before(async I => { console.log(’this is before’) }) .after(async I => { console.log(’this is after’) }) .afterEach(async I => { console.log(“this is afterEach”) });test .before(async t => { console.log(this is test's before) }) (“test beforeAndafter”, I => { console.log(“1111”) }) .after(async t => { console.log(this is test's after) });test(“test beforeAndafter”, I => { console.log(“2222”)});运行结果：注意： 从控制台输出看，test的before/after 会覆盖fixture中的beforeEach/afterEach。也就是说如果一个test里面包含了before/after 那么fixture中的beforeEach/afterEach对该test无效。跳过测试fixture.skip ：跳过该fixture下的所有testtest.skip : 跳过该testfixture.only ：只执行该fixture下的所有test，其余的fixture下的test全部跳过test.only ： 只运行该test，其余全部跳过元素定位Demo1.创建Selectorsimport { Selector } from ’testcafe’;2.使用Selectors// 通过css定位 const osCount = Selector(’.column.col-2 label’).count; // 通过id定位 const submitButtonExists = Selector(’#submit-button’).exists;同时因为是JS注入方式，所以定位方式非常灵活，几乎JS中定位元素的方式都支持。 例如import { Selector } from ’testcafe’;fixture My fixture .page http://devexpress.github.io/testcafe/example/;const label = Selector(’#tried-section’).child(’label’);test(‘My Test’, async t => { const labelSnapshot = await label(); await t.click(labelSnapshot);});test(‘My test’, async t => { const secondCheckBox = Selector(‘input’) .withAttribute(’type’, ‘checkbox’) .nth(1); const checkedInputs = Selector(‘input’) .withAttribute(’type’, ‘checkbox’) .filter(node => node.checked); const windowsLabel = Selector(’label’) .withText(‘Windows’); await t .click(secondCheckBox) .expect(checkedInputs.count).eql(1) .click(windowsLabel);});同时还支持自定义扩展选择器，而且针对当前流行的React,Vue,Angular,Aurelia前端框架，还有特点的定位选择器，这里内容很多，有兴趣直接看官方文档：http://devexpress.github.io/t…操作元素操作其实上面例子我们已经用过点击，文本输入等方法了，官方也给了很全的api文档和demo：http://devexpress.github.io/t… ，这里就讲下一些比较特殊的元素或浏览器的操作。- resizeWindow()：设置窗口大小- t.maximizeWindow( )：最大化窗口fixturedemo.page(‘https://www.baidu.com’);test(‘设置win窗口大小’, async I => { await I.resizeWindow(300, 500) ..maximizeWindow( );}); - getBrowserConsoleMessages()：获取页面控制台消息 console.log(await I.getBrowserConsoleMessages())}); - wait()：暂停test(‘暂停’, async I => { await I.wait(3000);});- switchToIframe()：切换到iframe- switchToMainWindow()：返回到主窗体fixtureiframe 处理 .pagehttp://www.w3school.com.cn/tiy/t.asp?f=jseg_alert;test(‘iframe ‘, async t => { await t .click(’#button-in-main-window’) // 切换ifrme .switchToIframe(’#iframe-1’) // 返回主窗体 .switchToMainWindow();});- 下拉框选取:其实就是定位下拉框，再定位到下拉框下的选项，然后点击两次。fixture下拉框选取 .pagefile:///C:/Note/selenium_html/index.html;test.only(‘下拉框选取 ‘, async t => { const phone = Selector(’#moreSelect’); const phoneOption = phone.find(‘option’); await t .click(phone) .click(phoneOption.withText(‘oppe’));});- 三种警告框的处理setNativeDialogHandler(fn(type, text, url) [, options])：fu返回true 点击确定，返回false点击取消，返回文本则在prompt输入文本，这个执行过程中就不会看到警告框弹出，直接处理掉。fixture警告框处理 .pagehttp://www.w3school.com.cn/tiy/t.asp?f=jseg_alert`;test('处理alert ‘, async t => { await t .switchToIframe(“iframe[name=‘i’]”) // return true 表示点击确定 .setNativeDialogHandler(() => true) .click(‘input[value=“显示警告框”]’) .wait(10000);});fixture警告框处理 .pagehttp://www.w3school.com.cn/tiy/t.asp?f=jseg_prompt;test.only(‘处理 提示框 ‘, async t => { await t .switchToIframe(“iframe[name=‘i’]”) .setNativeDialogHandler((type, text, url) => { switch (type) { case ‘confirm’: switch (text) { //false 点击 取消 case ‘Press a button!’: return false; // 返回 true 点击确定 case ‘You pressed Cancel!’: return true; default: throw ‘Unexpected confirm dialog!’; } case ‘prompt’: // 警告框填入值 hi vidor return ‘Hi vidor’; case ‘alert’: throw ‘我是警告框！！’; } }) .click(‘input[value=“显示提示框”]’) .wait(10000);});上传文件setFilesToUpload()，清空上传：clearUpload()：fixtureMy fixture .pagehttp://www.example.com/;test(‘上传图片’, async t => { await t .setFilesToUpload(’#upload-input’, [ ‘./uploads/1.jpg’, ‘./uploads/2.jpg’, ‘./uploads/3.jpg’ ]) // 清除上传 .clearUpload(’#upload-input’) .click(’#upload-button’);});断言TestCafe自带了较为齐全的断言方法。断言都是通过expect()开始;import { Selector } from ’testcafe’;fixture My fixture;test(‘My test’, async t => { // 断言 通过CSS定位到的有3个元素，eql()表示相等，count表示定位元素个数 await t.expect(Selector(’.className’).count).eql(3);});test(‘My test’, async t => {// 断言ok()表示为true，exists表示元素是否存在 await t.expect(Selector(’#element’).exists).ok();});更多APIdemo查看官方文档：http://devexpress.github.io/t…特性在介绍几个TestCafe比较有意思的几个地方。执行速度testcafe 支持测试执行的速度控制。 speed(x)，x支持0.01到1之间，1则表示正常速度执行。全局速度控制可以通过控制台执行命令控制：testcafe chrome xxxx.js –speed 0.1控制某个test的执行速度test(“test setTestSpeed”, I => { I.setTestSpeed(0.1); ……});控制某个步骤的执行速度test(“test setTestSpeed”, I => { I.click("#kw").setTestSpeed(0.5);});Chrome设备模拟在启动Chrome浏览器时，可以设定Chrome提供的模拟器。testcafe “chrome:emulation:device=iphone x” xxx.js设备模拟器更多参数查看：http://devexpress.github.io/t…PageObject demo大家都知道，做UI自动化测试，肯定得使用PO或者PF模式，下面简单Demo个例子看看TestCafe 可以如何组织PO模式。baiduPage.jsimport {Selector, t as I} from ’testcafe’class baiduPage { baiduInput = Selector(’#kw’); baiduButton = Selector(’#su’).withAttribute(‘value’, ‘百度一下’); async searchBaidu(text) { await I .typeText(this.baiduInput, text, { // 清空 replace: true, }) .click(this.baiduButton) };}export default baiduPage = new baiduPage();baiduCases.jsimport baiduPage from ‘./baidu_page’fixturebaidu search.pagehttps://www.baidu.com/;test(‘po demo’, async I => { await I.typeText(baiduPage.baiduInput, “test”); baiduPage.searchBaidu(“testCafe”); await I.typeText(baiduPage.baiduInput,“居于之前的字符串空两个字符中插入”,{ caretPos:2 })});参数化/数据驱动其实就是创建一个对象，用for … of … 循环遍历fixturetodoPage test cases.pagehttp://todomvc.com/examples/react/#/;const testCases = [ { todo: ‘123’, }, { todo: ‘!@#$’, } // 等等可能性的cases，这里随便造两个作为data driver];for (const todoText of testCases) { test(‘create todo list ’ + todoText.todo, async t => { await todoPage.createTodoList(todoText.todo); await t.expect(todoPage.firstTodo.innerText).eql(todoText.todo); });}运行方式RunnerTestCafe 可以通过命令行的方式来执行测试脚本，但是感觉实际过程中肯定不是很方便，特别如果运行时需要跟一堆参数的情况下，那么TestCafe 提供了Runner，更方便配置和运行。如下配置，我需要被运行的Cases，错误自动截图，并发，生成report，智能等待，执行速度，执行的浏览器等全部配到Runner里面，这样我就不需要通过命令行运行，而且在项目中使用非常方便。const createTestCase = require(’testcafe’);const fs = require(‘fs’);let testcafe = null;createTestCase(’localhost’, 1337, 1338) .then(tc => { testcafe = tc; const runner = testcafe.createRunner(); const stream = fs.createWriteStream(‘report.json’); return runner // 需要运行的cases .src( [ ‘../demo/podemo/*.js’, ‘../demo/setWindowsSize.js’ ] ) // 设置需要执行的浏览器 .browsers([ ‘chrome’, ‘firefox’ ]) // 错误自动截图 .screenshots( // 保存路径 ‘../error/’, true, // 保存路劲格式 ‘${DATE}_${TIME}/test-${TEST_INDEX}/${USERAGENT}/${FILE_INDEX}.png’ ) // 生成report格式,根据需要安装对应report模块, // 详细看:http://devexpress.github.io/testcafe/documentation/using-testcafe/common-concepts/reporters.html .reporter(‘json’, stream) // 并发 .concurrency(3) .run({ skipJsErrors: true, // 页面js错误是否忽略,建议为true quarantineMode: true, // 隔离模式，可以理解为失败重跑 selectorTimeout: 15000, // 设置页面元素查找超时时间,智能等待 assertionTimeout: 7000, // 设置断言超时时间 pageLoadTimeout: 30000, // 设置页面加载超时时间 debugOnFail: true, // 失败开启调试模式 脚本编写建议开启 speed: 1 // 执行速度0.01 - 1 }); }).then(failedCount => { console.error(‘Failed Count:’ + failedCount); testcafe.close();}) .catch(err => { console.error(err); });结语：跟大家推荐一个学习资料分享群：903217991，里面大牛已经为我们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！人生是一个逆水行舟的过程，不进则退，咱们一起加油吧！ ...

“什么是软件测试？”这个看似简单的一个问题，其实也是最难的问题。说它简单，是因为这是一个基本的问题，做软件测试工作多年的小伙伴，自然知道什么是软件测试。说它难，是因为“软件测试”有很多内涵，要了解其全部内涵，并非那么容易。如果我们去问软件研发人员什么是软件测试，得到的答案可能五花八门，人们对软件测试有不同的理解。现在最常见的理解就是:软件测试就是找bug、发现缺陷。但也有人会认为软件测试就是：检查软件产品是否符合设计要求；验证软件产品需求、设计和实现的一致性；确认软件产品是否满足用户的实际需求；对软件产品质量的全面评估；提供软件产品质量信息；揭示软件产品的质量风险；投入较低的保障性成本极大地降低劣质成本；验证与确认；调查、分析和比较；不断探索；……有太多的理解，而且都没有错，只是看问题的角度不一样。虽然回答问题时，也容易脱口而出，不会仔细斟酌，只看到软件测试的一面，没有系统地分析“什么是软件测试”。下面我们就好好讨论“什么是软件测试”，因为有什么理解就有什么行动。有正确的理解，就有正确的操作；相反，有错误的理解，就有错误的操作。所以，先帮助读者对“软件测试”建立正确、全面的认识，构建起一个完整的“软件测试”轮廓，不至于陷入“盲人摸象”的困境，对软件测试有片面的理解。然后，我们再展开流程、方法、技术和实践的讨论。也就是在全面讨论“全程软件测试”之前，咱们需要找到共同语言，即对软件测试的一些基本概念达成共识，为后面的沟通扫除障碍。软件测试基本认知——正反思维什么是软件测试？人们常常回答：软件测试就是发现软件产品中的bug（缺陷）。也有人说，不对，软件测试是验证软件产品特性是否满足用户的需求。实际上，上述回答都没错，是对软件测试的正反两个方面的解释。早期，人们更多的是将“测试”看作是对产品的“检验”，检查软件的每个功能是否运行正常。正如1983年Bill Hetzel将软件测试定义为：“软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。”从这个定义中，至少我们可以看到以下两点。测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性。测试的活动是以人们的“设想”或“预期的结果”为依据。这里的“设想”或“预期的结果”是指需求定义、软件设计的结果。但同时我们知道，软件测试有一条原则：测试是不能穷尽的。测试会面对大量的测试数据、测试场景或代码路径等，测试也只是一个样本实验，不能证明软件是正确的，只能说明发现的缺陷的确是缺陷。但如果没有发现问题，并不能说明问题就不存在，而是至今未发现软件中所潜在的问题。正如《软件测试的艺术》一书作者Glenford J. Myers所说，测试不应该着眼于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。他认为，从心理学的角度看，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。因此，1979年他给出了软件测试的不同的定义：“测试是为了发现错误而执行一个程序或者系统的过程。”从这个定义可以看出，假定软件总是存在缺陷的（事实上也是如此）、有错误的，测试就是为了发现缺陷，而不是证明程序无错误。从这个定义延伸出去，一个成功的测试是发现了软件问题的测试，否则测试就没有价值。这就如同一个病人（因为是病人，假定确实有病），到医院去做相应的检查，结果没有发现问题，那说明这次体检是失败的，浪费了病人的时间和金钱。以逆向思维方式引导人们证明软件是“不工作的”，会促进我们不断思考开发人员对需求理解的误区、不良的习惯、程序代码的边界、无效数据的输入等，找到系统的薄弱环节或识别出系统复杂的区域，目标就是发现系统中各种各样的问题。人类的活动具有高度的目的性，建立适当的目标具有显著的心理作用。如果测试目的是为了证明程序里面没有错误，潜意识里就可能不自觉地朝这个方向去做。在进行测试的过程中，就不会刻意选择一些尽量使程序出错的测试数据，而选择一些常用的数据，测试容易通过，而不容易发现问题。如果测试的目的是要证明程序中有错，那我们会设法选择一些易于发现程序错误的测试数据，这样，更早、更快地发现缺陷。毕竟开发人员力求构造软件，以正向思维方式为主，所以逆向思维方式可以提升我们的测试效率。逆向思维也有不利的一面，容易陷于局部的深度测试，缺乏广度。因为觉得某个地方有缺陷，就对这个地方进行测试，然后不断深入下去，这样容易忽视一些区域。虽然那些地方产生的缺陷不多，但如果产生了严重缺陷，也是我们不能承受的。所以正向思维也是有价值的，它会督促针对软件系统的所有功能点，逐个验证其正确性，哪个功能越重要越要进行检验。正向思维会让我们的测试更有广度——良好的测试覆盖面。为了做好测试，既要有深度，又要有广度；既要有效率，又要有测试工作自身完整的质量。所以，我们应该将正向思维和逆向思维有机地结合起来，做到效率和质量的平衡。换句话说，当我们需要效率时，更多采用逆向思维，当我们需要测试广度来确保完整的测试质量时，则多采用正向思维。这种平衡还体现在不同的应用领域，例如国防、航天、银行等关键性软件系统，承受不了系统的任何一次失效。因为这些失效完全有可能导致灾难性的事件，所以强调验证（verify），以保证非常高的软件质量。而一般的商业应用软件或服务，质量目标设置在“用户可接受水平”，以降低软件开发成本，加快软件发布速度，有利于市场的扩张，则可以强调逆向思维，尽快找出大部分缺陷。从狭义测试到广义测试前面提到Glenford J. Myers，他早期给软件测试的简单定义是：“程序测试是为了发现错误而执行程序的过程”，也体现出当时对软件测试的认识非常具有局限性。这也是受软件开发瀑布模型的影响，认为软件测试是编程之后的一个阶段。只有等待代码开发出来之后，通过执行程序，像用户那样操作软件发现问题，这就是“动态测试”。对于需求阶段产生的缺陷，在不同阶段发现和修复的成本是不一样的。如果在需求阶段发现需求方面的缺陷并进行修复，只要修改需求文档，其成本很低。需求阶段产生的缺陷，如果在需求阶段没有发现，等待设计完成之后才被发现，就需要修改需求和设计，成本增大。需求阶段产生的缺陷，如果在需求和设计阶段都没有发现，等待代码写完之后才被发现，就需要修改需求、设计、代码，成本就更大。设计上的问题，在设计阶段被发现，只要修改设计，如果在后期发现，返工的路径就变长了，其修复的成本自然就增大。缺陷发现得越迟，其修复的成本就越高，如图1-1所示，呈现了不同阶段产生的缺陷在不同阶段修复的成本，所以这要求我们尽早发现缺陷。图1-1　不同阶段产生的缺陷在不同阶段修复的成本为了尽早发现缺陷，我们有必要将软件测试延伸到需求、设计阶段，即对软件产品的阶段性成果——需求定义文档、设计技术文档进行评审或验证。这不同于软件质量保证（Quality Assurance，QA），虽然QA侧重评审，但它重点评审流程、评审管理，包括对需求、设计、编码和测试过程规范性的评审。而这里提到的需求和设计的评审依旧是对软件产品的检验或验证，只是需求文档和设计文档只是软件产品的阶段性产品。如果按照“软件=程序+文档+数据结构”这样的定义，需求文档和设计文档等也属于软件的组成部分，软件测试自然也包括需求和设计的验证。基于上述考虑，将早期的动态测试延伸到静态测试，即从狭义的软件测试发展到广义的软件测试。狭义的软件测试：动态测试——运行程序而进行的测试，测试只是编程之后的阶段，这也是由传统的瀑布模型而决定的。广义的软件测试：动态测试+静态测试，将需求评审、设计评审、代码评审（含代码的静态分析）等也纳入软件测试工作之中。这也使“软件测试”不再停留在编程之后的某个阶段上，而成为贯穿整个软件研发周期的质量保证活动，这也是本书“全程软件测试”的最早立意所在。静态测试就是在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审等。引入静态测试，就可以尽早地发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。不管你是刚入门的小白、还没入门的群众、已经入门很久的前辈，不满足现在的工作情况，你想升值加薪，想弯道超车，都可以加我的群：903217991，咱们会提供一套专门的测试学习路线规划，带领你实现人生逆袭，财富自由。当然，咱们也有免费的资料可以提供给喜欢自学的小伙伴，所以欢迎大家踊跃加群我会一一为大家通过的。基于质量的认知软件测试虽然不能等同于软件质量保证（SQA），但它是软件质量保证的主要手段之一。当我们讨论软件测试时，绝对离不开“质量”。基于质量的认识，软件测试就是对软件产品的质量评估，提高软件产品有关的质量信息。即使从1.1节中我们认为软件测试就是发现软件产品中的bug（缺陷），哪什么是“缺陷”呢？简单地说，缺陷就是质量的对立面，一切违背质量的问题都可以看作软件缺陷（虽然从专业术语来仔细辨析的话，会将问题分为“内在错误，外部失效”等）。所以要理解软件测试，就必须理解软件质量。说起“质量”这个概念，我们都很熟悉，会说“坏的质量会怎样怎样，好的质量会怎样怎样”，但让我们给出质量的正式定义，可能不是容易的事情。我们也可以查国际标准，了解如何给质量下定义。例如IEEE Std 829-2008定义质量就是系统、组件或过程满足特定需求的程度，满足客户/用户需求或期望的程度。满足程度越高，质量就越好。例如，从软件需求定义文档来看，它所描述的需求和客户实际业务需求越吻合，将来实现的软件越有可能满足客户的业务需求，也意味着需求文档的质量越高。但这样说，还是比较宽泛，很难衡量质量。那究竟如何评估质量？从哪些维度来衡量质量呢？这就引出质量模型。基于质量模型，我们可以清楚质量有哪些属性（或维度），然后针对这些属性逐个地进行评估，不需要对软件质量进行整体评估，相当于按质量的各个维度来进行评估、各个击破。过去将软件质量分为内部质量、外部质量和使用质量，像代码的规范性、复杂度、耦合性等可以看作是内部质量，内部质量和外部质量共用一个质量模型。现在国际/国家标准将内部质量和外部质量合并为产品质量。产品质量可以认为是软件系统自身固有的内在特征和外部表现，而使用质量是从客户或用户使用的角度去感知到的质量。因为质量是相对客户而存在，没有客户就没有质量，质量是客户的满意度。过去认为，内部质量影响外部质量、外部质量影响使用质量，而使用质量依赖外部质量、外部质量依赖内部质量。今天可以理解为产品质量影响使用质量，而使用质量依赖产品质量。1．产品质量根据国际标准IEEE 24765-2010，产品质量是指在特定的使用条件下产品满足明示的和隐含的需求所明确具备能力的全部固有特性。而根据ISO 25010:2011标准，质量模型从原来的6个特性增加到8个特性，新增加了“安全性、兼容性”。如图1-2所示，蓝色标注的内容属于新增加或改动的内容。这里的安全性是指信息安全性（Security），原来放在“功能性”下面，但现在绝大部分产品都是网络产品，安全性越来越重要，所以有必要作为单独的一个维度来度量。今天系统互联互通已经很普遍，其次终端设备越来越多，除了传统的PC机，还有许多智能移动设备，如手机、平板电脑、智能手环、智能手表等，这些都要求系统具有良好的兼容性。这些特性就对应着测试类型，如功能测试、性能测试（效率）、兼容性测试、安全性测试等。图1-2　ISO 25010 2016 产品质量模型功能适应性（functional suitability）：软件所实现的功能达到其设计规范和满足用户需求的程度，强调正确性、完备性、适合性等。效率（efficiency）：在指定条件下，软件对操作所表现出的时间特性（如响应速度）以及实现某种功能有效利用计算机资源（包括内存大小、CPU占用时间等）的程度，局部资源占用高通常是性能瓶颈存在；系统可承受的并发用户数、连接数量等，需要考虑系统的可伸缩性。兼容性（compatibility），涉及共存和互操作性，共存要求软件能给与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行合适的处理。 互操作性要求系统功能之间的有效对接，涉及API和文件格式等。易用性（usability）：对于一个软件，用户学习、操作、准备输入和理解输出所做努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段（即可达性）。可靠性（reliability）：在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度／概率，如成熟性越高，可靠性就越高；用平均失效前时间（Mean Time To Failure，MTTF）或平均故障间隔时间（Mean Time Between Failures，MTBF）来衡量可靠性。安全性（security）：要求其数据传输和存储等方面能确保其安全，包括对用户身份的认证、对数据进行加密和完整性校验，所有关键性的操作都有记录（log），能够审查不同用户角色所做的操作。它涉及保密性、完整性、不可抗抵赖性、可审核性、真实性。可维护性（maintainability）：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所做努力的程度。它涉及模块化、可复用性、易分析性、易修改性、易测试性等可移植性（portability）：软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。它涉及适应性、可安装性、可替换性。2．使用质量从ISO/IEC 25010标准看，软件测试还要关注使用质量，如图1-3所示。在使用质量中，不仅包含基本的功能和非功能特性，如功能（有效与有用）、效率（性能）、安全性等，还要求用户在使用软件产品过程中获得愉悦，对产品信任，产品也不应该给用户带来经济、健康和环境等风险，并能处理好业务的上下文关系，覆盖完整的业务领域。图1-3　使用质量的属性描述为了便于理解使用质量，下面举3个例子。【例1-1】我自己亲身经历的例子。我在手机上安装了一个英语学习软件，自动下载该款软件用到的多个语音库（如新概念英语、六级英语等），它在我讲课时，但并没有判断我手机连接的是Wi-Fi还是3G/4G，造成我的流量大大超过套餐额度，产生了额外的300元流量费。从功能上看，自动下载是一个不错的功能，但有很大的经济风险，在使用质量上有明显缺陷。【例1-2】当我们玩游戏，沉醉于某款游戏，从产品本身质量属性看。是一个好产品，没有问题。但从使用质量看，会有损于玩家的健康，有健康风险，所以需要设置防沉迷功能。【例1-3】当我们使用百度地图、滴滴打车等软件时，往往是在大街上。如果站在人行道或安全地方使用没问题，但是如果一面横穿马路一面还在使用，就有安全风险。这类软件应该给予提示，否则它们要承担相应的风险责任。基于风险的认知因为没有办法证明软件是正确的，软件测试本身总是具有一定的风险性，所以软件测试被认为是对软件系统中潜在的各种风险进行评估的活动。从风险的观点看，软件测试就是对软件产品质量风险的不断评估，引导软件开发工作，进而将最终发布的软件所存在的风险降到最低。基于风险的软件测试认知主要体现在两点上：软件测试不仅仅停留在单个缺陷上，要从所发现的问题看到（分析出）某类质量风险或某个具有潜在风险的区域。软件测试被看作是一个动态的质量监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，及时评估新的风险，设置新的监控基准，不断地持续下去。基于风险对测试的认知，会强调测试的持续性，持续地进行测试，写几行代码就要做测试、实现一个功能就要对这个功能进行测试，开发和测试相伴而行。这种认知特别适合敏捷开发模式下的测试——敏捷测试。在敏捷开发中，软件测试就能被解释为对软件产品质量的持续评估。在敏捷方法中，不仅提倡持续集成，而且提倡持续测试，持续集成实际上也是为了持续测试。基于风险对测试的认知还不断提醒我们：在尽力做好测试工作的前提下，工作有所侧重，在风险和开发周期限制上获得平衡。首先评估测试的风险，每个功能出问题的概率有多大？根据Pareto原则（也叫80/20原则），哪些功能是用户最常用的20％功能？如果某个功能有问题，其对用户的影响又有多大？然后根据风险大小确定测试的优先级。优先级高的功能特性，测试优先得到执行。一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全地、充分地执行，而低优先级功能的测试（另外用户不常用的80％功能）就可能由于时间或经费的限制，测试的要求降低、减少测试工作量。基于社会的认知软件不同于硬件，软件一般都是应用系统，常常和人们的娱乐、事务处理、商业活动、社区交流等紧密联系在一起，所以软件具有很强的社会性，所以有必要把心理学、人类学和社会学等引入到软件测试中。软件测试不仅仅是技术活动，而且是社会、心理等综合性活动，软件测试是跨学科的（inter-disciplinary）活动，以系统为焦点（systems-focused），通过不断调查（investigative）和讲故事（storytelling）的方式完成软件质量的评估。通过软件测试的社会性认知，强调测试人员的思维能力和探索能力，强调测试的有效性和可靠性，在测试中要理解用户的行为、人们活动的背景和目的（上下文关系），不断观察，不断学习，发现和质量相关的信息（差异或质疑），从客户利益、业务特性出发来守护产品的价值。也正是由于软件测试的社会性，需要对软件产品的易用性、免于风险的程度、上下文覆盖等进行验证。在易用性测试中，人们常常进行A/B测试，给出不同的解决方案（UI布局、功能设计等），向不同的用户群发布产品，来检测哪个解决方案更受用户喜欢。基于经济的认知一般来说，一个软件产品没有经过测试是不会发布（release）、不会部署(deploy)到产品线上，或者说，不敢发布、不敢上线。因为在当前的开发模式和开发技术情况下，人们开发的软件存在严重的缺陷绝对是大概率事件。如果没有经过测试，就发布出去，可能软件根本不能用、不好用，或者用起来出现各种各样的问题，用户满意度很低，给产品造成负面影响，甚至给客户带来严重的经济损失或影响到用户的生命安全。从经济观点看，软件缺陷会给企业带来成本，这个成本就叫劣质成本（Cost of Poor Quality，COPQ）。基于经济的认知，软件测试就是通过投入较低的保障性成本来降低劣质成本，帮助企业获得利润。高质量不仅是有竞争力，而且是带来良好的经济收益的。例如苹果手机就是以其高质量获得比其他品牌手机更高的利润率。据相关媒体统计数据看，苹果智能手机在高端手机市场只占四分之一，但利润占到一半。测试的经济观点就是如何以最小的代价获得更高的收益，这也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。所以，从经济观点出发，测试不能在软件代码写完之后才开始，而是从项目启动的第一天起，测试人员就参与进去，尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。基于标准的认知软件测试被视为“验证（Verification）”和“有效性确认（Validation）”这两类活动构成的整体，缺一不可。如果只做到其中一项，测试是不完整的。“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求相一致，即验证软件实现（即交付给客户的产品）是否达到了软件需求定义和设计目标。“有效性确认”是确认所开发的软件是否满足用户实际需求的活动。因为软件需求定义和设计可能就不对，上述一致性不能保证软件产品符合客户的实际需求，而且客户的需求也是在变化的，当需求定义是半年前确定的，这种变化的可能性就比较大。对验证和确认有不同的解释。简单地说，单元测试、集成测试和系统测试都可以理解为“验证”，都是基于需求定义文档和设计规格说明书文档来进行验证；而验收测试则在用户现场、由用户共同参与进行，可以理解为“有效性确认”，因为之前的需求定义和设计都可能存在错误，研发团队没有正确理解用户的原意（用户的真实期望），仅仅根据需求定义文档和设计规格说明书文档来完成测试，并不能代表所实现的功能特性是用户真正想要的。而在验收测试中，用户参与进来，是可以确认所实现的功能特性是否是用户真正想要的。另一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。图1-4　软件研发的V模型另一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。结语不管你是刚入门的小白、还没入门的群众、已经入门很久的前辈，不满足现在的工作情况，你想升值加薪，想弯道超车，都可以加我的群：903217991，咱们会提供一套专门的测试学习路线规划，带领你实现人生逆袭，财富自由。当然，咱们也有免费的资料可以提供给喜欢自学的小伙伴，所以欢迎大家踊跃加群我会一一为大家通过的。

作者：段聪，腾讯社交平台部高级工程师商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/421.htmlWeTest 导读近期测试反馈一个问题，在旧版本微视基础上覆盖安装新版本的微视APP，首次打开拍摄页录制视频合成时高概率出现crash。那么我们直奔主题，看看日志：另外复现的日志中还出现如下信息：’/data/data/com.tencent.weishi/appresArchiveExtra/res1bodydetect/bodydetect/libxnet.so: strtab out of bounds error后经过测试，发现覆盖安装后首次使用美体功能也会出现crash，日志如下：由于出现问题的场景都是覆盖安装首次使用，并且涉及到人体检测相关的so，似乎存在某种共同的原因。因此Abort异常比起fault addr类问题更容易分析，先从前面Linker出现Abort异常的位置开始着手。Linker是so链接和加载的关键，属于系统可执行文件，因此分析起来比较棘手。好在手上正好有一台刚刷完自己编译的Android AOSP的Pixel，做一些实验变得更轻松了。出现异常的Linker代码linker_soinfo.cpp如下：const char* soinfo::get_string(ElfW(Word) index) const { if (has_min_version(1) && (index >= strtab_size)) { async_safe_fatal("%s: strtab out of bounds error; STRSZ=%zd, name=%d", get_realpath(), strtab_size_, index); } return strtab_ + index;}bool soinfo::elf_lookup(SymbolName& symbol_name, const version_info* vi, uint32_t* symbol_index) const { uint32_t hash = symbol_name.elf_hash(); TRACE_TYPE(LOOKUP, “SEARCH %s in %s@%p h=%x(elf) %zd”, symbol_name.get_name(), get_realpath(), reinterpret_cast<void*>(base), hash, hash % nbucket_); ElfW(Versym) verneed = 0; if (!find_verdef_version_index(this, vi, &verneed)) { return false; } for (uint32_t n = bucket_[hash % nbucket_]; n != 0; n = chain_[n]) { ElfW(Sym)* s = symtab_ + n; const ElfW(Versym)* verdef = get_versym(n); // skip hidden versions when verneed == 0 if (verneed == kVersymNotNeeded && is_versym_hidden(verdef)) { continue; } if (check_symbol_version(verneed, verdef) && strcmp(get_string(s->st_name), symbol_name.get_name()) == 0 && is_symbol_global_and_defined(this, s)) { TRACE_TYPE(LOOKUP, “FOUND %s in %s (%p) %zd”, symbol_name.get_name(), get_realpath(), reinterpret_cast<void*>(s->st_value), static_cast<size_t>(s->st_size)); symbol_index = n; return true; } } TRACE_TYPE(LOOKUP, “NOT FOUND %s in %s@%p %x %zd”, symbol_name.get_name(), get_realpath(), reinterpret_cast<void>(base), hash, hash % nbucket_); symbol_index = 0; return true;}从代码上看，是在so的symtab中查找某个符号时ElfW(Sym) s的地址出现异常，导致s->st_name获取到错误的数据。通过复现问题，可以抓到更完整的 /data/tombstone日志，得到如下完整的信息：尽管从tombstone中我们可以看到一些寄存器数据及寄存处地址附近内存数据，同时也可以看到crash时的虚拟内存映射表，仍然无法获取有价值的信息。另外通过几次复现，发现并不是每次Crash都是SIGABRT，也出现不少SIGSEGV信号，而调用栈和之前都是一样的，比如这个：这基本上可以说明，并不是so本身的代码存在异常，只可能是加载的so出现了文件异常。另外通过在linker中增加日志，并重新编译linker替换到/system/lib/linker中：可以获取到如下的地址信息：通过根据tombstone中的/proc/<poc>/maps的虚拟内存地址与日志打印的地址进行对比，可以发现最为符号表地址的s并没有指向so文件在虚拟内存中的地址段，因此可以怀疑，so加载确实出现了异常。因为手机root，可以直接获取到crash时的so文件(adb pull /data/data/com.tencent.weishi/appresArchiveExtra/res1bodydetect/bodydetect/libxnet.so)，导出来对比md5，然而发现与正常情况下的so是一模一样的：既然前面的这些实验都没有得出什么有意义的结论，那么我回过头来分析一下，与问题关联的so加载到底有什么特殊性。实际上，微视为了减包，将一部分so文件进行下发，由于so也处于不断迭代的过程中，新版本的微视可能会在后台更新so文件，那么客户端一旦发现新的版本有新的so，就会去下载so并进行本地替换。那么这个过程有什么问题呢？唯一可能的问题，就是先加载了旧的so，之后下载新的so进行了热更新。我们先看下微视中是否有这种现象。要观察这种现象，我们可以打开linker自身的调试开关，开启so加载的日志。通过设置系统属性，我们可以很容易地进行开启LD_LOG日志：adb shell setprop debug.ld.all dlerror,dlopen当然我们也可以只针对某个应用开启这个日志（设置系统属性debug.ld.app.）。另外，为了开启linker中更多的日志，比如DEBUG打印的信息等，我们只需要在adb shell中设置环境变量：export LD_DEBUG=10那么，我们重新复现问题，可以看到如下so加载过程：这个过程表明：旧的so先被加载了，然后下载了新版本的so，并进行了替换。这个过程有什么问题呢？根据《理解inode》一文我们可以得知，linux的文件系统使用的inode机制支持了so文件的热更新（动态更新），即每个文件都有一个唯一的inode号，打开文件后使用inode号区分文件而不是文件名：八、inode的特殊作用由于inode号码与文件名分离，这种机制导致了一些Unix/Linux系统特有的现象。1. 有时，文件名包含特殊字符，无法正常删除。这时，直接删除inode节点，就能起到删除文件的作用。2. 移动文件或重命名文件，只是改变文件名，不影响inode号码。3. 打开一个文件以后，系统就以inode号码来识别这个文件，不再考虑文件名。因此，通常来说，系统无法从inode号码得知文件名。第3点使得软件更新变得简单，可以在不关闭软件的情况下进行更新，不需要重启。因为系统通过inode号码，识别运行中的文件，不通过文件名。更新的时候，新版文件以同样的文件名，生成一个新的inode，不会影响到运行中的文件。等到下一次运行这个软件的时候，文件名就自动指向新版文件，旧版文件的inode则被回收。但是问题就出在这里，如果替换文件使用的是cp这样的操作，会导致原来的so文件截断，然后重新写入数据，但是inode并没有更新号，磁盘与内存中的信息出现不一致，这种情况在linux中很常见，比如这篇文章就进行了分析：cp new.so old.so，文件的inode号没有改变，dentry找到是新的so，但是cp过程中会把老的so截断为0，这时程序再次进行加载的时候，如果需要的文件偏移大于新的so的地址范围会生成buserror导致程序core掉，或者由于全局符号表没有更新，动态库依赖的外部函数无法解析，会产生sigsegv从而导致程序core掉，当然也有一定的可能性程序继续执行，但是十分危险。2. mv new.so old.so，文件的inode号会发生改变，但老的so的inode号依旧存在，这时程序必须停止重启服务才能继续使用新的so，否则程序继续执行，使用的还是老的so，所以程序不会core掉，就像我们在第二部分删除掉log文件，而依然能用lsof命令看到一样。还有更深入的解释：Linux由于DemandPaging机制的关系，必须确保正在运行中的程序镜像（注意，并非文件本身）不被意外修改，因此内核在启动程序后会绑定 内存页到这个so的inode，而一旦此inode文件被open函数O_TRUNC掉，则kernel会把so文件对应在虚存的页清空，这样当运行到so里面的代码时，因为物理内存中不再有实际的数据（仅存在于虚存空间内），会产生一次缺页中断。Kernel从so文件中copy一份到内存中去,a)但是这时的全局符号表并没有经过解析，当调用到时就产生segmentfault , b)如果需要的文件偏移大于新的so的地址范围，就会产生bus error。那么问题基本清晰了。我们在回去看看微视的代码，这里下载了so之后直接unzip到原来的路径，并没有先进行rm操作。更近一步，我们自己写个demo测试下刚才的问题（2个按钮，一个加载指定so，一个调用so中的native方法）：代码不能再简单了：正常加载so然后执行native方法都是ok的，使用rm+mv替换或者adb push替换也都是ok的，最后再按照错误的方法操作，步骤为：启动app，点击加载so；通过cp命令替换so；点击执行native方法；结果确实是crash了：日志如下，是不是很最开始的日志信息一样呢：到此，我们有两种解决办法：如果so有升级，先不加载旧的so，等新的so下载完成之后再加载；可以先加载旧的so，但是下载了新的so之后，要删除旧的so，再进行替换。引文参考：https://www.cnblogs.com/cnlan…https://www.cnblogs.com/cnlan...http://www.nginx.cn/1329.htmlhttp://www.ruanyifeng.com/blo...https://www.bo56.com/linux%E4…_**目前，“自动化兼容测试” 提供云端自动化兼容服务，提交云端百台真机，并行测试。快速发现游戏/应用兼容性和性能问题，覆盖安卓主流机型。点击：https://wetest.qq.com/product/auto-compatibility-testing 即可体验。**如果使用当中有任何疑问，欢迎联系腾讯WeTest企业QQ：2852350015 ...

本文首发于泊浮目的专栏：https://segmentfault.com/blog…背景在笔者目前的项目中，大部分业务跑在基于kvm的vm上。鉴于对项目质量的追求及尽可能节省人力资源的目的，着手调研高测试覆盖率的解决方案。由于项目基于ZStack，所以架构与其较为相似，但在vm上添加了相应的agent，通过其来控制vm中的操作系统与软件。众所周知，ZStack管理节点部分有一套较为完善的自动化测试框架，可以满足大多数场景。而Utility并非如此，只能通过黑盒测试来保证其质量，且许多测试场景需要start up一个真实的ZStack的环境，测试成本较高。如果一部分测试可以设计在agent端，也就说是agent端的测试可以自举。这样就可以少设计一部分黑盒测试实例，降低潜在成本。从业务看测试从vm agent的业务逻辑来看，大多数业务都是修改DB配置、读DB配置，start, stop DB等。而为了case之间不受到影响，我们在跑完测试之后，需要重置当前的测试环境。方案选择Docker放弃。其无状态的特性简直完美契合上述需求。但是docker里只能跑单进程，对于oracle相关的业务，可能无法满足。且部分版本oracle对Docker的镜像支持上可能有问题。在docker中可以通过一些hack的手段去做到在一个容器中起多进程，比如systemd或supervisord。但是笔者对docker并不是非常的了解，所以没有继续研究下去。Pouch放弃。阿里自研的富容器技术，可以完美解决docker里单进程的问题——其实本质上也是在容器镜像起来时运行了一个init进程指定为1号进程，而不是像docker里在命令行中指定的进程。在实践过程中发现有各种莫名其妙的报错，且相关文档不齐全。VM By ZStack目前的方案。通过ZStack来管理环境vm的生命周期，通过快照机制来还原环境。缺点也非常的明显，仅仅一个case生命周期就需要1min+，生命周期大致如下：使用vm跑测试停止vm恢复快照启动vm让人感到舒服的是，ZStack提供了一套Java SDK，可以直接通过SDK完成上述操作。基于ZStack的自动化测试对接ZStack根本没有什么困难之处。更多的是要从成本这个点去考虑整个测试系统的设计。这里的成本则又可以分为两种成本：物理资源成本：产品线上目前能够投入进测试的host较少，故在资源稀缺的情况下，得尽量用较少的vm去完成这件事。时间成本：一个开发人员跑测试的时间越短越好，而不是花大量时间去等待测试环境准备、清理等。举个列子，如果我搭建一个mysql 主备库，需要两台vm，如果串行去完成生命周期相关的操作，那么就是2min+；如果并行的去做，便是1min+。同理，如果这些测试能够尽量并行的去跑，则可以省下更多的时间。角色角色示意图如下：TestCase一个测试实例，含有测试代码。同时它会向ResourcePool申请所需的vm。TestGroup根据当前的策略组织TestCase去并行的跑这些Case。在这里可以控制并发粒度，最后将会提交给Junit的跑测试。JUnitCore.runClasses(new ParallelComputer(true, true) , testGroup.toArray(arrayTestGroup));ResourcePool资源池的概念其实有点像云。比如组内有4个开发，那么4个开发几乎是不可能同时跑测试的，同时有2个开发在跑测试也是小概率事件。与其每个人都申请几台测试vm放在那边（一天可能就跑1、2小时的测试），还不如大家都共享一个池内的vm，避免资源的浪费。就像公有云卖你1core512m，你去架个网站，但是它料到你用不了这么多，所以它就会超分超卖。这个类会根据配置文件或者网络请求存入相应测试用的vm，并记录这些vm是否被使用，为了防止其他开发者一起跑测试的时候共用同一台vm，会给使用中的vm打上一个user tag，避免冲撞。另外，SessionId等常量也是从这里刷新而来。小结通过本文，向大家介绍了一下笔者目前在项目中设计的一个基于ZStack的自动化测试系统。基于各方各面的成本限制，故此设计的较为简单。如果后续有些较大的改动或显著的改进，笔者还会与大家继续分享。如果大家对于这方面的自动化测试有较好的实践或者建议，也欢迎在留言中一起交流学习。**

概要应同学邀请，演示如何使用 PyQt5 内嵌浏览器浏览网页，并注入 Javascript 脚本实现自动化操作。sg 原贴地址： 如何在Python利用runJavaScript模拟鼠标移动页面的某个元素https://segmentfault.com/q/10…下面测试的是一个廉价机票预订网站（http://www.flyscoot.com/），关键点如下使用 QWebEngineView 加载网页，并显示进度。在默认配置（QWebEngineProfile）中植入 Javascript 内容，这样脚本会在所有打开的网页中执行，不论跳转到哪个网址。Javascript 脚本使用网址中的路径名，判断当前网页位置，从而决定执行哪种操作。python 代码示例#!/usr/bin/env python3# -- coding: utf-8 --‘‘‘使用 PyQt5 内嵌浏览器浏览网页，并注入 Javascript 脚本实现自动化操作。‘‘‘import osimport sysfrom datetime import datetimefrom PyQt5.QtWidgets import ( QWidget, QApplication, QVBoxLayout, QHBoxLayout, QDesktopWidget, QTextEdit, QLabel, QLineEdit, QPushButton, QFileDialog, QProgressBar,)from PyQt5.QtCore import QUrl, pyqtSlotfrom PyQt5.QtWebEngineWidgets import QWebEngineView, QWebEngineProfile, QWebEngineScript, QWebEnginePageclass Browser(QWidget): def init(self): super().init() self.init_ui() # 脚本 self.profile = QWebEngineProfile.defaultProfile() self.script = QWebEngineScript() self.prepare_script() def init_ui(self): self.webView = QWebEngineView() self.logEdit = QTextEdit() self.logEdit.setFixedHeight(100) self.addrEdit = QLineEdit() self.addrEdit.returnPressed.connect(self.load_url) self.webView.urlChanged.connect( lambda i: self.addrEdit.setText(i.toDisplayString())) self.jsEdit = QLineEdit() self.jsEdit.setText(‘inject.js’) loadUrlBtn = QPushButton(‘加载’) loadUrlBtn.clicked.connect(self.load_url) chooseJsBtn = QPushButton(‘选择脚本文件’) chooseJsBtn.clicked.connect(self.choose_js_file) # 导航/工具 top = QWidget() top.setFixedHeight(80) topBox = QVBoxLayout(top) topBox.setSpacing(0) topBox.setContentsMargins(5, 0, 0, 5) progBar = QProgressBar() progBox = QHBoxLayout() progBox.addWidget(progBar) topBox.addLayout(progBox) naviBox = QHBoxLayout() naviBox.addWidget(QLabel(‘网址’)) naviBox.addWidget(self.addrEdit) naviBox.addWidget(loadUrlBtn) topBox.addLayout(naviBox) naviBox = QHBoxLayout() naviBox.addWidget(QLabel(‘注入脚本文件’)) naviBox.addWidget(self.jsEdit) naviBox.addWidget(chooseJsBtn) topBox.addLayout(naviBox) self.webView.loadProgress.connect(progBar.setValue) # 主界面 layout = QVBoxLayout(self) layout.addWidget(self.webView) layout.addWidget(top) layout.addWidget(self.logEdit) self.show() self.resize(1024, 900) self.center() def center(self): qr = self.frameGeometry() cp = QDesktopWidget().availableGeometry().center() qr.moveCenter(cp) self.move(qr.topLeft()) @pyqtSlot() def load_url(self): url = self.addrEdit.text().strip() if not url.lower().startswith(‘http://’) and not url.lower().startswith(‘https://’): url = ‘http://{}’.format(url) self.load(url) @pyqtSlot() def choose_js_file(self): f, _ = QFileDialog.getOpenFileName(filter=“Javascript files(*.js)”) if os.path.isfile(f): self.jsEdit.setText(f) self.prepare_script() def prepare_script(self): path = self.jsEdit.text().strip() if not os.path.isfile(path): self.log(‘invalid js path’) return self.profile.scripts().remove(self.script) with open(path, ‘r’) as f: self.script.setSourceCode(f.read()) self.profile.scripts().insert(self.script) self.log(‘injected js ready’) def log(self, msg, *args, **kwargs): m = msg.format(*args, **kwargs) self.logEdit.append(’{} {}’.format( datetime.now().strftime(’%H:%M:%S’), m)) def load(self, url): self.log(f’loading {url}’) self.addrEdit.setText(url) self.webView.load(QUrl(url))if name == ‘main’: app = QApplication(sys.argv) b = Browser() b.load(‘http://www.flyscoot.com/') sys.exit(app.exec_())Javascript 脚本示例// 简单起见，这里只演示部分页面，脚本内容摘自 Heng丶原贴文。function handle(path) { // 首页 if (path == ‘/zh’) { document.getElementsByClassName(‘radio-inline’)[1].click(); document.getElementById(‘oneway_from’).value=‘广州 (CAN)’; document.getElementById(‘oneway_to’).value=‘新加坡 (SIN)’; document.getElementById(‘oneway_departuredate’).value=‘2018年9月10日’; document.getElementsByClassName(‘btn–booking’)[1].click(); return; } // 选择航班 if (path == ‘/Book/Flight’) { document.getElementsByClassName(‘price–sale’)[0].click(); document.getElementsByClassName(‘heading-4’)[0].click(); document.getElementsByClassName(‘btn-submit’)[0].click(); return; } // 乘客信息 if (path == ‘/BookFlight/Passengers’) { document.getElementsByClassName(‘fname1’)[0].value = “匿名”; }}let host = document.location.hostname;if (host.endsWith(’.flyscoot.com’)) { handle(document.location.pathname);} ...