2015年11月，ThoughtWorks發(fā)布了新一期的技術(shù)雷達(dá)。技術(shù)雷達(dá)是以獨(dú)特的形式記錄ThoughtWorks技術(shù)顧問委員會(huì)對行業(yè)產(chǎn)生重大影響的技術(shù)趨勢 討論的結(jié)果，為從CIO到開發(fā)人員在內(nèi)的各方利益相關(guān)者提供價(jià)值。這期雷達(dá)的技術(shù)趨勢主要體現(xiàn)在：受到熱捧的微服務(wù)相關(guān)技術(shù)，逐步成熟的以Docker為典型的容器化生態(tài)系統(tǒng)，備受企業(yè)和用戶關(guān)注的信息安全問題。本文就從這幾個(gè)新趨勢來分析一下給軟件測試帶來了哪些影響。
自動(dòng)化測試是王道
在這個(gè)快速變化發(fā)展的時(shí)代，任何一款產(chǎn)品想要在市場具備競爭力，必須能夠快速適應(yīng)和應(yīng)對變化，要求產(chǎn)品開發(fā)過程具備快速持續(xù)的高質(zhì)量交付能力。而要做到快速持續(xù)的高質(zhì)量交付，自動(dòng)化測試將必不可少。同時(shí)，自動(dòng)化測試也不是用代碼或者工具替代手工測試那么簡單，有了新的特點(diǎn)和趨勢：針對不同的產(chǎn)品開發(fā)技術(shù)框架有著不同的自動(dòng)化技術(shù)支持，針對不同的業(yè)務(wù)模式需要不同的自動(dòng)化測試方案，從而使得自動(dòng)化測試有著更好的可讀性、更低的實(shí)現(xiàn)成本、更高的運(yùn)行效率和更有效的覆蓋率。來自技術(shù)雷達(dá)的下列主題分別體現(xiàn)了自動(dòng)化測試的這些特點(diǎn)：
- 針對微服務(wù)的消費(fèi)端驅(qū)動(dòng)的契約測試（Consumer-driven contract testing)，有助于解決隨著服務(wù)增多帶來集成測試效率低和不穩(wěn)定的問題。消費(fèi)端驅(qū)動(dòng)的契約測試是成熟的微服務(wù)測試策略中核心的組成部分。
- 專門用于測試和驗(yàn)證RESTful服務(wù)的工具REST-assured，它是一個(gè)Java DSL，使得為基于HTTP的RESTful服務(wù)編寫測試變得更加簡單。REST-assured支持不同類型的REST請求，并且可以驗(yàn)證請求從API返回的結(jié)果。它同時(shí)提供了JSON校驗(yàn)機(jī)制，用于驗(yàn)證返回的JSON數(shù)據(jù)是符合預(yù)期的。
- 安卓系統(tǒng)功能測試工具Espresso，其微小的內(nèi)核API隱藏了復(fù)雜的實(shí)現(xiàn)細(xì)節(jié)，并幫助我們寫出更簡潔、快速、可靠 的測試。
- ThoughtWorks開源的輕量級跨平臺(tái)測試自動(dòng)化工具Gauge，支持用業(yè)務(wù)語言描述測試用例，支持不同的編程語言，支持所支持平臺(tái)的并行執(zhí)行。
- 用于針對UI的自動(dòng)化測試構(gòu)建頁面描述對象的Ruby庫Pageify，該工具關(guān)注于更快的執(zhí)行測試以及代碼的可讀性，并可以很好的配合Webdriver或是Capybara使用。
- 專門用于iOS應(yīng)用開發(fā)的開源行為驅(qū)動(dòng)開發(fā)測試框架Quick，支持Swift、Objective-C，它和用來做測試驗(yàn)證的Nimble捆綁發(fā)布。Quick主要用于Swift和Objective-C程序行為的驗(yàn)證。它和rspec和jasmine具有相同的語法風(fēng)格，基礎(chǔ)環(huán)境很容易建立。Quick良好的結(jié)構(gòu)和類型斷言使得測試異步程序更加容易。Quick擁有現(xiàn)成的Swift和Objective-C規(guī)范文件模板，開發(fā)者只需4步，即可對應(yīng)用進(jìn)行快速測試。
工具很重要，設(shè)計(jì)不可少！自動(dòng)化測試工具云集，但做自動(dòng)化也不要沖動(dòng)，需要重視以下幾點(diǎn)：
- 綜合考慮項(xiàng)目技術(shù)棧和人員能力，采用合適的框架來實(shí)現(xiàn)自動(dòng)化；
- 結(jié)合測試金字塔和項(xiàng)目具體情況，考慮合適的測試分層，如果能夠在底層測試覆蓋的功能點(diǎn)一定不要放到上層的端到端測試來覆蓋；
- 自動(dòng)化測試用例設(shè)計(jì)需要考慮業(yè)務(wù)價(jià)值，盡量從用戶真實(shí)使用的業(yè)務(wù)流程／業(yè)務(wù)場景來設(shè)計(jì)測試用例，讓自動(dòng)化優(yōu)先覆蓋到最關(guān)鍵的用戶場景；
- 同等看待測試代碼和開發(fā)代碼，讓其作為產(chǎn)品不可分割的一部分。
云技術(shù)、容器化和開源工具使得測試成本下降
測試環(huán)境的準(zhǔn)備在過去是一個(gè)比較麻煩和昂貴的事情，很多組織由于沒有條件準(zhǔn)備多個(gè)測試環(huán)境，導(dǎo)致測試只能在有限的環(huán)境進(jìn)行，從而可能遺漏一些非常重要的缺陷，測試的成本和代價(jià)很高。隨著云技術(shù)的發(fā)展，多個(gè)測試環(huán)境不再需要大量昂貴的硬件設(shè)備來支持，加上以Docker為典范的容器技術(shù)生態(tài)系統(tǒng)也在逐步成長和成熟，創(chuàng)建和復(fù)制測試環(huán)境變得簡單多了，成本大大的降低。技術(shù)雷達(dá)推薦的鳳凰環(huán)境（Phoenix Environment），它能夠以自動(dòng)化的方式支持測試、開發(fā)、UAT和災(zāi)難恢復(fù)所需的新環(huán)境準(zhǔn)備。這一技術(shù)由上期的評估環(huán)上升到了采用環(huán)，表明它已經(jīng)得到了驗(yàn)證和認(rèn)可，是可以放心使用的技術(shù)。
另一方面是大量開源工具的出現(xiàn)，這些工具往往都是輕量級的、簡單易用，相對于那些重量級的昂貴的測試工具更容易被人們接受。測試工作有了這些開源工具的幫助，將更加全面、真實(shí)的覆蓋到要測試的平臺(tái)、環(huán)境和數(shù)據(jù)，將會(huì)加快測試速度、降低測試成本；更重要的一點(diǎn)，有了這些工具，讓測試人員能夠騰出更多的時(shí)間來做測試設(shè)計(jì)和探索性測試等更有意思的事情，使得測試工作變得更加有趣。新技術(shù)雷達(dá)提到的開源工具有：Mountebank、Postman、Browsersync、Hamms、Gor和ievms等。
- 在企業(yè)級應(yīng)用中，對組件進(jìn)行良好的測試至關(guān)重要，尤其是對于服務(wù)的分離和自動(dòng)化部署這兩個(gè)關(guān)系到微服務(wù)架構(gòu) 是否成功的關(guān)鍵因素，我們更需要更合適的工具對其進(jìn)行測試。Mountebank就是一個(gè)用于組件測試的輕量級測試工具，可以被用于對 HTTP、HTTPS、SMTP和TCP進(jìn)行模擬（Mock）和打樁 （Stub）。
- Postman是一個(gè)在Chrome 中使用的REST客戶端插件，通過Postman，你可以創(chuàng)建請求并且分析服務(wù)器端返回的信息。這個(gè)工具在開發(fā)新的 API或者實(shí)現(xiàn)對于已有API的客戶端訪問代碼時(shí)非常有用。Postman支持OAuth1和OAuth2，并且對于返回的 JSON和XML數(shù)據(jù)都會(huì)進(jìn)行排版。通過使用Postman，你可以查看你通過Postman之前發(fā)起過的請求，并且可以非常友好的編輯測試數(shù)據(jù)去測試API在不同請求下的返回。同時(shí)，雖然我們不鼓勵(lì)錄屏式的測試方法，但是Postman提供了一系列的拓展允許我們將它作為跑測試的工具。
- 隨著網(wǎng)站應(yīng)用所支持設(shè)備的增多， 花在跨設(shè)備測試上的代價(jià)也在不斷增大。Browsersync能夠通過同步多個(gè)移動(dòng)設(shè)備或桌面瀏覽器上的手工瀏覽器測試來極大的降低跨瀏覽器測試的代價(jià)。通過提供命令行工具以及UI界面，Browsersync對CI構(gòu)建非常友好，并且能夠自動(dòng)化像填寫表單這樣的重復(fù)任務(wù)。
- 在軟件開發(fā)領(lǐng)域，盲目地假設(shè)網(wǎng)絡(luò)總是可靠，服務(wù)器總是能夠快速并正確的響應(yīng)導(dǎo)致了許多失敗的案例。Hamms可以模擬一個(gè)行為損壞的HTTP服務(wù)器，觸發(fā)一系列的失敗，包括連接失敗，或者響應(yīng)緩慢，或者畸形的響應(yīng)，從而幫助我們更優(yōu)雅的測試軟件在處理異常時(shí)的反應(yīng)。
- Gor可以實(shí)時(shí)捕獲線上HTTP請求，并在測試環(huán)境中重放這些HTTP請求，以幫助我們使用到這些產(chǎn)品環(huán)境數(shù)據(jù)來持續(xù)測試我們的系統(tǒng)。 使用它之后可以大大提高我們在產(chǎn)品部署，配置修改或者基礎(chǔ)架構(gòu)變化時(shí)的信心。
- 盡管IE瀏覽器的使用量日益萎縮，但對很多產(chǎn)品而言IE瀏覽器 的用戶群依然不可忽視，瀏覽器兼容性仍然需要測試。這對于 喜歡使用基于Unix的操作系統(tǒng)進(jìn)行開發(fā)的人來說還是件麻煩事。為了幫助解決這個(gè)難題，ievms提供了實(shí)用的腳本來自動(dòng)設(shè)置不同的Windows虛擬機(jī)鏡像來測試從IE6到Microsoft Edge的各種版本瀏覽器。
安全測試貫穿整個(gè)生命周期
“安全是每一個(gè)人的問題”！互聯(lián)網(wǎng)安全漏洞頻繁爆發(fā)，安全問題已經(jīng)成為每個(gè)產(chǎn)品迫切需要關(guān)注和解決的問題，安全測試將需要貫穿于軟件開發(fā)的整個(gè)生命周期。同時(shí)，給軟件測試人員帶來了更多的機(jī)遇和挑戰(zhàn)，要求具備更多的安全相關(guān)知識(shí)（其中還包括更多的計(jì)算機(jī)基礎(chǔ)知識(shí)），掌握已有的安全測試相關(guān)技術(shù)，從而在軟件開發(fā)的各個(gè)階段做好安全相關(guān)的分析和測試工作。盡管有些團(tuán)隊(duì)已經(jīng)將安全跟整個(gè)開發(fā)實(shí)踐結(jié)合起來，但培養(yǎng)每個(gè)人在每個(gè)階段的安全意識(shí)還相當(dāng)?shù)闹匾?，探索新的安全測試技術(shù)、方法還有很多空間。
技術(shù)雷達(dá)上列出的安全測試相關(guān)的技術(shù)和工具有：Bug bounties、威脅建模（Threat Modelling）、ZAP和Sleepy Puppy。
- Bug bounties是一個(gè)安全漏洞舉報(bào)獎(jiǎng)勵(lì)制度，越來越多的組織開始通過Bug bounties鼓勵(lì)記錄常見的安全相關(guān)的Bugs，幫助提高軟件質(zhì)量。
- 威脅建模（Thread modeling）是一組技術(shù)，主要從防御的角度出發(fā)，幫助理解和識(shí)別潛在的威脅。當(dāng)把用戶故事變?yōu)椤靶皭河脩艄适隆睍r(shí)，這樣的做法可給予團(tuán)隊(duì)一個(gè)可控且高效的方法使他們的系統(tǒng)更加安全。
- ZED Attack Proxy (ZAP)是一個(gè)OWASP的項(xiàng)目，允許你以自動(dòng)化的方式探測已有站點(diǎn)的安全漏洞?？梢杂脕碜龆ㄆ诘陌踩珳y試，或者集成到CD的Pipleline中提供一個(gè)持續(xù)的常規(guī)安全漏洞檢測。使用ZAP這樣的工具并不能替換掉對安全的仔細(xì)思考或者其他的系統(tǒng)測試，但是作為一個(gè)保證我們的系統(tǒng)更安全的工具，還是很值得添加到你的工具集里。
- Sleepy Puppy是Netflix公司近期開源的一款盲打XSS收集框架。當(dāng)攻擊者試圖入侵第二層系統(tǒng)時(shí),這個(gè)框架可用于測試目標(biāo)程序的XSS漏洞。XSS是OWASP的Top10的安全威脅，Sleepy Puppy可以用來同時(shí)為幾個(gè)應(yīng)用完成自動(dòng)安全掃描。它可以自定義盲打方式，簡化了捕獲，管理和跟蹤XSS漏洞的過程。Sleepy Puppy還提供了API供ZAP之類的漏洞掃描工具集成，從而支持自動(dòng)化安全掃描。
優(yōu)化業(yè)務(wù)價(jià)值
大多數(shù)軟件都是做項(xiàng)目的模式，在不同的檔期內(nèi)進(jìn)行計(jì)劃、實(shí)現(xiàn)和交付。敏捷開發(fā)極大的挑戰(zhàn)了這種模式，通過在開發(fā)過程中各個(gè)階段進(jìn)行的分析和測試工作，持續(xù)的發(fā)現(xiàn)新的需求，使得需求更趨于合理化，更能體現(xiàn)業(yè)務(wù)價(jià)值。精益創(chuàng)業(yè)的技術(shù)，如觀察需求的A/B測試，進(jìn)一步削弱了這種心態(tài)。技術(shù)雷達(dá)推薦“產(chǎn)品優(yōu)于項(xiàng)目（Product over project）”，認(rèn)為大多數(shù)的軟件開發(fā)工作應(yīng)該遵循精益企業(yè)的引領(lǐng)，將自己定義為構(gòu)建支持業(yè)務(wù)流程的產(chǎn)品。這樣的產(chǎn)品并沒有所謂的最終交付，更多的是一個(gè)探索如何更好的支持和優(yōu)化業(yè)務(wù)流程的過程，只要業(yè)務(wù)依然有價(jià)值就會(huì)不斷持續(xù)下去。
作為軟件開發(fā)中的關(guān)鍵角色、負(fù)責(zé)軟件測試的QA人員，通過從用戶角度對軟件的測試，結(jié)合自身對軟件產(chǎn)品的了解，對優(yōu)化業(yè)務(wù)價(jià)值將會(huì)起到舉足輕重的作用。軟件測試不僅是檢驗(yàn)軟件是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別的過程，還需要有意識(shí)的對需求進(jìn)行持續(xù)的驗(yàn)證和優(yōu)化，對業(yè)務(wù)的趨勢和風(fēng)險(xiǎn)進(jìn)行分析。如果能在開發(fā)過程中結(jié)合使用BDD（行為驅(qū)動(dòng)開發(fā)）的思想，統(tǒng)一團(tuán)隊(duì)對需求的認(rèn)識(shí)，利用團(tuán)隊(duì)的力量來優(yōu)化業(yè)務(wù)將會(huì)達(dá)到事半功倍的效果。
傳統(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)境下最終用戶的反饋，對反饋進(jìn)行分類分析。這些反饋可能有：
- 缺陷：需要進(jìn)行優(yōu)先級劃分，確定是否需要修復(fù)；并且對這些缺陷進(jìn)行根源分析，在以后的開發(fā)過程中盡量避免同類型的缺陷再次出現(xiàn)。
- 抱怨：對于抱怨需要分析其背后的原因，可能正是能夠幫助我們改進(jìn)和優(yōu)化業(yè)務(wù)價(jià)值的好機(jī)會(huì)。
- 建議：一般用戶可能難以提出高質(zhì)量的建議，需要我們在收集反饋的時(shí)候下點(diǎn)功夫，有針對性的去收集。一旦收集到了建議，將是對業(yè)務(wù)價(jià)值優(yōu)化非常有利的。
通過對產(chǎn)品環(huán)境下的軟件質(zhì)量進(jìn)行分析，將有利于協(xié)助“產(chǎn)品優(yōu)于項(xiàng)目”實(shí)踐，幫助優(yōu)化業(yè)務(wù)價(jià)值，做好企業(yè)產(chǎn)品的創(chuàng)新工作。需要注意的是，產(chǎn)品環(huán)境下的QA可能會(huì)導(dǎo)致有些組織走的太遠(yuǎn)而忽視產(chǎn)品上線前的質(zhì)量保證，它只對那些已經(jīng)執(zhí)行并有一定程度持續(xù)交付實(shí)踐的組織有價(jià)值。
總結(jié)
軟件測試是一項(xiàng)技術(shù)工作，但軟件測試領(lǐng)域的問題不僅僅是技術(shù)問題。隨著自動(dòng)化程度越來越高，不斷有人懷疑QA存在的必要性，從前面的分析可以看到，新趨勢給QA提出了更高的要求，帶來了更多的機(jī)遇和挑戰(zhàn)，相信好的QA是不可能簡單的被取代的。
