測試庫： 自動(dòng)化測試的一個(gè)通用策略是開(kāi)發(fā)可以在不同測試中應用的測試函數庫。我曾經(jīng)看到過(guò)很多測試函數庫，自己也寫(xiě)了一些。當要求測試不受被測試產(chǎn)品接口變動(dòng)影響的時(shí)候，采用測試庫方法是非常有效的。不過(guò)，根據我的觀(guān)察測試庫已經(jīng)使用的太多了，已經(jīng)被濫用了，并且測試庫往往設計的不好，沒(méi)有相關(guān)的文檔支撐，因此，使用測試庫的測試往往很難開(kāi)展。當發(fā)現問(wèn)題的時(shí)候，往往不知道是測試庫自身的問(wèn)題，還是測試庫的使用問(wèn)題。由于測試庫往往很復雜，即便在發(fā)現測試庫存在問(wèn)題，相關(guān)的維護人員也很不愿意去修改問(wèn)題。通過(guò)前文中的論述，可以得出結論，在一開(kāi)始就應該保證測試庫設計良好。但是，實(shí)際情況是測試自動(dòng)化往往沒(méi)有花費更多的精力去保證一個(gè)優(yōu)良設計的測試庫。我曾經(jīng)看到有些測試庫中的功能根本不再使用了或僅僅使用一次。這與極限編程原則保持一致，即 " 你將不需要它 " 。這會(huì )導致在測試用例之間的代碼出現一些重復，我發(fā)現微小的變化可能仍然存在，很難與測試庫功能協(xié)調。你可能打算對測試用例作修改，采用源代碼的方式比采用庫的方式更容易修改。如果有幾個(gè)測試，他們有某些共同的操作，我使用剪切和粘貼的方式去復制代碼，有的人認為我采用的方法不可理喻。這允許我根據需要修改通用代碼，我不必一開(kāi)始嘗試和猜測如何重用代碼。我認為我的測試是很容易讀懂的，因為閱讀者不必關(guān)心任何測試庫的語(yǔ)法。這種辦法的優(yōu)勢是很容易理解測試，并且很方便擴展測試套。在開(kāi)發(fā)軟件測試項目的時(shí)候，大多數程序員找到與他們打算實(shí)現功能類(lèi)似的源代碼，并對源代碼做修改，而不是從頭開(kāi)始寫(xiě)代碼。同樣，在寫(xiě)測試套的過(guò)程中可以采用上述方法，這也是代碼開(kāi)發(fā)方式所鼓勵的方法。我比較喜歡寫(xiě)一些規模比較小的測試庫，這些庫可以被反復的使用。測試庫的開(kāi)發(fā)需要在概念階段充分定義，并且文檔化，從始至終都應該保持。我會(huì )對測試庫作充分的測試后，才在測試中使用這些測試庫。采用測試庫是對所有面臨的情況作權衡的。千萬(wàn)不要打算寫(xiě)一個(gè)大而全的測試庫，不要希望有朝一日測試人員會(huì )利用你的測試庫完成大量的測試，這一天恐怕永遠不會(huì )到來(lái)。
數據驅動(dòng)測試： 把測試數據寫(xiě)入到簡(jiǎn)單表格中，這種測試技術(shù)得到了越來(lái)越廣泛的應用，這種方法被稱(chēng)為表驅動(dòng)( table-driven )，數據驅動(dòng) (data-driven) 或者 “ 第三代 ” 自動(dòng)化測試( "third generation" automation )。這需要寫(xiě)一個(gè)解析器，用來(lái)解釋表格中的數據，并執行測試。該測試架構的最主要的好處是，它允許把測試內容寫(xiě)在具有一定格式的表格中，這樣方便數據設計和數據的檢視。如果測試組中有缺少編程經(jīng)驗的業(yè)務(wù)專(zhuān)家參與測試，采用數據驅動(dòng)測試方法是很合適的。數據驅動(dòng)測試的解析器主要是由測試庫和上層的少量開(kāi)發(fā)語(yǔ)言寫(xiě)成的代碼組成的，所以，上面關(guān)于測試庫的說(shuō)明放在這里是同樣合適的。在針對上面提到的少量代碼的設計、開(kāi)發(fā)、測試的工作，還存在各種困難。代碼所采用的編程語(yǔ)言是不斷發(fā)展的。也許，測試人員認為他們需要把第一部分測試的輸出作為第二部分測試的輸入，這樣，加入了新的變量。接下來(lái)，也許有人需要讓測試中的某個(gè)環(huán)節運行一百次，這樣加入一個(gè)循環(huán)。你可以采用其他語(yǔ)言，不過(guò)，如果你預料到會(huì )面臨上述情況的時(shí)候，那么做好采用一些能夠通過(guò)公開(kāi)的渠道獲取的編程語(yǔ)言，比如 Perl,Python 或者 TCL ，這樣比設計你自己的語(yǔ)言要快的多。
啟發(fā)式確認： 我曾經(jīng)看到很多測試自動(dòng)化沒(méi)有真正意義上的結果校驗，其原因有兩個(gè)，一個(gè)原因是做完全意義上的自動(dòng)化測試結果確認從技術(shù)上講是很困難的，另外一個(gè)原因是通過(guò)測試設計規格很難找出自動(dòng)化測試的預期結果。這很不幸。不過(guò)，采用手工校驗測試結果的方法是真正意義上的測試校驗。標準文件( Gold file )是另外一中校驗測試結果的方法。首先，捕獲被測試程序的輸出，并檢視程序的輸出，然后，把輸出信息文檔化，并歸檔，作為標準文件。以后，自動(dòng)化測試結果與標準文件作比較，從而達到結果校驗的目的。采用標準文件的方法，也有弊端。當產(chǎn)品發(fā)生變化，自動(dòng)化測試的環(huán)境配置發(fā)生變化，產(chǎn)品的輸出發(fā)生變化的時(shí)候，采用標準文方法，會(huì )上報大量的誤報告警。做好的測試結果校驗方法是，對輸出結果的特定內容作分析，并作合理的比較。有時(shí)候，很難知道正確的輸出結果是什么樣的，但是你應該知道錯誤的輸出結果是什么樣的。開(kāi)展啟發(fā)式的結果校驗是很有幫助的。我猜想一些人在自動(dòng)化測試中設計了大而全的測試結果校驗方法，是因為擔心如果結果校驗漏掉了任何信息，可能導致自動(dòng)化測試自身出現錯誤。不過(guò)，我們在測試過(guò)程中往往采用折衷的做法，沒(méi)有采用大而全的測試結果校驗方法，這樣就不得不面對少量漏測情況的出現的風(fēng)險。自動(dòng)化測試不能改變這種情況的出現。如果自動(dòng)化工程師不習慣采用這種折衷的方法，那么他必須找相關(guān)人員咨詢(xún)，尋找一種合適的測試結果校驗策略，這需要有很大的創(chuàng )造性。目前有很多技術(shù)可以保證在不產(chǎn)生誤報告警的情況下，找到被測試產(chǎn)品的缺陷。
把注意力放在通過(guò)設計保證測試的可延續性上，選擇一個(gè)合適的測試體系架構，你將進(jìn)一步邁向成功的自動(dòng)化測試。
步驟六：有計劃的部署
在前面的故事中，當自動(dòng)化工程師沒(méi)有提供打包后的自動(dòng)化測試程序給測試執行人員，會(huì )影響到測試執行，測試執行人員不得不反過(guò)來(lái)求助自動(dòng)化工程師指出如何使用自動(dòng)化測試程序。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
