自動化測試的發(fā)展趨勢.doc

自動化測試的發(fā)展趨勢 提及自動化測試，如果單純這么說，那么范圍非常廣泛。單元測試的自動化，功能測試自動化，性能測試自動化都屬于自動化測試的范疇。而我們常說的自動化測試往往指的是UI功能自動化測試。 其實，在自動化測試領(lǐng)域，較為成熟的應(yīng)用集中在單元功能自動化測試和性能自動化測試。在單元自動化測試階段，現(xiàn)在產(chǎn)生了很多成熟的理論和方法，指導(dǎo)著工作的開展與展開。 在我個人的編碼過程中，也嘗試過測試驅(qū)動開發(fā)，在功能編寫之前先進(jìn)行測試代碼的編寫，當(dāng)然，我使用的語言往往是Python，用的是Python的白盒自動化測試框架：unittest。然后，這種模式是和語言無關(guān)的，包括各種*unit。 在后續(xù)的代碼開發(fā)和重構(gòu)中，之前構(gòu)建的白盒測試用例也都有效的節(jié)約了測試的勞動力，大大提高了測試的覆蓋度。 性能自動化測試工具的應(yīng)用比較多。像我的工作中往往關(guān)注進(jìn)程本身的CUP,內(nèi)存，發(fā)展到后續(xù)的I/O，子進(jìn)程數(shù)量，線程數(shù)等等。這些也都有成熟的工具可以應(yīng)用。對于典型的協(xié)議層面的性能自動化測試，LR是比較成熟的工具。 曾經(jīng)和一個自認(rèn)為測試技術(shù)不錯的人探討過，他尊稱LR為性能測試之王，對此我深表遺憾。還有很多非常好的性能自動化測試工具。我們的產(chǎn)品特性讓我有機(jī)會接觸到業(yè)界的思博倫，BPS等等廠商的性能測試設(shè)備，進(jìn)行二三層的測試工作。 在這些測試工具中，開放了良好的二次開發(fā)接口，可以進(jìn)行自動化測試工具。 當(dāng)然，包括LR，包括思博倫或者BPS等廠商的測試設(shè)備，價值不菲。還有一種比較極端的請款就是自我開發(fā)。自我開發(fā)的工作難度比較過，因為要模擬并發(fā)很難，不過在一些要求并非十分嚴(yán)格的情況下，也是一種實現(xiàn)方式。 說了這么多，只是想說明，當(dāng)我們在探討自動化測試這個話題時，要明確其范圍，這個領(lǐng)域非常的廣，如果范圍不清，探討就不再有其意義。4. 關(guān)于自動化測試發(fā)展的思考： 上面談及了自動化測試的諸多領(lǐng)域。而我也一直在思考如果在我們實際的工作中應(yīng)用自動化測試輔助我們的功能進(jìn)行。 當(dāng)前的UI功能自動化層面從業(yè)人員比較多，多也有回歸測試階段節(jié)約資源的觀點。但我想，現(xiàn)在我們是否可以打破自己的視野，將自動化測試提前到前端去，而不是簡單的后端被動應(yīng)用。 首先說說UI的功能測試自動化?，F(xiàn)在的技術(shù)發(fā)展據(jù)說有：應(yīng)用為王的口號，在產(chǎn)品開發(fā)技術(shù)的逐漸成熟下，技術(shù)壁壘越來越低，而客戶的感知往往決定著產(chǎn)品的成敗。所以對于UI方面的測試重視逐步提高。 由此衍生了諸多的UI自動化測試方法的工具，QTP，Selenium，TC等等，太多了。 然后，拋開這些工具，讓我們來思考UI功能自動化測試本身，它自身的投入產(chǎn)出比，我們當(dāng)前是否做的足夠好？ 先說聽到的兩個案例吧： 1. 看到微軟的測試人員寫的一篇論文，在瀏覽器兼容性測試之前，通過編碼實現(xiàn)HTTP協(xié)議的GET，POST等函數(shù)，進(jìn)行與后端web服務(wù)器的功能交互，驗證功能的有效性。 從這個測試模式可以看出，至少在此測試階段，弱化了UI的測試，而主要進(jìn)行接口層面的功能驗證。這也體現(xiàn)了模塊化，解耦合的思想。后續(xù)當(dāng)然也會進(jìn)行UI的測試工作，但也許后續(xù)的會種感受，輕功能，當(dāng)然是有相應(yīng)的策略了，在此不作揣測。 2. Baidu的技術(shù)交流會，陳景衛(wèi)（如果名字打錯請見諒）先生介紹百度當(dāng)前的自動化測試分工，有7-2-1的劃分，貌似的意義在于七成在后臺，二成在功能，一成談UI，也不約而同的對UI的功能自動化進(jìn)行了一定程度的弱化。 其實在我們綠盟，雖然我們的自動化測試投入人力有限，也一直在進(jìn)行領(lǐng)域的探索。跟隨他們的腳步吧或者說也有同樣的認(rèn)知，我們在推廣UI功能自動化的同時就進(jìn)行了后臺功能測試重點推廣。爭取將自動化測試逐步推向前，而不是只在簡單的最終段。 所以，我在此想強(qiáng)調(diào)的是，隨著自動化測試從業(yè)人員的技術(shù)積累，所謂的在回歸測試應(yīng)用自動化測試等等的觀念可以做寫改進(jìn)了，我們理論上已經(jīng)有能力將自動化測試應(yīng)用到產(chǎn)品開發(fā)流程的前端。5. 我們該如何做： 既然有這樣的想法，具體如何實現(xiàn)才是關(guān)鍵。 回歸到底一段描述的內(nèi)容，我的面試題，我們是否可以直觀的看出，這樣的測試題和所謂研發(fā)的測試題目是否還有本質(zhì)的質(zhì)的區(qū)別？包括我們公司現(xiàn)在的招聘工作，研發(fā)測試都是同樣的筆試題，也在深刻的體現(xiàn)一個問題： 研發(fā)測試工作界線的弱化。 首先，現(xiàn)在的要求是研發(fā)、測試都要有強(qiáng)烈的質(zhì)量意識。這點其實很多研發(fā)職位的人員是有非常強(qiáng)烈的質(zhì)量意識的。他們對于產(chǎn)品質(zhì)量的要求甚至要比所謂的測試工作者更強(qiáng)。二者本應(yīng)是相輔相成的互助模式，而非所謂的敵對。 便如三權(quán)分立的思想，在合作的同時，彼此制衡，來保證產(chǎn)品的質(zhì)量。 隨著這個行業(yè)的發(fā)展，競爭逐漸激烈，門檻也會逐步提高。 在這種情況下，我們的測試人員還有理由沒有編碼能力嗎？所以，編碼能力必將成為測試從業(yè)者的基礎(chǔ)技能之一。 另外就是，要堅定的認(rèn)識到，自動化測試的推進(jìn)不再是產(chǎn)品測試人員的工作，需要研發(fā)測試的合力。 在產(chǎn)品的設(shè)計階段，留出良好的測試接口，當(dāng)然，可以包含在發(fā)布代碼中，也可以調(diào)試模式或者其他方式，現(xiàn)在也有成熟的理論支撐，在后續(xù)的發(fā)布版本中去掉。有了良好的測試代碼接口，我們的自動化測試人員可以大幅提高開發(fā)效率，進(jìn)而提高投入產(chǎn)品比，讓自動化測試不只停留在一個理論的階段。 同時，也要推進(jìn)研發(fā)人員的白盒測試工作，當(dāng)然，具體誰來執(zhí)行白盒測試各公司分工不同。至少要有認(rèn)識，如果他們不愿意或者排斥白盒測試的工作，你是否有能力承擔(dān)起白盒測試的工作？ 相比UI的功能自動化測試工作，我一直認(rèn)為白盒測試自動化和性能測試自動化相對要容易些。 對于想實現(xiàn)最終的自動化測試，可以逐步推進(jìn)，從白盒測試自動化，到功能測試自動化，UI功能自動化到性能測試自動化。在設(shè)計層面加入一些思考，讓彼此解耦合，能夠