Part1

1、你的測試職業(yè)發(fā)展是什么？【文末有面試文檔免費領(lǐng)取】

測試經(jīng)驗越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時間積累的，一步步向著高級測試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前3年積累測試經(jīng)驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務(wù)。

優(yōu)勢在于我對測試堅定不移的信心和熱情，雖然經(jīng)驗還不夠，但測試需要的基本技能我有信心在工作中得以發(fā)揮。

2、你認為測試人員需要具備哪些素質(zhì)

做測試應(yīng)該要有一定的協(xié)調(diào)能力，因為測試人員經(jīng)常要與開發(fā)接觸處理一些問題，如果處理不好的話會引起一些沖突，這樣的話工作上就會不好做。還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。除了耐心，測試人員不能放過每一個可能的錯誤。

3、你為什么能夠做測試這一行

雖然我的測試技術(shù)還不是很成熟，但是我覺得我還是可以勝任軟件測試這個工作的，因為做軟件測試不僅是要求技術(shù)好，還有有一定的溝通能力，耐心、細心等外在因素。綜合起來看我認為我是勝任這個工作的。

4、測試的目的是什么？

測試的目的是找出軟件產(chǎn)品中的錯誤，是軟件盡可能的符合用戶的要求。當然軟件測試是不可能找出全部錯誤的。

5、測試分為哪幾個階段？

一般來說分為5個階段：單元測試、集成測試、確認測試、系統(tǒng)測試、驗收測試

6、單元測試的測試對象、目的、測試依據(jù)、測試方法？

測試對象是模塊內(nèi)部的程序錯誤，目的是消除局部模塊邏輯和功能上的錯誤和缺陷。測試依據(jù)是模塊的詳細設(shè)計，測試方法是采用白盒測試。

7、怎樣看待加班問題

加班的話我沒有太多意見，但是我還是覺得如果能夠合理安排時間的話，不會有太多時候加班的。

8、結(jié)合你以前的學習和工作經(jīng)驗，你認為如何做好測試。

根據(jù)我以前的工作和學習經(jīng)驗，我認為做好工作首先要有一個良好的溝通，只有溝通無障礙了，才會有好的協(xié)作，才會有更好的效率，再一個就是技術(shù)一定要過關(guān)，做測試要有足夠的耐心，和一個良好的工作習慣，不懂的就要問，實時與同事溝通這樣的話才能做好測試工作。

9、你為什么選擇軟件測試行業(yè)

因為之前了解軟件測試這個行業(yè)，覺得他的發(fā)展前景很好。

10、根據(jù)你以前的工作或?qū)W習經(jīng)驗描述一下軟件開發(fā)、測試過程，由哪些角色負責，你做什么

要有架構(gòu)師、開發(fā)經(jīng)理、測試經(jīng)理、程序員、測試員。我在里面主要是負責所分到的模塊執(zhí)行測試用例。

11、根據(jù)你的經(jīng)驗說說你對軟件測試/質(zhì)量保證的理解

軟件質(zhì)量保證與測試是根據(jù)軟件開發(fā)階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計的一批測試用例(即輸入數(shù)據(jù)和預期的輸出結(jié)果)，并根據(jù)這些測試用例去運行程序，以發(fā)現(xiàn)錯誤的過程。它是對應(yīng)用程序的各個方面進行測試以檢查其功能、語言有效性及其外觀排布。

12、軟件測試的流程是什么？

需求調(diào)查：全面了解系統(tǒng)概況、應(yīng)用領(lǐng)域、軟件開發(fā)周期、軟件開發(fā)環(huán)境、開發(fā)組織、時間安排、功能需求、性能需求、質(zhì)量需求及測試要求等。根據(jù)系統(tǒng)概況進行項目所需的人員、時間和工作量估計以及項目報價。

制定初步的項目計劃。

測試準備：組織測試團隊、培訓、建立測試和管理環(huán)境等。

測試設(shè)計：按照測試要求進行每個測試項的測試設(shè)計，包括測試用例的設(shè)計和測試腳本的開發(fā)等。

測試實施：按照測試計劃實施測試。

測試評估：根據(jù)測試的結(jié)果，出具測試評估報告。

13、你對SQA的職責和工作活動(如軟件度量)的理解?

SQA就是獨立于軟件開發(fā)的項目組，通過對軟件開發(fā)過程的監(jiān)控，來保證軟件的開發(fā)流程按照指定的CMM規(guī)程(如果有相應(yīng)的CMM規(guī)程),對于不符合項及時提出建議和改進方案，必要時可以向高層經(jīng)理匯報以求問題的解決。通過這樣的途徑來預防缺陷的引入，從而減少后期軟件的維護成本。SQA主要的工作活動包括制定SQA工作計劃，參與階段產(chǎn)物的評審，進行過程質(zhì)量、功能配置及物理配置的審計等；對項目開發(fā)過程中產(chǎn)生的數(shù)據(jù)進行度量等等。

14、說說你對軟件配置管理的理解

項目在開發(fā)過程中要用相應(yīng)的配置管理工具對配置項(包括各個階段的產(chǎn)物)進行變更控制，配置管理的使用取決于項目規(guī)模和復雜性及風險的水平。軟件的規(guī)模越大，配置管理就越顯得重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標準，隨后的工作便基于此標準，并只有經(jīng)過授權(quán)后才能變更這個標準。配置管理工具主要有CC，VSS,CVS,SVN等。

15、怎樣寫測試計劃和測試用例

簡單點，測試計劃里應(yīng)有詳細的測試策略和測試方法，合理詳盡的資源安排等，至于測試用例，那是依賴于需求(包括功能與非功能需求)是否細化到功能點，是否可測試等。

16、什么是兼容性測試？兼容性測試側(cè)重哪些方面？

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行，即是通常說的軟件的可移植性。

兼容的類型，如果細分的話，有平臺的兼容，網(wǎng)絡(luò)兼容，數(shù)據(jù)庫兼容，以及數(shù)據(jù)格式的兼容。

兼容測試的重點是，對兼容環(huán)境的分析。通常，是在運行軟件的環(huán)境不是很確定的情況下，才需要做兼容。根據(jù)軟件運行的需要，或者根據(jù)需求文檔，一般都能夠得出用戶會在什么環(huán)境下使用該軟件，把這些環(huán)境整理成表單，就得出做兼容測試的兼容環(huán)境了。

兼容和配置測試的區(qū)別在于，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環(huán)境下做的。

17、我現(xiàn)在有個程序，發(fā)現(xiàn)在Windows上運行得很慢，怎么判別是程序存在問題還是軟硬件系統(tǒng)存在問題？

1、檢查系統(tǒng)是否有中毒的特征；

2、檢查軟件/硬件的配置是否符合軟件的推薦標準；

3、確認當前的系統(tǒng)是否是獨立，即沒有對外提供什么消耗CPU資源的服務(wù)；

4、如果是C/S或者B/S結(jié)構(gòu)的軟件，需要檢查是不是因為與服務(wù)器的連接有問題，或者訪問有問題造成的；

5、在系統(tǒng)沒有任何負載的情況下，查看性能監(jiān)視器，確認應(yīng)用程序?qū)PU/內(nèi)存的訪問情況。

18、測試的策略有哪些？

黑盒/白盒，靜態(tài)/動態(tài)## 標題，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）

19、你覺得bugzilla在使用的過程中，有什么問題？

1、界面不穩(wěn)定；

2、根據(jù)需要配置它的不同的部分，過程很煩瑣。

3、流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；

4、沒有綜合的評分指標，不好確認修復的優(yōu)先級別。

20、描述測試用例設(shè)計的完整過程？

1、需求分析 + 需求變更的維護工作；

2、根據(jù)需求得出測試需求；

3、設(shè)計測試方案，評審測試方案；

4、方案評審通過后，設(shè)計測試用例，再對測試用例進行評審；

21、單元測試的策略有哪些？

邏輯覆蓋、循環(huán)覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數(shù)據(jù)流分析

22、LoadRunner分哪三部分？

用戶動作設(shè)計；場景設(shè)計； 測試數(shù)據(jù)分析；

23、LoadRunner進行測試的流程?

1、 熟悉業(yè)務(wù)流程，測試規(guī)劃

2、 創(chuàng)建虛擬用戶腳本

3、 創(chuàng)建運行場景

4、 運行測試腳本

5、 監(jiān)視場景

6、 分析測試的結(jié)果

以上，最好是結(jié)合一個案例，根據(jù)以上流程來介紹。

