年中从某个跨国银行项目上下来之后，稍作休息就开始了某个新项目的整备工作。这个项目据说是我司第一个零售电商项目，从前期得到的信息来看，React构建的前端Web网站，提供标准REST API的CMS平台系统，以及后端的企业级ERP系统，无疑对QA来说都是非常友好的，各种前后端自动化测试应该是可以无缝儿畅玩儿的，我甚至连怎么“忽悠”客户给我资源搭建Micoo的词儿都想好了。然而，接下来几个月发生的事情，着实让我重温了一把什么叫天真。

“两个月捏一个美的官网”

这个项目的客户是一家跨国的家电制造商，自己生产冰箱、吸尘器、烤箱、空调等各种大小家电，类似国内的美的。项目的目标是给客户在T国市场构建新的零售电商网站，用以替换其目前的低效站点，至于老站点怎么个低效法儿，这里就不细说了。我如果没有记错的话，这个项目前期准备从五月份就开始了，直到九月份才正式开始动工写代码，前期的拉扯甚是冗长。而客户挖的第一个坑就是“十一月中上线”！没错，两个月给它捏一个“美的官网”，这里的“捏”可不仅仅是换个肤拉个皮尔的简单替换前端UI，而是要实现整个零售电商的全数据量打通，包括产品、库存、价格、订单、促销等等一切周围系统。客户之所以有这个“底气”要求两个月完成这一切，是因为他们购买了一个商业的电商管理平台VTEX。VTEX以PaaS的方式提供了运营电商网站的近乎所有功能，而客户的期望就是以VTEX为核心，向上打造新的官方购物网站，向下集成各个已有的ERP系统，从而完成对老旧站点的替换。

最近帮助一个客户项目改进它们的自动化测试，SUT是一个分别基于iOS和Android进行原生开发的APP，客户团队的即有测试代码使用Cucumber、Appium、WebDriver构建，属于非常典型的UI自动化测试套装。代码的层级结构大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

└── Tests/
    ├── features/
    │   ├── login.feature
    │   ├── shopping.feature
    │   ├── register.feature
    │   └── ...
    ├── glues/
    │   ├── login.glue
    │   ├── shopping.glue
    │   ├── register.glue
    │   └── ...
    ├── pageObjects/
    │   ├── loginPage.java
    │   ├── homePage.java
    │   ├── paymentPage.java
    │   └── ...
    └── utils/
        ├── fileHandling.java
        ├── environmentConfig.java
        └── ...

整个测试代码粗看起来有板有眼，feature文件中合理的使用了数据驱动，glue文件中对step的定义和参数化都还不错。但翻看到PageObject时就傻眼了，一个登录页面的PageObject竟然有3000行代码！是的，你没看错，足足3000行，是QA测试登录页面的PageObject代码，而不是Dev开发登录页面的代码。这个页面本身没有复杂的交互与功能设计，比如Social Login、单页注册等，就是一个非常简单、传统的登录页面，类似下面这样：

上篇中的OWASP API Security Top 10已经帮我们梳理了最常见的API安全问题，QA针对自己API服务的具体情况，开展有的放矢的测试和安全保障工作，能够在很大程度上扫除一大批基本的安全漏洞和隐患。这其中，作为API安全最关键的层面，API的认证与授权是整个测试工作中的重中之重。如果我们自己的团队负责构建了后端的认证授权服务，那么QA对认证授权的安全测试则需要更详细、更深入的关注。 值得一提的是，我们经常将”认证授权”放在一起描述，但认证、授权其实是两个不同的事件，我们接下来会对它们的常见方式和QA可以涉及的关注点进行介绍。

服务认证的相关基础

认证，Authentication，更准确一点的称谓应该是身份认证，主要功能是对服务的使用者进行身份的合法性校验，常见的身份认证方式主要有静态码、动态口令、短信码、数字证书、以及生物特征等。说到身份认证，我们经常将它解决的问题描述成”确定’你是谁’”，然而，更确切地来说，’你是谁’仅仅是确认身份的一个要素，除此之外，还有’你知道什么’、’你拥有什么’：

最近工作在一个跨国银行的项目上，整个项目是为客户构建一个面向终端用户的银行应用程序，包括Android、iOS、Web三前端及其配套的后端系统。我所在的团队负责其中的注册登录、会话管理、以及用户数据等和安全息息相关的部分。项目中，我们遇到了很多认证授权的具体实现及其测试需求，基于这样的背景，我觉得有必要对”以QA的视角、以API为对象、以安全为重点”的API安全测试进行一些整理总结，遂赘此文于斯。

安全测试向来都是质量工程师和安全工程师所共同关注的交叉地带，有时候甚至非常不幸的是混沌地带。对应用程序或系统而言，质量工程师关注的重点通常都是功能实现，安全作为非功能需求中的一环，虽然所有人都不会质疑其重要性，但落实到具体的保障手段上来说，对一般的质量工程师而言，还是缺乏相应的金刚钻。当然，和质量类似，安全也不是测试出来的，它需要全局性的、流程性的保障手段，所以，相较于单纯的测试，我们现在更注重SDL、BSI、NIST、CLASP这些基于流程、过程、以及全生命周期的综合性安全保障方案。即便如此，对QA而言，掌握基本的安全测试理念和技能，在日常测试工作中更有目的性和针对性的实施和安全相关的测试活动，还是非常有必要的。毕竟，对团队来说，大家还是期望在提交渗透测试之前能够有一些基本的安全信心。

