[微服务下的测试第一季]基于微服务的集成测试思想

举报
ETRS 发表于 2017/11/28 14:07:46 2017/11/28
【摘要】 事实证明,拥有大量的微服务开辟了设计这些测试的新途径。 我们发现我们可以使他们更快,更容易调试,以及更少的测试代码来维护。 在我们开始使用微服务之前,我们有一个相对简单的巨石测试结构。 我们在各个层面进行测试,主要是根据标准测试金字塔: 大多数测试用例都是单元测试,在类和方法级别。 除此之外,我们还围绕数据访问层进行了相当多的测试,使用相当细致的API来检查与数据库的ORM集成。 然后有一些更高

事实证明,拥有大量的微服务开辟了设计这些测试的新途径。 我们发现我们可以使他们更快,更容易调试,以及更少的测试代码来维护。

 

在我们开始使用微服务之前,我们有一个相对简单的巨石测试结构。 我们在各个层面进行测试,主要是根据标准测试金字塔:

 

https://blog.pagero.com/wp-content/uploads/2017/02/pyramid1-1024x704.png

 

大多数测试用例都是单元测试,在类和方法级别。 除此之外,我们还围绕数据访问层进行了相当多的测试,使用相当细致的API来检查与数据库的ORM集成。 然后有一些更高级别的测试访问API来测试整个功能。 然后进行端到端的测试,通过GUI测试整个堆栈。

 

当我刚到三年以前,这个工作很好。 麻烦的是,新的功能正在外部微服务中建立,我们需要一些方法来与巨石一起测试它们。 每一个新的微服务当然都有自己的测试 - 主要是单元测试,但是也有一些测试是针对整个服务单独运行的。 尽管如此,测试这样的棋子只会让你感到满意。 测试金字塔的更高层次也是需要的,这就是我们的瓶颈似乎在哪里。

 

“拥有大量的微服务为开发自动化的端到端系统测试开辟了新的途径。”


【版权声明】本文为华为云社区用户翻译文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容, 举报邮箱:cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。