如何評價一個項目的過程質(zhì)量净刮？是從代碼的層面谓晌，還是從發(fā)現(xiàn)的 BUG 來統(tǒng)計具温，或者是其他信息蚕涤。如何有效記錄并分析每個測試階段（冒煙測試、系統(tǒng)測試等等）的問題以及反饋提測質(zhì)量铣猩？

今次的目標(biāo)是：打通整個軟件生命周期

分層自動化的目標(biāo)

實現(xiàn)代碼揖铜、服務(wù)、界面分層自動化的整體架構(gòu)目標(biāo)剂习，滿足金字塔式一體化分層管理

20180730215739.png

20180730^注：圖中，待實現(xiàn)的 sonar, gatest均已實現(xiàn)较沪，且mock service 統(tǒng)一為go mock

優(yōu)勢：

1. 各層測試目標(biāo)清晰鳞绕，資源統(tǒng)一管理；
2. 代碼層級持續(xù)日構(gòu)建尸曼，支持 merge 后自動構(gòu)建们何，作為冒煙測試檢查手段；
3. 可以集成新測試工具和測試框架控轿，展現(xiàn)測試報告冤竹，提升管理效率拂封，利于各層各節(jié)點質(zhì)量數(shù)據(jù)統(tǒng)計分析；
4. 統(tǒng)一自動化測試入口鹦蠕，便于測試冒签、開發(fā)自測統(tǒng)一管理（基礎(chǔ)建設(shè)完成后，后期考慮）钟病。

基于現(xiàn)狀萧恕，有必要提高開發(fā)自測參與度，從【單元測試】和【接口測試】層面都需要更自動化肠阱，給到測試更多的質(zhì)量反饋數(shù)據(jù)票唆。接著，漸進(jìn)式的改進(jìn)測試流程的狀態(tài)屹徘，最終完成實現(xiàn)平臺化走趋，完成測試平臺入口的統(tǒng)一

測試散點態(tài) ----> 測試流程化 ----> 測試平臺化

20180730220001.png

分層測試設(shè)計思想：

測試基礎(chǔ)服務(wù)

主要是指：持續(xù)構(gòu)建服務(wù)（Jenkins）、靜態(tài)代碼分析服務(wù)（Sonar）噪伊、配置管理服務(wù)（Git）簿煌、統(tǒng)一構(gòu)建工具管理（Maven），可以使用 Docker 來構(gòu)建酥宴。

20180730^注：目前CI 采用 gitlab Runner 啦吧，也未使用 Maven

測試基石層

主要是指：Unit Test

在該層，通過自動化單元測試的持續(xù)構(gòu)建拙寡，可以作為測試階段的第一道關(guān)卡授滓，完成冒煙測試工作。流程要以下步驟實現(xiàn)：

1. 建立提測項目的單元測試環(huán)節(jié)肆糕，在 Gitlab CI上完成構(gòu)建般堆；
2. 構(gòu)建項目，進(jìn)行代碼編譯诚啃，執(zhí)行不通過淮摔，打回，要求開發(fā)人員修復(fù)直到構(gòu)建成功為止始赎，并且記錄打回節(jié)點和原因和橙，作為提測質(zhì)量的依據(jù)；
3. 單元測試造垛，單元測試失敗魔招、覆蓋度不符合標(biāo)準(zhǔn)，打回五辽，要求開發(fā)人員修復(fù)直到單測成功為止办斑，并且記錄打回節(jié)點和原因，作為提測質(zhì)量的依據(jù)；只有通過第一輪 UnitTest 冒煙測試之后乡翅，才能進(jìn)入下一個環(huán)節(jié)鳞疲；
4. 靜態(tài)代碼分析，對源代碼進(jìn)行度量分析蠕蚜，比如代碼風(fēng)格尚洽、單元測試覆蓋率、圈復(fù)雜度波势、耦合度等翎朱，如不通過，記錄打回節(jié)點和原因尺铣，作為提測質(zhì)量的依據(jù)拴曲，自動化審核工具運行通過后，才有獲得提測準(zhǔn)入資格凛忿。

流程上 —— 增加 Sonar 靜態(tài)代碼分析測試

目前第1-3步澈灼，主要依賴開發(fā)自主完成，但是目前缺少必要的工具店溢，無法做到有效監(jiān)控叁熔，所以，暫時先從簡單的第4點入手床牧。

Sonar 具有代碼靜態(tài)檢查荣回、單元測試覆蓋率分析、代碼復(fù)雜度分析戈咳、jar依賴關(guān)系分析等多種功能心软；提供了對 IDE 的支持，可以在 Eclipse 和 IntelliJ IDEA 這些工具里聯(lián)機(jī)查看結(jié)果著蛙；同時 Sonar 還對大量的持續(xù)集成工具提供了接口支持删铃，可以很方便地在持續(xù)集成中使用 Sonar。

Go 可用 go report 踏堡，sonar 在18年5月份開始支持go

測試中堅層 Service & Integration Test

主要是API測試猎唁，緩存服務(wù)，日志服務(wù)等顷蟆。API 測試包括 HTTP诫隅、CBin 協(xié)議等。

測試用例完全掌握在測試人員手里帐偎，開發(fā)修復(fù) BUG 之后逐纬，只能等待測試人員驗證，交付過程效率低肮街。正確的姿勢是開發(fā)风题、測試協(xié)同工作判导，開發(fā)人員修復(fù) BUG 后即可通過平臺執(zhí)行用例嫉父，快速回歸沛硅，實現(xiàn) 0 等待，驅(qū)動過程質(zhì)量的提升绕辖。

