面試——測試基礎理論

測試先導性知識

測試是什麼？

在規定的條件下對程序進行操作去發現錯誤，然後對軟件質量進行評估的一個過程。

需要注意的是，軟件是由文檔、數據以及程序組成的，所以對軟件測試應該包括：軟件形成過程的文檔、數據以及程序，而不僅僅是對程序進行的測試。

測試的目的、作用

通過測試工作發現並修復軟件當中潛在的各種錯誤和缺陷，提高軟件質量，進而提高用戶對產品的使用信心，避免軟件發佈後由於潛在的軟件缺陷和錯誤造成的隱患所帶來的商業風險。

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

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

測試的原則

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

缺陷存在羣集現象：對於軟件功能說，核心功能佔20%，非核心是80%。在實際工作中我們會集中測試20%的核心功能，所以這個部分發現缺陷的機率就會高於80%。因此我們就會遇到缺陷都集中在20%功能模塊裏的現象。

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

測試應儘早介入：爲了更多的發現和更好的解決軟件中的缺陷，我們追求測試工作儘早的開展

殺蟲劑現象：同樣的一個測試用例不能重的執行多次，因爲軟件會對它產生免疫（ 開發會根據你 的用例去修改，你再測同樣的用例肯定能過關的或是被開發矇混過關）

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

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

1.需求分析階段：各種需求規格說明書
2.軟件架構設計：API接口文檔（接口測試）
3.編碼實現階段：源代碼（白盒測試、單元測試）
4.系統功能使用：軟件功能主體（當前行業做的最多的一種測試）

測試計劃工作的關鍵是什麼？

明確測試的目標，增強測試計劃的實用性，明確內容與過程
採用評審和更新機制，保證測試計劃滿足實際需求
需要分別創建測試計劃與測試詳細規格、測試用例

測試基礎理論

軟件測試模型有哪些？

瀑布流

項目計劃—>需求分析—>軟件設計—>編碼—>測試—>運行維護

優點：
軟件開發的各項活動嚴格按照線性方式進行
前一階段完成後，只需關注後續階段

缺點：
難以適應需求的頻繁變化
早期的錯誤可能要等到開發後期的階段才能發現

V模型

W模型

還有X模型、H模型

軟件的生命週期（軟件開發的流程）

需求分析
軟件設計（概要設計、詳細設計）
軟件編碼
軟件測試（單元測試、集成測試、系統測試、驗證測試）
運行維護

詳細介紹

軟件產品質量特性是什麼？

功能性、可靠性、效率、易用性、可維護、可移植

功能性

定義:軟件在指定的使用環境下,滿足用戶顯性或隱性需求的能力
適合性:軟件爲指定的任務和用戶目標提供一組合適功能的能力
準確性:軟件提供具有所需精確度的正確或相符的結果或效果的能力
互操作性:軟件與一個或更多個的規定系統進行交互的能力

可靠性

定義:軟件在指定的條件下使用,維持規定的性能級別的能力
成熟性:軟件爲避免由軟件中錯誤而導致失控的能力,
容錯性:在軟件出現故障或違反指定接口的情況下,軟件維持規定性能級別的能力,
易恢復性:在失效發生的情況下軟件裏重建規定的件能級別並恢復受直接影響的數據的能力
可靠性依從性:軟件遵循與可靠件相關的標準,約定以及法律法規的能力

效率

定義:在規定的條件下,相對於所用資源的數量,軟件提供適當性能的能力
時間特性:在規定的條件下軟件執行其功能時,提供適當的響應和處理時間以及吞吐率的能力
資源利用性:在規定的條件下軟件執行其能力時,使用合適的資源數量和類別的能力
效率依從件:軟件遵循與效率相關的標準和約定的能力

易用性

