分享测试知识

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

1、token令牌token：令牌（令牌代表身份信息，身份标识----身份校验（数据库db校验，每发个请求就需要校验很麻烦，避免频繁访问数据库，token就表示身份））cookie和token（cookie里面最关键的就是session id值）cookie里面有时候有sessionid和token值一般为了减少对数据库的访问，校验，数据库的账号密码做个令牌：token需要身份校验，账号密码校验，获取token值（返回token字符串））

1、接口自动化测试概述什么是接口测试：前后端不分离：淘宝网站（响应的数据在页面，访问响应的数据是html的）返回的是一整个html（做接口难，需要解析数据，因为返回的是整个html代码）前后端分离，前端和后端通过api（接口交互），返回的只是数据本身（App可能并不需要后端返回一个HTML网页）（市面上主流项目前后端分离走json格式的）发请求以json数据格式返回的，通过api接口协议前后端进行交互的2、前端页面安卓或者ios app，网页统层为前端展示（数据展示和用户的交互）,

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

1、基础介绍1）什么是接口我们常说的接口一般指2种API：应用程序编程接口GUI：图形用户界面（接口）这里我们主要说API——接口测试2）接口测试的目的测试接口的正确性和稳定性（持续集成是接口测试的核心）3）接口测试的原理模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的一个过程。4）接口测试的重点检查数据的交换，传递和控制管理过程，还包括处理的次数5）接口测试用例设计。

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

1、什么是接口测试？定义：测试系统组件间接口的一种测试。主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点，重点是检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等；目的：测试接口的正确性和稳定性；原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；核心：持续集成是接口测试的核心；

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

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

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

1、说说最近做过的项目？这个问题考察的重点有如下几项：简历是否过度包装(阐述的项目经验和简历中的内容是否匹配)。对参与过的项目是否足够了解(业务流程、核心模块、技术架构)。在项目中做了哪些事情，有哪些技术实践(便于开展后续的提问)。项目迭代情况，交付质量，遇到的问题，以及候选人如何解决这些问题。2、你们的测试流程是什么？这个问题看似简单，其实很多同学在回答的时候容易犯流水账式的回答错误。比较好的回答步骤如下：说明测试流程的几个核心部分(需求-编码-测试-交付)。

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

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

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

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

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

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

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

1、落地前：分析因素从我个人的工作实践经验来看，在决定是否引入新的技术框架或者开展技术项目前，足够详尽的分析调研必不可少。这样做的好处在于一方面可以避免重复建设；另一方面，尽可能确保投入的资源能获得足够的收益。落地自动化测试之前，主要有如下几点因素需要考量。1）当前面临的痛点是什么？引入自动化测试是为了解决工作过程中遇到的问题或痛点，所以在引入之前第一个要考虑的是当前面临的痛点是什么。

自动化case越多，测试数据越多，数据的管理成本也越来越高，是否需要一个数据池来专门管理测试数据？随着技术不断发展，新的工具、方法论和技术实践越来越多，自动化测试在具体工作中有了很多方法论和实践，这些实践的背后是什么原因在推动技术的发展。自动化测试成熟度演变分为如下几个阶段：PS：上图不同阶段的标识，只是为了说明每个阶段的测试数据特性，而非这个阶段的具体技术实现方式和细节。1、学习阶段很多测试同学在刚开始学自动化测试的时候，基本都是脚本和测试数据写在一起，从实际工作应用的角度来说很不推荐。

自动化测试已经成了业务测试同学的面试必问技能。前几年大家觉得功能测试最多只负责功能+接口，自动化测试需要有专门的岗位，而近几年，自动化测试成了业务测试的必备技能。我个人认为原因有如下几点：软件工程理念在实际工作中的不断深入；业务迭代加速以及系统架构不断复杂化倒逼测试提升效率；自动化测试工具/框架/技术实践不断丰富成熟以及求职市场的整体水平提升；其实自动化测试的理念很早就被提出来了，国外也有很多的实践，国内相对较慢，但近几年测试圈子整体的基础技术建设也在快速发展。

