在做軟件測試工程師的這幾年，收獲了不少，對軟件測試這一職業的理解也隨著工作經驗有這更加深入的了解，在這里寫一篇關于“軟件測試”的小文，發表一下我個人的一些拙見，供大家探討學習之用。
軟件測試
什么是軟件測試？其實現在很多人對軟件測試這一職業不是很了解，不知到底什么是軟件測試。
關于軟件測試的定義有很多種，我個人覺的比較符合的是：“使用人工或者自動手段來運行或測試某個系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。由于現在軟件發展的十分迅速，軟件的復雜度也越來越高，所以軟件測試現在也變的原來越重要，軟件測試貫穿于整個軟件生命周期，軟件測試并不局限于程序測試，它還包括對相關的需求、文檔的測試，也包括一些多樣化的回歸測試、壓力測試、性能測試等。
關于軟件測試理論知識在很多書中都有詳細的描寫，這里就不摘抄了。但是根據我的經驗，想要做好軟件測試，深入了解軟件測試的理論知識是必不可少的，很多很多實際遇到的問題，都是由于對軟件測試的理論知識的不了解造成的。
測試心理
做好一名軟件測試人員，調整好心理是必須的。
（1）“創造者”與“破壞者”
在心理上，軟件開發和測試最大的區別在于前者是“創造者”而后者是“破壞者”。
對于“創造者”而言，在心理上是不會對自己“創造”出來的產品進行破壞，就像每個人都會很愛惜自己的手工作品。而對于“破壞者”，心理上應該是屬于樂于看到自己測試的系統“崩塌”的場面，就像拿著別人的手工作品摔砸扔來證明那個手工不行一樣。
又如在實際應用中，開發人員會說：“這個功能我測過好幾遍了，沒有問題了”，但測試軟件卻還是能在這個功能里挑出很多的問題，原因在于，開發人員測試時，心理上的關注點放在了“證明這個功能點可行”上，往往會無意識的繞過一些可能會引起問題的操作；而測試人員的關注點放在了“使這個功能點不行”上，會嘗試各種可能造成問題的操作。所以“破壞者”需要利用你所有可知的測試策略與方法，對軟件進行不同程度的“破壞”，檢查各種狀況下，軟件的處理方式與系統的能力。
（2）“第三方視角”&“好奇心”
以第三方的眼光看軟件產品是測試人員與開發人員在進行測試時最大的區別。除了“第三方的視角”，測試人員在心理上還要時常保持“好奇心”，隨著測試的深入，測試人員應不滿足于現有的測試成果，“好奇心”會讓我想知道每次點擊操作背后系統正在做些什么，驅使我去找程序員問個究竟或者看他們的代碼是怎么寫的，看看能否進一步優化系統；“好奇心”會讓我想弄清楚究竟多少用戶同時操作，系統就會崩潰，能否應付系統上線后的正常使用；“好奇心”會驅使我在想用戶如果來使用軟件的時候會如何操作，會遇到什么樣的問題，會不會覺得繁瑣。有了“好奇心”，才能讓系統在上線前就做了更加完備的測試。
（3）“興趣”
“興趣”也是關鍵，做過軟件測試工作的人知道，軟件測試有時候是一個很繁瑣枯燥的工作。比如測試一個表單填寫提交的功能，需要使用不同數據進行填寫并提交，所以非常有可能出現的情況是，這一星期，每天8小時的工作就是坐在電腦前，不停的做著“填寫表單并提交”這樣的簡單機械時勞動，這時，“興趣”是能讓我擺脫枯燥的方法。興趣是最好的老師，如果對測試工作真正感興趣的，就會不斷地研究測試相關的理論知識、技能技巧、工具等。就如上面說的“提交表單”測試，你可以把它當成一種挑戰，目標是搞垮它，這時，就可以嘗試各種各樣測試方法：嘗試不同的填寫數字、在填數字的地方寫英文、在寫英文的地方寫中文、將必填處留空提交、在填寫框中復制上一篇10W字的文章、上傳附件處上傳各式各樣的格式文件、上傳50MB以上的圖片文件、使用QTP反復快速操作、使用QTP Object對象方法篡改頁面控件屬性提交、使用Loadrunner模擬大量用戶同時提交、提交的時候拔掉網線、用Sniffer或HttpWatch抓包進行觀察等等，有太多的方法可以嘗試，再使出渾身解數后，發現不知不覺中，已對表單的各種場景進行了模擬測試，提交了大量表單，時間也覺得一個星期都不夠了呢。用一個比喻來說的話，如James A. Whittaker的《How to Break Software》說的，“像小時候我們拿上一個小玩具，可能就是一個陀螺，甚至是一個拖把，我們也會玩上半天也不會感到厭煩。我們會變著花樣來玩它，我們扮演各種角色，把它當成道具，玩得不亦樂乎?，F在的測試工作是什么，測試的對象有時候就是個玩具，只不過有些看起來過于嚴肅而已。如果我們能把軟件當成玩具來玩，那么我們可能不會那么快就認為測試已經可以停止了。因為還有那么多有趣的玩法還沒嘗試。如果實在是玩膩了，還大可以把玩具狠狠地甩在地上，用腳踩幾下，看它有什么反應。這也是一種測試方法！你是在進行破壞性測試！把你的小腳踏車一邊又一邊地從斜坡上沖下來，每次裝上不同重量的東西，看裝上哪一種東西會最快。哈哈，原來你是在做壓力測試！”
測試方法
測試的方法太多了，不是我一篇小文能夠全部概括的，在這里，我就說一些最基礎的測試方法。
如測試一個登錄界面。有用戶名和密碼框，確定和重置按鈕。用戶名和密碼長度要求為6-12位。
?。?）冒煙測試
我們測試的時候，最先需要使用正確的賬號登錄一遍，這叫“冒煙測試”，“冒煙測試”的作用是判斷一個功能模塊的最基本功能是否實現，如果“冒煙測試”能通過，則繼續進行深入的測試，如果不過，則不繼續進行測試。
冒煙測試是測試的第一步，當發現軟件連最基本的功能都無法實現的時候，應立即終止測試，交于開發處理問題，而不是繼續測試，放慢了整體研發速度。
?。?）邊界值&等價類
當“冒煙測試”過了，則可以進一步進行測試了。這里需要用到“邊界值”和“等價類”的測試思想。何為“邊界值”？邊界值的概念是輸入稍高于其邊界值及稍低于其邊界值的一種測試方法。往往會在邊界值的地方發生錯誤或與需求文檔要求的不符合。如例子中，假設限定用戶名長度只能為6-12位，則我們需要分別對長度為5位、6位、7位、11位、12位、13位這6種長度進行測試，這就是“邊界值”法。何為“等價類”？等價類是一種數學上的概念，在這里是將一個測試點劃分為多種類的集合，如：還是長度只能為6-12位的問題，使用等價類的方法可以劃分為三類：1是小于6位的情況，2是6-12位的情況，3是大于12位的情況。測試的時候，需要在這三類情況中各舉出一套測試數據進行測試。這就是“等價類”。
從概念上來看，邊界值和等價類的方法很好理解，這是軟件測試中，最最基礎的測試方法，但能真正活用于測試項目中的的確不多。從不少的來信中看到，其實還是有很多很多的測試人員不知道這兩種測試方法，更不用說活用。但如電影中最厲害的大招往往是最基礎的招式，小說中最厲害的人往往只是掃地僧，烹飪中最能看出能力的往往是炒蛋炒飯一樣?？匆粋€測試人員的基礎和能力，看他寫的測試用例就知道了。能活用與最簡單的測試方法，才是最有效高效的測試。
（3）錯誤猜想
猜，這也是一種測試方法，這也是用的最多的一種測試方法。當然，不是胡猜，而是有依據的猜。往往經驗豐富的測試人員能“猜”到更多有可能產生問題的情況，寫出更加有效的測試用例。剛剛的登錄例子，可以“猜”在能正常登陸的賬號前或后加個空格，看看是否能正常登錄；可以“猜”輸入空的用戶名和密碼進行登錄的情況；可以“猜”在登錄框中粘貼進大于保存用戶名變量類型的字符個數；可以“猜”在注冊一些帶有奇怪字符或是超出字庫范圍的文字后能否正常登錄；可以“猜”登錄瞬間關掉頁面檢查Sever上Session是否釋放等等，能猜的內容很多很多，隨著經驗的增長和對系統越發的熟悉，會“猜”到更多測試方案。
?。?）場景法
這也是在平時用的比較多的方法，定義不同的場景，進行有規律的測試。主要用于檢查流程等，可使用在有較多分支流程中進行測試。
?。?）失敗測試
純粹為了破壞而設計和執行的測試用例稱為失敗測試?？煽疾煜到y超出需求范圍時的行為。
測試方法太多太多，這里就不一一闡述了，但是上面5種，是用的最基礎也是用的最多的方法。
測試用例
測試用例的重要性不用多了，能規范化測試，記錄所有可能出現的問題，隨著對測試用例的擴充，能越來越達到完備的測試。關于測試用例，我想說的是兩點，“預期結果”與“測試數據”。
（1）預期結果
測試用例中必須要寫的中，最重要的一項是預期結果，我在指導一些網友寫的測試用例的時候，發現這點很難有做的很好的。往往剛接觸測試的人員會在預期結果一欄中寫入諸如“登錄正確”、“提交失敗”等這樣簡單的預期結果。殊不知這樣的寫法和沒寫是差不多的，因為當另一個測試人員進行測試的時候，完全不知道“登錄正確”時的表現形式，應寫明頁面上顯示了些什么，那個角落會有什么樣的顯示，數據是否真正寫到了數據庫中而“提交失敗”需寫明失敗提示到底是什么，是否有彈出框，是有錯誤圖標等等的詳細內容。
在預期結果中不要出現如“查看彈出框中內容是否有圖片”這樣的有兩層意思的句子，即不要出現“是否”。因為這樣的書寫，在別人看來是“查看彈出框中內容是有圖片”是預期結果還是“查看彈出框中內容沒有圖片”是預期結果，這個看來只有寫這條測試用例的人自己知道了。
PS：經常有初入軟件測試的人發郵件給我問，說做軟件測試是如此的枯燥無味，而且很難在一個軟件中找到更多的
BUG了，或是開始抱怨回歸測試的無聊時，我都會告訴他，你還沒找到軟件測試的“興趣”。非常有幸的，我發現了“它”，它讓我工作到現在仍能在軟件測試中找到無限的樂趣與挑戰，也是它，迫使我學習更多的知識。
?。?）測試數據
測試數據需要完整，如在某輸入框中輸入數據，需要寫明需要輸入的內容是什么，是“abcdefg”還是“1234567”，輸入的賬號也需要寫明是什么賬號，而不是寫“輸入正確的賬號”，在別人測試過程中，是不知道什么才是正確的賬號。如果這個賬號不會變動（如管理員賬號），則在測試數據中需寫明“輸入賬號：admin，密碼：123456”，如賬號是常變動的（如用戶賬號），需在測試用例的前置條件中申明賬號的可用性，如前置條件中寫“系統存在賬號為user123，密碼為123456789的用戶”，這時在測試數據中就可以寫“試用賬號user123，密碼為123456789進行登錄”。
總之，寫測試用例的時候，注意仔細與嚴謹。時常檢查自己寫的測試用例別人是否也能看懂。小組中有多么測試人員的，需要時常對測試用例進行評審，從而保證測試用例的高質量。
BUG單
提交BUG也是一門功課，既要簡單易讀，又要能說明問題。所以需要在BUG單中寫清楚復現的步驟，錯誤出現的頻率，嚴重性和優先級，一個BUG單講述一個問題，不可將多個問題寫于同一篇BUG單中，BUG單中需注意語氣，不得帶有情緒，如果BUG存在爭議，需要提供證據進行證明，如需求說明說，可以咨詢需求人員，如果什么都沒有可以參考行業軟件規范。
我談一下我在實際項目中遇到的一些問題，一次參加客戶方關于提交BUG單規范的會議，發現了如下問題：
?。?）客戶方想只使用一個數值，來定義嚴重性和優先級。真是不應該的，嚴重性和優先級是兩個不同的概念，嚴重性高的BUG不一定優先級就高，而嚴重性低的BUG很有可能優先級是最高的。如一個很少用的功能在一定的操作下會導致程序無響應，但是決定在下一個版本再進行修復，則它的嚴重性雖然是高，但是優先級確是低，而一個馬上要投入使用的功能點中，頁面上顯示的標題不正確不影響使用，雖然嚴重性是低，但優先級確實高。像這樣的情況使用一個數值便很難描述出BUG的嚴重情況和優先情況。
（2）客戶方的部分測試人員認為一張表單上的3種不同類型的問題可以寫在一個BUG單上。這也是不可以的，有時候雖然是一個頁面上的，但有可能3個錯誤點是由3個不同的開發人員開發的。這時，讓一個開發修改完成而兩個開發未修改時，無法正確調整BUG單狀態，導致測試進度收集也不完全，很難定位到還有多少問題需要修改。
?。?）客戶方將BUG的數量和測試人員的效益與開發員工的效益掛鉤，這個在管理中也是萬萬不可以的。會導致大量BUG冗余；開發修改大量嚴重程度非常低的小BUG導致延緩整個項目的進度；很少有測試人員會花更多的時間去找難以發現的BUG；造成開發和測試之間如仇家等等的問題。
自動化
在進入公司后，客戶方就交給了我一個非常艱巨的任務，要做現有系統的自動化測試平臺。還好對QTP比較熟悉，到目前為止，已經寫好BPM 1.0系統的自動化測試框架，和不少表單腳本，并將BPM 1.0的腳本經過修改后，復用至BPM 2.0版本。
如何進行自動化測試框架的搭建，我會在以后的文章中寫明。
所以在這里，我說幾點關于自動化測試的一些簡單的知識和我的一些經驗。很明顯，自動化測試從字面上來理解，就是讓電腦自動完成所需要的測試內容。如填寫表單的測試，我可以預先將所要填寫的內容寫好，然后下班后，讓電腦自動逐條進行填寫，提交，記錄測試的結果?？此坪芸?，但需要考慮的問題很多，最主要的是，需要有一定的編程基礎，畢竟，腳本是要靠“寫”的。在很多網友來信中發現，很多人對自動化的理解和自動化所能做的功能有一點偏差。主要有以下幾點：
只要開發出強大的自動化測試腳本，就能將測試人員解放出來。其實不是的，很多的測試都是靠手工進行測試，自動化只是輔助。比如頁面的排版是否好看，第一次測試時遇到的各種各樣的問題，因為開發做了較大的改變等等一些問題時，自動化的執行就會失敗。
對于需求會經常修改的系統如何進行自動化腳本的編寫。對于這樣需求會經常變動的系統，就不能開展自動化測試，還是老老實實的進行手工測試吧。
在軟件測試理論知識還不是很牢固的情況下，不要進行自動化。對軟件測試和自動化測試的錯誤理解會導致后期自動化進行十分的困難且根本沒辦法維護腳本。
在軟件版本還沒有穩定的情況下，不要進行自動化
領導不支持的情況下，不要進行自動化
系統中測試對象基本可以正常識別的情況下才進行自動化腳本的編寫。
自動化測試一般的情況下是用來證明軟件能正常運行，而不是用在證明軟件這么操作一定會出錯上。
記住，自動化測試最主要的是提高工作效率，正確的使用是，用1天開發一個腳本能用3個月的測試，而不是花3個月開發出一個很牛的腳本來測試1天，非常多初學者會范這個錯誤，我曾經也范過。
分析
學會分析數據也是軟件測試中必要的一項。優秀的軟件測試人員能通過各種數字，得到當前系統的各種信息。在性能測試中，分析數據顯得尤為重要，一個做金融保險類系統性能測試的前輩和我說過，做性能測試，用使用Loadrunner，編寫腳本設計場景，學的話幾個月就能搞定，但是分析執行腳本后的數據，可能需要2-3年的工作經驗，才能看到你想看到的信息。
說些簡單常用的，通過分析BUG數據，就發現很多有用的信息。如：當系統剛剛開發完成，交給測試人員進行測試的時候，BUG數量一定是呈上升趨勢，如果上升趨勢不明顯，一定是還沒有做更完善的測試，說明需要投入更多的測試，隨著測試的進行，BUG數量會成下降趨勢，經過開發的幾次調整，測試的幾輪復測，BUG數量走勢會在經過幾次小波動后，趨于穩定，通過這些數字，就可以清楚的了解測試的進度，測試何時需要加強，何時可以退出，何時可以自動化的介入，何時可以開始進行性能測試壓力測試等。
同樣的BUG單的數據，通過BUG單上模塊進行分類進行分析，會發現80%BUG會出現在20%的模塊中，這也是經典的“二八原則”，對于擁有80%錯誤的20%模塊，測試人員需要進行更多的測試，很有可能有更多的錯誤藏在這20%的模塊中。這樣可以劃分出測試的輕重，從而能更加好的計劃出測試投入的時間。
書寫和演講
測試人員平時會遇到很多需要書寫文檔的地方，如：測試計劃文檔、測試總結報告、測試用例、自動化測試用例、自動化測試報告、性能測試報告等，也需要開不少的會議，進行較多的報告演講。這些也是一個測試人員不可缺少的素質。
我總結的經驗就是：寫報告要有理有據，圖文并茂，提出一個點，需要給出足夠的證據與分析過程來進行描述，而不是只寫一個結論，要保證除測試人員外，開發、需求、架構人員也能從報告中，獲取到相應的信息。至于演講，盡量不要使用專有名詞，簡單明了，多做比喻，證據充足，由淺入深，才能讓聽的人接受你的觀點，認同你的分析是正確的，能獲得更多的幫助者與用戶者，在日后的工作中，展開會更容易的多。
作為一名系統測試人員，還需要做到細心、耐心，多注意細節。平時也需要多做學習：系統的、網絡的、軟件的、硬件的、數據庫的、語言的等等。總結也是必不可少的，把學到的、用到的知識，都記錄下來，會對以后的工作帶來非常多非常多的便利。
好了，也寫了不少了，希望我寫的東西，能對一些剛進入測試行業的、已進入測試行業的和一些像了解測試行業的一些開發一些幫助。
希望志同道合的朋友可以平時多交流，共同學習軟件測試。
版權聲明：本文出自 黑羽祭 的51Testing軟件測試博客：http://www.51testing.com/?307440
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。