定義:在指定的條件下使用時,軟件被學習,理解,使用和吸引用戶的能力
易理解性:軟件的使用，用戶能理解軟件是否合適,以及如何將軟件用於特定的任務和使用環境的能力
易學習:軟件使用戶能學習其應用的能力易操作性:軟件使用用戶操作和控制它的能力
吸引性:軟件吸引用戶的能力
易用性依從性:遭循與易用性相關的標準、約定風格指南或法規的能力

可維護

定義:軟件可被修改的能力,修改可能包括修正、改進或軟件對環境、需求和功能規格說明變化的適應性
易分析性:軟件診斷軟件的缺陷,失效原因或識別待修改部分的能力,
易改變性:軟件指定的修改可以被實現的能力
穩定性:軟件避免由於軟件修改而造成意外結果的能力,
易測試性:軟件使已修改軟件能被確認的能力
可維護依從性:遵循與維護相關標準和約定的能力,

可移植

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

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

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

Bug嚴重程度（Bug級別定義）

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

Bug的生命週期

添加鏈接描述

Bug狀態的處理（處理一個缺陷的流程）

請描述你對測試的瞭解

內容可以涉及測試流程，測試分類，測試方法，測試工具

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

需求分析，梳理清楚我們需要設計的點是什麼
編寫測試計劃，做什麼類型的測試，需要什麼樣的工具
編寫測試用例，用例是爲了測試軟件的某個功能而執行的操作過程
評審用例，對當前的用例進行添加或者刪除
配置環境
執行用例，執行用例前先做冒煙測試，通過纔開始正式測試
迴歸測試，缺陷被開發修復後進行復測
缺陷跟蹤
輸出測試報告，方便其它人去查看
測試結束，將整個測試過程產生的文檔進行整理歸檔，方便後續版本使用。

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

測試分類

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

1.單元測試[ UT unit test]（白盒）：在軟件測試中單元指的就是組成軟件最小的底層代碼結構一般就是類、函數、組件（當下的軟件測試行業，不會刻意要求測試人員對源代碼進行測試）

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

3系統測試（ ST system test）（黑盒）這是當前行業做的最多的一種測試。由測試人員充當用戶然後對軟件的功能主體進行測試

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

--------系統測試分類

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

--------常見的系統測試方法

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

----靜態測試和動態測試

白盒測試、黑盒測試、灰盒測試，在實現測試方法上既包括了動態測試，也包括了靜態測試。

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

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

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

測試方法

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

----黑盒測試（測試用例設計方法）（測試用例是怎麼設計的）

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

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

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

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

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

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

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

場景法：
模擬用戶操作軟件時的場景，主要用於測試系統的業務流程
當業務流程測試沒有問題，也就是該軟件的主要功能沒有問題時，我們再重點從邊界值、等價類等方面對控件進行測試
冒煙測試時也主要採用場景法進行測試
使用：
產品經理提供的業務需求就當成場景法的測試用例去測就行了，結果不一樣的話提bug就可以了

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

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

--------功能測試和性能測試的區別是什麼？

1）測試目的：

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

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

2）測試方式：

功能測試按照系用例，按照系統需求說明書和測試用例，對產品的功能一步步進行測試。找出產品功能是否全部實現

性能測試：一般都使用性能工具對產品的健壯性進行評估。通過創建場景和虛擬用戶模擬真實環境，進行壓力測試和負載測試。

--------負載測試和壓力測試？

性能測試包括壓力測試和負載測試，測試的是不同負載條件下系統的各項性能指標，如吞吐量、響應時間、點擊率等。

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

壓力測試可以被看作是負載測試的一種，即高負載下的負載測試。查看應用系統在峯值使用情況下操作行爲，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分爲高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。

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

負載測試是通過改變系統負載方式、增加負載等來發現系統中所存在的性能問題。負載測試是一種測試方法，可以爲性能測試、壓力測試所採用。負載測試的加載方式也有很多種，可以根據測試需要來選擇。
性能測試是爲獲取或驗證系統性能指標而進行測試。多數情況下，性能測試會在不同負載情況下進行。
壓力測試通常是在高負載情況下來對系統的穩定性進行測試，更有效地發現系統穩定性的隱患和系統在負載峯值的條件下功能隱患等。

