測試流程培訓

測試流程培訓第1頁，共59頁，2023年，2月20日，星期日第

1章

軟件工程與軟件測試1.1軟件工程1.2軟件質(zhì)量1.3軟件測試1.4軟件測試人員的基本素質(zhì)第2頁，共59頁，2023年，2月20日，星期日嚴格地說，軟件工程是應用計算機科學、數(shù)學及管理科學等原理開發(fā)軟件的工程。通俗地說，軟件工程是實現(xiàn)一個大型程序的一套原則方法，即按工程化的原則和方法組織軟件開發(fā)工作。軟件測試是軟件工程的一個重要環(huán)節(jié)，相當于工程領域中的質(zhì)量檢驗部分，是確保軟件工程質(zhì)量的重要手段。第3頁，共59頁，2023年，2月20日，星期日1.1軟件工程1.1.1

軟件工程的目標及其一般開發(fā)過程一個軟件產(chǎn)品從形成概念開始，經(jīng)過開發(fā)、使用和維護，直到最后退出使用的全過程稱為軟件生存周期。軟件生存周期根據(jù)軟件所處的狀態(tài)，以及軟件開發(fā)活動的目的和任務，可劃分為若干個階段。一般軟件生存周期包括軟件定義、軟件開發(fā)以及軟件使用與維護3個部分。第4頁，共59頁，2023年，2月20日，星期日1．軟件定義可行性分析的任務是了解用戶的要求及實現(xiàn)環(huán)境，從技術、經(jīng)濟和社會等幾個方面研究并論證軟件系統(tǒng)的可行性。需求分析的任務是確定所要開發(fā)軟件的功能需求、性能需求和運行環(huán)境約束，編制軟件需求規(guī)格說明、軟件系統(tǒng)的確認測試準則。軟件的性能需求包括軟件的適應性、安全性、可靠性、可維護性錯誤處理等。第5頁，共59頁，2023年，2月20日，星期日2．軟件開發(fā)軟件開發(fā)是按照需求規(guī)格說明的要求，由抽象到具體，逐步生成軟件的過程。軟件開發(fā)一般由設計、實現(xiàn)和測試等階段組成。第6頁，共59頁，2023年，2月20日，星期日3．軟件使用和維護軟件的使用是在軟件通過測試后，將軟件安裝在用戶確定的運行環(huán)境中移交給用戶使用。軟件的維護是對軟件系統(tǒng)進行修改或?qū)浖枨笞兓龀龇磻倪^程。第7頁，共59頁，2023年，2月20日，星期日1.1.2軟件過程模型軟件開發(fā)過程中存在各種復雜因素，為了解決由此而帶來的種種問題，軟件開發(fā)者們經(jīng)過多年的摸索，給出了多種實現(xiàn)軟件工程的方式——軟件過程模型，如瀑布過程模型、螺旋過程模型和增量過程模型等。第8頁，共59頁，2023年，2月20日，星期日1．瀑布過程模型瀑布過程模型反映了人們早期對軟件工程的認識水平，是人們所熟悉的一種線性思維的體現(xiàn)。瀑布過程模型強調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性，是一種嚴格線性的、按階段順序的、逐步細化的開發(fā)模式，如圖1-1所示。第9頁，共59頁，2023年，2月20日，星期日圖1-1瀑布過程模型第10頁，共59頁，2023年，2月20日，星期日2．螺旋過程模型螺旋過程模型的基本思路是，依據(jù)前一個版本的結果構造新的版本，這個不斷重復迭代的過程形成了一個螺旋上升的路徑，如圖1-2所示。第11頁，共59頁，2023年，2月20日，星期日圖1-2螺旋過程模型第12頁，共59頁，2023年，2月20日，星期日3．增量過程模型有些時候可能會用一種幾乎連續(xù)的過程小幅度地推進項目，這就是增量過程模型，如圖1-3所示。第13頁，共59頁，2023年，2月20日，星期日圖1-3增量過程模型第14頁，共59頁，2023年，2月20日，星期日1.2軟件質(zhì)量軟件質(zhì)量是軟件的生命，它直接影響軟件的使用與維護。通常軟件質(zhì)量由以下幾方面進行評價。第15頁，共59頁，2023年，2月20日，星期日①軟件需求是衡量軟件質(zhì)量的基礎，不符合需求的軟件就不具備質(zhì)量。設計的軟件應在功能、性能等方面都符合要求，并能可靠地運行。②軟件結構良好，易讀、易于理解，并易于修改、維護。③軟件系統(tǒng)具有友好的用戶界面，便于用戶使用。④軟件生存周期中各階段文檔齊全、規(guī)范，便于配置、管理。第16頁，共59頁，2023年，2月20日，星期日1.2.1質(zhì)量與質(zhì)量模型軟件的質(zhì)量因素很多，如正確性、精確性、可靠性、容錯性、性能、效率、易用性、可理解性、簡潔性、可復用性、可擴充性、兼容性等。軟件質(zhì)量因素也稱為軟件質(zhì)量特性，反映了質(zhì)量的本質(zhì)。討論一個軟件的質(zhì)量，問題最終要歸結到定義軟件的質(zhì)量特性。第17頁，共59頁，2023年，2月20日，星期日面對眾多的質(zhì)量因素如何取折衷，這實際上就是區(qū)分質(zhì)量因素對軟件質(zhì)量影響程度輕重的問題，這個問題已經(jīng)有了解決方案，即軟件質(zhì)量模型。圖1-4所示為ISO/IEC9126－1991標準規(guī)定的軟件質(zhì)量度量模型。它由3層組成，其中第1層稱為質(zhì)量特性，第2層稱為質(zhì)量子特性，第3層稱為度量。第18頁，共59頁，2023年，2月20日，星期日圖1-4ISO軟件質(zhì)量度量模型第19頁，共59頁，2023年，2月20日，星期日詳細說明第20頁，共59頁，2023年，2月20日，星期日軟件質(zhì)量評價的目的是為了直接支持開發(fā)并獲得能滿足用戶要求的軟件。最終目標是保證產(chǎn)品能提供所要求的質(zhì)量，即滿足用戶明確的和隱含的要求。軟件產(chǎn)品的一般評價過程是，確定評價需求，然后規(guī)定、設計和執(zhí)行評價，如圖1-5所示。第21頁，共59頁，2023年，2月20日，星期日圖1-5軟件評價過程第22頁，共59頁，2023年，2月20日，星期日1.2.2軟件質(zhì)量保證為了在軟件開發(fā)過程中保證軟件的質(zhì)量，軟件的質(zhì)量保證活動應貫穿整個軟件生存周期的每一個階段。軟件的質(zhì)量保證的措施主要有檢查、評審和測試。如圖1-6所示，軟件質(zhì)量保證的工作從項目一開始就應介入。第23頁，共59頁，2023年，2月20日，星期日圖1-6質(zhì)量保證活動第24頁，共59頁，2023年，2月20日，星期日1.3軟件測試

