面試提問(wèn)整理

1、精選優(yōu)質(zhì)文檔-傾情為你奉上1. 請(qǐng)描述一下你們公司的測(cè)試流程需求澄清會(huì)議測(cè)試計(jì)劃、方案及其評(píng)審測(cè)試用例及其評(píng)審測(cè)試執(zhí)行、缺陷跟蹤測(cè)試結(jié)束出報(bào)告2. 測(cè)試計(jì)劃是誰(shuí)編寫(xiě)的組長(zhǎng)/測(cè)試經(jīng)理3. 測(cè)試計(jì)劃主要內(nèi)容有哪些項(xiàng)目概述、測(cè)試范圍、人員分配、測(cè)試策略、進(jìn)度、風(fēng)險(xiǎn)4. 測(cè)試計(jì)劃評(píng)審人需要哪些項(xiàng)目經(jīng)理和測(cè)試組全體5. 什么叫里程碑就是項(xiàng)目或版本過(guò)程中的各個(gè)時(shí)間或任務(wù)節(jié)點(diǎn)，比如版本發(fā)布、需求定稿等等6. 什么是版本計(jì)劃針對(duì)一個(gè)升級(jí)版本做的計(jì)劃，內(nèi)容包括版本范圍、進(jìn)度安排、人員分配、風(fēng)險(xiǎn)等7. 測(cè)試計(jì)劃的編寫(xiě)依據(jù)有哪些需求規(guī)格設(shè)明書(shū)、項(xiàng)目計(jì)劃可能參考到的還有需求分析表、概要設(shè)計(jì)8. 項(xiàng)目進(jìn)度和測(cè)試計(jì)劃不一

2、致怎么處理根據(jù)實(shí)際情況修改計(jì)劃9. 編寫(xiě)測(cè)試計(jì)劃大概需要多次時(shí)間1-3天（一周內(nèi)隨便說(shuō)吧）10. 你們公司是什么階段介入軟件測(cè)試的從需求分析開(kāi)始，測(cè)試人員就介入了，開(kāi)發(fā)和測(cè)試人員同時(shí)進(jìn)行需求分析。從SE寫(xiě)出新需求的概要設(shè)計(jì)開(kāi)始，開(kāi)發(fā)和測(cè)試同時(shí)對(duì)FRS和概要設(shè)計(jì)進(jìn)行需求澄清會(huì)議，然后開(kāi)發(fā)人員寫(xiě)詳細(xì)設(shè)計(jì)，測(cè)試人員寫(xiě)測(cè)試方案，開(kāi)發(fā)人員編碼，測(cè)試人員寫(xiě)用例，開(kāi)發(fā)人員提交版本，測(cè)試人員進(jìn)行測(cè)試。11. 你們公司開(kāi)發(fā)和測(cè)試人員比例是多少3：112. 你們有獨(dú)立的測(cè)試部門(mén)嗎？有/沒(méi)有，我們都在同一個(gè)項(xiàng)目中，項(xiàng)目經(jīng)理管理我們，我們只有一個(gè)測(cè)試組長(zhǎng)。13. 開(kāi)發(fā)和測(cè)試出現(xiàn)了意見(jiàn)沖突怎么解決溝通，溝通解決不了的可

3、以將問(wèn)題升級(jí)。14. 測(cè)試需求分析是誰(shuí)做的除新員工外的全體測(cè)試人員，新員工也參與，但不會(huì)分配任務(wù)和對(duì)需求分析負(fù)責(zé)。15. 需求階段需要出哪些文檔測(cè)試需求分析表、概要設(shè)計(jì)、測(cè)試計(jì)劃等16. 測(cè)試的依據(jù)是什么需求，歸根結(jié)底就是需求。17. 什么是隱形需求就是需求中沒(méi)有明確要求，但是按照約定俗成的規(guī)則或日常習(xí)慣必須滿足的需求。就好像問(wèn)：你有XXX的電話號(hào)碼嗎？18. 項(xiàng)目中碰到需求的問(wèn)題，能夠直接和客戶溝通嗎？能，我在項(xiàng)目組中是對(duì)外接口人，我可以直接和客戶方的代表開(kāi)會(huì)進(jìn)行溝通。/不能，我們需要將問(wèn)題整理到一起，由測(cè)試經(jīng)理和項(xiàng)目經(jīng)理作為接口人和客戶進(jìn)行溝通。/不能，我們的需求是產(chǎn)品線提的，關(guān)于需求問(wèn)題

