模板
教程
環境
性能
功能
管理
從用例到測試用例的追蹤
本文闡述了一種從用例產生功能測試用例的正式方法，包括如何創建一個用例，產生所有場景，并且創建合理的測試用例，以及使用IBM Rational RequisitePro進行從用例到場景和測試用例的追蹤。
需求類型概覽一個需求被定義成 "系統必須遵從的條件或能力"。
它可以是：
一個顧客或用戶所需要的，用以解決一個問題或達成一個目標的能力
一個必須被一個系統所滿足和擁有的，用以滿足一個合同、標準、規格、規則或其它正式強制文檔的能力
一個被涉眾所強加的限制
圖1顯示了帶有不同需求級次的需求金字塔
圖1. 需求金字塔
最高層的是涉眾需求。通常，一個項目包含五到十五個這樣的高層需求。較低層次的是特性，用例和補充規約。不同層次的需求有不同的細節。越低的層次需要越多的細節。例如，一個需求可以是："數據必須是持久的"。特性可以將此需求精化為："系統應當使用一個關系數據庫"。在補充規約層次，需求會更加詳細：" 系統應當使用Oracle 9i數據庫"。層次越低，需要越詳細的需求。
需求之間的追蹤關系
追蹤是這樣一種技術，在系統中它能為不同層次的需求之間提供關聯。這個技術幫助你確定任何需求的起源。圖 2 闡述了從高層次到低層次需求是如何被追蹤的。每一個需求通常映射到幾個特性，然后這幾個特性映射到用例和補充需求。
圖2. 追蹤需求金字塔
用例描述了功能性的需求，補充規約描述了非功能性的項目。另外，每個用例映射到許多場景。映射用例到場景，是一對多的關系。 場景映射到測試用例也是多對一的關系。另一方面，在需要與特性之間，是多對多的映射。
追蹤起到了幾個重要的作用：
驗證一個實現是否完成了所有的需求：用戶要求的每一件事情都被實現了驗證應用程序只做了所要求的事情：不會去實現用戶從未要求的事情
有助于變更管理：當一些需求變更后，我們想知道哪些測試用例應當被重新執行以測試這個變化一個追蹤項是一個項目元素，其需要從另一個元素進行追蹤。按照IBM Rational RequisitePro，它是一個需求類型的實例所表示的任何事情。在RequisitePro中一些需求類型的例子是涉眾需求，特性，用例，參與者，和術語條款。
在RequisitePro中，有一種按照特定視圖展示追蹤性的便利方法。圖3 顯示了將特性映射到用例的一個例子。
圖3. 在RequisitePro中的追蹤關系
這里有一些問題，這些箭頭應指向哪里：是從更低的層次到更高的層次，還是從更高的層次到更低的層次。甚至在RequisitePro中的兩個例子使用了兩個不同的方法。答案是沒有關系，只要你在項目中始終如一地使用它們就可以了。
參與者和用例
參與者是與系統交互的某人或某事。用例是根據操作順序的一個系統描述。它為參與者產生了一個看的見的結果或數據值。以下是用例的一些特征：
被參與者初始化
模擬參與者和系統之間的交互
描述操作的序列
獲取功能需求
為參與者提供數據值
表示完整的和有意義的事件流
用例的目的是促使開發者、顧客和用戶之間對系統應做些什么達成一致。用例在開發者和顧客之間達成了某種契約。它同時也是用例實現的基礎，它在程序設計中起到了非常重要的作用。另外，你可以從用例中產生序列圖，協作圖和類圖。此外，你可以從用例產生用戶文檔。用例可能還在計劃迭代的技術內容方面有幫助，并且使系統開發者更好地了解系統的意圖。最后，你可以使用它們作為測試例程的輸入。
用例圖顯示了參與者和用例之間的關系。在本文我們使用一個在線書店作為項目的一個例子。圖4 展示了這個項目的用例圖。
圖4. 用例圖
原文轉自：http://www.uml.org.cn/Test/200607073.htm
