自動化測試實施步驟和最佳實踐

1、.：.；自動化測試實施步驟和最正確實際一個故事 : 我在很多軟件公司任務(wù)過，公司規(guī)模有大有小，也和其他公司的人員交流，因此閱歷過或者聽說過影響自動化測試效果的各種各樣的的問題。本文將提供假設(shè)干方法躲避能夠在自動化測試中出現(xiàn)的問題。我先給大家講一個故事，以便各位了解自動化測試會出現(xiàn)哪些問題。 以前，我們有一個軟件工程，開發(fā)小組內(nèi)一切的人都以為應(yīng)該在工程中采用自動化測試。軟件工程的經(jīng)理是 Anita Delegate 。她評價了一切能夠采用的自動化測試工具，最后選擇了一種，并且購買了幾份拷貝。她委派一位員工 Jerry Overworked 擔(dān)任自動化測試任務(wù)。 Jerry 除了擔(dān)任自動化測試任務(wù)

2、，還有其他的很多義務(wù)。他嘗試運用剛剛購買的自動化測試工具。當(dāng)把測試工具運用到軟件產(chǎn)品測試中的時候，遇到了問題。這個測試工具太復(fù)雜，難于配置。他不得不給測試工具的客戶支持熱線打了幾個。最后， Jerry 認(rèn)識到，他需求測試工具的技術(shù)支持人員到現(xiàn)場協(xié)助 安裝測試工具，并找出其中的問題。在打過幾個后，測試工具廠商派過來一位技術(shù)專家。技術(shù)專家到達(dá)后，找出問題所在，測試工具可以正常任務(wù)了。這還算是順利了。但是，幾個月后，他們還是沒有真正實現(xiàn)測試自動化， Jerry 回絕繼續(xù)從事這個工程的任務(wù)，他害怕自動化測試會一事無成，只是浪費時間而已。 工程經(jīng)理 Anita 把工程重新指派給 Kevin Shortt

3、imer ，一位剛剛被雇傭來做軟件測試的人員。 Kevin 剛剛獲得計算機科學(xué)的學(xué)位，希望經(jīng)過這份任務(wù)邁向更有挑戰(zhàn)性的、值得去做的任務(wù)。 Anita 送 Kevin 參與工具培訓(xùn)，防止 Kevin 步 Jerry 的后塵 由于運用測試工具遇到困難而變得沮喪，導(dǎo)致放棄擔(dān)任的工程。 Kevin 非常興奮。這個工程的測試需求反復(fù)測試，有點令人厭惡，因此，他非常情愿采用自動化測試。一個主要的版本發(fā)布后， Kevin 預(yù)備開場全天的自動化測試，他非常盼望得到一個時機證明本人可以寫非常復(fù)雜的，有難度的代碼。他建立了一個測試庫，運用了一些技巧的方法，可以支持大部分的測試，這比原方案多破費了很多時間，不過，

4、Kevin 使整個測試任務(wù)開展的很順利。他用已有的測試套測試新的產(chǎn)品版本，并且確實發(fā)現(xiàn)了 bug 。接下來， Kevin 得到一個從事軟件開發(fā)職位的時機，分開了自動化的崗位。 Ahmed Hardluck 接手 Kevin 的任務(wù)，從事自動化測試執(zhí)行任務(wù)。他發(fā)現(xiàn) Kevin 留下的文檔不僅少，并且沒有太多的價值。 Ahmed 破費不少時間去弄清楚已有的測試設(shè)計和研討如何開展測試執(zhí)行任務(wù)。這個過程中， Ahmed 閱歷了很多失敗，并且不能確信測試執(zhí)行的方法能否正確。測試執(zhí)行中，執(zhí)行失敗后的錯誤的提示信息也沒有太多的參考價值，他不得不更深的研討。一些測試執(zhí)行看起來仿佛永遠(yuǎn)沒有終了。另外一些測試執(zhí)行

5、需求一些特定的測試環(huán)境搭建要求，他更新測試環(huán)境搭建文檔，堅持不懈地任務(wù)。后來，在自動化測試執(zhí)行中，它發(fā)現(xiàn)幾個執(zhí)行失敗的結(jié)果，經(jīng)過分析，是回歸測試的軟件版本中有 BUG ，導(dǎo)致測試執(zhí)行失敗，發(fā)現(xiàn)產(chǎn)品的 BUG 后，每個人都很高興。接下來，他仔細(xì)分析測試套中的內(nèi)容，希望經(jīng)過優(yōu)化測試套使測試變得更可靠，但是，這個任務(wù)不斷沒有完成，預(yù)期的優(yōu)化結(jié)果也沒有到達(dá)。按照方案，產(chǎn)品的下一個發(fā)布版本有幾個主要的改動， Ahmed 立刻認(rèn)識到產(chǎn)品的改動會破壞已有的自動化測試設(shè)計。接下來，在測試產(chǎn)品的新版本中，絕大多數(shù)測試用例執(zhí)行失敗了， Ahmed 對執(zhí)行失敗的測試研討了很長時間，然后，從其他人那里尋求協(xié)助 。經(jīng)過

6、商討，自動化測試應(yīng)該根據(jù)產(chǎn)品的新接口做修正，自動化測試才干運轉(zhuǎn)起來。最后，大家根據(jù)新接口修正自動化測試，測試都經(jīng)過了。產(chǎn)品發(fā)布到了市場上。接下來，用戶立刻打來贊揚，贊揚軟件無法任務(wù)。大家才發(fā)現(xiàn)本人改寫了一些自動化測試腳本，導(dǎo)致一些錯誤提示信息被忽略了。雖然，實踐上測試執(zhí)行是失敗的，但是，由于改寫腳本時的一個編程錯誤導(dǎo)致失敗的測試執(zhí)行結(jié)果被忽略了。這個產(chǎn)品終于失敗了。 這是我的故事?；蛟S您曾經(jīng)親身閱歷了故事當(dāng)中某些情節(jié)。不過，我希望他沒有這樣的類似結(jié)局。本文將給出一些建議，防止出現(xiàn)這樣的結(jié)局。問題這個故事闡明了幾個使自動化測試工程墮入姿態(tài)的緣由：1. 自動化測試時間不充足：根據(jù)工程方案的安排，測

7、試人員往往被安排利用本人的個人時間或者工程后期介入自動化測試。這使得自動化測試無法得到充分的時間，無法得到真正的關(guān)注。2. 缺乏明晰的目的：有很多好的理由去開展自動化測試任務(wù)，諸如自動化測試可以節(jié)省時間，使測試更加簡單，提高測試的覆蓋率，可以讓測試人員堅持更好的測試自動性。但是，自動化測試不能夠同時滿足上述的目的。不同的人員對自動化測試有不同的希望，這些希望應(yīng)該提出來，否那么很能夠面對的是絕望。3. 缺乏閱歷：嘗試測試本人的程序的初級的程序員經(jīng)常采用自動化自動化測試。由于缺乏閱歷，很難保證自動化測試的順利開展。4. 更新?lián)Q代頻繁 High turnover ：測試自動化往往需求破費很多時間學(xué)習(xí)

