極客時間測試專欄閱讀總結——軟件測試整體方案

關鍵點&&概念

1. 測試數據準備方法：
   • API調用生成測試數據
   • 數據庫操做生成測試數據
   • 程序隨機生成測試數據
   • 以上方法組合生成測試數據 注意： 測試用例執行過程當中，實時建立測試數據，咱們一般稱這種方式爲 On-the-fly。 測試用例執行前，事先建立好「開箱即用」的測試數據，咱們一般稱這種方式爲 Out-of-box。
2. 接口測試和單元測試對比：
   • 單元測試：關注的是單個服務或程序接口的輸入或者輸出是否正確
   • 接口測試：關注的是多個程序服務或接口的組成的對外的業務接口的功能驗證
3. 測試分類：
   • 白盒測試：在徹底瞭解程序的邏輯，對程序邏輯進行的測試
   • 灰盒測試：內部邏輯不徹底可見，但能夠經過工具知道有判斷循環
   • 黑盒測試：徹底不清楚程序的實現方式
4. 核心競爭力：
   • 測試策略設計能力 測試執行力度，進度評估 工具、自動化框架選擇 資源分配 風險評估
   • 用例設計能力 基礎方法使用 常見中間件，技術瞭解：好比緩存，代理服務器，系統架構
   • 錯誤分析能力 代碼能力 嚴禁的邏輯思惟

原理

1. selenium2.0 原理

   當使用 Selenium2.0 啓動瀏覽器 Web Browser 時，後臺會同時啓動基於 WebDriver Wire 協議的 Web Service 做爲 Selenium 的 Remote Server，並將其與瀏覽器綁定。綁定完成後，Remote Server 就開始監聽 Client 端的操做請求。 執行測試時，測試用例會做爲 Client 端，將須要執行的頁面操做請求以 Http Request 的方式發送給 Remote Server。該 HTTP Request 的 body，是以 WebDriver Wire 協議規定的 JSON 格式來描述須要瀏覽器執行的具體操做。 Remote Server 接收到請求後，會對請求進行解析，並將解析結果發給 WebDriver，由 WebDriver 實際執行瀏覽器的操做。 WebDriver 能夠看作是直接操做瀏覽器的原生組件（Native Component），因此搭建測試環境時，一般都須要先下載瀏覽器對應的 WebDriver。

2. Appium原理：

   • 本質上，Appium Server 是一個 Node.js 應用，接受來自 Appium Client 的請求，解析後經過 WebDriver 協議和設備端上的代理打交道。Appium Client 其實就是測試代碼，使用對應語言的 Client 將基於 JSON Wire 協議的操做指令發給 Appium Server。

   • iOS：Appium Server 會把操做請求發送給 WebDriverAgent（簡稱 WDA），而後 WDA 再基於 XCUITest 完成 iOS 模擬器或者真機上的自動化操做；

   • Android：Appium Server 會把操做請求發送給 appium-UIautomator2-server，而後 appium-UIautomator2-server 再基於 UIAutomator V2 完成 Android 模擬器或者真機上的自動化操做。

   • 總結：Appium 屬於 C/S 架構，Appium Client 經過多語言支持的第三方庫向 Appium Server 發起請求，基於 Node.js 的 Appium Server 會接受 Appium Client 發來的請求，接着和 iOS 或者 Android 平臺上的代理工具打交道，代理工具在運行過程當中不斷接收請求，並根據 WebDriver 協議解析出要執行的操做，最後調用 iOS 或者 Android 平臺上的原生測試框架完成測試。

框架&&工具&&解釋

