軟體測試首先需要關注測試物件，不同種類的測試物件的測試策略和測試技術會有顯著區別。測試物件即有傳統的Web服務、移動APP，也有新興的微服務和IoT裝置。

測試物件的識別

移動APP

Android和iOS手機客戶端依然是網際網路toC創業的首選產品模式。移動App可以分為Web App、混合App和本地App三種模式，2016年以React Native為代表的技術又帶火了移動跨平臺開發。跨平臺開發可以幫助開發者複用大部分程式碼，但依然無法解決讓開發者頭疼的Android系統碎片化問題。移動相容性測試仍然是針對Android機型碎片化的主要測試手段。

Web服務

B/S結構的Web服務依然是很典型的IT產品交付形式，尤其是面向企業客戶的產品。同時很多遺留IT系統仍然使用SOA的架構方式。對新系統而言，前後端分離是B/S結構的標配。後端無論採用什麼語言和框架，和前端的介面基本都是RESTful化的，甚至一些框架可以幫助生成Swagger標準的介面描述文件。MVC和MVVM模式的普及使得前端架構模式化，最重要完成了分層化，配合Jasmine等JavaScript單元測試框架，讓前端程式碼質量不再是焦油坑。

微服務

微服務架構被普遍認為是一種比分散式單體架構更優的架構模式，可以降低服務耦合度，減輕伺服器資源浪費，提升交付和運維效率。微服務之間採用API的呼叫方式降低了服務的耦合度，微服務框架如Spring Boot對Swagger的內建支援也提高了微服務RESTful介面的標準化水平，這些都提升了服務的可測性。

微服務數量多，每個微服務職能獨立，每個微服務使用獨立流水線作快速交付，測試模式和傳統單體大服務架構有顯著區別，需要的不是

物聯網裝置

物聯網市場發展迅速，特別是智慧家居、車聯網、可穿戴裝置、智慧工廠等領域。共享單車最近非常火熱，其車鎖和定位裝置就是典型的物聯網終端。物聯網終端內建實時嵌入式系統，收集感測器資料做邊緣計算，並通過Wi-Fi、4G、NB-IoT等接入方式連線手機裝置或者雲端服務。物聯網裝置執行環境苛刻，並且會涉及個人隱私資料甚至生命安全、工廠和基礎設施的安全執行等，因此防黑客侵入的安全測試和防意外事故的遍歷測試和壓力測試等對物聯網產品至關重要。

公司的業務決定了公司的組織和流程。根據康威定律，開發團隊的組織結構決定了產品架構。網際網路公司專注於創造市場需要客戶滿意的產品，同時需要根據市場和政策環境及時調整產品競爭策略。產品的釋出週期越來越短，產品需求頻繁發生變更，產品架構頻繁發生重構。這些都對測試活動和產品質量保證提出了巨大挑戰。以上挑戰決定了DevOps模式的測試組織和流程明顯區別於傳統敏捷模式：

測試活動的質量目標發生變化

測試活動的質量目標由單純驗證產品功能需求、非功能需求擴充套件為保證客戶滿意和產品的業務可續。測試團隊會站在使用者的角度考察產品的易用性和可用性，同時會監控生產環境的PV、UV、峰值吞吐量等關鍵指標，並納入測試場景設計。

DevOps的閉環敏捷模式

敏捷不僅僅體現在開發和測試活動中，業務面也使用敏捷的流程，形成閉環的敏捷。DevOps會向前連線市場團隊和產品經理，向後連線客服團隊，形成Market-Product-Develop-Operation-Customer的閉環敏捷價值鏈。產品資訊的透明快速流動對敏捷的成功至關重要。測試人員會和產品經理同時獲得到來自市場的產品反饋，這些反饋會變成測試需求融入測試活動。

QA和開發的角色融合

在兩個披薩原則的團隊中，全棧程式設計師端到端地負責產品的開發、測試和運維，承擔了QA和運維人員的角色。極客風格的全棧程式設計師傾向於使用自動化的測試框架。自動化測試可以覆蓋的越來越多，解放出來的手工測試人員會向開發轉型。

自動化的持續整合