4、，我們直接找產(chǎn)品線。19. 需求過(guò)程中不確定的需求怎么解決項(xiàng)目組內(nèi)討論解決，如果還是得不到解決，需要找用戶確認(rèn)20. 需求文檔是誰(shuí)編寫(xiě)的客戶/產(chǎn)品線21. 怎么進(jìn)行需求測(cè)試會(huì)議討論評(píng)審22. 什么是測(cè)試點(diǎn)，測(cè)試點(diǎn)包含哪些內(nèi)容就是針對(duì)功能細(xì)分的點(diǎn)，我們寫(xiě)的測(cè)試點(diǎn)類似于測(cè)試用例的標(biāo)題，是說(shuō)什么功能的什么情況。23. 什么是測(cè)試方案，什么是測(cè)試策略方案是指導(dǎo)我們要怎么測(cè)的問(wèn)題，里邊的主要內(nèi)容是測(cè)試點(diǎn)。策略是指導(dǎo)我們都要測(cè)什么方面，比如要進(jìn)行功能測(cè)試，性能測(cè)試，兼容性測(cè)試等等，并指出需要依賴什么工具等。24. 測(cè)試方案是誰(shuí)編寫(xiě)的分給誰(shuí)誰(shuí)寫(xiě)，自己寫(xiě)自己負(fù)責(zé)的部分，一般除了新員工都會(huì)寫(xiě)。25. 測(cè)試方案包

5、含哪些內(nèi)容業(yè)務(wù)功能的描述，對(duì)需求、功能的理解，業(yè)務(wù)流程圖、業(yè)務(wù)表、測(cè)試點(diǎn)等等。26. 測(cè)試方案編寫(xiě)的輸入條件是什么需求規(guī)格說(shuō)明書(shū)、測(cè)試需求分析表27. 請(qǐng)描述一下測(cè)試用例需要參考的文檔絕大部分都是參考測(cè)試方案，很少量是參考需求文檔或其他文檔。28. 測(cè)試用例設(shè)計(jì)方法有哪些？等價(jià)類、邊界值、場(chǎng)景法、因果圖、判定表、錯(cuò)誤推測(cè)法29. 測(cè)試用例內(nèi)容有哪些ID、標(biāo)題、優(yōu)先級(jí)、前置條件、操作步驟、預(yù)期結(jié)果等30. 什么是好的測(cè)試用例我覺(jué)得不冗余不遺漏的測(cè)試用例就是好用例，我也看過(guò)理論方面的書(shū)，書(shū)上說(shuō)能夠發(fā)現(xiàn)至今沒(méi)有發(fā)現(xiàn)的缺陷的用例就是好用例，不過(guò)我們?cè)谠O(shè)計(jì)用例的時(shí)候根本不知道我們?cè)O(shè)計(jì)的用例執(zhí)行結(jié)果是什么

