第一篇：互聯網Web測試用例設計思路與方法（共）

互聯網Web測試用例設計思路與方法

互聯網Web測試用例設計思路

1、Web測試用例設計思路：主要是Web測試用例操作與界面流程，我們為什么在心中有思路，但是寫測試用例就無從下手，那就是一個人在做了ERP內部系統測試后，再從事Web測試工作，寫測試用例的時候就會模仿以前的工作經驗去編寫測試用例，所以編寫出的測試用例重復性的用例比較多，執行力也比較少。

2、Web測試用例設計思路：看到上面第一點的朋友，如果你是這樣的話，這條就是教你如果去放開思路編寫用例，我們每個公司的企業文化里面都會含有一個字的文化，那就是“創新”，為什么要選擇創新沒，大家都知道沒有創新的公司，就會必死，就像諾基亞的塞班系統一樣，塞班系統以前10年多輝煌的歷史，轉眼就被安卓取代，為什么就是塞班系統升級時，會重構與重寫很多代碼，代碼只會增加沒有大多減少，使系統運行起來慢。我們編寫測試用例一樣要學會創新，不能用以前行業的思路對現在的行業來進行工作。我們要放開思路大膽的去設想一些可能發生的事情。

上面2點主要是教大家，如何去理解項目，如何去放開思路，創新用例。（可能大家沒看出什么含義，大家不要擔心，請開下面的設計用例的方法吧！）

互聯網Web測試用例設計方法

1、按照模塊設計用例

為什么要按照模塊設計用例呢？因為互聯網Web有成千上萬的連接，里面也含有相同的跳轉頁面地址，也有模塊單獨分立，如：搜索、導航、友情連接、留言等都是獨立的頁面，也是屬于Web頁面中的模塊。

2、按照主要功能設計用例

為什么要按照主要功能設計用例呢？因為我剛剛說了Web頁面中有成千上萬的連接，很多連接其實都是只想一個頁面，如：首頁里面包含、新聞、資料、文章，我們點擊不同的頁面就好進入不同的詳細頁。這時我們只有按照功能進行用例的設計，這樣可以減少用例的重復性。

3、按照需求與項目流程設計用例

為什么要按照項目流程設計用例呢？其實我們拿手中的資料基本上都是項目的整理流程圖與項目需求文檔規格書，如果項目是一個新的項目話，我們沒有預覽網站，那就要使用項目流程與需求文檔來設計用例了，因為為什么往往看到的只有一個大致的首頁圖，我們從何下手，那就是要放開思路膽大設計了，為什么并不了解產品部要怎么實現這個功能，我們只有了解需求與開發溝通才能設計好的用例，很像敏捷測試吧，但不是哦！當功能與項目開發完畢后，我們要對用例的重整操作，因為我們設計的用例，有些并不符合邏輯，有些并不符合實際，所有這個流程是并不可少的。這樣用的設計我并不推薦。但這樣的設計方法最大的優勢就是，我們可以完完全全的貫穿這個項目與系統。

第二篇：測試用例設計步驟

測試用例設計步驟

設計測試案例的時候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟件測試的技術和流程，而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。測試用例設計一般包括以下幾個步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。測試需求應該在軟件需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關系是多對一的關系，即一個或多個測試用例集對應一個測試需求。

2、業務流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟件產品的業務流程。建議在做復雜的測試用例設計前，先畫出軟件的業務流程。如果設計文檔中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流程，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟件的處理邏輯和數據流向，從而指導測試用例的設計。

從業務流程上，應得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數據流向是什么

D、關鍵的判斷條件是什么

3、測試用例設計

完成了測試需求分析和軟件流程分析后，開始著手設計測試用例。測試用例設計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設計測試用例的時候可以使用軟件測試用例設計方法，結合前面的需求分析和軟件流程分析進行設計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是

可能發生的，類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值

分析、內部邊界值測試。

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部

性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包

括響應時間，吞吐量等。

適合的技術：業務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不

同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設計完成后，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。

第三篇：業務流程類測試用例的設計

業務流程類測試用例的設計

最近做的這個系統是強調業務流程的，感覺和以前的純功能的系統還是有區別，首先要做的是對業務需求的理解，在流程一致的前提下，再確定功能模塊的正確與否。在網上也參考了一些前輩的經驗，感覺很有道理的。

業務流程測試用例編寫原則以需求分析中的流程圖做為編寫測試用例的模型，堅持“試驅動開發，用例指導結果，數據記錄變化”的原則，靈活使用不同的方法制定測試用例。業務用例的構造要先于程序實現，與需求和開發人員溝通一致，并以此作為一個基準，保證程序實現不會錯，還能對整個軟件的進度和質量有一個很好的估計和度量。業務用例可以不關注程序的界面，但一定要有數據的支持。

