測試先導(dǎo)性知識

測試是什么？

在規(guī)定的條件下對程序進(jìn)行操作去發(fā)現(xiàn)錯誤，然后對軟件質(zhì)量進(jìn)行評估的一個過程。

需要注意的是，軟件是由文檔、數(shù)據(jù)以及程序組成的，所以對軟件測試應(yīng)該包括：軟件形成過程的文檔、數(shù)據(jù)以及程序，而不僅僅是對程序進(jìn)行的測試。

測試的目的、作用

通過測試工作發(fā)現(xiàn)問題并及時報告給開發(fā)，讓開發(fā)修復(fù)軟件當(dāng)中潛在的各種錯誤和缺陷，提高軟件質(zhì)量，進(jìn)而提高用戶對產(chǎn)品的使用信心，避免軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患所帶來的商業(yè)風(fēng)險。

測試可以記錄軟件運行過程中產(chǎn)生的一些數(shù)據(jù)，從而為決策提供數(shù)據(jù)支持
（比如搶火車票，你模擬用戶測試，最終測出的流量上限是1個億。那高層拿到你的測試數(shù)據(jù)后就可以去決策這個上限能否讓軟件投放市場）

測試可以降低同類型產(chǎn)品開發(fā)遇到問題的風(fēng)險。（參考同一公司的微信和qq，都是社交軟件，qq踩過的坑可以讓微信規(guī)避掉）

測試的原則

不能執(zhí)行窮盡測試：有些功能是沒有辦法將所有的測試情況都邏列出來

缺陷存在群集現(xiàn)象：對于軟件功能說，核心功能占20%，非核心是80%。在實際工作中我們會集中測試20%的核心功能，所以這個部分發(fā)現(xiàn)缺陷的幾率就會高于80%。因此我們就會遇到缺陷都集中在20%功能模塊里的現(xiàn)象。

某些測試需要依賴特殊的環(huán)境：像有些手機(jī)不考慮冬天的情況，溫度低的時候電量掉的快

測試應(yīng)盡早介入：為了更多的發(fā)現(xiàn)和更好的解決軟件中的缺陷，我們追求測試工作盡早的開展

殺蟲劑現(xiàn)象：同樣的一個測試用例不能重的執(zhí)行多次，因為軟件會對它產(chǎn)生免疫（ 開發(fā)會根據(jù)你 的用例去修改，你再測同樣的用例肯定能過關(guān)的或是被開發(fā)蒙混過關(guān)）

不存在缺陷謬論：任何軟件不可能是完美的。

測試測什么？（測試對象是什么）

1.需求分析階段：各種需求規(guī)格說明書
2.軟件架構(gòu)設(shè)計：API接口文檔（接口測試）
3.編碼實現(xiàn)階段：源代碼（白盒測試、單元測試）
4.系統(tǒng)功能使用：軟件功能主體（當(dāng)前行業(yè)做的最多的一種測試）

測試計劃工作的關(guān)鍵是什么？

明確測試的目標(biāo)，增強(qiáng)測試計劃的實用性，明確內(nèi)容與過程
采用評審和更新機(jī)制，保證測試計劃滿足實際需求
需要分別創(chuàng)建測試計劃與測試詳細(xì)規(guī)格、測試用例

測試基礎(chǔ)理論

軟件測試模型有哪些？

瀑布流

項目計劃—>需求分析—>軟件設(shè)計—>編碼—>測試—>運行維護(hù)

優(yōu)點：
軟件開發(fā)的各項活動嚴(yán)格按照線性方式進(jìn)行
前一階段完成后，只需關(guān)注后續(xù)階段

缺點：
難以適應(yīng)需求的頻繁變化
早期的錯誤可能要等到開發(fā)后期的階段才能發(fā)現(xiàn)

V模型

W模型

還有X模型、H模型

軟件的生命周期（軟件開發(fā)的流程）

需求分析
軟件設(shè)計（概要設(shè)計、詳細(xì)設(shè)計）
軟件編碼
軟件測試（單元測試、集成測試、系統(tǒng)測試、驗證測試）
運行維護(hù)

詳細(xì)介紹

軟件產(chǎn)品質(zhì)量特性是什么？

功能性、可靠性、效率、易用性、可維護(hù)、可移植

功能性

定義:軟件在指定的使用環(huán)境下,滿足用戶顯性或隱性需求的能力
適合性:軟件為指定的任務(wù)和用戶目標(biāo)提供一組合適功能的能力
準(zhǔn)確性:軟件提供具有所需精確度的正確或相符的結(jié)果或效果的能力
互操作性:軟件與一個或更多個的規(guī)定系統(tǒng)進(jìn)行交互的能力

可靠性

定義:軟件在指定的條件下使用,維持規(guī)定的性能級別的能力
成熟性:軟件為避免由軟件中錯誤而導(dǎo)致失控的能力,
容錯性:在軟件出現(xiàn)故障或違反指定接口的情況下,軟件維持規(guī)定性能級別的能力,
易恢復(fù)性:在失效發(fā)生的情況下軟件里重建規(guī)定的件能級別并恢復(fù)受直接影響的數(shù)據(jù)的能力
可靠性依從性:軟件遵循與可靠件相關(guān)的標(biāo)準(zhǔn),約定以及法律法規(guī)的能力

效率

定義:在規(guī)定的條件下,相對于所用資源的數(shù)量,軟件提供適當(dāng)性能的能力
時間特性:在規(guī)定的條件下軟件執(zhí)行其功能時,提供適當(dāng)?shù)捻憫?yīng)和處理時間以及吞吐率的能力
資源利用性:在規(guī)定的條件下軟件執(zhí)行其能力時,使用合適的資源數(shù)量和類別的能力
效率依從件:軟件遵循與效率相關(guān)的標(biāo)準(zhǔn)和約定的能力

