軟件測試經驗交流PPT_第1頁
軟件測試經驗交流PPT_第2頁
軟件測試經驗交流PPT_第3頁
軟件測試經驗交流PPT_第4頁
軟件測試經驗交流PPT_第5頁
已閱讀5頁,還剩26頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、軟件測試經驗交流,1,概述,測試前的準備工作 軟件測試的測試策略及思路 測試中容易出現的故障及易忽略之處 經驗交流 測試工程師應具備的素質,2,測試前的準備工作,了解項目當前的狀態(tài)信息。 1. 拿到樣機后測試人員首先應了解該項目目前所處的狀態(tài),是研發(fā)?中試?還是量廠階段? 2. 新項目還是衍生項目? 3.了解項目平臺信息,是全新平臺還是變形項目平臺? 4.了解屏、sensor等一些關鍵元件信息及檢查樣機是否完整? (往往有些問題會因為手機元器件不對或是配置不對而造成重啟,死機等現象。如屏不對會導致白屏,Camera sensor不對會導致進入相機拍照死機等現象。所以測試前樣機的檢查也很重要,測

2、試人員在測試前要對樣機進行硬件上的檢查,如發(fā)現提供的樣機不對要及時提出來。) 5.軟件版本號的檢查。 (需要注意的是:*#159#中版本號檢查應該是外部版本號,而不是內部版本號。另外同一個項目,其主要區(qū)別是更換屏,這時檢查版本號時注意有無區(qū)分出來),3,軟件測試的測試策略及思路,軟件測試的測試策略。 1. 研發(fā)階段的新平臺項目由于軟件功能還不穩(wěn)定這時我們第一步要做的是對新增功能模塊進行基本功能的檢查,其次對用戶常用的功能模塊進行深入測試(如電話簿,短信息,撥號,鬧鐘等模塊),最后再對其它功能模塊進行檢查。 2. 衍生的項目,在V1.0版本測試時務必要對改動的模塊進行詳細測試,如滑蓋或翻蓋項目衍

3、生到直板機的項目,這時我們首要要從兩者不同點下手。 (如滑蓋或翻蓋項目不支持鍵盤鎖,那這時衍生到直板機的項目鍵盤鎖功能有沒有加上) 3. 量廠項目的測試,如只改動圖片或某個問題的改動。這時我們首先要根據版本說明書進行回歸測試,即從改動點進行測試,驗證有無新改出來的Bug,完成后再根據軟件功能檢查表依依測試。,4,軟件測試的測試策略及思路,軟件測試的測試思路。 1.從用戶的角度對手機軟件各功能模塊進行基本功能測試。 (用戶用的最多的就是打電話,電話簿,信息,充電,鬧鐘及MP3等,測試人員要詳細,認真的檢查每個功能模塊,用戶常用的功能模塊需多花點時間) 2. 基本功能測試完畢后,再對各功能模塊進行

4、突發(fā)事件的測試。當然所謂的突發(fā)事件就是用戶在執(zhí)行某操作時插入另一事件,如來電話,插耳機,充電器,鬧鐘提示等; (由于突發(fā)事件測試涉及的工作量大,測試時所先考慮到是用戶常會遇到的突發(fā)事件測試,常用功能模塊中遇到突發(fā)事件最多了。如編輯信息的時候,聽MP3的時候,照相的時候等都是最有可能導致問題了,像一些短暫操作,如文件刪除中,復制中,移動中等功能模塊的突發(fā)事件測試用戶遇到的機率會比較低,如果時間允許的情況下,也需要進行測試) 3.極端測試。即用戶很少會遇到,也很少會去操作的角度來測試; (如拍照過程中和恢復原廠設置過程中連續(xù)插拔耳機,對文件管理菜單在PC上格式化,之后再拷貝些文件開機,通話過程中聊

5、天,保存號碼以及未插SIM卡狀態(tài)下等功能模塊的操作)。 4.模塊之間交叉進行測試。 (如通話記錄,電話簿及短消息等相關聯模塊),5,各功能模塊容易出現故障及忽略之處,電話簿 電話簿模塊是用戶最常用的模塊,測試時必需要慎密,多花點時間。下面簡要列舉了幾點電話簿模塊中曾出現過的典型問題,也是容易被忽視的問題: 1.字符串顯示,如電話簿的“簿”是否寫錯,寫成“薄”; (另外還包括菜單中各字符串的顯示,測試人員應仔細檢查,不要一眼帶過) 2.電話簿列表中#鍵切換輸入法,查看輸入法的顯示; 3.電話簿列表中單一刪除,直接刪除到空白,這時驗證恢復原廠設置功能; (以前有遇到過進入電話簿列表單一刪除電話號碼

6、到最后一個時,進入恢復原廠設置時發(fā)現該功能不能使用且花屏現象。這個操作就是屬于模塊交叉測試) 4.通話中進入電話簿菜單,對電話簿進行操作,(如播放影片,新增或刪除號碼等操作) 5.到通話記錄中或短信息列表中提示號碼保存,保存號碼時注意進行加入影片,大頭貼等功能操作測試; (以前有遇到在網絡攝相頭聊天畫面收到信息后,這時提示信息號碼并加入影片,播放影片時手機重啟,該問題也是平臺性問題),6,各功能模塊容易出現故障及忽略之處,電話簿 6.切換各種主題,查看電話簿記錄字體顯示; (如有此主題顯示的字休很淡會導致電話簿記錄很模糊,看不清) 7.電話簿中保存超長號碼或空號碼進行發(fā)送信息,或多方發(fā)送信息時