8、的，當(dāng)自動化測試更新?lián)Q代頻繁的時候，他就喪失了剛剛學(xué)習(xí)到的自動化測試閱歷。5. 對于絕望的反響：在測試還遠(yuǎn)沒有開場的時候，問題就曾經(jīng)埋伏在軟件中了。軟件測試不過是發(fā)現(xiàn)了這些埋伏的問題而已。就測試本身而言，測試是一件很困難的任務(wù)。當(dāng)在修正正的軟件上一遍接一遍的測試時，測試人員變得疲勞起來。測試什么時候后終了？當(dāng)按照方案的安排，軟件應(yīng)該交付的時候，測試人員的絕望變得尤其劇烈。假設(shè)不需求測試，那該有多好呀！在這種環(huán)境中，自動化測試能夠是個可以選擇的處理方法。但是，自動化測試卻未必是最好的選擇，他不是一個現(xiàn)實的處理方法，更像是一個希望。6. 不愿思索軟件測試：很多人發(fā)現(xiàn)實現(xiàn)產(chǎn)品的自動化測試比測試本身更

9、有趣。在很多軟件工程發(fā)生這樣的情況，自動化工程師不參與到軟件測試的詳細(xì)活動中。由于測試的自動化與測試的人為割裂，導(dǎo)致很多自動化對軟件測試并沒有太大的協(xié)助 。7. 關(guān)注于技術(shù)：如何實現(xiàn)軟件的自動化測試是一個很吸引人的技術(shù)問題。不過，過多的關(guān)注如何實現(xiàn)自動化測試，導(dǎo)致忽略了自動化測試方案能否符合測試需求。遵守軟件開發(fā)的規(guī)那么 他 能夠了解 SEI 軟件工程研討所提出的 CMM 才干成熟度模型。 CMM 分為 5 個界別，該模型用來對軟件開發(fā)組織劃分等級。 Jerry Weinberg 美國著名軟件工程專家也創(chuàng)建了本人的一套軟件組織模型，在他的組織模型中添加了一個額外的級別，他稱之為零級別。很顯然，

10、一個零方式的組織實踐上也是開發(fā)軟件；零方式組織中，在開發(fā)人員和用戶之間沒有差別 Weinberg 1992 。恰恰在這類組織環(huán)境中，經(jīng)常采用自動化測試方法。因此，把資源用于自動化測試，并且把自動化測試當(dāng)作一個軟件開發(fā)活動對待，把軟件測試自動化提升到一級。這是處理測試自動化的中心的方案。我們應(yīng)該像運作其他的開發(fā)工程一樣來運作軟件自動化測試工程。 像其他軟件開發(fā)工程一樣，我們需求軟件開發(fā)人員專注于測試自動化的開發(fā)義務(wù)；像其他軟件開發(fā)工程一樣，自動化測試可以自動完成詳細(xì)的測試義務(wù)，對于詳細(xì)的測試義務(wù)來說，自動化開發(fā)人員能夠不是這方面的專家，因此，軟件測試專家應(yīng)該提供詳細(xì)測試義務(wù)相關(guān)的咨詢，并且提供測

11、試自動化的需求；像其他軟件開發(fā)工程一樣，假設(shè)在開發(fā)編碼之前，對測試自動化作了整體設(shè)計有助于測試自動化開發(fā)的順利開展。像其他軟件開發(fā)工程一樣，自動化測試代碼需求跟蹤和維護，因此，需求采用源代碼管理。像其他軟件開發(fā)工程一樣，測試自動化也會出現(xiàn) BUG ，因此，需求有方案的跟蹤 BUG ，并且對修正后的 BUG 進(jìn)展測試。像其他軟件開發(fā)工程一樣，用戶需求知道如何運用軟件，因此，需求提供用戶運用手冊。 本文中不對軟件開發(fā)做過多講述。我假定您屬于某個軟件組織，該組織曾經(jīng)知道采用何種合理的、有效的方法開發(fā)軟件。我僅僅是推進(jìn)您在自動化測試開發(fā)過程中遵守曾經(jīng)建立的軟件開發(fā)規(guī)那么而已。本文按照在軟件開發(fā)工程中采

12、用的規(guī)范步驟組織的，重點關(guān)注測試自動化相關(guān)的事宜和挑戰(zhàn)。 * 改良軟件測試過程 * 定義需求 * 驗證概念 * 支持產(chǎn)品的可測試性 * 可延續(xù)性的設(shè)計 design for sustainability * 有方案的部署 * 面對勝利的挑戰(zhàn) 1. 改良軟件測試過程 假設(shè)他擔(dān)任提高一個商業(yè)買賣操作的效率，首先，他應(yīng)該確認(rèn)曾經(jīng)很好的定義了這個操作的詳細(xì)過程。然后，在他投入時間和金錢采用計算機提供一套自動化的商業(yè)買賣操作系統(tǒng)之前，他想知道能否可以采用更簡單、本錢更低的的方法。同樣的，上述過程也是用于自動化測試。我更情愿把 “ 測試自動化 這個詞解釋成可以使測試過程簡單并有效率，使測試過程更為快捷，沒

13、有延誤。運轉(zhuǎn)在計算機上的自動化測試腳本只是自動化測試的一個方面而已。 例如，很多測試小組都是在回歸測試環(huán)節(jié)開場采用測試自動化的方法?；貧w測試需求頻繁的執(zhí)行，再執(zhí)行，去檢查曾經(jīng)執(zhí)行過的有效的測試用例沒有由于軟件的變動而執(zhí)行失敗?；貧w測試需求反復(fù)執(zhí)行，并且單調(diào)乏味。怎樣才干做好回歸測試文檔化的任務(wù)呢？通常的做法是采用列有產(chǎn)品特性的列表，然后對照列表檢查。這是個很好的開場，回歸測試檢查列表可以通知他應(yīng)該測試哪些方面。不過，回歸測試檢查列表只是合于那些了解產(chǎn)品，并且知道需求采用哪種測試方法的人。在開場測試自動化之前，他需求完善上面提到的回歸測試檢查表，并且，確保他曾經(jīng)采用了確定的的測試方法，指明測試中

14、需求什么樣的數(shù)據(jù)，并給出設(shè)計數(shù)據(jù)的完好方法。假設(shè)測試掌握了根本的產(chǎn)品知識，這會更好。確認(rèn)可以提供上面提到的文檔后，需求明確測試設(shè)計的細(xì)節(jié)描畫，還應(yīng)該描畫測試的預(yù)期結(jié)果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有認(rèn)識到他們短少什么，并且由于害怕為難而不敢去求助。這樣一份詳細(xì)的文檔給測試小組帶來立竿見影的效果，由于，如今任何一個具有根本產(chǎn)品知識的人根據(jù)文檔可以開展測試執(zhí)行任務(wù)了。在開場更為完全意義上的測試自動化之前，必需曾經(jīng)完成了測試設(shè)計文檔。測試設(shè)計是測試自動化最主要的測試需求闡明。不過，這時候千萬不要走極端去過分細(xì)致地闡明測試執(zhí)行的每一個步驟，只需確保那些有軟件根本操作常識的人員可以

