軟件測試基礎(chǔ) -測試崗位入職培訓(xùn)

測試基本知識1測試項目流程2軟件測試基本知識軟件工程與軟件測試軟件工程是應(yīng)用計算機科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開發(fā)軟件的工程。通俗地說，軟件工程是實現(xiàn)一個大型程序的一套原則方法，即按工程化的原則和方法組織軟件開發(fā)工作。軟件測試是軟件工程的一個重要環(huán)節(jié)，相當于工程領(lǐng)域中的質(zhì)量檢驗部分，是確保軟件工程質(zhì)量的重要手段。軟件過程模型

軟件開發(fā)過程中存在各種復(fù)雜因素，為了解決由此而帶來的種種問題，軟件開發(fā)者們經(jīng)過多年的摸索，給出了多種實現(xiàn)軟件工程的方式——軟件過程模型，如瀑布過程模型、螺旋過程模型和增量過程模型等。瀑布過程模型

瀑布過程模型強調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性，是一種嚴格線性的、按階段順序的、逐步細化的開發(fā)模式。螺旋過程模型

螺旋過程模型的基本思路是，依據(jù)前一個版本的結(jié)果構(gòu)造新的版本，這個不斷重復(fù)迭代的過程形成了一個螺旋上升的路徑。增量過程模型

有些時候可能會用一種幾乎連續(xù)的過程小幅度地推進項目，這就是增量過程模型。軟件測試的定義及目的簡單地說，軟件測試就是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。在IEEE提出的軟件工程標準術(shù)語中，軟件測試被定義為：“使用人工和自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清楚預(yù)期結(jié)果與實際結(jié)果之間的差別。”軟件測試是與軟件質(zhì)量密切聯(lián)系在一起的，歸根結(jié)底，軟件測試是為了保證軟件質(zhì)量。軟件測試的目的就是為了發(fā)現(xiàn)盡可能多的缺陷，并期望通過改錯來把缺陷統(tǒng)統(tǒng)消滅，以期提高軟件的質(zhì)量。軟件測試的發(fā)展歷程軟件測試是伴隨著軟件的產(chǎn)生而產(chǎn)生的，有了軟件的生成和運行就必然有軟件測試。在早期的軟件開發(fā)過程中，測試的含義比較窄，將測試等同于“調(diào)試”，目的是糾正軟件中已經(jīng)知道的故障，常常由軟件開發(fā)人員自己完成這部分工作。對測試的投入極少，測試介入得也晚，常常是等到形成代碼，產(chǎn)品已經(jīng)基本完成時才進行測試。直到1957年，軟件測試才開始與調(diào)試區(qū)別開來，成為一種發(fā)現(xiàn)軟件缺陷的活動。直到20世紀80年代早期，“質(zhì)量”的號角才開始吹響。軟件測試的定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程，而且包含軟件質(zhì)量評價的內(nèi)容。近20年來，隨著計算機和軟件技術(shù)的飛速發(fā)展，軟件測試技術(shù)的研究也取得了很大的突破，測試專家總結(jié)了很好的測試模型，如著名的V模型，在單元測試、自動化測試等方面涌現(xiàn)了大量優(yōu)秀的軟件測試工具。軟件測試的發(fā)展趨勢根據(jù)國內(nèi)外軟件測試的發(fā)展現(xiàn)狀，可以看到軟件測試有以下的發(fā)展趨勢。

①測試工作將進一步前移。

②軟件架構(gòu)師、開發(fā)工程師、QA人員、測試工程師將進行更好的融合。

③測試職業(yè)將得到充分的尊重。 ④設(shè)置獨立的軟件測試部門將成為越來越多的軟件公司的共識。軟件測試部門將和開發(fā)部、質(zhì)量保證部一樣作為一個重要的獨立部門存在。

