首先會(huì)召開(kāi)需求分析會(huì)議，參加人員有產(chǎn)品、開(kāi)發(fā)和測(cè)試，主要是探討需求主要的一些功能點(diǎn)，完了之后，開(kāi)發(fā)就排期進(jìn)行開(kāi)發(fā)，我們就根據(jù)主管寫(xiě)出來(lái)的計(jì)劃、分配到的任務(wù)編寫(xiě)測(cè)試用例，寫(xiě)完之后會(huì)進(jìn)行用例評(píng)審，有評(píng)審修改的就修改整理形成最終的用例版本，之后開(kāi)發(fā)人員版本編譯完成后，我們會(huì)依據(jù)測(cè)試用例來(lái)執(zhí)行測(cè)試，測(cè)試過(guò)程中，提交bug， 跟蹤bug，直至關(guān)閉，測(cè)試完后編寫(xiě)測(cè)試報(bào)告。

我的上家公司環(huán)境蠻不錯(cuò)的，整個(gè)項(xiàng)目組的成員都很團(tuán)結(jié)，氛圍很濃郁，遇到不懂的問(wèn)題我能夠和同事們進(jìn)行溝通，但是考慮到我自身發(fā)展的因素，我還是被迫辭職了

首先，將問(wèn)題提交到缺陷管理庫(kù)里面進(jìn)行備案。

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

如果沒(méi)有文檔依據(jù)，可以根據(jù)類(lèi)似軟件的一般特性來(lái)說(shuō)明是否存在不一致的地方，來(lái)確認(rèn)是否是缺陷；

根據(jù)用戶的一般使用習(xí)慣，來(lái)確認(rèn)是否是缺陷；與設(shè)計(jì)人員、開(kāi)發(fā)人員和客戶代表等相關(guān)人員探討，確認(rèn)是否是缺陷；合理的論述，向測(cè)試經(jīng)理說(shuō)明自己的判斷的理由，注意客觀、嚴(yán)謹(jǐn)，不參雜個(gè)人情緒。

等待測(cè)試經(jīng)理做出最終決定，如果仍然存在爭(zhēng)議，可以通過(guò)公司政策所提供的渠道，向上級(jí)反映，并由上級(jí)做出決定。

軟件生存周期是軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，是從可行性研究到需求分析、軟件設(shè)計(jì)、編碼、測(cè)試、軟件發(fā)布維護(hù)的過(guò)程。

在經(jīng)歷需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、部署后，軟件將被使用并進(jìn)入維護(hù)階段，直到最后由于缺少維護(hù)費(fèi)用而逐漸消亡。這樣的一個(gè)過(guò)程，稱(chēng)為"生命周期模型"（Life Cycle Model）。

系統(tǒng)測(cè)試是指針對(duì)軟件產(chǎn)品系統(tǒng)進(jìn)行的測(cè)試，是做完單元測(cè)試和集成測(cè)試后進(jìn)行的測(cè)試，總體包含功能測(cè)試與非功能測(cè)試。

功能測(cè)試是驗(yàn)證軟件系統(tǒng)功能是否實(shí)現(xiàn)系統(tǒng)需求規(guī)格的測(cè)試過(guò)程，而非功能測(cè)試是驗(yàn)證系統(tǒng)是否在實(shí)現(xiàn)功能測(cè)試的基礎(chǔ)上，測(cè)試系統(tǒng)的容錯(cuò)性、穩(wěn)定性、異常處理能力，以及高強(qiáng)度輸入的處理能力、可用性、性能等是否符合用戶要求的測(cè)試過(guò)程。

●界面測(cè)試

●功能測(cè)試

●可用性測(cè)試

●客戶端兼容性測(cè)試

●安全性測(cè)試

