1.概念
軟件：實現用戶需求的源代碼及與之匹配的文檔和支撐其運行的配置數據。是一種邏輯存在的資產。（數據結構+算法+文檔+服務）。
軟件測試：以用戶需求為基準，運用科學的測試方法對被測對象進行檢測，發現其與需求偏離的需求實現。
軟件測試：是為了盡快盡早發現在軟件產品中所存在的各種軟件缺陷而展開的貫穿整個軟件開發生命周期、對軟件產品（包括階段性產品）進行驗證和確認的活動過程。
調試：通俗的理解，對軟件程序代碼做出的一系列檢查、改正的過程，以保證軟件能夠正常運行為目的。（早期軟件代碼少，邏輯簡單，程序員完全可以應付）
軟件測試目的：
程序測試是為了發現錯誤而執行程序的過程；
一個好的測試用例是發現迄今為止尚未發現的錯誤的測試用例；
一個成功的測試執行是發現了至今為止尚未發現的錯誤的測試執行。
注意：軟件測試的目的不僅僅是為了發現錯誤，還有易用性等測試，這些統稱為缺陷。（發現其與需求偏離的需求實現）
修改缺陷的成本隨項目發展而變高；尋找缺陷的時間隨項目發展而變難。
2.人們對軟件測試目的的認識過程
證明（表明軟件能夠工作）→檢測（發現錯誤）→預防（管理質量）。
注意：早期的結構化同行評審被用于幫助預防編碼前的缺陷。
3.測試執行
單元測試執行（UT執行）：一個測試用例的測試執行；
集成測試執行（IT執行）：一個測試用例集的測試執行；
系統測試執行（ST執行）：不同測試階段的測試執行。
4.測試和調試的區別
5.回歸測試的目的
（回歸測試應用于：增量開發；版本控制；軟件維護）
驗證缺陷是否修復或增加的部分是否正確；
檢測對代碼的修改是否引入了新的錯誤。
6.軟件測試的主要工作
檢視代碼，評審開發文檔；
進行測試設計，寫作測試文檔（測試計劃、測試方案、測試用例等）；
執行測試，發現軟件缺陷，提交缺陷報告，并確認缺陷最終得到了修復；
通過測試度量軟件的質量；
……
7.軟件危機的出現主要表現在
1.由于缺乏大型軟件開發經驗和軟件開發數據積累，開發工作計劃很難制定；
2.開發早期需求分析不夠明確，造成開發后期矛盾集中暴露；
3.不遵循開發規范，開發文檔不完善，軟件難以維護；
4.缺乏嚴密有效的軟件質量檢測手段，交付給用戶的軟件質量差。
8.軟件危機的后果
1.軟件質量不高，很難穩定；
2.軟件項目延期，進度無法控制；
3.成本增加，無法控制預算。
9.軟件危機的根源
1.根據摩爾定律，硬件發展很快，相應對軟件系統的期望越來越高；
2.軟件系統復雜性提高，需多人合作；
3.軟件開發是人的智力活動，無法用已有的產業工程方法來組織管理。
10.為什么會出現軟件缺陷
導致軟件缺陷最大的原因是需求說明書；
軟件缺陷的第二大來源是設計方案；
編寫代碼；
其他。
11.常見引入缺陷的原因
1.開發過程缺乏有效的溝通，或者沒有進行溝通；（表達不正確、以致理解不正確、以致設計不正確）
2.軟件復雜度越來越高；
3.編程中產生錯誤；（語法錯誤、語義錯誤等）
4.需求不斷變更；（項目失敗的最大殺手，會引起重新設計，工程重新安排等）
5.項目進度的壓力；（為了搶占市場，必須比競爭對手早一步把產品提供出來，于是不合理的進度安排就產生了，不斷的加班加點最終導致大量錯誤的產生。另一個方面，由于軟件項目的時間安排是最難的，通常是需要很多猜測的工作，因此當最后期限來臨的時候，錯誤也就伴隨發生了）
6.不重視開發文檔；（當團隊中一員離開，對于新進來的員工說，去讀懂和維護一個沒有文檔的代碼是很難的）
7.軟件開發工具本身隱藏的問題；（盡量選擇比較成熟的產品）
8.人員自大。
……
12.缺陷的類型
遺漏：規定的或預期的需求未體現在產品中（可能未將規格說明全面實現，也可能需求分析階段就遺漏了需求）；
錯誤：未將規格說明正確實現（可能設計錯誤、也可能編碼錯誤）；
額外的實現：規格說明并未規定的需求被納入產品，得到實現。
13.缺陷具體表現
軟件未達到產品說明書標明的功能。
軟件出現了產品說明書指明不會出現的錯誤。
軟件功能超出產品說明書指明范圍。
軟件未達到產品說明書雖未指出但應達到的目標。
軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。
14.常見軟件生產流程
（軟件的生命周期，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）：將軟件交付用戶投入正式使用，以后便進入維護階段，可能有多種原因需要對它進行修改，如軟件錯誤、系統軟件升級、增強軟件功能、提高性能等。
15.軟件研發三要素
人員、過程、工具；
只有適合的人員借助適合的工具經過適合的過程才能研發出高質量的軟件；工具是為人員和過程服務，起輔助作用，起關鍵作用的是人員和過程。
16.常見項目組框架（軟件項目組人員組成）
1.項目經理；
2.開發組：開發經理、分析人員、設計人員、開發人員；
3.測試組：測試經理、測試人員；
4.配置管理組：配置經理、配置管理員（CMO, configuration management officer）；
5.SQA（質量保證人員）。
17.軟件研發流程類型
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是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。
計劃開發一定功能，并把一個個功能挨個快速地實現，省略文檔寫作（包括概要設計等），在這個基礎上有可能增加功能。
18.軟件研發中幾個重要的過程
需求管理、配置管理、缺陷管理、同行評審。
19.其它
1.測試不是點點鼠標，敲敲鍵盤，而是要結合業務邏輯和用戶需求，并使用各種技術。
2.一個好的軟件測試人員，一定是懂開發知識的；一個好的軟件開發人員，一定是懂測試的。
軟件測試主要是為了發現以下幾類錯誤：
①是否有不正確或遺漏了的功能？
②在接口上，輸入能否正確地接受？能否輸出正確的結果？
③是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
④性能上是否能夠滿足要求？
⑤是否有初始化或終止性錯誤？
============================== 重要提醒 =============================
部分整理自網絡，如有侵權，請聯系刪除。
