一、为什么需要自动化测试
2012年我们采用2周迭代开发，每个迭代结束都要测试新版本。纯手工测试的问题：
- 回归测试工作量大——每次改一个功能，要把所有流程重新点一遍，容易遗漏。
- 人员状态影响测试质量——测试人员疲劳时容易漏bug。
- 重复性工作占用大量时间，没时间做探索性测试。
自动化测试的价值：把重复性的回归测试交给机器，测试人员专注于新功能和复杂场景。
二、自动化测试分层
2012年我们按照测试金字塔的思路搭建：
- 单元测试（底层，数量最多）：测试函数、类的逻辑正确性。
- 接口测试（中层）：测试API输入输出是否正确。
- UI自动化测试（顶层，数量最少）：模拟用户操作整个页面流程。
底层单元测试写得快、跑得快、维护成本低。顶层UI测试慢、容易因为页面改版而失效。
三、单元测试实践（PHPUnit）
PHP项目我们使用PHPUnit编写单元测试。
3.1 适合写单测的模块
- 金额计算、日期处理等工具函数。
- 核心业务规则（如折扣计算、权限判断）。
- 数据格式转换。
3.2 不适合写单测的模块
- 直接操作数据库、外部API的代码——需要Mock，复杂度高。
- 简单的CRUD代码——测试价值不高。
2012年我们的单测覆盖率目标是核心模块达到60%以上，不追求100%（成本太高）。
四、Web UI自动化（Selenium）
Selenium可以模拟浏览器操作：打开页面、点击按钮、填写表单、验证结果。
4.1 我们的自动化场景
- 用户登录/登出流程。
- 商品下单完整流程（浏览→加入购物车→提交订单）。
- 后台发布文章流程。
这些都是每次迭代都必须验证的核心流程，手工测试每次要花2-3小时，自动化后10分钟跑完。
4.2 元素定位策略
Selenium通过CSS选择器或XPath定位页面元素。我们规范要求：给关键元素设置id或语义化class，不要用依赖位置的XPath（如//div[2]/div[3]/input），否则页面改版就失效。
五、持续集成初探
2012年我们开始用Hudson（Jenkins前身）做持续集成：
- 代码提交到SVN后自动触发构建。
- 自动运行单元测试。
- 测试不通过时邮件通知开发人员。
这样代码问题在提交后几分钟内就能发现，而不是等到测试阶段才暴露。
六、推行中的挑战
6.1 开发人员不愿意写测试
写单元测试增加开发时间。我们的应对：
- 不从所有项目一刀切开始，先在新项目试点。
- 代码审查时检查测试代码。
- 让开发看到自动化测试减少了自己改bug的时间。
6.2 UI测试不稳定
Selenium测试经常因为页面加载慢、元素未出现而失败。我们的应对：
- 合理设置显式等待时间。
- 测试环境尽量稳定，不随便改页面结构。
- 失败的测试先截图保存，方便排查。
七、效果
推行自动化测试一年后：
- 回归测试时间从每次3天缩短到1天。
- 线上bug率下降约30%。
- 开发人员对自己代码的信心提升——重构后跑一遍测试就知道有没有改坏。
八、总结
自动化测试不是一蹴而就的，也不是所有东西都要自动化。务实的做法是从核心流程开始，逐步积累。2012年我们打下的自动化测试基础，后来成为旭日神州质量保障体系的重要组成部分。
本文关键词：自动化测试,Selenium,PHPUnit,持续集成,测试方法论
相关推荐
方法论 · 2026-08-15
人机协同IT服务方法论：重新定义「AI+人力」外包交付
方法论 · 2026-06-25
行业大模型落地方法论：从通用模型到行业专精的五步路径
方法论 · 2026-04-25