⑤測試外包服務(wù)將快速增長。和軟件開發(fā)外包一樣，軟件測試外包將成為全球化的一種趨勢?？梢岳寐殬I(yè)測試專家隊伍與機構(gòu)為自己的產(chǎn)品進行測試，而且可以節(jié)省測試費用。軟件測試人員的基本素質(zhì)軟件測試人員應(yīng)具備下列基本素質(zhì)。1．具有良好的計算機編程基礎(chǔ)2．具有創(chuàng)新精神和超前意識3．不懈努力，追求完美4．具有整體觀念，對細節(jié)敏感5．團隊合作精神軟件測試的原則1．應(yīng)當把“盡早和不斷的測試”作為開發(fā)者的座右銘2．程序員應(yīng)該避免檢查自己的程序，測試工作應(yīng)該由獨立的專業(yè)的軟件測試機構(gòu)來完成。3．設(shè)計測試用例時應(yīng)該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。4．一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。5．對測試錯誤結(jié)果一定要有一個確認的過程，一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。6．制定嚴格的測試計劃，并把測試時間安排的盡量寬松，不要希望在極短的時間內(nèi)完成一個高水平的測試。7．回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。8．妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。軟件測試的手段驗證和確認

所謂驗證，是指如何決定軟件開發(fā)的每個階段、每個步驟的產(chǎn)品是否正確無誤，并與其前面的開發(fā)階段和開發(fā)步驟的產(chǎn)品相一致。驗證工作意味著在軟件開發(fā)過程中開展一系列活動，旨在確保軟件能夠正確無誤地實現(xiàn)軟件的需求。

所謂確認，是指如何決定最后的軟件產(chǎn)品是否正確無誤。功能和結(jié)構(gòu)測試

當測試人員測試項目小組的解決方案時，將利用驗證和確認技術(shù)完成功能和結(jié)構(gòu)測試。功能測試通常也被稱為黑盒測試，因為測試案例中都不涉及系統(tǒng)的內(nèi)部邏輯。

結(jié)構(gòu)測試通常被稱為白盒測試，因為系統(tǒng)的內(nèi)部邏輯常被用于假想的測試案例。結(jié)構(gòu)測試主要使用驗證技術(shù)。測試模型測試與軟件開發(fā)各階段的關(guān)系軟件測試的分類按照開發(fā)階段劃分

按照開發(fā)階段劃分，軟件測試可分為單元測試、集成測試、系統(tǒng)測試、驗收測試和回歸測試。按照測試實施組織劃分

按照測試實施組織劃分，軟件測試可分為開發(fā)方測試、用戶測試（β測試）和第三方測試。按照測試技術(shù)劃分

按照測試技術(shù)劃分，軟件測試可分為白盒測試、黑盒測試、性能測試、安全測試等。測試類型

功能測試

健壯性測試

接口測試

強度測試

壓力測試

性能測試

用戶界面測試

安全測試

可靠性測試

安裝/反安裝測試

文檔測試

恢復(fù)測試

兼容性測試 α測試 β測試白盒測試介紹

白盒測試方法又可分為靜態(tài)測試和動態(tài)測試。

靜態(tài)測試是一種不通過執(zhí)行程序而進行測試的技術(shù)，其關(guān)鍵功能是檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義。它瞄準的是糾正軟件系統(tǒng)在描述、表示和規(guī)格上的錯誤，是任何進一步測試的前提。而動態(tài)測試需要軟件的執(zhí)行，當軟件系統(tǒng)在模擬的或真實的環(huán)境中執(zhí)行之前、之中和之后，對軟件系統(tǒng)行為的分析是動態(tài)測試的主要特點。它顯示了一個系統(tǒng)在檢查狀態(tài)下是正確還是不正確。

白盒測試的動態(tài)測試要根據(jù)程序的控制結(jié)構(gòu)設(shè)計測試用例。

白盒測試用例設(shè)計方法，包括程序插樁、邏輯覆蓋、基本路徑測試。黑盒測試

黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，前提是已知產(chǎn)品所具有的功能，通過測試來檢測每個功能是否都正常使用。

黑盒測試方法主要有等價類劃分、邊界值分析、因果圖、錯誤推測、功能圖法等，主要用于軟件確認測試。性能測試通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項是性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。安全性測試

