對于測試，很多公司并不看重，接觸過不少朋友或客戶，打開網站隨便點擊一下，就可以很容易發現爆黃頁、404、UI變型（瀏覽器兼容）、流程走不通、錯別字......等各種各樣的錯誤。當然也包括我以前工作過的公司，基本上都將測試交給了客戶或網站來訪者，發現有問題時經常是出了問題以后。
而我自己一直以來也同樣對這一塊不熟悉，雖然覺得它很重要，但只存在概念上的東西，而不知道怎么去實施。經手的產品上線前也是自己簡單的測試后覺得沒有問題就上線，而不是系統的測試。直到去年下半年，公司招了位在某互聯網知名公司的測試工程師大牛晴哥哥過來后，我才真正明白什么叫測試，給我上了一堂寶貴的課程，在他的淫威之下，整個技術團隊得以非常明顯的進步，當然我也有了很明顯的成長，在此對晴哥哥無私的付出與幫忙表示真誠的感謝，謝謝了。
幾乎每個開發人員都會堅信自己的這次修改完成通過，沒有Bug，然后一次次被擊毀這種幻想回到現實。這種經歷犯傻的事情我以前也經常發生，而結果可想而知。
03、04年的時候，開發的網站基本上沒測試就直接放上線，經常報黃頁或出錯后，才立馬進行修改，弄得暈頭轉向的。
08年的時候在深圳一家軟件公司上班，有一次幫東莞客戶在供應鏈管理系統增加一些新的功能，在本地寫完程序后自我檢查后覺得沒有問題，然后更新代碼并寫SQL語句更新數據，其中有一條刪除語句要刪除某個條件的記錄，動手之前想得好好，可寫的時候忘了加條件，然后直接在生產環境上提交執行......將整個表記錄全刪除了，而當時又不懂數據恢復，公司也不給權限上百度那些網站，整個人一下就蒙了......還好老板那里有數據庫備份，幫忙恢復了回去......
11年的時候在做Kjava手機端應用開發，有一次要對應用進行一次很小的修改，改完后自我感覺應該對其他地方沒有影響，然后就提交給運營部門做群發，當時運營部門也沒有測試直接放到網站上，并開足馬力發送。過了十多分鐘查數據發現沒有扣費記錄，然后重新測了軟件才發現原來有個參數改的時候給注釋掉了+_+ ......還好群發的數據量不算太大，損失不多......
......
還有很多經典的往事或發生在同事身上的囧事，現在都記不清楚了，而出現這些事情的主要原因是，開發人員沒有做好自測工作，太自以為是。當然公司對這一塊沒有重視也是很重要的原因，并沒有形成一套讓開發人員自律的規范，缺少測試部門。
還是說說一個小故事，4月份時有兩位同事負責一個電子商務網站的注冊、登錄、密碼修改、忘記密碼，弄了四五天才搞定（當然除了這個事情外還有其他事情在忙），總是提交測試打回來，然后修改再提交，再打回來......這個重復了N次，氣得晴大哥吐血，聊天記錄不方便全部發出來，而這種事情是否也曾發生在你、我、他......大家的身上呢？
事后他們自己總結，主要還是不夠嚴謹，粗心大意引起的，且完成后老是自以為這樣改改就肯定完事了，沒有經過自測就扔到測試環境中。這些大都發生在經驗不足的開發者身上，而對于其他老牛來說就極少發生這種事情，因為老牛當初也可能被虐過千百遍后成長起來了。
當然經過這一次深刻的教訓后，他們兩個都得到了很大的進步，對于要發布的程序自測都做得比較充足，類似的事情就比較少發生。而我們其他程序員在晴哥近半年的鞭撻之下，也有不同程度的長進，整個團隊開發出來的質量已不同往日而言了。
軟件測試，是用來促進鑒定軟件的正確性、完整性、安全性和質量的過程。軟件測試的經典定義是：在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。
對于軟件測試，在軟件開發周期中，它是非常重要的一項工作。一個軟件最終發布后質量如何，這就要看測試專不專業了。
從軟件開發的過程按階段劃分有 1）單元測試 2）集成測試 3）確認測試 4）系統測試 5）驗收測試 6）回歸測試 7）Alpha測試 8）Beta測試
以上是專業測試的分類，而對于我們開發人員經常接觸的則是下面這些內容。
Web測試階段劃分主要包括下面內容：
功能測試、界面測試、兼容性測試、安全測試、性能測試（包括負載/壓力測試）、預發布測試（如果嚴格點來說還會分不同環境做多好幾種測試）等。
當然也有別外一種說法：功能測試、界面測試、可靠性測試、易用性測試、可維護性測試、性能測試、可移植性測試、安全性測試等。
正常的測試流程包括下面幾點（每個階段大多都會按下面流程來進行）： 1）制定測試計劃 2）編寫測試用例 3）執行測試用例 4）發現并提交Bug 5）開發人員修復Bug 6）對已修復Bug進行返測 7）將修復完成的Bug關閉，對未修復的Bug重新激活
測試過程中需要編寫的文檔有很多，但總的來說每個階段要編寫的文檔主要有測試計劃、測試方案、測試用例和測試報告。
顧名思義，制定測試計劃，就是安排好將要進行的測試工作計劃。
俗話說沒規矩不成方圓，制定出測試計劃后才能安排好具體的工作步驟，協調相關人員配合做好相應工作，做好接下來的測試工作。一個測試計劃應包括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等等（摘自網上，具體內容請有興趣的朋友自行查找相關文章）。其實也可以簡單的理解為，要編寫測試計劃，首先要查看項目有關的各種文檔，了解需求、功能與系統結構，然后再根據功能模塊與各個測試階段來安排工作計劃。
做為一個開發人員，我們不需要知道測試計劃具體怎么去編寫，整個測試計劃如何實施，但我們必須了解測試的工作內容是什么，這有利于提高我們開發效率，減少Bug的出現。根據測試計劃，我們很容易安排接下來的開發任務，以便配合測試人員做好相應的開發工作。當然我們只有了解了測試的方法方式，我們才能更好的做好自測工作。
簡單的測試計劃例子：
在將要完成代碼工作，進入測試階段前，通常測試人員會和技術共同開個小會討論測試的相關工作，而這時測試人員會將他們編寫好的測試用例轉發一份給到我們。一份詳細的測試用例，會帶給我們非常多的驚奇喜，使我們發現原來測試還可以這樣玩的，程序是這樣操作爆出Bug的。就好像突然之前在我們的前面打開了一扇大門，讓我們的思路與視野突然開闊了起來。
看到測試師給的測試用例后，才知道自己寫的代碼對于一些輸入判斷還是有不少地方沒有考慮到的，才知道原來測試是這么做的。多看看測試用例，可以減少我們程序出現的Bug，特別是寫購物車、訂單之類的功能，稍微一個疏忽就可以產生漏洞，給別人攻擊。
會員登陸測試用例：
我們不是大公司，測試師只有晴哥哥一個人，所以提交給他測試前，我們需要進行全面的自測一次，而自測時會按他給我們的測試用例，逐個輸入測試一遍。而每一次Bug修改后，也必須做一次全面的測試。對于需要不厭其煩的一遍又一遍的按測試用例操作，對于我這樣脾氣非常好耐心也不錯的人有時都會感到心煩，有時想偷一下懶沒有完全按測試用例做好自測工作，就被晴哥哥抓個現行，當然被抓現行的不單是我，還有其他同事，哈哈......看到大家都給虐了一遍，心情自然也不錯了......對晴哥哥已經不能說是佩服了，應該是到了五體投地的膜拜這個層次了。
通過專業與非專業測試提交的Bug對比后，才知道什么才是專業精神。
在測試時公司會叫上幾位客服和運營人員幫忙測試，而他們提交的某些Bug有時會一頭霧水，只知道出錯了，但不知道是怎么回事。只有簡單的幾句或截了半個圖，認真看了半天也不知道是那個頁面做了什么操作后發生了......還得找到當事人慢慢溝通幾次讓他再演示后才明白，有時他自己也不知道為什么會發生這種情況，在那里截的圖，那是真心的無語。
而專業的測試，會詳細的寫明測試的步驟，提交的內容，正常情況下期望出現的內容，而出現的Bug是如何產生的，再配上幾幅詳細的截圖。一看就清晰明了，重現Bug也相對容易很多，自然修復起來也很容易。
當然做為開發人員，測試師與我們是相輔相成的，從他們的工作態度中就可以看出他們也很不容易，要互相體諒，必竟他們需要反反復復的重復同樣的工作，有時心情煩燥也是很正常的，呵呵...
對于本項工作相信大家都經常在做，所以就不再羅嗦了。想提醒的一點時，Bug修改時千萬不要粗心大意，很多問題就是這樣產生的。而修改完成后一定要按測試用例自測一遍，寧愿花多一點時間，而不是過于自信立馬提交，那樣做的話很容易出現前面故事所說的那種現象。
對于我們提交的Bug修復，測試人員會對這個Bug進行重新測試，責任心強的測試師會從頭來過，按測試用例一條條的重新創建記錄，進行驗證。從中可以看出能當測試的人脾氣和耐心是真心的不錯，如果大家有妹子未嫁的話，不防可以介紹給測試師哦，哈哈哈......
測試師返測完畢后，如果沒發現有問題就會將Bug關閉，而繼續出現Bug，則會重新激活這個Bug......再然后這個程序員就悲哀了......繼續他的Bug修復之路......
對于開發人員，除了自測外使用測試工具的機會并不多，而在項目進行優化階段或上線后版本迭代時，使用一些壓力測試工具（比如Jmeter）對自己的代碼進行壓力測試還是很有必要的。如果不懂得壓力測試工具的話，那么寫出的代碼就有可能經受不住上線后的壓力，而導致網站訪問緩慢、客戶流失。同時自己很難分析出代碼的瓶頸做好優化工作。
舉幾個例子給大家看看：
曾經試過對一些客戶的網站做過壓力測試（中小型電商網），10個并發運行一會后網站就掛掉了。
以前曾參與開發過一個電商網，300個并發運行過后，CPU與內存正常，但服務器出口帶寬一會就爆掉了，查明原因是網站圖片過多過大，需要將圖片與網站服務器分開處理。
也曾試過服務器性能一下降得很利害，檢查發現是由于某些數據表記錄量過大，導致數據庫查詢運算占用過長時間，導致CPU飚升。
以前做過的一個電商網，在壓力測試時1K并發沒有問題，然后對一些關鍵的數據表添加記錄，當記錄增加到一定量時就發現了一些異常，檢查過后發現是由于使用NOSQL緩存，程序一次性加載的記錄量過大時，加載時間過長導致數據加載超時出現異常。
......
從上面例子可以看出，很多問題都可以在上線前通過一些測試工具提前查找出來，而不是上線后出現問題再進行優化處理。有的問題可能可以通過優化手段解決，而有的則可能需要對某些代碼，甚至需要對框架架構進行修改才能搞定，提早發現問題可以幫我們減少很多不必要的損失。
當然如果有專業的測試師幫你做好這些工作的話，那開發人員就可以輕松很多。
我們開發的代碼不可避免的需要更新換代，而代碼的迭代過程中，測試師是一個非常重要的角色。
雖然絕大多數軟件公司都有使用Git、WTF、CVS、Subversion等版本控制工具來管理源代碼，而現實中在很多軟件公司可以發現這種現象，領導、運營部門或客戶提出一個需求進行修改后，則急忙更新到服務器中，根本就沒有進行專業的測試，控制好上線版本工作，而由此產生了很多不可預知的各種問題。
在有測試師參與的項目中，這種現象則比較少發生，原因在于專業的測試會對版本控制得比較嚴格，凡是需要更新到服務器上的程序，都會經過測試師嚴格的測試且沒有問題后，才會更新到服務器上。而每次更新到服務器端的版本，都會經過一系列的測試，而這些版本的源碼也會創建一個分支備份，做為一個穩定版本單獨保存，其他程序員則在主干繼續進行開發，萬一更新不成功則可以馬上使用上一個版本進行替換。
我不是專業的測試，所以很多關于測試的細節就不詳細描述了，只從開發的角度來講講測試的相關常識，了解一下關于測試的基礎知識，如有什么不正確或遺漏之處敬請諒解。
由于時間有限，所以就不對本框架進行全面的測試與編寫對應的測試文檔（水平有限），希望大家在使用的過程中發現Bug后告訴我一下，我會盡快修復后將補丁發布出來的。
一些比較專業的內部測試文檔不能共享出來，所以找測試拿了一些刪減版的測試文檔與模板，大家如果有興趣的話可以下載看看。
測試文檔.rar
解決方案20140715補丁.rar
修改模板函數GetFieldValue執行更新時，條件字段為null的異常，更新后請重新生成邏輯層代碼
版權聲明： 本文由AllEmpty原創并發布于博客園，歡迎轉載，未經本人同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利。如有問題，可以通過1654937@QQ.com 聯系我，非常感謝。
發表本編內容，只要主為了和大家共同學習共同進步，有興趣的朋友可以加加Q群：327360708 ，大家一起探討。
更多內容，敬請觀注博客：http://www.49028c.com/EmptyFS/
新聞熱點
疑難解答
