测试

屏幕截图 2021-01-28 152729

对于微服务来说,服务的拥有者应该负责测试代码的编写。

测试运行的缓慢会影响修复错误的效率,从而影响开发

类型

  • 面向技术的测试:如单元测试,非功能性测试(安全、性能)
  • 面向业务的测试:验收测试,探索性测试

范围

测试金字塔

202002131527

测试象限

屏幕截图 2021-01-28 153152

单元测试

但测试通常是只测试一个函数和方法调用,并且应该跟外部环境无关

同时,单元测试对代码重构非常重要

服务测试

只对单个服务进行测试可以提高测试的隔离性,针对服务所需要的外部合作者,一般都是mock或者打桩

契约测试

侧重于验证服务提供者的参数定义是否符合消费者的期望

org.springframework.cloud.contract.spec.Contract.make {
    request { // (1)
        method 'PUT' // (2)
        url '/fraudcheck' // (3)
        body([ // (4)
               "client.id": $(regex('[0-9]{10}')),
               loanAmount : 99999
        ])
        headers { // (5)
            contentType('application/json')
        }
    }
    response { // (6)
        status OK() // (7)
        body([ // (8)
               fraudCheckStatus  : "FRAUD",
               "rejection.reason": "Amount too high"
        ])
        headers { // (9)
            contentType('application/json')
        }
    }
}

用户界面测试

这种测试覆盖了整个系统

各种测试的比例

根据经验,下面一层的测试通常要比上面一层的测试多一个数量级,因为越往上的测试,反馈周期越长,出了错误就没有那么快可以解决

实现服务测试

打桩 :为被测服务的一些请求创建一些预设的响应

mock :mock会验证请求是否被正确调用

引入mock可能会更加复杂,所以可以创建一个智能的打桩服务

用户界面测试

集成的服务数量越多,测试就会越脆弱,不确定性也就越强

  • 消费者驱动测试:针对消费者的需求产生测试

部署后再测试

  • 平均修复时间胜于平均故障时间

跨功能测试

性能测试

性能测试需要有目标

results matching " "

No results matching " "

results matching " "

No results matching " "