契约测试Pact(二)

微服务测试对测试人员意味着什么

 

 每个服务承担一定的职责，服务尽可能地小，但是还需要达到一定的规模。对于项目做出向微服务转变的决策时，测试人员要用于提出质疑，要不要做这样的转变

 服务之间通常通过rest api来连接

 每种服务不一定提供界面。对测试人员意味着不一定能够从UI对系统进行完整测试，这就对API级别的集成化测试提出了要求

 微服务通常还可以划分为更小的模块，在对微服务进行测试时可以从不同的模块着手，进行相应的模块测试。

 

微服务给测试带来的挑战

总体的测试策略

 确保从各个维度上，无一遗漏的对微服务进行全面的测试，既要确保我们对系统各个层面的覆盖度，又要确保我们的测试执行效率，从而保证CI/CD的顺利实施。

 测试策略的正确实施，工具和技术固然重要，但是我们需要注意更为重要的人的因素，测试人员要在团队中树立质量第一的意识

 不能为了测试而测试，要以用户为核心，把有限的资源用在刀刃上，对于测试层次、流程以及用例的设计，要有的放矢

 

微服务给测试带来的挑战

 服务/模块/层次（layer）之间存在复杂的依赖性

 不同的服务可能会在不同的环境/设置下运行

 涉及多个服务的UI端到端测试（End-to-End测试，简称E2E测试）非常容易出错

 测试结果可能取决与网络的稳定性

 故障分析的复杂度会随着服务的增加而提高

 与交付周期不同的开发团队之间的交流成本

 

面对上述挑战，我们测试团队需要采用什么样的测试原则

 自动化

 层次化

 可视化

 

 

采用的主要测试方法

单元测试（Unit Test）

集成测试（Intergration Test）

组件测试（Component Test）

契约测试（Contract Test）

端到端的测试（End-to-end Test）

探索测试（Exploratory Test）

 

 

 【单元测试】：

测试最小的可测单元，验证他们能否按照预期进行表现

 

 

 【集成测试】

验证组件之间的交互路径

 

 

除了外部通信还有内部数据

 

 

 【组件测试】

在系统内部，对单个组件或者微服务个体使用Test doubles替换外部依赖来进行测试

 

验证的是微服务是否能够起到预期的作用

需要我们把微服务周边所有的依赖全部模拟化，服务正常运行以后(把外部模拟化)，站在外部来看，这些服务可以正常运行（能否正常输入输入输出）

 

 

 【契约测试】

在组件的外部，验证关联组件之间契约的正确性

 

 

对于我们的服务来说，比如被测区域需要外部服务的数据，他才能够正常动，那么对我我们这个内部服务来说我们是“消耗数据”，即【消费者】；那对于外部给它提供数据的服务来说，它是一个【提供者】，也叫【生产者】（producer）

 

【契约测试】：就是看生成者服务和消费者服务，他们之间进行通信，传递数据，那他们之间传递数据的这个协作（机制）是否恰当，生产者提供的内容，是否能满足被测服务(消费者)预期。

比如说：去食堂买饭，我今天点了一份鱼香肉丝，我发出的请求是【鱼香肉丝】，那么生产者把鱼香肉丝做好以后，他提供给我（消费者），给我的如果不是鱼香肉丝，那就不符合我这个契约测试的要求，没法满足我这个消费者的需求。

 

 【端到端测试】

在系统的外部，验证整个系统的业务功能满足设计的需求

 

粉色圈内的所有测试就是端到端测试

 

 【探索测试】

        探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。