隨著測(cè)試成為一門“專業(yè)”，所涉及到的范疇比較多，中培偉業(yè)《軟件自動(dòng)化測(cè)試與持續(xù)集成實(shí)踐》培訓(xùn)專家張老師在這里就軟件測(cè)試的一些重點(diǎn)問(wèn)題進(jìn)行了介紹。

1. 單元測(cè)試

單元測(cè)試在軟件工程中隸屬開(kāi)發(fā)過(guò)程域，開(kāi)發(fā)團(tuán)隊(duì)在完成一部分代碼（一個(gè)類、一個(gè)方法、函數(shù)）時(shí)設(shè)計(jì)對(duì)應(yīng)的單元測(cè)試用例來(lái)進(jìn)行驗(yàn)證這部分代碼是否按預(yù)期進(jìn)行執(zhí)行的行為。

實(shí)際上單元測(cè)試提了若干年，但這若干年里鮮有公司能將單元測(cè)試的覆蓋率提升到50%以上，60%的公司從不做單元測(cè)試。

為什么出現(xiàn)這個(gè)結(jié)果呢？

一方面，開(kāi)發(fā)人員認(rèn)為完成功能是首要任務(wù)，總覺(jué)得來(lái)不及也沒(méi)有職責(zé)做單元測(cè)試。修復(fù)后期別人發(fā)現(xiàn)的一大堆bug認(rèn)為是想當(dāng)然自己的工作，為了預(yù)防和減少這些bug認(rèn)真的做一把單元“測(cè)試”卻不是自己職責(zé)所在了？很有意思的習(xí)慣性思維。想起多年前剛參加工作時(shí)，公司貼在座位旁邊的的一句話“你的下游就是上帝”。我們?cè)诮桓断掠危y(cè)試團(tuán)隊(duì)/客戶）我們的東西時(shí)，我們應(yīng)該做到什么程度？

另一方面，開(kāi)發(fā)團(tuán)隊(duì)對(duì)單元測(cè)試的重要性認(rèn)知不夠。為什么認(rèn)知不夠呢，因?yàn)槿狈?duì)bug/故障的總結(jié)與分析。這屬于典型的做項(xiàng)目的一次性交付思維，項(xiàng)目/新需求交付即表示完成。事實(shí)上這個(gè)總結(jié)分析非常重要。大家可以嘗試著從重大故障庫(kù)里翻閱一下歷史上的重大故障，有些很低級(jí)的，比如結(jié)構(gòu)體初始化錯(cuò)誤、數(shù)組越界、變量類型錯(cuò)誤、邏輯缺失、甚至select忘記了where條件都有。其實(shí)這些錯(cuò)誤，在自己編碼階段完成可以通過(guò)單元測(cè)試/同行評(píng)審/代碼掃描檢查等方式發(fā)現(xiàn)，何必出現(xiàn)重大故障時(shí)扼腕嘆息？Boris Beizer：軟件歷史上最臭名昭著的錯(cuò)誤都是單元測(cè)試可以發(fā)現(xiàn)的錯(cuò)誤。

再談?wù)剢卧獪y(cè)試的執(zhí)行方法。結(jié)合性價(jià)比及開(kāi)發(fā)團(tuán)隊(duì)現(xiàn)狀，建議單元測(cè)試：

1） 先從核心代碼/核心模塊入手做；核心代碼/模塊的單元測(cè)試行覆蓋率要達(dá)到60%，方法/函數(shù)覆蓋率達(dá)到90%；

2） 單元測(cè)試用例先從基本邏輯路徑覆蓋、出錯(cuò)處理、接口、邊界條件四個(gè)方面設(shè)計(jì)；

3） 結(jié)合單元測(cè)試工具框架Xunit及Xmock（打樁用）來(lái)執(zhí)行；

4） 結(jié)合同行評(píng)審/自動(dòng)自動(dòng)靜態(tài)代碼掃描（findbugs/PMD/Cppcheck等）來(lái)執(zhí)行；

5） 結(jié)合持續(xù)集成來(lái)執(zhí)行，隨時(shí)看到全景視圖；

2. 功能測(cè)試

功能測(cè)試（含軟件工程中的集成和系統(tǒng)測(cè)試）經(jīng)過(guò)多年的項(xiàng)目實(shí)踐，相對(duì)來(lái)說(shuō)控制過(guò)程已經(jīng)相對(duì)較為成熟。重點(diǎn)把握住幾點(diǎn)：

