分享测试知识

1、自动化测试框架选型其实关于测试框架选型，要考量的无非是如下几点：个人技术基础如何，框架的学习难易曲线；框架功能是否丰富，官方文档是否详细，框架生态是否成熟；框架本身的扩展性如何，是否支持多语言，开源还是商业的；如果个人技术基础比较薄弱，建议选择功能丰富开箱即用，且学习曲线比较平滑的。有些框架入门简单，但是进阶和落地难度就会特别高；有些框架入门难度稍微高点，但整体的学习难易曲线比较平滑，适合不断打怪升级，这点需要看个人适配程度和喜好。

1、为什么要做接口测试测试理念的演变：早些时候，软件研发交付流程大多遵循V型或W型的瀑布模式，这种模式下只有开发编码完成才会提测进入测试验证阶段。这个阶段测试同学做的大多是基于业务流程和页面的功能测试工作，也就是我们自嘲的“点工”。近几年随着业务迭代速度加快，以及测试行业的不断发展，像测试左移、敏捷测试等理念开始被更多的人认可。从软件工程的角度来说，越早介入发现问题和风险，修复的成本越低，最终交付的质量也越高。技术要求的提升：国内大部分测试同学在技术上来说相比于开发，是要弱上不少的。

1、什么项目适合做自动化测试？答：一般来说，适合做自动化测试的项目应该满足以下几个条件：项目需求稳定，变更不频繁。项目周期较长，需要反复进行回归测试。项目功能较复杂，涉及多个模块和接口。项目质量要求较高，需要保证高覆盖率和高可靠性。2、你参与过哪些类型的自动化测试项目？答：我参与过以下几种类型的自动化测试项目：Web UI自动化测试：使用Selenium WebDriver和Python编写测试脚本，对网页上的元素进行定位、操作和断言，验证网页的布局、功能和兼容性。

1、接口分类及分析方法，测试重点1）功能分类功能间接口：系统中功能模块间的接口，比如：ERP系统中采购模块和库存模块之间的接口特点：一般部署在同一个服务器中，并且使用同一个数据库测试方法：通常采用黑盒测试方法，注意接口数据在不同模块间的走向；尤其是接口间的逻辑控制关系例如：销售发货，检查库存可用量，如可用量不足，则不允许发货系统间接口：不同系统间的接口，比如：银行的各个系统间的接口。核心系统和各个外围系统之间都是此类接口。

1、接口自动化测试项目框架搭建接口自动化测试框架的技术栈如下：1）语言：Python，简洁高效，上手容易，无压力；人生苦短，我用 python；2）测试框架：Unittest、Pytest，封装自定义断言方法进行验证，如：eq\lt\lte\gt\gte\neq\str_eq等等；3）接口调用：Requests库，提供不同的HTTP请求方法，支持session和cookies，支持失败请求重发等；4）数据驱动：数据驱动测试（DDT），以用例数据来生成测试用例；

测试面试之测试工具考点介绍一下测试中常用的工具（必备基础，必须掌握！需求问题跟进、测试计划、风险评估登记、测试报告、复盘会议：wiki测试用例：Xmind 编写，Testlink 管理测试执行：ELK、Xshell等Bug 管理：Jira、bugfree、禅道等接口测试相关：Charles、Fiddler、Postman、JMeter等自动化相关：Selenium、Appium、pytest、Locust、JMeter等用什么工具对用例进行管理？

学习自动化测试有那么重要吗？很多小伙伴都有诸如此类的疑问，例如：“日常工作中好像用不上自动化？”、“手工点点点好像也可以”、“为什么还要学自动化呢？等等 ……自动化测试框架：接口自动化测试方向：Python+requests+pytest+yaml+alluer+Jenkins；web自动化测试方向：Python+selenium4+pytest+POM+allure+Jenkins；app自动化测试方向：Python+appium+POM+pytest+allure+Jenkins；

1、为什么要学习自动化测试先聊一下测试人员的职业发展路线，无非就是两条，技术路线和管理路线，技术路线一般就是功能测试（60%）–> 自动化测试（25%）–> 测试开发（5%）–> 测试架构师 / 业务专家 / 测试专家（5%），管理路线一般就是测试工程师（60%）–> 测试组长（25%）–> 测试经理（10%）–> 测试总监（5%）。如果你已经从事测试工作两三年时间了，或者开发转测试，又或者上来就要包装三年及以上工作经验，那么掌握自动化测试技能必不可少。

