軟體測試基礎知識整理
一、軟體測試工程師須知
良好的溝通和表達能力具有懷疑與破壞的精神紮實的軟體測試基礎知識縝密的業務邏輯分析能力處在使用者的角度進行換位思考足夠的耐心、細心、信心、責任心積極樂觀向上的心態和團隊協作能力要有嚴謹、敢於承擔責任、穩重的做事風格善於自我總結、自我督促和不斷學習的能力二、軟體測試職業規劃 & 轉職
產品總監(ProductOwner)
專案經理(ProjectManager) / 技術經理(Technical Manager)QA (Quality Assurance)或者法律法規部門測試開發(TestingDeveloper)（領域）業務專家(BusinessExpert )手工測試(Manual testing)
測試的內容：B/S架構的Web測試，如各種網站(Website)APP的測試，iOS，安卓，在手機上或在iPad上C/S架構的軟體測試，多為桌面應用程式(Application)手機測試(MobilePhone)嵌入式軟體測試（測試硬體裝置裡的軟體功能遊戲測試搜尋引擎測試本地化測試AI測試？區塊鏈測試
不同的需求型別（Requirement）
使用者需求（UserRequirement）開發需求規格說明書（DEV Requirement Specification
客戶、產品線經理（ProductLine Manager，PLM）、專案開發經理或負責人需求的顯性和隱性
顯性：明確規定的功能與特性隱性：沒有被明確規定但是有可能或應該擁有的功能與特性，例如：娛樂圈的潛規則，汽車必須要有輪胎且必須是四個輪胎，飛機必須要會飛等一切約定俗成的東西軟體測試型別以階段劃分
單元測試（Unit Test）：單元就是人為規定的最小的被測功能模組。一般是開發做的，測試一般也就做程式碼插樁。
整合測試（Integration Test）：開發好的模組之間的整合第三方介面整合裝置整合（醫療行業見多）系統測試（System Test
驗收測試（Verification Test）：冒煙測試（Smoke Test）、迴歸測試（Regression Test）、自由測試或叫作隨機測試（Free Test）Alpha測試與Beta測試：Alpha測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，但不能由程式設計師或測試員完成。 Beta測試是在一個或多個或大量使用者的實際使用環境下進行的測試，但不能由任何公司內部人員完成。
A/B測試：主要是為Web網站或App軟體製作兩個（A/B）或多個（A/B/n）版本，在同一時間維度開放給終端使用的使用者。這些版本用來收集各種使用者體驗資料和業務資料，最後分析評估出最好版本來正式採用。
測試基類
自動化測試（泛指功能）
效能測試
安全性測試
泛指Web網站方面、醫療行業、汽車行業等、區塊鏈？去中心化後能否安全Web安全性測試定義：建立整體的威脅模型，測試溢位漏洞、資訊洩漏、錯誤處理、SQL 注入、身份驗證和授權錯誤。
靜態測試指測試不執行的部分——只是檢查和稽核。開發人員方面如：程式碼走查，程式碼Review，程式碼比較等；測試人員方面如：介面美觀度“鑑賞”，測試文件檢查，測試程式翻譯問題的本地化測試（也算是一種靜態測試型別吧）等動態測試
指通常意義上的軟體測試，使用和執行軟體、網站、APP等，就是我們常講的“點點點”。軟體測試用例
測試用例設計方法
一、等價類劃分法
1、避免冗餘
2、測試其中一個最具有代表性的值就能代表這一類的其他任何值，即：將無窮盡的測試資料進行合理分類
3、等價類劃分只適用於黑盒測試
4、等價類的基類永遠只有兩種：有效等價類和無效等價類。PS：有效等價類就是指對於程式的需求規格說明來說是合理的，有意義的輸入資料構成的集合。利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能。
舉例: 對電話專員的評分，範圍是0~10之間，低於6分可能被炒魷魚
有效等價類：0<=Point<=10、無效等價類：Point<0或者Point>10
二、邊界值分析法
邊界值分析法就是對輸入項的邊界值進行測試的一種黑盒測試方法，是作為對等價類劃分法的補充，基本就是繫結使用的。因果圖法
1或0（預設表達方式，Default）1代表真0代表假
Y或NY=Yes代表真 N=No代表假
T或FT=True代表真 F=False代表假
4種原因與結果的關係
4種原因與原因的約束
E約束（排他性約束、Exclusive）：C1和C2中最多有一個可能為1，即C1和C2不能同時為1
I約束（包含性約束, Inclusive）：： C1、C2、C3中至少有一個必須是1，即： C1、C2、C3不能同時為0
O約束（唯一性約束, Only）：C1和C2必須有一個且僅有一個為1
R約束（必要性約束, Request）：： C1是1時，C2必須是1
M約束（強制約束，Masking）：：唯一的針對結果的約束；若結果E1是1，則結果E2強制為0
判定表法Decision Table Method：
判定表是分析和表達多種輸入條件下系統執行不同動作的工具，它可以把複雜的邏輯關係和多種條件組合的情況表達得既準確又明確。
一般情況下，我們在畫出因果圖後寫出判定表，兩者繫結使用。但是無論是因果圖法也好，判定表法也好，它們兩者都是可以單獨使用的。
根據個人喜好，熟練了以後，可以考慮直接使用判定表法，省去畫圖步驟（Normally）。
因果圖+判定表的經驗結論
判定表法的優點：
1、充分考慮了輸入條件間的組合，對組合情況覆蓋充分；
2、最終每個用例覆蓋多種輸入情況，有利於提高測試效率；
3、設計過程中，對輸入條件間的約束關係做了考慮，避免了無效用例，用例的有效性高；
4、能同時得出每個測試項的預期輸出。
判定表法的缺點：
1、當被測試特性輸入較多時，會造成判定表規格過於龐大；
2、輸入之間的約束條件不能有效區分輸入是否確實需要進行組合測試，會造成不需要組合測試的輸入做了組合，從而產生用例冗餘。
場景法
軟體幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流
現在的場景法就是測試用例設計腦圖，人稱XMind錯誤推測法
任何有意義的錯誤推測都值得單獨寫一條測試用例，一般情況下，推測開發需求中沒有明確指明的，錯誤推測法很隨意，就是個頭腦風暴