15、根據(jù)文檔完成測試執(zhí)行任務(wù)既可。但是，不要假定他們了解那些存留在他頭腦中的軟件測試執(zhí)行的想法，把這些測試設(shè)計的思緒描畫清楚就可以了。以前擔(dān)任過一個軟件模塊的自動化測試任務(wù)。這個模塊的一些特性導(dǎo)致實現(xiàn)自動化非常困難。當(dāng)我了解到這項任務(wù)無需在很短的時間內(nèi)完成后，決議制定一個詳細(xì)回歸測試設(shè)計方案。我仔細(xì)地檢查了缺陷跟蹤庫中與該模塊相關(guān)的每個曾經(jīng)封鎖的缺陷，針對每個缺陷，我寫了一個可以發(fā)現(xiàn)該問題的測試執(zhí)行操作。我方案采用這種方法提供一個詳細(xì)的自動化需求列表，這可以通知我模塊的那一部分最適宜自動化測試。在完成上述任務(wù)后，我沒有時機完成測試自動化的實現(xiàn)任務(wù)。不過，當(dāng)我們需求對這個模塊做完好回歸測試的時候，我

16、將上面提到的文檔提供應(yīng)假設(shè)干只了解被測試產(chǎn)品但是沒有測試閱歷的測試人員。按照文檔的指點，幾乎不需求任何指點的情況下，各自完成了回歸測試，并且發(fā)現(xiàn)了 BUG 。從某種角度看，這實踐上是一次很勝利的自動化測試。在這個工程中，我們與其開發(fā)自動化測試腳本，還不如把測試執(zhí)行步驟文檔化。后來，在其它工程中，我們開發(fā)了自動化測試腳本，發(fā)現(xiàn)相關(guān)人員只需接受相關(guān)培訓(xùn)才干了解并執(zhí)行自動化測試腳本，假設(shè)測試自動化設(shè)計的很好，能夠會好一些。不過，經(jīng)過實際我們總結(jié)出完成一份設(shè)計的比較好的測試文檔，比完成一份設(shè)計良好的測試腳本簡單的多。另外一個提高測試效率的簡一方法是采用更多的計算機。很多測試人員動輒動用幾臺計算機，這一

17、點顯而易見。我之所以強調(diào)采用更多的計算機是由于，我曾經(jīng)看到一些測試人員被誤導(dǎo)在單機上努力的完成某些大容量的自動化測試執(zhí)行任務(wù)，這種情況下由于錯誤的運用了測試設(shè)備、測試環(huán)境，導(dǎo)致測試沒有效果。因此，自動化測試需求集中思索所需求的支撐設(shè)備。 針對改良軟件測試過程，我的最后一個建議是改良被測試的產(chǎn)品，使它更容易被測試，有很多改良措施既可以協(xié)助 用戶更好的運用產(chǎn)品，也可以協(xié)助 測試人員更好的測試產(chǎn)品。稍后，我將討論自動化測試的可測試需求。這里，我只是建議給出產(chǎn)品的改良點，這樣對手工測試大有協(xié)助 。一些產(chǎn)品非常難安裝，測試人員在安裝和卸載軟件上破費大量的時間。這種情況下，與其實現(xiàn)產(chǎn)品安裝的自動化測試，還

18、不如改良產(chǎn)品的安裝功能。采用這種處理方法，最終的用戶會受害的。另外的一個處置方法是思索開發(fā)一套自動安裝程序，該程序可以和產(chǎn)品一同發(fā)布?，F(xiàn)實上，如今有很多專門制造安裝程序的商用工具。另一些產(chǎn)品改良需求利用工具在測試執(zhí)行的日志中查找錯誤。采用人工方法，在日志中一頁一頁的查詢報錯信息很容易會讓人感到乏味。那么，趕快采用自動化方法吧。假設(shè)他了解日志中記錄的錯誤信息格式，寫出一個錯誤掃描程序是很容易的事情。假設(shè)，他不能確定日志中的錯誤信息格式，就開場動手寫錯誤掃描程序，很能夠面臨的是一場災(zāi)難。不要忘記本文開篇講的那個故事中提到的測試套無法判別測試用例能否執(zhí)行失敗的例子。最終用戶也不情愿采用經(jīng)過搜索日志的

19、方法查找錯誤信息。修正錯誤信息的格式，使其適宜日志掃描程序，便于掃描工具可以準(zhǔn)確的掃描到一切的錯誤信息。這樣，在測試中就可以運用掃描工具了。 經(jīng)過改良產(chǎn)品的性能對測試也是大有協(xié)助 的。很顯然的，假設(shè)產(chǎn)品的性能影響了測試速度，鑒別出性能比較差的產(chǎn)品功能，并度量該產(chǎn)品功能的性能，把它作為影響測試進(jìn)度的缺陷，提交缺陷報告。 上面所述的幾個方面可以在無需構(gòu)建自動化測試系統(tǒng)的情況下，大幅度的提高測試效率。改良軟件測試過程會破費他構(gòu)建自動化測試系統(tǒng)的時間，不過改良測試過程無疑可以使他的自動化測試工程更為順利開展起來。2. 定義需求 在前面的故事中，自動化工程師和自動化測試的發(fā)起者的目的存在偏向。為了防止這

20、種情況，需求在自動化測試需求上堅持一致。應(yīng)該有一份自動化測試需求，用來描畫需求測試什么。測試需求應(yīng)該在測試設(shè)計階段詳細(xì)描畫出來，自動化測試需求描畫了自動化測試的目的。很多人以為自動化測試顯然是一件好事情，但是，他們不情愿對自動化測試的目的給出明晰的描畫。下面是人們選用自動化測試的幾個緣由： * 加快測試進(jìn)度從而加快產(chǎn)品發(fā)布進(jìn)度 * 更多的測試 * 經(jīng)過減少手工測試降低測試本錢 * 提高測試覆蓋率 * 保證一致性 * 提高測試的可靠性 * 測試任務(wù)可以由技術(shù)才干不強測試人員完成 * 定義測試過程，防止過分依賴個人 * 測試變得更加有趣 * 提高了編程技藝 開發(fā)管理、測試管理和測試人員實現(xiàn)自動化測

21、試的目的經(jīng)常是有差別的。除非三者之間達(dá)成一致，否那么很難定義什么是勝利的自動化測試。 當(dāng)然，不同的情況下，有的自動化測試目的比較容易到達(dá)，有的那么比較難以到達(dá)。測試自動化往往對測試人員的技術(shù)程度要求很高，測試人員必需能了解充分的了解自動化測試，從而經(jīng)過自動化測試不斷發(fā)現(xiàn)軟件的缺陷。不過，自動化測試不利于測試人員不斷的積累測試閱歷。不論怎樣樣，在開場自動化測試之前應(yīng)該確定自動化測試勝利的規(guī)范。 手工測試人員在測試執(zhí)行過程中的一些操作可以發(fā)現(xiàn)不引人留意的問題。他們方案并獲取必要的測試資源，建立測試環(huán)境，執(zhí)行測試用例。測試過程中，假設(shè)有什么異常的情況發(fā)生，手工測試人員立刻可以關(guān)注到。他們對比實踐測試

