1、自我介紹

a. 基本信息：姓名、年齡、學歷信息、求職崗位。
b. 工作信息：由遠及近的介紹公司、崗位，概述工作內容，現在是否在職，考慮離職的原因。
c. 未來規劃：未來的行業和職業傾向，短期及中長期的計劃。對公司和崗位的了解，以及為何對該公司和該崗位感興趣。

您好！我是張三，2019年6月在清華大學取得了計算機信息技術學士學位。此次求職的崗位是軟件測試崗。目前是待業狀態，2019年6月—至今，在上家xxx公司擔任軟件測試崗位，主要負責XXX模塊的測試；單線多次與xxx進行聯系，分析、找到XXXbug問題并解決，推進了公司xxx項目提前XXX天上線（溝通、執行能力）。
我認為軟件測試崗位就是保證軟件在上線前，沒有嚴重的bug，不能夠給公司帶來損失，并且給用戶好的體驗。我對這個崗位的工作內容非常喜歡，希望可以通過努力未來成為這個測試專家，從近期來看,如果有幸被錄用，我希望可以在最短的時間內熟悉工作內容，然后不斷優化自己的工作模式，在1-2年能夠在正常完成工作的情況下，提升自動化方向的能力。在3-5年往測試開發方向發展，更好的完成本職工作，給公司帶來更大的價值。

2、軟件測試流程?

a. 需求分析：需求評審（RPD、產品原型圖） —產品經理和開發經理討論制定需求細節，開發人員和測試人員參與評審
b. 制定測試計劃：產品項目計劃，人員安排、任務安排—測試人員根據開發人員的設計文檔，和開發人員多交流，得知產品的細節功能。包括系統的細節功能、界面原型，這些是寫測試用例的依據。有條件的，甚至應該了解系統內部設計，比如分為一個大的子系統，之間接口，如何通訊。
c. 制定測試方案：測試需求點分析，測試模塊劃分，流程圖分析，制定測試規程
d. 設計測試用例：測試環境、測試步驟、測試數據和預期結果。–原則是盡量以最少的測試用例達到最大測試覆蓋率。
e. 執行測試用例：功能點測試、腳本測試
f. 回歸測試：出階段性測試報告（跟蹤bug修改情況，缺陷修復進度）
g. 驗收測試：出驗收測試報告（完成測試環境測試，提交生產環境進行驗收測試）
h. 產品上線后跟蹤與維護：收集用戶反饋問題

測試報告要點：
① 引言：測試報告編寫目的、報告中出現的專業術語解釋及參考資料等。
②測試概要：介紹項目背景、測試時間、測試地點及測試人員等信息。
③ 測試內容及執行情況：描述本次測試模塊的版本、測試類型，使用的測試用例設計方法及測試通過覆蓋率，依據測試的通過情況提供對測試執行過程的評估結論，并給出測試執行活動的改進建議，以供后續測試執行活動借鑒參考。
④缺陷統計與分析：統計本次測試所發現的缺陷數目、類型等，分析缺陷產生的原因給出規避措施等建議，同時還要記錄殘留缺陷與未解決問題。
⑤ 測試結論與建議：從需求符合度、功能正確性、性能指標等多個維度對版本質量進行總體評價，給出具體明確的結論。
總結：測試報告的數據是真實的，每一條結論的得出都要有評價依據，不能是主觀臆斷的。

3、軟件測試用例設計的方法？

1）白盒測試：邏輯覆蓋、循環覆蓋、基本路徑覆蓋
2）黑盒測試：等價類劃分、邊界值分析法、錯誤猜測法、因果圖法、狀態 圖法、測試大綱法、隨機測試、場景法

4、需求分析的方法？

What：用戶可以用這個產品或功能能做什么？產品或功能為用戶解決什么問題？
Where：用戶在哪里會用這個產品或功能？
Why：用戶為什么用你的產品，而不用別的產品？為什么需要這個功能？和其它產品有什么區別？
When：用戶在什么時候會用這個產品或功能？
Who：誰是我們的用戶群？產品或功能為誰設計？
How：用戶如何使用這個產品或功能？
Value ：產品的價值？

即

了解測試的系統。

這個需求添加之前系統功能是什么樣的？

這個需求是什么作用？

加上這個需求后功能是怎么樣的？

這個需求對系統會產生怎樣的影響？有什么樣的數據？

這個需求對應數據庫哪幾張表和字段？

6、軟件測試工程師的職責：

