與軟體測試專家對談

IBM測試經理陳雅麗

在IBM測試經理陳雅麗的測試管理理念中，標準和流程處於重要的位置。標準和流程定義，也是測試工作的重要基石。測試是個集體性的工作，不但需要多方的支援，而且測試組內要協調一致，如果出現混亂對測試來說是個致命的打擊。

陳雅麗說，一件事情，既然要做，就要盡自己的所能，從這裡你就可以想像得出她在工作中的嚴格。而據我瞭解，她在換產品組的時候，有她原來的下屬員工申請去她的新組，可見她的魅力。

Sametime的測試專案經歷
蔡為東（作者，以下簡稱蔡）：請和我們分享一下你印象深刻的專案。

IBM測試經理陳雅麗（對談者，以下簡稱陳）：我做Sametime 時間長， 讓我印象深刻的專案也來自於它。Sametime 現在仍然在做版本的升級開發，產品壽命時間很長。你知道，對於一個軟體產品來說，在這麼激烈的競爭環境下，有10 年的壽命就很不容易，這就相當於人的長壽了。當初Sametime 是Lotus 買的另外一個公司的產品（後Lotus 又被IBM 收購），是關於聊天和會議的整合式軟體，在同類產品中是很先進的，因為它提供了線上溝通和會議並行的解決方案。

產品從Domino遷移到WebSphere

陳：2005 年，Sametime 做了一個很大的底層改進，從基於Domino 服務遷移到基於WebSphere server。這是一個很大的變化，相當於要做一個全新的產品。那麼，對於測試初期來說，最困難的工作是把測試環境建立起來。不然的話，測試沒法進行。在建立基於WebSphere 的測試環境的時候，我們遇到了難題，因為產品的品質和我們的技術能力的原因我們怎麼也作不起來。

怎麼辦？專案的進度是有要求的。我們當時把人分成兩組，一組人白天工作，一組人晚上工作。美國方面，一個QE 協助我們，幫助我們和美國的開發人員交流。但是，兩周的時間過去了，這個Deployment（部署）的難題還是沒有解決。

後來，終於有一個人率先把環境建立起來了。我們回過頭去分析，是什麼原因讓我們這麼長的時間沒有把環境建立起來呢？除了產品的不穩定和新技術的缺乏，我們還有自身的原因。當時我們有一個Setup 文件，裡面有詳細的步驟，工程師要去一步一步地去Follow，更重要的是要理解做每個步驟的目的。我舉個例子，有的步驟要求在host file 中去設置hostname，但是要保留空值，有很多的人看到這一步的時候都會憑自己的經驗去做一個判斷，然後按照習慣新增上主機名稱。這個小小的舉動，導致了全域的失敗。所以，第一個把環境建立出來的人，是一個優秀的測試工程師，他沒有被自己的經驗所誤導，而是理解為什麼要這樣做。他首先明白自己為何要這樣做，而不是簡單的照搬。

測試要根據實際情況做相應的調整

蔡：在這個Project 當中，你有什麼體會和經驗的總結？

陳：前面我提到了，這個專案中Sametime 做了一個底層的改變，並且是很大的變化，所以在某種程度上成為了一個新的專案。那麼，對於新專案，測試工作就要做相應的調整，去做配合。

對於成熟的產品，測試案例可以是那種大Scenario的，就是一個案例包括了很多步驟，相當於把代表客戶的使用場景走一遍。這種辦法拿到新專案來不行，因為專案在有了很大的變化之後，Bug 就會多一些，這樣你的Scenario 案例可能就會全部失效。在測試報告中，全部失敗既給開發方面施加了很大的壓力，也沒有表現出實際的專案進展，開發肯定會有所進展的，怎麼會一點進展都沒有呢？所以，對於新的專案，測試案例要細分到更小的功能點，這樣測試的結果中就有成功的，也有失敗的，這才是真實的研發進度。也能幫助開發人員瞭解他們的開發品質。

更重要的是合作

陳：另外，我們知道，測試是前後連貫的，有的時候測試案例前後有依賴性，一個失敗了，後面可能就全部被Block 住了。

蔡：對，這種情況下有的測試經理會偷偷笑，反正責任在開發方，就發一個報告出去，表示測試無法繼續，然後就等著。

陳：這樣有點像踢皮球，測試完全把事情推回給開發方。是不是真的沒有辦法繼續測試？測試方應當去找找Workaround，因為可能會有辦法繞過這一塊，從而讓測試繼續進行。在產品研發中，重要的是合作。我們隨時都要想到，怎麼才能推動專案的進展，而不是互相推脫或抱怨。

測試方如果在開發遇到問題的時候，旁觀等待，這樣會造成研發團隊內部的不和諧，也會影響工作的效率。我們去幫助開發，其實也是在幫助自己。你想，如果開發方延遲了交付，到最後一周才把可以測試的Build 做出來，測試的風險是很高的。

