軟件測試定義：
通過手工或者工具對“被測對象”進行測試操作，從而驗證實際結果與預期結果之間是否存在差異。
軟件測試的作用：
1，通過測試工作可以發現并修復軟件當中存在的缺陷，從而提高用戶對產品的使用信心。
2，測試可以記錄軟件運行過程中產生的一些數據，從而為決策提供數據支持。
3，測試可以降低同類型產品開發遇到問題的風險。
測試原則：
所謂的測試原則指的就是我們在執行測試工作時必須要遵守的一些規則。
1，測試證明軟件存在缺陷：無論執行什么樣的測試操作都能證明當前軟件是有缺陷的。
2，不能執行窮盡測試：有些功能是沒有辦法將所有的測試情況都邏輯出來，所以任何的測試操作都有結束的時間。
3，缺陷存在群集現象：對于軟件功能說，核心功能占20%，非核心80%。在實際工作中我們會集中測試20%的核心功能，所以這個部分發現缺陷的幾率就會高于80%。因此我們就會遇到缺陷都集中在20%功能模塊里的現象。
4，某些測試需要依賴特殊的環境。
5，測試應盡早介入：為了更多的發現和更好的解決軟件中的缺陷。我們追求測試工作盡早的開展。
6，殺蟲劑現象：同樣的一個測試用例不能重的執行多次，因此軟件會對它產生免疫。
7，不存在缺陷謬論：任何軟件不可能是完美的。
測試對象的介紹：
對于當前的測試行業來說我們最經常測試的主題就是軟件（主體功能），但是需要我們明白的是一個軟件也不僅僅只有功能需要測試。我們可以將軟件分為三個部分組成：功能集合+使用說明書+配置數據。
測試的階段：
1，需求分析階段：各種需求規格說明書。
2，軟件架構設計：API接口文檔（接口測試）
3，編碼實現階段：源代碼（白盒測試，單元測試）
4，系統功能使用：軟件功能主題（當前行業做的最多的一種測試）
測試級別
常見的測試分類：
1，單元測試（UT unit test）：在軟件測試中單元指的就是組成軟件最小的底層代碼結構，一般就是類，函數，組成（當下的軟件測試行業，不會刻意要求測試人員對源代碼進行測試）。
2，集成測試（IT system ingertaion test）：將多個單元模塊組合在一起，然后驗證他們之間溝通的“橋梁”是否能正常工作（接口測試）
3，系統測試（ST system test）：這是當前行業做的最多的一種測試。由于測試人員充當用戶然后對軟件的功能主體進行測試。
4，驗收測試：
（1）a測試----內側
（2）β測試----公測
（3）UAT（user acceptance test）測試----由客戶派出對于業務非常精通的人員來使用該動能，從而對功能進行測試。
（4）驗收測試的核心就是讓用戶為當前軟件“買單”
（5）
系統測試分類：
1，功能測試：驗收當前的軟件主體功能是否可用。
2，兼容性測試：驗收當前軟件在不同的環境下是否還可以使用。
3，安全測試：驗證軟件是否是能授權用戶提供功能使用。
4，性能測試：相對于當前軟件消耗的資源它的產出能力。
1.8 常見的系統測試方法
一，按測試對象進行分類
1，白盒測試：這種測試的主題就是軟件的底層代碼，不會在意外在的界面是否OK，只要求底層功能實現，同時邏輯正確。
2、黑盒測試：這種測試指的是被測軟件外在主體功能是否可用
3，灰盒測試：介于兩者之間（接口測試）
4，上述三種方法當中的“盒”指的就是被測對象。
黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯
系？
黑盒測試：把測試對象當成一個黑盒子，測試人員完全不考慮邏輯結構和內部特性， 只依據程式的需求說明書
來檢查程式的功能是否滿足它的功能說明。
白盒測試：把測試對象當成一個透明的盒子，允許測試人員利用程序內部邏輯結構及 相關信息，設計或選擇測
試用例，對程式所有邏輯路徑進行測試。
單元測試：白盒測試的一種，對軟件設計中的單元模塊進行測試。
集成測試：在單元測試的基礎上，對單元模塊之間的連接和組裝進行測試。
系統測試：在所有都考慮的情況下，對系統進行測試。
驗收測試：第三方進行的確認軟件滿足需求的測試。
黑盒有等價類劃分法，邊界分析法，因果圖法和錯誤猜測法。
白盒有邏輯覆蓋法，循環測試路徑選擇，基本路徑測試。
黑盒? 白盒? 灰盒區別：
黑盒是模擬用戶操作，點點看看；
白盒是像程序員一樣，對一個未成型的，可能看到代碼的產品進行輸入輸出測試；
灰盒是對介于二者之間的過程測試。
黑盒測試關注程序的功能是否正確，面向實際用戶；
白盒測試關注程序源代碼的內部邏輯結構是否正確，面向編程人員；
灰盒測試是介于白盒測試與黑盒測試之間的一種測試。
所以通俗來講黑盒測試就是看我開始用一個軟件，它可以滿足我的需求不出錯嗎？
白盒測試就是我寫的程序代碼是不是沒有問題呢，我得在源程序中看看。
灰盒測試就是綜合兩種測試策略。
簡述黑盒測試和白盒測試的優缺點？
黑盒測試的優點有：黑盒測試關注程序的功能是否正確,面向實際用
1.比較簡單，不需要了解程序內部的代碼及實現；
2.與軟件的內部實現無關；
3.從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
4.基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
5.在做軟件自動化測試時較為方便。
黑盒測試的缺點有：
1.不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；
2.自動化測試的復用性較低。
白盒測試的優點有：白盒測試關注程序源代碼的內部邏輯結構是否正確,面向編程人員
灰盒測試是介于白盒測試與黑盒測試之間的一種測試。
所以通俗來講黑盒測試就是看我開始用一個軟件，它可以滿足我的需求不出錯嗎？
白盒測試就是我寫的程序代碼是不是沒有問題呢，我得在源程序中看看。
灰盒測試就是綜合兩種測試策略。
比較簡單，不需要了解程序內部的代碼及實現；
與軟件的內部實現無關；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
在做軟件自動化測試時較為方便。
軟件質量特性：
描述當前軟件是否好用，在當前的軟件行業里我們所采用的一套標準是基于ISO組織制定的。需要我們記憶的就是軟件質量的六大特征：
1，功能性：軟件需要滿足用戶顯示或者穩式的功能。
2，易用性：軟件易于學習和上手使用。
3，可靠性：指的就是軟件必須實現需求當中指明的具體功能。
4，效率型：類似于軟件的性能。
5，可維護性：需求軟件具有將某個功能修復之后繼續使用的功能。
6，可移植性：當前軟件可以從一個平臺移植到另一個平臺上去使用的能力。（功能靠用，效率可“以”）
軟件測試的流程：
? 從產品接到需求開立項會，確立需求文檔，測試進行編寫測試計劃，根據需求文檔進行編寫測試用例，開發進行編碼，等編碼結束會對主要功能進行冒煙測試，測試執行測試用例，
如果發現bug進行提交bug，開發進行修改，當開發修改后對bug進行在次的回歸測試（1.bug是否已經解決，2.解決后的bug是否對正常功能的影響）如果bug修改完成測試將bug的狀態改為關閉，如果bug沒有修改或者是修改后對其他的功能進行影響則bug重新打開并在次提交
需求分析：
1，當前階段的核心目的就是梳理清楚我們需要設計的點是什么
2，需求的來源：需求規格說明書，API文檔，競品分析，個人經驗
如果公司內部沒有需求文檔或者是API文檔你怎么做測試：
1.根據公司的產品進行對同行業或是同類軟件進行分析，找到相關文檔。
2.根據跟人經驗對軟件進行測試
3.先做到UI頁面和業務邏輯是否匹配? 在進行功能模塊的實現能否正常 然后在整個軟件進行系統分析并實現，然后開展性能測試或者是接口測試
4.沒有api文檔的時候? 進行接口測試? 可以通過抓包工具（charles /fiddler）來獲取接口相關信息（url 請求方式 參數 響應結果等）進行對單個接口測試或者是通過接口錄制（bodboy 對web端進行錄制? jmeter對移動端的錄制） 實現多接口或者一個業務場景進行接口測試
5.進行性能測試或者是自動化測試
測試計劃：
? ? ? 測試背景? 測試目的? 測試需求（軟件 硬件 人員） 測試用例的設計以及評審
? 執行進度? bug跟蹤? 風險評估
如何做測試用例的評審？
1.是否覆蓋測試需求上的所有功能點，不違背產品原型和代碼設計，用例設計的結構安排是否清晰合理，有利于高效覆蓋需求
2.用例是否具有可執行性，前提條件、執行步驟和預期結果是否正確，有明確的驗證方法。優先級安排是否合理
3.是否從用戶層面來設計用戶使用的場景和業務流程
4.是否包含充分的異常測試用例
5.是否簡潔，不冗余，復用性強
******
如何設計測試用例
? ? 用例的設計點：
? ? ? 1功能上
2.UI頁面
3.性能
4.安全
5.弱網
6.易用性
1，用例就是用戶為了測試軟件的某個功能而執行的操作過程
2，設計用例是有方法的（等價類，邊界值，判定表......）
評審用例
對當前的用例進行添加或者刪除
配置環境
1，環境：指的就是當前被測對象運行所需要的執行環境，作為測試人員需要具備配環境的能力。（一般情況下都會使用一鍵安裝的集成環境）
2，環境分類：操作系統+服務器軟件+數據庫+軟件底層代碼的執行環境
執行用例
1，一般在執行用例之前我們會做一個冒煙測試。這種測試的核心就是快速的對當前軟件的核心功能或者主體執行流程進行驗證。如果冒煙測試階段有問題，則可以將此版本回退給開發
2，如果冒煙測試通過那么才會開展示全面的測試
回歸測試及缺陷跟蹤
1，回歸測試指的就是當我們將某個缺陷提交給開發之后，由他們進行修復，修復完成之后需要測試人員再次對其進行測試（回歸測試）
2，缺陷跟蹤：指的就是當測試人員發現某個缺陷之后需要一直對其進行狀態的跟蹤
輸出測試報告
將當前的測試過程中產生的數據進行可視化的輸出，方便其他人去查看
測試結果
當將整個測試過程中產生的一些文檔進行整理歸檔，方便后續版本使用
在測試過程中 如果開發人員說改bug不是bug的你怎么辦?
在多次測試以及不同的測試環境中測試后將bug的復現步驟進行總結并提交開發人員讓開來確認
? 可以找項目經理或者產品經理根據根據規格說明書來進行對bug進行確認是否為bug
? 測試人員可以將bug的內容和步驟以及相關內容（1，執行的測試用例）保存進行到測試總結中，留意在后期出問題進行文件提供。
軟件架構
所謂的軟件架構我們可以理解為是用來指導我們軟件開發的一種思維，目前來說最常見的兩種架構模式就是b/s? c/s
b---browser 瀏覽器
C----clent 客戶端
S----server 服務端
兩種架構的比較
1，標準：相對于cs架構來說bs架構的兩端都是在使用現成的成熟產品。所以bs會顯示的標準一些。
2，效率：相對bs架構來說cs中的客戶端可以分擔一些數據的處理，因此執行效率會高一些
3，安全：bs架構當中得到數據傳輸都是以HTTP協議進行的輸出，而HTTP協議又是明文輸出。可以被抓包，所以相對于cs架構來說bs就顯得不那么安全（相對的）
4，升級：bs架構只需要在服務器端將數據進地更新，前臺只需要刷新頁面就可以完成升級，而cs架構當中必須要將兩端都進行更新
5，開發成本：相對于bs架構來說cs當中的客戶端需要自己開發，所以相對于來說成本會高一些
瀏覽器基本介紹
瀏覽器是什么
瀏覽器本身就是一款軟件，安裝在操作系統之上。一般給用戶提供瀏覽網頁的服務。目前來說我們會認為的將所有瀏覽器總結出一個所謂的五大生產廠商。（對于瀏覽器來說最核心的技術就是內核）
五大瀏覽器生產廠商
1，IE（微軟）---- trident
2，Chrome（谷歌）---- blink
3，Firefox（火狐）---- gecko
4，Safari（蘋果）---- webkit
5，Opera（歐朋）---- presto（現在已經放棄自己的東西完全向Chrome）
圖片類型
1，JPG（JPEG）：這是一種可以高度保留圖片色彩信息的格式
2，PNG：該類型的圖片可以實現透明
3，GIF：圖片所占體積小，可以實現動圖
4，PSD：它是一種分層的圖片
測試用例? 定義：
? ? ? 要素：? 用例編號? 所屬模塊? 前提條件? 測試輸入? 預期結果 實際結果
? 備注? 版本? 測試人? 測試日期
? ? 測試方法：
? 等價類劃分? 因果圖? 邊界值? 正交法? 錯誤推斷法? 場景法
面試題：
? ? 在項目中的哪些場景中運用了測試方法
測試用例的評審：
評審內容
評審的內容有以下幾個方面
1)用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
2)優先極安排是否合理。
3)是否覆蓋測試需求上的所有功能點。
4)用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確期待結果是否有明顯的驗證方法。
5)是否已經刪除了冗余的用例。
6)是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼都是在"保護"20%的功能實現。
7)是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
8)是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟
分為組內和組外評審：
組內評審的人員：? 測試Leader 和 測試人員
組內評審著重與? 1. 用例的冗余性
2.用例的準確性
3.用例的覆蓋度? 70%-80%
4.用例滿足需求
組外評審：? 測試leader? 測試人員? 項目經理? 產品經理
組外評審：? 1.是否滿足軟件的需求
2.用例覆蓋率
3.用例的執行性
4.用例的復用性
5.用例是否具有正反的用例
6.編寫用例的模板
7.非功能性測試用例的編寫
8.缺陷率在執行的測試用例中的占比
測試計劃：
開發團體人員：? 5：1
? 10人開發團隊? ? ? 1 UI? 5個后臺開發? 2個移動端? ? 1個測試/運維? 1產品
項目開發周期：? 6個月?
版本迭代：? 大版本? 1個半月? ? 小版本 1周?
測試分工：? 功能界面? 性能+接口? 自動化
