摘 要：如今，商務類軟件因其便捷易操作的特性，在各大行業(yè)領域中廣泛使用。因其特殊用途，保證其正確運行成為軟件開發(fā)的重中之重。結合作者在軟件開發(fā)測試領域的研究經驗，對該類軟件測試的流程進行簡要分析。

關鍵詞：軟件測試流程；科學；缺陷報告；基本測試方法

中圖分類號：TP311

眾所周知，目前主流的軟件開發(fā)模式大致可以分為原型開發(fā)模型、流水模式（瀑布模型）、螺旋模型三種。其中，螺旋模型已被證實是目前開發(fā)軟件的最有效手段，是測試人員最喜愛的測試模型。然而，因目前國內測試人員缺口較大，大部分公司依舊采用傳統的瀑布模型或原型開發(fā)模型進行軟件開發(fā)，使得測試工作時間十分緊湊。測試員如何在短時間內檢測出軟件存在的問題，成為一個完整的軟件開發(fā)的重中之重。本文從計劃測試工作、制定測試用例、實際測試、報告缺陷四個方面來分析軟件測試周期。

首先，我們來明確一下軟件缺陷的五種判定依據：（1）軟件未達到產品說明書標明的功能。（2）軟件出現了產品說明書致命不會出現的錯誤。（3）軟件功能超出產品說明書指明范圍。（4）軟件未達到產品說明書雖未指出但應達到的目標。（5）軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好?；谝陨吓卸ㄒ罁?，我們開始進行測試流程分析。

1 計劃測試工作

測試同編程一樣，不可能毫無根據的進行。計劃測試過程的最終目標是交流軟件測試團隊人員的意圖、期望，以及對即將要執(zhí)行的任務的理解。在計劃過程中，首先要明確測試的目標與內容，統一缺陷描述語句。其次，通過明確分配團隊人員的責任與任務來制定測試策略，建立良好的團隊依賴性。再次，編寫測試用例并執(zhí)行測試工作。最后，報告軟件缺陷并檢查缺陷修復情況。

2 制定測試用例

測試用例的編寫是作為軟件測試員最重要的任務之一。不正確的測試用例可能導致測試量過大或者過小，甚至測錯目標。在編寫測試用例時，首先要明確測試計劃的目標并規(guī)劃測試的范圍。目標必須絕對，以避免說不清軟件是否能夠達到目標需求。規(guī)劃測試范圍時，要確認無需測試的內容，以防重復測試，節(jié)約測試時間。確定無需測試內容時，需要明確理由，以防由于誤解使某一部分在測試過程中漏掉，產生重大缺陷。

接下來，介紹幾個容易在測試規(guī)劃中易遺漏的測試部分。首先是硬件配置測試。比如打印機。商務類軟件對打印機的使用要比其它類的軟件更為頻繁，然而，許多商務類軟件的測試用例執(zhí)行書中，常常忽略對打印機打印的測試，這可能使得用戶在使用過程中產生不滿（可能會出現無法打印或者軟件硬件不兼容的情況）。其次，測試軟件的兼容性。商務軟件可能需要大量的數據導入導出操作。數據導入導出文本格式以及對Windows Office或WPS各版本的文本兼容性也是測試的重點之一。再次，以使用者的角度測試軟件界面的易用性。比如，“回車鍵”的使用。許多人習慣以回車鍵代替確認按鈕。測試用例編寫人員在基于說明文檔編寫測試報告時，也應當從使用者的角度注意部分特殊按鍵對軟件功能的影響。

3 進行實際測試

3.1 靜態(tài)黑盒測試，是基于產品說明書進行的高級審查（即在代碼編寫前進行的測試，后簡稱審查），在軟件開發(fā)的初期進行。因其能以最快的速度將軟件缺陷的數量降至最低、損失降至最少，是軟件測試最重要的環(huán)節(jié)。如果時間充裕，應首先保證審查的執(zhí)行。

審查時，主要注意以下五點：（1）注意產品說明書的用語。比如，當文中出現絕對一類的詞語時，測試人員應當開始考慮針鋒相對的案列進行分析；當文中出現等等、諸如此類、依此類推這種讓人迷惑的詞語時，我們也可以將其視為缺陷。（2）注意產品說明書是否具有完整性、準確性、精確性、一致性、合理性、代碼無關性，并且功能描述是否貼切、可測試。（3）注意定義產品開發(fā)設計界面與代碼以及產品用語（術語）的標準和規(guī)范。（4）注意了解客戶，從用戶角度審查產品說明書是否合理。（5）注意了解其他同類軟件。正所謂“知己知彼，百戰(zhàn)不殆”。在了解其它同類軟件的同時，有助于制定測試條件以及測試方法，甚至可以發(fā)現無法想到的潛在缺陷。