22、結(jié)果和預(yù)期測試結(jié)果，記錄測試結(jié)果，復(fù)位被測試的軟件系統(tǒng)，預(yù)備下一個軟件測試用例的環(huán)境。他們分析各種測試用例執(zhí)行失敗的情況，研討測試過程可疑的景象，尋覓測試用例執(zhí)行失敗的過程，設(shè)計并執(zhí)行其他的測試用例協(xié)助 定位軟件缺陷。接下來，他們寫作缺陷報告單，保證缺陷被修正，并且總結(jié)一切的缺陷報告單，以便其他人可以了解測試的執(zhí)行情況。 千萬不要強行在測試的每個部分都采用自動化方式。尋覓可以帶來最大報答的部分，部分的采用自動化測試是最好的方法。或許他能夠發(fā)現(xiàn)采用自動化執(zhí)行和手動確認(rèn)測試執(zhí)行結(jié)果的方式是個很好的選擇，或許他可以采用自動化確認(rèn)測試結(jié)果和手工測試執(zhí)行相結(jié)合和方式。我聽到有人講，除非測試的各個環(huán)節(jié)都采

23、用自動化方式，否那么不是真正意義上的自動化測試，這真是胡言亂語。假設(shè)僅僅是為了尋覓挑戰(zhàn)，可以嘗試在測試的每個環(huán)節(jié)都采用自動化方法。但是，假設(shè)尋覓勝利測試的方法，請關(guān)注那些可以快速建立的，可以反復(fù)利用的自動化測試。 定義自動化測試工程的需求要求我們?nèi)娴?、清楚地思索各種情況，然后給出權(quán)衡后的需求，并且可以使測試相關(guān)人員更加合理的提出本人對自動化測試的期望。經(jīng)過定義自動化測試需求，間隔 勝利的自動化測試近了一步。3. 驗證概念 在前面的故事當(dāng)中，那個自動化測試人員在對測試方向一片茫然的情況下一頭扎進(jìn)了自動化測試工程中。不過，在工程的進(jìn)展中，他得到了各個方面的支持。 能夠還沒有認(rèn)識到這一點，不過，他

24、必需驗證自動化測試工程的可行性。驗證過程破費的時間往往比人們預(yù)期的要長，并且需求他身邊的各種人的協(xié)助 。 很多年前，我從事一個測試自動化工程的任務(wù)，參與工程的人員有各種各樣的好點子。我們設(shè)計了一個復(fù)雜的自動化測試系統(tǒng)，并且非常努力任務(wù)去實現(xiàn)系統(tǒng)的每個模塊。我們定期的引見測試自動化的設(shè)計思緒和任務(wù)進(jìn)度，甚至演示曾經(jīng)完成的部分功能。但是，我們沒有演示如何利用該套測試自動化系統(tǒng)如何開展實踐的測試任務(wù)。最后，整個工程被取消了，以后，我再也沒有犯這個錯誤。 他需求盡能夠快地驗證他采用的測試工具和測試方法的可行性，站在產(chǎn)品的角度驗證他所測試的產(chǎn)品采用自動化測試的可行性。這通常是很困難的，需求盡快地找出可行

25、性問題的答案，需求確定他的測試工具和測試方法對于被測試的產(chǎn)品和測試人員能否適宜。他需求做是驗證概念 一個快速、有壓服力的測試套可以證明他選在測試工具和測試方法的正確性，從而驗證了他的測試概念。他選擇的用來驗證概念的測試套是評價測試工具的最好的方式。 對 于很多人來說，自動化測試意味著 GUI 自動化測試，我不贊同這種觀念。我曾經(jīng)做過 GUI 和非 GUI 自動化測試，并驚奇的發(fā)現(xiàn)這兩類測試的測試方案有很大的互補性。不過， GUI 測試工具很昂貴、并且過分講究。選擇適宜的 GUI 測試工具是很重要的，由于，假設(shè)沒有選擇適宜的測試工具，他會遇到很多不可預(yù)測的困難。 Elisabeth Hendri

26、ckson 曾經(jīng)寫過一篇關(guān)于選擇測試的工具的指點性文章 Hendrickson 1999 。我建議在評價測試工具中，找出可以驗證他的想法的證據(jù)是很重要的環(huán)節(jié)。這需求測試工具至少有一個月試用期，他能夠計劃如今購買一份測試工具，然后直到評價完成后再購買更多份。他需求在付出大筆金錢購買測試工具的之前，找出工具存在的問題。這樣，他可以從測試工具供應(yīng)商得到更好的協(xié)助 ，當(dāng)他計劃改換工具的時候，他不會覺得很為難。 下面是一些候選的驗證概念的實驗： * 回歸測試：他預(yù)備在每個版本運轉(zhuǎn)同樣的測試用例嗎？回歸測試是最宜采用自動化測試的環(huán)節(jié)。 * 配置測試：他的軟件支持多少種不同的平臺？他計劃在一切支持的平臺上測

27、試執(zhí)行一切的測試用例嗎？假設(shè)是的，那么采用自動化測試是有協(xié)助 的。 * 測試環(huán)境建立：對于大量不同的測試用例，能夠需求一樣的測試環(huán)境搭建過程。在開展自動化測試執(zhí)行之前，先把測試環(huán)境搭建實現(xiàn)自動化。 * 非 GUI 測試：實現(xiàn)命令行和 API 的測試自動化比 GUI 自動化測試容易的多。 無論采用什么測試方法，定義一個看得見的目的，然后集中在這個目的上。驗證他自動化測試概念可以使自動化更進(jìn)一步邁向勝利之路。4.支持產(chǎn)品的可測試性軟件產(chǎn)品普通會用到下面三種不同類別的接口：命令行接口 command line interfaces ，縮寫 CLIs) 、運用程序接口 API 、圖形用戶接口 GUI

28、。有些產(chǎn)品會用到一切三類接口，有些產(chǎn)品只用到一類或者兩類接口，這些是測試中所需求的接口。從本質(zhì)上看， API 接口和命令行接口比 GUI 接口容易實現(xiàn)自動化，去找一找他的被測產(chǎn)品能否包括 API 接口或者命令行接口。有些時候，這兩類接口隱藏在產(chǎn)品的內(nèi)部，假設(shè)確實沒有，需求鼓勵開發(fā)人員在產(chǎn)品中提供命令行接口或者 API 接口，從而支持產(chǎn)品的可測試性。下 面，更多多的講解 GUI 自動化測試相關(guān)內(nèi)容。這里有幾個緣由導(dǎo)致 GUI 自動化測試比預(yù)期的要困難。1. 需求手工完成部分腳本。絕大多數(shù)自動化測試工具都有 “ 錄制回放 或者 “ 捕捉回放 功能，這確實是個很好的方法?？梢允止?zhí)行測試用例，測試工

29、具在后臺記住他的一切操作，然后產(chǎn)生可以用來反復(fù)執(zhí)行的測試用例腳本。這是一個很好的方法，但是很多時候卻不能奏效。很多軟件測試文章的作者得出結(jié)論 “ 錄制回放 雖然可以生成部分測試腳本，但是有很多問題導(dǎo)致 “ 錄制回放 不能運用到整個測試執(zhí)行過程中。 Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999. 結(jié)果， GUI 測試還是主要由手工完成。2. 把 GUI 自動化測試工和被測試的產(chǎn)品有機的結(jié)合在一同需求面臨技術(shù)上的挑戰(zhàn)。經(jīng)常要在采用眾多專

