測試管理的若干建議[1] 軟件測試
下面是可以提高軟件測試管理的一般建議。
盡早開始測試管理活動
雖然這一點看起來像最顯而易見的建議,但是很少軟件項目真正地應用這一觀念。在早期開始確定測試資源很容易而且很常見,但是許多測試分析(如識別關鍵的、優先的測試用例)可以而且應該盡快開始。一旦用例被充分開發產生事件流,就可以得到測試程序。如果一個項目沒有使用用例需求,那么仍可以從確認初始需求說明中得到測試。盡快開發測試能幫助減輕未來不可避免的時間限制。
迭代化測試
軟件測試應該是一個反復的過程,在整個項目周期的早期生成有價值的測試工件和工作。這是遵循盡早開始測試流程的首要建議:一個迭代的測試流程應該很早就關注測試管理。測試管理通過組織迭代的各類工件和資源來指導這一點。這個基于風險的方法有助于確保以最有效的方式處理項目時間線里可能出現的變更、延遲和其他一些不可預見的障礙。
重用測試工件
在一個項目或多個項目里重用測試工件能夠極大地提高測試團隊的有效性。這樣可以極大地緩解時間和資源有限造成的壓力?梢灾赜玫墓ぜ粌H包括自動操作測試對象,還包括測試程序和其他的計劃信息。為了有效地重用工件,測試管理必須在組織和描述給定項目的與測試相關的各種信息方面做得很好。在創建工件時,重用總是需要一些預先計劃,而且這一原則通?梢詰糜跍y試管理。
使用基于需求的測試
測試可以被分成兩種常用的方法:
確認事情按照計劃進行
盡力找出什么使得事情停止下來
雖然后面的探索性測試對于發現導致錯誤的難以預測的場景或情形來說非常重要,但是確認基本的需求可能是測試團隊執行的最重要的評估。
基于需求的測試是確認一個應用軟件或系統的主要方式,它既適用于傳統需求也適用于用例需求;谛枨蟮臏y試往往沒有探索性測試那么主觀,它也可以帶來其他的益處。軟件開發團隊的其他部分可能質疑或者譴責探索性測試的結果,但是他們不能懷疑直接確認需求的測試。另一個好處是它可以更容易地計算所需的測試工作(與探索性測試相反,它總是受限于可以利用的時間)。
它也可以提供各類統計數據,他們可能是有用的度量,例如測試覆蓋率。測試用例是由需求產生的,并且隨著事情變化對其關系的跟蹤也更為重要,這是一件復雜的工作,應該通過工具進行處理。RequisitePro 和 ClearQuest 中的測試管理能力提供了滿足這一需求的結果方案。
這一流程的局限性是它信賴于一個好的系統需求和一個十分有效的合理的需求管理計劃。從另一方面來說,探索性測試可能更加特殊。它很少依賴軟件開發團隊的其他部分,這有時會導致測試工作很少被關注在確認需求的重要任務上。雖然較好的測試工作應該將不同的方法集成起來,但是不應該忽視基于需求的測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/