軟體測試，談談對軟體測試的看法，從來沒有想過對這麼大一個話題來說出自己的一個想法或者說對軟體測試的理解，我就覺得自己能不能把自己對軟體測試的瞭解說說，或者說彙總彙總下這三四年來自己從事的行業，也算是自己的一種總結吧。
首先談談什麼是軟體測試，簡單來說軟體測試就是通過一個過程或一系列的過程，用來確認程式碼完成了它應該有的功能，不執行它不該有的功能，我們如何確定哪些功能是應該有的哪些功能是不應該有的，不是軟體開發或是軟體測試人員說了算的，這些確定的需求都來自於客戶的需求文件。(軟體測試人員是需要參與需求文件的評審的，一個比較完善測試流程，測試工程師從需求文件開始就參與進專案)。
知道軟體測試的定義知道後，我們需要了解的就是軟體測試的分類，軟體測試從不同的角度可以分為不同的種類，接下來我們就來了解下這些分類。
第一種分類：
- 功能測試： 主要關注點是所測系統的功能是否實現，是否滿足需求文件中所提到的功能（既不能多也不能少）；
- 介面（UI）測試： 主要關注點是所測系統的介面，是否會出現一些截斷的現象，介面的排版是否正常；
- 效能測試： 這塊主要分為效能測試（這塊主要關注的是需求文件裡面定義好了具體的需求，比如這個系統最多能容納多少使用者登入使用，或者系統能同時能承受多少使用者登入，然後根據效能測試工具能進行測試，按照需求文件中所指的明確值來進行測試，如果不能達到，就得尋求優化系統的方法，看是哪部分出現了錯誤），壓力測試（），負載測試，併發測試等測試。
- 國際化本地化測試： 這部分主要是主要測試的是軟體在不同的國家能否滿足當地市場的風俗習慣和語言習慣等，國際化測試指的是該軟體本身是哪個國家開發的，然後將這個軟體安裝在不同語言的作業系統上，看被測系統是不是符合需求文件的，舉個例子（針對英文或日語的軟體的國際化測試就是把英文的或日文的軟體安裝在各國不同語言的作業系統上來進行驗證）。而本地化測試指的卻是將不同語言的軟體或系統翻譯成當地的語言然後將翻譯後的軟體或系統裝在本地語言的作業系統進行測試，看被測軟體系統是否滿足需求文件中所提到得需求，在舉個例子（還是英文的或日本的軟體系統需要本地化成韓語或漢語，這個時候就需要將英文的或日文的軟體系統翻譯成韓語或簡中的語言然後在韓語的系統或中文的系統上進行測試，然後確定被測試系統是否滿足需求文件）。
第二種分類：
- 黑盒測試 ： 從測試方法的名字上我們可以看出，這種測試的方式就是我們把被測的軟體系統當成一個黑盒子來對待，我們只能看到盒子的表面功能而看不到盒子的內部結構和構成。這種測試的特點是不關注被測軟體系統內部是怎麼實現的，不用管被測系統到底是呼叫了什麼方法，到底採用什麼樣的架構實現的，單純的關注軟體測試我們看到的部分，主要從軟體的功能和介面方面進行測試。
- 白盒測試： 就是把被測軟體系統當成一個白盒子來對待，是能夠看到盒子的內部的結構的，能知道產品內部的工作流程，知道設計該系統語言邏輯是否正常，是通過檢查軟體系統的內部構造來驗證該軟體系統是否滿足需求文件的。
- 灰盒測試： 介於白盒測試和黑盒測試之間的一種測試方法，可以理解為灰盒測試即關心軟體輸入對輸出結果的正確表現，也關心軟體內部結構的測試。
第三種分類：
一個系統的編碼開始到客戶使用，這個過程有一個測試流程的分類：
單元測試;（一般這個階段是由開發人員自己測試自己的程式碼，比如java有JUnit和TestNG等單元測試框架），何為單元測試呢，就是開發人員編寫完一個模組或一個功能以後的自測行為；
整合測試：兩個或兩個以上的模組或功能整合以後進行的測試，驗證的是各個模組之間的藉口之間是否存在問題，有些時候雖然單個模組是OK的，但是幾個模組整合以後就會出現一些問題，這個測試過程測試人員就可以進行測試；
系統測試： 基本的系統已經成型以後的測試
驗收測試： 系統要上線之前進行的測試，在驗收測試階段我們需要做的事情很多，這些都需要測試人員出具體的文件來進行驗收：
- 功能確認測試
- 安全可靠性測試
- 易用性測試
- 可擴充性測試
- 相容性測試
- 資源佔用率測試
- 使用者文件資料驗收
第四種分類：
- 手工測試： 手工測試就是由人一個測試用例一個測試用例執行來驗證系統是否滿足使用者的需求，這裡提到了測試用例，下面會對測試用例進行具體的分析和講解。手工測試主要從事的就是根據測試用例通過鍵盤滑鼠對系統進行輸入然後參看輸出結果是否是預期的結果，預期結果也來自於需求文件。
- 自動化測試： 何為自動化測試呢？就是通過測試工具或程式碼來實現的測試。自動化測試分為功能自動化測試和效能自動化測試，
功能自動化測試：就是把手工測試轉換成機器來執行（就是將手工執行的測試用例轉換成程式碼來實現相應的功能），以此來提高工作的效率和加強測試的覆蓋率，
效能自動化測試： 因為進行效能測試，我們需要模擬更多的使用者或者對系統進行瓶頸方面的測試，所以這個階段我們需要藉助工具來對系統來進行對應的測試，現在市面上比較火的的效能測試工具有LoadRunner（收費的，但是萬能的我國人民永遠能找到祕鑰，哈哈）還有Apache開源的效能測試工具JMeter+Badboy，通過這些工具我們能模擬成千上萬的使用者對系統進行測試。
第五種分類：
對於下面的幾種分類也是在做專案的過程中，不同的公司會根據不同的專案所進行的相關進行的測試階段，這幾種可以不認為是測試的分類，就是在系統測試不同的階段所進行的測試過程，所以也由必要說說相關的術語，求別誤導廣大人民字第，完全是個人的想法。
- 冒煙測試： 何為冒煙測試，從字面上可是看不出到底是指的哪方面的測試型別，但是專案測試階段是非常有必要進行的，具體指的就是一個大型專案開始測試之前，需要對軟體基本是實現的功能進行一個流程化的測試，看這個系統把最基本的功能實現沒有，如果基本功能沒有實現，那就是這個系統不具備可測試性，測試人員可不是什麼垃圾都收的，這個時候就需要把該專案打回去重新指給開發部門。這樣有利於節省專案成本。
- 迴歸測試： 是指已經對系統進行了一遍完整的測試，發現了許多問題反饋給開發以後進行的下一輪測試，這輪測試我們需要驗證之前的問題是否還會重現，還要確認被修改的部分沒有引起其它地方出現問題，迴歸測試其實也是一個迴圈測試的過程，重複性比較大，所以在自動化測試中我就提到了，功能自動化測試一般是在迴歸測試階段進行的。
- 隨機測試或探索性測試： 隨著敏捷開發的盛行也隨之誕生了敏捷測試，這樣就產生了隨機測試或探索性測試的概念，簡單一句話，就是根據測試人員的經驗隨機性的測試測試用例沒有覆蓋到的地方（測試用例是不可能完全覆蓋所有的功能的，只能做到儘量覆蓋到，採用不同的測試用例編寫方法，後面慢慢說這塊）。
測試方法的分類不單單隻有這幾種，還有更多的分類，作為測試人員需要知道自己所處的階段，進行的是哪方面的測試，這樣利用不同的技術才能更高效的進行測試。
測試用例
對於測試用例，怎麼說這塊呢，測試用例這塊在測試團隊應該佔一定的比例，上家公司就會有專門的測試用例團隊，專門研究和進行測試用例的編寫，而且不同的公司採用的測試用例模板也完全不同，有的公司採用word來進行儲存，有的採用Excel或思維導圖，還有Visor畫的流程圖，測試用例的粗細程度也不盡相同，有的公司會把測試用例寫到面面俱到，輸入的字元都定義好了，有的公司則完全相反，測試用例寫的相對比較粗。其實這兩種也是各有利弊的，測試用例細的團隊方便新進入的成員快速瞭解系統的測試流程，但是不利於測試人員的發散，限制了測試工程師的思維，顆粒度粗的測試用例則方便了測試工程師利用自己的經驗來進行測試，能覆蓋更多的地方，發現更多的問題，但是卻也存在一定的弊端，對一些NewComer可能就是一個挑戰了。
說了這麼多，那麼到底什麼是測試用例呢？一條測試用例應該包含哪些具體的內容呢？
簡單一句話來描述測試用例就是：就是測試人員把測試系統的操作步驟（來自於需求文件）按照一定的格式用文字描述出來，
功能自動化測試的測試用例，就是把手工測試的測試用例轉換成程式碼指令碼的過程。
但是一條基本的測試用例應該包含：
- 測試用例名字：就是對該測試用例所驗證的功能進行一個簡短的描述
- 前置條件： 就是為了驗證這條測試用例先前所做的動作，也是一句話簡短的描述（解釋下這塊啊，比如說我們要測試一個登入系統的操作，前提條件就是我們需要擁有這個系統的使用者名稱，首先得註冊一個賬戶在這個系統上，但是我們不可能說再次將註冊的這個動作在進行一次（因為已經有其它測試用例已經覆蓋到這個功能點了，在寫的話只能是畫蛇添足多此一舉了），所以在這裡我們僅僅只需要一句話"已存在註冊該系統的使用者"來作為前置條件一句帶過）
- 輸入動作： 就是為了驗證一個結果之前，我們肯定會有動作（這裡還是以驗證登入為例子，我們為了驗證登入是否成功，所以這裡的動作就是，輸入使用者名稱，輸入密碼，有的系統還需要輸入驗證碼，然後點選登入按鈕等輸入動作）
- 輸出結果： 有了前提條件和輸入動作，最後就應該有個輸出結果，系統返回的輸出結果，（成功或失敗，比如說登入這個驗證，成功的標示就是成功跳轉到主頁，並且顯示該使用者登入成功，失敗的標示就是多種多樣的了，可能沒有反應，可能報錯，可能頁面不能跳轉，或者顯示不是該使用者登入等等），根據輸出結果來進行判斷測試是通過還是失敗。
知道了什麼是測試用例，也知道了測試用例的基本構成元素，接下來我們就來看看測試用例的編寫方法，下面的一些方法也是我在專案中常用的一些基本的方法。根據這些方法能讓你的測試用例編寫起來更有調理，思路更清晰，也具有更高的覆蓋率，
對於這些測試用例的編寫方法，我也說不出一個具體的概念，所有的方法我都以舉例子的方式來講解，或許更容易理解。
- 等價類劃分
這裡舉個使用者註冊的例子，比如使用者名稱的輸入框是有限制的，它的限制條件是使用者名稱的長度是8~16位的字串（這些字串只能是數字、字母以及下劃線）組成
我們根據等價類劃分，就可以分為有效等價類和無效等價類。
有效等價類： 輸入字元的長度在 8~16位之間， 輸入的字串是由數字或字母或下劃線或它們之間的組合這些組合
無效等價類：
- 輸入的字元長度小於8位字元
- 輸入的字元長度大於16位字元
- 輸入了非法的字元比如"@#￥%……！"等不滿足要求的字串
然後根據這些字元來編排測試用例。
- 邊界值分析：
在以往編寫測試用例的經驗中，邊界值分析和等價類劃分永遠是放在一起來使用的，根據經驗系統出問題的地方很多時候都是在邊界值的地方。
還是舉上面的那個註冊使用者名稱長度8~16位的例子來進行說明，
我們根據邊界值分析的方法，我們就需要在測試用例中插入剛好是6位字元和7位字元8位字元9位字元，14位15位16位17位18位等字元長度來進行驗證
- 錯誤推測法：
也就是反向思維來思考這件事，比如說一個輸入框只能輸入"a、b、c、d、e"這五個字元，你可以設計輸入"q""A"等字元預期結果應該是報錯的，如果沒有報錯那就是問題。
還有一些其它的方法，比如正交分解法、因果圖、流程分析法等這些方法，這些我在實際專案中我也很少用到，也就不在這說了，上面的三種方法應該就足夠能應付測試用例的編寫方法，而且也是我在專案中長用到的。
根據實際的專案，也總結了一些一個Web頁面的基本檢查點，在編寫測試用例的過程中，根據這些基本檢查點然後結合具體專案的需求擴充套件設計的測試用例，然後結合上面測試用例的編寫方法。
基本檢查點：
- 頁面元素的檢查（頁面的完整性、頁面元素的排版、字型的排版等）
- 頁面必輸項功能檢查（頁面上存在一些必輸項和可選項，檢查相對應的提示資訊）
- 頁面上輸入文字框的功能檢查（文字長度、文字字元型別、文字框特殊字元的輸入、特殊格式【比如郵箱等帶@】的輸入等）
- 頁面上日期控制元件的功能檢查（日期的選擇、日期的儲存、日期的選擇範圍等）
- 頁面上單選框的檢查
- 頁面上多選框的檢查
- 頁面上下拉框的檢查
- 頁面上按鈕的檢查
- 頁面上快捷鍵的使用（主要是Tab建、Space鍵、Esc鍵等等）
BUG的生命週期
測試的過程中肯定會伴隨著BUG的產生，遇到BUG了，該如何寫出一個相對完善的BUG呢？在這塊每個公司針對不同的專案肯定會有不同的要求，但是最基本的內容也就如下，我覺得下面的這個BUG模板還是包含了一個BUG所需要的所有資訊了，開發也能輕易的明白。
BUG Template:
Bug Title："簡單一句話描述下這個問題"
Bug 描述： "描述下問題的原因，以及產生BUG中的一些問題和依賴關係"
測試環境： "描述測試環境的具體資訊，包括作業系統、應用系統平臺版本、資料庫系統版本、瀏覽器型別"等等，把你發現問題的系統平臺的資訊描述出來，為什麼需要這塊呢？有可能是相容性的問題，不描述清楚，開發人員可能在他本地上無法重現。
重現步驟(儘量描述清楚，不要讓人感覺有歧義)：
步驟1….
步驟2…
步驟n…
實際結果：描述下通過上面的操作後實際產生的效果和輸出結果
預期結果：根據需求文件，進行上述步驟操作後應該得到的效果和輸出結果。
注意事項：描述下產生這個BUG的過程中要注意的事情，比如說只有IE上重現，Chrome上不重現等
客戶影響：這個問題會對客戶產生什麼樣的影響。