6、。31. 測(cè)試用例的顆粒度劃分顆粒度大小就是用例的粗細(xì)程度，每個(gè)項(xiàng)目組的尺度應(yīng)該有所不同吧。32. 測(cè)試用例為什么需要有優(yōu)先級(jí)，有哪一些優(yōu)先級(jí)因?yàn)樵诓煌A段執(zhí)行的用例數(shù)目是不同的，用例對(duì)應(yīng)的功能的重要程度也是不同的，我們用的是高中低三級(jí)33. 你們以前一天能夠編寫(xiě)多少測(cè)試用例30條左右吧，沒(méi)怎么統(tǒng)計(jì)過(guò)，大概是這個(gè)數(shù)34. 你們項(xiàng)目一共有多少條測(cè)試用例500-2000，具體項(xiàng)目具體分析，和項(xiàng)目大小、顆粒度大小都有關(guān)系。35. 高、中、低先級(jí)的測(cè)試用例的比例占多少都差不多只是中的會(huì)多于其他兩個(gè)，差不多3/4/3的比例吧。36. 測(cè)試用例需要哪些人來(lái)評(píng)審我們測(cè)用例評(píng)審是測(cè)試組內(nèi)評(píng)審的，因?yàn)槲覀兊姆桨?/p>

7、是全體項(xiàng)目組成員（PM、SE、開(kāi)發(fā)和測(cè)試）來(lái)評(píng)審的，并且方案里的測(cè)試點(diǎn)寫(xiě)到了測(cè)試用例標(biāo)題的程度，所以我們拿已經(jīng)全員評(píng)審過(guò)的測(cè)試點(diǎn)來(lái)寫(xiě)用例只不過(guò)是一個(gè)體力活，所以我們的用例評(píng)審就不用太多人員來(lái)參與了。我們是項(xiàng)目組全體來(lái)評(píng)審的，畢竟測(cè)試是保證軟件質(zhì)量的最后一個(gè)環(huán)節(jié)，測(cè)試用例是測(cè)試執(zhí)行的依據(jù)，所以測(cè)試用例十分重要，項(xiàng)目組非常重視用例的評(píng)審，希望把漏測(cè)的可能降到最低，所以我們的用例是項(xiàng)目組全體會(huì)議評(píng)審的。37. 一個(gè)項(xiàng)目需要寫(xiě)多少測(cè)試用例怎么估算這個(gè)在需求分析之后根據(jù)測(cè)試點(diǎn)來(lái)評(píng)估的，我們的測(cè)試點(diǎn)寫(xiě)的很細(xì)，所以測(cè)試用例的數(shù)目幾乎等于測(cè)試點(diǎn)的數(shù)目38. 測(cè)試用例是誰(shuí)寫(xiě)的測(cè)試人員39. 不能發(fā)現(xiàn)bug的測(cè)試

8、用例不是好的測(cè)試用例嗎？我不這樣認(rèn)為，我覺(jué)得在執(zhí)行之前，每個(gè)用例都可能發(fā)現(xiàn)缺陷，好的測(cè)試用例是一套完整的不冗余、不遺漏的測(cè)試用例，是能夠被其他測(cè)試人員執(zhí)行的測(cè)試用例。不能因?yàn)槭欠裾业紹UG來(lái)說(shuō)用例是否好。40. 為什么要進(jìn)行交叉測(cè)試執(zhí)行因?yàn)樽约簣?zhí)行自己設(shè)計(jì)的用例，會(huì)按照設(shè)計(jì)用例的思路來(lái)執(zhí)行用例，可能會(huì)忽略一些偶然或異常的情況，交叉執(zhí)行可能會(huì)發(fā)現(xiàn)新的BUG。當(dāng)然如果用例已經(jīng)寫(xiě)的很細(xì)，顆粒度很小，輸入輸出寫(xiě)的很全面，交叉執(zhí)行的效果都會(huì)差不多，因?yàn)闊o(wú)論誰(shuí)來(lái)執(zhí)行，結(jié)果都是一樣的。41. 測(cè)試環(huán)境是誰(shuí)搭建的我們老大/CMO/測(cè)試人員42. 你們測(cè)試版本是在哪里去獲取的開(kāi)發(fā)搞定之后提交到SVN上，我們?nèi)

