1.軟件測試工程師的素質(zhì)：

良好的溝通和表達能力

具有懷疑與破壞的精神

扎實的軟件測試基礎知識

縝密的業(yè)務邏輯分析能力

處在用戶的角度進行換位思考

足夠的耐心、細心、信心、責任心

積極樂觀向上的心態(tài)和團隊協(xié)作能力

要有嚴謹、敢于承擔責任、穩(wěn)重的做事風格

善于自我總結(jié)、自我督促和不斷學習的能

?

2.軟件的分類：

軟件?=?程序?+?數(shù)據(jù)?+?文檔。

　　按照功能劃分：

　　　　系統(tǒng)軟件：如操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)，各種驅(qū)動軟件等

　　　　應用軟件：如Office、金山詞霸、QQ等

　　按照技術結(jié)構劃分：

　　　　單機版本：如Office，畫圖工具等

　　　　C/S結(jié)構軟件：如QQ、MSN等

　　　　B/S結(jié)構軟件：如新浪、搜狐、google等

　　按照用戶劃分：

　　　　產(chǎn)品軟件：Office、財務處理軟件、金山毒霸等

　　　　項目軟件：如為企業(yè)定制的OA系統(tǒng)等

　　按照開發(fā)規(guī)模劃分：

　　　　類別??參與人數(shù)? ? ?開發(fā)時間

　　　　小型??10人以下 ?1-4個月

　　　　中型??10-100人 ?1年以下

　　　　大型??100人以上 ?1年

3.軟件測試的對象：

① 源程序/目標代碼

② 各開發(fā)階段的文檔（需求規(guī)格說明、概要設計說明、詳細設計說明及其它相關文檔）

4.軟件測試的目的：
軟件測試的目的是盡可能多的發(fā)現(xiàn)軟件缺陷。檢查系統(tǒng)是否滿足需求，站在用戶角度思考產(chǎn)品或項目功能實現(xiàn)的正確性。

測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征。可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，通過分析也能幫助我們設計出有針對性的檢測方法，改善測試的有效性。

5.軟件測試的原則

0）所有測試的都應以軟件設計需求規(guī)格說明書為標準進行。

1）應當把“盡早地不斷地進行軟件測試“作為軟件開發(fā)者的座右銘。

2）程序員應避免檢查自己的程序。

3）充分注意測試中的群集現(xiàn)象。

4）嚴格執(zhí)行測試計劃，排除測試的隨意性。

8）妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便。

5）完全測試是不可能的

6.軟件測試分類

?

單元測試：

單元測試又稱模塊測試，針對軟件設計中的最小單位——程序模塊，進行正確性檢查的測試工作。單元測試需要從程序的內(nèi)部結(jié)構出發(fā)設計測試用例。多個模塊可以平行地獨立進行單元測試。

單元定義:

C中指一個函數(shù)，Java中指一個類，在圖形化的軟件中，單元一般指1個窗口，1個菜單。

如何進行單元測試：

單元測試主要用白盒測試，先靜態(tài)地檢查代碼是否符合規(guī)范，然后動態(tài)運行代碼，檢查其實際運行結(jié)果，檢查程序的運行結(jié)果是否正確是一個最基本的要求，還要關注容錯處理，程序的邊界值處理等。

集成測試：

集成測試又叫組裝測試，通常在單元測試的基礎上，將所有程序模塊進行

有序的、遞增的測試。重點測試不同模塊的接口部分。

系統(tǒng)測試：

指將整個軟件系統(tǒng)看為一個整體進行測試，包括對功能、性能、以及軟件所運行的軟硬件環(huán)境進行測試。

驗收測試：

驗收測試指按照項目任務書或合同、供需雙方約定的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，決定是否接收或拒收系統(tǒng)。在系統(tǒng)測試的后期，以用戶測試為主或有測試人員等質(zhì)量保證人員共同參與的測試。

α測試：指的是指的是由用戶，測試人員、開發(fā)人員等共同參與的內(nèi)部測試。

β測試：指的是內(nèi)測后的公測，即完全交給最終用戶測試

驗收測試的重要性：驗收簽字,收錢。

靜態(tài)測試：

指不實際運行被測軟件，而只是靜態(tài)地檢查程序代碼、界面和文檔中可能存在的錯誤的過程。

動態(tài)測試：