持續整合的自動化程度越來越高，每個公司的實踐會有不同，藉助Jenkins等CI工具可以實現從程式碼提交到自動單元測試再到構建打包的持續整合，甚至和自動化部署、自動化測試打通。在持續整合鏈條上，自動化測試將覆蓋開發環境、測試環境、類生產環境和生成環境上的測試。

測試左移

產品經理使用業務語言描述產品需求，開發人員使用程式語言完成開發，雙方對需求的理解有時會產生偏差。BDD的方式可以幫助開發人員和產品經理對需求達成一致的理解，配合TDD的開發方式可以保證開發結果滿足需求預期。

產品架構的分層模型決定了測試金字塔依然有效。通過單元測試、服務和API測試、效能測試、前端測試、移動App測試的組合可以覆蓋B/S架構和雲服務+移動客戶端形式產品的測試。DevOps模式下測試自動化水平高，通過整合流水線完成和CI/CD打通的持續測試。一些技術發展為自動化測試的效率和質量提升提供了利器。

Selenium

Selenium已經成為前端自動化測試的事實標準，主流瀏覽器都提供對Web Driver的支援，Page Object的設計模式可以實現模組化的測試，Selenium也支援對多瀏覽器的併發測試。Web Driver協議已經提交到W3C做標準化工作，未來將成為前端自動化測試的行業標準。

但是現在Selenium還有一些缺點，例如使用Selenium需要一定的程式設計能力，因此就限定了使用人員角色，不熟悉程式設計的產品經理和驗收測試人員只能手工做驗收測試。另外如果前端頁面頻繁變動，頁面變動之後就得修改測試指令碼，這種情況指令碼維護成本大。

事實上沒有一種測試型別是能夠100%勝任產品測試的，前端自動化測試更適合針對相對穩定的頁面做迴歸測試和冒煙測試，對覆蓋不到的可以通過API級別測試或者手工測試來補充覆蓋。

容器化

Docker為代表的容器生態系統發展迅速，容器叢集管理系統Docker Swarm和Kubernetes可以幫助統一部署、管理、維護Docker叢集。Jenkins等CI工具也提供了對Docker的支援。由於Docker可以方便地將執行時環境連同應用一併打包到映象中，因此可以快速建立和複製標準化的測試環境，並且保持測試環境和開發環境一致性。

Swagger

Swagger 作為設計、構建和文件化RESTful API的工具，其OpenAPI標準已經成為事實上的RESTful API定義標準。在Swagger Editor中，基於YAML語法定義RESTful API就可以自動生成API描述文件。一些框架如Spring Boot也提供了對Swagger的原生支援。Swagger描述文件可以作為前後端分離開發中的介面“契約”。測試人員可以把Swagger描述檔案當作介面需求開發API測試。

資源編排和自動部署工具

測試環境管理分兩個層面，一個是環境的標準化，另外一個是環境管理的自動化。產品從開發到上線一般經過開發環境、測試環境、類生產環境、生產環境。每一個環境的差異都可能產生未知問題。手工搭建和管理測試環境費時並且易出錯，測試人員需要求助於開發人員獲取必要的作業系統資訊、環境變數、資料庫和中介軟體版本資訊、配置指令碼和安裝步驟等才能順利地搭建起一套測試環境。在環境統一這一層面，環境編排器可以幫助統一定義各種環境，保持標準化、可配置和易維護。在環境管理自動化這一層面，可以通過一些自動化管理工具完成批量系統設定，批量程式部署，批量執行命令等。華為軟體開發雲（DevCloud）的部署服務就為使用者提供了基於Ansible的部署能力。

雲化的壓力測試和移動APP測試

壓力測試作為非功能性測試的重要一環，在傳統模式下主要考量的是應用伺服器與資料庫的最大承載能力，在雲環境下增加了對雲主機彈性伸縮的能力測算。移動APP測試主要解決的是碎片化終端下的功能、效能及相容性覆蓋測試，主要考量的是覆蓋的機型範圍及如何高效自動化完成整體測試，形成全面的分析報告。

測試用例的管理是所有測試的基礎，在測試的不同階段（如迴歸測試、冒煙測試）都需要圍繞測試用例進行校驗，通過“需求-任務-用例-缺陷追溯”各環節的迭代來確保需求的測試覆蓋率，並提供測試驗收報告。自動化測試幫助大幅提升測試效率、穩定性和反饋速度。