在每一個用例步驟中應該包含多少信息呢？
我更偏愛于取得系統用例并將其根據業務用例分類，并且同樣通過一組步驟將大量的用戶交互活動分類。該組步驟解釋了該步驟的目的，并且可以在某些細節在實現過程中改變的情況下保持不變。這種方法使得文檔更加易懂，它將系統用例和業務用例聯系起來，并且如果產品執行變化時它允許用例可以被容易的修正。
例如，在上述系統用例中的簡單的步驟“運行代碼復審”中，向細心的讀者傳遞了一個非常有價值的信息，包括：
代碼復審被結合在IDE中。
代碼復審必須在使用中，或者“運行”。
代碼復審提供了一個關于違背某套有效性標準的問題清單。
某些問題可以被迅速的修正。
代碼復審將獲得迅速的修正。
確保有效的測試
一旦用例被適當的設置并且開發團隊就他們所扮演的角色達成共識，這些用例就成為方案中其他部分的基礎。實際上，這是最好的利用它們所提供功能的方法。
工程團隊建造一個開發方案，其中至少要包括：一份將要被建造的組建的清單，以及每一個組建的時間期限。清楚的描繪主用例的特性需求和實際工作特性的組件必要性之間的關系是非常重要的。
識別這些核心組件并且定義它們的用例是非常關鍵的步驟，它使得應用程序功能性的早期測試變成可能。如果該核心組件能夠在開發周期的初期被完成，那么測試人員就能夠開始為基本的規則集合撰寫測試腳本并且確認該工具功能的有效性。
在我們的例子中，系統用例“運行代碼復審”使得測試人員能夠為該核心功能制定能夠測試計劃，甚至可以在代碼被編寫出來之間就實現這一點。測試人員還可以為主流程和可選項目創建一套手工測試腳本。
測試類型
最簡單的測試形式，同時也是非常有效的一種測試形式，就是聚集一大批受過良好訓練的用戶來針對該應用程序的各種不同特性來進行測試和演練，并且將測試結果（發現的問題和缺陷）報告給代碼開發團隊。這種確認形式很簡單：擁有越多的用戶，就會檢查出更多的缺陷。不同的用戶群將用不同的方式使用該工具并且進一步增加被檢查出來的問題的數量。然而，有一些與此相關的問題。直到該軟件為用戶使用做好準備的那一刻之前，我們都有可能沒有足夠的時間來開展廣泛的測試計劃了。不同的用戶可能使用不同的產品。更重要的是，完全依靠人工是非常昂貴而且非常不可靠的。
還有更多的事情需要考慮。如果沒有一個清楚的測試計劃，就不可能采取同樣的測試方法來對不同版本的應用程序中的相同特性加以測試。如果沒有測試工具的協助，對于每一次測試我們所采取的測試步驟將會大不相同。并且，我們將會疏漏一下很少用到的，但卻是潛在的重要的情節。
手動測試和回歸測試
手動測試 是指以確定一個特定的系統相應為目標的一套動作。手動測試的另外一種選擇就是自動測試。兩者都屬于功能測試的類型.自動測試意味著您使用一個專門的工具或者一批腳本來對一套應用程序組件進行測試，記錄應用程序的反應，將其與想定值進行比較，從而決定測試是否成功。所有這些工作都沒有人工干涉。自動操作使得您可以一遍又一遍的重復同一項測試，具有人工永遠無法達到的精確性。自動操作功能測試的例子包括IBM Rational Robot以及IBM Rational Functional Tester。
回歸測試，用來衡量應用程序的質量，既可以手動處理也可以自動處理。您能夠從自動功能性測試或者自動開發者測試（詳見下文）中聚集一組回歸測試組合工具�？煽康幕貧w測試的關鍵因素就是景區的再現這些測試。因此，在被稱作測試腳本的文檔精確的定義測試步驟，并且在每一個回歸測試中嚴格的按照這些步驟操作是非常必要的。在此之后，您就可以放心的使用這些測試結果，既不必擔心有問題報告，也不必再去衡量其質量了。
測試的成功與否同您在制定測試計劃、文檔化手動測試和自動測試上所投入的時間長短是有著密切的聯系的。下面是一些實現有效測試的具體的建議：
根據用例制定您的測試計劃。首先開始測試主用例流程，然后擴展到可選流程。正如前面所描述的，關鍵是保持您的用例中的適當的粒度和模塊性。
通過測試計劃來組織您的手動測試，通過第一批測試就開始采用一種統一的方法記錄和分析測試結果。重復的、統一的操作（即使是手動的）也將會提高您工作的質量。
自動測試首先具有相對簡單可行的執行路徑，但是每一次運行它都需要大量的入口數據。運用現成的數據池來完成測試腳本（例如，進行數據驅動測試）。
開發者測試
將用例轉換為有效的測試通常會遇到一個大的障礙：代碼底層中的一大塊部分直到開發周期的后期才能夠提供給功能測試。因此，如果一些組件在被組裝進正在運行的應用程序之前就被測試將是一件好的事情。而這正是開發者測試所符合的。
開發者測試是一套關注于提高代碼質量的活動，它經常被開發者使用。開發者測試包括兩個主要方面：
自動化單元和組件測試。包括代碼評審，單元或組件測試，以及代碼覆蓋分析。
手動測試和調試。包括運行跟蹤，聲明，內存泄漏檢測和內存用法分析，性能評測，線程分析，等等。
自動批處理測試可以使用例如JUnit工具——一種集成在IBM Rational應用程序開發器里的代碼復審工具，也可以使用IBM Rational PurifyPlus提供的附加的方法來確保高質量的軟件。在開發環境下找到并且修改缺陷就意味著在后來會出現更少的功能性錯誤。并且可以節省出更多的時間來編寫代碼和引介更多的自動控制。另外，擁有可靠的可重復性的自動單元測試和代碼復審，可以使您收集到關于代碼質量的有價值的方案，獲得前面所描述的一樣的好處。
對于大多數組織，實現開發者測試的主要障礙就是對所需要工具的學習曲線。通常，個體的開發者測試工具注重于軟件質量中某一個相對狹窄的方面。如果團隊成員不具備自動開發者測試的經驗，那么如何找到合適的工具和決定采用何種類型的測試就成為呈現在我們面前的巨大的挑戰。因此，開發計劃不應當僅僅將時間投入到開發和調試應用程序組件上，也應當將時間和資源投入到培訓、設置、分析和報告有關執行自動開發測試方面。這一初期投資將會很快的帶來回報，它將使得測試團隊檢測更少的功能性錯誤。它同樣也會提高團隊成員理解代碼原理的水平。
下面是一些關于以開發者測試為開始的建議：
如果您即將進行單元測試，那么在運行單元測試的同時開始收集代碼覆蓋數據，從而對整套單元測試進行完全的評估。
如果您即將開發C++應用程序，那么請您運行關鍵用例，并且通過工具對動態內存分配進行分析。內存惡化的問題是本地C++應用程序的一個關鍵的方面，也是造成許多意想不到的和難于再現的缺陷的根源。
至少在每一個合成結構中的組件內收集執行的基線，并且隨時監視執行的過程。
如果您即將開發一個Java/J2EE應用程序，那么請您在一組基本測試中監視內存使用情況和內存中的對象類型。
在開始時應用一把最重要的靜態分析規則，將它們應用于每一個結構中，并且不斷向您的代碼底部添加更多的規則。這必將會減少運行結果中出現的錯誤。
開發者測試并不會取代功能回歸測試，手動的或者自動的。它只是通過在開發環境中檢測問題，從而在整體上提高了測試的效率，因為在這時修改起來相對更加容易。
積極測試和消極測試
積極的測試將關注點放在應用程序主流程的確認上，正如用例文檔中所定義和區分出的優先次序那樣。消極的測試則通常關注于那些應用程序性能極限的測試方面（例如，“破壞應用程序”）。
在我看來，一份好的測試計劃應當明確的關注于確認用例路徑，而不是包括極限測試。通常，您可以通過數據驅動測試來對極限進行評估，數據驅動測試應用不同的數據集來對某個單一的實例進行測試，這是為了確定應用程序對于特定問題和異常而不是標準的參數集的反應。
下面我來談我的最后一項策略。
支持市場工作
在當今這個業務驅動的動態的環境中，充分理解軟件市場的情況是項目成功的關鍵。實際上，一個組織對于市場的理解程度甚至比交流溝通、項目計劃、質量以及測試更能影響它的成功。如果其產品未滿足市場的需求或者定位于錯誤的消費群，那么即便是良好組織的、和諧的軟件開發組織也會遭遇失敗。
那么如何使得那些從事工程技術的人員同從事市場營銷的人員來共同合作，從而提高產品取得成功的機會呢？下面就是一些建議。
驅動beta程序和消費者參考信息
對于軟件團隊來說，最有效的有助于營銷一件新產品的方法就是從早期的客戶那里獲得積極的參考信息，并且通過他們這個組織的市場營銷渠道來共享這些信息。不論您的營銷人員具有多么熟練的技巧或者創造能力，他們都不可能在一夜之間收集到成功的經歷。讓消費者自己來熟悉新工具及其如何使用是需要一定的時間的。因此，為新項目制訂計劃應當將相當大量的時間和資源投入到早期的采用程序上。
在項目的開端階段，應當安排由市場營銷團隊、一些有代表性的人員，以及一位來自于您的目標客戶群的消費者共同參加的關于新產品特性及其他一些需求的討論。同那些提出要在您的產品中增加需求的關鍵的消費者建立聯系，拿出一份測試版本程序的計劃和時限，并且確保該計劃包括了用戶提到的需求并將其作為目標。通過事先交流和溝通這些需求信息，有助于您為程序設定一個正確的期望值，并且提高產品同時廠合拍的機會。通常，消費者必須通過一系列合法性檢查和許可之后才能提供出一些有助于您突出新的解決方案的優勢的參考信息。
早期協作
還有一個好主意，那就是在項目中盡早開始同市場營銷機構的合作，因為營銷人員可以幫助您得到一些創建有效用例的必要信息。由于經常同那些對當前市場心中有數的分析師打交道，他們可以幫助您確定目標客戶群和市場。同時，您為功能特性和產品發布確定目標所作的工作將產生出精心準備的文檔，這些文檔能夠幫助營銷機構較早的理解產品，并且使其能夠描述和促進產品的正確性。關鍵詞就是合作。
聚集一個合作的項目團隊來幫助其中的每一位成員理解那些事情需要去完成是一項非常好的措施。除了上面所提到的收集市場信息之外，協同工作的團隊還應當做下列事情：
認清關鍵的主辦者并使他們在開發計劃階段能夠聚在一起（復審目標，業務目標以及用例所描述的特定細節）。這些主辦者可以是外部的投資者，潛在的消費者，或者甚至是您組織中的某一個團隊。
獲得那些關于客戶支持的要求信息，包括他們的專業水平和進行培訓的需要。
從銷售團隊那里獲得渴望實現應用的日期，關鍵用戶以及主要關注點等信息。
收集陳述和介紹的材料來介紹本組織的其他部分介紹給該項目，從而他們可以開始一同參加工作。協作的團隊成員應當在整個項目周期中夜以繼日的加速實現項目的目標、計劃和活動，從而他們能夠繼續培養和教育感興趣的參與者。
“談論”市場營銷
“談論”市場營銷就是指如何通過媒體傳遞技術性的功能。有時針對目標客戶群的營銷努力是非常技術性的，但是在更多的情況下，這樣的努力由一些根本沒有技術基礎的業務決策者來執行。幫助您的營銷機構將特性細節轉換成有意思的信息以提供給一位非技術人員的顧客的最好的方法就是，充分理解該新產品所帶來的好處和價值，并且準備好將其通俗的表達出來，例如以美元的數額。
準備好為下列問題提供清楚地答案：
“為什么這個新產品或者增強版本很重要？”
“它是如何在我們的業務策略中對關鍵的開端提供支持的？”
“誰將從這項新性能中獲益？”
“該產品如何工作？”
根據我的經驗，即使是最復雜的技水性解決方案都可以通過一種相對簡單的方式來加以解釋，這種方式概括了解決方案及其好處后面的動機。挑戰在于如何找到一個使得您的用戶中的大多數人都能夠理解的模型。
總結
面對全球化所帶來的復雜的業務和技術要求，當今的組織不得不關注非技術性的和技術性的資源，才能夠創造出成功的產品并且在激烈的市場競爭中占有一席之地。盡管沒有所謂的“銀彈”來保護您的軟件開發組織在項目開發期間免受可能出現的挑戰，但是認清楚您的組織內部不同開發部門和功能之間同步的重要性，將會為您在今后的發展中所遇到的每一次挑戰做出更好的準備。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
