【正文】 面的代碼片斷所示，我們通過調(diào)用AjaxHelper的BuginForm生成了一個以Ajax形式提交的表單。表單成功提交（服務端因?qū)伋龅漠惓＿M行處理而返回一個封裝異常的Json對象，對于提交表單的Ajax請求來說依然屬于成功提交）后會調(diào)用我們定義的回調(diào)函數(shù)login。在該JavaScript函數(shù)中，我們通過得到的對象是否具有一個ExceptionType屬性來判斷服務端是否拋出異常。如果拋出異常，在通過調(diào)用alert方法將錯誤消息顯示出來，否則顯示“認證成功”。我們再次運行我們的程序并分別輸入不合法的用戶名和密碼，相應的錯誤消息會以對話框的形式顯示出來，具體的顯示效果如下圖所示。對于一個新項目，QA通常會首先為新特性創(chuàng)建手工測試用例，為了之后維護方便，也通常將這些用例存放在一張Excel表或者一個專門的測試用例管理 系統(tǒng)里。而在項目進行過程中或之后，具備自動化測試能力的QA團隊會將手工測試用例轉(zhuǎn)化為代碼，加入套件(Suite)中，用于之后的回歸。以往我們認為手工測試用例與自動化代碼之間存在聯(lián)系，但并不緊密： 手工測試用例文檔很容易閱讀，可以幫助學習業(yè)務，但因為維護不夠靈活，很難跟上快速的變化。依賴手工測試用例對項目進行回歸又是及其痛苦的。 自動化測試代碼可以很明顯的提升效率，但不容易閱讀。因為人們通常缺少更新代碼注釋的動力（沒什么外人會用到，老鳥又不依賴它），久而久之我們不知道那一堆自動化用例究竟測了些什么，導致通過率逐步走低，又無人維護。自動化測試最終土崩瓦解。這似乎是一種宿命般的失敗。有些團隊希望建立自動化測試體系，卻從一開始就遇到類似的問題，導致進展緩慢，無法持續(xù)向老板秀出效果，最終又退縮回原點。原因是什么？怎么去破解這個困局呢？1. 用例文檔不應該與自動化代碼分離，而應存在于代碼中，隨著代碼的變化而及時更新。2. 用例文檔應該簡潔，可以自我組織與管理，并以一種清晰的結(jié)構(gòu)被展現(xiàn)和分享。3. 自動化測試用例的運行歷史應該被測量和記錄，數(shù)據(jù)可以集中形成幾個直接清楚的度量指標，反映一個周期內(nèi)的平均質(zhì)量水平。4. 度量指標應該可以形成簡潔好看易懂的質(zhì)量報告，向相關(guān)各方展示測試工作對產(chǎn)品關(guān)鍵方面的評測結(jié)果。TestMP的測試用例管理和度量就是按照以上四點，為破局提供了一種解決方案。case的獨立性　 　通常一個test suite包含了一組相近的或者有關(guān)聯(lián)的test case. 而每一個test case應該只測試一種場景,根據(jù)case復雜程度的不同場景同樣可大可小,可以是某個功能的測試也可以是端到端的完整測試.(當然也有特殊的寫法比如工 作流測試和數(shù)據(jù)驅(qū)動.) case的獨立性又有哪些需要關(guān)注的點呢?　 　首先一個test suite內(nèi)的test case在執(zhí)行時不應該相互影響, 應該將通用的背景部分提取出來放到suite setup中, 允許我隨機的跑某一個case或者亂序的跑這些case. 如果case的步驟有造成環(huán)境被破壞的風險,那應該在case teardown中將環(huán)境恢復,并且在case setup中做環(huán)境監(jiān)察以及時的終止case. suite level和folder level同樣要注意獨立性的問題,在CRT中通常會將數(shù)百數(shù)千的case放在一起跑,robot并不會規(guī)定case執(zhí)行的順序所以從某種程度上來說它是 fail時信息的抓取上,經(jīng)過一個晚上大批case的執(zhí)行之后,環(huán)境通常已被破壞, 希望通過保留現(xiàn)場來用作case失敗問題定位是不現(xiàn)實的.　　所以每個case都應該準確的收集其開始和結(jié)束之間的信息.　　case的可遷移性　　case的可遷移性主要考慮:case對執(zhí)行環(huán)境的依賴,case對外部設備的依賴,case對測試對象的依賴.　　,你一直在個人PC上編寫的用例并執(zhí)行測試,但是不久之后你的用例就會被遷移到組內(nèi)的測試執(zhí)行服務器上,之后又被部署到持續(xù)集成服務器上,　　(windows,linux)和或者不同的腳本命令(CentOS,RedHat,MacOS)　　總之要像Java宣揚的那樣一處編譯處處運行.　　,我們會引入一些外部設備如Spirent、Cisco的一些輔助測試設備,各種網(wǎng)絡設備交換機、路由器,還有一些自行開發(fā)的模擬設備.　　外部設備會不斷的升級或者更換,在編寫用例時我們就需要考慮如何用一套case更好的兼容這些測試設備. 我有如下幾點建議:　,組織成組級別的庫.　　ii.　　,這里我考慮到的是如果測試對象是一個軟件平臺,CPU、內(nèi)存、組件的性能和數(shù)量都可能不同.　　對測試對象的依賴不僅要考慮在不同設備上的可執(zhí)行性,重點要考慮測試覆蓋率,由于設備組件的增多你的用例可能無法覆蓋到這些組件,或者捕捉不到某個性能瓶頸,這樣測試結(jié)果的可靠性也大打折扣.　　case的可重用性　　自動化用例的開發(fā)通常是一項費時的工作,它需要的時間會是手動執(zhí)行用例的10倍、20倍甚至更多. 我們通過搭建測試框架和封裝資源庫來實現(xiàn)最大范圍的可重用性.　　這里我考慮用例的可重用性包括兩塊:邏輯層的抽象和業(yè)務層的重用.　　對一個產(chǎn)品或者功能進行自動化工作時,我們要考慮這些可用性:首先根據(jù)測試邏輯的不同對測試用例進行分類,根據(jù)邏輯的不同選擇搭建有針對性的case框架,Work Flow, Data Driven等.　 　建立公共的庫,將業(yè)務的原子操作抽象出來,并且鼓勵其他同事對庫進行補充和調(diào)用,. 基于底層API編寫的業(yè)務操作也具備可重用性,比方說測試場景(背景資源)的建立、工作流的操作組合、檢查點都可以被復用. 層次分明的抽取時重用性的基礎(chǔ),提高可重用性可以減少開發(fā)時間,也方便日后的維護中的迭代修改.　　case的效率　 　不同的case執(zhí)行時間相距甚遠,短則數(shù)秒長則數(shù)小時甚至數(shù)天, 我們放眼某一個或者某一組case時,開發(fā)人員能在提交代碼后快速的獲得測試結(jié)果反饋,測試 人員能在最短的時間內(nèi)執(zhí)行更大范圍的測試覆蓋,不僅能提高團隊的工作效率也可增強團隊的信心.　　在編寫用例時我們應該注意哪些方面來提高用例的性能?　　對于單一的case我的注意點多放在一些細節(jié)上,例如:　　,如果檢查失敗，則盡快退出執(zhí)行.　　 抽取到suite甚至folder level, 抽取時可能需要做一些組合, 但決不允許出現(xiàn)重復的建刪操作.　　，sleep通常緊接著hard code的時間,wait until ...來代替.　　,我通常會再三確認其是否清楚它的必要性.　　對于批量的case,我們要如何才能獲得更高的效率呢?　　,并行方案總有著嚴苛的條件:　　,我們將軟件質(zhì)量分為0~10級,對應的把測試用例分為6~10級,從普通的功能測試開始測試復雜度逐級遞增.　 　 集。軟件人員修改了BUG,我可以根據(jù)BUG的復雜度選擇7和8級的用例來驗證,系統(tǒng)級測試時我們又會主要測試8和9級的用例.　　分級可以靈活調(diào)度用例,并給出更快的反饋,加速迭代過程.　　　　基于風險的測試簡單的說就是根據(jù)優(yōu)先級來選擇需要運行的測試,優(yōu)先級根據(jù)兩個最基本的維度:　　功能點發(fā)生錯誤的概率,以及發(fā)生錯誤后的嚴重性,根據(jù)兩者分值的乘積來排序優(yōu)先級.　　一般從用例失敗率,bug統(tǒng)計,出錯的代碼段,只有100%的測試覆蓋才能給他們足夠的信心.　　以上是個人的一些積累,由于框架的限制一些建議不一定適用于你的實際工作. 如果你有什么建議歡迎留言. Thx!自動化測試的基本流程　　自動化測試的基本流程包括：測試需求分析、測試計劃、測試用例設計、執(zhí)行測試、測試結(jié)果的評估?！　∽詣踊瘻y試與人工測試的不同之處在于前者在完成測試計劃后就需要搭建測試環(huán)境和測試場景，在測試用例設計時 所示。　　使用自動化測試在各個階段需要注意的事項如下：　　1）需求分析階段：　　假如測試項目確定在該項目中需要使用自動化測試，我們就需要進行自動化測試需求分析的設計，并在《測試需求說明書》補充說明。　　2）測試計劃：　　在測試計劃中需要確定自動化測試使用的階段、測試范圍以及相應的測試用例、測試數(shù)據(jù)的準備方式，便于自動化測試的建立。確定測試所使用的測試技術(shù)及測試體系結(jié)構(gòu)，建立測試程序與測試需求之間的聯(lián)系（一般使用測試管理工具如QC進行關(guān)聯(lián)），確定哪些測試使用自動測試方法、工具，以及測試數(shù)據(jù)的準備，決定如何進行自動化測試以及測試方法等。　　3）自動化測試環(huán)境的搭建。　　4）編寫自動化測試用例并編寫測試腳本（建議測試腳本使用管理工具控制管理）：　　這個階段有一個重要問題需要解決，即準備數(shù)據(jù)，如系統(tǒng)的基礎(chǔ)數(shù)據(jù)、用戶、權(quán)限等，沒有這些數(shù)據(jù)就無法登錄和執(zhí)行其他操作?！　?）強化測試腳本，保證測試腳本的可用性　　6）測試結(jié)果需要注意保存方式：　　測試執(zhí)行結(jié)束后，需要對測試結(jié)果進行比較、分析以及結(jié)果驗證，得出測試報告。其中總結(jié)性報告是提供給被測方的中高層管理者及客戶的，！希望您提出您寶貴的意見，你的意見是我進步的動力。贈語； 如果我們做與不做都會有人笑，如果做不好與做得好還會有人笑，那么我們索性就做得更好，來給人笑吧！ 現(xiàn)在你不玩命的學，以后命玩你。我不知道年少輕狂，我只知道勝者為王。不要做金錢、權(quán)利的奴隸；應學會做“金錢、權(quán)利”的主人。什么時候離光明最近？那就是你覺得黑暗太黑的時候。最值得欣賞的風景，是自己奮斗的足跡。壓力不是有人比你努力，而是那些比你牛幾倍的人依然比你努力。 參考