软件测试的理论知识
1、前言
1.1什么是軟件測試？
軟件測試是一系列過程活動，包括軟件需求分析，測試計劃分析，測試用例設計，執行測試用例等。它貫穿于整個軟件測試的周期，在軟件項目的每個階段，都需要進不同目的的內容的測試活動，以保證各個階段的正確性。
1.2為什么要進行軟件測試？
假如你安裝的軟件是一個未經測試的軟件，那么在使用過程中可能會遇到：軟件死機，賬號被盜，資金被轉等，而軟件測試工程師的出現正是為了規避這些問題。
1.3軟件研發初期的過程
2.研發模型
2.1 瀑布模型
計劃--需求分析--設計--編碼--測試--運行和維護
特點：
優點：
缺點：
2.2 V模型
用戶需求--需求分析--概要設計--詳細設計--編碼--單元測試--集成測試--系統測試--驗收測試
優點：
缺點：
１.忽略了軟件測試對象不止有程序還包括文檔
２.驗收測試是最后階段，需求階段的問題只能到驗收階段才能發現
2.3 W模型
優點：
缺點：
無法迭代，指的相對的，不是絕對的
2.4 X模型
2.5 螺旋模型
2.6 快速模型
又稱原型定義，非線性化研發模型，主要適用于小公司，客戶到了最后才知道軟件的最終模樣，先做一個ｄｏｍｅ（模型或樣本），給客戶進行產品的預演。
２.７迭代開發
每次只設計和實現產品的一部分，通過逐步完成的方法叫迭代開發，每次設計和實現一個階段叫迭代
優點：
2.8 敏捷開發
敏捷開發以用戶需求進化為核心，采用迭代，循序漸進的方法進行軟件開發
敏捷開發的核心價值觀：
優點：
敏捷確實是項目進入實質的迭代階段，用戶很快可用看到一個基本架構版的產品，敏捷注重市場快速反應能力
缺點：
敏捷注重人員的溝通，忽略了文檔的重要性，若項目人員流動太大，又給維護帶來了不少難度，特別是項目中新員工比較多，老員工比較累。
tips：
敏捷和迭代雖然不一樣，但是他們是分不開的，迭代開發和敏捷開發的結合，既保證了產品的質量又在項目產品的持續改進中具有一定的優勢，吸取精華，剔除糟粕，只有這樣，項目才會達到趨近完美的程度。
2.9 軟件的生命周期
需求--設計--編碼--測試--維護--升級--廢棄
2.11 項目中的成員
3.軟件測試基礎
3.1 軟件測試的定義
在規定條件下操作程序，發現缺陷，評估軟件質量
3.2 軟件測試的目的
盡可能多的發現軟件的缺陷，預防缺陷，對軟件的質量進行評估，以提高軟件的質量
3.3 軟件測試的范圍或對象
程序、文檔、數據
3.4 軟件測試的原則
所有的測試都應該追溯到用戶需求
需求是軟件測試的依據
應當把盡早測試和不斷測試作為軟件測試的座右銘
盡早測試能夠降低開發成本不斷測試更能提高軟件的質量
完全測試是不可能的，測試需要終止
出于成本考慮和現實考慮
軟件測試無法顯示潛在缺陷
缺陷有時候需要在特定的情況下才會出現
充分注意群集現象
二八原則，80%的缺陷出現在20%的模塊上，發現bug越多的模塊，殘留的bug越多
避免程序員檢查自己的程序
開發沿用之前的開發思路，去找問題很難發現問題
``避免軟件測試的隨機性`
測試需要計劃，節約成本和人力
3.5 軟件測試的風險
進度風險，質量風險，人員風險，成本風險，變更風險
3.6 測試工程師所具備的素質
綜合素質：
專業素質：
4.軟件測試的分類
4.1 按照階段 階段劃分
單元測試--集成測試--系統測試--驗收測試
自頂向下增量式集成需要編寫：測試樁
自底向上增量式集成需要編寫：驅動程序
分類和范圍
驗收測試
依據：用戶需求，需要用戶參與
分類：
正式驗收測試 非正式驗收測試 阿爾法測試(α測試）和貝塔測試（β測試）
阿爾法測試和貝塔測試的區別：
阿爾法測試是由公司內部人員測試，貝塔測試是由典型用戶測試
阿爾法測試遇到bug可以控制，貝塔測試遇到bug不可控
阿爾法測試使用的是測試環境，貝塔測試使用的是現網環境，又稱線上環境，公網環境，生產環境
阿爾法測試發現問題能夠及時修復，貝塔測試需要統一收集然后集中修復
4.2 按照是否運行程序 劃分
動態測試：運行被測試的軟件
靜態測試：靜態去查看文檔，或者代碼走查，代碼審查
4.3 按照技術 技術劃分
黑盒測試：不關注軟件的內部邏輯結構，只關注輸入和輸出，關注功能和性能，適用于系統測試和驗收測試
白盒測試：與黑盒測試相反，適用于單元測試
灰盒測試：介于白盒測試和黑盒測試之間，適合用于集成測試，接口測試
4.4 其他測試
5.需求分析
5.1 什么是需求分析
主要是解決測試什么的問題，明確測試的地方
以需求規格說明書為基礎，進行細化和分解
5.2 需求分析的范圍
主要指的是明確和隱含的需求
5.3 需求分析的責任人和時間
誰來做：有經驗的軟件測試工程師
需求分析的時間：通常占項目周期的10%-20% 左右的時間（工作日）
5.4 需求分析的文檔和工具
輸出的文檔：測試需求分析文檔（測試點）
工具:mindmanager，xmind
5.5 需求分析的評審人員
組內的軟件測試工程師，產品經理，開發代表，測試經理，項目經理，QA
5.6 需求分析的特征
需求項必須是可核實的
需求分析需要指出正確條件和錯誤條件
需求分析不包含具體數據
5.7 需求分析的方法
測試要點，測試類型，功能交互，質量特性
5.8 需求分析的過程
5.9 需求分析舉例
5.10 常見的測試點
5.10.1.登錄
5.10.2 刪除
5.10.3 修改密碼
5.10.4 新增
5.10.5 驗證碼
5.10.6 查詢
5.10.7 翻頁
5.10.8 統計
5.10.9 日歷控件
5.10.10 導入
5.10.11 導出
5.10.12 支付
6. 測試計劃
6.1 編寫人和時間
編寫人：測試經理或者測試組長
編寫時間：需求分析完成后，時間2-5天，在整個測試過程中處于不斷修改的狀態，保證測試計劃滿足實際需求
6.2 參考依據和讀者對象
參考依據：需求分析結果，項目計劃
讀者對象：
1.上：項目經理
2.中：開發經理，產品經理
3.下：組內的軟件測試工程師，組外的其他測試經理
6.3 如何制定測試計劃
認真做好測試資料的收集工作，主要收集人和設備
明確測試的目標，主要是時間目標和質量目標
堅持5W原則，明確內容和過程
why：測試的目的
what：測試的范圍
when：測試的時間
who：測試的參與人
where：項目中的輸出的文檔，軟件包存放的位置
6.4 測試計劃包含哪些內容
項目概述，目的和范圍，測試的通過準則，讀者對象，測試的參考資料，測試策略，硬件環境，軟件環境，啟動條件，結束條件，測試周期，人力投入，任務分配以及進度安排，測試風險
6.4.1 測試策略
又稱測試類型，主要指的是冒煙測試，功能測試，回歸測試，兼容性測試，性能測試，接口測試，安全性測試…
6.4.2 測試的啟動條件和結束條件
啟動條件：
1.測試用例編寫完成，并通過評審
2.開發編碼完成，并通過自測
3.開發提交了轉測試申請單以及相關配置
4.測試環境搭建完畢，冒煙測試通過
結束條件：
1.測試任務全部完成，人力投入充分
2.需求覆蓋率一般達到100%，測試用例通過率一般達到100%
3.缺陷密度達到預定標準
? 1.預定標準：高驗收標準：3-5個，一般驗收標準：6-10個
? 2.缺陷密度計算方式。缺陷密度=bug總數/中代碼量，代碼量單位：KLOC，千行
4.bug缺陷呈現正態分布或者收斂狀態
5.需求規格說明書中的所有功能全部正確實現
6.交付件齊全，系統測試通過
7.測試方案
7.1 概念
測試方案是對需求分析結果進行細化和分解得到的功能點，主要是解決怎么做的問題
7.2 編寫人和時間
時間：測試計劃編寫完成后，大型項目：兩周左右，中小型項目：一周左右
編寫人：具有豐富經驗的軟件測試工程師
tips：
真實項目中大多數公司（90%）沒有測試方案，將測試方案和需求分析結果合并一起稱為測試設
計，測試方案主要是圍繞測試類型進行展開，如：自動化測試，接口測試，性能測試，安全測試…
7.3 評審人
組內軟件測試工程師，產品經理，開發代表，測試經理，項目經理，QA
8.測試用例
8.1 概念
測試方案和測試用例均屬于測試的設計文檔，測試用例描述了輸入動作和一個期望結果，目的是確定程序的某個功能是否正常工作的
8.2 參考依據
需求規格說明書，需求分析結果，測試方案
8.3 編寫人和時間
編寫人：具有豐富經驗的軟件測試工程師
編寫時間：測試方案編寫完成并且通過評審，編寫時間占整個項目周期30% 左右
8.4 編寫的工具和輸出的文檔
輸出的文檔：測試用例
編寫工具：excel，word，zentao，bugfree，testlink…
8.5 評審人
組內軟件測試工程師，開發代表，產品經理，測試經理，項目經理，QA
8.6 用例組成
用例編號，功能模塊，標題，優先級，預置條件，操作步驟，預期結果，設計人，設計時間，備注
8.6.1 用例編號
不能重復
格式：項目名-模塊名-編號
如：QQ-login-0001
這里的模塊指的是一級模塊
8.6.2 功能模塊
主要是為了方便任務分配，知道用例的所屬路徑，一般寫二級模塊，也寫三級模塊。
如：朋友圈-評論
8.6.3 標題
格式：在什么地方+條件+結果
如：在QQ登錄界面，輸入正確的用戶名密碼，登錄成功
要求：
1.標題不能重復
2.標題中不能寫bug
3.標題不能有歧義。如：是否，大概，也許，可能…
4.標題不能涉及具體數據，具體數據在預置條件和操作步驟中
5.標題和預期結果相呼應
6.標題中沒有句號，最多一個逗號（不是必須）
7.標題長度一般不超過24個字（不是必須）
8.6.4 優先級
1.目的是為了測試時間不充分的情況下，按照優先級比例抽取主要功能模塊進行執行，如：冒煙
測試，回歸測試
2.根據重要性和使用頻率來確定用例的優先級，兩高得高，兩低得低，一高一低得中
3.優先級高中低的比例：1:3:1
4.正常場景用例比異常場景用例高一個級別
8.6.5 預置條件
1.在具體的測試數據之前需要準備的前提條件，如：登錄系統，必須提前注冊賬號
2.包含具體的測試數據
3.測試時需要的環境信息
8.6.6 操作步驟
1.具體的功能界面輸入的數據和操作的按鈕
2.操作步驟包含的測試數據
8.6.7 預期結果
用例的期望結果，指明測試用例執行后要達到什么樣的結果
9.黑盒測試用例的設計方法
9.1 概念
黑盒測試，又稱功能測試，數據驅動測試或者基于需求規格說明書的測試，是從用戶觀點出發的測試
9.2 測試用例的設計要點
1.用最少的測試用例盡可能全面的覆蓋所有的需求
2.窮舉測試數據太大，完全測試是不可能的，測試需要終止
9.3 等價類
1.定義：把所有可能輸入的數據劃分為若干部分，然后從子集中抽取少量具有代表性的數據作為測試用例
2.有效等價類：指對程序規格說明書來說是合理的，這些數據的構成的集合稱為有效等價類
3.無效等價類：指對程序規格說明書來說不合理無意義的輸入數據所構成的集合稱為無效等價類
4.劃分標準：
? 1.完備測試：將集合劃分成不相交的一組子集，而子集的并集是整個集合
? 2.避免冗余：子集之間互不相交
5.劃分方法：
? 5.1在輸入條件規定了取值范圍或者個數的情況下，可以確定一個有效等價類和兩個無效等價類
5.2 在輸入條件規定了值的集合或者規定了必須如何的情況下，確定一個有效等價類和一個無效等價類
5.3在輸入條件是一個布爾值的情況下，可以確定一個有效等價類和一個無效等價類，布爾值：True和False
5.4 在規定了輸入數據的一組值，并且程序需要對每一個值分別處理的情況下，可以確定n個有效等價類和一個無效等價類
5.5 在規定了輸入的數據必須遵守規則的情況下，可以確定一個有效等價類和n個無效等價類，從不同角度去違反規則
? 5.6在確定已劃分等價類中由于元素在程序處理方式不同的情況下，需要將等價類進一步劃分為更小的等價類
6.設計原則
1.為每個等價類規定一個唯一編號
2.設計一個新的用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步驟直到所有的有效等價類都被覆蓋為止
3.設計一個新的用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步驟直到所有的無效等價類都被覆蓋為止
7.舉例
某個系統的注冊頁面有一個會員名稱輸入框，該會員名稱由字母或者漢字組成，不能包含空格，長度為3-10個字符，一個漢字占一個字符，會員名稱不能為空，會員名稱不能重復，采用等價類劃分方法，對會員名稱進行用例設計
9.4 邊界值
邊界值是對等價類方法的補充
上點：取值范圍的端點，不用關注端點取值到底是有效還是無效
離點：取值范圍端點的左右兩邊的值
內點：取值范圍大概中間的值
弱覆蓋：上點有效，離點無效，上點無效，離點有效
強覆蓋：上點+離點
舉例：
例題1：某程序有一個輸入框，該輸入框可以輸入整數范圍(-32,23】 <==> （-32<x<=23），
請寫出需要對應的邊界值？
上點：-32,23
離點：-33.-31,22,24
內點：-5
強覆蓋：-33，-32，-31,22,23,24
弱覆蓋：-32，-31,23,24
例題2：電子稱生產商生產了一批電子稱，電子稱可稱重范圍是【1.01,100.00），電子稱精度為
0.01kg，寫出對應的邊界值？
上點：1.01,100.00
離點：1.00,1.02,99.99,100.01
內點：50.00
強覆蓋：1.01,1.00,1.02,99.99,100.00，100.01
弱覆蓋：1.00,1.01,99.99,100.00
9.5 錯誤推測法
基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而針對性的設計測試用例。如：
1.對于日歷控件中考慮閏年的2.29和平年的2.28
2.對于多條相同數據怎樣排序
3.密碼中加入空格
4.密碼不支持拷貝，但是可以在密碼輸入框中粘貼內容
5.兩個用戶同時刪除同一條數據，一個成功，一個失敗
6.不勾選數據，刪除數據，應當有相應的提示
7.新增時，考慮數據的唯一性
8.查詢數據時，輸入通配符，只能查詢出包含通配符%和_的數據
9.app軟件在使用過程中來電話，軟件能夠正常使用
10.退出用戶登錄界面，使用瀏覽器的返回按鈕，不能返回至登錄界面
11…
9.6 場景法
場景法又稱流程分析法，是將軟件系統的某個流程看成路徑，使用路徑分析的方法來設計測試用例，根據用例順序依次進行組合，使得流程的各個分支都能覆蓋
基本流：主場景，流程的主干
備選流：可選場景，流程的分支
1.開始用例–基本流–結束用例
2.開始用例–基本流–備選流1–結束用例
3.開始用例–基本流–備選流4–結束用例
4.開始用例–基本流–備選流1–備選流2–結束用例
5.開始用例–基本流–備選流3–結束用例
6.開始用例–基本流–備選流3–備選流1–結束用例
7.開始用例–基本流–備選流3–備選流4–結束用例
8.開始用例–基本流–備選流3–備選流1–備選流2–結束用例
例2：
9.7 用例設計方法選擇策略
1.對于業務流程清晰的系統，可以采用場景法貫穿整個測試流程（主要用于冒煙測試和回歸測試）
2.進行等價類的劃分，將無限的測試變為有限
3.然后結合邊界值分析方法進行補充
4.然后使用錯誤推測法追加一些異常的測試用例
10.測試執行
概念：根據編寫的測試用例，按照用例步驟進行執行，查看預期結果和實際結果是否一致，如果不一致則為bug（缺陷）
參考依據：測試用例
執行人：軟件測試工程師
開始時間：測試用例編寫完成并通過評審，且達到測試執行的啟動條件
時間周期：占整個項目周期40% 左右時間
測試用例執行過程中時間安排，假設項目周期為三個月（66天），66*40%=26
測試執行分為3輪，時間安排如下：13:8:5-------------------->按照5:3:2的比例進行安排
測試執行分為4輪，時間安排如下：10:8:5:3------------------>按照4:3:2:1 的比例進行安排
10.1 測試用例的執行結果狀態
new(未執行)：用例編寫完成，未開始執行的狀態
pass（通過）：執行用例預期結果和實際結果一致
fail （失敗）：執行用例預期結果和實際結果不一致
block（阻塞）：當因為軟件有缺陷妨礙了測試用例的執行，并且該缺陷不是該用例的關注點
investigate （觀察中）：當用例在執行過程中需要消耗較多的時間來觀察期間的結果
10.2 測試執行過程中的注意事項
搭建軟件測試環境
測試用例需要全部執行
不要忽視任何偶現的bug
加強測試過程中的記錄
提交缺陷和開發關系處理恰當
提交一份優秀的問題報告單
及時更新測試用例
10.3 提交的缺陷開發不認可，怎么處理？
1.首先進行自我檢查，依據需求確定該缺陷是否有問題
2.確定是問題，拿出依據與開發人員有理有據的溝通
3.溝通無效，告知測試經理，將問題升級提交項目組變更控制委員會CCB進行裁決是否是
問題
10.4 缺陷的分布特征
1.群集現象（二八定律）
2.測試進行的越多，新缺陷就越難發現，此時需要拓展測試思路，尋找新的突破點
3.并非所有的缺陷都需要修復
? 1.修復風險太大，不值得修復
? 2.沒有足夠的時間進行修復，并且遺留的bug不會影響版本發布新功能
10.5 測試過程中發現bug太多你會怎么處理？
1.冒煙測試進行的不充分，不徹底
2.發現bug越多的模塊，殘留的缺陷也越多，同時說明開發編碼質量太差，會影響到測試的質量
和效率
3.我們需要將版本打回，要求開發人員自測，自測通過后再提交代碼
10.6 幽靈（偶現）bug的處理方式？
1.截圖，保留證據，必要時錄制視頻，抓包，查看日志文件
2.在本機進行多次嘗試該問題，若能夠出現問題，則記錄
3.若本機不能重現，在其他電腦上嘗試重現是否能夠出現
4.在其他電腦上無法重現，但是問題比較嚴重，找到開發人員進行協助定位
5.對于難以重現的問題，需要將問題單掛起，看后續版本是否存在，后續版本如果不存在，則關
閉
10.7 缺陷的組成
缺陷ID，缺陷標題，缺陷狀態，缺陷級別，缺陷優先級，測試版本，測試階段，缺陷類型，重現步驟（缺陷描述），實際結果，預期結果，缺陷所屬模塊，提交人，提交時間，修改人，修改時間，關閉時間，附件
1.缺陷ID：缺陷編號，bug管理系統自動生成的編號
2.缺陷標題：對發現的bug通過簡潔的文字進行描述
3.缺陷的狀態
2.開發打開bug單，確認問題是否存在，bug狀態為 open（打開）
3.開發確認是bug，將bug修復完成后，bug狀態為fixed（修復）
4.開發給出依據確認不是bug，bug狀態為 rejected（拒絕）
5.測試回歸bug，驗證通過，bug狀態為 closed（關閉）
6.測試同意開發給出不是bug的依據，關閉問題單，bug狀態為 closed（關閉）
7.開發確認測試提交問題是問題，延遲解決，bug狀態為pending（掛起）
8.測試回歸bug，驗證不通過，bug狀態為 reopen（重新打開）
4.缺陷級別
致命：程序的主要功能喪失，閃退，崩潰，報5xx，如：無法注冊，無法登錄
? 嚴重：次要功能沒有實現，引發部分功能無法使用，如：無法刪除商品，無法新增商品，無法編輯商品
? 一般：基本功能實現，但是邊界值錯誤，或者某些重要功能異常情況錯誤
? 輕微：界面排版錯誤，系統操作不方便，但是可以使用
5.缺陷優先級：4,3,2,1
6.測試版本：即本次發布新功能的版本號
7.測試階段：
BVT（build verification testing）：冒煙測試
? SIT （system integration testing）：系統集成測試
? UAT（user acceptance testing）：用戶驗收測試
8.缺陷類型：
文檔缺陷：文檔不容易理解，文檔缺失，文檔描述錯誤
設計缺陷：主要指的是需求設計不合理
配置缺陷：軟件在安裝時出現的錯誤
界面錯誤：系統界面排版錯誤，界面文字錯誤
功能缺陷：需求規格說明書中要求的功能沒有實現
性能缺陷：業務處理性能低，查詢性能低，統計報表性能低
9.缺陷描述：又稱重現步驟，指導開發人員具體怎樣重現問題
10.實際結果：執行用例后得到的結果
11.預期結果：需求中期望得到的結果
12.bug所屬模塊：bug在哪個模塊下測試發現的
13.提交人：發現問題的軟件測試工程師
14.提交時間：發現問題的時間
15.修改人：缺陷修復對應的開發人員
16.修改時間：開發修改完bug的時間
17.關閉時間：軟件測試工程師關閉問題的時間
18.附件：主要是為了開發人員快速定位問題，提供分析問題的依據：如：截圖，視頻，抓包，日志文件
10.8 提單的5C原則
correct （準確） ：問題單中每個組成部分描述準確，不會引發誤解
clear （清晰） ：問題單中每個組成部分描述信息，易于理解
concise （簡潔） ：只包含必不可少的信息，不包含任何多余的信息
complete （完整） ：包含重現該缺陷的完整步驟
consistent （一致） ：按照一致的格式書寫全部的問題單
10.9 缺陷的生命周期
提交，確認，分配，修改，驗證，關閉
10.10 常用的bug管理工具
禪道（zentao），bugfree，QC，mantis，DTS（華為），TAPD（騰訊），jira…
11.配置庫管理工具
11.1 常用的配置庫管理工具
svn（subversion），git
11.2 svn使用
安裝和使用
連接服務器
上傳文件
下載文件
修改文件
查看文件
恢復刪除的文件
重新定位
給文件加鎖和解鎖
12.測試報告
概念：主要是對測試結果，測試過程中的質量和產品的質量進行度量，總結和描述
參考依據：測試計劃，測試用例執行結果，缺陷數量
負責人：測試組長和測試經理
時間：測試用例執行完成達到測試結束標準，時間為1-2天
評審人：組內軟件測試工程師，開發代表，產品經理，測試經理，項目經理，QA
測試報告的組成：
項目背景，測試目的，測試范圍，測試策略，測試環境，測試工具，人員組成，人力投入和工作量的數據統計,用例數，缺陷數，遺留問題，測試風險
測試用例的數據統計：
三個月項目測試用例在1200-1500左右
一個月迭代依次項目用例數在200 左右
缺陷數據統計：
三個月項目缺陷數在270-300 左右
一個月迭代項目數在80-100左右
測試時間安排：
假設項目第一個版本研發周期是3個月，大概可用工作日時間為66天
1.需求分析：10%-20%左右時間，如：10天
2.測試計劃：2-5天，如：3天
3.測試方案：1-2周，如5天
4.測試用例：30%左右時間，如：20天
5.測試執行：40%時間左右：如：26天
6.測試報告：1-2天時間：如：2天
項目組測試人員2名，人均每天編寫測試用例數35條/天左右
（35*2） * 20=1400條用例，總計bug數：300個左右，我發現了160個bug（體現自己的工作能力）
tips ：上面的數據只是合理范圍，不是寫死的
13.質量
13.1 質量的范圍
外部質量：明確的需求
內部質量：隱含的需求
使用質量：用戶在使用過程中對產品的質量進行評估
13.2 質量的三要素
技術、流程、組織
13.3 CMMI等級
CMMI：軟件能力成熟度模型綜合
初始級，受管理級，已定義級，定量管理級，持續優化級
13.4 質量的六大特性
功能性：適合性，準確性，互操作性，安全保密性，功能性的依從性
可靠性：成熟性，容錯性，易恢復性，可靠性的依從性
易用性：易理解性，易學性，易操作性，吸引性，易用性的依從性
效率：時間特性，資源利用性，效率的依從性
維護性：易分析性，易改變性，穩定性，易測試性，維護性的依從性
可移植性：適應性，易安裝，共存性，易替換性，可移植性的依從性
14.項目中的文檔
需求分析：用戶需求，產品需求，需求規格說明書
開發文檔：可行性分析，概要設計，詳細設計
測試文檔：需求分析，測試計劃，測試方案，測試用例，bug清單，測試報告
管理文檔：項目計劃，版本計劃
15.測試流程
1.產品經理進行需求調研，搜索用戶的需求，整理出一份文檔：需求規格說明書
2.產品經理組織開發和測試，召開需求講解會議，會議結束后，開發和測試均得到需求規格說明 書
3.開發和測試深入了解需求文檔，提出對需求文檔有疑問的地方
4.產品經理召開會議給測試和開發澄清需求
5.軟件測試工程師對自己負責的模塊進行需求分析，完成后組織測試內部人員和開發人員進 行評審
6.評審后根據評審意見修改需求分析文檔，測試經理開始編寫測試計劃，安排后期測試過程
中人力投入和各階段時間安排，測試計劃評審通過后
7.軟件測試工程師，開始編寫測試用例，完成后，進行評審
8.開發編碼完成后，從svn上獲取安裝包，搭建測試環境
9.軟件測試工程師開始執行冒煙測試，通過后，進行正式的測試執行，如果不通過版本打回
10.正式測試分為三輪，達到測試結束條件，終止測試
11.測試經理開始編寫測試報告，測試報告評審通過后，軟件提交預發布流程，審核通過后，開
始安排上線時間點
內部質量：隱含的需求
使用質量：用戶在使用過程中對產品的質量進行評估
13.2 質量的三要素
技術、流程、組織
13.3 CMMI等級
CMMI：軟件能力成熟度模型綜合
初始級，受管理級，已定義級，定量管理級，持續優化級
13.4 質量的六大特性
功能性：適合性，準確性，互操作性，安全保密性，功能性的依從性
可靠性：成熟性，容錯性，易恢復性，可靠性的依從性
易用性：易理解性，易學性，易操作性，吸引性，易用性的依從性
效率：時間特性，資源利用性，效率的依從性
維護性：易分析性，易改變性，穩定性，易測試性，維護性的依從性
可移植性：適應性，易安裝，共存性，易替換性，可移植性的依從性
14.項目中的文檔
需求分析：用戶需求，產品需求，需求規格說明書
開發文檔：可行性分析，概要設計，詳細設計
測試文檔：需求分析，測試計劃，測試方案，測試用例，bug清單，測試報告
管理文檔：項目計劃，版本計劃
15.測試流程
1.產品經理進行需求調研，搜索用戶的需求，整理出一份文檔：需求規格說明書
2.產品經理組織開發和測試，召開需求講解會議，會議結束后，開發和測試均得到需求規格說明 書
3.開發和測試深入了解需求文檔，提出對需求文檔有疑問的地方
4.產品經理召開會議給測試和開發澄清需求
5.軟件測試工程師對自己負責的模塊進行需求分析，完成后組織測試內部人員和開發人員進 行評審
6.評審后根據評審意見修改需求分析文檔，測試經理開始編寫測試計劃，安排后期測試過程
中人力投入和各階段時間安排，測試計劃評審通過后
7.軟件測試工程師，開始編寫測試用例，完成后，進行評審
8.開發編碼完成后，從svn上獲取安裝包，搭建測試環境
9.軟件測試工程師開始執行冒煙測試，通過后，進行正式的測試執行，如果不通過版本打回
10.正式測試分為三輪，達到測試結束條件，終止測試
11.測試經理開始編寫測試報告，測試報告評審通過后，軟件提交預發布流程，審核通過后，開
始安排上線時間點
12.上線后對主功能進行測試，成功上線后，開始進行下一輪迭代
總結
- 上一篇： java 模板转PDF(合同)详细讲解
- 下一篇： 钢构件建筑材料英国UKCA认证—EN 1