在這個專案上，我同樣感受到交流的重要性，在做軟體測試的專案中要多做有效的交流。

Sametime的Client端從C++到Eclipse的測試專案經歷

蔡：還有沒有印象深刻的專案？您這邊的經驗是非常寶貴的，我及讀者朋友都願意知道更多。

陳：好。這個專案同樣來自Sametime。具體時間我一下子說不準，那次是Sametime 的Client 端發生了很大的變化，從用C++ 程式設計移植到用Eclipse。另外，也新增了一百多個新功能。

新的開發工具加上新功能，這個專案的前期不大穩定。有的功能不穩定，有的功能甚至在不同的Build 裡時有時無，就是說這個Build 有，那個Build 沒有。

蔡：這對測試是個很大的挑戰啊，測試總是期盼一種穩定的狀態。

不要把時間浪費在等待上

陳：對，測試人員也感到很迷惑，這怎麼測試，因為沒有一個設計文件或需求文件可以參考？感覺沒有辦法開始做。測試專案天生就有些被動，在這種情況下，怎麼去進行控制？這是個問題。但測試肯定不能等，於是我去提醒team leader，無論如何不要等。等待的風險是很高的。

首先，我們主動和美國的開發人員交流，讓他們瞭解我們測試的困惑，希望能得到一個相對完整的功能列表。然後做測試，把發現的Bug 儘早交付上去。因為這些問題也是一個回饋，專案管理人員會根據這些回饋，而對專案計畫做一些相應的調整和修改。管理層可以根據當前測試的狀態，決定新功能的刪減，並評估專案計畫和時間。

有了問題，如果我們解決不了，一定要回饋到上一級。

另外，如果測試等待，等到Build 穩定了才進入，這樣開發方也會抱怨的，因為開發方Fix Bug 的時間少了。

測試工程師要盡全力去做好測試

蔡：在這個專案上你有什麼體會嗎？

陳：首先把工作當做你自己的事情，所以你就會更主動去解決問題。其次，我覺得，無論測試專案的大小，作為測試工程師的我們都一定要認真對待。透過你的手，讓軟體產品的品質有保障。設想一下，如果你能考100 分，但是實際只是得到了90 分，你會覺得冤的。測試是很重要的，對於一個軟體來說，軟體發佈了以後，再修改Bug 的成本是很高的，如你要做Patch，做測試，等等，成本高。當然，在實際的工作中，特別是在中小軟體公司，可能還是有一些朋友不大能理解測試的重要性。

推薦的測試管理方法

蔡：一個測試專案要開展，你有沒有麼推薦的流程或者方法？

陳：流程來說可能公司各有差異，我就說幾點管理方法。

關鍵字：及早介入

第一，測試人員可以及早地Involve（介入）到專案中。如果你在開發後期才進入，直接到了執行階段，就沒有時間去Training，去準備了。

當然，一個組一下子全過去不行，成本太高了。可以先讓幾個技術強一些的人進去，為小組做準備，對專案有一個全方位的理解。這種鋪墊會有利於制訂更合理的測試計畫，並瞭解開發每個階段的工作重點。

關鍵字：團隊建設

第二，Team Setup 也很重要。一個新的測試團隊建立之初，組員之間互相不大瞭解， 這個時候應當擬定一個完整的計畫書， 讓TeamMember 增進瞭解。

有的組員會做一天和尚撞一天鐘，只知道今天做什麼，不知道明天做什麼，這是管理上存在的問題，所以要加強專案的團隊建設，讓每個人都清楚專案的計畫和目標。

關鍵字：讓更多人參與

第三，做測試計畫的時候，可以讓更多的人參與進來，讓大家都有所貢獻，並對測試計畫有一個瞭解。

關鍵字：開好例會

第四，開好例會。每個小組每週都會有例會，泛泛而談Status 也會讓人感到枯燥，因此不要讓你的員工只帶“耳朵”來開會，要讓他們帶著問題來開會。我們要想辦法去改變會議的形式，關注效率和意義。

你要考慮到你要得到什麼，Team Member 他們能得到什麼。如果只是浪費時間地例行公事，不如去Run Case。有的老闆（註：外商中團隊負責人也被稱為老闆）能把大家調動得很好，那就是懂得了其中的技巧和藝術。

關鍵字：調節

第五，測試是重複的，枯燥的，團隊的主管要不定期地調節一下團隊的氣氛，讓團隊保持活力。另外，Leader 和Manager 保持團隊的士氣是很重要的。

關鍵字：做好總結

第六，做好總結。做了一個專案之後，我們拿出一點時間來，把經驗總結出來，這對於下一個專案很有好處。所以，即使是時間緊，也要拿時間出來進行總結。

