一、軟件測試工程師須知

良好的溝通和表達能力 具有懷疑與破壞的精神 扎實的軟件測試基礎知識 縝密的業(yè)務邏輯分析能力 處在用戶的角度進行換位思考 足夠的耐心、細心、信心、責任心 積極樂觀向上的心態(tài)和團隊協作能力 要有嚴謹、敢于承擔責任、穩(wěn)重的做事風格 善于自我總結、自我督促和不斷學習的能力

二、軟件測試職業(yè)規(guī)劃 & 轉職

產品總監(jiān)(ProductOwner)

項目經理(ProjectManager) / 技術經理(Technical Manager)QA (Quality Assurance)或者法律法規(guī)部門測試開發(fā)(TestingDeveloper)（領域）業(yè)務專家(BusinessExpert )

手工測試(Manual testing)唯一和最后的出路，但此路其實很光明

銷售（Sales）售后技術支持(TechnicalSupport Engineer)運營(Operation)培訓師/教練(Coach)
測試的內容：B/S架構的Web測試，如各種網站(Website)APP的測試，iOS，安卓，在手機上或在iPad上C/S架構的軟件測試，多為桌面應用程序(Application)手機測試(MobilePhone)嵌入式軟件測試（測試硬件設備里的軟件功能 游戲測試搜索引擎測試本地化測試AI測試？區(qū)塊鏈測試
不同的需求類型（Requirement）
用戶需求（UserRequirement）開發(fā)需求規(guī)格說明書（DEV Requirement Specification）測試需求（TestingRequirement）測試需求收集
客戶、產品線經理（ProductLine Manager，PLM）、項目開發(fā)經理或負責人需求的顯性和隱性
顯性：明確規(guī)定的功能與特性隱性：沒有被明確規(guī)定但是有可能或應該擁有的功能與特性，例如：娛樂圈的潛規(guī)則，汽車必須要有輪胎且必須是四個輪胎，飛機必須要會飛等一切約定俗成的東西軟件測試類型以階段劃分
單元測試（Unit Test）：單元就是人為規(guī)定的最小的被測功能模塊。一般是開發(fā)做的，測試一般也就做代碼插樁。
集成測試（Integration Test）：開發(fā)好的模塊之間的集成第三方接口集成設備集成（醫(yī)療行業(yè)見多）
系統測試（System Test）：所有模塊開發(fā)完畢后，打包給測試做的測試，我們大多數時間做的其實都是系統測試，玩法極多
驗收測試（Verification Test）：冒煙測試（Smoke Test）、?回歸測試（Regression Test）、自由測試或叫作隨機測試（Free Test）
Alpha測試與Beta測試：Alpha測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際操作環(huán)境下進行的受控測試，但不能由程序員或測試員完成。? Beta測試是在一個或多個或大量用戶的實際使用環(huán)境下進行的測試，但不能由任何公司內部人員完成。
A/B測試：主要是為Web網站或App軟件制作兩個（A/B）或多個（A/B/n）版本，在同一時間維度開放給終端使用的用戶。這些版本用來收集各種用戶體驗數據和業(yè)務數據，最后分析評估出最好版本來正式采用。
測試基類

自動化測試（泛指功能）

性能測試

安全性測試

泛指Web網站方面、醫(yī)療行業(yè)、汽車行業(yè)等、區(qū)塊鏈？去中心化后能否安全

Web安全性測試定義：建立整體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、SQL 注入、身份驗證和授權錯誤。

靜態(tài)測試
指測試不運行的部分——只是檢查和審核。開發(fā)人員方面如：代碼走查，代碼Review，代碼比較等；測試人員方面如：界面美觀度“鑒賞”，測試文檔檢查，測試程序翻譯問題的本地化測試（也算是一種靜態(tài)測試類型吧）等動態(tài)測試
指通常意義上的軟件測試，使用和運行軟件、網站、APP等，就是我們常講的“點點點”。軟件測試用例

測試用例設計方法

一、等價類劃分法

1、避免冗余

2、測試其中一個最具有代表性的值就能代表這一類的其他任何值，即：將無窮盡的測試數據進行合理分類

3、等價類劃分只適用于黑盒測試

4、等價類的基類永遠只有兩種：有效等價類和無效等價類。PS：有效等價類就是指對于程序的需求規(guī)格說明來說是合理的，有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規(guī)格說明中所規(guī)定的功能和性能。

舉例: 對電話專員的評分，范圍是0~10之間，低于6分可能被炒魷魚

有效等價類：0<=Point<=10、?無效等價類：Point<0或者Point>10

二、邊界值分析法

邊界值分析法就是對輸入項的邊界值進行測試的一種黑盒測試方法，是作為對等價類劃分法的補充，基本就是綁定使用的。

因果圖法

1或0（默認表達方式，Default）

? 1代表真???0代表假

Y或N

? Y=Yes代表真? N=No代表假

T或F

? T=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：

判定表是分析和表達多種輸入條件下系統執(zhí)行不同動作的工具，它可以把復雜的邏輯關系和多種條件組合的情況表達得既準確又明確。

? ?一般情況下，我們在畫出因果圖后寫出判定表，兩者綁定使用。但是無論是因果圖法也好，判定表法也好，它們兩者都是可以單獨使用的。

? ?根據個人喜好，熟練了以后，可以考慮直接使用判定表法，省去畫圖步驟（Normally）。

因果圖+判定表的經驗結論

判定表法的優(yōu)點：

1、充分考慮了輸入條件間的組合，對組合情況覆蓋充分；

2、最終每個用例覆蓋多種輸入情況，有利于提高測試效率；

3、設計過程中，對輸入條件間的約束關系做了考慮，避免了無效用例，用例的有效性高；

4、能同時得出每個測試項的預期輸出。

判定表法的缺點：

1、當被測試特性輸入較多時，會造成判定表規(guī)格過于龐大；

2、輸入之間的約束條件不能有效區(qū)分輸入是否確實需要進行組合測試，會造成不需要組合測試的輸入做了組合，從而產生用例冗余。

場景法

軟件幾乎都是用事件觸發(fā)來控制流程的，事件觸發(fā)時的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結果就形成事件流

現在的場景法就是測試用例設計腦圖，人稱XMind

錯誤推測法

任何有意義的錯誤推測都值得單獨寫一條測試用例，一般情況下，推測開發(fā)需求中沒有明確指明的，錯誤推測法很隨意，就是個頭腦風暴

總結

以上是生活随笔為你收集整理的软件测试基础知识整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。