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