单测、接口自动化、性能压测与移动端测试——各层的工具怎么配。

一、单元与接口测试

Java 单元测试

Java 单元测试通常以 JUnit 为核心，配合 Mockito 隔离外部依赖。测试类应对准一个类的公开行为：给定输入、断言输出和副作用，而不是去验证私有方法的实现细节。

Spring 项目里可用 @SpringBootTest 做切片或全容器测试，但单元层应尽量避开拉起整个上下文，否则套件会又慢又脆。数据库交互用内存库或 Testcontainers，时间、随机数和时钟要可注入。

覆盖率是辅助指标。优先锁住边界条件、异常路径和并发下的幂等。CI 中失败即阻断合并，并把不稳定用例单独隔离，避免团队学会“再跑一次就过”。

TestNG

TestNG 用注解组织测试：@Test、@BeforeMethod、依赖 groups 与 dataProvider。比 JUnit4 更强调套件、并行与失败重跑。testng.xml 可跨 class 编排。软断言 SoftAssert 适合一批校验一起失败。

适合集成测试与接口自动化。并行时注意线程安全的测试夹具。Listener 可对接报告。与 Spring 集成用 AbstractTestNGSpringContextTests。

和 JUnit5 选型：已有 TestNG 生态或需要依赖测试顺序时留；新项目更常见 JUnit5。Maven surefire 要指定 suiteXmlFile。不要把环境初始化放进每个 @Test。

Pytest测试框架

Pytest 是 Python 最常用的测试框架，用约定发现测试、用 fixture 管理前置条件、用插件扩展断言和报告。函数即测试，断言就是普通 assert，失败时会打印比较细节。

fixture 作用域要选对：session 级适合昂贵资源，function 级保证隔离。参数化覆盖边界值。conftest.py 放共享夹具，但不要变成隐形全局状态。标记区分慢测试与单元测试，CI 可以分流。覆盖率插件能看缺口，但不要为了数字写空测试。和 hypothesis、factory 组合可生成数据。保持测试可独立运行，顺序依赖是维护噩梦。

Selenium自动化测试框架

Selenium 通过 WebDriver 驱动浏览器模拟用户操作，是 Web 自动化测试的经典方案。测试代码发送标准协议，由浏览器驱动执行点击、输入和导航。它适合回归关键路径，而不是替代接口测试。

稳定用例要等元素可交互，而不是固定 sleep。定位优先用稳定的 data-testid，少用易变 XPath。并行跑要注意浏览器版本与驱动匹配。页面异步多时，显式等待比隐式等待更清晰。CI 里用无头模式并保存失败截图。能在 API 层断言的就不要走 UI，把 Selenium 留给真正的端到端场景，才能控制维护成本。

二、端到端与性能

Playwright自动化测试工具

Playwright 是微软的浏览器自动化工具，默认支持 Chromium、Firefox 和 WebKit，带自动等待、追踪和 codegen。相较 Selenium，它对现代前端的等待模型更省心，适合做可靠的端到端测试。

用例应走 page 对象或固定的 locator，避免复制粘贴选择器。trace 能回放失败现场，比只看截图更有用。鉴权可复用 storageState，不必每个测试重新登录。并行时隔离浏览器上下文。组件测试和 API 测试可以搭配，不必所有东西都点 UI。CI 安装浏览器依赖要固定版本。选择它还是 Cypress，看多浏览器需求和语言生态。

Locust

Locust 用 Python 写压测用户行为，gevent 模拟并发。定义 HttpUser 与 task 权重，Web UI 看 RPS 与百分位延迟。可分布式：master 调度，worker 发压。

适合接口与混合场景，不如 JMeter GUI 点选，但代码即场景更易进 Git。注意客户端本机成为瓶颈时要加 worker。断言失败率与响应时间一起看。

和环境隔离：压测数据不要污染生产。逐步加压找拐点。与 Grafana 对接看系统侧 CPU/GC。HTTP/2、长连接要按真实客户端建模。密钥放环境变量。

三、移动端测试

