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

自動化測試是王道

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

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

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

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

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

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

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

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

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

“安全是每一個人的問題”！互聯(lián)網(wǎng)安全漏洞頻繁爆發(fā)，安全問題已經(jīng)成為每個產(chǎn)品迫切需要關(guān)注和解決的問題，安全測試將需要貫穿于軟件開發(fā)的整個生命周期。同時，給軟件測試人員帶來了更多的機遇和挑戰(zhàn)，要求具備更多的安全相關(guān)知識（其中還包括更多的計算機基礎(chǔ)知識），掌握已有的安全測試相關(guān)技術(shù)，從而在軟件開發(fā)的各個階段做好安全相關(guān)的分析和測試工作。盡管有些團隊已經(jīng)將安全跟整個開發(fā)實踐結(jié)合起來，但培養(yǎng)每個人在每個階段的安全意識還相當(dāng)?shù)闹匾剿餍碌陌踩珳y試技術(shù)、方法還有很多空間。

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

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

優(yōu)化業(yè)務(wù)價值

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

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

傳統(tǒng)方式下，QA角色主要專注于保證軟件產(chǎn)品在類產(chǎn)品環(huán)境下的質(zhì)量。隨著持續(xù)交付的出現(xiàn)，QA角色逐漸轉(zhuǎn)變到需要分析軟件產(chǎn)品在產(chǎn)品環(huán)境下的質(zhì)量。產(chǎn)品環(huán)境下的QA（QA in production），就是要求QA角色在做好產(chǎn)品上線前的質(zhì)量保證工作前提下，做好軟件產(chǎn)品在產(chǎn)品環(huán)境下的質(zhì)量分析。具體做法有：

（一）引入產(chǎn)品系統(tǒng)的監(jiān)控， 制定檢測條件，找出產(chǎn)品環(huán)境下使用的質(zhì)量度量。比如，利用網(wǎng)站分析工具收集用戶使用應(yīng)用程序的數(shù)據(jù)，分析數(shù)據(jù)量需求、產(chǎn)品的性能趨勢、用戶的地域特征、用戶的行為習(xí)慣和產(chǎn)品在同類型產(chǎn)品市場的占有率等。

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

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

通過對產(chǎn)品環(huán)境下的軟件質(zhì)量進行分析，將有利于協(xié)助“產(chǎn)品優(yōu)于項目”實踐，幫助優(yōu)化業(yè)務(wù)價值，做好企業(yè)產(chǎn)品的創(chuàng)新工作。需要注意的是，產(chǎn)品環(huán)境下的QA可能會導(dǎo)致有些組織走的太遠而忽視產(chǎn)品上線前的質(zhì)量保證，它只對那些已經(jīng)執(zhí)行并有一定程度持續(xù)交付實踐的組織有價值。

總結(jié)

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

本文轉(zhuǎn)載自