易用性

定義:在指定的條件下使用時,軟件被學(xué)習(xí),理解,使用和吸引用戶的能力
易理解性:軟件的使用，用戶能理解軟件是否合適,以及如何將軟件用于特定的任務(wù)和使用環(huán)境的能力
易學(xué)習(xí):軟件使用戶能學(xué)習(xí)其應(yīng)用的能力易操作性:軟件使用用戶操作和控制它的能力
吸引性:軟件吸引用戶的能力
易用性依從性:遭循與易用性相關(guān)的標(biāo)準(zhǔn)、約定風(fēng)格指南或法規(guī)的能力

可維護(hù)

定義:軟件可被修改的能力,修改可能包括修正、改進(jìn)或軟件對環(huán)境、需求和功能規(guī)格說明變化的適應(yīng)性
易分析性:軟件診斷軟件的缺陷,失效原因或識別待修改部分的能力,
易改變性:軟件指定的修改可以被實現(xiàn)的能力
穩(wěn)定性:軟件避免由于軟件修改而造成意外結(jié)果的能力,
易測試性:軟件使已修改軟件能被確認(rèn)的能力
可維護(hù)依從性:遵循與維護(hù)相關(guān)標(biāo)準(zhǔn)和約定的能力,

可移植

定義:軟件從一種環(huán)境遷移到另一種環(huán)境的能力
適用性:軟件能適用于不同的環(huán)境的能力
易安裝性:軟件在指定環(huán)境中被安裝的能力
共存性:軟件在公共環(huán)境中同與其分享公共資源的其他獨立軟件共存的能力
易替換性:軟件在同樣的環(huán)境下,替代另一個相同用途的指定軟件產(chǎn)品的能力
可移植性依從性:軟件遵循可移植性相關(guān)的標(biāo)準(zhǔn)和約定的能力

如何判斷是Bug（Bug的定義，缺陷的定義）

只要滿足下列5個規(guī)則之一則稱為發(fā)生了一個軟件缺陷
軟件未實現(xiàn)產(chǎn)品說明書要求的功能
軟件未實現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實現(xiàn)的功能
軟件出現(xiàn)了產(chǎn)品說明書指明不應(yīng)該出現(xiàn)的錯誤
軟件實現(xiàn)了產(chǎn)品說明書未提到的功能
軟件難以理解、不易使用、運行緩慢，或者從測試員的角度看，最終用戶會認(rèn)為不好

Bug嚴(yán)重程度（Bug級別定義）

致命：系統(tǒng)崩潰、異常退出、嚴(yán)重計算錯誤、嚴(yán)重資源不足
嚴(yán)重：系統(tǒng)無法滿足主要的業(yè)務(wù)要求，像業(yè)務(wù)流程錯誤
一般：系統(tǒng)可以滿足業(yè)務(wù)要求但有性能缺陷或界面缺陷，像提示信息不準(zhǔn)確
輕微：易用性及建議性問題，不影響執(zhí)行工作功能，像出現(xiàn)錯別字

Bug的生命周期

添加鏈接描述

Bug狀態(tài)的處理（處理一個缺陷的流程）

請描述你對測試的了解

內(nèi)容可以涉及測試流程，測試分類，測試方法，測試工具

測試流程（測試工作流程）

需求分析，梳理清楚我們需要設(shè)計的點是什么
編寫測試計劃，做什么類型的測試，需要什么樣的工具
編寫測試用例，用例是為了測試軟件的某個功能而執(zhí)行的操作過程
評審用例，對當(dāng)前的用例進(jìn)行添加或者刪除
配置環(huán)境
執(zhí)行用例，執(zhí)行用例前先做冒煙測試，通過才開始正式測試
回歸測試，缺陷被開發(fā)修復(fù)后進(jìn)行復(fù)測
缺陷跟蹤
輸出測試報告，方便其它人去查看
測試結(jié)束，將整個測試過程產(chǎn)生的文檔進(jìn)行整理歸檔，方便后續(xù)版本使用。

社招：
1.首先要進(jìn)行需求分析。軟件開發(fā)完成以后，由項目經(jīng)理拿到需求文檔后，召開會議，開發(fā)、測試一同參與，評審需求文檔中的內(nèi)容。
（需求的來源（拿到軟件不知道要測什么的時候參考的渠道）：需求規(guī)格說明書（產(chǎn)品經(jīng)理提供）、看行業(yè)標(biāo)準(zhǔn)和政策法規(guī)、竟品分析、個人經(jīng)驗）
2.項目經(jīng)理根據(jù)評審后的需求文檔，制定測試計劃。
（包含內(nèi)容：人員、任務(wù)劃分、時間規(guī)劃（開發(fā)的 30%-40%）、項目結(jié)束需要出具的文檔（測試用例文檔或 bug 文檔）、做什么類型的測試？需要什么樣的工具……）
3.測試人員根據(jù)測試計劃，編寫測試用例。
4.測試用例編寫完后后，需要召開會議，開發(fā)、測試一同參與，評審測試用例。
5.搭建測試環(huán)境，在開發(fā)提交第一版本后，開始進(jìn)行測試，對測試發(fā)現(xiàn)的問題提交到bug管理平臺。
6.開發(fā)人員修改bug后，對bug進(jìn)行復(fù)測，確保bug修改后，關(guān)閉bug。
7.每次開發(fā)提交新版本后，重復(fù)5、6的操作，直到上線前的最后一個版本。
8.版本上線前，需要對系統(tǒng)進(jìn)行一次全面的系統(tǒng)測試，測試不再發(fā)現(xiàn)bug后，進(jìn)行上線的工作。

