測(cè)試部門現(xiàn)狀分析與規(guī)劃

1、測(cè)試部門現(xiàn)狀分析與規(guī)劃作者余邦利日期2018/8/8目錄 TOC o 1-5 h z HYPERLINK l bookmark2 o Current Document .引言3 HYPERLINK l bookmark4 o Current Document 測(cè)試部門現(xiàn)狀3 HYPERLINK l bookmark6 o Current Document 編寫規(guī)劃目的3 HYPERLINK l bookmark8 o Current Document 2當(dāng)前測(cè)試工作需要改進(jìn)的幾個(gè)方面 3 HYPERLINK l bookmark10 o Current Document 規(guī)范測(cè)試流程 3 HY

2、PERLINK l bookmark12 o Current Document 測(cè)試人員分配5 HYPERLINK l bookmark14 o Current Document 編寫測(cè)試用例5 HYPERLINK l bookmark16 o Current Document 建立測(cè)試用仞評(píng)審制度 7 HYPERLINK l bookmark18 o Current Document 定義Bug等級(jí)（或類別） 7 HYPERLINK l bookmark20 o Current Document 建立Bug評(píng)審制度 7 HYPERLINK l bookmark22 o Current Doc

3、ument 建立版本管理流程 8 HYPERLINK l bookmark24 o Current Document 建立對(duì)測(cè)試過(guò)程的跟蹤制度 10 HYPERLINK l bookmark26 o Current Document 根據(jù)項(xiàng)目的等級(jí)對(duì)測(cè)試標(biāo)準(zhǔn)的劃分 11 HYPERLINK l bookmark29 o Current Document 試標(biāo)準(zhǔn)11測(cè)試標(biāo)準(zhǔn) 11 HYPERLINK l bookmark31 o Current Document 3建立培訓(xùn)機(jī)制和自動(dòng)化工具引入 11 HYPERLINK l bookmark33 o Current Document 對(duì)于測(cè)試人員

4、的培訓(xùn) 11 HYPERLINK l bookmark35 o Current Document 自動(dòng)化工具的引入 12.引言測(cè)試部門現(xiàn)狀通過(guò)這段時(shí)間的了解，我們公司現(xiàn)階段的測(cè)試組的情況如下：測(cè)試流程不規(guī)范；測(cè)試文檔不健全；測(cè)試版本管理混亂測(cè)試沒(méi)有建立測(cè)試用例評(píng)審機(jī)制；測(cè)試沒(méi)有建立bug評(píng)審機(jī)制； 測(cè)試沒(méi)有建立培訓(xùn)機(jī)制等。編寫規(guī)劃目的根據(jù)測(cè)試部門現(xiàn)狀，以及公司領(lǐng)導(dǎo)對(duì)測(cè)試部們的重視與期望， 該文檔明確、測(cè)試流程、測(cè)試文檔規(guī)范以及測(cè)試部門人員技能與業(yè)務(wù)的培訓(xùn)等方面，在后期的工作實(shí)踐中由測(cè)試部門成員不斷地改進(jìn)優(yōu)化， 使得測(cè)試部門能夠更好與其他 部門成員做好產(chǎn)品的質(zhì)量控制。2當(dāng)前測(cè)試工作需要改進(jìn)的幾個(gè)

5、方面規(guī)范測(cè)試流程規(guī)范的測(cè)試流程能夠幫助大家提高工作效率，避免現(xiàn)在有的項(xiàng)目再重蹈覆轍，以后的項(xiàng)目進(jìn)展才會(huì)越來(lái)越順利， 產(chǎn)品質(zhì)量上才能得到進(jìn)一步的提升。 根據(jù) 我們的實(shí)際業(yè)務(wù)和目前的實(shí)際情況，我們的測(cè)試流程圖如下：測(cè)試流程圖測(cè)試人員分配問(wèn)題描述：目前測(cè)試人員是一個(gè)項(xiàng)目一個(gè)人員，人員上是緊缺的，最近也是在加緊招聘 中。風(fēng)險(xiǎn)：當(dāng)一個(gè)人負(fù)責(zé)一個(gè)項(xiàng)目的測(cè)試時(shí)，首先一個(gè)人想問(wèn)題不是很全面，在設(shè)計(jì)測(cè) 試用例時(shí)，考慮有可能不全面，內(nèi)部也不能進(jìn)行用例評(píng)審；還有目前我們的測(cè)試 任務(wù)也比較急，在這種情況下，測(cè)試人員也有可能測(cè)試不全面； 還有當(dāng)人員因?yàn)?一些外部因素請(qǐng)假時(shí)，那項(xiàng)目都無(wú)法進(jìn)行下去，所以目前這種狀態(tài)其實(shí)風(fēng)險(xiǎn)