普通程序员 35 岁之后的出路在哪里？互联网大厂裁员浪潮，35 岁左右互联网人该何去何从？大龄程序员转行做什么呢……成为 35 + 危机人群占比最大的行业，很大原因是由于 IT 行业各种技术层出不穷，更新迭代快，互联网代表着创新、活力和潮流，很明显是属于年轻人的行业。在我看来，中年危机的出现根本原因并不是因为你年龄大了，体力和脑力跟不上年轻人，而是你的能力没有追上你的工作年限，也就是说你只是一年经验重复使用了 N 年，感慨工作之后没有时间学习。

1、浅谈自动化1）自动化测试的价值传统的商业模式以业务驱动产品，而现在则以技术驱动产品。特别是在敏捷模式下，产品迭代速度快，市场不断调整，客户需求不断变化。单纯的手工测试越来越无法适应整个变化的过程。QA人员如何快速响应并保证产品在上线后质量能够满足市场要求（简单说，如何在上线一个新功能的同时快速对老功能进行回归测试，保证老功能不被新功能影响而出现严重的Bug），如何通过技术手段提高测试效率？显然，对于这些问题，采用自动化测试无疑是一个不错的选择。能够做到在保证产品质量的同时提升测试效率。

随着自动化用例的不断增加，需要维护的测试数据也会越来越多，维护成本越来越高，如何有效管理测试数据也是自动化测试实践中一个值得探讨的问题。并且随着技术的发展和工具的不断革新，方法论和实践经验的积累，自动化测试中测试数据的管理方式也在不断迭代和演进。1、脚本与数据捆绑在学习自动化测试初期，基本上使用的都是线性脚本，也就是将测试数据与测试脚本捆绑在一起。这也是每个初学者都会经历的阶段，这样做的好处就是可以快速实现一个demo，更好地帮助初学者从手工测试进阶到自动化测试。

1、接口信息来源与界面功能测试相比，除了要明确需求和测试目标之外，接口测试还需要有针对性地去设计测试数据和接口的组合，确定接口信息通常有两条路径，一是通过接口文档获取，二是通过接口抓包获取。2、接口文档开发人员一般不喜欢写接口文档，同时也讨厌别人不写接口文档，就像程序员一般不喜欢写注释，同时也讨厌不写注释的代码，所以测试人员想要获取一份相对完善的接口文档有时是比较麻烦的，这就需要驱动开发人员提供，这对于开发人员来说并不困难。统一的接口文档管理方式也是比较多的。

学习自动化测试有那么重要吗？相信不少同学都有诸如此类的疑问，例如：“日常工作中好像用不上自动化？”、“手工点点点好像也可以”、“为什么还要学自动化呢？”等等 ……接口自动化测试方向：Python+requests+pytest+yaml+alluer+Jenkins；web自动化测试方向：Python+selenium4+pytest+POM+allure+Jenkins；app自动化测试方向：Python+appium+POM+pytest+allure+Jenkins；1、何为自动化测试。

1、你们自动化怎么做的在需求分析阶段，跟前端沟通好，规范前端代码，避免造成后期自动化工作无法开展的问题。在用例设计阶段，挑选出适合做自动化的用例，单独整理到一个文件保存。在项目中后期，趋于稳定之后，就可以开始设计自动化脚本了。语言python+自动化测试工具selenium+单元测试框架unittest（这里可以挑自己熟悉的说，比如pytest等）+分层模型PO+测试报告HTMLTestRunner/Allure2、selenium是什么，测试所需要包括的工具。

1、介绍一下测试流程（重点，常见！需求评审、测试计划、测试用例、用例评审、冒烟测试、测试执行、验收测试、风险评估、上线观察、问题跟进、测试报告、复盘会议；根据自己的日常经验来回答，每个点的工作内容都需要清晰掌握，有可能就某个点如何工作进行提问。2、介绍一下测试方法按阶段：单元测试、集成测试、系统测试、验收测试按手段：黑盒测试、白盒测试、灰盒测试其他：冒烟测试、回归测试3、介绍一下测试用例设计方法（用例设计方法&测试方法需分清楚）

1、请问你是如何做接口测试的？大体来说，经历以下过程：接口需求调研、接口测试工具选择、接口测试用例编写、接口测试执行、接口测试回归、接口测试自动化持续集成。具体来说，接口测试流程分成以下九步：第一步：分析出测试需求，并请开发提供接口说明文档；第二步：从接口说明文档中整理出接口测试用例，里面要包括详细的入参（正常情况，异常情况包括输入参数个数，类型，可选/必选，考虑参数有互斥或关联的情况）和出参数据（符合接口文档需求）以及明确的格式和检查点；第三步：与开发一起对接口测试用例进行评审；