1） 波次需求-波次開(kāi)發(fā)-波次測(cè)試-波次發(fā)布；

2） 開(kāi)發(fā)、測(cè)試、編譯、生產(chǎn)環(huán)境相對(duì)獨(dú)立且權(quán)限受控；

3） 測(cè)試人員對(duì)業(yè)務(wù)的深入理解+測(cè)試用例的整理及測(cè)試要點(diǎn)；

4） Bug系統(tǒng)及bug跟蹤、Bug度量；

5） 適當(dāng)頻率的回歸測(cè)試應(yīng)對(duì)增量開(kāi)發(fā)；

6） 實(shí)際使用人員的參與測(cè)試很重要，比如工單補(bǔ)錄、模擬測(cè)試；

7） 先從端到端核心流程的穿越測(cè)試入手再擴(kuò)大范圍測(cè)試；

8） 重大專項(xiàng)的測(cè)試把握顆粒度，從最易出錯(cuò)處考慮；

9） 最好版本管理+持續(xù)集成工具框架。

3. 自動(dòng)化測(cè)試

很多年來(lái)一直有一個(gè)誤區(qū)，認(rèn)為自動(dòng)化測(cè)試能替代手工測(cè)試。事實(shí)上，目前沒(méi)有一家公司完全通過(guò)自動(dòng)化測(cè)試來(lái)替代手工測(cè)試的。拿一個(gè)需求簡(jiǎn)單對(duì)比執(zhí)行時(shí)間：手工測(cè)試的時(shí)間=用例編寫（文檔）+用例執(zhí)行；自動(dòng)化測(cè)試的時(shí)間=用例編寫（文檔）+自動(dòng)化用例設(shè)計(jì)調(diào)試+自動(dòng)化用例執(zhí)行。所以從普遍功能測(cè)試上看，自動(dòng)化測(cè)試不會(huì)比你單純的手工測(cè)試執(zhí)行更快。

但我們還是要去持續(xù)推動(dòng)自動(dòng)化測(cè)試呢？因?yàn)槲覀兠鎸?duì)的是迭代增量迭代開(kāi)發(fā)模式（敏捷也是高度迭代），我們已經(jīng)測(cè)試的功能在新的功能增量上來(lái)后還好用不好用，受不受影響？從工程實(shí)踐的統(tǒng)計(jì)來(lái)看，經(jīng)過(guò)多次版本增量迭代后，在上線前約30%的已經(jīng)測(cè)試過(guò)的功能受增量代碼交叉影響而又出現(xiàn)bug。所以我們要對(duì)已經(jīng)測(cè)試的功能做出自動(dòng)化用例，當(dāng)新增/迭代的版本/功能上來(lái)后，我們可以手工測(cè)試新增的版本/功能，同時(shí)啟動(dòng)已經(jīng)測(cè)試過(guò)的功能的自動(dòng)化用例執(zhí)行。這樣就能發(fā)現(xiàn)已測(cè)試過(guò)的功能是否受到后來(lái)功能版本的影響而導(dǎo)致的bug，又省略全部功能測(cè)試一遍的煩惱。因?yàn)橐粋€(gè)項(xiàng)目過(guò)程中有多次迭代和增量，那么這個(gè)規(guī)模效應(yīng)就越發(fā)顯現(xiàn)。在新需求開(kāi)發(fā)過(guò)程中更為重要：將核心功能做成自動(dòng)化腳本，每次上線的時(shí)候自動(dòng)化執(zhí)行那些核心功能的自動(dòng)化腳本+手工執(zhí)行本次上線需求的測(cè)試。

自動(dòng)化測(cè)試腳本還應(yīng)用在一次傳入多個(gè)測(cè)試數(shù)據(jù)的場(chǎng)合。

自動(dòng)化測(cè)試的應(yīng)用場(chǎng)景分析清楚后，我們?cè)僬務(wù)劄楹巫詣?dòng)化測(cè)試即便用在回歸測(cè)試這種場(chǎng)合及它的作用和效果，業(yè)界公司為何仍然很少能規(guī)模、例行的做起來(lái)呢？

