怎麼寫測試程序

不用 如果你創建所有類檔案都在同一個包裏，那麼就直接寫個test類，在test類中 直接使用你之前所創建類的就可以了，

前提是你的test類和其他的類在同一級目錄中，不需要繼承，也不需要接口的。

直接調用

比如你寫了個類檔案A.java

又寫了個測試類test.java，且A和test在同一級目錄

那麼在test.java中直接使用就行

比如

test.java{

public static void main(args[]){

A a;

}

}

你好！測試程序負責給編寫好的程序提供樣本數據，自動收集執行結果，並根據結果作出反饋。

測試程序可以單獨寫，也可以做爲模組整合在源程序中。像我們熟知的debug語句，就是測試的最簡單例子。

在沒有“斷電檢視”這一功能之前，爲了監測程序每步執行後變量的結果，往往加入一些輸出關鍵變量的語句。例如以下程序：#incldue using namespace std;#define DEBUG int main(){ int n;#ifdef DEBUG cout<

通常會顯示-89******00(0xcccccccc).一般這樣的語句還會出現在對指針進行操作之後，用debug語句輸出指針所指向內存的內容等。這只是測試程序的一個功能。

正如前面提到的，測試程序應該提供數據以檢測程序的健壯性和安全性，以及用海量數據對執行效率進行檢驗等。測試數據的選擇有以下幾個要點，分別檢測程序的不同特性：@ 儘可能包括輸入集合內所有可能出現的元素，觀察程序能否給出正確結果。

（Authenticity） 比如：有一個程序輸入給定迷宮平面圖，要測試出最短路徑長度。那麼輸入的迷宮應該包括各種可能：有通路的和沒有通路的，有死衚衕的和沒有的，有迴路的（避免搜尋時出現死循環），出口在左上角，右上角的等，都要考慮進去。

程序應該對每種情況都做出正確的反應。@ 注意測試極端情況以及臨界情況。

（Security） 這是爲了檢測程序的健壯性，用戶不可避免地會做出不合法的舉動，程序需要有足夠的防護強度來應對這些意外。 比如：如果編寫了一個簡易的計算器，那麼一定要檢查除數爲0的情況；一個程序的功能是將一片文檔的內容連結到另一個文檔內，那麼一定要檢查自己連結自己的情況；等等。

@ 注意輸入數據的規模以及隨機性。（Efficiency） 衡量程序效率的標準應該考慮大規模數據下的表現。

數據需要有足夠的隨機性以避免意外情況。 比如：比較幾種不同排序算法的效率時，選用的數據應該是隨機順序的。

在順序數據的情況下：冒泡算法顯然比快排還快，但這是偶然情況。@ 如果有可能，還可以檢測程序的通用性及擴展性（Versatility & Compatibility） 好的程序應該易於擴展，可利用價值高。

大多數軟件都在不停的打補丁，而不是推倒重寫。 測試程序一般無法直接檢測這兩種特性。

然而，測試中出現的錯誤有時可以幫助我們提升程序的質量。 我曾經寫過一個類似於美圖秀秀的圖像處理程序，C++寫的，相當粗糙。

輸入還要用命令行控制。當時我用各種圖片進行了測試，包括純色的，有明顯背景色調的，以及完全混亂的噪聲點。

前面的圖片表現都很好，但處理最後一張圖片時程序拋出了異常——經過檢驗發現，我的處理程序是基於24位圖片寫的，而最後一張圖片是32位的。類似的情況還有32位系統和64位系統下程序執行的問題等，在此就不贅述了。

要編寫測試程序，一般分爲兩個模組：數據生成和結果檢測。測試程序的第一部分將生成的數據寫入一個檔案，讓程序讀取檔案並執行後，再將結果寫入另一個檔案，之後由測試程序的第二部分比對輸出檔案和標準答案。

對於檢測健壯性的測試程序，只需有第一部分即可，待檢測程序在處理數據時如果發生異常，就根據結果作相應的修改。測試效率的程序，可以在待檢程序內加入計時模組。