測試分類

----測試級別（測試有哪幾個階段）

1.單元測試[ UT unit test]（白盒）：在軟件測試中單元指的就是組成軟件最小的底層代碼結(jié)構(gòu)一般就是類、函數(shù)、組件（當(dāng)下的軟件測試行業(yè)，不會刻意要求測試人員對源代碼進(jìn)行測試）

2.集成測試（IT system ingertaion test）（灰盒）：將多個單元模塊組合在一起，然后驗證它們之間溝通的”橋梁"是否能正常工作（接口測試）

3系統(tǒng)測試（ ST system test）（黑盒）這是當(dāng)前行業(yè)做的最多的一種測試。由測試人員充當(dāng)用戶然后對軟件的功能主體進(jìn)行測試

4.驗收測試
（1）α測試一內(nèi)測，在軟件開發(fā)環(huán)境下進(jìn)行的測試，開發(fā)和測試在一起，把用戶請到公司內(nèi)部進(jìn)行測試使用，或者說是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的測試
（2）β測試-公測，用戶的應(yīng)用環(huán)境下，開發(fā)和測試不再一起，還要由玩家把bug發(fā)郵箱然后獲得獎勵的那種
（3）UAT（ user acceptance test）測試一由客戶派出對于業(yè)務(wù)非常精通的人員來使用該軟件，從而對功能進(jìn)行測試。
（4）驗收測試的核心就是讓用戶為當(dāng)前軟件“買單

--------系統(tǒng)測試分類

1.功能測試：驗證當(dāng)前的軟件主體功能是否可用。
2.兼容性測試：驗證當(dāng)前軟件在不同的環(huán)境下是否還可以使用
3.安全測試：驗證軟件是否只是能授權(quán)用戶提供功能使用。
4.性能測試：相對于當(dāng)前軟件消耗的資源它的產(chǎn)出能力。

--------常見的系統(tǒng)測試方法

按測試對象進(jìn)行分類
1.白盒測試：這種測試的主體就是軟件的底層代碼，不會在意外在的界面是否OK，只要求底層功能實現(xiàn)，同時邏輯正確（把盒子打開，去研究里面的源代碼和程序結(jié)構(gòu)。）
2.黑盒測試：這種測試就是指測試軟件外在主體功能是否可用，完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性，注重于測試軟件的功能需求，只關(guān)心軟件的輸入數(shù)據(jù)和輸出數(shù)據(jù)
3.灰盒測試：介于二者之間（接口測試）
4.上述三種方法當(dāng)中的“盒”指的就是被測對象。

----靜態(tài)測試和動態(tài)測試

白盒測試、黑盒測試、灰盒測試，在實現(xiàn)測試方法上既包括了動態(tài)測試，也包括了靜態(tài)測試。

按測試對象是否執(zhí)行分類
1.靜態(tài)測試：指的就是測試不執(zhí)行。（開發(fā)出來的html和美工預(yù)期的html直接用肉眼看看是否相同即可）（指不實際運行被測軟件，而只是靜態(tài)地檢查程序代碼、界面或文檔中可能存在的錯誤過程）
2.動態(tài)測試：將軟件運行在真實的使用環(huán)境中進(jìn)行測試。是指實際運行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程。）

----手動測試和自動化測試

按測試手段進(jìn)行分類
1.手工測試：由測試人員手動的對被測對象進(jìn)行驗證，優(yōu)點就是可以靈活的改變測試操作及環(huán)境。
2.自動化測試：所謂自動化主要有二種形，一種是自已寫測試腳本，另外一種就是通過第三方的工具對被測對象進(jìn)行測試。優(yōu)點就是可以高效率的去執(zhí)行一些人工無法實現(xiàn)的操作。

測試方法

黑盒測試（功能測試）：邊界值。等價類劃分，因果圖，決策表，錯誤推測法
白盒測試：語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋

----黑盒測試（測試用例設(shè)計方法）（測試用例是怎么設(shè)計的）

1、等價類劃分法：把程序的輸入域劃分為若干部分，從每個部分中選取少數(shù)、有代表性的數(shù)據(jù)作為程序輸入的測試用例。

2、邊界值分析法：配合等價類使用的，對范圍的邊界數(shù)據(jù)進(jìn)行專門測試。一般情況下，需要對邊界值（O和100）以及邊界值兩邊的數(shù)（-1和1以及101和99）分別進(jìn)行測試。

3、錯誤推測法：利用直覺和經(jīng)驗猜測出出錯的可能類型，有針對性列舉出程序中所有可能的錯誤和容易發(fā)生錯誤的情況，
像輸入一些非法、錯誤、不正確和垃圾輸入，輸入空格、輸入為空等等

因果圖法：等價類和邊界值沒有考慮到輸入的組合關(guān)系，因果圖考慮的就是這個問題
用法：根據(jù)題目列出可能的輸入和輸出情況，然后對輸入和輸出各自進(jìn)行條件的組合，把各自的組合關(guān)系列出來，然后就可以制成判定表了。

判定表驅(qū)動法：因果圖只是一種輔助工具，通過分析最終得到判定表，再
通過判定表編寫測試用例。但有時畫因果圖非常麻煩，影響測試效率，可以直接寫判定表，進(jìn)而編寫測試用例。