（1）黑盒測(cè)試也稱(chēng)功能測(cè)試，通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否都正常使用，測(cè)試中把程序看成一個(gè)黑盒子，在完全不考慮內(nèi)部程序結(jié)構(gòu)和特性的情況下 ，執(zhí)行測(cè)試。黑盒測(cè)試是以用戶角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系出發(fā)進(jìn)行的測(cè)試。 缺點(diǎn)是：發(fā)現(xiàn)不了本身設(shè)計(jì)或規(guī)格說(shuō)明的問(wèn)題。黑盒測(cè)試設(shè)計(jì)測(cè)試用例的方法包括：等價(jià)類(lèi)劃分法、邊界值分析法、判定表法、因果圖法、正交法、錯(cuò)誤猜測(cè)法等；

（2）白盒測(cè)試是基于代碼測(cè)試，白盒是指盒子是可視的，清楚內(nèi)部是如何運(yùn)作的，白盒測(cè)試人員要全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對(duì)所有的邏輯路徑進(jìn)行測(cè)試。 常用的白盒測(cè)試用例設(shè)計(jì)方法有：語(yǔ)句覆蓋法、判定覆蓋法、條件覆蓋法、判定條件覆蓋法、路徑覆蓋法 ；

冒煙測(cè)試是對(duì)應(yīng)用程序的重點(diǎn)功能進(jìn)行測(cè)試，主要是看測(cè)試的軟件主要功能能否實(shí)現(xiàn)，環(huán)境通不通

Why:為什么要進(jìn)行測(cè)試，測(cè)試的目的是什么

What:測(cè)試哪些方面，不同階段的工作內(nèi)容

When:測(cè)試不同階段的起止時(shí)間

Where:相應(yīng)的文檔、缺陷存放位置，測(cè)試環(huán)境等

Who:測(cè)試的人員安排

How:測(cè)試的策略方法以及測(cè)試工具

錄入缺陷后，測(cè)試人員應(yīng)該跟蹤一個(gè)缺陷的整個(gè)生命周期，從new到closed的所有狀態(tài)包括new、open、fixed、rejected、delay、closed和reopen這些狀態(tài)。

提交缺陷到缺陷管理工具，這時(shí)缺陷的狀態(tài)是new。當(dāng)確認(rèn)是bug后，打開(kāi)缺陷，此時(shí)缺陷狀態(tài)為open，并且指派給相應(yīng)的開(kāi)發(fā)人員。開(kāi)發(fā)人員進(jìn)行修改把缺陷狀態(tài)置為fixed修改狀態(tài)，修改好后等待測(cè)試人員回歸測(cè)試。如果開(kāi)發(fā)人員認(rèn)為不是bug有權(quán)拒絕修改把缺陷狀態(tài)改為rejected。如果開(kāi)發(fā)人員認(rèn)為暫時(shí)不需要修改或暫時(shí)不能修改，則延后修改，缺陷狀態(tài)為delay。修改狀態(tài)的bug經(jīng)過(guò)測(cè)試人員復(fù)測(cè)通過(guò)后，則關(guān)閉bug，狀態(tài)為closed。如果復(fù)測(cè)不通過(guò)，則重新打開(kāi)bug這時(shí)的缺陷狀態(tài)是reopen，等待開(kāi)發(fā)人員重新修改。

QA是質(zhì)量保證人員 QC是質(zhì)量控制人員

他們都是對(duì)質(zhì)量進(jìn)行管理，都是在查找錯(cuò)誤，但是QC查找的是產(chǎn)品錯(cuò)誤，而QA查找的是過(guò)程錯(cuò)誤

功能性方面：首先看看這部電梯是否能夠使用，能不能承載重物，看看使用說(shuō)明；

安全性方面： 看這部電梯有沒(méi)有產(chǎn)品安全標(biāo)識(shí)，驗(yàn)證在使用過(guò)程中是否能夠保證安全使用；

易用性方面：看看這部電梯操作是否都能正常，按鍵能不能操作，門(mén)能否能打開(kāi)；

界面方面 ：先看看電梯外觀是否完好無(wú)損，有沒(méi)有破壞的地方，或者設(shè)計(jì)不合理的地方；

兼容性方面 ：看看這樣的電梯安裝在不同地區(qū)的樓層是都都能正常使用，在不同的溫度，人員重量下是否正常使用；