微軟資深軟體測試經理周慶輝

微軟資深軟體測試經理周慶輝在微軟做測試工作已經超過10年，他提醒各位測試工程師要有程式設計能力，在學習的時候要以開發工程師的標準來要求自己；並希望測試團隊的管理者要去瞭解公司的商業目標。他建議在中小軟體公司做軟體測試的朋友，在制訂測試方面的流程的時候，要具體情況具體分析，而不要照搬大公司的做法。在實行自動化測試方面，也是建議大家逐步推行，量力而行。

Windows Media Player的測試專案經歷

蔡：請你舉例說一下你印象深刻的專案。

微軟資深軟體測試經理周慶輝（對談者，以下簡稱周）：我在美國微軟總部雷德蒙的時候，當時是以做技術為主，Windows Media 是一個有代表性的、令人印象深刻的專案。

從一般意義上講，測試對開發的確有一定的依賴性，但在這個專案組中，我體會到，測試不是純粹被動的。例如，如何來證實產品的正確性。我們當時就遇到了挑戰：如何確定播放出來的音樂是正確的？如何確定播放出來的Video 是正確的？

我們可以做自動化測試，可是自動化的難點是Verification（驗證）。我們可以事先準備一段特殊的Video，但是如何驗證在做自動化測試的時候它被正確地播放了呢？如何排除Noise 呢？如何去開發測試工具，不光是測試團隊用，開發團隊也可以用？這些都是挑戰。

蔡：的確，驗證聲音和影像播放的正確性的確挺難的，那又是怎麼解決這個問題的呢？

周：那都是多年以前的事情了，我以播放Video 為例。我們在測試中需要驗證Frame rate 是否正確，內容是否正確等等。我們是這麼做的，把畫面劃分為小的區域，透過一種特殊的提取和演算法分析，再把得到的結果與檔案中的Block 進行比較，如果相似度很高，那說明播放是正確的。區域的大小可以調節，一般我們用4×4=16 個Block。如果你想更精準，當然Block 要劃分得更小一些。這樣，測試就不需要總是一個人去盯著螢幕了。

當然，人工觀看也是必要的。在一個Test Pass 之中，我們會有選擇性地由測試工程師來實際觀看播放的效果。人工的參與也可以驗證測試是否正確。

CWA的測試專案經歷

蔡：這是技術類的專案，是不是在管理方面也有印象深刻的專案？

周：管理類的專案中，CWA（Communicator Web Access）是有代表性的。專案啟動的時候，我們面臨著諸多挑戰。例如：

1. 這是一個1.0 版的產品，沒有以前的累積。

2. 測試的要求高，覆蓋面廣，功能測試、性能測試、安全性測試，等等，都覆蓋到了。

3. PM 都在美國，而不是本地，這在溝通上就是一個挑戰。

4. 測試組要從頭組建，並要帶著大家學習和掌握微軟的測試方法和開發流程。

5. 要建立測試Lab。

另外，CWA 是基於瀏覽器的，測試當中的OS 和Web Browser 的Matrix 很大，如何在有限的時間裡做好測試，如何排定優先順序，這也是挑戰。

如何尋求好的自動化測試的方法？當時MS 內部針對Web Application有不同的實現辦法，我們也需要做一個借鑒，然後透過自己團隊的探索，開發出適合CWA的測試框架來提高測試效率。

我做測試團隊的管理工作，從管理者的角度需要重點關注什麼，如何做好與總部團隊的溝通，這些都是挑戰。

測試要提供資訊，要儘早介入

蔡：你有多年的測試經驗，你對軟體測試的理解是什麼？

周：測試首先是要提供資訊。軟體研發的進度如何？進展到什麼程度？是否達到了預期的目標？大家透過這些資訊去推動專案，我們測試要為高層管理者提供決策的依據。

測試工程師要從用戶的角度來做工作，這是對的。但是，使用者可能希望軟體100%正確，完全沒有Bug，即Bug Free；而公司的資源卻是有限的，所以測試也要設定好自己的目標，因為一家公司是有商業目標的。

另外一個，也是測試的一個主要的作用，是要儘早、盡可能多地去發現問題。測試人員要儘早進入專案中，發現問題。問題發現越早，成本越低。我們也要推動整個團隊的Process達到高品質測試的要求。

制訂測試流程的時候要具體情況具體分析

蔡：我知道，很多大的軟體公司都有自己的一套相對完整的測試流程，但是國內的中小軟體企業卻不一定有，他們也很想聽到這方面的建議。在這方面你所推薦的測試流程是什麼？

周：這要看公司的具體情況。不同的公司，有不同的做法，要根據公司的承受能力來確定。對於中小公司來說，可以循序漸進地來做這件事。最開始的時候，公司可能也是剛開始引入測試角色，測試人員可以做一些End to End 的測試，就是一些大的場景測試，觀察主要的功能是否正確，是否能連貫地走下來。這樣，可以推進開發工作，並且發現了Bug 後，很容易知道問題出在什麼地方。