24、軟件的評審一般由哪些人參加？其目的是什么？

在正式的會議上將軟件項目的成果（包括各階段的文檔、產(chǎn)生的代碼等）提交給用戶、客戶或有關(guān)部門人員對軟件產(chǎn)品進行評審和批準。其目的是找出可能影響軟件產(chǎn)品質(zhì)量、開發(fā)過程、維護工作的適用性和環(huán)境方面的設(shè)計缺陷，并采取補救措施，以及找出在性能、安全性和經(jīng)濟方面的可能的改進。

人員：用戶、客戶或有關(guān)部門開發(fā)人員，測試人員，需求分析師都可以，就看處于評審那個階段

25、Beta測試與Alpha測試有什么區(qū)別？

–Beta testing(β測試),測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。開發(fā)者通常不在測試現(xiàn)場

–Alpha testing (α測試),是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的受控測試

26、你認為做好測試計劃工作的關(guān)鍵是什么？

軟件測試計劃就是在軟件測試工作正式實施之前明確測試的對象，并且通過對資源、時間、風險、測試范圍和預算等方面的綜合分析和規(guī)劃，保證有效的實施軟件測試；

做好測試計劃工作的關(guān)鍵 ：目的，管理，規(guī)范

（1）、明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準確

（2）、堅持“5W”規(guī)則，明確內(nèi)容與過程“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。

（3）、采用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內(nèi)容的可能不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導測試執(zhí)行人員。

（4）、分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例應(yīng)把詳細的測試技術(shù)指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。

27、你認為做好測試用例工作的關(guān)鍵是什么？

需求和設(shè)計文檔的理解程度，對系統(tǒng)的熟悉程度

28、簡述一下缺陷的生命周期？

提交->確認->分配->修復->驗證->關(guān)閉

29、軟件的安全性應(yīng)從哪幾個方面去測試？

(1) 用戶認證機制：如數(shù)據(jù)證書、智能卡、雙重認證、安全電子交易協(xié)議

(2) 加密機制

(3) 安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描

(4) 數(shù)據(jù)備份與恢復手段：存儲設(shè)備、存儲優(yōu)化、存儲保護、存儲管理

(5) 防病毒系統(tǒng)

30、你覺得軟件測試通過的標準應(yīng)該是什么樣的？

缺陷密度值達到客戶的要求

31、一套完整的測試應(yīng)該由哪些階段組成？

需求評審（有開發(fā)人員，產(chǎn)品經(jīng)理，測試人員，項目經(jīng)理）－>需求確定(出一份確定的需求文檔)－>開發(fā)設(shè)計文檔（開發(fā)人員在開始寫代碼前就能輸出設(shè)計文檔）－>想好測試策略，寫出測試用例－>發(fā)給開發(fā)人員和測試經(jīng)理看看（非正式的評審用例）－>接到測試版本－>執(zhí)行測試用例（中間可能會補充用例）－>提交bug（有些bug需要開發(fā)人員的確定（嚴重級別的，或突然發(fā)現(xiàn)的在測試用例范圍之外的，難以重現(xiàn)的），有些可以直接錄制進TD）－>開發(fā)人員修改（可以在測試過程中快速的修改）－>回歸測試（可能又會發(fā)現(xiàn)新問題，再按流程開始跑）

32、如何理解壓力、負載、性能測試測試？

性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內(nèi)容。

壓力測試是對服務(wù)器的穩(wěn)定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統(tǒng)的用戶數(shù)量、或者幾個用戶進行大數(shù)據(jù)量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統(tǒng)在一種或者集中極限條件下的相應(yīng)能力，是性能測試的重要部分。100個用戶對系統(tǒng)進行連續(xù)半個小時的訪問可以看作壓力測試，那么連續(xù)訪問8個小時就可以認為負載測試，1000個用戶連續(xù)訪問系統(tǒng)1個小時也可以看作是負載測試。

實際上壓力測試和負載測試沒有明顯的區(qū)分。測試人員應(yīng)該站在關(guān)注整體性能的高度上來對系統(tǒng)進行測試。

33、如何編寫提交給用戶的測試報告？

----根據(jù)內(nèi)部測試報告進行編寫，一般可以摘錄；

----不可以向客戶報告嚴重缺陷，即使是已經(jīng)修改的缺陷，開發(fā)中的缺陷也沒有必要讓客戶知道；

----報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的； -報告上面的內(nèi)容盡量要真實可靠；

----整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。

34、您所熟悉的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應(yīng)用。

1 ．等價類劃分

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

2．邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤.

使用邊界值分析方法設(shè)計測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).

3．錯誤推測法

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

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

4．因果圖方法

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

35、你對測試最大的興趣在哪里？為什么？

最大的興趣就是測試有難度，有挑戰(zhàn)性！做測試越久越能感覺到做好測試有多難。做測試，有部分是和人的性格有關(guān)，有部分需要后天的努力。但除了性格有關(guān)的我沒有把握，其他點我都很有信心做好它。

36、當開發(fā)人員說不是BUG時，你如何應(yīng)付？

開發(fā)人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產(chǎn)品經(jīng)理進行確認，需不需要改動，3方商量確定好后再看要不要改。二是這種情況不可能發(fā)生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據(jù)是什么？如果還是不行，那我可以給這個問題提出來,跟開發(fā)經(jīng)理和測試經(jīng)理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發(fā)人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認。

37、寫出bug報告當中一些必備的內(nèi)容。

硬件平臺和操作系統(tǒng)

測試應(yīng)用的硬件平臺（Platform），通常選擇“PC”。

測試應(yīng)用的操作系統(tǒng)平臺（OS）。

a) 版本 提交缺陷報告時通過該字段標識此缺陷存在于被測試軟件的哪個版本。

b) Bug報告優(yōu)先級

c) Bug狀態(tài)

d) Bug的編號

e) 發(fā)現(xiàn)人

f) 提交人

g) 指定處理人

h) 概述

i) 從屬關(guān)系

j) 詳細描述

k) 嚴重程度

l) 所屬模塊

m) 附件

n) 提交日期

38、開發(fā)人員老是犯一些低級錯誤怎么解決？

從兩個方面入手：

一方面從開發(fā)管理入手，也就是從根源來解決問題。可以制定規(guī)范的開發(fā)流程，甚至可以制定懲罰制度，還有就是軟件開發(fā)前做好規(guī)劃設(shè)計。

另一方面就是加強測試，具體做法就是加強開發(fā)人員的自己測試，把這些問題“消滅”在開發(fā)階段，這是比較好的做法。

39、簡述一下c/s模式或者b/s模式？

C/S模式：客戶端/服務(wù)器模式。工作原理：Client向Server提交一個請求；Server則使用一些方法處理這個請求，并將效果返回給Client。

B/S結(jié)構(gòu)，即Browser/Server(瀏覽器/服務(wù)器)結(jié)構(gòu)，主要是利用了不斷成熟的WWW瀏覽器技術(shù)，結(jié)合瀏覽器的多種Script語言(VBScript、JavaScript…)和ActiveX技術(shù)，用通用瀏覽器就實現(xiàn)了原來需要復雜專用軟件才能實現(xiàn)的強大功能，并節(jié)約了開發(fā)成本，是一種全新的軟件系統(tǒng)構(gòu)造技術(shù)。

Part2

1、什么是兼容性測試？兼容性測試側(cè)重哪些方面？

參考答案：

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行，即是通常說的軟件的可移植性。

兼容的類型，如果細分的話，有平臺的兼容，網(wǎng)絡(luò)兼容，數(shù)據(jù)庫兼容，以及數(shù)據(jù)格式的兼容。

兼容測試的重點是，對兼容環(huán)境的分析。通常，是在運行軟件的環(huán)境不是很確定的情況下，才需要做兼容。根據(jù)軟件運行的需要，或者根據(jù)需求文檔，一般都能夠得出用戶會在什么環(huán)境下使用該軟件，把這些環(huán)境整理成表單，就得出做兼容測試的兼容環(huán)境了。

兼容和配置測試的區(qū)別在于，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環(huán)境下做的。

2、我現(xiàn)在有個程序，發(fā)現(xiàn)在Windows上運行得很慢，怎么判別是程序存在問題還是軟硬件系統(tǒng)存在問題？

參考答案：

1、檢查系統(tǒng)是否有中毒的特征；

2、檢查軟件/硬件的配置是否符合軟件的推薦標準；