具體寫法如下：#include#define CHECK_TIME int main(){ //。.intput#ifdef CHECK_TIME clock t start = clock();#endif#ifdef CHECK_TIME cout << "Execution Time: " << clock() - start << " ms." << endl;#endif 嗯，就是這麼多啦，希望對你有幫助。

我一直在想，作爲測試人員應該用腦袋去測試，也就是說應該在工作中不斷的總結經驗，把自己的發現應用到測試中去，這樣你纔能有真正的提高，你所具備的理論和能力纔有競爭力。

回到測試用例中來，我覺得做好以下三點就是一個好的用例。

第一：依據分明

衆所周知，一個項目首先立項，然後經過一系列的動作到了需求分析，昨晚需求分析後，測試就可以做測試需求，然後就可以寫測試用例了。所以寫測試用例的依據就是需求。這麼說太籠統，舉一個例子。一個系統經過前期的需求分析，詳細設計，模組設計等一系列的動作，最後生成了詳細的需求說明和詳細設計文檔等等，在這些文檔中，已經很詳細的描述了所有的需求點和功能點，也有較詳細的技術說明，接下來的工作就是怎麼把這些功能點和需求點變成測試點，這就需要做好測試需求分析和測試方案工作，生成一個個可測試的測試點。這也是需求必須可測的一個體現。

假設經過上一步工作，分析出這個系統有5個模組，50個大的功能點，500個具體需求點，最後生成了5000個測試點。那麼 ok，我們就要寫5000個測試用例。還是那句話，一個測試用例只能對應一個測試點，測試點和用例是1對1的關係；一個需求點可以對應多個用例，需求點和用例是1對多的關係。這樣做的目的在統計中講。

第二：目的明確

用例都有個測試目的，這就是要目的明確，並且也只能有一個目的。前面無論多少步驟，都是爲了找到這個目的途徑。功能從大到小有層次的劃分，我們做測試用例也是有層次的，不然你怎麼定義用例的優先級呢？等到測試最小的功能點是，支援這個功能點的其他上層功能點，我們都默認正確就可以了，這就是我們的預期，所以在測試步驟中不用對上層的功能專門考慮測試數據，只把他當成一個正確的找到目前的功能點的途徑就行。換句話說，你要測試的功能點需要點10個連接才能找到，那麼前9個連接我們再以前就應該設計了用例，在第10個連接中默認他們正確就ok，這個用例的前9步，只是告訴你如何找到第10步。就是這樣。

第三：便於統計

測試用例對整個測試過程的質量控制和評估有很重要的意義。

一，可以做測試需求覆蓋分析。這樣如果一個用例寫幾個測試點，那麼就無法完成需求覆蓋分析工作，至少是不符合規則的。

你還可以透過模組劃分，來分析哪個模組存在的問題較多，還有可能存在更多的問題（應爲程序員不同，能力就不同，缺陷喜歡扎堆分佈，這個大家都知道），存在問題較多的模組需要做進一步的測試或者下一次作爲測試重點。如果你統計的數據不準確，會誤導結果的。

三，做缺陷分析。用例失敗了，就生成一個缺陷。

寫好一個軟件的測試用例62616964757a686964616fe78988e69d8331333337613764的建議有：

1、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明瞭，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，並且原則上每個用例的名稱不能重複。

2、預置條件要明確，包括測試環境、測試數據、測試場景。因爲許多BUG只有在特定的環境、特定的場景下才可以重現。沒有正確的前提條件，就無法進行後面的測試步驟或無法得到預期的結果。

3、測試步驟描述要簡單、清晰，並且要清楚每一個步驟的描述，比如：第一步，輸入用戶姓名；第二步，輸入登入密碼；第三步，用戶點擊登入。步驟寫的明確時就利於提高用例的可操作性。

4、用例的預期結果要完整而且清晰，並且要將各個輸出的結果寫出來，包括：返回值的內容、數據庫相關字段的記錄、介面的響應結果、輸出結果的規則符合度、日誌的檢查和對其它業務影響的檢查。

5、測試用例級別要劃分清楚，這樣在測試執行時有主次之分。

6、測試用例的劃分也要單一，一個測試用例只檢查功能點的一種情況。一個用例檢查的情況太多，會導致用例的目的不明確。而且這樣組織用例，有利於需求覆蓋率的統計。一個功能點我們測試了哪些情況，以及哪些功能點我們在重點測試，一目瞭然。

