軟件測試理論基礎知識

什麼是軟件測試
在必定的條件下，執行程序，比較實際結果與預期結果的過程

測試與調試的區別
測試 - 由測試人員完成 - 破壞性的
調試 - 由開發人員完成 - 建設性的

測試的七大原則
經過測試能夠顯示缺陷的存在
窮盡測試是不可能的
測試要儘早介入
缺陷的集羣效應
殺蟲劑悖論
測試依賴於具體的商業背景
沒有缺陷的系統並不表明是有用的系統

測試過程/測試流程/測試生命週期
制定測試計劃 - 測試組長/主管/經理 - 測試任務，時間，人員的安排
制定測試方案 - 測試管理人員/測試工程師 - 如何測試的指導性文檔
分析測試需求 - 測試工程師 - 基於軟件需求文檔，分析測試點
設計並編寫測試用例 - 測試工程師 - 將分析的測試點轉換爲企業標準的測試用例
評審測試用例 - 開發+測試+需求人員
搭建測試環境(Linux，Windows)
執行測試用例，提交併跟蹤缺陷 - 測試工程師
撰寫測試報告 - 測試工程師
測試總結 - 測試管理人員

軟件生命週期
計劃階段 - 項目經理 - 任務，時間，人員安排
需求分析 - 需求工程師/產品經理 - 分析並整理前端收集到的零散需求，並造成文檔
概要設計 - 架構人員 - 對系統總體框架的設計，肯定系統模塊，模塊與模塊之間的關係，編寫核心代碼，肯定系統與子系統的關係
詳細設計 - 開發人員 - 對模塊內部的算法及邏輯結構進行詳細設計，包括類，方法，函數，數據庫，表等
編碼 - 開發人員 - 編寫代碼
測試 - 測試團隊 - 參見測試流程
發佈 - 發佈負責人 - 程序+數據+文檔
運維 - 運維人員 - 負責客戶或用戶使用軟件過程當中的問題

軟件開發模型
邊作邊改模型
瀑布模型 - 把生命週期中的各個環節肯定下來，可是環節不可逆，測試滯後
快速原型模型 - 在需求階段，經過原型不斷和客戶溝通需求，最終肯定需求，再進行系統的總體設計與開發
V模型 - 爲每一個開發活動對應相關測試活動
用戶需求                                 驗收測試
    需求分析                    系統測試
        概要設計         集成測試
             詳細設計 單元測試
                        編碼
W模型
需求分析                   系統實施     測試需求分析                     系統測試
    概要設計           系統的集成                測試概設             集成測試
         詳細設計 模塊的集成                          測試詳設    單元測試
                     編碼                                                    編碼
增量模型 - 按照功能點開發
每個增量是一個流程，開發，測試，需求能夠並行工做

測試分類 - 按照不一樣維度分類
一、測試階段劃分（按測試執行順序）：
　　● 單元測試（Unit Testing）--UT
　　定義：針對軟件基本組成單元（軟件設計的最小單位）來進行正確性檢驗的工做；
　　測試目的：檢測軟件模塊對《詳細設計說明書》的符合程度。
　　● 集成測試（Integration Testing）--IT
　　定義：在單元測試的基礎上，將全部模塊按照概要設計要求組裝成爲子系統或系統，驗證組裝後功能以及模塊間接口是否正確的測試工做；
　　測試目的：檢測軟件模塊對《概要設計說明書》的符合程度。
　　● 系統測試（System Testing）--ST
　　定義：將已經集成好的的軟件系統，做爲整個基於計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其餘元素組合在一塊兒，

                 在實際運行（使用）環境下，對計算機系統進行的一系列的測試工做。