3、確認當前的系統(tǒng)是否是獨立，即沒有對外提供什么消耗CPU資源的服務(wù)；

4、如果是C/S或者B/S結(jié)構(gòu)的軟件，需要檢查是不是因為與服務(wù)器的連接有問題，或者訪問有問題造成的；

5、在系統(tǒng)沒有任何負載的情況下，查看性能監(jiān)視器，確認應(yīng)用程序?qū)PU/內(nèi)存的訪問情況。

3、測試的策略有哪些？

參考答案：

黑盒/白盒，靜態(tài)/動態(tài)，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）

4、正交表測試用例設(shè)計方法的特點是什么？

參考答案：

用最少的實驗覆蓋最多的操作，測試用例設(shè)計很少，效率高，但是很復雜；

對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；

具體的環(huán)境下，正交表一般都很難做的。大多數(shù)，只在系統(tǒng)測試的時候使用此方法。

5、描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程？

參考答案：

就是Bugzilla的狀態(tài)轉(zhuǎn)換圖。

6、你覺得bugzilla在使用的過程中，有什么問題？

參考答案：

界面不穩(wěn)定；

根據(jù)需要配置它的不同的部分，過程很煩瑣。

流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；

沒有綜合的評分指標，不好確認修復的優(yōu)先級別。

7、描述測試用例設(shè)計的完整過程？

參考答案：

需求分析 + 需求變更的維護工作；

根據(jù)需求 得出測試需求；

設(shè)計測試方案，評審測試方案；

方案評審通過后，設(shè)計測試用例，再對測試用例進行評審；

8、單元測試的策略有哪些？

參考答案：

邏輯覆蓋、循環(huán)覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數(shù)據(jù)流分析

9、LoadRunner分哪三部分？

參考答案：

用戶動作設(shè)計；

場景設(shè)計；

測試數(shù)據(jù)分析；

10、LoadRunner進行測試的流程?

參考答案：

1、 計劃負載測試

2、 創(chuàng)建虛擬用戶腳本

3、 創(chuàng)建運行場景

4、 運行測試腳本

5、 監(jiān)視場景

6、 分析測試的結(jié)果

以上，最好是結(jié)合一個案例，根據(jù)以上流程來介紹。

part3

1、軟件的生命周期（prdctrm）

計劃階段（planning）-〉需求分析（requirement）-〉設(shè)計階段（design）-〉編碼（coding）->測試（testing）->運行與維護（running maintrnacne）

2、你在測試中發(fā)現(xiàn)了一個bug，但是開發(fā)經(jīng)理認為這不是一個bug，你應(yīng)該怎樣解決？

首先，將問題提交到缺陷管理庫里面進行備案。

然后，要獲取判斷的依據(jù)和標準：根據(jù)需求說明書、產(chǎn)品說明、原型圖、設(shè)計文檔等，確認實際結(jié)果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據(jù)；

如果沒有文檔依據(jù)，

1）可以根據(jù)同行或類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；

2）根據(jù)用戶的一般使用習慣，來確認是否是缺陷；

3）與設(shè)計人員、開發(fā)人員和客戶代表等相關(guān)人員探討，確認是否是缺陷；

合理的論述，向測試經(jīng)理說明自己的判斷的理由，等待測試經(jīng)理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。

3、給你一個網(wǎng)站，你如何測試？

首先，查找需求說明、網(wǎng)站設(shè)計等相關(guān)文檔，分析測試需求。

制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；兼容性測試

設(shè)計測試用例：

功能性測試可以包括，但不限于以下幾個方面：

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

提交功能的測試。

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

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

界面測試可以包括但不限于一下幾個方面：

頁面是否風格統(tǒng)一，美觀

頁面布局是否合理，重點內(nèi)容和熱點內(nèi)容是否突出

控件是否正常使用

對于必須但未安裝的控件，是否提供自動下載并安裝的功能

文字檢查

性能測試一般從以下兩個方面考慮：

壓力測試；負載測試；強度測試

數(shù)據(jù)庫測試要具體決定是否需要開展。數(shù)據(jù)庫一般需要考慮連結(jié)性，對數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗證等方面。

安全性測試：

基本的登錄功能的檢查

是否存在溢出錯誤，導致系統(tǒng)崩潰或者權(quán)限泄露

相關(guān)開發(fā)語言的常見安全性問題檢查，例如SQL注入等

如果需要高級的安全性測試，確定獲得專業(yè)安全公司的幫助，外包測試，或者獲取支持兼容性測試，

根據(jù)需求說明的內(nèi)容，確定支持的平臺組合：

瀏覽器的兼容性；

操作系統(tǒng)的兼容性；

軟件平臺的兼容性；

數(shù)據(jù)庫的兼容性

開展測試，并記錄缺陷。合理的安排調(diào)整測試進度，提前獲取測試所需的資源，建立管理體系（

例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內(nèi)容）。

定期評審，對測試進行評估和總結(jié)，調(diào)整測試的內(nèi)容。

4、一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務(wù)器施壓，有什么區(qū)別?

300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結(jié)果。線程之間可能發(fā)生干擾，而產(chǎn)生一些異常。

300個用戶在一個客戶端上，需要更大的帶寬。

IP地址的問題，可能需要使用IP Spoof來繞過服務(wù)器對于單一IP地址最大連接數(shù)的限制。

所有用戶在一個客戶端上，不必考慮分布式管理的問題；

而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調(diào)配不同客戶機上的用戶。同時，還需要給予相應(yīng)的權(quán)限配置和防火墻設(shè)置。

5、軟件生存周期及其模型是什么？

軟件生存周期（Software life cycle）又稱為軟件生命期，生存期。是指從形成開發(fā)軟件概念起，所開發(fā)的軟件使用以后，直到失去使用價值消亡為止的整個過程。一般來說，整個生存周期包括 ：問題的定義及規(guī)劃、需求分析/評審、軟件設(shè)計、軟件編碼、測試階段、運行維護 六個時期，每個時期又劃分為若干個階段。每個階段有明確的任務(wù)。

周期模型（典型的幾種）：

1）瀑布模型

2）快速原型模型：快速原型模型允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設(shè)計開發(fā)出軟件系統(tǒng)的原型，該原型向用戶展示待開發(fā)軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發(fā)人員據(jù)此對軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現(xiàn)及測試、維護。

3）迭代模型：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開發(fā)活動和要使用該發(fā)布必需的所有其他外圍元素。在某種程度上，開發(fā)迭代是一次 完整地經(jīng)過所有工作流程的過程：需求分析、設(shè)計、實施和測試工作流程。實質(zhì)上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為迭代。每一次 的迭代都會產(chǎn)生一個可以發(fā)布的產(chǎn)品，這個產(chǎn)品是最終產(chǎn)品的一個子集。

生命周期階段：

軟件計劃與可行性分析

需求分析

軟件設(shè)計

編碼

軟件測試

運行與維護

6、什么是軟件測試？軟件測試的目的與原則

定義：

在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設(shè)計要求進行評估的過程。

目的：

測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤

軟件測試為了發(fā)現(xiàn)程序中存在的代碼或業(yè)務(wù)邏輯錯誤

軟件測試為了檢驗產(chǎn)品是否符合用戶的需求

軟件測試為了提高用戶體驗

軟件測試的原則：

測試應(yīng)盡早啟動、介入（需求分析階段），所有的測試應(yīng)追溯到用戶需求，測試證明軟件存在缺陷，不可能執(zhí)行窮盡測試，完全測試是不可能的，測試需要終止。

二八原則，測試發(fā)現(xiàn)的錯誤中80%很可能的起源于20%的模塊中。（缺陷存在群集現(xiàn)象）

對錯誤結(jié)果要進行一個確認的過程（測試的詳細數(shù)據(jù)，截圖，前置條件等），制定嚴格的測試計劃；妥善保管測試過程中的所有文檔；程序員盡量避免自己的檢查程序；設(shè)計測試用例是應(yīng)該考慮到合法的輸入和不合法的輸入

7、什么是軟件質(zhì)量？

概括地說，軟件質(zhì)量就是“軟件與明確的和隱含的定義的需求相一致的程度”。具體地說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、文檔中明確描述 的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應(yīng)具有的隱含特征的程度。 影響軟件質(zhì)量的主要因素，這些因素是從管理角度對軟件質(zhì)量的度量?？蓜澐譃槿M，分別反應(yīng)用戶在使用軟件產(chǎn)品時的三種觀點。正確性、健壯性、效率、完整性、可用性、風險（產(chǎn)品運行）；可理解性、可維修性、靈活性、可測試性（產(chǎn)品修改）；可移植性、可再用性、互運行性（產(chǎn)品轉(zhuǎn)移）。

