1、你的測試職業(yè)發(fā)展是什么?
測試經(jīng)驗越多,測試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間積累的,一步步向著(zhù)高級測試工程師奔去。而且我也有初步的職業(yè)規劃,前3年積累測試經(jīng)驗,按如何做好測試工程師的要點(diǎn)去要求自己,不斷更新自己改正自己,做好測試任務(wù)。
   優(yōu)勢在于我對測試堅定不移的信心和熱情,雖然經(jīng)驗還不夠,但測試需要的基本技能我有信心在工作中得以發(fā)揮。

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

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

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

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

4、測試的目的是什么?

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

5、測試分為哪幾個(gè)階段?

一般來(lái)說(shuō)分為5個(gè)階段:?jiǎn)卧獪y試、集成測試、確認測試、系統測試、驗收測試

6、單元測試的測試對象、目的、測試依據、測試方法?

測試對象是模塊內部的程序錯誤,目的是消除局部模塊邏輯和功能上的錯誤和缺陷。測試依據是模塊的詳細設計,測試方法是采用白盒測試。

7、怎樣看待加班問(wèn)題

加班的話(huà)我沒(méi)有太多意見(jiàn),但是我還是覺(jué)得如果能夠合理安排時(shí)間的話(huà),不會(huì )有太多時(shí)候加班的。

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

  根據我以前的工作和學(xué)習經(jīng)驗,我認為做好工作首先要有一個(gè)良好的溝通,只有溝通無(wú)障礙了,才會(huì )有好的協(xié)作,才會(huì )有更好的效率,再一個(gè)就是技術(shù)一定要過(guò)關(guān),做測試要有足夠的耐心,和一個(gè)良好的工作習慣,不懂的就要問(wèn),實(shí)時(shí)與同事溝通這樣的話(huà)才能做好測試工作。
9、你為什么選擇軟件測試行業(yè)
因為之前了解軟件測試這個(gè)行業(yè),覺(jué)得他的發(fā)展前景很好。

10、根據你以前的工作或學(xué)習經(jīng)驗描述一下軟件開(kāi)發(fā)、測試過(guò)程,由哪些角色負責,你做什么

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

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

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

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

  需求調查:全面了解系統概況、應用領(lǐng)域、軟件開(kāi)發(fā)周期、軟件開(kāi)發(fā)環(huán)境、開(kāi)發(fā)組織、時(shí)間安排、功能需求、性能需求、質(zhì)量需求及測試要求等。根據系統概況進(jìn)行項目所需的人員、時(shí)間和工作量估計以及項目報價(jià)。
  制定初步的項目計劃。
  測試準備:組織測試團隊、培訓、建立測試和管理環(huán)境等。
  測試設計:按照測試要求進(jìn)行每個(gè)測試項的測試設計,包括測試用例的設計和測試腳本的開(kāi)發(fā)等。
  測試實(shí)施:按照測試計劃實(shí)施測試。
測試評估:根據測試的結果,出具測試評估報告。

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

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

14、說(shuō)說(shuō)你對軟件配置管理的理解

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

15、怎樣寫(xiě)測試計劃和測試用例

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

16、什么是兼容性測試?兼容性測試側重哪些方面?  

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行,即是通常說(shuō)的軟件的可移植性。
  兼容的類(lèi)型,如果細分的話(huà),有平臺的兼容,網(wǎng)絡(luò )兼容,數據庫兼容,以及數據格式的兼容。
兼容測試的重點(diǎn)是,對兼容環(huán)境的分析。通常,是在運行軟件的環(huán)境不是很確定的情況下,才需要做兼容。根據軟件運行的需要,或者根據需求文檔,一般都能夠得出用戶(hù)會(huì )在什么環(huán)境下使用該軟件,把這些環(huán)境整理成表單,就得出做兼容測試的兼容環(huán)境了。
兼容和配置測試的區別在于,做配置測試通常不是Clean OS下做測試,而兼容測試多是在Clean OS的環(huán)境下做的。
 
