測試用例,模版

轉載:https://blog.csdn.net/a823080387/article/details/55100730

 

該範例已經包含一個測試用例的模板。

項目/軟件	技術出口合同網絡申領系統 （企業端）	程序版本	1.0.25
功能模塊名	Login	編制人	xxx
用例編號-	TC-TEP_Login_1	編制時間	2002.10.12
相關的用例	無
功能特性	用戶身份驗證
測試目的	驗證是否輸入合法的信息，容許合法登錄，阻止非法登錄
預置條件	無	特殊規程說明	如數據庫訪問權限
參考信息	需求說明中關於「登錄」的說明
測試數據	用戶名=yiyh 密碼=1
操做步驟	操做描述	數 據	指望結果	實際結果	實際結果	測試狀態（P/F）
1	輸入用戶名稱，按「登錄」按鈕。	用戶名=yiyh，密碼爲空	顯示警告信息「請輸入用戶名和密碼！」
2	輸入密碼，按「登錄」按鈕。	用戶名爲空，密碼=1	顯示警告信息「請輸入用戶名和密碼！」
3	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=yiyh，密碼=2	顯示警告信息「請輸入用戶名和密碼！」
4	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=xxx，密碼=1	顯示警告信息「請輸入用戶名和密碼！」
5	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=xxx，密碼=2	顯示警告信息「請輸入用戶名和密碼！」
6	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=空，密碼=空	顯示警告信息「請輸入用戶名和密碼！」
7	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=yiyh，密碼=1	進入系統頁面。
8	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=Admin，密碼=admin	進入系統維護頁面。
9	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=yiyh'',密碼=1	顯示警告信息「請輸入用戶名和密碼！」
10	輸入用戶名和密碼，按「登錄」按鈕。	用戶名=yiyh，密碼=1''	顯示警告信息「請輸入用戶名和密碼！」
11	輸入用戶名和密碼，按「重置」按鈕。	用戶名=yiyh，密碼=1	清空輸入信息
測試人員		開發人員			項目負責人

三、測試用例設計的誤區

一、能發現到目前爲止沒有發現的缺陷的用例是好的用例：

首先要申明，其實這句話是十分有道理的，但我發現不少人都曲解了這句話的原意，一心要設計出發現「難於發現的缺陷」而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向於將測試用例看成一個集合來認識，對它的評價也只能對測試用例的集合來進行，測試自己是一種「V&V」的活動，測試須要保證如下兩點：

l 程序作了它應該作的事情 

l 程序沒有作它不應作的事情

所以，做爲測試實施依據的測試用例，必需要能完整覆蓋測試需求，而不該該針對單個的測試用例去評判好壞。

 

二、測試用例應該詳細記錄全部的操做信息，使一個沒有接觸過系統的人員也能進行測試；

不知道國內有沒有公司真正作到這點，或者說，不知道有國內沒有公司可以將每一個測試用例都寫得如此詳細。在個人測試經歷中，對測試用例描述的詳細和複雜程度也曾有過不少的彷徨。寫得太簡單吧，除了本身沒人可以執行，寫得太詳細吧，消耗在測試用例維護（別忘了，測試用例是動態的，一旦測試環境、需求、設計、實現發生了變化，測試用例都須要相應發生變化）上的時間實在是太驚人，在目前國內大部分軟件公司的測試資源都不足的狀況下，恐怕很難實現。但我恰恰就能遇到一些這樣的老總或者是項目負責人，甚至是測試工程師自己，全然不顧實際的資源狀況，必定要寫出「沒有接觸過系統的人員也能進行測試」的用例。

在討論這個問題以前，咱們能夠先考慮一下測試的目的。測試的目的是儘量發現程序中存在的缺陷，測試活動自己也能夠被看做是一個Project，也須要在給定的資源條件下儘量達成目標，根據我我的的經驗，大部分的國內軟件公司在測試方面配備的資源都是不足夠的，所以咱們必須在測試計劃階段明確測試的目標，一切圍繞測試的目標進行。

除了資源上的約束外，測試用例的詳細程度也須要根據須要肯定。若是測試用例的執行者、測試用例設計者、測試活動相關人對系統瞭解都很深入，那測試用例就沒有必要太詳細了，文檔的做用原本就在於溝通，只要能達到溝通的目的就OK。

在我擔任測試經理的項目中，在測試計劃階段，通常給予測試設計30% - 40%左右的時間，測試設計工程師可以根據項目的須要自行肯定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。

 

三、測試用例設計是一勞永逸的事情；

這句話擺在這裏，我想沒有一我的會承認，但在實際狀況中，卻常常能發現這種想法的影子。我曾經參與過一個項目，軟件需求和設計已經變動了屢次，但測試用例卻沒有任何修改。致使的直接結果是新加入的測試工程師在執行測試用例時不知所措，間接的後果是測試用例成了廢紙一堆，開發人員在屢次被無效的缺陷報告打擾後，對測試人員不屑一顧。

這個例子可能有些極端，但測試用例與需求和設計不一樣步的狀況在實際開發過程當中確是家常便飯的，測試用例文檔是「活的」文檔，這一點應該被測試工程師牢記。

 

四、測試用例不該該包含實際的數據；

測試用例是「一組輸入、執行條件、預期結果」、毫無疑問地應該包括清晰的輸入數據和預期輸出，沒有測試數據的用例最多隻具備指導性的意義，不具備可執行性。固然，測試用例中包含輸入數據會帶來維護、與測試環境同步之類的問題，關於這一點，《Effective Software Test》一書中提供了詳細的測試用例、測試數據的維護方法，能夠參考。

 