1. 基於API測試：REST Assured
2. java 單元測試框架：TestNG，Junit
3. C語言測試工具：CppTest，Parasoft C/C++test
4. java 代碼覆蓋率統計：JaCoCo，原理：基本方法注入（Instrumentation），注入就是在被測代碼中自動插入用於覆蓋率統計的探針（Probe）代碼，並保證插入的探針代碼不會給原代碼帶來任何影響。
   • 對於 Java 代碼來說，根據注入目標的不一樣，能夠分爲源代碼（Source Code）注入和字節碼（Byte Code）注入兩大類。基於 JVM 自己特性以及執行效率的緣由，目前主流的工具基本都是使用字節碼注入，注入的具體實現採用 ASM 技術。
   • 兩種方式 On-The-Fly模式：支持Java Agent的運行環境，代理方式，表明工具：JaCoCo Offline 注入模式：沒法實時獲取代碼覆蓋率信息，只能在系統停機時下獲取，不須要代理，表明工具：Cobertura
5. JavaScript 代碼覆蓋率統計：Istanbul
6. 測試代碼分類：
   • 驅動代碼（Driver）指調用被測函數的代碼。在單元測試過程當中，驅動模塊一般包括調用被測函數前的數據準備、調用被測函數以及驗證相關結果。
   • 樁代碼（Stub）是用來代替真實代碼的臨時代碼;好比，某個函數 A 的內部實現中調用了一個還沒有實現的函數 B，爲了對函數 A 的邏輯進行測試，那麼就須要模擬一個函數 B，這個模擬的函數 B 的實現就是所謂的樁代碼。
7. 覆蓋率：業務覆蓋率，代碼覆蓋率
8. 持續集成工具：jenkins，sonar
9. 測試服務化 TaaS ：Test as a Service，就是把全部的測試變成一個服務，好比準備數據的服務，mock接口的服務，小業務模塊也是個服務，便於管理和調用，須要根據本身的實際狀況規劃，這個能力須要進一步增強！！！
10. 數據驅動(數據與)：採用數據和測試代碼分離的形式，把數據集中化，保證當某些點或者邏輯發生改變的狀況下，可在最小的代價下調試代碼。數據驅動包括：輸入數據，業務判斷標識數據和斷言數據
11. 頁面對象（Page Object）模型:這就是所謂的PO，人造概念，其實就是先把每一個要操做的元素封裝成一個變量，放到同一個類或者配置文件中，再把每一個功能（好比；一個功能包括對多個元素的操做）封裝成一個方法。每一個頁面就是一個類,開源工具Katalon Studio。
12. 對象自動生成工具：自動生成頁面對象模型的類，Katalon Studio。工具能在提供了URL後把當前頁面全部控件定位生成在同一個Page Class裏，可是中間有一些動態的信息的
13. js測試工具：Jest
14. E2E：端到端（end-to-end）UI測試是一種測試方法，它用來測試一個應用從頭至尾的流程是否和設計時候所想的同樣。簡而言之，它從一個用戶的角度出發，認爲整個系統都是一個黑箱，只有UI會暴露給用戶。
15. Responsive Page：Web 頁面是基於自適應網頁（自適應網頁設計【Responsive Web Design】）
16. 微服務：就是把業務系統的單工程拆解成N個小服務，小模塊，使得服務間不產生互相間的絕對影響。而分佈式則是同一工程，部署在不一樣服務器，提升系統抗壓能力。
17. 前端測試工具：WebPagetest（https://www.webpagetest.org，https://github.com/WPO-Foundation/webpagetest）
18. 生成器模式：builder pattern（java設計模式）
19. 測試架構：執行測試的過程當中用到的全部基礎硬件設施以及相關的軟件設施
20. 測試基礎架構：測試執行的機器或者集羣的建立與維護、測試執行集羣的容量規劃、測試發起的控制、測試用例的組織以及測試用例的版本控制等等
21. 元數據：管理數據的數據，記錄業務數據從產生到變化甚至最終銷燬的過程的數據
22. python測試框架：Unittest、Doctest、pytest、Nose、tox、Unittest二、mockunittest.mock
23. 全鏈路壓測：是基於真實的生產環境來模擬海量的併發用戶請求和數據，對整個業務鏈路進行壓力測試，試圖找到全部潛在性能瓶頸點並持續優化的實踐。
24. ROI：投資回報率