性能測(cè)試方面：看看電梯的控制主板是否正常，是否需要等很長(zhǎng)時(shí)間；

壓力測(cè)試方面 ：實(shí)驗(yàn)用此電梯的極限重量的物品放在電梯里面，看電梯是否會(huì)報(bào)警；

可靠性方面：長(zhǎng)時(shí)間使用這部電梯看看電梯正常工作的最長(zhǎng)時(shí)間是多少。

1、尋找Bug；

2、避免軟件開(kāi)發(fā)過(guò)程中的缺陷；
3、衡量軟件的品質(zhì)；
4、關(guān)注用戶的需求。
總的目標(biāo)是：確保軟件的質(zhì)量。

黑盒測(cè)試的優(yōu)點(diǎn)有：

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

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

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

●基于軟件開(kāi)發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能；

●在做軟件自動(dòng)化測(cè)試時(shí)較為方便。

黑盒測(cè)試的缺點(diǎn)有：

●不可能覆蓋所有的代碼，覆蓋率較低，大概只能達(dá)到總代碼量的30%；

●自動(dòng)化測(cè)試的復(fù)用性較低。

白盒測(cè)試的優(yōu)點(diǎn)有：

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

白盒測(cè)試的缺點(diǎn)有：

●程序運(yùn)行會(huì)有很多不同的路徑，不可能測(cè)試所有的運(yùn)行路徑；

●測(cè)試基于代碼，只能測(cè)試開(kāi)發(fā)人員做的對(duì)不對(duì)，而不能知道設(shè)計(jì)的正確與否，可能會(huì)漏掉一些功能需求；

系統(tǒng)龐大時(shí)，測(cè)試開(kāi)銷(xiāo)會(huì)非常大。

軟件測(cè)試計(jì)劃是指導(dǎo)測(cè)試過(guò)程的綱領(lǐng)性文件。

包含了產(chǎn)品概述、測(cè)試策略、測(cè)試方法、測(cè)試區(qū)域、測(cè)試配置、測(cè)試周期、測(cè)試資源、測(cè)試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測(cè)試計(jì)劃，參與測(cè)試的項(xiàng)目成員，尤其是測(cè)試管理人員，可以明確測(cè)試任務(wù)和測(cè)試方法，保持測(cè)試實(shí)施過(guò)程的順暢溝通，跟蹤和控制測(cè)試進(jìn)度，應(yīng)對(duì)測(cè)試過(guò)程中的各種變更。

測(cè)試計(jì)劃和測(cè)試詳細(xì)規(guī)格、測(cè)試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測(cè)試計(jì)劃主要從宏觀上規(guī)劃測(cè)試活動(dòng)的范圍、方法和資源配置，而測(cè)試詳細(xì)規(guī)格、測(cè)試用例是完成測(cè)試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測(cè)試測(cè)試策略和測(cè)試方法（最好是能先評(píng)審）。

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

邊界值分析法

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

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

錯(cuò)誤猜測(cè)法

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

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

因果圖方法

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

正交表分析法

有時(shí)候，可能因?yàn)榇罅康膮?shù)的組合而引起測(cè)試用例數(shù)量上的激增，同時(shí)，這些測(cè)試用例并沒(méi)有明顯的優(yōu)先級(jí)上的差距，而測(cè)試人員又無(wú)法完成這么多數(shù)量的測(cè)試，就可以通過(guò)正交表來(lái)進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。

場(chǎng)景分析方法

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

狀態(tài)圖法

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

大綱法

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

在傳統(tǒng)的BugZilla中，BUG描述應(yīng)該包括以下的信息：

●和BUG產(chǎn)生對(duì)應(yīng)的軟件版本和模塊

●開(kāi)發(fā)的接口人員

●BUG的優(yōu)先級(jí)

●BUG的嚴(yán)重程度

●BUG可能屬于的模塊，如果不能確認(rèn)，可以用開(kāi)發(fā)人員來(lái)判斷

