請問..
Test Strategy 與 Test Plan 分別是在什麼時候制訂？
所決定的事情有什麼差異呢？

謝謝^^

測試計畫：描述預劃進行測試的範圍、方法、資源與時程的文件。該項文件指定測試項目、將予測試之特徵、測試工作、由誰執行測試、以及需訂定應變計畫的風險事項。(IEEE Std 610.12)

測試策略：與將要執行或完成的某事項相應的方法或規劃，或是規劃的過程。

因此，我們可以知道，Test Plan 與 Test Strategy 基本上是相同的，但是策略會是比較原則性的事項或要求。

籌獲者在提出RFP時，可以就驗收測試的期望訂定驗收策略，然後納入RFP中，請投標商提出建議。

在軟體生命週期中，軟體的測試計畫要考慮籌獲者的驗收(測試)策略、開發者的測試策略，配合系統分析、系統架構設計、軟體需求分析、軟體設計的作業去訂定測試計畫書，在測試計畫中也將會述及相關的測試策略。

長久以來，軟體測試文件的撰寫一直是資訊軟體開發專案的重大挑戰。

本會自九十二年起開辦「如何撰寫軟體測試文件」課程以來，頗獲各界的好評，為因應各界的需要，本會將於 4/8(星期六) 再舉辦一場次，講授如何做好測試規劃、如何撰寫測試計畫與報告，並將介紹測試的程序與方法、測試準則、測試個案設計、文件範例 … 等，請把握機會報名參加 !

軟體品質協會秘書處 敬上

我是去年94年度最後一期的"軟體測試"學員(已結業),
我可以報名上4/8的課嗎?講師是那位?

4/8“如何撰寫測試文件”課程的主要目標是希望讓參加的學員，充分了解在一個軟體開發專案中，有關“測試”的過程應該產生那些文件，這些文件應該包含那些內容。

為了顧及學員來自各方，在背景上可能有的差異，首先我會對軟體、生命週期計畫以及與測試有關的一些基本觀念做一簡單的說明。

接下來，才會進入主題測試文件的介紹。這部份是以IEEE-829為主軸，包括：測試計畫、測試設計規格、測試個案、測試程序、測試項目移轉報告、測試日誌、測試事件報告與測試綜合報告。

最後，以實務中遇到的一些問題與實例，作為這項課程的總結。

至於您是否適合報名的問題，您還是要問問自己，前面所說的這些內容您是否都已了解? 您是否能夠撰寫合乎標準的測試文件? 如果答案都是肯定的，我想您就不必浪費金錢與時間了。否則的話，我認為您應該可以從這個課程中，得到一些對您有用的東西。

軟體品質協會資深管理師 周茂松

請問資訊系統進行測試及驗收時，需要實測多少「測試個案」才足夠 ?

何謂「測試涵蓋率」?

當系統經過測試，逐一修正每個錯誤程式並且完成單元測試後，最後「測試個案」還需要全部重做一次嗎 ?

請問何謂「迴歸測試」?

以上敬請賜教，3Q !

第一個問題：資訊系統進行測試及驗收時，需要實測多少「測試個案」才足夠 ?
這個問題本身並不是問得很貼切，比較正確的問法應該是這樣的：測試及驗收時測試工作要做到多完整？當然，很直覺的說法是要百分之一百的完成。那麼問題來了，這個百分之百的分母與分子各為何？這個問題的答案是依資訊系統種類、大小、複雜度與健全度等級以及甲方的要求不同而不同的。以測試的行話來說就是涵蓋率。

那麼什麼是「測試涵蓋率」? 測試涵蓋率是一個有關測試活動完整性的量測制(metrics)，它是回答“ 測試活動到底完成了多少？”這問題的一種簡易方式。一般以需求為基準或程式碼為基準兩種方式來計算。以需求為基準的測試涵蓋率就是以需求個數為分母，用已通過測試的需求為分子所計算出來的一個百分比。以程程碼為基礎的測試涵蓋率就是以通過測試的程式碼數量除全部的程式碼數量所算出來的一個百分比數字。

關於第三個問題，我把它拆成兩部份來說明。一、基本上資訊系統的測試活動有三層：單元測試、整合測試與系統測試(這是乙方做的)，各個測試有自己的測試個案，也可共用部份相同的測試個案。這三層測試活動完成後，才進行驗收測試(這是甲方做的)，驗收測試的測試個案通常為系統測試的(必要時也可包括另外二種)測試個案的子集，當然也可以是全部的系統測試個案，至於用那一種方式則由合約來約定。 二、當系統經過測試，逐一修正每個錯誤程式後，最後「測試個案」還需要全部重做一次嗎 ? 正規而言，已通過測試的測試個案，在程式經過修改後(不論是因為除錯或變更而修改)，都必須重新測試。這樣的測試就是廻歸測試。

歡迎您來參加我下週六(4/8)即將講授的「如何撰寫測試文件?」課程。

軟體品質協會資深管理師 周茂松 敬上

您好,

想請問如果公司成立一個測試團隊,專門負責SIT&UAT的測試(不含UT),可能會遇到的第一個問題是,如何驗證<開發>團隊遞交給<測試>團隊的程式是已做完UT的?

另外一個問題是,<測試>團隊在寫測試個案時,往往寫的測試個案會與UT個案有重覆,如果不做,又好像沒有測試完全,如果都做,<測試>團隊等於UT也幫忙做了,到底身為<測試>團隊的人最好如何界定測試的範圍?

謝謝!!

先回答第一個問題，如何驗證<開發>團隊遞交給<測試>團隊的程式已經做完單元測試？方式之一是：<開發>團隊在做單元測試時，一樣要留下客觀的書面證據。方式之二是：要客觀衡量的數據。也就是要有公司政策訂定或歷史的數據。於完成單元測試交付<測試>團隊後，程式碼的缺陷密度(Defect density)(bug 數/KLOC)要低於多少，當測試團隊於測試中發現某個測試項目的缺陷密度高於此數字時，不論是否做過單元測試，都退回給<開發>團隊重新執行單元測試並除錯。個人認為這就是為什麼CMMI要將“度量與分析”流程領域放在Level 2而“驗證”、“確認”放在Level 3的原因。

第二個問題，在文字上看起來有些許的模糊，我把它重新定義為：測試團隊如何界定其自身的測試工作範圍？(如果不是原意請包涵)要回答這個問題，先要了解測試基本上分為三個層級，即單元測試、整合測試與系統測試。測試團隊理應為整個軟體測試工作負起全部的責任。但是，在執行上可將單元測試委託給<開發>團隊去設計、執行，甚或單元測試的規劃工作也可委由他們來做。除此之外，其它的測試工作都要由測試團隊來處理。當然，這只是眾多方式中的一種。您可以依據貴公司的組織政策、文化與專案的特性而做不同的考量與安排。

軟體品質協會專案管理師 周茂松 敬上

請問什麼是[迴歸測試] ? 如何進行 ?

請問[迴歸測試]和系統的建構管理有相關性嗎 ?

請賜教，謝謝 !