經營成功的測試生涯(3)

　　漏洞

　　測試人員最終都會變得很擅長尋找缺陷，但是要翻過測試的高峰，我們必須更快并且更有效率：高速低阻。換句話說，我們必須擁有一種本身不含缺陷的缺陷查找技術!

　　我喜歡這樣來考慮問題：測試人員檢視自己的工作時也需要發揮那種尋找缺陷的能力。我們必須使用和尋找產品缺陷一樣的流程來尋找我們自己的測試流程，測試過程中的缺陷。我的測試流程是不是有問題?這里面是否有缺陷?這里是否存在著妨礙我提高效率的障礙?

　　你必須一直尋找更好的方法。有意識地去確定那些限制能力、阻礙前進、減緩速度的東西。就像缺陷限制了軟件滿足用戶需求的能力一樣，是什么限制了測試的能力?使用你擁有的測試能力來最優化自己的測試流程，這會幫助你在測試的山峰上快速攀登并增加你翻越山峰后成為專家的機會。

　　測試山峰的巔峰處是一個美好的地方。如果你成功地到了那里，恭喜你.但這并不是最終日標。這表示你已經成為一個杰出的測試人員。而此時的下坡路就是用你的洞察力和專家知識來幫助周圍的人也成為優秀的測試人員。自己一個人登頂是一回事，幫助其他人(那些能力不如你的人)登頂卻完全是另外一回事。

　　一般來說，那些成功登上測試巔峰的人會成為使用工具的大師。那些商業工具、開開源免費工具,和自己寫的工具(我個人最喜歡的工具)是極好地提高工作產出、增加工作成效的方法。不過，工具只是實現該目標的一種方法，但在許多其他方面它反而是一種限制，因為太多的人看不到工具的功能之外的東西。他們被限制在工具能為他們所做的事情中，沒能看到或理解對工具還有更多的需求。登頂需要真正掌握的是“信息”。因為很多工具能處理信息，并使得信息的獲取更加容易，所以測試人員變得過于依賴于他們的工具。但是信息本身以及如何利用這些信息才是真正的成功關鍵。

　　熟練掌握信息，指理解有哪些信息，這些信息將如何影響測試，保證最大限度地利用這些影響。有幾類信息是測試登頂者必須關注的。這里我要談的是其中兩種：來自應用程序的信息和來自之前測試的信息。

　　來自應用程序的信息包括需求、體系結構、代碼結構、源代碼……甚至是關于應用程序在執行時做了哪些事情的運行信息。在編寫和執行測試用例時，需要考慮這類信息，但信息的多寡在很大程度上取決于測試人員的能力，這是一種能夠使測試更高效的能力。在測試中使用這類信息越多，測試就越偏向于工程而不是猜測。

　　在微軟，我們有一個游戲測試組織(Games Test Organization,GTO)，負責Xbox和PC游戲的測試。談到利用應用程序的信息，他們是最優秀的。游戲是難以想象的豐富，測試起來非常復雜。游戲中很多可測試的內容都是隱藏的(因為讓那些玩家找尋可以交換的物品正是游戲的樂趣之一)o如果GTO的測試人員所做的僅僅是玩游戲，那么他們找到的問題不會比最終用戶更多。為了能做得更好，他們與游戲的開發人員合作創建了一些信息控制板，這些控制板暴露了一些基本上可以算得上作弊的信息給測試人員。這樣，測試人員就能提前知道怪物會被投放在何處、物品被隱藏在哪里，他們可以看到墻的另一邊，可以控制敵方的某些行為。他們的作弊工具(即測試上具)基本上使他們成為游戲里的神，讓他們可以控制看到的信息以便更快更巧妙地測試。這個例予給有測試人員都上了一課。

　　來自測試的信息意味著你必須關注在測試時所做的一切，并使用獲得的信息來影響今后的測試。你是否知道你的測試是如何與需求結合的，知道何時某一特定需求已經得到足夠的測試?你是否使用代碼覆蓋率來影響未來的測試?你知道當代碼更新或缺陷修復時那些測試會受到影響，還是知識重新運行所有的測試?理解測試進行到什么程度并隨著測試調整測試策略，這是測試成熟的標志。

　　我以前曾在微軟的Visual Studio的一個小組工作過，我們大量使用代碼改動量(由于添加新特性或修復缺陷而改變的代碼)和代碼覆蓋來影響我們的測試。我們花了很大的力氣將代碼覆蓋和代碼改動量通知測試人員，幫助他們理解哪些測試用例對覆蓋率有貢獻，幫助他們測試改動過的或修改過的組件。最終的結果是在代碼確實被改動時，我們清楚地知道哪些測試會被影響而只重新運行那些測試。我們還知道每個新的測試用例是如何對總體的接口，特性和代碼覆蓋率產生作用的，從而指導我們的測試人員，讓團隊中的每個人在他們所創建的所有測試用例基礎上，寫出更有意義的測試。

原文轉自：http://www.cnblogs.com/skytraveler/p/3546703.html