指實際運行被測程序，輸入相應的測試數(shù)據(jù)，檢查實際輸出結(jié)果與預期結(jié)果是否相符。（動態(tài)測試方法為結(jié)構和正確性測試；動態(tài)測試工具Robot、QTP等）

黑盒測試：

指的是把被測的軟件看做一個黑盒子，我們不關心盒子里面的結(jié)構是什么樣子的，只關心軟件的輸入數(shù)據(jù)和輸出

白盒測試：

指的是把盒子打來，去研究里面的源代碼和程序結(jié)構。

軟件公司中，往往采用黑盒測試&白盒測試相結(jié)合的方式。

（靜態(tài)黑盒測試：看文檔，看頁面等

靜態(tài)白盒測試：看源代碼等

動態(tài)黑盒測試：使用軟件等

動態(tài)白盒測試：運行源代碼等）

灰盒測試：

是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程序內(nèi)部的情況。

功能測試：

是黑盒測試的一方面，它檢查實際軟件的功能是否符合用戶的需求。

邏輯功能測試(functiontesting)

界面測試(UItesting)

易用性測試(usability testing)

安裝測試(installationtesting)

兼容性測試(compatibilitytesting)

性能測試：

是軟件測試的高端領域，通常我們所說的高級軟件測試工程師一般就是指性能測試或是白盒測試工程師。

時間性能（事務響應時間等）

空間性能（系統(tǒng)資源消耗）

一般性能測試

可靠性測試

負載測試

壓力測試

回歸測試：

指對軟件的新版本測試時，重復執(zhí)行上一個版本測試時的用例。

冒煙測試：

是指在對一個新版本進行系統(tǒng)大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現(xiàn)，是否具備可測試性。

隨機測試：

是指測試中所有的輸入數(shù)據(jù)都是隨機生成的，其目的是模擬用戶的真實操作，并發(fā)現(xiàn)一些邊緣性的錯誤。

7.軟件測試的常用種類：

黑盒測試：把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。

黑盒測試方法包括：等價類劃分、邊界值分析、因果圖分析、錯誤推測法、功能圖分析等。

等價類劃分：

為了保證軟件質(zhì)量，需要做盡量多的測試。但不可能用所有可能的輸入數(shù)據(jù)來測試程序，即窮盡測試不可能。因此可以選擇有代表性的數(shù)據(jù)來測試程序。

等價類是某個輸入域的集合，在這個集合中的每個輸入條件都是等效的。

等價類分為有效等價類和無效等價類。

劃分等價類重要的是：集合的劃分，劃分為互不相交的一組子集，而子集的并集是整個集合。

參考鏈接：https://wenku.baidu.com/view/c491516fa45177232f60a2c4.html

邊界值分析：

邊界值分析法就是對輸入或者輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充。

邊界值分析法與等價類劃分的區(qū)別

1.邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。

2.邊界值分析不僅考慮輸入條件，還要考慮輸出空間產(chǎn)生的測試情況。

注：

字符的邊界值檢驗：在計算機軟件中，字符也是很重要的表示元素，其中ASCII和Unicode是常見的編碼方式。下表中列出了一些常用字符對應的ASCII碼值。

?

字符	ASCII碼值	字符	ASCII碼值
空 (null)	0	A	65
空格 (space)	32	a	97
斜杠 ( / )	47	Z	90
0	48	z	122
冒號 ( : )	58	單引號 ( ‘ )	96
@	64	?	?

因果圖分析

等價類劃分方法和邊界值分析方法，未考慮輸入條件之間的聯(lián)系，相互組合。考慮輸入條件之間的相互組合，可能會產(chǎn)生新的情況。因果圖方法最終生成的就是判定表，適合于檢查程序輸入條件的各種組合情況。

錯誤推測法

基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。

錯誤猜測法并非是一項有章可循的工程設計方法，而是很大程度上依賴于測試人員的經(jīng)驗、能力以及態(tài)度。從個人測試經(jīng)驗角度來看，在考慮使用錯誤猜測法補充測試用例時，可以從如下維度考慮：

A.極限值設計：考慮數(shù)值最大、最小、為空、為0等情況。

B.特殊取值設計：

• 年、月、日情況，必須考慮平年、閏年，2月，每月包含28天、29天、31天等情況。同時考慮跨年、跨月等情況。
• 模糊查詢情況，考慮"."、"%"、"？"等特殊字符取值情況。原因是這些字符在SQL中有它指定的含義。
• 其他取值，包括NULL、1024、FALSE（0）、TRUE（1）、特殊字符（！@#...）等。