判定表的組成
條件樁：問題的所有條件
動作樁：問題的所有輸出
條件項：針對條件樁的取值
動作項：條件項的各種取值情況下的輸出結(jié)果：

正交表法：
使用最小的測試過程集合獲得最大的測試覆蓋率，不可能為每個輸入組合
都創(chuàng)建測試用例時，可以采用這種方法。
特點：均勻分散
使用：它有正交表模板，根據(jù)你題目中的控件和取值個數(shù)去選取合適的模板，然后把數(shù)據(jù)映射到模板上就可以得到測試用例表了。如果說是混合正交表不能使用模板的話就要用正交表生成工具了。

場景法：
模擬用戶操作軟件時的場景，主要用于測試系統(tǒng)的業(yè)務(wù)流程
當(dāng)業(yè)務(wù)流程測試沒有問題，也就是該軟件的主要功能沒有問題時，我們再重點從邊界值、等價類等方面對控件進(jìn)行測試
冒煙測試時也主要采用場景法進(jìn)行測試
使用：
產(chǎn)品經(jīng)理提供的業(yè)務(wù)需求就當(dāng)成場景法的測試用例去測就行了，結(jié)果不一樣的話提bug就可以了

--------測試方法的選擇

通常在確定測試方法時，有以下幾條參考原則：
（1）拿到一個測試任務(wù)時，先關(guān)注它的主要功能和業(yè)務(wù)流程、業(yè)務(wù)邏輯是否正確實現(xiàn)，考慮使用場景法。
（2）需要輸入數(shù)據(jù)的地方，考慮采用等價類劃分法，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試。
（3）在任何情況下都必須采用邊界值分析法。這種方法設(shè)計出的測試用例發(fā)現(xiàn)程序錯誤的能力最強(qiáng)
（4）如果程序的功能說明中含有輸入條件的組合情況，則一開始就應(yīng)考慮選用因果圖和判定表法。
（5）對于參數(shù)配置類的軟件，需要考慮參數(shù)之間的組合情況，考慮使用正交排列法選擇較少的組合方式（最少的測試南例獲得最大的的測試覆蓋率）.
（6）對照程序邏輯，檢查已設(shè)計出的測試用例的邏輯覆蓋程度。如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn)，則應(yīng)當(dāng)再補充更多的測試用例。
（7）采用錯誤推斷法再追加測試用例—依靠測試工程師的經(jīng)驗和智慧

--------功能測試和性能測試的區(qū)別是什么？

1）測試目的：

功能測試：檢測實際軟件的功能是否符合用戶需求，測功能是不是全部實現(xiàn)，某個實現(xiàn)是不是有BUG。主要為了發(fā)現(xiàn)以下幾類錯誤：A、是否有不正確或遺漏的功能？B、功能實現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計的隱藏需求？C、能否正確接收輸入？能否正確輸出結(jié)果？

性能測試：驗證軟件質(zhì)量的三個質(zhì)量特性，可靠性，正確性和效率。主要是測試產(chǎn)品的健壯性

2）測試方式：

功能測試按照系用例，按照系統(tǒng)需求說明書和測試用例，對產(chǎn)品的功能一步步進(jìn)行測試。找出產(chǎn)品功能是否全部實現(xiàn)

性能測試：一般都使用性能工具對產(chǎn)品的健壯性進(jìn)行評估。通過創(chuàng)建場景和虛擬用戶模擬真實環(huán)境，進(jìn)行壓力測試和負(fù)載測試。

--------負(fù)載測試和壓力測試？

性能測試包括壓力測試和負(fù)載測試，測試的是不同負(fù)載條件下系統(tǒng)的各項性能指標(biāo)，如吞吐量、響應(yīng)時間、點擊率等。

負(fù)載測試是模擬實際軟件系統(tǒng)所承受的負(fù)載條件的系統(tǒng)負(fù)荷，通過不斷加載（如逐漸增加模擬用戶的數(shù)量）或其它加載方式來觀察不同負(fù)載下系統(tǒng)的響應(yīng)時間和數(shù)據(jù)吞吐量、系統(tǒng)占用的資源（如CPU、內(nèi)存）等，以檢驗系統(tǒng)的行為和特性，以發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸、內(nèi)存泄漏、不能實時同步等問題。負(fù)載測試更多地體現(xiàn)了一種方法或一種技術(shù)。

壓力測試可以被看作是負(fù)載測試的一種，即高負(fù)載下的負(fù)載測試。查看應(yīng)用系統(tǒng)在峰值使用情況下操作行為，從而有效地發(fā)現(xiàn)系統(tǒng)的某項功能隱患、系統(tǒng)是否具有良好的容錯能力和可恢復(fù)能力。壓力測試分為高負(fù)載下的長時間（如24小時以上）的穩(wěn)定性壓力測試和極限負(fù)載情況下導(dǎo)致系統(tǒng)崩潰的破壞性壓力測試。

