亚洲日本乱码卡2卡3卡新区,亚洲精品美女视频,亚洲人成图片小说网站

測試用例的關鍵的認知

無論缺陷預防工作貫徹落實地多好，軟件組件總有缺陷。這很明顯，因為開發商無法阻止/消除軟件開發周期的所有缺陷。因此，軟件必須進行徹底的測試，然后才交付給最終用戶。測試人員的責任是：設計既可以（ⅰ）找軟件缺陷，又能（ii ）評估該軟件的性能，可用性和可靠性等方面的測試。
　　現在，為了實現這些目標，測試人員必須（往往是從一個非常大的執行域中）選擇和/或制定測試用例的有限數量。不幸的是，完整的測試通常不是在這個范圍，預算和時間的約束內實現和/或執行的。重要的是，當測試開始失控且不按計劃地運行時，由于預期無法實際，測試人員往往承受了來自管理層和利益相關者的巨大壓力。
　　因此，測試人員必須有效地計劃測試并制定正確的測試用例，選擇并執行合適的用例，監控過程，以確保有效利用工作資源和時間。所以，要列出這些無疑是一項艱巨的任務；要有效地實施，測試人員需要受過適當的教育和培訓并擁有贏得管理層支持的能力。
　　一般情況下，測試人員會用兩種不同的測試方法，其中，使用常規方法，測試人員主要是嘗試用所有可能的輸入去測試一個模塊或組件，用所有可能的軟件結構去實踐。盡管這種做法仍在使用，測試人員卻在慢慢灌輸推理軟件的一切的價值，最終使他們能夠檢測出所有可能存在的缺陷。但見多識廣且有學問的測試員們都明白，這在現實或經濟上是不可行，不可實現的目標。
　　現在，另一種方法可能就是讓測試員們隨機選擇測試輸入，希望這些測試能將大的缺陷找出來。不過，測試專家認為，隨機生成的測試輸入在評估系統的質量屬性方面表現紀錄欠佳。所以，從測試的角度來看，這是一個無休止的爭論和懸而未決的問題。盡管如此，我們還是認為，測試員的最終目標是了解測試的功能、輸入/輸出域和使用環境，等等。
　　同樣，對于某些特定類型的測試，測試人員也需要詳細地了解代碼是如何構造的。此外，測試人員也需要利用關于常在軟件開發或維護過程中生成的特定缺陷的知識。有了這些信息，測試者就必須明智地選擇測試輸入的子集，以及被認為最有可能找測試過程中條件和限制內的缺陷的測試輸入組合。然而，這個過程需要時間和精力。所以，測試人員知道且贊同：只有開發出基于執行的測試的有效測試用例，才能最大化和/或優化對時間和資源的利用。
　　“有效測試用例”我們是指：“一個很可能找出缺陷的測試用例” 。因此，制定有效測試用例的能力對于一個組織邁向一個更高質量的測試過程來說是非常重要的；反過來，　　一個組織邁向一個更高質量的測試過程對制定有效測試用例的能力也有許多積極影響。
例如，如果測試用例是有效的，那么：
　　檢測缺陷的概率更大。
　　更有效地利用組織資源。
　　測試再用的可能性更高。
　　更符合測試、項目進度、預算，更重要地，提供更高質量的軟件產品的可能性。
測試用例設計方法 - 概念化
　　上面介紹了有效測試用例的種種好處，但縝密考慮測試人員用來設計這些有效測試用例的方法也同樣重要。為了回答這個問題，有必要把軟件作為一個精心設計的產品來查看和/或檢查。現在，有了這個觀念，就有兩個基本方法可以用來設計測試用例：
　　黑盒（有時也稱為功能或規格）測試方法。
　　白盒（有時也稱為clear或透明盒）測試方法。
　　使用黑盒測試方法，測試人員把SUT （測試中的軟件）當作一個不知道其內部結構（即如何運作）的不透明盒子，測試人員只知道它的作用。使用這種方法的SUT的大小可以是一個簡單的模塊、成員函數、對象群、一個子系統、或一個完整的軟件系統。此外， SUT的基礎行為或功能的描述可以由正式規格，輸入/處理/輸出圖（ IPO），或一套定義明確的先決、后置條件來提供；重要的是，另一個值得一提的信息來源是：需求規格說明文檔，通常描述SUT的功能，輸入及預期輸出。現在，鑒于上述來源，測試員提供指定輸入到SUT，進行測試運行，然后確定所產生的輸出是否與說明文檔中提供的一致。因為黑盒測試方法只考慮了軟件的行為和功能，它通常被稱為功能測試，或基于規范的測試。這種方法特別有用，極有助于找到要求和規格中的缺陷。
　　與此相反，白盒測試方法關注將被測試的軟件的內部結構。因此，使用白盒測試方法來設計測試用例，測試人員應該先了解結構，且為了實現這一目標，必須可隨時參考和理解代碼或適當的類偽代碼的要求。一旦對結構有了必要的了解，測試者就可以選擇合適的測試用例去實踐特定的內部結構要素，并確定它們是否正常工作。例如，測試用例通常被設計來實踐所有語句或發生在一個模塊或成員函數中的真/假分支。但是，由于白盒測試的設計，執行和結果分析非常耗時，這種方法被限制和/或通常只適用于軟件的小部分，如模塊或成員函數。然而，白盒測試方法對于找出設計和基于代碼的控件的邏輯缺陷和順序缺陷，初始化缺陷和數據流缺陷等特別有用。
　　然而，從測試員的角度來看，要實現向用戶提供低缺陷高質量的軟件的目標，必須把這兩種方法都用來設計測試用例。另外，這兩種方法都支持測試員選擇有限數量的將被用于測試的測試用例。這兩種方法可以相互補充，因為每個都或許有助于找到某些特定類型的缺陷。重要的是，有了使用這兩種方法設計出的一組測試用例，測試員找到SUT中各種不同類型缺陷的機會就增加了。
　　測試員還有一套有效的可再用的用來進行回歸測試（更改后的重新測試），以及軟件測試的新版本。