17、我現在有個(gè)程序,發(fā)現在Windows上運行得很慢,怎么判別是程序存在問(wèn)題還是軟硬件系統存在問(wèn)題?
--1、檢查系統是否有中毒的特征;  
--2、檢查軟件/硬件的配置是否符合軟件的推薦標準;  
--3、確認當前的系統是否是獨立,即沒(méi)有對外提供什么消耗CPU資源的服務(wù);  
--4、如果是C/S或者B/S結構的軟件,需要檢查是不是因為與服務(wù)器的連接有問(wèn)題,或者訪(fǎng)問(wèn)有問(wèn)題造成的;  
--5、在系統沒(méi)有任何負載的情況下,查看性能監視器,確認應用程序對CPU/內存的訪(fǎng)問(wèn)情況。

18、測試的策略有哪些?

黑盒/白盒,靜態(tài)/動(dòng)態(tài),手工/自動(dòng),冒煙測試,回歸測試,公測(Beta測試的策略)

19、你覺(jué)得bugzilla在使用的過(guò)程中,有什么問(wèn)題?

--界面不穩定;  
--根據需要配置它的不同的部分,過(guò)程很煩瑣。
--流程控制上,安全性不好界定,很容易對他人的Bug進(jìn)行誤操作;
--沒(méi)有綜合的評分指標,不好確認修復的優(yōu)先級別。

20、描述測試用例設計的完整過(guò)程?

--1、需求分析 + 需求變更的維護工作;
--2、根據需求得出測試需求;
--3、設計測試方案,評審測試方案;
--4、方案評審通過(guò)后,設計測試用例,再對測試用例進(jìn)行評審;

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

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

22、LoadRunner分哪三部分?

用戶(hù)動(dòng)作設計;場(chǎng)景設計;  測試數據分析;

23、LoadRunner進(jìn)行測試的流程?  

--1、 熟悉業(yè)務(wù)流程,測試規劃  
--2、 創(chuàng )建虛擬用戶(hù)腳本
--3、 創(chuàng )建運行場(chǎng)景
--4、 運行測試腳本
--5、 監視場(chǎng)景
--6、 分析測試的結果
  以上,最好是結合一個(gè)案例,根據以上流程來(lái)介紹。

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

在正式的會(huì )議上將軟件項目的成果(包括各階段的文檔、產(chǎn)生的代碼等)提交給用戶(hù)、客戶(hù)或有關(guān)部門(mén)人員對軟件產(chǎn)品進(jìn)行評審和批準。其目的是找出可能影響軟件產(chǎn)品質(zhì)量、開(kāi)發(fā)過(guò)程、維護工作的適用性和環(huán)境方面的設計缺陷,并采取補救措施,以及找出在性能、安全性和經(jīng)濟方面的可能的改進(jìn)。
人員:用戶(hù)、客戶(hù)或有關(guān)部門(mén)開(kāi)發(fā)人員,測試人員,需求分析師都可以,就看處于評審那個(gè)階段

25、Beta測試與Alpha測試有什么區別?

--Beta testing(β測試),測試是軟件的多個(gè)用戶(hù)在一個(gè)或多個(gè)用戶(hù)的實(shí)際使用環(huán)境下進(jìn)行的測試。開(kāi)發(fā)者通常不在測試現場(chǎng)
--Alpha testing (α測試),是由一個(gè)用戶(hù)在開(kāi)發(fā)環(huán)境下進(jìn)行的測試,也可以是公司內部的用戶(hù)在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測試

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

軟件測試計劃就是在軟件測試工作正式實(shí)施之前明確測試的對象,并且通過(guò)對資源、時(shí)間、風(fēng)險、測試范圍和預算等方面的綜合分析和規劃,保證有效的實(shí)施軟件測試;
  做好測試計劃工作的關(guān)鍵 :目的,管理,規范