岗位：【技术能力】能独立完成产品线中自动化测试工作，根据测试任务，搭建软件测试环境，编写测试脚本，输出报告；【项目管理】熟练开发测试工具、测试脚本，及迭代优化测试框架，使用合理方式进行自动化管理项目；【业务推动】对测试项目的结果负责，使用合理方式推动业务端测试的效率、开发质量；【规范制定】 熟悉CI系统，完善准入/准出标准，持续提升测试效率；【效率提升】根据业务特点，引入新的测试方法和工具，探索新技术。改进测试工具或测试方法，提高效率，培训测试人员并支持技术难题解决。

自动化测试一直是测试人员的核心技能，也是测试的重要手段之一。尤其是在今年所谓的互联网寒冬的行情下，各大企业对测试人员的技术水平要求的很高。而测试人员的技术水平主要集中在三大自动化测试领域，再加测试辅助脚本的编写，测试工具的开发，测试平台的开发等。而普通的测试人员想快速提升技术，自动化测试必是无可挑剔的选择。但是由于业界一直存在着对自动化测试的误解，严重影响了自动化测试的发展，也影响了不少同学学习自动化测试的信心。

1、什么样的项目适合引入UI自动化测试？UI自动化的业务场景覆盖和用例条数覆盖情况，UI自动化用例条数情况1）什么样的项目适合引入UI自动化测试① 迭代版本周期比较长② 需求变更不频繁③ 页面控件稳定④ 项目周期长2）UI自动化的业务场景覆盖和用例条数覆盖情况面试官：你们之前做UI自动化，是只考虑正常场景吗？还是正常和异常场景都会考虑？==》我们之前做UI自动化只写正常场景的用例业务场景覆盖情况：A、可以覆盖到的场景占50-70%

1、你做过ui自动化吗？用什么做的？做过，用的是python+selenium+unittest单元测试框架来做的，那我大概和您讲一下我做ui自动化的流程吧答：首先的话就是我需要打开pycharm然后新建一个py模块，然后导入selenium模块，time模块等等，然后通过from selenium import webdriver语句导入webdriver模块。

1、mock技术的简介1）怎么实现mock（技术很多，大的概念，各种语言都可以实现）只要能把后台逻辑模拟出来的系统就是mock技术python，java 写后端；python+flask/django编程　　写一个简易的系统（请求响应后台服务，不需要前端）需要编码能力；现成的mock平台　　moco框架（java包）　　所有的配置使用json文件（一般采用第三种，不需要代码编程技术，只要改json配置文件2）模拟技术不同的命名mock技术挡板技术 —很大的概念，挡板是mock里面的一种。

1、yaml（专门用来做配置文件的）1）yaml格式简介（yaml文件非常简洁）yaml的意思是：yet anoter markup language（仍是一种置标语言）的缩写yaml是专门用来写配置文件的语言，非常简洁强大，远比json格式方便可以用yaml做自动化测试框架的配置文件或者用例文件yaml作配置文件config file　　比如说运行版本参数或者设置on和off都可以使用yaml来做2）python搭建yaml环境。

1、自动化测试用例设计：代码好处理，接口来说需要url、body、预期结果、请求方式、路径、接口名称、用例名称、模块、用例id、请求参数类型、请求参数）代码构建请求可能用到的，自动化测试用例要让代码容易解读。为什么需要用例名称：如果一个模块有很多接口，比如新增，列出，删除课程，一般按照顺序来测试如果不按照顺序（有名称可以自动识别用例模块，那个接口的，接口用例写的时候打乱，有用例名称可以自己识别组装成列表）—一般接口用例按照模块顺序写，方便。

1、API测试怎么做？如何应对复杂场景的 API 测试？测试场景一：被测业务操作是由多个 API 调用协作完成背景：一个单一的前端操作可能会触发后端一系列的 API 调用，此时 API 的测试用例就不再是简单的单个 API 调用，而是一系列 API 的调用。存在情况：1）存在后一个 API 需要使用前一个 API 返回结果的情况。2）需要根据前一个 API 的返回结果决定后面应该调用哪个 API。

