51Testing專訪史亮：測試人員在國外

不久前，我接受了51Testing的訪問，討論了軟件測試的一些問題。如下是全文。

 

一、史亮老師，做爲咱們51Testing的老朋友，能和咱們說說您最近在忙些什麼嗎？

自2011年起，我加入Microsoft Office部門，參與了Microsoft Office 2013的研發，主要工做是測試Windows版本的Office產品。目前，我正參與研發下一代的Microsoft Office，主要工做是測試產品和開發測試輔助工具。

今年，個人新書《軟件測試實戰》問世。這本書基於一個很樸素的想法：我在軟件測試領域有較多的積累，若是將個人所學所知分享給更多的測試工程師，想必能幫助他們節省學習時間，更快地提升測試水平。 在該想法的驅動下，我研究了測試文獻，反思了自身實踐，並持續地寫做。一方面，我總結了測試專家的看法和方法，將其精華內容綜述在本書之中，另外一方面，我努力將本身的經驗和反思融入書稿，使它體現出我在實際工做中使用的策略、方法和技巧。總之，這是一本注重實效的書，嘗試用理論結合實踐的方式來解決現實的問題。

 

二、您在國外工做了一段時間，您認爲國外公司和中國公司最大的不一樣在哪？讓您感覺最深的又是什麼？

我認同語境驅動測試（Context Driven Testing）的觀點：測試實踐的價值來自於它的語境。除了測試人員的態度和能力，產品、項目和團隊對測試實踐有最大的影響。所以，我在撰寫《軟件測試實戰》一書時，重點討論了測試人員如何研究產品（第7章）、研究項目（第8章）和融入團隊（第9章）。這些內容並不針對特定的企業或項目，而是嘗試提供一組方法，幫助測試人員瞭解當前的項目語境，以設計出高效的測試策略。

在我看來，國內的軟件行業蓬勃發展，軟件項目呈現出多樣化、差別化的特色。有些企業充分利用全球信息，致力於世界級的產品和服務，其企業文化和工做方式與外企並無太大的差異，甚至在許多地方處於領先位置。

從另外一個角度看，不存在「最好的工做方式」，只存在適合當前項目語境（市場環境、產品元素、產品質量、項目團隊）的「好的工做方式」。因此，一個好的團隊是一個「自學習、自組織」的團隊，可以從工做中持續學習經驗與教訓，並逐漸調整工做方式，經過動態適應變化的環境來優化項目成果。在成功發佈的過程當中，團隊成員的能力獲得發展，團隊擁有更強的凝聚力。不管在哪裏，技術人員都應該尋找這樣的團隊，或讓本身所在的團隊成爲這樣的團隊。

 

三、您在國內和國外都有至關豐富的測試經驗，您是如何看待國內外軟件測試行業的發展趨勢的？

爲了更好地討論這個問題，先介紹一個測試技術分類的參考模型。測試專家Lisa Chrispin和Janet Gregory在《敏捷軟件測試》中將測試技術劃分到如圖1所示的四個象限中。

圖1 敏捷測試四象限

• Q1：面向技術的（technology facing）、支持項目團隊的（supporting the team）的自動化測試，例如單元測試、組件測試等。
• Q2：面向商業的（business facing）、支持項目團隊的自動化和手工測試，包括功能測試、樣例、用戶故事測試、原型、模擬等。
• Q3：面向商業的、考驗產品的（critique product）的手工測試，包括探索式測試，情景測試、可用性測試、用戶驗收測試、Alpha及Beta測試等。
• Q4：面向技術的、考驗產品的、基於工具的測試，例如性能測試、負載測試、安全性測試、屬性測試等。

利用敏捷測試四象限，測試人員能夠快速理解測試技術在軟件開發中的位置，並根據當前任務選擇合適的測試技術。不過，我並不一樣意Lisa Chrispin和Janet Gregory將探索式測試（exploratory testing）置於Q3象限。探索式測試是一種並行地實施測試學習、測試設計、測試執行和結果評估的測試風格。做爲一種測試思惟方法，它能夠指導四個象限的任何一種測試技術的使用。

目前，軟件行業高速發展，之前所未有的速度向各個產業滲透。在互聯網應用、移動應用、物聯網應用等重要領域，市場競爭日趨激烈。爲了在競爭中脫穎而出，軟件項目團隊必須具有高度的機動性，可以快速地嘗試新想法，並持續發佈具備特點的產品。這要求程序員負責更多的測試活動，經過加速「編碼—測試—重構」的循環，來快速交付高質量的代碼。也就是說，程序員將承擔Q1象限（面向技術、支持項目團隊）的測試工做，以及部分其餘象限的活動——以Q2象限（面向商業、支持項目團隊）的活動較爲常見。

在該趨勢下，專職測試人員的活動將向四象限的右側和上方移動，更偏向面向商業的、考驗產品的測試活動。從業務角度，測試人員的角色應該是領域專家和實際用戶，可以以超越代碼（beyond code）眼光來考察產品的商業價值和用戶價值。從技術角度，測試人員的角色能夠是黑客和技術專家，可以在安全性、性能、穩定性等領域實施專業的、高強度的測試。