　　測試目的：與《需求規格說明書》作比較，發現軟件與系統需求定義不符合或與之矛盾的地方。
　　● 迴歸測試（Regression Testing）--RT
　　定義：軟件在測試或其餘活動中發現的缺陷通過修改後，進行的測試；
　　測試目的：驗證缺陷獲得了正確的修復，同時對系統的變動沒有影響之前的功能；
　　特色：迴歸測試能夠發生在任何一個階段，包括單元測試、集成測試和系統測試；
　　策略：
　　①、徹底重複測試：從新執行前期創建的全部測試用例，並確認缺陷解決和修改的擴散影響性；
　　②、選擇性重複測試：
　　——覆蓋修改法：選擇直接影響的用例；
　　——周邊影響法：選擇間接影響的用例；
　　——指標達成方法：達到指標的覆蓋率等。
　　流程：
　　1）制定迴歸測試策略
　　2）肯定測試的版本
　　3）按照迴歸測試策略執行迴歸測試
　　4）迴歸測試經過，關閉缺陷跟蹤單（問題單）
　　5）迴歸測試不經過，缺陷跟蹤單返回開發人員，經開發人員修改後再次進行迴歸測試
　　迴歸測試自動化：（需考慮的問題以下）
　　1）迴歸測試是一個重複的之前測試的測試，因此自動化是迴歸測試的追求；
　　2）自動化法包括：程序的自動運行、自動配置，用例的管理、自動輸入，測試自動執行，測試結果自動採集、比較及結論的自動輸出；
　　3）對比較穩定的可採用QTP、Robot、SilkTest等工具的「捕捉回放」工具；
　　4）爲了能實現自動化須要用到腳本語言，如：TCL、Python、Perl等；
　　5）對比較複雜的過程，沒法藉助工具的須要本身開發專用工具；
　　6）儘早考慮迴歸測試的自動化，造成工具化、可繼承和推廣的。
　　●　　其餘測試階段
　　○　　α測試：用戶在開發環境下進行的測試，評價軟件FLURPS
　　○　　β測試：多用戶在實際使用環境下進行的測試
　　○　　驗收測試：用戶根據合同、《需求規格說明書》或《驗收測試計劃》對產品進行的驗收測試
　　注：FLURPS即：功能、局域化、可用性、可靠性、性能、技術支持
二、單元測試、集成測試、系統測試的比較：
　　●　　測試方法:
　　單元測試屬於白盒測試範疇；
　　集成測試屬於灰盒測試範疇；
　　系統測試屬於黑盒測試範疇；
　　●　　考察範圍：
　　單元測試主要測試內部數據結構、邏輯控制、異常處理等；
　　集成測試主要測試模塊間的接口與接口數據傳遞關係，以及模塊組合後的總體功能；
　　系統測試主要測試整個系統相對於需求的符合度；
　　●　　評估基準：
　　單元測試主要經過邏輯覆蓋率來評估；
　　集成測試主要經過接口覆蓋率來評估；
系統測試主要經過測試用例對需求規格的覆蓋率來評估；

　　主要的測試文檔：
　　●　　測試計劃：測試範圍、方法、資源，以及相應測試活動的時間進度安排表的文檔；
　　●　　測試方案：爲完成軟件集成特性的測試而進行的設計測試方法的細節文檔；
　　●　　測試用例：爲完成一個測試項的測試輸入、預期結果、測試執行條件等因素的文檔；
　　●　　測試規程：執行測試時測試活動序列的文檔；
　　●　　測試報告：執行測試結果的文檔；
       ●　　測試日報：天天測試執行狀況的記錄和總結。
