平台测试策略

最近平台化是一个很火的词，都在讲什么什么的平台化，基于这种平台化应该怎么去制定测试策略呢，这是很值得我们去思考的一个问题。

系统的背景

最近就在做一个基于SAP的平台化项目，项目背景如下，客户的后台是一个大的SAP系统，我们需要基于这个SAP系统去做平台化。

由于SAP本身提供很多服务，客户能基于SAP去查询很多相关的数据，但是痛点在于，当客户需要去相关的一系列信息的时候，往往要登录不同的系统，做很多查询，最后才能查出想要的答案。我们的目的在基于当前SAP存在的功能，进一步做整合，能够更加方便快捷的为用户提供服务。

所以整体的系统结构为：

1. SAP系统，此系统为用户第三方提供的系统

2. Platform，这个是我们需要去做的系统，目的是为了整合SAP所提供的服务，是一个基于微服务的系统。

3. BFF，调用platform的微服务，为前端的页面提供服务。

4. Web application，显示给用户的页面。

在开发过程中，我们需要从上游拉动下游进行开发---从客户那里获得想要的需求，然后去拉动platform和SAP的开发。对这个系统我们需要怎样去做测试呢？

需要考虑的点

其实对于测试策略的制定来说，我们需要关注的点基本都是互通的，比如Responsibility，Automation，Data Management，Test Management，以及risk management等等。

关于测试类型

相信大家对UI automation，API，以及单元测试和code扫描测试都已经很熟悉了，这里我想重点说下的是SAP Regression。这个实际上有客户提供的SAP的回归测试，我们会把相应的这些测试放到pipline里面，当我们修改了SAP的某些功能的时候，我们就需要去运行SAP的回归测试，确保我们的修改不会影响SAP本身的功能。

具体的测试类型用到什么样的测试框架，都是与技术栈强相关的：

1. Unit test会针对前后端分别用到 Junit (backend)和Karma, Jasmine (frontend)。

2. API测试因为指在BFF层面有（其他的有契约测试覆盖），而BFF本很是用java编写的，所以我们选择了RestAssured。

3. 前端用的是Angular js的技术栈，所以我们选择了Nighwatch，其实对于前端来说，如果是angularjs，Protractor也是另外一个好的选择。

4. SAP的回归测试，由于是客户提供的，客户用的是newman，我们直接把脚本集成到pipline里面就好了。

最后我们整理如下图：

除了这些，我们还同时用到了契约测试和mock，为什么会用到契约测试和mock呢？

关于契约测试和mock

对月契约测试来说，我相信大家已经很熟悉了，主要是用于微服务之间以及，bff与platform之间。对我们为什么选择mock测试原因，可以参照我另外一篇文章： 江湖郎中，你还要吗？

测试计划

我们需要为我们项目制定测试计划，如下图，第一个迭代和第二个迭代与开发同步，主要用户测试框架的搭建，和准备工作，在第二个迭代的时候开始引入了system integration test的工作。

测试环境

与一般的项目一样，我们需要不同的环境，如下：

性能测试和安全测试

这也是我们一般所说的非功能性测试，对于性能测试我们定义了一些临时的性能指标，因为有很多不确定性因素，所以这个是要在项目持续进行修正的指标，如下图：

关于安全性测试，我们用到是比较常用的静态代码扫描Fortify用于JS的安全扫描,Lapse用于Java的安全扫描。

关于风险

对于这个项目来说，最大的风险就是SAP系统的不确定性，由此引发的考虑是，pipline如何与SAP集成？

1. 客户的SAP测试系统是一个第三方的系统，不仅极不稳定，这些都是短期内很难去和客户协调解决的问题，而且我们只有读的权限，并没有写的权限。导致我们在开发platform的过程中不能很好的和SAP集成，影响开发进度。

2. 当我们做完开发，pipline需要执行所有的测试，其中包括与SAP的集成测试，试想如果SAP不稳定，那么集成测试很多时候都会因为这个失败，怎样去做持续集成？

3. 如果我们能得到稳定的SAP环境，如何创建我们需要的数据呢？

对于测试策略来说，我们通常还要考虑到比如cases management，bug分析与管理等，这里就不再累赘。重要的不是在于我们能做什么，而是我们这样做能为项目带来什么样的价值。