軟件測試2
1.軟件的開發管理模型：
軟件開發的流程通過採用不同的模型，導致工作的流程不同。最早是“邊做邊改”模式，但是很不方便後期的修改，效率較低。
開發模型的分類：瀑布模型、螺旋模型、增量模型、迭代模型、敏捷模型
1.1 瀑布模型（Waterfall Model）
按照線性方式進行，當前活動接受上一項活動的工作結果。工作結果需要驗證。從上到下不可逆轉，所以效率較低，並且如果發現錯誤要全部打翻重新弄
計劃-→需求分析→設計→編碼→測試→運行維護
作用：瀑布模型是所有其他模型的基礎框架，在軟件工程中佔有重要地位。
瀑布模型是線性順序進行的軟件開發模式，因爲瀑布模型的每一個階段都只執行一次。
優點：
-
強調開發的階段性；
-
強調早起計劃及需求調查；
-
強調產品測試；
缺點：
-
依賴於早期進行的唯一一次需求調查，不能適應需求的變化；
-
瀑布模型是單一流程，開發中的經驗教訓不能反饋應用於本產品的過程；
-
早期的錯誤可能要等到開發後期才能顯露。
-
可以運行的產品很遲才能被看到，會給項目帶來很大的風險，尤其是集成的風險；
在瀑布模型中，測試階段處於軟件實現之後，也就是說代碼完成後有足夠的時間預留給測試活動，否則將導致測試不充分，從而把缺陷直接遺留給客戶。
1.2 原型模型：（更強調客戶的需求）
客戶與開發公司緊密聯繫，開發週期長。開發會受到需求變更的影響.
特點:
- 實現客戶與系統的交互。
2.進一步細化待開發軟件需求。
3.開發人員可以確定客戶的真正需求是什麼
1.3 螺旋模型：（在瀑布和原型的基礎上）
制定計劃→風險分析→實施工程(需求確認、軟件需求、軟件產品設計、設計確認與認證、詳細設計、開發、測試) →客戶評估
特點:
1.螺旋模型是將瀑布模型與快速原型模型結合起來
2.強調了其他模型所忽視的風險分析
3.每一次螺旋包括4個步驟:制定計劃、風險分析、實施工程、客戶評估（相當於一個遞進的過程，每一次的螺旋都包含這四個步驟）
1.4 敏捷模型
敏捷開發是一種以人爲核心、迭代、循序漸進的開發方法
特點:
短週期開發（把整個功能拆散，一點點的開發）增量開發（一點點的往上加着開發）
3.由程序員和測試人員編寫的自動化測試來監控開發進度
4.通過口頭溝通、測試和源代碼來交流系統的結構和意圖
5.編寫代碼之前先寫測試代碼，也叫做測試先行（可能項目還沒完善功能測試，只要接口做好就能進行測試）
敏捷的價值觀：
-
強調人與人之間的溝通；
-
輕文檔（對文檔的要求較低）；
-
要求客戶參與；
-
擁抱變化（變化中與計劃）；
-
白板：寫清楚每一個人的任務，一目瞭然
1.5 V字形模型
V模型是我們熟知的瀑布模型的一種改進，瀑布模型將軟件生命週期劃分爲計劃、分析、設計、編碼、測試和維護六個階段， 對於瀑布模型由於早期的錯誤可能要等到開發後期的測試階段才能發現，所以可能帶來嚴重的後果。V模型就是在這點改進了瀑布模型，在軟件開發的生存期,開發活動和測試活動幾乎同時開始,這兩個並行的動態的過程就會極大的減少bug和error出現的機率。
左邊是開發組，右邊是測試組，有了這麼一個一一對應的關係，比如單元測試就依據於編碼，集成測試依據於詳細設計， 相對於瀑布流已經有了進步，因爲讓測試和開發有了對照的關係。但是也由於需求上的錯誤可能到最後才能發現，出現了滯後性，所以仍然不好。
在開發階段一側,先從定義業務需求開始,然後把需求轉換爲軟件規格,再轉換到概要設計和詳細設計中,最後進行編碼成爲程序代碼。在測試執行階段一側,先進行單元測試,然後是集成測試、系統測試,最後是驗收測試,這些測試形成了軟件測試的不同層次(級別),並與開發過程的相應階段相對應。
1.6 W模型：又稱作雙V模型
一些高性能高風險的系統、互聯網軟件，或一個系統難以被具體模塊化的時候，就比較難做成V模式所需的各種構件， 需要更強調迭代的開發模型或者敏捷開發模型。
W模型從V模型演化過來，實際上開發是V,測試是並行的V;相對於V模型，W模型增加了軟件各開發階段中應同步進行的驗證和確認活動，W明確表示出了測試與開發的並行關係。測試與開發是同步進行的，有利於儘早地全面的發現問題。
圖中,W-模型由兩個“V”重疊而成。其中一個“V”表示開發過程,包括需求分析、規格書生成、軟件設計、代碼編程、軟件構建、系統構建以及安裝等階段。另一個“V”表示測試過程,包括需求測試、規格測試、設計測試、單元測試、集成測試、系統測試以及驗收測試等活動。軟件測試的各項測試活動與開發過程的各個階段相對應。
開發和測試一塊進行， ，測試也在用戶需求，就不用等開發做完再去做測試，所以測試在測試設計的時候不光可以參考開發的概要設計，還可以參考之前的需求分析等等。是目前用的的最多的模型
軟件開發過程各階段都可能產生錯誤。軟件錯誤具有傳遞性,即需求分析產生的錯誤如果沒有發現,會依次傳遞到設計和編碼。軟件錯誤的發現和解決具有放大性。據估計,在分析設計階段產生的錯誤,如果在編碼結束後的測試過程才被發現,其代價約爲在分析設計階段發現和解決錯誤的代價的10倍。如果該錯誤在產品交付使用後才發現和解決,則其代價將超過100倍。因此, 測試工作越早進行,發現和解決錯誤的代價越小,風險越小。
1.7 其他模型-H模型
是一種思想，真正的測試級別之間不存在嚴格的次序關係，各階段間可以反覆觸發、迭代、增量爲了解決V模型和W模型存在的問題，有專家提出了H模型。它將測試活動完全獨立出來,形成一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來
只要條件成熟，就可以進行測試
1.8 其他模型-X模型
左邊是對單獨的代碼進行的測試，然後進行 頻繁的集成，交接，最終集成成一個可執行程序，然後再進行測試，多層次合併。X模型是唯一一個定位了探索性測試的模型，分塊化探索性的測試。
對測試人員要求較高的一種模型。
2.軟件開發文檔
2.1 開發模型的變遷
- 最早期:邊做邊改
- 穩定期:瀑布式
- 發展期:敏捷
- 創新期: DEVOPS(更強集成，更多自動化，存在
211指標：對於小型需求上線週期保持在兩週左右上線，開發週期儘量壓縮在一週以內，發佈流程在30分鐘內發佈完成，回編測試加發布流程在一個小時內)
211指標：
針對不同的小型需求，上線週期定在2周左右
開發週期壓縮在1周
迴歸測試+項目的上線發佈保持在1小時之內
3.項目的一生
1.編程階段:
單元(白盒) -測試參與
2.編程完成：
開發聯調(集成測試) -
開發爲主（但是測試對於日誌，接口調通的返回值，數據調度都需要進行校驗）
3.提測：
冒煙測試(自動化爲主，手工爲輔) -
測試執行(8-2原則，80%的用戶集中使用20%的功能，這部分稱爲關鍵功能，冒煙測試主要測這部分功能)
4.測試階段：
系統測試(黑盒功能測試爲主，自動化/接口測試爲輔，根據項目進行性能、安全測試)
5.驗收階段1：
驗收測試-測試配合用戶或需求
4.軟件測試方法
經典定義：
軟件測試(Software Testing),在規定的條件下對程序進行操作,以發現程序錯誤，衡量軟件質量，並對其 是否能滿足設計要求進行評估的過程
標準定義：
軟件測試是使用人工或自動的手段來運行或測定某個軟件系統的過程，其期的在於檢驗它是否滿足規定的需求或 弄清預期結果與實際結果之間的差別
軟測的目的：
發現問題，檢查系統是否滿足需求