前階段為公司內(nèi)刊發(fā)表了一篇小文，談了下軟件測試的內(nèi)容,，今天也共享到我的微博上,，感興趣的同學(xué)可以看一下：

本次很榮幸的由我來寫一篇稿子。

在做軟件測試工程師的這幾年,，收獲了不少,，對軟件測試這一職業(yè)的理解也隨著工作經(jīng)驗有這更加深入的了解，在這里寫一篇關(guān)于“軟件測試”的小文,，發(fā)表一下我個人的一些拙見,，供大家探討學(xué)習(xí)之用。

軟件測試

什么是軟件測試,？其實現(xiàn)在很多人對軟件測試這一職業(yè)不是很了解,，不知到底什么是軟件測試。

關(guān)于軟件測試的定義有很多種,，我個人覺的比較符合的是：“使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別”。由于現(xiàn)在軟件發(fā)展的十分迅速,，軟件的復(fù)雜度也越來越高,，所以軟件測試現(xiàn)在也變的原來越重要，軟件測試貫穿于整個軟件生命周期,，軟件測試并不局限于程序測試,，它還包括對相關(guān)的需求、文檔的測試,，也包括一些多樣化的回歸測試,、壓力測試、性能測試等,。

關(guān)于軟件測試?yán)碚撝R在很多書中都有詳細(xì)的描寫,，這里就不摘抄了。但是根據(jù)我的經(jīng)驗,，想要做好軟件測試,，深入了解軟件測試的理論知識是必不可少的，很多很多實際遇到的問題,，都是由于對軟件測試的理論知識的不了解造成的,。

測試心理

做好一名軟件測試人員，調(diào)整好心理是必須的,。

（1）“創(chuàng)造者”與“破壞者”

在心理上,，軟件開發(fā)和測試最大的區(qū)別在于前者是“創(chuàng)造者”而后者是“破壞者”,。

對于“創(chuàng)造者”而言，在心理上是不會對自己“創(chuàng)造”出來的產(chǎn)品進行破壞,，就像每個人都會很愛惜自己的手工作品,。而對于“破壞者”，心理上應(yīng)該是屬于樂于看到自己測試的系統(tǒng)“崩塌”的場面,，就像拿著別人的手工作品摔砸扔來證明那個手工不行一樣,。

又如在實際應(yīng)用中，開發(fā)人員會說：“這個功能我測過好幾遍了,，沒有問題了”,，但測試軟件卻還是能在這個功能里挑出很多的問題，原因在于,，開發(fā)人員測試時,，心理上的關(guān)注點放在了“證明這個功能點可行”上，往往會無意識的繞過一些可能會引起問題的操作,；而測試人員的關(guān)注點放在了“使這個功能點不行”上,，會嘗試各種可能造成問題的操作。所以“破壞者”需要利用你所有可知的測試策略與方法,，對軟件進行不同程度的“破壞”,，檢查各種狀況下，軟件的處理方式與系統(tǒng)的能力,。

（2）“第三方視角”&“好奇心”

以第三方的眼光看軟件產(chǎn)品是測試人員與開發(fā)人員在進行測試時最大的區(qū)別,。除了“第三方的視角”，測試人員在心理上還要時常保持“好奇心”,，隨著測試的深入,，測試人員應(yīng)不滿足于現(xiàn)有的測試成果，“好奇心”會讓我想知道每次點擊操作背后系統(tǒng)正在做些什么,，驅(qū)使我去找程序員問個究竟或者看他們的代碼是怎么寫的,，看看能否進一步優(yōu)化系統(tǒng)；“好奇心”會讓我想弄清楚究竟多少用戶同時操作,，系統(tǒng)就會崩潰,，能否應(yīng)付系統(tǒng)上線后的正常使用；“好奇心”會驅(qū)使我在想用戶如果來使用軟件的時候會如何操作,，會遇到什么樣的問題,，會不會覺得繁瑣,。有了“好奇心”,，才能讓系統(tǒng)在上線前就做了更加完備的測試。

