代码覆盖率价值 业界一般是通过代码覆盖率来输出自动化case的覆盖数据，衡量接口自动化测试的完备程度，来指导后续要增加、完善case的方向。另一方面，它还可以反映服务端功能测试的全面性，用来评估服务端手工测试是否全面 除此以外，代码覆盖率还可以应用于单元测试，可以拿到经过执行单元测试用例后的覆盖率数
step1：拿到测试需求（需求阶段、设计评审时、提测后功能实现完成后不确定是否存在性能问题） step2：测试计划也会明确性能测试事项，在接口测试计划的基础上增加性能测试方案落地（文档输出和评审）、测试数据的准备和脚本编写、性能测试执行、性能结果分析 step3：接口测试完成后介入（如果没有接口测试
序言： 性能测试方案，包含：测试背景、测试目的、测试策略、测试内容、测试用例、风险等内容，一份详细的性能测试方案可以帮助团队成员明确测试计划和手段，更好的把控测试流程。 本文以我在实际工作中的项目举例，阐述如何编写性能测试方案。 方案设计： 一、测试背景 如果是测被测服务的压力，了解瓶颈，参考： 本
背景 对于开发人员来说，在实际项目中写单元测试的过程中会发现需要测试的类有很多依赖，这些依赖项又会有依赖，导致在单元测试代码里几乎无法完成构建，尤其是当依赖项尚未构建完成时会导致单元测试无法进行。 为了解决这类问题开发人员引入了Mock的概念。 而对于测试的我们来说，我们在测试被测服务过程中，会遇到
背景 现如今的研发团队中，早已形成一套成熟的代码分支管理规范和体系。如果离开代码分支管理，会有以下这些痛点问题： 版本控制困难，难以追踪特定版本的代码。 并行开发困难，多个开发者可能在同一份代码上进行修改，导致冲突和数据丢失。 代码合并复杂且容易出错。 代码审查困难，难以保证代码质量。 发布管理混乱
本文阐述在接口测试用例输出完成后，如何实现接口自动化框架的从0到1的搭建。 步骤1 搭建基础框架 搭建基础框架，外层目录结构包括： business--业务层通用方法， common--通用方法封装， logs--日志存储， config--配置存储， testCase--用例集， main--项目
背景： 之前在团队中落地了接口自动化检测服务工具的服务端，但是，如果想要提高程序的易用性，以及提高在团队中的推广力度，我基于pyqt实现了该扫描服务的客户端。 详细步骤 环境准备 安装python： 下载链接：https://www.python.org/getit/ 安装python编译器pych
背景： 实际业务场景中，多数接口的实现可能都是用的同一套实现逻辑。比方说当前团队所有业务所有服务涉及到身份认证、签名校验服务的，对于开发人员而言，都是同一套实现逻辑。但是从测试人员的角度来说，接口校验中其实有很多都是重复的测试用例。 为减少测试人员的重复性工作，基于Python和Flask技术栈，我
背景痛点： 落地接口自动化项目过程中，提高团队内部的编码效率和代码可读性一直是重中之重，并且，在自动化用例运行期间，如遇到运行异常或断言失败等问题，如果运行的用例数量过大，在一定程度上，影响了团队内排查定位问题的效率。并且，运行时的具体情况细节，如果仅打印在控制台，当下一次运行开始时，之前的记录都不
背景 断言是接口自动化测试的核心部分，它确保了测试的准确性和可靠性。 在实际落地项目过程中，如果直接使用uniitest自带的断言功能，未优化和封装断言模块，编写的断言脚本如下代码所示： def testCase_demo1(self): # 测试步骤 res = requests.