1、依據需求文檔及設計文檔，編寫測試用例;
2、完成產品的集成測試與系統測試;
3、根據測試計劃，搭建測試環境;
4、依據測試用例執行手工測試，反饋跟蹤產品BUG及用例缺陷;
5、測試工具/系統的研究和應用;

7、什么是軟件質量？

軟件質量：“軟件與明確的和隱含的定義的需求相一致的程度”。
軟件質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發標準、以及所有專業開發的軟件都應具有的隱含特征的程度。影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量。
可劃分為三組，分別反應用戶在使用軟件產品時的三種觀點，正確性、健壯性、效率、完整性、可用性、風險（產品運行）；可理解性、可維修性、靈活性、可測試性（產品修改）；可移植性、可再用性、互運行性（產品轉移）。

8、你在測試中發現了一個bug，但是開發經理認為這不是一個bug， 你應該怎樣解決？

1、將問題提交到缺陷管理庫里面進行備案。
2、要獲取判斷的依據和標準：
根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
3、與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
4、合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。

9、給你一個網站，你如何測試？

首先，查找需求說明、網站設計等相關文檔，分析測試需求。制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試、界面測試、性能測試、數據庫測試、安全性測試、兼容性測試、設計測試用例：功能性測試，可以包括但不限于以下幾個方面：

鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回。

提交功能的測試。

多媒體元素是否可以正確加載和顯示。多語言支持

是否能夠正確顯示選擇的語言等。

界面測試可以包括但不限于以下幾個方面：
a. 頁面是否風格統一，美觀
b. 頁面布局是否合理，重點內容和熱點內容是否突出
c. 控件是否正常使用
d. 對于必須但未安裝的控件，是否提供自動下載并安裝的功能
e. 文字檢查

性能測試一般從以下兩個方面考慮：壓力測試、負載測試、強度測試數據庫測試要具體決定是否需要開展。數據庫一般需要考慮連接性，對 數據的存取操作，數據內容的驗證等方面。

安全性測試：
a. 基本的登錄功能的檢查
b. 是否存在溢出錯誤，導致系統崩潰或者權限泄露
c. 相關開發語言的常見安全性問題檢查，例如SQL注入等
d. 如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外 包測試，或者獲取支持

兼容性測試，根據需求說明的內容，確定支持的平臺組合：
a. 瀏覽器的兼容性；
b. 操作系統的兼容性；
c. 軟件平臺的兼容性；
d. 數據庫的兼容性

開展測試，并記錄缺陷。合理的安排調整測試進度，提前獲取測試所需 的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺 陷報告、人力資源等內容）。定期評審，對測試進行評估和總結，調整測試的內容。

10、軟件的概念和特點？軟件復用的含義？構件包括哪些？

軟件是計算機系統中與硬件相互依存的另一部分，與計算機系統操作有 關的計算機程序、規程、規則，以及可能有的文件、文檔及數據。軟件復用(SoftWare Reuse)是將已有軟件的各種有關知識用于建立新 的軟件，以縮減軟件開發和維護的花費。軟件復用是提高軟件生產力和 質量的一種重要技術。
早期的軟件復用主要是代碼級復用，被復用的知識專指程序，后來擴大到包括領域知識、開發經驗、設計決定、體系結 構、需求、設計、代碼和文檔等一切有關方面。可以被復用的軟件成分一般稱作可復用構件

11、軟件生存周期生命周期階段：

軟件生存周期（Software life cycle）又稱為軟件生命期，生存期。是 指從形成開發軟件概念起，所開發的軟件使用以后，直到失去使用價值 消亡為止的整個過程。一般來說，整個生存周期包括計劃（定義）、開發、運行（維護）三個時期，每個時期又劃分為若干個階段。

a. 軟件計劃與可行性分析
b. 需求分析
c. 軟件設計
d. 編碼
e. 軟件測試
f. 運行與維護

12、軟件測試模型是什么？

軟件生存周期每個階段有明確的任務。
周期模型（典型的幾種）：
1）瀑布模型
2）快速原型模型：快速原型模型允許在需求分析階段對軟件的需求 進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該
原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進 行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對
軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現及測 試、維護。
3）迭代模型：迭代包括產生產品發布（穩定、可執行的產品版本） 的全部開發活動和要使用該發布必需的所有其他外圍元素。在某種程度
上，開發迭代是一次完整地經過所有工作流程的過程：需求分析、設計、 實施和測試工作流程。實質上，它類似小型的瀑布式項目。
RUP認為， 所有的階段都可以細分為迭代。每一次的迭代都會產生一個可以發布的 產品，這個產品是最終產品的一個子集。