三、軟件測試過程規範
　　首先來看看軟件最權威的規範CMM（capability maturity model 能力成熟度模型）關於過程的要素的描述有哪些？
　　●　　角色（rolse）：執行者、工做者
　　●　　入口準則（entry criteria）：過程執行的前提條件
　　●　　輸入（input）：過程所需資源
　　●　　活動（activities）：過程執行
　　●　　輸出（output）：過程執行結果
　　●　　出口準則（exit criteria）：過程結束的條件
　　●　　評審和審覈（reviews and audits）：監督活動
　　●　　可管理和受控的工做產品（work products managed controlled）：標準性的東西
　　●　　測量（measurements）：能夠度量的
　　●　　書面規程（documented procedures）：計劃文檔類
　　●　　培訓（training）：業務培訓等
　　●　　工具（tools）：過程執行採用的工具
　　這些要素已經全面囊括了一個過程的方方面面，若是在軟件流程中的每個過程都按照這樣的規範執行，那麼軟件質量就能獲得必定的保證！
　　那麼做爲軟件測試工做，在整個軟件開發流程中的每個過程當中有哪些工做要作的呢？下面我將分角色、分階段的來學習。
四、系統測試過程
　　在這裏主要研究軟件系統測試過程當中的輸入和輸出，瞭解咱們應該根據什麼來作、要作什麼以及咱們作的前後順序是怎麼安排的過程。
　　系統測試計劃階段：
　　輸入：軟件開發計劃、軟件測試計劃、需求規格說明書
　　輸出：系統測試計劃
　　系統測試設計階段：
　　輸入：需求規格說明書、系統測試計劃
　　輸出：系統測試方案
　　系統測試實現階段：
　　輸入：需求規格說明書、系統測試計劃、系統測試方案
　　輸出：系統測試用例、系統測試規程、系統測試預測試項
　　系統測試執行階段：
　　輸入：系統測試計劃、系統測試方案、系統測試用例、系統測試預測試項、系統測試規程
　　輸出：系統預測試報告、系統測試報告、缺陷報告
五、集成測試過程
　　一樣這個過程將研究集成測試過程各個階段的輸入及輸出。
　　集成測試計劃階段：
　　輸入：軟件測試計劃、概要設計說明書
　　輸出：集成測試計劃
　　集成測試設計階段：
　　輸入：概要設計說明書、集成測試計劃
　　輸出：集成測試方案
　　集成測試實現階段：
　　輸入：概要設計說明書、集成測試計劃、集成測試方案
　　輸出：集成測試用例、集成測試規程
　　集成測試執行階段：
　　輸入：集成測試計劃、集成測試方案、集成測試用例、集成測試規程
　　輸出：集成測試報告、缺陷報告
六、單元測試過程
　　一樣這個過程將研究單元測試過程各個階段的輸入及輸出。
　　單元測試計劃階段：
　　輸入：詳細設計說明書、軟件測試計劃
　　輸出：單元測試計劃
　　單元測試設計階段：
　　輸入：詳細設計說明書、單元測試計劃
　　輸出：單元測試方案
　　單元測試實現階段：
　　輸入：詳細設計說明書、單元測試計劃、單元測試方案
　　輸出：單元測試用例、單元測試規程
　　單元測試執行階段：
　　輸入：單元測試計劃、單元測試方案、單元測試用例、單元測試規程
　　輸出：單元測試報告、缺陷報告
七、需求分析階段
　　每一個階段有每一個階段的任務，這裏將瞭解需求分析階段的任務，及其軟件項目各工做人員的任務所在。
　　需求分析階段任務：
　　●　　需求分析，完成SRS
　　●　　軟件需求規格說明書的評審：檢查遺漏和存在問題
　　●　　進行需求跟蹤
　　●　　系統測試計劃
　　●　　系統測試計劃的評審
八、概要設計階段
　　概要設計階段任務：
　　●　　軟件系統各層設計，完成HLD
　　●　　HLD的評審
　　●　　更新需求跟蹤
　　●　　系統測試方案、用例的設計
　　●　　系統測試方案、用例的評審
　　●　　集成測試計劃
　　●　　集成測試計劃的評審
9 、詳細設計階段
　　詳細設計階段任務：
　　●　　軟件詳細模塊的設計，完成LLD
　　●　　詳細設計的評審
　　●　　更新需求跟蹤
　　●　　集成測試方案、用例的設計
　　●　　集成測試方案、用例的評審
　　●　　單元測試計劃
　　●　　單元測試計劃的評審
十、編碼階段
　　編碼階段任務：
　　●　　軟件編碼
　　●　　對代碼進行靜態質量檢查
　　●　　代碼評審
　　●　　單元測試方案、用例的設計
　　●　　單元測試方案、用例的評審
十一、測試階段
　　測試階段的任務：
　　●　　系統預測試項執行
　　●　　系統預測試報告工做
　　●　　執行各階段測試用例
　　●　　各階段的缺陷記錄、修復
　　●　　各階段日誌報告
　　●　　各階段缺陷的迴歸測試
　　●　　各階段測試報告
　　●　　測試報告的評審

系統測試的類型：
　　　　　　　　功能測試-手工
　　　　　　　　功能測試-自動化
　　　　　　　　性能測試
　　　　　　　　兼容性測試
　　　　　　　　安全測試
　　　　　　　　接口測試
　　　　　　　　健壯性測試
　　　　　　　　安裝卸載升級測試
　　　　　　　　文檔測試

按照測試技術分：
　　　　　　　　白盒測試
　　　　　　　　灰盒測試
　　　　　　　　黑盒測試

按照是否運行程序：
　　　　　　　　靜態測試
　　　　　　　　動態測試

其餘測試相關開概念：
　　　　　　　　迴歸測試
　　　　　　　　冒煙測試
　　　　　　　　國際化測試 - I18N 本地化測試 - L10N
　　　　　　　　隨機測試
　　　　　　　　探索性測試

