《 自動化測試最佳實踐：來自全球的經典自動化測試案例解析》一一0.1 管理層問題

0.1　管理層問題

從許多案例研究中可以清晰地了解到，管理層的支援力度關系到自動化測試的成功與失敗。舉例而言，第4、6、11、17和20章都叙述了管理層支援欠缺導緻自動化測試失敗的情形。

0.1.1　自動化測試目标

制訂一個合适的目标對自動化測試的成功實施至關重要！這似乎是顯而易見的，但令人驚訝的是，在沒有任何清晰目标或僅僅是隻有一些模糊的陳詞濫調作為目标（如“更快的測試”、“做得更好”、“節省時間”）的情況下，一個自動化測試就開始了，這類事情經常發生。目标越具體，自動化測試越有可能得到好的評價并取得成功。

将軟體測試所要達到的目标與自動化所要達到的目标區分開來是很重要的。自動化是運作測試的一種方法，無論這些測試是好還是壞。一個好的測試目标是發現許多bug。這沒有必要成為一個好的自動化測試目标：在近期對項目進行一些改動之後，需要進行回歸測試以確定變更的部分不會影響系統的行為，而這類測試很少發現新的錯誤。這并不意味着自動化測試不成功，隻是因為它有了錯誤的目标。如果一個高層經理感到自動化測試沒有達到預期目标（即使這個目标是一種誤導），那麼資金也可能被撤掉。

0.2.9節讨論了一些能夠有效地找到bug的自動化測試示例。一些好的自動化測試目标在第1、2、3、6、7、10、11、12、14、20、21、25、27和29章中讨論。

0.1.2　管理層支援

在一個無法對自動化測試進行精心培育并有效引導的組織中，自動化測試很難成功發展起來。對于個人來說最好先親自試驗一下，如果想要大規模地進行自動化測試，并能收獲自動化測試對于産品最終釋出所帶來的巨大好處，則需要管理層的大力支援。一種“自下而上”的方法并不是通向良好自動化測試的一條長期可持續的道路。

管理層支援對自動化測試的成功至關重要；我們可以在本書的很多案例研究中看到這一點。管理層支援包括多種形式：對工具的資金支援，對于一個試點項目和測試件架構的開發過程的資金支援，以及為此需要付出的時間，管理層還要有興趣去了解自動化行為以監督成本與回報（參見a.3節的roi）。

對于經理來說很重要的一點是，對于自動化過程他能夠提供什麼，以及對要達到期望的結果需要付出時間與努力有着很明确的了解。

在某些案例中，一些高層的經理并不十分了解好的自動化測試意味着什麼。這可能是因為他們沒有很好地親自調查，但另一個因素可能是做自動化測試的人員沒有積極溝通，雖然溝通是他們本應該做好的事情。

與管理層溝通的重要性主要在第1、4、6、13、20和29章中進行強調，而具體作法則在第16、19和29章中涉及。管理層支援作為示例學習的關鍵因素在第1、2、6、11、18、21章中進行了強調。

0.1.3　roi和度量标準

一個普遍的誤解是，成功的自動化測試僅僅需要購買相應工具的投資（如果你得到一個開源工具，那就不需要其他任何花費）。如果在自動化方面的投資為0，則其投資回報率可能為負值。簡而言之，如果你什麼也不投入，你将會陷入麻煩！

要在以下方面進行投資：對于觀點的研究和實驗；設計和開發一個好的自動化測試件架構；學習和了解失敗和成功的因素；找到符合特定情況的解決方案；就自動化測試計劃、進度及測試方法進行溝通。

常常在一個自動化測試開始時評估roi。這是一個很明智的做法：相對于自動化測試的投入，是否獲得了更多的收益并節約了資金？執行自動化測試的理由通常是比較執行同一測試手動和自動所花費的時間。盡管這是證明自動化測試有用的方法，但僅僅執行自動化測試并不是全部。實作自動化測試的時間，對自動化測試的維護，分析錯誤測試的時間以及其他一些可能比手動測試花費更多時間的任務。這些其他任務可能是一個重要的額外開銷，也應該考慮。要知道如果你使用一個工具供應商的roi電腦，這些其他的開銷可能不包括在roi的計算中。

其他需要考慮的因素包括：更高的覆寫率（已經測試過的系統數量），最少的時間推向市場，以及增長的信心。但這些益處在早期的自動化測試實施中可能無法實作。它們會在自動化測試一旦完成之時變成現實。它們同樣難以量化，是以也可被看做額外的收益。

一旦一個自動化測試建立，看它能否達到預期也是非常重要的，是以最好定期做這樣類似的比較（将所有因素考慮進去），并且将這一資訊和負責資金的管理層交流，這是非常重要的。

