軟體測試之我見 (轉)

軟體測試之我見 (轉)[@more@]

測試之我見:namespace prefix = o ns = "urn:schemas--com::office" />

我做軟體測試有一段不短的時間了，可大量的盲目測試幾乎沒有增長我的測試，每次測試前總有些茫然，不知道自己怎樣才能有效的發現軟體中存在的缺陷；測試後也不能肯定是否可以放心的釋出被測軟體。我想可能很多初涉測試的工作者都同我有相似的感覺，我們需要有關測試的理論知識的引導，以下是我讀了一些講解測試技術的書籍後的收穫，以及我對我國當前軟體業中測試這一領域的認識，希望也能給測試同行點滴的收益。

一、軟體測試員的目標是儘可能早一些找出軟體缺陷，並確保其得以關閉。

或許大家會認為軟體測試員的工作目標是不言而喻的：就是找軟體缺陷，然而《軟體測試》這本書為軟體測試人員提出了更確切的目標：儘可能早一些找出軟體缺陷，並確保其得以修復。在閱讀全書並仔細思考後，我覺得此目標包含三大點含義：

1．  軟體測試員的基本目標是發現軟體缺陷。

我覺得在這裡有必要把這不言而喻的事實再次強調一下，因為有時產品的開發小組要測試員只是為了證實軟體可以執行，而不是找缺陷。在這種情況下，測試人員也就缺乏不懈努力發現缺陷的探索精神和熱情。所以我覺得在心裡堅信不移的認為：軟體測試員的基本目標是發現軟體缺陷，是做好測試的首要條件。

2．  軟體測試員追求的是儘可能早的找出軟體缺陷。

因為軟體的修復費用，隨著時間的推移，將數十倍的增長，所以軟體測試員應儘可能早的找出軟體缺陷。對大型的軟體，在的同時，就應該有緊隨其後的測試，如果等到產品已經開發完畢才開始測試，非常有可能引起大量耗時費力的返工。而如何儘可能早的找出缺陷？《軟體測試》這本書向我們介紹了一些理論上的測試方法：靜態黑盒測試、動態黑盒測試、靜態白盒測試、動態白盒測試；測試、相容性測試、易用性測試……，怎樣才能有效的用這些方法儘早的發現軟體缺陷，需要大家在工作實踐中不斷的摸索、總結，進而不斷的提高自己的測試能力。

3．  軟體測試人員必需確保找出的軟體缺陷得以關閉。

請注意，我們這裡提的是軟體測試人員必需確保找出的軟體缺陷得以關閉，而不是要軟體缺陷得以修復。我們軟體測試員需要對自己找出的軟體缺陷保持一種平常心：並不是我們辛苦找出的每個軟體缺陷都是必要修復的。可能是由於沒有足夠的時間、不算真正的軟體缺陷、修復的風險太大等原因，產品開發小組決定對一些軟體缺陷不作修復。

另外，測試員對軟體缺陷描述不清楚，也會使軟體測試員發現的缺陷被忽略。所以我們測試員必須在描述軟體缺陷方面狠下功夫：用簡單明瞭的語句描述軟體缺陷；每一件報告儘量針對一個軟體缺陷，避免多個缺陷混雜在一起，以致其中一些被忽略或忘卻；記錄引出軟體缺陷的操作步驟，使缺陷得以再現。

雖然我們軟體測試員需要對自己找出的軟體缺陷保持一種平常心，但同時又必須堅持有始有終的原則，跟蹤每一個軟體缺陷的處理結果，確保軟體缺陷得以關閉。關閉軟體缺陷的前提可以是缺陷得以修復或決定不作修復。而缺陷是否需要修復的最終決定權在軟體的最終負責人，檢查缺陷得以關閉的責任在測試人員。

二、測試一個軟體最首要也是最重要的是測試其產品功能說明書。

²  概念

產品功能說明書：對產品最終需要實現的功能的描述。這些功能是最終確定的需要滿足的客戶需求，也包括是一些軟體必須具備的能力。

在規範的軟體生成的流程中，產品功能說明書應在需求評審會議召開後，進行的概要設計前確定。

²  原因

1．  很多軟體的缺陷都是因為產品功能說明書不夠全面，經常更改造成的；

2．  只有詳細的閱讀了產品功能說明書，確認產品需要實現的功能，才能擬定切實可行的測試方案；

²  方法