●BUG標(biāo)題，需要清晰的描述現(xiàn)象

●BUG描述，需要盡量給出重新Bug的步驟

●BUG附件中能給出相關(guān)的日志和截圖。

●高質(zhì)量的BUG記錄就是指很容易理解的BUG記錄，所以，對(duì)于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開(kāi)發(fā)人員定位，因此提交高質(zhì)量的軟件缺陷記錄需要注意對(duì)BUG記錄的描述質(zhì)量多且準(zhǔn)確。

盡量面對(duì)面的溝通，其次是能直接通過(guò)電話溝通，如果只能通過(guò)Email等非及時(shí)溝通工具的話，強(qiáng)調(diào)必須對(duì)特性的理解深刻以及能表達(dá)清楚。

運(yùn)用一些測(cè)試管理工具如TestDirector進(jìn)行管理也是較有效的方法，同時(shí)要注意在TestDirector中對(duì)BUG有準(zhǔn)確的描述。

在團(tuán)隊(duì)中建立測(cè)試人員與開(kāi)發(fā)人員良好溝通中注意以下幾點(diǎn)：

1、真誠(chéng)；

2、有團(tuán)隊(duì)精神；

3、是在專(zhuān)業(yè)上有共同語(yǔ)言；

4、是要對(duì)事不對(duì)人，工作至上；

當(dāng)然也可以通過(guò)直接指出一些小問(wèn)題，而不是進(jìn)入BUG Tracking System來(lái)增加對(duì)方的好感。

回答這個(gè)面試題，沒(méi)有固定統(tǒng)一的答案，但可能是許多企業(yè)都會(huì)問(wèn)到的。提供以下答案參考：

最大的興趣，感覺(jué)這是一個(gè)有挑戰(zhàn)性的工作；

測(cè)試是一個(gè)經(jīng)驗(yàn)行業(yè)，工作越久越能感覺(jué)到做好測(cè)試的難度和樂(lè)趣；通過(guò)自己的工作，能使軟件產(chǎn)品越來(lái)越完善，從中體會(huì)到樂(lè)趣。

回答此類(lèi)問(wèn)題注意以下幾個(gè)方面：

1、盡可能的切合招聘企業(yè)的技術(shù)路線來(lái)表達(dá)你的興趣，例如該企業(yè)是數(shù)據(jù)庫(kù)應(yīng)用的企業(yè)，那么表示你的興趣在數(shù)據(jù)庫(kù)的測(cè)試，并且希望通過(guò)測(cè)試提升自己的數(shù)據(jù)庫(kù)掌握能力。表明你做測(cè)試的目的是為了提升能力，也是為了更好的做好測(cè)試；提升能力不是為了以后轉(zhuǎn)開(kāi)發(fā)或其他的，除非用人企業(yè)有這樣的安排。

2、不要過(guò)多的表達(dá)你的興趣在招聘企業(yè)的范疇之外。比如招聘企業(yè)是做財(cái)務(wù)軟件的，可是你表現(xiàn)出來(lái)的是對(duì)游戲軟件的興趣；或招聘是做JAVA開(kāi)發(fā)的，而你的興趣是在C類(lèi)語(yǔ)言程序的開(kāi)發(fā)。

自頂向下集成

優(yōu)點(diǎn)：較早地驗(yàn)證了主要控制和判斷點(diǎn)；按深度優(yōu)先可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；功能較早證實(shí)，帶來(lái)信心；只需一個(gè)驅(qū)動(dòng)，減少驅(qū)動(dòng)器開(kāi)發(fā)的費(fèi)用；支持故障隔離。

缺點(diǎn)：柱的開(kāi)發(fā)量大；底層驗(yàn)證被推遲；底層組件測(cè)試不充分。

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

自底向上集成

優(yōu)點(diǎn)：對(duì)底層組件行為較早驗(yàn)證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。

缺點(diǎn)：驅(qū)動(dòng)的開(kāi)發(fā)工作量大；對(duì)高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。
適應(yīng)于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。