最近平臺(tái)化是一個(gè)很火的詞，都在講什么什么的平臺(tái)化，基于這種平臺(tái)化應(yīng)該怎么去制定測(cè)試策略呢，這是很值得我們?nèi)ニ伎嫉囊粋€(gè)問題。
系統(tǒng)的背景
最近就在做一個(gè)基于SAP的平臺(tái)化項(xiàng)目，項(xiàng)目背景如下，客戶的后臺(tái)是一個(gè)大的SAP系統(tǒng)，我們需要基于這個(gè)SAP系統(tǒng)去做平臺(tái)化。
由于SAP本身提供很多服務(wù)，客戶能基于SAP去查詢很多相關(guān)的數(shù)據(jù)，但是痛點(diǎn)在于，當(dāng)客戶需要去相關(guān)的一系列信息的時(shí)候，往往要登錄不同的系統(tǒng)，做很多查詢，最后才能查出想要的答案。我們的目的在基于當(dāng)前SAP存在的功能，進(jìn)一步做整合，能夠更加方便快捷的為用戶提供服務(wù)。
所以整體的系統(tǒng)結(jié)構(gòu)為：
1. SAP系統(tǒng)，此系統(tǒng)為用戶第三方提供的系統(tǒng)
2. Platform，這個(gè)是我們需要去做的系統(tǒng)，目的是為了整合SAP所提供的服務(wù)，是一個(gè)基于微服務(wù)的系統(tǒng)。
3. BFF，調(diào)用platform的微服務(wù)，為前端的頁(yè)面提供服務(wù)。
4. Web application，顯示給用戶的頁(yè)面。
在開發(fā)過程中，我們需要從上游拉動(dòng)下游進(jìn)行開發(fā)---從客戶那里獲得想要的需求，然后去拉動(dòng)platform和SAP的開發(fā)。對(duì)這個(gè)系統(tǒng)我們需要怎樣去做測(cè)試呢？
需要考慮的點(diǎn)
其實(shí)對(duì)于測(cè)試策略的制定來(lái)說(shuō)，我們需要關(guān)注的點(diǎn)基本都是互通的，比如Responsibility，Automation，Data Management，Test Management，以及risk management等等。
關(guān)于測(cè)試類型
相信大家對(duì)UI automation，API，以及單元測(cè)試和code掃描測(cè)試都已經(jīng)很熟悉了，這里我想重點(diǎn)說(shuō)下的是SAP Regression。這個(gè)實(shí)際上有客戶提供的SAP的回歸測(cè)試，我們會(huì)把相應(yīng)的這些測(cè)試放到pipline里面，當(dāng)我們修改了SAP的某些功能的時(shí)候，我們就需要去運(yùn)行SAP的回歸測(cè)試，確保我們的修改不會(huì)影響SAP本身的功能。
具體的測(cè)試類型用到什么樣的測(cè)試框架，都是與技術(shù)棧強(qiáng)相關(guān)的：
1. Unit test會(huì)針對(duì)前后端分別用到 Junit (backend)和Karma, Jasmine (frontend)。
2. API測(cè)試因?yàn)橹冈贐FF層面有（其他的有契約測(cè)試覆蓋），而BFF本很是用java編寫的，所以我們選擇了RestAssured。
3. 前端用的是Angular js的技術(shù)棧，所以我們選擇了Nighwatch，其實(shí)對(duì)于前端來(lái)說(shuō)，如果是angularjs，Protractor也是另外一個(gè)好的選擇。
4. SAP的回歸測(cè)試，由于是客戶提供的，客戶用的是newman，我們直接把腳本集成到pipline里面就好了。
最后我們整理如下圖：
除了這些，我們還同時(shí)用到了契約測(cè)試和mock，為什么會(huì)用到契約測(cè)試和mock呢？
關(guān)于契約測(cè)試和mock
對(duì)月契約測(cè)試來(lái)說(shuō)，我相信大家已經(jīng)很熟悉了，主要是用于微服務(wù)之間以及，bff與platform之間。對(duì)我們?yōu)槭裁催x擇mock測(cè)試原因，可以參照我另外一篇文章： 江湖郎中，你還要嗎？
測(cè)試計(jì)劃
我們需要為我們項(xiàng)目制定測(cè)試計(jì)劃，如下圖，第一個(gè)迭代和第二個(gè)迭代與開發(fā)同步，主要用戶測(cè)試框架的搭建，和準(zhǔn)備工作，在第二個(gè)迭代的時(shí)候開始引入了system integration test的工作。
測(cè)試環(huán)境
與一般的項(xiàng)目一樣，我們需要不同的環(huán)境，如下：
性能測(cè)試和安全測(cè)試
這也是我們一般所說(shuō)的非功能性測(cè)試，對(duì)于性能測(cè)試我們定義了一些臨時(shí)的性能指標(biāo)，因?yàn)橛泻芏嗖淮_定性因素，所以這個(gè)是要在項(xiàng)目持續(xù)進(jìn)行修正的指標(biāo)，如下圖：
關(guān)于安全性測(cè)試，我們用到是比較常用的靜態(tài)代碼掃描Fortify用于JS的安全掃描,Lapse用于Java的安全掃描。
關(guān)于風(fēng)險(xiǎn)
對(duì)于這個(gè)項(xiàng)目來(lái)說(shuō)，最大的風(fēng)險(xiǎn)就是SAP系統(tǒng)的不確定性，由此引發(fā)的考慮是，pipline如何與SAP集成？
1. 客戶的SAP測(cè)試系統(tǒng)是一個(gè)第三方的系統(tǒng)，不僅極不穩(wěn)定，這些都是短期內(nèi)很難去和客戶協(xié)調(diào)解決的問題，而且我們只有讀的權(quán)限，并沒有寫的權(quán)限。導(dǎo)致我們?cè)陂_發(fā)platform的過程中不能很好的和SAP集成，影響開發(fā)進(jìn)度。
2. 當(dāng)我們做完開發(fā)，pipline需要執(zhí)行所有的測(cè)試，其中包括與SAP的集成測(cè)試，試想如果SAP不穩(wěn)定，那么集成測(cè)試很多時(shí)候都會(huì)因?yàn)檫@個(gè)失敗，怎樣去做持續(xù)集成？
3. 如果我們能得到穩(wěn)定的SAP環(huán)境，如何創(chuàng)建我們需要的數(shù)據(jù)呢？
對(duì)于測(cè)試策略來(lái)說(shuō)，我們通常還要考慮到比如cases management，bug分析與管理等，這里就不再累贅。重要的不是在于我們能做什么，而是我們這樣做能為項(xiàng)目帶來(lái)什么樣的價(jià)值。