C.特殊組網(wǎng)考慮：測試場景的考慮必須考慮版本使用局點的組網(wǎng)情況，特別是一些特殊的組網(wǎng)，比如網(wǎng)元主備、容災等。曾經(jīng)出現(xiàn)過某token使用未考慮同步到備機，導致業(yè)務出現(xiàn)故障后切換備機，業(yè)務運行失敗的問題。

D.端到端用例考慮：通常測試用例都是以特性為維度進行設計，或者測試人員在用例執(zhí)行時都是分功能進行測試用例設計和執(zhí)行，并未進行端到端測試用例設計。而端到端的測試用例更容易發(fā)現(xiàn)問題。以充值轉(zhuǎn)賬功能為例。端到端的用例場景包括：用戶開戶（用戶模型）->用戶轉(zhuǎn)賬（不同用戶層級間，所有的轉(zhuǎn)賬接口轉(zhuǎn)賬） -> 用戶充值（預付費、后付費，所有的充值接口） -> 交易記錄查詢（所有的查詢接口）。當然，如果有必要。這里還需要考慮用戶的類型、交易渠道等。

E.性能角度考慮：測試場景補充設計時必須要考慮性能情況，特別是未針對核心特性進行性能場景驗證的情況。最經(jīng)常出現(xiàn)的性能問題是報表查詢（功能測試時未考慮交易記錄數(shù)），包括充值交易記錄查詢、轉(zhuǎn)賬記錄查詢等涉及大業(yè)務量數(shù)據(jù)的測試。類似的功能包括報表測試或者核心交易邏輯的測試。業(yè)務數(shù)據(jù)量（交易記錄數(shù)）一定需要與現(xiàn)網(wǎng)數(shù)據(jù)量保持一致。

F.安全角度考慮：是否考慮不同用戶權限功能使用情況、日志中是否有明文顯示用戶隱私信息、用戶登錄是否安全校驗機制（如密碼連續(xù)3次輸入錯誤鎖賬戶、驗證碼）、是否允許越權、前后臺校驗是否一致等等。

G.可維護性考慮：新開發(fā)特性出現(xiàn)問題時，已知日志信息是否可以快速定位問題故障。如果沒有，需要增加日志信息。

H.用戶體驗：提示信息描述是否合理、搜索出現(xiàn)單條記錄是否默認選中、交互次數(shù)是否太多、界面操作是否簡潔、新增菜單風格是否與已知菜單保持一致。

I.功能實現(xiàn)與規(guī)格描述是否一致：功能實現(xiàn)是否與規(guī)格描述一致。是否存在規(guī)格中描述但實際特性缺失或者規(guī)格中未描述但存在多于交付特性。無特殊情況，交付功能需與規(guī)格內(nèi)容保持一致。另外一點，產(chǎn)品的某些特性需要在不同模塊中同時滿足。比如新增某充值功能，需要界面模塊和業(yè)務模塊兩種接入方式同時支持。

J.輸出域考慮：用例設計需針對輸出域情況進行分類考慮。一個是針對輸出情況設計輸入條件，另外一個是針對輸出內(nèi)容的使用途徑進行補充用例設計。比如某特性是針對充值功能的話單記錄新增一個字段，也就是話單發(fā)生了變化。那么必須要考慮后臺對邏輯對話單的處理是否能夠成功將新增字段的話單入庫到充值歷史記錄表。

K.隱含功能測試考慮：比如客戶要求歷史交易功能查詢，客戶通常僅會要求輸入條件和查詢方式，并會針對隱含功能如交易記錄展示的分頁、跳轉(zhuǎn)、單頁默認顯示行數(shù)等內(nèi)容。但測試設計時必須針對這些隱含功能進行測試。

L.針對不同開發(fā)考慮用例設計：這一條情況比較特殊。版本的缺陷會因人而異，同樣的特性會由于開發(fā)能力、開發(fā)態(tài)度、開發(fā)自驗證程度的不同而產(chǎn)生不同的bug。特別注意新員工、自驗證隨意的開發(fā)人員，你會發(fā)現(xiàn)有很多"驚喜"。但這些"驚喜"沒有在版本發(fā)布前發(fā)現(xiàn)，就會成為"驚嚇"了

參考鏈接：https://zhuanlan.zhihu.com/p/121831069