8、目前主要的測試用例設(shè)計方法是什么？

白盒測試：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋

黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態(tài)圖法、測試大綱法、隨機測試、場景法

9、軟件的安全性應(yīng)從哪幾個方面去測試？

軟件安全性測試包括程序、數(shù)據(jù)庫安全性測試。根據(jù)系統(tǒng)安全指標不同測試策略也不同。

用戶認證安全的測試要考慮問題：

1）明確區(qū)分系統(tǒng)中不同用戶權(quán)限 、系統(tǒng)中會不會出現(xiàn)用戶沖突 、系統(tǒng)會不會因用戶的權(quán)限的改變造成混亂

2）用戶登陸密碼是否是可見、可復制 、是否可以通過絕對途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進入系統(tǒng)）

3）用戶退出系統(tǒng)后是否刪除了所有鑒權(quán)標記，是否可以使用后退鍵而不通過輸入口令進入 系統(tǒng)

系統(tǒng)網(wǎng)絡(luò)安全的測試要考慮問題 ：

1）測試采取的防護措施是否正確裝配好

2）有關(guān)系統(tǒng)的補丁是否打上

3）模擬非授權(quán)***

4）看防護系統(tǒng)是否堅固

5）采用成熟的網(wǎng)絡(luò)漏洞檢查工具檢查系統(tǒng)相關(guān)漏洞（即用最專業(yè)的******工具***試一下，現(xiàn)在最常用的是 NBSI 系列和 IPhacker IP ）

6)采用各種***檢查工具檢查系統(tǒng)***情況

7)采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞

數(shù)據(jù)庫安全考慮問題：

1）系統(tǒng)數(shù)據(jù)是否機密（比如對銀行系統(tǒng)，這一點就特別重要，一般的網(wǎng)站就沒有太高要求）

2）系統(tǒng)數(shù)據(jù)的完整性（我剛剛結(jié)束的企業(yè)實名核查服務(wù)系統(tǒng)中就曾存在數(shù)據(jù) 的不

3）完整，對于這個系統(tǒng)的功能實現(xiàn)有了障礙） 、系

4）統(tǒng)數(shù)據(jù)可管理性 、

5）系統(tǒng)數(shù)據(jù)的獨立性 、

6）系統(tǒng)數(shù)據(jù)可備份和恢復能力（數(shù)據(jù)備份是否完整，可否恢復，恢復是否可以完整）

10、什么是測試用例 什么是測試腳本 兩者的關(guān)系是什么？

用例：

未實施測試而編制的一組測試輸入、執(zhí)行條件、各種環(huán)境設(shè)置以及預期結(jié)果以及期望結(jié)果的一個特定的集合。

腳本：

測試腳本是為了進行自動化測試而編寫的腳本。

測試腳本的編寫必須對應(yīng)相應(yīng)的測試用例

11、簡述什么是靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、α測試 β測試

靜態(tài)測試：是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。

動態(tài)測試：是實際運行被測程序，輸入相應(yīng)的測試實例，檢查運行結(jié)果與預期結(jié)果的差異，判定執(zhí)行結(jié)果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，并分析系統(tǒng)運行效率和健壯性等性能。

黑盒測試：一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現(xiàn),把被測試的程序當作一個黑盒,不考慮其內(nèi)部結(jié)構(gòu),在知道該程序的輸入和輸出之間的關(guān)系或程序功能的情況下,依靠軟件規(guī)格說明書來確定測試用例和推斷測試結(jié)果的正確性。

白盒測試：根據(jù)軟件內(nèi)部的邏輯結(jié)構(gòu)分析來進行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通

過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般黑盒測試由項目經(jīng)理在程序員開發(fā)中來實現(xiàn)。

α測試：是由用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試不能由程序員或測試員完成。

β測試：由軟件的一個或多個用戶在實際使用環(huán)境下進行的測試， 開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。

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

功能性：適應(yīng)性、準確性、互操作性、依從性、安全性。

可靠性：成熟性、容錯性、易恢復性。

可使用性：易理解性、易學習性、易操作性。

效率：時間特性、資源特性。

可維護性：易分析性、易變更性、穩(wěn)定性、易測試性。

可移植性： 適應(yīng)性、易安裝性、遵循性、易替換性

13、軟件測試的策略是什么?

軟件測試策略：在一定的軟件測試標準、測試規(guī)范的指導下，依據(jù)測試項目的特定環(huán)境約束而規(guī)定的軟件測試的原則、方式、方法的集合。

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

測試過程會依次經(jīng)歷單元測試、集成測試、系統(tǒng)測試、驗收測試四個主要階段

單元測試：是針對軟件設(shè)計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發(fā)人員進行。

集成測試：是將模塊按照設(shè)計要求組裝起來進行測試，主要目的是發(fā)現(xiàn)與接口有關(guān)的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)小組都要進行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。

系統(tǒng)測試：是在集成測試通過后進行的，目的是充分運行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設(shè)計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產(chǎn)品的質(zhì)量有重大的影響。

驗收測試：以需求階段的《需求規(guī)格說明書》為驗收標準，測試時要求模擬實際用戶的運行環(huán)境。對于實際項

目可以和客戶共同進行，對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面測試，尤其要進行文檔測試。

單元測試測試策略：

自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。

自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。

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

集成測試的測試策略：

大爆炸集成：適應(yīng)于一個維護型項目或被測試系統(tǒng)較小

自頂向下集成：適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；高層接口變化較小；底層接口未定義或經(jīng)?？赡鼙恍薷?#xff1b;產(chǎn)口控制組件具有較大的技術(shù)風險，需要盡早被驗證；希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

自底向上集成：適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。

基于進度的集成

優(yōu)點：具有較高的并行度；能夠有效縮短項目的開發(fā)進度。

缺點：樁和驅(qū)動工作量較大；有些接口測試不充分；有些測試重復和浪費。

系統(tǒng)測試的測試策略：

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

15、軟件測試各個階段通常完成什么工作？各個階段的結(jié)果文件是什么？包括什么內(nèi)容？

單元測試階段：

各獨立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。生成單元測試報告，提交缺陷報告。

集成測試階段：

集成測試是在單元測試的基礎(chǔ)上，測試在將所有的軟件單元按照概要設(shè)計規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標及要求的活動。該階段生成集成測試報告，提交缺陷報告。

系統(tǒng)測試階段：

將通過確認測試的軟件，作為整個給予計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行全面的功能覆蓋。該階段需要提交測試總結(jié)和缺陷報告。

16、測試人員在軟件開發(fā)過程中的任務(wù)是什么？

1、盡可能早的找出系統(tǒng)中的Bug；

2、避免軟件開發(fā)過程中缺陷的出現(xiàn)；

3、衡量軟件的品質(zhì)，保證系統(tǒng)的質(zhì)量；

4、關(guān)注用戶的需求，并保證系統(tǒng)符合用戶需求。

總的目標是：確保軟件的質(zhì)量。

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

一條Bug記錄最基本應(yīng)包含：

bug編號；

bug嚴重級別，優(yōu)先級；

bug產(chǎn)生的模塊；

首先要有bug摘要，闡述bug大體的內(nèi)容；

bug對應(yīng)的版本；

bug詳細現(xiàn)象描述，包括一些截圖、錄像…等等；

bug出現(xiàn)時的測試環(huán)境，產(chǎn)生的條件即對應(yīng)操作步驟；

高質(zhì)量的Bug記錄：

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

2.盡量使用業(yè)界慣用的表達術(shù)語和表達方法
使用業(yè)界慣用的表達術(shù)語和表達方法，保證表達準確，體現(xiàn)專業(yè)化。

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

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

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

6.明確指明缺陷嚴重等級和優(yōu)先等級時刻明確嚴重等級和優(yōu)先等級之間的差別。高嚴重問題可能

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

8.短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距

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

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

10.確認步驟完整，準確，簡短

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

11.根據(jù)缺陷，可選擇是否進行圖象捕捉

為了直觀的觀察缺陷或缺陷現(xiàn)象，通常需要附加缺陷或缺陷出現(xiàn)的界面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節(jié)省空間，又能真實反映缺陷或缺陷本質(zhì)，可以捕捉缺陷或缺陷產(chǎn)生時的全屏幕，活動窗口和局部區(qū)域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。

