第三届中国 Rust 开发者大会 应用 waPC (rust) 做软件测试工具 Alan poon 潘泳权 大家好！ @rustropy_gaming ruito_89 PhoTto / image / chart Webassembly Procedures Call waPC 协议标准化了本机代码调用 WebAssembly 和 WebAssembly 调用本机代码的通信 (messaging) modified request • 模拟数据规则 • 自动化测试 • https://github.com/wasmmock/ wasm_mock_server • 用 rust 打包所有测试需求 Wasm mock server Why use rust ？ Software testing tool • 模拟数据规则 • 自动化测试 • Company's own protocol • Multiple backend product line with complex upstream • Common testing platform 大公司抓包工具的需求 软件测试工具 • 模拟数据规则 • 自动化测试 • Supports http/https/tcp/websocket(MITM) • Can use rust to construct own protocol

编译期间对生命周期检查确保内 存安全，无 GC 和运行时损耗 01 完善的测试类型支持，包括单元 测试、集成测试、基准测试等 02 03 和文档系统以及 CI/CD 工具的良 好集成 完整的断言系统 异步协程 零成本抽象 强大的测试框架 REPL 命令行客户端 WebUI 面向分析师，提供图模型定义、数据管理、图查询分析、服务状态监控、用户管理能力 免代码，可视化定义实体、 边，设计图模型。

Rainbond KubeSphere KubeVela 面向资源管理的运维工具集 面向开发者，需结合 CI/CD 工具额外 搭建全流程能力 专门面向开发者的生产力平台，涵盖需求到开 发，测试，运维的云原生一体化技术底座支撑 云厂商 DevOps 平台 华为云 DevCloud 阿里云效 腾讯 CODING 云厂商引流为主，锁定风险高 对多云跨地域支持不够 实施负担较重难以推广 Zadig 核心特性： 运维 真正意义的持续交付：以工程师体验为核心，价值交付为理念，完成需求到发布的全路径。 测试 发布 洞察 一堆复杂脚本、维护成本极高 员工手工操作费时费力易出错 手动更新服务、手动打包、交付 付效率低下、占据大量研发时间 、研发利用率极低 环境不透明、测试效率低下、测 试有效性低、大量手工、价值难 以体现 上下游烟囱式、协作效率低、团 队花大量时间在碎片化沟通和流 碎片化：手工协作 + 复杂工具链 工程化：一个平台 一键发布 工作流、环境配置自动更新、高 效调试、消除手工操作、精准快 速迭代、研发生产力 / 幸福感提 升 自助运行、系统化管理、自动化 程度高、测试有效性提升、质量 有保障、横向赋能、技能提升 随时调用工程基线提供的能力、 产品视角开发交付、团队高效协 同、稳定迭代 产研数字化过程数据透明、关键 指标易抽取、有能力合理调动资 源、随时决策响应客户需求

架构 开发 测试 运维 运维 / 开发 技术支持 事件 需求设计 架构设计 拆任务、写代码 代码集成 xN 单元测试验证 xN 代码扫描 xN 自测、联调 xN 集成验证 xN 写测试用例 系统验证 xN 自动化测试 xN 性能测试 xN 安全测试 xN 数据变更 xN 代码变更 xN 配置变更 xN 部署测试环境 xN 小时 服务一：设计 | 代码编写 | 构建 | 测试 | 部署 | 发布 服务二：设计 | 代码编写 | 构建 | 测试 | 部署 | 发布 服务三：设计 | 代码编写 | 构建 | 测试 | 部署 | 发布 以前：面向代码片段的串行交付 现在：面向多个服务编排的产品级自动化并行交付 | 构建 | 部署 | 测试 | 发布 服务二： 服务定义 | 构建 | 部署 | 测试 | 发布 服务三： 服务定义 | 构建 | 部署 | 测试 | 发布 代码一： 代码编写 | 构建 | 部署 | 测试 | 发布 代码二： 代码编写

无分支编程 Branchless Programming by 彭于斌（ @archibate ） 两种代码写法：分支 vs 三目运算符 两种使用方式：排序 vs 不排序 测试结果（均为 gcc -O3 ） 测试结果可视化 图表比较：分支 vs 无分支 分支 无分支 0 0.01 0.02 0.03 耗时（越低越好） 乱序 有序 • 传统的分支方法实现的 uppercase 255) 不同写法的性能测试 • ifelse_clamp 带 if-else 分支的原始版本。 • bailan_clamp 用摆烂的态度坐等编译器优化。 • addmul_clamp 用“妙用加减乘”的方法优化。 • 我们照常编写了测试用例，禁止内联优化，同样 生成 10^7 个随机数（ -512 到 512 区间）。 • 为什么采用需要三个分支的 clamp 做测试？ • 优化级别在 if-else ，编译器往往会自动检测到可以优化，帮你 应用“妙用加减乘”了，无法体现手动优化的意义。 不同写法的性能测试 • 我们照常编写了测试用例，禁止内联优化，同样生成 10^7 个随机数（ -512 到 512 区间）。 • 至于为什么采用需要三个分支的 clamp 做测试？ • 优化级别在 -O1 以上时，对于只有两个分支的 if- else ，编译器往往会自动检测到可以优化，帮你应用