13、什么是軟件測試？

軟件測試的目的與原則在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并 對其是否能滿足設計要求進行評估的過程。

軟件測試的目的：

測試是程序的執行過程，目的在于發現錯誤
一個成功的測試用例在于發現至今未發現的錯誤
一個成功的測試是發現了至今未發現的錯誤的測試
確保產品完成了它所承諾或公布的功能，并且用戶可以訪問到的 功能都有明確的書面說明。
確保產品滿足性能和效率的要求
確保產品是健壯的和適應用戶環境的

軟件測試的原則：

a. 測試用例中一個必須部分是對預期輸出或結果進行定義
b. 程序員應避免測試自己編寫的程序
c. 編寫軟件的組織不應當測試自己編寫的軟件
d. 應當徹底檢查每個測試的執行結果
e. 測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況
f. 檢擦程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”
g. 應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件
h. 計劃測試工作時不應默許假定不會發現錯誤
i. 程序某部分存在更多錯誤的可能性，與該部分已經發現錯誤的數量成正比
j.軟件測試是一項極富創造性，極具智力的挑戰性的工作

14、軟件配置管理的作用？軟件配置包括什么？

軟件配置管理（Software Configuration Management，SCM）是一種 標識、組織和控制修改的技術。軟件配置管理應用于整個軟件工程過程。在軟件建立時變更是不可避免的，而變更加劇了項目中軟件開發者之間 的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變更正 確實現并向其他有關人員報告變更。從某種角度講，SCM是一種標識、 組織和控制修改的技術，目的是使錯誤降為最小并最有效地提高生產效 率。軟件配置包括如下內容：配置項識別、工作空間管理、版本控制、變更 控制、狀態報告、配置審計。

15、BUG的八要素：

缺陷編號：缺陷的唯一標識符
缺陷狀態：缺陷跟蹤過程的進展情況
缺陷標題：缺陷的概述，描述問題的本質
重現步驟：一步一步描述再現缺陷的操作步驟
嚴重程度：缺陷對軟件系統的影響程度
優先級：修復缺陷的重要性或緊迫性
缺陷類型：根據缺陷產生的來源和根據劃分出的種類
測試環境：測試環境配置,包括操作系統和瀏覽器

16、BUG的生命周期

提交bug—分配bug—處理bug—驗證bug—關閉bug
新建，確認，解決，重新驗證，關閉，重新打開

17、數據庫知識（若有筆試一定會考）

1、在工作中一般用數據庫驗證什么
2、多表查詢多不多，左右連接代表什么意思；
3、存儲過程是否了解，簡單說下存儲過程的語法；

18、Linux+部署

linux基本命令，考察了解哪些方面的命令，文件操作、部署相關、權限、查看性能；

19、項目情況+測試基礎知識

1、設計用例的方法（面試官會讓你舉例說明），測試方案包含哪些內容bug如何跟蹤，如何進行bug分析
2、每個版本是否有遺留bug，如何解決？bug如何管理？
3、開發不改的bug怎么辦？如何定位bug？任務如何分配，工作量怎么評估
4、軟件測試方法有哪些
5、接口測試關注哪些
6、UI測試關注點
7、公司系統有多少個接口
8、項目組成員有多少（了解開發與測試比例，看能否承擔起入職后項目工作）

20、c/s與b/s架構

A端是開發界面。即管理員所接觸的界面。
B端是商家界面。即瀏覽器界面，依托于web界面–企業端用戶。
C端是用戶界面。即app的界面，用戶所接觸最為廣泛的界面。
B端客戶：B2B（Business-to-Business)中的企業之間的網絡營銷！
C端客戶：C代表consumer （消費者），所以C端用戶指的是消費者，即產品的最終使用者。

我的另一個博客總結：https://blog.csdn.net/Y1730008223CONG/article/details/125146275?spm=1001.2014.3001.5501

21、什么是測試用例？什么是測試腳本？兩者關系？

1> 測試用例：為實現測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的合集
2> 測試腳本：為了進行自動化測試而編寫的腳本

關系：測試腳本的編寫必須對應相應的測試用例

22、簡述靜態測試、動態測試、黑盒測試、白盒測試、α測試 、β測試

