從零開始編寫本身的C#框架（24）——測試

時間 2019-11-12

標籤開始編寫本身 c# 框架測試欄目 C# 简体版

原文原文鏈接

　　一、前言

　　對於測試，不少公司並不看重，接觸過很多朋友或客戶，打開網站隨便點擊一下，就能夠很容易發現爆黃頁、40四、UI變型（瀏覽器兼容）、流程走不通、錯別字......等各類各樣的錯誤。固然也包括我之前工做過的公司，基本上都將測試交給了客戶或網站來訪者，發現有問題時常常是出了問題之後。程序員

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

　　二、不堪回首的開發往事

　　幾乎每一個開發人員都會堅信本身的此次修改完成經過，沒有Bug，而後一次次被擊毀這種幻想回到現實。這種經歷犯傻的事情我之前也常常發生，而結果可想而知。瀏覽器

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

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

　　11年的時候在作KJava手機端應用開發，有一次要對應用進行一次很小的修改，改完後自我感受應該對其餘地方沒有影響，而後就提交給運營部門作羣發，當時運營部門也沒有測試直接放到網站上，並開足馬力發送。過了十多分鐘查數據發現沒有扣費記錄，而後從新測了軟件才發現原來有個參數改的時候給註釋掉了+_+ ......還好羣發的數據量不算太大，損失很少......服務器

　　......架構

　　還有不少經典的往事或發生在同事身上的囧事，如今都記不清楚了，而出現這些事情的主要緣由是，開發人員沒有作好自測工做，太自覺得是。固然公司對這一塊沒有重視也是很重要的緣由，並無造成一套讓開發人員自律的規範，缺乏測試部門。併發

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

　　仍是說說一個小故事，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關閉，對未修復的Bug從新激活

　　測試師返測完畢後，若是沒發現有問題就會將Bug關閉，而繼續出現Bug，則會從新激活這個Bug......再而後這個程序員就悲哀了......繼續他的Bug修復之路......

　　十二、靈活使用壓力測試工具

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

　　舉幾個例子給你們看看：

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

　　之前曾參與開發過一個電商網，300個併發運行事後，CPU與內存正常，但服務器出口帶寬一會就爆掉了，查明緣由是網站圖片過多過大，須要將圖片與網站服務器分開處理。

　　也曾試過服務器性能一降低得很利害，檢查發現是因爲某些數據表記錄量過大，致使數據庫查詢運算佔用過長時間，致使CPU飈升。

　　之前作過的一個電商網，在壓力測試時1K併發沒有問題，而後對一些關鍵的數據表添加記錄，當記錄增長到必定量時就發現了一些異常，檢查事後發現是因爲使用NOSQL緩存，程序一次性加載的記錄量過大時，加載時間過長致使數據加載超時出現異常。

　　......

　　從上面例子能夠看出，不少問題均可以在上線前經過一些測試工具提早查找出來，而不是上線後出現問題再進行優化處理。有的問題可能能夠經過優化手段解決，而有的則可能須要對某些代碼，甚至須要對框架架構進行修改才能搞定，提前發現問題能夠幫咱們減小不少沒必要要的損失。

　　固然若是有專業的測試師幫你作好這些工做的話，那開發人員就能夠輕鬆不少。

　　1三、測試與版本控制

　　咱們開發的代碼不可避免的須要更新換代，而代碼的迭代過程當中，測試師是一個很是重要的角色。

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

　　在有測試師參與的項目中，這種現象則比較少發生，緣由在於專業的測試會對版本控制得比較嚴格，凡是須要更新到服務器上的程序，都會通過測試師嚴格的測試且沒有問題後，纔會更新到服務器上。而每次更新到服務器端的版本，都會通過一系列的測試，而這些版本的源碼也會建立一個分支備份，作爲一個穩定版本單獨保存，其餘程序員則在主幹繼續進行開發，萬一更新不成功則能夠立刻使用上一個版本進行替換。