關(guān)于測試工作的規(guī)范，上次討論了用例部分。

本次將繼續(xù)聊下測試執(zhí)行期間的規(guī)范標(biāo)準(zhǔn)，是主要需要測試執(zhí)行人員關(guān)注的部分。

【測試執(zhí)行】

測試執(zhí)行規(guī)范或標(biāo)準(zhǔn)，主要是為了確保測試人員“在正確的環(huán)境做正確的驗證”，并且能“留下相關(guān)記錄、準(zhǔn)確及時地暴露出問題”。

這里會包含可測性確認(rèn)、測試記錄、問題/風(fēng)險判斷與提交、異常情況處理等；

也就是主要與測試執(zhí)行期關(guān)聯(lián)的要求。

可測性確認(rèn)算可測評估的一部分，是其中的初步執(zhí)行驗證部分。

它通過冒煙檢查指定環(huán)境、提測版本、功能范圍的實現(xiàn)情況，確認(rèn)對應(yīng)提測內(nèi)容是否可以繼續(xù)測試。

關(guān)于此類判斷標(biāo)準(zhǔn)，可以看看這些示例：

對于環(huán)境，是環(huán)境不可用即不可測，還是允許協(xié)調(diào)/共用其他環(huán)境測試；

提測版本需要核對哪幾個數(shù)據(jù)，是必須等于某個版本還是高于某個build即可；

功能范圍是否要求包含所有需求點，是否必須包含核心提測需求，或是否需要全應(yīng)用核心功能可用；

實現(xiàn)狀態(tài)驗證上，是要求冒煙功能主流程，還是確認(rèn)清單中入口可進(jìn)入即可，或需要驗證到需求所述優(yōu)化表現(xiàn)。

以上這些，都屬于執(zhí)行可測性驗證時候會涉及到的規(guī)范或標(biāo)準(zhǔn)；

執(zhí)行測試的人員，需要參考這些要求，結(jié)合實際功能情況來評估本次可測/不可測范圍。

測試記錄部分，通常會被要求和測試用例分離。

至于具體要求，就是各個團(tuán)隊或項目的要求了。

可能出現(xiàn)的規(guī)范方向，例如：

需要記錄哪些內(nèi)容，使用什么格式；

執(zhí)行同時記錄還是每日更新；

本地記錄、在線表格還是專用平臺；

如何存檔，是否定期回顧；

以及等等。

測試記錄，通常也代表了測試進(jìn)度。

相關(guān)要求也可能包括進(jìn)度更新/溝通，比如測試完成后是否要實時標(biāo)記完成，是否要實時與PM或相關(guān)產(chǎn)品研發(fā)溝通。

問題的判斷與提交，也可以認(rèn)為是bug相關(guān)規(guī)范或標(biāo)準(zhǔn)。

在這里，我指的是什么樣的問題會被判定需要提交。

比如：

上個版本存在的問題是否需要重新提交；

是否需要忽略特定模塊的問題；

特定機型的問題是同步給適配團(tuán)隊還是直接提交；

特定類型的問題除提bug外是否還要做其他操作；

以及等等。

這部分要求通常階段性比較強

——可能只是本次提測這樣要求，下個版本就變化了

——若是如此，這是需要在每次測試前確認(rèn)清楚的。

異常情況處理，是指在異常狀態(tài)下，要求測試執(zhí)行人員做出怎樣的反饋。

異常情況通常包括：

進(jìn)入測試后遇到的，例如環(huán)境不穩(wěn)定/受意外因素影響出現(xiàn)無法測試/測試無效；

質(zhì)量與預(yù)期差異過大，導(dǎo)致進(jìn)度和預(yù)估不符合；

單點阻斷，或某些入口阻斷其它功能驗證；

以及等等。

而測試人員被要求做的，或者說相關(guān)規(guī)范，可能包括：

報給測試接口人；

直接與阻斷對應(yīng)研發(fā)人員溝通；

需要用什么形式溝通，提供哪些信息，給到誰；

是否在進(jìn)度表或用例表有對應(yīng)記錄格式；

哪些問題要發(fā)現(xiàn)后第一時間上報；

以及等等。

【BUG】

