從零開始編寫自己的C#架構（24）——測試

標籤：style   blog   http   java   color   使用   

　　導航　　1、前言　　2、不堪回首的開發往事　　3、測試推動開發的成長——將Bug消滅在自測中　　4、關於軟體測試　　5、制定測試計劃　　6、編寫測試案例　　7、執行測試案例　　8、發現並提交Bug　　9、開發人員修複Bug　　10、對已修複Bug進行返測　　11、將修複完成的Bug關閉，對未修複的Bug重新啟用　　12、靈活使用壓力測試工具　　13、測試與版本控制　　14、小結　　15、附件下載

 

　　1、前言

　　對於測試，很多公司並不看重，接觸過不少朋友或客戶，開啟網站隨便點擊一下，就可以很容易發現爆黃頁、404、UI變型（瀏覽器安全色）、流程走不通、錯別字......等各種各樣的錯誤。當然也包括我以前工作過的公司，基本上都將測試交給了客戶或網站來訪者，發現有問題時經常是出了問題以後。

　　而我自己一直以來也同樣對這一塊不熟悉，雖然覺得它很重要，但只存在概念上的東西，而不知道怎麼去實施。經手的產品上線前也是自己簡單的測試後覺得沒有問題就上線，而不是系統的測試。直到去年下半年，公司招了位在某互連網知名公司的測試工程師大牛晴哥哥過來後，我才真正明白什麼叫測試，給我上了一堂寶貴的課程，在他的淫威之下，整個技術團隊得以非常明顯的進步，當然我也有了很明顯的成長，在此對晴哥哥無私的付出與幫忙表示真誠的感謝，謝謝了。

 

　　2、不堪回首的開發往事

　　幾乎每個開發人員都會堅信自己的這次修改完成通過，沒有Bug，然後一次次被擊毀這種幻想回到現實。這種經曆犯傻的事情我以前也經常發生，而結果可想而知。

　　03、04年的時候，開發的網站基本上沒測試就直接放上線，經常報黃頁或出錯後，才立馬進行修改，弄得暈頭轉向的。

　　08年的時候在深圳一家軟體公司上班，有一次幫東莞客戶在供應鏈管理系統增加一些新的功能，在本地寫完程式後自我檢查後覺得沒有問題，然後更新代碼並寫SQL語句更新資料，其中有一條刪除語句要刪除某個條件的記錄，動手之前想得好好，可寫的時候忘了加條件，然後直接在生產環境上提交執行......將整個表記錄全刪除了，而當時又不懂資料恢複，公司也不給許可權上百度那些網站，整個人一下就蒙了......還好老闆那裡有Database Backup，幫忙恢複了回去......

　　11年的時候在做KJava手機端應用開發，有一次要對應用進行一次很小的修改，改完後自我感覺應該對其他地方沒有影響，然後就提交給運營部門做群發，當時運營部門也沒有測試直接放到網站上，並開足馬力發送。過了十多分鐘查資料發現沒有計費記錄，然後重新測了軟體才發現原來有個參數改的時候給注釋掉了+_+ ......還好群發的資料量不算太大，損失不多......

　　......

　　還有很多經典的往事或發生在同事身上的囧事，現在都記不清楚了，而出現這些事情的主要原因是，開發人員沒有做好自測工作，太自以為是。當然公司對這一塊沒有重視也是很重要的原因，並沒有形成一套讓開發人員自律的規範，缺少測試部門。

 

　　3、測試推動開發的成長——將Bug消滅在自測中

 　　還是說說一個小故事，4月份時有兩位同事負責一個電子商務網站的註冊、登入、密碼修改、忘記密碼，弄了四五天才搞定（當然除了這個事情外還有其他事情在忙），總是提交測試打回來，然後修改再提交，再打回來......這個重複了N次，氣得晴大哥吐血，聊天記錄不方便全部發出來，而這種事情是否也曾發生在你、我、他......大家的身上呢？

　　

　　事後他們自己總結，主要還是不夠嚴謹，粗心大意引起的，且完成後老是自以為這樣改改就肯定完事了，沒有經過自測就扔到測試環境中。這些大都發生在經驗不足的開發人員身上，而對於其他老牛來說就極少發生這種事情，因為老牛當初也可能被虐過千百遍後成長起來了。

　　當然經過這一次深刻的教訓後，他們兩個都得到了很大的進步，對於要發布的程式自測都做得比較充足，類似的事情就比較少發生。而我們其他程式員在晴哥近半年的鞭撻之下，也有不同程度的長進，整個團隊開發出來的品質已不同往日而言了。

 

　　4、關於軟體測試

　　軟體測試，是用來促進評鑑軟體的正確性、完整性、安全性和品質的過程。軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體品質，並對其是否能滿足設計要求進行評估的過程。

　　對於軟體測試，在軟體開發週期中，它是非常重要的一項工作。一個軟體最終發布後品質如何，這就要看測試專不專業了。

　　從軟體開發的過程按階段劃分有
　　1）單元測試
　　2）整合測試
　　3）確認測試
　　4）系統測試
　　5）驗收測試
　　6）迴歸測試
　　7）Alpha測試
　　8）Beta測試

