對(duì)于測(cè)試范圍的形式，谷歌并沒有使用通用的代碼測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試這些常用術(shù)語來做區(qū)分，而是使用小規(guī)模測(cè)試、中等規(guī)模測(cè)試、大規(guī)模測(cè)試這樣的稱呼【譯者注：代碼測(cè)試（code testing）， 通常指單元測(cè)試和API級(jí)別的測(cè)試，一般使用XUnit、Gtest框架，但谷歌并沒有使用代碼級(jí)別測(cè)試這種說法】。小規(guī)模測(cè)試是針對(duì)小量代碼的測(cè)試，中等規(guī)模測(cè)試、大規(guī)模測(cè)試以此類推。所有的三種工程師角色【譯者注，軟件開發(fā)工程師、軟件測(cè)試開發(fā)工程師、軟件測(cè)試工程師，參見本系列第二篇】，都會(huì)去執(zhí)行上面的三類測(cè)試，可能是自動(dòng)化的測(cè)試，也可能是手動(dòng)測(cè)試。

　　小規(guī)模測(cè)試，通常（但也并非所有）是自動(dòng)化的，一般是針對(duì)一個(gè)單獨(dú)的函數(shù)或者模塊。這種測(cè)試一般由軟件開發(fā)工程師【SWE】或者軟件測(cè)試開發(fā)工程師【SET】來實(shí)現(xiàn)，通常在運(yùn)行的時(shí)候會(huì)依賴模擬環(huán)境，當(dāng)軟件測(cè)試工程師【TEs】需要去診斷定位一個(gè)特定錯(cuò)誤時(shí)，會(huì)去篩選一些小規(guī)模測(cè)試集合并運(yùn)行來驗(yàn)證特定問題。對(duì)于小規(guī)模測(cè)試，主要集中在常見功能問題驗(yàn)證上，例如數(shù)據(jù)損壞、錯(cuò)誤邊界、發(fā)生錯(cuò)誤時(shí)如何結(jié)束等。小規(guī)模測(cè)試嘗試去解決的問題是，代碼是否按照其假定的方式運(yùn)行。

　　中等規(guī)模測(cè)試，可以是自動(dòng)化的或者手動(dòng)的，涉及到2個(gè)及以上功能模塊，特別是要覆蓋這些功能模塊之間交互的地方。有不少軟件測(cè)試開發(fā)工程師【SET】把這種測(cè)試描述成“測(cè)試一個(gè)函數(shù)，以及它近的鄰居們”【”testing a function and its nearest neighbors.”】。軟件測(cè)試開發(fā)工程師在獨(dú)立的功能模塊開發(fā)完畢后會(huì)驅(qū)動(dòng)進(jìn)行這種測(cè)試，軟件開發(fā)工程師是寫這些測(cè)試代碼、并調(diào)試和維護(hù)這些測(cè)試的主要力量。如果一個(gè)測(cè)試用例運(yùn)行失敗或者運(yùn)行錯(cuò)誤，相應(yīng)的開發(fā)會(huì)自動(dòng)地跳出來查看處理。在開發(fā)周期的后期，軟件測(cè)試工程師會(huì)運(yùn)行這些中等規(guī)模測(cè)試，可能是手動(dòng)的方式（如果很難或者需要投入比較大成本去自動(dòng)化的時(shí)候）或者自動(dòng)化的方式去運(yùn)行。中等規(guī)模測(cè)試嘗試去解決的問題是，一些相近的交互功能模塊組合在一起是否和預(yù)期一致。

　　大規(guī)模測(cè)試，涵蓋三個(gè)及以上（通常更多）功能模塊，描述終用戶的使用場(chǎng)景及其可能擴(kuò)展。所有的功能模塊集成為一個(gè)整體的時(shí)候需要去關(guān)心許多問題，但在谷歌，對(duì)于大規(guī)模測(cè)試，更傾向于著重結(jié)果，例如，這個(gè)軟件是用戶期望的那樣么？所有的工程師都會(huì)參與到大規(guī)模測(cè)試中，無論是使用自動(dòng)化還是探索性測(cè)試方法。大規(guī)模測(cè)試嘗試去解決的問題是，這個(gè)產(chǎn)品運(yùn)行地是否是終用戶期望的那樣。