另外一個軟件研發的趨勢是DevOps，即融合研發團隊和運維團隊，由一個團隊負責整個產品開發、測試、發佈、運維和更新。在此類團隊中，測試人員須要承擔部分開發和運維任務，例如分析服務端的日誌、分析客戶端提交的遙測（telemetry）數據、分析用戶行爲、報告服務狀態、定位產品問題、修復特定環節的錯誤、發佈產品更新等。這意味着測試人員的工做不只僅是尋找缺陷，而是經過技術調查（調查對象包括已發佈的線上產品）來得到產品信息，以持續提升產品質量。能夠說，在一些項目環境中，測試人員的職責發生了變化，須要更多樣化的技能。測試人員須要積極面對變化，拓展本身的能力，以適應行業的發展。

 

四、怎麼才能進行有效地探索性測試？另外不少優秀的軟件測試工程師都能敏銳地嗅到bug，您認爲該如何訓練這方面能力？
首先，「態度決定一切」。成爲一個優秀的測試人員，我認爲最重要的基礎是對項目、對本身負責任的態度。對項目負責，測試人員須要提供高質量的測試服務來幫助項目成功；對本身負責，測試人員應該以專業人員（professionals）自居，堅持專業主義（professionalism），追求精湛的技藝和卓越的成果。這須要經過日復一日的努力工做來落實，無捷徑可言。

第二，Cem Kaner等測試專家指出「困惑是一種測試工具」。有時，軟件的表現出乎測試人員預料，可是他並不能肯定這是一個缺陷。這說明測試人員對軟件的設計還有不瞭解的地方。他應該將此疑惑視爲一個學習的機會，經過閱讀文檔、諮詢同事等方法來得到答案。推而廣之，若是測試人員對軟件、技術或項目產生疑問，他應該感到警戒。這可能意味着他不瞭解業務邏輯，不知曉產品設計，不清楚實現細節。這些知識上的漏洞會致使薄弱的測試設計和嚴重的缺陷遺漏。

負責人的測試人員不會放過任何一個疑問，在「好奇心」的指引下，他會「打破沙鍋問到底」。他會運用多種手段（周密測試、代碼分析、軟件調試、文檔閱讀、請教專家等）對問題進行研究。經過積極地測試和學習，測試人員不但能夠彌補知識的漏洞，還能夠發現隱藏的缺陷。

第三，測試人員須要「刻意練習」。測試專家已經給出了許多好的建議和方法，這些想法皆來自於實踐。軟件開發專家Ralph E. Johnson 指出「從實踐中來的知識在沒有實踐以前是沒法被真正理解的」（practical knowledge has to be experienced to fully understood），測試專家Cem Kaner等也認爲「你不能掌握測試，除非你從新發明它」（You can’t master testing unless you reinvent it）。所以，測試人員須要將學到的新技術應用於真實的測試，並認真評估其效果。經過練習、評估和反思，測試人員可以掌握方法的原理和細節，並混入自身經驗和其餘技術，以演化出新的方法。堅持這樣的研究和創新將幫助測試人員走上精通之路。

 

五、您認爲如何作一名優秀的軟件測試工程師？他至少具有哪些技術能力？

《軟件測試實戰》的目錄（點擊連接，在彈出頁面中點擊「顯示目錄級別3」，能夠查看完整的目錄）概述了測試人員須要考慮的專業能力。在此，我作簡要的介紹。

• 第2章，缺陷報告：提交高質量的缺陷報告，盡力讓缺陷獲得修復。
• 第3章，測試文檔：在測試的迭代過程當中，發展出實用且多樣的測試策略，將測試設計和測試結果的核心信息記錄爲一組精要的文檔。
• 第4章，測試建模：創建產品的模型，以指導測試設計。
• 第5章，測試技術：掌握多種測試技術和測試先知，並結合項目狀況多樣地選擇測試技術。
• 第6章，測試開發：掌握開發技術，以高效地實施自動化測試、計算機輔助測試和超大規模自動化測試。
• 第7章，研究產品：利用靜態分析研究產品源代碼，利用動態分析研究產品行爲，利用業務分析研究理解關係人和領域，從而得到更有針對性的測試設計。
• 第8章，研究項目：熟悉項目團隊、研究項目元素、分析項目風險，從而得到更注重實效的測試設計。
• 第9章，團隊工做：創建正確的價值觀，積極融入團隊，並經過有效的測試管理、軟件估算、軟件度量來爲團隊服務。
• 第10章，我的管理：積極實施時間管理，經過持續學習和且行且思來逐步成爲測試專家。

面對如此多的內容，一條值得參考的指導原則是，肯定項目團隊或所在領域最須要的技能，而後努力掌握它們。對於此類知識，經過實際工做來掌握是一種比較好的學習方法。這樣作能夠加速獲取知識與應用知識的循環，並讓學習成果當即幫助測試過程。成功的應用可以加強測試人員的信心，鼓舞他更深刻地研究。

 

