對象庫編程VS描述性編程

對象庫編程和描述性編程的區別？    

    描述性編程採用的是描述屬性的方式來識別對象，不需要對象庫。開發的腳本可移植性強。不過對於腳本的編寫能力也比較的強。
    對象庫編程則是完全依靠QTP自帶的對象庫進行識別對象，有些限制，對象庫如果出現了一些對象屬性的變動或者是腳本一到別的機器上，可能就不能識別對象，導致不能回放腳本。

專家建議，剛開始學習是使用對象庫編程進行學習QTP的自動化流程，熟悉後再進行描述性編程的開發，不過對於描述性編程，你需要學好正則表達式是主要的。

最近也在弄努力剋制，不能完全依賴對象庫編程，每次發新版本，回放腳本總出問題，這是相當令人頭疼的問題。加油啦！學習描述性編程。

對象庫編程和描述性編程各自的優缺點？

  自動化腳本編寫都涉及到對控件的操作，那麼是把這些要操作的控件放在一起進行管理，還是把控件放到腳本中在操作時進行描述呢，這一直都是很有爭論的問題。兩種操作方式都有其優劣，不能絕對的說其中某一種一定比另一種好，根據不同的應用場景，選擇不同的操作方式，才能揚長避短。 

對象庫，就是把控件放在一處地方集中進行描述、管理，使用時只需要使用該控件的別名即可。如：

LoginPage.StandButton.click

它的優點：

一、這樣的腳本看起來很簡潔

二、控件的描述只需要在對象庫做一次，不需要反覆的在腳本中做

三、如果控件發生了變化，那麼你需要做的僅僅是維護對象庫，不需要去維護所有的腳本

四、控件對象可以共享，你做過的工作，不需要別人再來做一次

五、對象庫可以提前構建，不依賴對象的具體實現，這樣我們的測試腳本也就可以提前編寫，推動整個自動化工作前移

六、其它…………

它的缺點：

一、腳本是很簡潔了，但其可讀性變差了，至少增加了讀腳本的成本

二、既然放在一地方進行維護，就涉及到命名規範的建立，否則就會亂

三、維護的時候，加大了評估所帶來的影響的難度，因爲你可能不知道這個對象在哪裏被引用了

描述性編程,就是在編寫測試腳本時描述需要操作的控件。如：

p.button(“#name_submit”).click

它的優點：

一、腳本編寫很靈活

二、腳本可讀性相對對象庫來說，會好很多

三、整個自動化測試框架會相對簡單，帶來的是自動化測試相對穩定

四、一定程度上降低了腳本之間的耦合性，控件的維護不會影響到其它腳本

五、其它…………

它的缺點：

一、最大的缺點是顯而易見的，腳本的維護難度加大了，如果控件發生了變化，維護的工作量很大

二、控件的描述要反覆的做，不能共享

三、測試腳本相對來說變的複雜了，沒有對象庫的腳本簡潔

四、正是因爲腳本的編寫依賴着控件的描述，所以腳本的編寫也很難提前

上面羅列了部分兩種操作模式各自的優缺點，如何做出正確的選擇，就需要根據應用場景有所取捨。

取捨：對於大型的、持續優化的被測系統，對象庫使用的選擇要優與描述性編程，這種場景下的自動化測試不是各自獨立的，不是臨時性的。對象庫的前期投入，表面上可能是會加大自動化的成本，但它的共享和維護都降低了後續自動化的成本，而且爲自動化測試腳本的關鍵字驅動打下了基礎，並且可以推動控件定義中的一些標準和規範的實施，這是可以提高被測試系統的可測試性以及穩定性。

對象庫編程VS描述性編程轉載自：http://blog.163.com/tech_qa/blog/static/13017634920105179235405/

版權歸原創作者所有