1）受限于自動(dòng)化測(cè)試框架。目前業(yè)界的主流自動(dòng)化測(cè)試框架，例如QTP、selenium、watin、watir等全部都是基于界面的自動(dòng)化工具，基本原理都是捕獲界面組件（按鈕/下拉菜單/彈出框等）的動(dòng)作，重新執(zhí)行一遍這個(gè)動(dòng)作來(lái)完成驗(yàn)證。這里面涉及到界面組件的任何變化，比如位置、比如內(nèi)容、比如觸發(fā)方式、比如執(zhí)行環(huán)境等都需要修改和調(diào)試自動(dòng)化腳本，帶來(lái)較大的維護(hù)工作量。常常地，執(zhí)行一遍自動(dòng)化測(cè)試腳本報(bào)出若干個(gè)各種類型的錯(cuò)誤，真正定位是bug的又少，越來(lái)越失去信心，最終放棄。

2）前期的測(cè)試人員投入和堅(jiān)持。我們上面分析了自動(dòng)化測(cè)試的特點(diǎn)，所以要自動(dòng)化測(cè)試?yán)新涞兀匦枨捌谟幸欢ǖ娜藛T投入（最好測(cè)試人員分一部分精力來(lái)做），隨著腳本維護(hù)的數(shù)量和腳本的數(shù)量積累，才能有一定的規(guī)模效應(yīng)出現(xiàn)，最終體驗(yàn)到自動(dòng)化測(cè)試的樂(lè)趣和價(jià)值。自動(dòng)化測(cè)試還要有所堅(jiān)持，因?yàn)楦鶕?jù)上面分析的自動(dòng)化測(cè)試特點(diǎn)，有時(shí)候很多次自動(dòng)化用例執(zhí)行不一定能發(fā)現(xiàn)關(guān)聯(lián)錯(cuò)誤，關(guān)聯(lián)影響的錯(cuò)誤畢竟要大幅度少于新增功能測(cè)試的錯(cuò)誤。不能因?yàn)榘l(fā)現(xiàn)的bug少就認(rèn)為價(jià)值小最后失望告終。

在自動(dòng)化測(cè)試的落地實(shí)施上，我們建議：

1）范圍：新需求開(kāi)發(fā)過(guò)程/長(zhǎng)周期界面不易變化的項(xiàng)目建議做自動(dòng)化測(cè)試實(shí)施；短周期項(xiàng)目不做自動(dòng)化測(cè)試，界面易變化的項(xiàng)目不做自動(dòng)化測(cè)試；

2）工具。互聯(lián)網(wǎng)類可嘗試python+webdriver+robotfromwork的自動(dòng)化測(cè)試框架，這個(gè)框架之所以成為互聯(lián)網(wǎng)近期關(guān)注的熱門。主要還是python腳本語(yǔ)言的簡(jiǎn)單好寫跨平臺(tái)的特點(diǎn)，再結(jié)合robotfromwork的用例管理及表格化編寫用例帶來(lái)方便性。但是正如我前面的分析，目前這類工具都是界面型工具，有天然界面變化引起維護(hù)的這個(gè)弊端。所以我們還是要強(qiáng)烈推薦我們自有研發(fā)的自動(dòng)化測(cè)試工具Sitechtester，這個(gè)工具主要是拋開(kāi)界面，將界面訪問(wèn)邏輯的過(guò)程封裝，只需調(diào)服務(wù)和傳測(cè)試數(shù)據(jù)，因?yàn)樵谀_本制作上和腳本執(zhí)行上都比較快。目前自有工具的主要弱點(diǎn)是C主體開(kāi)發(fā)，在跨平臺(tái)使用和編寫用例上要求更具程序基礎(chǔ)，對(duì)于測(cè)試人員的使用有一定技術(shù)局限。

3）資源。雖然我們寄希望長(zhǎng)期降低成本。但是不得不面對(duì)，我們?cè)谧詣?dòng)化初期的人員投入腳本編寫和腳本維護(hù)及自動(dòng)化環(huán)境搭建等過(guò)程，建議可先從核心功能做出自動(dòng)化用例，先現(xiàn)有人員分離部分職能來(lái)做自動(dòng)化測(cè)試。

4. 測(cè)試用例

測(cè)試用例的重要性、設(shè)計(jì)方法在這兒不再闡述，我主要想表達(dá)下測(cè)試用例的積累和復(fù)用。我們知道，如果一個(gè)項(xiàng)目/產(chǎn)品的代碼重新開(kāi)發(fā)的比例超過(guò)30%，這個(gè)產(chǎn)品/項(xiàng)目基本上來(lái)說(shuō)是比較失敗的。測(cè)試用例亦如此。同樣產(chǎn)品/項(xiàng)目的測(cè)試用例應(yīng)盡量復(fù)用或者在復(fù)用基礎(chǔ)上進(jìn)一步修改使用，總比全部重新來(lái)寫的好。

