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

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

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

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

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

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

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

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

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

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

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

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

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