計劃測試系列

（三）——人

在本系列文章中的第一篇，筆者就提到了計劃的實質是“特定的人在特定的時間在特定的地方做了特定的事情以實現特定的目標”,在上一篇文章的回復中，土豆老粗回復了對于測試計劃的看法，也就是5W1H定義：
> WHY：為什么要寫測試計劃；
> WHAT：測試什么；
> WHEN：測試不同階段的起止時間；
> WHERE：文檔放哪；
> WHO：哪些人去做；
> HOW：怎么測試；

這個定義相對于我的來說，對于測試計劃定義得更加詳細。不過，正像筆者在博客簽名中所宣稱的那樣：來自草根的實用主義。因此，5w1h定義就不適合三五個人十來桿搶的軟件作坊了。對于很多剛剛起步測試活動（近兩年才擁有“專門測試人員”，注意是“專門”而不一定是“專業”）的公司來講——而這種公司，就筆者接觸的一些同仁口中所述，在中國還不在少數——或許一些簡化版的東西會更適合現在的他們，等到漸漸成長起來，我們才逐漸步入正軌。本文中筆者繼續自己的草根實用主義，分享自己的關于計劃測試活動中人的一些拙見。

這陣子軟件相關論壇上都多多少少有人提到了工具與人的關系，在筆者看來這是一個很扯淡的問題，人的作用是不可能被工具取代的，人之所以為人而不是跟其他動物一樣處于原始的生存狀態，是因為人會“使用”工具。不過關于人和工具的那點兒事，則是后話了。

中國有句老話“養兵千日，用在一時”。這句話往往是在臨戰的時候將軍（測試負責人）對戰士（普通測試人員）說的。中國古代還有一個方法叫做“戰時兵閑時農”的策略，即我們廣大的勞動人民在沒有戰爭的時候安心種我們的地，一旦戰爭爆發或者國家需要的時候我們就披上盔甲去作戰。這兩句話給我們一個提示：我們應該培養我們的測試人員或者說我們的測試隊伍。

先拿“養兵千日用在一時”來講，正如我上面提到的，往往在臨戰的時候大家才想起這句話，可是我們不妨倒過來想一想，一時的用是需要千日的積累的。這也是在提示我們，一支優秀的測試隊伍的每個人都應該是優秀的并且我們需要在“用一時”之前好好“養千日”。這種積累不是一天兩天可以形成的，正所謂冰凍三尺非一日之寒。為什么要在談論計劃測試的時候談論這個問題呢？原因在于“巧婦難為無米之炊”，我們在做計劃的時候如果發現沒有一個可用之才，那我們的計劃怕是做不下去了，或者我們只有準備另外招新人到行伍中間來，亦或者只能外包測試給專業隊伍，這無疑又增加了項目的風險，因為新人或者其他隊伍使我們不了解的，他們會做成什么樣子只有老天知道，當我們把命運交給老天的時候，這相當于在玩火。我們需要把“養千日兵”拉到我們的計劃中來，從更加長遠的角度來計劃一下我們的測試工作，測試方向等等。對于人才的培養，一般使用的是人盡其才的分工制度，即某一個或者一些人熟練掌握某一些測試技能，并對其他技能有所了解，最理想的情況下，我們在測試的方向（或者說是本公司主要的開發方向相關聯的各個測試技術方面）都有“專家”，這樣才可以保證一個測試隊伍可以應付不可預知的測試任務。

對于草根一族來講，一開始公司很可能就你一個測試人員，有幾種情況：

> 公司將“建立一支專業的軟件（測試）隊伍”的艱巨任務寄托在你身上時，先不要沾沾自喜襲擊已經被boss重視了；

> 公司只是拿你來標榜自己擁有了測試，拿你來寫測試計劃，測試報告等提交給客戶看的文檔的專業測試——文檔——人員

上面兩種是比較常見的情況，在筆者看來，這兩種情況都很好創造了給你學習的機會，第一種情況你可以打著公司的“建立一支專業的軟件（測試）隊伍”旗號學習；第二種情況來講，如果僅僅是寫文檔的話，那剩余的時間就可以好好利用下來了，而目的在于你想提高自己的技能。而我們的學習方向，筆者大概歸納一下：

> 測試理論（包括測試基本概念，流程，管理等等內容。對于測試來講，這才是基本）

> 測試文檔 （雖然網絡上的文檔中的內容對于目前的你來說不可能完全有用，但是知道一份專業或者說完整的文檔是怎么寫的也是必要的）

