0.概念

軟體：實現使用者需求的原始碼及與之匹配的文件和支撐其執行的配置資料。是一種邏輯存在的資產。（資料結構+演算法+文件+服務）。
軟體測試：是為了儘快儘早發現在軟體產品中所存在的各種軟體缺陷而展開的貫穿整個軟體開發生命週期、對軟體產品（包括階段性產品）進行驗證和確認的活動過程。
除錯：通俗的理解，對軟體程式程式碼做出的一系列檢查、改正的過程，以保證軟體能夠正常執行為目的。（早期軟體程式碼少，邏輯簡單，程式設計師完全可以應付）
軟體測試目的：
程式測試是為了發現錯誤而執行程式的過程；
一個好的測試用例是發現迄今為止尚未發現的錯誤的測試用例；
一個成功的測試執行是發現了至今為止尚未發現的錯誤的測試執行。
注意：軟體測試的目的不僅僅是為了發現錯誤，還有易用性等測試，這些統稱為缺陷。（發現其與需求偏離的需求實現）
修改缺陷的成本隨專案發展而變高；尋找缺陷的時間隨專案發展而變難。

1.人們對軟體測試目的的認識過程

證明（表明軟體能夠工作）→檢測（發現錯誤）→預防（管理質量）。
注意：早期的結構化同行評審被用於幫助預防編碼前的缺陷。

2.測試執行

單元測試執行（UT執行）：一個測試用例的測試執行；
整合測試執行（IT執行）：一個測試用例集的測試執行；
系統測試執行（ST執行）：不同測試階段的測試執行。

3.測試和除錯的區別

4.迴歸測試的目的

（迴歸測試應用於：增量開發；版本控制；軟體維護）

驗證缺陷是否修復或增加的部分是否正確；

檢測對程式碼的修改是否引入了新的錯誤。

5.軟體測試的主要工作

檢視程式碼，評審開發文件；
進行測試設計，寫作測試文件（測試計劃、測試方案、測試用例等）；
執行測試，發現軟體缺陷，提交缺陷報告，並確認缺陷最終得到了修復；
通過測試度量軟體的質量；
……

6.軟體危機的出現主要表現在

1.由於缺乏大型軟體開發經驗和軟體開發資料積累，開發工作計劃很難制定；
2.開發早期需求分析不夠明確，造成開發後期矛盾集中暴露；
3.不遵循開發規範，開發文件不完善，軟體難以維護；
4.缺乏嚴密有效的軟體質量檢測手段，交付給使用者的軟體質量差。

7.軟體危機的後果

1.軟體質量不高，很難穩定；
2.軟體專案延期，進度無法控制；
3.成本增加，無法控制預算。

8.軟體危機的根源

1.根據摩爾定律，硬體發展很快，相應對軟體系統的期望越來越高；
2.軟體系統複雜性提高，需多人合作；
3.軟體開發是人的智力活動，無法用已有的產業工程方法來組織管理。

9.為什麼會出現軟體缺陷

導致軟體缺陷最大的原因是需求說明書；
軟體缺陷的第二大來源是設計方案；
編寫程式碼；
其他。

10.常見引入缺陷的原因

1.開發過程缺乏有效的溝通，或者沒有進行溝通；（表達不正確、以致理解不正確、以致設計不正確）
2.軟體複雜度越來越高；
3.程式設計中產生錯誤；（語法錯誤、語義錯誤等）
4.需求不斷變更；（專案失敗的最大殺手，會引起重新設計，工程重新安排等）
5.專案進度的壓力；（為了搶佔市場，必須比競爭對手早一步把產品提供出來，於是不合理的進度安排就產生了，不斷的加班加點最終導致大量錯誤的產生。另一個方面，由於軟體專案的時間安排是最難的，通常是需要很多猜測的工作，因此當最後期限來臨的時候，錯誤也就伴隨發生了）
6.不重視開發文件；（當團隊中一員離開，對於新進來的員工說，去讀懂和維護一個沒有文件的程式碼是很難的）
7.軟體開發工具本身隱藏的問題；（儘量選擇比較成熟的產品）
8.人員自大。
……

11.缺陷的型別