安全性測試（securitytesting）是有關(guān)驗證應(yīng)用程序的安全服務(wù)和識別潛在安全性缺陷的過程。注意：安全性測試并不最終證明應(yīng)用程序是安全的，而是用于驗證所設(shè)立策略的有效性，這些對策是基于威脅分析階段所做的假設(shè)而選擇的。易用性測試簡介

易用性(Useability)是交互的適應(yīng)性、功能性和有效性的集中體現(xiàn)。

人體工程學(xué)(ergonomics)是一門將日常使用的東西設(shè)計為易于使用和實用性強的學(xué)科。

在2003年頒布的GB/T16260-2003(ISO9126-2001)《軟件工程產(chǎn)品質(zhì)量》質(zhì)量模型中，提出易用性包含易理解性、易學(xué)習(xí)性和易操作性;即易用性是指在指定條件下使用時，軟件產(chǎn)品被理解、學(xué)習(xí)、使用和吸引用戶的能力。易用性測試分類易用性測試包括針對應(yīng)用程序的測試，同時還包括對用戶手冊系統(tǒng)文檔的測試。通常采用質(zhì)量外部模型來評價易用性。包括如下方面的測試：(1)易理解性測試;(2)易學(xué)性測試;(3)易操作性測試;(4)吸引性測試;優(yōu)秀UI具備的七個要素—符合標準和規(guī)范

最重要的用戶界面要素是軟件符合現(xiàn)行的標準和規(guī)范——或者有真正站得住腳的不符合的理由。

注意：如果測試在特定平臺上運行的軟件，就需要把該平臺的標準和規(guī)范作為產(chǎn)品說明書的補充內(nèi)容。像對待產(chǎn)品說明書一樣，根據(jù)它建立測試用例。

優(yōu)秀UI具備的七個要素——直觀用戶界面是否潔凈、不唐突、不擁擠?UI的組織和布局合理嗎?有多余功能嗎?幫助系統(tǒng)有效嗎?優(yōu)秀UI具備的七個要素——一致

如果軟件或者平臺有一個標準，就要遵守它。如果沒有，就要注意軟件的特性，確保相似的操作以相似的方式進行。如以下元素：快捷鍵和菜單選項。術(shù)語和命名，諸如OK和Cancel按鈕的位置。優(yōu)秀UI具備的七個要素——靈活多種視圖的選擇：狀態(tài)跳轉(zhuǎn)狀態(tài)終止和跳過數(shù)據(jù)輸入和輸出優(yōu)秀UI具備的七個要素——舒適軟件使用起來應(yīng)該舒適，不能給用戶工作制造障礙和困難。恰當;錯誤處理;性能。優(yōu)秀UI具備的七個要素——正確、實用要測試正確性，就是測試UI是否做了該做的事。注意：市場定位偏差、語言和拼寫、不良媒體、所見即所得。是否實用事優(yōu)秀用戶界面的最后一個要素。軟件測試的原則軟件測試的原則尚沒有標準的說法，根據(jù)經(jīng)驗得出以下幾條：

（1）所有的測試都應(yīng)追溯到用戶需求。（2）應(yīng)當把“盡早地和不斷地進行軟件測試”作為軟件測試者的座右銘。（3）設(shè)計時應(yīng)完成測試計劃，詳細的測試用例定義可在設(shè)計模型確定后開始，測試可在代碼產(chǎn)生之前進行計劃和設(shè)計。

（4）pareto原則：測試發(fā)現(xiàn)的錯誤中80%很可能起源于20%的模塊中。應(yīng)孤立這些疑點模塊，進行重點測試。

（5）完全測試是不可能的，測試需要終止。

（6）充分注意測試中的群集現(xiàn)象。

（7）要盡量避免測試的隨意性。

（8）兼顧合理的輸入和不合理的輸入數(shù)據(jù)。

（9）應(yīng)長期保留測試用例，直至系統(tǒng)廢棄。測試用例的設(shè)計測試按照階段分為單元測試、集成測試以及系統(tǒng)測試。而各階段都有相應(yīng)的測試用例。

