ExtJS 6 SPA应用：Selenium运行ExtJS代码与API测试的优劣对比

作为长期和ExtJS 6 SPA以及Selenium打交道的老测试，我来给你拆解下这两种测试方式的优劣——毕竟我在这类项目上踩过的坑，说出来能当反面教材了😅

一、通过Selenium WebDriver运行ExtJS代码测试 #

优点 #

• 精准定位，告别DOM烦恼：ExtJS的ComponentQuery简直是救星！不用再跟动态生成的ext-comp-xxxx ID或者嵌套十几层的DOM结构死磕，直接用组件的属性定位，比如Ext.ComponentQuery.query('form[itemId="userForm"]')[0]，不管DOM怎么变，只要组件配置没错，就能精准拿到目标。
• 直接操作组件，效率拉满：能直接调用ExtJS组件的原生方法，比如要刷新表格，不用模拟点击刷新按钮再等加载，一行grid.getStore().reload()就搞定；判断表单是否合法，直接调用form.isValid()，比用Selenium去挨个检查输入框的提示靠谱多了，测试步骤大幅简化，运行速度也快。
• 状态判断更准确：ExtJS组件的内部状态（比如是否禁用、是否加载完成），直接通过组件属性就能获取，比如button.isDisabled()，不用靠DOM的class或者样式去猜，避免误判。

缺点 #

• 强依赖ExtJS环境：必须确保页面的ExtJS框架完全加载完成才能执行测试代码，而且测试代码要和ExtJS版本严格兼容——比如ExtJS 6.0和6.5的ComponentQuery语法有细微差异，框架一升级，测试可能集体翻车。
• 调试成本高：测试代码是在浏览器的ExtJS上下文里运行，Selenium只是个“传声筒”，一旦测试失败，你得先排查是ExtJS代码写错了，还是Selenium的执行时机有问题，抑或是框架本身的bug，排查链路比普通Selenium测试长很多。
• 团队技能要求高：测试人员不仅要会Selenium，还得熟悉ExtJS的组件API、ComponentQuery语法，甚至要懂一点ExtJS的开发逻辑，新人上手慢，团队培养成本高。

二、使用Selenium原生API开展测试 #

优点 #

• 通用性强，学习成本低：不管是ExtJS、Vue还是React应用，Selenium的click()、sendKeys()这些API都能用，测试人员不用专门去啃ExtJS的文档，只要掌握基础的Web自动化测试技能就行，团队复用性好，新人也能快速上手。
• 贴近真实用户场景：完全模拟用户的操作流程——点击按钮、输入文本、滚动页面，能发现一些ExtJS代码层面覆盖不到的UI交互问题，比如按钮点击后DOM渲染异常、弹窗遮挡等，这类问题用ExtJS代码测试很难发现。
• 调试更友好：Selenium自带的日志、截图、元素定位工具都能直接用，出问题了直接看DOM结构就行，排查思路和普通Web测试一致，门槛低，不用额外学习ExtJS的调试技巧。

缺点 #

• 元素定位噩梦：ExtJS生成的DOM结构极其复杂，很多元素的ID是动态生成的，CSS选择器很容易失效，XPath写起来又长又容易出错，只要页面布局稍微调整，比如组件嵌套层级变了，测试就得跟着改，维护成本极高。
• 测试效率低下：模拟用户操作的步骤多、耗时长——比如要获取表格的行数，得先找到表格的DOM元素，再数里面的<tr>标签，而用ExtJS代码直接grid.getStore().getCount()一秒就能拿到，大型测试套件跑起来会慢很多。
• 状态判断不准确：无法直接获取组件的内部状态，比如要判断表格是否加载完成，只能通过等待某个DOM元素出现，或者看加载动画是否消失，很容易出现“假阳性”——比如加载动画消失了，但数据还没渲染完，导致测试失败。

总结建议 #

如果你们团队有熟悉ExtJS的开发或测试人员，且测试重点是业务逻辑、组件功能正确性，优先选择第一种方法，效率和准确性都更高；如果团队技能偏通用Web测试，或者测试重点是用户交互流程、UI兼容性，那第二种方法更合适。当然，也可以混合使用：核心业务逻辑用ExtJS代码测试，交互流程和UI场景用Selenium API测试，兼顾效率和覆盖范围。

内容的提问来源于stack exchange，提问作者Pinidbest