1)、明確測試的目標,增強測試計劃的實(shí)用性編寫(xiě)軟件測試計劃得重要目的就是使測試過(guò)程能夠發(fā)現更多的軟件缺陷,因此軟件測試計劃的價(jià)值取決于它對幫助管理測試項目,并且找出軟件潛在的缺陷。因此,軟件測試計劃中的測試范圍必須高度覆蓋功能需求,測試方法必須切實(shí)可行,測試工具并且具有較高的實(shí)用性,便于使用,生成的測試結果直觀(guān)、準確
2)、堅持“5W”規則,明確內容與過(guò)程5W”規則指的是“What(做什么)”、“Why(為什么做)”、“When(何時(shí)做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”規則創(chuàng )建軟件測試計劃,可以幫助測試團隊理解測試的目的(Why),明確測試的范圍和內容(What),確定測試的開(kāi)始和結束日期(When),指出測試的方法和工具(How),給出測試文檔和軟件的存放位置(Where)。
3)、采用評審和更新機制,保證測試計劃滿(mǎn)足實(shí)際需求測試計劃寫(xiě)作完成后,如果沒(méi)有經(jīng)過(guò)評審,直接發(fā)送給測試團隊,測試計劃內容的可能不準確或遺漏測試內容,或者軟件需求變更引起測試范圍的增減,而測試計劃的內容沒(méi)有及時(shí)更新,誤導測試執行人員。
4)、分別創(chuàng )建測試計劃與測試詳細規格、測試用例應把詳細的測試技術(shù)指標包含到獨立創(chuàng )建的測試詳細規格文檔,把用于指導測試小組執行測試過(guò)程的測試用例放到獨立創(chuàng )建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術(shù)的關(guān)系,測試計劃主要從宏觀(guān)上規劃測試活動(dòng)的范圍、方法和資源配置,而測試詳細規格、測試用例是完成測試任務(wù)的具體戰術(shù)。

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

需求和設計文檔的理解程度,對系統的熟悉程度

28、簡(jiǎn)述一下缺陷的生命周期?

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

29、軟件的安全性應從哪幾個(gè)方面去測試?

(1) 用戶(hù)認證機制:如數據證書(shū)、智能卡、雙重認證、安全電子交易協(xié)議
(2) 加密機制  
(3) 安全防護策略:如安全日志、入侵檢測、隔離防護、漏洞掃描  
(4) 數據備份與恢復手段:存儲設備、存儲優(yōu)化、存儲保護、存儲管理
(5) 防病毒系統  
30、你覺(jué)得軟件測試通過(guò)的標準應該是什么樣的?  
缺陷密度值達到客戶(hù)的要求

31、一套完整的測試應該由哪些階段組成?

需求評審(有開(kāi)發(fā)人員,產(chǎn)品經(jīng)理,測試人員,項目經(jīng)理)->需求確定(出一份確定的需求文檔)>開(kāi)發(fā)設計文檔(開(kāi)發(fā)人員在開(kāi)始寫(xiě)代碼前就能輸出設計文檔)->想好測試策略,寫(xiě)出測試用例->發(fā)給開(kāi)發(fā)人員和測試經(jīng)理看看(非正式的評審用例)->接到測試版本->執行測試用例(中間可能會(huì )補充用例)->提交bug(有些bug需要開(kāi)發(fā)人員的確定(嚴重級別的,或突然發(fā)現的在測試用例范圍之外的,難以重現的),有些可以直接錄制進(jìn)TD)->開(kāi)發(fā)人員修改(可以在測試過(guò)程中快速的修改)->回歸測試(可能又會(huì )發(fā)現新問(wèn)題,再按流程開(kāi)始跑)
32、如何理解壓力、負載、性能測試測試?
性能測試是一個(gè)較大的范圍,實(shí)際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。
壓力測試是對服務(wù)器的穩定性以及負載能力等方面的測試,是一種很平常的測試。增大訪(fǎng)問(wèn)系統的用戶(hù)數量、或者幾個(gè)用戶(hù)進(jìn)行大數據量操作都是壓力測試。而負載測試是壓力相對較大的測試,主要是測試系統在一種或者集中極限條件下的相應能力,是性能測試的重要部分。100個(gè)用戶(hù)對系統進(jìn)行連續半個(gè)小時(shí)的訪(fǎng)問(wèn)可以看作壓力測試,那么連續訪(fǎng)問(wèn)8個(gè)小時(shí)就可以認為負載測試,1000個(gè)用戶(hù)連續訪(fǎng)問(wèn)系統1個(gè)小時(shí)也可以看作是負載測試。
實(shí)際上壓力測試和負載測試沒(méi)有明顯的區分。測試人員應該站在關(guān)注整體性能的高度上來(lái)對系統進(jìn)行測試。

33、如何編寫(xiě)提交給用戶(hù)的測試報告?