通過壓力測試可以更快地發(fā)現(xiàn)影響系統(tǒng)穩(wěn)定性的問題。例如，在正常負(fù)載情況下，某些功能不能正常使用或系統(tǒng)出錯的概率比較低，可能一個月只出現(xiàn)一次，但在高負(fù)載（壓力測試）下，可能一天就出現(xiàn)，從而發(fā)現(xiàn)有缺陷的功能或其它系統(tǒng)問題。通過負(fù)載測試，可以證明這一點，某個電子商務(wù)網(wǎng)站的訂單提交功能，在10個并發(fā)用戶時錯誤率是零，在50個并發(fā)用戶時錯誤率是1%，而在200個并發(fā)用戶時錯誤率是20％。
負(fù)載測試是為了發(fā)現(xiàn)系統(tǒng)的性能問題，負(fù)載測試需要通過系統(tǒng)性能特性或行為來發(fā)現(xiàn)問題，從而為性能改進(jìn)提供幫助，從這個意義看，負(fù)載測試可以看作性能測試的一部分。但它們兩者的目的是不一樣的，負(fù)載測試是為了發(fā)現(xiàn)缺陷，而性能測試是為了獲取性能指標(biāo)。因為性能測試過程中，也可以不調(diào)整負(fù)載，而是在同樣負(fù)載情況下改變系統(tǒng)的結(jié)構(gòu)、改變算法、改變硬件配置等等來得到性能指標(biāo)數(shù)據(jù)，從這個意義看，負(fù)載測試可以看作是性能測試所c的一種技術(shù)，即性能測試使用負(fù)載測試的技術(shù)、使用負(fù)載測試的工具。性能測試要獲得在不同的負(fù)載情況下的性能指標(biāo)數(shù)據(jù)。

負(fù)載測試是通過改變系統(tǒng)負(fù)載方式、增加負(fù)載等來發(fā)現(xiàn)系統(tǒng)中所存在的性能問題。負(fù)載測試是一種測試方法，可以為性能測試、壓力測試所采用。負(fù)載測試的加載方式也有很多種，可以根據(jù)測試需要來選擇。
性能測試是為獲取或驗證系統(tǒng)性能指標(biāo)而進(jìn)行測試。多數(shù)情況下，性能測試會在不同負(fù)載情況下進(jìn)行。
壓力測試通常是在高負(fù)載情況下來對系統(tǒng)的穩(wěn)定性進(jìn)行測試，更有效地發(fā)現(xiàn)系統(tǒng)穩(wěn)定性的隱患和系統(tǒng)在負(fù)載峰值的條件下功能隱患等。

----白盒測試

黑盒主要是根據(jù)業(yè)務(wù)需求來設(shè)計的輸入，白盒則根據(jù)系統(tǒng)的內(nèi)部實現(xiàn)設(shè)計的輸入，它的主要目標(biāo)是覆蓋更多的代碼

只適用于單元測試階段

優(yōu)點：代碼覆蓋率高
缺點：覆蓋所有代碼路徑難度大、業(yè)務(wù)功能可能覆蓋不全、測試開銷大（手工測，費人力；自動測，代碼量大）

測試設(shè)計方法：

靜態(tài)：測試過程中不執(zhí)行程序，即不執(zhí)行代碼進(jìn)行測試

• 手工方法：
  桌面檢查（交叉檢查）（a寫的代碼給b檢查，b寫的代碼給a檢查）、
  代碼審查（相對正式，以會議的形式進(jìn)行檢查，由開發(fā)講解自己的代碼，下面的開發(fā)和測試聽，然后提意見）、
  代碼走查（也要開會，形式是測試人員提前準(zhǔn)備好測試用例看看程序的走向如何，人工來計算查看數(shù)據(jù)的走向）

• 自動化方法：
  自動化工具，進(jìn)行代碼的掃描

動態(tài)：執(zhí)行代碼進(jìn)行測試

方法有：
邏輯覆蓋法：是通過對程序邏輯結(jié)構(gòu)的遍歷實現(xiàn)程序約覆蓋。
基本路徑測試法：在程序控制流圖的基礎(chǔ)上，通過分析程序的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例

---

邏輯覆蓋法具體有：

語句覆蓋：設(shè)計瀏試用例，使得程序中每條語句至少被執(zhí)行一次
缺點：語句覆蓋不能準(zhǔn)確的判斷運算中的邏輯關(guān)系錯誤。

判定覆蓋：也叫分支覆蓋，設(shè)計測試用例，使得程序中的每個判斷的“真”和假"都至少被執(zhí)行一次。即：程序中的每個分支至執(zhí)行一次。
缺點：判定覆蓋會忽略條件中取或（or)的情況。

條件覆蓋：設(shè)計測試用例，使得判定中的每個條件至少有一次取真值，有一次取假值。
缺點：條件覆蓋并不能保證判定覆蓋。

判定條件覆蓋：滿足100%判定覆蓋和100%條件覆蓋的標(biāo)準(zhǔn)
缺點：會忽略條件中取或（or)的情況。

條件組合覆蓋：設(shè)計測試用例，使得被測試程序中的每個判定中條件結(jié)果的所有可能組合至少執(zhí)行一次。
缺點：條件組合覆蓋不能保證所有路徑被執(zhí)行

路徑覆蓋：設(shè)計測試用例，覆蓋程序中所有可能的路徑
缺點：滿足路徑覆蓋，并不一定能滿足條件覆蓋，也就不能滿足條件組合覆蓋。并且實際過程中的循環(huán)是無法用這個方法的，工作量巨大。

---

設(shè)計用例一般使用基本路徑測試，重點模塊使用多種覆羕率標(biāo)準(zhǔn)

請簡述黑盒測試和白盒測試的優(yōu)缺點

黑盒測試優(yōu)缺點

優(yōu)點
?對測試人員要求不高
?執(zhí)行起來較簡單，不需要了解程序內(nèi)部的代碼及實現(xiàn)
?能夠諞歷說明書中全部的功能；
?可以方便的測試復(fù)雜邏輯的程序功能

缺點：
?不可能進(jìn)行窮舉測試
?不可能進(jìn)行覆蓋所有代碼的測試
?測試的正確率依賴于需求文檔說明書，但是該文檔也是人為編寫的，存在一定的風(fēng)險

白盒測試優(yōu)缺點