測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一。

測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。

測試用例編寫準備

1

從配置管理員處申請軟件配置：《需求規格說明書》和《設計說明書》；

2

根據需求規格說明書和設計說明書，詳細理解用戶的真正需求，並且對軟件所實現的功能已經準確理解，然後着手製訂測試用例。

測試用例制定的原則

1測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。

2測試數據應該選用少量、高效的測試數據進行儘可能完備的測試。

用例覆蓋

1正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。

2容錯性（健壯性）測試：程序能夠接收正確數據輸入並且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示 並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。

3完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部資訊（數據庫或檔案）的完整。

4接口間測試：測試各個模組相互間的協調和通信情況，數據輸入輸出的一致性和正確性。

5壓力測試：輸入10條記錄執行各個功能，輸入30條記錄執行，輸入50條記錄進行測試。

6性能：完成預定的功能，系統的執行時間（主要是針對數據庫而言）。

7可理解（操作）性：理解和使用該系統的難易程度（介面友好性）。

8可移植性：在不同操作系統及硬件配置情況下的執行性。

測試方法

1邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。

2等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。

3錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。

測試用例的填寫

1一個軟件系統或項目共用一套完整的測試用例，整個系統測試過程測試完畢，將實際測試結果填寫到測試用例中，操作步驟應儘可能的詳細，測試結論是指最終的測試結果（結論爲：透過或不透過）。

如何編寫測試計劃呢？測試計劃要包括以下四個要點：1、待測試的內容；2、編寫測試用例的時間；3、執行測試用例的時間；4、執行迴歸測試的時間。以上四點，待測試的內容可以需求分析中取得，需求分析中的測試要點就是要測試的內容，而其它3點就不是很容易確定了。因爲我們可以從軟件的開發進度中獲得開始時間，但很難確定測試的結束的時間。下面有一個預估的辦法，是大多數測試工程師的經驗所得，我們拿到評審後的需求分析可以用下面的方法預估。

1、計算需求分析的頁數，得出測試用例的頁數，需求分許頁數：測試用例頁數 ≈ 1:1

2、由測試用例頁數計算編寫系統測試用例時間：編寫系統測試用例時間 ≈ 系統測試用例頁數*1小時

3、計算執行測試用例時間：編寫測試用例用時：執行系統測試用時 ≈ 1:2

4、計算迴歸測試包含的時間：系統測試用時：迴歸測試用時≈ 2:1

以上的方法可能根據測試人員對項目熟悉程度和測試經驗的不同而有所差別，大家可以根據自己的經驗做出調整。計算出測試用例、執行測試和迴歸測試的時間後，根據軟件項目的開發進度就可以編寫出一個軟件測試的時間表了。

不過從目前國內軟件公司的現狀來說，測試時間一般都不夠，所以我們只能延長我們的工作時間，提高我們的工作效率。程序員說他們處於最底層，用戶說要改什麼，他們就要實現什麼，沒人關心他們的工作難度和工作時間。（發點牢騷，大家就當沒看見，呵呵）

需要明確個問題，有沒有有需求或者設計文檔沒？1，有的話按照文檔寫，將文檔中的功能點摘錄出來，按照功能點去寫測試用例；2，沒有文檔，按照軟件功能去寫--那你們應該屬於瞭解和學習階段了：先了解軟件功能，然後將軟件的功能模組進行劃分，梳理出來一個個功能點；這樣有了功能點就可以進行測試用例編寫了：1，測試用例的要包括操作步驟：怎麼操作--把你的操作過程描述下來； 期望結果--軟件設計的結果是什麼--這個來自設計和平時的體驗； 實際結果--在測試過程中按照步驟執行下來之後看到的結果；2，編寫測試用例時將功能點進行劃分，需要確認該功能點有幾個測點，基本上做到一個測點一個case;3，測試用例要劃分優先級和重要級別：軟件功能主流程上的功能是重要級別最高的，而優先級一半配合開發過程和功能完善來確定：基本的要優先級最高，邊角的可以優先級最低；LZ如果是個新手，建議將軟件劃分成小塊，一個個的消化，其實測試最容易入門的方式就是將你作爲使用者，這就是用例的來源。