所以要強(qiáng)化測(cè)試用例收集和復(fù)用的工作。收集后就是復(fù)用的問(wèn)題了，先有地可尋，再?gòu)?qiáng)化復(fù)用。

測(cè)試用例的復(fù)用要遵循：對(duì)于項(xiàng)目還是建立按照產(chǎn)品樹(shù)-構(gòu)件-測(cè)試用例，轉(zhuǎn)到項(xiàng)目樹(shù)的產(chǎn)品構(gòu)件下的測(cè)試用例對(duì)應(yīng)即為復(fù)用/修改屬性帶過(guò)去。對(duì)于新需求，每個(gè)產(chǎn)品要建立最小回歸用例集，需求上線時(shí)確保該部分用例覆蓋測(cè)試到，包括測(cè)試場(chǎng)景及測(cè)試數(shù)據(jù)等。

5. 敏捷開(kāi)發(fā)與敏捷測(cè)試

敏捷開(kāi)發(fā)和敏捷測(cè)試我們這兒不去談?wù)撍暮脡摹Ｒ罁?jù)我們的了解，國(guó)內(nèi)真正做起敏捷開(kāi)發(fā)/敏捷測(cè)試的公司也屈指可數(shù)，而且多數(shù)變了形。

敏捷真的好的事物，關(guān)鍵是我們?cè)趺从盟?/p>

在測(cè)試方面，關(guān)鍵的是我們對(duì)敏捷測(cè)試的態(tài)度是不要照貓畫虎，應(yīng)該更多的學(xué)習(xí)和借鑒它的一些方法和思想：

1）劃分波次的思想，先劃分系統(tǒng)的主干功能，一個(gè)波次一個(gè)波次的整理需求、設(shè)計(jì)開(kāi)發(fā)、集中測(cè)試、波次交付。這樣最大限度的避免了原來(lái)我們領(lǐng)到任務(wù)后，黑箱操作幾個(gè)月到半年再一次性集成發(fā)布，結(jié)果要花費(fèi)巨大的時(shí)間來(lái)解決集成和缺陷。波次思想的核心就是通過(guò)一次次端到端的潛在集成替代了原有的黑箱操作完畢一次性集成發(fā)布。

2）測(cè)試人員和開(kāi)發(fā)人員的溝通應(yīng)該是以bug為中心隨時(shí)、無(wú)障礙、互相坦誠(chéng)相見(jiàn)，而不是傳統(tǒng)意義上的“相互對(duì)立”，因?yàn)槟繕?biāo)是統(tǒng)一的。敏捷中的站會(huì)、總結(jié)評(píng)審會(huì)就解決了這些矛盾。

3）測(cè)試計(jì)劃應(yīng)該詳細(xì)做最近一個(gè)波次的，更遠(yuǎn)波次的測(cè)試計(jì)劃只做總體計(jì)劃。這個(gè)有好處的，其實(shí)我們都深刻有體會(huì)，計(jì)劃跟不上變化。能把握的是最近的事和人。

4）敏捷中測(cè)試用例突破原有的標(biāo)準(zhǔn)文檔模式，可以通過(guò)示意圖、測(cè)試要點(diǎn)（站會(huì)時(shí)隨時(shí)記錄）等方式來(lái)呈現(xiàn)，核心是你是否真的理解和掌握了你所測(cè)的東西。但不管何時(shí)方式呈現(xiàn)，都要積累下來(lái)，以備復(fù)用。

5）敏捷始終強(qiáng)調(diào)質(zhì)量?jī)?nèi)建，也就是說(shuō)測(cè)試不是保障質(zhì)量的唯一環(huán)節(jié)，質(zhì)量更應(yīng)該是越早解決越好，體現(xiàn)在規(guī)劃階段的FDD、開(kāi)發(fā)設(shè)計(jì)階段的極限編程（靜態(tài)代碼檢查、同行評(píng)審、單元測(cè)試、結(jié)對(duì)編程、持續(xù)集成等）、項(xiàng)目管理過(guò)程的scrum（共同分享信息，關(guān)注總結(jié)）等；

