1.概念：驗證軟體功能是否能夠滿足使用者的需求。（找bug,驗證它沒有問題)
2023年，《軟體測試藝術》：軟體測試是為了發現錯誤而執行程式或系統的過程。
2023年，《軟體測試完全指南》，測試是以評價乙個程式或者系統屬性為目標的任何一種活動。測試是對軟體質量的度量。
2023年，ieee軟體工程標準術語：使用人工或自動手段，來執行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清楚預期結果與實際結果之間的差別。
2.目的：驗證軟體有或者沒有問題。
3.原則;以客戶為中心，遵循軟體測試的規範，流程，標準和要求。
4.需求：滿足使用者期望或正式規定文件(合同，標準，規範)所具有的條件和權能，包括使用者需求和軟體需求
1)使用者需求：一般比較粗略，不能指導開發人員和測試人員進行工作。
2)軟體需求：一般更詳細，更加具體，可以指導開發人員和測試人員進行工作。
5.bug：
1) 當需求規格說明書存在且正確，程式與需求規格說明書不匹配就是bug.
2) 當沒有需求規格說明書時，判斷標準最終以使用者的期望為標準.(即當程式沒有實現使用者最終預期的結果就是bug)
6.測試用例：為了實施測試而向被測試的系統提供的一組集合。該集合包括：測試環境，操作步驟，測試資料，預期結果。
測試用例的編號是唯一的。
7. 為什麼編寫測試用例?
1) 不知道是否較全面的測試了所有功能
2) 測試的覆蓋率無法衡量
3) 對新版本的重複測試很難實施
4) 存在大量冗餘測試影響測試效率
1.軟體的生命週期：需求分析-->計畫-->設計-->編碼--> 測試-->執行維護。
2.瀑布模型(wate***ll model)
優點：1) 強調開發的階段性 2) 強調早期計畫及需求調查 3) 強調產品測試
缺點：1) 依賴於早期進行的唯一一次需求調查，不能適應變化
2) 流程單一，開發中的經驗教訓不能反饋應用於本產品的過程
3) 風險往往到了後期的測試階段才能顯露出來，因此會措施盡早糾正的機會
應用場景：1) 需求變更比較小的項 目 2) 和之前專案比較類似的專案
3.螺旋模型(spiral model) （漸進式的開發模型）
優點：1) 強調嚴格的全過程風險管理 2) 強調各開發階段的質量 3) 提供機會檢討專案是否有價值繼續下去
缺點：引入了非常嚴格的風險識別，風險分析和風險控制，這對風險管理的技能水平提高了很高的要求.
應用場景：適用於規格龐大，複雜度高，風險大的專案.
4.增量、迭代
增量：逐塊建造的概念(直接進入一小塊進行處理，處理完，在進行另一塊的處理)
增量開發的優勢：能顯著降低專案風險
迭代：反覆求精的概念(先整體，後細節)
5.敏捷
敏捷開發模式與傳統開發模式的區別？
1) 強調人與人之間的溝通
2) 輕文件(對需求規格說明書的依賴少)
3) 使用者參與專案開發過程
4) 擁抱變化
敏捷特點：人數少，周期短
scrum裡面的角色：
產品負責人po （product owner）
專案經理 sm （scrum master）
研發團隊 team (包括所有成員po,sm........)
敏捷中的測試：輕文件(依賴少，若沒有文件，則與客戶進行溝通)
6.軟體測試v模型
v模型的缺點：測試時工作放在最後，讓人誤以為測試工作不重要
發現缺陷的時間比較晚，修改的工作複雜。
7.軟體測試w模型
w模型的缺陷：解決不了需求要頻繁更改的專案需求
1.軟體測試的流程（生命週期）：
需求分析--->測試計畫--->測試設計--->測試開發--->測試執行--->測試評估
2.軟體開發的生命週期
需求階段--->計畫階段--->設計階段--->編碼階段--->測試階段--->執行階段
3.描述乙個bug
版本號、環境、操作步驟、預期結果、實際結果(一條測試用例只有乙個結果)......
4.定義乙個bug的級別
blocker (崩潰) 、critical (嚴重)、major (一般)、minor (次要)
5.bug的生命週期
new:發現新的bug,未經評審決定是否指派給開發人員進行修改。
open:確認是bug,並且認為需要進行修改，指派給相應的開發人員。
fixed:開發人員進行修改後標識成修改狀態，有待測試人員的回歸驗證測試。
rejected:如果開發人員認為不是bug,則拒絕修改。
delay:如果認為暫時不需要修改或暫時不能修改，則延後修改。
closed:修改狀態的bug經測試人員的回歸測試驗證並驗證通過，則關閉bug.
reopen:如果經驗證bug仍然存在，則需要重新開啟bug，開發人員重新修改。
無效的bug：open--->closed open--->rejected--->closed
6.執行測試
1) 開啟待測試的系統
2) 開啟測試管理工具用例模組，開始執行用例
3) 發現bug,進行復現確認bug的復現步驟
4) 記錄bug
5) 溝通bug
6) 驗證以前提交的bug
7) 確認本次測試完成
8) 編寫測試報告
7.如何發現更多的bug
1） 軟體測試的二八原則，80%的故障集中於20%的模組。
2) 開發人員的二八原則，80%的故障集中於20%的開發人員。
3)多進行逆向思維和發散性思維
4) 不要侷限於用例和需求文件
5) 盡早介入專案，不等到開發的差不多了再進入專案
回歸測試相關知識理論
最近學習了回歸測試的一些基礎知識，現在分享一下我的學習成果。1.回歸測試的定義 產品修正了bug或增加了功能，生成新的版本，對這個版本進行測試，就叫做回歸測試。回歸測試是指修改了舊 後，重新進行測試以確認修改沒有引入新的錯誤或導致其他 產生錯誤。1.確認軟體中被修改的部分 2.從原基線測試用例庫中,...
測試理論小結
典型的測試步驟 1 計畫 確定目標，確定測試策略，測試方法 2 執行 建立測試環境，按測試計畫執行 3 檢查 一步步驗證，是否執行完畢 4 迴圈 如果沒有改正，繼續執行 測試職責 1 驗證在整個軟體開發周期中，各個階段的軟體質量是否合格 2 驗證最終交付給客戶的軟體系統是否是客戶想要的，滿足需求的 ...
測試理論二
1.軟體測試的分類 1 按測試策略分類 黑盒 白盒測試 動態 靜態測試 手工 自動測試 2 按測試階段分類 單元測試 整合測試 確認測試 系統測試 驗收測試 3 按測試方法分類 功能測試 效能測試 壓力測試 負載測試 易用性測試 安裝測試 介面測試 配置測試 文件測試 相容性測試 安全性測試 恢復測...