以前也經常看一些文章，談到測試多么多么的重要，其實對于重要性來看，自己也已經略有了解，只是一直以來對如何采用單元測試，編寫測試樣例之類還沒有太深的感觸，直到手頭的項目再一次面臨結項的時候……
這個版本已經是第三個版本了，前面的兩個版本產品感覺還不是特強烈，可能也是和自己在項目中的角色慢慢轉變有關系，以前自己只是負責自己的一畝三分地，大家加班，自己加班，有問題處理，沒有問題測試版本，對于同事在忙的部分有太多的不了解，所以缺乏整體概念是當時的一大特色，我想，很多開發人員都會 有過這樣的感覺吧~
經歷了三個版本的開發，自己逐漸對項目有了整體概念，也做了一些整體框架方面的大的調整，在熟悉了項目的各個細節后，會經常有很多的“想法”，比如，這個 地方的邏輯過于復雜、前臺腳本過于臃腫、業務流程是否還有優化的余地等等，當然，在平衡了項目資源之后，有一些想法可以終變為現實，但有一些想法只能暫時處于待命狀態~
但這不是想說的，想說說為啥自己突然對單元測試和測試樣例的態度有了巨大的轉變？
事情的經過是這樣的：
開發人員添加新需求 + 處理系統bug =》提交測試版本 =》 測試人員進行系統測試 =》 發現系統bug，并提交開發進行處理 =》 重現bug，并處理bug（有可能會引發其他問題；測試不徹底……） =》 測試人員反測，發現有問題繼續返回，抑或沒有發現隱含的bug =》開發人員……
大概是這么一個生死輪回！眼看結項日期越來越近，但是上述輪回依舊，不同的，可能是問題數量和嚴重級別上的差異，但每發現一個問題，需要重新出一個版本，需要測試全面的測試，然后我們大家都在盼望奇跡的發生……可是貌似噩夢一直延續，這是我們的現狀！
你或許會說，產品總不會是完美的，總會多多少少有一些瑕疵的吧~這個道理我也知道，但是，上面的輪回顯然會出現一個很大的漏洞，那是在缺少詳細的測試樣例指導和完整的單元測試情況下，再加上人手的限制，那么帶來的不會是一段愉快的回憶！
總之，我們不能破罐子破摔是一定的，因為當我們進入公司參加工作以后，這個想法不應該存在了！好吧，那我們看看在現在的這個爛攤子上，我們能怎么稍微掙扎一下：
（1） 合理安排好結項期間的開發任務：
i. 保證測試人員發現bug后，開發人員能夠第一時間處理。
ii. 如還有新需求研發，一定要能夠合理評估，不能盲目進行添加，尤其對開發難度和開發時間有足夠的把握，否則完全可以放到下面的版本進行完善。
iii. 開發人員在修改了一個bug后，至少要通過兩遍的測試，一個是自己開發環境的，一個是測試的現場環境，而且在測試完畢，將代碼更新到服務器，并填寫適當的描述文字。
iv. 一定要控制好版本的發布間隔，過長或過短都是不太合適的，一般情況下，可以控制在1-2天，當然，如果出現嚴重的影響正常流程的問題，還是需要馬上進行版本更新的，這樣也是為了保證測試人員的測試質量和心情。
（2） 合理安排好測試任務：
i. 每新出一個新的版本，先不要發布，首先由開發人員該版本修正的問題進行反測，并保證基本業務流程的正確性，直到沒有異常再發布新版本，提由測試人員進行測試，這樣可以明顯減輕測試人員的壓力.
ii. 對于測試人員，建議能夠抽時間對系統的測試工作進行一些樣例總結，開始可以只對主要流程進行總結，而后根據時間情況再補充后面的內容，因為一個系統中可能存在多個功能模塊，完全有必要按照模塊來劃分人力進行重點的測試，從而避免這個版本發現這個功能模塊有很多問題，但是其他部分沒有仔細地測試，而下一個版 本，這個模塊雖然好一些了，但是發現另外的模塊又出現N多bug，這種情況其實完全可以一次發現一次解決的，如果拉長戰線的話，會給人一種bug無窮無 盡，末日來臨，增加無謂的壓力！這也是不能把版本周期設定過短的另外一個原因，如果時間太倉促的話，測試人員也不是三頭六臂，很定會有很多的遺漏，而且頻繁地發布版本更會降低測試人員測試的激情，降低測試效率，這些都是很現實的問題！
iii. 不斷的往復測試加上結項日期的壓力，都使得這個階段的氣氛和壓力要高于往常，所以一定要保證開發人員和測試人員精神狀況的飽滿，此時如果團隊中有一個到兩個人能起到活躍和放松氣氛的作用，那真是不幸中的萬幸，因為保證輕松的心情才能更有效地發現和處理問題。對于測試人員來說，不能因為想著馬上結項而放松測 試的要求，開發人員也不能一味想著好沒有bug，萬事大吉，下班回家的心態，一定要知道，越早發現問題，代價越小，如果到了客戶上線后再發現，那后果都 是非常嚴重的，而代價將不是數倍的增加！
（3） 其他一些實用的小技巧：
i. 有必要為“版本發布期”做一個主體的計劃，即需要定幾個關鍵點，并分別設定版本目標，但沒有必要過于頻繁，一般保證在3個左右可能效果會好一些，如果沒有 這些關鍵時間點的話，人的惰性會大大降低我們的效率，對項目的順利結項也是一個很大的威脅。
ii. 將修改后的代碼更新后，負責更新版本包的人員，有必要在獲取新代碼的時候對修改的代碼進行一下審查，因為不同開發人員的視角往往不同，因為和修改bug 的人員相比，審查人員沒有將精力聚焦在問題本身，往往可以跳出問題的怪圈，可能會發現一些修改遺漏和潛在隱患，或者能提出更好的方法也不一定。
iii. 從“版本結項期”伊始，我們需要創建一個版本改善意見簿，其目的很簡單，是為了記錄在這個“測試輪回”中，開發人員的一些“想法”，可以是有關某一部 分功能模塊的重構意見，也可以是對某些相同代碼的重構，或者是對一些更炫的功能的實現等等，總之，因為在這個階段，我們和系統會有很親密的接觸，所以會更加容易發現系統的很多問題，同時激發我們的思考。錯過這么好的機會，真的是非常可惜的。
iv. 在為測試提供修改后的版本的dll的時候，好把dll的小版本進行修改，而且測試人員也不要進行直接覆蓋，好能夠把原有文件進行備份，方便還原問題環境。
v. 每次測試開始之前，都需要首先將此次版本中修改的問題進行反測，必須做到一個不剩，然后再按照既定方案進行全面測試。
vi. 在發布版本的過程中，每個人都會出現一些比較低級的錯誤，例如，筆誤、忘記更新代碼、忘記打包、和測試人員的摩擦等等，我們必須心懷若谷，尤其是對一個團隊來講，更需要彼此的理解和尊重，記住沒有人故意犯錯！
