我来给MeterSphere写测试用例05

目前为止，我们已经创建了测试项目，并且在项目内创建了模块和用例。接下来，将介绍如何将测试用例纳入测试计划，并执行。

作为一个计划，一般都会存在着负责人、计划开始/结束时间等管理要素。以下是前台可以看到的测试计划界面。通过观察MeterSphere前台的测试计划界面,我们可以了解到，一个测试计划隶属于某个项目。随着项目的切换，测试计划清单也会随之切换，并且具备了一个计划所必须的关键要素。

测试流程管理简单来说就是定义好项目阶段-测试级别-测试类型，也就是说明确在不同项目阶段中，定义好若干的测试级别，并规定好各个级别所要实施的各类型测试活动。

目前随着敏捷研发模式，尤其是互联网类型的项目成为主流，项目更多的是随着业务发展而来的系统维护更新，采用更为轻量、阶段划分更为紧凑或者不明显的测试计划管理也是贴合实际需求的。因此我们可以看到MeterSphere这里使用了测试阶段+测试计划来安排测试活动。

新建测试计划

聊完了测试项目的管理流程，言归正传来对MeterSphere的这个接口进行测试。以下是一个示例，

     @Order(4)
     @Test
     @DisplayName("04测试计划-新建测试计划")
     public void addTestPlan() throws Exception {
         String input="{\"name\":\"1234\",\"projectIds\":[\"8e06530d-4125-4114-9b4e-dc1cd809c63a\"],\n" +
                 "    \"principal\":\"demo\",\"stage\":\"system\",\"description\":\"demoo\",\n" +
                 "    \"plannedStartTime\":1604160000000,\"plannedEndTime\":1606147200000,\n" +
                 "    \"workspaceId\":\"f0d189dc-7e27-4a63-9702-976aff21d334\"}";
         addTestPlanRequest=JSON.parseObject(input,AddTestPlanRequest.class);
         addTestPlanRequest.setProjectIds(Arrays.asList(project.getId()));
         addTestPlanRequest.setName("plan-"+getRandom());
         addTestPlanRequest.setCreator("admin");
         addTestPlanRequest.setDescription(getRandom());
         addTestPlanRequest.setWorkspaceId(workspace.getId());
        String result= doPost("/test/plan/add",JSON.toJSONString(addTestPlanRequest));
        assertThat(result).contains("true");
         result=doPost("/test/plan/list/all"," ");
         List<TestPlan> testPlans= JSON.parseArray(String.valueOf(JSON.parseObject(result,ResultHolder.class).getData()),TestPlan.class);
         assertThat(testPlans).isNotEmpty();
         testPlan=testPlans.get(0);
     }

测试过程是这样的，

• 首先组织测试计划的信息，主要是测试计划的名字、创建人、工作空间、所属项目、测试阶段等信息。
• 然后通过调用接口完成计划的创建。
• 最后通过查询来获取刚才新建的测试计划并保存。

通过JSON串准备基础数据

与先前的测试用例不同的是，这里在构建addTestPlanRequest对象时，首先通过一个JSON串的反序列化新创建了一个AddTestPlanRequest的实例，然后根据本测试用例的需要，对一些需要变化的属性重新进行了赋值。这是笔者经常使用的一个数据准备方式。特别是在一些单元测试和集成测试时，如果待构造的对象属性较多，且各个用例中均需要使用此类对象且存在大量重复属性的时候，就可以使用这种方式。先准备一个JSON串作为基础数据，然后在各个用例中通过反序列化来构造对象，并对变化部分重新赋值。这样隔离了共享一个类所带来的数据冲突问题，也不用重写对象的深拷贝方法，更避免了测试用例代码中大量存在的set方法调用。

另外还有一点提醒读者注意，MeterSphere团队在关联某个测试计划与测试项目时，使用的是List<String> 来记录测试项目，而不是单个的String

addTestPlanRequest.setProjectIds(Arrays.asList(project.getId()));

虽然目前来说测试计划只隶属于一个项目，笔者猜测不排除后续将测试计划独立出来，成为与测试项目平级的业务对象。

关联测试计划与测试用例

在创建了测试计划之后，我们要将之前创建的测试用例与之关联起来，也就是将测试用例纳入测试计划。

     @Order(5)
     @Test
     @DisplayName("05测试计划-关联测试用例")
     public void addTestPlanRelevance() throws Exception {
         PlanCaseRelevanceRequest planCaseRelevanceRequest= new PlanCaseRelevanceRequest();
         String input="{\"name\":\"1234\",\"projectIds\":[\"8e06530d-4125-4114-9b4e-dc1cd809c63a\"],\n" +
                 "    \"principal\":\"demo\",\"stage\":\"system\",\"description\":\"demoo\",\n" +
                 "    \"plannedStartTime\":1604160000000,\"plannedEndTime\":1606147200000,\n" +
                 "    \"workspaceId\":\"f0d189dc-7e27-4a63-9702-976aff21d334\"}";
         QueryTestCaseRequest queryTestCaseRequest=  new QueryTestCaseRequest();
         queryTestCaseRequest.setPlanId(testPlan.getId());
         queryTestCaseRequest.setTestCaseIds(Arrays.asList(testCase.getId()));
         queryTestCaseRequest.setProjectId(project.getId());
         planCaseRelevanceRequest.setPlanId(testPlan.getId());
         planCaseRelevanceRequest.setRequest(queryTestCaseRequest);
         planCaseRelevanceRequest.setTestCaseIds(Arrays.asList(testCase.getId()));
         String result= doPost("/test/plan/relevance",JSON.toJSONString(planCaseRelevanceRequest));
         assertThat(result).contains("true");
     }

至此，我们在原先创建了测试项目、测试模块，将测试用例挂到了相应的测试模块的基础上，在该测试项目之下创建了测试计划，将测试用例纳入了该计划。