六、您認爲在測試中如何提升本身的測試思惟和測試技術？

問題4和問題5的回答對於本問題有參考價值。在這裏，我補充說明一個測試人員容易忽略的要點：提升測試技術的根本目標是爲了更有效的測試，在許多狀況下，測試效果（測試技術的實施效果）決於測試人員對軟件和項目的理解。

我曾經長期測試一個網絡應用。當我離開這個項目時，測試經理安排一個測試員工來接替我。他剛剛入職，對被測軟件和業務領域都不瞭解，在工做中遇到了許多困難，我幫助他解決了一系列問題。做爲一個測試工程師，個人工做效率更高，主要緣由包括：

• 我理解產品，知道它的業務目標，瞭解它經過什麼方法去實現目標。所以，我可以快速地制定測試方案。
• 我理解用戶的指望，知道哪些功能絕對不能出錯，須要仔細測試。我也知道哪些功能容許一些瑕疵，即使出錯，也能夠在三個月以後發佈的下一個版本中修復。所以，我可以更好地分配測試時間。
• 我理解產品的架構，閱讀過大部分模塊源代碼，知道哪些模塊容易出現哪些缺陷。所以，我能夠針對不一樣的模塊採用有針對性的測試策略。
• 我曾經嘗試自動化測試用戶界面，可是發現此類自動化測試很不穩定，須要很高的維護代價，卻不能發現錯誤。因而，我只爲Web服務編寫自動化測試用例，用手工測試來檢查用戶界面。所以，我回避了浪費時間卻沒有收益的任務。
• 我瞭解產品元素和項目團隊。當出現缺陷時，我知道如何閱讀系統日誌發掘蛛絲馬跡；當我遇到困難時，我知道向哪位程序員或測試人員求助。所以，我能夠深刻挖掘並快速推動。
• 我在原先的團隊工做了很長的時間，與同事們保持了良好的關係。當我提出一些可測試性的建議時，比較容易受到程序員的支持。

從以上幾點不難看出，我可以更有效地測試，其主要緣由不是我掌握更多的測試技術，而是我更瞭解軟件產品、業務領域和項目環境。經過逐點分析，能夠獲得以下啓示。

• 產品是一種解決方案，若是沒有解決問題，它就是無用的。測試人員須要瞭解軟件產品和業務領域，才能設計有效的測試。
• 測試是一種信息服務，要了解服務對象（一般最重要的服務對象是用戶和項目經理）的需求。若是用戶不能容忍某些錯誤，測試人員就須要仔細測試相關功能；若是用戶對一些瑕疵並不在乎，測試人員就沒必要在此花費更多的時間。只有瞭解服務對象的優先級，才能更好地設定測試工做的優先級。
• 不一樣的模塊採用不一樣的技術，擁有不一樣的典型錯誤。只有瞭解軟件實現，才能設計差別化且有針對性的測試用例。
• 測試設計可能包含錯誤，測試人員須要從錯誤中吸收經驗和教訓。避免一些已知的錯誤，會提升測試效率。
• 當測試工做遇到困難時，測試人員須要知道在哪裏尋找信息。瞭解產品可以提供的信息、瞭解哪位同事知道更多內幕，會節省時間。
• 「人脈」有時候會極大地提升測試人員的工做效率，測試人員須要和程序員和測試同事保持良好的關係。達成協做關係的關鍵之一是測試人員可以爲同事們提供高質量的信息服務。
• 在職業生涯中，測試人員老是會遇到新的軟件、項目和團隊。他應該培養一種好的工做風格，以求快速地理解產品和項目。

實施高效的測試須要不少條件。熟練地掌握測試技術是一個很重要的因素，但不多會是決定性的因素。只有充分地掌握軟件產品和項目環境，測試技術才能找到大放光彩的舞臺。

 

七、您能給想學習探索式測試的新人，給推薦幾本書？

探索式測試是一個內涵豐富的主題，感興趣的測試人員能夠從如下書籍入手。

• Cem Kaner, James Bach, Bret Pettichord, 《軟件測試經驗與教訓》（Lessons Learned in Software Testing：A Context-Driven Approach）。該書是語境驅動測試的經典著做，充滿對軟件測試的真知灼見，系探索式測試者案頭必備。
• 史亮，高翔，《探索式測試實踐之路》。該書由我與淘寶資深測試工程師高翔合著，系統地總結了現有的探索式測試實踐，並歸入了咱們的經驗和反思。探索式測試大師James Bach對此書予以了確定：This is the first book on exploratory testing, in any language, that summarizes the published work in the field。
• 史亮，《軟件測試實戰》。我本人是探索式測試的忠實實踐者，該書可視爲「一個探索式測試者的自我總結」。全書雖然沒有強調名詞「探索式測試」，可是探索式測試的核心精神（將測試學習、測試設計、測試執行、測試結果評估做爲相互支持的活動來並行實施）貫穿全書。
• 我和高翔在《探索式測試實踐之路》的附錄B提供了一批推薦讀物，供讀者參考。