UI自動化

1. 瀏覽器：普通瀏覽器，無頭瀏覽器（Headless Browser，無界面瀏覽器，Google的Headless Chrome），
2. 無界面瀏覽器測試框架：Google的Puppeteer（須要Node支持），PhantomJS（已經中止維護）
3. GUI穩定性保障方法：
   • 異常場景恢復模式————GUI自動化的異常處理後繼續執行（瀏覽器內的彈窗或者瀏覽器外的異常恢復，只能處理已知錯誤）
   • 模糊匹配————因爲頁面的細微變化，好比id是element_01變爲element_02，須要本身二次開發，UFT就實現了，須要在測試報告中明確告知
   • A/B測試————須要指明系統
   • 頁面加載緩慢，還有重試機制，重試元素，頁面，業務等
   • 前置的測試數據錯誤
4. 測試範圍：
   • 只覆蓋最核心且直接影響主營業務流程的 E2E 場景
   • 全部業務點覆蓋率達到70%到80%
5. 測試報告：
   • 擴展selenium，完成截圖，且對關鍵的元素高亮顯示
   • 在Hook（HOOK：鉤子，掛鉤，是一種實現Windows平臺下相似於中斷的機制）中操做，完成截圖功能
   • ？？？進一步瞭解測試報告
6. 測試方法：
   • 代碼重用

app測試

1. app應用測試特色
   • Web App 指的是移動端的 Web 瀏覽器。
   • Native App 指的是移動端的原生應用， 對於 Android 是 apk，對於 iOS 就是 ipa。
   • Hybrid App（俗稱：混血應用），是介於 Web App 和 Native App 二者之間的一種 App 形式。經過一個原生實現的 Native Container 展現 HTML5 的頁面。在原生移動應用中嵌入了 Webview，而後經過該 Webview 來訪問網頁。
   • iOS 通常採用 XCUITest Driver，而 Android 通常採用 UiAutomator2 或者 Espresso等
   • Hybrid App測試注意點：Native Container 和 Webview 分別屬於兩個不一樣的上下文（Context），Native Container 默認的 Context 爲「NATIVE APP"，而 Webview 默認的 Context 爲「WEBVIEW_+ 被測進程名稱」。
   • 六項專項測試： 交叉事件測試：切換應用：例如電話、短信、提示升級、鬧鐘、先後臺切換、切換網絡 兼容性測試：屏幕大小，系統版本，不一樣機型，不一樣網絡 流量測試：系統自帶監控或者監控軟件，例如：tcpdump、Wireshark 和 Fiddler 耗電量測試：Android 命令「adb shell dumpsys battery」來獲取應用的耗電量信息；iOS 經過 Apple 的官方工具 Sysdiagnose 來收集耗電量信息，後，能夠進一步經過 Instrument 工具鏈中的 Energy Diagnostics 進行耗電量分析。 弱網絡測試：移動網絡測試工具Augmented Traffic Control（ATC） 邊界測試：內存佔用超過90%，存儲佔用超過95%，系統時間誤差，長時間使用
   • 被測Demo： Native App：https://github.com/appium/ios-test-app Web App：http://appium.io
   • IOS開發工具Xcode，模擬器Simulator
2. APP多機同步測試框架：Appium + OpenSTF + Selenium Gird

API測試——接口測試

1. API測試工具：命令行工具 cURL、Postman、SoapUI、JMeter（Newman插件？？？）
2. API被測Demo：https://github.com/SpectoLabs/spring-cloud-contract-blog
3. Java API測試框架：OkHttP、Unirest
4. Python API測試框架：http.client、Requests、HttpRunner
5. NodeJS API測試框架：Native、Request
6. 基於契約的測試方法：關注服務的使用者，好比該服務有固定的調用者，並且不會亂傳參數。

代碼級測試——單元測試