1、什么项目适合做自动化测试？1）需求稳定，不会频繁变更2）研发和维护周期长，需要频繁执行回归测试3）需要在多种平台上重复运行相同测试的场景4）某些测试项目通过手工测试无法实现，或者手工成本太高5）被测软件的开发较为规范，能够保证系统的可测试性6）测试人员已经具备一定的编程能力所以，要综合实际情况来看待“自动化测试”。它的确可以从一定程度上解放测试人员的劳动力，完成一些人工无法实现的测试，但并不适用于所有的测试场景。如果，维护自动化测试的代价高过了节省的测试成本，往往会得不偿失。

1、自动化测试-实施方案1）项目讨论1.1 项目中符合自动化测试的部分有哪些？(目标和范围 scope， 准入准出标准)稳定的需求点、变动较少的页面每日构建后的测试验证 daily build比较频繁的回归测试需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务1.2 自动化用例在整个项目的测试用例的覆盖率一般的要求 50% +重点的要求 80% +根据项目的具体要求，变动特别大的项目需要额外单独考虑覆盖率2）团队建设。

1、自动化测试目标自动化测试的主要目标是提高测试效率和准确性，以便更好地支持软件开发和交付流程。以下是一些常见的自动化测试目标：提高测试效率：自动化测试可以代替手动测试，从而加速测试过程，尤其是在重复性、繁琐或复杂的测试任务中。支持更高的测试覆盖率：自动化测试可以覆盖更多的测试用例和情景，以便检测潜在的问题和错误。提高测试准确性：自动化测试可以避免人为错误和主观判断，从而提高测试结果的准确性和可靠性。支持持续集成和交付：自动化测试可以与持续集成和交付流程集成，以便在软件开发过程中快速检测和解决问题。

1、你会封装自动化测试框架吗？这个问得最多，甚至有很多公司直接写在招聘要求中！当然可以，自动化框架主要的核心框架就是分层+PO模式：分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。然后再加上日志处理模块，ini配置文件读取模块，unittest+ddt数据驱动模块，jenkins持续集成模式组成。2、如何把自动化测试在公司中实施并推广起来的？1）项目组调研选择自动化工具并开会演示demo案例，我们主要是演示selenium和robotframework两种。

1、原则任何新增接口和修改接口都需通知测试人员，并由其进行相关接口测试；接口测试不仅要求从白盒角度对系统的整体架构有足够了解(逻辑)，还要求从黑盒角度对用户场景熟悉(业务)，两者相辅相承设计测试用例；始终站在用户的角度对系统接口进行全面高效持续的检测。2、评估项业务功能覆盖是否完整业务规则覆盖是否完整参数验证是否达到要求（边界、业务规则）接口异常场景覆盖是否完整接口覆盖率是否达到要求代码覆盖率是否达到要求性能指标是否满足要求安全指标是否满足要求3、类型。

1、测试环境选择和搭建自动化测试运行环境，不外乎测试环境(SIT)、验收环境(UAT)、灰度环境(PRE)和生产环境(PROD)。在不同的环境运行的目的、效果、优势和不足也各不相同，下面是不同环境的区分对比结果。不同环境对自动化测试开展的便利性和制约性不同，建议根据自动化测试的成熟度、要解决的问题来选择不同的环境。当然，如果选择搭建单独的自动化测试环境，就要考虑环境资源申请、域名、代码仓库权限、维护成本等因素。

1、线性测试早期的自动化测试，就是通过录制或者编写应用程序的操作步骤产生响应的线性脚本，来模拟用户完整的操作场景。优点：单个脚本相对完整，且独立，可拿出来单独执行；缺点：开发成本很高，测试用例之间可能存在重复操作，每次都要录制或编写重复的操作，比如用户登录；维护成本很高，因为存在重复操作，因此如重复操作发生变更，就需要包含重复操作的用例都需要进行修改；2、模块驱动化测试将重复的操作独立封装为公共模块，用例执行过程中需要用到时调用该公共模块，最大限度的消除重复操作；

1、自动化测试的分层模型自动化测试的分层模型，测试同学都应该很熟悉了，按照分层测试理念，自动化测试的投入产出应该是一个金字塔模型。越是向下，投入/产出比就越高，但开展的难易程度/成本和技术要求就越高。接口自动化测试方向：Python+requests+pytest+yaml+alluer+Jenkins；web自动化测试方向：Python+selenium4+pytest+POM+allure+Jenkins；

