测试开发工具【免费下载链接】hypothesisThe property-based testing library for Python项目地址https://gitcode.com/gh_mirrors/hy/hypothesis点击查看免费下载性能优化是软件开发中最容易出现隐蔽回归的环节优化后的代码往往更快但更快必须建立在结果正确的前提之上。本文基于 Hypothesis 官方技术文章《Testing performance optimizations》讲解如何利用**差分测试differential testing**这一属性测试经典手法自动验证优化版实现与参考实现是否对每一组输入都返回相同结果。读完本文你将掌握为什么有两个实现是属性测试的绝佳场景、如何用given写出可复现的等价性测试、以及如何将这一技巧与状态机测试结合验证缓存层、数据库后端等复杂组件的行为一致性。从清除崩溃到验证正确答案在《Getting started with Hypothesis》一文中我们介绍过最基础的测试思路随便给函数喂随机数据看它会不会崩溃。当你把这类基本崩溃问题清理得差不多之后自然会想测试一些更有意思的性质。下一个最容易上手的测试目标是你知道每个输入应该得到什么正确答案的代码。乍一听这有点废话——理论上你当然知道正确答案是什么直接运行代码不就行了但这恰恰没有意义因为你运行代码得到的答案正是你想要验证的东西。关键洞察在于有时候得到正确答案的路径不止一条而你在生产环境中选择某一条不是因为它的答案不同而是因为它在答案相同的前提下更快。Hypothesis 官方文章中给出了三种最常见的场景快算法与慢算法并存同一个算法存在一个精巧但快的版本和一个朴素但慢的版本例如合并排序 vs 冒泡排序缓存层可以分别开启和关闭缓存运行同一段代码或使用不同的缓存超时时间数据库后端迁移为了提升可扩展性而迁移到新的数据库后端但迁移完成前旧后端的代码仍然保留。类似的场景还有很多但以上三种最为常见。它们共同构成了属性测试的绝佳用例如果两个函数被期望对同样的输入永远返回相同的答案那么测试方法非常简单——用同一份数据调用两个函数然后断言它们的返回值相等。given(测试数据) def test_两个实现返回相同结果(data): assert 参考实现(data) 优化实现(data)实战案例用冒泡排序验证合并排序假设我们用 Hypothesis 官方文章中的方式实现了一个合并排序merge sortdef merge_sort(ls): if len(ls) 1: return ls else: k len(ls) // 2 return merge_sorted_lists(merge_sort(ls[:k]), merge_sort(ls[k:])) def merge_sorted_lists(x, y): result [] i 0 j 0 while i len(x) and j len(y): if x[i] y[j]: result.append(x[i]) i 1 else: result.append(y[j]) j 1 return result我们希望有一个参考实现来对照测试于是再实现一个冒泡排序bubble sortdef bubble_sort(ls): ls list(ls) needs_sorting True while needs_sorting: needs_sorting False for i in range(1, len(ls)): if ls[i - 1] ls[i]: needs_sorting True ls[i - 1], ls[i] ls[i], ls[i - 1] return ls两个函数理论上应该永远返回相同结果那么就用 Hypothesis 来验证这一点from hypothesis import given from hypothesis.strategies import integers, lists given(lists(integers())) def test_bubble_sorting_is_same_as_merge_sorting(ls): assert bubble_sort(ls) merge_sort(ls)Hypothesis 立即揪出的排序 bug运行这个测试Hypothesis 立刻给出了一个失败用例given(lists(integers())) def test_bubble_sorting_is_same_as_merge_sorting(ls): assert bubble_sort(ls) merge_sort(ls) E assert [0, 0] [0] E Left contains more items, first extra item: 0 E Use -v to get the full diff foo.py:43: AssertionError ----- Hypothesis ----- Failing test case: test_bubble_sorting_is_same_as_merge_sorting(ls[0, 0])问题出在我们把merge_sorted_lists的实现写错了当两个子列表中的某一个被遍历完后我们忘了把另一个列表中剩余的元素追加进结果。结果就是合并排序悄悄丢掉了列表中的元素而更朴素的冒泡排序实现反而不存在这个问题。修正方法是在while循环结束后补上两个extenddef merge_sorted_lists(x, y): result [] i 0 j 0 while i len(x) and j len(y): if x[i] y[j]: result.append(x[i]) i 1 else: result.append(y[j]) j 1 result.extend(x[i:]) result.extend(y[j:]) return result修正后测试通过。注意这个失败案例的价值所在ls[0, 0]是一个极其精简的输入Hypothesis 自动完成了收缩shrinking把复杂的反例一步步简化到最小可复现形式让你能一眼看出 bug 的根源。从源码看lists与integers的生成行为这个例子中用到的两个核心策略在当前仓库中均有明确实现与文档化语义integers()定义于 hypothesis/src/hypothesis/strategies/_internal/numbers.py默认不限定取值范围生成整数时会向 0 收缩且负数会向正数收缩即-n可能被替换为n这正是反例能被简化到[0, 0]的底层原因lists()定义于 hypothesis/src/hypothesis/strategies/_internal/core.py默认min_size0、max_sizeNone生成列表时会尝试从列表中删除元素并逐个收缩每个元素从而让[0, 0]这类极简反例成为可能它还支持min_size、max_size、unique、unique_by等参数来控制长度与唯一性given装饰器定义于 hypothesis/src/hypothesis/core.py负责把测试函数与策略绑定并批量执行。如果希望测试更严格的场景可以给lists()传入min_size1排除空列表或用integers(min_value..., max_value...)限定数据范围——这些参数的实际校验逻辑check_valid_bound、check_valid_interval都在numbers.py的源码中可见。进阶差分测试 × 状态机测试验证复杂 API 的实现一致性朴素函数级差分测试虽然好用但现实中的性能优化往往落在带状态的复杂系统上。这时可以把差分测试与 Hypothesis 的规则状态机测试Rule Based Stateful Testing结合用状态机生成一串随机的操作序列同时施加到多个不同实现上再断言它们的状态与返回值始终一致。Hypothesis 项目自身就实践了这一组合在 hypothesis/tests/nocover/test_database_agreement.py 中用一个DatabaseComparison(RuleBasedStateMachine)状态机同时验证三种示例数据库example database实现的行为完全一致InMemoryExampleDatabase基于内存字典实现不持久化见 hypothesis/src/hypothesis/database.py适合单会话内多次调用或用于测试其他数据库实现DirectoryBasedExampleDatabase基于目录的文件系统持久化实现同一文件 L422 起BackgroundWriteDatabase带后台写入的包装实现同一文件 L1166 起。状态机测试的精髓让接口契约自动被验证DatabaseComparison定义了与数据库操作一一对应的规则save向三个实现写入同一组键值delete从三个实现删除同一组键值move在三个实现上执行相同的键迁移而values_agree规则则会逐库对比fetch(k)的结果集合一旦两个实现的返回值出现差异断言立即失败rule(kkeys) def values_agree(self, k): last None last_db None for db in self.dbs: keys set(db.fetch(k)) if last is not None: assert last keys, (last_db, db) last keys last_db db这就是差分测试思想的完整延伸三个实现内存版、磁盘版、后台写入版扮演同一接口的多个实现而状态机随机生成的操作序列则扮演任意输入。任何实现之间的行为差异——无论是磁盘持久化丢数据、后台写入丢更新还是move语义不一致——都会被自动捕获。测试入口test_database_equivalence()通过DatabaseComparison.TestCase().runTest()运行并针对 crosshair 并发场景做了跳过处理。可复用的实现模式从DatabaseComparison中可以提炼出验证多实现等价性的通用套路收集实现在状态机__init__中把待对比的所有实现放入同一个列表如示例中的self.dbs统一施加操作对每个rule把同一操作依次施加到列表中的每个实现上周期性校验定义一条对比规则如values_agree从每个实现读取当前状态并断言两两相等统一清理在teardown中释放临时资源示例中删除临时目录。这套模式可以原样迁移到你的业务场景缓存开启 vs 关闭、新旧数据库后端、快速算法 vs 朴素参考实现本质都是多个实现必须行为一致。何时适合使用差分测试结合本文讨论可以总结出差分测试的适用条件必须存在一个可信的参考实现——它不一定要快但必须足够简单、足够可信让它是对的这一前提站得住脚两个实现被期望完全等价——任何输入下结果都必须相同不允许存在语义差异差异应能通过返回值和状态观察到——如果两个实现只有性能差异而没有可观察的行为差异那就不存在可断言的属性不要忽视异常路径——差分测试同样可以断言两个实现在非法输入下抛出相同类型的异常这在迁移后端、替换算法时尤其重要。小结性能优化不应该建立在我觉得没问题之上。当你的代码库中同时存在快的版本和慢但可信的版本时Hypothesis 的差分测试能替你完成最枯燥也最关键的验证工作用随机生成的输入反复对照两个实现的输出并在发现差异时把反例收缩到最小。而一旦对象变成复杂的状态系统规则状态机RuleBasedStateMachine与多实现等价比对可以无缝接管正如 Hypothesis 在自己仓库中用DatabaseComparison验证三种示例数据库实现的一致性那样。掌握这一技巧后缓存层调整、数据库迁移、算法替换这些高风险操作都可以在改动之前先用属性测试织好一张安全网。赞分享测试开发工具【免费下载链接】hypothesisThe property-based testing library for Python项目地址https://gitcode.com/gh_mirrors/hy/hypothesis点击查看免费下载相关推荐GLIM位姿图优化全局一致性保持算法GLIM位姿图优化全局一致性保持算法 引言为什么需要位姿图优化 在SLAMSimultaneous Localization and Mapping同scrcpy 安卓投屏1 分钟镜像出来鼠标键盘直接控手机scrcpy 安卓投屏1 分钟镜像出来鼠标键盘直接控手机 scrcpy 是免费开源的安卓投屏工具把手机画面和声音实时传到电脑同时用电脑的键盘鼠标直接控制测试开发工具Swift Algorithms性能优化算法库底层实现原理与性能测试Swift Algorithms性能优化算法库底层实现原理与性能测试 Swift Algorithms是苹果官方推出的开源算法库为Swift开发提供了强大的开发工具上一篇Triton GE Backend 性能调优方法论面向 NPU 的动态图、静态图与多流并行吞吐优化实战下一篇HDRNet终极指南深度学习如何实现实时图像增强的革命性突破创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考