bug相關(guān)的規(guī)范或標(biāo)準(zhǔn)，主要是為了讓bug可以被高效理解和流轉(zhuǎn)。

通常主要包括bug的內(nèi)容要求，以及bug流轉(zhuǎn)、流程要求。

內(nèi)容要求方面，比較直觀的規(guī)范例如，字段有哪些、是否必填、填寫什么內(nèi)容。

這些規(guī)范，通常是在測試可提供信息，和處理人需要信息間權(quán)衡的結(jié)果

——要求信息過多會給測試人員增加工作量，提供信息不足會影響處理人判斷問題情況。

比較常見的要求，例如：

標(biāo)題格式包含問題簡述，加上該項目重要區(qū)分維度如模塊、類型、環(huán)境、版本，以便看到bug標(biāo)題可以快速歸類或找責(zé)任人；

內(nèi)容要求有版本號、發(fā)現(xiàn)時間、賬號信息、前置條件、操作步驟、問題現(xiàn)象、預(yù)期結(jié)果、重現(xiàn)概率、對應(yīng)截圖或視頻等；

額外字段可能有模塊、類型、嚴(yán)重程度、優(yōu)先級、重現(xiàn)情況、版本、基線、處理人等；

常見bug系統(tǒng)當(dāng)然還有創(chuàng)建人、創(chuàng)建時間、處理時間等自動生成的字段，但這通常不需要填寫時關(guān)注；

除此之外，提交bug還經(jīng)常會被要求，附件上傳特定方式獲取的log。

關(guān)于內(nèi)容的要求，除了bug提交時的格式、內(nèi)容，也包括各字段相關(guān)的判斷標(biāo)準(zhǔn)；

比如：

如何判斷是哪個模塊、哪種類型的bug；

如何區(qū)分bug的嚴(yán)重級別和優(yōu)先級；

偶現(xiàn)bug需要嘗試復(fù)現(xiàn)幾次；

以及等等。

bug的流程要求，通常包括提單流程和回歸流程

——實際bug規(guī)范還有與研發(fā)、產(chǎn)品策劃、PM等角色有關(guān)部分，此處僅描述測試有關(guān)部分。

提單部分除了前文描述的內(nèi)容，還包括一些其它要求，例如：

提單初步處理人選誰，什么情況給測試接口人，什么時候給PM、相關(guān)研發(fā)或產(chǎn)品策劃；

除提單外，是否需要其他通知操作，或哪些bug，要求什么形式的額外通知；

對于bug，是發(fā)現(xiàn)就提，還是需進(jìn)行指定復(fù)驗/定位，或要求非阻斷問題每日統(tǒng)一提單；

以及等等。

在回歸流程中，測試方面通常會有重新打開流程和回歸關(guān)閉流程。

針對不同流程，會分別規(guī)定不同情況需提供的信息。

都要提供的如驗證版本，重新打開單獨需要的如：

描述現(xiàn)象，提供新的截圖/視頻/log，如果現(xiàn)象有變化可能需要提供更多信息。

回歸重新打開的流程，還可能涉及類似提單的流轉(zhuǎn)人判斷、通知等流程要求。

規(guī)范和標(biāo)準(zhǔn)類型還沒有討論完。

在用例、執(zhí)行、bug之外，測試流程上還有一些可能的規(guī)范，下次會做一些補充性說明。

聲明：

本號對所有原創(chuàng)、轉(zhuǎn)載文章的陳述與觀點均保持中立，推送文章僅供讀者學(xué)習(xí)和交流。文章、圖片等版權(quán)歸原作者享有，如有侵權(quán)，聯(lián)系刪除。

北京漢通達(dá)科技主要業(yè)務(wù)為給國內(nèi)用戶提供通用的、先進(jìn)國外測試測量設(shè)備和整體解決方案，產(chǎn)品包括多種總線形式（臺式/GPIB、VXI、PXI/PXIe、PCI/PCIe、LXI等）的測試硬件、相關(guān)軟件、海量互聯(lián)接口等。經(jīng)過二十年的發(fā)展，公司產(chǎn)品輻射全世界二十多個品牌，種類超過1000種。值得一提的是，我公司自主研發(fā)的BMS測試產(chǎn)品、芯片測試產(chǎn)品代表了行業(yè)一線水平。