（3）“興趣”

“興趣”也是關(guān)鍵,，做過軟件測試工作的人知道,，軟件測試有時候是一個很繁瑣枯燥的工作,。比如測試一個表單填寫提交的功能，需要使用不同數(shù)據(jù)進行填寫并提交,，所以非常有可能出現(xiàn)的情況是,，這一星期，每天8小時的工作就是坐在電腦前,，不停的做著“填寫表單并提交”這樣的簡單機械時勞動,，這時，“興趣”是能讓我擺脫枯燥的方法,。興趣是最好的老師,，如果對測試工作真正感興趣的，就會不斷地研究測試相關(guān)的理論知識,、技能技巧,、工具等。就如上面說的“提交表單”測試,，你可以把它當(dāng)成一種挑戰(zhàn),，目標(biāo)是搞垮它，這時,，就可以嘗試各種各樣測試方法：嘗試不同的填寫數(shù)字,、在填數(shù)字的地方寫英文、在寫英文的地方寫中文,、將必填處留空提交,、在填寫框中復(fù)制上一篇10W字的文章、上傳附件處上傳各式各樣的格式文件,、上傳50MB以上的圖片文件,、使用QTP反復(fù)快速操作、使用QTP Object對象方法篡改頁面控件屬性提交,、使用Loadrunner模擬大量用戶同時提交,、提交的時候拔掉網(wǎng)線、用Sniffer或HttpWatch抓包進行觀察等等,，有太多的方法可以嘗試,，再使出渾身解數(shù)后，發(fā)現(xiàn)不知不覺中,，已對表單的各種場景進行了模擬測試,，提交了大量表單，時間也覺得一個星期都不夠了呢,。用一個比喻來說的話,，如James A. Whittaker的《How to Break Software》說的，“像小時候我們拿上一個小玩具,，可能就是一個陀螺,，甚至是一個拖把,，我們也會玩上半天也不會感到厭煩。我們會變著花樣來玩它,，我們扮演各種角色,，把它當(dāng)成道具，玩得不亦樂乎?，F(xiàn)在的測試工作是什么,，測試的對象有時候就是個玩具，只不過有些看起來過于嚴(yán)肅而已,。如果我們能把軟件當(dāng)成玩具來玩,，那么我們可能不會那么快就認(rèn)為測試已經(jīng)可以停止了。因為還有那么多有趣的玩法還沒嘗試,。如果實在是玩膩了,，還大可以把玩具狠狠地甩在地上，用腳踩幾下,，看它有什么反應(yīng),。這也是一種測試方法！你是在進行破壞性測試,！把你的小腳踏車一邊又一邊地從斜坡上沖下來,，每次裝上不同重量的東西，看裝上哪一種東西會最快,。哈哈,，原來你是在做壓力測試！”

PS：經(jīng)常有初入軟件測試的人發(fā)郵件給我問,，說做軟件測試是如此的枯燥無味,，而且很難在一個軟件中找到更多的BUG了，或是開始抱怨回歸測試的無聊時,，我都會告訴他,，你還沒找到軟件測試的“興趣”。非常有幸的,，我發(fā)現(xiàn)了“它”,，它讓我工作到現(xiàn)在仍能在軟件測試中找到無限的樂趣與挑戰(zhàn)，也是它,，迫使我學(xué)習(xí)更多的知識,。

測試方法

測試的方法太多了，不是我一篇小文能夠全部概括的,，在這里,，我就說一些最基礎(chǔ)的測試方法。

如測試一個登錄界面。有用戶名和密碼框,，確定和重置按鈕。用戶名和密碼長度要求為6-12位,。

（1）冒煙測試

我們測試的時候,，最先需要使用正確的賬號登錄一遍，這叫“冒煙測試”,，“冒煙測試”的作用是判斷一個功能模塊的最基本功能是否實現(xiàn),，如果“冒煙測試”能通過，則繼續(xù)進行深入的測試,，如果不過,，則不繼續(xù)進行測試。

