1.1.軟體缺陷產生的原因
(1)需求解釋有錯誤
(2)使用者需求定義錯誤
(3)需求記錄錯誤
(4)設計說明有誤
(5)編碼說明有誤
(6)程式**有誤
(7)資料輸入有誤
(8)測試錯誤
(9)問題修改不正確
(10)不正確的結果是由於其他的缺陷而產生
1.2軟體測試和缺陷修復的代價
缺陷發現的越早,則修復這個缺陷的代價就越小，在需求、設計、編碼、測試、發布等不同的階段，發現缺陷後修復的代價都會比在前乙個階段修復的代價提高10倍
軟體測試定義
狹義：測試的定義：「程式測試是為了發現錯誤而執行程式的過程」。這個定義，被業界所認可，經常被引用
廣義：為了更早地發現問題，所以將測試延伸到需求評審、設計審查活動中去，也就是將「軟體質量保證」的部分活動歸為測試活動。
如何快速融入新團隊
查詢編寫測試用例
虛心學習
查閱需求文件
檢視使用者使用手冊
查閱bug
1.3 測試人員的基本素質
1、參與需求討論，制訂測試計畫，確保測試能順利執行並完成
2、負責專案的功能性測試、使用者體驗測試、相容性測試以及效能測試
3、負責測試用例的編寫；編寫測試報告和對測試結果分析
4、與開發人員、產品經理溝通和協作，推動整個專案的順利進行
5、負責軟體開發團隊專案進度管理工作
6.熟悉linux常用命令，熟悉常用資料庫，熟練使用基本的sql語句
7.熟練使用loadrunner，jmeter等至少一種效能測試工具
測試流程
立項------需求文件（需求人員）--------需求評審（開發，測試，專案經理，需求）-------詳細設計(開發人員)-------測試用例（測試人員）-----測試用例評審（開發，測試，專案經理，需求）-----
編碼------部署（測試）---------冒煙測試---------bug（禪道）------測試報告—上線（運維）
軟體測試分類
3.1. 黑盒測試和白盒測試
黑盒測試(black box -test)指的是把被測試的軟體看做乙個黑盒子，我們不去關心盒子裡邊的結構是什麼樣子，只關心軟體的輸入資料和輸出結果
白盒測試(white box testing),指的是把盒子蓋開啟，去研究裡邊源**和程式結構
3.2. 靜態測試和動態測試
靜態測試，是指不實際執行被測試軟體，而只是靜態的檢查程式**、介面或者文件中可能存在的錯誤的過程
動態測試:是指實際執行被測程式，輸入相應的測試資料，檢查實際輸出結果和預期結果是否相符的過程
3.3. 功能測試和效能測試
功能測試是黑盒測試的一部分，它檢查實際軟體的功能是否符合使用者的需求。功能測試可以細分邏輯功能測試，介面測試，易用性測試，安裝測試和相容性測試
效能測試：時間效能，一般效能測試，穩定性測試，負載測試，壓力測試
3.4. 回歸測試、冒煙測試、隨機測試
回歸測試是指對軟體的新版本進行測試時，重複執行上乙個版本測試時的用例，比如在1.0版本中，有乙個bug，到了2.0版本中,再重新測試1.0中這個bug
冒煙測試指對乙個軟體進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性
隨機測試是指測試中所有的輸入資料都是隨機生成的，其目的是模擬使用者的真實操作，並發現一些邊緣性的錯誤
3.5. 單元測試、整合測試、系統測試和驗收測試
單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證(白盒測試)
整合測試是單元測試的下乙個階段，是指將通過測試單元模組組裝成系統或者子系統，再進行測試，重點測試不同模組的介面部分（白盒測試，黑盒測試）
系統測試:指的是將整個軟體系統看做乙個1個整體進行測試，包括對功能、效能，以及軟體所執行的軟硬體環境進行測試。（黑盒測試）
驗收測試：以使用者為主的測試，軟體開發人員和質量保證人員參加（黑盒測試）
水杯的測試用例
功能（用途），效能（承受），介面（觀察），安全（存在隱患），易用（使用者使用）
功能:裝水，裝其他液體
效能:裝多少
介面：顏色，形狀
安全:材質
易用：使用者使用
軟體測試的原則
1.應當把「盡早和不斷地測試」作為開發者的座右銘。
2.設計測試用例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要製造極端狀態和意外狀態，比如網路異常中斷、電源斷電等情況
3.一定要注意測試中的錯誤集中發生現象，這和程式設計師的程式設計水平和習慣有很大的關係
4.對測試錯誤結果一定要有乙個確認的過程。一般有a測試出來的錯誤，一定要有乙個b來確認，嚴重的錯誤可以召開評審會進行討論和分析。
5.制定嚴格的測試計畫，並把測試時間安排得盡量寬鬆，不要希望在極短的時間內完成乙個高水平的測試。
6.回歸測試的關聯性一定要引起充分的注意，修改乙個錯誤而引起更多錯誤出現的現象並不少見
7.妥善儲存一切測試過程文件，意義是不言而喻的，測試的重現性往往要靠測試文件。
軟體的開發模式
線性模型：最常見的「瀑布模型」，基礎框架，但缺點在於「整合之日就是**之日」。（立項分析-需求分析-設計-編碼-測試-維護）很多企業使用後使用迭代進行修改。
漸進式模型：最常見的「螺旋模型」，（需求分析-風險分析-設計、編碼-測試、評審），迭代開發和增量開發模式。
軟體生命週期模型
瀑布模型：瀑布型簡單地說就是按照需求、設計、編碼、測試、軟體維護這個基本的順序來研發軟體，前面乙個步驟不完成，後面的步驟不能開始，否則問題會滾到下個階段，帶來更多的問題
優點：為專案提供了按階段劃分的檢查點
當前一階段完成後，只需要去關注後續階段。
缺點：1）各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。
2）由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
3）通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
4）瀑布模型的突出缺點是不適應使用者需求的變化
螺旋模型：統一了瀑布模型與原型模型，與增量模型相似，更強調風險分析
1.軟體分多個版本開發，每個版本就是一次螺旋。
2.每個版本按照這樣的順序進行：
1）確定軟體目標，選取定實施方案，弄清專案開發的限制條件；（圖中左上象限）
2）分析所選取方案，考慮如何識別和消除風險；（圖中右上象限）
3）實施軟體開發；
4）評價開發工作，提出修正建議，調整計畫。（圖中右下象限、左下象限）
3.需求不是一次獲取和實現的，通過多個螺旋來完善。
4.計畫也不是一次成型的，每次螺旋都需要調整。
優點：1）設計上很靈活，可以在專案的各個階段進行變更；
2）以小的分段來構建大型系統，使成本計算變得簡單容易；(國企專案)
3）客戶始終參與每個階段的開發，保證了專案不偏離正確方向以及專案的可控性；
4）隨著專案推進，客戶始終掌握專案的最新資訊 , 從而能夠和管理層有效地互動；
5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。
缺點：螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，並做出相關反應是不容易的。
因此，這種模型往往適應於內部的大規模軟體開發。該模型建設週期長，而軟體技術發展比較快，所以經常出現軟體開發完畢後，和當前的技術水平有了較大的差距，無法滿足當前使用者需求。
軟體測試基礎 軟體測試概要
1.歷史上由軟體bug引發的重大事故 因此，軟體質量是非常重要的，而軟體測試作為軟體質量保證重要的組成部分，在軟體研發中有著重要的地位，是不可或缺的一環。2.什麼是測試？ieee定義 iso iec ieee 29119 使用人工或自動的手段來執行或測量軟體系統的過程，以檢驗軟體系統是否滿足規定的要...
軟體測試基礎
功能測試 主要是黑盒測試，也稱行為測試 只考慮各個功能，不考慮整個軟體的內部結構及 一般從軟體產品的介面 架構出發 按照需求編寫出來的測試用例，輸入資料在預期結果和實際結果之間進行評測，進而提出使產品更加符合使用者使用的要求。包括邊界值測試 找到邊界，然後在其邊界及其邊界附近選點 健壯性測試 最壞情...
軟體測試基礎
1 缺陷編號 defect id 所提交的bug的順序 2 缺陷標題 summary 簡明扼要地說明一下該缺陷 3 缺陷的發現者 detected by 4 發現缺陷的日期 detected on date 5 缺陷所屬的模組 subject 在測試哪個模組的時候發現的bug 6 發現缺陷的版本 d...