技術：
　　高級測試工程師
　　自動化測試工程師
　　性能測試工程師
　　安全測試工程師
　　接口測試
　　單元測試
　　數據庫管理員DBA
　　Linux系統運維
　　開發
　　運維
　　管理
　　測試組長、主管、經理
　　測試總監
　　項目經理
　　運維經理
　　質量部經理
業務：
　　需求工程師
　　產品經理
　　行業專家（電信，銀行，證券，供應鏈）

一個優秀的測試工程師須要具有的技能
素質：專業、性格、邏輯、情感
能力：測試基礎、標準與規範、測試流程、測試工具、測試方法
管理：管人、理事
行業經驗：業務、測試與行業背景結合愈來愈緊密
英語：外企、國外項目
性格：開朗、交流、團隊合做、追求完美、懷疑精神、善於說服

==========用例規範==========
測試用例的概念：
是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否知足某個特定需求。

爲何要寫測試用例：
　　　　　　　　　　便於可視化管理
　　　　　　　　　　避免測試點的遺漏
　　　　　　　　　　能夠提升測試效率
　　　　　　　　　　統一標準
　　　　　　　　　　便於重複測試
　　　　　　　　　　便於團隊交流
　　　　　　　　　　便於統計跟蹤

測試用例的八要素及其餘要素：
用例編號 – Test case no
測試項目/模塊 – Project name / Section
用例標題 – Test case name
優先級 - Priority
預置條件 – Pre-condition
輸入數據 - data
操做步驟 - Step
預期結果 – Expected result
做者 - author
版本 - version
日期 - data
測試結果 result
經過 - passed
失敗 - failed
阻礙 – blocked
未執行 - NA

-----------------
P1: 系統的基本功能，case數量應受到控制 15~20%
劃分依據：該用例執行失敗，會致使多處重要功能不可用；發生機率較高的，常用的功能
該類用例需在每一輪版本測試中執行
P2: 系統的重要功能，case數量較多 30~50%
劃分依據：各類應用場景，使用頻率較高的正常功能。功能交互相關。
在非迴歸的系統測試版本中都要執行，系統全部的重要功能都必須實現
P3: 系統的通常功能，case數量較多 30~50%
劃分依據：使用頻率低於P2，好比超長字符串，邊界值，事物完整性等
非迴歸的系統測試版本中不用都進行驗證，在系統測試的中後期不必定每一個版本都驗證
P4：無關緊要 10%
劃分依據：比較生僻的輸入，使用頻率很是低得功能
在版本測試中，有某些正常緣由，通過和產品經理進行溝通確承認以不執行
-----------------

測試用例的完整寫做過程
基於需求規格說明書分析測試需求-》設計測試用例-》寫做測試用例-》評審測試用例
用例如何評審？
當測試工程師完成用例的編寫後，先會通知開發與需求，開發和需求可提早查看測試用例，
測試工程師會安排評審會議，併發送會議邀請給相關開發，需求，項目經理，測試及開發組長。
測試，開發，需求等人員一塊兒開會，測試主導評審會議，並講解用例寫做相關內容，開發，
需求及其餘人員能夠提出建議及相關補充，會議經過後，測試再對用例進行最終整理。

什麼樣的用例是好的測試用例
從三個維度分析，第一個，用例設計角度，第二個，用例寫做角度，第三個，用例維護的角度
對需求的覆蓋
對被測試對象設計的瞭解
對具體的方法的使用
用例寫做符合5C原則
正確（correctness）：數據輸入
清楚（clarity）：操做步驟
簡潔（concision）：標題
完整（completion）：預期結果檢查完整
一致性（consistency）：用例編號
用例易於維護

==========缺陷管理==========
缺陷的屬性：
建立者 reporter
建立時間 date
缺陷版本 version
缺陷類型 type
缺陷所屬的產品/項目/模塊 product, project, feature
指派給 assign to
缺陷編號 no
標題 title
缺陷嚴重程度 serverity
缺陷優先級 priority
缺陷狀態 status 狀態： 激活active，已解決fixed, 已關閉closed；
【新建new,正在修改inprogress, 打開open, 從新激活reopened】
詳細描述 description
系統環境 OS (服務器環境和客戶端環境)
測試環境（用戶名/密碼）test environment
重現率
預置條件 pre condition
步驟 steps
實際結果 actual result
指望結果 expected result
其餘信息 additional information
用例編號 testcase no
*附件 attachment （截圖，視頻，文件-log日誌）
==================
解決者
解決方案：已修復fixed, 重複duplicated, 不能重現cannot reproduced, 無效Invalid
(設計如此by design，外部緣由external issue), 不修復won't fix, 推遲修改postpone)