冒煙測試是測試的第一步,，當(dāng)發(fā)現(xiàn)軟件連最基本的功能都無法實現(xiàn)的時候,，應(yīng)立即終止測試，交于開發(fā)處理問題,，而不是繼續(xù)測試,，放慢了整體研發(fā)速度。

（2）邊界值&等價類

當(dāng)“冒煙測試”過了,，則可以進一步進行測試了,。這里需要用到“邊界值”和“等價類”的測試思想。何為“邊界值”,？邊界值的概念是輸入稍高于其邊界值及稍低于其邊界值的一種測試方法,。往往會在邊界值的地方發(fā)生錯誤或與需求文檔要求的不符合。如例子中,，假設(shè)限定用戶名長度只能為6-12位,，則我們需要分別對長度為5位、6位,、7位,、11位、12位,、13位這6種長度進行測試,，這就是“邊界值”法。何為“等價類”,？等價類是一種數(shù)學(xué)上的概念,，在這里是將一個測試點劃分為多種類的集合，如：還是長度只能為6-12位的問題,，使用等價類的方法可以劃分為三類：1是小于6位的情況,，2是6-12位的情況，3是大于12位的情況。測試的時候,，需要在這三類情況中各舉出一套測試數(shù)據(jù)進行測試,。這就是“等價類”。

從概念上來看,，邊界值和等價類的方法很好理解,，這是軟件測試中，最最基礎(chǔ)的測試方法,，但能真正活用于測試項目中的的確不多,。從不少的來信中看到，其實還是有很多很多的測試人員不知道這兩種測試方法,，更不用說活用,。但如電影中最厲害的大招往往是最基礎(chǔ)的招式，小說中最厲害的人往往只是掃地僧,，烹飪中最能看出能力的往往是炒蛋炒飯一樣,。看一個測試人員的基礎(chǔ)和能力,，看他寫的測試用例就知道了,。能活用與最簡單的測試方法，才是最有效高效的測試,。

（3）錯誤猜想

猜,，這也是一種測試方法，這也是用的最多的一種測試方法,。當(dāng)然,，不是胡猜，而是有依據(jù)的猜,。往往經(jīng)驗豐富的測試人員能“猜”到更多有可能產(chǎn)生問題的情況,，寫出更加有效的測試用例。剛剛的登錄例子,，可以“猜”在能正常登陸的賬號前或后加個空格,，看看是否能正常登錄；可以“猜”輸入空的用戶名和密碼進行登錄的情況,；可以“猜”在登錄框中粘貼進大于保存用戶名變量類型的字符個數(shù),；可以“猜”在注冊一些帶有奇怪字符或是超出字庫范圍的文字后能否正常登錄；可以“猜”登錄瞬間關(guān)掉頁面檢查Sever上Session是否釋放等等,，能猜的內(nèi)容很多很多,，隨著經(jīng)驗的增長和對系統(tǒng)越發(fā)的熟悉，會“猜”到更多測試方案,。

（4）場景法

這也是在平時用的比較多的方法,，定義不同的場景,，進行有規(guī)律的測試。主要用于檢查流程等,，可使用在有較多分支流程中進行測試,。

（5）失敗測試

純粹為了破壞而設(shè)計和執(zhí)行的測試用例稱為失敗測試?？煽疾煜到y(tǒng)超出需求范圍時的行為,。

測試方法太多太多，這里就不一一闡述了,，但是上面5種，是用的最基礎(chǔ)也是用的最多的方法,。

測試用例

測試用例的重要性不用多了,，能規(guī)范化測試，記錄所有可能出現(xiàn)的問題,，隨著對測試用例的擴充,，能越來越達到完備的測試。關(guān)于測試用例,，我想說的是兩點,，“預(yù)期結(jié)果”與“測試數(shù)據(jù)”。

（1）預(yù)期結(jié)果

