1、什么是回歸測(cè)試

回歸測(cè)試（Regression testing） 指在發(fā)生修改之后重新測(cè)試先前的測(cè)試以保證修改的正確性。理論上，軟件產(chǎn)生新版本，都需要進(jìn)行回歸測(cè)試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯(cuò)誤是否在新軟件版本上再次出現(xiàn)。

2、測(cè)試策略

回歸測(cè)試的策略一般由測(cè)試經(jīng)理或測(cè)試組長(zhǎng)制定，初級(jí)軟件測(cè)試人員只要按相應(yīng)的策略執(zhí)行測(cè)試即可?，F(xiàn)以XYC郵箱的測(cè)試為例，簡(jiǎn)要介紹一下回歸測(cè)試的基本策略。

（1）回歸測(cè)試時(shí)執(zhí)行全部的測(cè)試用例

XYC郵箱V1.0版本的第一輪測(cè)試中發(fā)現(xiàn)100個(gè)Bug，那么在第二輪的回歸測(cè)試中，除了測(cè)試這100個(gè)Bug之外，其他所有功能點(diǎn)的測(cè)試用例需要重新再執(zhí)行一遍，這樣做的原因在于，回歸測(cè)試的V1.1版本是在修改了V1.0版本存在的100個(gè)Bug的基礎(chǔ)上建立起來的。由于修復(fù)了大量的Bug，這就意味著要改動(dòng)大量的代碼，當(dāng)多處代碼被改動(dòng)后誰也不能保證其他功能點(diǎn)不受影響，所以對(duì)所有的功能點(diǎn)進(jìn)行測(cè)試是比較保險(xiǎn)的，也是比較周密的，不會(huì)遺漏任何的測(cè)試點(diǎn)。使用此策略的時(shí)間周期和人力成本也是比較高的，一般情況下，當(dāng)?shù)谝惠啘y(cè)試發(fā)現(xiàn)的Bug數(shù)量過多的情況下，第二輪回歸測(cè)試應(yīng)該執(zhí)行全部的測(cè)試用例。

（2）選擇重要的功能點(diǎn)、常用的功能點(diǎn)、與Bug相關(guān)聯(lián)的功能點(diǎn)進(jìn)行回歸測(cè)試

XYC郵箱的第二輪回歸測(cè)試中又發(fā)現(xiàn)了40個(gè)Bug，那么在第三輪的回歸測(cè)試過程中，除了要測(cè)試這40個(gè)Bug之外，還應(yīng)當(dāng)把重要的功能點(diǎn)、常用的功能點(diǎn)、與Bug相關(guān)聯(lián)的功能點(diǎn)的測(cè)試用例再執(zhí)行一遍，其他次要的測(cè)試用例可在時(shí)間充足的情況下選擇性執(zhí)行。

（3）選擇性執(zhí)行關(guān)鍵功能點(diǎn)的測(cè)試用例

XYC郵箱的第三輪回歸測(cè)試中又發(fā)現(xiàn)了12個(gè)Bug，那么在第四輪的回歸測(cè)試過程中，除了測(cè)試這12個(gè)Bug之外，還可以選擇性地執(zhí)行一些關(guān)鍵功能點(diǎn)的測(cè)試用例，其他測(cè)試用例可在時(shí)間充足的情況下選擇性執(zhí)行。

（4）僅測(cè)試出現(xiàn)Bug的功能點(diǎn)

如果測(cè)試組認(rèn)為軟件的功能點(diǎn)已經(jīng)十分穩(wěn)定了，回歸測(cè)試的時(shí)候可選擇僅測(cè)試出現(xiàn)Bug的功能點(diǎn)。每個(gè)策略都有其適應(yīng)的場(chǎng)景，不能一概而論，應(yīng)當(dāng)以Bug的數(shù)量和嚴(yán)重程度為導(dǎo)向，深入分析，然后得出適合本項(xiàng)目的回歸測(cè)試策略。