五、測試用例中不須要明顯的驗證手段；

我見過不少測試工程師編寫的測試用例中，「預期輸出」僅描述爲程序的可見行爲，其實，「預期結果」的含義並不僅是程序的可見行爲。例如，對一個定貨系統，輸入定貨數據，點擊「肯定」按鈕後，系統提示「定貨成功」，這樣是否是一個完整的用例呢？是否是系統輸出的「定貨成功」就應該做爲咱們惟一的驗證手段呢？顯然不是。定貨是否成功還須要查看相應的數據記錄是否更新，所以，在這樣的一個用例中，還應該包含對測試結果的顯式的驗證手段：在數據庫中執行查詢語句進行查詢，看查詢結果是否與預期的一致。

四、測試用例在軟件測試中的做用 

    一、指導測試的實施 

    測試用例主要適用於集成測試、系統測試和迴歸測試。在實施測試時測試用例做爲測試的標準，測試人員必定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。並對測試狀況記錄在測試用例管理軟件中，以便自動生成測試結果文檔。 

    根據測試用例的測試等級，集成測試應測試那些用例，系統測試和迴歸測試又該測試那些用例，在設計測試用例時都已做明確規定，實施測試時測試人員不能隨意做變更。 

    二、規劃測試數據的準備 

在咱們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤爲象測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。

除正常數據以外，還必須根據測試用例設計大量邊緣數據和錯誤數據。 

    三、編寫測試腳本的"設計規格說明書" 

    爲提升測試效率，軟件測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。若是說軟件工程中軟件編程必須有設計規格說明書，那麼測試腳本的設計規格說明書就是測試用例。 

    四、評估測試結果的度量基準 

    完成測試實施後須要對測試結果進行評估，而且編制測試報告。判斷軟件測試是否完成、衡量測試質量須要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。之前統計基準是軟件模塊或功能點，顯得過於粗糙。採用測試用例做度量基準更加準確、有效。 

    五、分析缺陷的標準 

    經過收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測仍是缺陷復現。漏測反映了測試用例的不完善，應當即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試用例，則反映實施測試或變動處理存在問題。

五、試用例編號規則

目的：好的測試用例編號，能夠更好的去了解此項用例所針對的模塊，也有助於記憶和新用例的增長。

規則：測試用例編號採用「版本+細類+編號」的形式。

備註：其中「版本」爲設計此測試用例的軟件版本。

「細類」爲小模塊中的漢字頭一個字母，以最多5個字母爲標準。

「編號」爲BUG用例的編號，以4位爲標準，依次遞增。

例如：引導系統V2.01版本中，候車點設置，用例編號能夠書寫爲：

          2.01_HCDSZ_0001

9、集成測試

      集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，而且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片斷的組合，並最終擴展進程，將您的模塊與其餘組的模塊一塊兒測試。最後，將構成進程的全部模塊一塊兒測試。此外，若是程序由多個進程組成，應該成對測試它們，而不是同時測試全部進程。

      集成測試識別組合單元時出現的問題。經過使用要求在組合單元前測試每一個單元並確保每一個單元的生存能力的測試計劃，能夠知道在組合單元時所發現的任何錯誤極可能與單元之間的接口有關。這種方法將可能發生的狀況數量減小到更簡單的分析級別。

      集成測試是在單元測試的基礎上，測試在將全部的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程當中各部分工做是否達到或實現相應技術指標及要求的活動。也就是說，在集成測試以前，單元測試應該已經完成，集成測試中所使用的對象應該是已經通過單元測試的軟件單元。這一點很重要，由於若是不通過單元測試，那麼集成測試的效果將會受到很大影響，而且會大幅增長軟件單元代碼糾錯的代價。 

      集成測試是單元測試的邏輯擴展。在現實方案中，集成是指多個單元的聚合，許多單元組合成模塊，而這些模塊又聚合成程序的更大部分，如分系統或系統。集成測試採用的方法是測試軟件單元的組合可否正常工做，以及與其餘組的模塊可否集成起來工做。最後，還要測試構成系統的全部模塊組合可否正常工做。集成測試所持的主要標準是《軟件概要設計規格說明》，任何不符合該說明的程序模塊行爲都應該加以記載並上報。 

      全部的軟件項目都不能擺脫系統集成這個階段。無論採用什麼開發模式，具體的開發工做總得從一個一個的軟件單元作起，軟件單元只有通過集成才能造成一個有機的總體。具體的集成過程多是顯性的也多是隱性的。只要有集成，老是會出現一些常見問題，工程實踐中，幾乎不存在軟件單元組裝過程當中不出任何問題的狀況。從圖1能夠看出，集成測試須要花費的時間遠遠超過單元測試，直接從單元測試過渡到系統測試是極不穩當的作法。 

      集成測試的必要性還在於一些模塊雖然可以單獨地工做，但並不能保證鏈接起來也能正常工做。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現。此外，在某些開發模式中，如迭代式開發，設計和實現是迭代進行的。在這種狀況下，集成測試的意義還在於它能間接地驗證概要設計是否具備可行性。 

      集成測試的目的是確保各單元組合在一塊兒後可以按既定意圖協做運行，並確保增量的行爲正確。它所測試的內容包括單元間的接口以及集成後的功能。使用黑盒測試方法測試集成的功能。而且對之前的集成進行迴歸測試。