1、靜態測試：不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程
2、動態測試：實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢測程序的正確性、可靠性、有效性、并分析系統運行效率和健壯性等性能
3、黑盒測試：一般用來確認軟件功能的正確性和可操作性，目的是檢測軟件的各個功能是否得以實現，把北側程序當作一個黑盒，不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性
4、白盒測試：根據軟件內部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。
5、α測試:由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由程序員或測試員完成
6、 β測試: 軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試，開發者通常不在測試現場，Beta測試不能由程序員或測試員完成

23、軟件測試分為幾個階段，各階段的測試策略和要求是什么？

測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段：

1、單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發人員進行。
2、集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由于在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。
3、系統測試：系統測試是在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。
4、驗收測試：驗收測試以需求階段的《需求規格說明書》為驗收標準，測試時要求模擬實際用戶的運行環境。對于實際項目可以和客戶共同進行，對于產品來說就是最后一次的系統測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。

單元測試測試策略：

自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。

孤立單元測試策略：最好的單元測試策略。

集成測試的測試策略：

大爆炸集成：適應于一個維護型項目或被測試系統較小

自頂向下集成：適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。

自底向上集成：適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

基于進度的集成
優點：具有較高的并行度；能夠有效縮短項目的開發進度。
缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。

系統測試的測試策略：

數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試

24、黑盒測試和白盒測試各自的優點和缺點！

黑盒測試

優點：比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。

缺點：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；自動化測試的復用性較低。

白盒測試

優點：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。

缺點：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

25、測試人員在軟件開發過程中的任務是什么？

1、盡可能早的找出系統中的Bug；
2、避免軟件開發過程中缺陷的出現；
3、衡量軟件的品質，保證系統的質量；
4、關注用戶的需求，并保證系統符合用戶需求。
總的目標是：確保軟件的質量。

26、在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

bug編號；
bug嚴重級別，優先級；
bug產生的模塊；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄像…等等；
bug出現時的測試環境，產生的條件即對應操作步驟；

高質量的Bug記錄：

通用UI要統一、準確
缺陷報告的UI要與測試的軟件UI保持一致，便于查找定位。

盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。

每條缺陷報告只包括一個缺陷
每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。

不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之后仍不能重現，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率。

明確指明缺陷類型
根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬于其中某種形式。

明確指明缺陷嚴重等級和優先等級
時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先級。

描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
描述要準確反映缺陷的本質內容，簡短明了。為了便于在軟件缺陷管理數據庫中尋找制定的測試缺陷，包含缺陷發生時的用戶界面（UI）是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控件的名稱。

短行之間使用自動數字序號，使用相同的字體、字號、行間距
短行之間使用自動數字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規范專業。

每一個步驟盡量只記錄一個操作
保證簡潔、條理井然，容易重復操作步驟。

確認步驟完整，準確，簡短
保證快速準確的重復缺陷，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多余的步驟。

根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全屏幕，活動窗口和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
? 附加必要的特殊文檔和個人建議和注解
如果打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或注解。

檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。

盡量使用短語和短句，避免復雜句型句式
軟件缺陷管理數據庫的目的是便于定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復雜的句型，增強可讀性。
以上概括了報告測試缺陷的規范要求，隨著軟件的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。

缺陷描述內容
缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什么，期望結果可以讓開發了解正確的結果應該是如何。

27、測試計劃工作的目的是什么？測試計劃文檔的內容應該包括什么？其中哪些是最重要的？

軟件測試計劃是指導測試過程的綱領性文件：

領導能夠根據測試計劃進行宏觀調控，進行相應資源配置等
測試人員能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等
便于其他人員了解測試人員的工作內容，進行有關配合工作
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

測試計劃編寫6要素（5W1H）：

why——為什么要進行這些測試；
what—測試哪些方面，不同階段的工作內容；
when—測試不同階段的起止時間；
where—相應文檔，缺陷的存放位置，測試環境等；
who—項目有關人員組成，安排哪些測試人員進行測試；
how—如何去做，使用哪些測試工具以及測試方法進行測試

測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。

28、詳細的描述一個測試活動完整的過程

（以瀑布模型為例）

項目經理通過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。然后SQA進入項目，開始進行統計和跟蹤

開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內容上面有描述。

測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。

測試用例完成后，測試和開發需要進行評審。

測試人員搭建環境

開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現BUG后提交給BugZilla。

開發提交第二個版本，包括Bug Fix以及增加了部分功能，測試人員進行測試。

重復上面的工作，一般是3-4個版本后BUG數量減少，達到出貨的要求。

如果有客戶反饋的問題，需要測試人員協助重現并重新測試。

總結

以上是生活随笔為你收集整理的软件测试面试常见问题（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

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