从Postman迁移至IntelliJ+Rest-Assured：测试自动化请求存储最佳实践咨询

嘿，很高兴看到你从Postman转到IntelliJ搭配Rest-Assured做自动化测试——这绝对是个能提升测试可维护性的好选择！针对你提到的存储请求体的最佳实践，结合你的业务场景（多主服务、附加服务、多国家的价格请求），我整理了几个实用方案，你可以根据团队的实际情况挑选：

如果你的请求体结构差异较大，或者需要非技术人员也能修改请求内容，这种方式很合适：

• 先在src/test/resources下创建统一的请求存储目录，比如requests，然后按业务场景+地域分层，比如：

  src/test/resources/requests
  ├── main_service
  │   ├── us
  │   │   ├── basic_price_request.json
  │   │   └── premium_price_request.json
  │   └── eu
  │       └── basic_price_request.json
  └── addon_service
      └── apac
          └── streaming_addon_request.json
  

• 在测试代码里，用Rest-Assured结合IO工具类读取文件内容，比如封装一个简单的工具方法：

  public static String readRequestFile(String filePath) throws IOException {
      return IOUtils.toString(
          new FileInputStream("src/test/resources/requests/" + filePath + ".json"),
          StandardCharsets.UTF_8
      );
  }
  

  然后在测试中直接调用：

  given()
      .body(readRequestFile("main_service/us/basic_price_request"))
  .when()
      .post("/price/calculate");
  

• 优势是请求体和代码完全分离，结构清晰，后期维护时找对应请求非常直观。

如果你的请求体结构相对固定，只是参数值随场景变化，强烈推荐这种方式：

• 创建对应的Java实体类（POJO），比如PriceRequest，用Lombok可以简化getter/setter的编写：

  @Data
  public class PriceRequest {
      private String serviceType;
      private String countryCode;
      private List<String> addonServices;
      // 其他字段...
  }
  

• 再配合Builder模式封装一个请求构建器，快速生成不同场景的请求：

  public class PriceRequestBuilder {
      private PriceRequest request = new PriceRequest();
  
      public PriceRequestBuilder withMainService() {
          request.setServiceType("MAIN");
          return this;
      }
  
      public PriceRequestBuilder withCountryCode(String code) {
          request.setCountryCode(code);
          return this;
      }
  
      public PriceRequestBuilder addAddonService(String service) {
          if (request.getAddonServices() == null) {
              request.setAddonServices(new ArrayList<>());
          }
          request.getAddonServices().add(service);
          return this;
      }
  
      public PriceRequest build() {
          return request;
      }
  }
  

• 测试中使用起来非常简洁：

  PriceRequest request = new PriceRequestBuilder()
      .withMainService()
      .withCountryCode("US")
      .addAddonService("NETFLIX")
      .build();
  
  given()
      .body(request)
  .when()
      .post("/price/calculate");
  

• 这种方式的好处是类型安全，IDE会提示字段，避免拼写错误；而且请求结构复用性强，新增场景只需要在Builder里加方法即可，维护成本极低。

如果请求体大部分内容固定，只有少数参数（比如国家码、服务ID）需要动态变化，可以用模板加占位符的方式：

• 先创建模板文件，比如price_request_template.json：

  {
    "serviceType": "{{serviceType}}",
    "countryCode": "{{countryCode}}",
    "addonServices": {{addonServices}}
  }
  

• 在代码里用简单的字符串替换或者轻量模板引擎（比如FreeMarker）填充参数：

  String template = readRequestFile("templates/price_request_template");
  String requestBody = template
      .replace("{{serviceType}}", "ADDON")
      .replace("{{countryCode}}", "EU")
      .replace("{{addonServices}}", "[\"SPOTIFY\"]");
  
  given()
      .body(requestBody)
  .when()
      .post("/price/calculate");
  

• 这种方式既保留了请求体的可读性，又能灵活调整参数，适合那些结构固定但参数多变的场景。

如果你的测试需要覆盖大量参数组合（比如所有国家+所有服务的组合），可以把测试数据和请求体结构分开：

• 用CSV或Excel存储测试数据，比如test_data/price_test_cases.csv：

  countryCode,serviceType,addonServices,expectedPrice
  US,MAIN,"NETFLIX,SPOTIFY",99.99
  EU,MAIN,,79.99
  APAC,ADDON,"YOUTUBE",29.99
  

• 结合JUnit 5或TestNG的参数化测试，读取数据并动态构建请求体：

  @ParameterizedTest
  @CsvSource(resources = "/test_data/price_test_cases.csv")
  void testPriceCalculation(String countryCode, String serviceType, String addonServices, double expectedPrice) {
      List<String> addons = addonServices != null ? Arrays.asList(addonServices.split(",")) : new ArrayList<>();
      
      PriceRequest request = new PriceRequestBuilder()
          .withServiceType(serviceType)
          .withCountryCode(countryCode)
          .addAddonServices(addons)
          .build();
  
      given()
          .body(request)
      .when()
          .post("/price/calculate")
      .then()
          .statusCode(200)
          .body("price", equalTo(expectedPrice));
  }
  

• 这种方式能让一个测试方法覆盖N个场景，测试数据的维护不用修改代码，非常适合大规模的回归测试。

最后给个小建议：如果你的团队刚转到Rest-Assured，可以先从POJO+Builder模式入手，配合少量模板文件处理复杂请求，等团队熟悉后再引入参数化测试覆盖多场景。记得把所有请求相关的资源（文件、POJO、工具类）放在统一的目录下，方便团队成员查找和维护。

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