白盒測試：是對軟件的過程性細節(jié)做細致的檢查。是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結(jié)構測試或邏輯驅(qū)動測試。

白盒測試方法包括：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋等。

單元測試：是對軟件中的基本組成單位進行的測試，如一個模塊、一個過程等等。它是軟件動態(tài)測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。一個軟件單元的正確性是相對于該單元的規(guī)約(詳細設計)而言的。因此，單元測試以被測試單位的規(guī)約為基準。

單元測試方法包括：控制流測試、數(shù)據(jù)流測試、排錯測試、分域測試等。

集成測試：是在軟件系統(tǒng)集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據(jù)集成測試計劃，一邊將模塊或其他軟件單位組合成越來越大的系統(tǒng)，一邊運行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。

系統(tǒng)測試：是對已經(jīng)集成好的軟件系統(tǒng)進行徹底的測試，以驗證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它被稱為測試的“先知者問題”。因此，系統(tǒng)測試應該按照測試計劃進行，其輸入、輸出和其他動態(tài)運行行為應該與軟件規(guī)約進行對比。軟件系統(tǒng)測試方法很多，主要有功能測試、性能測試、隨機測試等。

驗收測試：由客戶或最終用戶執(zhí)行，旨在向軟件的購買者展示該軟件系統(tǒng)滿足其用戶的需求。它的測試數(shù)據(jù)通常是系統(tǒng)測試的測試數(shù)據(jù)的子集。所不同的是，驗收測試常常有軟件系統(tǒng)的購買者代表在現(xiàn)場，甚至是在軟件安裝使用的現(xiàn)場。這是軟件在投入使用之前的最后測試。

UAT測試：

UAT，(User Acceptance Test),也就是用戶驗收測試，或用戶可接受測試，系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據(jù)測試計劃和結(jié)果對系統(tǒng)進行測試和接收。 它讓系統(tǒng)用戶決定是否接收系統(tǒng)。 它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。

功能測試：對產(chǎn)品的各功能進行驗證，根據(jù)功能測試用例，逐項測試，檢查產(chǎn)品是否達到用戶要求的功能。

性能測試：是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。

用戶視角的軟件性能：

• 從用戶角度來說，軟件性能就是軟件對用戶操作的響應時間。

系統(tǒng)管理員視角的軟件性能：

• 系統(tǒng)的響應時間；
• 系統(tǒng)運行時服務器的狀態(tài)，如CPU利用情況、內(nèi)存使用情況等；
• 系統(tǒng)是否能夠?qū)崿F(xiàn)擴展；
• 系統(tǒng)支持多少用戶訪問；
• 系統(tǒng)性能可能的瓶頸在哪里；
• 系統(tǒng)是否支持7*24小時的業(yè)務訪問。

軟件性能指標：

• 并發(fā)用戶：一給定時間內(nèi)，某個時刻與服務器同時進行會話操作的用戶數(shù)。
• 響應時間：客戶端發(fā)出請求到得到服務器返回結(jié)果的整個過程所經(jīng)歷的時間。
• 吞吐量：單位時間內(nèi)系統(tǒng)處理的客戶請求的數(shù)量；一般來說，吞吐量用請求數(shù)/秒或頁面數(shù)/秒來衡量；從業(yè)務的角度，吞吐量也可以用訪問人數(shù)/天或處理的業(yè)務數(shù)/小時等單位來衡量；從網(wǎng)絡的角度來說，也可以用字節(jié)數(shù)/天等單位來考察網(wǎng)絡流量。
• 資源利用率：指系統(tǒng)資源的使用程度，比如服務器的CPU利用率、內(nèi)存利用率、磁盤利用率、網(wǎng)絡帶寬利用率等。

負載測試：

• 定義
  • 數(shù)據(jù)在超負荷環(huán)境下運行，測試軟件系統(tǒng)是否能夠承擔。這種超負荷主要指多并發(fā)用戶。
• 方法
  • 人為生成大數(shù)據(jù)量，并利用工具模擬頻繁并發(fā)訪問
• 工具
  • 一般需要使用自動化工具
• 考察指標
  • 響應時間、交易容量、資源使用率等

壓力測試：

• 定義
  • 指系統(tǒng)不斷施加越來越大的負載（并發(fā)，循環(huán)操作，多用戶，網(wǎng)絡流量）的測試。
• 目標
  • 通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來確定系統(tǒng)能提供的最大服務級別的測試。

