程序為什麼要單元測試

A. 單元測試到底是什麼應該怎麼做

單元測試一般是有開發人員或測試人員來做。誰來做並沒有一個絕對的標准，要根據公司的實際情況來決定。

單元測試的實現方式包括：人工靜態檢查、動態執行跟蹤。

人工靜態檢查：就是通常所說的「代碼走讀」，主要是保證代碼邏輯的正確性。

動態執行跟蹤：就是把程序代碼運行起來，檢查實際的運行結果和預期結果是否一致。

開發人員做單元測試：

優點：開發人員對代碼最熟悉，而且開發人員編程技能相對比較強，所以開發人員自己寫單元測試效率上和覆蓋率上都比較高。

缺點：開發人員平時寫業務代碼就要花費很多時間，有時候確實沒有時間寫單元測試；而且大部分開發人員沒有太好的測試思想，單元測試可能只是寫個最簡單的用例就完了；自己寫的代碼自己測，往往都是不靠譜。

測試人員做單元測試：

優點：測試人員有比較系統的測試思想，可以更好地保證用例的覆蓋。而且通過寫單測測試能更好地了解具體代碼結構、流程，對於後續的業務測試也非常有利。

缺點：測試人員的編程技能相對比較弱，如果不同編程是無法開展單元測試的。並且測試人員對代碼沒有開發人員熟悉，效率會比較低。

B. 什麼是單元測試意義是什麼

單元測試是什麼
單元測試是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確，通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行為
單元測試的好處
1，單元測試不蘆悉汪但會使你的工作完成得更輕松。而且會令你的設計會變得更好，甚至大大減少你花在調試上面的時間 2，提高代碼質量 3，減少bug，快陸亮速定位bug 4，放心地修改、重構
寫單元測試要注意什麼
1，不能只測試一條正確執行路徑，要考慮到所有可能的情況
2，要確保所有測試都能夠通過，避免間接損害
3，如果一個函數復雜到無法單測，那就說明模塊的抽象有問題
4，配置不是單元測試的難點，難點是mock（後文講），做單元測試需要偽造被測函數用到的大部分函數
為什麼寫單元測試
編寫單元測試太花時間了？考慮下面問題：
1，對於所編寫的代碼，你在調試上面畫了多少時間？
2，對於以前你自認為正確的代碼，而實際上這些代碼卻存在重大的bug，你畫了多少時間在重新確認這些代碼上面？
3，對於一個別人報告的bug，你花了多少時間才找出導致這個bug的源碼位置？
對於那些沒有使用單元測試的程序員陪仔而言，上面這些問題所耗費的時間的遞增速度是很快的，而且隨著項目深入，遞增速度會變得更快；而另一方面，適當的單元測試卻可以很大程度地減少這些時間，從而為你騰出足夠的時間來編寫所有的單元測試——甚至可能還有剩餘的空閑時間。

C. 為什麼需要做單元黑盒測試

有了戚拿亮單元高寬測試，我們可以自信的交付自己的代碼，而沒有任何的後顧之憂。敏此
單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。

D. 軟體開發裡面單元測試是用來做什麼的

單元測試是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件(或者場景)下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然後確認該值出現在list 的尾部。或者，你可能會從字元串中刪除匹配某種模式的字元，然後確認字元串確實不再包含這些字兄孫符了。

執行單元測試，是為了證明某段代碼的行為確實和開發者所期望梁塌的一致。

為什麼需要單元測試?

當編寫項目的時刻，如果我們假設底層的代碼是正確無誤的，那麼先是高層代碼中使用了底層代碼;然後這些高層代碼又被更高層的代碼所使用，如此往復。當基本的底層代碼不再可靠時，那麼必需的改動就無法只局限在底層。雖然你可以修正底層的問題，但是這些對底層代碼的修改必然會影響到高層代碼。於是，一個對底層代碼的修正，可能會導致對幾乎所有代碼橡塵圓的一連串改動，從而使修改越來越多，也越來越復雜。從而使整個項目也以失敗告終。

單元測試針對程序模塊，進行正確性檢驗的測試。其目的在於發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。

E. 單元測試的意義

單元測試由一組獨立的測試構成，每個測試針對軟體中的一個單獨的程序單元。如果對單元測試的內容不清楚的同學，昌平鎮電腦培訓建議可以參考這篇文章，詳細講解單元測試的內容。

對於單元測試，人們往往存在很多的誤解：

1)浪費的時間太多

一旦編碼完成，缺乏軟體工程實踐經驗的開發人員就會迫不及待地進行軟體集成工作，這樣就能看到實際系統開始啟動工作，在這種開發步驟中，真正意義上的進步被表面上的進步所取代。系統能進行正常工作的可能性很小，更多的情況是充滿了各式各樣的Bug。這些Bug包含在獨立的單元里，其本身也許是瑣碎、微不足道的，但在軟體集成為一個系統時會增加額外的工期和費用。