1. 代碼測試方法
   • 人工靜態方法:經過人工閱讀代碼查找代碼中潛在錯誤的方法，一般採用的手段包括，開發人員代碼走查、結對編程、同行評審等
   • 自動靜態方法:發現語法特徵錯誤、邊界行爲特徵錯誤和經驗特徵錯誤這三類「有特徵」的錯誤,工具：SonarLint，SonarQube
   • 人工動態方法:設計代碼的輸入和預期的正確輸出的集合，而後執行代碼，判斷實際輸出是否符合預期。我在以前的第三篇文章
   • 自動動態方法，又稱自動邊界測試方法，指的是基於代碼自動生成邊界測試用例並執行，以捕捉潛在的異常、崩潰和超時的方法
2. 動態測試方法入參：
   • 定義的變量值
   • 靜態變量（函數中已經定義的特定值）
   • 成員變量
   • 調用的函數返回值和被調用函數的返回值修改的變量
   • 嵌入式系統中，在中斷調用中改寫的數據
3. 動態測試方法預期：
   • 程序運行後的返回值
   • 程序運行後的輸出
   • 程序運行後改變的全局變量或成員變量
   • 程序運行後改變的文件，數據庫中的數據，消息隊列

性能測試

1. 性能測試須要關注的是算法設計、架構設計、性能最佳實踐、數據庫相關、軟件性能的可測試性這五大方面。

2. 性能測試須要關注的具體內容：

   • 算法設計包含的點： 核心算法的設計與實現是否高效 必要時，設計上是否採用 buffer 機制以提升性能，下降 I/O 是否存在潛在的內存泄露 是否存在併發環境下的線程安全問題 是否存在不合理的線程同步方式 是否存在不合理的資源競爭
   • 架構設計包含的內容： 站在總體系統的角度，是否能夠方便地進行系統容量和性能擴展 應用集羣的可擴展性是否通過測試和驗證 緩存集羣的可擴展性是否通過測試和驗證 數據庫的可擴展性是否通過測試和驗證
   • 性能最佳實踐包含的點： 代碼實現是否遵照開發語言的性能最佳實踐 關鍵代碼是否在白盒級別進行性能測試 是否考慮前端性能的優化 必要的時候是否採用數據壓縮傳輸 對於既要壓縮又要加密的場景，是否採用先壓縮後加密的順序
   • 數據庫相關的點： 數據庫表設計是否高效 是否引入必要的索引 SQL 語句的執行計劃是否合理 SQL 語句除了功能是否要考慮性能要求 數據庫是否須要引入讀寫分離機制 系統冷啓動後，緩存大量不命中的時候，數據庫承載的壓力是否超負荷
   • 軟件性能的可測試性包含的點： 是否支持高併發場景下的性能打點 是否支持全鏈路的性能分析

3. 性能測試的能力

   • 性能需求的總結和抽象能力
   • 根據性能測試目標，精準的性能測試場景設計和計算能力
   • 性能測試場景和性能測試腳本的開發和執行能力
   • 測試性能報告的分析解讀能力
   • 性能瓶頸的快速排查和定位能力
   • 性能測試數據的設計和實現能力
   • 面對互聯網產品，全鏈路壓測的設計與執行能力，可以和系統架構師一塊兒處理流量標記、影子數據庫等的技術設計能力
   • 深刻理解性能測試工具的內部實現原理，當性能測試工具備限制時，能夠進行擴展二次開發
   • 極其寬廣的知識面，既要有「面」的知識，好比系統架構、存儲架構、網絡架構等全局的知識，還要有大量「點」的知識積累，好比數據庫 SQL 語句的執行計劃調優、JVM 垃圾回收（GC）機制、多線程常見問題等等

4. 併發用戶數：業務上認爲是最大最大在線人數，但對於服務的性能來說，是在線的人想發起請求數，同時要注意用戶發起的哪類請求較多

