<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          一種有效的測試策略

          • 發布:軟件測試培訓
          • 來源:網路
          • 時間:2017-04-06 16:50

          在最近的一個大型項目中,我們在早期就定下了一個目標:不會在軟件中使用大量QA人員專注于手工測試。通過手工測試發現bug極其耗時且成本高昂,這促使團隊嘗試盡可能的將質量內嵌到產品內部。但這并不意味著手工測試毫無價值,因為人們總能在怎樣使用軟件上給你一些特別的驚喜。

          這是一個為期18個月左右,周期很長的項目,并且后續也會持續更新。 在項目初期,團隊就意識到項目成功的重中之重在于一個優秀的測試策略,尤其是讓我們的團隊能夠做到:1)隨著項目時間的推移能夠持續的提高團隊的工作效率。2)不管面對的變更是大是小都能夠具有足夠的信心。

          我們花費了很長時間才確定了一種有效的策略。這在很大程度上是因為我們不得不學習怎樣讓我們的程序在所有層上都具有可測性。雖然所有的項目團隊成員都具有TDD(測試驅動開發)的經驗,但僅僅這樣并不足以建立有效的測試策略。

          測試分層

          給不同的測試分類是一件令人煩惱的事。有功能測試,集成測試,單元測試,驗收測試,slow tests,fast tests,UI測試...等等等等。然后我們發現屬于我們的測試主要有三種類型:

          · 系統測試

          · 皮下測試

          · 單元測試

          它們之間的區別主要在于被測試內容的范圍。系統測試指的是通過應用的外部接口進行運作,無論對象是一個瀏覽器,文件下拉菜單,隊列,window窗體應用或者其他的什么東西。

          皮下測試運行在外部用戶接口之下。如果測試的是Web應用,皮下測試在我們理解就是指在真實的類

          以及環境部署到位的情況下,通過命令處理器進行發送的表單對象。繞過UI層邏輯,直接到達domain層。發送表單對象,拋出”成功/失敗”的執行結果。

          對于最底層而言,我們有單元測試。單元測試用于測試一個類,并且可以是fast test 或者 slow test中的一種。Fast Test 即是常規的TDD測試,用于增量的類設計。Test doubles曾被認為是必要的,但是除非系統交互非常值得關注,否則嚴格的 基于交互的測試 并不是那么有價值。我們同樣也有slow 單元測試,其同樣可被分類為 交互測試。當然它們同樣可歸類為 repository tests, persistence tests等。

          單元:皮下:系統 測試在我們的測試工作中各自占的比重差不多是 10:2:1。 為了完成項目我們做了大約 5000 個單元測試,1000個皮下測試,500個使用 WaitN 以及 Gallio驅動瀏覽器的系統測試。6000個單元/皮下測試的執行時間大概是10分鐘,而剩下的500個UI測試大概需要50分鐘完成。

          單元測試策略

          單元測試是在嚴密的TDD模式下開發的。我們在功能實現之前編寫單元測試,并用這些測試驅動代碼設計。這些測試可以幫助發現設計問題、封裝問題、代碼異味等。

          我們努力避免編寫純粹用于提供測試的代碼。它們常常意味著我們有設計問題、責任錯位或封裝已被破壞。

          隨著我們越來越深入項目管道,我們對交互測試的重視越來越少。 如果你真的對交互感興趣,那么通過mock進行的交互測試也僅僅是有趣而已。但更多的時候,我們更感興趣的是附加作用,而交互只是一個實現細節。反之,我們經常做的是模擬(mock)出過慢或不可測的代碼,比如存儲庫、基于外部服務的外觀、配置類等等。否則,我們有限的模擬只是模擬了我們感興趣的那些觀察點。

          在大型項目中的某些時間點,為了提取出能加快功能交付的理念,設計往往需要做大型的重構。在我們上一個項目中,我們發掘出了如下理念:

          · AutoMapper

          · 將表單作為單獨的命令消息處理

          · Input builders

          有了以上這些,單元測試是重構時的保障。但只有我們依賴這些測試來捕獲應用程序中所有有趣的行為時,才能有保障的作用。為了允許有效的大中型重構,我們需要增加額外的測試層級。

          皮下測試策略

          皮下測試,顧名思義,所有的測試都是在用戶界面之下進行的。在MVC應用程序中,皮下測試是測試控制器下面的所有內容。對于Web service,一切測試都在終端下進行。皮下測試的思想是,應用程序的最上層不執行任何實際的業務邏輯,而只是外部接口與底層服務之間的連接。

          皮下測試的重要性體現在我們希望在拋開如用戶接口和外部服務這類外部連接點的情況下,能夠在整個系統運行的同時測試業務邏輯。相對于單元測試關注小模塊的設計,皮下測試關注的不涉及設計,而是測試整個系統的基本輸入和輸出。

          要建立有效的皮下測試,我們可以嘗試通過常見的邏輯流程建立uniform pinch points。例如,我們可以建立一個命令消息處理系統,或一個普通的查詢界面。在最近的一個處理批處理文件項目上,批處理文件中的每一行都被轉換為一條消息。然后,我們創造一條消息,發送給這個系統,然后驗證處理該消息的所有異常情況。

          由于皮下測試不是基于設計而是基于高級(業務)行為,它們是理想的基于場景的測試策略,如BDD或Testcase Class per Fixture模式。如果我們要進行大的重構,我們需要這些高層次的測試,為商業行為建立全面的安全保障。由于皮下測試更關注于端對端的邏輯,所以它也是標志功能點完成的一個重要的目標點。

          雖然皮下測試使我們能夠安全地執行較大的重構,但它仍無法保證我們可以放心地將系統升級到生產環境。

          全系統測試策略

          起初,我們把全系統測試稱為“UI 測試”,直到我們的項目越來越多地牽涉到集成策略。這時輸入到我們系統中的不再是瀏覽器,取而代之的是消息,來自 REST 端點、FTP 或批處理文件。UI 測試只是全系統測試的一個子集。全系統測試背后的思想是,我們想按照軟件在生產環境中的使用方式來測試它們。對于一個 MVC 應用程序來說,就是基于瀏覽器的測試。對于批處理文件來說,我們會使用實際的文件。對于 REST 使用實際的 HTTP 請求。對于消息則使用實際的隊列和消息。

          如果我們想知道,應用程序在部署到生產環境之前是否能按照預期工作,一個有效而且高效的方法是,創建一個自動化測試來測試整個系統。如果我可以讓 UI 測試登錄到應用程序中、創建一個訂單,然后我可以驗證是否產生了一個訂單請求,那么我會感覺很良好。

          關于全系統測試的一個常見誤區是認為它就是黑盒測試。然而,全系統測試的特點在于,你必須對系統內部發生的事情了如指掌。實際上,全系統測試甚至還可以利用域模型來生成數據,而不是一個純粹為測試目的而構建的系統后門。很多團隊容易掉進去的一個大坑是,不按照與生產環境一樣的代碼路徑來測試,這將導致系統處于古怪的、無效的、很難處理的狀態。

          在我們的項目中,全系統測試代碼是我們在聲稱一個功能/故事做完之前的所寫的最后代碼。對于描述一個功能的“已完成”特性來說,手工測試的成本太高、而且不可靠。但是,如果我能像在生產環境一樣去測試,通過完全一樣的外部界面來完成,那這樣的手工測試也算是成功的。

          全盤考慮

          在一個未經測試過的應用程序中,作為提高覆蓋率的手段,我們發現實際上最有價值的測試策略是從全系統測試開始,然后往下移,直至單元測試。我們先做最寬松、最簡單的斷言,然后慢慢往下移,直至單元級別的邏輯。在全新開發的應用程序中,我們傾向于不只是特別關注某一個區域,因為對于一個需要長期維護的系統來說,所有的測試都很重要。

          這種測試策略確實需要一定的投資。我們發現,當我們知道這個應用程序對客戶的業務有決定性作用的時候,這樣的全盤考慮在特別有效。如果一個應用程序對業務有決定性作用,那它將不得不面臨變更。當變更來臨的時候,我們最好能安全地實施變更而不影響客戶的業務。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:設計測試用例的四條原則
          下一篇:從哪采集需求?這十方面就夠了

          變革中的軟件測試——組織篇

          五種比較好Android自動化測試工具推薦

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>