測試用例中必須要寫的中,，最重要的一項是預(yù)期結(jié)果,，我在指導(dǎo)一些網(wǎng)友寫的測試用例的時候，發(fā)現(xiàn)這點很難有做的很好的,。往往剛接觸測試的人員會在預(yù)期結(jié)果一欄中寫入諸如“登錄正確”,、“提交失敗”等這樣簡單的預(yù)期結(jié)果。殊不知這樣的寫法和沒寫是差不多的,，因為當(dāng)另一個測試人員進行測試的時候,，完全不知道“登錄正確”時的表現(xiàn)形式，應(yīng)寫明頁面上顯示了些什么,，那個角落會有什么樣的顯示,，數(shù)據(jù)是否真正寫到了數(shù)據(jù)庫中而“提交失敗”需寫明失敗提示到底是什么，是否有彈出框,，是有錯誤圖標(biāo)等等的詳細(xì)內(nèi)容,。

在預(yù)期結(jié)果中不要出現(xiàn)如“查看彈出框中內(nèi)容是否有圖片”這樣的有兩層意思的句子，即不要出現(xiàn)“是否”,。因為這樣的書寫,，在別人看來是“查看彈出框中內(nèi)容是有圖片”是預(yù)期結(jié)果還是“查看彈出框中內(nèi)容沒有圖片”是預(yù)期結(jié)果，這個看來只有寫這條測試用例的人自己知道了,。

（2）測試數(shù)據(jù)

測試數(shù)據(jù)需要完整,，如在某輸入框中輸入數(shù)據(jù)，需要寫明需要輸入的內(nèi)容是什么，是“abcdefg”還是“1234567”,，輸入的賬號也需要寫明是什么賬號,，而不是寫“輸入正確的賬號”，在別人測試過程中,，是不知道什么才是正確的賬號,。如果這個賬號不會變動（如管理員賬號），則在測試數(shù)據(jù)中需寫明“輸入賬號：admin,，密碼：123456”,，如賬號是常變動的（如用戶賬號），需在測試用例的前置條件中申明賬號的可用性,，如前置條件中寫“系統(tǒng)存在賬號為user123,，密碼為123456789的用戶”，這時在測試數(shù)據(jù)中就可以寫“試用賬號user123,，密碼為123456789進行登錄”,。

總之，寫測試用例的時候,，注意仔細(xì)與嚴(yán)謹(jǐn),。時常檢查自己寫的測試用例別人是否也能看懂。小組中有多么測試人員的,，需要時常對測試用例進行評審,，從而保證測試用例的高質(zhì)量。

BUG單

提交BUG也是一門功課,，既要簡單易讀,，又要能說明問題。所以需要在BUG單中寫清楚復(fù)現(xiàn)的步驟,，錯誤出現(xiàn)的頻率,，嚴(yán)重性和優(yōu)先級，一個BUG單講述一個問題,，不可將多個問題寫于同一篇BUG單中,，BUG單中需注意語氣，不得帶有情緒,，如果BUG存在爭議,，需要提供證據(jù)進行證明，如需求說明說,，可以咨詢需求人員,，如果什么都沒有可以參考行業(yè)軟件規(guī)范。

我談一下我在實際項目中遇到的一些問題,，一次參加客戶方關(guān)于提交BUG單規(guī)范的會議,，發(fā)現(xiàn)了如下問題：

（1）客戶方想只使用一個數(shù)值,，來定義嚴(yán)重性和優(yōu)先級。真是不應(yīng)該的,，嚴(yán)重性和優(yōu)先級是兩個不同的概念,，嚴(yán)重性高的BUG不一定優(yōu)先級就高，而嚴(yán)重性低的BUG很有可能優(yōu)先級是最高的,。如一個很少用的功能在一定的操作下會導(dǎo)致程序無響應(yīng),，但是決定在下一個版本再進行修復(fù)，則它的嚴(yán)重性雖然是高,，但是優(yōu)先級確是低,，而一個馬上要投入使用的功能點中，頁面上顯示的標(biāo)題不正確不影響使用,，雖然嚴(yán)重性是低,，但優(yōu)先級確實高。像這樣的情況使用一個數(shù)值便很難描述出BUG的嚴(yán)重情況和優(yōu)先情況,。

