摘要：軟件測試的最高層次需求是：UI測試，也就是這個軟件“長得好不好看”。
為了讓讀者更好地理解測試，我們從最基礎的概念開始介紹。以一個軟件的“輪回”為例，下圖展示了一個軟件的研發流程。隨着軟件規模的不斷增大，一個軟件動輒百萬行的代碼，想要單靠人工檢查或者程序猿的技術本身保證質量已經變得不現實。因此，測試成為軟件流程中必不可少的環節。
測試過程中會涉及不同的需求，以Mike Cohn在他的著作《Succeeding with Agile》一書中提出的“測試金字塔”寶圖鎮樓為例， 從下至上對應的測試需求分別為：單元測試，服務測試，用戶界面測試。
這個金字塔形象地反應了筆者這些程序猿面臨的問題。我們知道馬斯洛的需求層次理論，在其著名的“馬斯洛需求金字塔”中展示了一個人的不同層次的需求。筆者感覺這兩個金字塔有很多相似之處。
個人最基本的需求是生理需求與安全需求，對應測試中就是“單元測試”。如果一個程序中的單元測試都不能保證，其上層的測試就無需談起。而這部分也是需要花費大量精力去做的事情。每個開發人員在編寫“單元測試”，並且完成測試之后，保證自己的服務能夠正常運行才會考慮服務測試。就相當於自己吃飽了，安全了，才有力氣和意願去和別人交流。
此時，我們進入到下一個層次“社交需求”，服務之間的通信就像人類之間的“社交”，大家都要遵循一定的規則（程序接口，各種規范），才可以進行順暢的通信。在日常生活的這個“交流”過程中，難免會出現一些誤差，導致錯誤。然而，軟件中出現一點點錯誤，可能導致不小的麻煩。例如2017年的這個新聞：以色列報紙“哈雷茲”報道說，一名巴勒斯坦男子被以色列警方逮捕，當時他在自己的臉書賬號上寫了“早上好”，Facebook自動翻譯服務錯誤地用希伯來語翻譯為“攻擊他們”，用英語翻譯為“傷害他們”，Facebook對此表示歉意。
軟件測試的最高層次需求是：UI測試，也就是這個軟件“長得好不好看”。這里引用一個詞語“一想之美”，每個人心中關於美的定義都不相同，那什么樣的軟件才是“美”的？我們又應該如何測試？（終於湊夠了領導要求的字數）。
下面是恰飯時間，不感興趣的童鞋可以刷其他文章了。
單元測試需要程序猿自己在開發過程中編寫，那么服務測試如何實現自動化？
這里華為雲提供了雲測（CloudTest）的測試平台。
官方介紹：雲測（CloudTest）是面向軟件開發者提供的一站式雲端測試平台，覆蓋功能測試、接口測試，融入DevOps敏捷測試理念，幫助您高效管理測試活動，保障產品高質量交付。
功能測試
雲測融入全生命周期追溯、團隊多角色協作、敏捷測試、需求驅動測試等理念，覆蓋測試需求管理、測試任務分配、測試任務執行、測試進度管理、測試覆蓋率管理、測試結果管理、缺陷管理、測試報告、測試儀表盤，一站式管理功能和自動化測試，提供適合不同團隊規模、流程的自定義能力，幫助多維度評估產品質量，高效管理測試活動，保障產品高質量交付。
接口測試
基於接口URL或Swagger文檔快速編排接口測試用例，集成流水線，支持微服務測試、分層自動化測試。測試用例免代碼編寫，技術門檻低，適合接口開發者、接口消費者、測試人員、業務人員等不同角色使用。一鍵導入Swagger接口定義自動生成腳本模板，基於腳本模板組裝編排、管理接口自動化測試用例。支持HTTP和HTTPS協議，可視化用例編輯界面，豐富的預置檢查點、內置變量，支持自定義變量、參數傳遞、持續自動化測試。
在上面的描述中，我們引入了測試金字塔的概率，介紹了單元測試和服務測試。這里我們嘮嘮最上面的是UI測試。基於對UI測試的粗淺了解，筆者也將UI測試畫了一個金字塔。
最下層的“功能測試”對應的是測試UI界面中的“交互”功能。例如，一個按鈕是否能夠點擊，下拉框是否顯示等。如果說UI測試是看一個人是不是好看，功能測試就是說，一個人五官是否齊全，並且能否完成正常的生理功能。一般的測試團隊的測試可能包括以下內容：
- 控件
- 快捷鍵
- 文案
- 圖片
- 布局
在人工測試時，會對界面中的以上元素進行檢查，比如在交互的地方會手動點擊，查看交互結果是否正常。這部分工作現在有一些自動化工具可以完成，但是其過程需要包含兩個動作：錄制和回放。錄制指的是測試人員根據測試經理設計的測試用例操作軟件，在操作過程中使用自動化工具，將這個操作過程“錄制”下來，然后保存用例。而回放是自動化工具提供自動執行“用例”的能力，在需要測試的環境中，回放上一步錄制的用例。若回放失敗，則認為被測環境出現異常，與錄制環境中期望的結果發生差異。導致這種失敗的情形多種多樣：環境不穩定，網絡超時，軟件升級等。
一個人僅僅有五官還不夠，還需要有基本的生理功能，比如說話是否伶俐，耳朵是否靈敏。對應到UI測試的性能測試中，就是要求一個軟件不僅能夠完成基本的功能，並且不能出現性能的問題。比如我們開發的打賞功能，若有一個用戶發表了一篇熱文，短時間有千萬人打賞，但是這個小程序因為性能掛掉了，就會導致用戶損失很多錢。又比如當用戶打開這個小程序，一篇文章的加載卻需要超過一分鍾，嚴重影響用戶的體驗。
在這個看臉的世界，一個人長得漂亮就會帶來許多便利。一千個人心中有一千個哈姆雷特，每個人的標准也不一樣，那么如何判斷一個人是否漂亮呢，就是讓不同的評委進行評判。以此類推，評判一個軟件是否“好看”，能否經得起各種環境和不同系統的“認證”，就需要對軟件進行兼容性測試。在移動端剛開始普及時，許多PC端的網頁需要對移動端進行專門的適配，其工作量不亞於重新開發一塊應用。雖然現在許多架構支持多終端的自動適配，但是，你永遠不知道用戶使用的是哪一種設備，在什么環境中使用。因此，對軟件進行兼容性測試變得越來越重要。
前段時間流行過一個詞“小而美”。有些程序猿也說，我們要做一款“小而美的應用”。這個“美”不僅需要內功夠硬，在UI設計中花大量功夫，在測試階段也需要考慮兼容性問題。說了這么多，那兼容性測試究竟應該怎么做呢？下面我們要做的是對兼容性測試的條件進行“庖丁解牛”式的詳細描述。（趕時間的同學可以離開了，下面是大量描述）。
- 測試環境
- 環境搭建
- 環境管理
- 環境升級
- 機器維護
對於正在看這篇文章的讀者來說，想必手里至少有一個手機或者一台電腦。手機是什么牌子的？手機系統是什么樣的？電腦是什么系統的以及屏幕分辨率是多少？這篇文章在這些不同的環境中是否都能夠正常顯示？要想回答這些問題，在進行兼容性測試時我們的測試人員就需要搭建環境。雖然不能完全包含市面上所有界面的機器型號，但是至少可以覆蓋目前主流的設備和系統。假設測試人員現在搭建了至少 1000 種環境，那么如何有效地管理這1000種環境呢？如果其中一個測試環境出現問題了，要怎么進行維護呢？在維護過程中又是如何保證測試業務正常執行？又或者其中一個系統有了最新版本，我們如何進行升級？(后面廣告時間可以提供一站式解決方案。)
- 測試用例
- 設計用例
- 編寫用例
- 調試用例
- 維護用例
有了測試環境之后需要有測試用例，這里同樣也涉及測試用例的設計、編寫、調試和維護的過程。根據測試經理或者設計人員給出的功能點，需要對UI中的頁面進行測試。細心的同學發現了，這個用例的概念不是功能測試中才有的么？在兼容性測試中同樣需要用用例。比如，對於用戶登錄這一功能，在一些軟件中，只有登錄之后才能進行各種操作，並且還可能需要驗證碼。此時需要結合功能測試中的能力，跳轉到目標頁面，然后對該頁面進行兼容性測試。具體來說，是以a環境為基礎，對UI界面截圖，同時在b環境中對UI界面截圖，比較兩個不同環境下的截圖是否一致。在實際的兼容性測試工作中，涉及的問題遠不止以上列舉的，比維護用例為例，由於軟件升級、環境改變或者是系統不同（ios，android），可能導致以前編寫的用例在后續一段時間內失敗。這時就會面對一個取舍的問題，維護用例的成本，自動化進行兼容性測試的收益。那還要不要進行自動化的兼容性測試。這就需要業務經理根據自身情況進行抉擇。
- 測試執行
- 用例管理
- 執行機調度
- 測試能力
在執行階段，我們需要做一件事：對比兩張圖片，判斷是否一致。這一句看似簡單的話語，只有做過圖像的童鞋才能理解其中的辛酸。現在假設我們可以輕松地完成對比圖片的工作，那么接下來，如何在最短時間使用最少的資源去運行最多的用例？這其實是一個多目標優化問題，而且其中的優化目標還可能存在沖突。在解決這些問題之后，歡迎來到下一個坑。
- 測試報告
- 報告查看
- 報告管理
- 報告修改
- 報告更新
最后一步的難點在哪呢？要想確定UI中是否存在兼容性問題，自動化能做的只能是根據事先約定的“標准”進行判斷，但是由於這些標准大部分都是比較模糊的，因此最終的測試結果往往需要測試人員進行確認。由用戶最終確定是否通過兼容性測試。對於一些出現誤報的區域，還需要用戶進行交互式的處理，在后續執行過程中對這些區域進行特殊處理，這個過程就類似用例的維護。
那說了這么多廢話，兼容性測試怎么做？ 我需要自己買那么多手機，搭建環境，編寫管理系統。。。搞這么多工作么？
下面是恰飯時間，不感興趣的童鞋可以刷其他文章了。
華為雲提供了 移動應用測試 平台MobileAPPTest。
只需要點擊上面這個鏈接，跳轉到如下頁面，點擊“立即體驗”
再按照如下步驟進行點擊。
即可到達我們的兼容性測試配置頁面，選擇自己喜歡的手機類型、希望覆蓋的測試人群，想要測試的測試對象。記得要先充值。
充錢之后，點擊運行就可以去睡覺了。測試結束之后會自動生成一個測試報告，點擊測試報告查看結果，齊活兒。
本文分享自華為雲社區《軟件“美不美”，UI測試一下就知道》，原文作者：Self-Consistent F 。