《微服务架构实战》读书笔记微服务测试

背景：

相比单体应用，微服务进行变更时，仅需更新应用程序的单个组件。但同时面临着以下挑战：

系统依赖性增加：微服务架构需要更多的隔离组件，给系统带来更多的依赖，导致接口数量增多，更新时需要测试的接口也就增多。
并行开发：接口数量增加，不同服务可能由不同团队进行维护。一个接口变动，会导致连锁反应。
与传统测试的冲突
更多潜在的故障：大量的独立故障点
更多的团队交互

微服务测试

微服务测试从传统的三层测试金字塔扩展到五层：

同三层测试金字塔基本原则相同：

越往上，越接近业务/最终用户；月往下，越接近开发
越往上，测试用例越少
越往上，测试成本越高（越耗时，失败时的信息越模糊，越南跟踪）。
越往上，测试的实现和维护成本就越高，测试的速度也越慢

具体描述如下：

UI/UE测试：功能测试、兼容性测试、安装卸载测试等。界面风格、文字等界面友好性测试。掺杂测试人员主管意念
端对端测试：除了测试服务，测试者还需要确保无论使用何种架构构建，应用都必须实现业务目标，同时，还需要测试继承系统运行的完整性。还要确保架构重构时业务功能不会受到影响（找到覆盖缺口）
API测试：API测试同UI功能测试，在已经知道输入内容和期望结果的前提下，使用这个功能/调用这个API并且验证是否返回期望的结果。主要使用工具/软件调用待测API，验证是否返回期望的output
组件接口测试：测试各个模块之间能够正确交互，并测试其作为子系统的交互性以查看接口的缺陷。通过集成测试来完成。
- 集成测试：通过集成模块检查路径畅通与否，来确认模块与外部组件的交互情况。
单元测试：局限在服务内部，围绕一组相关联的按理编写。是指对软件中最小可测试单元进行检查和验证。比如测试一个类、一个类的方法……

单元测试

单元测试的三个步骤：

准备测试环境和数据
执行目标方法
验证执行结果

在做单元测试时，代码负载率常常被拿来作为衡量测试好坏的指标，甚至用代码覆盖率考核测试完成情况。

代码覆盖率包含如下指标：

行覆盖率
分支覆盖率
路径覆盖率
条件覆盖率
状态机覆盖率

单元测试工具1—— JUnit

JUnit：java单元测试框架。

JUnit的基本注释如下：

@BeforeClass：所有测试方法签执行一次，一般写在整体初始化的代码
@AfterClass：所有测试方法后执行一次，一般在其中写上销毁和释放资源的代码
@Before：在每个测试方法前执行，一般用来初始化方法。
@After：在每个测试方法后执行，在方法执行后要完成的事情
@Test（timeout = 1000）：测试方法执行超过1000毫秒后算超时，测试将失败
@Test（excepted = Exception.class）：测试方法期望得到的异常类，如果方法执行没有抛出指定的异常，则测试失败。
@Ignore（“not ready yet”）：执行测试时忽略掉此方法，如果用于修饰类，则忽略整个类。
@RunWith：选择JUnit中的Runner，如果做简单测试，不涉及spring，可以省略@Runwith注解，此时系统使用默认注解。

单元测试工具2——Spring boot单元测试

@SpringBootTest是Spring Boot项目测试的和兴注解，标识该测试类以Spring Boot方式运行。

单元测试工具3 —— Mockito

Mockito是一个基于MIT协议的开源java测试框架。Mockito区别于其他模拟框架的地方主要在于允许开发者在没有建立“预期”时验证被测系统的行为。对mock对象的一个批评是被测代码与测试系统高度耦合，由于Mickito试图通过移除“期望规范”来去除expect-run-verify模式（期望-运行-验证），因此使耦合度降到最低。由此简化代码，使代码更容易阅读和修改。

API测试

Postman，基于工具测试，发送http请求，支持get/put/post/delete及许多其他http方法。
Jmeter：一款专门用于功能测试和压力测试的轻量级测试开发平台。
压力测试：使用Hitchhiker，进入Stress模块，点击“create stress test”，设置并发数、qps、timeout、keeplive等参数。