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

1. 單元測試

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

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

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

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

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

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

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

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

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

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

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

2. 功能測試

功能測試（含軟件工程中的集成和系統(tǒng)測試）經(jīng)過多年的項目實踐，相對來說控制過程已經(jīng)相對較為成熟。重點把握住幾點：

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

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

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

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

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

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

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

8） 重大專項的測試把握顆粒度，從最易出錯處考慮；

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

3. 自動化測試

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

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

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

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

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

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

在自動化測試的落地實施上，我們建議：

1）范圍：新需求開發(fā)過程/長周期界面不易變化的項目建議做自動化測試實施；短周期項目不做自動化測試，界面易變化的項目不做自動化測試；

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

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

4. 測試用例

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

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

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

5. 敏捷開發(fā)與敏捷測試

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

敏捷真的好的事物，關(guān)鍵是我們怎么用它。

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

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

2）測試人員和開發(fā)人員的溝通應(yīng)該是以bug為中心隨時、無障礙、互相坦誠相見，而不是傳統(tǒng)意義上的“相互對立”，因為目標(biāo)是統(tǒng)一的。敏捷中的站會、總結(jié)評審會就解決了這些矛盾。

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

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

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

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

5性能與安全測試

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

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

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

本質(zhì)還是開發(fā)團(tuán)隊要有針對性的避免和減少安全問題。因為一旦工具跑出一堆安全問題，要不要修改？修改的代價有多大？我認(rèn)為還是比較大的一個量的估算，比如數(shù)據(jù)字段加密，你是加了密了，加密后傳給對方是否要解密還是對方解密等等涉及的面很多。必需要有取舍。否則根本按期完不成功能交付。建議：

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

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

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