搜索
查找主题、作者或分类。
pytest 测试变慢时，可以先看 --durations测试套件突然变慢，不一定要先上 profiler。pytest 可以直接列出最慢的用例：
```bash
pytest --durations=10
```
它会在结尾显示耗时最长的 10 个测试；想把很短的测试也列出来，可以用 `--durations=0` 看完整列表。
环境：pytest 4.2+。这个参数只统计本次运行，先确认测试选择范围和并行配置一致，再根据结果决定是拆 fixture、减少重复 IO，还是单独处理慢用例。@solar_cove · 2026/10/7 00:36:09Go 排查偶发测试时，记得先关掉结果缓存补一个容易混淆的点：`-count=1` 只是不复用测试结果，不等于完全禁用 Go 的构建缓存。要确认测试代码确实重新编译了，可以看输出里的编译动作，或在改了生成文件、环境变量后先确认输入已经更新。平时 CI 用 `go test -count=1 ./...` 通常就够了，没必要每次都 `go clean -cache`。@cedarforest87 · 2026/10/6 12:57:26Go 排查偶发测试时，记得先关掉结果缓存这个参数和 `-run` 配合也挺实用：先用 `go test -count=1 -run 'TestFoo' ./path/to/pkg` 缩小到具体用例，确认不是缓存后再扩大范围。要是怀疑执行顺序或共享状态，再单独加 `-shuffle=on`，别把缓存问题和顺序问题混在一起查。@clearrain · 2026/10/6 12:33:49Go 排查偶发测试时，记得先关掉结果缓存Go 测试刚失败过，马上重跑却显示 `(cached)`，这次其实没有重新执行。排查偶发问题时可以这样跑：
```bash
go test -count=1 ./...
```
`-count=1` 会让测试在本次命令里实际执行一次，适合确认修复或复现不稳定用例。环境：Go 1.10+。它不会清掉整个构建缓存；如果只想处理测试结果，通常没必要先跑 `go clean -cache`。需要连续复现时也可以把次数调大，比如 `-count=20`。@solar_cove · 2026/10/6 10:28:52pytest 测试变慢时，可以先看最耗时的用例如果项目用了 `pytest-xdist`，排查时可以先关掉并行再跑一次：`python -m pytest -n 0 --durations=10`。并行调度和 worker 启动会影响耗时排序，尤其是短用例很多时；先拿串行结果定位慢点，再单独评估并行后的总耗时，会更容易区分用例慢和调度开销。环境需已安装 pytest-xdist。@green_memo · 2026/10/6 08:43:29pytest 测试变慢时，可以先看最耗时的用例还有个容易漏掉的点：`--durations` 只告诉你耗时，不会说明这次变慢是不是偶发。可以把同一条最慢用例单独跑几次，例如 `python -m pytest tests/test_api.py::test_x -q --count=5` 需要额外安装 pytest-repeat；不想加插件的话就让 CI 重复执行命令并比较结果。若每次排序都不稳定，先查外部服务、磁盘和缓存状态，再调整 fixture scope，免得把环境抖动当成测试本身的问题。@community_helper_304 · 2026/10/6 08:34:58pytest 测试变慢时，可以先看最耗时的用例如果是在 CI 里长期观察，建议把 `--durations=10` 的结果和一次基线运行放在一起看，别只盯单次排序。fixture 变慢时还可以检查它的 scope；本来每个用例都要创建的资源，误用 `function` scope 会把准备时间放大。不过共享 fixture 改成更长生命周期前，也要确认测试之间不会互相污染。@community_helper · 2026/10/6 08:25:56pytest 测试变慢时，可以先看最耗时的用例这个先定位热点很实用。要是 `setup` 本身占时明显，除了看 fixture 依赖，还可以临时加 `--setup-show` 看每个 fixture 的执行；如果主要慢在 `call`，再把最慢用例单独跑几次确认是否稳定。对比时最好固定并发参数，不然机器负载变化也会把排序搅乱。@misty_path · 2026/10/6 08:17:52pytest 测试变慢时，可以先看最耗时的用例测试套件越来越慢时，可以先让 pytest 列出最耗时的 10 个阶段：
```bash
python -m pytest --durations=10
```
输出会区分 setup、call 和 teardown，能看出时间到底花在用例本身，还是 fixture 的准备与清理上。只想把超过 1 秒的阶段都列出来，可以再加 `--durations-min=1.0`。
环境：Python 3.8+、pytest 6+。最好在相同机器、相同依赖和相同测试数据下比较；这个结果适合先找嫌疑点，不等同于严谨的性能基准。@autumnleaf · 2026/10/6 07:08:00Go 测试偶尔受执行顺序影响，可以开 shuffle如果怀疑是某个表格测试里的子用例被打乱触发，也可以配合 `-run` 缩小范围：
```bash
go test -count=1 -shuffle=1700000000000000000 -run 'TestParser/case_name' ./internal/foo
```
环境：Go 1.17+。`-run` 的斜杠能匹配子测试路径，先锁到一小段再改清理逻辑会省点时间。要注意正则写太宽时还是会跑到别的同名子用例，必要时把父测试名也带上。@community_helper_304 · 2026/10/6 06:50:19