一、目錄
軟體品質模型
測試技術類型
測試流程規範
研發品質規範
問題交流
二、軟體品質模型
1、好的架構
2、充分了解了使用者需求
3、盡量少的bug
4、性能好
軟體品質模型
功能性 可靠性 可移植性 易用性 維護性 效率
三 測試技術類型
1、功能測試
單元測試
內建測試
系統測試
驗收測試
測試計劃
測試用例
測試執行
缺陷跟蹤
修改建議
測試報告
2、性能測試
壓力測試
負載測試
疲勞測試
POC測試
性能問題分析診斷
性能問題分析診斷
資料庫優化、SQL優化
中間件優化、作業系統優化
3、安全測試
等級保護
實體安全
網絡安全
主機安全
應用安全
資料安全
SQL注入
DOS攻擊
XSS跨站腳本攻擊
工具掃描
人工掃描
4、自動化測試
自動化設計
自動化腳本開發
中斷處理
排程執行
結果分析
5、使用者體驗測試
易用性測試
可用性測試
全面CE
A/B測試
6、雲測試
雲服務測試
雲平台測試
雲安全測試
核心子產品POC測試
7、移動網際網路、手機API測試
App功能測試
APP性能測試
APP相容性測試
APP安全測試
APP使用者體驗測試
APP自動化測試
8、API測試
API功能測試
API性能測試
9、相容性測試
浏覽器相容性
作業系統相容性
資料庫相容性
移動用戶端相容性
國産化相容性測試
四、測試流程規範
1、研發測試流程：
2、研發任務單撰寫要求：
任務名稱：
為該任務的名稱，建議名稱簡潔，并能展現任務包解決的問題。（必填）
任務描述：對任務包解決問題或者功能的較長的描述。
所屬元件：為該任務所屬元件。一個任務隻能屬于一個元件。（必填）
菜單路徑：修改的問題涉及到的具體菜單，提供此資訊可以友善測試人員測試。
需求/TD号：填寫任務包修改的問題與TD或者已有的需求管理系統中得對應編号。
優先級：根據任務包的緊急程式分為高、中、低三級，根據實際情況填寫。
部署說明：為該任務包生成後的建構包在運作環境中的部署方式說明。如果部署說明比較長，建議整理成文檔添加在附件中。
有無sql：任務包中有更新sql，則填寫有，否則為無。該字段沒有實際的意義，主要用來提醒測試人員和釋出人員。
依賴的任務：該任務包依賴的其他任務包。如果該任務包依賴其他的任務包，在建構和測試時，會有提示必須先建構和測試依賴的任務包。
計劃完成時間：該任務包的計劃完成時間。目前這個時間不做預警。
測試結果：測試人員填寫該任務包的測試結果。
實際完成時間：該任務包的實際完成時間。
3、缺陷管理-缺陷嚴重程度
緻命關鍵：
造成系統崩潰或引起嚴重資料錯誤的問題、可能導緻敏感資料洩露的安全問題
嚴重：
主要業務流程無法跑通或嚴重影響軟體使用的問題，且無其它的替代方式
一般（平均）：
不影響主要業務流程，但會影響軟體使用的一般問題
較輕：
對軟體使用影響較小，輕微的程式問題
建議：
針對非主要功能易用性或使用者潛在需求提出建議性問題
4、缺陷原因分類
| 序号 | 一級分類 | 二級分類 |
| 1 | 程式技術 | 腳本錯誤 |
| 對象擷取錯誤 | ||
| 邏輯判斷 | ||
| 錯誤的方法 | ||
| java異常 | ||
| 浏覽器相容性 | ||
| 字元集 | ||
| 2 | SQL類 | SQL文法錯誤 |
| SQL相容性 | ||
| 通路資源不存在 | ||
| SQL性能 | ||
| SQL注入 | ||
| 3 | 業務邏輯 | 需求未完全實作 |
| 需求實作錯誤 | ||
| 需求遺漏 | ||
| 流轉環節有誤 | ||
| 計算與精度 | ||
| SQL設計錯誤 | ||
| 序号 | 一級分類 | 二級分類 |
| 4 | 部署問題 | 應用系統配置 |
| 環境遺留 | ||
| 源檔案不正确 | ||
| 5 | 易用性 | 校驗與提示 |
| 頁面問題 | ||
| 使用者體驗 | ||
| 6 | 自測不足 | 直接拷貝 |
| 資源不存在 | ||
| 拼寫錯誤 | ||
| 方法無實作 | ||
| 7 | 第三方軟體 | 樓上平台 |
| 平台使用錯誤 | ||
| 第三方插件 | ||
| 8 | 其它 | 其它 |
5、缺陷生命周期
| 狀态 | 具體含義 | 授予的角色 |
| New | 新的缺陷,并未得到确認。 | 測試人員 |
| Open | 缺陷經過确認，研發人員必須修改 | 項目經理 |
| Fixed | 缺陷經過修改 | 開發人員 |
| Closed | 缺陷關閉，跟蹤結束 | 測試人員 |
| Reopen | 缺陷重新打開，該缺陷仍然存在 | 測試人員 |
| Rejected | 缺陷被拒絕修改 | 項目經理\開發人員 |
| Delete | 缺陷錄入重複時選擇此項，表明此缺陷已被錄入 | 測試人員 |
| Confirm | 缺陷确認，測試人員對被拒絕的缺陷與項目經理及開發人員進行确認 | 測試人員 |
| Delay | 延遲修改 | 開發人員 |
6、缺陷管理流程
五、研發品質評價
1、統一的軟體品質名額
| 名額類别 | 名額名稱 | 計算公式 |
| 研發品質 | 缺陷檢出率 | =檢出缺陷數/(檢出缺陷數+回報缺陷數）*100％ |
| 嚴重缺陷占比 | =檢出嚴重缺陷數/檢出缺陷總數*100％ | |
| 回報缺陷密度 | =客戶回報缺陷數/産品研發規模（人月） | |
| 缺陷密度 | =檢出缺陷數/産品研發規模（人天） |
2、常用研發人員工作評價
| 序号 | 品質名額 | 名額公式 | 名額說明 | 為建立、改進品質名額拟采取的品質活動 |
| 1 | 一次通過率 | 一次測試就通過的被測包數/送出測試包數 | 評價研發人員開發品質 |
|
| 2 | 平均每包缺陷數 | 測試發現缺陷數/已測包數 | 評價研發人員的開發品質 |
|
| 3 | 平均每包研發時長 | 每個任務包在研發階段的時間求平均 | 評價研發人員研發效率 |
|
| 序号 | 品質名額 | 名額公式 | 名額說明 | 為建立、改進品質名額拟采取的品質活動 |
| 4 | 缺陷修複率 | 經驗證已正确修複的缺陷數/确認缺陷數 | 評價研發人員修複效率 |
|
| 5 | 代碼審查缺陷數 | 代碼審查出問題數 | 評價研發人員靜态代碼品質 |
|
3、常用測試人員工作評價名額
| 序号 | 品質名額 | 名額公式 | 名額說明 | 為建立、改進品質名額拟采取的品質活動 |
| 1 | 平均每天Bug數 | 測試出的有效bug數（個）/工作量（天） | 評價測試品質和效率 |
|
| 2 | 測試規範 | 每月抽查測試用例規範和BUG規範與部門标準比較 | 評價測試品質 |
|
| 3 | 缺陷根因分析 | 對關鍵、嚴重的問題進行代碼級别的原因分析；與部門标準比較 | 評價測試品質 |
|
| 4 | 工作量飽和度 | 實際工作量(天)/正常工作量 | 評價測試工作飽和度 |
|