9、VN上取43. 什么叫預(yù)測(cè)試，預(yù)測(cè)試是怎么進(jìn)行的，預(yù)測(cè)試一般為多長(zhǎng)時(shí)間預(yù)測(cè)試就是開(kāi)放剛剛開(kāi)發(fā)完成，測(cè)試環(huán)境剛搭建起來(lái)，這時(shí)我們要對(duì)系統(tǒng)的各種功能能不能跑通，業(yè)務(wù)流程能不能完成進(jìn)行測(cè)試，就是“冒煙測(cè)試”，這就是轉(zhuǎn)測(cè)試，我們轉(zhuǎn)測(cè)試大概需要一天的時(shí)間。44. 測(cè)試準(zhǔn)入條件是什么預(yù)測(cè)試功能無(wú)阻塞45. 測(cè)試環(huán)境搭建需要和需求配置一樣的硬件條件嗎不一定，功能測(cè)試環(huán)境是不關(guān)注硬件條件的，如果測(cè)試性能的話，就要關(guān)注這個(gè)了。（其實(shí)我不知道什么是需求配置）46. 測(cè)試環(huán)境會(huì)不會(huì)在虛擬機(jī)上搭建可能會(huì)吧，我們的測(cè)試環(huán)境都搭建在物理主機(jī)上了。47. 測(cè)試環(huán)境搭建一般會(huì)有安裝說(shuō)明書(shū)嗎會(huì)48. 預(yù)測(cè)試無(wú)法通過(guò)怎么處理開(kāi)發(fā)

10、連夜改，如果改不好推遲測(cè)試開(kāi)始時(shí)間49. 每天能夠執(zhí)行多少條測(cè)試用例20來(lái)?xiàng)l吧50. 執(zhí)行用例之后用例會(huì)有哪些狀態(tài)通過(guò)、不通過(guò)、阻塞51. 對(duì)于無(wú)效的用例怎么處理，哪些情況會(huì)導(dǎo)致用例無(wú)效刪，需求變更、設(shè)計(jì)重復(fù)、或者對(duì)需求理解有偏差都可能造成用例無(wú)效。52. Bug的生命周期以及Bug在每個(gè)階段的的狀態(tài)測(cè)試人員提交BUG 新建測(cè)試經(jīng)理確認(rèn)BUG 打開(kāi)項(xiàng)目經(jīng)理/開(kāi)發(fā)經(jīng)理確認(rèn)，分配給開(kāi)發(fā) 打開(kāi)開(kāi)發(fā)確認(rèn)，修改 已修改測(cè)試回歸通過(guò) 關(guān)閉開(kāi)發(fā)確認(rèn)非錯(cuò) 非錯(cuò)/rejected測(cè)試確認(rèn)非錯(cuò) 關(guān)閉開(kāi)發(fā)確認(rèn)不改 不改開(kāi)發(fā)確認(rèn)遺留 delay/延遲/遺留測(cè)試人員回歸不通過(guò)或確認(rèn)是BUG reopen/重新打開(kāi)53.

11、 測(cè)試人員在Bug或者需求上存在爭(zhēng)議解決過(guò)程是怎么樣的？溝通、討論，找用戶確認(rèn)，不成就升級(jí)54. 項(xiàng)目中出現(xiàn)爭(zhēng)議，測(cè)試經(jīng)理和開(kāi)發(fā)經(jīng)理無(wú)法抉擇怎么處理沒(méi)有遇到過(guò)，具體問(wèn)題具體分析，都是一個(gè)團(tuán)隊(duì)的，沒(méi)有解決不了的問(wèn)題55. 你們公司用什么缺陷管理工具，誰(shuí)維護(hù)缺陷管理工具BUGFREE BUGZILLA BUGBASE QC 56. 系統(tǒng)測(cè)試缺陷產(chǎn)生的主要原因有哪些需求理解錯(cuò)誤、設(shè)計(jì)不完善、程序錯(cuò)誤、UI錯(cuò)誤、兼容性、性能、安全性等57. Bug級(jí)別怎么來(lái)定義，一般有幾級(jí)我們用的是四級(jí)，1-致命，2-嚴(yán)重，3-一般，4-輕微/建議58. 說(shuō)出你映像最深刻的Bug略，我在課堂說(shuō)過(guò)一個(gè)userid和cu

