以前也經常看一些文章，談到測試多麼多麼的重要，其實對於重要性來看，自己也已經略有了解，只是一直以來對如何採用單元測試，編寫測試樣例之類還沒有太深的感觸，直到手頭的專案再一次面臨結項的時候……
這個版本已經是第三個版本了，前面的兩個版本產品感覺還不是特強烈，可能也是和自己在專案中的角色慢慢轉變有關係，以前自己只是負責自己的一畝三分地，大家加班，自己就加班，有問題就處理，沒有問題就測試版本，對於同事在忙的部分有太多的不了解，所以缺乏整體概念是當時的一大特色，我想，很多開發人員都會 有過這樣的感覺吧~
經歷了三個版本的開發，自己逐漸對專案有了整體概念，也做了一些整體框架方面的大的調整，在熟悉了專案的各個細節後，會經常有很多的「想法」，比如，這個 地方的邏輯過於複雜、前台指令碼過於臃腫、業務流程是否還有優化的餘地等等，當然，在平衡了專案資源之後，有一些想法可以最終變為現實，但有一些想法只能暫時處於待命狀態~
但這不是今天想說的，今天想說說為啥自己突然對單元測試和測試樣例的態度有了巨大的轉變？
事情的經過是這樣的：
開發人員新增新需求 + 處理系統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. 在發布版本的過程中，每個人都會出現一些比較低階的錯誤，例如，筆誤、忘記更新**、忘記打包、和測試人員的摩擦等等，我們必須心懷若谷，尤其是對乙個團隊來講，更需要彼此的理解和尊重，記住沒有人故意犯錯！
說了這麼多，無非是對已有工作的一點想法，希望能對大家有所幫助~
專案「結項期」中如何改善開發VS測試效率的一點想法
以前也經常看一些文章，談到測試多麼多麼的重要，其實對於重要性來看，自己也已經略有了解，只是一直以來對如何採用單元測試，編寫測試樣例之類還沒有太深的感觸，直到手頭的專案再一次面臨結項的時候 這個版本已經是第三個版本了，前面的兩個版本產品感覺還不是特強烈，可能也是和自己在專案中的角色慢慢轉變有關係，以前...
vs2005專案測試 續
vsts裡的unit test可以幫助我們實現我們希望的絕大多數功能.我們從實際的專案開發入手來介紹.假設我們新建了乙個.net專案,嗯,這是乙個有關快取的子專案,名字叫mycache.我們很認真的設計了專案的架鉤,進行了可行性分析,介面和抽象的建立,具體物件的建立,關係建立,最後編碼完成了.專案經...
團隊開發經驗 如何帶領乙個專案團隊並做好專案總結
最近帶領乙個小團隊做完乙個專案，專案雖不算大，可五贓俱全，感覺在這專案中最重要的還是溝通協調。下面是我自己經過這個專案，自己的一點體會，寫在這裡，總結自己的思路，並希望在以後的專案中有更多的提高，到時繼續與大家分享。一 總體把握，統一部署 1 總體把握 接手乙個專案，首先要有乙個總體的認識，抓住專案...