6）工具。不管我們是否采用敏捷，伴隨著敏捷，一大批開(kāi)源工具可以被我們使用和掌握。比如持續(xù)集成的相關(guān)工具（jenkins/maven/ant等）、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的工具（fitnesse等）、代碼檢查的工具（findbugs等）、自動(dòng)化測(cè)試工具selenium工具等。

5性能與安全測(cè)試

性能測(cè)試本身不再多說(shuō)。我這兒想要說(shuō)的產(chǎn)品/項(xiàng)目的性能不要單單放在性能測(cè)試的時(shí)候才去關(guān)注，到那時(shí)候產(chǎn)品的性能bug修復(fù)代價(jià)太大了，開(kāi)發(fā)測(cè)試團(tuán)隊(duì)日常中就要關(guān)注產(chǎn)品性能。

對(duì)于設(shè)計(jì)團(tuán)隊(duì)來(lái)講，比如批量與數(shù)據(jù)庫(kù)交互設(shè)計(jì)、充分利用緩存和存儲(chǔ)層推前、多進(jìn)程與集群設(shè)計(jì)、分表與分庫(kù)等都會(huì)對(duì)系統(tǒng)性能造成重大影響；對(duì)于開(kāi)發(fā)團(tuán)隊(duì)來(lái)講，你代碼中申請(qǐng)的內(nèi)存不要忘記回收（malloc/free，new/delete）以免造成內(nèi)存泄漏、你get的線程使用完畢要close掉、你的報(bào)文傳輸壓縮、CSS置前JS放后、請(qǐng)求合并處理、減少硬解析、正確使用索引等等都是避免后期性能的簡(jiǎn)單而有效的方法，你編碼的時(shí)候考慮到了就好了。

安全測(cè)試隨著近年來(lái)重大安全事件的暴露而變得熱門。安全測(cè)試本身的技術(shù)和方法并不復(fù)雜，你用appscan、zap等工具，一會(huì)兒跑出大片安全漏洞就ok了。當(dāng)然測(cè)試團(tuán)隊(duì)也要理解安全漏洞的原理和攻擊方法。

本質(zhì)還是開(kāi)發(fā)團(tuán)隊(duì)要有針對(duì)性的避免和減少安全問(wèn)題。因?yàn)橐坏┕ぞ吲艹鲆欢寻踩珕?wèn)題，要不要修改？修改的代價(jià)有多大？我認(rèn)為還是比較大的一個(gè)量的估算，比如數(shù)據(jù)字段加密，你是加了密了，加密后傳給對(duì)方是否要解密還是對(duì)方解密等等涉及的面很多。必需要有取舍。否則根本按期完不成功能交付。建議：

1） 對(duì)于面向互聯(lián)網(wǎng)普通大眾的系統(tǒng)，從根本上要控制認(rèn)證和授權(quán)、數(shù)據(jù)加密保護(hù)和傳輸這兩個(gè)主要切入點(diǎn)。關(guān)鍵動(dòng)作必須重新認(rèn)證（不要信任session）。關(guān)鍵數(shù)據(jù)必須加密保存和傳輸，注意提醒那些還沉浸在MD5加密的人們，這個(gè)早就被破解了，更不要用自己的加密函數(shù)。面向互聯(lián)網(wǎng)普通大眾的系統(tǒng)還要重點(diǎn)考慮網(wǎng)絡(luò)攻擊（比如Ddos攻擊，這時(shí)候防火墻是解決不了的）。

2） 對(duì)于傳統(tǒng)渠道產(chǎn)品，比如支撐系統(tǒng)、經(jīng)分系統(tǒng)等，因運(yùn)營(yíng)商有4A等類似單點(diǎn)登錄的統(tǒng)一認(rèn)證系統(tǒng)，認(rèn)證和授權(quán)可以適當(dāng)充分信任4A等系統(tǒng)。更多的是從合法用戶的非法行為入手考慮，比如合法IP的刷機(jī)行為、合法用戶的盜權(quán)行為、合法用戶的信息泄漏行為（強(qiáng)化數(shù)據(jù)加密）。

先寫這些，感覺(jué)要寫的很多。后面再推出個(gè)（2）吧，重點(diǎn)談?wù)劤掷m(xù)集成、國(guó)內(nèi)外優(yōu)秀工具測(cè)試的實(shí)踐及分析我們的差距。……