Android Instrumented Test 仪表测试

Instrumented Test 运行在真机或模拟器上，通过 instrumentation 注入应用进程，能访问 Android 框架 API。它和本地 JVM 单测相对：后者快但不碰系统服务，前者慢但能验证权限、数据库和 UI。

工程上放在 androidTest，用 AndroidJUnitRunner 启动。涉及文件系统或 ContentProvider 时注意隔离，避免污染被测应用数据。CI 上优先用模拟器矩阵，真机留给兼容性抽样。Flaky 的根因多半是时机与环境，而不是断言写错。能用 Robolectric 或纯单测解决的，就不要上仪表测试，把有限的设备时间留给关键集成场景。

Appium 移动APP自动化测试工具

Appium 用 WebDriver 协议驱动 iOS 和 Android，脚本可写 Python、Java 或 JS。它不改应用源码，靠辅助功能树找控件。适合回归冒烟和跨端同一套用例。定位策略优先稳定的 content-desc 或 resource-id，坐标点击最脆。会话要管理安装、权限和重置。

真机与模拟器差异大，CI 用云真机要注意并发和配额。等待用显式等待，不要 sleep 满天飞。与业务测试数据隔离。失败截图和页源要归档。Appium 慢于白盒单元测试，不要用它测所有逻辑。分层：单元测规则，Appium 测关键用户路径。维护定位器的成本，往往比写第一版脚本更高。

Android Espresso测试

Espresso 是 Android 官方 UI 测试框架，核心 API 是 onView(matcher).perform().check()。它与主线程空闲同步，减少 sleep 等待。适合验证点击、输入、列表滚动等用户可见路径。

稳定用例的关键是写好 Matcher：用资源 id 而不是脆弱的文案；异步数据要用 IdlingResource 告诉 Espresso 何时空闲。动画、系统弹窗和 WebView 是常见不稳定来源。测试应跑在独立的 androidTest 源集，不依赖生产环境账号。能单测覆盖的逻辑不要堆到 Espresso，端到端只保留关键路径，否则 CI 会又慢又脆。

Android CAT测试-兼容性测试

Android CAT 兼容性测试验证应用在不同系统版本、厂商 ROM、屏幕和传感器上的行为。覆盖安装卸载、权限、后台限制、深色模式、刘海、字体缩放和推送通道。厂商对后台和自启动的策略差异最大，兼容问题往往出在这里而不是 API 本身。测试矩阵要按用户份额取机型，而不是贪多。

自动化可用云真机跑冒烟，深度场景仍要人工。关注 targetSdk 升级后的行为变更。崩溃按机型聚合，不要只看总量。新系统版本预览期就要跟 CTS 和官方行为变更清单。兼容性不是测完一次就结束，每次系统大版本和依赖升级都要回归。把已知 ROM 限制写进适配说明，客服和研发才对得上用户描述。

四、方法论

什么是测试驱动开发？TDD

测试驱动开发（TDD）按红绿重构循环：先写失败测试，再写刚好让它通过的代码，最后整理结构。它把可测试性提前，接口设计往往比事后补测更干净。

适用单元级规则和纯逻辑；对 UI 和分布式时序不要机械套用。测试应描述行为而不是实现细节，否则重构会被测试锁死。速度要快，慢测试会让循环名存实亡。

落地指标看缺陷逃逸和回归信心，而不是覆盖率数字。结对时一人写测试一人写实现，能减少自欺欺人的“先写代码再补一个必过用例”。

软件测试：灰度测试

灰度测试把新版本先放到一小部分真实流量上观察，而不是实验室全部通过就全量。它验证的是真实用户路径、数据和网络差异，能提前暴露配置、兼容性和性能问题。

常见切分维度包括用户 ID 哈希、地域、客户端版本和内部员工名单。关键是对照实验：灰度组和对照组要用同一套指标看转化、错误率和延迟，避免季节波动被当成版本效果。

测试计划要预先写好回滚条件和观察窗口。没有自动回滚和日志采样，灰度只是把风险从发布会挪到了用户身上。