　　以上是專業測試的分類，而對於我們開發人員經常接觸的則是下面這些內容。

　　Web測試階段劃分主要包括下面內容：

　　功能測試、介面測試、相容性測試、安全性測試、效能測試（包括負載/壓力測試）、預發布測試（如果嚴格點來說還會分不同環境做多好幾種測試）等。

　　當然也有別外一種說法：功能測試、介面測試、可靠性測試、易用性測試、可維護性測試、效能測試、可移植性測試、安全性測試等。

　　正常的測試流程包括下面幾點（每個階段大多都會按下面流程來進行）：
　　1）制定測試計劃
　　2）編寫測試案例
　　3）執行測試案例
　　4）發現並提交Bug
　　5）開發人員修複Bug
　　6）對已修複Bug進行返測
　　7）將修複完成的Bug關閉，對未修複的Bug重新啟用

　　測試過程中需要編寫的文檔有很多，但總的來說每個階段要編寫的文檔主要有測試計劃、測試方案、測試案例和測試報告。

 

　　5、關於測試計劃

　　顧名思義，制定測試計劃，就是安排好將要進行的測試工作計劃。

　　俗話說沒規矩不成方圓，制定出測試計劃後才能安排好具體的工作步驟，協調相關人員配合做好相應工作，做好接下來的測試工作。一個測試計劃應包括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等等（摘自網上，具體內容請有興趣的朋友自行尋找相關文章）。其實也可以簡單的理解為，要編寫測試計劃，首先要查看項目有關的各種文檔，瞭解需求、功能與系統結構，然後再根據功能模組與各個測試階段來安排工作計劃。

　　做為一個開發人員，我們不需要知道測試計劃具體怎麼去編寫，整個測試計劃如何實施，但我們必須瞭解測試的工作內容是什麼，這有利於提高我們開發效率，減少Bug的出現。根據測試計劃，我們很容易安排接下來的開發工作單位，以便配合測試人員做好相應的開發工作。當然我們只有瞭解了測試的方法方式，我們才能更好的做好自測工作。

　　簡單的測試計劃例子：

　　

　　

 

　　6、關於測試案例

　　在將要完成代碼工作，進入測試階段前，通常測試人員會和技術共同開個小會討論測試的相關工作，而這時測試人員會將他們編寫好的測試案例轉寄一份給到我們。一份詳細的測試案例，會帶給我們非常多的驚奇喜，使我們發現原來測試還可以這樣玩的，程式是這樣操作爆出Bug的。就好像突然之前在我們的前面開啟了一扇大門，讓我們的思路與視野突然開闊了起來。

　　看到測試師給的測試案例後，才知道自己寫的代碼對於一些輸入判斷還是有不少地方沒有考慮到的，才知道原來測試是這麼做的。多看看測試案例，可以減少我們程式出現的Bug，特別是寫購物車、訂單之類的功能，稍微一個疏忽就可以產生漏洞，給別人攻擊。

　　會員登陸測試案例：

　　

 

　　7、執行測試案例

　　我們不是大公司，測試師只有晴哥哥一個人，所以提交給他測試前，我們需要進行全面的自測一次，而自測時會按他給我們的測試案例，逐個輸入測試一遍。而每一次Bug修改後，也必須做一次全面的測試。對於需要不厭其煩的一遍又一遍的按測試案例操作，對於我這樣脾氣非常好耐心也不錯的人有時都會感到心煩，有時想偷一下懶沒有完全按測試案例做好自測工作，就被晴哥哥抓個現行，當然被抓現行的不單是我，還有其他同事，哈哈......看到大家都給虐了一遍，心情自然也不錯了......對晴哥哥已經不能說是佩服了，應該是到了五體投地的膜拜這個層次了。

 

　　8、發現並提交Bug

　　通過專業與非專業測試提交的Bug對比後，才知道什麼才是專業精神。

　　在測試時公司會叫上幾位客服和運營人員幫忙測試，而他們提交的某些Bug有時會一頭霧水，只知道出錯了，但不知道是怎麼回事。只有簡單的幾句或截了半個圖，認真看了半天也不知道是那個頁面做了什麼操作後發生了......還得找到當事人慢慢溝通幾次讓他再示範後才明白，有時他自己也不知道為什麼會發生這種情況，在那裡截的圖，那是真心的無語。

　　而專業的測試，會詳細的寫明測試的步驟，提交的內容，正常情況下期望出現的內容，而出現的Bug是如何產生的，再配上幾幅詳細的。一看就清晰明了，重現Bug也相對容易很多，自然修複起來也很容易。

　　當然做為開發人員，測試師與我們是相輔相成的，從他們的工作態度中就可以看出他們也很不容易，要互相體諒，必竟他們需要反反覆複的重複同樣的工作，有時心情煩燥也是很正常的，呵呵...

 

　　9、開發人員修複Bug

