• 1. 軟體測試背景
  • 1.1軟體缺陷測試與軟體故障
    • 一、軟體缺陷與軟體故障案例
  • 二、 軟體缺陷定義
  • 1.2軟體缺陷產生的原因
  • 1.3軟體測試和缺陷修復的代價
  • 2.軟體測試基礎理論
  • 2.1軟體測試定義
  • 2.2軟體測試的現狀
  • 2.3軟體測試的前景
  • 2.4新人如何融入一個專案團隊
  • 2.5、優秀的測試人員的基本素質
  • 2.6、軟體工程的目的
  • 2.7程式測試包含哪些內容
  • 2.8測試環境
  • 2.9測試流程
  • 3.測試的分類
  • 3.1黑盒測試和白盒測試
  • 3.2靜態測試和動態測試
  • 3.3功能測試和效能測試
  • 1.1.2.效能測試
  • 3.4迴歸測試、冒煙測試、隨機測試
    • 迴歸測試
    • 冒煙測試
    • 隨機測試
  • 3.5單元測試、整合測試、系統測試和驗收測試
  • 1.1.6.單元測試
  • 1.1.7整合測試
  • 1.1.8系統測試和驗收測試
  • 3.6測試案例（需求：500ml的水杯）
  • 1.1.9需求：(功能，效能，介面，安全，易用)
  • 1.1.10功能測試
  • 1.1.11介面測試
  • 1.1.12效能測試
  • 1.1.13安全性測試
  • 1.1.14易用性測試

1. 軟體測試背景

軟體測試在軟體生命週期中佔據重要的地位，軟體測試慢慢的獨立發展成為一個行業，並且在迅猛發展。

1.1軟體缺陷測試與軟體故障

一、軟體缺陷與軟體故障案例

二、 軟體缺陷定義

對於軟體缺陷的精確定義，通常有下列描述：
1.軟體出現了產品說明書指明不會出現的錯誤
2.軟體未達到的《需求文件》中規定的功能
3.軟體功能超出產品說明書指明範圍
4.軟體測試員認為難以理解、不易使用、執行速度緩慢、或者終端使用者認為不好
 

1.2軟體缺陷產生的原因

缺陷從哪來？第一大原因就是軟體產品規格說明書，很多情況下，說明書沒有寫，或寫的不夠全面，經常更改，或者開發小組沒有很好的溝通，造成對說明書理解的不一致。第二大原因是軟體設計，沒有做設計或設計不好，經常變動等和產品規格說明書一樣的問題，第三個原因才是編寫程式碼和其它原因；前兩個原因至少佔了 80%以上。如圖1-1所示

通過大量的測試理論研究及測試實踐經驗的積累，典型的軟體缺陷產生的原因被歸納為以下幾種型別：
(1)需求解釋有錯誤；
(2)使用者需求定義錯誤；
(3)需求記錄錯誤；
(4)設計說明有誤；
(5)編碼說明有誤；
(6)程式程式碼有誤；
(7)測試錯誤；
(8)問題修改不正確；
(9)不正確的結果是由於其他的缺陷而產生。
 

1.3軟體測試和缺陷修復的代價

缺陷發現的越早，則修復這個缺陷的代價就越小，在需求、設計、編碼、測試、釋出等不同的階段，發現缺陷後修復的代價都會比在前一個階段修復的代價提高10倍（參見圖1-2）。

2.軟體測試基礎理論

軟體測試是保證軟體質量的一種手段，那麼，什麼叫軟體測試？

2.1軟體測試定義

軟體測試（英語：Software Testing），描述一種用來促進鑑定軟體的正確性、完整性、安全性和質量的過程。換句話說，軟體測試是一種實際輸出與預期輸出之間的稽核或者比較過程。軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。

2.2軟體測試的現狀

根據中國調研報告網釋出的《2019年中國軟體測試行業現狀研究分析與市場前景預測報告》顯示，軟體軟體測試企業以非外包公司為主，其中傳統IT企業、網際網路企業數量佔比超過50%.軟體測試企業中對軟體測試己有較高的認可度和重視度。
隨著對軟體測試的重視，企業測試人員與開發人員比基本保持在1： 3的比例。比例在1： 7以上的近幾年來下降趨勢明顯。向其他比例分散轉變，說明多數公司的測試理念已發生改變，對專業測試的重視程度逐步加強；而1：3的比例近年的持續緩慢上升，也體現出在未來幾年國內企業對這種人員配比傾向度較高。