5. 響應時間標準定義：應用系統從請求發出開始，到客戶端接收到最後一個字節數據所消耗的時間

   • 響應時間：分爲前端展示時間和系統響應時間兩部分。其中，前端時間，又稱呈現時間，取決於客戶端收到服務器返回的數據後渲染頁面所消耗的時間；而系統響應時間，又能夠進一步劃分爲 Web 服務器時間、應用服務器時間、數據庫時間，以及各服務器間通訊的網絡時間。
   • 若是響應時間沒法提高，能夠經過在沒有徹底接受就加載的技術實現部分加載，提高用戶體驗

6. 系統吞吐量：單位時間內的請求數量，請求的字節大小，頁面多少

   • 「Bytes/Second」和「Pages/Second」表示的吞吐量，主要受網絡設置、服務器架構、應用服務器制約；
   • 「Requests/Second」表示的吞吐量，主要受應用服務器和應用自己實現的制約。

7. 性能測試方法分類：

   • 後端性能測試（Back-end Performance Test）：經過性能測試工具模擬大量的併發用戶請求，而後獲取系統性能的各項指標，而且驗證各項指標是否符合預期的性能需求的測試手段
   • 前端性能測試（Front-end Performance Test）： 一般來說，前端性能關注的是瀏覽器端的頁面渲染時間、資源加載順序、請求數量、前端緩存使用狀況、資源壓縮等內容，但願藉此找到頁面加載過程當中比較耗時的操做和資源，而後進行有針對性的優化，最終達到優化終端用戶在瀏覽器端使用體驗的目的。 優化方法：減小 http 請求次數，減小 DNS 查詢次數，避免頁面跳轉，使用內容分發網絡（CDN），Gzip 壓縮傳輸文件 雅虎軍規：https://developer.yahoo.com/performance/rules.html?guccounter=1
   • 代碼級性能測試（Code-level Performance Test）：簡單的重複單元測試
   • 壓力測試（Load/Stress Test）
   • 配置測試（Configuration Test）：操做系統配置、應用服務器配置、jvm配置、數據庫配置、網絡配置等
   • 併發測試（Concurrence Test）：同時調用後端服務，期間觀察被調用服務在併發狀況下的行爲表現，旨在發現諸如資源競爭、資源死鎖之類的問題
   • 可靠性測試（Reliability Test）：經過長時間模擬真實的系統負載來發現系統潛在的內存泄漏、連接池回收等問題，通常須要3-7天

8. 性能測試領域：能力驗證、能力規劃、性能調優、缺陷發現

9. 性能測試步驟

   • 性能需求獲取
   • 性能場景設計
   • 性能測試腳本開發
   • 性能場景實現
   • 性能測試執行
   • 性能結果報告分析
   • 性能優化和再驗證

10. 性能工具組成：虛擬用戶腳本生成器、壓力控制器、壓力產生器、系統監控器、測試結果分析器

11. 負載策略

12. 全鏈路疑難點解決

    • 海量併發請求的發起主要藉助於 JMeter，而且經過 Jenkins Job 來實現海量併發的調度控制（小型能夠用分佈式的 JMeter）；
    • 全鏈路壓測流量和數據的隔離主要藉助含有特定標記的流量和數據來實現，同時須要對業務模塊以及中間件進行必要的改造，數據庫這邊還會使用影子數據庫（數據分發就是要本身開發，哇咔咔）；
    • 實際業務負載的模擬，主要是採用基於歷史流量修改後的回放來實現；
    • 全鏈路壓測完成後的數據清洗，則是藉助自動化的手段來批量完成。

測試數據

1. 生成方式：接口，數據庫生成，隨機程序生成。
2. 方案：使用java的生成器模式和restful API開發一個數據準備平臺

集成測試環境

1. Selenium Hub 用來管理各個 Selenium Node 的註冊信息和狀態信息，而且接收遠程客戶端代碼的測試調用請求，並把請求命令轉發給符合要求的 Selenium Node 執行。

2. 搭建通常的selenium grid

3. 在Docker上搭建 selenium grid

4. 在雲端搭建selenium grid