回歸測(cè)試是在系統(tǒng)測(cè)試人員完成了需求評(píng)審、測(cè)試計(jì)劃、用例設(shè)計(jì)、環(huán)境搭建、Bug提交等關(guān)鍵性的測(cè)試工作之后所要開展的工作，可以說此時(shí)的測(cè)試人員已經(jīng)完全融入測(cè)試體系當(dāng)中，也完全可以勝任相應(yīng)的測(cè)試工作了。至于回歸測(cè)試的策略，初級(jí)軟件測(cè)試人員可通過先學(xué)習(xí)測(cè)試經(jīng)理制定的策略，再從執(zhí)行回歸測(cè)試策略過程中進(jìn)一步提升自己的測(cè)試經(jīng)驗(yàn)。

3、對(duì)Bug起爭(zhēng)議時(shí)的處理

測(cè)試人員和開發(fā)人員因Bug起爭(zhēng)議的事情常有發(fā)生，例如開發(fā)人員認(rèn)為這不算是一個(gè)Bug，或認(rèn)為這個(gè)Bug不重要，不需要修改，而測(cè)試人員認(rèn)為這是一個(gè)很嚴(yán)重的Bug，需要開發(fā)人員修改，或因其他原因起了爭(zhēng)議等。如果出現(xiàn)了這些情況，測(cè)試人員應(yīng)如何處理呢？

（1）任何爭(zhēng)議都需要“對(duì)事不對(duì)人”，不能因?yàn)锽ug而激化了雙方的矛盾。

（2）有很多初級(jí)軟件測(cè)試人員提交的Bug單流轉(zhuǎn)到開發(fā)人員那里后，開發(fā)人員看不懂。原因在于測(cè)試人員提交的Bug單沒有描述清楚，這是一個(gè)非常常見的現(xiàn)象。測(cè)試人員提交的Bug單一定要描述清楚，并需要有充足的依據(jù)和理由。

（3）如果Bug單寫清楚了，但開發(fā)人員還是不愿意修改的話，可以找一個(gè)合適的時(shí)間，心平氣和地與開發(fā)人員溝通，說明此Bug對(duì)產(chǎn)品質(zhì)量可能產(chǎn)生的不良影響，測(cè)試人員在溝通過程中不能意氣用事。

（4）經(jīng)溝通后，如果開發(fā)人員還是不愿意修改的話（當(dāng)然開發(fā)人員不修改也有他們的原因），那么此時(shí)可以向測(cè)試經(jīng)理匯報(bào)這一情況，由測(cè)試經(jīng)理出面解決，或是由測(cè)試經(jīng)理召開Bug評(píng)審大會(huì)（開發(fā)人員、測(cè)試人員、產(chǎn)品經(jīng)理三方人員參與，有時(shí)也包括項(xiàng)目經(jīng)理），共同定奪。

（5）有些初級(jí)軟件測(cè)試人員把Bug提交到開發(fā)人員那后，經(jīng)過開發(fā)人員的各種解釋，就會(huì)同意開發(fā)人員的意見，也認(rèn)為這確實(shí)不是一個(gè)Bug，從而忽略這個(gè)問題，這也是經(jīng)常發(fā)生在初級(jí)軟件測(cè)試人員身上的事情。這就要求測(cè)試人員提交Bug的過程要有原則性，這也是作為一名合格的測(cè)試人員最重要的特征之一，對(duì)待問題需要堅(jiān)持原則。

（6）測(cè)試人員應(yīng)和開發(fā)人員面對(duì)面或通過電子郵件、電話等方式保持密切溝通，共同協(xié)商和處理Bug，以減少兩者間的隔膜，增加測(cè)試人員與開發(fā)人員之間的信任和了解。直接溝通也應(yīng)貫穿到產(chǎn)品開發(fā)、測(cè)試的每個(gè)環(huán)節(jié)當(dāng)中。