轉自：http://blog.51cto.com/xqtesting/2057574
1. 簡介
1.1 編寫目的
本文檔用於記錄測試過程，總結各輪次的測試情況，分析測試數據，歸納測試工作進行過程中暴露的問題與遺留的風險，給出相應的測試建議以供后續項目參考。
1.2 項目背景
xx需要一個擁有真實用戶的社區化產品，通過真實高信任度用戶關系的建立，提高用戶粘性，提升活躍會員數，帶來長效的增長。在此背景下，以真實用戶為基礎的社區應運而生。主要具有以下5點意義：
1. 提高社區活躍會員數
2. 提高用戶粘度
3. 建立真實（和用戶的社區身份相一致）的多維用戶信息
4. 建立高信任度的用戶關系
5. 達到真實可信用戶關系中的用戶之間的傳播效應
1.3 定義、首字母縮寫詞和縮略語
無
1.4 參考資料
各輪系統測試階段總結
2. 測試概要
整個xx項目的測試經歷了xx-1.0與xx-1.1兩個階段，共經歷了1輪集成測試、6輪冒煙測試和7輪系統測試和1輪上線跟蹤測試。整個測試過程中累計執行用例8100條，發現缺陷1026個。截至xx-1.1第四系統測試結束，所發現的高權重問題已得到修復和驗證。
2.1 測試時間
整個xx項目的測試時間從xx年2月18日開始，到xx年3月27日上線止，期間各階段工作情況如下：
| 工作階段 |
開始時間 |
結束時間 |
工作量 (人日) |
|
| xx-1.0 |
xx-1.0需求確認、評審、測試用例編寫&評審 |
2008年2月18日 |
2008年2月25日 |
30 |
| xx-1.0集成測試 |
2008年2月22日19：30 |
2008年2月23日 1：00 |
4 |
|
| xx-1.0第一輪系統測試之冒煙測試一 |
2008年2月26日 10：30 |
2008年2月26日 17：00 |
5 |
|
| xx-1.0第一輪系統測試之冒煙測試二 |
2008年2月29日 13：00 |
2008年2月29日 19：00 |
4.5 |
|
| xx-1.0第一輪系統測試之冒煙測試三 |
2008年3月3日 10：00 |
2008年3月3日 16：00 |
4.5 |
|
| xx-1.0第一輪系統測試 |
2008年3月5日 15：00 |
2008年3月8日 16：30 |
36 |
|
| xx-1.0第二輪系統測試 |
2008年3月10日 10：30 |
2008年3月11日 19：00 |
20 |
|
| xx-1.0第三輪系統測試 |
2008年3月11日 21：00 |
2008年3月11日 22：00 |
1 |
|
| xx-1.1 |
xx-1.1需求評審、測試用例編寫&評審 |
2008年3月12日 |
2008年3月17日 |
15 |
| xx-1.1第一輪系統測試之冒煙測試 |
2008年3月18日 10：00 |
2008年3月18日 15：30 |
4 |
|
| xx-1.1第一輪系統測試 |
2008年3月19日 10：00 |
2008年3月21日 18：00 |
20 |
|
| xx-1.1第二輪系統測試之冒煙測試 |
2008年3月22日 16：00 |
2008年3月22日 18：30 |
1.5 |
|
| xx-1.1第二輪系統測試 |
2008年3月22日 16：00 |
2008年3月24日 16：00 |
18 |
|
| xx-1.1第三輪系統測試 |
2008年3月25日 10：00 |
2008年3月25日 17：00 |
6.25 |
|
| xx-1.1第四輪系統測試 |
2008年3月25日 21：30 |
2008年3月26日 1：30 |
4 |
|
| xx-1.1上線跟蹤測試 |
2008年3月27日6:30 |
2008年3月27日12:00 |
4.5 |
|
| 合計 |
178 |
2.2 測試范圍
本次測試覆蓋的范圍包括：功能測試、兼容性測試、接口測試、數據遷移測試、性能測試、安全性測試和品質監控。以下分別對功能測試、兼容性測試、接口測試、數據遷移測試、性能測試和安全性測試進行說明。
功能測試
xx-1.1在xx-1.0基礎上更新的主要功能如下：
| No. |
模塊 |
權重 |
| 1 |
通行證注冊、登錄，及個人社區產品的開通 |
A |
| 2 |
系統消息 |
A |
| 3 |
訂閱 |
A |
| 4 |
即時聊天 |
B |
| 5 |
名片 |
B |
| 6 |
更新提示 |
B |
| 7 |
Feed改造 |
B |
| 8 |
UIC 改造 |
B |
| 9 |
報錯頁 |
B |
| 10 |
xx-1.0遺留到xx-1.1的缺陷 |
C |
| 11 |
各個產品針對xx-1.1的改造 |
C |
xx-1.0 包括的主要功能如下：
| No. |
模塊 |
權重 |
| 1 |
登錄注冊開通 |
C |
| 2 |
導航 |
C |
| 3 |
Profile |
A |
| 4 |
Account帳戶管理 |
B |
| 5 |
Privac隱私設置 |
B |
| 6 |
Feed |
A |
| 7 |
個人資料 |
B |
| 8 |
Space-q |
B |
| 9 |
Space-bbs |
B |
| 10 |
Space-bar |
B |
| 11 |
Firend好友 |
A |
| 12 |
Vistor訪客 |
A |
| 13 |
紙條箱 |
A |
| 14 |
留言 |
A |
| 15 |
UIC（頭像、昵稱） |
A |
| 16 |
幫助 |
C |
| 17 |
各個產品針對xx-1.0的改造 |
C |
數據遷移測試
| No. |
關注項 |
權重 |
| 1 |
博客播客相冊圈子論壇與Space的用戶頭像切換 |
A |
| 2 |
博客老用戶訪客數據為Space的提供 |
A |
| 3 |
博客播客相冊圈子論壇老用戶好友數據與Space的整合 |
A |
| 4 |
博客播客相冊圈子論壇老用戶紙條箱數據與Space的整合 |
A |
| 5 |
圈子老用戶個人資料數據與Space的整合 |
A |
| 6 |
博客播客圈子老用戶留言數據與Space的整合 |
A |
接口測試
| No. |
關注項 |
權重 |
| 1 |
各產品與Space的feed功能的接口測試 |
A |
兼容性測試
| No. |
關注項 |
權重 |
| 1 |
IE6 |
A |
| 2 |
IE7 |
B |
| 3 |
Firefox2.0 |
C |
性能測試
參見SVN中的性能測試報告。
安全性測試
整個xx測試過程中先后進行了三輪安全性測試，發現了2個影響較嚴重的安全性問題，且都已得到修復和驗證。
2.3 測試版本
下表顯示了各輪次測試版本和對應測試范圍的分配情況：
2.4 測試用例
根據需求文檔，測試人員編寫和內審了測試用例，為xx項目共計編寫用例3558條，累計執行用例8100條。
2.5 測試策略
xx-1.0測試策略
1. 測試類型：按階段划分定義為集成測試和系統測試。
2. 集成測試階段進行了一輪集成測試，主要以需求挖掘、分析、確認和尋找實現與需求不一致為主要目標
3. 系統測試階段分三輪進行，基本策略如下：
第一輪為覆蓋性測試，測試范圍覆蓋以上描述的所有范圍，關注所有級別的bug；
第二輪對權重為A、B的模塊進行功能測試、兼容性測試，權重為C的模塊進行冒煙測試，回歸測試所有已修復的bug；
第三輪對權重為A的模塊進行功能測試、兼容性測試，對權重為B、C的模塊進行冒煙測試，回歸測試所有待解決的bug，及已關閉的高優先級bug。
每輪測試開始前都進行快速的冒煙測試，通過冒煙確信系統可測時進入下一輪系統測試。
數據遷移測試、接口測試只在第一輪進行。
4. 缺陷評估：每輪測試結束后都組織開發工程師、測試工程師、產品工程師等共同評估產品缺陷，評估內容包括缺陷解決方案、是否涉及需求變更、下一輪開始時間及是否可以結束測試等。
xx-1.1測試策略
1. 測試類型：按階段划分定義為系統測試。
2. 系統測試分四個輪次進行，基本策略如下：
第一輪為覆蓋性測試，測試范圍覆蓋以上描述的所有范圍，關注所有級別的bug；
第二輪對權重為A、B的模塊進行功能測試、兼容性測試，權重為C的模塊進行冒煙測試，回歸測試所有已修復的bug；對系統進行性能測試。
第三、四輪對權重為A的模塊進行功能測試、兼容性測試，對權重為B、C的模塊進行冒煙測試，回歸測試所有待解決的bug，及已關閉的高優先級bug；
每輪測試開始前都進行快速的冒煙測試，通過冒煙確信系統可測時進入下一輪系統測試。
數據遷移測試、接口測試只在第一輪進行。
3. 缺陷評估：每輪測試結束后都組織開發工程師、測試工程師、產品工程師、QA等共同評估產品缺陷，評估內容包括缺陷解決方案、是否涉及需求變更、下一輪開始時間及是否可以結束測試等。
3. 結果分析
整個xx測試過程中累計發現有效缺陷1026個，其中A級缺陷3個，B級21個，C級800個，D級169個，E級33個。經項目組成員評估，到xx-1.1發布止遺留缺陷51個，其余975個缺陷均已修復且全部驗證通過。下面分別從xx-1.0和xx-1.1兩個階段、從不同角度對缺陷進行分析。
3.1 缺陷趨勢
xx-1.0
整個測試過程中累計發現缺陷734個，各輪次缺陷分布情況如下表。
下圖顯示了xx-1.0測試過程中缺陷的發展趨勢：
xx-1.1
整個測試過程中累計發現缺陷292個，各輪次缺陷分布情況如下表。
下圖顯示了xx-1.1測試過程中缺陷的發展趨勢：
從缺陷趨勢圖中可以看出，xx-1.0和xx-1.1兩個測試階段，缺陷均隨着測試過程的推進呈現收斂趨勢，這符合測試缺陷的發展規律，證明測試計划和策略是可靠有效的。
3.2 缺陷優先級分布
xx-1.0
每輪次各級別缺陷分布情況如下：
xx-1.1
每輪次各級別缺陷分布情況如下：
整個xx項目測試過程種中發現的C級以上（包括C級）缺陷824個，占總缺陷數的80.31%，這說明系統在測試過程中處於不穩定狀態，存在大量較為嚴重的問題，但隨着測試過程的推進，高優先級問題又逐漸減少，整個系統趨於穩定。
3.3 缺陷按模塊分布
下表顯示了整個xx測試過程中發現缺陷在各模塊中的分布情況
| 模塊 |
缺陷數 |
% |
| 需求0221 |
223 |
21.73% |
| 好友 |
101 |
9.84% |
| 個人資料 |
75 |
7.31% |
| Feed |
74 |
7.21% |
| 登錄 注冊 開通 |
61 |
5.95% |
| Space-blog |
54 |
5.26% |
| 紙條 |
53 |
5.17% |
| Space-q |
52 |
5.07% |
| 帳戶管理 |
38 |
3.70% |
| Space-bbs |
35 |
3.41% |
| Space-gallery |
31 |
3.02% |
| UIC |
31 |
3.02% |
| 留言 |
31 |
3.02% |
| Space-bar |
25 |
2.44% |
| 系統消息 |
25 |
2.44% |
| 其它 |
21 |
2.05% |
| Space-vblog |
20 |
1.95% |
| 名片 |
17 |
1.66% |
| 訂閱 |
17 |
1.66% |
| 訪客 |
15 |
1.46% |
| 導航 |
11 |
1.07% |
| 隱私設置 |
10 |
0.97% |
| Space管理后台 |
4 |
0.39% |
| 安全 |
2 |
0.19% |
| 合計 |
1026 |
從下圖中可以看出各模塊缺陷的分布趨勢：
從以上缺陷分布情況看，所有缺陷中有近30%是和產品需求相關的，諸如需求定義欠明確、需求描述有歧義、需求沒有定義、實現和需求不一致等。
3.4 重開缺陷情況
從上表可以看出整個Space測試過程中，各輪驗證缺陷的重開比率都偏高，這是我們后續項目中需要關注和提高的地方。
3.5 遺留缺陷情況
到xx-1.1發布止，整個Space項目遺留缺陷51個，且這些缺陷均通過PDT相關成員評估后確信可以遺留，待后續版本規划處理。具體缺陷信息此處略去。
3.6 上線跟蹤測試結果
xx-1.1於3月27日7:00上線后，我們在當日的7:00-12:00進行了集中跟蹤測試，且在此之后安排有2名測試工程師，每天用一些時間跟蹤上線情況、客服反饋問題的最新動態。截止4月2日上午11:00上線跟蹤測試結果是：累計缺陷40個，且都是C級以下。其中屬需求相關問題5個，因上線后環境差異導致問題35個，開放中缺陷4個，已關閉缺陷16個，已解決待驗證缺陷20個。
4. 結論&問題&建議
4.1 測試結論
1. 經過前后兩個階段的多輪測試，雖遺留了一些缺陷沒有解決，但系統功能已趨於穩定，且項目確定的范圍、策略和計划均已實現，項目測試可以結束、xx-1.1可以上線。
2. 通過測試覺得產品在用戶體驗方面有待后續版本進一步改進，不排除用戶在使用該產品時有“暈”的感覺。
4.2 呈現的問題
1. 需求問題。特別是xx-1.0項目需求，雖然陸續看到了好多需求文檔，但這些文檔給人的感覺是：需求分析不完整、需求描述不清晰，需求文檔的邏輯性、可讀性、可實現性、可測試性比較差，需求的歧義性較大。從而感覺在整個xx-1.0測試過程中不斷地在挖掘需求、確認需求、變更需求和評審需求。xx-1.1的項目需求有了很大改觀，xx本身需求經過和收集、分析、確認和評審的過程，但對各接口產品的需求仍然沒有進行統一的分析、確認和評審，這部分需求的歧義性較大且變更較多，整個需求文檔的可讀性、可測試性、完整性和清晰性仍然較差。
2. 變更控制問題。這在xx-1.0的測試過程中體現的比較明顯，如項目需求的變更、項目責任人的變更、項目計划的變更等。xx-1.0整個測試過程中一直在確認和變更需求，且需求變更的機制沒有規約，一個會議、一封mail或是一個口頭傳達就可能變更需求。xx-1.1測試過程中這一問題得到了較好的改進，但變更控制規約的實施欠佳。所有的需求變更均沒有及時很好的更新至需求文檔，xx-1.0體現的更為明顯。
3. 版本控制問題。xx-1.0測試過程中沒能進行版本管理；xx-1.1測試過程中對xx本身的代碼進行了版本管理，各接口產品的代碼均由各技術負責人進行管理，在這期間出現過代碼覆蓋的情況、代碼忘記上傳或遺漏部署的情況。難以保證每輪測試版本的清晰、和發布版本與測試版本的一致性。
4. 測試環境問題。xx-1.1測試期間測試環境和開發環境沒能很好的分離，導致測試和開發修復缺陷不能並行；測試期間有開發工程師直接在測試環境上修復缺陷和修改測試環境的情況；測試環境不穩定，如hosts設置不正確等。
5. 項目計划欠明確、人員職責欠清晰。
4.3 測試建議
1. 遺留缺陷。建議在xx-1.1上線后以patch方式，或在后續版本中解決遺留缺陷，以提升產品的穩定性和用戶體驗。
2. 需求建議。不論是xx本身還是各接口產品，建議進一步加強需求收集、分析、確認和評審過程，進一步提升需求文檔的質量：減少需求的歧義性，提升需求的完整性、描述的清晰性、一致性、可讀性、可實現性和可測試性。同時建議在后續項目中能對設計文檔（如UI/UE等）進行評審，以增強產品的使用性、提升用戶體驗。
3. 變更控制。建議在后續項目中進一步加強變更控制策略和規約制定，並強化變更控制規約的執行。不怕變更，關鍵要控制好變更的時機和策略。
4. 版本控制。加強xx本身，特別是各接口產品的版本控制策略，以保證測試版本的清晰性、發布/上線版本和最終測試版本的一致性。
5. 測試環境。期望在后續項目中xx及各接口產品的測試環境和開發環境完全分開，或階段性完全獨立，且各部分環境有專門的接口人負責，在測試期間嚴格禁止在測試環境上修復缺陷或更改環境配置（如確實需要更改配置，請提前通知測試及其它相關負責人）。以減少因此帶來的溝通、反復偵測的成本。
6. 項目管理。主要是建議加強項目的計划性，諸如：進度計划、人力資源計划、風險預防機制等，這也將更利於項目成員間高效的配合：大家能更適時的、更合理的制定各自工作計划，也更清楚到什么時候我會輸出什么、我將配合他人做些什么。減少項目進行過程中的緊張和慌亂、項目也變得更加易控和可控。