因此摇肌，必要的API 冒煙測試顯示尤為重要，開發(fā)自助執(zhí)行測試提供的冒煙測試用例仪际。如果此環(huán)節(jié)不通過围小，會記錄節(jié)點并且發(fā)送郵件通知開發(fā)人員，開發(fā)人員根據(jù)測試報告树碱，排查存在問題的API肯适，進(jìn)行修復(fù)之后，再次提測成榜，直到通過為止框舔。

測試技術(shù)實現(xiàn)上

1. 針對 HTTP API，如支付網(wǎng)關(guān)赎婚，支付 PHP API刘绣，采用 SoapUI 工具生成用例，以 XML 方式存儲挣输，進(jìn)行測試纬凤。
2. 針對 CBin 協(xié)議等，例如賬號網(wǎng)關(guān)撩嚼，采用新的 PHPUnit 框架下停士，引入舊協(xié)議 lib 包進(jìn)行測試。
3. 針對 gRPC 服務(wù)绢馍，采用開發(fā)功能代碼與 go test 結(jié)合的方式進(jìn)行測試向瓷。—— 待優(yōu)化

流程上 —— 增加冒煙測試

重大變化的點：流程上,測試人員需要在開發(fā)完成任務(wù)前給到 API 測試用例

引入冒煙測試的目的：

• 提升QA概念舰涌，納入質(zhì)量監(jiān)控
• 提高準(zhǔn)入標(biāo)準(zhǔn)
• 減少時間損耗
• 快速響應(yīng)
• 理清接口數(shù)量猖任，服務(wù)數(shù)量，版本個數(shù)瓷耙，應(yīng)用場景朱躺，冒煙用例數(shù)

流程實施分兩個階段，分步前進(jìn)：

1. 第一階段搁痛，測試點覆蓋长搀，Xmind 給出功能點，開發(fā)進(jìn)行冒煙測試鸡典。

人工統(tǒng)計節(jié)點數(shù)據(jù)源请。可能存在的痛點是，提測谁尸，冒煙舅踪，打；再提測良蛮，再冒煙抽碌，再打回，而在上線時間緊湊的情況下决瞳，這樣的流程會增加開發(fā)的處理時間货徙，壓縮測試時間。

2. 第二階段皮胡，系統(tǒng)評估質(zhì)量和執(zhí)行用例痴颊。

設(shè)定由開發(fā)、測試都認(rèn)可的預(yù)設(shè)條件作為冒煙測試階段屡贺，通過之后則相當(dāng)于具備了正式提測條件祷舀。如未通過，則打回烹笔，同時記錄打回的節(jié)點裳扯，作為提測質(zhì)量依據(jù)。開發(fā)自助通過冒煙測試谤职，完成冒煙階段的任務(wù)饰豺，可雙向節(jié)省時間，更加關(guān)注業(yè)務(wù)實現(xiàn)允蜈。

但是冤吨，此階段測試給出的測試功能點，舊接口有現(xiàn)成的測試用例可以直接部署饶套，新接口需要Mock Service 才能實現(xiàn)漩蟆。因此，我們的流程上還需要將 Mock Service 納入考慮范圍妓蛮。

方案傳送帶：http://gitlab.xxx.cn/testing-group/base/issues/20

新增 Mock Server

Mock Server 在們的支付網(wǎng)關(guān)測試和新接口開發(fā)過程中怠李，顯示尤為重要，最突出的一個貢獻(xiàn)應(yīng)該是可以解決接口只在文檔中定義蛤克，而實操中界限不清捺癞，邏輯含糊模糊不清，人工溝通出現(xiàn)紕漏不斷的問題构挤。如髓介，常見的返回格式，編碼不統(tǒng)一筋现，類型出錯唐础，多版本邏輯箱歧，返回碼定義模糊。當(dāng)存在這樣一個Mock系統(tǒng)時一膨，我們隨時可以告知任何人叫胁，按照我們的要求來接入。

方案傳送帶：http://gitlab.xxx.cn/testing-group/base/issues/18

新增統(tǒng)一 API 管理平臺

方案傳送帶：http://gitlab.xxx.cn/testing-group/base/issues/18#note_35670

測試表現(xiàn)層

UI 測試的投入需要非常慎重汞幢。如果頁面元素頻繁變動，一般不建議馬上開展UI自動化測試微谓，但可以轉(zhuǎn)變測試思想：

• 業(yè)務(wù)主要入口和頁面樣式兼容性可以與業(yè)務(wù)邏輯分離森篷，只做頁面版本檢查。利用生成的快照豺型，在上下兩個版本之間進(jìn)行對比仲智，如此，只需要在大版本需要切換時姻氨，做基準(zhǔn)數(shù)據(jù)準(zhǔn)備即可钓辆。日常兼容性校驗均可由檢測快照來完成自動化 check 工作。技術(shù)方案采用 Selenium肴焊。
• 長期（6 個月以上）穩(wěn)定的功能前联，并且頁面元素有清晰的定義，可以投入核心業(yè)務(wù)的UI自動化測試娶眷。區(qū)分主要業(yè)務(wù)邏輯和分支結(jié)構(gòu)似嗤，進(jìn)行常規(guī)元素檢查〗斐瑁可使用關(guān)鍵字驅(qū)動烁落，也可采用行為驅(qū)動 BDD 的方式。目前我們采用Cucumber豌注。

方案傳送帶：http://gitlab.xxx.cn/testing-group/base/issues/19

結(jié)尾

各層的測試報告單獨給出伤塌，每層測試報告中匯總測試的功能模塊，測試用例轧铁，通過率等每聪。

每個點的數(shù)據(jù)統(tǒng)計。----[數(shù)據(jù)服務(wù)需要修改的內(nèi)容]