希望能對你有幫助。

三、編制測試用例 着重介紹一些編制測試用例的具體做法。

1、測試用例文檔 編寫測試用例文檔應有文檔模板，須符合內部的規範要求。測試用例文檔將受制於測試用例管理軟件的約束。

軟件產品或軟件開發項目的測試用例一般以該產品的軟件模組或子系統爲單位，形成一個測試用例文檔，但並不是絕對的。 測試用例文檔由簡介和測試用例兩部分組成。

簡介部分編制了測試目的、測試範圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。

每個具體測試用例都將包括下列詳細資訊：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、註釋等。以上內容涵蓋了測試用例的基本元素：測試索引，測試環境，測試輸入，測試操作，預期結果，評價標準。

2、測試用例的設定 我們早期的測試用例是按功能設定用例。後來引進了路徑分析法，按路徑設定用例。

目前演變爲按功能、路徑混合模式設定用例。 按功能測試是最簡捷的，按用例規約遍歷測試每一功能。

對於複雜操作的程序模組，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。

路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。 但路徑分析法也有侷限性。

在一個非常簡單字典維護模組就存在十餘條路徑。一個複雜的模組會有幾十到上百條路徑是不足爲奇的。

筆者以爲這是路徑分析比較合適的使用規模。若一個子系統有十餘個或更多的模組，這些模組相互有關聯。

再採用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那麼子系統模組間的測試路徑或測試用例還是要靠傳統方法來解決。

這是按功能、路徑混合模式設定用例的由來。 返回《軟件測試術語及名詞解釋》。

呵呵，我剛寫的一篇文章~專門討論測試需求~~摘抄一些吧~1. 基本概念軟件測試需求是根據測試目標而確定的被測軟件的測試屬性。

測試屬性就是軟件測試人員結合軟件測試意圖和被測軟件本身的特點分析得到的測試對象、範圍和內容等要素。其中軟件測試意圖指測試人員根據被測軟件或系統的實際使用情況或者工作環境，考察被測軟件功能性、可靠性、安全性、易用性等方面能力的想法。

軟件測試類型是軟件測試意圖的具體表現。透過對測試模式的總結，並且從軟件質量屬性的角度進行分類，形成軟件測試類型。

根據被測試對象的不同，軟件測試可以分成不同的級別如單元測試、部件測試、配置項測試、系統測試等。軟件系統測試需求則是軟件測試需求在系統測試級別中的具體應用。

同理，軟件系統測試類型也是軟件測試類型在系統測試級別中的實例應用。在軟件需求規格說明文檔中，開發人員對各個軟件需求點進行了描述，因此我們用{軟件需求}表示依據軟件需求點形成的矩陣，用符號 表示。

2.軟件系統測試需求與軟件需求的關係軟件系統測試需求和軟件需求的相同之處在於兩者分析的對象都是軟件系統，並且都是對其需求的描述。理想狀態下，軟件系統測試需求與軟件需求應該是相同的，均是以用戶需求爲依據，對其進行全面闡述。

但是由於軟件工程化水平的發展情況，以及實際操作過程中由於軟件開發人員和軟件測試人員從不同的角度分析和理解用戶的需求，造成軟件系統測試需求和軟件需求現實上的差異。在實際操作過程中，軟件需求主要是描述軟件該實現什麼樣的功能或者該達到什麼樣的性能等用戶的需求[2]。

軟件需求與用戶的需要有着十分緊密的關係，軟件需求是本着實現用戶需要的思想開展的，以滿足用戶需要爲前提的。因此軟件需求就是描述軟件要做什麼。

而軟件系統測試需求又是從另外一個角度分析軟件的。軟件測試需求主要描述軟件是否做了應該做的，同時沒有做不該做的，也就是說從用戶實際使用的角度出發，考察軟件是否實現了用戶的需求，同時考察軟件對非用戶需求的處理情況。

軟件系統測試需求就是在系統測試這個測試級別上以軟件需求爲基礎分析出的測試需求，它是進行軟件系統測試活動的基礎。歡迎討論~~。