速成測試接口達(dá)人測試流程.ppt

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