?附加必要的特殊文檔和個人建議和注解如果打開某個特殊的文檔而產(chǎn)生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現(xiàn)缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現(xiàn)，可以附加個人的修改建議或注解。

12.檢查拼寫和語法缺陷

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

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

14.缺陷描述內(nèi)容

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

18、黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優(yōu)點和缺點？

黑盒測試的優(yōu)點有：

比較簡單，不需要了解程序內(nèi)部的代碼及實現(xiàn)；

與軟件的內(nèi)部實現(xiàn)無關(guān)；

從用戶角度出發(fā)，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；

基于軟件開發(fā)文檔，所以也能知道軟件實現(xiàn)了文檔中的哪些功能；在做軟件自動化測試時較為方便。

黑盒測試的缺點有：

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

白盒測試的優(yōu)點有：

幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱 藏的問題。

白盒測試的缺點有：

程序運行會有很多不同的路徑，不可能測試所有的運行路徑；

測試基于代碼，只能測試開發(fā)人員做的對不對，而不能知道設(shè)計的正確與否，可能會漏掉一些功能需求；系統(tǒng)龐大時，測試開銷會非常大。

19、如何測試一個紙杯？

功能度：用水杯裝水看漏不漏；水能不能被喝到

安全性：杯子有沒有毒或細菌

可靠性：杯子從不同高度落下的損壞程度

可移植性：杯子在不同的地方、溫度等環(huán)境下是否都可以正常使用

兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等

易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述

疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等

壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透

20、黑盒測試的測試用例常見設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應(yīng)用。

1）等價類劃分：

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

2）邊界值分析法：

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

3）錯誤猜測法：

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

4）因果圖方法：

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

5）正交表分析法：

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

6）場景分析方法：

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

7）狀態(tài)圖法：

通過輸入條件和系統(tǒng)需求說明得到被測系統(tǒng)的所有狀態(tài)，通過輸入條件和狀態(tài)得出輸出條件；通過輸入條件、輸出條件和狀態(tài)得出被測系統(tǒng)的測試用例。

8）大綱法：

大綱法是一種著眼于需求的方法，為了列出各種測試條件，就將需求轉(zhuǎn)換為大綱的形式。大綱表示為樹狀結(jié)構(gòu)，在根和每個葉子結(jié)點之間存在唯一的路徑。大綱中的每條路徑定義了一個特定的輸入條件集合，用于定義測試用例。樹中葉子的數(shù)目或大綱中的路徑給出了測試所有功能所需測試用例的大致數(shù)量。

part4

探討測試用例設(shè)計的六大思路

有這樣一個面試題：在一個Web測試頁面上，有一個輸入框，一個計數(shù)器（count）按鈕，用于計算一個文本字符串中字母a出現(xiàn)的個數(shù)。請設(shè)計一系列測試用例用以測試這個Web頁面。

有經(jīng)驗的測試人員可能會問面試官，字母a區(qū)分大小寫嗎？只統(tǒng)計英文字母的a嗎？最長輸入字符是多少，最少輸入字符是多少？對輸入的字符類型是否有限制，是否會自動清除不符合要求的字符？

  所以第一步應(yīng)該是明確需求，然后我們才開始進行思考如何設(shè)計測試用例。通常說來，我們考慮一個測試對象的時候至少從以下六方面來考慮：1.功能性2.兼容性3.易用性4.可靠性5.性能6.安全1.從功能方面考慮：輸入："  "（思路：什么都不輸入）輸入："null"（思路：特殊值）輸入："Aa"（思路：輸入字符既含大寫字符也有小寫）輸入："abc"（思路：以a開頭）輸入："cac"（思路：a在中間）輸入："aba"（思路：以a開頭，以a結(jié)尾）輸入：" ba"（思路：以空格開頭含a）輸入："中ba"（思路：以中文或者其他字符開頭含a）輸入："AAaa"（思路：輸入字符僅僅只有大寫A和小寫a）輸入："全角和半角a"（思路：考慮半角和全角符號）2.從兼容性方面考慮：1.各個瀏覽器 顯示是否正確，點擊按鈕是否有效；2.瀏覽器各個版本顯示是否正確，點擊按鈕是否有效；3.是否支持手機端和平板端。3.從易用性方面考慮：1.web界面外觀，風格是否合適；2.文本輸入框長度是否合適，是否應(yīng)該默認提示如何輸入；3.輸入錯誤時提示是否友好；4.考慮該應(yīng)用是否支持其他語言。4.從可靠性和性能方面考慮：1.輸入HTML和JavaScript相關(guān)標簽字符，計算是否正確，是否會破壞頁面；2.這個應(yīng)用能否在同一臺服務(wù)器上運行多個實例，多個用戶同時使用是否會有問題；3.在大并發(fā)下使用，計算速度是否滿足要求。5.從安全性方面考慮：1.輸入的數(shù)據(jù)是否會被保存，輸入字符串可能包含敏感信息；2.嘗試復制/粘貼字符串；3.嘗試快速點擊多次計算按鈕；4.考慮是否有安全漏洞，點擊計算按鈕，請求是否會被截取，導致返回失敗。

part5

1、金融軟件測試面試題目有哪些？

網(wǎng)上銀行轉(zhuǎn)賬是怎么測的，設(shè)計一下測試用例。

回答思路：

宏觀上可以從質(zhì)量模型（萬能公式）來考慮，重點需要測試轉(zhuǎn)賬的功能、性能與安全性。設(shè)計測試用例可以使用場景法為主，先列出轉(zhuǎn)賬的基本流和備選流。然后設(shè)計場景，最后根據(jù)場景設(shè)計數(shù)據(jù)。實際面試中需要舉出具體的例子。

先檢查界面。

再測試功能，

驗證同行轉(zhuǎn)賬，跨行轉(zhuǎn)賬。

驗證轉(zhuǎn)賬限額。

驗證非法賬戶（掛失，凍結(jié)，鎖定的賬戶）的轉(zhuǎn)賬。

再測試性能方面的。

測試工作的流程?缺陷狀態(tài)有什么?設(shè)計測試用例有幾種方法？

測試工程師的實際工作流程（以P2P中型版本為例，一個月一個版本）：

產(chǎn)品經(jīng)理或者SR把需求書發(fā)下來給開發(fā)和測試

測試先看一遍，進行需求分析。測試組長編寫測試計劃，并且分配測試任務(wù)給測試人員（2天時間）（此時開發(fā)也在進行需求分析）

過了2天，產(chǎn)品經(jīng)理再把測試和開發(fā)召集在一起，進行需求講解（或者說需求評審），有問題可以直接問，如果發(fā)現(xiàn)需求有問題，也可以提出來，SR回去會修改。（需求講解時間0.5天）

講完需求后，測試同事要進行測試場景的梳理和案例的編寫了（xmind和Excel就要用上了），一共5個工作日。（此時開發(fā)在編寫代碼）

之后就要進行案例評審了，評審時候有SR、測試同事、開發(fā)同事，評審時候一般SR、測試組長、對應(yīng)模塊的開發(fā)同事會提出一點意見，評審完之后，回去修改、補充一下案例。（案例評審0.5天）

修改完以后，有兩種處理情況：

對大項目有時候要進行案例的第二次評審。

對小項目，在時間緊的時候，一般不會二審，但是要以郵件的形式把修改或者新增后的案例發(fā)出來，給領(lǐng)導看，并抄送給其他同事。（案例評審0.5天，修改案例0.5天，案例二審0.5天）

案例評審完就要開始測試了，一般測試環(huán)境開發(fā)搭建好（要說自己也會搭建，搭建流程背老師總結(jié)的）：

中型版本的測試一般分2輪：第一輪：5天；第二輪：3天；回歸測試2天；（共10個工作日）。

回歸測試完后，達到了上線標準，就會如期上線，一般當天晚上12點上線

缺陷狀態(tài)：缺陷管理的流程圖

2、在項目中找到的經(jīng)典BUG是什么？

兼容性問題，在ie瀏覽器，提交訂單按鈕可以點擊，到了谷歌，火狐就不能了。

查詢訂單頁面，根據(jù)條件篩選的結(jié)果不是想要的結(jié)果，還有某些字段的值沒有顯示出來，或者顯示錯誤。（因為開發(fā)從庫表取值有誤）

付款成功后，訂單狀態(tài)一直不翻轉(zhuǎn)為交易成功。（因為代碼沒有正確獲取庫表中付款成功記錄的狀態(tài)碼）

