如何驗證程式是否完成，測試以及修正Bug?

一.背景介紹

在日常中，我們碼代碼都是按照需求來的，為了驗證我們的工作成果是否符合項目的需求，那麼驗證程式是否完成、測試以及修複bug就成了我們工作中非常重要的流程。

二.知識剖析

什麼樣的程式是完成的程式

• 從需求的角度看：滿足使用者的全部需求
• 從程式的角度看：代碼不存在明顯bug，結構明晰，邏輯通順，有一定的優化
• 從UI圖的角度看：較為完美的還原了UI圖的設計
• 從後期版本維護疊代的角度看：注釋完備，穩定性好，不加班的代碼就是好代碼

軟體測試的方法

測試：測試是使用人工操作或者軟體自動運作的方式來檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差别的過程。

• 按照測試範圍，可以分為子產品測試和整體聯調
• 按照測試條件，可以分為正常操作情況測試和異常情況測試
• 按照測試的輸入範圍，可以分為全覆寫測試和抽樣測試
• 按照測試方式

  子產品測試：針對設計中的一個一個子產品來進行測試的，目的是保證每個子產品作為一個單元能正确運作，是以子產品測試通常又被稱為單元測試。在這個測試步驟中所發現的往往是編碼和詳細設計的錯誤。
  
  整體聯調：測試子產品間接口的正确性、各子產品間的資料流和控制流是否按照設計實作其功能、以及內建後整體功能的正确性。
  
  正常操作情況測試：根據正确的操作流程對單獨的子產品或整體進行測試，确定被測對象可以良好運作
  
  異常情況測試：異常情況，可能會包括資料庫異常，系統異常，使用者異常操作等情況
             

一些測試的概念

成熟性：軟體産品要避免由軟體中錯誤而導緻失效的能力

容錯性：在軟體失效或者違反規定的接口的情況下，軟體産品維持規定的性能級别的能力

易恢複性：在發生故障的情況下，軟體重建規定的性能級别并恢複受直接影響的資料的能力

可靠性依從性：軟體産品依附于同可靠性相關的标準、約定或規定的能力

全覆寫測試：對于被測對象全面，整體，多元度的測試，受限于時間和人力成本，除非被測對象級别很高，不然不會采用這種測試方式

抽樣測試：針對功能及子產品随機抽取被測對象

三.常見問題

如何debug？

四.解決方案

知乎上的回答：

1. 确認Bug是否在本地可以重制。
2. 确認Bug在哪一段代碼中。
3. 去除掉所有無關代碼，隻去調試和Bug相關的代碼。
4. 和之前正常運作的版本對比，嘗試恢複到之前可以正常運作的代碼。
5. 重新寫一個小Demo，确認是否可以正常運作，可以的話，移動代碼到原有的代碼中。
6. 如果本地無法重制，打日志，觀察線上行為。
7. 重新開機服務，重新開機IDE，重新開機筆記本，重新開機伺服器。
8. 跟産品經理說這個Bug解決不了，花費的代價很大，不值得。

解決問題的流程：了解問題→定位問題→分析問題→解決問題→驗證問題

解決問題的方法(排名分先後)

1. 借助搜尋引擎：遇到有明顯的異常資訊，且自己并不熟悉為什麼異常時，最高效的解決方法是借助搜尋引擎，這裡的搜尋引擎一定是谷歌，不是百度；借助搜尋引擎能解決工作中的大部分bug，你要相信，全世界這麼多開發人員，你遇到過的大多數問題其他人也遇到過；
2. 列印調試法：這是最笨但最有效的辦法，人會說謊、斷點調試可能會說謊，但日志一定不會說謊；
3. 二分排除法：當你遇到随機問題、幫助他人解bug或者遇到自己不熟悉的代碼時，通過屏蔽一部分代碼，運作觀察問題仍然存在，如果存在則進一步分析屏蔽一部分代碼，直到定位到有問題的具體位置為止，這種方法能解決工作中的很大一部分疑難雜症；
4. 小黃鴨調試法：當你向某個對象陳述你的思路時，往往會有意想不到的結果，哪怕對方并不是一個生物；
5. 斷點調試法：受限于效率不高以及在多線程環境下斷點調試并不靈，有必要時才考慮用這種方法；通常可以使用列印調試法來代替；
6. 線上求助：包括論壇提問、RTX和微信群提問等；不到萬不得已不要用這種辦法，在有限的圈子裡面，你遇到的一個具體技術問題很有可能其他人并沒有遇到過，多數時候問了也是白問，但有時候也可能是一種有效的方法。

五.編碼實戰

六.拓展思考

什麼是小黃鴨調試法?

小黃鴨調試法，又稱橡皮鴨調試法、黃鴨除蟲法（Rubber Duck Debugging）是可在軟體工程中使用的一種調試代碼的方法。方法就是在程式的調試、除錯或測試過程中，操作人耐心地向小黃鴨解釋每一行程式的作用，以此來激發靈感與發現沖突。

此概念是參照于一個故事。故事中程式大師随身攜帶一隻小黃鴨，在調試代碼的時候會在桌上放上這隻小黃鴨，然後詳細地向鴨子解釋每行代碼。許多程式員都有向别人提問及解釋程式設計問題的經曆，而目标甚至可能是完全不懂程式設計的人。而就在解釋的過程中，程式員可能就發覺了問題的解決方案。一邊闡述代碼的意圖，一邊觀察它實際上的意圖并做調試，兩者間的任何不協調都會變得更明顯，使人更容易發現錯誤所在。如果沒有玩具小鴨，操作人也可以向其他任何東西傾訴，比如桌上的盆栽、鍵盤/滑鼠等。

七.參考資料

軟體開發流程

如何提高測試覆寫率

測試分析中對異常情況考慮

軟體異常測試

斷點調試

老程式員解bug有那些通用套路？

八.更多讨論

bug的優先級有哪幾種？

• critical(危險的)：是說項目中某一塊功能因為這個bug而導緻測試無法進行下去，此critical級别，該等級問題出現在不影響其他功能測試的情況下可以繼續該版本試block是說項目中有閃退情況，崩潰情況。此為block級别，出現這種級别的問題此本停止測試
• major(重要的)：是說一些功能沒有實作，但是不影響使用，功能菜單缺失，但不會影響系統穩定。此為major，這種問題應該合理安排時間進行修改
• normal(普通的)：是說界面等UI問題顯示錯誤，比如字型大小，顔色，間距等問題。此類問題在測試初期較多，優先程度較低；在測試後期出現較少，應及時處理）
• minor(次要的)：是說界面、性能缺陷，建議類問題，不影響操作功能的執行，可以優化性能的方案等。

日志和斷點的優劣？

對于少量資料的檢測，斷點操作比較麻煩，日志很直接。但是對于比較複雜的代碼，打斷點能更好的理清邏輯和檢查資料。

如何避免寫出bug？

改動代碼時要考慮到對其他子產品的影響；思考問題要全面，考慮到可能發生的各種情況；從其他地方找到的代碼要弄清楚原理，了解這個知識點，再用到自己的項目中。