軟件測試基礎教程——慕課網課程目標1?了解軟件測試的含義2?軟件測試遵循的準則3?軟件測試有哪些分類？分別是什么概念4?何時開始測試？測試方案如何設計？5?測試流程是怎樣的？怎么提bug？怎么寫報告？6?為什么要作自動化？怎么做？第一課時：軟件測試概要一、軟件測試的定義軟件測試是使用人工或自動的手段來運行或測量軟件系統的過程，以檢驗軟件系統是否滿足規定的要求，并找出與預期結果之間的差異。二、軟件測試的測試的對象需求、概要設計、詳細設計、運行環境、可運行程序、源代碼。（軟件測試工程序測試）三、 軟測的五大要素及兩大目標五大要素:質量（最為核心），人員（決定因素），技術（實現手段）【測試技術，方法，測試工具】，資源【測試所需的硬件，網絡環境，測試生命周期，測試時間】，流程（測試標準）【測試計劃，測試執行，報告】目標：提升測試覆蓋率及測試效率四、 軟件測試所遵循的原則：測試顯示缺陷的存在，但不能證明系統不存在缺陷。窮盡測試是不可能的，應設定及時終止的條件。煽碼單元測姦系域測試驗收測就發布后測試應該盡早進行。煽碼單元測姦系域測試驗收測就發布后引入缺陷發現缺陷朕觸修復成本缺陷具備群集特性。越是發現問題多的模塊，就是我們重點關注的對象。測試的殺蟲劑悖論。在測試當中，我們采用同樣的測試用例、同樣的測試方法，多次、重復的來測試某一個模塊，那最后我們就不能夠再發現新的缺陷。所以我們的測試用例和測試方法應該不定期的評審和修改，并增加不同的測試方法或測試用例來測試軟件或系統的不同部分，從而發現更多的缺陷。測試的二八原則。就是我們應該把80%的時間或資源用在20%的重點模塊上，重點測試這款軟件中20%的重要模塊，來達到我們測試的效率和資源配置最佳的比例。測試活動依賴于測試背景。第二課時：軟件測試階段、手段、模式一、軟件測試階段軟件測試按測試階段來分類：單元測試、集成測試、系統測試、驗收測試。（一）單元測試是各個階段測試的基礎，是對軟件中的最小可測試單元進行檢查和驗證。單元是人為規定的可測試的最小的模塊°（java面向對象語言來說，最小可測試單元是每一個類）單元測試是對代碼進行測試測試框架：junit針對JAVAnunit針對.net phpunit針對PHPCppUnit針對C++原則：盡可能的保證各個測試用例是互相獨立的。盡量避免使用依賴的方法。編寫一個模擬的方法來取代使用外部依賴。一般由代碼的開發人員來實施，用以檢驗所開發的代碼功能符合自己的設計要求。益處：能盡早發現缺陷。有利于重構。簡化集成。文檔。簡化文檔作用用于設計。限制：不可能覆蓋所有的執行路徑，所以不可能保證捕捉到所有路徑的錯誤。每一行代碼，一般需要3~5行測試代碼才能完成單元測試。所以存在投入和產出的一個平衡。（二）集成測試（偏于技術角度驗證）是在單元測試完成的基礎上針對已經完成單元測試的那些模塊，把他們組成更高一級的模塊和子系統，來針對這些子系統進行的集成。各個最小單元模塊之間的接口和子系統的集成。主要實施方案：BigBang。也叫一次性集成。就是把所有的東西組裝好，然后再一起進行測試。自頂向下。是一個遞增的組裝軟件結構的方法。自底向上核心系統集成。高頻集成。高頻次的不斷地進行集成。集成測試與單元測試的區別是：測試對象不同測試依據不同單元——主要；集成——概要測試的方法不同集成測試——關注接口之間的集成；單元測試——關注單元的內部（三）系統測試（偏于業務角度驗證）（一般測試崗位，主要集中在系統測試）把整個系統組裝以后置于真實的運行環境對這個系統進行全面的測試。主要做功能測試、性能測試、穩定性測試等多種測試。是將經過集成測試的軟件，作為計算機系統的一個部分，與系統中其他部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效的測試，以發現軟件潛在的問題，保證系統的正常運行。關注點關注系統本身的使用關注系統與其他相關系統間的連通關注系統在不同使用壓力下的表現關注系統在真實使用環境下的表現系統測試&集成測試區別測試對象集成測試：由通過了單元測試的各個模塊所集成起來的構件系統測試：除了軟件之外，還包括計算機硬件及相關的外圍設備、數據采集和傳輸機構、支持軟件、系統操作人員等整個系統測試時間集成測試介于單元測試和系統測試之間測試系統測試在集成測試之后測試內容集成測試：各個單元模塊之間的接口系統測試：整個系統的功能和性能測試角度集成測試：偏于技術角度的驗證系統測試：偏于業務角度的驗證（四）驗收測試從用戶的角度對系統軟件的認可驗收。也稱交互測試。針對用戶需求、業務流程的正式的測試，確定系統是否滿足驗收標準，由用戶、客戶或其他授權結構決定是否接受系統。定義：交付測試。針對用戶需求、業務流程的正式的測試、確定是否滿足驗收標準，由用戶、客戶或者其他授權機構決定是否接受系統。驗收測試細分可分為用戶驗收測試：開發交付之前運行驗收測試：運維的層面合同和規范驗收測試：參照約定的規范驗收，還有法律法規alpha測試：在開發環境中，由用戶進行測試Beta測試：脫離開發環境由用戶提供的環境下進行測試二、軟件測試手段軟件測試的分類：按可見度：黑盒白盒按狀態：靜態、動態按測試執行方式：手工、自動化（一）黑盒測試在完全不考慮程序內部結構和特性的情況下，通過暴露出來的接口對程序進行測試程序是否能正常接收輸入，正確輸出，一般針對界面或可見功能用戶視角，通過結果判斷優：容易實施，不需要關注內部實現，操作簡單更貼近用戶視角，測試場景與正式場景更接近缺：覆蓋率較近，只能覆蓋代碼量的不足40%（不了解內部實現不知道內部分支）針對黑盒的自動化測試，復用率較低，維護成本較高黑盒針對功能進行測試，變動較大，用例使用率較低主要測試的地方（關注點）：功能是否正確或遺漏接口上輸入、輸出是否正確數據結構或外部信息是否有訪問錯誤性能是否滿足系統測試階段主要使用黑盒測試其它各個階段也會用到黑盒測試的主要設計方法1.等價類劃分法：針對程序有很多輸入條件，把所有的輸入把等價的歸為一類，形成若干等價的代表形輸入，通過典型數據進行測試用例的設計。2.邊界值分析法：特殊的等價類劃分，更關注各種邊界條件，開發時容易出現失誤的地方需要重點關注錯誤推測法：基于經驗或直覺，判斷出程序中容易失誤的地方，從而制作測試用例例如：特殊字符、文件不存在，或文件超大等因果圖法：拿到程序的需求規格說明書，針對輸入輸出在因果圖中看作原因和結果根據規劃說明生成判斷表正交試驗分析法：主要用于篩選輸入數據狀態遷移圖法：通過處理功能點的狀態遷移關系，例如審批流程中的狀態變化流程分析法：通過梳理邏輯程序的路徑（二）白盒測試黑盒：內部不可見白盒：邏輯結構對測試人員是透明的，又叫結構化測試或透明盒，通過對邏輯結構來設計測試用例。用邏輯的覆蓋率來測試邏輯的完整性。邏輯的單位：語句、條件、條件組合、分支、路徑語句覆蓋：保證每條語句至少被執行一次判定：條件覆蓋：覆蓋表達式分支是路徑的一部分優：1.迫使測試人員去仔細思考軟件的實現，理解原理2.可以檢測代碼中的每條分支和路徑揭示隱藏在代碼中的錯誤對代碼的測試比較徹底缺：昂貴（較高的覆蓋率，工作量大）無法檢測代碼中遺漏的路徑和數據敏感性錯誤針對代碼不是針對需求，不能正確驗證需求實現是否正確白盒測試的方法：代碼檢測法：對代碼進行檢測靜態結構分析法：通過測試工具分析系統結構數據結構、內部控制邏輯來制定測試用例靜態質量度量法：iso標準制作度量模型4?邏輯覆蓋法：6種主要覆蓋測試方法：語句條件條件組合分支路徑條件vs判定覆蓋基本路徑測試法：白盒中主要的一種測試方法在程序控制流圖的基礎上，通過分析控制構造復雜度導出基本可執行的路徑的集合進而制作測試用例的方法控制流圖：描述控制流灰盒：介于黑、白盒測試之間的，關注輸入、輸出的正確性、同時也關注內部表現結合了黑、白的測試要素，主要用于組件的測試（三） 靜態測試靜態測試：無須執行被測程序，通過評審軟件文檔或代碼，度量復雜度，檢查軟件是否符合編程標準以發現程序的不足之處，減少錯誤出現的概率可以通過人工，也可以通過自動化工具方式：互審-走查（小組）-會議（記錄正式），不正式到正式的集體活動（四） 動態測試動態測試：通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率、正確性和健壯性等黑盒：主要是動態測試方法白盒：代碼檢查法和靜態代碼分析法就是典型的靜態方法（五） 手工測試手工測試：由專門的測試人員從用戶視角來驗證軟件是否滿足設計要求的行為。更適用針對深度的測試和強調主觀判斷的測試手工測試方法：眾包測試、探索式測試優：1.易發現缺陷2.容易實施3.更具有創造性、靈性性缺：1.覆蓋量化難2.重復測試效率低3.不一致性、可靠性低（前后不一致）4.人力資源依賴（六）自動化測試自動化：使用單獨的測試工具軟件控制測試的自動化執行以及對預期和結果進行自動檢查自動化測試方法：單元測試、接口測試、性能測試等優：1.高效率、速度快2.高復用性3.覆蓋率容易度量4.準確、可靠5.不知疲勞缺：1.機械、發現缺陷率低，不具備創造性不靈活一次性投入較大（從實施自動化測試之初、從測試工具的選型、框架的設計到自動化測試腳本的編寫、維護都需要投入較大的精力和資源）手工和自動化各有適用場景手工測試vs自動化測試手工測試自動化測試?易發現缺陷?咼效率,MS快■容易實施*咼復用性?創造性、靈活?覆蓋率容易度量,覆蓋量化難?準確、可靠?重復測試效率低?平知疲勞*不一致性.可靠性低訂幾械、發現缺陷率低-人力資源依賴-_次性投入較大三、軟件測試模式瀑布模型、敏捷測試、基于腳本的測試、基于風險的測試、探索式測試等。一）瀑布模型瀑布模型：項目計劃、需求分析、軟件設計、程序開發、軟件測試、集成維護項目計劃：制定總體的研發計劃，確定主要的里程碑節點－輸出項目計劃書）需求分析：明確用戶需求定義，并對定義進行清晰描述，充分理解需求，描述產品功能－輸出產品需求規格說明）

