十八个免费的舆情网站,九江市广安建设工程有限公司网站,深圳网站公司招聘,网站建设制作专业开发定制一.测试象限#xff08;Brain Marick#xff09; 二.测试金字塔#xff08;Mike Cohn#xff09; 1.单元测试 通常只测试一个函数或方法调用#xff0c;通过TDD或者基于属性而写的测试就属于这一类#xff0c;在UnitTest中#xff0c;我们不会启动服务#xff0c;对且对…一.测试象限Brain Marick 二.测试金字塔Mike Cohn 1.单元测试 通常只测试一个函数或方法调用通过TDD或者基于属性而写的测试就属于这一类在UnitTest中我们不会启动服务对且对外部文件和网络连接的使用也很有限通常我们需要大量的单元测试。 单元测试是帮助开发人员是面向技术而非业务的。 2.服务测试 对于包含多个服务的系统一个服务测试只测试其中一个单独服务的功能。只测试一个单独的服务可以提高测试的隔离性这样我们可以更快地定位并解决问题为了达到这种隔离性我们需要给所有的外部合作者打桩以便只把服务本身保留在测试范围内。打桩是指为被测服务的请求创建一些有预调响应的服务。 对于每一位下游合作者我们都需要一个打桩服务然后在运行服务测试的时候启动它们在测试过程中连接这些打桩服务为了模仿真实的服务我们还需要配置打桩服务返回请求响应。例如我们可以配置积分账户为不同的客户返回不同的预设积分。 另一种替换打桩有方式是mock。与打桩相比mock还会进一步验证请求本身是否被正确调用如果与期望请求不匹配测试便会失败过度使用mock会让测试变得脆弱。两者之间需要一些权衡。 我们可以使用一些打桩的软件来协助我们测试如Mountebank等。 3.UI测试端到端测试 对于包含多个微服务的系统来说“端到端的测试”这个名称相比“UI测试”可能更适合端到端测试会覆盖整个系统这类测试通常用图形界面来模仿用户交互动作。这类的测试会覆盖大范围的产品代码因此当它们通过时你会感觉很好。 因为端到端测试涉及到多个微服务我们可以用扇入模型来解决多个微服务同时开发同时测试的问题。 虽然扇入模型可以来解决一些难题但是端到端测试仍然有着很多的缺点。 首先端到端测试非常脆弱。 有时测试失败并不是因为功能真的被破坏了而是由其他一些原因引起的比如其他服务停止或者网络故障等这些跟测试的功能本身没有关系。 包含在测试中的服务数量越多测试就会越脆弱不确定性也就越强。 一个包括脆弱测试的测试套件往往成为Diane Vaughn所说的异常正常化的受害者也就是说随着时间的推移我们对事情出错变得习以为常并开始接受它们是正常的。 Martin Flower在http://martinflower.com/articles/nonDeterminism.html中提议在碰到脆弱的测试时应该立刻记录下来当不能立即修复时需要把它们从测试套件中移除然后就可以不受打扰地安心修复他们。修复时看能否通过重写来避免被测代码运行在多个线程中再看是否能让运行的环境更稳定更好的办法是看能否用不易出问题的小范围测试取代脆弱的端到端测试。 单个微服务的测试可以由这个特性团队来维护。那么涉及到多个微服务的端到端测试该由谁负责 虽然这种责任分配方式还在探索当中但将测试对所有人开放或者把这些测试交给专门的团队来维护都是错误的前者可能会导致团队成员可以在无须对测试套件质量有任何理解的情况下随意添加测试这会导致测试用例爆炸有时导致测试没有真正的拥有者当测试失败时每个人都认为这是别人的问题而不在乎测试是否通过后者则会导致开发人员没有在第一时间得到自己代码的测试反馈这会出现很大问题。一个可能的解决方案是让各特性团队共享端到端测试套件的代码权对测试套件联合负责。 端到端的测试通常需要的时间最长如果经常有与功能破坏无关的测试失败这就是个灾难这样即使真的是功能被破坏了也需要花很多长时间才能发现而此时大家已经转而做其他的事情了切换大脑的上下文来修复测试是很痛苦的。 我们可以用Selenium Grid工具通过并行运行测试来改善缓慢的问题但是长期的积累测试用例越来越多但我们却不敢删除测试而这可能是端到端测试面临着管理、维护困难的局面。我们应该改变我们的端到端测试思路把测试整个系统的重心放到少量核心的场景上来把任何在这个核心场景之外的功能放到相互隔离的服务测试中覆盖。 同时人们容易有这样的想法既然所有服务在这些版本下能够一起工作为什么不一起部署它们呢如果接受了这个观念慢慢的这成了常态我们就会丢弃微服务的主要优势之一独立于其他服务单独部署一个服务的能力。不用很长时间本来分享地很好的服务就会与其他服务纠缠得越来越紧密最终系统杂乱无序你必须同时部署多个服务。这非常糟糕。 4.三种测试之间的权衡 越靠近金字塔的顶端测试覆盖的范围越大同时我们对被测后的功能也越有信心缺点则是需要更长的时间运行测试反馈周期也会变长测试失败后很难定位哪个功能被破坏而靠近金字塔的底部测试更快反馈周期也会变短测试失败后更容易定位破坏的功能和代码CI也很短。一般来说顺着金字塔向下下一层的测试数量要比上一层多一个数量级。 三.消费者驱动测试 使用之前的端到端测试我们试图解决的关键问题是什么是试图确保部署新的服务到生产环境后变更不会破坏新服务的消费。有一种不需要用真正的消费者也能达到相同的目的我们可以使用消费者驱动的契约CDC。当使用CDC时我们会定义服务的消费者的期望这些期望最终会变成对生产者运行的测试代码如果使用得到CDC应该成为服务提供者CI的一部分这样可以确保如果这些契约被破坏了服务提供者无法部署。 让我们回头看一下前面图片中的例子客户服务有两个独立的消费者帮助台和Web客户端我们将创建两个测试集合其实就是模拟消费者每个集合分别体现帮助台和Web客户端对客户服务的使用方式。因为这些CDC是对客户服务如何工作的期望所以客户服务本身的所有下游依赖都可以使用打桩从测试范围来看它与测试金字塔中的服务测试位于同一层但侧重点不同这些测试重在消费者如何使用服务。 Packhttps://github.com/realestate-com-au/pact 是一个消费者驱动的测试工具开始时消费者使用Ruby DSL来定义生产者的期望然后启动本地一个mock服务器以后就可以单独地来测试消费者并对其运行这些期望来生成pact规范文件pack规范文件是一个标准的JSON规范在生产者这边你可以使用 JSON Pact规范来驱动对生产者API的调用然后验证响应以测试消费者的规范是否被满足因为生产者代码需要访问Pact文件所以我们这里采用JSON。 Pack的JSON规范是由消费者生成的该规范需要成为一个生产者可访问的构建物你可以把它存储在CI/CD仓库或Pack Broker中。 另外Pactohttps://github.com/thoughtworks/pacto 和janushttps://github.com/gga/janus 也是开源的消费契约测试工具。 四.线上测试 在生产环境我们也需要进行测试我们可以在高峰或请求来临之前进行测试这样可以发现特定环境中的问题。 1.冒烟测试 我们可以对生产环境进行冒烟测试用来帮助我们识别与环境有关的任何问题我们应该把冒烟测试加入到我们的部署脚本中。 2.蓝绿发布 使用蓝绿发布时我们会部署两份软件但只有一个接受真正的请求。我们对新部署的版本运行一些测试等测试没有问题时我们再切换生产负荷到新部署的版本通常情况下我们会保留旧版本一小段时间这样如果发生任何错误能够快速恢复到旧的版本。这样可以降低风险还可以大幅减少发布软件所需要的停机时间我们甚至可以达到零宕机部署。 3.金丝雀发布 金丝雀发布是指通过将部分流量引流到新部署的系统来验证系统是否按预期执行与蓝绿发布不同金丝雀发布过程中新旧版本共存的时间更长而且经常会调整流量。 当考虑使用金丝雀发布时你需要选择是引导部分生产流量到金丝雀还是直接复制一份生产请求如果你选择复制一份生产请求然后引导师复制的请求至金丝雀这样现行的版本和金丝雀版本将面对相同的请求只是生产环境的请求是外部可见的这样方便大家对新旧版本做比较同时又避免金丝雀发布失败时影响客户的请求但复制请求的工作可能会很复杂尤其是在请求不幂等的情况下。 4.灰度发布 灰度发布是指在黑与白之间能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式让一部分用户继续用A一部分用户开始用B如果用户对B没有什么反对意见那么逐步扩大范围把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定在初始灰度的时候就可以发现、调整问题以保证其影响度。 这些部署技术的原则无外乎说明更快的从错误中修复比千方百计地防范错误更重要当然这不是说防范错误不重要而是因为错误不可避免。 五.非功能测试 非功能测试包括一些服务延迟测试、并发量测试、负载量测试、安全性测试、性能测试等。微服务拆分之后会导致一个功能引发多个微服务的协同工作这样跨网络边界调用的次数明显增加了因此性能测试也是一件非常重要的事。 参考 《微服务设计》Sam Newman 著 / 崔力强 张骏 译
相关文章
微服务的概念——《微服务设计》读书笔记微服务架构师的职责——《微服务设计读书笔记》建模:确定服务的边界——《微服务设计》读书笔记微服务集成——《微服务设计》读书笔记服务的协作服务间的消息传递——《微服务设计》读书笔记拆分:分解单块系统——《微服务设计》读书笔记部署:持续集成CI与持续交付CD——《微服务设计》读书笔记
原文地址http://www.cnblogs.com/gudi/p/6683305.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