在软件开发的过程中，和安全相关的实体是很多的，从传统的前端应用、后端服务，到基础设施、乃至业务逻辑本身都可能存在安全风险，我们这里将以QA的视角，单独聚焦后端API的安全测试问题。

距离我上一次写契约测试的文章已经过去了三年，在这期间，契约测试在测试策略层面已经确确实实地被很多团队落地实践，无论是对工具的熟练层度、还是对引入契约测试的主观意愿，越来越多的团队在契约测试上都展现出了更高的使用水准，甚喜。

最近，我接触到了两个不同项目的一些事情，它们都对契约测试有所涉及，但又都包含了一些很容易让人迷失的细节，所以想和大家一起分享。

生产者端的契约测试不是“写”出来的

什么是UI测试中的图像对比

首先唠叨一下什么是UI测试，顾名思义，UI测试就是泛指对UI的测试工作。UI又分图形化UI和非图形化UI，即Graphic User Interface和Non-Graphic User Interface，常见的GUI主要有Web页面、移动应用界面、桌面应用界面、以及嵌入式设备的图形界面等。而非图形化用户界面则主要是各种命令行终端程序，比如docker，xcrun，kubectl等。我们这里讨论的UI，限定在GUI的范畴内，严谨的同学就别挑刺儿了哟。

对UI的测试，又可以分为功能性的测试和非功能性的测试。功能测试主要关注应用的业务实现，非功能测试则关注业务实现之外的其它方面，比如安全性、性能、易用性、兼容性等。那图像对比在UI测试中扮演怎样的角色呢？

这是一份在UI自动化测试中使用图像对比的实践分享，分为故事篇和技术篇两部分，故事篇会首先回顾这几年在视觉测试上的历程，技术篇则会介绍一些视觉测试上的技术总结。

六年前刚入职到ThoughtWorks成都办公室后，第一次参加QA社区的Catch Up，那时的我在新环境中还分不清谁是张三谁是李四。 会上，依稀记得有两位貌似道行深厚的人物，就某个工具的使用反馈，询问在座的众生，现场一片寂静。会后，回到组上，我好奇的 问了一下我们的TL（请允许这里隐去TA的名字，不然我多半会被怼的）那是什么东西、我们有没有使用，面对TL一番风卷残云的 介绍，作为刚刚从通讯行业跨入互联网行业才三天的菜鸟，小的我真的是屁都没听懂，唯一听明白并且记下来的就是“它还需要部署服务器，很难用”。

那个工具的名字叫做Viff，在后来很长的一段时间内，我仍然不知道它是干嘛的，而这，就是我第一次和UI测试中的图像对比的擦肩而过。

这篇文章原本是当年（具体当的哪一年，忘了…T_T)抱着学习的心态，翻译的Toby Clemson的文章《Testing Strategies in a Microservice Architecture》，后来又加入了一些自己在项目上的实践总结。最近在清理磁盘文件的时候，偶然又给刨了出来，索性就搬到博客里来吧~

如果你在Google上面搜索”microservice test strategy”，你一定会找到下面这个结果：

伴随着Martin Flower的大名赫然在目，但是，这篇文章的作者，不是老马，而是Toby Clemson。之所以提这个，是因为已经多次听到有小伙伴在述及这篇文章时，张口就是”Martin Fowler的那篇微服务测试策略的文章……”，所以，尊重作者，还是从记住他们的名字开始吧~

在之前写的《契约测试之Pact By Example》中，我曾提到会再写一篇文章，来聊聊如何正确地认识和理解契约测试（好吧，至少是我认为的”正确地”）。但在随后的一年多时间里，对契约测试的讨论渐渐淡出了我的视野。我的理解是，随着微服务的大行其道，契约测试作为带刀护卫，已经深入人心了，所以没必要再去炒这碗冷饭，就像现在已经没有谁会再来码字吹Selenium一样（…请相信，我一定不是因为懒才这么说的o(*￣3￣)o）。

然而，在最近参加的一次面向Dev的后端分享的讨论中，我意外的发现，契约测试作为构建微服务重要的一环工程实践，虽然确实已经被团队原生接受，但对于契约测试的理解，还存在一些认识上的盲点，特别是当契约测试与集成测试、接口测试一起讨论的时候，理解的偏差往往会被放大不少。所以，我想必要的码点字，分享一下我对契约测试的理解，还是有益的。

如今，契约测试已经逐渐成为测试圈中一个炙手可热的话题，特别是在微服务大行其道的行业背景下，越来越多的团队开始关注服务之间的契约及其契约测试。

从2015年开始我就在Thoughtworks和QA Community里推广契约测试，收到了不错的成效，期间有不少同学和我讨论过如何上手契约测试，发现网上介绍契约测试的讲义、博客不乏其数（当然，质量也参差不齐），可手把手教你写契约测试的文章却几乎没有，原因恐怕就是契约测试的特性吧。契约测试是架设在消费者和服务者之间的一种比较特殊的测试活动，如果你只是想自己学习而又没有合适的项目环境，那你得自己先准备适当的消费者和服务者程序源代码，然后再开始写契约测试，而不是像写个Selenium测试那样，两三行代码就可以随随便便地调戏度娘。～(￣▽￣～)

所以，我花了些时间磨叽出了这片文章……