2015年11月，ThoughtWorks發布了新一期的技術雷達。技術雷達是以獨特的形式記錄ThoughtWorks技術顧問委員會對行業產生重大影響的技術趨勢討論的結果，為從CIO到開發人員在內的各方利益相關者提供價值。這期雷達的技術趨勢主要體現在：受到熱捧的微服務相關技術，逐步成熟的以Docker為典型的容器化生態系統，備受企業和用戶關注的信息安全問題。本文就從這幾個新趨勢來分析一下給軟件測試帶來了哪些影響。

自動化測試是王道

在這個快速變化發展的時代，任何一款產品想要在市場具備競爭力，必須能夠快速適應和應對變化，要求產品開發過程具備快速持續的高質量交付能力。而要做到快速持續的高質量交付，自動化測試將必不可少。同時，自動化測試也不是用代碼或者工具替代手工測試那么簡單，有了新的特點和趨勢：針對不同的產品開發技術框架有著不同的自動化技術支持，針對不同的業務模式需要不同的自動化測試方案，從而使得自動化測試有著更好的可讀性、更低的實現成本、更高的運行效率和更有效的覆蓋率。來自技術雷達的下列主題分別體現了自動化測試的這些特點：

• 針對微服務的消費端驅動的契約測試（Consumer-driven contract testing)，有助于解決隨著服務增多帶來集成測試效率低和不穩定的問題。消費端驅動的契約測試是成熟的微服務測試策略中核心的組成部分。
• 專門用于測試和驗證RESTful服務的工具REST-assured，它是一個Java DSL，使得為基于HTTP的RESTful服務編寫測試變得更加簡單。REST-assured支持不同類型的REST請求，并且可以驗證請求從API返回的結果。它同時提供了JSON校驗機制，用于驗證返回的JSON數據是符合預期的。
• 安卓系統功能測試工具Espresso，其微小的內核API隱藏了復雜的實現細節，并幫助我們寫出更簡潔、快速、可靠的測試。
• ThoughtWorks開源的輕量級跨平臺測試自動化工具Gauge，支持用業務語言描述測試用例，支持不同的編程語言，支持所支持平臺的并行執行。
• 用于針對UI的自動化測試構建頁面描述對象的Ruby庫Pageify，該工具關注于更快的執行測試以及代碼的可讀性，并可以很好的配合Webdriver或是Capybara使用。
• 專門用于iOS應用開發的開源行為驅動開發測試框架Quick，支持Swift、Objective-C，它和用來做測試驗證的Nimble捆綁發布。Quick主要用于Swift和Objective-C程序行為的驗證。它和 RSpec和Jasmine具有相同的語法風格，基礎環境很容易建立。Quick良好的結構和類型斷言使得測試異步程序更加容易。Quick擁有現成的Swift和Objective-C規范文件模板，開發者只需簡單幾步，即可對應用進行快速測試。

工具很重要，設計不可少！自動化測試工具云集，但做自動化也不要沖動，需要重視以下幾點：

1. 綜合考慮項目技術棧和人員能力，采用合適的框架來實現自動化；
2. 結合測試金字塔和項目具體情況，考慮合適的測試分層，如果能夠在底層測試覆蓋的功能點一定不要放到上層的端到端測試來覆蓋；
3. 自動化測試用例設計需要考慮業務價值，盡量從用戶真實使用的業務流程／業務場景來設計測試用例，讓自動化優先覆蓋到最關鍵的用戶場景；
4. 同等看待測試代碼和開發代碼，讓其作為產品不可分割的一部分。

云技術、容器化和開源工具使得測試成本下降

測試環境的準備在過去是一個比較麻煩和昂貴的事情，很多組織由于沒有條件準備多個測試環境，導致測試只能在有限的環境進行，從而可能遺漏一些非常重要的缺陷，測試的成本和代價很高。隨著云技術的發展，多個測試環境不再需要大量昂貴的硬件設備來支持，加上以Docker為典范的容器技術生態系統也在逐步成長和成熟，創建和復制測試環境變得簡單多了，成本大大的降低。技術雷達推薦的鳳凰環境（Phoenix Environment），它使用鳳凰服務器（Phoenix Server）的模式，能夠以自動化的方式支持測試、開發、UAT和災難恢復所需的新環境準備。這一技術由上期的評估環上升到了采用環，表明它已經得到了驗證和認可，是可以放心使用的技術。