1.3.1軟件測試的定義及目的簡單地說，軟件測試就是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。第25頁，共59頁，2023年，2月20日，星期日在IEEE提出的軟件工程標準術語中，軟件測試被定義為：“使用人工和自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清楚預期結果與實際結果之間的差別。”軟件測試是與軟件質(zhì)量密切聯(lián)系在一起的，歸根結底，軟件測試是為了保證軟件質(zhì)量。第26頁，共59頁，2023年，2月20日，星期日軟件測試是一個找錯的過程。軟件測試的過程亦是程序運行的過程。程序運行需要數(shù)據(jù)，為測試設計的數(shù)據(jù)稱為測試用例。測試用例的設計原則是盡可能暴露程序中的錯誤。第27頁，共59頁，2023年，2月20日，星期日軟件是由人來完成的，所有由人做的工作都不會是完美無缺的。軟件開發(fā)是個很復雜的過程，期間很容易產(chǎn)生錯誤。無論是軟件從業(yè)人員、專家和學者做了多大的努力，軟件錯誤仍然存在。因而大家也得到了一種共識：軟件中殘存著錯誤，這是軟件的一種屬性，是無法改變的。所以通常說軟件測試的目的就是為了發(fā)現(xiàn)盡可能多的缺陷，并期望通過改錯來把缺陷統(tǒng)統(tǒng)消滅，以期提高軟件的質(zhì)量。一個成功的測試用例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。第28頁，共59頁，2023年，2月20日，星期日軟件測試的目的是以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患所帶來的商業(yè)風險。第29頁，共59頁，2023年，2月20日，星期日1.3.2軟件測試信息流為進一步說明軟件測試的過程，這里給出軟件測試的信息流示意圖，如圖1-8所示。圖1-8軟件測試信息流第30頁，共59頁，2023年，2月20日，星期日1.3.3軟件測試與軟件開發(fā)過程的關系對于軟件測試與軟件開發(fā)過程之間的關系，套用固定的模型不是聰明之舉。比如“程序設計”與“測試”之間的關系，習慣上總以為程序設計在先，測試在后，如圖1-9（a）所示。而對于一些復雜的程序，將測試分為同步測試與總測試更有效，如圖1-9（b）所示。第31頁，共59頁，2023年，2月20日，星期日圖1-9程序設計與測試的關系第32頁，共59頁，2023年，2月20日，星期日現(xiàn)在還有一種全新的軟件開發(fā)模式——以測試驅(qū)動軟件開發(fā)，總的思想是：軟件測試是貫穿于軟件開發(fā)過程的。軟件生存周期的各個階段中都少不了相應的測試，軟件生存周期各個階段的測試分別對應于軟件測試過程中的單元測試、集成測試、系統(tǒng)測試和確認測試，如圖1-10所示。這種對應關系有利于軟件開發(fā)過程的管理和軟件質(zhì)量的控制。第33頁，共59頁，2023年，2月20日，星期日圖1-10軟件測試與軟件開發(fā)的關系第34頁，共59頁，2023年，2月20日，星期日1.3.4軟件測試與質(zhì)量保證的區(qū)別1．質(zhì)量保證質(zhì)量保證（QA）工作通過預防、檢查與改進來保證軟件質(zhì)量。QA采用“全面質(zhì)量管理”和“過程改進”的原理開展質(zhì)量保證工作。第35頁，共59頁，2023年，2月20日，星期日2．軟件測試測試雖然也與開發(fā)過程緊密相關，但關心的不是過程的活動，而是對過程的產(chǎn)物以及開發(fā)出的軟件進行剖析。測試人員要“執(zhí)行”軟件，對過程中的產(chǎn)物——開發(fā)文檔和源代碼進行走查，運行軟件，以找出問題，報告質(zhì)量。測試人員必須假設軟件存在潛在的問題，測試中所做的操作是為了找出更多的問題，而不僅僅是為了驗證每一件事是正確的。第36頁，共59頁，2023年，2月20日，星期日對測試中發(fā)現(xiàn)的問題的分析、追蹤與回歸測試也是軟件測試中的重要工作，因此軟件測試是保證軟件質(zhì)量的一個重要環(huán)節(jié)。軟件質(zhì)量保證活動與軟件測試的關系可用圖1-11說明。第37頁，共59頁，2023年，2月20日，星期日圖1-11軟件質(zhì)量保證活動與測試的關系第38頁，共59頁，2023年，2月20日，星期日1.3.5軟件測試的發(fā)展歷程及趨勢軟件測試是伴隨著軟件的產(chǎn)生而產(chǎn)生的，有了軟件的生成和運行就必然有軟件測試。在早期的軟件開發(fā)過程中，測試的含義比較窄，將測試等同于“調(diào)試”，目的是糾正軟件中已經(jīng)知道的故障，常常由軟件開發(fā)人員自己完成這部分工作。對測試的投入極少，測試介入得也晚，常常是等到形成代碼，產(chǎn)品已經(jīng)基本完成時才進行測試。第39頁，共59頁，2023年，2月20日，星期日直到1957年，軟件測試才開始與調(diào)試區(qū)別開來，成為一種發(fā)現(xiàn)軟件缺陷的活動。直到20世紀80年代早期，“質(zhì)量”的號角才開始吹響。軟件測試的定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程，而且包含軟件質(zhì)量評價的內(nèi)容。軟件開發(fā)人員和測試人員開始坐在一起探討軟件工程和測試問題。制定了各類標準，包括IEEE標準、美國ANSI標準和ISO國際標準。第40頁，共59頁，2023年，2月20日，星期日