30、家意見和最新的 GUI 接口技術(shù)才干使 GUI 測試工具正常任務(wù)。這個主要的困難也是 GUI 自動化測試工具價錢昂貴的主要緣由之一。非規(guī)范的、定制的控件會添加測試的困難，處理方法總是有的，可以采用修正產(chǎn)品源代碼的方式，也可以從測試工具供應(yīng)商處晉級測試工具。另外，還需求分析測試工具中的 BUG ，并且給工具打補丁。也能夠測試工具需求做相當(dāng)?shù)亩ㄖ?，以便能有效地測試產(chǎn)品界面上的定制控件。 GUI 測試中，困難總是不測出現(xiàn)，讓人驚奇。他也能夠需求重新設(shè)計他的測試以躲避那些存在問題的界面控件。3. GUI 設(shè)計方案的變動會直接帶來 GUI 自動化測試復(fù)雜度的提高。在開發(fā)的整個過程中，圖形界面經(jīng)常被修正或

31、者完全重設(shè)計，這是出了名的事情。普通來講，第一個版本的圖形界面都是很糟糕。假設(shè)處在圖形界面方案不停變動的時候，就開展 GUI 自動化測試是不會有任何進(jìn)展的，他只能破費大量的時間修正測試腳本，以順應(yīng)圖形界面的變卦。不論怎樣，即使界面的修正會導(dǎo)致測試修正腳本，他也不應(yīng)該反對開發(fā)人員改良圖形界面。一旦原始的設(shè)計完成后，圖形界面接口下面的編程接口就固定下來了。 上面提到的這些緣由都是基于采用 GUI 自動化測試的方法完成產(chǎn)品的功能測試。圖形界面接口當(dāng)然需求測試，可以思索實現(xiàn) GUI 測試自動化。不過，他也應(yīng)該思索采用其他方法測試產(chǎn)品的中心功能，并且這些測試不會由于圖形界面發(fā)生變化而被中斷，這類測試應(yīng)該

32、采用命令行接口或者 API 接口。我曾經(jīng)看到有人選擇 GUI 自動化測試，由于，他們不計劃修正被測試產(chǎn)品，但是，最終他們認(rèn)識到必需對產(chǎn)品做修正，以保證 GUI 測試自動化可以正常任務(wù)。無論他選擇哪種方法，自動化都需求對被測試的產(chǎn)品做修正。因此，采用可編程的接口是最可靠的。為了讓 API 接口測試更為容易，應(yīng)該把接口與某種解釋程序，例如 Tcl 、 Perl 或者 Python 綁定在一同。這使交互式測試成為能夠，并且可以縮短自動化測試的開發(fā)周期。采用 API 接口的方式，還可以實現(xiàn)獨立的產(chǎn)品模塊的單元測試自動化。 一 個關(guān)于隱藏可編程接口的例子是關(guān)于 InstallShield 非常流行的制造

33、安裝盤的工具。 InstallShield 有命令行選項，采用這種選項可以實現(xiàn)非 GUI 方式的安裝盤，采用這種方式，從提早創(chuàng)建好的文件中讀取安裝選項。這種方式能夠比采用 GUI 的安裝方式更簡單更可靠。另 一個例子是關(guān)于如何防止基于 WEB 軟件的 GUI 自動化測試。采用 GUI 測試工具可以經(jīng)過閱讀器操作 WEB 界面。 WEB 閱讀器是經(jīng)過 協(xié)議與 WEB 效力器交互的，所以直接測試 協(xié)議更為簡單。 Perl 可以直接銜接 TCP/IP 端口，完成這類的自動化測試。采用高級接口技術(shù)，譬如客戶端 JAVA 或者 ActiveX 不能夠利用這種方法。但是，假設(shè)在適宜的環(huán)境中采用這種方式，他

34、將發(fā)現(xiàn)這種方式的自動化測試比 GUI 自動化測試更加廉價更加簡單。我曾經(jīng)受雇在一家公司擔(dān)任某個產(chǎn)品 GUI 相關(guān)的自動化測試，該產(chǎn)品也提供命令行接口，不過，他們曾經(jīng)實現(xiàn)了 GUI 的自動化測試。經(jīng)過一段時間的研討，我發(fā)現(xiàn)找到圖形界面中的 BUG 并不困難，不過，用戶并不關(guān)注圖形界面，他們更喜歡運用命令行。我還發(fā)現(xiàn)我們還沒有針對最新的產(chǎn)品功能這些功能即可經(jīng)過 GUI 的方式，也可以經(jīng)過命令行的方式運用實現(xiàn)自動化測試。我決議推遲 GUI 自動化測試，擴展命令行測試套，測試新增的產(chǎn)品功能。如今回過頭看這個決議，我沒有選擇 GUI 自動化測試是最大的勝利之處，假設(shè)采用了 GUI 自動化測試一切的時間和

35、努力都會浪費在其中。他們曾經(jīng)預(yù)備好做 GUI 自動化測試了，并且曾經(jīng)購買了一套測試工具和其他需求的東西，但我知道在開展詳細(xì)的 GUI 自動化測試活動中，會遇到各種各樣的困難和妨礙。無論他需求支持圖形界面接口、命令行接口還是 API 接口，假設(shè)他盡能夠早的在產(chǎn)品設(shè)計階段提出產(chǎn)品的可測試性設(shè)計需求，未來的測試任務(wù)中，他很能夠勝利。盡能夠早的啟動自動化測試工程，提出可測試性需求，會使您走向自動化測試勝利之路。5. 具有可延續(xù)性的設(shè)計在開篇的故事中，我們看到由于自動化工程師把留意力僅僅集中在如何使自動化運轉(zhuǎn)起來，導(dǎo)致測試自動化達(dá)不到預(yù)期的效果。自動化測試是一個長期的過程，為了與產(chǎn)品新版本的功能和其他相

36、關(guān)修正堅持一致，自動化測試需求不停的維護和擴展。自動化測試設(shè)計中思索自動化在未來的可擴展性是很關(guān)鍵的，不過，自動化測試的完好性也是很重要的。假設(shè)自動化測試程序報告測試用例執(zhí)行經(jīng)過，測試人員應(yīng)該置信得到的結(jié)果，測試執(zhí)行的實踐結(jié)果也應(yīng)該是經(jīng)過了。其實，有很多存在問題的測試用例外表上執(zhí)行經(jīng)過了，實踐上卻執(zhí)行失敗了，并且沒有記錄任何錯誤日志，這就是失敗的自動化。這種失敗的自動化會給整個工程帶來災(zāi)難性的后果，而當(dāng)測試人員構(gòu)建的測試自動化采用了很糟糕的設(shè)計方案或者由于后來的修正引入了錯誤，都會導(dǎo)致這種失敗的測試自動化。失敗的自動化通常是由于沒有關(guān)注自動化測試的性能或者沒有充分的自動化設(shè)計導(dǎo)致的。性能： 提