另一方面是大量開源工具的出現，這些工具往往都是輕量級的、簡單易用，相對于那些重量級的昂貴的測試工具更容易被人們接受。測試工作有了這些開源工具的幫助，將更加全面、真實的覆蓋到要測試的平臺、環境和數據，將會加快測試速度、降低測試成本；更重要的一點，有了這些工具，讓測試人員能夠騰出更多的時間來做測試設計和探索性測試等更有意思的事情，使得測試工作變得更加有趣。新技術雷達提到的開源工具有：Mountebank、Postman、Browsersync、Hamms、Gor和ievms等。

• 在企業級應用中，對組件進行良好的測試至關重要，尤其是對于服務的分離和自動化部署這兩個關系到微服務架構 是否成功的關鍵因素，我們更需要更合適的工具對其進行測試。Mountebank就是一個用于組件測試的輕量級測試工具，可以被用于對 HTTP、HTTPS、SMTP和TCP進行模擬（Mock）和打樁（Stub）。
• Postman是一個在Chrome中使用的REST客戶端插件，通過Postman，你可以創建請求并且分析服務器端返回的信息。這個工具在開發新的API或者實現對于已有API的客戶端訪問代碼時非常有用。Postman支持OAuth1和OAuth2，并且對于返回的JSON和XML數據都會進行排版。通過使用Postman，你可以查看你通過Postman之前發起過的請求，并且可以非常友好的編輯測試數據去測試API在不同請求下的返回。同時，雖然我們不鼓勵錄屏式的測試方法，但是Postman提供了一系列的拓展允許我們將它作為跑測試的工具。
• 隨著網站應用所支持設備的增多， 花在跨設備測試上的代價也在不斷增大。Browsersync能夠通過同步多個移動設備或桌面瀏覽器上的手工瀏覽器測試來極大的降低跨瀏覽器測試的代價。通過提供命令行工具以及UI界面，Browsersync對CI構建非常友好，并且能夠自動化像填寫表單這樣的重復任務。
• 在軟件開發領域，盲目地假設網絡總是可靠，服務器總是能夠快速并正確的響應導致了許多失敗的案例。Hamms可以模擬一個行為損壞的HTTP服務器，觸發一系列的失敗，包括連接失敗，或者響應緩慢，或者畸形的響應，從而幫助我們更優雅的測試軟件在處理異常時的反應。
• Gor可以實時捕獲線上HTTP請求，并在測試環境中重放這些HTTP請求，以幫助我們使用到這些產品環境數據來持續測試我們的系統。 使用它之后可以大大提高我們在產品部署，配置修改或者基礎架構變化時的信心。
• 盡管IE瀏覽器的使用量日益萎縮，但對很多產品而言IE瀏覽器的用戶群依然不可忽視，瀏覽器兼容性仍然需要測試。這對于喜歡使用基于Unix的操作系統進行開發的人來說還是件麻煩事。為了幫助解決這個難題，ievms提供了實用的腳本來自動設置不同的Windows虛擬機鏡像來測試從IE6到Microsoft Edge的各種版本瀏覽器。

安全測試貫穿整個生命周期

“安全是每一個人的問題”！互聯網安全漏洞頻繁爆發，安全問題已經成為每個產品迫切需要關注和解決的問題，安全測試將需要貫穿于軟件開發的整個生命周期。同時，給軟件測試人員帶來了更多的機遇和挑戰，要求具備更多的安全相關知識（其中還包括更多的計算機基礎知識），掌握已有的安全測試相關技術，從而在軟件開發的各個階段做好安全相關的分析和測試工作。盡管有些團隊已經將安全跟整個開發實踐結合起來，但培養每個人在每個階段的安全意識還相當的重要，探索新的安全測試技術、方法還有很多空間。

技術雷達上列出的安全測試相關的技術和工具有：Bug bounties、威脅建模（Threat Modelling）、ZAP和Sleepy Puppy。