20世紀90年代，測試工具終于盛行起來。到了2002年，Rich和Stefan在《系統(tǒng)的軟件測試》一書中對軟件測試做了進一步定義：“測試是為了度量和提高被測軟件的質(zhì)量，對測試軟件進行工程設計、實施和維護的整個生命周期過程”。這些經(jīng)典論著對軟件測試研究的理論化和體系化產(chǎn)生了巨大的影響。第41頁，共59頁，2023年，2月20日，星期日近20年來，隨著計算機和軟件技術的飛速發(fā)展，軟件測試技術的研究也取得了很大的突破，測試專家總結了很好的測試模型，如著名的V模型，在單元測試、自動化測試等方面涌現(xiàn)了大量優(yōu)秀的軟件測試工具。第42頁，共59頁，2023年，2月20日，星期日雖然軟件測試技術的發(fā)展很快，但是其發(fā)展速度仍落后于軟件開發(fā)技術的發(fā)展速度，使得軟件測試在今天面臨著很大的挑戰(zhàn)，主要體現(xiàn)在以下幾個方面。①軟件在國防現(xiàn)代化、社會信息化和國民經(jīng)濟信息化領域中的作用越來越重要，由此產(chǎn)生的測試任務越來越繁重。②軟件規(guī)模越來越大，功能越來越復雜，如何進行充分而有效的測試成為難題。第43頁，共59頁，2023年，2月20日，星期日③面向?qū)ο蟮拈_發(fā)技術越來越普及，但是面向?qū)ο蟮臏y試技術卻剛剛起步。④對分布式系統(tǒng)的整體性能還不能進行很好的測試。⑤對實時系統(tǒng)缺乏有效的測試手段。⑥隨著安全問題的日益突出，對信息系統(tǒng)的安全性如何進行有效的測試與評估，成為世界性難題。第44頁，共59頁，2023年，2月20日，星期日根據(jù)國內(nèi)外軟件測試的發(fā)展現(xiàn)狀，可以看到軟件測試有以下的發(fā)展趨勢。①測試工作將進一步前移。②軟件架構師、開發(fā)工程師、QA人員、測試工程師將進行更好的融合。③測試職業(yè)將得到充分的尊重。第45頁，共59頁，2023年，2月20日，星期日④設置獨立的軟件測試部門將成為越來越多的軟件公司的共識。軟件測試部門將和開發(fā)部、質(zhì)量保證部一樣作為一個重要的獨立部門存在。⑤測試外包服務將快速增長。和軟件開發(fā)外包一樣，軟件測試外包將成為全球化的一種趨勢?？梢岳寐殬I(yè)測試專家隊伍與機構為自己的產(chǎn)品進行測試，而且可以節(jié)省測試費用。第46頁，共59頁，2023年，2月20日，星期日1.4軟件測試人員的基本素質(zhì)軟件測試人員應具備下列基本素質(zhì)。1．具有良好的計算機編程基礎2．具有創(chuàng)新精神和超前意識3．不懈努力，追求完美4．具有整體觀念，對細節(jié)敏感5．團隊合作精神第47頁，共59頁，2023年，2月20日，星期日單元測試

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。例如，你可能把一個很大的值放入一個有序list中去，然后確認該值出現(xiàn)在list的尾部?；蛘撸憧赡軙淖址袆h除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。

