參加培訓(xùn)后，這個(gè)收獲應(yīng)該來說是大的，也給了我思考問題的不同的角度，先說下歷史吧：還是從bug說起吧，我們都知道bug是我們測試人員永遠(yuǎn)都要討論的話題，之前也說了，把bug分為2類：一個(gè)是新功能的bug，一個(gè)是舊功能的bug。其實(shí)還有一種bug是客戶發(fā)現(xiàn)的bug。那么對于這三種bug，會(huì)想出不同的方法和team來對付這些bug，

　　我們的目標(biāo)是發(fā)現(xiàn)更多的新功能的bug，減少舊功能和客戶發(fā)現(xiàn)的bug。目標(biāo)確定后，要組織team和系統(tǒng)去測試這些，培訓(xùn)老師給的方案也是思科公司目前的做法：一個(gè)功能測試部專注于測試新的項(xiàng)目，新的功能，發(fā)現(xiàn)新功能的bug；一個(gè)回歸測試部專門負(fù)責(zé)所有舊功能的回歸工作，并發(fā)現(xiàn)舊功能的bug；后一個(gè)是解決方案測試部，專注于研究用戶使用環(huán)境，模擬線上真實(shí)環(huán)境，盡大可能發(fā)現(xiàn)用戶發(fā)現(xiàn)的bug。

　　上面我們可以看到的是有3個(gè)team在整個(gè)產(chǎn)品周期中所起到的作用，第一個(gè)功能測試部的運(yùn)作方式大家都很熟了，這里不詳細(xì)說了。下面說下回歸測試部的運(yùn)作方式：這里有2個(gè)前提，那是產(chǎn)品的基線庫的建立，一定要完備，二個(gè)是以前功能測試用例的自動(dòng)化程度要高，才能啟動(dòng)回歸測試部的工作。首先說下回歸測試任務(wù)的參與階段，同樣是在系統(tǒng)質(zhì)量穩(wěn)定后，

　　大概是第三輪測試的時(shí)候，這里可是24X7 auto regression所有功能。不停的跑以前功能的測試腳本，像火車一樣，定時(shí)開始運(yùn)行，哪個(gè)項(xiàng)目上線，趕上哪趟火車上，其測試人員負(fù)責(zé)運(yùn)行所有腳本，分析產(chǎn)生的bug（是腳本問題，還是舊功能的bug，測試環(huán)境問題），以及report所有的bug。這里回歸測試部的人員不負(fù)責(zé)維護(hù)腳本。

　　怎樣使回歸測試部的管理更好呢：首先采用標(biāo)準(zhǔn)的拓?fù)浣Y(jié)構(gòu)的測試床（測試環(huán)境）；并行的運(yùn)行所有的腳本；對測試床的有效性和回歸周期進(jìn)行有效的關(guān)聯(lián)；對腳本的要求是如果一旦硬件環(huán)境等問題可自動(dòng)重啟服務(wù)，繼續(xù)運(yùn)行后面的腳本。

　　這里還有個(gè)小問題是我們發(fā)現(xiàn)的問題怎么判斷是是bug呢？ 這里說到基線的作用了，我們會(huì)與基線相比較來確定是否bug和分析。有4種情況：

　　第一： 基線是 Pass的，加入新功能后回歸 是Pass的。  不用分析的，直接跳過。

　　第二： 基線是 Fail的，加入新功能后回歸 是Pass的。  不用分析的，直接跳過。

　　第三： 基線是 Fail的，加入新功能后回歸 是Fail的。  絕大部分情況不用分析的。

　　第四： 基線是 Pass的，加入新功能后回歸 是Fail的。  肯定是bug，直接分析。

　　有人肯定懷疑第二種情況，其實(shí)好的基線是不允許這個(gè)情況的，也是說好的繼續(xù)其Pass率是很高的。我們主要關(guān)心的是第四種情況。一旦發(fā)現(xiàn)了，那產(chǎn)出顯而易見了。

　　這里大概講下解決方案測試部的運(yùn)作方式，之前在第一家公司的時(shí)候，確實(shí)有這個(gè)部門去做：有幾個(gè)特點(diǎn)吧：直接面向客戶；專注不同測試類型；與第三方公司合作；負(fù)責(zé)的用戶環(huán)境；模擬真實(shí)線上環(huán)境。有點(diǎn)類似我們的預(yù)發(fā)布測試。這個(gè)team做的好的是當(dāng)我們項(xiàng)目用到其他產(chǎn)品的接口時(shí)能發(fā)現(xiàn)很多相關(guān)的bug。

　　上面說的是思科公司的做法，人家也許是好的，但我們更多的是了解別人為啥這么做，主要是要了解context，能不能適合我們呢？是不是能給我們帶來一些新的思考角度呢？