遺漏：規定的或預期的需求未體現在產品中（可能未將規格說明全面實現，也可能需求分析階段就遺漏了需求）；
錯誤：未將規格說明正確實現（可能設計錯誤、也可能編碼錯誤）；
額外的實現：規格說明並未規定的需求被納入產品，得到實現。

12.缺陷具體表現

軟體未達到產品說明書標明的功能。
軟體出現了產品說明書指明不會出現的錯誤。
軟體功能超出產品說明書指明範圍。
軟體未達到產品說明書雖未指出但應達到的目標。
軟體測試員認為軟體難以理解、不易使用、執行速度緩慢，或者終端使用者認為不好。

13.常見軟體生產流程

（軟體的生命週期，Software Lifecycle Model，9個階段）：市場調研→→可行性研究→→產品立項→→需求調研→→設計開發→→系統測試→→產品釋出→→產品維護→→產品升級。
問題定義→可行性研究→需求分析（功能建模、資料建模）→概要設計→詳細設計→編碼→測試→維護
1.計劃（Planning）：（1）確定軟體開發總目標；（2）給出軟體的功能、效能、可靠性以及介面等方面的設想；（3）研究完成該專案的可行性，探討問題解決方案；（4）對可供開發使用的資源、成本、可取得的效益和開發進度做出估計；（5）制定完成開發任務的實施計劃。
2.需求分析（Requirement Analysis）：對開發的軟體進行詳細的定義，由需求分析人員和使用者共同討論決定，哪些需求是可以滿足的，並且給予確切的描述，寫出軟體需求說明書SRS。（針對產品的軟體研發，需求來源於市場調研，特點是自己想研發什麼，自己就來研發；針對專案的軟體研發，需求來源於客戶要求，特點是別人想研發什麼，我們幫著研發。專案型軟體：特定客戶針對某個特定軟體產品指定供應商，軟體智慧財產權歸客戶所有；產品型軟體：特定軟體針對某個特定群體開發的通用型軟體產品，軟體智慧財產權歸軟體開發商所有。）
3.設計（Design，概要設計與詳細設計）：是軟體工程的技術核心，這個階段需要完成設計說明書。
概要設計（HLD）：在設計階段把各項需求轉換成相應的體系結構，每一部分是功能明確的模組；
詳細設計（LLD）：對每個模組要完成的工作進行具體的描述。
4.程式編碼（Coding）：把軟體設計轉換成計算機可以接受的程式，即寫成以某個程式設計語言表示的源程式清單。
5.測試（Testing）：檢驗軟體是否符合客戶需求，達到質量要求，一般由獨立的小組執行，測試工作分為：單元測試（對每一個函式進行測試）、整合測試（對函式與函式的整合，即函式間、模組與模組的整合，即模組間、子系統與子系統的整合，即系統間，進行測試）、系統測試（對每一個功能需求、效能需求等進行測試）。
6.執行和維護（Run and Maintenance）：將軟體交付使用者投入正式使用，以後便進入維護階段，可能有多種原因需要對它進行修改，如軟體錯誤、系統軟體升級、增強軟體功能、提高效能等。

14.軟體研發三要素

人員、過程、工具；
只有適合的人員藉助適合的工具經過適合的過程才能研發出高質量的軟體；工具是為人員和過程服務，起輔助作用，起關鍵作用的是人員和過程。

15.常見專案組框架（軟體專案組人員組成）

1.專案經理；
2.開發組：開發經理、分析人員、設計人員、開發人員；
3.測試組：測試經理、測試人員；
4.配置管理組：配置經理、配置管理員（CMO, configuration management officer）；
5.SQA（質量保證人員）。

16.軟體研發流程型別