6、還是 很多的。措施：測(cè)試工作安排方面采用2人組合方式進(jìn)行。也就是說(shuō)按照咱公司的人員編制， 一個(gè)項(xiàng)目有兩個(gè)人員負(fù)責(zé)測(cè)試，具體實(shí)現(xiàn)時(shí)可以采用：專職為主、兼職為輔和交 叉測(cè)試的策略。在這樣的狀態(tài)下就可以規(guī)避以上這些風(fēng)險(xiǎn)。編寫測(cè)試用例問(wèn)題描述：測(cè)試用例作為軟件測(cè)試的重要手段，測(cè)試質(zhì)量的重要依據(jù)，應(yīng)該占用相 當(dāng)長(zhǎng)的時(shí)間，但是，目前我們是在沒(méi)有測(cè)試用例的條件下進(jìn)行盲目的測(cè)試。 風(fēng)險(xiǎn)：這樣的測(cè)試雖然也可以發(fā)現(xiàn)一些問(wèn)題，但是，這些問(wèn)題是根據(jù)測(cè)試人員 的測(cè)試經(jīng)驗(yàn)和專業(yè)經(jīng)驗(yàn)才能發(fā)現(xiàn)的。并且，在說(shuō)明軟件質(zhì)量是如何得到保證 時(shí)，缺乏有力的依據(jù)，在這樣的測(cè)試下，我們的功能測(cè)試覆蓋率根本無(wú)據(jù)可 查，更可以認(rèn)為這樣的測(cè)試是

7、無(wú)效的測(cè)試。措施：測(cè)試用例編寫原則及規(guī)范.統(tǒng)一測(cè)試用例編寫的規(guī)范，為測(cè)試設(shè)計(jì)人員提供測(cè)試用例編寫的指導(dǎo)， 提高編寫的測(cè)試用例的可讀性，可執(zhí)行性、合理性。.測(cè)試用例，不僅僅用于 QA閱讀和執(zhí)行。它們也可能會(huì)被開(kāi)發(fā)、PD、PM等閱讀審查或執(zhí)行；也更可能被其他測(cè)試人員或者新員工作為業(yè)務(wù)學(xué)習(xí)、 測(cè)試執(zhí)行的參照。3.編寫測(cè)試用例的最終目標(biāo)是：一個(gè)對(duì)于產(chǎn)品毫無(wú)所知的人員，也能夠 快速的熟悉用例并執(zhí)行用例。用例顆粒度原則：測(cè)試用例是執(zhí)行的最小實(shí)體，用例劃分基本原則是以最小功能模塊來(lái)劃 分，為保障用例的可執(zhí)行性、覆蓋度，規(guī)范編寫用例的粒度要求如下：.一個(gè)功能正常流程，編寫一個(gè)測(cè)試用例；.一個(gè)功能中多個(gè)異常流程

8、，應(yīng)分開(kāi)編寫多個(gè)測(cè)試用例；.同一功能不同入口，可合并編寫一個(gè)測(cè)試用例；.同一功能不同數(shù)據(jù)準(zhǔn)備，應(yīng)分開(kāi)編寫多個(gè)測(cè)試用例；.同一個(gè)功能用例的自動(dòng)化用例和功能用例要匹配，若自動(dòng)化用例不能 完全覆蓋功能用例，自動(dòng)化用例和功能用例拆分兩個(gè)互補(bǔ)測(cè)試用例； 用例編寫要求規(guī)范：.具有清晰名稱、前提條件、操作步驟、期望結(jié)果的；.可被他人理解的；.可被他人執(zhí)行的；具體分項(xiàng)要求如下：.用例名稱.前置條件.重現(xiàn)步驟用例維護(hù)規(guī)范：測(cè)試用例編寫完成后，應(yīng)對(duì)測(cè)試用例進(jìn)行持續(xù)的維護(hù)：.新項(xiàng)目需求變更，應(yīng)及時(shí)對(duì)測(cè)試用例進(jìn)行修改；.維護(hù)期項(xiàng)目，可根據(jù)項(xiàng)目組情況周期對(duì)用例進(jìn)行維護(hù)；.所有發(fā)現(xiàn)的bug和故障，基于測(cè)試用例無(wú)法發(fā)現(xiàn)，需

