測試基礎【第一篇】一篇文章帶你完全理解測試基礎

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.軟件研發流程類型

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

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

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

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

18.其它

1.測試不是點點鼠標，敲敲鍵盤，而是要結合業務邏輯和用戶需求，並使用各類技術。
2.一個好的軟件測試人員，必定是懂開發知識的；一個好的軟件開發人員，必定是懂測試的。
軟件測試主要是爲了發現如下幾類錯誤：
①是否有不正確或遺漏了的功能？
②在接口上，輸入可否正確地接受？可否輸出正確的結果？
③是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
④性能上是否可以知足要求？
⑤是否有初始化或終止性錯誤？

 

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