1、瀑布模型（Waterfall Model）：線性，序列，無風險控制能力，適合需求變化較小的情況。瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用瀑布模型結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
計劃階段：專案計劃書，Project Plan
需求階段：需求規格說明書，SRS: Software Requirement Specification
設計階段：概要設計：High Level Design，詳細設計：Low Level Design
開發階段：程式碼，用例
測試階段：測試實現和執行
維護階段：產品維護
優點：簡單高效（一般產品要求立即上線，應第一時間保證執行，其它的有時間再做）
缺點：測試介入較晚，人員閒置嚴重，後續工作跟不上；在專案各個階段之間極少有反饋；只有在專案生命週期的後期才能看到結果；通過過多的強制完成日期和里程碑來跟蹤各個專案階段；瀑布模型的突出缺點是不適應使用者需求的變化。
適用範圍：專案開發完成後才招測試人員，那麼可能是瀑布模型，不適合需求頻繁變更的專案。不適合於大的專案，適用於小規模傳統專案業務研發。適合範圍：專案小，需求明確。
按照瀑布模型的階段劃分，軟體測試可以分為單元測試，整合測試，系統測試。

風險驅動的模型，迭代模型（Iteration），可在迭代模型中應用瀑布模型。每次迭代產生一個可執行的版本,同時增加更多的功能。每次迭代必須經過質量和整合測試。
增量：軟體開發過程中，先開發主要功能模組，再開發次要功能模組，逐步完善，最終開發出符合需求的軟體產品。
迭代：指增量開發過程中，各模組的開發是反覆進行的，並不是完成了某個模組後就終止該模組的開發轉而開發下一個模組，可能還要對之前開發的模組不斷完善，增加新功能。
2、螺旋模型：基於風險管理的模型，高風險的優先考慮，對風險管理人員的要求較高。綜合了基本的瀑布式模型和演化/漸增原型方法。與瀑布模型不同點：螺旋模型有替代方案，是多個瀑布模型的並行集合。充分考慮了風險問題，故設計了替代方案。
優點：充分考慮風險，抗風險能力強；
缺點：成本太高，需要專業的風險分析專家參與；
適用範圍：與生命財產相關的系統。
3、RUP（Rational Unified Process）：統一軟體開發過程，是一個面向物件且基於網路的程式開發方法論。所有的工作流在各個階段都有體現。面向物件的，通用的。特點：基於風險；用例集驅動；以架構為中心；迭代和增量。所以工作流在各個階段都有體現。
優點：針對大型複雜的系統，進行逐步完善，降低了實施複雜度；使用者可在早期提出變更並進行修復，從而有效控制變更風險及代價（往往都是區域性變更）；可在早期增強使用者的信心（看到了半成品）。
缺點：要有專業的架構師（架構師的職責），當功能與功能之間聯絡太過緊密的話，不太使用rup模型，比如登入與註冊的聯絡；已經確定了的功能將不允許變更，但由於因為設計引起的內在聯絡引起的變更是無法控制的。
適用範圍：大型複雜的專案研發，耦合度較低的系統。
4、IPD（integrated product development）：整合產品開發，IPD的思想來源於美國PRTM公司出版的《產品及生命週期優化法》（簡稱PACE——Product And Cycle-time Excellence）一書，該書中詳細描述了這種新的產品開發模式所包含的各個方面。產品結構重整（資源重整）；公共模組共用。
從整個產品角度出發，不僅僅針對研發。
優點：將軟硬體研發及生產、銷售等各個部門有效整合，集中在一個平臺下統一管理，提高了決策的準確性及時效性；利於各部門關鍵資料的共享；
缺點：管理成本高；部門之間的協調關係較複雜；
適用範圍：大型軟硬體整合廠商。
5、敏捷開發：Scrum是一種迭代式增量軟體開發過程，通常用於敏捷軟體開發。
計劃開發一定功能，並把一個個功能挨個快速地實現，省略文件寫作（包括概要設計等），在這個基礎上有可能增加功能。

17.軟體研發中幾個重要的過程

需求管理、配置管理、缺陷管理、同行評審。

18.其它

1.測試不是點點滑鼠，敲敲鍵盤，而是要結合業務邏輯和使用者需求，並使用各種技術。
2.一個好的軟體測試人員，一定是懂開發知識的；一個好的軟體開發人員，一定是懂測試的。
軟體測試主要是為了發現以下幾類錯誤：
①是否有不正確或遺漏了的功能？
②在介面上，輸入能否正確地接受？能否輸出正確的結果？
③是否有資料結構錯誤或外部資訊（例如資料檔案）訪問錯誤？
④效能上是否能夠滿足要求？
⑤是否有初始化或終止性錯誤？

部分整理自網路，如有侵權，請聯絡刪除。