速成測試接口達人測試流程.ppt

速成測試接口達人_測試流程的講座,研發(fā)部講師介紹： 姓名：方杰 部門：研發(fā)_業(yè)務保障部 2010年11月9日,通過此次培訓我能知道什么,與測試負責人溝通時，那些測試術語是什么含義？,測試開始前我需要做什么？,如何申請測試資源？如何在jira中提交測試任務單？,測試過程中哪些工作是我們測試接口人需要關注的事宜？,什么叫測試結束？測試結束后我們會從測試人員那里得到哪些數(shù)據(jù)？,測試結束后，還需要測試接口人做什么事情？,目錄,測試術語的定義,提交測試的相關流程,測試過程中測試接口人的相關管理之15大職能,不同分工的人員如何處理缺陷,缺陷產生原因定義及處理,重開缺陷的定義,缺陷等級的定義,線上遺漏缺陷表的填寫方法,測試項目管理案例分析,培訓總結,測試術語的定義,測試項目類型的定義 什么是冒煙測試 什么是回歸測試 什么是主功能測試 什么是兼容性測試 什么是安全性測試 什么是線上跟蹤測試 什么是常規(guī)測試、非常規(guī)測試,測試術語的定義,測試項目類型的定義,B/S（Web）功能測試,B/S（Browser/Server）結構即瀏覽器和服務器結構，B/S結構功能測試特指用黑盒的方法對Browser訪問的頁面實現(xiàn)的功能及兼容性進行的測試,C/S（Client）功能測試,C/S（Client/Server）結構即客戶機和服務器結構，C/S結構功能測試特指用黑盒的方法對客戶端實現(xiàn)的功能及兼容性進行的測試,測試術語的定義,測試項目類型的定義,接口功能測試 特指脫離頁面呈現(xiàn)，脫離頁面調用是否正確，直接測試接口功能的一種測試類型，測試的重點是要檢查數(shù)據(jù)的交換，傳遞的正確性。通常包括測試接口的參數(shù)檢查、接口的參數(shù)傳入及接口返回值是否正確，各接口間邏輯調用是否可以實現(xiàn)應用層功能 提交接口測試的重要意義：實現(xiàn)開發(fā)期并行測試，減少頁面層測試的深度，縮短整個項目的測試周期。目前的接口測試除API類均已使用自動化測試的方式執(zhí)行 4. 服務器功能測試 特指為前端客戶端或頁面提供后臺服務的服務器功能的測試，測試重點是要檢查服務器與前端或后端DB數(shù)據(jù)交換及傳遞是否正確，服務器異常處理，主、從服務器間切換，丟包率等,測試術語的定義,測試項目類型的定義,驗收測試 a、 B/S結構驗收測試 同B/S功能測試類似，只是測試范圍只是針對驗收規(guī)格說明書進行主功能測試，不涉及功能詳細測試及兼容性測試范疇 b、 C/S結構驗收測試 同C/S功能測試類似，只是測試范圍只是針對驗收規(guī)格說明書進行主功能測試，不涉及功能詳細測試及兼容性測試范疇 c、手機客戶端驗收測試 同C/S功能測試類似，只是測試范圍只是針對驗收規(guī)格說明書進行手機客戶端主功能測試，不涉及功能詳細測試及兼容性測試范疇，通常只在Symbian的一個主流操作系統(tǒng)上進行主功能測試,測試術語的定義,測試項目類型的定義,性能測試 分為負載測試、壓力測試、并發(fā)測試、疲勞強度測試4種測試類型 負載測試 定義：指通過逐步增加系統(tǒng)負載，測試系統(tǒng)性能的變化，并最終確定在滿足系統(tǒng)的性能指標情況下，系統(tǒng)所能夠承受的最大負載量 目標：確定系統(tǒng)處理能力的極限 壓力測試 定義：指通過逐步增加系統(tǒng)負載，測試系統(tǒng)性能的變化，并最終確定在什么壓力條件下系統(tǒng)性能處于失效狀態(tài)，由此獲得系統(tǒng)能夠提供的最大服務級別 目標：發(fā)現(xiàn)在什么條件下應用系統(tǒng)的性能會變得不可接受,測試術語的定義,性能測試的相關定義,并發(fā)測試 定義：并發(fā)測試指測試多個用戶同時訪問同一個應用、同一個模塊或者操作數(shù)據(jù)記錄時的性能 目標：考察系統(tǒng)在多用戶訪問時的性能狀況 疲勞強度測試 定義：疲勞強度測試是指在保證總業(yè)務量的情況下長時間運行系統(tǒng)的測試。屬可靠性測試范疇 目標：通過綜合分析交易執(zhí)行指標和監(jiān)控資源指標來測試系統(tǒng)長時間無故障穩(wěn)定運行的能力,測試術語的定義,什么是主功能測試,什么是冒煙測試,什么是回歸測試,使用較短的時間，對提交測試的產品進行測試，確認產品的基本功能正常，可以進行后續(xù)的正式測試工作。這種測試強調功能的覆蓋率，而不對功能處理細節(jié)的正確性進行驗證,在軟件測試周期中，如果代碼改變就需要進行回歸測試，回歸測試分為兩類，一個是對已修正缺陷的回歸測試，一個是主功能的回歸測試，是一種再確認的重復測試工作,特指針對產品需求說明書上描述的所有新增、變更功能和產品未變更功能的基本驗證，不做深入測試,測試術語的定義,什么是線上跟蹤測試,什么是兼容性測試,什么是安全性測試,B/S兼容性測試 驗證多瀏覽器下的頁面功能是否正常，通常頁面的CSS、JS、flash版本會影響到頁面的兼容性 C/S兼容性測試 驗證多操作系統(tǒng)下客戶端軟件功能是否正常,特指為產品進行安全方面的測試，例如是否暴露用戶個人私密信息、是否有被盜號的可能、是否會被黑客利用破壞用戶利益，是否有損壞DB及服務的不安全漏洞,特指產品經(jīng)過測試并上線后，在線上環(huán)境進行的主功能測試,測試術語的定義,什么是常規(guī)測試,什么是非常規(guī)測試,進行3輪測試，第1輪、第2輪進行全部測試用例的遍歷和已修正缺陷的回歸，并在第2輪測試完成時進行兼容性測試，第3輪進行所有已修正缺陷的回歸測試及主功能測試 此測試方案對于項目質量來講最有保障，是測試團隊建議使用的一種測試方案,進行少于3輪或多于3輪的測試 此測試方案適用于上線時間緊迫、線上測試類項目、測試過程版本出現(xiàn)重大問題需要增加測試輪次提高產品質量的項目,測試的相關流程,項目立項階段 項目測試開始階段 項目測試準備階段 測試執(zhí)行階段 測試完成階段,測試的相關流程,項目立項階段,測試的相關流程,項目測試開始階段,測試的相關流程,項目測試準備階段,測試的相關流程,測試執(zhí)行階段,測試的相關流程,測試完成階段,測試過程中測試接口人的 相關管理之15大職能,提前申請測試資源，發(fā)送項目立項郵件 在jira中提交測試任務單 參與需求評審會，并按照會議內容補充需求 參與測試計劃及用例評審 得到冒煙測試用例后，督促產品部涉及測試職能的員工及時完成冒煙測試工作（目前此職能為產品部特有職能） 測試過程中需求變更后及時更新需求并上傳到SVN，郵件通知開發(fā)、測試負責人需求變更 測試接口人及時分配缺陷給相應的開發(fā)處理缺陷，對于延遲及放棄處理的缺陷及時注釋延遲和放棄的原因并修改缺陷處理的狀態(tài),測試過程中測試接口人的 相關管理之15大職能,督促并檢查開發(fā)工程師在解決缺陷時，是否在jira中正確標注了缺陷產生原因（如果選擇其他原因，請在其他原因下方的注釋框中添加缺陷造成的具體原因，如果有可選原因，應盡量避免選擇其他） 測試過程中，關注每日的測試日報及風險預警，測試階段啟動郵件，確認開發(fā)修改缺陷完成點，及時與測試負責人溝通測試進度，協(xié)助測試負責人把控項目測試進度 測試過程中督促產品部涉及測試職能的工程師按期完成非測試部門完成的測試任務 測試各階段完成時，與測試負責人一起參與Bug評審會議，嚴格控制延遲和放棄缺陷的比例，共同提高被測產品質量,測試過程中測試接口人的 相關管理之15大職能,根據(jù)測試報告，分析項目風險，提出規(guī)避風險的解決方案，并確認產品是否上線 如果項目進行了安全測試，請將安全測試報告及時反饋給開發(fā)負責人，確認是否修改 如果項目進行上線跟蹤測試，請在上線前將欲上線時間點郵件發(fā)給測試負責人，并在上線完成時立刻電話通知測試負責人及時進行線上跟蹤測試 項目完成后請收集測試遺漏缺陷，并統(tǒng)計到遺漏缺陷記錄表中,測試過程中測試接口人的 相關管理之15大職能,如何在jira中建立測試任務單 提交方式：請在jira中如下地址提交測試項目申請 類別 : 研發(fā)-質量保證 項目 : 研發(fā)-質保-提交測試任務庫 (TOTEST) /browse/TOTEST 實際操作演練 如何提交B/S測試 如何提交C/S測試,不同分工人員如何處理缺陷,不同分工的測試接口人如何處理缺陷,開發(fā)人員 a、將分配給自己的缺陷進行修正，處理缺陷為已修正狀態(tài) b、將建議延遲或放棄處理的缺陷分配給項目負責人確認是否同意延遲或放棄處理，本人不能更改Bug為延遲或放棄 c、將全部分配給自己的缺陷在jira中選擇缺陷產生原因 產品人員、項目負責人、項目經(jīng)理 a、將測試人員提交的欲修改的缺陷分配給對應的開發(fā)人員并注釋修改的方案 b、將確認延遲或放棄的缺陷及時解決為延期或放棄，并注釋延遲或放棄處理的原因。解決延遲處理的缺陷時請務必選擇本項目直接延遲處理或本項目間接延遲處理 c、檢查項目中所有的缺陷是否均已經(jīng)選擇了缺陷產生的原因，如果沒有選擇請分配給開發(fā)重新選擇 備注：除測試人員外，其他不能自行關閉缺陷,缺陷產生原因定義及處理,缺陷產生原因的一級分類 缺陷產生原因的二級分類 在jira中進行缺陷產生原因的選擇方法,缺陷產生原因定義及處理,缺陷產生原因的一級分類,環(huán)境：如測試環(huán)境不穩(wěn)定：特指上傳新版本時沒有更新修改過的文件或者測試過程中有人動了測試環(huán)境的代碼；需要提交測試的文件未更新完整 需求：如需求變更未及時通知開發(fā)及測試 代碼錯誤：如代碼循環(huán)錯誤 兼容性類錯誤：如對IE8瀏覽器未做處理 程序實現(xiàn)間接類錯誤：如外部門提供的接口或其它服務不穩(wěn)定 其他原因（選擇此項時，請在其他原因下方的注釋框中填寫具體原因，如果可以選擇到對應的原因，應避免選擇其他原因）,缺陷產生原因的二級分類 詳見項目名稱缺陷造成的原因分析表.xlsx,缺陷產生原因定義及處理,在jira中進行缺陷產生原因的選擇方法 進入本項目缺陷庫 選擇本項目缺陷庫中未解決缺陷 修改缺陷狀態(tài)為延遲、放棄或已修正狀態(tài)時，選擇缺陷產生原因（not a bug的無需選擇，其他狀態(tài)均需選擇缺陷產生原因） 選擇缺陷產生的原因時，請務必選擇一級分類和二級分類，切不可只選擇一級分類、不選擇二級分類,缺陷產生原因定義及處理,在jira中進行缺陷產生原因實踐,重開缺陷的定義,重開缺陷的定義 重開缺陷的原因 Jira中重開缺陷的標識 重開率的計算公式 重開缺陷關注點,重開缺陷的定義,什么是重開缺陷? 重開缺陷：指開發(fā)修正并在jira中置為已修正的缺陷經(jīng)過測試人員驗證，發(fā)現(xiàn)仍有問題則將該缺陷重開,什么狀態(tài)的缺陷可能會被重開？ 已解決-已修正缺陷：指經(jīng)過開發(fā)修正并在jira中將相應狀態(tài)置為已修正的缺陷 已關閉-已修正缺陷：指開發(fā)修正并在jira中置為已修正的缺陷經(jīng)過測試人員驗證，確認無誤后將該缺陷關閉,重開缺陷的定義,重開缺陷的原因 A：缺陷未修改，問題仍然存在 該類重開缺陷產生可能原因：缺陷未修改，開發(fā)將缺陷置成已修正，經(jīng)過驗證，此問題被重開 B：缺陷描述未理解，修改不全面 該類重開缺陷產生可能原因：1）開發(fā)人員對于測試人員的缺陷描述未理解；2）對于描述的缺陷，只修正部分；3）一個功能有多個入口，開發(fā)只修改其中一個入口 C：缺陷已修改，但未按照原始需求實現(xiàn) 該類重開缺陷產生可能原因：1）開發(fā)未按照原始需求進行修改缺陷；2）需求已經(jīng)變更但是測試人員不知，導致缺陷重開；3）需求已經(jīng)變更但是開發(fā)人員不知，導致缺陷重開,重開缺陷的定義,重開缺陷的原因 D：缺陷狀態(tài)標識錯誤 該類重開缺陷產生可能原因：缺陷本應置為放棄或延遲處理，但是開發(fā)人員誤操作將其置為已修正，導致缺陷重開 說明：目前對于該類缺陷未計入重開缺陷中。 E：環(huán)境更新錯誤 該類重開缺陷產生可能原因：部署版本錯誤或新版本未部署上,重開缺陷的定義,Jira中重開缺陷的標識 重開缺陷標識 測試人員在回歸測試中，對于要重開的缺陷，會增加如下注釋：$reopenN-開發(fā)工程師郵箱前綴-tM(N為該bug在該輪回歸測試中被重開的次數(shù)，M代表第幾輪測試，如t2:代表第二輪) 例如：$reopen1-fangjie-t3 含義：方杰修正的缺陷在第3輪中被重開了一次 關閉缺陷標識 測試人員在回歸測試中，對于驗證無誤的缺陷，會增加如下注釋： $reviewN-開發(fā)工程師郵箱前綴-tM(N為該bug在該輪回歸測試中被驗證的次數(shù)，M代表第幾輪測試，如t1:代表第一輪) 例如：$review3-fangjie-t1 含義：方杰修正的缺陷在第1輪中被驗證了3次 請回答： $reopen2-fangjie-t2是什么含義？,重開缺陷的定義,重開率的計算公式 開發(fā)工程師重開率 個人被重開Bug總數(shù)/個人被驗證Bug總數(shù) 每輪重開率 本輪重開缺陷/本輪驗證的總缺陷數(shù) 項目重開率 所有測試輪次中總的重開缺陷/總驗證缺陷數(shù) 產品線重開率 所有項目中總的重開缺陷數(shù)/所有項目總驗證缺陷數(shù),重開缺陷的定義,重開缺陷的關注點 以下缺陷，不會計入重開缺陷內 執(zhí)行了重開操作但是未加注釋$reopenN-開發(fā)工程師郵箱前綴-tN的缺陷，不計入重開缺陷內 在驗證缺陷A時，發(fā)現(xiàn)存在由于修改該缺陷引發(fā)的新缺陷，此時會關閉A缺陷，新增缺陷B，不會出現(xiàn)重開缺陷A的情況 關注： 對于出現(xiàn)爭議的重開記錄，需開發(fā)提交給測試主管審核，確認后再加重開標識，這一點要求開發(fā)工程師及項目負責人及時關注項目中加有$reopenN-開發(fā)工程師郵箱前綴-tN的缺陷 兼容性缺陷，必須在缺陷中標注瀏覽器版本，開發(fā)需按照標注的瀏覽器版本有針對性的修改，如果測試工程師又在其他瀏覽器中出現(xiàn)相同問題，會新建提案，不會在原已經(jīng)修改正確的提案中重開,缺陷等級的定義,按照測試類型分類 B/S結構(Web)測試的缺陷等級定義 C/S結構(Client)測試的缺陷等級定義 服務器及接口測試的缺陷等級定義 缺陷等級分類 A、致命 B、嚴重 C、較嚴重 D、一般性問題主要為：界面類、容錯類缺陷 E、易用性和建議類缺陷 備注：具體內容詳見所有類型測試的缺陷等級定義.docx,線上遺漏缺陷表的填寫方法,線上遺漏缺陷表： 遺漏缺陷記錄表.xlsx 填寫完整后請發(fā)送給給產品線責任測試主管,測試項目管理案例分析,一個產品人員的困惑： 10月初期領導安排了一個項目，周期一個月的時間，從11月1日開始到12月1日上線。接到任務后，終于完成了需求文檔的編寫，提交到開發(fā)那里，被告知需求編寫不詳細，經(jīng)過了多次會議的溝通，開發(fā)工程師們終于明白了要做成什么樣子，詢問什么時候可以開發(fā)完成，被告知11月26日。我的工作終于可以告一段落了，開始等待開發(fā)完成的時間點26日 26日，開發(fā)提交了可測試的版本，我給測試主管打電話，被告知沒有測試資源安排，需要等到12月1日，郁悶與領導溝通后，終于項目可以拖延一周的時間，于是找到測試主管，告知這個好消息，產品可以12月8日上線，測試主管卻反饋說一周的時間無法完成測試，測試用例的編寫時間需要3個工作日，測試執(zhí)行一輪需要2個工作日，如果按照常規(guī)的項目來執(zhí)行，則需要3+2+0.5+3+0.5+1=10個工作日延期開始,測試項目管理案例分析,12月1日，測試人員通知我參與需求評審會議，會議上發(fā)現(xiàn)確實有些地方設計的不夠全面，于是虛心接受，更改了需求，并提交給了測試部門，測試部門得到需求后開始編寫用例，終于用了3個工作日編寫完成，但完成時間點卻是12月6日下班前，而不是12月3日下班前，困惑中，為什么會拖延了1個工作日？ 因為上線時間緊迫，測試部門發(fā)給我和開發(fā)編寫完成的測試用例后，通知我們用郵件的方式反饋用例評審結果。為了節(jié)約時間，測試部門直接進入了測試執(zhí)行階段，問題出現(xiàn)了，冒煙測試沒有通過真是雪上加霜，測試剛剛開始就收到了風險預警郵件測試被迫暫停 為了爭取測試快速啟動，開發(fā)說需要1.5個工作日完成缺陷修復，我苦口婆心的與開發(fā)溝通，壓縮成0.5個工作日完成影響測試執(zhí)行的缺陷修復，并及時通知了測試方。測試方在0.5個工作日后反饋給我，告知缺陷未被修改完成，無法進入測試為什么受傷的總是我,測試項目管理案例分析,開發(fā)又花費了1個工作日的時間修改缺陷，這次冒煙測試終于通過了，但是在執(zhí)行過程中，太多缺陷被開發(fā)建議放棄處理，問詢原因：你的需求變更了，為什么測試還按照原始需求進行測試？報告了很多缺陷？無奈下，我一一過缺陷，把因為需求變更的缺陷均修改為放棄處理，并通知測試，這部分有需求變更，測試人員反饋，需要把最新需求發(fā)給他們，以便他們更正測試用例，更正測試用例的時間需要0.5個工作日可是我根本沒有時間給你們啊，老板也不給我時間啊持續(xù)郁悶。測試過程中發(fā)現(xiàn)了需求評審中補充的那部分需求均沒有實現(xiàn)？困惑中這到底是個什么局面？ 延期再延期測試進度一拖再拖，風險預警一封接著一封沒有按計劃完成缺陷的修改、測試環(huán)境錯誤造成測試無法繼續(xù)完成、沒有達到進入第二輪測試的標準等等，太多原因造成項目延期，居然在測試過程中，測試主管說因為項目進度失控，提交可測試版本時間不確定，測試資源要調離到其他已經(jīng)排期的項目中這樣我的項目不就是遙遙無期了 肺腑之言：“老板，請再給我一點時間、一點空間”,通過此次培訓我能知道什么 總結篇,與測試負責人溝通時，那些測試術語是什么含義？ 測試項目類型分類定義、常規(guī)非常規(guī)方案定義,測試開始前我需要做什么？ 發(fā)送立項郵件、發(fā)送Q提交測試項目計劃、發(fā)送月提交測試項目計劃、準備需求文檔、