軟件測試?？济嬖囶}-軟件測試面試寶典(5)

邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.

錯誤猜測法
基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為 0 的情況.輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

正交表分析法
有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

場景分析方法
指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。

狀態圖法
通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測試用例。

23.詳細的描述一個測試活動完整的過程。

答案：（供參考，本答案主要是瀑布模型的做法）

• 項目經理通過和客戶的交流，完成需求文檔
• 由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。
• 項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。然后 SQA 進入項目，開始進行統計和跟蹤
• 開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。
• 測試人員完成測試計劃文檔，測試計劃包括的內容上面有描述。
• 測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。
• 測試用例完成后，測試和開發需要進行評審。
• 測試人員搭建環境
• 開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現 BUG后提交給 BugZilla。
• 開發提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進行測試。
  重復上面的工作，一般是 3-4 個版本后 BUG 數量減少，達到出貨的要求。
• 如果有客戶反饋的問題，需要測試人員協助重現并重新測試。

24.BUG 管理工具的跟蹤過程

用 BugZilla 為例子
測試人員發現了 BUG，提交到 bugzilla/' target='_blank'>Bugzilla 中，狀態為 new，BUG 的接受者為開發接口人員
開發接口將 BUG 分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的 BUG，則設置為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論并確認后，拒絕這個 BUG，

原文轉自：https://blog.csdn.net/mj813/article/details/52451355