2.3軟體測試的前景

2.4新人如何融入一個專案團隊

2.5、優秀的測試人員的基本素質

1、參與需求討論，制訂測試計劃，確保測試能順利執行並完成。 2、負責專案的功能性測試、使用者體驗測試、相容性測試以及效能測試 3、負責測試用例的編寫；編寫測試報告和對測試結果分析， 4、與開發人員、產品經理溝通和協作，推動整個專案的順利進行； 5、負責軟體開發團隊專案進度管理工作，6.熟悉Linux常用命令，熟悉常用資料庫，熟練使用基本的SQL語句； 7.熟練使用Loadrunner，Jmeter等至少一種效能測試工具

2.6、軟體工程的目的

成本：專案的開銷，人工成本，工具成本，裝置成本，錯誤成本（BUG）
進度：時間，計劃
質量：軟體對顧客需求的滿意程度，一個低質量的軟體，即使生產成本很低，進度控制良好，顧客也難以接受。

2.7程式測試包含哪些內容

程式測試包括程式邏輯功能，介面，效能，易用性，相容性，安裝等測試，當然文件測試也算，排版，字型大小，也算程式測試的內容

2.8測試環境

測試環境=硬體+軟體+網路
硬體環境：筆記本,桌上型電腦，伺服器
軟體環境：不同的作業系統 windows10   windows8   windows7   Linux   Mac，
不同瀏覽器firefox  chrom
網路:區域網還是網際網路

2.9測試流程

3.測試的分類

3.1黑盒測試和白盒測試

黑盒測試(Black Box -Test)指的是把被測試的軟體看做一個黑盒子，我們不去關心盒子裡邊的結構是什麼樣子，只關心軟體的輸入資料和輸出結果

有人把黑盒測試比作中醫，通過“望聞問切”來判斷是否有問題。

“望”：觀察軟體的行為是否正常。

“聞”：檢查輸出的結果是否正確。

“問”：輸入各種資訊，結合“望”，“聞”來觀察軟體的響應。

“切”：像中醫一樣給軟體“把把脈”，敲擊一下軟體的某些“關節”

 
白盒測試(White Box Testing),指的是把盒子蓋開啟，去研究裡邊原始碼和程式結構。

3.2靜態測試和動態測試

靜態測試，是指不實際執行被測試軟體，而只是靜態的檢查程式程式碼、介面或者文件中可能存在的錯誤的過程。

動態測試:是指實際執行被測程式，輸入相應的測試資料，檢查實際輸出結果和預期結果是否相符的過程。

3.3功能測試和效能測試

是黑盒測試的一部分，它檢查實際軟體的功能是否符合使用者的需求。

功能測試可以細分邏輯功能測試，介面測試，易用性測試，安裝測試和相容性測試。

邏輯功能測試:測試應用是否符合邏輯，比如應該先註冊賬號之後，才能進行登入,登入之後才能看我的購物車

介面測試:視窗大小，按鈕大小，點選按鈕彈出什麼樣的提示框，是否有滾動條，下拉選單是否有展示內容...

易用性測試:從軟體使用的合理性和方便性等角度對軟體系統進行檢查,比如，軟體視窗長寬比例是否合適，顏色色彩是否賞心悅目，字型大小是否合適

相容性測試:硬體相容性測試和軟體相容性測試

硬體相容性:比如一款軟體在pc機，筆記本,主機上是否相容

軟體相容性測試:比如一款軟體在windows8和windows10上是否相容

1.1.2.效能測試

時間效能:軟體的一個具體事務的響應時間。比如點選一個登陸按鈕，到登入成功(失敗)的反應時間，瀏覽器非常常見，ANR（Application not responding 應用程式無響應）

空間效能:軟體執行時所消耗的系統資源，比如對記憶體和cpu的消耗

一般效能測試:軟體正常執行，不向其施加任何壓力的測試

穩定性測試:也叫可靠性測試，是指連續執行被測系統，檢查系統執行時的穩定程度。
7
負載測試:讓被測系統在其能夠忍受的壓力範圍之內連續執行，來測試系統的穩定性。（測試載重）

壓力測試:持續不斷的給被測試的系統增加壓力，直到被測試的系統壓垮為止，用來測試系統所承受的最大壓力。（測試強度）