測試用例的設(shè)計步驟：（1）步驟1：使被測對象運行（2）步驟2：正面測試（3）步驟3：負面測試（4）步驟4：需求中其他測試特性用例設(shè)計（5）步驟5：覆蓋率測試用例設(shè)計（6）步驟6：測試執(zhí)行（7）步驟7：完善覆蓋測試工具按照測試工具的主要用途和應(yīng)用領(lǐng)域?qū)y試軟件做了一個整理歸納，將自動化測試工具分為以下幾類：捕獲錯誤用途，用于捕獲軟件錯誤或程序調(diào)試。GUI自動化用途，這類軟件除了提供在窗口界面中使用外，也有不少是針對瀏覽器接口開發(fā)的自動化測試工具。專項用途，如：專用代碼測試工具、白盒測試工具、網(wǎng)絡(luò)測試工具。軟件產(chǎn)品功能、性能測試用途。測試管理工具。LoadRunner LoadRunner是MercuryInteractive公司開發(fā)的一種預(yù)測系統(tǒng)行為和性能的負載測試工具，它可以通過模擬成千上萬個用戶和實施實時監(jiān)測來確認和查找問題。對于有實力的大公司而言，這款軟件可能比較適合，它的功能和QALoad相比不相上下。通過使用LoadRunner，企業(yè)能夠最大限度地縮短測試時間、優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。QuickTestProfessional Mercury的自動化功能測試軟件QuickTestProfessional是一個B/S系統(tǒng)的自動化功能測試的利器,軟件程序測試工具?？梢愿采w絕大多數(shù)的軟件開發(fā)技術(shù)，簡單高效，并具備測試用例可重用的特點。

QuickTestProfessional是一款先進的自動化測試解決方案，用于創(chuàng)建功能和回歸測試。它自動捕獲、驗證和重放用戶的交互行為。

QualityCenter QualityCenter可以幫助您組織和管理應(yīng)用程序測試流程的所有階段，包括指定測試需求、計劃測試、執(zhí)行測試和跟蹤缺陷。

QualityCenter為部署之前的測試應(yīng)用程序過程提供了一個系統(tǒng)的框架。由于測試計劃涉及新的或修改后的應(yīng)用程序需求，因此，您需要一個集中的數(shù)據(jù)存儲庫來組織和管理測試流程。QualityCenter為整個測試流程提供指導(dǎo)信息，包括指定需求、計劃測試、執(zhí)行測試和跟蹤缺陷等階段。

測試基本知識1測試流程2項目組組織結(jié)構(gòu)--

測試組長職責(zé)

小組內(nèi)部測試任務(wù)的分配安排。協(xié)調(diào)測試資源以及解決小組內(nèi)測試過程中出現(xiàn)的問題。項目進度控制以及風(fēng)險控制：負責(zé)評估測試周期，協(xié)調(diào)測試人力，并及時同項目管理人員同步測試進度以及風(fēng)險信息。團隊建設(shè)及人員培訓(xùn)：負責(zé)組建測試團隊并對測試人員提供必要的培訓(xùn)，包括測試技能培訓(xùn)，工具培訓(xùn)，業(yè)務(wù)培訓(xùn)等。測試文檔的審核：評審測試計劃、測試用例，審核輸出的測試報告和驗收用例以及以各種形式輸出的本小組的測試結(jié)果并對輸出的測試結(jié)果負責(zé)。對本小組承接項目的測試結(jié)果負測試計劃的制定：根據(jù)承接的測試任務(wù)或需求情況，制定明確可行的測試計劃。測試需求分析：負責(zé)根據(jù)需求規(guī)格說明書以及開發(fā)文檔梳理測試需求并拆分出測試點。測試用例設(shè)計：根據(jù)測試需求設(shè)計可擴展，清晰，明確，完整的測試用例。按計劃執(zhí)行測試，并按時按標準完成測試任務(wù)。維護測試環(huán)境、更新包：根據(jù)開發(fā)提供的程序包部署并維護應(yīng)用程序，根據(jù)測試需要設(shè)置配置信息。測試文檔輸出：負責(zé)編寫驗收用例和測試報告并統(tǒng)計缺陷數(shù)量，和相關(guān)負責(zé)人確認遺留缺陷。項目組組織結(jié)構(gòu)--測試人員的職責(zé)