單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

工廠在組裝一臺電視機之前，會對每個元件都進行測試，這，就是單元測試。

對于程序員來說，如果養(yǎng)成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質(zhì)量的代碼，而且還能提高編程水平。

要進行充分的單元測試，應專門編寫測試代碼，并與產(chǎn)品代碼隔離。老納認為，比較簡單的辦法是為產(chǎn)品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數(shù)（很簡單的除外）建立測試函數(shù)。首先就幾個概念談談老納的看法。

一般認為，在結構化程序時代，單元測試所說的單元是指函數(shù)，在當今的面向?qū)ο髸r代，單元測試所說的單元是指類。以老納的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數(shù)作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數(shù)。單元測試不應過分強調(diào)面向?qū)ο?，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。

有一種看法是，只測試類的接口(公有函數(shù))，不測試其他函數(shù)，從面向?qū)ο蠼嵌葋砜矗_實有其道理，但是，測試的目的是找錯并最終排錯，因此，只要是包含錯誤的可能性較大的函數(shù)都要測試，跟函數(shù)是否私有沒有關系。對于C++來說，可以用一種簡單的方法區(qū)隔需測試的函數(shù)：簡單的函數(shù)如數(shù)據(jù)讀寫函數(shù)的實現(xiàn)在頭文件中編寫(inline函數(shù))，所有在源文件編寫實現(xiàn)的函數(shù)都要進行測試(構造函數(shù)和析構函數(shù)除外)。