修改支付密碼，新密碼和原密碼一致，也通過了，系統(tǒng)沒有做新舊密碼的校驗。

付款時候的手機驗證碼，可以一直使用，沒有成功做有效期控制。

手機app斷開網(wǎng)絡(luò)后，再去點擊，沒有友好的錯誤頁面提示網(wǎng)絡(luò)已斷開，只有undefined返回

3、定期存款到期自動轉(zhuǎn)存該怎么測？

回答思路：到期肯定會有邊界，所以設(shè)計里面可以考慮邊界值法。自動轉(zhuǎn)存（首先要搞清楚什么是自動轉(zhuǎn)存。）

4、存錢該怎么測，用什么測試方法？

準備思路：存錢要分類：活期、零存整取等（具體規(guī)則百度下），然后根據(jù)每類的業(yè)務(wù)規(guī)則選擇合適的用例設(shè)計方法。譬如一次最少存入多少？最多一次能存入多少等。

5、你發(fā)現(xiàn)Bug后，應(yīng)該怎么辦？

首先咨詢一下開發(fā)是不是bug，讓他初步判斷一下。

如果不是bug，開發(fā)給到理由也比較充分，確實自己也搞錯了，也就算了。

如果開發(fā)也認為是bug，那就直接提了。

如果我懷疑開發(fā)的解答，我覺得是bug，開發(fā)堅持不是bug，我就要咨詢我們組長或者開發(fā)組長，讓他們判斷一下。

6、假如發(fā)現(xiàn)了一個BUG，跟開發(fā)本身沒什么關(guān)系，涉及到理念，需求問題，如何解決？

把問題暴露給測試組長和開發(fā)組長，咨詢他們意見，組長們再知會開發(fā)分組經(jīng)理和項目經(jīng)理，然后大家和產(chǎn)品經(jīng)理一起探討解決，需要改需求的地方就要改了。

7、測試非常緊急過程中，遇到阻塞性問題，對應(yīng)的開發(fā)沒有時間解決，你如何推動問題解決？

首先判斷問題的嚴重性，向?qū)?yīng)的開發(fā)了解問題的原因。

然后再匯報給自己的測試組長和開發(fā)組長，讓組長知情，咨詢他們的意見，再把問題匯報給開發(fā)分組經(jīng)理，讓他們統(tǒng)一協(xié)調(diào)處理。安排經(jīng)驗豐富的其他高級開發(fā)人員來協(xié)助此開發(fā)解決問題，然后通過加班來完成問題解決和測試。

8、功能測試的BUG級別你們怎么劃分？

bug嚴重程度：一般提L4 和L3，L2很少提，除非影響流程。L1這個是非常致命的bug，基本上不會提。

9、執(zhí)行別人的用例，如果發(fā)現(xiàn)用例有錯怎么處理？

首先咨詢一下案例作者或者詢問測試組長，確認一下，如果確實有誤就要修正用例。

10、你們做過冒煙側(cè)嗎？冒煙測試是什么（理論）？

冒煙測試也叫預測試，就是正式測試之前的一種測試，為了確保主流程能走通。

可以回答沒有冒煙測試，就說測試之前一般會要求開發(fā)自測，開發(fā)自測后（自測大概就是一天左右的時間），確保沒有大的問題，再通知測試開始測試。

11、你們項目做了多久，共寫了多少用例？項目多少人？

項目做了多久：（兩種回答，建議選擇第一種）

我進去的時候項目已經(jīng)上線了，一直存在，然后就是版本的微小更新，小修改的話，大概半個月一個版本，中修改的話，大概一個月一個版本。每次版本更新，針對新的功能點或者修改點大概寫了60條案例左右（一個月一個版本的例子）。

我進去的時候，一開始就參與這個項目（也就是需求分析開始），項目從零到有進行了半年左右，六個月內(nèi)大概整個項目組寫了900條案例左右。自己寫了200條左右(共5個測試，包括組長)。

PS:如果大家說自己是從零到有參與的項目，那么6個月時間是從需求分析開始。需求書編寫完成前，產(chǎn)品經(jīng)理他們是要做很多前期準備工作，可能要花費3個月左右的時間。

那么測試6個月的實際工作時間內(nèi)：

前期2個月：剛開始需求書的漏洞比較多，需求評審比較多，基本上每個星期一次評審。開發(fā)和測試都會參與，此時開發(fā)在進行代碼設(shè)計，測試就在分析需求，看參考文檔，用xmind梳理測試場景，提取測試點，開發(fā)經(jīng)常和產(chǎn)品經(jīng)理討論需求，測試經(jīng)常問開發(fā)和產(chǎn)品經(jīng)理有關(guān)需求的疑問。大家一直碰撞，一步一步得出比較完美的邏輯。

中間2個月：開發(fā)設(shè)計完后，進行編碼，我們測試就根據(jù)之前梳理的測試場景來編寫案例，進一步優(yōu)化。這個期間，需求書基本穩(wěn)定，不會再改了。要改也就是把細化需求，把籠統(tǒng)的地方，描述的更詳細，更讓人易懂，功能點的大方向不會改。開發(fā)和測試在此期間有疑問，都會郵件或者電話聯(lián)系產(chǎn)品經(jīng)理。測試也會經(jīng)常去問開發(fā)有關(guān)功能點的邏輯問題。

后面2個月： 執(zhí)行案例工作開始進行，一般分為兩輪st測試，第一輪1個月，第二輪半個月，回歸測試半個月。Uat測試組在st測試第二輪時候，并行開始。Uat測試組有專門人負責，一般需要st測試組派一個人左右去支持，uat測試也有第一輪（半個月），第二輪（半個月）。

項目多少人：一個公司往往有很多項目，自己只是其中一個項目組的，我的P2P項目組大概20人，開發(fā)15個，測試5個。（大家把自己當成外包人員，在甲方工作，也叫駐場工作）

12、假如要你測試6個月期限的p2p借款產(chǎn)品，你應(yīng)該怎么設(shè)計案例，說出測試點

（回答思路：1站在用戶的角度測試，用戶怎么用，你就怎么測試。2 一個人扮演多種角色測試。 3多想出一些異常場景。）

借款產(chǎn)品投標結(jié)束日T+7時，滿標和不滿標的情況。

借款產(chǎn)品投標結(jié)束日T+7前，產(chǎn)品提前滿標情況

產(chǎn)品成立后，每個月還款日前，檢查系統(tǒng)有沒有發(fā)出郵件，短信，站內(nèi)信通知借款人充值到平臺賬戶。

在每月還款日，借款人充值用來還款時，充值資金足夠、不足夠、不充值情況，查看系統(tǒng)如何處理。充值資金不足或者沒有充值時，系統(tǒng)應(yīng)該有罰息。

借款人提前還清余款場景，有些產(chǎn)品不支持提前還款，有些產(chǎn)品要滿一定期限才可以提前還款（提前還款有一定手續(xù)費）。這些都是要關(guān)注的測試點。（自己要扮演借款用戶去操作提前還清余款，然后扮演后臺管理員去審核，然后又扮演投資人用戶去檢查虛擬賬戶的資金到賬情況）

最后一期借款人還清資金時，去后臺頁面查看借款產(chǎn)品狀態(tài)，應(yīng)該已正常結(jié)束。再去前臺頁面搜索，應(yīng)該無該借款產(chǎn)品了。 （或者補充說：去數(shù)據(jù)庫里查看此借款產(chǎn)品的狀態(tài)）

13、你們這個P2P上線了嗎？能查嗎？項目花了多久時間，預計多久完成？

回答：兩種方案：

還沒上線，查不了，這個是新項目，計劃半年時間完成，但是因為中途有出現(xiàn)一些問題沒有解決完畢，所以現(xiàn)在還沒有在預計時間內(nèi)完成。

大家寫的項目名在網(wǎng)上確實能查出來，就說上線了，能查到的。（面試官其實不一定會去查）

14、實名認證你們是怎么測得？調(diào)取什么平臺的資料？

實名認證接口：

銀行卡實名認證（調(diào)用銀行接口，驗證卡號，姓名，身份證號碼，手機號碼。需要利用到手機接收到的驗證碼）

身份證實名認證（全國公民身份證號碼查詢服務(wù)中心，或者直接說公安接口）

15、注冊需要實名認證嗎？

注冊不需要實名認證：當購物時候需要實名認證。

16、P2P你們也測試后臺管理嗎？個人芝麻信用積分是調(diào)取哪里的資料？

測試后臺管理：