缺陷引起的緣由 root cause
代碼改動範圍
影響範圍
解決日期
==================
驗證人
驗證環境
驗證範圍
結果
---------
缺陷的等級劃分：
緊急 - 致使系統運行中斷，程序崩潰，核心業務未完成，測試工做沒法進行，核心金額計算錯誤
嚴重 - 主要流程沒法進行，功能與需求不符，輕微的金額計算錯誤
通常 - 次要功能出錯，提示信息不符，體驗差，
微小 - 很細小的問題，幾乎對功能沒有影響
須要加強的功能Enhancement - 須要加強的功能
界面（UI）bug：有多是比較嚴重的問題，也有多是比較微小的問題
--------------
缺陷管理流程中的幾個角色
開發
測試
開發組長
測試組長

缺陷處理流程/缺陷的生命週期
測試人員在執行測試用例的過程當中發現bug，將其上報到缺陷管理系統，並指派給開發，開發初步判斷缺陷，
若是是缺陷並須要修復的，開發修改代碼後將代碼提交到服務器上，並將bug解決爲 已解決，同時回指給測試。
測試環境經過最新代碼更新後，測試人員驗證bug，若是肯定已經修復，測試關閉bug；不然，測試從新激活bug。
若是開發認爲缺陷是重複缺陷，開發會將缺陷解決爲重複缺陷，並回指給測試，測試要肯定是否確實重複，
若是是，測試關閉bug，不然，測試從新 激活 bug。若是在開發環境不能重現bug，開發會將缺陷解決爲 不能重現，
並回指給測試，測試要肯定是否確實不能重現，若是是，測試關閉bug，不然，測試從新 激活 bug。
若是開發認爲是無效bug，開發會將缺陷解決爲 無效【外部緣由，設計如此】，並回指給測試，測試要肯定是否確實無效，
若是是，測試關閉bug，不然，測試從新 激活 bug。若是開發認爲缺陷不須要修復，開發會召集產品經理，開發組長，
測試人員及測試組長一塊兒討論，若是你們一致贊成該缺陷不須要修復，開發會將缺陷解決爲 不予修復，並回指給測試，測試關閉bug。
若是討論以後肯定該缺陷須要修復，開發會修改缺陷若是缺陷須要推遲到下一個版本修改，在產品經理，
項目經理及其餘相關人員贊成以後，開發能夠將缺陷解決爲推遲修改，並回指給測試。

--------------------
XAMPP部署禪道系統 Windows+Apache+Mysql+PHP