12、stomerid重復(fù)的問(wèn)題。59. 哪一些Bug需要關(guān)閉回歸通過(guò)的，確認(rèn)非錯(cuò)的，無(wú)效的60. 測(cè)試什么時(shí)候可以結(jié)束軟件通過(guò)驗(yàn)收測(cè)試；用例覆蓋率、測(cè)試執(zhí)行率、測(cè)試通過(guò)率、遺留問(wèn)題等方面達(dá)到質(zhì)量指標(biāo)；問(wèn)題都已修復(fù)，執(zhí)行用例無(wú)法發(fā)現(xiàn)新問(wèn)題。61. 性能測(cè)試在什么時(shí)候測(cè)試功能穩(wěn)定之后，具體的時(shí)間就是沒(méi)有其他干擾性能環(huán)境的時(shí)間。比如一共四輪測(cè)試的第三輪。62. 自動(dòng)化測(cè)試在什么時(shí)候測(cè)試回歸63. 兼容性測(cè)試在什么時(shí)候測(cè)試功能穩(wěn)定之后64. 資料測(cè)試包括哪些，誰(shuí)來(lái)測(cè)試，資料測(cè)試在什么時(shí)候測(cè)試測(cè)試方案、測(cè)試用例、版本說(shuō)明書(shū)、安裝說(shuō)明書(shū)等等文檔的評(píng)審。方案、用例的評(píng)審就是在其完成之后，版本說(shuō)明書(shū)、安裝說(shuō)明書(shū)在

13、版本發(fā)布之前。65. 資料是誰(shuí)寫(xiě)的CMO，我們寫(xiě)的。66. 資料測(cè)試需要設(shè)計(jì)測(cè)試用例嗎？無(wú)67. 測(cè)試一般分幾輪，大致的時(shí)間段是怎么樣的我們新項(xiàng)目一般測(cè)4、5輪甚至更多，我們的版本測(cè)試一般都是3輪。新項(xiàng)目中第一、二輪都差不多一個(gè)月，3輪可能有半個(gè)多月，第4輪大概只有幾天。版本中第一輪可能有一周，第二輪差不多3、4天，第三輪可能只有1、2天。68. 無(wú)法執(zhí)行的測(cè)試用例怎么處理分析原因，如果是冗余的就刪除，如果是被阻塞的就保留69. 測(cè)試提交的bug怎么處理確認(rèn)、修改70. Bug修改后由誰(shuí)來(lái)回歸提BUG的測(cè)試人員71. 回歸不通過(guò)的Bug是什么狀態(tài)打開(kāi)72. 你寫(xiě)過(guò)測(cè)試總結(jié)嗎？你說(shuō)的測(cè)試總結(jié)是更

14、像測(cè)試報(bào)告還是業(yè)務(wù)總結(jié)呢？我寫(xiě)過(guò)業(yè)務(wù)總結(jié)，就是在進(jìn)行了這部分業(yè)務(wù)的測(cè)試之后，總結(jié)一下這個(gè)業(yè)務(wù)的細(xì)節(jié)和測(cè)試需要關(guān)注的點(diǎn)。73. 測(cè)試報(bào)告是誰(shuí)編寫(xiě)的測(cè)試經(jīng)理/組長(zhǎng)74. 測(cè)試報(bào)告時(shí)誰(shuí)評(píng)審的PM、測(cè)試主管、部門(mén)主管、部門(mén)經(jīng)理等75. 測(cè)試報(bào)告里面包含哪些內(nèi)容測(cè)試過(guò)程中的數(shù)據(jù)如用例覆蓋率、執(zhí)行率、通過(guò)率等，遺留BUG的分析，風(fēng)險(xiǎn)，質(zhì)量評(píng)估結(jié)果等76. 驗(yàn)收測(cè)試是誰(shuí)做的用戶77. sit，ut，uat是什么 SIT就是System Integreation Testing 系統(tǒng)集成測(cè)試UT就是 Unit Testing 單元測(cè)試UAT 就是User acceptance Testing 用戶接收測(cè)試/驗(yàn)