許多人混淆了收益（benefit）和roi。收益隻是收益，而roi則是将收益與成本有效地進行比較。

請記住，你決定收集的度量标準可能被誤解，也許它沒能傳達你所希望的意思。也請注意，那些在新的上下文中不再有用的度量标準；第28章描述了自動化測試的職業生涯的影響。

roi和量化收益在第1、2、9、12、13、18、23、26和29章中讨論。在第9章有一個用來評判投資的基于模型測試的roi電腦的範例。

0.1.4　在靈活開發中的自動化測試

随着靈活開發變得更加普遍，其自動化測試也變得越來越重要。持續的內建就是測試自動化；回歸測試每天都要進行，有時候甚至更為頻繁。自動化測試也需要在出現變更時能做出響應，就像靈活開發中那樣，于是測試件架構便顯得更加至關重要（參見0.2.1節）。自動化測試在傳統開發和靈活開發中都取得了成功，沒有自動化測試，靈活開發就不會成功。

靈活技術，如測試驅動的開發（test-driven development，tdd）可以確定自動化的單元測試，但是對使用靈活方法開發的系統仍需要進行系統測試。第1章主要講述的是靈活開發中的自動化測試；靈活項目中的自動化測試也在第6、7、17、18、19和21章中提及。

0.1.5　技能

測試人員所需要的技能和自動化測試人員不同，自動化測試人員的角色可以看做測試人員和工具之間的橋梁（參見0.2.1節）。

自動化測試人員的角色有着嚴格的區分：一類是高層次的自動化設計人員（測試架構師，test architect），另一類是自動化測試件的實作人員，自動化測試人員（test automator）可以用于這兩類人員。自動化測試架構師的任務是設計自動化測試的整體結構，或者為了建立好的測試件架構而選擇架構，或是将現有架構進行改進以适應新的需求。自動化測試人員的任務是設計、編寫、維護自動化測試的軟體、腳本、資料、期望結果以及額外的實用工具。自動化測試人員負責實作多個層次的抽象（在0.2.1節中讨論），這使得測試人員不必學會程式設計就可以使用這些自動化手段。自動化測試人員同樣可以幫助測試人員，包括解決技術上的問題、決定花費/ 收益的比率，以及實作新的測試需求等。自動化測試人員必須有好的程式設計基礎。

有這樣一種趨勢，即測試人員同時也是開發人員。如果測試人員同時還是一名好的程式員，那麼這個人既可以成為測試人員也可以成為自動化測試人員——我們讨論的是不同的角色，他們不一定是不同的個人。

然而，很多測試人員并不一定擅長技術，而且他們也不想成為程式員。就如hans buwalda說的，強迫一名非技術的測試人員去做程式員，不僅會使你失去一名好的測試人員，還會讓你得到一名不稱職的程式員。非技術的測試人員也應該參與自動化測試！如果将他們從自動化測試的過程中排除，就不能充分發揮這些測試人員的技能，進而也無法充分挖掘出自動化測試的潛力。

測試人員和測試自動化人員的角色在第10、12、18、19、20、23和29章中讨論。

0.1.6　計劃、範圍和期望

當自動化測試有好的計劃時，它通常更有可能獲得成功。計劃應當包括，在自動化測試應用于整個項目前花些時間進行一些實驗。例如，一個限制時間的試點項目，讓你能更清晰地看到如何達到自動化測試長期目标的方法，當然這個項目也要有清晰的目标和足夠的資源。

不要期望自動化項目中不會出現任何問題；沒有什麼事情是沒有問題的！應該随時準備應對可能出現的問題。記住即使是最好的計劃也僅僅是一項指導——要根據情況去重新審視這些計劃。

設定符合實際的目标，即在規定時限内完成任務，并且定義好項目的範圍。不要太過于關注細節，否則就無法在公司中獲得那些潛在的收益。要關注在早期就能得到的一些有用的結果，而不要以減少有用的自動化測試為代價，去建構過量用于支援測試複用的庫。一旦自動化測試開始運作，要繼續尋找方法去改進這些自動化測試，并且為自動化測試設立新的目标以減少花費和增加收益。

第1、5、6、11、16、20、25和29章讨論了這些問題，第1、3、23和27章還讨論了如何持續地改進自動化測試過程。

0.1.7　和開發人員的關系