• Bug bounties是一個安全漏洞舉報獎勵制度，越來越多的組織開始通過Bug bounties鼓勵記錄常見的安全相關的Bugs，幫助提高軟件質量。
• 威脅建模（Thread modeling）是一組技術，主要從防御的角度出發，幫助理解和識別潛在的威脅。當把用戶故事變為“邪惡用戶故事”時，這樣的做法可給予團隊一個可控且高效的方法使他們的系統更加安全。
• ZED Attack Proxy (ZAP)是一個OWASP的項目，允許你以自動化的方式探測已有站點的安全漏洞。可以用來做定期的安全測試，或者集成到CD的Pipleline中提供一個持續的常規安全漏洞檢測。使用ZAP這樣的工具并不能替換掉對安全的仔細思考或者其他的系統測試，但是作為一個保證我們的系統更安全的工具，還是很值得添加到你的工具集里。
• Sleepy Puppy是Netflix公司近期開源的一款盲打XSS收集框架。當攻擊者試圖入侵第二層系統時，這個框架可用于測試目標程序的XSS漏洞。XSS是OWASP的Top10的安全威脅，Sleepy Puppy可以用來同時為幾個應用完成自動安全掃描。它可以自定義盲打方式，簡化了捕獲、管理和跟蹤XSS漏洞的過程。Sleepy Puppy還提供了API供ZAP之類的漏洞掃描工具集成，從而支持自動化安全掃描。

優化業務價值

大多數軟件都是做項目的模式，在不同的檔期內進行計劃、實現和交付。敏捷開發極大的挑戰了這種模式，通過在開發過程中各個階段進行的分析和測試工作，持續的發現新的需求，使得需求更趨于合理化，更能體現業務價值。精益創業的技術，如觀察需求的A/B測試，進一步削弱了這種心態。技術雷達推薦“產品優于項目（Product over project）”，認為大多數的軟件開發工作應該遵循精益企業的引領，將自己定義為構建支持業務流程的產品。這樣的產品并沒有所謂的最終交付，更多的是一個探索如何更好的支持和優化業務流程的過程，只要業務依然有價值就會不斷持續下去。

作為軟件開發中的關鍵角色、負責軟件測試的QA人員，通過從用戶角度對軟件的測試，結合自身對軟件產品的了解，對優化業務價值將會起到舉足輕重的作用。軟件測試不僅是檢驗軟件是否滿足規定的需求或弄清預期結果與實際結果之間的差別的過程，還需要有意識的對需求進行持續的驗證和優化，對業務的趨勢和風險進行分析。如果能在開發過程中結合使用BDD（行為驅動開發）的思想，統一團隊對需求的認識，利用團隊的力量來優化業務將會達到事半功倍的效果。

傳統方式下，QA角色主要專注于保證軟件產品在類產品環境下的質量。隨著持續交付的出現，QA角色逐漸轉變到需要分析軟件產品在產品環境下的質量。產品環境下的QA（QA in production），就是要求QA角色在做好產品上線前的質量保證工作前提下，做好軟件產品在產品環境下的質量分析。具體做法有：

（一）引入產品系統的監控， 制定檢測條件，找出產品環境下使用的質量度量。比如，利用網站分析工具收集用戶使用應用程序的數據，分析數據量需求、產品的性能趨勢、用戶的地域特征、用戶的行為習慣和產品在同類型產品市場的占有率等。

（二）收集產品環境下最終用戶的反饋，對反饋進行分類分析。這些反饋可能有：

• 缺陷：需要進行優先級劃分，確定是否需要修復；并且對這些缺陷進行根源分析，在以后的開發過程中盡量避免同類型的缺陷再次出現。
• 抱怨：對于抱怨需要分析其背后的原因，可能正是能夠幫助我們改進和優化業務價值的好機會。
• 建議：一般用戶可能難以提出高質量的建議，需要我們在收集反饋的時候下點功夫，有針對性的去收集。一旦收集到了建議，將是對業務價值優化非常有利的。

通過對產品環境下的軟件質量進行分析，將有利于協助“產品優于項目”實踐，幫助優化業務價值，做好企業產品的創新工作。需要注意的是，產品環境下的QA可能會導致有些組織走的太遠而忽視產品上線前的質量保證，它只對那些已經執行并有一定程度持續交付實踐的組織有價值。

總結

軟件測試是一項技術工作，但軟件測試領域的問題不僅僅是技術問題。隨著自動化程度越來越高，不斷有人懷疑QA存在的必要性，從前面的分析可以看到，新趨勢給QA提出了更高的要求，帶來了更多的機遇和挑戰，相信好的QA是不可能簡單的被取代的。

本文轉載自