代碼復查的方法

Ⅰ 智能家居系統測試的方法有哪些

1、單元測試
單元測試是對軟體中的基本組成單位進行的測試，其目的是檢驗專軟體屬基本組成單位的正確性。智能家居系統測試有一個設計很好的體系結構就顯得尤為重要。
單元測試的方法只有兩種基本的測試方法：
第一個是：代碼復查
第二個是：編寫測試程序
2、集成測試
集成測試是在軟體系統集成過程中所進行的測試，其主要目的是檢查軟體單位之間的介面是否正確。
集成測試的方法主要有自頂向下和自底向上兩種。
3、系統測試
系統測試是對已經集成好的軟體系統進行徹底的測試，以驗證軟體系統的正確性和性能等滿足其規約所指定的要求，檢查軟體的行為和輸出是否正確並非一項簡單的任務。

Ⅱ 個人軟體過程的缺陷管理

缺陷是指程序中存在的錯誤，例如語法錯誤、標點符號錯誤或者是一個不正確的程序語句，是任何影響程序完整而有效的滿足用戶要求的東西，是可以表示、描述和統計的客觀事物。
有人把缺陷稱為Bug，這是不正確的。當成為Bug時，令人想到的是那些令人討厭的小蟲子，應該把它們拍死或者不予理睬。這會使一些重要的問題被視為瑣碎小事，會養成一種錯誤的態度。缺陷並不像無足輕重的Bug，更像是定時炸彈。大家可能會覺得有些誇大其詞，絕大部分細小的缺陷沒有引起嚴重後果。然而不幸的是，很小一部分看起來無關緊要的缺陷卻能引起嚴重問題。雖然現在缺陷對你來說還不是一個嚴重問題，但很快就會成為一個重要的問題。
設計錯誤的復雜性和所導致的缺陷的影響沒有直接關系，一些微小的編碼錯誤卻可能引起嚴重的系統問題。事實上，絕大多數軟體缺陷都源於程序員的疏忽大意。
為了減小缺陷，就必須進行缺陷管理，研究已經引入的缺陷，確定引起這些缺陷的原因，並學會在將來如何避免重復同樣的錯誤。
缺陷分類。在分析缺陷時，將缺陷進行分類是有幫助的。通過缺陷分類，可以迅速找出哪一類缺陷的問題最大，然後集中精力預防和排除這一類缺陷，這就是缺陷管理的關鍵。把精力集中到最容易引起問題的幾類缺陷上，一旦這幾類缺陷得到控制，在進一步找到新的容易引起問題的幾類缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。
不要急於把10種類型的每一類細分出若乾子類，直到你已經搜集到大量程序的缺陷數據。那時，才能夠看出哪裡需要更詳細以及補充什麼樣的信息才是最有用的。
統計缺陷個數。採用缺陷記錄日誌，記錄那些當你完成初始設計或編碼後仍然留在產品中的缺陷。人們很容易對缺陷辯解，但是要管理好缺陷，就必須收集有關缺陷的准確數據。如果原諒缺陷，那隻會自欺欺人。如果你這樣做的話，就別指望有所提高。
為什麼要盡早發現缺陷。不要期望一個簡單拼湊出來的滿是缺陷的程序，經過修改可以成為一個合格的產品。一旦生產出一個有缺陷的程序，它將永遠是有缺陷的。雖然你可以修復所有已知的問題，並且讓它通過所有的測試，但它還是一個有許多不定的有缺陷的程序。如果工程師能寬容有缺陷的工作，他將生產出低質量的產品。「我們忙，以後在修補吧」，這樣的態度不可能出產出優質產品。
發現和修復缺陷的費用。在典型項目中，產品被分成很多小的模塊，由不通的工程師負責開發。在模塊設計、實現、編譯後，工程師作初始的單元測試；單元測試後，多個模塊組成一些大組件進行集成測試；經過各種級別的組件測試後，這些組件集成為產品進行產品設計；最後，將產品集成到系統中進行系統測試。隨著系統的規模和復雜程度不同，單元測試、集成測試、組件測試、產品測試、系統測試的類型、持續時間、復雜程度有所不同，但幾乎所有規模的軟體產品，都需要這個過程。
研究證明，開發過程每前進一步，發現和修復缺陷的平均代價要增長10倍。盡管缺陷的修復時間變化很大，但平均時間總是遵循這樣的規律，而與缺陷的類型無關。
發現和修復缺陷的方法。盡管沒有辦法不引入缺陷，但是在開發過程中盡早發現和修復缺陷還是可能的。有多種發現程序中的缺陷的方法，基本上都包括以下步驟：表示缺陷徵兆；從徵兆中推斷出缺陷的位置；確定程序中的錯誤；決定如何修復缺陷；修復缺陷；驗證這個修復是否已經解決了這個問題。
有多種工具和輔助手段來幫助完成這些步驟，工程師最常用的工具是編譯器，它能夠表示出大部分語法缺陷。但是編譯器最基本的任務是生成目標代碼，並且可能會在源程序有缺陷的情況下生成代碼。因此，不能檢查出所有的拼寫、標點符號或其他不符合語法的缺陷。一般編譯器僅提供了缺陷的徵兆，你必須自己對問題定位，並確定是什麼問題，通常很快能夠做到這一點，但偶爾也需要較長的時間
另外一種常用方法就是上面講述的測試。測試的質量是由測試用例覆蓋所有程序功能的程度決定的。測試可以用來驗證程序幾乎所有的功能，但有自己的缺點：同編譯器一樣只能滿足缺陷派出的第一個步驟，你仍必須從缺陷徵兆找出問題的根源，然後才能修復；隨著項目規模的擴大，全面的測試會花費大量的時間，要進行完全測試幾乎不可能的。
最有效的發現和修復缺陷的方法是個人復查源程序清單。這種方法是負很難徹底清除程序中的缺陷，但事實證明，這是最快而且最有效的方法。
代碼復查就是研究源代碼，並從中發現錯誤。代碼復查更有效的原因是：在復查時看到的是問題本身而不是徵兆。從頭到尾復查代碼時，考慮的是程序應該做什麼。因此，當看到某些地方不正確時，就可以看到可能的問題是什麼，並立即去驗證代碼。復查的缺點是：非常耗時，而且很難恰當的進行；復查時一種技能，當然可以通過學習和實踐來提高。
代碼復查的第一步是了解自己引入的缺陷的種類，這是收集缺陷數據的主要原因。因為在下一個程序中引入的缺陷種類一般會與前面的基本類似，只要採用同樣的軟體開發方法，情況會一直如此。另一方面來說，當你有了技能和經驗或改變了過程，缺陷的類型和數目會隨之變化。但是到了一定程度後，改進就變得非常困難了。這是，就必須研究缺陷，這可以幫助你找到更好的發現和修復缺陷的方法。
如何進行代碼復查。代碼復查的目標是在軟體過程中盡可能早和盡可能多的發現缺陷，缺陷發現時間越少越好。採用表4.3描述的一個有序的檢查方法，在編譯之前進行代碼復查，是完成目標最好的方法。
編譯之前進行復查。有幾個原因說明應在編譯之前進行代碼復查：不論編譯前或編譯後，進行完整的代碼復查的時間大約相同；不論編譯前或編譯後，對檢查語法有效性的效果是一樣的；先做復查將節省大量編譯時間，若不做代碼復查，一般要花12%～15%的開發時間進行編譯，一旦使用代碼復查後，編譯時間可以縮短至3%或更少；編譯程序後，代碼一般復查很難徹底的進行； 經驗證明，在編譯階段有大量的缺陷時，一般在測試階段也有許多缺陷。
建立個人代碼復查檢查表。如果想發現和改正程序中的每一個缺陷，就必須遵照一個精確的規程。檢查表可以確保遵循這個規程，它包括一系列程式的步驟。按照檢查表去作時，就知道如何進行代碼復查。
如果能夠正確使用檢查表，還能知道每個步驟發現了多少缺陷。這樣就能測量出復查過程的效率，並進一步改進檢查表。檢查表包括了個人的經驗。通過不斷的使用和改進個人檢查表，就可以幫助你用較少的時間發現這些缺陷。表4.4是一個C++程序代碼復查表的範例。
定期更新檢查表。隨著時間的推移，檢查表自然的要變大。但是，檢查表的主要作用是幫助你把注意力集中在關鍵的方面。太大以後，你將失去重點。所以要定期復查缺陷數據，刪除那些不能找到問題的表項。
從個人檢查表的方法可以認識到，每個工程師都有各自的特點，某個工程師的實踐經驗對別人不一定適用。因而要設計出適合自己的檢查表，並定期的對它進行檢查以保證檢查表更有效。只要你在代碼復查中還遺漏缺陷，就要不斷尋找改進檢查表的方法。
進展是很緩慢的。最初，你發現缺陷的能力隨著每次復查都有所提高。此後，提高將變得很困難。要堅持收集和分析缺陷數據，並堅持思考如何才能預防缺陷的產生或怎樣更好的找到缺陷。只要堅持不斷的做下去，就能在代碼復查中不斷進步，不斷提高自己編寫程序的質量。
編碼標准。編碼標準是被廣泛接受的、能夠作為工作樣板的編碼實踐集。良好的編碼標准將有效地幫助您避免開發有潛在危險的代碼，有助於預防缺陷。例如，可以在編碼標准中列出那些應該避免使用的方法，規定號循環入口或在說明是初始化變數，避免不良的變數命名等。編碼標准還能有效地統一和規范整體開發活動。當其他開發人員加入到項目中來時，他們能夠很好地適應這一切。代碼也將變得更規范更易維護。
其他種類的代碼復查。在軟體組織中，一種常用的方法是同行評審，就是幾個工程師彼此復查程序。組織良好的同行評審一般會發現程序中50%～70%的缺陷。互查雖然需要很多時間，但是可以有效發現缺陷，因為工程師往往難於發現自己的設計錯誤。他們創作這個設計，直到程序應該完整什麼，即使概念有瑕疵、作了錯誤的設計或實現假定，他們往往很難發現。檢查這可以幫助他們克服這些問題。對一個大的項目，最佳檢查策略是，先做個人代碼復查再進行編譯，然後在任何測試前進時行同行檢查。
細心工作是有回報的。當工程師覺得對自己開發的程序附有質量責任時，他就不會依賴於編譯器或其他工具來發現缺陷。全面的代碼復查要花費時間，但是他們節省出來的時間比花費的時間多得多，並能夠生產出更好的產品。
引入缺陷是人類的正常現象，所有的工程師都會引入缺陷。因此所有的工程師都應該了解自己引入缺陷的類型和數據。
在開發過程中，總是可再進行一輪測試或代碼復查，決定是否這樣做的唯一方法就是分析缺陷數據。通過分析歷史數據，可以估計出程序中缺陷的個數。通過把當前項目的數據??的質量情況。這樣就能決定是否需要增加一些缺陷排除步驟。
缺陷率的預測。當開發一個新的程序時，可能會覺得很難估計你將引入多少缺陷，理由是缺陷的個數因程序的不同而不同。缺陷個數不穩定是有以下幾個原因造成的。首先使經驗問題，個人的技能是在不斷提高的。開始編程序時，要面臨著很多以前沒有碰到過的問題。往往不能確定有些過程和函數是如何執行的，可能是語言的結構不清楚或者可能會遇到新的編譯器或編程環境的問題。這些問題都會引起開發時間和缺陷路的波動。有了經驗後，你將逐漸克服這些問題，犯的錯誤就減少了。這既減少缺陷的總數又減少缺陷數目的波動。缺陷的減少起初是由於經驗的增加和對語言熟練程度的提高。經過這最初的提高後，就需要收集和分析缺陷數據來進一步改進了。
缺陷路波動的第二個原因是個體過程不穩定。當開始學習寫程序時你也同時開始學習使用新的過程和方法。你的過程將隨著實際的經驗不斷的發展，這就會引起完成不同程序任務的時間和引入缺陷的數據的波動。
最後，缺陷本身也是這種變化的原因，引入的缺陷越多，修復這些缺陷所花時間就越長。修復缺陷所花的時間越長，引入新的缺陷的幾率也就會增加。因此缺陷的修改時間變動幅度很大。所以，很難對一個引入很多缺陷的過程進行預測。
隨著開發過程的改進，過程會逐步穩定下來。這種穩定將提高缺陷預測的准確性。試驗證明，如果在代碼復查方面花了足夠的時間，你的過程會迅速穩定下來。一旦你的過程相當穩定，缺陷也將容易預測。
根據對最近的程序跟蹤每千行引入和排除的缺陷數，就可估計出在將來的程序中可能引入和排除的缺陷數。