軟件測試基本理論-IBM模式

軟件測試基本理論（1）

IBM生產模式

1   參考書目

《IBM-從菜鳥到測試架構師-一個測試工程師的成長日記》

• 出版社：電子工業出版社
• 印次：2013年6月
• 做者：IBM主要工程師

2   重要提醒

Warning

IBM的業務性質是作大型企業的IT解決方案，仍然屬於比較中規中矩的傳統企業。因此對傳統的軟件企業有比較大的借鑑意義，可是對於互聯網等新興企業的從業人員，仍是採起保留式的態度，取其精華便可。

3   測試產生的時代背景

1968年NATO會議提出了「軟件危機」：

• 脆弱
• 不可靠
• 缺少安全性
• 性能降低
• 出錯
• 難以升級
• 73%的軟件項目被延遲/超資/取消或失敗

4   軟件測試目的-IBM

• 確保軟件質量
• 減小質量問題給企業及用戶帶來隱患

5   測試的現狀

測試的理論及實踐已經逐漸完善，可是測試的方法和體系卻缺少完整性的討論。

6   測試分類

• 測試分類

  1. 安裝測試
  2. 構建測試
  3. 白盒測試
  4. 黑盒測試
  5. 性能測試
  6. 遷移測試

• 目的

  肯定軟件從安裝到使用及至後期維護的穩定性和健壯性。

7   新手入門

• 測試是一個嚴謹、全面而有條理的過程

• 測試須要有測重點2/8原則）

  除了小型項目，進行徹底（各類輸入和前提條件的組合）的測試是不可行的。須要動用風險分析和不一樣系統功能的測試優先級，來肯定測試的關注點，從而替代窮盡測試。

8   單元測試

定義：開發人員針對程序模塊（軟件設計的最小單位）來進行正確性檢驗的測試。

• 單元測試是和開發最接近的一種測試

• 由開發人員編寫。開發人員編寫單元測試用例並執行，驗證單元模塊是否得出預期的結果

• 單元測試是粒度最小的軟件測試

  • 過程化編程：單個程序，函數，過程
  • 對象化編程：方法，基類，抽象類，派生類

• 子系統只有經過單元測試以後才集成到大系統中

9   白盒測試

定義：指測試人員能夠直接訪問內部數據結果、算法及其代碼實現的測試。

常見的方法：

• 接口測試
• 代碼覆蓋率測試
• 缺陷注入方法

10   「單元測試」和「白盒測試」區別

1. 測試目不一樣

   • 「白」是測試程序的總體邏輯
   • 「單」是測試程序中一個獨立的模塊

2. 執行人員不一樣

   • 白盒通常是由專門的白盒測試人員完成
   • 單元測試通常由程序員本身完成

11   功能測試（黑盒測試）

定義：經過黑盒模式發現代碼集成後存在的功能問題的測試。

• 關注的重點是系統的功能
• 能夠自動或者手動執行測試用例

和 單元測試 的區別：粒度不一樣。

• 單元測試關注的是最小代碼片段
• 功能測試關注的是一個完整的業務功能

12   性能測試

• 關注重點

  驗證軟件的非功能性需求的測試

• 應對複雜苛刻的用戶場景

  • 吞吐率
  • 穩定性
  • 可靠性

• 主要手段

  經過自動化的方法模擬真實用戶併發訪問的場景

• 最終目的

  • 驗證系統的性能指標或發現其性能瓶頸
  • 從根本上保證用戶體驗和長遠利益

13   手工測試特色

• 優勢

  • 方便靈活
  • 首次投入成本低
  • 人員素質要求低

• 缺點

  • 效率低
  • 重複開銷大
  • 難以模擬複雜的使用場景，如：併發或連續事務

14   自動化測試特色

• 優勢

  • 效率高，提供很強的生產力
  • 重複活動開銷小
  • 基本能夠模擬任何複雜的使用場景，除了圖靈測試
  • 弱化了軟件測試人員個體差別的影響

• 缺點

  • 首次投入成本高
  • 變動成本大
  • 人員素質要求高

15   自動化vs手動測試（1）

• 造成良好互補，2/8原則

• 因地制宜。測試投資回報比。ROI算法

  • 穩定，持續迭代，增量式的開發，流程固化（目前互聯網主流模式），適合以自動化爲主
  • 需求不穩定，一次性項目任務（傳統軟件工業主流模式），適合以手工爲主

• 創造性的工做交付人來作，重複性工做交付機器來作

• 大項目適合自動化測試，小項目適合手工測試

16   自動化vs手動測試（2）

估計自動化腳本開發的必要性：

• 自動化測試成本= 腳本開發成本+（平均調試腳本成本 +平均執行腳本成本）× 測試執行次數
• 手工測試成本=平均手工執行工做量×測試執行次數
• ROI=自動化測試成本/手工測試成本

17   自動化vs手動測試（3）

小規模項目成本對比圖：

分析：

• 小規模測試基本上手動和自動均可以適用
• 在很小規模的時候，手工在成本上有很大的優點
• 隨着迴歸次數增長，手工成本基本線性增長，自動化則成本趨於穩定

18   自動化vs手動測試（4）

大規模項目成本對比圖：

分析：

• 軟件項目隨着規模增大，很容易產生滾雪球效應
• 手工測試很快遇到天花板，不管是成本仍是可操做性都會出現障礙，投入成本增幅遠高於開發成本增幅
• 自動化將成爲主流，基本成本的增加和開發的成本投入幅度至關

19   瀑布模式和敏捷模式

• 瀑布模式

  • 過程嚴格劃分：需求分析/設計/實現/測試/集成/維護
  • 分工明確，可是靈性性差，項目失敗風險大

• 敏捷模式(Agile Development)

  • 迭代開發(Iterative Development)
  • 增量開發（Incremental Development）
  • 把完整的過程分紅多個持續時間較短的迭代
  • 可以實現持續集成
  • 具備很好的項目的風險控制能力和項目持續生產能力

20   軟件過程自動化

• 構建自動化

  自動化從各個模塊的源碼構建組裝成一個完整的產品

• 測試自動化

  構建前自動完成相應的測試工做

• 部署自動化

  對於經過測試的構建好的產品，作好成品測試後，自動化部署到生產服務器

21   自動化場合選取

• 儘可能對穩定的對象作自動化，如API接口
• GUI不建議使用自動化，投資回報比過低，變動大

22   自動化比例

• 自動化腳本的開發工做並非越早越好，而是應該基於穩定的測試環境和測試計劃。

• 有經驗的測試工程師，是會在效率和質量上尋求平衡點，把精力集中在最容易出問題的點上。

• 自動化比例

  • 對於API測試的自動化測試選取40%~60%
  • 對於GUI測試的自動化測試選取30%左右

23   保留的爭議性觀念

1. 文檔的重要性不亞於軟件產品自己

   這和另外的思路「最好的文檔就是產品自己的代碼」有所出入。

2. 徹底的TDD是不適合大多數公司的。畢竟測試是屬於上層建築，創建在已有的開發產品上的。

---

做者:	Harmo哈莫
做者介紹:	https://zhengwh.github.io
QQ:	1295351490
時間:	2015-08-24
版權說明:	未經許可，嚴禁用於商業目的的非法傳播
聯繫或打賞:	http://zhengwh.github.io/contact-donate.html