5. 注意如下流程，這樣能夠實現大型系統的統一控制，若是是小型系統能夠不使用統一測試平臺，和jenkins集羣，甚至不須要把selenium grid部署在docker上，服務器自動擴容等

6. 注意實現selenium grid的遠程控制併發，持續集成，使用人員

7. 測試服務化：

   • 統一測試執行服務：以 Restful API 的形式對外提供測試執行服務，兼具了測試版本管理、Jenkins 測試 Job 管理，以及測試執行結果管理的能力
   • 統一測試數據服務：以 Restful API 的形式對外提供測試數據服務，元數據管理，測試數據自動補全，測試數據質量監控（好高級）
   • 全局測試配置服務：好比要測試的不一樣國家，不一樣地域，不一樣語言等配置
   • 測試報告服務：根據不一樣測試，好比GUI測試或者是API測試給出不一樣的測試報告，並存儲測試報告
   • 測試執行環境準備服務：根據測試數據服務，測試內容控制selenium接點和是否擴容（我有生之年還能夠用到嗎？？？）
   • 被測系統部署服務：以 Restful API 的形式對外提供部署環境，或者安裝APP等服務

測試工做思惟

1. 測試驅動開發:Test-Driven Development，一般簡稱爲 TDD，測試確認好需求，用例給開發，讓開發更有目的。
2. 探索式測試:瞭解了需求後，預測到業務上或者實現上可能出現問題，進行有目的的測試。
3. 精準測試：藉助必定的技術手段、經過算法的輔助對傳統軟件測試過程進行可視化、分析以及優化的過程。

• 理解；技術手段分析用例、數據、代碼之間的聯繫並把記錄可視化
• 精準測試範例：http://www.threadingtest.com/index.html
• 核心技術：
  • 軟件測試精準顯示波：在人工或者自動化測試過程當中記錄邏輯塊，代碼條件函數調用等的速率，並記錄成圖表
  • 測試用例和被測產品代碼的雙向追溯：雙向關聯代碼和用例
  • 智能迴歸測試用例選取算法：智能選取改動代碼影響的測試用例
  • 測試用例的聚類分析：把用例和業務關聯（就是作一個分類，和2,3有區別？？）

安全測試

1. 滲透測試：由專業安全人員模擬黑客，從其可能存在的位置對系統進行攻擊測試，在真正的黑客入侵前找到隱藏的安全漏洞，從而達到保護系統安全的目的。
2. 滲透測試分類：
   • 有針對性的測試：「開燈」測試，在瞭解內部全部信息（代碼，架構，環境）基礎下的測試外部測試
   • 針對外部可見的服務器和設備（包括：域名服務器（DNS）、Web 服務器或防火牆、電子郵箱服務器等等），模擬外部攻擊者對其進行攻擊，檢查它們是否可以被入侵，以及若是被成功入侵了，會被入侵到系統的哪一部分、又會泄露多少資料
   • 內部測試；由測試工程師模擬內部人員，在內網（防火牆之內）進行攻擊，所以測試人員會擁有較高的系統權限，也可以查看各類內部資料，目的是檢查內部攻擊能夠給系統形成什麼程度的損害
   • 盲測；嚴格限制提供給測試執行人員或團隊信息的前提下，由他們來模擬真實攻擊者的行爲和上下文。一般，測試人員可能只被告知被測系統公開的信息，而對系統細節以及內部實現一無所知
   • 雙盲測試：也叫做「隱祕測試」，不光測試人員對系統內部知之甚少，並且被測系統內部也只有極少數人知道正在進行安全測試。所以，雙盲測試能夠反映軟件系統最真實的安全狀態，可以有效地檢測系統在正常狀況下，對安全事件的監控和處理能力是否合格
