|
|
回歸測試的價值在於它是一個能夠檢測到回歸錯誤的受控實驗。當測試組選擇縮減的回歸測試時，有可能刪除了將揭示回歸錯誤的測試用例，消除了發現回歸錯誤的機會。然而，如果采用了代碼相依性分析等安全的縮減技術，就可以决定哪些測試用例可以被刪除而不會讓回歸測試的意圖遭到破壞。
選擇回歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式包括：
1再測試全部用例：
選擇基綫測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，隨着開發工作的進展，測試用例不斷增多，重複原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度。
2基於風險選擇測試 ：
可以基於一定的風險標準來從基綫測試用例庫中選擇回歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級別低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特徵到次要特徵
3基於操作剖面選擇測試 ：
如果基綫測試用例庫的測試用例是基於軟件操作剖面開發的，測試用例的分佈情況反映了係統的實際使用情況。回歸測試所使用的測試用例個數可以由測試預算確定，回歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助於盡早發現那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高係統可靠性，但實施起來有一定的難度。
4再測試修改的部分：
當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況並分析修改的影響，將回歸測試局限於被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。
再測試全部用例的策略是最安全的策略，但已經運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由於時間、人員、設備和經費的原因，不允許選擇再測試全部用例的回歸測試策略，此時，可以選擇適當的策略進行縮減的回歸測試。
回歸測試的條件：
·本輪測試中測試用例中有95%一次性通過測試,結束測試任務；
·本輪測試中發現的錯誤有98%經過修改並且通過再次測試（即bug狀態closed），測試人員重新開始新的一輪測試，即為回歸測試； |
|
軟件回歸測試及其實踐
本文描述了軟件回歸測試的概念和進行回歸測試的基本步驟，介紹了可用於回歸測試的測試用例庫的維護方法，給出了幾種可以可保證回歸測試效率和有效性的回歸測試策略，總結了回歸測試時應該註意的一些實際問題。
一、 概述
在軟件生命周期中的任何一個階段，衹要軟件發生了改變，就可能給該軟件帶來問題。軟件的改變可能是源於發現了錯誤並做了修改，也有可能是因為在集成或維護階段加入了新的模塊。當軟件中所含錯誤被發現時，如果錯誤跟蹤與管理係統不夠完善，就可能會遺漏對這些錯誤的修改；而開發者對錯誤理解的不夠透徹，也可能導致所做的修改衹修正了錯誤的外在表現，而沒有修復錯誤本身，從而造成修改失敗；修改還有可能産生副作用從而導致軟件未被修改的部分産生新的問題，使本來工作正常的功能産生錯誤。同樣，在有新代碼加入軟件的時候，除了新加入的代碼中有可能含有錯誤外，新代碼還有可能對原有的代碼帶來影響。因此，每當軟件發生變化時，我們就必須重新測試現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否損害了原有的正常功能。同時，還需要補充新的測試用例來測試新的或被修改了的功能。為了驗證修改的正確性及其影響就需要進行回歸測試。
回歸測試在軟件生命周期中扮演着重要的角色，因忽視回歸測試而造成嚴重後果的例子不計其數，導致阿裏亞娜5型火箭發射失敗的軟件缺陷就是由於復用的代碼沒有經過充分的回歸測試造成的。
回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發的各個階段都會進行多次回歸測試。在漸進和快速迭代開發中，新版本的連續發佈使回歸測試進行的更加頻繁，而在極端編程方法中，更是要求每天都進行若幹次回歸測試。因此，通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是非常有意義的。
二、 回歸測試策略
對於一個軟件開發項目來說，項目的測試組在實施測試的過程中會將所開發的測試用例保存到“測試用例庫”中，並對其進行維護和管理。當得到一個軟件的基綫版本時，用於基綫版本測試的所有測試用例就形成了基綫測試用例庫。在需要進行回歸測試的時候，就可以根據所選擇的回歸測試策略，從基綫測試用例庫中提取合適的測試用例組成回歸測試包，通過運行回歸測試包來實現回歸測試。保存在基綫測試用例庫中的測試用例可能是自動測試腳本，也有可能是測試用例的手工實現過程。
回歸測試需要時間、經費和人力來計劃、實施和管理。為了在給定的預算和進度下，盡可能有效率和有效力地進行回歸測試，需要對測試用例庫進行維護並依據一定的策略選擇相應的回歸測試包。
1、測試用例庫的維護
為了最大限度地滿足客戶的需要和適應應用的要求，軟件在其生命周期中會頻繁地被修改和不斷推出新的版本，修改後的或者新版本的軟件會添加一些新的功能或者在軟件功能上産生某些變化。隨着軟件的改變，軟件的功能和應用接口以及軟件的實現發生了演變，測試用例庫中的一些測試用例可能會失去針對性和有效性，而另一些測試用例可能會變得過時，還有一些測試用例將完全不能運行。為了保證測試用例庫中測試用例的有效性，必須對測試用例庫進行維護。同時，被修改的或新增添的軟件功能，僅僅靠重新運行以前的測試用例並不足以揭示其中的問題，有必要追加新的測試用例來測試這些新的功能或特徵。因此，測試用例庫的維護工作還應包括開發新測試用例，這些新的測試用例用來測試軟件的新特徵或者覆蓋現有測試用例無法覆蓋的軟件功能或特徵。
測試用例的維護是一個不間斷的過程，通常可以將軟件開發的基綫作為基準，維護的主要內容包括下述幾個方面。
(1)、刪除過時的測試用例
因為需求的改變等原因可能會使一個基綫測試用例不再適合被測試係統，這些測試用例就會過時。例如，某個變量的界限發生了改變，原來針對邊界值的測試就無法完成對新邊界測試。所以，在軟件的每次修改後都應進行相應的過時測試用例的刪除。
(2)、改進不受控製的測試用例
隨着軟件項目的進展，測試用例庫中的用例會不斷增加，其中會出現一些對輸入或運行狀態十分敏感的測試用例。這些測試不容易重複且結果難以控製，會影響回歸測試的效率，需要進行改進，使其達到可重複和可控製的要求。
(3)、刪除冗餘的測試用例
如果存在兩個或者更多個測試用例針對一組相同的輸入和輸出進行測試，那麽這些測試用例是冗餘的。冗餘測試用例的存在降低了回歸測試的效率。所以需要定期的整理測試用例庫，並將冗餘的用例刪除掉。
(4)、增添新的測試用例
如果某個程序段、構件或關鍵的接口在現有的測試中沒有被測試，那麽應該開發新測試用例重新對其進行測試。並將新開發的測試用例合併到基綫測試包中。
通過對測試用例庫的維護不僅改善了測試用例的可用性，而且也提高了測試庫的可信性，同時還可以將一個基綫測試用例庫的效率和效用保持在一個較高的級別上。
2、回歸測試包的選擇
在軟件生命周期中，即使一個得到良好維護的測試用例庫也可能變得相當大，這使每次回歸測試都重新運行完整的測試包變得不切實際。一個完全的回歸測試包括每個基綫測試用例，時間和成本約束可能阻礙運行這樣一個測試，有時測試組不得不選擇一個縮減的回歸測試包來完成回歸測試。
回歸測試的價值在於它是一個能夠檢測到回歸錯誤的受控實驗。當測試組選擇縮減的回歸測試時，有可能刪除了將揭示回歸錯誤的測試用例，消除了發現回歸錯誤的機會。然而，如果采用了代碼相依性分析等安全的縮減技術，就可以决定哪些測試用例可以被刪除而不會讓回歸測試的意圖遭到破壞。
選擇回歸測試策略應該兼顧效率和有效性兩個方面。常用的選擇回歸測試的方式包括：
(1)、再測試全部用例
選擇基綫測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，隨着開發工作的進展，測試用例不斷增多，重複原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度。
(2)、基於風險選擇測試
可以基於一定的風險標準來從基綫測試用例庫中選擇回歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級別低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特徵到次要特徵。
(3)、基於操作剖面選擇測試
如果基綫測試用例庫的測試用例是基於軟件操作剖面開發的，測試用例的分佈情況反映了係統的實際使用情況。回歸測試所使用的測試用例個數可以由測試預算確定，回歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助於盡早發現那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高係統可靠性，但實施起來有一定的難度。
(4)、再測試修改的部分
當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況並分析修改的影響，將回歸測試局限於被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。
再測試全部用例的策略是最安全的策略，但已經運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由於時間、人員、設備和經費的原因，不允許選擇再測試全部用例的回歸測試策略，此時，可以選擇適當的策略進行縮減的回歸測試。
3、回歸測試的基本過程
有了測試用例庫的維護方法和回歸測試包的選擇策略，回歸測試可遵循下述基本過程進行:
(1). 識別出軟件中被修改的部分；
(2). 從原基綫測試用例庫T中，排除所有不再適用的測試用例，確定那些對新的軟件版本依然有效的測試用例，其結果是建立一個新的基綫測試用例庫T0。
(3). 依據一定的策略從T0中選擇測試用例測試被修改的軟件。
(4). 如果必要，生成新的測試用例集T1，用於測試T0無法充分測試的軟件部分。
(5). 用T1執行修改後的軟件。
第(2)和第(3)步測試驗證修改是否破壞了現有的功能，第(4)和第(5)步測試驗證 修改工作本身。
三、 回歸測試實踐
在實際工作中，回歸測試需要反復進行，當測試者一次又一次地完成相同的測試時，這些回歸測試將變得非常令人厭煩，而在大多數回歸測試需要手工完成的時候尤其如此，因此，需要通過自動測試來實現重複的和一致的回歸測試。通過測試自動化可以提高回歸測試效率。為了支持多種回歸測試策略，自動測試工具應該是通用的和靈活的，以便滿足達到不同回歸測試目標的要求。
在測試軟件時，應用多種測試技術是常見的。當測試一個修改了的軟件時，測試者也可能希望采用多於一種回歸測試策略來增加對修改軟件的信心。不同的測試者可能會依據自己的經驗和判斷選擇不同的回歸測試技術和策略。
回歸測試並不減少對係統新功能和特徵的測試需求，回歸測試包應包括新功能和特徵的測試。如果回歸測試包不能達到所需的覆蓋要求，必須補充新的測試用例使覆蓋率達到規定的要求。
回歸測試是重複性較多的活動，容易使測試者感到疲勞和厭倦，降低測試效率，在實際工作中可以采用一些策略減輕這些問題。例如，安排新的測試者完成手工回歸測試，分配更有經驗的測試者開發新的測試用例，編寫和調試自動測試腳本，做一些探索性的或ad hoc測試。還可以在不影響測試目標的情況下，鼓勵測試者創造性地執行測試用例，變化的輸入、按鍵和配置能夠有助於激勵測試者又能揭示新的錯誤。
在組織回歸測試時需要註意兩點，首先是各測試階段發生的修改一定要在本測試階段內完成回歸，以免將錯誤遺留到下一測試階段。其次，回歸測試期間應對該軟件版本凍結，將回歸測試發現的問題集中修改，集中回歸。
在實際工作中，可以將回歸測試與兼容性測試結合起來進行。在新的配置條件下運行舊的測試可以發現兼容性問題，而同時也可以揭示編碼在回歸方面的錯誤。
回歸測試的概述
驗收測試是部署軟件之前的最後一個測試操作。驗收測試的目的是確保軟件準備就緒，並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是嚮未來的用戶表明係統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟件係統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
通過綜合測試之後，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最後一步——驗收測試即可開始。驗收測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。
1.驗收測試標準 實現軟件確認要通過一係列墨盒測試。驗收測試同樣需要製訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無是計劃還是過程，都應該着重考慮軟件是否滿足合同規定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。 驗收測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段纔發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協商，尋求一個妥善解决問題的方法。
2.配置復審 驗收測試的另一個重要環節是配置復審。復審的目的在於保證軟件配置齊全、分類有序，並且包括軟件維護所必須的細節。
3.α、β測試 事實上，軟件開發人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數據組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一係列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有係統的測試。有時，驗收測試長達數周甚至數月，不斷暴露錯誤，導致開發延期。一個軟件産品，可能擁有衆多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎衹有最終用戶才能發現的問題。 α測試是指軟件開發公司組織內部人員模擬各類用戶行對即將面市軟件産品（稱為α版本）進行測試，試圖發現錯誤並修正。α測試的關鍵在於盡可能逼真地模擬實際運行環境和用戶對軟件産品的操作並盡最大努力涵蓋所有可能的 用戶操作方式。經過α測試調整的軟件産品稱為β版本。緊隨其後的β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本，並要求用戶報告異常情況、提出批評意見。然後軟件開發公司再對β版本進行改錯和完善。 一般包括功能度、安全可靠性、易用性、可擴充性、兼容性、效率、資源占用率、用戶文檔八個方面。
一、施驗收測試的常用策略
施驗收測試的常用策略有三種，它們分別是：
• 正式驗收
• 非正式驗收或 Alpha 測試
• Beta 測試
您選擇的策略通常建立在合同需求、組織和公司標準以及應用領域的基礎上。
正式驗收測試
正式驗收測試是一項管理嚴格的過程，它通常是係統測試的延續。計劃和設計這些測試的周密和詳細程度不亞於係統測試。選擇的測試用例應該是係統測試中所執行測試用例的子集。不要偏離所選擇的測試用例方向，這一點很重要。在很多組織中，正式驗收測試是完全自動執行的。
對於係統測試，活動和工件是一樣的。在某些組織中，開發組織（或其獨立的測試小組）與最終用戶組織的代表一起執行驗收測試。在其他組織中，驗收測試則完全由最終用戶組織執行，或者由最終用戶組織選擇人員組成一個客觀公正的小組來執行。
這種測試形式的優點是：
• 要測試的功能和特性都是已知的。
• 測試的細節是已知的並且可以對其進行評測。
• 這種測試可以自動執行，支持回歸測試。
• 可以對測試過程進行評測和監測。
• 可接受性標準是已知的。
缺點包括：
• 要求大量的資源和計劃。
• 這些測試可能是係統測試的再次實施。
• 可能無法發現軟件中由於主觀原因造成的缺陷，這是因為您衹查找預期要發現的缺陷。
非正式驗收測試
在非正式驗收測試中，執行測試過程的限定不象正式驗收測試中那樣嚴格。在此測試中，確定並記錄要研究的功能和業務任務，但沒有可以遵循的特定測試用例。測試內容由各測試員决定。這種驗收測試方法不象正式驗收測試那樣組織有序，而且更為主觀。
大多數情況下，非正式驗收測試是由最終用戶組織執行的。
這種測試形式的優點是：
• 要測試的功能和特性都是已知的。
• 可以對測試過程進行評測和監測。
• 可接受性標準是已知的。
• 與正式驗收測試相比，可以發現更多由於主觀原因造成的缺陷。
缺點包括：
• 要求資源、計劃和管理資源。
• 無法控製所使用的測試用例。
• 最終用戶可能沿用係統工作的方式，並可能無法發現缺陷。
• 最終用戶可能專註於比較新係統與遺留係統，而不是專註於查找缺陷。
• 用於驗收測試的資源不受項目的控製，並且可能受到壓縮。
Beta 測試
在以上三種驗收測試策略中，Beta 測試需要的控製是最少的。在 Beta 測試中，采用的細節多少、數據和方法完全由各測試員决定。各測試員負責創建自己的環境、選擇數據，並决定要研究的功能、特性或任務。各測試員負責確定自己對於係統當前狀態的接受標準。
Beta 測試由最終用戶實施，通常開發（或其他非最終用戶）組織對其的管理很少或不進行管理。Beta 測試是所有驗收測試策略中最主觀的。
這種測試形式的優點是：
• 測試由最終用戶實施。
• 大量的潛在測試資源。
• 提高客戶對參與人員的滿意程度。
• 與正式或非正式驗收測試相比，可以發現更多由於主觀原因造成的缺陷。
缺點包括：
• 未對所有功能和/或特性進行測試。
• 測試流程難以評測。
• 最終用戶可能沿用係統工作的方式，並可能沒有發現或沒有報告缺陷。
• 最終用戶可能專註於比較新係統與遺留係統，而不是專註於查找缺陷。
• 用於驗收測試的資源不受項目的控製，並且可能受到壓縮。
• 可接受性標準是未知的。
• 您需要更多輔助性資源來管理 Beta 測試員。
二、驗收測試過程
1. 軟件需求分析：瞭解軟件功能和性能要求、軟硬件環境要求等，並特別要瞭解軟件的質量要求和驗收要求。
2. 編製《驗收測試計劃》和《項目驗收準則》：根據軟件需求和驗收要求編製測試計劃，製定需測試的測試項，製定測試策略及驗收通過準則，並經過客戶參與的計劃評審。
3. 測試設計和測試用例設計：根據《驗收測試計劃》和《項目驗收準則》編製測試用例，並經過評審。
4. 測試環境搭建：建立測試的硬件環境、軟件環境等。（可在委托客戶提供的環境中進行測試）
5. 測試實施：測試並記錄測試結果。
6. 測試結果分析：根據驗收通過準則分析測試結果，作出驗收是否通過及測試評價。
7. 測試報告：根據測試結果編製缺陷報告和驗收測試報告，並提交給客戶。
三、驗收測試的總體思路
用戶驗收測試是軟件開發結束後，用戶對軟件産品投入實際應用以前進行的最後一次質量檢驗活動。它要回答開發的軟件産品是否符合預期的各項要求，以及用戶能否接受的問題。由於它不衹是檢驗軟件某個方面的質量，而是要進行全面的質量檢驗，並且要决定軟件是否合格，因此驗收測試是一項嚴格的正式測試活動。需要根據事先製訂的計劃，進行軟件配置評審、功能測試、性能測試等多方面檢測。
用戶驗收測試可以分為兩個大的部分：軟件配置審核和可執行程序測試，其大致順序可分為：文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核、可執行程序測試。
要註意的是，在開發方將軟件提交用戶方進行驗收測試之前，必須保證開發方本身已經對軟件的各方面進行了足夠的正式測試（當然，這裏的“足夠”，本身是很難準確定量的）。
用戶在按照合同接收並清點開發方的提交物時（包括以前已經提交的），要查看開發方提供的各種審核報告和測試報告內容是否齊全，再加上平時對開發方工作情況的瞭解，基本可以初步判斷開發方是否已經進行了足夠的正式測試。
用戶驗收測試的每一個相對獨立的部分，都應該有目標（本步驟的目的）、啓動標準（着手本步驟必須滿足的條件）、活動（構成本步驟的具體活動）、完成標準（完成本步驟要滿足的條件）和度量（應該收集的産品與過程數據）。在實際驗收測試過程中，收集度量數據，不是一件容易的事情。
軟件配置審核
對於一個外包的軟件項目而言，軟件承包方通常要提供如下相關的軟件配置內容：
●可執行程序、源程序、配置腳本、測試程序或腳本。
●主要的開發類文檔：《需求分析說明書》、《概要設計說明書》、《詳細設計說明書》、《數據庫設計說明書》、《測試計劃》、《測試報告》、《程序維護手册》、《程序員開發手册》、《用戶操作手册》、《項目總結報告》。
●主要的管理類文檔：《項目計劃書》、《質量控製計劃》、《配置管理計劃》、《用戶培訓計劃》、《質量總結報告》、《評審報告》、《會議記錄》、《開發進度月報》。
在開發類文檔中，容易被忽視的文檔有《程序維護手册》和《程序員開發手册》。
《程序維護手册》的主要內容包括：係統說明（包括程序說明）、操作環境、維護過程、源代碼清單等，編寫目的是為將來的維護、修改和再次開發工作提供有用的技術信息。
《程序員開發手册》的主要內容包括：係統目標、開發環境使用說明、測試環境使用說明、編碼規範及相應的流程等，實際上就是程序員的培訓手册。
不同大小的項目，都必須具備上述的文檔內容，衹是可以根據實際情況進行重新組織。
對上述的提交物，最好在合同中規定階段提交的時機，以免發生糾紛。
通常，正式的審核過程分為5個步驟：計劃、預備會議（可選）、準備階段、審核會議和問題追蹤。預備會議是對審核內容進行介紹並討論。準備階段就是各責任人事先審核並記錄發現的問題。審核會議是最終確定工作産品中包含的錯誤和缺陷。
審核要達到的基本目標是：根據共同製定的審核表，盡可能地發現被審核內容中存在的問題，並最終得到解决。在根據相應的審核表進行文檔審核和源代碼審核時，還要註意文檔與源代碼的一致性。
在實際的驗收測試執行過程中，常常會發現文檔審核是最難的工作，一方面由於市場需求等方面的壓力使這項工作常常被弱化或推遲，造成持續時間變長，加大文檔審核的難度；另一方面，文檔審核中不易把握的地方非常多，每個項目都有一些特別的地方，而且也很難找到可用的參考資料。
可執行程序的測試
在文檔審核、源代碼審核、配置腳本審核、測試程序或腳本審核都順利完成，就可以進行驗收測試的最後一個步驟——可執行程序的測試，它包括功能、性能等方面的測試，每種測試也都包括目標、啓動標準、活動、完成標準和度量等五部分。
要註意的是不能直接使用開發方提供的可執行程序用於測試，而要按照開發方提供的編譯步驟，從源代碼重新生成可執行程序。
在真正進行用戶驗收測試之前一般應該已經完成了以下工作（也可以根據實際情況有選擇地采用或增加）：
●軟件開發已經完成，並全部解决了已知的軟件缺陷。
●驗收測試計劃已經過評審並批準，並且置於文檔控製之下。
●對軟件需求說明書的審查已經完成。
●對概要設計、詳細設計的審查已經完成。
●對所有關鍵模塊的代碼審查已經完成。
●對單元、集成、係統測試計劃和報告的審查已經完成。
●所有的測試腳本已完成，並至少執行過一次，且通過評審。
●使用配置管理工具且代碼置於配置控製之下。
●軟件問題處理流程已經就緒。
●已經製定、評審並批準驗收測試完成標準。
具體的測試內容通常可以包括：安裝（升級）、啓動與關機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復測試（在出現掉電、硬件故障或切換、網絡故障等情況時，係統是否能夠正常運行）、可靠性測試等。
性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試範圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由於開發方已經事先進行過性能測試和壓力測試，因此可以直接使用開發方的輔助工具。也可以通過購買或自己開發來獲得輔助工具。具體的測試方法可以參考相關的軟件工程書籍。
如果執行了所有的測試案例、測試程序或腳本，用戶驗收測試中發現的所有軟件問題都已解决，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發生的變化，用戶驗收測試就完成了。
四、測試報告形式
《驗收測試報告》
《缺陷報告》
《驗收測試計劃》中規定的其他文檔
五、驗收測試工作流程說明和註意事項
驗收測試業務洽談
雙方就測試項目及合同進行洽談
簽訂測試合同
委托方提交測試樣品及相關資料
委托方需提交的文檔有：
•基本文檔：（驗收測試必需的文檔）
用戶手册
安裝手册維護手册
軟件樣品（可刻錄在光盤）
•特殊文檔：（根據測試內容不同，委托方所需提交下列相應的文檔）
軟件産品開發過程中的測試記錄
軟件産品源代碼。
編製測試計劃並通過評審
進行項目相關知識培訓
測試設計
評測中心編製測試方案和設計測試用例集。
方案評審
評測中心測試組成員、委托方代表一起對測試方案進行評審。
實施測試
評測中心對測試方案進行整改，並實施測試。在測試過程中每日提交測試事件報告給委托方。
編製驗收測試報告並組織評審
評測中心編製驗收測試報告，並組織內部評審。
提交驗收測試報告
評測中心提交驗收測試報告。 |
|
|
|
|