自动化测试其实是一个老生常谈的话题了，业内各种自动化测试平台/框架，或者最佳实践已经足够多。按理来说大家依葫芦画瓢，摸着别人的路走应该都不至于难以落地，但现实是依然有很多团队面临难以落地或者说落地了没到达预期效果。1、自动化测试要解决什么问题？在传统的软件研发交付流程中，大致有五个阶段：需求-设计-编码-测试-发布。测试更多的只是这个流程中的一环，主要负责QC(质量检测)，即分析需求，评估测试点，设计测试用例，执行case，发现并追踪BUG。由于测试处在软件产品发布前的最后一环，且在前面几个阶段往往有各种原

为什么要设计case？无论是功能测试还是自动化测试甚至性能测试，设计测试case都是必须的。当然，不同的测试类型，在设计测试case时候的侧重点和颗粒度是不同的。设计测试case的目的，我个人认为主要有如下几点原因：1、便于测试活动开展测试工作的本质是尽可能以更高的效率保障交付产出物的质量满足甚至超出预期，这是所有测试工作的最终目标。但在实际的工作实践中，绝大多数的测试工作都是围绕测试case来开展。

功能测试到接口自动化的进阶。1、接口测试的必要性和意义接口测试实施在多系统的平台架构下，有着极为高效的成本收益比（当然，单元测试收益更高，但实施单元测试的成本投入更大，技术要求更高，所以应该选择更适合自身的才是最好的方案）。接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台复杂，系统越庞大，接口测试的效果越明显。总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益驱动作用下的最佳方案，主要体现在如下三个方面：1）节省了测试成本。

接口自动化建设过程中遇到了一些困境，需要从团队建设角度给出发展目标和具体的指标，主要问题有如下两点：大厂/有最佳实践的团队，接口自动化在微服务的角度覆盖率需要达到多少？接口自动化的稳定性(case通过率)需要达到多少才算是达标，达到多少算比较优秀？个人认为背后的原因在于，在开展接口自动化测试工作时，并没有考虑清楚需要投入的成本，团队当前的现状，以及优先级最高的问题该如何解决。从自动化测试的投入产出比金字塔模型来说，接口自动化确实是性价比最高的一种自动化测试方式。

对于自动化测试的价值如何体现，主要有如下2点：1）基于团队内部，从解决问题角度出发的技术落地实践和数据度量；2）基于跨团队合作，从KPI/OKR角度,用度量的数据来支撑你的价值传递；1、团队内部，解决问题不同公司不同技术团队对于开展自动化的目的各有不同，常见的目的有下面几点：测试数据准备耗时长，为了提升造数据的效率而做自动化测试；项目上线之前的核心业务链路回归，为了提升回归测试效率，这也是一种上线前的check手段；

接口自动化测试中，有必要把接口返回的每个字段都进行断言吗？无论是性能测试还是自动化测试中，要不要设置断言，为什么设置断言，断言的作用是什么，如何设置断言，都是新手容易踩坑犯错的地方。1、什么是断言设计测试用例的方法相信大家都深谙于心，最基本的要素有场景、操作步骤、输入和输出值，目的是验证测试用例对应的业务场景或功能是否如预期实现。预期输出值可能有一个也可能有多个，在功能测试场景中，我们可以通过界面返回或渲染的结果，与产品需求描述和UI设计进行对比，如果符合需求描述和UI设计，则判定该测试用例执行通过。

一般来说，这种技术落地方案，原因不外乎下面这几点：技术实践落地，方案本身就是一个指引；文档落地沉淀为知识库，便于其他同学查看学习；梳理落地思路，经过评审才能获得团队和上级认同，进而有资源投入；1、实施背景和挑战写技术落地方案时，优先级最高的是交代清楚为什么要做这件事，做这件事能解决什么问题。技术本身是无法直接等于价值的，而是通过技术解决问题才能间接创造价值。且任何技术方案的落地，势必都需要一定的成本投入，如果落地后能解决的问题所创造的价值还不如投入的资源，那这个技术案例就是失败的。

持续集成的自动化用例很多，测试环境日志level为debug，日志量大概40G/每天，定位问题时日志查询很慢，该怎么解决？这个问题可以说是自动化测试实践中经常遇到的问题，那么该如何解决这些问题呢？或者说有没有更好的方案来优化这些问题？1、日志作用日志的本质就是记录系统各种操作事件的记录信息。它记录了系统的各项特征，类似医院体检后的体检报告。它反映了系统的健康状态、各项操作事件、系统变更情况以及各种异常隐患。