3.4迴歸測試、冒煙測試、隨機測試

迴歸測試

是指對軟體的新版本進行測試時，重複執行上一個版本測試時的用例，比如在1.0版本中，有一個bug，到了2.0版本中,再重新測試1.0中這個bug（迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。）

冒煙測試

指對一個軟體進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性。

測試小組在正式測試一個新版本之前，先指派一兩個測試人員測試一下軟體的主要功能，如果沒有實現，則打回開發組重新開發，這樣做可以節省大量的時間成本和人力成本。

隨機測試

是指測試中所有的輸入資料都是隨機生成的，其目的是模擬使用者的真實操作，並發現一些邊緣性的錯誤。

3.5單元測試、整合測試、系統測試和驗收測試

1.1.6.單元測試

單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函式，Java裡單元指一個類，圖形化的軟體中可以指一個視窗或一個選單等。
總的來說，單元就是人為規定的最小的被測功能模組。

單元測試當一段程式碼完成之後，是由白盒測試工程師或者開發人員自行測試，比如java中執行單元測試叫做junit測試。

目前大部分公司單元測試由開發人員簡單編譯和除錯一下自己的程式，沒有相應的單元測試計劃。

單元測試方式:先靜態地觀察程式碼是否符合規範，然後動態地執行一下程式碼,檢查執行的結果。

1.1.7整合測試

整合測試是單元測試的下一個階段，是指將通過測試單元模組組裝成系統或者子系統，再進行測試，重點測試不同模組的介面部分。

在把各個模組連線起來的時候，穿越各個模組的介面的資料時候會丟失
一個模組的功能是否會對另一個模組的功能產生不利的影響
各個子功能組裝完成後，能否達到預期的父功能
全域性資料結構是否有問題
單個模組產生的誤差累計起來是否會放大
例如：模組介面測試
應對通過所測模組的資料流進行測試
呼叫所測模組時的輸入引數與模組的形式引數的個數、屬性和順序是否匹配
所測模組呼叫子模組時，輸入子模組的引數與子模組的形式引數在個數、屬性和順序上是否匹配。
輸出給標準函式的引數的個數、屬性和順序是否正確

1.1.8系統測試和驗收測試

整合測試完成之後，就是系統測試和驗收測試。

系統測試:指的是將整個軟體系統看做一個1個整體進行測試，包括對功能、效能，以及軟體所執行的軟硬體環境進行測試。

系統測試由黑盒測試人員在整個系統整合完畢後進行測試，前期主要測試系統的功能是否滿足需求，後期主要測試系統執行的效能是否滿足需求，以及系統在不同的軟硬體環境的相容性等。

驗收測試：以使用者為主的測試，軟體開發人員和質量保證人員參加

3.6測試案例（需求：500ml的水杯）

1.1.9需求：(功能，效能，介面，安全，易用)

測試一個帶廣告圖案的花紙杯

1.1.10功能測試

能否裝水，
除了裝水， 能否裝其他液體。比如可樂，酒精
能裝多少ML的水
杯子是否有刻度表
杯子能否泡茶，跑咖啡
杯子是否能放冰箱，做冰塊
杯子的容量是否於需求一致（500ml）

1.1.11介面測試

外觀好不好看。
什麼顏色
杯子的形狀是怎麼樣的。
杯子的圖案是否合理
杯子外觀是否簡單，美觀（需求文件）
杯子大小是否一致
杯子的材質是否與需求一致

1.1.12效能測試

能否裝100度的開水 (泡茶)
能否裝0度冰水
裝滿水，長時間放置是否漏水(7*24)
能否使用的最大的次數（漏水）
杯子內壁上的塗料是否容易脫落。
杯子上的顏色是否容易褪色或者脫落
掉在地上不易摔碎
如果是有蓋子的：
	蓋子擰多緊不會漏水

1.1.13安全性測試

製作杯子的材料，是否有毒
放微波爐裡轉的時候，是否會熔化。
杯子盛放熱水是否釋放難聞氣味(毒味)
杯子是否容易滋生細菌
杯子內壁上的材料，是否會溶解到水中
裝進不同液體，是否會有化學反應。

1.1.14易用性測試

杯子是否容易燙手
杯子是否好端，好拿
杯子的水是否容易喝到
杯子是否有防滑措施
是否能接受杯子的廣告內容與圖案 