測試用例編寫時要分開寫，在編碼前就應該確定業務流程用例，編碼時進行系統功能測試用例的設計編寫。系統測試業務流程用例的目的在于驗證軟件最終數據的準確性.我們的軟件體現為,手工數據與報表數據的一直性.用例與用例之間有著一定的關系,目的性十分明確。

在業務流程的分析上，我們應該得到以下信息：

1）系統的主流程是什么

2）條件備選流程是什么

3）數據流向是什么

4）關鍵的判斷條件是什么

作為測試人員，在測試過程中要關注的是流程的走向是否正確，同時關注流程節點數值和輸出值的變化來設計用例。

我覺得一個測試人員首先應該具有需求分析人員的能力（或者說要承擔起需求分析的責任來），只有這樣才會在整個項目中貫穿始終，而且最重要的是有助于測試的進行，測試時會更多的站在用戶的角度去考慮，這樣的系統才會是實際可用的。

第四篇：如何快速設計接口測試用例（定稿）

接口測試是項目測試的一部分，它測試的主要對象是接口，是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與所測系統之間以及內部各系統之間的交互點。測試的重點是檢查數據交互、傳遞、和控制管理過程以及系統間的相互依賴關系等。

如何設計接口測試用例？

首先，明確出發點，和所有的測試一樣，接口測試出發點是你要證明所測的程序是錯誤的。以這個出發點為導向，你的設計行為就會盡量朝這個方向，更易發現問題。

其次，選擇好測試對象。對于一個系統做接口測試選擇好的測試對象是接口測試關鍵。一個系統有無數的接口，每個接口如果分別測試，那將是很痛苦的一件事情，而且任何一個內部接口的變動，都將導致我們用例的不可用。可將這些最外層的接口分為兩類：一類是數據進入系統的接口；一類是數據流出系統的接口。進入系統的接口實際是我們用例的執行調用的接口。可通過變化參數對這些接口進行調用，模擬外部的使用；而流出的接口則是我們用例真正該驗證的點。數據從哪里流出，流出時的狀態如何，此時系統又是什么狀態都是我們所應該驗證的。

然后，確認完整的測試對象的功能：確認外部接口提供給使用這些接口的外部用戶什么樣的功能，外部用戶真正需要什么樣的功能。此兩個功能一定要準確詳細，用例的設計要嚴格按照測試對象功能設計才是正確的用例。

最后當出發點、對象、功能都確定了，就可以真正設計用例了。下面詳細介紹下如何去設計一個結構好、可讀性高、滲透性強的接口測試用例。

接口測試用例設計和測試用例設計一樣，用例設計的內容應該包括：主要測試功能點、測試環境、測試數據、執行操作以及預期結果。1）接口測試環境分為兩種：一種是程序內部的環境；一種是程序的所調用外部接口的環境。2）接口測試測試數據分為接口參數數據和用例執行所需系統數據。數據的設計、準備測試用例的數據上需要花費更多的心思。要通過好的測試數據使用例查找問題。接口參數數據需對每個參數根據測試接口的實際的功能進行分析，在符合業務邏輯的情況下進行邏輯組合排列，不要遺漏了某些邊界值和錯誤點的數據。每個用例執行所需系統數據和接口參數數據盡可能的采用不一樣的數據，使用例更容易發現問題。3）測試功能點，如果一個接口功能復雜時推薦對接口用例進行結構劃分，這樣子用例具有更好的可讀性和維護性。接口劃分原則為以接口提供的功能點的不同進行合適粒度的劃分。同一功能點的用例又可根據測試環境的不同、數據的不同進行用例的填充。

4）接口測試用例執行操作非常簡單，就是所測接口的調用。5）預期結果驗證，這也是接口用例設計的很關鍵的一步，應該細而不冗余。每個用例均需驗證，避免一個用例中重復做相同的驗證，提高測試用例的效率。如何設計接口測試用例小例子： 簡單劃分可以按照2個基本組成要素進行劃分：1.參數 2.業務 以下為最簡單的一種劃分用例的方法，可能涵蓋不全，但只為說明一種劃分接口用例的方法方式以及需要考慮的測試用例的測試點 為何要如此設計，是為了更好的將用例分類為程序規定型以及業務限制型，盡量的保證覆蓋，盡量細化到點的劃分形式來保證工作時間的預估和計劃。所有的自動化接口的測試用例 都基本圍繞三部曲進行，傳數據，執行，校驗返回的數據和期望數據是否一致來構成每個簡單的測試用例。有清晰的線路和清晰的思維，才能做好整體測試的掌控。

