像對待自己的孩子一樣對待每一個軟體測試案例_測試案例

來源:互聯網
上載者:User

  因項目的需要,最近一直在整理軟體測試案例。大量的軟體測試案例和業務整理起來並不容易,雖然耗費了相當長的實踐,卻也因此收穫一些想法,希望能對以後的軟體測試工作有所協助。

  在整理測試案例過程中,從頭到尾都在思考一個問題,為什麼這些用例需要整理呢。如何才能做到讓後面的人再也不用整理這些用例,而是很開心的按照一定的規範做著每一個日常或項目,以期投入更多的時間把力氣用在刀刃上,不遺漏bug呢。正如題所說,我們要像對待自己的孩子一樣對待每一個用例,用心寫好每一個用例。以下是小女的一些拙見,提出來供大家討論。:-)

  一個好的介面/單元測試用例應該做到:

  1、對環境沒有依賴

  2、驗證點檢驗完全(不能因為用例編寫經常拷貝而忽略或遺漏)

  3、用例分類合理,命名通俗易懂

  4、對資料沒有依賴,資料由所測的代碼自動建立。一定需要測試資料的情況下,也要將資料準備完全

  5、每一個用例運行完成後都要刪除測試資料

  6、能夠在一個用例中覆蓋到的測試點,盡量在一個用例中完成,以減少後續對測試資料和用例本身的維護成本。

  7、各個測試案例相互獨立,不相互依賴

  8、盡量減少和開發代碼的耦合,能夠從上層覆蓋到的情況盡量從上層覆蓋

  9、通俗易懂,注釋完全,後人很容易根據用例理解業務

  10、用例結構清晰,測試案例也可以學習開發的代碼,採用一些設計模式進行最佳化,提高用例本身的代碼品質,減少後續用例的編寫成本和維護成本

  另外,如果能根據不同業務分門別類,不同業務的根目錄或入口的地方增加註釋類,或者主流程測試類別裡。一方面可以供後人蔘考,另一方面也可以用作自己的備忘錄。和代碼放一起,同樣方便瀏覽。開發也習慣看代碼裡的注釋,錯誤的地方容易及時發現,也利於和開發的溝通。當然,這裡所說的指的是注釋一些比較細節的代碼實現方面的業務點和總結。

  更重要的是,如果能定義一個用例規範,我們測試也可以像開發一樣進行review. 功能測試的會對手工執行的用例進行評審,開發組會對代碼進行review。我們介面測試會對用例設計進行評審,那麼同樣也可以對用例實現進行review. 雖然不同項目的業務不同,測試案例實現方式架構也可能不同,但我相信一個好的測試案例的標準一定是相同的。

  我相信,在那麼多雙眼睛的監督下,如果我們每個項目的所有測試案例都能做到上面這些點,那麼能做到讓用例的維護變成一件輕鬆的事情,讓用例一旦運行不過就意味著一個bug的出現, 這樣的日子離我們也就不再遙遠了。並且當有一天我們離開現在的項目組時,我們曾經用心編寫的用例就不會因為維護成本太高,而變成一堆一文不值的垃圾。

  但願這樣的日子離我們不再遙遠,也相信它很快就會到來,阿門。:-)

本文轉載自51Testing軟體測試網,查看更多:http://www.51testing.com/html/news.html

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.