自動(dòng)化測(cè)試的發(fā)展趨勢(shì).doc

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