近几年随着业务迭代速度加快，以及测试行业的不断发展，像测试左移、敏捷测试等理念开始被更多的人认可。从软件工程的角度来说，越早介入发现问题和风险，修复的成本越低，最终交付的质量也越高。1、理解接口和接口测试1）如何理解接口？简单来说，接口就是一个中介，负责界面层的业务场景和代码层的实现逻辑交互转化。接口遵循一定的规则和约束，输入特定的数据会返回特定的数据，输入和输出的逻辑需要事先约定。接口之间互相调用也需要遵循一定的规则，这个规则就是网络协议，如：http协议、tcp协议，rpc协议。

技术菜鸟如何提升自己的能力？常见背景：1）本科软件工程专业，3年测试经验，历经两家公司。2）当前岗位是测试工程师，业务和技术占比9:1，加班较多。3）学了一些技术课程，但工作中技术实践不多，个人比较迷茫。4）希望能提升自己的技术水平和专业能力，但不知道从哪里切入。首先，要承认成长是一个比较长的过程，而非一蹴而就的事情。自动化测试方向：接口自动化测试方向：Python+requests+pytest+yaml+alluer+Jenkins；

1、测试范围无论是功能测试，还是自动化或者性能测试，第一步要做的，是明确测试范围和需求指标。对于自动化测试来说，特别是UI自动化，并不是所有的功能点都适合做UI自动化。根据具体的业务情况和项目稳定程度，选择UI自动化+API自动化结合，选择合适的业务点来进行针对性的自动化测试方案设计，才是最佳方案。对于什么项目适合做UI自动化，这里列几个我个人觉得比较适合做UI自动化的点：①使用频次较高，异常判断较多，且最基础的功能，比如用户注册、登录；②用户端比较核心的功能，比如订单中心，会员中心；

1、接口测试的必要性和意义接口，即API，应用程序编程接口，关于接口的介绍，之前的博客就有详细介绍过，感兴趣的童鞋可以去看看：接口测试简介这里主要说说接口测试的必要性和意义：接口测试实施在多系统的平台架构下，有着极为高效的成本收益比（当然，单元测试收益更高，但实施单元测试的成本投入更大，技术要求更高，所以应该选择更适合自身的才是最好的方案）。接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台复杂，系统越庞大，接口测试的效果越明显。

1、Pytest框架Pytest是一个强大的Python自动化测试框架，它提供了丰富的功能来帮助用户编写、运行和组织测试用例。Pytest支持丰富的插件，能够扩展其功能，例如生成HTML测试报告、多线程运行测试用例、控制用例执行顺序等。此外，Pytest还支持与Selenium、Requests等库结合，实现Web自动化、接口自动化和App自动化测试。2、开发思想接口自动化测试框架的核心思想是通过封装一些自动化的基础模块、管理模块和统计模块，来提高测试效率，降低维护成本，减少人工干预，增加代码的重用性。

面试题：你有没有做过自动化测试？我在xx项目中实施了web自动化测试，我们项目中搭建自动化测试框架技术：python+selenium+unittest/Pytest+ddt+jenkins，然后用的POM分层的模式（面向对象思想），数据驱动使用的是excel+ddt的驱动模式，我在这个自动化测试实施的项目里所负责的那些模块那些测试用例的自动化代码编写我在xx项目中实施了接口自动测试平台搭建，技术栈：python+django+unittest+ddt+jenkins。

1、测试面试时，面试官要你介绍项目，怎么说？关于介绍自己的项目？可以从以下几个方面来表述：【项目基本介绍]】项目架构、项目业务流程、包含功能模块；【项目职责】总结自己在项目中所做的工作，可进行一些数据量化【某一项职责细化】针对项目中所做工作的某一项展开说明，体现亮点，凸显优势以电商项目为例：1）项目基本介绍这个电商项目是一个B/S架构的 B2C电商平台系统，依托线上平台为客户提供各种美妆产品，包括护肤、化妆品、美容、香水等等。