因此带宽是 31198 MB/s 。 • 和理论带宽 42672 MB/s 相差不多，符合我的预期 。 第 2 章：缓存与局域性 针对不同数据量大小的带宽测试 • 我们试试看 a 不同的大小，对带宽有什么影响。 针对不同数据量大小的带宽测试（续） • 可见数据量较小时，实际带宽甚至超过了 理论带宽极限 42672 MB/s ！ • 而数据量足够大时， 才回落到正常的带宽 。 • 这是为什么？ 的 a[i] 写回主内存。 • 这种代码在主内存看来， CPU 做的事情相当于：读 + 写，从而 每个元素只需要访问两遍内存。对这种完全 mem-bound 的程 序而言就是加速了 2 倍。 测试结果 可见，能否很好的利用缓存，和程序访问内存的时间局域性有关。 案例：一维 jacobi 迭代 • 一些物理仿真中，常用到这种形式的迭代法： • for (i=0...n) b[i] = a[i 就没问题，因为他们是静态大小，编译器可 以检测到并自动扁平化，转换成乘法和加法来计算地址。 今日乳 Ja (1/1) 有一种病 ~ 叫 JavaBean~ 为什么二级指针是低效的存储和索引方式 随机访问性能测试 内存分配性能测试 二维数组：行主序与列主序 • 实际上二维数组的扁平化分为两种方法，行主序与列主序。 • （以下符号约定： i 行号， j 列号； n 行数， m 列数） • C/C++ 编译器把静态数组

可见，并行后虽然降低了时间复杂度，但是以提升工作复杂度为代价！ 更多细节，敬请期待 GPU 专题，我们会以 CUDA 为例详细探讨两全方案。 封装好了： parallel_scan 第 3 章：性能测试 案例： map 与 reduce 的组合 测试所花费时间： tbb::tick_count::now() 并行和串行的速度比较 如何评价 • 公式：加速比 = 串行用时 ÷ 并行用时 • 理想加速比应该是核心的数量。 ，需要做大量数学运算，因此瓶颈在 ALU 。 • 这里卖个关子，欲知后事如何，请待下集揭晓！ 更专业的性能测试框架： Google benchmark • 手动计算时间差有点太硬核了，而且只运 行一次的结果可能不准确，最好是多次运 行取平均值才行。 • 因此可以利用谷歌提供的这个框架。 • 只需将你要测试的代码放在他的 • for (auto _: bm) • 里面即可。他会自动决定要重复多少次， 保证结果是准确的，同时不浪费太多时间 。 运行结果 刚才的 BENCHMARK_MAIN 自动生成了一个 main 函数 ，从而生成一个可执行文件供你运行。运行后会得到测试 的结果打印在终端上。 命令行参数 他还接受一些命令行参数来控制测试的输出格式为 csv 等等，你可以调用 --help 查看更多用法。 CMake 中使用： find_package CMake 中使用：作为子模块 这个什么“勾勾”公司非要默认开启

• 优化 if err != nil • Panic 不是错误处理 错误处理：保守与创新 Part8 – 编程实践：测试、调试与性能剖析 践行哲学，遵循惯例，认清本质，理解原理 • Go 测试惯例与组织形式 • 模糊测试 (fuzzing test) • 性能基准测试、度量数据与 pprof 剖析 • 调试实践 聚焦编码之外的 Go 工具链使用实践 Part9 – 标准库、反射与

支持高效的分布式查询 - Tokio Preemption - Future Cancellation Rust 生产实践 生产实践 – Tokio 为什么使用 Tokio ？ 1. 业界使用最广泛，测试齐全。 2. Tokio 支持 async/await ，提供了高效的异步锁、异步队列等。 3. Tokio 社区支持好。 生产实践 – Tokio Rust future preemption ption 2. https://www.influxdata.com/blog/using-rustlangs-async-tokio-runtime- for-cpu-bound-tasks/ 测试源码： https://github.com/chunshao90/tokio-preemption However, this kind of swapping can only happen

便于存储在传统容器； AOSOA 两者得兼！是王鑫磊的最 爱。 缺点：需要两层 for 循环，不利于随机访 问；需要数组大小是 4 的整数倍，不过 可以用边界特判法解决。 测试一下加速了多少倍？ 优化前： 优化后： 测试结果 SOA + unroll 的方案，比优化前快了 5 倍 ！ 并行情况下最快的也是 SOA 。 单线程的 SOA + unroll 甚至略微超过了并 行版的 AOS