----白盒測試

黑盒主要是根據業務需求來設計的輸入，白盒則根據系統的內部實現設計的輸入，它的主要目標是覆蓋更多的代碼

只適用於單元測試階段

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

測試設計方法：

靜態：測試過程中不執行程序，即不執行代碼進行測試

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

• 自動化方法：
  自動化工具，進行代碼的掃描

動態：執行代碼進行測試

方法有：
邏輯覆蓋法：是通過對程序邏輯結構的遍歷實現程序約覆蓋。
基本路徑測試法：在程序控制流圖的基礎上，通過分析程序的環路複雜性，導出基本可執行路徑集合，從而設計測試用例

---

邏輯覆蓋法具體有：

語句覆蓋：設計瀏試用例，使得程序中每條語句至少被執行一次
缺點：語句覆蓋不能準確的判斷運算中的邏輯關係錯誤。

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

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

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

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

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

---

設計用例一般使用基本路徑測試，重點模塊使用多種覆羕率標準

請簡述黑盒測試和白盒測試的優缺點

黑盒測試優缺點

優點
・對測試人員要求不高
・執行起來較簡單，不需要了解程序內部的代碼及實現
・能夠諞歷說明書中全部的功能；
・可以方便的測試複雜邏輯的程序功能

缺點：
・不可能進行窮舉測試
・不可能進行覆蓋所有代碼的測試
・測試的正確率依賴於需求文檔說明書，但是該文檔也是人爲編寫的，存在一定的風險

白盒測試優缺點

優點
・迫使測試人員去仔細思考軟件的實現
・可以檢測代碼中的每條分支和路徑
・揭示隱藏在代碼中的錯誤
・對代碼的測試比較徹底
・讓軟件最優化

缺點
・昂貴
・無法檢測代碼中遺漏的路徑和數據敏感性錯誤
・不驗證規格的正確性

----灰盒測試

介於白盒測試與黑盒測試之間的測試。灰盒測試關注輸出對於輸入的正確性；同時也關注內部表現，但這種關注不像白盒測試那樣詳細、完整，只是通過一些表徵性的現象、事件、標誌來判斷內部的運行狀態。
測試者知道系統組件之間是如何相互作用的，但對組件內部程序功能和運作缺乏瞭解。

灰盒測試的優點
①相對於白盒測試，灰盒測試成本低；
②引入了自動化技術，提高測試效率，規範測試流程；
③能夠進行基於程序路徑的覆蓋測試，保證軟件質量。

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

----自動化測試

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

21僞爲什麼要進行自動化測試？能解決哪些問題？
1.解決-迴歸測試
2.解決-壓力測試
3.解決-兼容性測試
4.提高測試效率，保證產品質量
迴歸測試：項目在發新版本之後對項目之前的功能進行驗證；（並不是所有項目都要回歸測試，但是和金融、火箭相關的就一定要，因爲很精細）
壓力測試：可以理解多用戶同時去操作軟件，統計軟件服務器處理多用戶請求的能力
兼容性測試：不同瀏覽器（IE、 Firefox chrome）等等

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

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

優點
1.較少的時間內運行更多的則試用例
2.自動化腳本可重複雲行；
3.減少人爲的錯誤；
4.測試數據存儲

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

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

測試工具

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

測試用例設計

添加鏈接描述

開放性問題

爲什麼需要軟件測試？

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

測試人員需要的能力？（需要的素質？）

硬技能方面，第一計算機知識，包括操作系統，數據庫，通訊協議原理，熟悉至少一門編程語言；
第二軟件測試知識，包括各種測試理論，測試方法，測試用例編寫，缺陥跟蹤流程，軟件質量評估等；
第三產品業務分析能力，熟悉所測產品的一些隱藏需求或者功能

