1.1 編寫目的web
本文檔用於記錄測試過程,總結各輪次的測試狀況,分析測試數據,概括測試工做進行過程當中暴露的問題與遺留的風險,給出相應的測試建議以供後續項目參考。安全
1.2 項目背景ide
xx須要一個擁有真實用戶的社區化產品,經過真實高信任度用戶關係的創建,提升用戶粘性,提高活躍會員數,帶來長效的增加。在此背景下,以真實用戶爲基礎的社區應運而生。主要具備如下5點意義:性能
1. 提升社區活躍會員數測試
2. 提升用戶粘度spa
3. 創建真實(和用戶的社區身份相一致)的多維用戶信息設計
4. 創建高信任度的用戶關係3d
5. 達到真實可信用戶關係中的用戶之間的傳播效應版本控制
1.3 定義、首字母縮寫詞和縮略語orm
無
1.4 參考資料
各輪系統測試階段總結
整個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;對系統進行性能測試。
第3、四輪對權重爲A的模塊進行功能測試、兼容性測試,對權重爲B、C的模塊進行冒煙測試,迴歸測試全部待解決的bug,及已關閉的高優先級bug;
每輪測試開始前都進行快速的冒煙測試,經過冒煙確信系統可測時進入下一輪系統測試。
數據遷移測試、接口測試只在第一輪進行。
3. 缺陷評估:每輪測試結束後都組織開發工程師、測試工程師、產品工程師、QA等共同評估產品缺陷,評估內容包括缺陷解決方案、是否涉及需求變動、下一輪開始時間及是否能夠結束測試等。
整個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.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. 項目管理。主要是建議增強項目的計劃性,諸如:進度計劃、人力資源計劃、風險預防機制等,這也將更利於項目成員間高效的配合:你們能更適時的、更合理的制定各自工做計劃,也更清楚到何時我會輸出什麼、我將配合他人作些什麼。減小項目進行過程當中的緊張和慌亂、項目也變得更加易控和可控。