网站发布与推广方式,如何做产品的网络推广,网站内容建设的布局和结构图,济南seo外包公司代码质量管理是软件开发过程中的关键组成部分#xff0c;比如我们常说的代码规范、代码可读性、单元测试和测试覆盖率等#xff0c;对于研发人员来说单元测试和测试覆盖率是保障自己所编写代码的质量的重要手段#xff1b;好的用例可以帮助研发人员确保代码质量和稳定性、减…代码质量管理是软件开发过程中的关键组成部分比如我们常说的代码规范、代码可读性、单元测试和测试覆盖率等对于研发人员来说单元测试和测试覆盖率是保障自己所编写代码的质量的重要手段好的用例可以帮助研发人员确保代码质量和稳定性、减少维护成本、提高开发效率以及促进团队合作。之前看过一篇关于 OceanBase 质量之道的文章文章中提到的工程理念就把测试作为非常重要的组成部分是和研发同样重要的组成部分也听过内部的同学说过OB 最核心的是用例。 OceanBase工程理念经过多年的摸索OceanBase团队打造了独特的工程文化。测试和开发同时进行功能测试不再是一个独立分开的过程而是融入到开发环节从源端控制引入bug的概率。资深测试人员的精力主要放在难度较大的bug的发现测试体系建设和相关技术钻研、测试自动化实施。我们建立了一套高效的代码准入流程防范了许多初级的问题提升了团队整体的研发效率。 由此可见测试用例对于项目的重要性。从实际的工作中也会发现大多数的同学对于如何编写测试用例其实是比较模糊的在以项目交付为核心思路的工程实践中测试用例往往只占整个工程周期相当小的一部分更多时候是依赖测试团队进行功能测试属于纯黑盒测试。那么这种测试对于业务常规流程可以起到一定的作用但是对于一些边界问题其实很难 cover 住另外基于黑盒模式的功能性测试对于研发团队本身来说除了拿到准入的测试报告之外并无其他帮助当研发需要对代码进行重构或者升级某部分组件时没有用例的保障则会将风险直接带到线上环境去。
常见的测试方式
在既往的工作团队中关于测试方式包括我自己在内在没系统了解过测试理论之前对于各种测试方式也是模棱两可因为测试方式的种类实在是多又杂。下面是梳理的常见的测试方式按照不同的维度进行了分类。
分类维度测试方式说明测试目标功能测试验证系统是否按照规格说明的功能需求进行操作和响应。性能测试评估系统在不同负载条件下的性能表现。安全性测试发现系统的安全漏洞和弱点以确保系统不容易受到攻击。回归测试确保在对系统进行修改后没有引入新的错误或破坏已有功能。可用性测试评估系统的用户界面和用户体验。兼容性测试验证系统在不同浏览器、操作系统和设备上的兼容性。测试层次单元测试验证单个代码单元通常是函数、方法、类等的正确性。组件测试验证单个软件组件的功能性和正确性。集成测试验证不同组件、模块或服务之间的接口和协同工作。系统测试验证整个系统是否按照需求规格正常运行。验收测试由最终用户或客户进行的测试以验证系统是否满足其需求和期望。测试方法手动测试测试人员手动执行测试用例模拟用户的操作。自动化测试使用自动化测试工具和脚本来执行测试用例提高测试效率和一致性。白盒测试关注内部代码逻辑通常由开发人员执行。黑盒测试关注输入和输出不关心内部代码逻辑。灰盒测试结合了白盒测试和黑盒测试的特点。执行时机静态测试在代码编写之前或编译之后执行包括静态代码分析、代码审查等。动态测试在运行时执行包括各种类型的功能测试、性能测试等。测试对象功能测试测试系统的功能性。非功能测试测试系统的非功能性特征如性能、安全性、可用性等。白盒测试测试代码的内部逻辑和结构。黑盒测试测试系统的输入和输出不考虑内部实现。
每种测试方式都有其独特的目标和方法可以在软件开发生命周期的不同阶段进行。不同的测试方式在不同的测试维度分类下会有一些重叠这是正常的但是他们的关注点是一致的。
在本篇文章中主要更偏向于研发侧所以从测试层次角度来看更多的是关注单元测试(UT)、组件测试(CT)以及集成测试(IT)。总体来说UT 关注代码单元的正确性CT关注组件的功能性IT关注不同组件的集成和协同工作。这些测试层次通常是渐进的从UT开始然后是CT最后是IT。不同的测试方式在软件测试策略中起着不同的作用这些测试手段的目的就是共同确保软件在各个层次上的质量和稳定性。 下面会通过一些具体的例子来阐述不同的测试方式主要是针对单元测试、组件测试和集成测试项目基于 Spingboot 2.4.12 版本使用 Junit4 和 Mockito 两种测试工具包。 UT、CT 和 IT
在具体看案例之前先把几个测试工具跑出来做个简单了解。
测试工具
下面的案例中主要涉及到的测试工具和框架包括spring-boot-starter-test、junit4和Mockito。
spring-boot-starter-test 官方文档docs.spring.io/spring-boot… spring-boot-starter-test 是 Spring Boot 提供的一个用于测试的依赖库它简化了 Spring Boot 应用程序的测试过程提供了许多有用的工具和类帮助开发人员编写高效、可靠的单元测试和集成测试。就目前而言JAVA 技术栈的项目是绕不开 Spring 这套体系的而绝大多数情况下在 spring 或者 springBoot 项目中我们需要依赖 spring 容器刷新之后去测试相应的逻辑spring-boot-starter-test 就是做这个事情的。 dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency
junit4
JUnit 4 是一个用于 Java 编程语言的单元测试框架。目前版本是 JUnit 5目前我们项目中使用的是 JUnit4。以下是 JUnit 4 中一些常用的特性和概念
注解驱动的测试JUnit 4使用注解来标记测试方法以指定哪些方法应该被运行为测试。常见的测试注解包括 Test 用于标记测试方法、Before 用于标记在每个测试方法之前运行的方法、After 用于标记在每个测试方法之后运行的方法等。对于全局资源的初始化和释放可以通过 BeforeClass 和 AfterClass 来搞定。测试套件JUnit 4允许你将多个测试类组合在一起形成一个测试套件然后可以一次运行所有测试类。这对于组织和管理测试非常有用。断言JUnit 4提供了一系列的断言方法用于验证测试中的条件是否为真。如果条件不满足断言将引发测试失败。常见的断言方法包括 assertEquals、assertTrue、assertFalse、assertNull、assertNotNull 等。运行器Runners JUnit 4引入了运行器的概念允许你扩展测试的执行方式。JUnit 4提供了一些内置的运行器例如 BlockJUnit4ClassRunner 用于普通的 JUnit 测试类还有一些用于特定用途的运行器如 Parameterized 用于参数化测试。目前在 springboot 中使用了 SpringRunner 其实也是 BlockJUnit4ClassRunner 的子类。
Mockito
Mockito 是一个用于模拟对象的框架用于创建和配置模拟对象以模拟外部依赖。Mockito 的主要焦点是模拟外部依赖以便在单元测试中隔离被测试的代码并确保它与外部依赖正确交互。和 JUnit 4 的区别在于JUnit 4 是一个单元测试框架用于编写和运行测试用例JUnit 4 的主要焦点是定义和执行测试以及管理测试生命周期。
单元测试UT
在前面的测试分类中单元测试主要是验证单个代码单元通常是函数、方法、类等的正确性在实际的项目中单元测试主要是对于一个封装好的工具类的测试。如在 DateUtil 工具类中有一个方法 public static String getDate(Date date, String pattern) { if (null date) { return null; } SimpleDateFormat sdf new SimpleDateFormat(pattern); return sdf.format(date); }
右击选中方法goto - test也可以通过相应的快捷键直接创建当前选中方法的测试用例。 相应的测试代码如下 public class DateUtilTest { Test public void test_getDate() { int dateYear DateUtil.getDateYear(new Date()); String yyyy DateUtil.getDate(new Date(), YYYY); Assert.assertEquals(String.valueOf(dateYear), yyyy); } }
这里覆盖了正常的情况对于传入 date 为 null 的分支并未覆盖到所以对于强调覆盖率必须满足一定阈值的情况(之前的一个项目中在 CI 流程中会对当前提供的代码覆盖率进行严格把控比如行覆盖率比如达到 75% 才能被 merge)则对于不同分支逻辑也需要提供对应的用例。 // 当date 为 null 时期望返回 null Test public void test_getDate_when_date_null_thenReturn_null() { String result DateUtil.getDate(null, YYYY); Assert.assertEquals(null, result); }
组件测试CT/集成测试IT
我们目前基于 SpringBoot test 的测试大体可以归类于组件测试这种情况只需要针对当前服务自己的组件进行设计用例对于可能涉及到的上下游依赖一般可以通过 mock 的方式来绕过从而使得当前应用的用例 focus 在自己的业务逻辑上。
使用 mock 代替实际请求
场景描述UserCaseService 中有个 getUserCaseList 方法通过传入一个 UserCaseRequest 参数然后去另一个服务拉取当前用户的事件列表代码如下 public ResponseCaseResponse getUserCaseList(UserCaseRequest request) { MapString, Object param new HashMap(); param.put(phone,request.getPhone()); param.put(pageNo,request.getPageNo()); param.put(pageSize,request.getPageSize()); JSONObject result HttpUtils.useHHMApi(/miniapp/user/case, param); ResponseCaseResponse response result.toJavaObject(result, Response.class); return response; }
在 HttpUtils 中底层是对 RestTemplate 的封装 public static JSONObject request(String url, MapString, Object headers, MapString, Object param) { HttpHeaders head new HttpHeaders(); if (!ObjectUtils.isNull(headers)) { for (String h : headers.keySet()) { head.add(h, String.valueOf(headers.get(h))); } } // HttpUtils.useHHMApi 底层实际发起拉取数据的地方 String entity restTemplate.postForObject(url, new HttpEntityMap(param, head), String.class); return JSONObject.parseObject(entity); }
在上面那段代码中会具体发送 http 请求到另一个服务去拉取数据。对于这种场景
1、需要保障用例不会受到对方服务的影响都能顺利执行。2、关注的是 getUserCaseList 这个方法本身的逻辑这里举例代码做了相应的简化
因此和实际运行的逻辑不同在于在编写测试用例时对于底层发起的 http 调用其实不是主要关注的可以基于约定好的成功/失败的数据报文结构通过 mock 的方式来代替实际 http 请求发送。 Test public void test_getUserCaseList() { // 提供 mock 条件 Mockito.when(restTemplate.postForObject(Mockito.any(String.class), Mockito.any(HttpEntity.class), Mockito.any(Class.class))).thenReturn(MockData.mockMiniAppUserCaseResponseData(true)); UserCaseRequest request new UserCaseRequest(); request.setPhone(15215608668); request.setPageNo(1); request.setPageSize(10); ResponseUserCaseResponse response naturalService.getUserCaseList(request); Assert.assertEquals(200, response.getCode()); }
通过这种形式则可以有效屏蔽因为三方服务对于我们自己当前用例的影响核心的还是要关注在自己的业务逻辑上。 准备条件可以在 Before 中体现 Before public void before() { RestTemplate restTemplate Mockito.mock(RestTemplate.class); HttpUtils.setRestTemplate(restTemplate); }
SpringBootTest 说明
在 test_getUserCaseList 中naturalService 是一个spring bean因此执行此用例我们需要依赖 spring 容器环境。 SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT, classes ServerApplication.class) RunWith(SpringRunner.class) public class UserCaseTest { Autowired private NaturalService naturalService; // your test case }
SpringBootTest 在官文档中被描述用于 integration testing 使用的注解其目的是用于启动一个 ApplicationContext达到在无需部署应用程序或连接到其他基础设施即可执行 集成测试。已上面的代码为例其中
webEnvironment 用于描述运行环境主要包括以下几种类型
类型描述MOCK这个选项不启动真正的 Web 服务器而是使用模拟的 Servlet 上下文来运行测试。这意味着你的应用程序的 Web 层控制器、过滤器等将在一个模拟的环境中运行不会实际处理 HTTP 请求和响应。这种环境适用于单元测试和切片测试通常用于测试应用程序的业务逻辑。RANDOM_PORT这个选项会启动一个嵌入式的 Web 服务器并随机选择一个可用的端口。测试将通过实际的 HTTP 请求和响应与应用程序的 Web 层交互。这种环境适用于端到端测试可以测试整个 Web 栈包括控制器、服务、数据访问等。DEFINED_PORT这个选项也会启动嵌入式的 Web 服务器但它会使用一个预定义的端口号。你可以通过 server.port 配置属性来指定端口号。与 WebEnvironment.RANDOM_PORT 不同这个选项的端口号是固定的。这对于需要在已知端口上运行测试的情况很有用。NONE这个选项完全不启动 Web 服务器。它用于纯粹的单元测试不涉及任何 Web 层的逻辑。在这种环境中通常只测试应用程序的业务逻辑和服务层不测试与 HTTP 请求和响应相关的内容。
classes 属性用于指定要加载的配置类这些配置类将用于初始化 Spring Boot 应用程序上下文。通过 classes 属性可以控制在测试中加载的 Spring Bean 配置以适应不同的测试需求。在上述案例中ServerApplication.class 是当前项目的启动类表示在测试中加载整个应用程序上下文。RunWith 用于指定测试运行器RunnerJUnit 4 默认运行器是 BlockJUnit4ClassRunner 在 Spring 中对应的是 BlockJUnit4ClassRunner 的子类 SpringJUnit4ClassRunner而上述代码中的 SpringRunner 和 SpringJUnit4ClassRunner 是一样的从 SpringRunner 类的源码注释中可以看到SpringRunner是 SpringJUnit4ClassRunner 的别名(SpringRunner is an alias for the SpringJUnit4ClassRunner)。
使用 H2 内存数据库来代替实际库
在编写用例时大多数情况下我们需要依赖数据库的数据进行场景描述但是一般情况下即使是测试库用于作为测试用例的依赖也是不合适的。因此在实践过程中一般会使用 H2 来代替实际使用的类似 Mysql 数据库来进行测试实现数据层面的环境隔离。使用 H2 作为测试用例依赖数据库也比较简单在 pom 中引入如下 H2 的依赖。然后在测试时指定对应 H2 的配置文件代替 Mysql 的配置文件即可制定配置参考下一小节。 dependency groupIdcom.h2database/groupId artifactIdh2/artifactId scopetest/scope /dependency
使用指定的测试配置文件
如前面提到如何我们期望测试用例的环境和实际的环境隔离则可以使用一个单独的配置文件来描述比如使用 H2 代替实际的数据库。
测试配置文件 application-test.yaml spring: # 使用 H2 作为数据源 datasource: url: jdbc:h2:mem:customdb driverClassName: org.h2.Driver username: root password: password # 省略其他配置
指定配置文件 SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT, classes ServerApplication.class) RunWith(SpringRunner.class) PropertySource(value {classpath:application-test.yaml}) public class UserCaseTest { Autowired private NaturalService naturalService; // your test case }
做好测试资源的清理
做好测试资源清理是一个好用例具备的基本前提如果两个研发同时需要依赖某一个表的数据进行用例设计如果每个人都没有做好自己用例的资源清理则在实际的用例执行过程中则会出现用例之间的相互干扰。另外如果对于一些团队没有使用 H2 来代替实际的测试库那么在用例不断执行的过程中会给测试库产生相当于的测试脏数据。基于上面两个前提所以我们在设计用例时特别是涉及到数据或者状态变更的场景时一定要做好相应的资源清理。如用户注册的场景逻辑 Test public void test_register(){ UserDto userDto new UserDto(); userDto.setPhone(test number); userDto.setName(test); userDto.setNickName(test); userDto.setPassword(test pwd); // 注册用户 bool success userService.register(userDto); Assert.assertTrue(success); }
在上面这段用例可能会出现的情况
如果用户表中没有做基于名字或者手机号的唯一性校验则在我们的表中可能会出现很多 name 为 test 的用户。每执行一次则产生一条记录如果用户表做了唯一性约束那么当第一次执行完之后第二次执行时则可能会报错当前用例会执行失败。
所以在优化这个用例时就可以将用例执行完之后的数据清除掉。具体做法有两种
1、在当前用例中执行比如通过 try finally在 finally 块中执行删除插入的数据2、在 After 中执行删除插入的数据After 注解描述的方法会在每个用例执行完之后执行通过用于做资源清理
小结
本篇主要针对如何编写测试用例进行了简单的介绍包括场景的测试方式分类、测试工具并通过几个小的测试用例对单元测试、组件测试和集成测试做了分析。最后针对日常研发中如何做好测试编写和如何做好测试资源释放给了目前主流方案的建议和使用说明。