3.2 動態(tài)黑盒測試，在業(yè)內也被戲稱為“閉著眼睛測試軟件”，因為在測試過程中測試員不知道程序如何工作，只是按照用例說明標注的操作步驟進行行為操作，因此，動態(tài)黑盒測試也被稱為“行為測試”。在執(zhí)行測試用例時，首先要進行通過測試，確定產品在普通情況下能正確運行并實現需求說明書中的基本功能。在確定軟件可以正常運行之后，采取各種手段以搞垮軟件為目的進行破壞性測試。

3.3 靜態(tài)白盒測試，也稱為結構分析，是在不執(zhí)行軟件的情況下審查軟件設計、體系結構和代碼，首要目的是盡早發(fā)現動態(tài)黑盒測試難以遇到的軟件缺陷。審查的目標是要查找出出錯的代碼以及遺漏的項目。審查時要注意編碼是否符合編碼標準和規(guī)范；注意數據是否存在聲明、引用、計算、比較等方面的錯誤；注意軟件是否有錯誤處理相關代碼，注釋是否齊全，是否考慮兼容性等方面。

3.4 動態(tài)白盒測試，即在軟件執(zhí)行的情況下檢查代碼并觀察其運行狀況。主要由四個部分組成：檢查API，從頂層起完整的測試軟件，通過訪問權限強制軟件以非正常方式運行，估算“命中”代碼并查缺補漏。動態(tài)白盒測試通過提供關于測試對象“內部”的信息，大幅的減輕測試工作，消除冗余的測試案例，增加測試案例的針對性，是一種非常強大的測試方法。

4 報告軟件缺陷

4.1 缺陷報告的基本原則。（1）盡快報告軟件缺陷。越早發(fā)現軟件缺陷，修復的時間越多，越能減少因軟件缺陷造成的損失。（2）有效的描述軟件缺陷。語言盡量簡短明確，便于查看；缺陷報告盡量單一、詳細；步驟描述盡量通俗易懂，易分離可再現。（3）報告缺陷時不夾雜個人感情。在進行軟件測試時，測試員常常會與開發(fā)人員產生沖突，在兩方人員相互對立的情況下開展的測試活動整個對項目的進行會產生惡劣的影響，甚至導致項目的失敗。因此在提交缺陷時要求測試員不夾雜個人感情、客觀的報告缺陷。（4）及時補充和完善缺陷報告。良好的測試員善于發(fā)現并記錄軟件缺陷，優(yōu)秀的測試員在發(fā)現和記錄大量軟件缺陷之后，會繼續(xù)跟蹤其后續(xù)修復過程，以保證缺陷被完全修復。

4.2 分離和再現軟件缺陷。要想有效的報告缺陷，就要以明顯易用和再現的形式報告它，必要時可以使用windows自帶的問題記錄器或通過錄音錄像等方式提交Bug步驟說明。

我們可以通過以下幾種方法分離軟件的缺陷：（1）通過考慮軟件缺陷出現的時間點，內存及網絡的使用狀況，查找時間依賴和競爭條件產生的缺陷。（2）查看缺陷的產生是否與內存泄露或數據溢出等邊界條件相關。（3）查找特定狀態(tài)。在本人進行的軟件測試中，曾有一次系統崩潰在連續(xù)打開不同界面后突然返回某一主控制界面導致整個操作系統的數據庫被清空。（4）考慮硬件問題。主板松動，內存損壞，硬盤壞道，CPU溫度過高，硬件型號都有可能是導致軟件缺陷產生的原因。

5 結束語

軟件缺陷的報告是在軟件測試周期中的最后一步。從表面上來看，報告軟件缺陷似乎是測試周期中的最簡單一步。然而實際上，這一步有可能是測試員最重要甚至是最難完成的一步。由于時間、風險、缺陷報告的有效性等原因有可能導致軟件缺陷無法被修復。一個優(yōu)秀的測試員不僅要有良好的技術能力，也要有良好的語言描述及公關能力，保證缺陷得到修復的機會。

參考文獻：

[1]（美）Rom Patton：Software Testing.

[2]（美）William E.Perry：Effective Methods for Software Testing.

[3]（美）William E.Perry，Randall W.Rice：Surviving the Top Ten Challenge of Software Testing.

作者簡介：孫斯奇（1992.09-），女，遼寧遼陽人，在校生，研究方向：軟件工程。

作者單位：大連交通大學外國語學院，遼寧大連 116052