第48頁，共59頁，2023年，2月20日，星期日為什么要使用單元測試

我們編寫代碼時，一定會反復調(diào)試保證它能夠編譯通過。但代碼通過編譯，只是說明了它的語法正確；我們卻無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。什么時候測試？單元測試越早越好，早到什么程度？XP開發(fā)理論講究TDD，即測試驅(qū)動開發(fā)，先編寫測試代碼，再進行開發(fā)。在實際的工作中，可以不必過分強調(diào)先什么后什么，重要的是高效和感覺舒適。從老納的經(jīng)驗來看，先編寫產(chǎn)品函數(shù)的框架，然后編寫測試函數(shù)，針對產(chǎn)品函數(shù)的功能編寫測試用例，然后編寫產(chǎn)品函數(shù)的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產(chǎn)品函數(shù)的框架，是指先編寫函數(shù)空的實現(xiàn)，有返回值的隨便返回一個值，編譯通過后再編寫測試代碼，這時，函數(shù)名、參數(shù)表、返回類型都應該確定下來了，所編寫的測試代碼以后需修改的可能性比較小。

由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經(jīng)過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。

關于樁代碼，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產(chǎn)品函數(shù)或測試函數(shù)調(diào)用了一個未編寫的函數(shù)，可以編寫樁函數(shù)來代替該被調(diào)用的函數(shù)，樁代碼也用于實現(xiàn)測試隔離。采用由底向上的方式進行開發(fā)，底層的代碼先開發(fā)并先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函數(shù)時，也是對下層函數(shù)的間接測試；當下層函數(shù)修改時，通過回歸測試可以確認修改是否導致上層函數(shù)產(chǎn)生錯誤。

單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復的，無論是在軟件修改，或是移植到新的運行環(huán)境的過程中。因此，所有的測試都必須在整個軟件系統(tǒng)的生命周期中進行維護。

經(jīng)常與單元測試聯(lián)系起來的另外一些開發(fā)活動包括代碼走讀(Codereview)，靜態(tài)分析(Staticanalysis)和動態(tài)分析(Dynamicanalysis)。靜態(tài)分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數(shù)據(jù)，并不需要對代碼進行編譯和執(zhí)行。動態(tài)分析就是通過觀察軟件運行時的動作，來提供執(zhí)行跟蹤，時間分析，以及測試覆蓋度方面的信息。

返回

第49頁，共59頁，2023年，2月20日，星期日集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎上，將所有模塊按照設計要求）如根據(jù)結構圖〕組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現(xiàn)。集成測試方法集成測試應該考慮以下問題：1、在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；2、各個子功能組合起來，能否達到預期要求的父功能；3、一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；4、全局數(shù)據(jù)結構是否有問題；5、單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度。因此，單元測試后，有必要進行集成測試，發(fā)現(xiàn)并排除在模塊連接中可能發(fā)生的上述問題，最終構成要求的軟件子系統(tǒng)或系統(tǒng)。對子系統(tǒng)，集成測試也叫部件測試。任何合理地組織集成測試，即選擇什么方式把模塊組裝起來形成一個可運行的系統(tǒng),直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號和測試的次序、生成測試用例和調(diào)試的費用。通常，有兩種不同的組裝方式：一次性組裝方式和增值式組裝方式。第50頁，共59頁，2023年，2月20日，星期日集成測試的實施在制定測試計劃時，應考慮如下因素：

