產品設計需求文件的軟體：
例項：分析需求 編寫用例
每個用例都是乙個場景、具體的邏輯要梳理需求設計文件，還是不清楚的要和產品核對
實付金額 = 訂單數× 客單價
訂單數=客單數
總業績概況中的實付金額=成交訂單數 ×客單價
訂單數=客單數
月份 （28天的、30天的、31天的）
當前日期 會員
定義：基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從⽽有針對性的設計測試⽤例的⽅法。
假設----》驗證---》結論來驗證假設是否正確
場景1：
針對電商類的產品，我們開啟首頁後只載入能夠看見的資源資訊，隨著往下滑動的過程中資源都會載入出來，這個過程可能會出現頁面卡住或者卡死。
針對翻頁的元件：只展示當前頁面的資料，後面的資料是隨著翻頁的過程中逐步載入的，那麼可能就會出現頁面卡死或者卡住
上傳檔案元件：上傳1g的檔案，那麼可能就會導致上傳的問題缺失，或者是檔案上傳成功後，檔案內容是亂碼，還有可能是出現記憶體洩露（outofmemory --->oom）
針對底層服務：（效能測試）
1、超時
2、堵塞
3、假死
1、定義：判定表是分析和表達多邏輯條件下執⾏不同操作的情況的⼯具。
2、優點：能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利⽤判定表能夠設計出完整的測試⽤例集合。
缺點：不能表達重複執行的動作、例如迴圈結構。
3、應用場景：在⼀些資料處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執⾏不同的操作。判定表很適合於處理這類問題。（適用於有多個輸入和多個輸出，輸入和輸出之間有相互的組合關係、制約和依賴關係。
4、四個組成部分：
1)條件樁（condition stub）：列出了問題得所有條件。通常認為列出的條件的次序⽆關緊要。
2)動作樁（action stub）：列出了問題規定可能採取的操作。這些操作的排列順序沒有約束。
3)條件項（condition entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。
4)動作項（action entry）：列出在條件項的各種取值情況下應該採取的動作。
5、規則
任何乙個條件組合的特定取值及其相應要執行的操作稱為規則。
在判斷表中貫穿條件項和動作項的一列就是一條規則。顯然判定表中列出多少組條件取值，也就有多少條規則，即條件項和動作項有多少列。
6、步驟
①明確規則個數
②列出所有條件項和動作項
③填入條件項
④填入動作項，等到初始判定表
⑤簡化，合併相似規則
7、小結
因果圖法是通過判定表法的乙個中間過程，我們經常會將因果圖法和判定表分析法結合起來使用。
對於業務邏輯比較複雜的我們建議先使用因果圖法進行分析，然後再轉化為判定表法，最後寫測試用例，這樣思路比較清晰。
對於簡單的可以直接使用判定表法分析，然後寫測試用例。
判定表驅動分析法：劃分測試的範圍和邊界，列出需要測試的各種不同的條件。（列表的方式去列出因果圖的輸入和輸出結果，是因果圖的簡化版）
因果圖：在劃分測試範圍的基礎上，列出各個不同條件的排列組合的測試。（分析輸入條件、條件之間的關係組合、對應的輸出結果）
正交實驗分解法：在因果圖的基礎上，選擇有代表的資料進行測試。
jira；tapd)
面試：工作用的專案管理工具？
tapd。早上上班登入tapd工具，接收自己今日的任務，並且把任務狀態改為實現中/進行中，完成之後狀態改為已完成/已實現。
這種在軟體設計⽅⾯的思想也可以引⼊到軟體測試中，可以⽐較⽣動地描繪出事件觸發時的情景，有利於測試設計者設計測試⽤例，同時使測試⽤例更容易理解和執⾏。
大多數業務軟體由後台管理（比如：使用者管理、角色管理、許可權管理等等各種管理）和工作流等幾個部分組成。終端使用者，期望軟體能夠實現業務需求，而不是簡單的功能的組合。對於單點功能利用等價類、邊界值、。判定錶用例設計方法能夠解決大部分問題。涉及業務流程的軟體系統，採用場景法比較合適。
總之，對於多個功能組合測試的場景適合使用場景法，所以場景測試，也是業務場景組合測試。
基本流：表示通過業務流程時輸入都正確，正達到目標的流程。
備選流：表示通過業務流程時輸入錯誤（或者操作錯誤）導致流程存在反覆，但經過糾正後能達到目標的流程(插卡→輸入錯誤密碼→輸入正確密碼→輸入金額→取款→取卡)
異常流：表示通過業務流程時輸入錯誤（或者操作錯誤）產生異常終止流程
步驟:開始 、過程、結束（產品從無到有，和使用者使用的過程）
例：網購商品
開始：商品通過審核，商品上架。
過程：使用者搜尋產品關鍵字，瀏覽挑選產品，檢視產品詳情，加入購物車，填寫收貨資訊，完成支付，收貨，評價。
結束：商品下架，商品搜尋不到。
小結：場景流程比較適合於涉及到業務需求的場景，能夠多個功能聯合進行測試，不是單個功能進行測試
⼀個程式的功能說明通常由動態說明和靜態說明組成.動態說明描述了輸⼊資料的次序或轉移的次序.靜態說明描述了輸⼊條件與輸出條件之間的對應關係.對於較複雜的程式,由於存在⼤量的組合情況,因此,僅⽤靜態說明組成的規格說明對於測試來說往往是不夠的.必須⽤動態說明來補充功能說明.功能圖⽅法是⽤功能圖fd形式化地表示程式的功能說明,並機械地⽣成功能圖的測試⽤例.
測試⽤例則是由測試中經過的⼀系列狀態和在每個狀態中必須依靠輸⼊/輸出資料滿⾜的⼀對條件組成.功能圖⽅法其實是是⼀種⿊盒⽩盒混合⽤例設計⽅法。
產品測試，快速建立全域性思維：
1、使用場景設計方法快速梳理出被測產品的核心業務邏輯。
2、使用判定表驅動分析方法列出流程中可能的邏輯判斷條件。
3、使用功能圖列出產品的輸入輸出，完善每個不同條件下的業務場景。
條件不同代表著場景不同。就會出現正常業務流程和異常業務流程。
例如：拿電商產品的商品上架為例：
1、上架審核通過，那麼就可以搜尋購買
2、審核拒絕，商品搜尋不到
3、庫存位0，商品未下架
面試題：
一共有多少種設計方法，分別是什麼？舉例說明使用場景？
軟體測試 理論3
軟體測試用例設計方法 1.等價類劃分法 把程式的輸入域劃分為若干部分，從每個部分選取少數代表性資料作為測試用例。每一類的代表性資料在測試中的作用等價於這一類中其他值，該集合內的每個資料都是等效的，可以將該集合視為等價的一類。有效 無效 等價類 2.邊界值分析法 上點 邊界值的點，內點 域內的任意一點...
敏捷測試理論以及實踐 3
本篇是 敏捷 測試理論以及實踐 第三篇，第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇 現在先來總結一下到底上面說的模型存在著哪些問題 1.客戶生氣地說 這個產品好像不是我們想要的吧！早知你們給我這樣子的產品，我才不會下單了，你們也早點跟我說這個產品是這樣子，到現在才給我看，浪費我時間，精力...
測試理論小結
典型的測試步驟 1 計畫 確定目標，確定測試策略，測試方法 2 執行 建立測試環境，按測試計畫執行 3 檢查 一步步驗證，是否執行完畢 4 迴圈 如果沒有改正，繼續執行 測試職責 1 驗證在整個軟體開發周期中，各個階段的軟體質量是否合格 2 驗證最終交付給客戶的軟體系統是否是客戶想要的，滿足需求的 ...