　　對於本項工作相信大家都經常在做，所以就不再羅嗦了。想提醒的一點時，Bug修改時千萬不要粗心大意，很多問題就是這樣產生的。而修改完成後一定要按測試案例自測一遍，寧願花多一點時間，而不是過於自信立馬提交，那樣做的話很容易出現前面故事所說的那種現象。

 

　　10、對已修複Bug進行返測

　　對於我們提交的Bug修複，測試人員會對這個Bug進行重新測試，責任心強的測試師會從頭來過，按測試案例一條條的重新建立記錄，進行驗證。從中可以看出能當測試的人脾氣和耐心是真心的不錯，如果大家有妹子未嫁的話，不防可以介紹給測試師哦，哈哈哈......

 

　　11、將修複完成的Bug關閉，對未修複的Bug重新啟用

　　測試師返測完畢後，如果沒發現有問題就會將Bug關閉，而繼續出現Bug，則會重新啟用這個Bug......再然後這個程式員就悲哀了......繼續他的Bug修複之路......

 

　　12、靈活使用壓力測試工具

　　對於開發人員，除了自測外使用測試載入器的機會並不多，而在項目進行最佳化階段或上線後版本迭代時，使用一些壓力測試工具（比如Jmeter）對自己的代碼進行壓力測試還是很有必要的。如果不懂得壓力測試工具的話，那麼寫出的代碼就有可能經受不住上線後的壓力，而導致網站訪問緩慢、客戶流失。同時自己很難分析出代碼的瓶頸做好最佳化工作。

　　舉幾個例子給大家看看：

　　曾經試過對一些客戶的網站做過壓力測試（中小型電商網），10個並發運行一會後網站就掛掉了。

　　以前曾參與開發過一個電商網，300個並發運行過後，CPU與記憶體正常，但伺服器出口頻寬一會就爆掉了，查明原因是網站圖片過多過大，需要將圖片與網站伺服器分開處理。

　　也曾試過伺服器效能一下降得很利害，檢查發現是由於某些資料表記錄量過大，導致資料庫查詢運算佔用過長時間，導致CPU飆升。

　　以前做過的一個電商網，在壓力測試時1K並發沒有問題，然後對一些關鍵的資料表添加記錄，當記錄增加到一定量時就發現了一些異常，檢查過後發現是由於使用NOSQL緩衝，程式一次性載入的記錄量過大時，載入時間過長導致資料載入逾時出現異常。

　　......

　　從上面例子可以看出，很多問題都可以在上線前通過一些測試載入器提前尋找出來，而不是上線後出現問題再進行最佳化處理。有的問題可能可以通過最佳化手段解決，而有的則可能需要對某些代碼，甚至需要對架構架構進行修改才能搞定，提早發現問題可以幫我們減少很多不必要的損失。

　　當然如果有專業的測試師幫你做好這些工作的話，那開發人員就可以輕鬆很多。

 

　　13、測試與版本控制

　　我們開發的代碼不可避免的需要更新換代，而代碼的迭代過程中，測試師是一個非常重要的角色。

　　雖然絕大多數軟體公司都有使用Git、WTF、CVS、Subversion等版本控制工具來管理原始碼，而現實中在很多軟體公司可以發現這種現象，領導、運營部門或客戶提出一個需求進行修改後，則急忙更新到伺服器中，根本就沒有進行專業的測試，控制好上線版本工作，而由此產生了很多不可預知的各種問題。

　　在有測試師參與的項目中，這種現象則比較少發生，原因在於專業的測試會對版本控製得比較嚴格，凡是需要更新到伺服器上的程式，都會經過測試師嚴格的測試且沒有問題後，才會更新到伺服器上。而每次更新到伺服器端的版本，都會經過一系列的測試，而這些版本的源碼也會建立一個分支備份，做為一個穩定版本單獨儲存，其他程式員則在主幹繼續進行開發，萬一更新不成功則可以馬上使用上一個版本進行替換。

 

　　14、小結

　　我不是專業的測試，所以很多關於測試的細節就不詳細描述了，只從開發的角度來講講測試的相關常識，瞭解一下關於測試的基礎知識，如有什麼不正確或遺漏之處敬請諒解。

　　由於時間有限，所以就不對本架構進行全面的測試與編寫對應的測試文檔（水平有限），希望大家在使用的過程中發現Bug後告訴我一下，我會儘快修複後將補丁發布出來的。

 

　　15、附件下載

 　　一些比較專業的自我裝載文檔不能共用出來，所以找測試拿了一些刪減版的測試文檔與模板，大家如果有興趣的話可以下載看看。

測試文檔.rar

 

解決方案20140715補丁.rar

修改模板函數GetFieldValue執行更新時，條件欄位為null的異常，更新後請重建邏輯層代碼

 

 

 著作權聲明：

　　本文由AllEmpty原創並發佈於部落格園，歡迎轉載，未經本人同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結，否則保留追究法律責任的權利。如有問題，可以通過[email protected] 聯絡我，非常感謝。

 

　　發表本編內容，只要主為了和大家共同學習共同進步，有興趣的朋友可以加加Q群：327360708 ，大家一起探討。

 

　　更多內容，敬請觀注部落格：http://www.cnblogs.com/EmptyFS/