其實進行完整的單元測試和編寫代碼所花費的精力大致上是相同的，一旦完成了單元測試，在確保手頭擁有穩定可靠部件的情況下，再進行高效的軟體集成才是真正意義上的進步。

程序的可靠性對軟體產品的質量有很大的影響，在大型軟體公司，每寫一行程序，都可能要測試很多遍。由此可見大型軟體公司對測試的重視程度。

2)軟體開發人員不應參與單元測試

單元測試常常和編碼同步進行，每完成一個模塊就應進行單元測試。在對每個模塊進行單元測試時，不能忽略和其他模塊的關系，為模擬這一關系，需要輔助模塊，因此若單獨的測試人員喊念跡進行單元測試，往往工作量大，周期長，耗費巨大，其結果事倍功半。軟體的開發者總是應當負責高尺程序的單個單元的測試，保證每個單元能夠完成設計的功能，其實在很多情況下，開發者也應進行集成測試。

3)我是很棒的程序員，不需要進行單元測試

如果我們真正擅長編程並且有絕招，就應當不會有錯誤，但這只是一個神話。編碼不是可以一次性通過的，必須經過各種各樣的測試，單元測試只是其中一種。缺乏測試的程序代碼可能包含許多Bug，程序員在沒有測試保護的情況下修改Bug，會引發更多的Bug，忙於除蟲，於是更沒有時間測試。如此循環往往會導致項目的崩潰。為避免產生惡性循環，代碼必須有一張安全網來保護，隨鄭並時進行的單元測試就是這張安全網。

4)不管怎樣，集成測試將會抓住所有的Bug

集成測試的目標是把通過單元測試的模塊拿來，構造一個在設計中所描述的程序結構，通過測試發現和介面有關的問題。我們在測試工作開展的過程中，發現並提交進行合格性測試的軟體，在測試過程中有很多Bug，有些嚴重問題，甚至導致死機，以至於不能再測試其他功能，進行錯誤修改，回歸測試時又發現其他新的問題，使得測試工作很難開展下去。

F. 為什麼要做測試

1、測試是做什麼的?
如果是專業的測試人員的話，那軟體測試的工作就相當復雜了，首先制定測試計劃是勢在必行的，包括測試的起始結束時間，在什麼時間要有什麼進度，之後就是進行各個測試環節，單元測試——集成測試——系統測試——驗收測試。這里邊前兩步是用到白盒測試，後兩步需要的是黑盒測試。
如果是找測試方面的工作的話，那一開始我相信問得不會很深，但是基礎肯定是要知道的，就是什麼是黑白盒測試，建議測試文檔包含的必須部分等等吧，都是很基礎的。
2、軟體測試類型都有哪些?測試類型的區別與聯系?
測試類型有：功能測試，性能測試，界面測試。
功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
界面測試，界面是軟體與用戶交互的最直接的層，界面的好壞決定用戶對軟體的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由於界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。
區別在於，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題。性能測試主要關注於產品整體的多用戶並發下的穩定性和健壯性。界面測試更關注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規范(快捷鍵之類的)，是否美觀(能否吸引用戶的注意力)，是否安全(盡量在前台避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告)?做某個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然後再考慮該功能點的性能測試。
3、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系?
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1)是否有不正確或遺漏的功能?
2)在介面上，輸入是否能正確的接受?能否輸出正確的結果?
3)是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤?
4)性能上是否能夠滿足要求?
5)是否有初始化或終止性錯誤?
軟體的白盒測試是對軟體的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：
1)對程序模塊的所有獨立的執行路徑至少測試一遍。
2)對所有的邏輯判定，取「真」與取「假」的兩種情況都能至少測一遍。
3)在循環的邊界和運行的界限內執行循環體。
4)測試內部數據結構的有效性，等等。
單元測試(模塊測試)是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件(或者場景)下某個特定函數的行為。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。
集成測試(也叫組裝測試，聯合測試)是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的介面。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。
系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。(常見的聯調測試)
系統測試的目的是對最終軟體系統進行全面的測試，確保最終軟體系統滿足產品需求並且遵循系統設計。
驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確保軟體准備就緒，並且可以讓最終用戶將其用於執行軟體的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能和性能如同用戶所合理期待的那樣。
4、做好測試用例設計工作的關鍵是什麼?
白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果;
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題。
5、測試計劃工作的目的是什麼?測試計劃工作的內容都包括什麼?其中哪些是最重要的?
軟體測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法(最好是能先評審)。
6、做好測試計劃工作的關鍵是什麼?
1)明確測試的目標，增強測試計劃的實用性
編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試項目，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、准確。
2)堅持「5W」規則，明確內容與過程
「5W」規則指的是「What(做什麼)」、「Why(為什麼做)」、「When(何時做)」、「Where(在哪裡)」、「How(如何做)」。利用「5W」規則創建軟體測試計劃，可以幫助測試團隊理解測試的目的(Why)，明確測試的范圍和內容(What)，確定測試的開始和結束日期(When)，指出測試的方法和工具(How)，給出測試文檔和軟體的存放位置(Where)。
3)採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
4)分別創建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。