4.測試分類佔比

5.軟體測試的原則

6.軟體的開發模式

6.1線性模型與漸進式模型

線性模型：最常見的“瀑布模型”，基礎框架，但缺點在於“整合之日就是爆炸之日”。（立項分析-需求分析-設計-編碼-測試-維護）很多企業使用後使用迭代進行修改。

漸進式模型：最常見的“螺旋模型”，（需求分析-風險分析-設計、編碼-測試、評審），迭代開發和增量開發模式。

注意：每一次迭代原型出來後，測試人員都需要從原型介面，系統主要功能，效能等方面對原型進行評審。

6.2迭代和增量的理解

7.1. 軟體生命週期模型

軟體生命週期 同任何事物一樣，一個軟體產品或軟體系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟體生命週期（軟體生存週期）[1] 。軟體生命週期模型是指人們為開發更好的軟體而歸納總結的軟體生命週期的典型實踐參考。

7.1邊做邊改模型

許多產品都是使用“邊做邊改”模型來開發的。在這種模型中，既沒有規格說明，也沒有經過設計，軟體隨著客戶的需要一次又一次地不斷被修改.
在這個模型中，開發人員拿到專案立即根據需求編寫程式，除錯通過後生成軟體的第一個版本。在提供給使用者使用後，如果程式出現錯誤，或者使用者提出新的要求，開發人員重新修改程式碼，直到使用者滿意為止。
這是一種類似作坊的開發方式，對編寫幾百行的小程式來說還不錯，但這種方法對任何規模的開發來說都是不能令人滿意的，其主要問題在於：
（1） 缺少規劃和設計環節，軟體的結構隨著不斷的修改越來越糟，導致無法繼續修改；
（2） 忽略需求環節，給軟體開發帶來很大的風險；
（3） 沒有考慮測試和程式的可維護性，也沒有任何文件，軟體的維護十分困難。

7.2瀑布模型

瀑布模型是最早出現的軟體開發模型，在軟體工程中佔有重要的地位，它提供了軟體開發的基本框架。其過程是從上一項活動接收該項活動的工作物件作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對於經常變化的專案而言，瀑布模型毫無價值。
瀑布型簡單地說就是按照需求、設計、編碼、測試、軟體維護這個基本的順序來研發軟體，前面一個步驟不完成，後面的步驟不能開始，否則問題會滾到下個階段，帶來更多的問題

優點：
1) 為專案提供了按階段劃分的檢查點
2) 當前一階段完成後，只需要去關注後續階段。
缺點：
1）各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。
2）由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
3）通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
4）瀑布模型的突出缺點是不適應使用者需求的變化。

7.3原型化模型

原型化模型的第一步是建造一個快速原型，實現客戶或未來的使用者與系統的互動，經過和使用者針對原型的討論和交流，弄清需求以便真正把握使用者需要的軟體產品是什麼樣子的。充分了解後，再在原型基礎上開發出使用者滿意的產品。
如圖所示：原型嚴格來說不算一種軟體生命週期模型，它只是一種獲取需求的方法，在實際工作中該方法是相當重要的方法。
模型要點：瀑布和原型模型相結合，強調版本升級。

該模式的特點是一次性地獲取全部的需求，然後做出分版本實現各需求的計劃，每個版本只實現一部分需求，通過多個版本逐步實現全部需求，而每個版本可以認為是一個“小瀑布”。
該模型的好處是可以儘快讓系統上線，讓客戶先使用部分功能，儘早實現系統的價值。
該模型比較能符合實際的情況，我們往往也是通過多個版本來逐步實現全部需求，但需求是不可能在一開始就完全確定的，實際情況是往往只能確定80%，而後期通過各版本我們還會獲取更多的新需求以及需求調整。將此模型稍微調整後，可以適用於大部分的實際專案。

7.4增量模型

增量模型也是原型化開發方法。如圖所示

7.5螺旋模型

螺旋模型是一個演化軟體過程模型，將原型實現的迭代特徵與線性順序（瀑布）模型中控制的和系統化的方面結合起來。使得軟體的增量版本的快速開發成為可能。在螺旋模型中，軟體開發是一系列的增量釋出。螺旋模型的整個開發過程如圖所示。