后臺也測，但是我主要測試前臺，我的關(guān)注點是前臺，后臺只是拿來用，能配合前臺正常走完流程就行。后臺主要對前臺進行管理，主要有貸款管理，資金管理。

貸款管理：

可以查看投資人的投資情況，也可以查看借款人的借款產(chǎn)品，對借款產(chǎn)品進行管理。比如審批，每期的還款提醒，預警等。

資金管理：

管理查看用戶的充值，審批用戶的提現(xiàn)過程。

芝麻信用積分：

調(diào)用的是支付寶的接口，芝麻信用：調(diào)用的是支付寶那邊的接口（支付寶提供這樣的芝麻信用服務(wù)，每查一次收取大概0.1元）

17、如果要測試后臺刪除用戶，就是用戶名后面一個刪除按鈕的情況，能寫出哪些測試用例？

刪除一個用戶的場景：點擊刪除按鈕，頁面自動刷新，此用戶在該頁面已查詢不到。再去打開另外一個瀏覽器，在前臺登錄已刪除的用戶，頁面提示該用戶不存在。

同時刪除多個用戶的場景：利用復選框，測試多選，反選，全選刪除用戶的情況。刪除后，被刪用戶在該頁面已查詢不到，同樣要去前臺登錄已刪除的用戶，頁面應(yīng)該提示該用戶不存在。

18、如果京東有一個購物網(wǎng)頁給你，你要怎么進行測試？測試哪些主要功能？

首先進行需求分析，用xmind梳理測試點，再編寫案例，之后就行案例評審，尋求他人意見。之后再完善案例，發(fā)出來給其他人檢查。

測試點，首先是UI方面：美觀度，和易操作型，易理解性型方面進行測試。

然后再考慮他的功能點，注冊登錄，添加購物車，下單，付款，發(fā)貨，確認收貨，評價。還有支付時候的綁定銀行卡，實名認證

性能方面：打開網(wǎng)頁，確認訂單、付款的響應(yīng)時間等等。

兼容性：支持各種主流瀏覽器，ie，360，火狐，谷歌等。

19、針對添加購物車這個測試點說一下你要怎么測試“添加購物車”

（增刪改查的角度）

能否加入購物車，同一件商品能否再次添加到購物車。

購物車商品件數(shù)的上限限制（淘寶限制100件）

購物車是否可以正常移除商品，移除商品后，能否再添加回來。

添加的每種商品是否可以正常增減數(shù)量，數(shù)量大于0

退出購物車，再去查詢購物車，商品正常。

購物車的商品可以全選，取消全選，可以復選，選中的商品和數(shù)量可以正常下單。

商品添加到購物車以后，已下架。購物車會提示此寶貝已失效。

商品添加到購物車以后，降價了，購物車會有降價提示。

商品添加到購物車以后，庫存不足了。

20、P2P功能測試你們一般做幾輪？

中型版本（大修改，一個月上線一次）：測試一般分2輪：第一輪：5天；第二輪：3天；回歸測試2天；（共10個工作日）。（一個月工作日22天，需求分析評審，編寫測試用例等等一般占用整個版本時間的一半，或者少個幾天）

小型版本（小修改，兩個星期一次）：一輪測試3天，回歸測試2天。

21、你們每次開會討論的時候十幾個開發(fā)都去開會了嗎？

案例評審會：一般開發(fā)和測試、產(chǎn)品經(jīng)理都會到場。（開發(fā)分組經(jīng)理可能也會去）需求評審會：項目經(jīng)理、開發(fā)分組經(jīng)理、產(chǎn)品經(jīng)理、測試、開發(fā)一般都會到。

如果是我們測試小組開會，一般都要到，各位測試同事報告自己的心得體會，匯報自己的進度和問題。

22、數(shù)據(jù)庫查找兩個表

回答思路：

多表查詢，后面具體會學到：select 列1，列2 from 表1,表2 where 表1.列=表2.列 這樣的格式要能說出來。

23、熟悉數(shù)據(jù)庫嗎？平時數(shù)據(jù)庫用的多嗎？

熟悉數(shù)據(jù)庫嗎：比較熟，比如DML語句有增刪改查：（有序思維說出來）

1 insert into 表名 values（值1，值2，值3，…）

2 delete from 表名 where 條件

3 update 表名 set 列名 = 新值

4 select * from 表名

查詢語句最長的是 select * from 表名 where 條件 group by 分組列名 having 分組后的條件 order by 列名。

平時數(shù)據(jù)庫用的多嗎（大概測試過程的1/4時間在查數(shù)據(jù)庫）：還行，一般出現(xiàn)問題，遇到bug，就要去查詢數(shù)據(jù)庫，初步定為問題。開發(fā)會給到我們一個庫表設(shè)計的excel（數(shù)據(jù)字典），里面有描述表名和表中的字段，我把交易過程的一些唯一標識，把他作為where條件去查詢數(shù)據(jù)。初步分析后，再把問題暴露給開發(fā)。（比如淘寶支付時，輸入支付密碼后，已經(jīng)返回了支付成功的提示信息，然后界面上的訂單查詢還是待付款，這個時候就要去查詢訂單表的數(shù)據(jù)，找到自己剛才做的交易的那一筆訂單，去分析一下錯誤，再暴露給開發(fā)）

24、linux查看文件用什么命令，查看進程用什么命令？

回答：

查看文件內(nèi)容的命令有 more less head tail cat tac

查看進程：ps -ef | grep 進程號

查看日志文件常用:less、view

查看日志常用什么命令，主要查看什么內(nèi)容

查看日志常用less命令或者view命令。

主要查看程序運行的記錄，比如支付失敗，后臺就有報錯信息打印到.log日志文件中，就可以通過分析日志信息來初步定為問題。（補充：同時也去查詢數(shù)據(jù)庫，分析訂單數(shù)據(jù)，查看支付狀態(tài)等等）

PS:日志就是.log的文本文件，和.txt一樣屬于文本文件。vi或者vim編輯器屬于記事本軟件，一般不會用來查看日志。

25、如何查找a.log日志文件的error字符串？

第一種方式：（建議說第一種方式）

cat a.log | grep error;

第二種方式：

1 less a.log;

2 /error;

你所熟悉的linux命令

linux：cat,more,less,head -n，tail -n，find ,| grep,ps -ef,tar,gzip,mv,cp,touch,mkdir，vi,top

也可以結(jié)合搭建環(huán)境的過程說用到的命令。

26、如果領(lǐng)導分配你的任務(wù)超出負荷，領(lǐng)導高估了你的能力，怎么辦？

回答思路：

首先表達態(tài)度，態(tài)度上愿意通過加班來完成，還可以請求測試同事支援，讓組長協(xié)調(diào)。

高估了能力，能力可以在工作中通過自己的努力來達到領(lǐng)導的要求

總而言之基本的思路是態(tài)度要端正。

不能直接拒絕任務(wù)。但也同時表達萬一做不好還請領(lǐng)導包容。

27、假設(shè)你是組長，團隊中有一個員工無法按時完成交付的任務(wù)，你如何處理？

回答思路：

首先先檢討自己是否任務(wù)安排超過了這個員工的能力。

如果沒有超過，首先表示關(guān)心身體和狀態(tài)，了解未及時完成任務(wù)的原因，如果原因是客觀原因則一起加班跟員工來完成任務(wù)。

如果是態(tài)度原因，則指出利害關(guān)系，責令其通過加班來完成。

28、如果因為你的錯誤導致工作發(fā)生問題，你怎么辦？

回答思路：

首先要表達在過去的工作中從未發(fā)生過類似事情，因為自己工作態(tài)度還是很端正的。

萬一因為自己的錯誤導致工作發(fā)生問題，首先應(yīng)該把問題上報給領(lǐng)導，爭取把問題的影響降到最低程度。

29、給你一個模塊測試，只有一個星期的時間你如何有效率地完成？

答：在有限的時間里，明確需求的情況下，制定工作計劃，把每天任務(wù)細分，先保證重要功能，跟進修復情況，及時驗證bug。每天發(fā)工作日報，匯報進度，如果遇到風險，及時匯報領(lǐng)導。

30、如果給你一個沒有需求的app測試項目，你應(yīng)該怎么測？

建議：根據(jù)APP的 11大測試點；

權(quán)限測試

安裝、運行、卸載測試

UI測試

功能測試

性能測試

中斷測試

兼容測試

安全測試

回歸測試

升級更新測試

用戶體驗測試