15、收測(cè)試78. 什么是用戶手冊(cè)指導(dǎo)用戶使用的說(shuō)明書(shū)79. 驗(yàn)收測(cè)試不通過(guò)測(cè)試需要做什么改BUG80. Bug怎么進(jìn)行回溯分析漏測(cè)的BUG是什么原因產(chǎn)生的，如果是容易發(fā)現(xiàn)的，并且測(cè)試用例中有涉及，要追究相應(yīng)測(cè)試人員的責(zé)任，如果是偶發(fā)性，隱藏比較深，也要進(jìn)行記錄，在日后的測(cè)試中加以注意?？傊?，如果是能力范圍內(nèi)，能夠找到卻沒(méi)有找到的BUG就要追究相關(guān)測(cè)試人員的第一責(zé)任，如果非能力范圍內(nèi)的，要引以為戒，吸取教訓(xùn)，積累經(jīng)驗(yàn)。81. 你們項(xiàng)目的缺陷密度是多少BUG數(shù)/代碼量82. 驗(yàn)收的缺陷密度是多少不知道83. 驗(yàn)收不通過(guò)，誰(shuí)承擔(dān)責(zé)任一般來(lái)說(shuō)，測(cè)試人員承擔(dān)第一責(zé)任84. 有Bug的版本能否發(fā)布可能會(huì)發(fā)布，

16、看BUG是啥BUG，有多大影響，修改需要多少成本，還是那句話，具體問(wèn)題具體分析。85. 阿爾法測(cè)試盒貝塔測(cè)試區(qū)別是公司內(nèi)部員工模擬用戶進(jìn)行測(cè)試。測(cè)試是用戶進(jìn)行非正式驗(yàn)收測(cè)試。86. 你們項(xiàng)目總共發(fā)現(xiàn)了多少Bug項(xiàng)目的話200-400版本的話20-6087. 一個(gè)項(xiàng)目10個(gè)月，你能大致劃分一下每個(gè)階段嘛？確定需求可能需要2、3個(gè)月，之后要做近一個(gè)月的需求分析，開(kāi)發(fā)設(shè)計(jì)、編碼，測(cè)試人員的測(cè)試設(shè)計(jì)可能也需要3個(gè)月左右，而測(cè)試執(zhí)行大概需要4個(gè)來(lái)月。88. Bug在項(xiàng)目中不能正常收斂，原因有哪些？需求不斷變更是很可能的原因，或者是開(kāi)發(fā)人員水平較低，修復(fù)一個(gè)BUG引發(fā)出若干其他BUG。89. 在測(cè)試階段能

17、夠發(fā)現(xiàn)大概多少比例的Bug很多吧，應(yīng)該有80%以上，如果版本很穩(wěn)定可能會(huì)更高。90. 解釋一下為什么越早發(fā)現(xiàn)Bug，修復(fù)成本越小因?yàn)樵皆绨l(fā)現(xiàn)BUG，就會(huì)在錯(cuò)誤的道路上走的越短，及時(shí)修正后，避免了在錯(cuò)誤的道路上越走越遠(yuǎn)的情況。91. 什么是28原則8成BUG在2成的模塊。92. 你是怎么安排你的工作時(shí)間的我還是以任務(wù)為導(dǎo)向或者說(shuō)以結(jié)果為導(dǎo)向的，每天我都有自己的目標(biāo)，今天打算完成多少工作，會(huì)做到今日事今日畢，如果完成的比較早，可能會(huì)幫助其他同事或加強(qiáng)自己學(xué)習(xí)和提高，如果在下班的時(shí)候還差一點(diǎn)完成不了，我寧可加班完成，也不愿意將任務(wù)拖到第二天。當(dāng)然如果遇到我個(gè)人無(wú)法解決的問(wèn)題，造成了我任務(wù)完成不了，我