優(yōu)點
?迫使測試人員去仔細(xì)思考軟件的實現(xiàn)
?可以檢測代碼中的每條分支和路徑
?揭示隱藏在代碼中的錯誤
?對代碼的測試比較徹底
?讓軟件最優(yōu)化

缺點
?昂貴
?無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤
?不驗證規(guī)格的正確性

----灰盒測試

介于白盒測試與黑盒測試之間的測試。灰盒測試關(guān)注輸出對于輸入的正確性；同時也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不像白盒測試那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運行狀態(tài)。
測試者知道系統(tǒng)組件之間是如何相互作用的，但對組件內(nèi)部程序功能和運作缺乏了解。

灰盒測試的優(yōu)點
①相對于白盒測試，灰盒測試成本低；
②引入了自動化技術(shù)，提高測試效率，規(guī)范測試流程；
③能夠進(jìn)行基于程序路徑的覆蓋測試，保證軟件質(zhì)量。

灰盒測試的缺點
①投入的時間比黑盒測試多20%-40%；
②對測試人員的要求相對較高；
③不適用于簡單的系統(tǒng)，成本高，性價比低。

----自動化測試

概念：讓程序代替人為去驗證程序功能的過程

21偽為什么要進(jìn)行自動化測試？能解決哪些問題？
1.解決-回歸測試
2.解決-壓力測試
3.解決-兼容性測試
4.提高測試效率，保證產(chǎn)品質(zhì)量
回歸測試：項目在發(fā)新版本之后對項目之前的功能進(jìn)行驗證；（并不是所有項目都要回歸測試，但是和金融、火箭相關(guān)的就一定要，因為很精細(xì)）
壓力測試：可以理解多用戶同時去操作軟件，統(tǒng)計軟件服務(wù)器處理多用戶請求的能力
兼容性測試：不同瀏覽器（IE、 Firefox chrome）等等

自動化測試在什么階段開始？
功能測試完畢（手工測試
手工測試：就是由人去一個一個輸入用例，然后觀察結(jié)果；

站在代碼可見度而言
自動化測試所屬分
1.黑盒測試（功能測試）
2.灰盒測試（接口測試）
白盒測試（單元測試）
提示：web自動化測試屬于黑盒測試（功能測試）

優(yōu)點
1.較少的時間內(nèi)運行更多的則試用例
2.自動化腳本可重復(fù)云行；
3.減少人為的錯誤；
4.測試數(shù)據(jù)存儲

缺點
1.不能取代手工測試（比如登錄框本來是要驗證輸入是否有用的，結(jié)果因為界面打不開而自動提交bug了）
2.手工測試比自動化測試發(fā)現(xiàn)的缺陷更多；
3.測試人員技腰要求；
誤區(qū)：
1）.自動化測試完全替代手工測試
2）·自動化測試一定比手工測試厲害
3）.自動化可以發(fā)掘更多的BUG

3.自動化測試分類
1.web-（UI）自動化測試（本階段學(xué)習(xí)）
2.接口-自動化測試
3.移動（app）-自動化測試
4.單元測試-自動化測試

測試工具

接口測試工具： Jmeter, postman, robotframework
性能測試工具： Jmeter, loadrunner
U測試： Selenium

測試用例設(shè)計

添加鏈接描述

開放性問題

為什么需要軟件測試？

1.一款軟件從無到有會經(jīng)歷很多的開發(fā)階段由不同的人來參與開發(fā)，所以最終產(chǎn)出的軟件功能可能會存在問題。因此為了保證軟件的功能是可用的，我們必須要進(jìn)行測試。
2.當(dāng)前的軟件件行業(yè)已經(jīng)不在是功能為王了，用戶不僅僅只盯看軟件的功能是否滿足需求還會對軟件是否容易上手，執(zhí)行效率是否OK……等一系列其它體驗都有了更高的要求，所以這也需要我們對軟件進(jìn)行大量的測試。

測試人員需要的能力？（需要的素質(zhì)？）

硬技能方面，第一計算機(jī)知識，包括操作系統(tǒng)，數(shù)據(jù)庫，通訊協(xié)議原理，熟悉至少一門編程語言；
第二軟件測試知識，包括各種測試?yán)碚?#xff0c;測試方法，測試用例編寫，缺陥跟蹤流程，軟件質(zhì)量評估等；
第三產(chǎn)品業(yè)務(wù)分析能力，熟悉所測產(chǎn)品的一些隱藏需求或者功能

軟技能方面，像溝通能力、做事嚴(yán)謹(jǐn)耐心、富有責(zé)任心、對被測產(chǎn)品具有懷疑與破壞的精神、另外還要善于自我總結(jié)、自我督促。

為什么做測試不做開發(fā)？你怎么看測試？你做測試的優(yōu)點是什么？

因為喜歡測試，我從來不覺得測試不如開發(fā)！
測試的過程又是一個學(xué)習(xí)和思維進(jìn)一步發(fā)散的過程，一直引領(lǐng)人往前探索，很有吸引力。我喜歡玩解謎類的益智游戲，我感覺測試和解謎游戲是一樣的，都有一個從觀察到推演，到嘗試，到歸納再到發(fā)現(xiàn)的一個過程。
我覺得其實測試需要比開發(fā)擁有更加全面的技術(shù)，好的測試不僅要會做測試，還要懂代碼的內(nèi)部實現(xiàn)，還要有產(chǎn)品、業(yè)務(wù)的意識；
測試和開發(fā)是兩個關(guān)注點不一樣的工作。開發(fā)的目標(biāo)是實現(xiàn)功能，測試的目標(biāo)是確定功能是否能夠正常運作。那么它的樂趣在哪里？簡單地說是兩個關(guān)鍵詞：“發(fā)現(xiàn)”和“分析”。
我很喜歡一句話就是：
有的人喜歡創(chuàng)造世界，所以他們做了開發(fā)
有的人喜歡拯救世界，所以他們做了測試

