需求分析——採用技術——理論支持
1.需求分析
1.1團隊代碼開發工作流
1.規約、文檔、需求分析原型設計
2.架構與編碼 (代碼版本管理系統Git/SVN)
3.代碼審查、測試與調試【本篇主要任務】
4.發佈、部署
1.2需要的功能
參考我上一篇博客收集到的現有工具來進行分析：
代碼檢查、評審、單元測試工具 大搜集
軟件測試對象的6種分類:
單元測試（靜態檢查、動態測試）
集成測試
壓力測試
迴歸測試
Alpha測試（系統測試）
Bete測試（交付測試）
- IDE界面
讓使用者可以粘貼或修改代碼，提供語法高亮和檢查 - 導入工程 配置編譯器
爲方便使用和整體測試，提供可以全工程導入的方法
爲適應不同編譯環境的系統，讓代碼跑起來的環境應該可以自定義，對新手提供路徑方法提示 - 生成測試用例
可以手動輸入用例、可以自動按類型生成測試用例、可以按規則設置用例、可以導入導出用例 - 靜態測試、動態測試，迴歸測試
可以進行迴歸測試，判斷按照斷言機制，生成驅動函數並返回正確率 - 性能測試（時間、內存，類似在線判題系統）
對運行各個模塊所消耗的時間和內存進行記錄 - 生成報表
可以生成徵提的測試報告 - 樁函數 覆蓋率分析
爲解決不便測又存在於其他模塊流程中的模塊的運行問題，進行樁函數處理
對控制語句進行白盒測試的覆蓋率分析
2.採用技術（功能模塊）
-
IDE界面
使用現有開源的IDE作爲基礎，並對其進行精簡和二次開發，測試的反饋頁顯示在它上面 -
導入工程 配置編譯器
貌似是調用系統命令行驚醒自動處理，配置改的就是其調用參數 -
生成測試用例 斷言與迴歸測試
用例進行擴充，包括名字、電話等類型的自動生成
使用現有開源測試框架，自動生成其基礎之上的驅動函數再運行
C++ 的單元測試工具 —— Catch
google test -
樁函數 覆蓋率分析
不懂 -
性能測試（時間、內存，類似在線判題系統）
google benchmark -
生成報表
不懂
3.理論支持
- 單元測試（Unit Testing）
顆粒度最小，一般由開發小組採用白盒方式來測試，主要測試單元是否符合“設計”；是指對軟件中的最小可測試單元進行檢查和驗證。 - 集成測試
介於單元測試和系統測試之間，一般由開發小組採用白盒+黑盒的方法來測試，即驗證“設計”又驗證“需求”。主要用來測試模板與模板之間的接口，同時還要測試一些主要的業務功能。 - 系統測試
顆粒度最大，一般由獨立的測試小組採用黑盒的方式來測試，主要測試系統是否符合“需求規格說明書”。在經過以上各階段測試確認後，把系統完整的模擬客戶環境來進行測試。
以上摘自：什麼是：單元測試、集成測試、系統測試
其中，集成測試對象是由通過了單元測試的各個模塊所集成起來的構件；系統測試對象則除了軟件之外，還包括計算機硬件及相關的外設、數據採集和傳輸機構、支持軟件、系統操作人員等整個系統。
所以此處我們着重討論單元測試
以下摘自：
軟件測試概念及分類整理彙總（真大佬，很全面）
單元測試(自頂向下，自底向上，靜態測試)
單元(Unit)指一個可獨立運行的代碼段，獨立運行指這個工作不受前一次或接下來的程序運行的結果影響。
單元測試的內容包括對最小單元進行功能、性能、接口和設計約束等正確性檢驗，主要- 測試其在語法、格式和邏輯上的錯誤。
3.1單元測試重點內容
- 白盒測試
語句覆蓋測試
判定覆蓋測試
條件覆蓋測試
判定—條件覆蓋測試
條件組合測試
路徑覆蓋測試 - 黑盒測試
等價類劃分方法
邊界值分析方法
錯誤推測方法 - 靜態測試
代碼走查
代碼審查
代碼評審
3.2單元測試的內容
-
模塊接口測試
對通過被測模塊的數據流進行測試，檢查進出模塊的數據是否正確。
調用本模塊的輸入參數是否正確；
本模塊調用子模塊時輸入給子模塊的參數是否正確；
全局量的定義在各模塊中是否一致；
外部輸入、輸出。
模塊局部數據結構測試 -
檢查局部數據結構能否保持完整性。
不正確或不一致的數據類型說明
變量無初值
變量初始化或默認值有錯
不正確的變量名或從來未被使用過
出現上溢或下溢和地址異常
模塊邊界條件測試 -
檢查臨界數據是否正確處理
普通合法數據是否正確處理
普通非法數據是否正確處理
邊界內最接近邊界的(合法)數據是否正確處理
邊界外最接近邊界的(非法)數據是否正確處理
模塊獨立執行路徑測試 -
對模塊中重要的執行路徑進行測試。檢查由於計算錯誤、判定錯誤、控制流錯誤導致的程序錯誤。
運算符優先級
混合類型計算
精度不夠
表達式的不正確符號
循環變量的使用錯誤
模塊內部錯誤處理測試 -
檢查內部錯誤處理設施是否有效。
輸出的出錯信息難以理解
記錄的錯誤與實際不相符
程序定義的出錯處理前系統已介入
異常處理不當
未提供足夠的定位出錯信息
3.3單元測試的環境
基本單元本身不是一個獨立的程序，自己不能運行，要靠其它部分來調用和驅動。
驅動模塊的設計比樁模塊簡單
- 驅動模塊(driver)
被測基本單元的主程序，它接收測試數據，並把數據傳送給被測單元，最後輸出實測結果。 - 樁模塊(stub) ──存根模塊
用來代替被測基本單元調用的其他基本單元。
3.4其他補充
4.擼起袖子加油幹！
基本思路就是——IDE+調用分析+編譯運行+結果記錄。
4.1蒐集養料
先進行頂層設計，搭好框架，要用什麼做出有什麼功能的東西？
不同功能之間的代碼低耦合，最好能以插件形式存在（靜態、動態、錄製……）
C++ 動態鏈接庫的兩種調用方式
開源一個代碼規範檢測工具
基於動態輸入追蹤的模糊技術研究
下圖來自論文“基於動態輸入追蹤的模糊技術研究”，這是個逆向的漏洞測試。
還有 Cppcheck分析報告裏的處理流程和功能組成
4.2編輯界面+編譯選項——簡單的IDE
在VS code中使用MSVC+命令行編譯生成C++程序
Cppcheck的命令行使用
我採用qt框架和c++語言，先搭出編輯器的架子
開發自己的IDE（十），我終於搞定了智能提示了哇哈哈
4.3調用cppcheck進行靜態分析
通過命令行進行調用？
4.4使用googletest框架進行動態測試
如何使用googletest？
4.5性能測試
記錄並顯示
4.6覆蓋率分析、生成報表
如何使用googletest？
4.7操作錄製，自動化測試
這又是另一種問題