《軟體測試》第十八章 編寫和追蹤測試用例

2021-04-13 23:04:22 字數 2559 閱讀 8697

the goals of testcase planning -計畫的目的

測試用例

測試用例計畫的目的是什麼呢?如果你想要別人按照一定的規矩辦事,那麼你自己也必須首先遵守這些規矩。所以作為乙個測試員,如果一拿到測試計畫就坐下來瘋狂的寫case,那麼跟乙個不看產品說明書就開始編碼的程式設計師是一樣的。我們要仔細地而且系統地去計畫測試用例,為什麼要這樣子呢?有4個原因:

organization- 乙份好的計畫可以被很好地組織起來,這樣的話出來你以外的其他人就能有效地回顧你的成品

repeatability- 如果沒有乙個正確的計畫,那麼是不可能知道我們的測試用例運**況,而且幾乎不能被重新使用,因為通常你都不知道它在**

tracking- 可追蹤的。有了好的計畫,才能追蹤專案的進度,多少case已經被執行了多少pass多少fail。各自狀態如何。

proof of testing (or not testing)- 證明已經測試過的。這個記得以前在reyrey的時候乙個老外就說過,測試用例能夠幫助公司避免法律的紛爭。

test case planning overview - 測試用例計畫概覽

除了書中以前說的測試計畫(test plan),在它的下面會有這些:test design specification(測試設計說明書), test case specification(測試用例說明書), the test procedure specification(測試流程說明書)

test design - 測試設計

test case identification - 測試用例的識別。這裡不是說要有詳細的測試用例,只是標明了哪些測試用例將會覆蓋哪些功能的測試。具體細節不會出現在測試設計裡面。

pass/fail criteria - 通過測試和測試失敗的標準。

test cases - 測試用例。

「對測試的實際輸入以及其相應的輸出進行文件記錄,測試用例同時識別出任何在測試流程中可能出現的限制。」而且測試用例會跟乙個或多個測試計畫想關聯,而通常還會跟不止乙個的測試流程關聯。

identifiers - id,用來做文件關聯。

test item - 測試專案。描述被測試的細節的功能,**模組等等。而且還需要關聯上哪些文件提及到了被測試的功能。

input specification - 輸入詳述。列舉出所有的輸入或者執行測試用例的條件。

output specification - 輸出詳述。描述測試用例的期望輸出。

environmental needs - 環境需要。是不是需要特定的硬體軟體外設工具等等?

special procedural requirements - 特殊的程式要求?

intercase dependencies - 用例之間的相互依賴,是否有一些用例,需要在別的用例執行通過的情況下才能進行的。

test procedures - 測試流程。

「識別出執行所需要的步驟。測試流程是一步一步如何去執行測試用例的細節說明」

identifiers - id,用來做文件關聯。

purpose - 目的。

special requirements - 特殊需求。

procedure steps - 流程步驟。

detail versus reality - 與實際的對照。

the trick is finding the right level of moderation - 這裡的竅門就是找到合適的度。古人云:過猶不及。很多時候我們要做到什麼樣的程度,取決於每個專案不同的要求。

test case organization and tracking - 測試用例的組織與跟蹤

in your head - 記載腦子裡面?俗語說的好啊,好記性不如爛筆頭。大家還是省點頭腦風暴的時間吧。

*****/documents - 記在文件裡面有個缺點就是很難找到具體想要的東西,不過好處就是如果有個測試員的簽名的話,是個很好避免法律糾紛的方法,呵呵

spreadsheet - 電子**。日本公司喜歡用excel(當然啦,excel只是其中一種spreadsheet)。而且用的出神入化。我看我連excel的門都沒入啊。唉。

custom database -資料庫。一種比較好的選擇就是測試用例管理工具。例如qc, cc。呵呵。不過是要錢di。還是看開源的吧。

後記:其實書裡面分的好細,一般公司也就是乙個測試計畫下來就是測試用例了,而且一般我們說的測試用例都已經包含了測試流程的內容--具體的執行步驟。我覺得任何書或者參考資料或者方**都只是參考而不是標準,即使它們沒有說能夠被裁剪,但是我們也可以發揮自己的主觀能動性來改造它們,讓之適合我們各自的使用情況。我個人覺得就不用死扣你這公司不標準啊怎麼測試用例跟測試流程都連在一起了。呵呵。做人要變通:)

C 程式語言 第十八章 演算法和函式物件

1 標準庫演算法綜述 它們都宣告在 2 函式物件 如果乙個類的物件具有應用運算子,我們稱為函式物件 標準庫中的基類 unary function和binary function 3 謂詞 謂詞就是返回bool的函式物件 或者函式 4 約束器 通過將乙個引數約束到某個值,是我們可以將兩個引數的函式物件...

C和指標 第十八章 效能評測工具gprof

linux平台下的gprof評測工具可以對程式進行分析,需要在編譯時加上 pg選項,如上一章的二叉樹 gcc pg main.c arraybinarytree.h arraybinarytree.c先執行一下,然後就會生產gmon.out檔案,該檔案用於分析程式執行 a.out再次執行進行分析 g...

標準編寫軟體 如何設計和編寫軟體測試用例

一 測試用例是軟體測試的核心 軟體測試的重要性是毋庸置疑的。但如何以最少的人力 資源投入,在最短的時間內完成測試,發現軟體系統的缺陷,保證軟體的優良品質,則是軟體公司探索和追求的目標。每個軟體產品或軟體開發專案都需要有一套優秀的測試方案和測試方法。影響軟體測試的因素很多,例如軟體本身的複雜程度 開發...