恢復測試：恢復測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)。恢復測試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復。如果系統(tǒng)恢復是自動的（即恢復由系統(tǒng)自身完成），則應該檢驗以下內(nèi)容：重新初始化、檢驗點設置機構、數(shù)據(jù)恢復以及重新啟動是否正確。

可用性測試：

可用性測試是面向用戶的系統(tǒng)測試。讓一群有代表性的用戶嘗試對產(chǎn)品進行典型操作，- - 同時觀察員和開發(fā)人員在一旁觀察，聆聽，做記錄。

• 系統(tǒng)中是否存在繁瑣的功能以及指令；
• 安裝過程是否復雜；
• 錯誤信息提示內(nèi)容是否詳細；
• GUI接口是否標準；
• 登錄是否方便；
• 需要用戶記住內(nèi)容的多少；
• 幫助文本是否詳細；

兼容性測試：

• 定義
  • 測試軟件在一個特定的硬件、軟件、操作系統(tǒng)、網(wǎng)絡等環(huán)境下系統(tǒng)能否正常運行。
• 目的
  • 檢驗被測軟件對其他應用軟件或者其他系統(tǒng)的兼容性。

安全性測試：

• 定義
  • 安全測試檢測系統(tǒng)對非法入侵的防范能力。
• 應用程序級別的安全性測試
• 數(shù)據(jù)庫安全性測試
• 系統(tǒng)級別的安全性測試

Alpha測試：由用戶在開發(fā)者的場所進行，并且在開發(fā)者對用戶的“指導”下進行測試。開發(fā)者負責記錄發(fā)現(xiàn)在錯誤和使用中遇到的問題。總之，Alpha測試是在受控的環(huán)境中進行的。

Beta測試：由軟件的最終用戶們在一個或多個客房場所進行。與Alpha測試不同，開發(fā)者通常不在Beta測試的現(xiàn)場，因Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。用戶Beta測試過程中遇到的一切問題（真實在或想像的），并且定期把這些問題報告給開發(fā)者。接收到在Beta測試期間報告的問題之后，開發(fā)者對軟件產(chǎn)品進行必要的修改，并準備向全體客戶發(fā)布最終的軟件產(chǎn)品。

冒煙測試：可以根據(jù)其名稱理解為該種測試耗時短，僅用一袋煙功夫足夠了；其實是對軟件基本的功能進行測試，測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本的功能正常，保證軟件系統(tǒng)能跑的起來，可以進行后續(xù)的正式測試工作。

回歸測試：是指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤，回歸測試的困難在于不好確定哪些內(nèi)容應當被重新測試。

隨機測試：主要是根據(jù)測試者的經(jīng)驗對軟件進行功能和性能抽查。它是根據(jù)測試說明書執(zhí)行樣例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。

動態(tài)測試：是指通過運行被測程序，檢查運行結(jié)果與預期結(jié)果的差異，并分析運行效率和健壯性等性能，這種方法由三部分組成：構造測試實例、執(zhí)行程序、分析程序的輸出結(jié)果。所謂軟件的動態(tài)測試，就是通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。目前，動態(tài)測試也是公司的測試工作的主要方式。

靜態(tài)測試：是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結(jié)構、過程、接口等來檢查程序的正確性。對需求規(guī)格說明書、軟件設計說明書、源程序做結(jié)構分析、流程圖分析、符號執(zhí)行來找錯。靜態(tài)方法通過程序靜態(tài)特性的分析，找出欠缺和可疑之處，例如不匹配的參數(shù)、不適當?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態(tài)測試結(jié)果可用于進一步的查錯，并為測試用例選取提供指導。

UI測試：指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面美工是否好看，文字，圖片組合是否完美，背景是否美觀，操作是否友好等；用戶界面(UI)測試用于核實用戶與軟件之間的交互。UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI測試還可確保UI中的對象按照預期的方式運行，并符合公司或行業(yè)的標準。包括用戶友好性，人性化，易操作性測試。UI測試比較主觀，與測試人員的喜好有關。

自動化測試：利用軟件測試工具自動實現(xiàn)全部或部分測試，它是軟件測試的一個重要組成部分，能完成許多手工測試無法實現(xiàn)或難以實現(xiàn)的測試；正確、合理的實施自動測試，能夠快速、全面的對軟件進行測試，從而提高軟件質(zhì)量，節(jié)省經(jīng)費，縮短軟件發(fā)布周期。

樁測試：