----根據內部測試報告進(jìn)行編寫(xiě),一般可以摘錄;
----不可以向客戶(hù)報告嚴重缺陷,即使是已經(jīng)修改的缺陷,開(kāi)發(fā)中的缺陷也沒(méi)有必要讓客戶(hù)知道;
----報告上可以列出一些缺陷,但必須是中級的缺陷,而且這些缺陷必須是修復的; -報告上面的內容盡量要真實(shí)可靠;
----整個(gè)測試報告要仔細審閱,力爭不給項目帶來(lái)負面作用,尤其是性能測試報告。

34、您所熟悉的測試用例設計方法都有哪些?請分別以具體的例子來(lái)說(shuō)明這些方法在測試用例設計工作中的應用。

.等價(jià)類(lèi)劃分   
劃分等價(jià)類(lèi): 等價(jià)類(lèi)是指某個(gè)輸入域的子集合.在該子集合中,各個(gè)輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價(jià)類(lèi)的代表值就等于對這一類(lèi)其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價(jià)類(lèi),在每一個(gè)等價(jià)類(lèi)中取一個(gè)數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價(jià)類(lèi)劃分可有兩種不同的情況:有效等價(jià)類(lèi)和無(wú)效等價(jià)類(lèi).   
2.邊界值分析法   
邊界值分析方法是對等價(jià)類(lèi)劃分方法的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
  使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價(jià)類(lèi)的邊界,就是應著(zhù)重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價(jià)類(lèi)中的典型值或任意值作為測試數據.     
3.錯誤推測法   
基于經(jīng)驗和直覺(jué)推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時(shí)曾列出的許多在模塊中常見(jiàn)的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現的錯誤等, 這些就是經(jīng)驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用例.     
4.因果圖方法   
前面介紹的等價(jià)類(lèi)劃分方法和邊界值分析方法,都是著(zhù)重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會(huì )產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類(lèi),他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產(chǎn)生多個(gè)動(dòng)作的形式來(lái)考慮設計測試用例. 這就需要利用因果圖(邏輯模型). 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.

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

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

36、當開(kāi)發(fā)人員說(shuō)不是BUG時(shí),你如何應付?

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

37、寫(xiě)出bug報告當中一些必備的內容。  

   硬件平臺和操作系統
   測試應用的硬件平臺(Platform),通常選擇“PC”。
   測試應用的操作系統平臺(OS)。
  a) 版本    提交缺陷報告時(shí)通過(guò)該字段標識此缺陷存在于被測試軟件的哪個(gè)版本。
  b) Bug報告優(yōu)先級
  c) Bug狀態(tài)
d) Bug的編號
e) 發(fā)現人
f) 提交人
g) 指定處理人
h) 概述
i) 從屬關(guān)系
j) 詳細描述
k) 嚴重程度
l) 所屬模塊
m) 附件
n) 提交日期
 
38、開(kāi)發(fā)人員老是犯一些低級錯誤怎么解決?
從兩個(gè)方面入手:
  一方面從開(kāi)發(fā)管理入手,也就是從根源來(lái)解決問(wèn)題??梢灾贫ㄒ幏兜拈_(kāi)發(fā)流程,甚至可以制定懲罰制度,還有就是軟件開(kāi)發(fā)前做好規劃設計。
  另一方面就是加強測試,具體做法就是加強開(kāi)發(fā)人員的自己測試,把這些問(wèn)題“消滅”在開(kāi)發(fā)階段,這是比較好的做法。

39、簡(jiǎn)述一下c/s模式或者b/s模式?

C/S模式:客戶(hù)端/服務(wù)器模式。工作原理:Client向Server提交一個(gè)請求;Server則使用一些方法處理這個(gè)請求,并將效果返回給Client。
  B/S結構,即Browser/Server(瀏覽器/服務(wù)器)結構,主要是利用了不斷成熟的WWW瀏覽器技術(shù),結合瀏覽器的多種Script語(yǔ)言(VBScript、JavaScript…)和ActiveX技術(shù),用通用瀏覽器就實(shí)現了原來(lái)需要復雜專(zhuān)用軟件才能實(shí)現的強大功能,并節約了開(kāi)發(fā)成本,是一種全新的軟件系統構造技術(shù)。