單元測試中的條件編譯

⑴ 軟體測試中的單元測試，如果測試的單元為類，請問怎麼對一個類進行測試

單元測試應該是重點對方法和函數進行測試，寫好樁和驅動，通過調用和被調用，驗證方法在處理不同參數時的結果。
如果單元是一個類，主要就是看類設計的合理性，是否已經囊括需要的對象的必要屬性，屬性的類型設計是否正確，類的方法是否能滿足對類的操作，是否和其他類有沖突或重復的設計等。

⑵ 集成測試單元測試.系統測試,的聯系和區別

一、區別

1、方式不同

單元測試一般由開發小組採用白盒方式來測試。

集成測試一般由開發小組採用白盒加黑盒的方式來測試。

系統測試一般由獨立測試小組採用黑盒方式來測試。

2、粒度不同

單元測試的粒度最小。

系統測試的粒度最大。

集成測試界於單元測試和系統測試之間，起到「橋梁作用」。

3、內容不同

單元測試主要測試單元是否符合「設計」。

集成測試既驗證「設計」，又驗證「需求」。

系統測試主要測試系統是否符合「需求規格說明書」。

二、聯系

單元測試是開發者編寫的一小段代碼，集成測試是單元測試的邏輯擴展，系統測試是將經過集成測試的軟體。

⑶ c語言中，什麼是條件編譯

條件編譯屬於三種宏定義中的一種，條件指示符的最主要目的是防止頭文件的重復包含和編譯，例如:一個c文件包含同一個h文件多次，如果不加#ifndef宏定義，會出現變數重復定義的錯誤

條件編譯常用的有四個預處理命令：#if、#else、#elif、#endif。
#if指令的形式為：
#if 常量表達式
代碼塊
#endif
#if後面的常量表達式為值，則編譯它與#endif之間的代碼，否則跳過這些代碼。指令#endif標識一個#if塊的結束。

#else被使用來標志#if的末尾和#else塊的開始。這是必須的，因為任何#if僅有一個#endif與之關聯。

#elif意指"else if"，它形成一個if else if嵌套語句用於多種編譯選擇。#elif後面跟一個常量表達式，如果表達式是真，則編譯其後的代碼塊，不對其他#elif表達式進行檢測，否則順序測試下一塊。常見的形式如下：
形式1:
#ifdef 標識符
/*程序段 1*/
#else
/*程序段 2*/
#endif
它的作用是當標識符已經由#define定義過了,則編譯程序段1,否則編譯程序段2，也可以使用簡單形式
#ifdef 標識符
/*程序段1*/
#endif

形式2:
#ifndef 標識符
#define 標識符
/*程序段 1*/
#else
/*程序段 2*/
#endif
它的作用是當標識符沒有由#define定義過,則編譯程序段1,否則編譯程序段2 ，也可以使用簡單形式
#ifndef 標識符
#define 標識符
/*程序段 1*/
# endif
形式3:
#if 表達式
/*程序段 1*/
#else
*程序段 2*/
# endif
它的作用是 當「表達式」值為真時編譯程序段1。否則則編譯程序段2,也可以使用簡單形式
# if 表達式
/*程序段 1*/
# endif
形式4:
#if 表達式1
/*程序段 1*/
#elif 表達式2
/*程序段 2*/
............
#elif 表達式n
/*程序段n */
#endif
它的作用是當「表達式1」值為1時編譯程序段1，表達式2的值為真是編譯程序段2,否則依次順序判斷到表達式n。

最後，條件編譯的條件是一個常量表達式，支持邏輯與&&和或||運算。以上四種形式的條件編譯預處理結構都可以嵌套使用，
標識符: 在理論上來說可以是自由命名的，但每個頭文件的這個標識符都應該是唯一的。標識的命名規則一般是頭文件名全大寫，前後加下劃線，並把文件名中的「.」也變成下劃線，如：stdio.h。
#ifndef _STDIO_H_
#define _STDIO_H_
/*程序段 */
#endif

⑷ 關於c++中的assert語句

C里用法:
使用斷言可以創建更穩定，品質更好且不易於出錯的代碼。當需要在一個值為FALSE時中斷當前操作的話，可以使用斷言。單元測試必須使用斷言（Junit/JunitX）。
除了類型檢查和單元測試外，斷言還提供了一種確定各種特性是否在程序中得到維護的極好的方法。
使用斷言使我們向按契約式設計更近了一步。
斷言特性:
前置條件斷言：代碼執行之前必須具備的特性
後置條件斷言：代碼執行之後必須具備的特性
前後不變斷言：代碼執行前後不能變化的特性
使用方式:
斷言可以有兩種形式
1.assert Expression1
2.assert Expression1:Expression2
其中Expression1應該總是一個布爾值，Expression2是斷言失敗時輸出的失敗消息的字元串。如果Expression1為假，則拋出一個 AssertionError，這是一個錯誤，而不是一個異常，也就是說是一個不可控制異常（unchecked Exception),AssertionError由於是錯誤，所以可以不捕獲，但不推薦這樣做，因為那樣會使你的系統進入不穩定狀態。
java斷言:
斷言在默認情況下是關閉的，要在編譯時啟用斷言，需要使用source1.4標記 既javac source1.4 Test.java ,在運行時啟用斷言需要使用 -ea參數 。要在系統類中啟用和禁用斷言可以使用 -ea和 -dsa參數。

⑸ 什麼是單元測試

