paratest需严格遵循文件命名（test.php结尾）、路径扫描（默认仅tests/）和自动加载配置（--bootstrap=vendor/autoload.php），否则易报“no tests executed”或“class not found”。
Paratest 不是“装了就能快”，它默认不读 phpunit.xml 的 autoload 或 <php></php> 配置，也不自动识别 Laravel/Symfony 的测试基类 —— 这是 90% 的“No tests executed”和“Class not found”错误的根源。
vendor/bin/paratest 提示 No tests executed
这不是命令写错了，而是 Paratest 对文件名、路径、命名空间有硬性要求：
- 测试文件必须以
Test.php结尾（ExampleTest.php✅，example_test.php❌，Example.php❌） - 默认只扫描
tests/目录下符合 PSR-4 命名空间的类，比如Tests\Unit\ExampleTest；tests/Feature/这种 Laravel 风格路径不会被自动发现 - 如果测试不在
tests/下，必须显式指定：vendor/bin/paratest --path=tests/Feature - 如果用了自定义测试套件名（如
phpunit.xml里定义了<testsuite name="Feature"></testsuite>），要用--testsuite=Feature
并行运行时报 Class not found
子进程启动时不会复用 PHPUnit 的完整初始化流程，autoload 和框架上下文得手动对齐：
- 必须传
--bootstrap=vendor/autoload.php，否则 Composer 自动加载器不生效 - Laravel 项目还需加
--configuration=phpunit.xml，否则TestCase里的setUp()、数据库迁移等逻辑不会触发 - 所有测试类必须继承一个能被 Composer 自动加载的基类（如
Tests\TestCase），不能靠require_once 'tests/TestCase.php'手动引入 - 若用到
App\Models\User等应用类，确认它们在composer.json的"autoload"段已声明，且执行过composer dump-autoload
如何选进程数 -p 参数
不是越多越好，实际收益取决于测试用例的 I/O 密集度和 CPU 占用比：
- 纯计算型测试（如数据转换、算法验证）：设为 CPU 核心数的 1–1.5 倍较稳，比如 8 核机器用
-p 10 - 含数据库操作的集成测试：通常
-p 2到-p 4反而更快，太多并发会挤爆连接池或触发锁竞争 - CI 环境中建议固定值（如
-p 4），避免因容器分配核数波动导致结果不可复现 - 可先用
vendor/bin/paratest --help | grep -A5 "processes"确认当前版本是否支持--processes别名（部分旧版只认-p）
为什么 phpunit.xml 里的 配置不生效
Paratest 启动的是多个独立的 php 子进程，每个都只加载 --bootstrap 文件，不解析 phpunit.xml 中的 <php></php> 段（比如 <env name="APP_ENV" value="testing"></env>）：
- 环境变量需在命令行显式传入：
APP_ENV=testing vendor/bin/paratest -p 4 - 或改用
--php-options（v7+ 支持）：vendor/bin/paratest --php-options="-d memory_limit=512M" -p 4 - 数据库配置等敏感项，别硬编码进 XML，应通过
.env.testing+vlucas/phpdotenv加载，确保子进程也能读取
最易被忽略的一点：Paratest 不会帮你重跑失败用例 —— 它没有 --filter 或 --order=random 的智能回退机制。一旦某个进程崩溃，整个并行流就停了，得靠 vendor/bin/paratest --verbose 抓出具体是哪个测试类在哪个进程里挂掉，再单独用 phpunit 复现调试。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