在成功的自動化測試實踐中通常有一項因素，即在測試人員、自動化測試人員和開發人員之間保持良好的關系。如果他們的關系不好，那麼自動化過程就會更加艱難，即便自動化測試在最後還是會帶來一些收益。如果軟體在設計時沒有考慮到自動化，那麼自動化測試就會變得非常困難。例如，如果軟體使用了非标準的控件，那麼自動化測試就很難和軟體進行互動。測試人員或者自動化測試人員或許會對開發人員說：“請僅僅使用标準的控件——這會使得我們的工作更加容易。”但是開發人員的時間很倉促，可能會說：“我們為什麼要做一些不會給我們帶來好處的事情呢？”這個開發人員并非很無理，這确實是一個相當合理的原因（雖然一些測試人員不會同意這個觀點）。

更好的方法是告訴開發人員自動化測試是如何讓他們受益的，并且和他們保持良好的合作關系。例如，如果你能夠在15分鐘内在測試環境中對一個新編碼的函數運作測試，你就能夠在一定時間内向開發人員提供有用的資訊（找到了bug或者測試已經通過），這對他們是極大的幫助。

關于開發人員和自動化測試人員的關系在第1、2、6、9、17、20、27和29*章中讨論。

0.1.8　促進項目改變并啟動自動化測試的觸發器

是什麼讓一家公司決定它們應該采用自動化測試？有時，因為測試不足所帶來的嚴重問題或者近期的災難，促使公司做出改變；有時，來自公司外部的觀點也會帶來更好的解決方案；有時，管理層決定公司需要自動化測試，這甚至決定了公司的生存。人們總是先嘗到了苦頭，然後才會進行實際的改變。

對于那些打算應用自動化測試的公司，最重要的建議是要從小範圍開始應用。試點項目（pilot project）是個好主意，在将自動化測試擴充到更廣的範圍之前先在小範圍内嘗試不同的方法，來判斷哪種方法最好。

這些問題在第1、9、10、12、17、23、26、27和29章中讨論。

0.1.9　工具和教育訓練

人們經常會問一個問題，哪個工具是最好的？這就像問哪個汽車最好一樣。一個人認為最好的車是能夠容納四個小孩和兩條狗的車；另一個人可能更關注于車的速度和性能；還有一些人關注哪個車更經濟一些。是以，沒有完美的工具，但是有很多工具是足以應對某些特定場景的。

事實上，正如第17章講述的那樣，有時可能會選擇錯誤的工具，是以為所要做的工作選擇合适的工具是很重要的。在第17章中錯誤使用的工具卻在第7章和第25章中取得了成功。

但是工具不是測試自動化最重要的因素。是的，通常确實需要使用工具來執行測試，但是在大多情況下，好的自動化測試的其他方面遠遠比因單獨工具之間的差異所帶來的影響要大得多。擁有好的工具不能保證在測試自動化中取得成功——必須對整個測試架構進行良好地計劃、定制和維護，工具僅僅是一小部分。

使用一個工具失敗并不意味着使用其他工具就能取得成功；一些公司嘗試了一些工具但是在每次嘗試中都以相同的方式失敗了。遺憾的是，公司經常将這些失敗歸咎于工具或者個人，而實際原因在于自動化測試項目沒有進行足夠的計劃和管理。

工具的主要用處是為人員提供支援！那些将要使用工具的測試人員應該在如何使用這些工具上有話語權，而且公司應當為工具提供基礎設施以支援他們。

無論使用什麼工具，教育訓練都是很重要的。那些将會直接使用工具的人應該在早期就接受一些深入的教育訓練，無論是通過工具生産商的課程或者線上教程。如果公司引進組織外部的顧問或者工具生産商的技術支援人員來進行教育訓練，将每次會議的間隔日期進行适當調整，以便在這段時間中測試人員能夠吸收這些知識并且對他們所學到的内容有實踐的時間。之後，為那些需要使用這個自動化工具的人提供教育訓練，告訴他們自動化測試應該如何進行——這是内部教育訓練，而不是外部教育訓練。良好的教育訓練能夠避免浪費很多時間。

關于工具和教育訓練相關的問題會在第1、6、11、12、13、18、19、21、23、25、26和29章中讨論。

0.1.10　行政因素

在自動化過程中，有一些因素是測試人員、測試自動化人員，甚至是經理或者其他利益相關者無法控制的；例如，可能會因為一個主要項目的取消，導緻為成功的自動化測試付出的努力也變成徒勞。

很多測試人員和自動化測試人員之是以艱難地進行一些項目，可能僅僅是因為他們經理的一句看起來随意的話。第29章中的奇聞轶事就舉了這方面的例子，還有在第4章中，經理的行為“謀殺”（雖然這可能是“過失殺人”，而不是“謀殺”）了自動化測試。第28章舉了一個例子，即當自動化測試帶來的改進是如此巨大，以緻經理都不肯相信這些結果。

行政因素是生活的一部分；做出的決定并不經常像看上去那樣合理。