3. 滲透測試步驟
   • 規劃和偵察：定義測試的範圍和目標、初步肯定要使用的工具和方法、明確須要收集的情報（例如，網絡和域名，郵件服務器）
   • 安全掃描：包括靜態分析（掃描全部代碼來估計其運行時的方式，工具Fortify SCA 和 Checkmarx Suite）和動態分析兩個階段（代碼運行時進行掃描）。
   • 獲取訪問權限：模擬黑客對應用程序進行網絡攻擊，例如使用 SQL 注入或者XSS 跨站腳本攻擊，發現系統漏洞，利用漏洞升級本身的權限、竊取數據、攔截流量等方式瞭解其可能對系統形成的損害
   • 維持訪問權限，查看被發現的漏洞是否能夠長期存在於系統，或者經過手段保持漏洞存在
   • 入侵分析：能夠被利用的特定漏洞；利用該漏洞的具體步驟；可以被訪問的敏感數據；滲透測試人員可以在系統中不被偵測到的存在時間。
4. 滲透測試工具
   • Nmap 是進行主機檢測和網絡掃描的重要工具。用來收集系統基本信息（IP，端口），漏洞探測和安全掃描，從主機發現、端口掃描到操做系統檢測和 IDS 規避 / 欺騙。滲透測試中最早用到的，適用於Windows、Linux、OSX等系統
   • Aircrack-ng 是評估 Wi-Fi 網絡安全性的一整套工具。主要功能有：網絡偵測、數據包嗅探、WEP 和 WPA/WPA2-PSK 破解。Aircrack-ng 能夠工做在任何支持監聽模式的無線網卡上並嗅探 802.11a、802.11b、802.11g 的數據。 Aircrack-ng 的執行是經過命令行或者腳本文件的方式，能夠運行在 Linux 和 Windows 操做系統上。它的典型應用場景，主要包括數據包注入重播攻擊、解除身份驗證、虛假接入點等，也能夠用於破解 WEP 和 WPA PSK。
   • sqlmap 是一種開源的基於命令行的滲透測試工具。它可以自動進行 SQL 注入和數據庫接入，而且支持全部常見並普遍使用的數據庫平臺，包括 Oracle、MySQL、Microsoft SQL Server、SQLite、Microsoft Access、IBM DB二、FireBird、Sybase 和 SAP Max DB 等，使用的 SQL 注入技術也幾乎涵蓋了全部的攻擊手段。
   • Wifiphisher 是一種惡意接入點工具，能夠對 WiFi 網絡進行自動釣魚攻擊。滲透測試執行人員，能夠經過 Wifiphisher 執行有針對性的 WiFi 關聯攻擊，實現無線客戶端的滲透測試。Wifiphisher 還能夠用於對鏈接的客戶端進行受害者定製的網絡釣魚攻擊，用來獲取憑證（例如，從第三方登陸頁面或 WPA/WPA2 預共享密鑰）或用惡意軟件感染受害者站點。
   • AppScan 是 IBM 公司的一款企業級商業 Web 應用安全測試工具，採用的是黑盒測試，能夠掃描常見的 Web 應用安全漏洞。 工做原理首先，從起始頁爬取站下全部的可見頁面，同時測試常見的管理後臺；而後，利用 SQL 注入原理測試全部可見頁面，是否在注入點和跨站腳本攻擊的可能；同時，檢測 Cookie 管理、會話週期等常見的 Web 安全漏洞。

基於模型的測試

1. 定義：Model-Based-Testing，簡稱 MBT,是自動化測試的一個分支。它是將測試用例的設計依託於被測系統的模型，並基於該模型自動生成測試用例的技術。其中，這個被測系統的模型表示了被測系統行爲的預期，也能夠說是表明了咱們對被測系統的預期。
2. MBT 的基本原理是經過創建被測系統的設計模型，而後結合不一樣的算法和策略來遍歷該模型，以今生成測試用例的設計。‘
3. 經常使用模型，有限狀態機：不一樣組合對應不一樣狀態，狀態圖，UML
4. MBT 工具簡介 BPM-X fMBT
5. 優缺點：優勢已維護，缺點難學，花錢

試試

1. spring boot + Cucumber + REST Assured + selenium