软件测试初入
1、什么是軟件測試？
在需求正確的前提下，驗證軟件的功能是否滿足用戶的需求
目的： 保證和提高軟件的質量，給用戶交付一個高質量、高可用度的一個軟件。
2、軟件測試和研發的區別？
測試和調試的區別
測試 是測試人員確保程序做了它應該做的事情
調試 是程序開發人員確保程序做了它想要程序實現的功能
3、為什么做軟件測試？ 軟件測試人員需要具備哪些素質？
思維模式:發散性思維，逆向思維，敢于質疑
興趣：對軟件測試感興趣
性格特征：好奇心、敏感、不浮躁、善于懷疑
能力：快速學習能力、溝通能力、文字能力、開發能力、責任感、抗壓能力？
4、軟件測試崗位劃分
按測試對象劃分： WEB測試工程師、APP測試工程師、游戲測試工程師、嵌入式測試工程師
按是否手工： 手工測試、自動化測試
按測試分類： 功能測試、性能測試、安全測試等
5、軟件測試的目的和原則
目的： 驗證軟件有或沒有問題
原則： 以客戶需求為中心，遵循軟件測試的規范、流程、標準和要求
6、什么是軟件需求？
滿足用戶的期望和規定的合同（標準、規范、流程）所需要的條件和權能，包含用戶需求和軟件需求
（1）用戶需求
外部用戶和內部用戶，目標所需的功能，一般比較簡略
（2）軟件需求
又叫功能需求，由用戶需求轉化而成，是對用戶需求的分析，形成比較詳細的需求實現文檔
軟件需求是測試人員進行測試工作的基本依據
7、什么是BUG？
當且僅當規格說明是存在的并且正確，程序與規格說明之間的不匹配才是錯誤
當沒有修去規格說明書時，判斷標準以最終用戶為準：當程序沒有實現其最終用戶合理預期的功能要求時，就是軟件錯誤
軟件Bug實際是軟件產品沒有達到預期設計目標，在軟件內部存在的一種缺陷。在不影響用戶和系統正常運行的情況下處于隱蔽狀態，沒有表現出來。當Bug發生運行錯誤時，輕者影響用戶使用，重者會構成事故，造成損失或傷害。
軟件缺陷分類等級 按其危害程度大致分為4類：
（1）致命缺陷：Bug一旦運行，造成系統奔潰或掛起、數據被破壞。
（2）嚴重錯誤：造成系統不穩定，產生錯誤結果，業務處理嫩合理無法實現。
（3）一般錯誤：用戶在某一功能時出現錯誤，但不影響該功能的實現和系統的正常運行。
（4）細微錯誤：用戶使用軟件時，感覺不方便。（界面不規范、輔助說明描述不清楚、提示窗口文字）
8、Bug產生的原因
軟件缺陷的產生主要是由軟件產品的特點和開發過程決定的
（1）需求不清晰，但至設計目標偏離客戶的需求，從而引起功能或產品特征上的缺陷。
（2）系統結構非常復雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統或系統或維護、擴充上的困難；即使設計成良好的面向對象的系統，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數傳遞、方法調用、對象狀態變化等方面問題。
（3）對程序邏輯路徑或數據范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。
（4）對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調、不一致性帶來的問題。
（5）沒有考慮系統崩潰后的自我恢復或數據的異地備份、災難性恢復等問題，從而存在系統上安全性、可靠性的隱患。
（6）系統運行環境的復雜，不僅用戶使用的計算機環境千變萬化，包括用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；在系統實際應用中，數據量很大，從而引起強度或負載問題。
（7）由于通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題。
（8）新技術的采用，可能涉及技術或系統兼容的問題，實現沒有考慮到。
9、Bug的生命周期
新建bug—指派—已解決—待驗證—關閉
10、如何描述一個Bug
（1）出現問題的版本（版本號）
（2）出現問題的環境
硬件環境：系統所在的硬件設備
軟件環境：瀏覽器的版本、客戶機操作系統等
（3）錯誤重現的步驟
執行測試測試用例時，出現錯誤的步驟 （便于開發人員按照步驟定位）
（4）預期行為的描述
需求期望的描述
（5）錯誤行為的描述
實際情況和預期情況不一致時的情況
（6）測試數據
出現缺陷時輸入的數據
（7）bug的類型
功能錯誤：功能沒有實現
界面優化：UI、用戶界面
設計缺陷：開發、需求文檔中的功能沒有實現
（8）優先級
緊急
重要
一般
11、敏捷開發和敏捷測試
軟件開發的5個模型： 瀑布模型、螺旋模型、迭代、增量、
敏捷開發： 輕文檔、輕流程、重目標、重產出
敏捷開發 的最大特點是高度迭代，有周期性，并且能夠及時、持續地響應客戶的頻繁反饋。
敏捷測試 即是不斷修正質量指標，正確建立測試策略，確認客戶的有效需求能得以圓滿實現和確保整個生產的過程安全的、及時的發布最終產品。
（1）強調從客戶的角度，即從使用系統的用戶角度，來測試系統。
（2）重點關注持續迭代地測試新開發的功能，而不再強調傳統測試過程中嚴格的測試階段。
（3）建議盡早開始測試，一旦系統某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時隨著測試深入，持續進行回歸測試保證之前測試過內容的正確性。
敏捷測試與普通測試的區別
1.項目相當于開發與測試并行，項目整體時間較快。
2.模塊提交較快，測試時較有壓迫感。
3.工作任務劃分清晰，工作效率較高。
4.項目規劃要合理，不然測試時會出現復測的現象，加大工作量。
5.發現問題需跟緊，項目中人員都比較忙，問題很容易被遺忘。
6.耗時、或較難解決對項目影響不大的問題一般會遺留到下個階段解決。
7.發現BUG能夠很快的解決，對相關的模塊的測試影響比較小。
8.版本更換比較勤，影響到測試的速度。
9.要多與開發溝通。
10.要注意版本的更新情況。
11.測試人員幾乎要參加整個項目組的所有會議。
12、軟件測試V模型和W模型
V模型： 每個階段的測試和相應階段的開發是一一對應的，用戶需求–驗收測試、需求分析與系統–系統測試、概要設計–集成測試、詳細設計–單元測試、編碼。缺點： 測試在編碼之后，如果需求分析和設計有錯誤，到后期才能發現，不利于風險的控制。
W模型： 又稱為雙V模型，明確指出了在開發的某個階段，測試相應需要的工作。缺點： 階段依賴性很強，每個階段的開始都依賴于上一階段的完成后才能開始，不是很靈活，不能適用于敏捷開發的模式。
13、軟件開發的生命周期、軟件測試的生命周期
軟件開發的生命周期： 需求分析–計劃–設計–編碼–測試執行–運行維護
軟件測試的生命周期： 需求分析–測試計劃–測試設計、測試開發–測試執行–測試評估
14、什么是測試用例？測試用例的常用設計方法
測試用例： 是為了實施測試而向被測試的系統提供的一組集合，這組集合包含：測試環境、操作步驟、測試數據、預期結果等。
基于需求的設計
（1）等價類劃分法
將測試的范圍劃分成幾個互不相交的子集，他們的并集是全集，從每個子集選出若干個有代表性的值作為測試用例。分為有效等價類和無效等價類
（2）邊界值分析法
根據輸入輸出邊界的一種測試方法，對于在區間min,max的值,測試用例可以記為:min,min+,max,max-。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。
（3）錯誤推測法
在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有正對性地編寫檢查這些錯誤的測試用例的方法。（沒有固定的形式，依靠的是經驗和直覺）
（4）因果圖法
因果圖法最終生成的是判定表。它適合于檢查程序輸入條件的各種組合情況。
（5）正交表分析法
在各種因素相互獨立的情況下，設計出一種特殊的表格，找出能以少數替代全面的測試用例。特殊表格稱為正交表。
（6）場景分析法：指根據用戶場景來模擬用戶的操作步驟
15、什么是B/S結構？什么是C/S結構？
c/s結構 是客戶機/服務器結構。有兩層和多層之分。
服務器端只需要安裝個sql2000服務器，客戶端安裝應用程序，這是典型的兩層結構。
客戶端和服務器端安裝的內容都不一樣，服務器端的安裝抱要大一些，這可能是多層結構。
B/S結構 就是只安裝維護一個服務器（Server），而客戶端采用瀏覽器（Browse）運行軟件bai，即瀏覽器/服務器結構。
1、C/S與B/S結構模式
隨著Internet獲得愈來愈廣泛的應用,原來基于LAN的企業網開始采用Internet技術
來構筑或改建自己的企業網,即Intranet。于是,一種新的結構模式Browser/Server結構
應運而生,并且獲得飛速發展, 成為眾多廠家爭相采用的一種技術。其實,B/S也是一種Clinet/Server結構,它以瀏覽器為客戶端軟件,Web Server為服務器軟件。但相對C/S結構,它又具有許多獨特的優點:
(1) B/S是一種跨平臺的、一點對多點及多點對多點的應用軟件結構,減少了開發人員在客戶端的工作量,使他們可以把注意力集中到怎樣合理地組織信息、提供客戶服務上來。
(2) B/S具有統一的瀏覽器客戶端軟件,不僅節省了開發、維護客戶端軟件的時間與精力,而且方便了用戶的使用。
(3) 在B/S結構中,客戶端只需運行操作系統和Web瀏覽器,數據的查詢、處理和表示都由服務器完成。和C/S結構的應用系統相比,客戶端變得非常"瘦"。
(4) 可以透明地跨越異質網絡、計算機平臺,無縫地聯合使用數據庫、超文本、多媒體等多種形式的信息。
(5) B/S系統運行的Internet易于設置、使用和管理。
16、版本控制工具Git
Git是一個開源的分布式版本控制系統，用以有效、高速的處理從很小到非常大的項目版本管理.
Git 是 Linus Torvalds 為了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。
1. Git簡介
Git是一個版本管理工具，它有協同修改、數據備份、版本控制、權限控制、歷史記錄、分支管理等功能。
協同修改:多人并行不悖的修改服務器端的同一個文件。
數據備份：不經保存目錄和文件的當前狀態，還夠保存每一個提交過的歷史狀態。
版本管理：在保存每一個版本的文件信息的時候要做到不保存重復數據，以節約存儲空間，提高運行效率。Git采取文件系統快照的方式。
權限控制：對團隊中參與開發的人員進行權限控制。除此之外，可以對團隊外開發者貢獻的代碼進行審核，這是git獨有的一個功能。
歷史記錄：查看修改人、修改時間、修改內容、日志信息，將本地文件恢復到某一個歷史狀態。
分支管理：允許開發團隊在工作工程中多條生產線同時推進任務，進一步提高效率。
17、軟件測試的方法
1、從是否關心內部結構來看：
（1）白盒測試：有稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構設計測試數據并完成測試的一種測試方法。
（2）黑盒測試：又稱為數據驅動測試，把測試對象當作看不見的黑河，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求考慮，確定測試用例和推斷測試結果的正確性。它是站在使用軟件或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。
（3）灰盒測試：是一種宗合測試法，它將“黑盒”測試與“白盒”測試結合在一起，是基于程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序并采集路徑執行信息和外部用戶接口結果的測試技術
2、從是否執行代碼來看：
（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。
（2）動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率、正確性和健壯性等性能指標。
3、從開發過程來看：
（1）單元測試：又稱模塊測試，是針對軟件設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在于檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，能滿足其性能和接口要求。
（2）集成測試：又叫組裝測試或聯合，時單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟件單元之間的接口關系，以期望通過測試發現各種軟件單元接口之間存在的問題，最終把經過測試的單元組成符合設計要求的軟件。
（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬件系統進行的測試活動，它是將已經集成好的軟件系統作為基于整個計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、人員、數據等其他系統元素結合一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。
4、在系統測試中，對于具體的測試類型有：
（1）功能測試：對軟件需求規格說明書中的功能需求進行的測試，以驗證功能是否滿足要求。
（2）性能測試：對軟件需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。
（3）接口測試：對軟件修去規格說明書中的接口需求逐項進行的測試。
（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。
（5）強度測試：強制軟件運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟件可以運行到何種程序的測試。
（6）余量測試：對軟件是否達到規格說明書中要求的余量的測試。
（7）安全性測試：檢驗軟件中已經存在的安全性、安全保密性措施是否有效的測試。
（8）可靠性測試：在真實的或仿真的環境中，為做出軟件可靠性估計而對軟件進行的功能（其輸入覆蓋和環境覆蓋一般大于普通的功能測試）
（9）恢復性測試：對有恢復或重置功能的軟件的每一類導致恢復或重置的情況，逐一進行的測試。
（10）邊界測試：對軟件處在邊界或端點情況下運行狀態的測試。
（11）數據處理測試：對完成專門數據處理功能所進行的測試。
（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。
（13）容量測試：檢驗軟件的能力最高達到什么程度的測試。
（14）互操作性測試：為驗證不同軟件之間的互操作能力而進行的測試。
（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。
（16）標準符合性測試：驗證軟件與相關國家標準或規范（如軍用標準、國家標準、行業標準及國際標準）一致性的測試。
（17）兼容性測試：驗證軟件在規定條件下與若干個實體共同使用或實現數據合適轉換時能滿足有關要求能力的測試。
（18）中文本地化測試：驗證軟件在不降低原有能力的條件下，處理中文能力的測試。
5、從執行過程中是否需要人工干預來看：
（1）手工測試：就是測試人員按照事先為覆蓋被測軟件需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟件進行交互（如輸入測試數據、記錄測試結果等），然后觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬于比較原始但是必須執行的一個步驟。
（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）
6、從測試實施組織看：
（1）開發測試：開發人員進行的測試
（2）用戶測試：用戶方進行的測試
（3）第三方測試：有別于開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性
7、從測試所處的環境看：
（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試
（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，并要求用戶報告
18、軟件測試的內容
軟件測試的內容：
1 得到需求、功能設計、內部設計說書和其他必要的文檔
2 得到預算和進度要求
3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標準和過程 ( 例如發行過程、變更過程、等等 )
4 確定應用軟件的高風險范圍，建立優先級、確定測試所涉及的范圍和限制
5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試
6 確定對測試環境的要求 ( 硬件、軟件、通信等 )
7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等
8 確定對測試的輸入數據的要求
9 分配任務和任務負責人，以及所需的勞動力
10 設立大致的時間表、期限、和里程碑
11 確定輸入環境的類別、邊界值分析、錯誤類別
12 準備測試計劃文件和對計劃進行必要的回顧
13 準備白盒測試案例
14 對測試案例進行必要的回顧 / 調查 / 計劃
15 準備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日志和檔案、建立或得到測試輸入數據
16 得到并安裝軟件版本
17 進行測試
18 評估和報告結果
19 跟蹤問題 / 錯誤，并解決它
20 如果有必要，重新進行測試
21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具
總結
- 上一篇： 基于大疆EP和Opencv完成人脸跟随项
- 下一篇： Github拉代码太慢怎么办？