> 測試工具（對于剛起步的測試人員，如果你不是開發大牛，建議你還是先使用別人已經寫好的工具）

> 開發知識 （有則加之，無則添之，總是是要學，因為這一點是為將來打算，這些知識有助于我們更好地測試）

筆者在文章開頭提到了人與工具的問題�，F在各種各樣的測試工具很多，有關于性能的測試工具，有關于功能自動化的測試工具等等。不過昨天看到一篇博文，博文作者深感當前幾乎所有人討論的問題都是測試工具怎么用，而關于測試工具開發相關的帖子卻很少，筆者也認為這是一個不正常的現象。的確，對于大多數軟件項目組來講，自己開發一個性能測試工具并不是一個現實的想法，又鑒于性能測試的重要性，在測試組中擁有掌握主流性能測試工具的專家是很迫切的需求。如果可以的話，我們擁有自動化測試工具的專家，我們擁有自動化測試工具自主開發的專家等等這些都是很有用的。不過這些專家的培養的順序也要順勢而行，不僅急不得而且也急不了。

當一個優秀的測試團隊成立起來之后，“米”的問題就解決了，這個時候再來針對某一個具體的項目考慮怎樣“炊”的問題就簡單很多了。簡單，并不代表可以不費吹灰之力就可以把事情擺平了。要知道，人是一個復雜的動物，人的心情會有陰晴圓缺，人會有喜怒哀樂，關于這些跟技術不搭調的問題筆者就不扯了，畢竟筆者的人生閱歷還沒有精彩到可以教讀者怎么做人的地步~關于計劃測試中人有關的話題，在本系列的后續文章中會結合“特定的事”“特定的時間”等等繼續探討。

（四）——地

正所謂，天時地利人和，前面的一片里面筆者花費了大堆口水在“用兵一時，養兵千日”的怎么“養兵”和“兵”自己怎么實現自我修行。 人有了，該是考慮“地利”的問題了。所謂地利，即指軟件的測試環境，這與開發環境有著很大的不同，同時也保持了一定的聯系（廢話）。

測試不會憑空出現，正是因為之前有過太多的教訓，人們開始對質量重視起來。從這個意義上來講，相關組織是為了避免損失而測試，而減少支出其實是賺了錢，所以他們進行測試是為了獲取利潤的。從另外一個方面來看，測試也要投資，而測試環境則在這些支出中免不了分一杯“羹”。

先看一個筆者趕制的一個草圖

對于上面的圖，簡單說明一下，或者“按圖索驥”吧。 在我們計劃測試的過程中，我們使用由頂向下的分析策略。

所謂測試環境（我們這里指的是物理意義上的環境），對于軟件測試來講“咔嚓”一聲分成兩半：硬件環境和軟件環境。

把硬件環境拿出來講，包括了測試項目依賴的硬件環境，測試工作本身依賴的硬件環境。

所謂測試項目依賴的硬件環境，舉例來講我們測試一個手機操作系統，總得要拿出個手機來試一試吧；如果拖拉機也需要軟件配備，那么一臺拖拉機也是需要的，另外還需要弄一個庫房或者至少一個空地來放這個拖拉機；所謂測試工作本身依賴的硬件環境，至少得一臺測試用的機器吧，對于特殊要求，比如開發一個嵌入式程序用來監控室內二氧化碳的濃度，這個時候一個特殊的工作室可能也是必要的，至少有一個工具可以改變二氧化碳濃度，有個地方可以困住這些二氧化碳吧。關于機器，我們還需要考慮到機器的配置等等問題。

接著就是軟件環境了，跟硬件環境一樣，包括了測試項目依賴的軟件和測試工作本身依賴的軟件，當然最重要的是要有個操作系統，還要搭上待測的應用程序。

關于待測應用程序就不講了，想想如果沒有待測程序那我們還測什么啊，是不？測試項目依賴的軟件，這里面的彎彎繞就顯得多了一點了。首先，待測程序引用或者操作的一些應用程序得準備齊整，比如說某應用程序用于監測某個人每天打開了多少次Outlook并收發了多少郵件，如果機器上沒有裝上outlook的那我們就只能測試沒有outlook下該應用程序的的表現這一種情況了，雖然這也是一個很重要的用例，但是更多的有用的用例還是需要我們配備上outlook來測測的。其次待測程序運行的平臺，.NET開發的你總得安裝上相應的.NET Framework吧，web應用程序沒個瀏覽器也是不行的。

測試工作本身依賴的軟件，說明白點主要就是測試工具了，這里面的彎彎繞太多，筆者就不繞進去了。

