關鍵字：PB 測試
隨著軟件工程技術的發展，軟件設計規模的增大，軟件測試在軟件開發過程中的作用顯得尤為重要。目前，軟件測試技術的研究領域雖然取得了一些成果，但對具體的開發環境下開發的特定領域的軟件系統應采用怎樣的測試方法對其進行全面的、完整的測試，仍沒有具體的標準可以遵循。 網絡技術和數據庫技術的飛速發展，使管理信息系統（MIS）向客戶機/服務器（Client/Server或C/S）或B/C（Browser/Server）加SQL Server（或Sybase、Oracle）模式發展。開發工具也大多不再是面向過程的語言，而是使用諸如PB（Power Builder）的Script等具有面向對象特征的腳本語言。開發環境的改變及應用的日趨復雜使MIS的開發方法也正在從傳統的結構化方法向面向對象的方法轉變。因此，對基于PB等環境下的軟件測試技術及方法的研究，不僅具有方法論上的理論意義，而且具有使用價值。
1．PB軟件的特點
利用PB開發中大型的MIS應用系統，一般采用三層C/S的體系結構．在這種結構下，系統可分為兩部分，即后臺數據庫部分和前臺應用程序部分，后臺采用非面向對象的關系數據庫管理系統RDBMS（如SQL Server等）實現對應用數據的組織，安全性、完整性維護，以及存取控制；前臺應用程序部分利用PB提供的可視化編程技術實現用戶的各種需求。其特點表現在，利用PB提供的窗口、菜單及數據窗口等對象很方便地實現友好的用戶界面，系統的各種功能以窗口對象為主線，利用PB 提供的Script語言，通過對窗口的各控件的事件描述來實現。與傳統的面向過程的語言相比較，PB支持面向對象的程序設計方法，其用戶界面的元素都是對象，所以都有屬性、事件和方法，具有繼承、封裝和重用等面向對象的特性。
2．測試目標
無論傳統的系統，還是基于PB的C/S系統，測試的目標都是確保所開發軟件的功能符合用戶的要求。具體表現在以下幾個方面：
(1)確保系統達到需求功能的說明；
(2)確保系統滿足性能需求；
(3)強度測試確認程序能夠處理要求的負載；
(4)確保系統在要求的硬件和軟件平臺上工作正常。
3．測試方法
原則上講，可以將軟件測試方法分為兩大類，即靜態測試和動態測試。靜態測試是對被測程序進行特性分析的一些方法的總稱，這種方法的主要特性是不利用計算機運行被測試的程序，而是采用其他手段達到檢測的目的。動態測試是實際運行被測程序，輸入相應的測試用例，判定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性。動態測試的兩種主要的方法是黑盒測試和白盒測試。
4．測試過程
測試雖然是軟件生存周期的一個獨立階段，但測試工作卻滲透到從分析、設計直到編程的各個階段中，如測試計劃的編寫從分析和設計階段就開始了，而具體的測試工作隨編程工作的不斷深入也在進行中。在實際工作中，測試環節可分為明顯的、同等重要的三個階段：即單元測試、集成測試（又稱構件測試）和系統測試。測試工作中的第四個階段是驗收測試階段，驗收測試無論在規模上或性質上都和系統測試很相似，它們的根本區別在于：前者是內部的，而后者則是受“客戶”控制的。
(1)單元測試
軟件單元定義了一個軟件很底層的塊，用PB開發的客戶機/服務器的軟件系統中，一個窗口、函數、菜單、報表或一個存儲過程都可以作為一個單元進行測試。單元測試是測試的第一步。
1)人員安排：對于一個完整的軟件單元，沒有人比它的開發者更熟悉它，因此，開發者自己對其進行測試是最合適的。
2)單元測試計劃：測試計劃必須在單元測試之前被設計和記錄好。大量的文檔說明必須足夠詳細，以備當單元開發者調離、提升或其他原因離開其崗位時，其他人員也能對相應的單元進行測試。此外，在集成測試和系統測試階段，清晰、詳細、易于理解的單元測試文檔對于測試者也將發揮巨大作用。
單元測試的測試計劃由單元的開發者（也是該單元的測試者）編制，但在測試計劃執行前必須進行審查。這些審查由開發者以外的人進行，第一遍審查由開發者的直接上司去做，其目的在于找出測試計劃中的錯誤、缺點和疏漏之處。第二遍審查由測試該單元所屬系統的測試人員進行，其目的在于確認測試計劃符合公布的標準。如果測試計劃在任何方面有問題，都將被立即退回到開發者手中。
3)進行單元測試的時間
在客戶機/服務器的開發過程中，單元測試是測試的第一步。經驗表明，單元測試執行得越快，它的結果就越有價值，在開發周期中錯誤發現得越早，糾正它們所花的代價就越小。一般來講，單元編碼完成后，就對其進行單元測試。另外，單元測試可以并行進行。對于彼此獨立的單元，進行并行測試可以加速測試的進程。
4)單元測試階段的測試類型
在單元測試階段一般采用白盒測試法。深入到代碼層去充分地測試它們是必要的。在這一階段，必須進行的測試有：路徑測試、聲明測試、循環測試、邊值測試、接口測試、數據確認、事務測試等。
5)單元測試的特殊考慮
在PB環境下，開發的軟件是以窗口為主線將軟件的功能聯系起來，軟件系統表現為各種各樣的窗口，因此，對窗口中各控件的各事件的描述的測試是這類軟件測試的中心。
a.控件的測試：一個空間可以看成是由相關聯的一組事件的描述組成的，完成一個相對獨立的功能。對每一個事件的Script分別進行測試就完成了對一個控件的測試。與傳統的軟件相比，PB開發的軟件風格表現在各事件獨立存在，因此對它的測試相對容易。一般來講，先按設計的規格說明對其代碼進行審核；然后，用白盒法對其進行測試，可以達到較好的效果。
b.窗口的測試：宏觀上看，很像是集成測試。其實，所謂單元測試和集成測試也都是相對而言的，在有些情況下不易分得很清楚。在單元測試階段，對窗口的測試主要是測試窗口上各控件是否能按設計要求正常工作。在軟件開發過程中，制定了一系列的標準文件，包括設計文檔標準，界面標準，測試大綱等。對窗口和控件的測試過程中，界面標準和測試大綱是測試的依據。
(2)集成測試
在將所有的單元經過測試以后，接著進行集成測試。集成測試也稱綜合測試，即將已分別通過測試的單元按要求組合起來再進行的測試，以檢查這些單元之間的接口是否存在問題。
1)人員安排：綜合測試既要求參與的人熟悉單元的內部細節，又要求他們能夠從足夠高的層次上觀察整個系統。一般由有經驗的測試人員和主要的軟件開發者來完成集成測試的計劃。
2)測試計劃：集成測試計劃由系統設計人員在設計階段制定，它是和設計規格說明同時完成的。在這份計劃里主要包含的內容有：測試的描述和范圍、測試環境、時間表、集成次序、測試用例、測試的預期結果、測試的實際結果等。
3)測試內容：在經過了單元測試后，需要將所有單元集成到一起，組成一個完整的軟件系統。需重點測試：各單元的接口是否吻合、代碼是否符合規定的標準、界面標準是否同一等。
4)集成策略：在PB環境下開發的軟件系統進行測試按自底向上集成的方式比較自然。這種方法是將底層的單元分組集成測試，然后再逐步向上將軟件集成起來，直到最后所有的單元都在一個組中。測試可按下列步驟進行：
a.將最底層的窗口分組，原則是將那些與上層某個窗口相關聯的窗口為一組。
b.對每一組分別進行測試，各組測試可并行展開，這樣可以加快測試的進程。
c.沿軟件的結構，逐級向上集成，直到所有的單元都組合到一起，這樣就完成了集成測試的任務。
5)測試方法：集成測試階段是以黑盒法為主，在自底向上集成的早期，白盒法測試占一定的比例，隨著集成測試的不斷深入，這種比例在測試過程中將越來越少，漸漸地，黑盒法測試占據主導地位。
(3)系統測試
從技術角度看，系統測試是整個測試階段的最后一步，所有的開發和測試在這一點上集中表現為生成一個具有一定功能的軟件系統。該階段主要對系統的準確性及完整性等方面進行測試。主要進行：功能確認測試、運行測試、強度測試、恢復測試、安全性測試等。系統測試的測試人員由測試組成員（或質量保證人員）或測試組成員與用戶共同測試。在整個系統開發完成，即將交付用戶使用前進行。在這一階段，完全采用黑盒法對整個系統進行測試。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/