加解密接口的处理目标：知道项目中接口加解密的实现流程了解加解密的代码实现知道Jmeter如何实现接口加解密测试知道基于Requests如何实现接口加解密测试1、APP端/客户端接口加解密介绍加密方式（两种）：在TCP/IP四层模型中的应用层进行加密。类似密码本，当前项目使用的是这种，可以看到所有响应内容，只是看不懂。在TCP/IP四层模型中的运输层和应用层之间进行加密，通过传输协议实现加密，如https。类似加密路径，此种加密方式抓取到的报文响应内容全是乱码2、加解密接口测试时的要点。

1、自动化测试框架概念随着时代高速发展，面对市场强大的竞争，研发的产品需要快速完成研发和测试。面对质量和快速的交付双重压力下，我们需要让代码替代人工完成日益多CASE检查，自动化测试框架孕育而生。自动化测试框架是一套包含测试case、测试结果、测试方法等一些实现对测试软件进行测试的解决方法。对于一个刚刚起步的测试团队，选择一款自动化测试框架，它们帮我们提前定义好概念和CASE编写方法等集合，能在项目中产生收益。2、关键字驱动什么是关键字驱动？

如何构建性能测试的技术体系？性能测试技术体系的构建，大致要分为四个阶段，分别是：日常化、自动化、工具化和平台化。1、日常化很多做性能测试的同学，在工作中面临的最大问题是性能测试无法成为日常测试工作的一部分，即性能测试作为质量保障的一种手段，却无法融入正常的需求版本迭代流程中。最常见的例子就是一句话需求，比如：这几个接口压测一下，出一份报告；或者线上出了性能问题，才火急火燎的找测试同学，对系统进行压测，再排查定位问题。

问题：把测试数据放配置文件读取和放文件通过函数调用读取有什么区别？自动化测试过程中，现在大多都默认测试脚本与测试数据分离的设计，这样做的好处是：降低维护成本，迁移成本以及提高效率。因此测试数据放在哪里，如何管理，不能一概而论。1、业务场景1）比如在UI自动化测试中，需要测试某个电商网站的各个业务模块，但前提是要用户登录。这个用来执行登录的测试账号数据往往是固定的，那么专门将一组username和password放在一个测试数据文件或者测试数据库中，这样就显得太笨重，耗时费力。

1、为什么要做接口测试？1）现在很多系统前后端架构是分离的，因为不同端（前段，后端）的工作进度不一样，所以我们要针对最开始出来的接口，以及需要调用其他公司的（银行，支付宝，微信，qq等）一些接口进行接口测试及验证数据，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。在这种情况下就需要从接口层面进行验证。前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

1、什么是框架定义：为解决某些特定问题而约束边界，支撑整个问题解决方案，配套了一些解决问题的组件而构成的工具。特定问题：什么问题？——自动化测试约束边界：为什么约束？——明确测试范围和目的解决方案：用什么方案解决问题？——编程语言+工具+其他构成工具的组件：哪些组件？—— 用例、脚本、数据、日志、报告、通知工具：特点是什么？—— 灵活性、可扩展性、高内聚低耦合2、自动化测试1）为什么要进行自动化测试？①黑盒测试回归效率低②手动测试的偶然性和不确定性③回归的覆盖率不足。

一般来说，工作中写这种技术落地方案，原因不外乎下面这几点：技术实践落地，方案本身就是一个指引；文档落地沉淀为知识库，便于其他同学查看学习；梳理落地思路，经过评审才能获得团队和上级认同，进而有资源投入；从个人的实践经验来说，一个自动化测试落地方案或者技术方案，主要由下面几点构成。1、实施背景和挑战写技术落地方案时，优先级最高的是交代清楚为什么要做这件事，做这件事能解决什么问题。技术本身是无法直接等于价值的，而是通过技术解决问题才能间接创造价值。

今天给大家分享自动化测试到底该怎么做？1、软件测试三层金字塔在讲自动化测试前，大家都知道软件测试的分层模型，“三层金字塔”，分为单元、服务和UI三个层级。尽管大家对此的具体描述各不相同（有人将三层分别定义为单元、接口、集成测试；也有人将整个金字塔划分为4-5个层级），但金字塔自底向上的结构是大家公认和遵循的。1）单元测试单元测试是针对代码单元（通常是类/方法）的测试，单元测试的价值在于能提供最快的反馈，在开发过程中就可以对逻辑单元进行验证。