7、全部選擇電話簿中超長號碼,手機不會有任何提示,一直處于發(fā)送中; 8. 將電話簿容量保存滿的情況下,手機開關機后查看號碼是否丟失,開機在找網時到通話記錄中保存號碼是否仍能保存到電話簿中; 9. 電話簿批量操作比較容易引發(fā)手機重啟; 10. 電話簿列表中的號碼來電話,來信息,有時手機會出現號碼混亂現象,如A號碼來電或來信息,進入通話記錄中查看發(fā)現號碼顯示不對或號碼前多了+86;,7,各功能模塊容易出現故障及忽略之處,信息 1. 短信中心號碼或彩信中心網址被更改的情況下,手機進行發(fā)信息; (如:短信中心號碼更改后發(fā)信息,手機會一直處理發(fā)送中,這時本機收到信息,進行查看時手機會提示“短信功能無法使用”

8、 2.開機后馬上進入短信息選擇語音信箱菜單手機會提示亂碼或者開機后馬上發(fā)送信息能發(fā)出去嗎? 3.發(fā)送信息時直接到電話簿中查看到號碼,這時不發(fā)送直接按掛機鍵退出,手機能退出嗎?如退出后再進入信息菜單能正常使用嗎? 4. 手機恢復原廠設置后進入信息菜單發(fā)送彩信,手機一直提示“發(fā)送失敗”; 5.信息編輯畫面兩種輸入法切換導致問題; (如當前默認的拼音輸入法編輯內容后,再#鍵切換字母輸入法編輯內容,發(fā)現之前編輯的信息內容會消失) 6.剛開機就馬上進入信息編輯畫面編輯內容,查看輸入法是否與實際顯示的默認輸入法一致,如顯示的是T9輸入法,但是編輯過程中會出現拼音輸入法 7.通話中進入信息菜單,注意左右功能

9、鍵切換不能進入到其它菜單,否則當進入到文件管理菜單選擇影片等手機會死機;,8,各功能模塊容易出現故障及忽略之處,信息 8.短消息模板中英文內容是否一致? 9.閱讀信息內容畫面左右方向鍵依次切換不同信息閱讀,手機容易引發(fā)重啟現象; 10.收件箱列表畫面,移動光標到發(fā)件箱,當前發(fā)件箱為空,OK功能是否屏蔽掉,如果沒屏蔽掉的話會,當收件箱,發(fā)件箱,草稿箱都為空的情問下,OK鍵會引發(fā)信息功能無法使用; 11.信息存滿的情況下手機信息顯示是否正常?(這點很容易被忽視) 12.MP3鈴聲設為信息鈴聲,開啟信息報告,注意信息報告鈴聲應同信息鈴聲一樣,而不是一直播放MP3;,9,各功能模塊容易出現故障及忽略之

10、處,通話記錄 通話記錄模塊出現的問題不是很多,往往用戶最常用的就是到通話記錄列表中選擇號碼發(fā)送信息或是打電話。MTK手機也曾出現過有關于通記錄中發(fā)送信息時造成的嚴重問題,所以測試該模塊時除測基本功能外,還要進行跟通話記錄模塊相關聯的模塊進行交叉點測試;下面列舉幾個以往在測試通話記錄中發(fā)現的幾個嚴重Bug,希望大家在以后的新項目中能夠從中吸取些測試方法; 1. 到未接電話,已接電話記錄中選擇號碼發(fā)送信息,手機總是默認發(fā)送給已撥電話記錄中的第一個號碼. 2.通話記錄中如有超長號碼,選擇超長號碼發(fā)送信息發(fā)現手機黑屏重啟; 3.進入收件箱列表中選擇一信息讀取后提取號碼“撥號”,發(fā)現撥打的號碼錯誤,不是

11、當前提取的號碼,而是通話記錄中已撥電話記錄中的號碼; 以上列舉的三個嚴重問題都是跟信息有關,所以在測試該模塊時一定要多交叉測相關模塊,如短信息,電話簿等菜單。另外通話設置中的IP撥號,黑名單設置跟通話記錄也有一定的關聯;,10,各功能模塊容易出現故障及忽略之處,情景模式 情境模式模塊問題點一般在靜音模式下出現的比較多,如: 靜音模式下插拔耳機,耳機圖標不消失,進入菜單查看仍顯示耳機模式; 靜音模式下插拔耳機后再恢復原廠設置,#鍵切換不能回到一般模式; 靜音模式下進行五連拍拍照無顯示,及玩游戲過程重啟等; 未插SIM卡狀態(tài)的情境模式菜單,也千萬別忽略! 此時MP3模塊,文件管理模塊及情境模式都有

12、相互間的關聯,可交叉測試!,11,經驗交流,有效溝通和總結測試中遇到的問題 1.為什么要進行溝通和總結? 與相關的測試人員溝通可以改進自己的測試方法并且使自己的測試思維得到拓展; 與開發(fā)人員進行溝通可以加深自己對軟件理解的深度,并從中找到一些測試思路 舉例:關于支持MP3播放的音樂文件格式、FT終測時撥號容易呼叫外網等,12,經驗交流,針對一些重點難點模塊加強測試 1.測試一段時間后,對整個軟件模塊以及特點要非常熟悉,并劃分出軟件的幾個重點模塊進行加強測試如:手機在“通話、電話本、短消息、待機電流等”幾個菜單需要重點測試,因為這幾個模塊是用戶必用的功能菜單; 2.針對軟件中的新增模塊也需要加強

13、測試,往往一些異常重啟掉電等現象都可能由于這些模塊引起。 3.功能沖突、多事件干擾、鈴聲交錯、軟件的極限測試.,13,經驗交流,準確把握項目的進展情況、及時了解各方面的信息 1.通過郵件及會議的方式及時了解項目目前的進度以及狀態(tài)(何時需要量產版本、客戶需求、硬件結構目前存在的一些問題等等) 2. 軟件上的所有問題都要做到心中有數,并且在項目會議上告訴相關負責人目前軟件上存在哪些問題,哪些問題為重點或者難點.,14,經驗交流,1.手機進入中試階段 2.手機進入量產階段 3.客戶反饋問題的處理 4.項目經驗總結,15,中試階段,手機進入中試階段 1.手機進入中試的條件 必須滿足公司進入中試的原則,

14、無A類及5個以下B類問題,或者通過特批后進入量產階段; 2.手機中試階段應該注意的幾個問題 軟件版本的穩(wěn)定性是否能夠得到保證; CTA版本是否已經通過國家檢測標準; 手機小批量試產時出現的產線問題以及測試程式的 時間是否滿足大批量生產而不影響產能; 硬件結構等其他方面的問題;,16,量廠階段,手機進入量產階段 測試重點 優(yōu)先考慮版本的穩(wěn)定性、保證軟件測試全面性、嚴格按照測試流程測試(版本下載測試模擬產線測試上一版本FIX問題驗證執(zhí)行測試模板中所有選項檢查針對重難點模塊以及待觀察問題跟蹤模擬測試測試分析以及總結測試報告發(fā)布) 測試方法探討 1.執(zhí)行版本的全面測試,保證每個模塊都能被測試 2.針對

15、上一版本修改的問題做重點測試 3.跟蹤待觀察問題,盡可能找到規(guī)律,如果同一發(fā)現兩次以上,則升級問題等級 4.針對新發(fā)現的重大問題,相應模塊及功能應該重點測試 5.如果重大BUG或者多個待觀察問題時,應該在報告中及時提出預警,17,量廠后期,客戶反饋問題的處理 版本在進入量產階段,一般客戶都會做同步測試,并把測試中發(fā)現的BUG和他們認為需要修改的菜單模塊拿到測試部做一個反饋; 客戶發(fā)現的BUG,如果確實存在則需要做為BUG提出放到BugReport上面;如果提出的BUG為軟件設計很難更改的問題,則可以說明原因,建議不做修改 ; 及時把測試部的意見反饋到相應負責人手中,并適當的解釋原因。,18,項

16、目總結階段,項目經驗總結 項目到了最后收尾階段,這時測試人員應對自已負責的項目作個總結.項目周期內遇到過的重點問題或典型問題及測試過程中的遇到的困難都可以寫出來,這樣對以后的項目測試會有所幫助,可以從中吸取經驗.,19,經驗交流,針對新平臺項目如何開展軟件測試才能使工作效率達到最高、質量最好? 關于新平臺項目的測試流程、測試方法的探討?,20,經驗交流,測試流程圖,21,經驗交流,常用的功能測試方法 功能測試就是對產品的各功能進行驗證,首先要根據軟件部提供的立項申請表,產品定義書等 檢查產品是否達到用戶要求的功能。常用的測試方法如下: 1.頁面鏈接檢查:每一個鏈接是否都有對應的頁面,并且頁面之

17、間切換正確。 2. 相關性檢查:如刪除/增加各項會不會對其他項產生影響,如果產生影響,這些影響是否都正確。 3. 檢查按鈕功能是否正確:如update, cancel, delete, save等功能是否正確。 4. 字符串長度檢查: 輸入超出需求所說明的字符串長度的內容, 看系統是否檢查字符串長度,會不會出錯.,22,經驗交流,常用的功能測試方法 5. 字符類型檢查: 在應該輸入指定類型內容的地方輸入其他類型的內容(如在應該輸入整型的地方輸入其他字符類型),看系統是否檢查字符類型,會否報錯. 6. 標點符號檢查: 輸入內容包括各種標點符號,特別是空格,各種引號,回車鍵.系統處理是否正確. 7

18、.檢查帶出信息的完整性: 在查看信息和update信息時,查看所填寫的信息是不是全部帶出.,帶出信息和添加的是否一致(如保存的信息) 8.信息重復: 在一些需要命名,且名字應該唯一的信息輸入重復的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區(qū)分大小寫,以及在輸入內容的前后輸入空格,系統是否作出正確處理.,23,經驗交流,常用的功能測試方法 9. 檢查刪除功能:在一些可以一次刪除多個信息的地方,不選擇任何信息, 按”delete”,看系統如何處理,是否出錯; 10.檢查修改重名:修改時把不能重名的項改為已存在的內容,看會否處理,報錯同時也要注意,會不會報和自已重名的錯; 11. 重復提交

19、表單:一條已經成功提交的紀錄,back后再提交,看看系統是否作了處理; 12.檢查多次使用back鍵的情況, 在有back的地方,back,回到原來頁面,再back重復多次,看是否會出錯;,24,經驗交流,常用的功能測試方法 13. search檢查: 在有search功能的地方輸入系統存在和不存在的內容,看search結果是否正確.如果可以輸入多個search條件,可以同時添加合理和不合理的條件,看系統處理是否正確. 14.輸入信息位置: 注意在光標停留的地方輸入信息時,光標和所輸入的信息會否跳到別的地方. 15.上傳下載文件檢查:上傳下載文件的功能是否實現,上傳文件是否能打開。對上傳文件的

20、格式有何規(guī)定,系統是否有解釋信息,并檢查系統是否能夠做到。 16.必填項檢查:應該填寫的項沒有填寫時系統是否都做了處理,對必填項是否有提示信息,如在必填項前加* ;,25,測試工程師應具備的素質,一個好的測試工程師應具備的素質 1.溝通能力 一名理想的測試者必須能夠同測試涉及到的所有人進行溝通,具有與技術(開發(fā)者)和非技術人員(客戶,管理人員)的交流能力。既要可以和用戶談得來,又能同開發(fā)人員說得上話,不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統可以正確地處理什么和不可以處理什么上。而和開發(fā)者談相同的信息時,就必須將這些活重新組織以另一種方式表達出來,測試小組的成員必須能夠同等地同用戶和開發(fā)者溝通。 2.移情能力 和系統開發(fā)有關的所有人員都處在一種既關心又擔心的狀態(tài)之中。用戶擔心將來使用一個不符合自己要求的系統,開發(fā)者則擔心由于系統要求不正確而使他不得不重新開發(fā)整個系統,管理部門則擔心這個系統突然崩潰而使它的聲譽受損。測試者必須和每一類人打交道,因此需要測試小組的成員對他們每個人都具有足夠的理解和同情,具備了這種能力可以將測試人員與相關人員之間的沖突和對抗減少到最低程度。,26,測試工程師應具備的素質,一個好的測試工程師應具備的素質 3.自信心 開發(fā)者指責測

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論