常用C++单测框架对比 特性 Google Test (gtest) Catch2 Boost.Test CppUnit 开发者 Google Phil Nash Boost社区 CppUnit社区 许可证...在 Mac 上 可以通过 Homebrew 安装 Boost库： brew install boost 步骤二：创建项目结构 示例工程结构： /boost.test /src...#include 包含 Boost.Test 的头文件。...BOOST_AUTO_TEST_CASE(test_add) 定义一个测试用例。 使用gcov + lcov统计代码覆盖率 准备工作 确保已经安装以下工具： CMake：用于构建项目。...GCC：支持代码覆盖率生成（其他编译器如 Clang 也可以，但这里以 GCC 为例）。 gcov：GCC 自带的代码覆盖率工具。 lcov：用于生成 HTML 格式的覆盖率报告。
在大部分情况下，我们是自己给自己写的函数做单元测试，当运用黑盒测试的思路时，要 假装 被测函数是别人写的。 覆盖 在单元测试中，覆盖率是一个常用的评估指标。 所谓覆盖，可以简单理解为 “被执行过”。...= 4) return false; // ... } 因此我们在设计测试用例时，可以： 首先设计覆盖 正常流程 的用例，构造一些合法的输入：一个典型的 IP 报文，一个有扩展头部的 IP 报文，...的 IP 报文，一个大小为 64K 上限的 IP 报文，一个头部完整但payload 不完整的 IP 报文…… 在设计测试用例过程中，可能会遇到被测函数需要与外部 DB、文件、网络交互的情况，这时候需要使用...不关心内部实现方式，代码优化重构用例仍可复用 白盒测试为辅： 白盒测试关注黑盒测试用例遗漏的分支、路径 可以聚焦于异常处理逻辑是否合理 项目工期紧时可推迟进行 可能踩到的坑 不要被高覆盖率骗了 单元测试的目标是发现问题...Release 下再跑一次 代码合并导致单测失败 小A和小B分别开发新功能，push 前单测都通过了，MR 后单测却挂了 使用持续集成发现问题 提高代码的可测性 在编码过程中，多多考虑代码的可测性，可以让单元测试事半功倍
在selenium测试中，我们可以用来做webdriver的初始化等等 testcase 测试用例，unittest的最小单元。用以对指定输入的返回结果进行检测。...在unittest中提供 了TestCase基类，用来创建新的测试用例类。 test suite 测试套件，一系列测试用例或测试套件的集合。在unittest中由TestSuite类实现。...test runner 测试执行器，负责用例执行并生成测试报告，在unittest中提供了命令行模式和GUI模式来执行。 unittest使用过程 下面一步步的展示如何使用unittest来测试。...sys reload(sys) sys.setdefaultencoding("utf-8") # 被测函数 def add(a, b): return a + b # 测试用例 class...2 -v, --verbose 查完整的测试结果输出信息 3 -q, --quiet 查看最小测试结果输出信息 4 -f, --failfast 在第一次遇到失败时，停止测试 5 -c, --catch
二，TDD模式简介 测试驱动开发 (TDD，全称test-driven-development) 是一种软件开发实践，专注于在开发实际代码之前创建单元测试用例。...它是一种迭代式的软件开发流程，在迭代的过程中将编码、单元测试和代码重构结合起来。TDD在测试失败时修改或编写新代码，防止重复测试同一个bug。...BDD的步骤 1.给定业务功能的场景 2.定义场景的执行步骤，编写测试用例 3.运行执行步骤的测试代码，如果失败了，修改步骤对应的代码，直到测试通过 BDD的语言描述形式 GIVE-WHEN-THEN...测试用例之间相互隔离，同一个测试用例内部，又可以分割为多个section，每个section都是独立的运行单元。 测试用例命名时支持自由格式的字符串命名。...1.断言：REQUIRE和CHECK REQUIRE：测试失败后中止测试用例 CHECK：测试失败后继续执行 样例： CHECK( str == "string value" ); CHECK( thisReturnsTrue
在做前端测试时，选用合适的测试策略远比一通狂写测试更重要，所谓 “方向 > 努力”。 如果选择了错误的测试策略，很容易写出维护性差和不稳定的测试用例。一旦业务出现变化，用例就全崩了。...像上面那样过度测试实现细节会带来两个结果： 我可以在测试完全通过的情况下弄崩业务代码（比如在 onClick 赋值时故意写错变量名） 我可以在重构业务代码的时候弄崩测试用例（例如，把 increment...重命名为 updateCount，测试就崩了，但业务代码是能正常运行的） （译注：作者对重构的理解是：改动业务代码逻辑时，测试代码不应该做改动的，因为业务逻辑没变，只是实现方式变了） 类似这样的测试用例是最难维护的...代码覆盖只能告诉你一件事： 这行代码有被测试用例跑过 然而，它没有告诉你的事有： 代码是否按业务需求来正常工作 代码是否能和项目里其它代码一起工作 项目崩了的时候会发生什么（这里指意外崩溃） 代码覆盖率的另一个问题是...这三个误区的产生都是因为我们没有搞清楚测试的本质：提高代码自信。当你很痛苦地编写测试用例的时候，那么很可能你钻入了牛角尖，往错误的方向写测试了，这时就要停止然后回过头来想：怎么做才能提高代码自信呢？
pytest -h --help # 显示命令行及配置文件选项帮助信息 2.第1(N)次失败后停止测试 在第1(N)次用例失败后停止测试执行： pytest -x #...第1次失败后停止 pytest --maxfail=2 # 2次失败后停止 3.指定及选择测试用例 运行模块内所有用例 pytest test_mod.py 运行目录内所有用例 pytest...--tb=no # 不使用追溯信息 5.详尽的测试结果摘要 -r标志可用于在测试会话结束时显示测试结果摘要,从而可以在拥有大量用例的测试套件中轻松获得所有失败、跳过、标记失败(xfails)...一般,你可能只希望在第一次失败的测试中执行此操作以了解某种故障情况： pytest -x --pdb # 在第一次用例失败时进入PDB pytest --pdb --maxfail=3 # 在前3...次失败是进入PDB 注意,在任何失败时,异常信息都存储在`sys.last_value1,1sys.last_type1和1sys.last_traceback1中 7.分析测试用例执行时间# 显示执行最慢的
背景 当你作为一个测试工程师在送测阶段（提测阶段）A1还没到测试结束时间时，开发突然过来问你现在有个***问题需要更新测试才能验证，才能联调，才能....，现在可以更新测试环境吗？...第一次负责送测就闹这一出，心里很是压抑，决定要进行复盘 提出问题 在送测阶段测试时间未结束时，开发询问测试是否能提前更新测试环境，测试应该如何分析和决策？...大项 小项 测试进度 送测功能是否已完成测试？ 测试用例是否已执行完成？ 还剩下哪些未执行？ 影响范围 下一个送测阶段的测试内容 会不会影响当前测试？ 会压缩当前送测阶段多少测试时间？...待更新功能的重要性 沟通相关 及时跟同组测试沟通，一起衡量和决定是否可以让开发更新环境 送测功能是否已完成测试？ 测试用例是否已执行完成？ 还剩下哪些未执行？...待更新功能的重要性 沟通相关 及时跟同组测试沟通，一起衡量和决定是否可以让开发更新环境 可参考官方定义的测试停止准则 1、测试超过预定时间 2、执行完了所有用例没有发现新的bug 3、单位时间内查出的
在本文中，我将通过讨论以下主题来研究如何使用Python创建单元测试。...它就像一个总结考试内容的标题。如果测试失败，你首先看到的就是它。因此，名称应该清楚地表明哪些功能不起作用。 测试用例名称的列表应该读起来像摘要或场景列表。这有助于读者理解被测单元的行为。...构造测试用例方法体 一个设计良好的测试用例由三部分组成。第一部分，安排、设置要测试的对象。第二部分，Act，练习被测单元。最后，第三部分，断言，对应该发生的事情提出主张。...原因是，当断言失败时，测试用例的执行就会停止。因此，您永远不会知道测试用例中的下一个断言是否成功。 使用pytest进行单元测试 在上一节中，我们使用了unittest模块。...在您的测试用例中，您可以使用用该属性装饰的方法的名称作为参数。 pytest框架在运行时将它们连接起来，并将fizzBuzz实例注入测试用例中。
如果条件为假，则断言将抛出错误，将测试标记为失败。 举一个烤蛋糕的例子 让我们以烘焙巧克力蛋糕为例，以及如何在过程之间和结束时插入断言。...这与检查最终结果的断言相同（在软件中，这可能是检查事务是否完成）。 二、软件测试中的断言类型 下面是两种类型的断言和比较表： 硬断言是指当不满足断言条件并且测试用例失败时测试执行将中止的断言。...，它将继续下一个测试用例，但在测试用例结束时将该场景标记为失败。...它在以下情况下尤其有用： 复杂测试用例: 当你有一个包含很多断言的复杂测试用例，并且希望获取关于所有断言的反馈，而不仅仅是第一个失败的断言。...在使用`pytest.assume()`时，如果出现断言失败的情况，会如何继续执行其他断言？ 当使用 pytest.assume() 函数时，该函数会捕获断言错误并将其记录下来，而不会立即抛出异常。
相比在项目结束时才进行的测试工作会花费更多的时间，用在单元测试上的时间是要少得多的。当然，前提是开发者必须要对所要测试的单元要实现什么样的功能，期望输出是怎样的要十分了解才行。...3.记录您的代码，运行，调试甚至只是阅读测试都可以提供许多有关原始代码如何工作的信息，因此您可以将它们用作隐式文档。 如何开展单元测试 实际软件项目中如何开展单元测试？...2.逻辑执行体：要明确当前测试用例测试的是哪个函数、哪个分支逻辑，不要一次性覆盖大多。 3.结果校验：尽可能完整，不要只校验函数返回值。 单元测试的原则 单元测试必须遵循的原则： 1....函数的风险在哪里，哪部分逻辑不太自信，最容易出错？ 并不是所有函数都需要单测，如get/set等逻辑比较简单的的，不一定需要写 。...单元测试最佳实战 客户端单元测试实践——C++篇 从头到脚说单测——谈有效的单元测试（下篇） · TesterHome
如果这个时候你的修改导致测试用例失败，你再重新审视自己的修改，发现之前的修改还有一些特殊场景没有包含，恭喜你减少了一次上库失误。...1.2 如何写好单元测试 首先，学会写测试用例。比如如何测试单个函数/方法；比如如何做基准测试；比如如何写出简洁精炼的测试代码；再比如遇到数据库访问等的方法调用时，如何 mock。...tt.want { t.Errorf("Add() = %v, want %v", got, tt.want) } }) } } 2.3.5 回归测试 我们修改了代码之后仅仅执行那些失败的测试用例或新引入的测试用例是错误且危险的...Table Driven的形式如下图。主要分成三个部分： 测试用例的定义：即每一个测试用例需要有什么。 具体的测试用例：你设计的每一个测试用例都在这里。...当你使用前面 Table Driven 的模式时，可以单个运行测试用例。
，所有的任务类都继承了一个抽象类，在action方法里定义了数据清理的接口请求 在每次创建数据后，实例化任务类，然后添加到队列里 所有测试用例执行完成后，afterTest里遍历队列依次数据清理 采用这个方式的优势...1、线上业务自动化校验 在公司越来越复杂的分布式架构下，难免会出现远程调用失败，消息发送失败，并发bug等问题，最终会导致系统间的数据不一致。...我们来讲讲如何覆盖这个场景的： 在对应的后台应用上找到购买商品的Topic A 在BCP平台建立一个监听A广播消息的Channel B 消费A的广播消息时触发接口请求，查询买家的权益信息，检查是否对于的优惠券信息...，监听BEFORE、RETRUN、THROW事件机制获取每次调用的传参和返回 每一个完整流量的traceid和调用链路，会生成一个MD5值，判断是否有重复，若有，测试用例热度+1，若无，创建新的测试用例保存...测试环境部署被测代码，也挂载上Agent，创建任务执行线上流量保存下来的测试用例，支持Mock dubbo consumer和中间件调用 执行返回的response和线上采集的进行Json diff，
前言 “80%的bug集中在20%的模块，越是容易出现bug的模块，bug是越改越多“平常我们做手工测试的时候，比如用100个用例需要执行，其中10个用例失败了， 当开发修复完bug后，我们一般是重点测上次失败的用例...那么自动化测试也一样，当用例特别多时，为了节省时间，第一次部分用例失败了，修复完之后，可以只测上次失败的用例。...(喜欢纸质书的，可以直接点下方购买入口，推荐指数：★★★★★) pytest -h 命令行输入pytest -h，找到里面两个命令行参数： —lf 和 —ff —lf, —last-failed 只重新运行上次运行失败的用例...（或如果没有失败的话会全部跑） —ff, —failed-first 运行所有测试，但首先运行上次运行失败的测试（这可能会重新测试，从而导致重复的fixture setup/teardown） ?...—lf 和 —ff lf是last-failed的缩写，我第一次运行全部测试用例有4个通过passed， 2个失败failed，1个error E:\YOYO\web_conf_py>pytest ==
所以为了跟上时代的步伐，作为软测的大家是不是也应该考虑如何让AI辅助我们更加完整高效的完成日常的各类质量保障工作呢？ 那么对于软件测试来说，先阶段的AI可以帮助我们做些什么呢？...4.2 配置应用 在我们创建测试用例之前我们需要先创建一个应用程序，这个应用程序其实就是我们的被测对象，我们点击Configuration侧边栏按钮，跳转到下图的页面，然后点击Configuring applications...那么在mabl自动化测试平台中，也有这么一个自愈的概念，其核心的主旨就在于当被测对象的某些特性或属性发生改变的时候我们的测试用例就会失效，这个无论是手工测试用例还是自动化测试用例都会遇到，同时随着被测系统的功能迭代与规模增加...这里我们做一下整理，如果你的测试用例因为某些页面或元素属性的变更然导致执行失败，那是非常常见的情况，无论是日常的需求变更还是功能与页面迭代，只要断言的那个元素依然正确，那AI就自动辨认发生变更的一些页面元素...在见解与通知界面中找到我们的测试用例，可以看到我们自愈测试用例的细节，如果不想测试用例进行自愈，那么就可以点击下图的REJECT CHANGES按钮来拒绝这个变更动作。
方法一：使用注解方式，实现重复执行单条用例 在测试用例前添加注解@pytest.mark.repeat(value)，value表示重复的次数，来实现单条用例的重复执行。...方法三：所有测试用例执行一次，重复执行N遍(我在使用下面四个参数运行脚本后的结果都与- -count即方法二的结果一样，但不影响其它功能的运行，所以这边先做个记录，后续有用到这个知识再去解决。...，将会话中的所有测试用例执行一遍，共执行N轮 二、测试用例执行失败重运行 (一)、安装环境 重运行机制使用到了pytest的插件，插件名称为：rerunfailures，要使用它，需要先安装此插件 命令行输入...pytest -s -v --reruns=2 --reruns-delay=10 test.py 运行结果如下： image.png 三、重复执行测试用例直到失败停止 将pytest的 -x 选项与pytest-repeat...结合使用，可以实现在重复运行测试用例的过程中，测试用例第一次失败时就停止运行，具体实现方法如下： # 重复运行5次，运行过程中第一次失败时就停止运行 import pytest class TestFailure
、--cache-clear 3、自定义标记mark 1、运行上次失败用例 执行全部用例，第一次部分用例执行失败，此时当被测系统修复后，可执行上次失败的用例。...1、如果只想运行 failed 和 error 用例，使用参数 --lf 在命令行输入： pytest --lf test_lf_ff.py 运行结果： 2、如果想先运行上次失败的，后运行其它通过的用例...--cache-clear 在测试运行开始时删除所有缓存内容。 创建test_cache.py文件 编写4条测试用例 脚本代码： #!...例如：可以标明哪些用例是在 Windows 下执行的，哪些用例是在 Mac 下执行的，在运行代码时指定 mark 即可。 示例一： 1、创建test_mark.py文件 脚本代码： #!...例如： 文件内容： [pytest] markers = case1: 执行case1的测试用例 case2: 执行case2的测试用例 case3: 执行case3的测试用例
首先，是确定测试用例的来源； 当开始准备编写自动化测试用例时，需要确定测试用例的来源，即需要明确例如以下几个方面： （1）哪些功能是主要功能、哪些功能可以自动化； （2）用例的优先级、作用的测试阶段；...然后，应该合理地去设计自动化测试用例； 在设计自动化测试用例时，除了实现用例来源中的功能步骤外，用例的原子性是需要额外注意的，这将影响到多个用例在一起时是否可以高效稳定地运行。...在编写测试用例时需要验证用例的有效性，在测试用例交付使用后，也应该定期地关注测试用例的运行情况及其有效性。...由于在测试执行时，不同的用例执行时间长短不同，且作用的测试阶段也各不相同阶，因此在进行用例管理时，需要明确用例的级别，例如区分是核心功能用例还是普通用例，从而将不同级别的用例放于一处进行管理，在执行时才可以有针对性地进行测试...图15.失败用例的报告详情页 用例采用出错重试并截图机制，当用例失败时进行截图，并往后开启截取一系列运行时的图片，每个用例右边有四个按钮，分别为将截图以gif格式播放、展示多台手机下同一用例运行情况、
测开不能只靠鸡汤，基础硬才是真的硬，欢迎收看【测试开发干货】我是作者-我去热饭 紧接上文，我们在服务器上下载并配置了gitlab-runner这个工具，并且在gitlab上项目的设置处看到亮起了绿灯...你可以给你公司产品app的项目代码设置一下，来执行你提前写好的自动化测试用例脚本。 问题：这个文件调试和执行时机是什么？...所以我们在gitlab网页上，在线修改.gitlab-ci.yml 然后保存，也一样可以触发才对，这样我们调试就方便了~ 注意，当你用公司的产品时，尽量单弄个分支代码来不断调试这个gitlab-runner...问题：有的同学发现，什么都没改，第一次可以执行成功，再次执行就会报错。 答：这个问题我当时也遇到了，为什么第一次可以成功，之后开始失败。...git 至此，如果你很幸运成功了，那么恭喜你可以继续深造这个CI/CD了，比如用测试平台和这个联动起来，让gitlab-runner发送一条http请求给测试平台，测试平台来执行对应某测试环境的测试用例脚本
所以为了跟上时代的步伐，作为软测的大家是不是也应该考虑如何让AI辅助我们更加完整高效的完成日常的各类质量保障工作呢？ 那么对于软件测试来说，先阶段的AI可以帮助我们做些什么呢？...Width Height: 被测对象的显示宽高，这个根据你设定的值来显示执行时的浏览器窗口大小Add to Plan: 这里需要说明下，是否加入计划，这里的计划可以理解为在某个特定的测试场景下需要执行的一组测试用例...那么在mabl自动化测试平台中，也有这么一个自愈的概念，其核心的主旨就在于当被测对象的某些特性或属性发生改变的时候我们的测试用例就会失效，这个无论是手工测试用例还是自动化测试用例都会遇到，同时随着被测系统的功能迭代与规模增加...这里我们做一下整理，如果你的测试用例因为某些页面或元素属性的变更然导致执行失败，那是非常常见的情况，无论是日常的需求变更还是功能与页面迭代，只要断言的那个元素依然正确，那AI就自动辨认发生变更的一些页面元素...在见解与通知界面中找到我们的测试用例，可以看到我们自愈测试用例的细节，如果不想测试用例进行自愈，那么就可以点击下图的REJECT CHANGES按钮来拒绝这个变更动作。
我之前就教过很多人测试的基础知识、如何配置工具、如何针对不用情况写好测试，等等。但是知道如何测试只是成功的一半，知道要测什么才是更重要的另一半。...这种情况下的代码覆盖率报告可以让我们知道：得马上写测试了，但它没有告诉我们这个函数有哪些重要的部分，也没有告诉我们这个函数支持的真实用例（正是我们在写测试时最要重点关注的内容）是哪些。...所以，当你看着这份覆盖率报告时，你不要总想着那些 if/else、循环或者生命周期，而是要问问自己： 这几行代码实现对应的是哪些使用用例？我应该要加哪些测试用例来覆盖它们？...在写测试时，你应该时刻想着要支持两种用户：真实用户和开发者。 再啰嗦一句，如果做测试的时候，你还是一直想着业务代码而不是真实用例，就会很容易陷入测试 “代码实现细节” 的陷阱。...后面 Kent 说到要如何把测试引入团队的方法也很值得大家去尝试：先按功能优先级列出个清单，再写 E2E 覆盖住最重要的那部分，再加集成测试，再加单元测试，等一切就绪，那么剩下的就是时间堆测试用例，最后测试用例也能慢慢融入到代码中了
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
云直播
对象存储
腾讯会议