1、是采用何種系統(tǒng)組裝方法來進行組裝測試；

2、組裝測試過程中連接各個模塊的順序；

3、模塊代碼編制和測試進度是否與組裝測試的順序一致

4、測試過程中是否需要專門的硬件設備；解決了上述問題之后，就可以列出各個模塊的編制、測試計劃表，標明每個模塊單元測試完成的日期、首次集成測試的日期、集成測試全部完成的日期、以及需要的測試用例和所期望的測試結果。在缺少軟件測試所需要的硬件設備時，應檢查該硬件的交付日期是否與集成測試計劃一致。例如，若測試需要數(shù)字化儀和繪圖儀，則相應測試應安排在這些設備能夠投入使用之時，并需要為硬件的安裝和交付使用保留一段時間，以留下時間余量。此外，在測試計劃中需要考慮測試所需軟件（驅(qū)動模塊、樁模塊、測試用例生成程序等）的準備情況。集成測試完成標準1、成功地執(zhí)行了測試計劃中規(guī)定的所有集成測試；2、修正了所發(fā)現(xiàn)的錯誤；3、測試結果通過了專門小組的評審。集成測試應由專門的測試小組來進行，測試小組由有經(jīng)驗的系統(tǒng)設計人員和程序員組成。整個測試活動要在評審人員出席的情況下進行。在完成預定的組裝測試工作之后，測試小組應負責對測試結果進行整理、分析，形成測試報告。測試報告中要記錄實際的測試結果、在測試中發(fā)現(xiàn)的問題、解決這些問題的方法以及解決之后再次測試的結果。此外還應提出目前不能解決、還需要管理人員和開發(fā)人員注意的一些問題，提供測試評審和最終決策，以提出處理意見。

返回第51頁，共59頁，2023年，2月20日，星期日系統(tǒng)測試是將已經(jīng)確認的軟件、計算機硬件、外設、網(wǎng)絡等其他元素結合在一起，進行信息系統(tǒng)的各種組裝測試和確認測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方，從而提出更加完善的方案.。它的的任務是近可能徹底的檢查出程序中的錯誤，提高軟件系統(tǒng)的可靠性，其目的是檢驗系統(tǒng)"做得怎樣？"。這階段又可分為三個步驟：模塊測試，測試每個模塊的程序是否有錯誤；組裝測試，測試模塊之間的接口是否正確；確認測試，測試整個軟件系統(tǒng)是否滿足用戶功能和性能的要求。該階段結束應交付測試報告，說明測試數(shù)據(jù)的選擇，測試用例以及測試結果是否符合預期結果。測試發(fā)現(xiàn)問題之后要經(jīng)過調(diào)試找出錯誤原因和位置，然后進行改正。是基于系統(tǒng)整體需求說明書的黑盒類測試，應覆蓋系統(tǒng)所有聯(lián)合的部件。系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進行的測試，目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不相符合或與之矛盾的地方。

系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各種依賴的資源結合起來，在系統(tǒng)實際運行環(huán)境下來進行測試

返回第52頁，共59頁，2023年，2月20日，星期日基本概述：確認測試又稱有效性測試。有效性測試是在模擬的環(huán)境下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。任務是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定，它包含的信息就是軟件確認測試的基礎。測試內(nèi)容：

1、安裝測試

2、功能測試

3、可靠性測試

4、安全性測試

5、時間及空間性能測試

6、易用性測試

7、可移植性測試

8、可維護性測試

9、文檔測試第53頁，共59頁，2023年，2月20日，星期日基本方法：

1.確認測試標準實現(xiàn)軟件確認要通過一系列墨盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無論是計劃還是過程，都應該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。確認測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴重錯誤和偏差一般很難在預定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。

2.配置復審確認測試的另一個重要環(huán)節(jié)是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。

3.α、β測試事實上，軟件開發(fā)人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。

α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為α版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進行改錯和完善。

返回第54頁，共59頁，2023年，2月20日，星期日V模型是最廣為人知的測試模型。

最典型的V模型版本一般會在其開始部分對軟件開發(fā)過程進行描述，如下圖所示：

圖1V模型的各