圖中的螺旋線代表隨著時間推進的工作進展；開發過程具有周期性重複的螺旋線形狀。4個象限分別標誌每個週期所劃分的4 個階段：制定計劃、風險分析、實施工程和客戶評估。螺旋模型要點：統一了瀑布模型與原型模型，與增量模型相似，更強調風險分析。
1.軟體分多個版本開發，每個版本就是一次螺旋。
2.每個版本按照這樣的順序進行：
   1）確定軟體目標，選取定實施方案，弄清專案開發的限制條件；（圖中左上象限）
   2）分析所選取方案，考慮如何識別和消除風險；（圖中右上象限）
   3）實施軟體開發；（圖中右下象限）
   4）評價開發工作，提出修正建議，調整計劃。（圖中右下象限、左下象限）
3.需求不是一次獲取和實現的，通過多個螺旋來完善。
4.計劃也不是一次成型的，每次螺旋都需要調整。


優點：
1）設計上很靈活，可以在專案的各個階段進行變更；
2）以小的分段來構建大型系統，使成本計算變得簡單容易；(國企專案)
3）客戶始終參與每個階段的開發，保證了專案不偏離正確方向以及專案的可控性；
4）隨著專案推進，客戶始終掌握專案的最新資訊 , 從而能夠和管理層有效地互動；
5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。


缺點：
螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的。
因此，這種模型往往適應於內部的大規模軟體開發。該模型建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。

7.6V模型

V 模型的左邊下降的是開發過程各階段，與此相對應的是右邊上升的部分，即各測試過程的各個階段。
V 模型的優點在於它非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發各階段的對應關係。
V模型的缺陷及解決思路
V模型僅僅把測試過程作為在需求分析、系統設計及編碼之後的一個階段，忽視了測試對需求分析,系統設計的驗證，需求的滿足情況一直到後期的驗收測試才被驗證。
解決的思路是，當一個軟體開發的時候，研發人員和測試人員需要同時工作，測試在軟體做需求分析的同時就會有測試用例的跟蹤，這樣，可以儘快找出程式錯誤和需求偏離，從而更高效的提高程式質量，最大可能的減少成本，同時滿足使用者的實際軟體需求。

優點：
1 每一個階段都清晰明瞭，便於控制開發的每一個過程。
2 既包含單元測試又包含系統測試。
缺點：
1 測試介入的比較晚，對於前期的一些缺陷無從發現和修改。
2 測試和開發序列。

7.7Ｗ模型

相對於V模型，W模型更科學。W模型是V模型的發展，強調的是測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於儘早地發現問題。
優點
1 測試伴隨著軟體的整個生命週期，例如，在需求分析結束後就可以進行需求分析測試。
2 測試於開發是並行獨立進行的。
缺點
1 對有些專案，開發過程中根本沒有文件產生，故W模型無法使用。
2 對於需求和設計的測試技術要求很高，實踐起來很困難。

8.軟體測試的常識知識

8.1測試部門的組織結構

9.軟體測試工具

https://zhidao.baidu.com/question/8152959.html
軟體測試工具是通過一些工具能夠使軟體的一些簡單問題直觀的顯示，使測試人員更好的找出軟體錯誤所在。
軟體測試工具分為自動化軟體測試工具和測試管理(禪道)工具。
軟體測試工具存在的價值是為了提高測試效率，用軟體來代替一些人工輸入。
測試管理工具是為了複用測試用例，提高軟體測試的價值。
一個好的軟體測試工具和測試管理工具結合起來使用將會使軟體測試效率大大的提高。
Bug管理工具：  禪道 Jira（付費）,Trac,gitlab
自動化   python+ selenium ，python+ appnium （ui自動化） pytest,unites,Junit (測試用例 單元測試)  innerHtml  （傳送測試報告） request +python+allure 介面自動化
效能測試工具   jmeter ,Loadrunner、
抓包工具       Fiddler ,charles (弱網測試的)
介面工具      postman ，jmeter 
錄製指令碼      bodyboy  jmeter

雲測    騰訊雲   模擬不同的移動端或者是web瀏覽器

命令  Linux  adb  monkey
資料庫  myql,oracle,redis
語言  python,java,c,c++

9.1 WinRunner