9、轉(zhuǎn)化為測(cè)試用例。建立測(cè)試用例評(píng)審制度由于各方面原因的局限性，測(cè)試用例會(huì)有一定的缺陷。所以，讓更多的 人參與進(jìn)來(lái)，對(duì)測(cè)試用例進(jìn)行完善，以提高測(cè)試標(biāo)準(zhǔn)。定義Bug等級(jí)（或類別）問(wèn)題描述：對(duì)Bug的等級(jí)（嚴(yán)重、一般、輕微）進(jìn)行明確的劃分。制定某些等級(jí)或類別的錯(cuò)誤是必須修改的相關(guān)制度（其實(shí)我更偏向于只要是 Bug就必須修改，只不過(guò)是放在此次修改還是在下版本中修改的問(wèn)題）。優(yōu)點(diǎn)：有利于Bug進(jìn)行管理，便于相關(guān)人員對(duì)修改工作日程安排做出正確的計(jì)劃。建立Bug評(píng)審制度問(wèn)題描述：對(duì)于測(cè)試部門測(cè)試出來(lái)的有爭(zhēng)議問(wèn)題，應(yīng)該經(jīng)過(guò)Bug評(píng)審，首先要確定是否屬于Bug,然后再確定應(yīng)該由哪一個(gè)部門或者說(shuō)研發(fā)人員對(duì)其進(jìn)行修

10、改以及修改的時(shí)間，對(duì)應(yīng)的測(cè)試人員要及時(shí)進(jìn)行回歸測(cè)試等。咱們還有個(gè) bug來(lái)源是外部的，包括業(yè)務(wù)方、實(shí)施人員等，他們會(huì)提交一些 bug。但他 們往往因?yàn)閷?duì)于系統(tǒng)的不了解或者說(shuō)對(duì)產(chǎn)品的設(shè)計(jì)不是很熟悉的情況下， 有時(shí)候會(huì)提交問(wèn)題并不是bug。參與人員：項(xiàng)目組中涉及的各個(gè)部門相關(guān)人員或負(fù)責(zé)人，包括產(chǎn)品、研發(fā)、測(cè)試等 人員。Bug流轉(zhuǎn)圖:外部提交bug我們測(cè)試內(nèi)部提交的bug 一般情況下是可以確認(rèn)的，只有極少一部分的 bug是需要評(píng)審的。對(duì)于這部分的 bug評(píng)審?fù)ㄟ^(guò)后就可以直接轉(zhuǎn)給開(kāi)發(fā)進(jìn)行 修復(fù)，對(duì)于沒(méi)有通過(guò)的bug就要closed ,我們?cè)瓌t上誰(shuí)提交的誰(shuí)關(guān)閉；外部 提交的bug,首先要測(cè)試人員確認(rèn)是否

11、是bug,當(dāng)無(wú)法確認(rèn)的可以找外部提交 的人員確認(rèn)或者找多方評(píng)審確認(rèn)，其他流程和測(cè)試提交bug流程一致。建立版本管理流程根據(jù)目前我們測(cè)試反應(yīng)的情況大概有這么幾種：.測(cè)試的功能并不在提交測(cè)試的版本中；.測(cè)試在構(gòu)建時(shí)經(jīng)常失?。?提交給客戶的版本該有的功能沒(méi)有了；等等這樣一些情況吧，總之就是在版本控制方面做的不是很好，希望能夠加 強(qiáng)版本控制能實(shí)現(xiàn)：提高開(kāi)發(fā)和測(cè)試的效率，提高軟件版本穩(wěn)定性，便于追 溯問(wèn)題。流程圖:01迭代功能開(kāi)發(fā).從Mast日啦新的分支.禪道上項(xiàng)目管理的IDHotfi電項(xiàng)目ID01迭代功能開(kāi)發(fā).從Mast日啦新的分支.禪道上項(xiàng)目管理的IDHotfi電項(xiàng)目IDFeature_項(xiàng)目 ID0

12、5生成tag發(fā)布上線一、禪道上修改BUG r必須認(rèn)真填寫產(chǎn)生原因、解決方案、影響危圍以及自測(cè)臨品二、版本合并前迸行代碼田定也合并之后自測(cè)完成 后交給測(cè)試團(tuán)隊(duì)*三、task完成之后指派給項(xiàng)目主管，由主管確認(rèn)OK再 次指派給測(cè)試。02線上BUG修復(fù)04 Mawte 哈并合并到其他開(kāi)發(fā)版本中1.制定合理版本發(fā)布計(jì)劃，加強(qiáng)版本控制管理。協(xié)商測(cè)試版本發(fā)布及發(fā)布頻率：制定版本進(jìn)度計(jì)劃，該計(jì)劃中包括開(kāi)發(fā)團(tuán)隊(duì)提交不同版本的計(jì)劃時(shí)間、每個(gè)版本中新增功能模塊列表、提交版本的要求、 修復(fù)的bug列表等。測(cè)試版本發(fā)布基礎(chǔ)：代碼評(píng)估（代碼review ）,版本控制的文檔（標(biāo)識(shí)新增 或修改的功能、修復(fù)的bug、能夠很方便