操作系統，對于基于windows操作系統的軟件，我們就需要考慮到微軟這些年來給我們貢獻的這么多版本，如果考慮到其他操作系統，我們就不得不考慮到蘋果等等的貢獻了。

總結一下，對于測試人員來講，在項目里面不需要考慮到所有的部分（圖的葉子部分），但非葉子節點部分還是得好好琢磨琢磨。對于開發人員來講，比較常出現的一個情況是軟件工作的環境問題：應用Team Foundation管理團隊項目的時候，項目開發人員A引用了外部DLL（假設為C.DLL），當簽入源代碼的時候這個DLL是不被簽入到TFS上的，這就會導致服務器上的版本編譯不通過，提示無法找到DLL之類的錯誤信息。這是一個常見的環境錯誤。另外，如果項目組成員使用的開發環境不一致，也可能導致應用程序集成失敗或者BVT運行不通過；如果開發團隊開發環境一致，那么在對應用程序有兼容性要求的時候，相關的系統兼容性測試是必需的。

（五）——時

到了“時”了，這是計劃測試過程中最讓人糾結的地方了。計劃本來就是一件很麻煩的事情，關鍵點就在于計劃的時候很難拿捏準時間的長度。在一本稱之為《軟件工程中的事實與謬誤》的書籍中，作者提到一條軟件項目走向失敗的兩大因素中的一條就是估算不準，由此可見計劃之難了。Aaron現在對于時間計劃搞得也是沒模沒樣。

初一的時候計劃在十五月圓之夜一起賞月對飲，可是天有不測風云，到了十五那天天氣轉陰了，月亮連個影子都沒有更不要提月圓了。在項目中也會經常遇到這種情況，我們預計某年某月某日我們實現某項功能，可是等真的到了那一天，才發現原來我們想象中的那項功能依然只能存在與想象之中了。

那我們怎么做時間計劃呢？ 在Aaron看來，因項目性質而異，要知道我們從事的項目大致可以分為兩種：產品性質的和外包性質的。這兩種性質的項目對于時間的要求，對于測試強度的要求是大不一樣的。

對于一般外包項目來講，對于測試要求相對較低，而時間是固定的。當前大多數標榜使用螺旋開發的團隊其實只是變相的甚至是變質的瀑布模型，對于測試的現狀更是如此。測試先行，測試與項目同時啟動在大多數項目中都只是一句口號而已，因為大家心里都明白，口號是不要錢的，所以空喊口號這種最廉價的朝臉上貼金的方式廣受軟件作坊主們的歡迎甚至推崇。廢話不扯了，對于這種項目的測試工作來講，一般是標準的段段式的，即計劃測試，測試用例設計，測試用例執行及bug管理，測試報告提交等等階段。這就好弄多了，根據經驗（如果一點經驗都沒有，那還有直覺）我們把這幾個階段換算成比例，然后把測試總時間瓜分了，需要提醒大家的就是記得在瓜分之后留點“緩沖時間”來，否則到時候出了點意外就麻煩了，記住是在每段時間之后加上一個緩沖期，而不是最后加上一次。

對于產品來講，測試要求會比較高，時間當然也是需要考慮的，套用IT界最常被引用的一句話，“在這個瞬息萬變的時代”，把握時機對于一個產品來講無疑是很重要的。不過，由于眾公司都不愿意自己的產品一出生生了滿身毒瘡——bug。輕則產品銷量受損，重則產夭折，甚至嚴重影響公司形象乃至導致公司運轉等嚴重問題。這個時候我們還是先將測試分段，對于這種項目，我們首先站在測試質量的角度，實事求是按照功能點數目、難度，測試經驗等來估計測試時間，然后將總時間加起來，如果時間充裕，我們考慮加入更多測試面，如果時間緊迫，我們考慮是否刪除部分非核心功能，以降低開發和測試的時間成本，從而為測試質量保駕護航。

回到上面的“月圓之夜”的故事片段上來，這個片段提醒了我們在時間計劃的時候還有一些問題需要注意。上面提到計劃失敗是因為“月圓”這個外界因素沒有達到要求，這就提醒我們在計劃的過程中，應當盡量減少對于外界的依賴，如果依賴是必需的，那么對于依賴可能導致的意外我們要多出幾套應急方案。另外，在項目執行過程中，及時檢查項目進度也是必要的，這可以避免我們跑在錯誤的道路上，那樣只會越錯越遠，這部分不屬于計劃測試的范疇，因此不做考慮了，如果有興趣可以看一下持續集成相關的資料。