37、高代碼的性能往往添加了代碼的復(fù)雜性，因此，會要挾到代碼的可靠性。很少有人關(guān)懷如何對自動化本身加以測試。經(jīng)過我對測試套性能的分析，很多測試套都是破費大量的時間等候產(chǎn)品的運轉(zhuǎn)。因此，在不提高產(chǎn)品運轉(zhuǎn)性能的前提下，無法更有效的提高自動化測試執(zhí)行效率。我疑心測試自動化工程師只是從計算機課程了解到應(yīng)該關(guān)注軟件的性能，而并沒有實踐的操作閱歷。假設(shè)測試套的性能問題無法改動，那么應(yīng)該思索提高硬件的性能；測試套中經(jīng)常會出現(xiàn)冗余，也可以思索取出測試套中的冗余或者減少一個測試套中完成的測試義務(wù)，都是很好的方法。便于分析： 測試自動化執(zhí)行失敗后應(yīng)該分析失敗的結(jié)果，這是一個棘手的問題。分析執(zhí)行失敗的自動化測試結(jié)果是件困

38、難的事情，需求從多方面著手，測試上報的告警信息是真的還是假的？是不是由于測試套中存在缺陷導(dǎo)致測試執(zhí)行失??？是不是在搭建測試環(huán)境中出現(xiàn)了錯誤導(dǎo)致測試執(zhí)行失敗？是不是產(chǎn)品中確實存在缺陷導(dǎo)致測試執(zhí)行失??？有幾個方法可以協(xié)助 測試執(zhí)行失敗的結(jié)果分析，某些方法可以找到問題所在。經(jīng)過在測試執(zhí)行之前檢查常見的測試環(huán)境搭建問題，從而提高測試套的可靠性；經(jīng)過改良錯誤輸出報告，從而提高測試自動化的錯誤輸出的可分析性；此外，還可以改良自動化測試框架中存在的問題。訓(xùn)練測試人員如何分析測試執(zhí)行失敗結(jié)果。甚至可以找到那些不可靠的、冗余的或者功能比較獨立的測試，然后平安地將之刪除。上面這些都是減少自動化測試誤報告警、提高測

39、試可分析性的積極有效的方法。另外，有一種錯誤的測試結(jié)果分析方法，那就是采用測試結(jié)果后處置程序?qū)y試結(jié)果自動分析和過濾，雖然也可以采用這種測試結(jié)果分析方法，不過這種方法會使自動化測試系統(tǒng)復(fù)雜化，更重要的是，后處置程序中的 BUG 會嚴(yán)重?fù)p害自動化測試的完好性。假設(shè)由于自動化測試本身存在的缺陷誤把產(chǎn)品中的正常功能視為異常，那該怎樣辦？我曾經(jīng)看到測試小組破費開發(fā)測試自動化兩倍的時間來修正測試腳本，并且不情愿開展培訓(xùn)過程。那些僅僅關(guān)注很淺層次測試技術(shù)的測試管理者對這種方法很感興趣，他們排斥采用隱藏測試復(fù)雜度的方法。綜上所述，應(yīng)該集中精神關(guān)注可以延續(xù)運用的測試套，從以下幾方面思索，測試的可檢視性、測試的

40、可維護性、測試的完好性、測試的獨立性、測試的可反復(fù)性?？勺x性： 很多情況下，在測試人員開場測試工程之前，公司曾經(jīng)有了一套測試腳本，并且曾經(jīng)存在很多年了。我們可以稱之為 “ 聰明的橡樹 (wise oak tree)Bach 1996 。大家很依賴它，但是并不知道它是什么。由于 “ 聰明的橡樹 類型的測試腳本缺乏可讀性，在詳細(xì)運用中，那些腳本經(jīng)常沒有多大的適用價值，越來越讓人迷惑。因此，測試人員很難確定他們實踐在測試什么，反而會導(dǎo)致測試人員對本身的測試才干有過高的估計。測試人員可以檢視測試腳本，并且了解測試腳本終究測試了什么，這是很關(guān)鍵的。好的文檔是處理問題的手段之一，對測試腳本全面分析是另外一

41、個手段。由上面兩種方法可以引申出其它的相關(guān)方法，我曾經(jīng)在一個工程中運用過引申之后的方法。在測試腳本中插樁，把一切執(zhí)行的產(chǎn)品相關(guān)的命令記錄到日志里。這樣，當(dāng)分析日志確定執(zhí)行了哪些產(chǎn)品命令，命令采用了何種參數(shù)配置時，可以提供一個非常好的測試記錄，里面記錄了自動化測試執(zhí)行了什么，沒有執(zhí)行什么。假設(shè)測試腳本可讀性不好，很容易變得過分依賴并沒有完全了解的測試腳本，很容易以為測試腳本實踐上做的任務(wù)比他想象中的還要多。測試套的可讀性提高后，可以更容易的開展同行評審活動?？删S護性： 在任務(wù)中，我曾經(jīng)運用過一個測試套，它把一切的程序輸出保管到文件中。然后，經(jīng)過對比輸出文件內(nèi)容和一個已有的輸出文件內(nèi)容的差別，可以

42、稱已有的輸出文件為 “ 規(guī)范文件 “gold file 。在回歸測試中，用這個方法查找 BUG 是不是明智之舉。這種方法太過于敏感了，它會產(chǎn)生很多錯誤的警告。隨著時間的推移，軟件開發(fā)人員會根據(jù)需求修正產(chǎn)品的很多輸出信息，這會導(dǎo)致很多自動化測試失敗。很明顯，為了保證自動化測試的順利進(jìn)展，應(yīng)該在對 “ 規(guī)范文件 仔細(xì)分析的根底上，根據(jù)開發(fā)人員修正的產(chǎn)品輸出信息對之做相應(yīng)的修正。比較好的可維護性方法是，每次只檢查選定的產(chǎn)品的某些特定輸出，而不是對比一切的結(jié)果輸出。產(chǎn)品的接口變動也會導(dǎo)致原來的測試無法執(zhí)行或者執(zhí)行失敗。對于 GUI 測試，這是一個更大的挑戰(zhàn)。研討由于產(chǎn)品接口變化引起的相關(guān)測試修正，并研

43、討使測試修正量最小的方法，測試中采用庫是處理問題的方法。當(dāng)產(chǎn)品發(fā)生變化的時候，只需求修正相關(guān)的庫，保證測試與產(chǎn)品的變動同步修正即可。完好性： 當(dāng)自動化測試執(zhí)行后，報告測試執(zhí)行經(jīng)過，可以斷定這是真的嗎？這就是我稱之為測試套的完好性。在前面的故事中，當(dāng)沒有對自動化測試完好性給予應(yīng)有的關(guān)注的時候，發(fā)生了富有喜劇性的情況。我們應(yīng)該在多大程度上置信自動化化測試執(zhí)行結(jié)果？自動化測試執(zhí)行中的誤報告警是很大的問題。測試人員特別厭惡由于測試腳本本身的問題或者是測試環(huán)境的問題導(dǎo)致測試執(zhí)行失敗，但是，對于自動化測試誤報告警的情況，大家往往無能為力。他期望本人設(shè)計的測試對 BUG 很敏感、有效，當(dāng)測試發(fā)現(xiàn)異常的時候，