　　小規(guī)模測(cè)試、中等規(guī)模測(cè)試、大規(guī)模測(cè)試這些術(shù)語本身其實(shí)并不重要，你可以給它們?nèi)∪魏文阆氲拿Q。對(duì)于谷歌的測(cè)試人員來說，有了這樣一個(gè)統(tǒng)一的稱謂后，可以使用這些稱謂來討論正在進(jìn)行什么樣的測(cè)試以及其測(cè)試范圍。有一些雄性勃勃的測(cè)試人員也會(huì)談到第四種測(cè)試，被稱為超級(jí)大規(guī)模測(cè)試，公司的其他測(cè)試人員可以認(rèn)為這樣的測(cè)試是一個(gè)非常大的系統(tǒng)級(jí)別的測(cè)試，涵蓋到幾乎所有的功能而且會(huì)持續(xù)很長(zhǎng)的時(shí)間，其他的解釋都會(huì)比較多余了。

　　哪些需要被測(cè)試及測(cè)試范圍的確定，這是一個(gè)動(dòng)態(tài)變化的過程，在不同的產(chǎn)品之間會(huì)有比較大的差異。谷歌更傾向于頻繁發(fā)布，從產(chǎn)品的外面用戶那里得到反饋之后再迭代開發(fā)。如果谷歌開發(fā)了一些產(chǎn)品，或者在已有產(chǎn)品上增加了新功能，會(huì)盡可能早地對(duì)外發(fā)布并讓外部用戶能使用并從中受益。在這個(gè)過程中需要較早地把用戶和外部開發(fā)者牽扯進(jìn)來，并要有一個(gè)很好的處理規(guī)則來驗(yàn)證是否滿足發(fā)布條件。

　　后，自動(dòng)化測(cè)試和手動(dòng)測(cè)試，對(duì)于所有的三種類型測(cè)試【小規(guī)模、中等規(guī)模、大規(guī)模測(cè)試】來說當(dāng)然更喜歡前者。如果能夠被自動(dòng)化，而且不需要任何人智力和直覺判斷，那應(yīng)該把它變成自動(dòng)化的。只有在特別需要人為判斷的時(shí)候，例如用戶的界面是否漂亮、或暴漏一些涉及用戶隱私的內(nèi)容時(shí)，在這些情況下應(yīng)該保留手動(dòng)測(cè)試。

　　話雖如此，對(duì)于谷歌來說非常重要的是仍然使用了大量的手動(dòng)測(cè)試，不管是使用文本記錄的方式還是使用探索性測(cè)試，雖然有些已經(jīng)進(jìn)入了自動(dòng)化測(cè)試的視線。業(yè)界使用的錄制技術(shù)將手動(dòng)測(cè)試轉(zhuǎn)變成自動(dòng)化測(cè)試，可以在每個(gè)版本后自動(dòng)地重復(fù)運(yùn)行，這樣保證了少的回歸工作，并把手動(dòng)測(cè)試的重點(diǎn)放在新問題上。而且，谷歌已經(jīng)將提交BUG的過程和一些手動(dòng)測(cè)試的日常工作也自動(dòng)化了，例如，如果一個(gè)自動(dòng)化測(cè)試運(yùn)行失敗，系統(tǒng)會(huì)自動(dòng)檢測(cè)到后一次代碼變更的信息，一般來說這是引起測(cè)試失敗的原因，系統(tǒng)會(huì)給這次代碼提交的作者發(fā)送一封通知郵件同時(shí)自動(dòng)創(chuàng)建一個(gè)BUG來記錄這個(gè)問題。在測(cè)試上，“人類智慧的后一英寸”體現(xiàn)在測(cè)試設(shè)計(jì)上，谷歌的下一代測(cè)試工具也正在這個(gè)方向上努力嘗試，將其自動(dòng)化。

　　這些工具在以后的文章中會(huì)被提及強(qiáng)調(diào)。不過，下一篇文章還是會(huì)將重點(diǎn)放在軟件測(cè)試開發(fā)工程師【SET】的工作上。希望能得到你的持續(xù)關(guān)注。