單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然後確認該值出現在list 的尾部。或者，你可能會從字元串中刪除匹配某種模式的字元，然後確認字元串確實不再包含這些字元了。 單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。 工廠在組裝一台電視機之前，會對每個元件都進行測試，這，就是單元測試。 其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什麼的，這，也是單元測試，老納把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟體，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難於調試，大幅度提高後期測試和維護成本，也降低了開發商的競爭力。可以說，進行充分的單元測試，是提高軟體質量，降低開發成本的必由之路。 對於程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。 要進行充分的單元測試，應專門編寫測試代碼，並與產品代碼隔離。老納認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談老納的看法。 一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以老納的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。 有一種看法是，只測試類的介面(公有函數)，不測試其他函數，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯並最終排錯，因此，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對於C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫(inline函數)，所有在源文件編寫實現的函數都要進行測試(構造函數和析構函數除外)。 為什麼要使用單元測試 我們編寫代碼時，一定會反復調試保證它能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會願意交付給自己的老闆。但代碼通過編譯，只是說明了它的語法正確；我們卻無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。 幸運，單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。有了單元測試，我們可以自信的交付自己的代碼，而沒有任何的後顧之憂。 什麼時候測試？單元測試越早越好，早到什麼程度？XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工作中，可以不必過分強調先什麼後什麼，重要的是高效和感覺舒適。從老納的經驗來看，先編寫產品函數的框架，然後編寫測試函數，針對產品函數的功能編寫測試用例，然後編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的隨便返回一個值，編譯通過後再編寫測試代碼，這時，函數名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以後需修改的可能性比較小。 由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。 關於樁代碼，老納認為，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產品函數或測試函數調用了一個未編寫的函數，可以編寫樁函數來代替該被調用的函數，樁代碼也用於實現測試隔離。採用由底向上的方式進行開發，底層的代碼先開發並先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函數時，也是對下層函數的間接測試；當下層函數修改時，通過回歸測試可以確認修改是否導致上層函數產生錯誤。 在一種傳統的結構化編程語言中，比如C，要進行測試的單元一般是函數或子過程。在象C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發人員可以選擇是在獨立的過程和函數，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言(4GL)的開發中，在這里基本單元被典型地劃分為一個菜單或顯示界面。 單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試必須是可重復的，無論是在軟體修改，或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟體系統的生命周期中進行維護。 經常與單元測試聯系起來的另外一些開發活動包括代碼走讀(Code review)，靜態分析(Static analysis)和動態分析(Dynamic analysis)。靜態分析就是對軟體的源代碼進行研讀，查找錯誤或收集一些度量數據，並不需要對代碼進行編譯和執行。動態分析就是通過觀察軟體運行時的動作，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。 一些流行的誤解 在明確了什麼是單元測試以後，我們可以進行"反調論證"了。在下面的章節里，我們列出了一些反對單元測試的普遍的論點。然後用充分的理由來證明這些論點是不足取的。 它浪費了太多的時間
一旦編碼完成，開發人員總是會迫切希望進行軟體的集成工作，這樣他們就能夠看到實際的系統開始啟動工作了。 這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。 在這種開發步驟中，真實意義上的進步被外表上的進步取代了。系統能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug。在實踐中，這樣一種開發步驟常常會導致這樣的結果：軟體甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會導致在軟體集成為一個系統時增加額外的工期， 而且當這個系統投入使用時也無法確保它能夠可靠運行。 在實踐工作中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩定可靠的部件的情況下，開發人員能夠進行更高效的系統集成工作。這才是真實意義上的進步，所以說完整計劃下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。 使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。 它僅僅是證明這些代碼做了什麼
這是那些沒有首先為每個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條普遍的抱怨， 當編碼完成以後並且面臨代碼測試任務的時候，他們就閱讀這些代碼並找出它實際上做了什麼，把他們的測試工作基於已經寫好的代碼的基礎上。當然，他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見的編譯器Bug，但是他們能夠做的僅僅是這些。 如果他們首先寫好一個詳細的規格說明，測試能夠以規格說明為基礎。代碼就能夠針對它的規格說明，而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規格說明中的錯誤。好的規格說明可以使測試的質量更高，所以最後的結論是高質量的測試需要高質量的規格說明。 在實踐中會出現這樣的情況： 一個開發人員要面對測試一個單元時只給出單元的代碼而沒有規格說明這樣吃力不討好的任務。你怎樣做才會有更多的收獲，而不僅僅是發現編譯器的Bug？第一步是理解這個單元原本要做什麼， --- 不是它實際上做了什麼。 比較有效的方法是倒推出一個概要的規格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對這個概要規格說明的走讀(Review)，以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來設計單元測試了。 我是個很棒的程序員， 我是不是可以不進行單元測試？
在每個開發組織中都至少有一個這樣的開發人員，他非常擅長於編程，他們開發的軟體總是在第一時間就可以正常運行，因此不需要進行測試。你是否經常聽到這樣的借口？ 在真實世界裡，每個人都會犯錯誤。即使某個開發人員可以抱著這種態度在很少的一些簡單的程序中應付過去。 但真正的軟體系統是非常復雜的。真正的軟體系統不可以寄希望於沒有進行廣泛的測試和Bug修改過程就可以正常工作。 編碼不是一個可以一次性通過的過程。在真實世界中，軟體產品必須進行維護以對操作需求的改變作出反應， 並且要對最初的開發工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎？ 這些製造出這些未經測試的原始代碼的資深專家們還會繼續在其他地方製造這樣的代碼。在開發人員做出修改後進行可重復的單元測試可以避免產生那些令人不快的負作用。

⑹ 單元測試、集成測試、系統測試的順序可否調換，為什麼

不可以，軟體的開發也是從小的模塊開始，不可能沒有模塊就開始集成，後來才打包成一個軟體，形成一個系統。
單元測試是測試各個小的模塊，通過對他們的測試，才能找出基本的bug，然後為各個模塊搭建介面，也就是把模塊組裝起來，之後進行集成測試，看各個模塊的介面是否正常穩定，打包成軟體後，先做出一個demo版本，由開發和測試一起進行系統測試。