44、可以報告測試執(zhí)行失敗。有的測試框架支持對特殊測試結(jié)果的分類方法，分類包括 PASS ， FAIL 和第三種測試結(jié)果 NOTRUN 或者 UNRESOLVED 。無論他怎樣稱謂第三種測試結(jié)果，它很好的闡明了由于某些測試失敗導(dǎo)致其他測試用例無法執(zhí)行而并非執(zhí)行失敗的情況。得到正確的測試結(jié)果是自動化測試完好性定義的一部分，另一部分是可以確認(rèn)執(zhí)行勝利的測試確確實實曾經(jīng)執(zhí)行過了。我曾經(jīng)在一個測試隊列中發(fā)現(xiàn)一個 BUG ，這個 BUG 引起測試隊列中部分測試用例被跳過，沒有執(zhí)行。當(dāng)測試隊列運轉(zhuǎn)終了后，沒有上報任何錯誤，我不得不經(jīng)過走讀代碼的方式發(fā)現(xiàn)了這個 BUG 。假設(shè)，我沒有關(guān)注到這個 BUG ，那么能夠

45、在認(rèn)識到自動化測試曾經(jīng)出現(xiàn)問題之前，還在長時間運轉(zhuǎn)部分測試用例。獨立性： 采用自動化方法不能夠到達(dá)和手工測試同樣的效果。當(dāng)寫手工測試執(zhí)行的規(guī)程時候，通常假定測試執(zhí)行將會由一個有頭腦、擅長思索、具有察看力的測試人員完成的。假設(shè)采用自動化，測試執(zhí)行是由一臺不會說話的計算機完成的，他必需通知計算機什么樣的情況下測試執(zhí)行是失敗的，并且需求通知計算機如何恢復(fù)測試場景才干保證測試套可以順利執(zhí)行。自動化測試可以作為測試套的一部分或者作為獨立的測試執(zhí)行。測試都需求建立本人所需求的測試執(zhí)行環(huán)境，因此，保證測試執(zhí)行的獨立性是獨一的好方法。手工回歸測試通常都相關(guān)的指點文檔，以便一個接著一個有序地完成測試執(zhí)行，每個測

46、試執(zhí)行可以利用前一個測試執(zhí)行創(chuàng)建的對象或數(shù)據(jù)記錄。手工測試人員可以清楚地把握整個測試過程。在自動化測試中采用上述方法是經(jīng)常犯的錯誤，這個錯誤源于 “ 多米諾骨牌 測試套，當(dāng)一個測試執(zhí)行失敗，會導(dǎo)致后續(xù)一系列測試失敗。更糟糕的是，一切的測試關(guān)聯(lián)嚴(yán)密，無法獨立的運轉(zhuǎn)。并且，這使得在自動化測試中分析合法的執(zhí)行失敗結(jié)果也困難重重。當(dāng)出現(xiàn)這種情況后，人們首先開場疑心自動化測試的價值。自動化測試的獨立性要求在自動化測試中添加反復(fù)和冗余設(shè)計。具有獨立性的測試對發(fā)現(xiàn)的缺陷的分析有很好的支持。以這種方式設(shè)計自動化測試好似是一種低效率的方式，不過，重要的是在不犧牲測試的可靠性的前提下保證測試的獨立性，假設(shè)測試可以

47、在無需人看守情況下運轉(zhuǎn)，那么測試的執(zhí)行效率就不是大問題了。可反復(fù)性： 自動化測試有時可以發(fā)現(xiàn)問題，有時候又無法發(fā)現(xiàn)問題，對這種情況真實沒有什么好的的處置方法。因此，需求保證每次測試執(zhí)行的時候，測試是以同樣的方式任務(wù)。這意味著不要采用隨機數(shù)據(jù)，在通用言語庫中構(gòu)造的隨機數(shù)據(jù)經(jīng)常隱藏初始化過程，運用這些數(shù)據(jù)會導(dǎo)致測試每次都以不同的方式執(zhí)行，這樣，對測試執(zhí)行的失敗結(jié)果分析是很讓人沮喪的。這里有兩個運用隨機數(shù)據(jù)發(fā)生器的的方法可以防止上述情況。一種方法是運用常量初始化隨機數(shù)據(jù)發(fā)生器。假設(shè)他計劃生成不同種類的測試，需求在可預(yù)測，并且可控制的情況下建立不同類型的隨機數(shù)據(jù)發(fā)生器。另外一個方法是提早在文件中或數(shù)據(jù)

48、庫中建立生成隨機測試數(shù)據(jù)，然后在測試過程中運用這些數(shù)據(jù)。這樣做看起來似乎很好，但是我卻曾經(jīng)看到過太多違反規(guī)那么的做法。下面我來解釋究竟看到了什么。當(dāng)手動執(zhí)行測試的時候，往往匆匆忙忙整理文件名和測試數(shù)據(jù)記錄。當(dāng)對這些測試采用自動化測試方法，該做哪些任務(wù)呢？方法之一是，可以為測試中運用的數(shù)據(jù)記錄給固定的命名。假設(shè)這些數(shù)據(jù)記錄在測試完成后還要繼續(xù)運用，那么就需求制定命名規(guī)那么，防止在不同的測試中命名沖突，采用命名規(guī)那么是一種很好的方法。然而，我曾經(jīng)看到有些測試只是隨機的命名數(shù)據(jù)記錄，很不幸，現(xiàn)實證明采用這種隨機命名的方式不可防止的導(dǎo)致命名沖突，并且影響測試的可反復(fù)性。很顯然，自動化工程師低估了命名沖

49、突的能夠性。下面的情況我遇到過兩次，測試數(shù)據(jù)記錄的名字中包含四個隨機產(chǎn)生的數(shù)字，經(jīng)過簡單的推算假設(shè)我們采用這種命名方式的時候，假設(shè)測試運用了 46 條記錄，會存在 10% 沖突的能夠性，假設(shè)運用 118 條記錄，沖突的幾率會到達(dá) 50% 。我以為測試當(dāng)中運用這種隨機命名是出于偷懶的想法 防止再次測試之前寫代碼去除老的數(shù)據(jù)記錄，這樣引入了問題，損害了測試的可靠性和測試的完好性。測試庫： 自動化測試的一個通用戰(zhàn)略是開發(fā)可以在不同測試中運用的測試函數(shù)庫。我曾經(jīng)看到過很多測試函數(shù)庫，本人也寫了一些。當(dāng)要求測試不受被測試產(chǎn)品接口變動影響的時候，采用測試庫方法是非常有效的。不過，根據(jù)我的察看測試庫曾經(jīng)運用

50、的太多了，曾經(jīng)被濫用了，并且測試庫往往設(shè)計的不好，沒有相關(guān)的文檔支撐，因此，運用測試庫的測試往往很難開展。當(dāng)發(fā)現(xiàn)問題的時候，往往不知道是測試庫本身的問題，還是測試庫的運用問題。由于測試庫往往很復(fù)雜，即使在發(fā)現(xiàn)測試庫存在問題，相關(guān)的維護人員也很不情愿去修正問題。經(jīng)過前文中的論述，可以得出結(jié)論，在一開場就應(yīng)該保證測試庫設(shè)計良好。但是，實踐情況是測試自動化往往沒有破費更多的精神去保證一個優(yōu)良設(shè)計的測試庫。我曾經(jīng)看到有些測試庫中的功能根本不再運用了或僅僅運用一次。這與極限編程原那么堅持一致，即 他將不需求它 。這會導(dǎo)致在測試用例之間的代碼出現(xiàn)一些反復(fù)，我發(fā)現(xiàn)微小的變化能夠依然存在，很難與測試庫功能協(xié)調(diào)

