v模型，瀑布模型，敏捷開發模型，W模型
軟件生命周期:
1，問題的定義和規劃
2.需求分析
3、軟件設計(明確怎麽做！)
4.軟件編碼
5.軟件測試
6.使用和維護
測試生命周期:
單元測試:通常在開發完成時。
集成測試:單元測試後，單元之間的接口是否正確，數據傳輸是否正常。比如註冊和充值兩個功能是否可以連接。
系統測試:根據測試用例進行完整的系統測試。
驗收測試:用戶接受軟件。
軟件測試階段:
單元、集成、系統和驗收(正式驗收、Alpha測試和Beta測試)
軟測量方法:
白盒測試、黑盒測試和灰盒測試
軟測試類型:
功能、接口、安全性、兼容性、可用性、性能、壓力、負載、恢復測試等。
其他測試類別:冒煙測試、回歸測試和探索性測試。
常見的開發模式:V模式
軟件測試的分類
什麽是黑盒測試？
黑盒測試，也稱功能測試，是測試各項功能能否正常使用。不管內部結構如何，測試都是在程序接口中進行的。
Alpha測試和Beta測試的區別是什麽？
Alpha測試:預用戶測試，在模擬實際操作環境下，在公司內進行的驗收測試。
Beta測試:後期用戶測試，已經通過內測，即將發布，是軟件在壹個或多個用戶的實際使用環境下的測試。
冒煙測試和回歸測試有什麽區別？
冒煙測試:新版本出來後，會對軟件的所有功能進行審核，功能可以正常進行，不影響測試進度。這個版本真的可以測試。
回歸測試:驗證在以前版本中發現的bug在新版本中是否存在，是否引起新的bug。
1，邊界值:
選擇等於、剛好高於和剛好低於邊界的值作為測試數據。
基本思路是取最小值，略高於最小值，正常值，略低於最大值，最大值。
2、等價類的劃分:
等價類劃分是將壹個程序的輸入域分成幾個部分，然後從每個部分中選取少量有代表性的數據作為測試用例。
無效等價類:不合理且無意義的輸入數據，驗證程序處理意外數據的能力。
有效等價類:有意義的輸入數據的集合，它驗證程序是否實現了規範的整體功能和性能。
等價類劃分方法:按區間劃分、數值劃分、數值集劃分、限制條件和規則劃分。
3.誤差推理算法:
執行錯誤操作，驗證程序是否有某種處理錯誤場景和情況的能力，選擇測試用例數據。
4、因果法/決策表法:
基於決策表的每壹列設計測試用例。檢查輸入條件的各種組合。
5、情景法:
通過描述業務流程，設計用例來列出不同的業務場景作為測試用例的測試數據。
基本流程:主要是功能的正常操作流程。
分支和支流:需要程序非法判斷的。
*測試用例方法的選擇*(重點)
1，等價類的劃分，主要是輸入條件的劃分，是提高測試效率最有效的方法。
無論如何，必須使用邊界值分析法，這種方法設計測試用例發現程序錯誤的能力最強。
2.通過錯誤推測添加測試用例。
3.如果程序描述包含輸入組合，則從壹開始就使用判斷表方法(很少使用判斷表方法)。
4.如果沒有達到覆蓋標準，就要補充足夠的測試用例(場景法)。
1.在需求文檔中列出測試性的原始需求。
2.每個需求被細分成可測試的測試點。
3.為測試點確定合適的測試類型。
4.建立壹個測試需求分析矩陣來管理測試需求。
軟件測試需求的重點是“測試什麽”。
測試需求分析的目的是獲取測試點，並根據測試點編寫用例。
按鈕指示燈:按下上下按鈕時指示燈是否亮。
電梯門開關:按上下按鈕，看電梯門在當前樓層是否能打開。
按下上行按鈕:電梯是否關閉並前往上層？
按下下行按鈕:電梯是否關閉並向下層運行？
電梯門沒關的時候:按下按鈕打開電梯門，門開了嗎？
電梯門沒關的時候:按下按鈕關電梯門，門關了嗎？
電梯內:根據每個樓層，相應的指示燈是否亮起？
電梯內的報警裝置:報警裝置正常嗎？
電梯裏的通訊設備:按呼叫按鈕能和外面連接嗎？
電梯內照明:電梯內照明是否亮著，是否損壞。
電梯內通風:通風嗎？
按下每個樓層按鈕:是否要停在當前樓層並開門？
超過最大載重量時:電梯是否報警打開電梯門，直到小於最大載重量？
電梯當前樓層與電梯內顯示樓層壹致嗎？
顯示屏中是否有當前樓層，當前向上或向下箭頭，並與當前操作壹致。
電梯門超過規定時間不關會有報警提示嗎？
上行和下行按鈕是控制壹部電梯還是兩部電梯的開關門，如果控制兩部電梯，按上行或下行按鈕，另壹部電梯是否控制。
電梯分單層和雙層嗎？
在單層電梯的情況下，按雙層電梯。雙層電梯對應的數字亮了嗎，會到達這壹層嗎？
在雙層電梯的情況下，按照單層電梯，單層電梯對應的號是不是亮了，會不會到這個樓層？
電梯樓層限制:根據超過樓層限制的電梯樓層數，數是否開，是否會到達本樓層。
雙擊壹個樓層:這個樓層會不會被取消，樓層燈滅？
如果我在9樓，有人先按12樓，再按1樓。電梯是不是應該先上12樓，再下1樓？
電梯感應:有人或物體卡在門中間，門會不會關上，會不會報警？
電梯到達指定樓層時有聲音提示嗎？
電梯是否刷卡:如果電梯刷卡，我可以選擇樓層嗎？
維修開關:電梯裏有維修開關嗎？
測試用例:指導測試執行並幫助證明軟件功能或發現軟件缺陷的描述。每個測試點的數據設計和步驟設計。
測試用例的重要性:
(1)，易於實現測試計劃。
壹般主要適用於集成測試、系統測試和回歸測試。根據用例了解您的進度
(2)計劃測試數據的準備
比如註冊，要提前準備好手機號，身份證號，唯壹用戶名，郵箱。
(3)編寫測試腳本的基礎
自動化測試的中心任務是編寫測試腳本。測試腳本基於測試用例。
(4)評估測試結果的基準
通過測試用例的覆蓋率和錯誤率來判斷測試結果是否可以發布。
(5)、缺陷分析標準
？收集缺陷並比較測試用例。分析缺失或缺陷再現。反映了測試的不完善，相應的測試用例應該馬上補充。
*如何寫考題:考點，並對考點進行細化分解。比如輸入正確的用戶名和密碼，能正常登錄嗎？
測試用例編寫格式註:
(1)，試題標題壹定要描述考點(驗證什麽，寫什麽)，簡潔明了，沒有重復。
(2)、測試步驟應具有指導性，涉及測試數據輸入時，最好包括具體的測試數據。
(3)預期結果是唯壹的，不能出現“發送成功或失敗”。
如何寫測試用例？
用例包括:用例編號、功能模塊、用例標題、前提條件、操作步驟、預期結果(包括判斷標準)、實際結果和備註。
編寫方法:按功能+業務邏輯
(1)，首先保證單個功能正常。
(2)組合功能的業務邏輯正確。
比如登錄，充值，提現功能都不錯。業務邏輯就是把所有的功能組合起來，過壹遍，看看好不好。
用例覆蓋:有正面和負面的用例。
(1).正面用例:按照功能模塊劃分，為待測試的功能模塊編寫所有輸入數據正常的測試用例。
(2)負面用例:如登錄失敗、非法數據輸入、違反唯壹約束等。