在selenium测试websocket应用的场景中，当多个测试用例并发执行时，可能会出现独立测试通过但批量执行失败的情况。这通常是由于websocket服务器实例在测试之间未正确关闭，导致端口被占用而无法为后续测试启动新的服务器。本文将深入分析此问题，并提供通过在测试清理阶段确保服务器资源释放的解决方案，以实现稳定可靠的自动化测试。
问题现象：Selenium测试WebSocket应用时的并发挑战
在使用Selenium对基于WebSocket的Web应用进行自动化测试时，开发者可能会遇到一个令人困惑的现象：单个测试用例（例如row41()）能够成功执行并验证预期行为，但当多个测试用例（如row41()和row42()）同时运行在一个测试套件中时，除了第一个测试用例外，后续的测试用例会失败。常见的错误信息是org.openqa.selenium.ElementNotInteractableException: element not interactable，这通常意味着页面上的元素（如“startButton”）未能正确加载或变得可交互。进一步观察发现，在并发执行时，只有第一个测试用例的WebSocket服务器会成功启动并打印“Server started!”，而后续测试用例对应的服务器则没有启动日志。这暗示了资源冲突的存在。
根本原因分析：资源未释放导致的端口冲突
此问题的核心在于WebSocket服务器实例的生命周期管理不当。在提供的测试配置中，每个测试用例都会在@BeforeEach方法中启动一个新的Server实例，并使其监听在固定的8800端口。然而，在@AfterEach方法中，虽然Selenium WebDriver（driver1）被正确关闭，但对应的WebSocket服务器实例（server）却没有被显式地停止或关闭。
当测试用例独立运行时，前一个测试完成后，JVM可能在短时间内释放了所有资源，包括被占用的端口，使得下一个独立运行的测试能够成功启动新的服务器。但当多个测试用例在同一个JVM进程中连续执行时，前一个测试用例的Server实例可能仍然在后台运行，或者操作系统尚未完全释放其占用的8800端口。当第二个测试用例尝试在@BeforeEach中启动一个新的Server实例并监听同一端口时，就会因为端口已被占用而失败。WebSocket服务器未能成功启动，导致客户端页面无法建立连接，进而使得依赖于WebSocket连接的页面元素（如startButton）无法进入预期状态，最终引发Selenium的ElementNotInteractableException。
解决方案：确保WebSocket服务器的正确关闭
要解决这个问题，关键是在每个测试用例执行完毕后，显式地停止WebSocket服务器并释放其占用的端口。这可以通过在@AfterEach方法中调用WebSocket服务器的关闭方法来实现。对于org.java_websocket.server.WebSocketServer，其关闭方法通常是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 MyWebSocketTest { // Renamed Test to MyWebSocketTest to avoid conflict
WebDriver driver1;
String path = "path/web.html"; // 确保路径正确
Path sampleFile;
Server server; // WebSocket服务器实例
JavascriptExecutor js1;
@BeforeAll
static void setupClass() {
WebDriverManager.chromedriver().setup();
}
@BeforeEach
void setup() throws InterruptedException {
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 {
// 关闭Selenium WebDriver
if (driver1 != null) {
driver1.quit();
}
// 停止WebSocket服务器并释放端口
if (server != null) {
try {
server.stop();
// 给予操作系统一些时间来释放端口
Thread.sleep(500);
} catch (IOException | InterruptedException e) {
System.err.println("Error stopping WebSocket server: " + e.getMessage());
Thread.currentThread().interrupt(); // 重新中断当前线程
}
}
}
@Test
void testCaseOne() throws InterruptedException {
driver1.get(sampleFile.toUri().toString());
// 确保页面加载完成，并且WebSocket连接已建立
// 可以添加显式等待，例如等待某个元素可见或JavaScript变量就绪
WebDriverWait wait = new WebDriverWait(driver1, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("startButton")));
driver1.findElement(By.id("startButton")).click();
// 模拟其他操作
// assertEquals(2, server.getNextPlayer()); // 假设getNextPlayer方法存在
}
@Test
void testCaseTwo() throws InterruptedException {
driver1.get(sampleFile.toUri().toString());
// 确保页面加载完成，并且WebSocket连接已建立
WebDriverWait wait = new WebDriverWait(driver1, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("startButton")));
driver1.findElement(By.id("startButton")).click();
// 模拟其他操作
}
}关键改进点：
- server.stop(): 在@AfterEach方法中添加server.stop()，确保每个测试用例结束后WebSocket服务器都被正确关闭。
- 延迟等待: 在server.start()和server.stop()之后都添加了Thread.sleep(500)。虽然Thread.sleep不是最佳实践，但在测试环境中可以作为一种快速解决端口释放时间问题的手段。更健壮的方法是等待服务器的onStop()回调或者通过检查端口是否真正空闲。
- 显式等待: 在测试用例内部，添加WebDriverWait来等待页面元素（如startButton）变得可见和可交互。这有助于处理页面加载和WebSocket连接建立的异步性，避免因元素未就绪而导致的ElementNotInteractableException。
- 异常处理: 在server.stop()周围添加try-catch块，以优雅地处理服务器关闭过程中可能出现的异常。
最佳实践与注意事项
- 资源管理的重要性: 自动化测试中对外部资源（如数据库连接、文件句柄、网络端口、外部服务）的生命周期管理至关重要。任何未正确释放的资源都可能导致后续测试的失败，尤其是在并发或连续执行的场景中。
- 动态端口分配: 如果可能，考虑为每个测试用例或测试套件使用一个动态分配的端口，而不是硬编码固定端口。这可以进一步避免端口冲突，尤其是在大型测试套件或并行测试环境中。例如，可以使用ServerSocket来查找一个可用的随机端口。
- 服务器状态检查: 在@BeforeEach中启动服务器后，可以添加逻辑来确认服务器确实已启动并正在监听端口，而不是简单地依赖Thread.sleep。例如，可以尝试连接该端口，或者通过服务器内部状态标志来确认。
- 测试隔离: 确保每个测试用例都是独立的，不依赖于其他测试用例的执行状态。这有助于提高测试的稳定性和可维护性。
- 异步操作的处理: WebSocket通信本质上是异步的。在Selenium测试中，对于涉及WebSocket消息发送和接收的场景，应使用显式等待（WebDriverWait）来等待预期的UI变化或数据更新，而不是使用固定的Thread.sleep。
总结
当Selenium测试WebSocket应用在批量运行时出现失败，而单独运行时通过时，最常见的原因是WebSocket服务器实例在测试之间未正确关闭，导致端口冲突。通过在@AfterEach清理方法中显式调用server.stop()来停止WebSocket服务器，并结合适当的等待机制，可以有效解决此问题，确保测试用例的隔离性和稳定性。良好的资源管理是构建健壮自动化测试套件的关键。
