第一篇：黑盒測試心得
“黑盒”測“外”不測“內”
“黑盒”測的是功能
黑盒測試也稱功能測試或數據驅動測試。它在已知產品應具有的功能的條件下，通過測試來檢測每個功能是否都能正常使用。在測試時，把程序看作一個不能打 開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否 能適當地接收輸入數據而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。
“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使 用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
“黑盒”的兩種基本方法
黑盒測試有兩種基本方法，即通過測試和失敗測試。
在進行通過測試時，實際上是確認軟件能做什么，而不會去考驗其能力如何。軟件測試員只運用最簡單，最直觀的測試案例。
在設計和執行測試案例時，總是先要進行通過測試。在進行破壞性試驗之前，看一看軟件基本功能是否能夠實現。這一點很重要，否則在正常使用軟件時就會奇怪地發現，為什么會有那么多的軟件缺陷出現？
在確信了軟件正確運行之后，就可以采取各種手段通過搞“垮”軟件來找出缺陷。純粹為了破壞軟件而設計和執行的測試案例，被稱為失敗測試或迫使出錯測試。
黑盒測試的設計方法
黑盒測試是以用戶的觀點，從輸入數據與輸出數據的對應關系出發進行測試的，它不涉及到程序的內部結構。很明顯，如果外部特性本身有問題或規格說明的規 定有誤，用黑盒測試方法是發現不了的。黑盒測試法注重于測試軟件的功能需求，主要試圖發現幾類錯誤：功能不對或遺漏、界面錯誤、數據結構或外部數據庫訪問 錯誤、性能錯誤、初始化和終止錯誤。
具體的黑盒測試方法包括等價類劃分、因果圖、正交實驗設計法、邊值分析、判定表驅動法、功能測試等。在使用時，自然要針對開發項目的特點對方法加以適當的選擇。
◆ 等價類劃分
等價類劃分是一種典型的黑盒測試方法，用這一方法設計測試用例可以不用考慮程序的內部結構，只以對程序的要求和說明，即需求規格說明書為依據，仔細分析和推敲說明書的各項需求，特別是功能需求，把說明中對輸入的要求和輸出的要求區別開來并加以分解。
由于窮舉測試的數量太大，以致于無法實際完成，促使我們在大量的可能數據中選取其中的一部分作為測試用例。例如，在不了解等價分配技術的前提下，測試 了1+1、1+2、1+3和1+4之后，還有必要測試1+5和1+6嗎?能否放心地認為它們正確嗎?那么1+999…（可以
輸入的最大數值）呢？這個測試 用例是否與其他用例不同？是否屬于另外一種類別？另外一個等價區間？這是軟件測試員必須考慮到的問題。
等價類別或者等價區間是指測試相同目標或者暴露相同軟件缺陷的一組測試案例。1+999…和1+13有什么區別呢？至于1+13，就像一個普通的加法，與1+5或者1+392沒有什么兩樣，而1+999…則屬于鄰界的極端情況。假 如輸入最大允許數值，然后加1，就會出現問題——也許就是軟件的缺陷。這個極端案例屬于一個單獨的區間，與常規數字的普通區間不同。
等價類劃分的辦法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數代表性數據當作測試用例。每一類的代表性數據在測試中的作用等價于這一類 中的其他值，也就是說，如果某一類中的一個例子發現了錯誤，這一等價類中的其他例子也能出現同樣的錯誤。使用這一方法設計測試用例，首先必須在分析需求規 格說明的基礎上劃分等價類，列出等價類表。
在考慮等價類劃分時，先從程序的功能說明中找出每個輸入條件，然后為每個輸入條件劃分兩個或更多個等價類。等價類可分兩種情況：有效等價類和無效等價 類。有效等價類是指對程序的規格說明是有意義的、合理的輸人數據所構成的集合；無效等價類是指對程序的規格說明是不合理的或無意義的輸人數據所構成的集 合。
◆ 邊界值分析
軟件測試常用的一個方法是把測試工作按同樣的形式劃分。對數據進行軟件測試，就是檢查用戶輸入的信息、返回結果以及中間計算結果是否正確。
即使是最簡單的程序，要處理的數據也可能數量極大。還記得在計算器上簡單加法的全部可能性嗎？再想一想字處理程序、導航系統和證券交易程序。使這些數 據得以測試的技巧（如果稱得上的話）是，根據下列主要原則進行等價分配，以合理的方式減少測試案列：邊界條件、次邊界條件、空值和無效數據。
邊界值分析（Boundary Value Analysis，BVA）是一種補充等價劃分的測試用例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。實踐證明，在設計測試用 例時，對邊界附近的處理必須給予足夠的重視，為檢驗邊界附近的處理專門設計測試用例，常常可以取得良好的測試效果。BVA不僅重視輸人條件邊界，而且也從 輸出域導出測試用例。
第二篇：黑盒測試技術實驗報告
黑盒測試技術 — 三角形問題 實驗報告 一、問題描述 輸入三個整數 a、b、c，分別作為三角形的三條邊，通過程序判斷這三條邊是否能構成三角形？如果能構成三角形，則判斷三角形的類型并輸出（等邊三角形、等腰三角形、一般三角形），如果不構成三角形輸出不能構成三角形。
要求:(1)輸入三個整數 a、b、c，必須滿足以下條件：1≤a≤200；1≤b≤200；1≤c≤200。
(2)容錯處理：輸入空值的提示；輸入的值滿足類型的提示；(3)不限制開發環境，不限制開發語言；(4)盡可能不對自己的程序進行測試設計。
(5)請分別采用邊界值分析法、等價類分析法、決策表分析法、基于場景分析法設計測試用例；(6)正文格式（除源代碼用小五號單倍行距），其他行距固定值 20，字號小四。
二、程序主要源代碼 (標注：測試的源代碼是哪位同學（學號姓名）編寫的。)
三、程序界面（截圖）
四、設計測試用例
1.用邊界值測試方法設計測試用例
用邊界值分析法設計測試用例，按照下列步驟進行：
（（1）
分析各變量取值 三角形三條邊的取值范圍都是 1-200，所以邊長 A 的邊界點為 1 和 200，邊長 B的邊界點為 1 和 200，邊長 C 的邊界點為 1 和 200。
（（2）
測試用例數 輸入條件 邊界值 測試數據 A 1,200 0,1,2,199,200,201 B 1,200 0,1,2,199,200,201 C 1,200 0,1,2,199,200,201
設計測試用例（給出所有測試用例）
三角形問題的測試用例 測試用例 編號 輸入數據 預期輸出 測試結果 a b c 1 0 100 100 邊長 A 不合法
邊長 A 不合法1 100 100 等腰三角形 等腰三角形 3 2 100 100 等腰三角形 等腰三角形 4 199 100 100 等腰三角形 等腰三角形 5 200 100 100 不是三角形 不是三角形 6 201 100 100 邊長 A 不合法
邊長 A 不合法100 0 100 邊長 B 不合法
邊長 B 不合法100 1 100 等腰三角形 等腰三角形 9 100 2 100 等腰三角形 等腰三角形 10 100 199 100 等腰三角形 等腰三角形 11 100 200 100 不是三角形 不是三角形 12 100 201 100 邊長 B 不合法
邊長 B 不合法100 100 0 邊長 C 不合法
邊長 C 不合法100 100 1 等腰三角形 等腰三角形 15 100 100 2 等腰三角形 等腰三角形 16 100 100 199 等腰三角形 等腰三角形 17 100 100 200 不是三角形 不是三角形 18 100 100 201 邊長 C 不合法
邊長 C 不合法
2.用等價類測試方法設計測試用例
（（1）首先分析題目中給出的條件和隱含的輸入要求，輸入條件如下：
條件：1<=邊長 A<=200,1<=邊長 B<=200,1<=邊長 C<=200
隱含條件:A 輸入條件 有效等價類 無效等價類 是否是三角形 1.1<=A<=200 2.1<=B<=200 3.1<=C<=200 4.A (3)設計測試用例，覆蓋上表中的等價類，如表 1-3 表所示。（至少 20 條） 表 表 1-3 三角形問題的測試用例 測試用例 編號 輸入數據 預期輸出 覆蓋等價類 測試結果 a b c 1 100 100 100 等邊三角形 1,2,3,4,5,6,17 等邊三角形 2 50 50 50 等邊三角形 1,2,3,4,5,6,17 等邊三角形 3 150 150 150 等邊三角形 1,2,3,4,5,6,17 等邊三角形 4 50 100 100 等腰三角形 1,2,3,4,5,6,15 等腰三角形 5 100 50 100 等腰三角形 1,2,3,4,5,6,14 等腰三角形 6 100 100 50 等腰三角形 1,2,3,4,5,6,13 等腰三角形 0 2 3 邊長 A 不合法 7 邊長 A 不合法 8 2 1 3 不是三角形 12 不是三角形 9 3 0 1 邊長 B 不合法 8 邊長 B 不合法 10 3 1 2 不是三角形 10 不是三角形 11 1 3 0 邊長 C 不合法 9 邊長 C 不合法 12 2 3 1 不是三角形 11 不是三角形 13 50 51 52 不是等腰三角形 1,2,3,4,5,6,16 一般三角形 14 51 52 50 不是等腰三角形 1,2,3,4,5,6,16 一般三角形 15 52 50 51 不是等腰三角形 1,2,3,4,5,6,16 一般三角形 16 100 100 101 不是等邊三角形 1,2,3,4,5,6,19,20 等腰三角形 17 100 101 100 不是等邊三角形 1,2,3,4,5,6,18,20 等腰三角形 18 101 100 100 不是等邊三角形 1,2,3,4,5,6,18,19 等腰三角形 19 50 50 51 不是等邊三角形 1,2,3,4,5,6,19,20 等腰三角形 20 50 51 50 不是等邊三角形 1,2,3,4,5,6,18,20 等腰三角形 21 51 50 50 不是等邊三角形 1,2,3,4,5,6,18,19 等腰三角形 3.用決策表測試方法設計測試用例 （（1）構建決策表 （（2）化簡 測試用例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 輸入條件 是三角形 Y Y Y Y Y Y Y Y N N N N N N N N A=B Y Y N Y N Y N N N Y Y Y N N Y N A=C Y N Y Y Y N N N N Y Y N Y N N Y B=C Y Y Y N N N Y N N Y N Y Y Y N N 預期輸出 不是三角形 等腰三角形 等邊三角形 一般三角形 出錯提示 測試用例 1 2,3,4 5,6,7 8 9-16 輸入條件 是三角形 A=B A=C B=C 預期輸出 不是三角形 Y 等腰三角形 Y 等邊三角形 Y 一般三角形 Y 出錯提示 Y （（3）化簡后的測試用例設計 測試用例 編號 輸入數據 預期輸出 覆蓋等價類 測試結果 a b c 1 50 50 50 等邊三角形 1,2,3,4,5,6,17 等邊三角形 2 50 50 51 等腰三角形 1,2,3,4,5,6,13 等腰三角形 3 51 50 50 等腰三角形 1,2,3,4,5,6,15 等腰三角形 4 50 51 50 等腰三角形 1,2,3,4,5,6,14 等腰三角形 5 1 2 3 不是三角形 12 不是三角形 6 1 3 2 不是三角形 11 不是三角形 7 3 2 1 不是三角形 10 不是三角形 8 2 3 4 一般三角形 1,2,3,4,5,6 一般三角形 9 3 2 4 一般三角形 1,2,3,4,5,6 一般三角形 10 4 3 2 一般三角形 1,2,3,4,5,6 一般三角形 4.基于場景的測試 （1 1）基本流和備選流圖 （2 2）場景設計 場景 1 1 ：基本流 場景 2 2 ：基本流+ + 備選流 1 1 場景 3 3 ：基本流+ + 備選流 2 2 場景 4 4 ：基本流+ + 備選流 3 3 場景 5 5 ：基本流+ + 備選流 4 4 （3 3）） 測試用例設計 開始輸入 輸入 A,B,C 判斷各邊邊長是否是在 1-200 A+B>C && A+C>B && B+C>A 備選流 1:邊長不符合條件 備選流 2:不是三角形 是三角形 備選流 3:是等腰三角形 備選流 4:是等邊三角形 一般三角形 結束 場景 A A B B C C 預期輸出 測試結果1234 一般三角形 一般三角形2 0 0 0 0 0 0 邊長錯誤 邊長錯誤3247 不是三角形 不是三角形4 等腰三角形 等腰三角形5 等邊三角形 等邊三角形 5.測試結果分析與總結（至少 0 150 字，對測試過程中失敗用例的原因進行分析，對學習了黑盒測試技術的學習總結） 在用等價類測試方法時，在測試無效等價類的結果和預期結果不一致，其原因是在設計程序時沒有考慮無效等價類的這些測試用例的輸出語句，黑盒測試技術是我們常使用的軟件測試的方法，在測試中，我們需要將邊界值測試，等價類測試，決策表測試，基于場景測試聯合使用。任何一款軟件都不可能做到完全測試，所以我們需要做的就是將黑盒測試中的方法盡可能結合使用，爭取讓軟件少一些 bug。 黑盒測試的測試流程簡單介紹 話說我們一直在做黑盒自動化測試，那我們究竟處于測試中的哪個位置呢？ 其實我們更多的是在執行測試提交報告和發現的軟件Error，測試用例是如何設計的，為什么要這樣設計又有多少人想過呢？黑盒測試中的測試用例設計的簡單方法又有多少了解呢？我們常做的測試中哪些地方用到了例如等價類劃分法？ 下面僅僅對黑盒測試的簡單的測試流程進行下說明關于黑盒測試的其他內容會在以后的帖子中說明。 首先來了解兩個名詞： Statement of Work（SOW）軟件使用說明書 Software Requirement Specification(SRS)軟件需求規格說明書 1.需求分析階段：對業務的學習，分析需求點。 2.測試計劃階段：測試組長就要根據SOW開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風險識別等內容。 3.測試設計階段：測試方案一般由對需求很熟的高資深的測試工程師設計，測試方案要求根據《SRS》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成后也需要進行評審。 4.測試方案階段：主要是對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的，通過《測試方案》階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。 5.測試執行階段：執行測試用例，及時提交Error和測試報告等相關文檔。 做電子商務網站測試已經一個月了，這一個月基本上是熟悉網站產品和流程的一個過程，對網站的各個部分基本上都進行了一次測試，感覺電子商務網站主要注意以下幾點： 1、注冊和登錄模塊的測試 在測試該部分時，給我印象最深的就是： 1)注冊成功，但登陸失敗：注冊時，密碼設置為一些特殊的符號，比如：空格、%等，但登錄時，失敗。 后來經開發人反映出現這樣的問題，原因是：在登錄模塊，對密碼設置了一些限定。 2)登錄時，沒區分大小寫，就是說，用小寫字母注冊的，登錄時，用相應的大寫字母登錄也能成功。 出現問題的原因：登錄時，沒用MD5加密進行驗證 2、購物車的測試 1)測試產品能否放入購物車中 2)當某種產品有購物數量限制時，超過這一數值，能否也能放入購物車中 3)購物車中的購物限制是否正確 3、支付流程測試 1)購物車中的產品能否正常支付 2)當支付完成，不等頁面跳轉，直接關閉瀏覽器，數據傳遞是否正確 3)當支付完成，等待頁面跳轉，跳轉到得頁面是否正確 4、網站某個模塊間的數據傳遞是否正確 當網站某個模塊涉及的數據傳遞比較多而且比較復雜時，一定要搞清楚數據是怎么傳遞的，因為這是最容易出現bug的地方。比如：下拉菜單的數據沒有傳遞過來，或傳遞過來了，但不正確，這時就要靜下心來，慢慢濾清思考，耐心去測試。 最后一點就是，在購買的過程中，也要考慮到并發，比如，當某種產品只剩一件了，這時兩個用戶或更多同時并發點擊該產品，放入購物車中，那么在多個用戶同時點擊這個只剩一件的產品時，系統是否有相應的提示，或是，該產品能否都放入不同用戶的購物車中，我上周測試的過程中，該問題是存在的，等待明天程序的解答和修改。 從事測試到現在已有半年多的時間，剛開始做為新人時，面對未接觸過的系統中的每個模塊，心中是有些慌張的。僅憑業務學習和前輩們講的測試方法還是很難做到完全讓自己放心，這可能是新人的通病，害怕測試不全面不深入。至少我在測試之初，是比較膽怯的。隨著時間的推移，我發現自己越來越自信，特別是面對新的模塊新的功能消除了那種恐懼感。總結了以前的一些心得，供大家交流： 一、根據自己的實際情況，做一個學習計劃，邊學邊測，以學來熟悉側，以測來鞏固學，做到二者的融合；一開始會比較苦，畢竟很多都不熟悉，有時單據不能保存，有時流程走不下去，一定要堅持住；業務知識熟悉了，就好多了。 二、剛開始時因為業務不熟悉，需求也不熟悉，就開始測試任務。這時自己就看看測試用例，隨便測測，看功能能不能正常走通。 1、根據功能做一個基本的測試計劃；當然在做這個測試計劃時可以先問下你的主測或是開發經理，有什么建議，畢竟他們經驗比我們豐富。 2、開始測試時，嚴格按照測試用例來執行，當然等業務熟練后，自己可以寫測試用例來執行，畢竟原有測試用例并未覆蓋整個模塊的功能；這樣就可以補缺補漏。 3、在學習或測試中，有不懂的或是不明白的地方，盡量去問主測或是其他同事，但要有個度，畢竟別人都有自己的任務，不要一有問題就問，你可以將今天學習或是測試中存在的問題一條條記錄下來，等中午休息或是下班前一刻向別人求教；也可回家后自己上網上搜索相關的知識解決問題。 三、學會換位思考，將自己當客戶，發揮自己的想象找出客戶存在的應用場景，在客戶操作的基礎上尋找測試突破口，假如實際經驗積累不多，可上網查找或是詢問別人；因為每個客戶的操作不一樣，會存在比較復雜業務邏輯，這時可以分解成一小塊一小塊測試，最后再從整體的角度入手；由簡單到復雜，簡單的測試通過后再做復雜的測試，而不是一開始就做復雜的測試。 四、隨時記錄學習到的新知識，特別是其他相關模塊的知識；同時記錄工作心得，特別是好的測試方法和測試思考方法；好記憶不如爛筆頭，何況在這科技發達的時代，鍵盤隨便敲敲，即清晰又明了，下次碰到相同問題可查看。 最后說一句，路是自己走出來的，測試也是自己測出來的。第三篇：黑盒測試的測試流程簡單介紹
第四篇：web測試心得
第五篇：軟件測試心得
點擊咨詢 