補充：根據(jù)自己的經(jīng)驗，制定測試計劃，每天匯報自己的進度，發(fā)出測試日報。

測試過程有問題，及時上報，及時跟進bug，多和開發(fā)交流溝通，明確需求。

21、如果你和開發(fā)的意見產(chǎn)生分歧，你怎么處理？

回答思路：

大的原則是對事不對人。

另外我會首先嘗試站在開發(fā)的角度接受對方的意見和建議，同時控制好自己的情緒，在對方情緒可控的情況下表達自己的意見。

32、如果你組長的用例寫錯了，但他認為是對的，你怎么處理？

回答：

通常情況下，領(lǐng)導看問題的角度會比我們更全面，所以我首先得確保領(lǐng)導的用例是否真的有考慮不到的地方。

我不會堅持自己的是對的，但會在合理的情況下表達自己的觀點。

33、你同時負責功能和性能，你怎么做？

先測成功能，保證功能的完成，再做性能，在提交bug后，開發(fā)還沒改好時，可以準備性能測試，在工作時間很緊的情況下會主動加班

34、我們公司自動化測試用的語言是Java，Java你不會，該怎么辦？

回答思路：

問到不會的標準思路：要么說會一點相關(guān)的內(nèi)容，要么表達自己有不錯的學習能力和很好的學習意愿和態(tài)度。

我們學了Java了就說會，知道面向?qū)ο蟮姆庋b，繼承，多態(tài)，知道多線程的兩種創(chuàng)建方式（自定義子類繼承Thread類，或者自定義子類實現(xiàn)Runable接口），還知道異常Throwable，Exception的格式，try catch finally。知道List， Set，Map集合。我可以很快的學會用Java做自動化。

35、以前的項目是怎么管理的？

回答思路：

我們以前的項目是用禪道來做測試的需求管理、用例管理、缺陷管理的。另外版本管理工具使用的是SVN。

36、以前的項目每天需要執(zhí)行多少用例？

回答思路：

正常情況一般每天執(zhí)行20個左右的用例，剛開始測試的時候，bug比較多，需要很多時間和開發(fā)交流溝通

案例執(zhí)行會比較慢。越到后面就越快了。

37、你們做回歸測試的時候是否全部都做呢？

看時間，如果時間比較充足，會全部回歸，回歸時候因為自己操作比較熟練，然后系統(tǒng)基本上也沒有bug。所以執(zhí)行案例的速度會比較快。

如果時間比較緊，就會挑選重要模塊來回歸測試了。

PS:自己組織好語言。

38、你們怎么確保用例覆蓋率？確保不重復？

利用判定表法的思想，先窮舉，再挑代表。

然后，案例評審時候產(chǎn)品經(jīng)理、開發(fā)組長、測試組長，還有對應(yīng)模塊的開發(fā)負責人也會把關(guān)，可以咨詢他們意見，確保案例即覆蓋完全，又沒有多余的重復案例。

我整理了一波之前發(fā)布的軟件測試資源【點擊文末小卡片免費領(lǐng)取】，無套路領(lǐng)取！

基本涵蓋了軟件測試 的全部核心技術(shù)點：測試理論，Linux 基礎(chǔ)，MySQL 基礎(chǔ)，Web 測試，接口測試，App 測試，管理工具，Selenium 相關(guān)，性能測試，計算機網(wǎng)絡(luò)，組成原理，數(shù)據(jù)結(jié)構(gòu)與算法，邏輯題，人力資源，技術(shù)腦圖等等…質(zhì)量非常高！！！應(yīng)對技術(shù)面試綽綽有余！

39、你們案例是怎么評審的？

評審時候有產(chǎn)品經(jīng)理（SR）、測試同事、開發(fā)同事，評審時候一般產(chǎn)品經(jīng)理（SR）、測試組長、對應(yīng)模塊的開發(fā)同事會提出一點意見，評審完之后，回去修改、補充一下案例。

修改完以后，有兩種處理情況：

對大項目有時候要進行案例的第二次評審。

對小項目，在時間緊的時候，一般不會二審，但是要以郵件的形式把修改或者新增后的案例發(fā)出來，給領(lǐng)導看，并抄送給其他同事。（案例評審0.5天，修改案例0.5天，案例二審0.5天）。

40、視圖是什么?

視圖記錄了一條SQL語句，當查詢時才有數(shù)據(jù)返回。表就是一張具體的表。視圖只能查詢數(shù)據(jù)，表可以增刪改查。

人力面試

1、為什么轉(zhuǎn)做測試

回答思路：

大學就通過互聯(lián)網(wǎng)了解軟件測試，了解IT，自己也比較喜歡，然后也選修了C語言或者Java語言來學。

在大四之前的暑假，在松勤培訓過軟件測試。

2、加班出差能接受嗎，加班能接受嗎?

回答思路：

通常如果這個問題被問題，是絕對不能直接說不接受的，能接受出差，還沒有男/女朋友。

搞IT一般都要加班，我以前也是這么加的，沒問題。

站在自己的角度說：還年輕，希望能在短時間內(nèi)提高自己的能力和積累更豐富的經(jīng)驗，加班是沒有問題的。

3、說說你自己與眾不同的地方和性格上的缺陷以及你準備如何改善？

回答思路：

其實這個問題就是回答優(yōu)缺點。

性格本身是一種習慣，說以你應(yīng)該表示通過優(yōu)化自己的行為習慣來改變自己的缺點。

向身邊的榜樣學習，就是學最好的別人，做最完美的自己。

4、在學校時參加過社團嗎、當過最高的職位，會協(xié)調(diào)嗎？

回答：

如果有就更好，這個能夠體現(xiàn)自己的協(xié)調(diào)能力、組織能力、溝通能力。這些對于工作很重要。要講一兩件具體的事情，把能力通過事情體現(xiàn)出來。

5、領(lǐng)導和追隨者你認為自己適合哪個？

回答：

領(lǐng)導是帶領(lǐng)和指導，一般通用的回答要是領(lǐng)導，因為自己可以以身作則，技術(shù)上也能對下屬有一定的指導能力。

6、以往工作經(jīng)驗

回答：

在忙碌的工作當中，既充實，又有成就感。通過不斷的測試，我的溝通能力、協(xié)調(diào)能力得到了提高，同時還收獲了行業(yè)知識經(jīng)驗等，深刻感受到了團體精神的重要性。

8、為什么要從事軟件測試？

回答：

自己非常喜歡互聯(lián)網(wǎng)，喜歡it，我覺得這一行非常有前景，馬云說現(xiàn)在已經(jīng)世界已經(jīng)進入第三次工業(yè)革命了，就是信息技術(shù)革命。計算機發(fā)展速度很快，互聯(lián)網(wǎng)公司可以利用短短幾年時間到達傳統(tǒng)行業(yè)過去要幾十年才能達到的境界。

9、過去工作中最有成就的事情是什么？

回答思路：

基本原則是要謙卑，談不上最有成就的事情。

如果非得要說有的話從某一件事情上收獲頗多，克服了什么樣的困哪等。

10、試用期、轉(zhuǎn)正期望工資多少？

回答思路：

首先要說其實工資不是最關(guān)鍵的，然后給一個500元范圍浮動的值

一線城市工資應(yīng)屆生最低6000，畢業(yè)一年7000，畢業(yè)兩年8000，畢業(yè)三年9000以上。小編給的是最低標準，大家看根據(jù)自己學習情況，適當調(diào)整，比如學的不錯的同學，兩年工作經(jīng)驗提10000沒有問題的。

如果問你上一家公司工資多少，就說出比你現(xiàn)在期望工資少個500元的值。

總結(jié)

最后祝大家都能找到心儀的工作，快樂工作，幸福生活，廣闊天地，大有作為。我也整理了一波之前發(fā)布的軟件測試文檔【點擊文末小卡片免費領(lǐng)取】，無套路領(lǐng)取！

整份文檔一共有308 頁，全部為大家展示出來肯定是不太現(xiàn)實的，為了不影響大家的閱讀體驗就只展示了部分內(nèi)容，還望大家海涵，希望能幫助到您面試前的復習且找到一個好的工作，也節(jié)省大家在網(wǎng)上搜索資料的時間來學習！

同時，在這我為大家準備了一份軟件測試視頻教程（含面試、接口、自動化、性能測試等），就在下方，需要的可以直接去觀看，也可以直接【點擊文末小卡片免費領(lǐng)取資料文檔】

軟件測試視頻教程觀看處：