天天看點

軟體品質管理實踐總結

文章版權由作者小小小絲和部落格園共有,若轉載請于明顯處标明出處:http://rpc.cnblogs.com/metaweblog/xxxs

目錄

第一章:缺陷綜述

第二章:需求開發與管理

第三章:配置與變更管理

第四章:同行評審

第五章:軟體測試

第六章:QA發現不符合問題的處理

第七章:軟體度量

第八章:缺陷管理 

第一章:缺陷綜述

1. 軟體缺陷的定義:軟體産品在某種程度上不能滿足使用者的需求

2. 軟體缺陷的生命周期:從一個軟體缺陷被發現、報告到這個缺陷被修複、驗證,最後關閉的過程

3. 缺陷産生的原因: 原因很多,例如重技術不重管理、項目監控和計劃做得不夠好、不紮實等等

4. 缺陷是誰産生的: 任何人都有可能産生缺陷

5. 缺陷發現的手段: 同行評審、測試、管理評審、 QA發現、項目組内部發現、客戶回報

第二章:需求開發與管理

1. 需求的概念和層次

① 概念:需求就是以一種清晰、簡潔、一緻且無二性的方式,對待開發的各個有意義方面的陳述的集合

② 層次:從應用角度看軟體需求

  A. 業務需求:反映組織機構/客戶對系統産品高層次的目标要求

  B. 使用者需求:使用者使用産品必須完成的任務

  C. 功能需求:開發人員實作軟體功能,使得使用者能夠完成的任務,進而滿足業務需求

2. 需求管理:控制和維持需求的約定;需求追蹤是雙向的,正向由PM主導,其他人輔助,逆向由測試主導

3. 需求驗證:評審為主,一般參與人員為各個技術的專家

第三章:配置與變更管理

1. 概念:一門用來記錄并且控制軟體産品資料的管理學科,是對各類工作産品的内容、版本、變更和釋出進行控制

① 忽視軟體配置管理會導緻如下現象:

  A. 已經排除的bug,反複出現

  B. 找不到最新修改的源代碼

  C. 找不到原來的程式設計人員

  D. 發行的版本錯誤

  E. 軟體正常安裝後不能工作

  F. 異地不能正常工作

2. 配置控制委員會CCB:一般項目經理會根據配置控制委員會的建議和準許管理各項活動并且控制它們的程序,一般組成人員:高層經理、項目經理、關鍵的RD、關鍵的QA、PPQA代表、 CM代表、 PM,CCB的組長不能是項目經理

3. 配置項:一般包含:計算機程式、開發者和使用者的文檔、資料等,每一個配置項需表明:作者、時間、原因、目前狀态、版本号

4. 配置管理活動:

① 内容

  A. 制定配置管理計劃

  B. 建立三庫(開發庫、受控庫、發行庫)

  C. 确定配置辨別規則

  D. 進行版本管理和發行管理

  E. 實施變更控制

  F. 進行配置審計

  G. 報告配置狀态

5. 變更管理活動

① 發生在開發過程的所有階段,從需求分析到産品開發再到維護

② 變更追蹤:處理變更及新增功能送出、評估、實施、驗證與完成的流程

③ 實施變更管理重要的作用就是對變更進行度量分析

④ 變更申請流程:涉及的變更範圍寫明,通知項目經理——同意後,項目經理填寫變更申請單—

—送出給CCB審批,告知CM(客戶經理)

第四章:同行評審

1. 同行評審與測試的關系:開發階段,專家對代碼的一個評審,提高代碼品質,減少測試成本,這樣能夠加深開發人員對工作的了解,預防bug,也避免在測試階段大量返工

2. 同行評審的種類:正式評審、技術審查、走查

3. 同行評審的對象:産品需求規格書、使用者界面規範與設計、設計模型、源代碼、測試計劃、設計、用例及步驟、項目計劃

4. 正式評審的流程:預備會議-審查-評審會-書寫評審報告-返工-跟蹤

第五章:軟體測試

1. 軟體測試的基本問題:軟體測試的概念、對象、目的、原則、方法等

① 軟體測試的概念:廣義指驗證和确認、狹義指檢查代碼和文檔的品質問題

② 軟體測試的對象:程式代碼、開發階段需求文檔

③ 軟體測試的目的:

  A. 從使用者角度看:發現隐藏的錯誤和缺陷

  B. 從開發者的角度看:驗證軟體實作了所有使用者的要求

  C. 從測試的角度看:一是發現錯誤、二是通過錯誤來改進軟體開發過程中存在的缺陷

④ 軟體測試原則:

  A. 程式修改,需要回歸測試

  B. 寫測試用例和執行case的人應該分開………..

⑤ 測試可以發現的缺陷:

  A. 通過調試過程開發人員可以進行缺陷自測

  B. 通過單元測試可以發現代碼中的缺陷

  C. 通過黑河測試可以發現功能測試

  D. 理想狀态下,測試用例設計的足夠完善,可以發現全部的bug

2. 軟體測試的基本方法:

① 白盒測試:一直産品内部工作過程的測試活動,通過測試檢測内部操作是否符合設計說明書的

要求

② 白盒測試時窮舉路徑測試,主要的方法:邏輯驅動、基路測試,白盒測試過程應全面了解程式

内部邏輯結構,從檢查程式入手,對所有的邏輯路徑進行測試,得出測試資料

③ 黑盒測試:功能測試

3. 測試工程師的技能:

① 需掌握測試設計的方法,相應的測試思路

② 需了解測試的不同級别、級别的差異、每個級别的重點

③ 需要掌握測試的類型,了解測試需關注的重點、差別和重疊的地方

④ 需掌握系統背景知識,業務知識

4. 軟體測試的過程:單元測試、內建測試、驗收測試

5. 軟體測試的方法:

6. 測試技術專題:

① 測試政策:先按标準步驟來測試,然後進行邊界和破壞性的檢查。測試原則:盡早測試、經常測試、充分測試開發人員要建立品質的意識

② 手工/自動測試的時機:

  自動化測試的時機:項目沒有時間壓力、被測系統是可以自動化測試的、擁有運作測試的硬體…

  手工測試的時機:與上相反

 測試用例複審:測試用例應該具有重複使用性

 何時終止測試:不允許存在A、 B、 C類bug,D不超過50%、 E允許存在(系統測試)

 Web性能測試:驗證軟體系統是否能夠達到使用者提出的性能名額

 記憶體洩漏測試:解決思路,安排有經驗的程式設計人員進行代碼走查和分析,或者利用專門的測

試工具進行分析

 測試風險的管理:需求了解、測試用例覆寫、需求變更、測試環境等等

 代碼移交過程測試

 處理不可重複出現的bug:版本資訊、環境、人、測試工具、

7. 測試的度量:搜集相關的規模、工作量、進度、成本、品質等資料和資訊

① 客戶回報的缺陷:提現測試的品質

② 子產品缺陷密度

③ 遺留缺陷數

④ 測試用例的有效性

第六章:QA發現的不符合問題的處理

1. QA的擔當的角色:老師(指導項目)、警察(評價開發的過程)、醫生(幫助項目組想辦法解決問題)

2. QA的職責要求:

① 具備一定的知識和技能(有開發經驗)

② 公平公正的素質

③ 自信,較強大的溝通能力

3. QA特别關注的問題

① 項目計劃制定不合理

② 維護需求的可追蹤性和一緻性容易出問題

③ 配置管理容易出問題

4. 對QA的誤解:

① 認為QA應該負責産品品質,産品品質應該是由每一個人負責

② 認為QA