第五篇：常見的測試用例設計方法都有哪些

/ 6

（常見）測試用例-設計方法-面試題目

常見的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

1.等價類劃分

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

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

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

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

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

6.場景分析方法

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

您認為做好測試用例設計工作的關鍵是什么？

白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果

黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題

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

1.項目經理通過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功

能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。然后sqa進入項目，開始進行統計和跟蹤

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

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

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

5.測試人員搭建環境

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

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

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

9.如果有客戶反饋的問題，需要測試人員協助重現以及回歸測試。

以往是否曾經從事過性能測試工作？請盡可能的詳細描述您以往的性能測試工作的完整過程。

曾經做過一套網管系統的性能測試，主要測試該軟件在同時管理大量終端的情況下，在響應時間，cpu/磁盤/內存等參數是否滿足要求。

也曾經做過軟交換系統的呼叫性能測試，主要是測試軟交換系統在有大量呼叫的情況下，響應時間，呼叫成功率，cpu/磁盤/內存等參數是否滿足設計要求。

您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。

測試網管系統中，使用的mimic來模擬終端，能夠大量的節省成本。

測試軟交換系統的時候，使用的prolab來模擬終端并發送呼叫軟交換，他完成了同時數百人才能完成的摘機撥號工作，主要工作原理是產生一些符合要求的ip包并發送給軟交換系統，同時對軟交換系統的回應進行處理，決定下一步動作。

您認為性能測試工作的目的是什么？做好性能測試工作的關鍵是什么？

主要是保障在大量用戶的情況下，服務能正常使用。

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

1.在傳統的bugzilla中，bug描述應該包括以下的信息

2.和bug產生對應的軟件版本

3.開發的接口人員

4.bug的優先級

5.bug的嚴重程度

6.bug可能屬于的模塊，如果不能確認，可以用開發人員來判斷

7.bug標題，需要清晰的描述現象

8.bug描述，需要盡量給出重新bug的步驟

9.附件中能給出相關的日志和截圖。

高質量的bug記錄就是指很容易理解的bug記錄，所以，對于描述的要求高，能提供的信息多且準確，很好的幫助開發人員定位。

1、黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別？

軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。

黑盒測試主要是為了發現以下幾類錯誤：

1）是否有不正確或遺漏的功能？

2）在接口上，輸入是否能正確的接受？能否輸出正確的結果？

3）是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？

4）性能上是否能夠滿足要求？

5）是否有初始化或終止性錯誤？

白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。

白盒測試主要是想對程序模塊進行如下檢查：

1）對程序模塊的所有獨立的執行路徑至少測試一遍。

2）對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

3）在循環的邊界和運行的界限內執行循環體。

4）測試內部數據結構的有效性，等等。

單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。

系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）

系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求并且遵循系統設計。

驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。

驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

● 單元測試的主要目的是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗證過程中的邊界值的錯誤。

● 集成測試主要目的是針對詳細設計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。

● 系統測試主要針對概要設計，檢查了系統作為一個整體是否有效地得到運行，例如在產品設置中是否達到了預期的高性能

● 驗收測試通常由業務專家或用戶進行，以確認產品能真正符合用戶業務上的需要(需求)。

2、您認為做好測試計劃工作的關鍵是什么？

1）明確測試的目標，增強測試計劃的實用性

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

2）堅持“5W”規則，明確內容與過程

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

3）采用評審和更新機制，保證測試計劃滿足實際需求

測試計劃寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。

4）分別創建測試計劃與測試詳細規格、測試用例

應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用于指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

3、你認為公司的BUG測試流程是什么？

1）當測試工程師發現了一個bug而且在bug tracking tool里面沒有相同的bug, 他需要填寫所有需要的bug信息并且把這個bug分配給test leader

2）如果這個bug不是一個真正的bug, test leader需要close這個bug

3）test leader需要審查bug的各種信息都完備，如果有信息不完整，他需要把狀態改成”feedback” 并重新assign給提交者

4）如果這個bug是一個真正存在的bug, test leader需要把這個bug分配給相關的開發團隊的PM, 并且把bug狀態改成Assigned

5）如果這個bug屬于另外一個開發團隊，PM需要把這個bug重新分配給那個開發團隊的PM

6）PM審查bug,并且分配給相應的開發人員去改正。

7）開發人員收到bug以后，對相關的缺陷進行改正，并且重新分配給提交bug的測試人員并且把狀態改成”Fixed”