XAMPP是一個集成工具，具體安裝過程以下：
一、下載 xampp安裝包到本身的電腦，解壓後雙擊進入到安裝界面，全部步驟均默認安裝
二、安裝完成後，打開xampp，打開方式：XAMPP -> XAMPP Control Panel， 此時會打開xampp的面板。
三、修改Apache的端口號80，修改方法爲：XAMPP面板上面點擊Apache後面的Config按鈕，在顯示出來的菜單中點擊 Apache(httpd.conf)，
此時會打開httpd.conf文件，找到 Listen 80，將80改成8008以後的端口，如8008，修改以後保存該文件並退出。點擊Apache後面的Config按鈕，
在顯示出來的菜單中點擊 Apache(httpd-ssl.conf)，打開該文件，找到 Listen 443，將443改成其餘端口，如4437，修改以後保存該文件並退出。
四、啓動Apache，啓動的方法：點擊 Apache後面的 Start 按鈕，若是啓動成功，則變爲 Stop，若是啓動時報ports之類的錯誤信息，
則代表第3步所修改的兩個端口號可能被佔用，須要從新修改端口號。
五、啓動Mysql數據庫，啓動的方法：點擊 Mysql 後面的 Start 按鈕，啓動以後，則變爲 Stop， Mysql的默認端口號爲3306，不須要修改。
六、將禪道的代碼佈署在環境當中，過程以下，拷貝 禪道安裝包到本機的C:\xampp\htdocs，拷貝完成後在該壓縮文件上面點擊右鍵，選擇解壓到當前文件夾，
解壓完成以後會生成一個新的文件夾，名稱爲 zentaopms。
七、安裝禪道環境：在瀏覽器中輸入 http://localhost:端口號/zentaopms/www/，進入安裝禪道界面，點擊 開始安裝 按鈕，進入受權界面，點擊下一步按鈕，
進入系統檢查界面，所有爲經過時，點擊 下一步 按鈕，進入生成配置文件界面， 默認語言選擇 簡體，數據庫服務器內輸入數據庫所在電腦的IP地址
【若是數據庫服務器在本機，輸入 127.0.0.1或localhost】,服務器的端口爲 數據庫服務的端口，默認爲3306，數據庫的用戶名默認爲 root
【root用戶爲mysql數據庫最高權限的管理員用戶】，數據庫的密碼默認爲空【安裝完mysql以後，若是沒有設置 root用戶的密碼，則其密碼默認爲空】，
PMS使用的庫爲正在安裝的禪道系統的數據庫名稱，建表前使用的前綴 默認便可，不須要勾選擇 清空現有數據 ，點擊保存，進入保存配置文件頁面，
點擊下一步按鈕，進入設置賬號界面，輸入公司名稱，管理員賬號及密碼【注意：此處須要牢記管理員賬號與密碼】，不須要勾選擇 導入demo數據，
點擊保存按鈕。進入安裝成功界面，點擊 登陸禪道管理系統 按鈕，進入禪道系統的登陸界面，輸入用戶名與密碼以後便可登陸。

==========敏捷開發==========
敏捷體現的是一個字：快 - 在比較短的時期內發佈可工做的軟件產品
Scrum流程：
客戶/市場/高層 提出一些創意/新功能/缺陷，由產品負責人[產品經理]對其進行整理成產品功能列表[產品需求清單]【產品需求清單中的每個功能點，也稱之爲需求點
或故事-story】，產品負責人從產品需求清單中挑選出一個版本(迭代)須要完成的功能點，交由開發團隊，此時，開發團隊和產品負責人一塊兒開迭代計劃會，肯定一個
迭代的詳細計劃，並對開發任務進行分解及分配，當完成計劃會後，開發人員分別按照計劃開發各自負責的任務，當全部任務完成以後，團隊內部會進行 迭代評審會議，

會議的內容爲該迭代是否可以正常發佈，如能發佈，則在發佈以後，團隊進行 回顧會議。

三大角色：
產品負責人/產品經理：需求+相關管理工做
流程管理員/項目經理：大多數狀況下由項目經理或開發組長承擔
開發團隊：開發+測試

其餘概念：
版本：與傳統開發模式的版本相似
迭代- sprint：有可能一個版本有一個迭代，有可能一個版本有多個迭代
故事-story：須要開發的功能點
任務看板：將未開始的任務，已開始的任務及已完成的任務分類彙總
燃燼圖- burn down chart：以任務和時間爲Y與X軸，繪製天天的任務完成狀況，造成具體的圖形。
五大會議：
迭代規劃會議
每日站立會議
演示會議：產品經理演示需求的原型，開發人員演示功能點，全部開發的功能完成後的總體功能演示。
評審會議
回顧會議

里程碑 - mile stone
基線 - base line
最後期限 - dead line

==========軟件質量==========
質量的定義：實體的特性對需求的知足程度

軟件質量的三個層次：
符合需求規格
符合用戶顯式需求
符合用戶實際需求【顯式需求+隱式需求】

影響軟件質量的三大因素[軟件質量的鐵三角]
技術
流程
組織
問題：你是如何確保你所負責的功能模塊的質量的?
大家項目組是如何確保所測項目的質量的?

三大質量管理體系
ISO9000：八項質量管理原則 【以顧客爲中心，以顧客的需求爲導向】
CMM/CMMI：Capability Muturity Model/ Integration - 能力成熟度模型
初始級
可重複級
已定義級
已管理級
優化級
CMM與CMMI的區別：
表達方式：CMM階段式，CMMI可階段，可連續
關鍵過程域不一樣：第三級的關鍵過程域
六西格瑪：起源於製造業-摩托羅拉
核心：百萬樣本3.4個缺陷

軟件質量模型：內部質量與外部質量 - 六大特性，二十七大子特性