1．  參照需求說明書，檢查產品功能說明書描述的產品將要實現的功能是否已經完整、準確、一致、合理的描述了產品的功能，並確保這些功能是可測試的

2．  研究產品說明書是否符合現有的軟體設計開發的標準或規範；

3．  研究同類軟體，預測產品的最終結果；

如果測試人員發現產品說明書不符合以上幾點，該怎麼做？

測試人員需要明白，我們的責任是反映產品的缺陷，我們不需要也不能修正產品，所以同發現軟體的其它缺陷一樣，在發現產品說明書的缺陷後，應該把它們如實並詳細的記錄下來，呈報給此軟體的最終負責人，對並此缺陷的處理情況進行跟蹤。

注意同發現的軟體其它缺陷一樣，缺陷列表應該呈報給軟體的最終負責人，而不是給相關技術人員或技術主管，因為技術人員可能會以在技術的實現上有難度為推託，拒絕對缺陷的修改。

²  目前的可度

1．很多軟體在開發前並沒有書面形式的產品說明書

目前我國的許多軟體公司都是小型的手工作坊式的公司，在開發前都沒有一個正式的、完整的、確定的產品說明書，即便是這種情況，產品說明書也是存在的，它存在在軟體設計人員、專案負責人的腦海裡，在他們心中都有一個軟體的輪廓，假定了軟體將要實現的功能。我們的測試人員可以在同他們的交流和不斷的詢問中獲得這個非正式的產品說明書，值得注意的是在我們得到這些資訊後還需要以書面的形式把它們一一列舉出來，再向相關人員請教，最後做到能完整、準確、一致、合理的描述了產品的功能。

2．測試人員一般不會在專案初期就參與專案

當前還存在著這樣一種問題，公司一般不會讓軟體測試人員在專案的初期就參與專案，一般要等到軟體的雛形出來後才會讓軟體測試人員著手進行測試。對這種情況，測試人員可以透過已經建立的軟體的雛形，揣摩產品說明書，然後也是同上段所說一樣，向相關人員請教，擬定一份書面的完整的、準確的、一致的、合理的產品說說明書。值得注意的是，測試人員在執行軟體的雛形時，往往會發現一些軟體缺陷，這時千萬不要侷限在這些缺陷上耗費經歷，以致忘了擬定產品說明書的主要任務，一定要記住：測試一個軟體最首要也是最重要的是測試其產品說明書，在產品說明書明確後，再製定具體的測試案例。

以上兩點是指在公司體系不太正規的情況下給測試員的建議，但我認為要能更好的保證軟體的質量，或許規範生成軟體的整個運作流程更為有效：產品說明書由專案負責人來主持定版比較好，因為他把握著產品發展的方向；在產品說明書定版時的會議應請負責測試的人參加，使他們對產品有一個宏觀的認識，我也不贊成測試人員過早的侷限於某一專案，如果那樣他們會覺得無所事事。

三、完全測試軟體是絕不可能的，必須對測試的各項進行等價劃分。

²  概念

等價分配：軟體有無限的測試案例，我們要想辦法把軟體的相似輸入、輸出、操作分成一組，來使無限的測試案例減小到同樣有效的小範圍，這個過程稱為等價分配。

邊界條件：軟體計劃的操作界限所在的邊緣條件，即如果超出這個邊界條件，就可能會引出錯誤。

²  原因

1．  輸入量太大

2．  輸出結果太多

3．  軟體實現途徑太多

4．  軟體說明書沒有客觀標準。從不同的角度看，軟體缺陷的標準不同。

²  方法

1．  資料測試：

1）  確定輸入的邊界條件，對邊界線上的及邊界線兩邊的資料進行測試；

2）  邊界線可能是2的乘方，預設值、空白值、零值等；每一個軟體測試問題各不相同，可能包含格式各樣邊界的不同資料。

2．  狀態測試（軟體的狀態是指軟體當前所處的情況或者）

1）  每種狀態至少訪問一次；

2）  測試看起來最常見最普遍的狀態轉換；

3）  測試狀態之間最不常用的分支；

4）  測試所有錯誤狀態及其返回值；

5）  測試隨機狀態轉換。

²  目前的可執行度

如果為了減少測試案例的數量過度進行等價分配，測試漏掉軟體缺陷的風險就會增加。對初涉軟體測試者，一定要請經驗豐富的測試員審查預定的等價類別。