產(chǎn)品測試、項目測試

產(chǎn)品和項目的最大區(qū)別是項目需求全部來自一個客戶，因此項目的需求變更更頻繁，項目周期短，不容易做好整體文檔、且文檔復(fù)用性不高，而產(chǎn)品的需求一部分來自客戶、一部分來自市場、還有一部分來自行業(yè)標準，相對來說需求變動較小，主要是版本的升級，主要功能變動不大，文檔的復(fù)用性高。產(chǎn)品測試模型需求、設(shè)計等階段區(qū)分明顯，以瀑布型為主。項目測試模型由于需求變更明顯，所以以增量迭代式為主測試信息流測試項目流程項目各階段描述—項目準備階段

測試項目目標分析

測試項目立項后，對測試背景、對象、環(huán)境進行了解，明確測試目的、要達成的效果。

測試目標要與客戶方進行溝通和確認。測試項目需求分析

對測試項目中的需求進行分析，形成測試需求。測試方案、計劃

根據(jù)測試目的、范圍、需求的分析以及時間、人力的要求編寫測試方案和計劃。

本階段成果物：《測試方案》、《測試計劃》項目各階段描述—項目實施階段

項目準備階段中的‘測試方案’、‘測試計劃’評審?fù)ㄟ^，進入項目實施階段。測試用例和環(huán)境準備

依據(jù)測試方案編制測試用例、準備測試環(huán)境。測試執(zhí)行

依據(jù)測試計劃執(zhí)行設(shè)計的測試用例。產(chǎn)生的成果物：

測試用例執(zhí)行數(shù)據(jù)

測試缺陷記錄

測試執(zhí)行日志測試各階段描述—測試報告階段

按照測試計劃，完成測試用例后，開始進入測試報告階段。數(shù)據(jù)分析

本階段需要對測試執(zhí)行過程中產(chǎn)生的數(shù)據(jù)進行整理、分析，測試報告

根據(jù)對測試結(jié)果和過程的分析編寫測試報告產(chǎn)生的成果物：《測試報告》、《測試工作匯報》項目過程中的注意事項測試用例執(zhí)行之前做好準備，避免遺漏監(jiān)控指標，影響測試分析；測試結(jié)束后，做好記錄。缺陷跟蹤過程一般流程: New---------open----------fixed-------closed

測試人員新建bug狀態(tài)為new-------開發(fā)人員確認為bug狀態(tài)改為open--------開發(fā)人員修改好了bug狀態(tài)改為fixed--------測試人員確認修改好了狀態(tài)改為closed不是BUG的流程： New----------notabug----------Reopen----------open------fixed--------closed

測試人員新建bug狀態(tài)為new-----開發(fā)人員認為不是bug狀態(tài)改為notabug-------測試人員向開發(fā)確認認為是bug測試人員狀態(tài)改為Reopen--------開發(fā)人員確認bug狀態(tài)改為open------------開發(fā)人員修改好了bug狀態(tài)改為fixed--------測試人員確認修改好了狀態(tài)改為closed (如果確認這不是一個bug，狀態(tài)為notabug，不做修改)

（狀態(tài)為notabug的bug，開發(fā)要在批注是注明原因）缺陷跟蹤過程需要理多信息的流程： New----------moreinformation------reopen----------open------fixed--------closed

測試人員新建bug狀態(tài)為new-------開發(fā)人員想要更多的關(guān)于此bug的信息狀態(tài)改為moreinformation---------測試人員提供了更多關(guān)于此bug的信息狀態(tài)改為reopen-------開發(fā)人員確認為bug狀態(tài)改為open------------開發(fā)人員修改好了bug狀態(tài)改為fixed--------測試人員確認修改好了狀態(tài)改為closed延期修改的bug流程： New----------delay

測試人員新建bug狀態(tài)為new-------開發(fā)人員認為要以后修改的bug狀態(tài)改為delay

（狀態(tài)改為delay的bug，開發(fā)人員要在批注中說明delay的原因）缺陷跟蹤過程重復(fù)的bug流程