8）測試人員需要對這個bug進行重新測試，保證相關的缺陷已經改正，測試人員可以reopen這個bug如果缺陷依然存在并且重新分配給相關的開發人員或者close這個bug如果缺陷已經改正。

4、測試人員所應具備的知識

1）基本的測試知識，測試方法，測試用例，缺陷的概念

2）測試計劃

3）數據方面(數據庫/XML/Hibernate/LDAP)

4）表現層知識(JSP/HTML/Struts/CSS)

5）EAI(中間件/SOA概念, 項目相關的經驗)

6）測試自動化知識

7）設計模式知識(UML等等)

8）敏捷實踐(TDD, Refectoring, CI等等)

9）軟件生命周期經驗(分析，設計，團隊開發，測試，部署)

10）管理經驗(Estimation, Mentoring, 團隊組織)

11）學習能力

5、測試類型共劃分為哪些？

1）功能測試：對軟件功能進行測試，檢查軟件的各項功能是否實現了軟件功能說明書（軟件需求）上的要求。

2）界面測試：對用戶界面進行測試，檢查用戶界面的美觀度、統一性、易用性等方面的內容。

3）流程測試：按操作流程進行測試，主要有業務流程、數據流程、邏輯流程、正反流程，檢查軟件在按照流程操作時是否能夠正確處理。

4）并發測試：在網絡環境、并發環境和多用戶條件下對軟件進行的測試。

5）極限測試：在軟件的極限條件下進行的測試，主要有對數據的極限值、邊界值操作，對軟件進行致命操作等。

6）數據處理測試：對軟件數據接口進行的測試，主要檢查軟件數據處理中輸入、處理、輸出數據過程。

7）安全測試：對軟件安全性方面的測試，主要檢測軟件中加密、解密、數據備份、恢復、病毒檢測等問題。

8）性能測試：對軟件整體性能的測試，測試內容有適應性、健壯性、可恢復性、災難恢復能力等

9）安裝測試：在不同PC條件、操作系統、模擬客戶機等條件下進行軟件的安裝測試，主要檢查軟件打包或發布之后存在的問題。

10）性能測試：對軟件整體性能進行測試，測試的內容有適應性、健壯性、可恢復性、災難恢復能力等

6、你是怎么看待測試的？

1）試想一下如果一個系統開發完畢后不能正常運行可能造成的后果，損失錢財，損失時間，損失客戶，等等

2）介紹一下軟件測試的意義

a.發現軟件錯誤；

b.有效定義和實現軟件成分由低層到高層的組裝過程；

c.驗證軟件是否滿足任務書和系統定義文檔所規定的技術要求；

d.為軟件質量模型的建立提供依據。

3）介紹一下軟件測試的目的？

a.確認軟件的質量，其一方面是確認軟件做了你所期望的事情（Do the right thing），并且確認軟件以正確的方式來做了這個事件（Do it right）。

b.提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。

c.軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。如果一個軟件產品開發完成之后發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發過程是高質量的。

正是基于以上所述，我認為軟件測試是整個軟件質量保證過程中重要的一部分，這也就是我選擇軟件測試這個行業的原因

7.如何撰寫集成測試計劃？

1）確定集成測試對象

2）確定集成測試策略

3）確定集成測試驗收標準

4）確定集成測試掛起和恢復條件

5）估計集成測試工作量

6）估計集成測試所需資源

7）進行集成測試任務劃分（包括任務名、責任人、輸入和輸出、風險及應對措施、進度安排等）

8.測試技術方面的鬼話？

1、功能測試的規范化、流程化操作；

2、利用Robot錄制和編寫自動功能測試腳本

3、利用LoadRunner進行性能測試執行

4、主流關系型數據庫（例如Oracle、SQLServer）的優化策略

5、非關系型數據庫（例如Trip）的配置、安裝、常用命令等

6、非Windows操作系統的安裝和常用命令

7、常用服務器的安裝、配置和優化策略（Weblogic，TomCat）

8、對系統存在的性能問題進行定位診斷

9、對系統存在的性能問題提出優化解決方案，并配合研發和集成人員進行系統調優

問hr的問題：

1.貴公司近期和遠期的發展目標是什么？

2.貴公司的主要競爭對手有哪些？

3.貴公司有多少開發人員有多少測試人員？

4.貴公司又進一步擴充測試人員的計劃嗎?

5.如果我有幸能進入貴公司的話，我有怎么樣的發展？

6.測試人員的溝通能力很重要，貴公司有規范的溝通渠道嗎？

7.請介紹一下貴公司的福利情況。

8.請問我什么時候能知道結果？