測試和測試開發(fā)的區(qū)別？為什么不做測試開發(fā)？

測試人員不需要有太強(qiáng)的編程技術(shù)，普通應(yīng)用或是代碼段能看懂就行。思考問題時要全面、細(xì)致、有原則，對產(chǎn)品敏感，不能跟著開發(fā)和產(chǎn)品走，這是測試人員的基本要求。 測試開發(fā)人員需要寫測試工具，自動化測試代碼，具備一定的開發(fā)編碼能力，雖然不像開發(fā)那樣深入地掌握一種編碼語言，但對于腳本語言還是要有所掌握，比如：Java、Python

為什么開發(fā)不測還要找人測？

每個公司的的項目都有嚴(yán)格的開發(fā)進(jìn)度，開發(fā)部門忙于實現(xiàn)功能的時候，我想沒幾個產(chǎn)品經(jīng)理會同意頻頻打斷開發(fā)的進(jìn)度要求停下來做bug分析。

而且專人做專事質(zhì)量更加有保障，開發(fā)大多數(shù)的時間都是在思考如何實現(xiàn)具體的軟件功能，怎樣把功能做對，怎樣讓用戶去用這個功能，測試則每天想的是如何提高軟件質(zhì)量，我要向的是每天要以怎樣的奇葩的方式去用這個軟件，而我們想的是用戶怎么把這個功能用錯

舉例，就好像生產(chǎn)電腦，開發(fā)想的是怎么開機(jī)關(guān)機(jī)，測試想的是要是有人把筆記本360度折疊怎么辦

而且從測試力度的角度來說，對于開發(fā)來說，自己寫的東西就是最好的，測起來就不會這么狠，毛病就不會挑的這么多

你發(fā)現(xiàn)的bug，開發(fā)人員不覺得是bug咋辦?

首先確認(rèn)開發(fā)環(huán)境是否跟自己的測試環(huán)境一致，排除因環(huán)境或者業(yè)務(wù)理解不一致而產(chǎn)生的錯誤bug。確認(rèn)是bug后，和開發(fā)保持有效的溝通。重要程度高的bug，去找相關(guān)的需求規(guī)格說明書、概要設(shè)計文檔等，確認(rèn)這個功能是否與文檔不一致，把bug描述清楚，盡量做到無歧義無冗余步驟，bug按照操作步驟可以復(fù)現(xiàn)，難以復(fù)現(xiàn)的截圖下來和開發(fā)進(jìn)行討論。如果開發(fā)還不接受，就找項目經(jīng)理或者產(chǎn)品溝通。
如果這個bug是個重要程度較低的，你可以優(yōu)先測試其他功能，暫時不需要花大量時間去說服開發(fā)修改，有時間再進(jìn)行集中跟進(jìn)。

說一個印象最深的 bug？（項目中遇到什么難題？）

在我負(fù)責(zé)的這個入庫模塊里，有一個入庫數(shù)量的文本框。
我測的時候，發(fā)現(xiàn)它只能接受數(shù)字，不能接受字母，也不能為空。
你按鍵盤下去再松開鍵盤按鈕它會消失剛才輸入的字母。然后我看了它的源碼，開發(fā)寫的是他給這個文本框定義了一個事件onkeyup，他用了一個replace函數(shù)對輸入的字母用正則表達(dá)式替換成了空字符串。
然后如果你在這個框里不輸入數(shù)據(jù)進(jìn)行提交的話它會彈出一個提示讓你輸入，不能為空。
一開始測的時候，不能接受字母和非空測試沒問題。當(dāng)時就覺得說這個文本框通過測試。
到后面系統(tǒng)開發(fā)差不多了，我再復(fù)測一遍。那次我記得我當(dāng)時一直按著一個字母a鍵，想著說看松開能不能通過不能接受字母的測試，后面不小心鼠標(biāo)點到了文本框的外面，那一連串的a被輸入到輸入框里了，沒有消失。我當(dāng)時就很興奮，那我這不是繞過了它的前端檢驗嗎。我就提交，發(fā)現(xiàn)系統(tǒng)報錯了。然后我就去看數(shù)據(jù)庫，看了它的表的結(jié)構(gòu)，它對應(yīng)表的屬性是整型，不能接受字母很正常。然后我覺得說可能是后端沒有校驗，直接接受前端的數(shù)據(jù)傳給數(shù)據(jù)庫導(dǎo)致失敗。
我就突發(fā)奇想，再找一種繞過前端的方式看看是不是后端真的沒有進(jìn)行校驗。我就打開開發(fā)者工具對表單校驗進(jìn)行一個http請求的抓包。在輸入一個有效值提交后，找到它的請求文件里的請求頭，因為它請求的方法是get，請求的參數(shù)明文顯示在url里。我把剛才輸入的值刪掉然后直接在開發(fā)者工具里進(jìn)行重發(fā)，繞過前端頁面，然后看數(shù)據(jù)庫果然保存了一個空值。證明了后端沒有校驗，不然它會給我返回錯誤消息什么的。
這也給了我一個思路，表單提交的時候不僅要測前端，還要測后端
（其實非空驗證直接空值提交然后抓包的時候它不會產(chǎn)生任何請求文件，這也說明了沒有進(jìn)行http請求過程，也就是說這個非空校驗是前端校驗）

