1. 單元測試-計畫 在day01裡面學過
1) 確定要測試**範圍
2) 評估標準(確定被測**的覆蓋率)
2. 測試策略-設計
1) 拿到開發**進行調整(可獨立執行)
1. 自上向下
2. 自下向上
3. 孤立策略
方式：從最上層函式往下開始逐層測試兩個函式(求和、求減)，求和函式內呼叫求減函式；1. 編寫求和函式
2. 編寫求減函式
3. 在求和函式內呼叫求減函式
4. 呼叫求和函式
1. 我們只想測試求和函式不測求減函式該如何做？概念：打樁就是模擬編寫乙個我們需要引用的函式
示例： def fun_1(self):
return true
1. 方式
2. 打樁(模擬呼叫的函式)
3. 缺點(成本高)
方式：從最底層函式往上開始逐層測試1. 方式
2. 缺點(周期長) 要等開發把最下層函式定義好
方式：選擇需要進行測試的函式進行測試1. 方式
2. 【推薦使用】
3. 優點：選擇重要的**進行測試
測試策略-實現
1) 根據調整好的**-畫流程圖
2) 根據流程圖畫流圖-確定複雜度、路徑
3) 根據複雜度和路徑確定測試用例(測試資料)
概念：表達程式業務邏輯的複雜度一種示意圖
構成：
1) 圈：判斷條件、語句塊(一條或多條語句)兩者都圈
2) 線：箭頭指向的線，用來連線圈和圈的指向
1) 確定單元的複雜度級別
2) 確定測試用例
備註: 路徑的個數為複雜度的級別(一條路徑為1個複雜度級別)
函式(test001)判斷引數a,如果a>0，執行語句1；
流圖其實就是程式所有可能執行的邏輯。
根據流圖可以寫出測試用例，這樣寫出的測試用例完全覆蓋了所有的可能。
注意：在根據流圖寫測試用例時，一定要把流圖附在用例檔案裡，不然誰知道你路徑怎麼標的。
1. 路徑：2 (1-2-4,1-4) 路徑個數就是複雜度個數
2. 複雜度：2
3. 用例個數：2
總結出結論：複雜度最少為條件個數，最多為條件個數加1
函式(test002)判斷引數a,b;如果a>0 and b<10 輸入語句1；否則輸入語句2；
**:流程圖:
流圖：
思考
如果把案例3的條件 a>0 and b<10 換成 條件1 or 條件2 那麼複雜度是多少？
輸入兩個數，如果兩個數同時為大於0小於10，那麼就進行求和運算；否則判斷兩個數是否同時大於等於10小於20那麼
就進行求減運算，否則輸入錯誤；
**：流程圖：
流圖：
（可能判斷條件裡面的**調下順序結果就不一樣）
測試用例
使用while迴圈求1-10相加之和；
**：流程圖：
流圖：
提示輸入三角形三條邊,進行判斷三角形型別(等邊、等腰、普通)並進行提示，否則提示不是三角形；
三角形：兩邊之和大於第三邊；
等腰三角形：兩條邊相等
等邊三角形：三條邊相等
1. **：
1) 自定義函式
2) 判斷是否為三角形
3) 判斷是否為等邊三角形 如果是等邊肯定就是等腰了，沒必要往下走，所以等邊判斷在等腰上面
4) 非等邊三角形繼續判斷是否為等腰三角形
5) 如果不是等腰三角形，輸出普通三角形
2. 流程圖
3. 流圖
4. 用例
1. 單元測試計畫
2. 測試策略設計
3. 測試策略實現
測試day02整理
瀑布模型是將軟體生存週期的各項活動規定為按固定順序而連線的若干階段工作，形如瀑布流水，最終得到軟體產品。優點1.開發的各個階段比較清晰 2.強調早期計畫及需求調查 3.適合需求穩定的產品開發 缺點1.依賴於早期的需求調查,不適應需求變化 2.單一流程不可逆 3.風險往往延至後期才顯露,失去及早糾正的...
測試用例設計Day02
設計測試用例的步驟 典型應用場景 設計測試用例步驟 設計測試用例 典型應用場景 需求數學表示 上點內點 離點精簡5點 6 16位自然數 需求數學表示 上點內點 離點精簡5點 標題長度 0且標題長度 30 需求 兩位數加法器取值範圍 數學表示 上點內點 離點精簡5點 大於等於 99，小於等於99 99...
python 白盒測試 白盒測試方法
白盒測試是單元測試階段常用到的測試方法，其特點有 1 可以構成測試資料，使特定程式部分得到測試 2 有一定的充分性度量手段 3 可獲得較多工具支援 4 通常只用於單元測試。下邊通過一段 來看一下白盒測試中的邏輯覆蓋 那麼為了清晰，我們畫出乙個該程式的流程圖 1 語句覆蓋 語句覆蓋是最弱的邏輯覆蓋準則...