軟件設計：根據需求定義，設計產品的實現方案，包括定義軟件硬件的結構、組件、實現方法、接口、界面、數據－輸出概要設計、詳細設計程序開發：根據概要和詳細設計具體實現，根據編程規范構建各類組件模塊，輸出產品版本。軟件測試：通過獨立的測試小組評估產品是否滿足需求定義－輸出測試報告集成維護：交付用戶，根據用戶使用情況進行維護及升級優點：1.強調需求、設計的作用；2.前一階段完成后，只需關注后續階段；為項目提供了按階段劃分的檢查點，里程碑清晰；4.文檔規范缺點：1.難以適應需求的頻繁變；2.項目周期后段才能看到成果，增加了風險強制的里程碑、完成時間點，適應能力差；4.文檔工作量大瀑布模型的優缺點駐點＞強調需求、設計的作用駐點＞強調需求、設計的作用-前—階段完成后,只需關注后續階段*為項目提供了按階段劃分的檢査點,里程碑清晰*文檔規范-難以適應需求的頻緊變化*項目周期后段才能看到成果?強制的里程碑、完成時間點口?文檔工作量大（二）V模型（最廣泛）是瀑布模型的變種明確表明測試過程的不同級別，階段：單元測試－集成測試－系統測試－驗收測試并且描述了各個階段與開發過程各個階段的對應關系。