對自己的職業(yè)規(guī)劃?

如果有幸入職咱們公司
1年內(nèi)先做好本職工作、積累業(yè)務(wù)知識；
2-3年時間希望能完成公司項目的自動化架構(gòu)，實現(xiàn)自動化測試；
目前我已經(jīng)開始在研究學(xué)習(xí) Python編程及編寫自動化測試腳本；
3-5年的時間，希望能在技術(shù)上面上升到測試開發(fā)，能自己獨立開發(fā)測試平臺及工具，為公司帶來更大價值。

加班的看法？

加班我覺得主要是兩種情況。
第一種，工作效率低不得不通過加班來完成工作任務(wù)，像這種加班我會盡可能提高自己的工作效率，不做無意義的加班。
另外一種，像發(fā)版日、緊急任務(wù)需要加斑這種情況的加班會義不容辭。

如果開發(fā)比較閑，公司只有你一個測試，怎么支配開發(fā)幫忙？

首先，單元測試開發(fā)來做，另外開發(fā)結(jié)束后，進(jìn)行冒煙測試，冒煙覆蓋了一部分測試用例，如果冒煙通過，那很多測試也就解決了。

平時都是怎么學(xué)習(xí)測試的？

看視頻入門，對原理有不懂的地方看書

你平時看什么書？

《軟件測試的藝術(shù) (原書第 3 版) 》
《高性能 MySQL》
《Java編程的邏輯》

如果沒網(wǎng)，可能是什么原因造成的？

一、使用的是有線網(wǎng)線
1、路由器數(shù)據(jù)堵塞，一般重啟路由可以解決；如果重啟仍不能解決，可能是運營商的問題了，及時電話咨詢；
2、自身電腦問題，連接有線網(wǎng)的情況，這種情況很少見；

二、連接的是無線網(wǎng)
1、路由器問題，重啟路由試試；也不排除線路問題；
2、無線接收器問題，看燈閃爍是否正常，可以嘗試拔隊，重新插上；
3、也可以嘗試把無線禁用，然后重新開無線網(wǎng)絡(luò)；
4、重新安裝無線網(wǎng)驅(qū)動試試；

如果輸入一個url,沒有訪問到你預(yù)期的網(wǎng)站,原因可能是什么

(我答的是 1.DNS壞掉了,修改自己的ip為8.8.8.8試試 2.網(wǎng)斷了 3.服務(wù)器拒絕訪問 4.請求/響應(yīng)在網(wǎng)絡(luò)傳輸中途被劫走)

軟件測試問題定位分析

（即不要一有什么事就提bug，像網(wǎng)頁打不開你也提bug，至少你要問題定位分析過后，要提一個具體是什么原因?qū)е碌腷ug）

軟件問題分析的兩個方向（軟件缺陷的方向，并不一定軟件錯誤就說bug，軟件配置方向也是bug）
業(yè)務(wù)方向：用戶需求（顯性+隱形）：使用用戶場景
技術(shù)方向：軟件架構(gòu)（系統(tǒng)設(shè)計+環(huán)境部署）：運用IT技術(shù)

實戰(zhàn)案例分析

問題描述：通過 Windows上的瀏覽器，訪問部署在 Linux系統(tǒng)的Web網(wǎng)站，發(fā)現(xiàn)網(wǎng)站無法訪問？
?實戰(zhàn)操作：該如何分析與定位問題？

步驟：
網(wǎng)絡(luò)（客戶端+服務(wù)端）：先看看瀏覽器端有沒有連上網(wǎng)，能不能打開其他的網(wǎng)站
是否設(shè)置代理（瀏覽器有沒有代理上網(wǎng)）
査看DNS解析正確？（開其他的網(wǎng)站看一下，或是直接打ip上去看看）
網(wǎng)址是否正確，有沒有urI重定向、換其他瀏覽器
數(shù)據(jù)庫
能不能ping通服務(wù)器lP
【以上鑒別完客戶端沒有問題】
web文件是否存在（cd /var/www/html，進(jìn)到文件夾里看看有沒有你的html）
服務(wù)器本機(jī)能不能打開（用服務(wù)端的瀏覽器打開網(wǎng)頁看一下）
看看能不能ping通外面（ping一下百度看一下）
【以上鑒別完基本的服務(wù)端沒有問題】

在這個過程中會不會有東西丟失了？抓個包看一下，可以用tcpdump -v port 80：看大于小于號就行，左邊是客戶端windows，右邊是服務(wù)端linux，看到抓到的消息全都是>號，說明只有win給linux，沒有l(wèi)inux給win，即只有請求，沒有響應(yīng)

現(xiàn)在可說明，是操作系統(tǒng)（進(jìn)階的服務(wù)端）阻礙了數(shù)據(jù)的出去，即防火墻

看看防火墻有沒有運行：service iptables status，把防火墻關(guān)了試一下看看

確定是防火墻問題后不能直接粗暴地關(guān)閉它，因為會有安全問題

你改一下防火墻的規(guī)則即可。但又不能直接在命令行敲，因為服務(wù)器重啟你這條規(guī)則就沒有了。加到防火墻的配置文件里即可

現(xiàn)在你可以提bug了，運維或開發(fā)人員沒有把防火墻設(shè)置好，導(dǎo)致服務(wù)器在外面訪問不了

參考：添加鏈接描述

其他：
錯誤代碼（網(wǎng)頁顯示什么錯誤代碼）
端口號檢査（80號端口）
服務(wù)器日志信息

總結(jié)

以上是生活随笔為你收集整理的面试——测试基础理论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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