本文探讨了selenium测试套件中，当涉及websocket服务器时，单个测试用例成功但批量运行失败的问题。核心原因在于websocket服务器实例在每次测试结束后未能正确关闭，导致端口被占用。教程将详细分析问题根源，并提供在测试清理阶段（`@aftereach`）优雅关闭websocket服务器的解决方案，确保测试环境的隔离性和稳定性。
问题描述
在使用Selenium对包含WebSocket通信的Web应用进行自动化测试时，开发者可能会遇到一个常见且令人困惑的现象：当单独运行每个测试用例时，它们都能顺利通过；然而，一旦将这些测试用例组合成一个测试套件并批量执行时，除了第一个测试用例外，后续的测试用例往往会失败，并抛出 org.openqa.selenium.ElementNotInteractableException 异常，或表现为页面元素未能正确加载。
在给定的场景中，测试环境包括一个HTML客户端页面和一个Java实现的WebSocket服务器，两者通过端口8800进行通信。Selenium测试在 BeforeEach 方法中启动Chrome浏览器和WebSocket服务器，并在 AfterEach 方法中关闭浏览器。当批量运行测试时，观察到只有第一个测试用例的服务器会打印 "Server started!" 信息，而后续测试用例则没有，这强烈暗示了服务器启动失败。
根本原因分析
问题的核心在于测试用例之间的资源隔离性不足，特别是WebSocket服务器的生命周期管理不当。
- 服务器未关闭： 在 BeforeEach 方法中，每个测试用例都会尝试启动一个新的WebSocket服务器实例。然而，在 AfterEach 方法中，只执行了 driver1.quit() 来关闭浏览器实例，而没有对之前启动的WebSocket服务器实例进行停止操作。
- 端口占用： Java进程中的WebSocket服务器一旦启动，就会绑定到指定的端口（例如8800）。如果前一个测试用例的服务器没有被显式关闭，那么该端口将继续被占用。当下一个测试用例尝试在相同的端口上启动新的WebSocket服务器时，由于端口已被占用，新的服务器实例将无法成功启动。
- 测试环境不一致： 服务器启动失败导致后续测试用例的Web页面无法与WebSocket服务器建立连接。客户端页面中的JavaScript代码（如 new WebSocket("ws://localhost:8800")）将无法成功连接，进而影响页面元素的加载和交互行为。例如，示例中的 startButton 按钮可能依赖于WebSocket连接状态才能显示或变得可交互，连接失败自然会导致 ElementNotInteractableException。
- 进程内生命周期： 由于所有测试用例都在同一个Java进程中运行，即使一个测试用例完成，其创建的服务器实例也不会自动终止，除非显式调用其停止方法。
通过复制HTML页面和使用不同端口（例如8802）进行测试，发现问题得以解决，这进一步证实了端口占用是问题的根本原因。
解决方案
解决此问题的关键在于确保每个测试用例完成后，其启动的WebSocket服务器实例都能被正确地关闭，从而释放占用的端口资源。这可以通过在JUnit的 @AfterEach 方法中添加服务器关闭逻辑来实现。
1. 修改服务器类
确保你的WebSocket服务器类（如示例中的 Server 类）提供了公共的关闭方法。org.java_websocket.server.WebSocketServer 类本身就提供了 stop() 方法，可以直接调用。
import org.java_websocket.WebSocket;
import org.java_websocket.handshake.ClientHandshake;
import org.java_websocket.server.WebSocketServer;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.util.*;
public class Server extends WebSocketServer {
public Server(int port) {
super(new InetSocketAddress(port));
}
@Override
public void onStart() {
System.out.println("Server started!");
setConnectionLostTimeout(0);
setConnectionLostTimeout(500);
}
// 其他方法...
@Override
public void onOpen(WebSocket conn, ClientHandshake handshake) {
System.out.println(conn.getRemoteSocketAddress().getAddress().getHostAddress() + " entered the room!");
}
@Override
public void onClose(WebSocket conn, int code, String reason, boolean remote) {
System.out.println(conn + " has left the room!");
}
@Override
public void onMessage(WebSocket conn, String message) {
System.out.println(conn + ": " + message);
// 处理消息逻辑
}
@Override
public void onError(WebSocket conn, Exception ex) {
ex.printStackTrace();
if (conn != null) {
// some errors like port binding failed may not be assignable to a specific websocket
}
}
}2. 修改测试配置类
在 Test 类中的 @AfterEach 方法中，除了关闭浏览器实例外，还需要调用WebSocket服务器的 stop() 方法。
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.*;
import org.openqa.selenium.chrome.ChromeDriver;
import io.github.bonigarcia.wdm.WebDriverManager;
import java.nio.file.Path;
import java.nio.file.Paths;
import static org.junit.jupiter.api.Assertions.*;
public class MySeleniumWebSocketTest { // 建议使用更具描述性的类名
WebDriver driver1;
String path = "path/web.html"; // 请替换为实际的HTML文件路径
Path sampleFile;
Server server; // WebSocket服务器实例
JavascriptExecutor js1;
@BeforeAll
static void setupClass() {
WebDriverManager.chromedriver().setup();
}
@BeforeEach
void setup() throws InterruptedException, IOException { // stop() 方法可能抛出 IOException
driver1 = new ChromeDriver();
js1 = (JavascriptExecutor) driver1;
sampleFile = Paths.get(path);
// 启动WebSocket服务器
server = new Server(8800);
server.start();
// 确保服务器有足够时间启动并绑定端口
Thread.sleep(500); // 短暂等待，确保服务器完全启动
}
@AfterEach
void teardown() throws InterruptedException {
// 关闭浏览器实例
if (driver1 != null) {
driver1.quit();
}
// 关闭WebSocket服务器实例
if (server != null) {
try {
server.stop();
// 确保服务器有足够时间关闭并释放端口
Thread.sleep(500); // 短暂等待，确保端口被释放
} catch (IOException e) {
System.err.println("Error stopping WebSocket server: " + e.getMessage());
e.printStackTrace();
}
}
}
@Test
void testCaseOne() throws InterruptedException {
driver1.get(sampleFile.toUri().toString());
// 确保WebSocket连接已建立
// 可以通过JS执行判断WebSocket状态，或等待特定元素出现
// 例如：等待按钮可见并可点击
WebElement startButton = driver1.findElement(By.id("startButton"));
WebDriverWait wait = new WebDriverWait(driver1, Duration.ofSeconds(10));
wait.until(ExpectedConditions.elementToBeClickable(startButton));
startButton.click();
// 其他操作
// assertEquals(2, server.getNextPlayer()); // 假设 server 有 getNextPlayer 方法
}
@Test
void testCaseTwo() throws InterruptedException {
driver1.get(sampleFile.toUri().toString());
// 确保WebSocket连接已建立
WebElement startButton = driver1.findElement(By.id("startButton"));
WebDriverWait wait = new WebDriverWait(driver1, Duration.ofSeconds(10));
wait.until(ExpectedConditions.elementToBeClickable(startButton));
startButton.click();
// 其他操作
}
}代码解释：
- server.stop(): 这是关键的改动。在 AfterEach 方法中调用 server.stop() 会优雅地关闭WebSocket服务器，释放占用的端口。
- Thread.sleep(500): 在 server.start() 之后和 server.stop() 之后添加短暂的等待，是为了给服务器足够的时间来完成启动和关闭操作。虽然 start() 是非阻塞的，但服务器绑定端口需要一点时间。同样，stop() 也需要时间来关闭所有连接并释放端口。在生产级代码中，可以考虑使用更健壮的等待机制，例如等待服务器的特定状态或使用Latch。
- 异常处理： server.stop() 可能会抛出 IOException 或 InterruptedException，因此需要进行适当的异常处理。
- WebDriverWait: 为了提高测试的稳定性，建议使用 WebDriverWait 显式等待元素变为可交互状态，而不是简单地 Thread.sleep()。这可以更好地处理页面加载和WebSocket连接的异步性。
注意事项
- 资源管理最佳实践： 任何在测试设置阶段 (@BeforeEach, @BeforeAll) 初始化的资源（如浏览器实例、数据库连接、模拟服务、外部服务器等）都应在测试清理阶段 (@AfterEach, @AfterAll) 得到妥善释放。这是确保测试隔离性和避免资源泄漏的关键。
- 异步操作的等待： WebSocket连接是异步的。在测试中，不要假设页面加载后WebSocket连接就立即可用。应使用显式等待机制（如 WebDriverWait 结合 ExpectedConditions）来等待WebSocket连接建立完成或依赖WebSocket状态的UI元素变为可交互状态。
- 错误日志： 确保服务器的 onError 方法能够捕获并记录错误，这对于调试服务器启动或连接问题至关重要。
- 端口可用性检查： 在某些复杂场景下，如果端口释放仍然存在问题，可以考虑在 BeforeEach 中添加一个端口可用性检查逻辑，或者动态分配端口以避免冲突。然而，对于大多数情况，正确的 stop() 调用足以解决问题。
- 测试隔离性： 每个测试用例都应该能够独立运行，并且其结果不应受其他测试用例的影响。通过正确管理外部资源（如WebSocket服务器），可以确保测试环境的清洁和一致性。
总结
在Selenium自动化测试中集成WebSocket服务时，确保测试套件的稳定性和可靠性至关重要。本文通过分析WebSocket服务器未正确关闭导致端口占用的问题，提供了一个清晰的解决方案：在JUnit的 @AfterEach 生命周期方法中显式调用WebSocket服务器的 stop() 方法。遵循这一最佳实践，结合适当的异步等待机制，可以有效解决测试用例批量运行时遇到的端口冲突和 ElementNotInteractableException 等问题，从而构建出更加健壮和可维护的自动化测试套件。