軟件編碼V模型需求分桁驗收測試概要設計隼成測試PaulRock詳細設計軟件編碼V模型需求分桁驗收測試概要設計隼成測試PaulRock詳細設計優點：強調軟件開發的協作和速度，反應測試活動和分析設計的關系，軟件的實現和驗證有機結合缺點：僅把關系明確對應，忽略了對需求分析的驗證，對需求和功能的測試到驗收測試才能發現；沒有很好的體現測試的及時性（三）W模型（雙V模型）開發與測試并行，可以盡早發現問題交忖實編集朗單元測試W模型用戶需求驗收測試設計驗收測試系統測試設計需求分析概要設計隼成測試設計集成測試詳細設計單元測試設計Eglutif開發與測試并行，可以盡早發現問題交忖實編集朗單元測試W模型用戶需求驗收測試設計驗收測試系統測試設計需求分析概要設計隼成測試設計集成測試詳細設計單元測試設計Eglutif公司優點：1.增加了開發各個階段的驗證，測試的對象不再是對象，對需求和分析都有測試過程2.有利于及于發現項目的風險，線性的相互關系缺點：不能很好的支持像迭帯這樣的模式（四） X模型解決交接和頻繁集成周期的問題（五） H模型把測試當成一個完全獨立的流程，便于盡早的完成測試，與其他流程并發進行，可以是任何流程（比如設計流程，并發流程，甚至是測試流程），可交叉。四、軟件測試模式——敏捷測試（一）敏捷測試定義：AgileTesting遵循敏捷宣言的一種測試實踐敏捷宣言：個體與交互重于過程和工具可用的軟件重于完備的文檔客戶協作重于合同談判響應變化重于遵循計劃敏捷測試：強調從客戶角度測試重點關注迭代測試新功能，不在強調測試階段盡早測試，不間斷測試，具備條件即測試強調持續反饋預防缺陷重于發現缺陷敏捷測試vs傳統測試：傳統測試敏捷測試測試是質量的最后保護者開發和測試人員緊密合作，大家都有責任對軟件負責嚴格的變更管理變更可以接受預先的計劃和細節準備計劃隨著進展時常調整重量級文檔只需要必要的文檔各階段測試嚴格的入口和出口標準各迭代之間沒有明顯入口和出口標準更多在回歸測試時進行重量級自動化測試所有階段都要自動測試，每個人都需要做，是項目集成一部分嚴格依賴測試流程流程不再需要嚴格執行測試與開發團隊相對獨立團隊合作是無縫隙合作（二） 基于腳本的測試SBT基于腳本的測試Script（測試用例）-basedtestingScripted（測試腳本）testingST先設計測試，再執行測試。（三） 探索式測試ETET探索式測試：exploratorytesting完全拋開測試腳本的測試探索式測試分為局部探索式測試和全局探索測試局部探索式測試五大模塊輸入：接受輸入、產生輸出、存儲數據、進行運算（主要是這四種任務）測試時是從輸入順序，輸出內容輸出異常幾個角度來考慮測試的要點狀態：可分為臨時狀態和永久狀態運行有效、階段是有效，這種是臨時狀態、數據庫保存、文件保存，相對來說是永久狀態。協助我們更叫有效的判斷測試輸入測試輸出代碼路徑：多指代對碼的覆蓋 （例如白盒測試覆蓋的方法）用戶數據：構造真實的用戶數據執行環境：軟件運行的操作系統系統組網的網絡拓撲與系統交互的第三方系統系統的配置數據運行系統的硬件設備對測試的影響（局部測試所要考慮的要點）全局探索式測試（漫游測試法）商業區：軟件從啟動到關閉，這期間主要可能使用到的功能；旅館區：主要指軟件在休息運行的功能（后臺的進程，或者是定時的任務）；歷史區：以前測試中發現較多問題的功能；旅游區：新手使用的功能（新手指引）；娛樂區：系統主要功能之外的輔助功能破舊區：系統已經廢棄的或者看不到的探索式測試流程了解測試任務的重點、主要的測試方向，系統的環境，做到有個總體的思路了解系統的業務邏輯，具體功能，深入學習被測系統探索式測試的實施階段，完成主要功能點的測試驗收，覆蓋測試在上一步的基礎上，發散式探索式測試，挖掘一些深層次的問題對前面的測試工作的總結，整理過程的測試信息缺陷大掃除優缺點：探索式測試的優點探索式測試的缺點1?更能激發測試人員的創造性和工作樂趣1?測試管理上有局限性，較難協調和控制2?增加了發現新的或較深入Bug的可能性2?對于Bug的重現傷作用有限3?在較短的時間內找到更多Bug以及對SUI（被測系統）做一個快速的評估3?對測試人員的測試技能和業務只是深度依賴較大4?有利于更加有效的實施自動化4?只有在SUT已完全可用的前提下才更有作用5?更加適用于敏捷項目5.ET的生產率很難定義6?減少了再簡單、繁復上用例的無為編寫時間6.ET本身較難進行自動化ST【基于腳本的測試】和ET【探索性測試】互補實際項目實施情況：purescripted完全參照測試用例執行，測試用例十分詳細vaguescripted寫測試用例，對預期結果，執行步驟的描述簡單fragmentarytestcases不再編寫測試用例，只是寫一些測試點charters詳細的任務列表，寫出測試對象，測試策略，可能風險，參考文檔roles給測試人員一個角色，測試人員從角色出發測試產品freestyleET完全自由，無文檔，不記錄要點STvsETSTVsETETET（四） 基于風險的測試RBTRisk-baseTesting：—種基于對軟件失效的風險評估并以此指導測試計劃、設計、執行、結果評價的軟件測試類型風險包括：質量風險、管理風險風險級別=風險可能性*風險嚴重度識別風險：可能性、復雜性、時間壓力、高變更率、技能水平、地理分散度嚴重程度：使用頻率、失效可視性、商業損失、組織負面影響和損害、社會損失和法律責任（五） 基于模型的測試MBT它的測試用例是從一個模型中導出所得，這個模型描述了被測系統的某些方面，通常是功能部分。模型：對需求功能建模第三課時：軟件測試類型軟件測試按測試類型:功能測試、性能測試、兼容性測試、部署測試、易用性測試、文檔測試、本地化測試、安全測試、無障礙測試、可靠性測試一、功能測試根據產品特性、操作描述和用戶方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求。針對的問題:功能錯誤或遺漏、界面問題、性能錯誤、數據及訪問錯誤、初始化及終止錯誤。功能測試工具:商用:QTP（web應用）、winrunner（桌面軟件）、silkTest、Rationalrobot開源:selenium、Watir（基于ruby語言，針對web應用）、Sikuli（屏幕截圖）二、性能測試性能測試分類負載測試：在測試過程中，逐步的增加負載，來觀察系統的表現，最終確定出系統在正常的指標范圍下的最大負載。壓力測試：測試系統在極限情況下的壓力情況，最終系統是什么樣的壓力環境下會導致失效，不能正常運行，確定出我們這個系統所能承受的最大極限。穩定性測試：一般是以稍大于正常業務量的負載進行持續的、長時間的測試，比如：24*5，連續5天的對這個系統進行24小時的施加壓力，以確定系統在較長時間的運行情況下，我們這個系統地穩定性情況。性能指標并發用戶數VU,同時訪問系統的用戶數量；每秒事務數TPS，每秒系統處理業務的數量；系統響應時間；設備性能，CPU等性能測試工具LoadRunner,Silkperformer,Jmeter（java開源的有效的測試工具）,WebLoad,ApacheBench,LoadUI傳門針對接口的性能測試）靜態性能評估開發web應用時，基于一系列web應用性能優化的最佳實踐對web應用的頁面進行靜態分析，并給出評估結果的性能分析方法評估的標準/工具（YSIow,PageSpeed）應用性能管理APM提供對系統的實時監控以實現性能管理，故障管理的解決方案三、安全測試安全測試：對軟件產品進行測試以確保其符合產品安全需求和質量標準滲透測試：通過對軟件系統的惡意攻擊行為來評估系統安全性的一種測試區別：滲透測試：嘗試去攻破軟件的防御機制安全測試：建立全方位攻擊防御機制OWasp：openwebapplicationsecurityproject開放的WED應用安全項目安全測試最關注：A.OWASPtoptenproject1.Injection注入腳本漏洞使用戶訪問到不該訪問的數據的目的BrokenAuthenticationandSessionManagement失效的身份認證和會話管理會話劫持漏洞Cross—SiteScripting（XSS）跨站腳本4.InsecureDirectObjectReferences不安全的對象直接引用參數的保護5.SecurityMisconfiguration安全配置類錯誤6.SensitiveDataExposure敏感信息泄露信息傳遞沒有對關鍵信息進行加密MissingFunctionLeveIAccessControI 功能級別訪問控制缺失，比如訪問網站可以訪問到用戶沒有權限到達的地方Cross-SiteFunctionLeveIAccessControI（CSRF） 跨站請求偽造UsingComponentswithKnownVuInerabiIities 使用了已知有漏洞的組件UnvaIidatedRedirectsadnForwards 未被驗證的重定向和轉發（釣魚網站）B?測試指南testingproject安全測試工具：appscan（針對web）,webinspect（web）nessus（服服務器）nmap（端口）metasploit（-攻擊框架，有大量插件，滲透測試）webscarab（代理堅持，攻擊路徑）fortify（白盒，源代碼靜態測試）W3AF（web）四、兼容性測試（1）軟件本身的兼容性：主要是軟件的向后兼容，如軟件升級，以前版本的功能也能使用（2）不同平臺下的兼容性：如在Linux系統下的ubuntu、openSUSE等，進行平臺的兼容性測試（3） 對不同的設備的兼容性：如32位、64位、如小型機、PC等（4）