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

關鍵點&&概念

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、Unittest2、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 DB2、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