軟件測試理論個人總結與整理
前言
循例先說一聲大家好，本人第一次在博客園發表隨筆，僅當作個人的能力提升日記來記錄。事情是這樣的，我有幾個大學同學都在從事“軟件測試”這份工作，恰巧本人目前打算轉行，便與其中一名比較要好的同學進行了溝通，本來我就是意向於轉型互聯網行業的，當然，互聯網行業范圍很廣，我是軟件工程專業畢業的，更想從事其中的編程工作，特別是游戲開發，無奈畢業后的一年間，我從事了一份專業不對口的工作，雖然在那份工作上有所提升，但終究不是我想要的行業，而在期間我居然沒有夯實過自己的編程水平，導致現在已經忘記了學校的非常多的知識，真的深刻表示非常后悔，在與同學交談以后，我從中簡單地了解到了一些關於軟件測試的內容，此時，我再三糾結着，必須規划自己的未來，決定往軟件測試行業發展，同學也向我伸出援手，將他之前校外培訓的一些視頻與PPT等資料文檔完整地發送給我。
憑之，我開始了新一輪的自我培訓（此前，離職上一份工作后，我重新學習完大學時期學過的c語言程序設計），在軟件測試方面，平時看視頻學到有不懂的地方我也會問下他，他也樂意給我解答，在磕磕碰碰間，我也基本學習完了軟件測試的理論基礎（主要是黑盒測試），所以有了現在的個人知識整理，我想這會是我進入互聯網行業的第一步，因為首先我的目標是想成為一名游戲測試工程師，進入游戲行業，不僅是我自身喜歡的行業，而且能通過游戲公司慢慢摸索到游戲行業的具體結構和產品發展流程，當然，編程能力在我能力范圍之內也一定會惡補加強。
正文
雖然與視頻中發出聲音的老師素未謀面，但看了他的這么多教學錄像，可以判斷到是一位經驗非常豐富的軟件測試工程師，一開始講，可能他的課上有很多非計算機專業的學生，所以講了一些很基礎的東西，下面，我也是按照同學給我的視頻教學順序來總結和回憶，當然，里面有本人個人理解和本人從其他渠道獲得補充的知識。
①首先，讓我記憶業內的一些專業名詞的英文單詞，畢竟計算機行業的專業名詞很多都會用英文顯示，比較常見的單詞應該不用再去找翻譯軟件翻譯了。
【軟件——Software】【硬件——hardware】【程序——program 】【文檔——document 】 【缺陷——Defect （BUG）】 【Configuration-配置】【Adapter-適配器】
【Urgent--Veryhigh--high--medium--Low——對應BUG的嚴重程度與優先級（緊急——非常高——高——中等——低）】
【new-open-fixed-close—對應一個BUG的周期分別是（“測試員”新發現BUG—“測試或開發經理確認是BUG”打開狀態—“開發已修復”已修復狀態—“測試員返測后”關閉狀態）】
【基本輸入輸出系統——BIOS（Basic input/output system）】 【操作系統——OS（Operrating System）】 【Address-地址】【Default-默認】
當然不止以上這些，但在視頻中講到的大概就是以上這些名詞。
前面的幾個視頻，老師很耐心地講解了一些計算機知識，包括OS的主要功能、軟硬件的分類、單機與網絡軟件的分類、C/S與B/S結構的分布式軟件大概的運作流程、數制（十進制、二進制、八進制、十六進制）的相互轉換與相關知識等等，這些知識與計算機有關，但不屬於軟件測試的根本理論，故在此就不詳細作出總結了。
②第二，老師從淺入深，先從最簡單的缺陷報告（BUG報告、管理）講起，這里他沒有講出一些游戲測試公司常用的BUG管理工具，但是我從同學那里了解到，現在游戲公司一般使用“禪道”“Tapd”等工具管理與跟蹤BUG，我得知后也是馬上去網上自行搜索這些工具，嘗試了簡單的使用，發現的確很方便，我個人認為這些面向普通客戶的軟件一般使用難度不大。
回到視頻方面，總結老師說的內容，就是缺陷報告的組成要素，即相當於一份總結文檔，缺陷報告需要有以下11點要素：
（1）缺陷編號：（個人理解：是一個自己發現BUG的順序編號，比如發現了三個不同的BUG，提交的時候分別是1號BUG，2號BUG，3號BUG）
（2）缺陷標題：（個人理解：簡單扼要地形容並表達出自己發現的BUG）
（3）缺陷發現者：（個人理解：這個認為比較簡單了，就是自己發現的BUG寫上自己的名字，比如我的名字Tzh（英文縮寫））
（4）發現缺陷的日期：（個人理解：就是寫上發現BUG當天的日期，有需要可以加上當時是幾時幾分）
（5）缺陷所屬的模塊：（個人理解：就是自己發現的BUG屬於該軟件或游戲的哪一個功能模塊，比如我發現了用戶充值點券后，用戶的錢扣了，商品卻沒有發放，這時應該屬於充值點券模塊的BUG）
（6）發現缺陷的版本：（個人理解：就是測出一個BUG后，記錄下當時所在的軟件版本，比如我此時此刻測出一個BUG，是在1.26版本測試出來的，應該記錄好）
（7）指派給誰處理：（個人理解：我覺得這里應該看各公司的內部運作是如何的，有可能直接給開發人員，也有可能給測試或者開發經理，再由他們分配給相應的開發人員，當然，如果用BUG管理工具，相應模塊的開發人員應該可以接到自己開發的模塊出現BUG的信息通知）
（8）缺陷的狀態：（個人理解：這個上面的英語單詞有講到，就是new-open-fixed-close，這個狀態理應是隨時更新的，測試人員發現BUG后，標注New，測試或者開發經理確認是BUG后，標注Open，開發人員收到該BUG並修復好后，標注Fixed，測試人員返測沒問題后，標注Close，當然可能不同公司使用的名詞不一樣，但應大同小異）
（9）缺陷的嚴重程度：（個人理解：這個上面的英語單詞同樣有講到，就是Urgent--Veryhigh--high--medium--Low，當然可能不同公司使用的名詞不一樣，但應大同小異，此處視頻老師有講到，每個公司都應有自己的BUG等級定義手冊，並以此為標准）
（10）缺陷的優先級：（個人理解：分級同上，Urgent--Veryhigh--high--medium--Low，不同公司使用的名詞和等級可能不一樣，這里視頻老師也注重給我講了一個知識點，就是“嚴重程度”與“優先級”的判定方法，比如有可能medium級別嚴重程度的BUG，但該BUG是比較表層的錯誤，開發人員應能很快處理好，故優先級是Urgent）
（11）缺陷描述：（個人理解：就是發現BUG的那條測試用例的步驟，記錄下來，方便開發人員重現BUG）
以上。
補充一點，老師也有講到的，缺陷報告的用途（作用、意義）：1.記錄BUG 2.對BUG進行分類 3.跟蹤BUG 4.方便項目組對BUG進行分析統計
③第三，也是本次教學的重中之重，測試用例（如何使用黑盒測試方法與思路進行編寫用例）。
首先講的是，一個完整的測試用例應該由什么組成。根據視頻老師的教學與本人其他方式的補充學習，個人覺得應該由以下模塊組成。
（1）用例編號（2）測試模塊（3）測試目的（4）用例描述（5）預期結果（6）實際結果（7）是否通過（8）證跡（視頻老師講到，有些公司會讓你證明你有測試過，比如截圖）
其實一份測試用例就是一份Excel表格，大概需要由以上模塊組成，每個模塊需要如何填寫，就是字面意思，這里就不累贅了。
補充：編寫用例的依據就是公司產品的需求文檔、軟件本身、以及自身的黑盒測試技術與思路。
下面就講到軟件測試中（黑盒、白盒、灰盒）的黑盒測試！
先數數有幾種測試理論方法：等價類划分！邊界值划分！因果圖！判定表！場景法！測試大綱法！目前應用較多的是這六種。
（1）等價類划分【重要程度：五顆星（五顆星滿）】
首先該方法的應用場合：狹義上說，需要輸入數據的文本框，都可以用到等價類划分，廣義上說，其他一些黑盒測試方法都用到了等價類划分的思想。
使用該方法的目的：是為了從無限多的數據中選取少數具有代表性的數據進行測試。
舉例：有一個文本框，需要要求合法輸入是0-100的整數，你手工測試總不可能就這個文本框測100次吧，可以選取其中一到兩個，比如54,72出來測試，當然，其中一個原因也是因為從開發角度想，0-100的文本框定義一般不會出現其中個別數出錯，其他數正確的情況的，后面補充測邊界值就能確保這個文本框的有效等價類是否有BUG了。
使用方法：1.分析需求，划出有效等價類與無效等價類，（按照我的理解，實際工作中這步應該一般與邊界值一起划分好），然后從有效等價類和無效等價類中都選取一定數量的數字出來進行測試。
（2）邊界值划分【重要程度：四顆星】
首先該方法的應用場合：也是需要輸入數據的地方。
使用該方法的目的：可以測出開發中最容易出錯的邊界地方，按照我的編程水平舉例，比如：文本框==a，定義了if（a>=0&&a<100）,則報錯誤提示，那這里如果輸入100也會報錯了，因為代碼中沒有寫a<=100,而是寫成了a<100，這與需求就不符合了，邊界值100就出錯了。
使用方法：划分出有效等價類以及無效等價類的邊界值，一般拿邊界值還有其左右的兩個次邊界值出來進行測試，比如：0-100的有效等價類，我測試0/1/2/99/100/101（很多文本框測試-1沒有意義，所以我選取了0/1/2，有時間可以多測幾個），六個邊界值。
（3）因果圖【重要程度：三顆星】
應用場合：一個界面中有多個控件，不同的控件輸入組合就會產生不同的輸出結果的組合（控件數量不能太多，如果太多控件組合需要用正交排列法）
使用目的：為了弄清楚這些控件，用怎樣的輸入組合，會產生對應怎樣的輸出結果，因此稱因果圖。
使用方法：其實就是畫圖，根據視頻老師教我的9個圖形關系，來實際畫出界面控件與控件間邏輯關系。
以下，讓本人來展現一下靈魂畫手的本領。
控件中的基本關系（輸入與輸出的基本關系）有：
第一種——
（圖片上的Tzh僅作為原創標注）
關系含義：若a出現，則相當於b出現；若a不出現，則相當於b不出現。（我們以1作為出現，0作為不出現，則有：若a=1，則b=1；若a=0，則b=0）
補充，a相當於輸入，b相當於輸出，比如：按下充值50元按鈕，與提示請投入50元人民幣，就是a與b的恆等關系，做了這個操作，就會有這個結果。
第二種——
關系含義：若a出現，則b不出現；反之亦然（若a=1，則b=0） 比如，按下了使用微信支付，就不會出現支付寶支付的提示，反之亦然
第三種——
關系含義：幾個輸入中，只要有一個出現，結果就會出現，若全部都不出現，結果則不出現（a=1或b=1或c=1，則d=1,；若a=b=c=0，則b=0）
第四種
關系含義：若幾個輸入全部出現，結果才會出現；若幾個輸入中有一個不出現，則結果不出現。（若a=b=c=1，則b=1,；若a=0或b=0或c=0，則b=0）
★下面五種是限制關系（只能單獨限制輸入，或者單獨限制輸出）：
第五種——
關系含義：表示a、b、c三個不可能同時成立，他們互相排斥，最多只能有一個成立。
比如，一個軟件讓你選擇身份：1.學生 2.教室 3.游客 ，你只能選擇一種，不能同時選兩種。選擇了其中一種，其他種類就會置灰無法選擇。
第六種——
關系含義：表示a、b、c中至少有一個成立（可以三個都成立），不能全部都不成立。
第七種——
（視頻老師講到，這是非常重點一種關系）
關系含義：a、b、c中有且僅有一個成立（唯一與互斥很相似，但是唯一關系一般有默認值，互斥一般沒有）
第八種——
關系含義：a要求b，即a出現時，b必須出現。
第九種——
關系含義：a屏蔽b，即a出現時，b必定不出現。
以上就是因果圖法9種圖形。
★此外，視頻老師教導了我一套因果七步法，即使用七個步驟，運用因果圖與判定表生成測試用例的方法。以下我來總結介紹：
第一步：將界面所有的輸入（也稱原因、可能性）找出來，並列出來。
比如有三個按鈕a、b、c，那么輸入情況有可能是單獨a、單獨b、單獨c、a+b、a+c、b+c、a+b+c幾種，這就是所有輸入情況（用戶所有有可能的操作），然后根據需求划分他們之間的關系（哪些能組合，哪些不能）。
第二步：將所有的輸出（結果）找出來，並列出來。
即所有有可能發生的輸出都列出來。
第三步：在第一步的基礎上，找到所有輸入之間的限制關系與組合關系（決定測試用例的數量）。
第四步：在第二步的基礎上，找到所有輸出之間的限制關系與組合關系。
第五步：找到輸入與輸出之間的關系與組合關系（怎么樣的輸入產生怎么樣的輸出）。
第六步：根據畫出的因果圖，寫出一個判定表。
第七步：判定表中的每一種情況都生成一條測試用例。
（4）判定表【重要程度：四顆星】
個人理解：判定表其實就是因果圖的后續，兩者密不可分，就是用因果圖方法分析后，將控件的輸入輸出組合總結成表格，列出所有有可能發生的情況，然后根據此表生成測試用例。
（5）正交排列法【重要程序：三顆星】
應用場合：在一個界面中，有多個控件，每個控件中又有多個取值，此時控件組合數量龐大，不可能窮舉測試。
使用目的：正交排列法正是為此而用的，在龐大的組合數量中選取少數最優的數據進行測試，提高測試效率。
首先，此方法是借鑒正交表的一種方法，而正交表是數學家固定的，我們只能借鑒。
正交表：
是以該種形式表示的一種數學表格，以下來解釋一下這些數字的意義，比如L9（三的四次方），代表有四個控件，每個控件有三個取值，需要測試9次。
1.n是表的行數，也就是需要測試組合的次數。
2.k是表的列數，也就是控件的個數（因子數）
3.m是每個控件的取值個數（狀態數）
使用方法：分析需求，將需要測試的控件與取值個數列出來，然后根據控件與取值的個數，選擇一個合適的正交表。
正交表有9種，需要用到時上網查找即可，或者自己用文檔記錄好，用的時候拿出來。下面貼出L9（三的四次方）的正交表出來。
表中的1/2/3值就是控件的3個取值，表頭的1/2/3/4列就表示4個控件，只需要將控件及其取值放到正交表中即可得出測試用例。
此外，需要注意的是很多時候軟件中的控件和取值並沒有這么規范（4個控件都是3個取值），當不符合正交表時，選取最接近的正交表，采取1.少數服從多數原則 或者 2.取最大值為底原則，做出自己加工過的正交表（以公平、均勻的思想）。
（6）場景法【重要程度：五顆星】
該方法是游戲測試的主要應用方法。
應用場合：1.界面沒有太多填寫項，主要通過鼠標的點擊、雙擊或者拖拽等完成操作（移動端通過觸摸）。
2.將自己當做最終的用戶，思考在使用該軟件時可能會遇到哪些場景。
使用目的：測試軟件的主要業務流程、主要功能的正確性與錯誤處理能力。
核心概念：1.基本流（正確流程）：模擬用戶正確的操作流程，直達目的（驗證軟件的業務流程和主要功能實現）
2.備選流（錯誤流程）：模擬用戶的錯誤操作流程（驗證軟件的錯誤處理能力）
總結：1.場景法是基於等價類划分的一種測試方法（基本流-有效，備選流-無效），在技術層面。
2.場景法的應用是基於對軟件業務（需求）的深入理解，在業務層面。
使用方法：（1）根據說明，描述出程序的基本流與各項備選流。
（2）根據基本流和各項備選流生成不同的場景。
（3）對每一個場景生成相應的測試用例。
PS：一條基本流中，每一個步驟都有可能有一條備選流，需仔細模擬。
（7）測試大綱法【重要程度：四顆星】
應用場合：在一個程序中涉及多個窗口，並且每個窗口有多個操作，窗口與窗口之間有一定聯系，為了直觀地弄清楚它們之間的聯系，使用測試大綱法。
使用方法：（1）列出所有窗口，以及窗口中包含的操作（按鈕、選項）
（2）找出窗口之間的聯系，例如先后順序，點擊哪個按鈕跳轉到哪個窗口，然后根據之編寫測試用例。
以上就是黑盒測試的七種最常用方法，先后順序我也是根據視頻老師教導我的順序寫下來的，參考資料是我自己看視頻學習時寫的筆記。
④除此以外，視頻老師還教導了一些測試的流程說明，以下我繼續根據我的筆記列出來。
（1）單元測試：1.依據軟件的詳細設計文檔（需求）來測試
2.以功能測試為主，極少部分重點核心模塊進行白盒測試
（2）集成測試：1.拿到開發給過來的新版本后，先做“冒煙測試”，即用較少時間與人員，測試新版本中主要功能是否基本實現，判斷是否有值得測試的價值。
2.冒煙合格后，進行測試人員返測，即將之前發現的BUG都重新測試一次。
3.進行“回歸測試”，即對前面版本執行過的測試用例再重新執行一次，測試一次。
4.最后才是針對新版的添加的功能，進行編寫測試用例，執行測試。
（3）系統測試：1.對整個軟件進行全面的測試
2.在系統測試前，一般有“確認測試”，即再次冒煙測試，與檢查各類文檔是否齊全。
（4）驗收測試：是用戶接受度測試，用戶體驗測試，1.alpha測試：最終用戶在開發環境中，對軟件進行測試。
2.beta測試：由最終用戶在實際環境中使用（公測）
以下附上開發與測試的W關系模型：
結言
本人學習軟件測試的時間不算長，以上文章內容是100%手打的總結與個人理解，沒有一個字是我復制過來的，如果有不正確的地方，請各位多多指點。（參考資料：同學給我的視頻教學，自己的筆記，上網查的資料）
寫這篇博客是很隨性的，旨在記錄自己的學習是否有掌握到核心內容，是否有理論基礎支持本人從事 軟件測試/游戲測試 這個職位，當然，我到現在都未有相關實踐經驗，仍然在簡歷的投放搏斗中，我自己都很期待自己接下來的故事。
雖然不知道有多少人能一字不漏地看完我的隨筆，但是很感謝看到這篇文章的人，謝謝。