Winrunner 最主要的功能是自動重複執行某一固定的測試過程，它以指令碼的形式記錄下手工測試的一系列操作，在環境相同的情況下重放，檢查其在相同的環境中有無異常的現象或與預期結果不符的地方。可以減少由於人為因素造成結果錯誤，同時也可以節省測試人員大量測試時間和精力來做別的事情。功能模組主要包括：GUI map、檢查點、TSL 指令碼程式設計、批量測試、資料驅動等幾部分

9.2 LoadRunner

商業化-掙錢 效能測試工具 響應時間，CPU，記憶體，吞吐量....
LoadRunner® 是一種預測系統行為和效能的工業標準級負載測試工具。通過以模擬上千萬使用者實施併發負載及實時效能監測的方式來確認和查詢問題，LoadRunner 能夠對整個企業架構進行測試。通過使LoadRunner ，企業能最大限度地縮短測試時間，優化效能和加速應用系統的釋出週期。LoadRunner 是一種適用於各種體系架構的自動負載測試工具，它能預測系統行為並優化系統性能。LoadRunner 的測試物件是整個企業的系統，它通過模擬實際使用者的操作行為和實行實時效能監測，來幫助您更快的查詢和發現問題。此外，還能支援廣範的協議和技術，為您的特殊環境提供特殊的解決方案

9.3 QTP

測試管理工具
基於WEB的測試管理工具，他能夠讓你係統地控制整個測試過程，並建立整個測試工作流的框架和基礎，使整個測試管理過程變得更為簡單和有組織。他能夠幫助你維護一個測試工程資料庫，並且能夠覆蓋你的應用程式功能性的各個方面。T並且還為你提供了直觀和有效的方式來計劃和執行測試集、收集測試結果並分析資料。還專門提供了一個完善的缺陷跟蹤系統。並可以同Mercury公司的測試工具、第三方或者自主開發的測試工具、需求和配置管理工具、建模工具的整合功能。你可以通過他進行需求定義、測試計劃、測試執行和缺陷跟蹤，即整個測試過程的各個階段

9.5 Selenium

自動化測試工具 支援java python的指令碼 python
   自動化--寫好指令碼，執行指令碼，自己執行，自己出測試報告，自己傳送到測試和開發郵箱
80%bug 手動測試出來
Selenium是為正在蓬勃發展的web應用開發的一套完整的測試系統。Selenium測試直接執行在瀏覽器中，就像真正的使用者在操作一樣。它的主要功能包括：測試與瀏覽器的相容性——測試你的應用程式看是否能夠很好得工作在不同瀏覽器和作業系統之上。測試系統功能——建立衰退測試檢驗軟體功能和使用者需求。支援自動錄製動作和自動生成。Selenium的核心Selenium Core基於JsUnit，完全由JavaScript編寫，因此可運行於任何支援JavaScript的瀏覽器上，包括IE、Mozilla Firefox、Chrome、Safari等

9.6 Appium

自動化測試工具，android和ios軟體 手機App app 
Appium是一個開源、跨平臺的，適用於原生或混合移動應用(hybrid mobile apps)的自動化測試平臺。Appium使用WebDriver（JSON wire protocol）驅動安卓和iOS移動應用.Appium的設計哲學是不要為了移動端的自動化測試而重新發明輪子，重新寫一套驚天動地的api，也就是說webdriver協議裡的api已經夠好了，拿來改進一下就可以了另外Appium可以把server放在任意機器上，哪怕是雲伺服器都可以，所以Appium和WebDriver天生適合做雲測試。

9.7Jmeter

開源，免費，簡單，易操作。 開源組織，支援指令碼錄製，支援抓包測試，支援測試移動端軟體
壓力和負載測試

9.8postman

介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

介面測試的目的是測試介面，尤其是那些與系統相關聯的外部介面，測試的重點是要檢查資料的交換，傳遞和控制管理過程，還包括處理的次數。外部介面測試一般是作為系統測試來看待的。
介面自動化

介面上傳引數的正確性，和伺服器返回值的正確性，容錯性驗證(滴滴)，以及安全性檢測。

9.9抓包測試

包是指資料包.目的是分析包的內容與相關協議,然後衡量是否符合當初的設計或排除故障.
在被測介面並沒有明確的介面文件給出時，我們需要藉助抓包工具來幫助測試，利用抓包工具我們幾乎可以獲得介面文件中能給你的一切


Charles，fiddler 抓包工具
抓瀏覽器，抓手機APP請求