樁的英文是stub；是指一個軟件模塊的框架或特殊目標實現(xiàn)，主要用于開發(fā)和測試一個組件，該組件調(diào)用或依賴這個模塊。

樁模塊：集成測試前要為被測模塊編制一些模擬其下級模塊功能的“替身”模塊，以代替被測模塊的接口，接受或傳遞被測模塊的數(shù)據(jù)，這些專供測試用的“假”模塊稱為被測模塊的樁模塊。

測試樁一般是 自頂向下集成時需要使用

驅(qū)動測試：

所謂驅(qū)動測試（自底向上集成時使用），就是你負責測試模塊/方法是中間的，沒有main（）入口，怎么編譯，怎么啟動呢？就需要寫一個帶main()的方法來調(diào)用你的模塊/方法

樁模塊的使命除了使得程序能夠編譯通過之外，還需要模擬返回被代替的模塊的各種可能返回值(什么時候返回什么值需要根據(jù)測試用例的情況來決定)。

驅(qū)動模塊的使命就是根據(jù)測試用例的設計去調(diào)用被測試模塊，并且判斷被測試模塊的返回值是否與測試用例的預期結(jié)果相符

public class ddd{//Test driverpublic static void main(String[] args) {ddd d = new ddd();d.Add();}//My modulepublic int Add() { int output=this.Stub1() + this.Stub2();System.out.print("My module: return value is "+output+"\n");return output; }//Stub1public int Stub1() { int output=3;System.out.print("Stub 1 : return value is "+output+"\n");return output;}//Stub2public int Stub2() {int output=7;System.out.print("Stub 2 : return value is "+output+"\n");return output;}}

測試用例八大設計方法

測試方法分類：

• 黑盒測試 ：等價類劃分 邊界值分析 因果圖分析 錯誤測試
• 白盒測試：語句覆蓋 判定覆蓋 條件覆蓋 判定/條件覆蓋 多重條件覆蓋

等價類劃分方法

等價類劃分：指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的，并合理地假定；測試某等價類的代表值就等于對這一類其它值的測試。因此，可以把全部輸入數(shù)據(jù)合理劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件，就可以用少量代表性的測試數(shù)據(jù)，取得較好的測試結(jié)果。

等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

邊界值分析方法

邊界值：是對等價類劃分方法的補充，測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。

錯誤推測方法

錯誤推測：基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。

錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例。例如：在單元測試時曾列出的許多在模塊中常見的錯誤。以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等，這些就是經(jīng)驗的總結(jié)。還有，輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發(fā)生錯誤的情況。可選擇這些情況下的例子作為測試用例。

因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系，相互組合等。考慮輸入條件之間的相互組合，可能會產(chǎn)生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種適合于描述對于多種條件的組合，相應產(chǎn)生多個動作的形式來考慮設計測試用例。這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。

判定表驅(qū)動分析方法

判定表：是分析和表達多邏輯條件下執(zhí)行不同操作的情況的工具。

正交表設計分析方法

有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增，同時，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

功能圖分析方法

功能圖：由狀態(tài)遷移圖和布爾函數(shù)組成，狀態(tài)遷移圖用狀態(tài)和遷移來描述。一個狀態(tài)指出數(shù)據(jù)輸入的位置（或時間），而遷移則指明狀態(tài)的改變。同時要依靠判定表或因果圖表示的邏輯功能。

場景模擬分析方法

指根據(jù)用戶場景來模擬用戶的操作步驟,這個比較類似因果圖,但是可能執(zhí)行的深度和可行性更好。

軟件測試基本流程

軟件測試的基本流程（文字描述）

1測試需求分析階段：閱讀需求，理解需求，主要就是對業(yè)務的學習，分析需求點，參與需求評審會議

2制定測試計劃階段：主要任務就是編寫測試計劃，參考軟件需求規(guī)格說明書，項目總體計劃，內(nèi)容包括測試范圍（來自需求文檔），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規(guī)避措施有一個制定。

3測試設計階段：主要是編寫測試用例，會參考需求文檔（原型圖），概要設計，詳細設計等文檔，用例編寫完成之后會進行評審。

4測試執(zhí)行階段：搭建環(huán)境，執(zhí)行冒煙測試（預測試）-然后進入正式測試，bug管理直到測試結(jié)束

5測試評估階段：出測試報告，確認是否可以上線

人工測試技術

從心理學的角度出發(fā)思考，下面兩個方面顯著地提高了測試的功效和可靠性

首先，人們普遍認識到錯誤發(fā)現(xiàn)得越早，改正錯誤的成本越低，正確改正錯誤

的可能性也越大。

其次，程序員在開始基于計算機的測試時似乎要經(jīng)歷一個心理上的轉(zhuǎn)變。從內(nèi)部產(chǎn)生的壓力似乎會急劇增長，并產(chǎn)生一個趨勢，要“盡可能快地修正這個缺陷”。由于這些壓力的存在．程序員在改正某個由基于計算機測試發(fā)現(xiàn)的錯誤時所犯的失誤，要比改正早期發(fā)現(xiàn)的問題時所犯的失誤更多一些。

檢查與走查(Inspections And Walkthroughs)

代碼檢查與走查是兩種主要的人工測試方法

代碼檢查與走查都要求人們組成一個小組來閱讀或直觀檢查特定的程序。無論采用哪種方法，參加者都需要完成一些準備工作。準備工作的高潮是在參加者會議上進行的所謂“頭腦風暴會”。“頭腦風暴會”的目標是找出錯誤來，但不必找出改 正錯誤的方法。換句話說，是測試，而不是調(diào)試

代碼檢查是以組為單位閱讀代碼，它是一系列規(guī)程和錯誤檢查技術的集合。對代碼檢查的大多數(shù)討論都集中在規(guī)程、所要填寫的表格等。

這個代碼檢查過程通常將注意力集中在發(fā)現(xiàn)錯誤上，而不是糾正錯誤。

軟件生命周期

是指從軟件的產(chǎn)生直到報廢的整個周期，包括可行性分析與項目計劃，需求分析，概要設計和詳細設計，編碼，調(diào)試，維護七個階段。

軟件測試生命周期

是指從測試項目計劃建立到BUG提交的整個測試過程，包括軟件項目測試計劃，測試需求分析，測試用例設計，測試用例執(zhí)行，BUG提交五個階段。

也可以是（測試計劃 → 測試設計 → 測試開發(fā) → 測試執(zhí)行 → 測試評估）。

軟件測試生命周期并行與軟件生命周期，存在于軟件生命周期的各個階段。

軟件測試人員的主要職責

編寫測試計劃

設計測試用例

執(zhí)行測試，發(fā)現(xiàn)缺陷提交測試報告

驗證缺陷是否得到修改

編寫測試總結(jié)報告

軟件測試的原則 ：

十項原則

1 測試用例中一個必需部分是對預期輸出或結(jié)果進行定義

2 程序員應避免測試自己編寫的程序

3 編寫軟件的組織不應當測試自已編寫的軟件

4 應當徹底檢查每個測試的執(zhí)行結(jié)果

5 測試用例的編寫不僅應當根據(jù)有效和預料到的輸入情況，而且也應當根據(jù)無效和未預料到的輸入情況

6 檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程是 否“做了其不應該做的”

7 應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件

8 計劃測試工作時不應默許假定不會發(fā)現(xiàn)錯誤

9 程序某部分存在更多錯誤的可能性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比

10 軟件測試是一項極富創(chuàng)造性，極具智力的挑戰(zhàn)性的工作

三個重要的測試原則：

? 軟件測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

? 一個好的測試用例具有較高的發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤的可能性。

? 一個成功的測試用例能夠發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤。

優(yōu)秀的軟件測試人員需要具備的素質(zhì)和技能

良好的溝通和表達能力

具有懷疑與破壞的精神

扎實的軟件測試基礎知識

縝密的業(yè)務邏輯分析能力

處在用戶的角度進行換位思考

足夠的耐心、細心、信心、責任心

積極樂觀向上的心態(tài)和團隊協(xié)作能力

要有嚴謹、敢于承擔責任、穩(wěn)重的做事風格

善于自我總結(jié)、自我督促和不斷學習的能力

常用測試工具

1、Apache JMeter是一個Apache項目，可用作負載測試工具，用于分析和測量各種服務的性能，重點關注Web應用程序。

做壓力測試的步驟如下:

1. 寫腳本 或者錄制腳本

2. 使用用戶自定義參數(shù)

3. 場景設計

4. 使用控制器，來控制 模擬多少用戶。

5. 使用監(jiān)聽器， 查看測試結(jié)果

總結(jié)

以上是生活随笔為你收集整理的软件测试面试1--软件测试基础理论（持续更新中...）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。