　　上面是一份概要：使用任一設計方法制定測試用例的各種可用方法。
　　但是，在使用任一設計方法準備測試用例前有一些因素需要考慮清楚。它們分別是：
　　測試相關風險。
　　預期缺陷類型。
　　測試員的知識和經驗。
　　測試水平和必須進行分組和管理的小組活動。
　　用于執行測試用例的工具。
　　應用程序，軟件和問題域的類型。
　　客戶要求，等等。
現在除了上述因素，以下幾個要點和/或問題在選擇正確的測試用例設計技術中發揮了至關重要的作用：

　　基于“經驗”的測試用例設計
　　在基于經驗的技術中，是人們的知識，技能和專業知識（關于域，技術等）構成了測試條件和測試用例的基礎，且對制定測試條件和測試用例很重要。
　　在這兒，人們技術和業務兩方面的經驗都是絕對必需的，必要的，因為這給測試分析和設計過程提供了不同的角度。
　　重要的是，有了他們使用類似系統工作的豐富（前）的經驗，他們或許對什么會出錯，什么有助于測試有了想法和/或深入的理解。
　　因此，基于經驗的技術與基于規范既與基于結構的技術偕行，又可用于沒有規格，或者規格不足或過時的時候。
　　這可能是用于設計測試低風險系統的測試用例的唯一技術，但是這種方法可能在非常緊急的情況下特別有用，事實上，這是導致探索性測試的一個因素。
　　“隨機”方式—考慮了嗎？
　　通常，任何軟件模塊或系統都有輸入域，從這個域里選擇并使用測試輸入數據建和/或執行測試用例。
　　現在，如果一個測試人員從必要輸入域中隨機選擇輸入，準備測試用例，并用它們來測試應用程序，這種方法被稱為“隨機測試”。
　　例如，如果一個模塊的有效輸入域是1到100之間所有的正整數，然后用這種方法測試人員會隨機或胡亂地從該領域內選擇值，如，選15 ， 27和33。
　　但是，使用這種方法，也有一些一直無解的問題：
　　值（上面的例子中三個值）足以表明，執行測試用或運行例測試時，模塊符合其規格嗎？
　　是否有其他輸入值，比那些（在本例中）被選中的值，更能找缺陷？
　　抑或有效輸入域外的任何值應該作為執行測試用例的測試輸入？
　　這就是說，測試數據應包括大于100的浮點值，負值或整數值？
　　因此，上述問題可以立即通過更加結構化的黑盒測試設計方法解決，盡管使用隨機測試輸入可以節省一些時間和精力，其他測試輸入選擇方法要求。
　　但是，根據許多測試專家，隨機選擇測試輸入會產生一個有效的用于執行測試用例的測試數據集的機會非常小，并且對于一個更結構化的方法，隨機方法生成測試輸入的相對有效性總成為自省和/或研究的課題。
　　測試用例必不可少的部分—概念化
　　首先，設計一個測試用例用來回答這個問題：“我要測試什么？ ” 。因此，對于測試人員來說，開發測試用例時周到地考慮很重要，這能夠明確界定和/或提供需被驗證以確保系統如期運行且能反映出它是用最高質量創建的信心的項目（模塊，應用程序，子系統，或SUT ）的完整概述。
　　現在，無論開發測試用例時用了什么設計技術/戰略，測試人員都必須確保基本涵蓋以下主要內容：
　　摘要 -應該反映實際的主題，類別和功能特性，使測試人員可以輕易地組織測試用例成邏輯組，并相應地對它們進行分類。
　　這部分可能具有關于基于測試時間，工作單元，和優先級等的執行工作的細節。它經常被稱為測試用例的權重。
　　測試用例設計 - 這部分反映了測試用例的整體設計，其中可能包括一些高層次的描述。
　　正式審查 - 包含了關于必須審查或批準測試用例、并定義審批流程的團隊清單的詳情。
　　這部分主要是用來建立一個正式的審查程序，以確保業務流程符合標準。
　　此外，它可能包括關于測試用例所有人，工作項目，通知和成果總結等的細節
　　要求 - 本部分旨在：當要求被添加到測試計劃中時，聯系要求與一個特定的測試用例。
　　因此，一旦需求和測試用例間的聯系被建立，測試人員就可以繼續創建覆蓋報告來了解和確定被測試用例覆蓋的要求的比例有多大。重要的是，通過保持這種關聯，有助于設置和檢查整個項目的可追溯性。
　　先決條件 - 描述了形成前提的或必須在測試人員可以真正開始運行/執行測試用例之前發生的事物。
　　后置條件 - 不像先決條件，后置條件說明了需在測試用例運行/執行完成之后發生的事物。通常是產生適當的確認，如發送電子郵件通知等。
　　預期結果 - 本部分詳細介紹了必須在測試員認為測試運行已取得成功前獲得的結果列表。它可能包含了結果代碼的文件或圖像。
　　測試腳本 - 本部分概述了與特定的測試用例相關的測試腳本。通常，測試腳本有幾種類型，包括手動測試腳本，關鍵字啟用測試腳本，及其中每個測試腳本都包含用來實現一個測試用例的指示的自動化功能測試腳本。
　　在執行過程中，不像使用工具自動運行的自動化測試腳本，手工測試腳本是用語句處理語句。
　　測試執行記錄 - 通常測試執行記錄包含測試用例的詳細信息，及從測試用例執行產生的高層次結果的細節。
　　重要的是，它們提供測試執行所需的相關硬件和軟件環境的細節。例如，如果當運行在兩個不同的操作系統和兩個不同的硬件平臺上，且使用了不同的瀏覽器的測試用例通過了，那么測試員可以為這些組合中的每一個創建測試執行記錄。
　　測試執行記錄還包含與該測試用例運行，測試運行的詳細記錄，以及所有執行結果的詳細歷史相關的的整體結果。
　　附件 – 本部分通常包含了支持測試用例的所有文檔和文件。
　　風險評估表 - 本部分意在列出與某個特定的測試用例相關的風險。
　　所以，當上述所有部分都與測試用例相關，且如果這樣的測試例被執行，那么就是一個好的跡象：關于實現完整的測試覆蓋率，效率等方面的標準已達到。

posted on 2014-05-13 13:12 順其自然EVO 閱讀(223) 評論(0) 編輯收藏所屬分類: 測試學習專欄

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 如何進行Web服務的性能測試？利用drozer進行Android滲透測試 Appium Android Bootstrap源碼分析之命令解析執行 Fliptest—iOS 的應用A/B測試框架 iOS功能測試工具 Frank iOS單元測試框架Kiwi for iOS Appium Android Bootstrap之控件AndroidElement 移動應用測試框架—Calabash Android 簡介 Appium Server源碼分析之作為Bootstrap客戶端移植MonkeyRunner的圖片對比功能實現-Appium篇

qileilove

測試用例的關鍵的認知

導航

統計

常用鏈接

留言簿(55)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