13、的跟蹤和監(jiān)控測(cè)試版本的執(zhí)行） 測(cè)試啟動(dòng)條件：功能是否開(kāi)發(fā)完成、有沒(méi)有進(jìn)行自測(cè)（避免出現(xiàn)版本質(zhì)量太 差）、軟件版本說(shuō)明。提測(cè)后注意事項(xiàng)：非bug fix的修改，必須說(shuō)明（如代碼重構(gòu)）；Bug fix涉 及的代碼，明確回歸范圍和影響范圍（避免修復(fù) bug是修改共同文件，引起 全局問(wèn)題）。2、強(qiáng)化測(cè)試準(zhǔn)入條件測(cè)試啟動(dòng)條件：功能是否開(kāi)發(fā)完成、有沒(méi)有進(jìn)行自測(cè)（自測(cè)報(bào)告，避免出現(xiàn) 版本質(zhì)量太差）、軟件版本說(shuō)明（清楚每一次版本更新都修改了什么， 會(huì)對(duì)哪 些功能造成影響）。開(kāi)展冒煙測(cè)試：保證系統(tǒng)能跑的起來(lái)，不至于讓測(cè)試工作做到一半突然出現(xiàn) 錯(cuò)誤導(dǎo)致業(yè)務(wù)中斷，如果最基本的測(cè)試都有問(wèn)題則直接打回。（開(kāi)發(fā)人員在試圖

14、解決一個(gè)問(wèn)題的時(shí)候，造成了其它功能模塊一系列的連鎖反應(yīng)，原因可能是只集中考慮了一開(kāi)始的那個(gè)問(wèn)題，而忽略其它的問(wèn)題，這就可能引起了新的Bug。）冒煙測(cè)試的通過(guò)標(biāo)準(zhǔn)：基本的功能和流程通過(guò)就可以。軟件提測(cè)后注意事項(xiàng)：非bug fix的修改，必須周知（如重構(gòu)），Bug fix涉 及的代碼，代碼review ,明確回歸范圍，減少質(zhì)量隱患。3、強(qiáng)化bug管理bug內(nèi)容（發(fā)現(xiàn)版本，對(duì)應(yīng)人員，發(fā)現(xiàn)模塊，回歸次數(shù)，bug關(guān)閉的版本號(hào)）， 可以分析不同版本和不同模塊 bug走勢(shì)。發(fā)現(xiàn)此次迭代范圍外的之前遺留的 bug,測(cè)試記錄后，和開(kāi)發(fā)及項(xiàng)目管理人 員商討是否解決，解決方式（代碼限制 OF作說(shuō)明中限制），是否占用

15、此次 迭代的開(kāi)發(fā)時(shí)間。4、版本控制文檔管理工作版本信息、測(cè)試記錄、測(cè)試結(jié)果（開(kāi)發(fā)和測(cè)試活動(dòng)的追溯）.降低測(cè)試的輪次保證開(kāi)發(fā)和測(cè)試環(huán)境的獨(dú)立性： 測(cè)試環(huán)境和開(kāi)發(fā)環(huán)境分開(kāi)，盡量做到測(cè)試數(shù) 據(jù)不會(huì)被開(kāi)發(fā)人員修改。明確測(cè)試需求：需求功能點(diǎn)全部實(shí)現(xiàn)，如果有需求不能在規(guī)定時(shí)間完成，需 要在需求階段提出，而不是在測(cè)試階段完善需求，從而加長(zhǎng)了開(kāi)發(fā)和測(cè)試時(shí) 間，影響效率。冒煙測(cè)試：達(dá)到送測(cè)標(biāo)準(zhǔn)，在服務(wù)器上取下測(cè)試的版本，編譯、部署后，對(duì) 部分主要的功能進(jìn)行預(yù)測(cè)試，如果預(yù)測(cè)試通過(guò)了，就可以開(kāi)始測(cè)試。如果預(yù) 測(cè)試不通過(guò)，就打回開(kāi)發(fā)部門修改好后再預(yù)測(cè)試，直到預(yù)測(cè)試通過(guò)為止。.測(cè)試環(huán)境的維護(hù)測(cè)試環(huán)境最好是專人維護(hù)，頻繁

