驗收測試的測試內(nèi)容
通?？梢园ǎ喊惭b（升級）、啟動與關(guān)機、功能測試（正例、重要算法、邊界、時序、反例、錯誤處理）、性能測試（正常的負載、容量變化）、壓力測試（臨界的負載、容量變化）、配置測試、平臺測試、安全性測試、恢復(fù)測試（在出現(xiàn)掉電、硬件故障或切換、網(wǎng)絡(luò)故障等情況時，系統(tǒng)是否能夠正常運行）、可靠性測試等。
性能測試和壓力測試一般情況下是在一起進行，通常還需要輔助工具的支持。在進行性能測試和壓力測試時，測試范圍必須限定在那些使用頻度高的和時間要求苛刻的軟件功能子集中。由于開發(fā)方已經(jīng)事先進行過性能測試和壓力測試，因此可以直接使用開發(fā)方的輔助工具。也可以通過購買或自己開發(fā)來獲得輔助工具。具體的測試方法可以參考相關(guān)的軟件工程書籍。如果執(zhí)行了所有的測試案例、測試程序或腳本，用戶驗收測試中發(fā)現(xiàn)的所有軟件問題都已解決，而且所有的軟件配置均已更新和審核，可以反映出軟件在用戶驗收測試中所發(fā)生的變化，用戶驗收測試就完成了。
驗收測試指的是什么
驗收測試
驗收測試是將系統(tǒng)作為單一的實體進行測試，測試內(nèi)容與系統(tǒng)測試基本相同，但是驗收測試是在用戶參與下進行的，它的目的是由用戶來測試軟件能否滿足用戶的需求。
模塊與程序的調(diào)試，主要采用白盒法，而在子系統(tǒng)測試、系統(tǒng)測試過程中主要采用黑盒法。
軟件測試主要學(xué)什么，在南京有沒有？
軟件測試的分類
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分
A.白盒測試
B.黑盒測試
C.灰盒測試
從是否執(zhí)行程序的角度
A.靜態(tài)測試
B.動態(tài)測試。
從軟件開發(fā)的過程按階段劃分有
A.單元測試
B.集成測試
C.確認測試
D.系統(tǒng)測試
E.驗收測試
* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。
* 開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。
* 集成測試把已測試過的模塊組裝起來，主要對與設(shè)計相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。
* 確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位 — 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
* 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內(nèi)容
* 在單元測試時，測試者需要依據(jù)詳細設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。
(1) 模塊接口測試
* 在單元測試的開始，應(yīng)對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：
– 調(diào)用本模塊的輸入?yún)?shù)是否正確；
– 本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確；
– 全局量的定義在各模塊中是否一致；
* 在做內(nèi)外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區(qū)容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結(jié)束文件處理時是否關(guān)閉了文件；
– 正文書寫／輸入錯誤，
– I／O錯誤是否檢查并做了處理。
(2) 局部數(shù)據(jù)結(jié)構(gòu)測試
* 不正確或不一致的數(shù)據(jù)類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數(shù)據(jù)類型
* 全局數(shù)據(jù)對模塊的影響
(3) 路徑測試
* 選擇適當(dāng)?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。
* 應(yīng)當(dāng)設(shè)計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導(dǎo)致的錯誤。
* 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠?qū)﹀e誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等
(5) 邊界測試
* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
– 驅(qū)動模塊 (driver)
– 樁模塊 (stub) —— 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。
* 對支持某些標(biāo)準(zhǔn)規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。
集成測試（ Testing）
* 集成測試 (集成測試、聯(lián)合測試）
* 通常，在單元測試的基礎(chǔ)上，需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮的問題是：
– 在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；
– 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；
– 各個子功能組合起來，能否達到預(yù)期要求的父功能；
– 全局數(shù)據(jù)結(jié)構(gòu)是否有問題；
– 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng)。
* 子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
* 通常，把模塊集成成為系統(tǒng)的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
* 在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結(jié)構(gòu)的*層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。
* 一般來講，一種方式的優(yōu)點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新算法模塊進行測試;
– 再自底向上組裝成為功能相當(dāng)完整且相對獨立的子系統(tǒng);
– 然后由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試;
– 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
* 回歸測試
– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統(tǒng)，再自底向上測試。
關(guān)鍵模塊問題
* 在組裝測試時，應(yīng)當(dāng)確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進行測試。
* 關(guān)鍵模塊的特征：
① 滿足某些軟件需求；
② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；
③ 較復(fù)雜、較易發(fā)生錯誤；
④ 有明確定義的性能要求。
確認測試（ Testing）
* 確認測試又稱有效性測試。任務(wù)是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎(chǔ)。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
* 首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預(yù)定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復(fù)、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：
– 測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
– 測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。
2. 軟件配置復(fù)查
n 軟件配置復(fù)查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求；
u 具有維護階段所必需的細節(jié)；
u 而且已經(jīng)編排好分類的目錄。
n 應(yīng)當(dāng)嚴(yán)格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（ Testing）
* 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應(yīng)開始系統(tǒng)的驗收測試。
* 驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加。
* 由用戶參加設(shè)計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
* 在測試過程中，除了考慮軟件的功能和性能外，還應(yīng)對軟件的可移植性、兼容性、可維護性、錯誤的恢復(fù)功能等進行確認。
* 確認測試應(yīng)交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發(fā)總結(jié)報告。
系統(tǒng)測試（System Testing）
* 系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
* 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
驗收測試的相關(guān)標(biāo)準(zhǔn)
通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的*一步——驗收測試即可開始。驗收測試應(yīng)檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標(biāo)準(zhǔn)。 事實上，軟件開發(fā)人員不可能完全預(yù)見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應(yīng)由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導(dǎo)致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，用來發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。 α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為α版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關(guān)鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡*努力涵蓋所有可能的 用戶操作方式。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進行改錯和完善。 一般包括功能度、安全可靠性、易用性、可擴充性、兼容性、效率、資源占用率、用戶文檔八個方面。
現(xiàn)場驗收測試
現(xiàn)場驗收測試（SAT）可以幫助我們確認系統(tǒng)是否達到我們期望或者是我們需要的水準(zhǔn)。SAT的主要目的是給系統(tǒng)的整體合規(guī)性做一個全局性的評價，來保證系統(tǒng)能夠滿足商務(wù)需求。在優(yōu)化系統(tǒng)結(jié)果的相關(guān)關(guān)鍵性指標(biāo)中，SAT也很有用。
SAT與工程驗收測試有關(guān)，他們通過對系統(tǒng)該組件的檢查和動態(tài)測試來達到目的?？蛻糇约鹤珜慡AT方案，用來驗證設(shè)備的功能，并且*是在現(xiàn)場測試。測試結(jié)果基本上就是達到要求，未達到要求，或者是超出預(yù)期。
FAT（工廠驗收測試）也用了一樣的原則，更關(guān)注用戶需求是否得到滿足。它由客戶和客戶代表執(zhí)行。它們既考慮了制造商又考慮了用戶，就像它們的標(biāo)題一樣，在工廠/制造地進行測試。
在生物技術(shù)，制藥和藥學(xué)行業(yè)，這類測試屬于共識。SAT文件需要定期完成，來保證系統(tǒng)符合GMP要求。沒有SAT嘗試，我們很難保證設(shè)備的合規(guī)性。
關(guān)鍵的一點在于SAT能保證制藥的生產(chǎn)和制造工序都能滿足要求法律協(xié)議所希望的保密標(biāo)準(zhǔn)。
SAT是效率測試，更是質(zhì)量測試。它上達高級管理處和責(zé)任員工來保證不同*的系統(tǒng)軟件水平的追蹤。通過SAT，我們可以保證質(zhì)量，保證良好的生產(chǎn)規(guī)范，安全的質(zhì)量風(fēng)險管理和有效的質(zhì)量控制檢測。
在給SAT的測試結(jié)果配備適當(dāng)人員之前，所有的結(jié)果都需要監(jiān)控和記錄。SAT還必須跨越場地、設(shè)施和設(shè)備進行轉(zhuǎn)移，因此需要允許進行跨國界測試。
很多因素都會影響SAT的成功，包括：完成目視檢查，主要部件目視檢查，內(nèi)部箱壓和通風(fēng)設(shè)備檢查，要檢查的公共設(shè)施功能，要檢查的與功能相關(guān)的聯(lián)鎖裝置，分配系統(tǒng)的熱測試，校準(zhǔn)器驗證，安全裝置檢查和操作人員培訓(xùn)和能力的測試。
SAT非常重要，他可以驗證系統(tǒng)是否足夠勝任工作，以及能否安全達標(biāo)，從而保證操作者的安全。FAT保證制造者的安全，所以兩種測試都非常重要。
問題可能造成損失和傷害，我們可以在發(fā)生之前進行糾正，從而讓項目正常運行，從而保證財務(wù)正常。SAT并不只用于制藥業(yè)，他們可以廣泛用于各個領(lǐng)域中，甚至是交通信號系統(tǒng)。通過SAT，用戶可以知道系統(tǒng)是正常工作的。
