Tricentis托斯卡測試用例設計:高級技巧

我常問“技巧”或最佳實踐分享關於Tricentis托斯卡測試用例的設計。這並不像看起來那麼容易,因為沒有“一刀切”解決方案的測試用例的設計。適合於一個組織的戰略可能是太靈活和限製。

考慮到這一點,我想分享一些關鍵因素與Tricentis托斯卡創建一個有效的測試用例設計:

自由你的頭腦從堅持一個完美的世界

首先,請記住:如果我有一個業務用例和設計測試用例,它看起來不同於其他任何人的測試用例設計。它可能會有一些共同點,但根據不同的需要,使用(更多的功能,更多的務實),經驗,和設計師的理解,測試用例將完全不同。我甚至會走這麼遠來押注10人會創建10個不同的版本。對於每個用例,測試用例的設計是獨特的。

指南是為選項,而不是需要

它並不重要指導原則要遵循設計“完美”的測試用例。更重要的是,你已經考慮這些指導方針,從每一個選項,選擇正確的解決你的問題。說:“一個測試用例需要確定…”將導致失敗和不一致。我保證!當然,你需要調整你的測試表使用類和使用常識,所以每個人都可以讀取和處理您的測試用例——這是一個事實。但除此之外,總是保持開放,敢於嚐試新事物和改變,即使你倒退往往比你進步。可能發生的最壞的事情就是你增加你的知識和信任您的解決方案。

如果你停止運動,你已經死了

不僅僅是鯊魚死亡如果他們停止運動——它也適用於測試用例設計。想象一下:有一個故事在你的衝刺使一個新特性。你的證明和一個非常接近於完美的設計測試用例沒有機會處理,並且不給你機會把它作為一個合適的選擇。所以,要做的是什麼?去更糟糕的是,不滿意解決方案嗎?改變你的測試用例!接受挑戰,盡力達到近乎完美的狀態,隻是你需要的元素。如果不需要靈活,它不是一個足夠成熟的測試用例。

保持你的注意力

總有指導方針在公司,告訴你你應該關注的地方。保持簡單,試圖得到一個高引用的類(不是所有應該類!),並且努力保持它的維護和可讀性。不要失去自己在結構和尋求第二意見。什麼是完美的解決方案的價值,如果沒有人能讀懂它或使用它嗎?功能和簡單的,但不要錯過業務邏輯。認為在大局,不僅在你的用例。最重要的是,不要追求完美,你就不會達到它。

清理你的懷疑

一定要理解測試用例設計的重要性。從測試用例開始設計早在你實現和堅持下去。理由做測試用例設計包括有功能模板,存儲您的測試數據,顯示您的工作流程,業務可讀的測試用例,所有你的測試用例,提高維護,等等。

這裏有一些選項可以使用:

• 測試用例通常有三個主要部分:前提條件、工作流程,發布狀態。你可以測試表結構。使用賬戶的先決條件需要在您的測試用例,材料或其他類似環境中,瀏覽器或用戶。盤點工作流程的所有數據使用在你的測試用例,你需要把它做好。情況後,放在驗證,也許拯救你需要清理前期在接下來的測試用例。
• 如果你有超過4到6屬性,它們分組,使結構內的一個新的水平。某些情況下這是不可能的(銀行賬戶、預訂等)。但是對於那些有可能,想做就做。每個人都需要閱讀或使用它將感激。
• 單一的選擇和類型字段之間的決定可能比你想象的要容易,並改變它們之間是一個單一的點擊。隻是你喜歡什麼。類型字段非常適合不斷變化的價值的不同實例的實例。
• 使用不同的顏色來驗證和管理屬性。
• 盡可能經常練習設計測試用例。習慣了快捷鍵和其他研究的測試用例。你可能會提高,看到不同的東西。
• 從一個實例出發,忽略其他,隻填寫你所需要的東西。然後用每個進一步實例,讓它成長進步與您添加每一個變體。變化越來越大的結構在需要的時候你會的,我保證。
• 結合其他的測試表,以確保他們有相同的結構。如果每個人都有錯誤消息作為普通文本,做同樣的事情。如果每個人都有單一的選擇錯誤消息作為價值,做同樣的事情。如果消息隻是在測試用例部分,調查的目的決定。
• 一個測試表包含一個直通和它的變體,包括負麵測試用例。變異是連續的不同選擇通過在相同的業務工作流程。負麵測試用例是一個直接的目的在某種程度上與一個預定義的原因。
• 的使用功能開關在測試用例中是被允許的。也許用下麵的“價值”屬性,使用存儲的數據。
• 使用類,他們是有意義的。使用預定義的和重複的行為和價值觀(預訂)。不要用它來改變數據,如果每個變體是不同的。
• 一個測試表通常不應該包含100實例。
• 測試表可以是一個類,並被重用在其他測試表。
• 將在一個單獨的測試板測試數據管理結構是有意義的,但保持儲存後更改並作為備份。

最後,隻有一個方法改善:通過這樣做。學習需要練習。嚐試什麼對你是有意義的——甚至嚐試的東西沒有意義,理解它,使用它,扔掉它。一段時間後,你會看到比你首先想到的更容易。繼續前進,讓我知道你的想法,你所麵臨的挑戰”。