軟技能方面，像溝通能力、做事嚴謹耐心、富有責任心、對被測產品具有懷疑與破壞的精神、另外還要善於自我總結、自我督促。

爲什麼做測試不做開發？你怎麼看測試？你做測試的優點是什麼？

因爲喜歡測試，我從來不覺得測試不如開發！
測試的過程又是一個學習和思維進一步發散的過程，一直引領人往前探索，很有吸引力。我喜歡玩解謎類的益智遊戲，我感覺測試和解謎遊戲是一樣的，都有一個從觀察到推演，到嘗試，到歸納再到發現的一個過程。
我覺得其實測試需要比開發擁有更加全面的技術，好的測試不僅要會做測試，還要懂代碼的內部實現，還要有產品、業務的意識；
測試和開發是兩個關注點不一樣的工作。開發的目標是實現功能，測試的目標是確定功能是否能夠正常運作。那麼它的樂趣在哪裏？簡單地說是兩個關鍵詞：“發現”和“分析”。
我很喜歡一句話就是：
有的人喜歡創造世界，所以他們做了開發
有的人喜歡拯救世界，所以他們做了測試

測試和測試開發的區別？爲什麼不做測試開發？

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

爲什麼開發不測還要找人測？

每個公司的的項目都有嚴格的開發進度，開發部門忙於實現功能的時候，我想沒幾個產品經理會同意頻頻打斷開發的進度要求停下來做bug分析。

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

舉例，就好像生產電腦，開發想的是怎麼開機關機，測試想的是要是有人把筆記本360度摺疊怎麼辦

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

你發現的bug，開發人員不覺得是bug咋辦?

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

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

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

對自己的職業規劃?

如果有幸入職咱們公司
1年內先做好本職工作、積累業務知識；
2-3年時間希望能完成公司項目的自動化架構，實現自動化測試；
目前我已經開始在研究學習 Python編程及編寫自動化測試腳本；
3-5年的時間，希望能在技術上面上升到測試開發，能自己獨立開發測試平臺及工具，爲公司帶來更大價值。

加班的看法？

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

如果開發比較閒，公司只有你一個測試，怎麼支配開發幫忙？

首先，單元測試開發來做，另外開發結束後，進行冒煙測試，冒煙覆蓋了一部分測試用例，如果冒煙通過，那很多測試也就解決了。

平時都是怎麼學習測試的？

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

你平時看什麼書？

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

如果沒網，可能是什麼原因造成的？

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

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

如果輸入一個url,沒有訪問到你預期的網站,原因可能是什麼

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

軟件測試問題定位分析

（即不要一有什麼事就提bug，像網頁打不開你也提bug，至少你要問題定位分析過後，要提一個具體是什麼原因導致的bug）

軟件問題分析的兩個方向（軟件缺陷的方向，並不一定軟件錯誤就說bug，軟件配置方向也是bug）
業務方向：用戶需求（顯性+隱形）：使用用戶場景
技術方向：軟件架構（系統設計+環境部署）：運用IT技術

實戰案例分析

問題描述：通過 Windows上的瀏覽器，訪問部署在 Linux系統的Web網站，發現網站無法訪問？
・實戰操作：該如何分析與定位問題？

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

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

現在可說明，是操作系統（進階的服務端）阻礙了數據的出去，即防火牆

看看防火牆有沒有運行：service iptables status，把防火牆關了試一下看看

確定是防火牆問題後不能直接粗暴地關閉它，因爲會有安全問題

你改一下防火牆的規則即可。但又不能直接在命令行敲，因爲服務器重啓你這條規則就沒有了。加到防火牆的配置文件裏即可

現在你可以提bug了，運維或開發人員沒有把防火牆設置好，導致服務器在外面訪問不了

參考：添加鏈接描述

其他：
錯誤代碼（網頁顯示什麼錯誤代碼）
端口號檢査（80號端口）
服務器日誌信息