16、發(fā)布新功能或者修改是不可取的。保證版本 的統(tǒng)一性很重要。建立對(duì)測(cè)試過(guò)程的跟蹤制度問(wèn)題描述：測(cè)試過(guò)程就是執(zhí)行測(cè)試用例以及記錄測(cè)試用例執(zhí)行結(jié)果的過(guò)程，這一過(guò)程應(yīng)該被明確記錄，是測(cè)試被執(zhí)行的依據(jù)。優(yōu)點(diǎn)：測(cè)試用例是否是按照計(jì)劃的逐個(gè)的執(zhí)行的將更加明確； 測(cè)試是否通過(guò)的標(biāo)準(zhǔn)一一測(cè)試用例的通過(guò)率統(tǒng)計(jì)時(shí)的重要依據(jù)； 作為對(duì)測(cè)試人員工作監(jiān)督的一個(gè)重要手段。根據(jù)項(xiàng)目的等級(jí)對(duì)測(cè)試標(biāo)準(zhǔn)的劃分項(xiàng)目級(jí)測(cè)試標(biāo)準(zhǔn)所有項(xiàng)目均應(yīng)該通過(guò)單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、安裝測(cè)試、驗(yàn)收測(cè)試五個(gè)測(cè)試階段的測(cè)試；功能覆蓋率應(yīng)達(dá)到100%測(cè)試用例通過(guò)率不低于90%BUO復(fù)率不低于90%升級(jí)項(xiàng)目測(cè)試標(biāo)準(zhǔn)升級(jí)項(xiàng)目測(cè)試標(biāo)準(zhǔn)應(yīng)在項(xiàng)目級(jí)測(cè)試標(biāo)準(zhǔn)的基礎(chǔ)

17、上，增加兼容性測(cè)試;對(duì)于上版本中的遺留問(wèn)題，應(yīng)該在此次升級(jí)工作中解決；采用對(duì)測(cè)試工作流程化管理之后，由于有了相對(duì)的技術(shù)沉淀（原有 的測(cè)試用例、已知缺陷報(bào)告），僅需對(duì)升級(jí)部分編寫測(cè)試用例，將會(huì) 大大減少測(cè)試工作量，縮短項(xiàng)目周期。3建立培訓(xùn)機(jī)制和自動(dòng)化工具引入對(duì)于測(cè)試人員的培訓(xùn)測(cè)試部門根據(jù)部門人員能力情況，以及測(cè)試人員的發(fā)展方向，定期 安排技能、工具和業(yè)務(wù)流程的培訓(xùn)等。測(cè)試人員應(yīng)積極彌補(bǔ)自己在測(cè)試方面、專業(yè)知識(shí)方面的不足，積極 學(xué)習(xí)先進(jìn)的測(cè)試技術(shù)，提高測(cè)試水平；建立知識(shí)共享庫(kù)，包括測(cè)試中生成的技術(shù)文檔、學(xué)習(xí)資料、個(gè)人經(jīng) 驗(yàn)筆記都可以放到知識(shí)共享庫(kù)分享給大家；自動(dòng)化工具的引入對(duì)于一些基本的、邏輯性不

18、強(qiáng)的操作，可以使用自動(dòng)化測(cè)試工具。應(yīng)該說(shuō)，現(xiàn)在在性能測(cè)試、壓力測(cè)試等方面，自動(dòng)化測(cè)試有其不可替代的優(yōu)勢(shì)。 它可以用 簡(jiǎn)單的腳本，實(shí)現(xiàn)大量的重復(fù)的操作。從而通過(guò)對(duì)測(cè)試結(jié)果的分析，得出結(jié)論，這樣不僅節(jié)省了大量的人力和物力，而且使測(cè)試的結(jié)果更準(zhǔn)確。對(duì)于一些邏輯性 很強(qiáng)的操作，如果自動(dòng)化測(cè)試不是很健全的話， 不建議使用。因?yàn)檫@需要比較復(fù) 雜的腳本語(yǔ)言，不可避免的增加了由于測(cè)試腳本的缺陷所造成測(cè)試結(jié)果錯(cuò)誤的誤 差。這時(shí)就需要手動(dòng)測(cè)試了。自動(dòng)化工具常用的有：Web自動(dòng)化測(cè)試工具：selenium QTP。性能自動(dòng)化測(cè)試工具：loadrunner； jmeter。接口自動(dòng)化測(cè)試工具：SoapUI、postman引入自動(dòng)化測(cè)試的前提條件：項(xiàng)目周期長(zhǎng)，需求變動(dòng)不頻繁 測(cè)試用例的穩(wěn)定性決定了自動(dòng)化測(cè)試的維護(hù)成 本。如果軟件需求變動(dòng)過(guò)于頻繁，測(cè)試人員需要根據(jù)變動(dòng)的需求來(lái)更新測(cè)試 用例以及