（2）客戶方的部分測試人員認(rèn)為一張表單上的3種不同類型的問題可以寫在一個BUG單上,。這也是不可以的,，有時候雖然是一個頁面上的,，但有可能3個錯誤點是由3個不同的開發(fā)人員開發(fā)的。這時,，讓一個開發(fā)修改完成而兩個開發(fā)未修改時,，無法正確調(diào)整BUG單狀態(tài)，導(dǎo)致測試進度收集也不完全,，很難定位到還有多少問題需要修改,。

（3）客戶方將BUG的數(shù)量和測試人員的效益與開發(fā)員工的效益掛鉤，這個在管理中也是萬萬不可以的,。會導(dǎo)致大量BUG冗余,；開發(fā)修改大量嚴(yán)重程度非常低的小BUG導(dǎo)致延緩整個項目的進度；很少有測試人員會花更多的時間去找難以發(fā)現(xiàn)的BUG,；造成開發(fā)和測試之間如仇家等等的問題,。

自動化

在進入公司后，客戶方就交給了我一個非常艱巨的任務(wù),，要做現(xiàn)有系統(tǒng)的自動化測試平臺,。還好對QTP比較熟悉，到目前為止,，已經(jīng)寫好BPM 1.0系統(tǒng)的自動化測試框架,，和不少表單腳本，并將BPM 1.0的腳本經(jīng)過修改后,，復(fù)用至BPM 2.0版本,。

如何進行自動化測試框架的搭建,，我會在以后的文章中寫明。

所以在這里,，我說幾點關(guān)于自動化測試的一些簡單的知識和我的一些經(jīng)驗,。很明顯，自動化測試從字面上來理解,，就是讓電腦自動完成所需要的測試內(nèi)容,。如填寫表單的測試，我可以預(yù)先將所要填寫的內(nèi)容寫好,，然后下班后,，讓電腦自動逐條進行填寫，提交,，記錄測試的結(jié)果,。看似很酷,，但需要考慮的問題很多,，最主要的是，需要有一定的編程基礎(chǔ),，畢竟,，腳本是要靠“寫”的。在很多網(wǎng)友來信中發(fā)現(xiàn),，很多人對自動化的理解和自動化所能做的功能有一點偏差,。主要有以下幾點：

只要開發(fā)出強大的自動化測試腳本，就能將測試人員解放出來,。其實不是的,，很多的測試都是靠手工進行測試，自動化只是輔助,。比如頁面的排版是否好看,，第一次測試時遇到的各種各樣的問題，因為開發(fā)做了較大的改變等等一些問題時,，自動化的執(zhí)行就會失敗,。

對于需求會經(jīng)常修改的系統(tǒng)如何進行自動化腳本的編寫。對于這樣需求會經(jīng)常變動的系統(tǒng),，就不能開展自動化測試,，還是老老實實的進行手工測試吧。

在軟件測試?yán)碚撝R還不是很牢固的情況下,，不要進行自動化,。對軟件測試和自動化測試的錯誤理解會導(dǎo)致后期自動化進行十分的困難且根本沒辦法維護腳本。

在軟件版本還沒有穩(wěn)定的情況下,，不要進行自動化

領(lǐng)導(dǎo)不支持的情況下,，不要進行自動化

系統(tǒng)中測試對象基本可以正常識別的情況下才進行自動化腳本的編寫,。

自動化測試一般的情況下是用來證明軟件能正常運行，而不是用在證明軟件這么操作一定會出錯上,。

記住,，自動化測試最主要的是提高工作效率，正確的使用是,，用1天開發(fā)一個腳本能用3個月的測試,，而不是花3個月開發(fā)出一個很牛的腳本來測試1天，非常多初學(xué)者會范這個錯誤,，我曾經(jīng)也范過,。