51、。他能夠計劃對測試用例作修正，采用源代碼的方式比采用庫的方式更容易修正。假設(shè)有幾個測試，他們有某些共同的操作，我運用剪切和粘貼的方式去復(fù)制代碼，有的人以為我采用的方法不可理喻。這允許我根據(jù)需求修正通用代碼，我不用一開場嘗試和猜測如何重用代碼。我以為我的測試是很容易讀懂的，由于閱讀者不用關(guān)懷任何測試庫的語法。這種方法的優(yōu)勢是很容易了解測試，并且很方便擴展測試套。在開發(fā)軟件測試工程的時候，大多數(shù)程序員找到與他們計劃實現(xiàn)功能類似的源代碼，并對源代碼做修正，而不是從頭開場寫代碼。同樣，在寫測試套的過程中可以采用上述方法，這也是代碼開發(fā)方式所鼓勵的方法。我比較喜歡寫一些規(guī)模比較小的測試庫，這些庫可以被反

52、復(fù)的運用。測試庫的開發(fā)需求在概念階段充分定義，并且文檔化，從始至終都應(yīng)該堅持。我會對測試庫作充分的測試后，才在測試中運用這些測試庫。采用測試庫是對一切面臨的情況作權(quán)衡的。千萬不要計劃寫一個大而全的測試庫，不要希望有朝一日測試人員會利用他的測試庫完成大量的測試，這一天恐怕永遠(yuǎn)不會到來。數(shù)據(jù)驅(qū)動測試： 把測試數(shù)據(jù)寫入到簡單表格中，這種測試技術(shù)得到了越來越廣泛的運用，這種方法被稱為表驅(qū)動 table-driven ，數(shù)據(jù)驅(qū)動 (data-driven) 或者 “ 第三代 自動化測試 third generation automation 。這需求寫一個解析器，用來解釋表格中的數(shù)據(jù)，并執(zhí)行測試。該測試

53、架構(gòu)的最主要的益處是，它允許把測試內(nèi)容寫在具有一定格式的表格中，這樣方便數(shù)據(jù)設(shè)計和數(shù)據(jù)的檢視。假設(shè)測試組中有短少編程閱歷的業(yè)務(wù)專家參與測試，采用數(shù)據(jù)驅(qū)動測試方法是很適宜的。數(shù)據(jù)驅(qū)動測試的解析器主要是由測試庫和上層的少量開發(fā)言語寫成的代碼組成的，所以，上面關(guān)于測試庫的闡明放在這里是同樣適宜的。在針對上面提到的少量代碼的設(shè)計、開發(fā)、測試的任務(wù)，還存在各種困難。代碼所采用的編程言語是不斷開展的。也許，測試人員以為他們需求把第一部分測試的輸出作為第二部分測試的輸入，這樣，參與了新的變量。接下來，也許有人需求讓測試中的某個環(huán)節(jié)運轉(zhuǎn)一百次，這樣參與一個循環(huán)。他可以采用其他言語，不過，假設(shè)他預(yù)料到會面臨上述

54、情況的時候，那么做好采用一些可以經(jīng)過公開的渠道獲取的編程言語，比如 Perl,Python 或者 TCL ，這樣比設(shè)計他本人的言語要快的多。啟發(fā)式確認(rèn)： 我曾經(jīng)看到很多測試自動化沒有真正意義上的結(jié)果校驗，其緣由有兩個，一個緣由是做完全意義上的自動化測試結(jié)果確認(rèn)從技術(shù)上講是很困難的，另外一個緣由是經(jīng)過測試設(shè)計規(guī)格很難找出自動化測試的預(yù)期結(jié)果。這很不幸。不過，采用手工校驗測試結(jié)果的方法是真正意義上的測試校驗。規(guī)范文件 Gold file 是另外一中校驗測試結(jié)果的方法。首先，捕獲被測試程序的輸出，并檢視程序的輸出，然后，把輸出信息文檔化，并歸檔，作為規(guī)范文件。以后，自動化測試結(jié)果與規(guī)范文件作比較，從

55、而到達(dá)結(jié)果校驗的目的。采用規(guī)范文件的方法，也有弊端。當(dāng)產(chǎn)品發(fā)生變化，自動化測試的環(huán)境配置發(fā)生變化，產(chǎn)品的輸出發(fā)生變化的時候，采用規(guī)范文方法，會上報大量的誤報告警。做好的測試結(jié)果校驗方法是，對輸出結(jié)果的特定內(nèi)容作分析，并作合理的比較。有時候，很難知道正確的輸出結(jié)果是什么樣的，但是他應(yīng)該知道錯誤的輸出結(jié)果是什么樣的。開展啟發(fā)式的結(jié)果校驗是很有協(xié)助 的。我猜測一些人在自動化測試中設(shè)計了大而全的測試結(jié)果校驗方法，是由于擔(dān)憂假設(shè)結(jié)果校驗漏掉了任何信息，能夠?qū)е伦詣踊瘻y試本身出現(xiàn)錯誤。不過，我們在測試過程中往往采用折衷的做法，沒有采用大而全的測試結(jié)果校驗方法，這樣就不得不面對少量漏測情況的出現(xiàn)的風(fēng)險。自動

56、化測試不能改動這種情況的出現(xiàn)。假設(shè)自動化工程師不習(xí)慣采用這種折衷的方法，那么他必需找相關(guān)人員咨詢，尋覓一種適宜的測試結(jié)果校驗戰(zhàn)略，這需求有很大的發(fā)明性。目前有很多技術(shù)可以保證在不產(chǎn)生誤報告警的情況下，找到被測試產(chǎn)品的缺陷。把留意力放在經(jīng)過設(shè)計保證測試的可延續(xù)性上，選擇一個適宜的測試體系架構(gòu)，他將進(jìn)一步邁向勝利的自動化測試。6. 有方案的部署 在前面的故事中，當(dāng)自動化工程師沒有提供打包后的自動化測試程序給測試執(zhí)行人員，會影響到測試執(zhí)行，測試執(zhí)行人員不得不反過來求助自動化工程師指出如何運用自動化測試程序。 作為自動化工程師，他知道如何利用自動化方法執(zhí)行測試和分析執(zhí)行失敗的結(jié)果。不過，測試執(zhí)行人員卻未必知道如何運用自動化測試。因此，需求提供自動化測試程序的安裝文檔和運用文檔，保證自動化測試程序容易安裝和配置。當(dāng)安裝的環(huán)境與安裝的要求不匹配，出現(xiàn)安裝錯誤的時候，可以給出有價值的提示信息，便于定位安裝問題?？梢园炎詣踊瘻y試程序和測試套作為產(chǎn)品對待，那真是太好了。他應(yīng)該對自動化測試程序和測試套件開展測試，保證它們不依賴于任何公用的庫或者是設(shè)備上的任何其他程序。保證