18、會(huì)盡快反饋、協(xié)調(diào)解決問(wèn)題，盡量保證當(dāng)天可以完成，或調(diào)整我的工作計(jì)劃。93. 你對(duì)出差有什么看法全球不限時(shí)不限地點(diǎn)94. 項(xiàng)目是否發(fā)現(xiàn)Bug越多，質(zhì)量越好NO！發(fā)現(xiàn)的越多，藏的也越多95. 上線前晚上發(fā)現(xiàn)嚴(yán)重Bug，第二天之前來(lái)不及修復(fù)，該項(xiàng)目能否上線不能UT = unit testing 單元測(cè)試IT = integration testing 集成測(cè)試ST = system testing 系統(tǒng)測(cè)試UAT= User acceptance testing 用戶接受測(cè)試(俗稱:驗(yàn)收測(cè)試)經(jīng)過(guò)了近2年的努力，多數(shù)研發(fā)團(tuán)隊(duì)都用上了技術(shù)質(zhì)量部自主研發(fā)的Bug管理工具Kelude_Issues，告別了

19、商業(yè)工具和其他的開(kāi)源工具。這個(gè)過(guò)程中Bug跟蹤流程也發(fā)生了比較多的變化，下圖是現(xiàn)在Kelude_Issues的Bug跟蹤流程圖：這個(gè)流程還是有著比較多的“淘寶特色”，我想可能很多用慣了其他Bug管理產(chǎn)品的同仁，看著這個(gè)圖會(huì)感覺(jué)不太習(xí)慣，覺(jué)得狀態(tài)比較多，箭頭也多，有點(diǎn)繞。在經(jīng)典的Bug跟蹤流程里面，對(duì)于“狀態(tài)”概念的定義，是比較清楚的，一般來(lái)說(shuō)這些狀態(tài)會(huì)比較常見(jiàn)，當(dāng)然由于工具的不同，所用的英文單詞也會(huì)有些差別，這個(gè)不用糾結(jié)，領(lǐng)會(huì)精神。New：新創(chuàng)建的BugOpen：經(jīng)過(guò)了PM的確認(rèn)，確實(shí)是個(gè)BugAssigned：已經(jīng)分配給開(kāi)發(fā)工程師進(jìn)行解決Resolved：開(kāi)發(fā)工程師解決了，等待測(cè)試工程師驗(yàn)證

20、（注意是解決，不是fix）Closed：通過(guò)了驗(yàn)證，關(guān)閉這里最容易引起混淆的概念，就是“Resolved”被解決過(guò)了。最常見(jiàn)的解決方式，就是Fixed，被修復(fù)了；有時(shí)因?yàn)橐恍┰?，暫時(shí)無(wú)法修復(fù)，只能Later，其實(shí)Later也是一種解決方式，常見(jiàn)的解決方式有以下幾個(gè)：Fixed：被修復(fù)了Later：暫時(shí)不修復(fù)，后面的版本再修復(fù)Wont Fix：不修復(fù)了，其實(shí)是一種Later的特例，無(wú)限期LaterInvalid：根本不是Bug，往往由于對(duì)需求的誤解Duplicate：重復(fù)的，相同的Bug已經(jīng)被提交過(guò)一次了Not Reproducible：無(wú)法重現(xiàn)，在淘寶叫做Works for Me嚴(yán)格來(lái)說(shuō)，這一組“解決方式”，是屬于同一層面的，它們都需要由測(cè)試或者PM來(lái)驗(yàn)證，如果驗(yàn)證不通過(guò)，那就回到Open狀態(tài)，驗(yàn)證通過(guò)就Close。而在淘寶Bug流程中，這些“解決方式”都被設(shè)置成了“狀態(tài)”，其實(shí)也挺好，更加直觀。但是這里有一個(gè)很要命的問(wèn)題，就是那個(gè)“wont