分析

學(xué)會分析數(shù)據(jù)也是軟件測試中必要的一項。優(yōu)秀的軟件測試人員能通過各種數(shù)字,，得到當(dāng)前系統(tǒng)的各種信息,。在性能測試中，分析數(shù)據(jù)顯得尤為重要,，一個做金融保險類系統(tǒng)性能測試的前輩和我說過,，做性能測試，用使用Loadrunner,，編寫腳本設(shè)計場景,，學(xué)的話幾個月就能搞定，但是分析執(zhí)行腳本后的數(shù)據(jù),，可能需要2-3年的工作經(jīng)驗,，才能看到你想看到的信息,。

說些簡單常用的,，通過分析BUG數(shù)據(jù)，就發(fā)現(xiàn)很多有用的信息,。如：當(dāng)系統(tǒng)剛剛開發(fā)完成,，交給測試人員進行測試的時候，BUG數(shù)量一定是呈上升趨勢,，如果上升趨勢不明顯,，一定是還沒有做更完善的測試，說明需要投入更多的測試,，隨著測試的進行,，BUG數(shù)量會成下降趨勢，經(jīng)過開發(fā)的幾次調(diào)整,，測試的幾輪復(fù)測,，BUG數(shù)量走勢會在經(jīng)過幾次小波動后，趨于穩(wěn)定,，通過這些數(shù)字,，就可以清楚的了解測試的進度,，測試何時需要加強，何時可以退出,，何時可以自動化的介入,，何時可以開始進行性能測試壓力測試等。

同樣的BUG單的數(shù)據(jù),，通過BUG單上模塊進行分類進行分析,，會發(fā)現(xiàn)80%BUG會出現(xiàn)在20%的模塊中，這也是經(jīng)典的“二八原則”,，對于擁有80%錯誤的20%模塊,，測試人員需要進行更多的測試，很有可能有更多的錯誤藏在這20%的模塊中,。這樣可以劃分出測試的輕重,，從而能更加好的計劃出測試投入的時間。

書寫和演講

測試人員平時會遇到很多需要書寫文檔的地方,，如：測試計劃文檔,、測試總結(jié)報告,、測試用例,、自動化測試用例,、自動化測試報告,、性能測試報告等,，也需要開不少的會議,，進行較多的報告演講,。這些也是一個測試人員不可缺少的素質(zhì),。

我總結(jié)的經(jīng)驗就是：寫報告要有理有據(jù),，圖文并茂,，提出一個點，需要給出足夠的證據(jù)與分析過程來進行描述,，而不是只寫一個結(jié)論,，要保證除測試人員外，開發(fā),、需求,、架構(gòu)人員也能從報告中，獲取到相應(yīng)的信息,。至于演講,，盡量不要使用專有名詞，簡單明了,，多做比喻,，證據(jù)充足，由淺入深,，才能讓聽的人接受你的觀點,，認(rèn)同你的分析是正確的,，能獲得更多的幫助者與用戶者，在日后的工作中,，展開會更容易的多,。

作為一名系統(tǒng)測試人員，還需要做到細(xì)心,、耐心,，多注意細(xì)節(jié)。平時也需要多做學(xué)習(xí)：系統(tǒng)的,、網(wǎng)絡(luò)的,、軟件的、硬件的,、數(shù)據(jù)庫的,、語言的等等?？偨Y(jié)也是必不可少的,，把學(xué)到的、用到的知識,，都記錄下來,，會對以后的工作帶來非常多非常多的便利。

好了,，也寫了不少了,，希望我寫的東西，能對一些剛進入測試行業(yè)的,、已進入測試行業(yè)的和一些像了解測試行業(yè)的一些開發(fā)一些幫助,。

希望志同道合的朋友可以平時多交流，共同學(xué)習(xí)軟件測試,。