专项测试：90%测试工程师都忽略的领域

做了几年测试，我发现一个残酷的事实：90%的测试工程师只会功能测试。需求评审看一眼，写几个用例，点一点界面，pass了就完事。然后上线那天，性能崩了、安全漏洞了、兼容性炸了——锅全甩给测试。

这篇文章，我想聊聊"专项测试"这个被严重低估的领域。

---

一、先说人话：什么是专项测试？

专项测试就是"功能之外的测试"。

功能测试验的是"对不对"——用户点下单，能不能下单成功。

专项测试验的是"好不好"——1000个人同时点下单，系统扛不扛得住？换个浏览器还能不能用？黑客能不能绕过你的支付逻辑？

一句话：功能测试是及格线，专项测试是天花板。

---

二、专项测试有哪些？

我接触最多的专项测试就这几类：

1. 性能测试——系统能扛多少人？

这是我最早接触的专项测试。当时测一个系统，领导说"要支持500并发"。我用JMeter一压，好家伙，200并发就开始超时了。

性能测试核心指标：

• 响应时间：用户点一下，多久出结果？超过3秒就有人骂了
• 吞吐量：系统每秒能处理多少请求？
• 并发数：同时能扛多少用户？
• 资源占用：CPU、内存、磁盘IO是不是快爆了？

踩过的坑： 性能测试环境和生产环境配置不一样，测出来的数据完全没参考价值。后来学乖了，必须拿接近生产的环境测。

2. 安全测试——黑客能不能搞你？

这个我做得不多，但见过教训。有项目上线后，安全团队用SQL注入直接把数据库拖出来了，整个团队脸都绿了。

常见的安全漏洞：

• SQL注入：通过输入恶意SQL语句，偷取或篡改数据库
• XSS攻击：在页面注入恶意脚本，窃取用户信息
• 越权访问：普通用户能访问管理员接口
• 敏感信息泄露：接口返回了密码、身份证号等不该返回的数据

我的经验： 安全测试不需要你变成黑客，但至少得会用Burp Suite抓包改参数，会用sqlmap跑一下注入。

3. 兼容性测试——换个环境还能用吗？

做Web项目最头疼的就是这个。Chrome上好好的，Safari上样式乱了；PC上没问题，手机上按钮点不到。

兼容性测试维度：

• 浏览器：Chrome、Safari、Firefox、Edge、微信内置浏览器
• 操作系统：Windows、macOS、iOS、Android
• 分辨率：1920×1080、1366×768、手机竖屏
• 网络环境：WiFi、4G、弱网、断网重连

踩过的坑： 微信内置浏览器是个奇葩，很多CSS特性不支持，必须单独测。

4. 弱网测试——网络差的时候会怎样？

这个很多测试根本没想过。但实际用户场景里，地铁上、电梯里、偏远地区，网络差得很。

弱网测试关注点：

• 请求超时了有没有友好提示？
• 断网后重连，数据会不会丢失？
• 图片加载不出来，有没有占位图？
• 表单提交到一半断网了，恢复后能不能继续？

我的做法： 用Chrome DevTools的Network面板，限速到Slow 3G，然后体验一遍核心流程。

5. 稳定性测试——跑久了会不会出问题？

有些bug只有跑够长时间才会暴露。比如内存泄漏，刚启动没问题，跑了一天内存占满了，系统挂了。

稳定性测试方法：

• 核心场景持续跑72小时以上
• 监控内存、CPU、磁盘使用趋势
• 观察日志里有没有异常堆积

---

三、专项测试的"反常识"认知

做了几年测试，我总结出几个跟直觉相反的结论：

1. 不是所有项目都需要所有专项测试

很多测试一听到"专项测试"就觉得要把性能、安全、兼容性、弱网、稳定性全做一遍。其实没必要。

小型内部系统：功能测试 + 基础兼容性就够了

面向C端的产品：性能 + 兼容性 + 弱网是刚需

金融/政务系统：安全测试必须做，而且要专业团队做

关键是评估风险，不是堆测试类型。

2. 专项测试不是测试工程师一个人的事

性能测试需要开发配合调优，安全测试需要专业工具和知识，兼容性测试需要产品定义"支持哪些环境"。

专项测试是团队协作，不是测试背锅。

3. 自动化不等于专项测试

很多人觉得"我写了UI自动化脚本"就是在做专项测试。其实自动化只是手段，不是目的。

自动化能提高效率，但不能替代测试设计。 你得先知道测什么、怎么测，再考虑用什么工具。

4. 接口自动化≠专项测试

这个误解更普遍。很多测试同学觉得"我会写接口自动化脚本，所以我擅长专项测试"。这是两码事。

先搞清楚三个维度：

| 概念 | 本质 | 举例 |

|------|------|------|

| 接口测试 | 测什么（测试对象） | 验证登录接口返回的字段对不对 |

| 自动化 | 怎么测（测试手段） | 用脚本代替手工执行 |

| 专项测试 | 测哪方面（质量属性） | 性能、安全、兼容性、弱网 |

三者是不同维度，可以组合：

• 接口 + 手工 = 功能回归
• 接口 + 自动化 = 自动化回归（本质还是功能测试）
• 接口 + 性能 = 性能专项（JMeter压接口）
• 接口 + 安全 = 安全专项（SQL注入、越权测试）

一句话：接口自动化是"用脚本跑功能测试"，本质还是功能测试，只是效率更高。

真正的专项测试，关注的不是"接口返回了什么"，而是"接口在极端条件下表现如何"——扛不扛得住并发、有没有安全漏洞、弱网下会不会超时。

---

四、转型AI后的思考

后来我开始转型做AI相关开发，反而更理解专项测试的价值了。

AI应用的专项测试更难：

• 性能测试：大模型推理慢，怎么优化响应时间？
• 稳定性测试：AI输出有随机性，同样的输入可能得到不同的输出，怎么验证稳定性？
• 安全测试：Prompt注入、数据投毒、模型越狱，传统安全测试根本覆盖不到

我现在的认知： 专项测试不是"锦上添花"，而是"保命底线"。功能测试保证"能用"，专项测试保证"敢用"。

---

五、新手怎么入门专项测试？

如果你是测试新人，我的建议：

第一步：先把功能测试做扎实。 连需求都理解不透，谈什么专项测试都是空中楼阁。

第二步：选一个方向深入。 性能测试入门门槛最低（JMeter免费），安全测试最有前途（人才稀缺），兼容性测试最容易出成果（立竿见影）。

第三步：在项目中实践。 别光看理论，找个项目压一下、注入一下、换个浏览器测一下，踩过坑才能真正理解。

第四步：积累工具链。 JMeter、Postman、Burp Suite、Lighthouse、BrowserStack……工具不用全会，但得知道什么时候用什么。

---

写在最后

测试工程师的核心竞争力不是"会用什么工具"，而是"能发现什么风险"。

功能测试是基本功，但只做功能测试的测试工程师，迟早会被替代。AI能写测试用例，能跑自动化脚本，但它判断不了"这个系统上线后会不会崩"。

专项测试的价值，在于它需要经验和判断力——这恰恰是AI短期内替代不了的。

所以，如果你还在测试岗位，别只埋头写用例。抬头看看性能、安全、兼容性这些领域，那里才有你的护城河。

如果你也在考虑转型，专项测试的经验会是你最值钱的资产之一——因为它训练的是"风险嗅觉"，这东西AI学不会。

---

本文是"肖恩的博客"系列文章之一，首发于 seanwalter.top