蔡：也就是說，你的意思是把重點放在主要功能上，保證一些主要的使用流程能走通，然後再逐步細化，是嗎？

周：對。在這之後，可以做功能測試，詳細一點的。然後，性能測試、擴展性測試、相容性測試，等等。如果你的產品準備賣到海外市場，還要做Globalization 測試，即當地語系化測試。如果你的人力有限，你不要一下子搭一個很大的架子，不要等整體的架子搭好了再去做測試。你還是要根據自己的實際情況先把事情做完。

手動測試、手動去做Verification，也是一種方法，在開始的時候不要花很長時間去做測試工具。等公司有了一定的累積以後，再引入或者開發Bug Tracking 工具、測試工具等等。

沒有依據，怎麼衡量

蔡：對於一些測試團隊的負責人來說，有一個難題就是如何把握軟體的品質。可能有的是老闆會經意或者不經意地問問：“軟體現在測得怎麼樣？軟體怎麼樣？”這個不好回答。

周：對於這個問題，測試負責人要先解決另外一個問題：當前的軟體產品的定位是什麼？

軟體應當有詳細的功能列表，各種功能參數，要做到什麼程度都要有定義，然後測試要儘早介入。這些都是軟體專案的Goal，而且是各方面都認同的目標，衡量的時候就以這些為依據。不然的話，沒有依據，怎麼衡量呢？

如果這個軟體的定位是搶佔市場，不讓競爭對手爭了先，那麼它的要求就會低一些，因為要儘快上市。只要能在一定程度上滿足客戶的要求就可以了。如果是要把這款軟體做強，與已經存在的競爭對手去競爭，那要求就不一樣了。例如，如果有一個Goal 是軟體持續執行500天，這個目標對於一個只是搶佔市場的產品就不大適合，因為客戶可能也只是先試試，沒有這方面的要求，或者說在這方面要求比較低。

如果沒有具體的Goal，你會很難衡量的。有了Goal之後，你就能知道當前軟體的主要問題是功能問題還是GUI的問題，你也好回答老闆的問題了。

另外，只要你帶著團隊認真地測試過一遍，你對產品就會有清晰的瞭解。這個時候，如果老闆來問，你就能很好地回答了。（摘錄整理自第七、八章）

關於軟體測試人員生涯規畫的建議

Q 蔡為東（作者）：在軟體測試行業做了幾年的朋友，如果他/ 她是用心的話，就會開始考慮個人的職業發展規劃。這個問題也挺難的，大家都覺得個人規劃不好定，我想聽聽你的建議。

A 陳雅麗（IBM測試經理）：我們要確定一個方向，那就是要做得更好。對於一位測試工程師來說，如果你在電腦技能上還有所欠缺，要去補課。例如，自動化測試技能，有沒有這個技能是相差很大的。

測試工程師也應當學一些開發語言，如Java。理工科的人去學習開發語言不會很難，因為畢竟也就是一個工具，不會很難的。

軟體測試工程師應當保持這樣的傾向：總是多瞭解一些。在廣度和深度上，多瞭解自己的產品，對於相關的產品也要有所瞭解。你看，有一種職位——Test Architect（測試架構師），他/ 她就要去定義測試的全過程，確認一個專案的投入和產出。如果沒有廣泛而深入的把握，是沒有這樣的能力的。

A 周慶輝（微軟資深軟體測試經理）：我個人的看法是，制訂個人發展規劃的時候要考慮到很多的因素，無法一概而論。例如，自己到底喜歡什麼？如果不喜歡測試，那可能就不大願意繼續在這一行發展。如果你喜歡軟體測試，那就要看，是想在技術上繼續發展，還是管理上？
如果是在技術這條路線上發展，以後可以往測試架構上去發展（在大型的軟體企業裡，會有軟體測試架構師的職位）。

做測試的優勢：轉做相關工作不是很難

做測試還有一個優勢，就是轉做其他工作也不是特別難，例如三四年以後。測試廣度的要求對一個人有利，是一個優勢，你從頭到尾測試了這個產品，對產品是比較瞭解的。你做了幾年的測試，也有可能去做其他的行業，例如專案管理，因為測試在日常工作中與很多團隊都有接觸和合作。瞭解多了，你對專案管理的工作自然也不陌生。轉做開發也可以

自己擅長什麼

做了三四年的軟體測試以後，你對自己擅長做什麼要有所瞭解，對於自己希望達到什麼程度也要瞭解清楚，這對於確定自己的職業發展方向很有幫助。

 

贏在測試

軟體測試專家之道

蔡為東／編著

松崗出版

售價：420元