基于PB環境下的軟件測試[2]

　　基于PB環境下的軟件測試[2]  軟件測試

　　單元測試的測試計劃由單元的開發者(也是該單元的測試者)編制，但在測試計劃執行前必須進行審查。這些審查由開發者以外的人進行，第一遍審查由開發者的直接上司去做，其目的在于找出測試計劃中的錯誤、缺點和疏漏之處。第二遍審查由測試該單元所屬系統的測試人員進行，其目的在于確認測試計劃符合公布的標準。如果測試計劃在任何方面有問題，都將被立即退回到開發者手中。

　　3)進行單元測試的時間：在客戶機/服務器的開發過程中，單元測試是測試的第一步。經驗表明，單元測試執行得越快，它的結果就越有價值，在開發周期中錯誤發現得越早，糾正它們所花的代價就越小。一般來講，單元編碼完成后，就對其進行單元測試。另外，單元測試可以并行進行。對于彼此獨立的單元，進行并行測試可以加速測試的進程。

　　4)單元測試階段的測試類型

　　在單元測試階段一般采用白盒測試法。深入到代碼層去充分地測試它們是必要的。在這一階段，必須進行的測試有：路徑測試、聲明測試、循環測試、邊值測試、接口測試、數據確認、事務測試等。

　　5)單元測試的特殊考慮

　　在PB環境下，開發的軟件是以窗口為主線將軟件的功能聯系起來，軟件系統表現為各種各樣的窗口，因此，對窗口中各控件的各事件的描述的測試是這類軟件測試的中心。

　　a.控件的測試：一個空間可以看成是由相關聯的一組事件的描述組成的，完成一個相對獨立的功能。對每一個事件的Script分別進行測試就完成了對一個控件的測試。與傳統的軟件相比，PB開發的軟件風格表現在各事件獨立存在，因此對它的測試相對容易。一般來講，先按設計的規格說明對其代碼進行審核;然后，用白盒法對其進行測試，可以達到較好的效果。

　　b.窗口的測試：宏觀上看，很像是集成測試。其實，所謂單元測試和集成測試也都是相對而言的，在有些情況下不易分得很清楚。在單元測試階段，對窗口的測試主要是測試窗口上各控件是否能按設計要求正常工作。在軟件開發過程中，制定了一系列的標準文件，包括設計文檔標準，界面標準，測試大綱等。對窗口和控件的測試過程中，界面標準和測試大綱是測試的依據。

　　(2)集成測試

　　在將所有的單元經過測試以后，接著進行集成測試。集成測試也稱綜合測試，即將已分別通過測試的單元按要求組合起來再進行的測試，以檢查這些單元之間的接口是否存在問題。

　　1)人員安排：綜合測試既要求參與的人熟悉單元的內部細節，又要求他們能夠從足夠高的層次上觀察整個系統。一般由有經驗的測試人員和主要的軟件開發者來完成集成測試的計劃。

　　2)測試計劃：集成測試計劃由系統設計人員在設計階段制定，它是和設計規格說明同時完成的。在這份計劃里主要包含的內容有：測試的描述和范圍、測試環境、時間表、集成次序、測試用例、測試的預期結果、測試的實際結果等。

　　3)測試內容：在經過了單元測試后，需要將所有單元集成到一起，組成一個完整的軟件系統。需重點測試：各單元的接口是否吻合、代碼是否符合規定的標準、界面標準是否同一等。

　　4)集成策略：在PB環境下開發的軟件系統進行測試按自底向上集成的方式比較自然。這種方法是將底層的單元分組集成測試，然后再逐步向上將軟件集成起來，直到最后所有的單元都在一個組中。測試可按下列步驟進行：

　　a.將最底層的窗口分組，原則是將那些與上層某個窗口相關聯的窗口為一組。

原文轉自：http://www.anti-gravitydesign.com