極客時間測試專欄閱讀總結——軟體測試總體方案
阿新 • • 發佈：2019-06-10
關鍵點&&概念
- 測試資料準備方法：
- API呼叫生成測試資料
- 資料庫操作生成測試資料
- 程式隨機生成測試資料
- 以上方法組合生成測試資料
注意：
測試用例執行過程中，實時建立測試資料，我們通常稱這種方式為 On-the-fly。
測試用例執行前，事先建立好“開箱即用”的測試資料，我們通常稱這種方式為 Out-of-box。
- 介面測試和單元測試對比：
- 單元測試：關注的是單個服務或程式介面的輸入或者輸出是否正確
- 介面測試：關注的是多個程式服務或介面的組成的對外的業務介面的功能驗證
- 測試分類：
- 白盒測試：在完全瞭解程式的邏輯，對程式邏輯進行的測試
- 灰盒測試：內部邏輯不完全可見，但可以通過工具知道有判斷迴圈
- 黑盒測試：完全不清楚程式的實現方式
- 核心競爭力：
- 測試策略設計能力
測試執行力度，進度評估
工具、自動化框架選擇
資源分配
風險評估 - 用例設計能力
基礎方法使用
常見中介軟體，技術瞭解：比如快取，代理伺服器，系統架構 - 錯誤分析能力
程式碼能力
嚴禁的邏輯思維
- 測試策略設計能力
原理
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。- 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 平臺上的原生測試框架完成測試。
框架&&工具&&解釋
- 基於API測試：REST Assured
- java 單元測試框架：TestNG，Junit
- C語言測試工具：CppTest，Parasoft C/C++test
- java 程式碼覆蓋率統計：JaCoCo，原理：基本方法注入（Instrumentation），注入就是在被測程式碼中自動插入用於覆蓋率統計的探針（Probe）程式碼，並保證插入的探針程式碼不會給原始碼帶來任何影響。
- 對於 Java 程式碼來講，根據注入目標的不同，可以分為原始碼（Source Code）注入和位元組碼（Byte Code）注入兩大類。基於 JVM 本身特性以及執行效率的原因，目前主流的工具基本都是使用位元組碼注入，注入的具體實現採用 ASM 技術。
- 兩種方式
On-The-Fly模式：支援Java Agent的執行環境，代理方式，代表工具：JaCoCo
Offline 注入模式：無法實時獲取程式碼覆蓋率資訊，只能在系統停機時下獲取，不需要代理，代表工具：Cobertura
- JavaScript 程式碼覆蓋率統計：Istanbul
- 測試程式碼分類：
- 驅動程式碼（Driver）指呼叫被測函式的程式碼。在單元測試過程中，驅動模組通常包括呼叫被測函式前的資料準備、呼叫被測函式以及驗證相關結果。
- 樁程式碼（Stub）是用來代替真實程式碼的臨時程式碼;比如，某個函式 A 的內部實現中呼叫了一個尚未實現的函式 B，為了對函式 A 的邏輯進行測試，那麼就需要模擬一個函式 B，這個模擬的函式 B 的實現就是所謂的樁程式碼。
- 覆蓋率：業務覆蓋率，程式碼覆蓋率
- 持續整合工具：jenkins，sonar
- 測試服務化 TaaS ：Test as a Service，就是把所有的測試變成一個服務，比如準備資料的服務，mock介面的服務，小業務模組也是個服務，便於管理和呼叫，需要根據自己的實際情況規劃，這個能力需要進一步加強！！！
- 資料驅動(資料與)：採用資料和測試程式碼分離的形式，把資料集中化，保證當某些點或者邏輯發生改變的情況下，可在最小的代價下除錯程式碼。資料驅動包括：輸入資料，業務判斷標識資料和斷言資料
- 頁面物件（Page Object）模型:這就是所謂的PO，人造概念，其實就是先把每個要操作的元素封裝成一個變數，放到同一個類或者配置檔案中，再把每個功能（比如；一個功能包括對多個元素的操作）封裝成一個方法。每個頁面就是一個類,開源工具Katalon Studio。
- 物件自動生成工具：自動生成頁面物件模型的類，Katalon Studio。工具能在提供了URL後把當前頁面所有控制元件定位生成在同一個Page Class裡，但是中間有一些動態的資訊的
- js測試工具：Jest
- E2E：端到端（end-to-end）UI測試是一種測試方法，它用來測試一個應用從頭到尾的流程是否和設計時候所想的一樣。簡而言之，它從一個使用者的角度出發，認為整個系統都是一個黑箱，只有UI會暴露給使用者。
- Responsive Page：Web 頁面是基於自適應網頁（自適應網頁設計【Responsive Web Design】）
- 微服務：就是把業務系統的單工程拆解成N個小服務，小模組，使得服務間不產生互相間的絕對影響。而分散式則是同一工程，部署在不同伺服器，提高系統抗壓能力。
- 前端測試工具：WebPagetest（https://www.webpagetest.org，https://github.com/WPO-Foundation/webpagetest）
- 生成器模式：builder pattern（java設計模式）
- 測試架構：執行測試的過程中用到的所有基礎硬體設施以及相關的軟體設施
- 測試基礎架構：測試執行的機器或者叢集的建立與維護、測試執行叢集的容量規劃、測試發起的控制、測試用例的組織以及測試用例的版本控制等等
- 元資料：管理資料的資料，記錄業務資料從產生到變化甚至最終銷燬的過程的資料
- python測試框架：Unittest、Doctest、pytest、Nose、tox、Unittest2、mockunittest.mock
- 全鏈路壓測：是基於真實的生產環境來模擬海量的併發使用者請求和資料，對整個業務鏈路進行壓力測試，試圖找到所有潛在效能瓶頸點並持續優化的實踐。
ROI：投資回報率
UI自動化
- 瀏覽器：普通瀏覽器，無頭瀏覽器（Headless Browser，無介面瀏覽器，Google的Headless Chrome），
- 無介面瀏覽器測試框架：Google的Puppeteer（需要Node支援），PhantomJS（已經停止維護）
- GUI穩定性保障方法：
- 異常場景恢復模式————GUI自動化的異常處理後繼續執行（瀏覽器內的彈窗或者瀏覽器外的異常恢復，只能處理已知錯誤）
- 模糊匹配————由於頁面的細微變化，比如id是element_01變為element_02，需要自己二次開發，UFT就實現了，需要在測試報告中明確告知
- A/B測試————需要指明系統
- 頁面載入緩慢，還有重試機制，重試元素，頁面，業務等
- 前置的測試資料錯誤
- 測試範圍：
- 只覆蓋最核心且直接影響主營業務流程的 E2E 場景
- 所有業務點覆蓋率達到70%到80%
- 測試報告：
- 擴充套件selenium，完成截圖，且對關鍵的元素高亮顯示
- 在Hook（HOOK：鉤子，掛鉤，是一種實現Windows平臺下類似於中斷的機制）中操作，完成截圖功能
- ？？？進一步瞭解測試報告
- 測試方法：
- 程式碼重用
- 程式碼重用
app測試
- 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
- APP多機同步測試框架：Appium + OpenSTF + Selenium Gird
API測試——介面測試
- API測試工具：命令列工具 cURL、Postman、SoapUI、JMeter（Newman外掛？？？）
- API被測Demo：https://github.com/SpectoLabs/spring-cloud-contract-blog
- Java API測試框架：OkHttP、Unirest
- Python API測試框架：http.client、Requests、HttpRunner
- NodeJS API測試框架：Native、Request
- 基於契約的測試方法：關注服務的使用者，比如該服務有固定的呼叫者，而且不會亂傳引數。
程式碼級測試——單元測試
- 程式碼測試方法
- 人工靜態方法:通過人工閱讀程式碼查詢程式碼中潛在錯誤的方法，通常採用的手段包括，開發人員程式碼走查、結對程式設計、同行評審等
- 自動靜態方法:發現語法特徵錯誤、邊界行為特徵錯誤和經驗特徵錯誤這三類“有特徵”的錯誤,工具：SonarLint，SonarQube
- 人工動態方法:設計程式碼的輸入和預期的正確輸出的集合，然後執行程式碼，判斷實際輸出是否符合預期。我在之前的第三篇文章
- 自動動態方法，又稱自動邊界測試方法，指的是基於程式碼自動生成邊界測試用例並執行，以捕捉潛在的異常、崩潰和超時的方法
- 動態測試方法入參：
- 定義的變數值
- 靜態變數（函式中已經定義的特定值）
- 成員變數
- 呼叫的函式返回值和被呼叫函式的返回值修改的變數
- 嵌入式系統中，在中斷呼叫中改寫的資料
- 動態測試方法預期：
- 程式執行後的返回值
- 程式執行後的輸出
- 程式執行後改變的全域性變數或成員變數
- 程式執行後改變的檔案，資料庫中的資料，訊息佇列
效能測試
- 效能測試需要關注的是演算法設計、架構設計、效能最佳實踐、資料庫相關、軟體效能的可測試性這五大方面。
- 效能測試需要關注的具體內容：
- 演算法設計包含的點：
核心演算法的設計與實現是否高效
必要時，設計上是否採用 buffer 機制以提高效能，降低 I/O
是否存在潛在的記憶體洩露
是否存在併發環境下的執行緒安全問題
是否存在不合理的執行緒同步方式
是否存在不合理的資源競爭 - 架構設計包含的內容：
站在整體系統的角度，是否可以方便地進行系統容量和效能擴充套件
應用叢集的可擴充套件性是否經過測試和驗證
快取叢集的可擴充套件性是否經過測試和驗證
資料庫的可擴充套件性是否經過測試和驗證 - 效能最佳實踐包含的點：
程式碼實現是否遵守開發語言的效能最佳實踐
關鍵程式碼是否在白盒級別進行效能測試
是否考慮前端效能的優化
必要的時候是否採用資料壓縮傳輸
對於既要壓縮又要加密的場景，是否採用先壓縮後加密的順序 - 資料庫相關的點：
資料庫表設計是否高效
是否引入必要的索引
SQL 語句的執行計劃是否合理
SQL 語句除了功能是否要考慮效能要求
資料庫是否需要引入讀寫分離機制
系統冷啟動後，快取大量不命中的時候，資料庫承載的壓力是否超負荷 - 軟體效能的可測試性包含的點：
是否支援高併發場景下的效能打點
是否支援全鏈路的效能分析
- 演算法設計包含的點：
- 效能測試的能力
- 效能需求的總結和抽象能力
- 根據效能測試目標，精準的效能測試場景設計和計算能力
- 效能測試場景和效能測試指令碼的開發和執行能力
- 測試效能報告的分析解讀能力
- 效能瓶頸的快速排查和定位能力
- 效能測試資料的設計和實現能力
- 面對網際網路產品，全鏈路壓測的設計與執行能力，能夠和系統架構師一起處理流量標記、影子資料庫等的技術設計能力
- 深入理解效能測試工具的內部實現原理，當效能測試工具有限制時，可以進行擴充套件二次開發
- 極其寬廣的知識面，既要有“面”的知識，比如系統架構、儲存架構、網路架構等全域性的知識，還要有大量“點”的知識積累，比如資料庫 SQL 語句的執行計劃調優、JVM 垃圾回收（GC）機制、多執行緒常見問題等等
- 併發使用者數：業務上認為是最大最大線上人數，但對於服務的效能來講，是線上的人想發起請求數，同時要注意使用者發起的哪類請求較多
- 響應時間標準定義：應用系統從請求發出開始，到客戶端接收到最後一個位元組資料所消耗的時間
- 響應時間：分為前端展現時間和系統響應時間兩部分。其中，前端時間，又稱呈現時間，取決於客戶端收到伺服器返回的資料後渲染頁面所消耗的時間；而系統響應時間，又可以進一步劃分為 Web 伺服器時間、應用伺服器時間、資料庫時間，以及各伺服器間通訊的網路時間。
- 如果響應時間無法提升，可以通過在沒有完全接受就載入的技術實現部分載入，提升使用者體驗
- 系統吞吐量：單位時間內的請求數量，請求的位元組大小，頁面多少
- “Bytes/Second”和“Pages/Second”表示的吞吐量，主要受網路設定、伺服器架構、應用伺服器制約；
- “Requests/Second”表示的吞吐量，主要受應用伺服器和應用本身實現的制約。
- 效能測試方法分類：
- 後端效能測試（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天
效能測試領域：能力驗證、能力規劃、效能調優、缺陷發現
- 效能測試步驟
- 效能需求獲取
- 效能場景設計
- 效能測試指令碼開發
- 效能場景實現
- 效能測試執行
- 效能結果報告分析
- 效能優化和再驗證
- 效能工具組成：虛擬使用者指令碼生成器、壓力控制器、壓力產生器、系統監控器、測試結果分析器
負載策略
- 全鏈路疑難點解決
- 海量併發請求的發起主要藉助於 JMeter，並且通過 Jenkins Job 來實現海量併發的排程控制（小型可以用分散式的 JMeter）；
- 全鏈路壓測流量和資料的隔離主要藉助含有特定標記的流量和資料來實現，同時需要對業務模組以及中介軟體進行必要的改造，資料庫這邊還會使用影子資料庫（資料分發就是要自己開發，哇咔咔）；
- 實際業務負載的模擬，主要是採用基於歷史流量修改後的回放來實現；
- 全鏈路壓測完成後的資料清洗，則是藉助自動化的手段來批量完成。
測試資料
- 生成方式：介面，資料庫生成，隨機程式生成。
- 方案：使用java的生成器模式和restful API開發一個數據準備平臺
整合測試環境
- Selenium Hub 用來管理各個 Selenium Node 的註冊資訊和狀態資訊，並且接收遠端客戶端程式碼的測試呼叫請求，並把請求命令轉發給符合要求的 Selenium Node 執行。
- 搭建一般的selenium grid
- 在Docker上搭建 selenium grid
- 在雲端搭建selenium grid
- 注意以下流程，這樣可以實現大型系統的統一控制，如果是小型系統可以不使用統一測試平臺，和jenkins叢集，甚至不需要把selenium grid部署在docker上，伺服器自動擴容等
注意實現selenium grid的遠端控制併發，持續整合，使用人員
- 測試服務化：
- 統一測試執行服務：以 Restful API 的形式對外提供測試執行服務，兼具了測試版本管理、Jenkins 測試 Job 管理，以及測試執行結果管理的能力
- 統一測試資料服務：以 Restful API 的形式對外提供測試資料服務，元資料管理，測試資料自動補全，測試資料質量監控（好高階）
- 全域性測試配置服務：比如要測試的不同國家，不同地域，不同語言等配置
- 測試報告服務：根據不同測試，比如GUI測試或者是API測試給出不同的測試報告，並存儲測試報告
- 測試執行環境準備服務：根據測試資料服務，測試內容控制selenium接點和是否擴容（我有生之年還可以用到嗎？？？）
- 被測系統部署服務：以 Restful API 的形式對外提供部署環境，或者安裝APP等服務
測試工作思維
- 測試驅動開發:Test-Driven Development，通常簡稱為 TDD，測試確認好需求，用例給開發，讓開發更有目的。
- 探索式測試:瞭解了需求後，預測到業務上或者實現上可能出現問題，進行有目的的測試。
- 精準測試：藉助一定的技術手段、通過演算法的輔助對傳統軟體測試過程進行視覺化、分析以及優化的過程。
- 理解；技術手段分析用例、資料、程式碼之間的聯絡並把記錄視覺化
- 精準測試範例：http://www.threadingtest.com/index.html
- 核心技術：
- 軟體測試精準顯示波：在人工或者自動化測試過程中記錄邏輯塊，程式碼條件函式呼叫等的速率，並記錄成圖表
- 測試用例和被測產品程式碼的雙向追溯：雙向關聯程式碼和用例
- 智慧迴歸測試用例選取演算法：智慧選取改動程式碼影響的測試用例
測試用例的聚類分析：把用例和業務關聯（就是做一個分類，和2,3有區別？？）
安全測試
- 滲透測試：由專業安全人員模擬黑客，從其可能存在的位置對系統進行攻擊測試，在真正的黑客入侵前找到隱藏的安全漏洞，從而達到保護系統安全的目的。
- 滲透測試分類：
- 有針對性的測試：“開燈”測試，在瞭解內部所有資訊（程式碼，架構，環境）基礎下的測試外部測試
- 針對外部可見的伺服器和裝置（包括：域名伺服器（DNS）、Web 伺服器或防火牆、電子郵箱伺服器等等），模擬外部攻擊者對其進行攻擊，檢查它們是否能夠被入侵，以及如果被成功入侵了，會被入侵到系統的哪一部分、又會洩露多少資料
- 內部測試；由測試工程師模擬內部人員，在內網（防火牆以內）進行攻擊，因此測試人員會擁有較高的系統許可權，也能夠檢視各種內部資料，目的是檢查內部攻擊可以給系統造成什麼程度的損害
- 盲測；嚴格限制提供給測試執行人員或團隊資訊的前提下，由他們來模擬真實攻擊者的行為和上下文。通常，測試人員可能只被告知被測系統公開的資訊，而對系統細節以及內部實現一無所知
- 雙盲測試：也叫作“隱祕測試”，不光測試人員對系統內部知之甚少，而且被測系統內部也只有極少數人知道正在進行安全測試。因此，雙盲測試可以反映軟體系統最真實的安全狀態，能夠有效地檢測系統在正常情況下，對安全事件的監控和處理能力是否合格
- 滲透測試步驟
- 規劃和偵察：定義測試的範圍和目標、初步確定要使用的工具和方法、明確需要收集的情報（例如，網路和域名，郵件伺服器）
- 安全掃描：包括靜態分析（掃描所有程式碼來估計其執行時的方式，工具Fortify SCA 和 Checkmarx Suite）和動態分析兩個階段（程式碼執行時進行掃描）。
- 獲取訪問許可權：模擬黑客對應用程式進行網路攻擊，例如使用 SQL 注入或者XSS 跨站指令碼攻擊，發現系統漏洞，利用漏洞升級自己的許可權、竊取資料、攔截流量等方式瞭解其可能對系統造成的損害
- 維持訪問許可權，檢視被發現的漏洞是否可以長期存在於系統，或者通過手段保持漏洞存在
- 入侵分析：可以被利用的特定漏洞；利用該漏洞的具體步驟；能夠被訪問的敏感資料；滲透測試人員能夠在系統中不被偵測到的存在時間。
- 滲透測試工具
- 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 安全漏洞。
基於模型的測試
- 定義：Model-Based-Testing，簡稱 MBT,是自動化測試的一個分支。它是將測試用例的設計依託於被測系統的模型，並基於該模型自動生成測試用例的技術。其中，這個被測系統的模型表示了被測系統行為的預期，也可以說是代表了我們對被測系統的預期。
- MBT 的基本原理是通過建立被測系統的設計模型，然後結合不同的演算法和策略來遍歷該模型，以此生成測試用例的設計。‘
- 常用模型，有限狀態機：不同組合對應不同狀態，狀態圖，UML
- MBT 工具簡介 BPM-X fMBT
- 優缺點：優點已維護，缺點難學，花錢
試試
- spring boot + Cucumber + REST Assured + selenium
- API呼叫生成測試資料
- 資料庫操作生成測試資料
- 程式隨機生成測試資料
- 以上方法組合生成測試資料
注意：
測試用例執行過程中，實時建立測試資料，我們通常稱這種方式為 On-the-fly。
測試用例執行前，事先建立好“開箱即用”的測試資料，我們通常稱這種方式為 Out-of-box。
- 介面測試和單元測試對比：
- 單元測試：關注的是單個服務或程式介面的輸入或者輸出是否正確
- 介面測試：關注的是多個程式服務或介面的組成的對外的業務介面的功能驗證
- 測試分類：
- 白盒測試：在完全瞭解程式的邏輯，對程式邏輯進行的測試
- 灰盒測試：內部邏輯不完全可見，但可以通過工具知道有判斷迴圈
- 黑盒測試：完全不清楚程式的實現方式
- 核心競爭力：
- 測試策略設計能力
測試執行力度，進度評估
工具、自動化框架選擇
資源分配
風險評估 - 用例設計能力
基礎方法使用
常見中介軟體，技術瞭解：比如快取，代理伺服器，系統架構 - 錯誤分析能力
程式碼能力
嚴禁的邏輯思維
- 測試策略設計能力
原理
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。- 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 平臺上的原生測試框架完成測試。
框架&&工具&&解釋
關鍵點&&概念
- 測試資料準備方法：
- API呼叫生成測試資料
- 資料庫操作生成測試資料
- 程式隨機生成測試資料
- 以上方法組合生成測試資料
注意：
測試用例執行過程中，實時建立測試資料，我們通常稱這種方式為 On-the-fly。
測試用例執行前，事先建立好“開箱即用”的測試資料，我們通常稱這種方式為 Out-of-box。
- 介面測試和單元測試對比：
- 單元測試：關注的是單個服務或程式介面的輸入或者輸出是否正確
- 介面測試：關注的是多個程式服務或介面的組成的對外的業務介面的功能驗證
- 測試分類：
- 白盒測試：在完全瞭解程式的邏輯，對程式邏輯進行的測試
- 灰盒測試：內部邏輯不完全可見，但可以通過工具知道有判斷迴圈
- 黑盒測試：完全不清楚程式的實現方式
- 核心競爭力：
- 測試策略設計能力
測試執行力度，進度評估
工具、自動化框架選擇
資源分配
風險評估 - 用例設計能力
基礎方法使用
常見中介軟體，技術瞭解：比如快取，代理伺服器，系統架構 - 錯誤分析能力
程式碼能力
嚴禁的邏輯思維
- 測試策略設計能力
原理
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。- 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 平臺上的原生測試框架完成測試。
框架&&工具&&解釋
- 基於API測試：REST Assured
- java 單元測試框架：TestNG，Junit
- C語言測試工具：CppTest，Parasoft C/C++test
- java 程式碼覆蓋率統計：JaCoCo，原理：基本方法注入（Instrumentation），注入就是在被測程式碼中自動插入用於覆蓋率統計的探針（Probe）程式碼，並保證插入的探針程式碼不會給原始碼帶來任何影響。
- 對於 Java 程式碼來講，根據注入目標的不同，可以分為原始碼（Source Code）注入和位元組碼（Byte Code）注入兩大類。基於 JVM 本身特性以及執行效率的原因，目前主流的工具基本都是使用位元組碼注入，注入的具體實現採用 ASM 技術。
- 兩種方式
On-The-Fly模式：支援Java Agent的執行環境，代理方式，代表工具：JaCoCo
Offline 注入模式：無法實時獲取程式碼覆蓋率資訊，只能在系統停機時下獲取，不需要代理，代表工具：Cobertura
- JavaScript 程式碼覆蓋率統計：Istanbul
- 測試程式碼分類：
- 驅動程式碼（Driver）指呼叫被測函式的程式碼。在單元測試過程中，驅動模組通常包括呼叫被測函式前的資料準備、呼叫被測函式以及驗證相關結果。
- 樁程式碼（Stub）是用來代替真實程式碼的臨時程式碼;比如，某個函式 A 的內部實現中呼叫了一個尚未實現的函式 B，為了對函式 A 的邏輯進行測試，那麼就需要模擬一個函式 B，這個模擬的函式 B 的實現就是所謂的樁程式碼。
- 覆蓋率：業務覆蓋率，程式碼覆蓋率
- 持續整合工具：jenkins，sonar
- 測試服務化 TaaS ：Test as a Service，就是把所有的測試變成一個服務，比如準備資料的服務，mock介面的服務，小業務模組也是個服務，便於管理和呼叫，需要根據自己的實際情況規劃，這個能力需要進一步加強！！！
- 資料驅動(資料與)：採用資料和測試程式碼分離的形式，把資料集中化，保證當某些點或者邏輯發生改變的情況下，可在最小的代價下除錯程式碼。資料驅動包括：輸入資料，業務判斷標識資料和斷言資料
- 頁面物件（Page Object）模型:這就是所謂的PO，人造概念，其實就是先把每個要操作的元素封裝成一個變數，放到同一個類或者配置檔案中，再把每個功能（比如；一個功能包括對多個元素的操作）封裝成一個方法。每個頁面就是一個類,開源工具Katalon Studio。
- 物件自動生成工具：自動生成頁面物件模型的類，Katalon Studio。工具能在提供了URL後把當前頁面所有控制元件定位生成在同一個Page Class裡，但是中間有一些動態的資訊的
- js測試工具：Jest
- E2E：端到端（end-to-end）UI測試是一種測試方法，它用來測試一個應用從頭到尾的流程是否和設計時候所想的一樣。簡而言之，它從一個使用者的角度出發，認為整個系統都是一個黑箱，只有UI會暴露給使用者。
- Responsive Page：Web 頁面是基於自適應網頁（自適應網頁設計【Responsive Web Design】）
- 微服務：就是把業務系統的單工程拆解成N個小服務，小模組，使得服務間不產生互相間的絕對影響。而分散式則是同一工程，部署在不同伺服器，提高系統抗壓能力。
- 前端測試工具：WebPagetest（https://www.webpagetest.org，https://github.com/WPO-Foundation/webpagetest）
- 生成器模式：builder pattern（java設計模式）
- 測試架構：執行測試的過程中用到的所有基礎硬體設施以及相關的軟體設施
- 測試基礎架構：測試執行的機器或者叢集的建立與維護、測試執行叢集的容量規劃、測試發起的控制、測試用例的組織以及測試用例的版本控制等等
- 元資料：管理資料的資料，記錄業務資料從產生到變化甚至最終銷燬的過程的資料
- python測試框架：Unittest、Doctest、pytest、Nose、tox、Unittest2、mockunittest.mock
- 全鏈路壓測：是基於真實的生產環境來模擬海量的併發使用者請求和資料，對整個業務鏈路進行壓力測試，試圖找到所有潛在效能瓶頸點並持續優化的實踐。
ROI：投資回報率
UI自動化
- 瀏覽器：普通瀏覽器，無頭瀏覽器（Headless Browser，無介面瀏覽器，Google的Headless Chrome），
- 無介面瀏覽器測試框架：Google的Puppeteer（需要Node支援），PhantomJS（已經停止維護）
- GUI穩定性保障方法：
- 異常場景恢復模式————GUI自動化的異常處理後繼續執行（瀏覽器內的彈窗或者瀏覽器外的異常恢復，只能處理已知錯誤）
- 模糊匹配————由於頁面的細微變化，比如id是element_01變為element_02，需要自己二次開發，UFT就實現了，需要在測試報告中明確告知
- A/B測試————需要指明系統
- 頁面載入緩慢，還有重試機制，重試元素，頁面，業務等
- 前置的測試資料錯誤
- 測試範圍：
- 只覆蓋最核心且直接影響主營業務流程的 E2E 場景
- 所有業務點覆蓋率達到70%到80%
- 測試報告：
- 擴充套件selenium，完成截圖，且對關鍵的元素高亮顯示
- 在Hook（HOOK：鉤子，掛鉤，是一種實現Windows平臺下類似於中斷的機制）中操作，完成截圖功能
- ？？？進一步瞭解測試報告
- 測試方法：
- 程式碼重用
app測試
- 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
- APP多機同步測試框架：Appium + OpenSTF + Selenium Gird
API測試——介面測試
- API測試工具：命令列工具 cURL、Postman、SoapUI、JMeter（Newman外掛？？？）
- API被測Demo：https://github.com/SpectoLabs/spring-cloud-contract-blog
- Java API測試框架：OkHttP、Unirest
- Python API測試框架：http.client、Requests、HttpRunner
- NodeJS API測試框架：Native、Request
- 基於契約的測試方法：關注服務的使用者，比如該服務有固定的呼叫者，而且不會亂傳引數。
程式碼級測試——單元測試
- 程式碼測試方法
- 人工靜態方法:通過人工閱讀程式碼查詢程式碼中潛在錯誤的方法，通常採用的手段包括，開發人員程式碼走查、結對程式設計、同行評審等
- 自動靜態方法:發現語法特徵錯誤、邊界行為特徵錯誤和經驗特徵錯誤這三類“有特徵”的錯誤,工具：SonarLint，SonarQube
- 人工動態方法:設計程式碼的輸入和預期的正確輸出的集合，然後執行程式碼，判斷實際輸出是否符合預期。我在之前的第三篇文章
- 自動動態方法，又稱自動邊界測試方法，指的是基於程式碼自動生成邊界測試用例並執行，以捕捉潛在的異常、崩潰和超時的方法
- 動態測試方法入參：
- 定義的變數值
- 靜態變數（函式中已經定義的特定值）
- 成員變數
- 呼叫的函式返回值和被呼叫函式的返回值修改的變數
- 嵌入式系統中，在中斷呼叫中改寫的資料
- 動態測試方法預期：
- 程式執行後的返回值
- 程式執行後的輸出
- 程式執行後改變的全域性變數或成員變數
- 程式執行後改變的檔案，資料庫中的資料，訊息佇列
效能測試
- 效能測試需要關注的是演算法設計、架構設計、效能最佳實踐、資料庫相關、軟體效能的可測試性這五大方面。
- 效能測試需要關注的具體內容：
- 演算法設計包含的點：
核心演算法的設計與實現是否高效
必要時，設計上是否採用 buffer 機制以提高效能，降低 I/O
是否存在潛在的記憶體洩露
是否存在併發環境下的執行緒安全問題
是否存在不合理的執行緒同步方式
是否存在不合理的資源競爭 - 架構設計包含的內容：
站在整體系統的角度，是否可以方便地進行系統容量和效能擴充套件
應用叢集的可擴充套件性是否經過測試和驗證
快取叢集的可擴充套件性是否經過測試和驗證
資料庫的可擴充套件性是否經過測試和驗證 - 效能最佳實踐包含的點：
程式碼實現是否遵守開發語言的效能最佳實踐
關鍵程式碼是否在白盒級別進行效能測試
是否考慮前端效能的優化
必要的時候是否採用資料壓縮傳輸
對於既要壓縮又要加密的場景，是否採用先壓縮後加密的順序 - 資料庫相關的點：
資料庫表設計是否高效
是否引入必要的索引
SQL 語句的執行計劃是否合理
SQL 語句除了功能是否要考慮效能要求
資料庫是否需要引入讀寫分離機制
系統冷啟動後，快取大量不命中的時候，資料庫承載的壓力是否超負荷 - 軟體效能的可測試性包含的點：
是否支援高併發場景下的效能打點
是否支援全鏈路的效能分析
- 演算法設計包含的點：
- 效能測試的能力
- 效能需求的總結和抽象能力
- 根據效能測試目標，精準的效能測試場景設計和計算能力
- 效能測試場景和效能測試指令碼的開發和執行能力
- 測試效能報告的分析解讀能力
- 效能瓶頸的快速排查和定位能力
- 效能測試資料的設計和實現能力
- 面對網際網路產品，全鏈路壓測的設計與執行能力，能夠和系統架構師一起處理流量標記、影子資料庫等的技術設計能力
- 深入理解效能測試工具的內部實現原理，當效能測試工具有限制時，可以進行擴充套件二次開發
- 極其寬廣的知識面，既要有“面”的知識，比如系統架構、儲存架構、網路架構等全域性的知識，還要有大量“點”的知識積累，比如資料庫 SQL 語句的執行計劃調優、JVM 垃圾回收（GC）機制、多執行緒常見問題等等
- 併發使用者數：業務上認為是最大最大線上人數，但對於服務的效能來講，是線上的人想發起請求數，同時要注意使用者發起的哪類請求較多
- 響應時間標準定義：應用系統從請求發出開始，到客戶端接收到最後一個位元組資料所消耗的時間
- 響應時間：分為前端展現時間和系統響應時間兩部分。其中，前端時間，又稱呈現時間，取決於客戶端收到伺服器返回的資料後渲染頁面所消耗的時間；而系統響應時間，又可以進一步劃分為 Web 伺服器時間、應用伺服器時間、資料庫時間，以及各伺服器間通訊的網路時間。
- 如果響應時間無法提升，可以通過在沒有完全接受就載入的技術實現部分載入，提升使用者體驗
- 系統吞吐量：單位時間內的請求數量，請求的位元組大小，頁面多少
- “Bytes/Second”和“Pages/Second”表示的吞吐量，主要受網路設定、伺服器架構、應用伺服器制約；
- “Requests/Second”表示的吞吐量，主要受應用伺服器和應用本身實現的制約。
- 效能測試方法分類：
- 後端效能測試（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天
效能測試領域：能力驗證、能力規劃、效能調優、缺陷發現
- 效能測試步驟
- 效能需求獲取
- 效能場景設計
- 效能測試指令碼開發
- 效能場景實現
- 效能測試執行
- 效能結果報告分析
- 效能優化和再驗證
- 效能工具組成：虛擬使用者指令碼生成器、壓力控制器、壓力產生器、系統監控器、測試結果分析器
負載策略
- 全鏈路疑難點解決
- 海量併發請求的發起主要藉助於 JMeter，並且通過 Jenkins Job 來實現海量併發的排程控制（小型可以用分散式的 JMeter）；
- 全鏈路壓測流量和資料的隔離主要藉助含有特定標記的流量和資料來實現，同時需要對業務模組以及中介軟體進行必要的改造，資料庫這邊還會使用影子資料庫（資料分發就是要自己開發，哇咔咔）；
- 實際業務負載的模擬，主要是採用基於歷史流量修改後的回放來實現；
- 全鏈路壓測完成後的資料清洗，則是藉助自動化的手段來批量完成。
測試資料
- 生成方式：介面，資料庫生成，隨機程式生成。
- 方案：使用java的生成器模式和restful API開發一個數據準備平臺
整合測試環境
- Selenium Hub 用來管理各個 Selenium Node 的註冊資訊和狀態資訊，並且接收遠端客戶端程式碼的測試呼叫請求，並把請求命令轉發給符合要求的 Selenium Node 執行。
- 搭建一般的selenium grid
- 在Docker上搭建 selenium grid
- 在雲端搭建selenium grid
- 注意以下流程，這樣可以實現大型系統的統一控制，如果是小型系統可以不使用統一測試平臺，和jenkins叢集，甚至不需要把selenium grid部署在docker上，伺服器自動擴容等
注意實現selenium grid的遠端控制併發，持續整合，使用人員
- 測試服務化：
- 統一測試執行服務：以 Restful API 的形式對外提供測試執行服務，兼具了測試版本管理、Jenkins 測試 Job 管理，以及測試執行結果管理的能力
- 統一測試資料服務：以 Restful API 的形式對外提供測試資料服務，元資料管理，測試資料自動補全，測試資料質量監控（好高階）
- 全域性測試配置服務：比如要測試的不同國家，不同地域，不同語言等配置
- 測試報告服務：根據不同測試，比如GUI測試或者是API測試給出不同的測試報告，並存儲測試報告
- 測試執行環境準備服務：根據測試資料服務，測試內容控制selenium接點和是否擴容（我有生之年還可以用到嗎？？？）
- 被測系統部署服務：以 Restful API 的形式對外提供部署環境，或者安裝APP等服務
測試工作思維
- 測試驅動開發:Test-Driven Development，通常簡稱為 TDD，測試確認好需求，用例給開發，讓開發更有目的。
- 探索式測試:瞭解了需求後，預測到業務上或者實現上可能出現問題，進行有目的的測試。
- 精準測試：藉助一定的技術手段、通過演算法的輔助對傳統軟體測試過程進行視覺化、分析以及優化的過程。
- 理解；技術手段分析用例、資料、程式碼之間的聯絡並把記錄視覺化
- 精準測試範例：http://www.threadingtest.com/index.html
- 核心技術：
- 軟體測試精準顯示波：在人工或者自動化測試過程中記錄邏輯塊，程式碼條件函式呼叫等的速率，並記錄成圖表
- 測試用例和被測產品程式碼的雙向追溯：雙向關聯程式碼和用例
- 智慧迴歸測試用例選取演算法：智慧選取改動程式碼影響的測試用例
測試用例的聚類分析：把用例和業務關聯（就是做一個分類，和2,3有區別？？）
安全測試
- 滲透測試：由專業安全人員模擬黑客，從其可能存在的位置對系統進行攻擊測試，在真正的黑客入侵前找到隱藏的安全漏洞，從而達到保護系統安全的目的。
- 滲透測試分類：
- 有針對性的測試：“開燈”測試，在瞭解內部所有資訊（程式碼，架構，環境）基礎下的測試外部測試
- 針對外部可見的伺服器和裝置（包括：域名伺服器（DNS）、Web 伺服器或防火牆、電子郵箱伺服器等等），模擬外部攻擊者對其進行攻擊，檢查它們是否能夠被入侵，以及如果被成功入侵了，會被入侵到系統的哪一部分、又會洩露多少資料
- 內部測試；由測試工程師模擬內部人員，在內網（防火牆以內）進行攻擊，因此測試人員會擁有較高的系統許可權，也能夠檢視各種內部資料，目的是檢查內部攻擊可以給系統造成什麼程度的損害
- 盲測；嚴格限制提供給測試執行人員或團隊資訊的前提下，由他們來模擬真實攻擊者的行為和上下文。通常，測試人員可能只被告知被測系統公開的資訊，而對系統細節以及內部實現一無所知
- 雙盲測試：也叫作“隱祕測試”，不光測試人員對系統內部知之甚少，而且被測系統內部也只有極少數人知道正在進行安全測試。因此，雙盲測試可以反映軟體系統最真實的安全狀態，能夠有效地檢測系統在正常情況下，對安全事件的監控和處理能力是否合格
- 滲透測試步驟
- 規劃和偵察：定義測試的範圍和目標、初步確定要使用的工具和方法、明確需要收集的情報（例如，網路和域名，郵件伺服器）
- 安全掃描：包括靜態分析（掃描所有程式碼來估計其執行時的方式，工具Fortify SCA 和 Checkmarx Suite）和動態分析兩個階段（程式碼執行時進行掃描）。
- 獲取訪問許可權：模擬黑客對應用程式進行網路攻擊，例如使用 SQL 注入或者XSS 跨站指令碼攻擊，發現系統漏洞，利用漏洞升級自己的許可權、竊取資料、攔截流量等方式瞭解其可能對系統造成的損害
- 維持訪問許可權，檢視被發現的漏洞是否可以長期存在於系統，或者通過手段保持漏洞存在
- 入侵分析：可以被利用的特定漏洞；利用該漏洞的具體步驟；能夠被訪問的敏感資料；滲透測試人員能夠在系統中不被偵測到的存在時間。
- 滲透測試工具
- 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 安全漏洞。
基於模型的測試
- 定義：Model-Based-Testing，簡稱 MBT,是自動化測試的一個分支。它是將測試用例的設計依託於被測系統的模型，並基於該模型自動生成測試用例的技術。其中，這個被測系統的模型表示了被測系統行為的預期，也可以說是代表了我們對被測系統的預期。
- MBT 的基本原理是通過建立被測系統的設計模型，然後結合不同的演算法和策略來遍歷該模型，以此生成測試用例的設計。‘
- 常用模型，有限狀態機：不同組合對應不同狀態，狀態圖，UML
- MBT 工具簡介 BPM-X fMBT
- 優缺點：優點已維護，缺點難學，花錢
試試
- spring boot + Cucumber + REST Assured + selenium
- 基於API測試：REST Assured
- java 單元測試框架：TestNG，Junit
- C語言測試工具：CppTest，Parasoft C/C++test
- java 程式碼覆蓋率統計：JaCoCo，原理：基本方法注入（Instrumentation），注入就是在被測程式碼中自動插入用於覆蓋率統計的探針（Probe）程式碼，並保證插入的探針程式碼不會給原始碼帶來任何影響。
- 對於 Java 程式碼來講，根據注入目標的不同，可以分為原始碼（Source Code）注入和位元組碼（Byte Code）注入兩大類。基於 JVM 本身特性以及執行效率的原因，目前主流的工具基本都是使用位元組碼注入，注入的具體實現採用 ASM 技術。
- 兩種方式
On-The-Fly模式：支援Java Agent的執行環境，代理方式，代表工具：JaCoCo
Offline 注入模式：無法實時獲取程式碼覆蓋率資訊，只能在系統停機時下獲取，不需要代理，代表工具：Cobertura
- JavaScript 程式碼覆蓋率統計：Istanbul
- 測試程式碼分類：
- 驅動程式碼（Driver）指呼叫被測函式的程式碼。在單元測試過程中，驅動模組通常包括呼叫被測函式前的資料準備、呼叫被測函式以及驗證相關結果。
- 樁程式碼（Stub）是用來代替真實程式碼的臨時程式碼;比如，某個函式 A 的內部實現中呼叫了一個尚未實現的函式 B，為了對函式 A 的邏輯進行測試，那麼就需要模擬一個函式 B，這個模擬的函式 B 的實現就是所謂的樁程式碼。
- 覆蓋率：業務覆蓋率，程式碼覆蓋率
- 持續整合工具：jenkins，sonar
- 測試服務化 TaaS ：Test as a Service，就是把所有的測試變成一個服務，比如準備資料的服務，mock介面的服務，小業務模組也是個服務，便於管理和呼叫，需要根據自己的實際情況規劃，這個能力需要進一步加強！！！
- 資料驅動(資料與)：採用資料和測試程式碼分離的形式，把資料集中化，保證當某些點或者邏輯發生改變的情況下，可在最小的代價下除錯程式碼。資料驅動包括：輸入資料，業務判斷標識資料和斷言資料
- 頁面物件（Page Object）模型:這就是所謂的PO，人造概念，其實就是先把每個要操作的元素封裝成一個變數，放到同一個類或者配置檔案中，再把每個功能（比如；一個功能包括對多個元素的操作）封裝成一個方法。每個頁面就是一個類,開源工具Katalon Studio。
- 物件自動生成工具：自動生成頁面物件模型的類，Katalon Studio。工具能在提