B/S架構(gòu)和C/S架構(gòu)區(qū)別：
b/s：是瀏覽器和服務(wù)端? ?c/s：是客戶端和服務(wù)器
http協(xié)議：
http協(xié)議又叫做文本傳輸協(xié)議，在做網(wǎng)絡(luò)請(qǐng)求的時(shí)候敬察，我們基本上使用http協(xié)議。
http協(xié)議包括請(qǐng)求和響應(yīng)
? ? ? ? 請(qǐng)求中包含：請(qǐng)求地址尔当，請(qǐng)求方式莲祸，請(qǐng)求方式包括get和post請(qǐng)求，get和post的區(qū)別是get請(qǐng)求在地址欄后邊跟隨請(qǐng)求參數(shù)椭迎，但是請(qǐng)求參數(shù)大小有限制锐帜，不同瀏覽器是不同的。一般是4KB侠碧。post請(qǐng)求主要用于向服務(wù)器提交請(qǐng)求參數(shù)抹估。post請(qǐng)求參數(shù)是放到請(qǐng)求實(shí)體中的缠黍，相對(duì)get請(qǐng)求更為安全些弄兜。
響應(yīng)包括：200（），404（）瓷式，500（）替饿，304（），307（）
還有各種響應(yīng)頭信息贸典，比如設(shè)置緩存的響應(yīng)頭视卢，Content-Type內(nèi)容類型，設(shè)置cookie頭信息
POST與GET區(qū)別：
get請(qǐng)求沒有請(qǐng)求體廊驼，通過url攜帶數(shù)據(jù)据过，大小有限制，不安全
post請(qǐng)求通過請(qǐng)求體傳輸數(shù)據(jù)妒挎，大小沒有限制绳锅，比get安全
Cookie和Session的區(qū)別與聯(lián)系：
cookie數(shù)據(jù)放在客戶端瀏覽器上，session數(shù)據(jù)存在服務(wù)器上
cookie不是很安全酝掩，別人可以分析存在本地的cookin并進(jìn)行欺騙鳞芙，考慮到安全應(yīng)當(dāng)使用session
session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多會(huì)比較占用你的服務(wù)器的性能，考慮減輕服務(wù)器性能方面原朝，應(yīng)當(dāng)使用cookin
單個(gè)cookin保存的數(shù)據(jù)不能超過4K很多瀏覽器限制一個(gè)站點(diǎn)最多保存20個(gè)cookin
測(cè)試的目的：
軟件測(cè)試的目的是為了保證軟件產(chǎn)品的最終質(zhì)量驯嘱，在軟件開發(fā)的過程中，對(duì)軟件產(chǎn)品進(jìn)行質(zhì)量控制一般來說軟件測(cè)試應(yīng)由獨(dú)立的產(chǎn)品評(píng)測(cè)中心負(fù)責(zé)喳坠，嚴(yán)格按照軟件測(cè)試流程鞠评，制定測(cè)試計(jì)劃、測(cè)試方案丙笋、測(cè)試規(guī)范谢澈，實(shí)施測(cè)試，對(duì)測(cè)試記錄進(jìn)行分析御板，并根據(jù)回歸測(cè)試情況撰寫測(cè)試報(bào)告锥忿。測(cè)試是為了證明程序有錯(cuò)，而不能保證程序沒有錯(cuò)誤怠肋。
軟件測(cè)試原則：
1.測(cè)試證明軟件存在缺陷：無論執(zhí)行什么樣的測(cè)試操作都能證明軟件是有缺陷的
2.不能執(zhí)行窮盡測(cè)試：有些功能是沒有辦法將所有的測(cè)試情況都邏輯出來敬鬓，所以任何的測(cè)試操作都有結(jié)束時(shí)間
3.缺陷存在群集現(xiàn)象：對(duì)于軟件功能來說，核心功能占20%笙各，非核心占80%钉答。在實(shí)際工作中我們會(huì)集中測(cè)試20%的核心功能，所以這個(gè)部分發(fā)現(xiàn)缺陷的幾率就會(huì)高于80%杈抢。因此我們就回遇到缺陷都集中在20%功能模塊里的現(xiàn)象
4.某些測(cè)試需要依賴特殊的環(huán)境
5.測(cè)試應(yīng)盡早介入：為了更多的發(fā)現(xiàn)和更好的解決軟件中缺陷数尿。我們追求測(cè)試工作盡早開展
6.殺蟲劑現(xiàn)象：同樣的一個(gè)測(cè)試用例不能重的執(zhí)行多次，因此軟件會(huì)對(duì)他產(chǎn)生免疫
7.不存在缺陷謬論：任何軟件不可能是完美的
軟件測(cè)試分為哪幾個(gè)階段：
單元測(cè)試：按模塊劃分后的顆粒度進(jìn)行分類測(cè)試
集成測(cè)試：功能模塊的測(cè)試
系統(tǒng)測(cè)試：多個(gè)模塊合成測(cè)試
驗(yàn)收測(cè)試：客戶以及產(chǎn)品經(jīng)理進(jìn)行
單元測(cè)試：比如說對(duì)Java中的類和方法的測(cè)試惶楼，一般由軟件開發(fā)人員實(shí)施（盡可能保證測(cè)試用例相對(duì)獨(dú)立右蹦，測(cè)試過程中不要調(diào)用其他類的方法，而是在測(cè)試用例中重寫模擬方法）
集成測(cè)試：（測(cè)試各個(gè)單元模塊的接口）在單元測(cè)試的基礎(chǔ)上歼捐，把軟件單元按照概要規(guī)格說明書要求何陆，組裝模塊，測(cè)試看是否模塊達(dá)到了規(guī)格技術(shù)指標(biāo)豹储。
系統(tǒng)測(cè)試：（黑盒測(cè)試）在經(jīng)過集成測(cè)試的單元模塊贷盲，按照整體需求規(guī)格說明書，進(jìn)行一套有效嚴(yán)格的測(cè)試剥扣，保證軟件的正常運(yùn)行巩剖。（集成測(cè)試偏重于技術(shù)角度，系統(tǒng)測(cè)試偏重于業(yè)務(wù)角度）
回歸測(cè)試：（回歸測(cè)試在測(cè)試生命周期中是很重要的一部分钠怯，會(huì)進(jìn)行多次回歸測(cè)試）佳魔，是指在發(fā)生修改之后，再重新回去測(cè)試一下呻疹，避免修改的內(nèi)容導(dǎo)致了其他的錯(cuò)誤吃引。驗(yàn)證之前出現(xiàn)過但已修復(fù)好的缺陷不再重新出現(xiàn)筹陵。
冒煙測(cè)試：（是自由測(cè)試的一種）是指開發(fā)者功能完成后的完整性功能測(cè)試，發(fā)現(xiàn)問題后反饋給開發(fā)者進(jìn)行修改镊尺，然后看這次修改是否真的修復(fù)解決了這bug朦佩，或者對(duì)其他模塊造成了影響，這個(gè)時(shí)候就需要冒煙測(cè)試來進(jìn)行驗(yàn)證庐氮，缺點(diǎn)就是覆蓋率低语稠。
驗(yàn)收測(cè)試：也叫交付測(cè)試，是針對(duì)用戶需求弄砍、業(yè)務(wù)流程進(jìn)行的整體測(cè)試仙畦，確認(rèn)是否滿足驗(yàn)收標(biāo)準(zhǔn)，由用戶音婶、客戶看是否接受系統(tǒng)慨畸，可以部署上線。
Alpha測(cè)試：用戶在開發(fā)者的場(chǎng)所進(jìn)行測(cè)試衣式，是一個(gè)可控的環(huán)境中測(cè)試的寸士。
Beta測(cè)試：是用戶在對(duì)軟件產(chǎn)品進(jìn)行測(cè)試，開發(fā)者不在現(xiàn)場(chǎng)碴卧，用戶對(duì)測(cè)試過程中遇到的bug進(jìn)行記錄弱卡，開發(fā)并對(duì)它進(jìn)行修改，再測(cè)試住册，直到用戶覺得可以了婶博，就部署上線。
單元測(cè)試與集成測(cè)試的側(cè)重點(diǎn)：
單元測(cè)試
? ? ? ?是在軟件開發(fā)過程中要進(jìn)行的最低級(jí)別的測(cè)試活動(dòng)荧飞，在單元測(cè)試活動(dòng)中凡人，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測(cè)試，測(cè)試重點(diǎn)是系統(tǒng)的模塊垢箕，包括子程序的正確性驗(yàn)證等划栓。?
集成測(cè)試
? ? ? ? 也叫組裝測(cè)試或聯(lián)合測(cè)試兑巾。在單元測(cè)試的基礎(chǔ)上条获，將所有模塊按照設(shè)計(jì)要求，組裝成為子系統(tǒng)或系統(tǒng)蒋歌，進(jìn)行集成測(cè)試帅掘。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作堂油，但并不能保證連接起來也能正常的工作修档。程序在某些局部反映不出來的問題，在全局上很可能暴露出來府框，影響功能的實(shí)現(xiàn)吱窝。測(cè)試重點(diǎn)是模塊間的銜接以及參數(shù)的傳遞等。
a（內(nèi)測(cè)）測(cè)試與?（功測(cè)）測(cè)試的區(qū)別：
α測(cè)試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶對(duì)即將面市軟件產(chǎn)品（稱為α版本）進(jìn)行測(cè)試，試圖發(fā)現(xiàn)錯(cuò)誤并修正院峡。α測(cè)試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對(duì)軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的 用戶操作方式兴使。經(jīng)過α測(cè)試調(diào)整的軟件產(chǎn)品稱為β版本。
β測(cè)試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試照激，這些用戶返回有關(guān)錯(cuò)誤信息給開發(fā)者发魄。測(cè)試時(shí)，開發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)俩垃。因而励幼，β測(cè)試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場(chǎng)應(yīng)用。在β測(cè)試中口柳，由用戶記下遇到的所有問題苹粟，包括真實(shí)的以及主觀認(rèn)定的，定期向開發(fā)者報(bào)告跃闹。β測(cè)試主要衡量產(chǎn)品的FLURPS六水，著重于產(chǎn)品的支持性，包括文檔辣卒，客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力掷贾。 只有當(dāng)α測(cè)試達(dá)到一定的可靠程度時(shí)，才能開始β測(cè)試荣茫。它處在整個(gè)測(cè)試的最后階段想帅。同時(shí)，產(chǎn)品的所有手冊(cè)文本也應(yīng)該在此階段完全定稿啡莉。
驗(yàn)收測(cè)試怎么做：
驗(yàn)收測(cè)試(Acceptance Test)：在軟件產(chǎn)品完成了功能測(cè)試和系統(tǒng)測(cè)試之后港准、產(chǎn)品發(fā)布之前所進(jìn)行的軟件測(cè)試活動(dòng)。它是技術(shù)測(cè)試的最后一個(gè)階段咧欣，也稱為交付測(cè)試浅缸。
驗(yàn)收測(cè)試的目的：確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)魄咕。
驗(yàn)收測(cè)試的參與者：用戶衩椒，客戶經(jīng)理，還可能有軟測(cè)工程師等哮兰。
1 毛萌、驗(yàn)收測(cè)試的過程和主要內(nèi)容
前提: ? ? 系統(tǒng)或軟件產(chǎn)品已通過了系統(tǒng)測(cè)試的軟件系統(tǒng)。
測(cè)試內(nèi)容: ?? ?驗(yàn)證系統(tǒng)是否達(dá)到了用戶需求規(guī)格說明書（可能包括項(xiàng)目或產(chǎn)品驗(yàn)收準(zhǔn)則）中的要求喝滞，測(cè)試試圖盡可能地發(fā)現(xiàn)軟件中存留的缺陷阁将，從而為軟件進(jìn)一步改善提供幫助，并保證系統(tǒng)或軟件產(chǎn)品最終被用戶接受右遭。主要包括易用性測(cè)試做盅、兼容性測(cè)試缤削、安裝測(cè)試、文檔（如用戶手冊(cè)吹榴、操作手冊(cè)等）測(cè)試等幾個(gè)方面的內(nèi)容僻他。
任務(wù)：?驗(yàn)證軟件的功能和性能符合用戶期待。
測(cè)試步驟：
制定測(cè)試計(jì)劃腊尚，測(cè)試項(xiàng)吨拗，測(cè)試策略及驗(yàn)收通過準(zhǔn)則，并經(jīng)過客戶參與的計(jì)劃評(píng)審婿斥。
建立測(cè)試環(huán)境劝篷，設(shè)計(jì)測(cè)試用例，并經(jīng)過評(píng)審民宿。
準(zhǔn)備測(cè)試數(shù)據(jù)娇妓，執(zhí)行測(cè)試用例，記錄測(cè)試結(jié)果活鹰。
分析測(cè)試結(jié)果哈恰，根據(jù)驗(yàn)收通過準(zhǔn)則分析測(cè)試結(jié)果，作出驗(yàn)收是否通過及測(cè)試評(píng)價(jià)志群。 測(cè)試項(xiàng)目通過着绷； 測(cè)試項(xiàng)目沒有通過，并且不存在變通方法锌云，需要很大的修改荠医； 測(cè)試項(xiàng)目沒有通過，但存在變通方法桑涎，在維護(hù)后期或下一個(gè)版本改進(jìn)彬向； 測(cè)試項(xiàng)目無法評(píng)估或者無法給出完整的評(píng)估。此時(shí)必須給出原因攻冷。如果是因?yàn)樵摐y(cè)試項(xiàng)目沒有說明清楚娃胆，應(yīng)該修改測(cè)試計(jì)劃。
提交測(cè)試報(bào)告等曼。
驗(yàn)收標(biāo)準(zhǔn)和注意事項(xiàng)：
驗(yàn)收測(cè)試完成標(biāo)準(zhǔn): 完全執(zhí)行了驗(yàn)收測(cè)試計(jì)劃中的每個(gè)測(cè)試用例里烦。
在驗(yàn)收測(cè)試中發(fā)現(xiàn)的錯(cuò)誤已經(jīng)得到修改并且通過了測(cè)試或者經(jīng)過評(píng)估留待下一版本中修改。
完成軟件驗(yàn)收測(cè)試報(bào)告涉兽。
注意事項(xiàng)：
必須編寫正式的招驴、單獨(dú)的驗(yàn)收測(cè)試報(bào)告
驗(yàn)收測(cè)試必須在實(shí)際用戶運(yùn)行環(huán)境中進(jìn)行 由用戶和測(cè)試部門共同執(zhí)行篙程。
如公司自開發(fā)產(chǎn)品枷畏，應(yīng)由測(cè)試人員，產(chǎn)品設(shè)計(jì)部門虱饿，市場(chǎng)部門等共同進(jìn)行拥诡。
白盒触趴、黑盒和灰盒測(cè)試區(qū)別：
白箱測(cè)試或白盒測(cè)試(White-box?testing 或glass-box testing)是通過程序的源代碼進(jìn)行測(cè)試而不使用用戶界面。這種類型的測(cè)試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法渴肉，溢出冗懦，路徑，條件等等中的缺點(diǎn)或者錯(cuò)誤仇祭，進(jìn)而加以修正披蕉。
黑箱測(cè)試或黑盒測(cè)試(Black-box testing)是通過使用整個(gè)軟件或某種軟件功能來嚴(yán)格地測(cè)試, 而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的。測(cè)試人員通過輸入他們的數(shù)據(jù)然后看輸出的結(jié)果從而了解軟件怎樣工作乌奇。通常測(cè)試人員在進(jìn)行測(cè)試時(shí)不僅使用肯定出正確結(jié)果的輸入數(shù)據(jù)没讲，而且還會(huì)使用有挑戰(zhàn)性的輸入數(shù)據(jù)以及可能結(jié)果會(huì)出錯(cuò)的輸入數(shù)據(jù)以便了解軟件怎樣處理各種類型的數(shù)據(jù)。
灰箱測(cè)試或灰盒測(cè)試(Gray-box testing):灰箱測(cè)試就像黑箱測(cè)試一樣是通過用戶界面測(cè)試礁苗，但是測(cè)試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的爬凑。甚至于還讀過部分源代碼。 因此測(cè)試人員可以有的放矢地進(jìn)行某種確定的條件/功能的測(cè)試试伙。這樣做的意義在于:如果你知道產(chǎn)品內(nèi)部的設(shè)計(jì)和對(duì)產(chǎn)品有透過用戶界面的深入了解嘁信，你就能夠更有效和深入地從用戶界面來測(cè)試它的各項(xiàng)性能。
冒煙測(cè)試的目的：
為正式測(cè)試前，驗(yàn)證是否產(chǎn)品或系統(tǒng)的主要需求或預(yù)置條件是否存在bug丛版。
回歸測(cè)試怎么做：
1逐沙、在測(cè)試策略制定階段，制定回歸測(cè)試策略
2秘豹、確定需要回歸測(cè)試的版本
3、回歸測(cè)試版本發(fā)布,按照回歸測(cè)試策略執(zhí)行回歸測(cè)試
4昌粤、回歸測(cè)試通過既绕，關(guān)閉缺陷跟蹤單（問題單）
5、回歸測(cè)試不通過涮坐，缺陷跟蹤單返回開發(fā)人員凄贩，開發(fā)人員重新修改問題，再次提交測(cè)試人員回歸測(cè)試
全部回歸與部分回歸的區(qū)別：
需求分析的目的：
第一袱讹、把用戶需求轉(zhuǎn)化為功能需求：1）對(duì)測(cè)試范圍進(jìn)度量??? 2）對(duì)處理分支進(jìn)行度量?? 3）對(duì)需求業(yè)務(wù)的場(chǎng)景進(jìn)行度量?? 4）明確其功能對(duì)應(yīng)的輸入疲扎、處理和輸出?? 5）把隱式需求轉(zhuǎn)變?yōu)槊鞔_。
第二捷雕、明確測(cè)試活動(dòng)的五個(gè)要素：測(cè)試需求是什么椒丧、決定怎么測(cè)試、明確測(cè)試時(shí)間救巷、確定測(cè)試人員壶熏、確定測(cè)試環(huán)境：測(cè)試中需要的技能，工具以及相應(yīng)的背景知識(shí)浦译，測(cè)試過程中可能遇到的風(fēng)險(xiǎn)等等棒假。測(cè)試需求需要做到盡可能的詳細(xì)明確溯职，以避免測(cè)試遺漏和誤解。
測(cè)試計(jì)劃的目的：
（1）為測(cè)試各項(xiàng)活動(dòng)制定一個(gè)現(xiàn)實(shí)可行的帽哑、綜合的計(jì)劃谜酒，包括每項(xiàng)測(cè)試活動(dòng)的對(duì)象、范圍妻枕、方法僻族、進(jìn)度和預(yù)期結(jié)果。
（2）為項(xiàng)目實(shí)施建立一個(gè)組織模型屡谐，并定義測(cè)試項(xiàng)目中每個(gè)角色的責(zé)任和工作內(nèi)容鹰贵。
（3）開發(fā)有效的測(cè)試模型，能正確地驗(yàn)證正在開發(fā)的軟件系統(tǒng)康嘉。
（4）確定測(cè)試所需要的時(shí)間和資源碉输，以保證其可獲得性、有效性亭珍。
（5）確立每個(gè)測(cè)試階段測(cè)試完成以及測(cè)試成功的標(biāo)準(zhǔn)敷钾、要實(shí)現(xiàn)的目標(biāo)。
（6）識(shí)別出測(cè)試活動(dòng)中各種風(fēng)險(xiǎn)肄梨，并消除可能存在的風(fēng)險(xiǎn)阻荒，降低由不可能消除的風(fēng)險(xiǎn)所帶來的損失。
什么時(shí)候開始寫測(cè)試計(jì)劃：
測(cè)試需求分析前總體測(cè)試計(jì)劃書/測(cè)試需求分析后詳細(xì)測(cè)試計(jì)劃書
由誰來編寫測(cè)試計(jì)劃：
具有豐富經(jīng)驗(yàn)的項(xiàng)目測(cè)試負(fù)責(zé)人
測(cè)試計(jì)劃的內(nèi)容：
1.簡介 2.參考文檔和提交文件 3.進(jìn)度安排 4.測(cè)試資源 5.嚴(yán)重程度和優(yōu)先級(jí) 6.風(fēng)險(xiǎn)分析
7.測(cè)試策略
結(jié)束條件(項(xiàng)目上線的條件)：
1众羡、軟件經(jīng)過充分的測(cè)試
?? 開發(fā)人員測(cè)試---〉交叉測(cè)試---〉測(cè)試人員測(cè)試---〉用戶的業(yè)務(wù)專家測(cè)試---〉一定數(shù)量的用戶業(yè)務(wù)專家集中測(cè)試---〉上線前試運(yùn)行----〉上線侨赡。
?? 壓力測(cè)試是必須的
2、用戶培訓(xùn) ：管理員粱侣，一定廠或地區(qū)必須有一個(gè)人經(jīng)過了培訓(xùn)羊壹。
3、基礎(chǔ)數(shù)據(jù)導(dǎo)入完成 ：用戶齐婴、組織機(jī)構(gòu)油猫、業(yè)務(wù)數(shù)據(jù)等基礎(chǔ)必須數(shù)據(jù)導(dǎo)入完成。
4柠偶、授權(quán)必須完成
5情妖、新老系統(tǒng)的切換必須提前演練過，各種老數(shù)據(jù)的導(dǎo)入工作完成诱担。
6毡证、應(yīng)急方案必須有。
常見的測(cè)試風(fēng)險(xiǎn)：
需求風(fēng)險(xiǎn)蔫仙，測(cè)試用例風(fēng)險(xiǎn)料睛，缺陷風(fēng)險(xiǎn)，代碼質(zhì)量風(fēng)險(xiǎn)，測(cè)試環(huán)境風(fēng)險(xiǎn)秦效，測(cè)試技術(shù)風(fēng)險(xiǎn)
回歸測(cè)試風(fēng)險(xiǎn)雏蛮，溝通協(xié)調(diào)風(fēng)險(xiǎn)涎嚼，研發(fā)流程風(fēng)險(xiǎn)阱州，其他不可預(yù)計(jì)風(fēng)險(xiǎn)
測(cè)試用例的要素：
用例編號(hào) 用例描述?? 執(zhí)行條件? 預(yù)期結(jié)果 測(cè)試輸入? 實(shí)際結(jié)果
測(cè)試用例級(jí)別的劃分：
高，中法梯，低
怎樣保證覆蓋用戶需求苔货？
分類：一次告知類，個(gè)人喜好立哑，不合理需求類夜惭，合理需求類拓展關(guān)鍵詞
寫好測(cè)試用例的關(guān)鍵 /寫好用例要關(guān)注的維度：
做好測(cè)試用例工作的關(guān)鍵是要充分考慮測(cè)試計(jì)劃的實(shí)用性，采用評(píng)審和更新機(jī)制铛绰，確保測(cè)試計(jì)劃滿足實(shí)際需求诈茧。因?yàn)檐浖?xiàng)目是一個(gè)漸進(jìn)的過程，中間不可避免地會(huì)發(fā)生需求變化捂掰，為滿足需求變化敢会，測(cè)試計(jì)劃也需要及時(shí)地進(jìn)行變更。測(cè)試策略要作為測(cè)試的重點(diǎn)進(jìn)行描述这嚣。測(cè)試策略是測(cè)試計(jì)劃中的重要組成部分鸥昏，測(cè)試計(jì)劃是從宏觀上說明一個(gè)項(xiàng)目的測(cè)試需求、測(cè)試方法姐帚、測(cè)試人員安排等因素吏垮。
測(cè)試用例的狀態(tài)：
排隊(duì)（In Queue）：
測(cè)試用例已經(jīng)指定給某個(gè)測(cè)試人，不準(zhǔn)備在這一個(gè)測(cè)試階段運(yùn)行罐旗。
該測(cè)試正在進(jìn)行膳汪，并且會(huì)持續(xù)一段時(shí)間。
一些因素會(huì)導(dǎo)致測(cè)試不能進(jìn)行到底九秀，例如某個(gè)功能欠缺或者測(cè)試環(huán)境的某個(gè)部分欠缺旅敷。我通常會(huì)在測(cè)試用例總結(jié)工作表的意見欄記錄下阻塞的狀態(tài)。你可以把阻塞理解為：我希望運(yùn)行測(cè)試颤霎，但是目前還不能運(yùn)行測(cè)試媳谁。
你決定在當(dāng)前測(cè)試階段跳過某個(gè)測(cè)試，可能是因?yàn)樗膬?yōu)先權(quán)相對(duì)較低友酱。
測(cè)試運(yùn)行結(jié)束晴音，測(cè)試人得到了預(yù)料中的測(cè)試結(jié)果狀態(tài)和測(cè)試行為。
在很多情況下锤躁，測(cè)試人得到預(yù)料之外的測(cè)試結(jié)果，狀態(tài)或行為或详，這些結(jié)果與測(cè)試目標(biāo)相差甚遠(yuǎn)系羞。這就引發(fā)了關(guān)于系統(tǒng)質(zhì)量的疑問郭计。一個(gè)或多個(gè)測(cè)試錯(cuò)誤需要記錄下來。
在很多情況下椒振，測(cè)試人得到預(yù)料之外的測(cè)試結(jié)果昭伸，狀態(tài)或行為，但是這些結(jié)果與測(cè)試目標(biāo)差別不是很大另一種想法是澎迎，警告意味著當(dāng)前的錯(cuò)誤是無關(guān)緊要的庐杨，或者對(duì)正在測(cè)試的特征是沒有意義的。系統(tǒng)報(bào)出了更多的錯(cuò)夹供。我處理這個(gè)問題的一個(gè)標(biāo)準(zhǔn)是只和延期的或不是一定要改的錯(cuò)誤相關(guān)的測(cè)試可以標(biāo)記為警告灵份，而不是失敗。
一個(gè)測(cè)試在第一個(gè)循環(huán)中被標(biāo)為失敗或警告哮洽，第二個(gè)測(cè)試發(fā)布中將第一個(gè)測(cè)試循環(huán)出現(xiàn)的錯(cuò)誤修改了填渠。重新運(yùn)行了整個(gè)測(cè)試用例后，沒有錯(cuò)誤出現(xiàn)鸟辅。將這類測(cè)試標(biāo)記為關(guān)閉而不是通過氛什，使得你可以跟蹤測(cè)試在某一個(gè)測(cè)試發(fā)布中失敗的實(shí)事
常見的測(cè)試用例設(shè)計(jì)方法：
等價(jià)類劃分法，邊界值分析法剔桨，錯(cuò)誤推測(cè)法屉更，因果圖法，正交實(shí)驗(yàn)法洒缀，場(chǎng)景法
判定表用在哪些時(shí)候/哪些功能：
判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況下的工具.在程序設(shè)計(jì)發(fā)展的初期瑰谜，判定表：編寫程序的輔助工具
什么時(shí)候用到場(chǎng)景法：
基本流和備選流，一般基本流為正常的測(cè)試树绩，測(cè)試結(jié)果為成功的測(cè)試萨脑，備選流為異常的情況測(cè)試
測(cè)試環(huán)境怎么搭建的：
1，在搭建測(cè)試環(huán)境前是需要和開發(fā)人員做個(gè)溝通交接工作的饺饭，一般他們會(huì)給到相應(yīng)的系統(tǒng)發(fā)布手冊(cè)渤早，我們會(huì)根據(jù)這個(gè)手冊(cè)操作流程來搭建。
2瘫俊，雖然在當(dāng)下鹊杖，越來越多的平臺(tái)開始使用linux操作系統(tǒng)，但也存在差異性扛芽，常見的linux包含redhat骂蓖、centos以及ubuntu等。同樣川尖，不同平臺(tái)使用的web服務(wù)器也不一樣登下，當(dāng)今主流的web服務(wù)器包括Tomcat，apache、nginx以及weblogic被芳。而數(shù)據(jù)庫則分為MySQL和oracle.
這個(gè)要看不同軟件是采用什么類型的要素來進(jìn)行開發(fā)的缰贝。
3，由于源碼程序是使用JAVA編寫的畔濒，所以在事先需要向開發(fā)拿到相關(guān)編譯好的安裝包剩晴。
4，接著需要用xshell(或CRT)遠(yuǎn)程連接上linux系統(tǒng)篓冲，把相關(guān)的服務(wù)器停掉李破。在這里以tomcat服務(wù)器為例宠哄，需要把java程序包放到webapps目錄下壹将。
5，接著就是需要啟動(dòng)tomcat服務(wù)器了毛嫉，操作步驟如下：
? ? ?首先要停止tomcat服務(wù)器诽俯，命令如下
? ? ?ps -ef | grep tomcat -- 查詢出tomcat的進(jìn)程ID，
? ? ? 然后承粤，使用命令 kill -9 tomcat的進(jìn)程ID暴区。
6，最后就是要重新啟動(dòng)tomcat,首先是進(jìn)入tomcat的bin目錄辛臊，然后執(zhí)行命令 ./catalina.sh start即可仙粱。
偶然性問題的處理：
一、一定要提交３菇ⅰ伐割！
1． 記得有這么個(gè)缺陷，以后再遇到的時(shí)候可能就會(huì)了解發(fā)生的原因刃唤。
2． 盡力去查找出錯(cuò)的原因隔心，比如有什么特別的操作，或者一些操作環(huán)境等尚胞。
3． 程序員對(duì)程序比測(cè)試人員熟悉的多硬霍，也許你提交了，即使無法重現(xiàn)笼裳，程序員也會(huì)了解問題所在唯卖。
4． 無法重現(xiàn)的問題再次出現(xiàn)后，可以直接叫程序員來看看問題躬柬。
5． 記錄bug要盡量描述清楚發(fā)生問題時(shí)的測(cè)試步驟拜轨、測(cè)試環(huán)境、測(cè)試數(shù)據(jù)楔脯。
二撩轰、盡量重現(xiàn)bug
對(duì)于整個(gè)項(xiàng)目或者產(chǎn)品而言，如果這些不可復(fù)現(xiàn)的Bug是很嚴(yán)重的Bug，比如導(dǎo)致系統(tǒng)崩潰等堪嫂，如果不能及時(shí)偎箫、準(zhǔn)確的定位和解決，最終發(fā)布出來的軟件到達(dá)用戶手中后皆串，一旦出現(xiàn)勢(shì)必會(huì)影響軟件在用戶心中的形象淹办，嚴(yán)重的會(huì)“迫使”用戶選擇競(jìng)爭(zhēng)對(duì)手的產(chǎn)品，這些顯然都是公司所不愿看到的恶复。而對(duì)于測(cè)試人員而言怜森，出現(xiàn)了這些不可復(fù)現(xiàn)的Bug，實(shí)際上是一次很好的鍛煉和提高機(jī)會(huì)谤牡，如果只是提交缺陷報(bào)告將這個(gè)大皮球踢給開發(fā)人員副硅，不僅喪失了一次提高測(cè)試水平的機(jī)會(huì)，還有可能破壞和開發(fā)人員之間的關(guān)系翅萤。
要想復(fù)現(xiàn)不可復(fù)現(xiàn)的Bug恐疲，需要先提到一個(gè)概念就是ET（Exploring Test），也就是探索式測(cè)試套么，這種測(cè)試方法是由James Bach首先提出來的培己，在所掌握的被測(cè)對(duì)象的信息不是很充分的情況下，這是一種很有效的測(cè)試方法.當(dāng)出現(xiàn)不可復(fù)現(xiàn)的Bug時(shí)胚泌，大家可以從以下五個(gè)方面來進(jìn)行考慮：
1省咨、被測(cè)對(duì)象的版本信息
我測(cè)試的到底是哪個(gè)版本，這主要是有兩個(gè)作用：一是確認(rèn)我測(cè)試的是正式的軟件版本玷室，如果不是就先記錄下該問題零蓉，然后選擇正式的版本進(jìn)行測(cè)試（開發(fā)人員基于嘗試的一次非正規(guī)的修改可能會(huì)導(dǎo)致不可復(fù)現(xiàn)的Bug）；二是可以和其它版本進(jìn)行對(duì)比阵苇，如果其它的版本沒有類似的問題壁公，就可以去對(duì)比這兩個(gè)版本之間的區(qū)別。
2绅项、環(huán)境
這里的環(huán)境是指出現(xiàn)不可復(fù)現(xiàn)的Bug時(shí)所對(duì)應(yīng)的測(cè)試環(huán)境等紊册，比如測(cè)試所用的計(jì)算機(jī)，如果出現(xiàn)不可復(fù)現(xiàn)的Bug快耿，那我換一臺(tái)機(jī)器是不是還會(huì)出現(xiàn)類似的問題囊陡，也就是說通過環(huán)境的改變來進(jìn)一步搜集不可復(fù)現(xiàn)Bug的相關(guān)信息。
3掀亥、模式
這里的模式是指我對(duì)這個(gè)Bug如何出現(xiàn)的一個(gè)理解撞反，先給這個(gè)Bug設(shè)定一個(gè)模式，比如是不是<u>[<u>數(shù)據(jù)庫</u>](javascript:;)</u>通信中斷搪花，然后再進(jìn)行測(cè)試遏片，收集更多的信息去修改和完善這個(gè)模式嘹害，這樣不斷進(jìn)行，最終直到Bug能完全復(fù)現(xiàn)為止吮便，這個(gè)時(shí)候只要使用這個(gè)模式就可以復(fù)現(xiàn)出Bug了笔呀。
4、人
這里提到的人有兩個(gè)含義：一是測(cè)試是由人來進(jìn)行的髓需，人的操作许师、人的思維方式會(huì)有不同，通過分析這些信息也有可能找到這些不可復(fù)現(xiàn)的Bug的蛛絲馬跡僚匆；二是想復(fù)現(xiàn)不可復(fù)現(xiàn)的Bug微渠，往往需要多<u>個(gè)人</u>之間的相互協(xié)作，比如測(cè)試人員咧擂、開發(fā)人員等逞盆，通過大家的溝通和協(xié)作就能更容易去復(fù)現(xiàn)了。
5、測(cè)試工具
通過一些debug工具或者log工具等搜集內(nèi)存等信息英古，根據(jù)這些信息來進(jìn)行分析，找出不同信息之間的共同點(diǎn)，比如某一塊內(nèi)存始終都會(huì)被改寫等寂嘉，通過這種方式來去復(fù)現(xiàn)Bug。
上面的五個(gè)方面都是和ET的思想緊密相關(guān)的瘪撇，通過不斷的測(cè)試和不斷的信息收集和分析缀去，逐步的把模糊的、不確定的測(cè)試變成清晰的识脆、確定的測(cè)試设联，這樣就能復(fù)現(xiàn)那些不能復(fù)現(xiàn)的Bug了∽莆妫考慮信息時(shí)可以從以上五個(gè)方面來進(jìn)行考慮离例。
三、實(shí)在沒辦法重現(xiàn)
問題無法重現(xiàn)悉稠，也要提出宫蛆，程序員那里可以回復(fù)無法再現(xiàn)。問題放在那里的猛，等到再次出現(xiàn)的時(shí)候耀盗，就立刻叫程序員過來查看。
當(dāng)我們認(rèn)為某個(gè)地方是bug卦尊，但開發(fā)認(rèn)為不是bug叛拷，怎么處理：
1.找到需求文檔或者是原型圖進(jìn)行匹對(duì)
2.嘗試多種測(cè)試環(huán)境和多種測(cè)試方式來確認(rèn)是否為bug
3.整理bug的復(fù)現(xiàn)的步驟和出現(xiàn)的頻率
4.開發(fā)堅(jiān)持不認(rèn)為是bug的時(shí)候找項(xiàng)目經(jīng)理測(cè)試經(jīng)理進(jìn)行溝通來確認(rèn)是否為bug
5.將客戶經(jīng)理 測(cè)試 測(cè)試經(jīng)理和項(xiàng)目經(jīng)理進(jìn)行開確認(rèn)會(huì)來判定是否為bug
6.測(cè)試人員需要將bug整理并寫入測(cè)試總結(jié)中
產(chǎn)品在上線后用戶發(fā)現(xiàn)bug，這時(shí)測(cè)試人員應(yīng)做哪些工作：
1.測(cè)試人員可以做的是重現(xiàn)這個(gè)問題并及時(shí)反饋給開發(fā)人員岂却，找到解決方案進(jìn)行修復(fù)
2.由于疏忽造成測(cè)試用例執(zhí)行遺漏忿薇，測(cè)試人員需要在下次執(zhí)行測(cè)試的過程和下個(gè)版本上線的前要補(bǔ)全測(cè)試用例并避免這樣的情況發(fā)生裙椭，
分析bug的根本原因，考慮如何避免此類問題再次發(fā)生
分析bug是在哪個(gè)階段引入署浩？是設(shè)計(jì)階段骇陈、開發(fā)階段、測(cè)試階段瑰抵？
分析bug引入的原因是什么你雌？是流程問題、技術(shù)問題二汛、管理問題婿崭？
處理問題的流程是否合理？是否有問題預(yù)警肴颊、是否有緊急上線規(guī)范氓栈。
出現(xiàn)問題后，根據(jù)問題的緊急性而決定解決方案婿着，如有的必須的幾個(gè)小時(shí)內(nèi)解決授瘦，有的可以幾天內(nèi)解決，有的必須立刻修改錯(cuò)誤數(shù)據(jù)讓業(yè)務(wù)能繼續(xù)運(yùn)作......
你也可以談根據(jù)問題嚴(yán)重程度而使用不同的修復(fù)竟宋、測(cè)試流程提完。
對(duì)于測(cè)試通過的補(bǔ)丁，也可以談安裝窗口的選擇丘侠。
其實(shí)發(fā)現(xiàn)bug后的行動(dòng)很多徒欣，不可能全部談，找?guī)讉€(gè)行動(dòng)談蜗字，讓雇主相信你真的有運(yùn)維經(jīng)驗(yàn)就行打肝。
二八定理：
二八定律又名80/20定律，帕累托法則也叫巴萊特定律挪捕、朱倫法則粗梭、關(guān)鍵少數(shù)法則、不重要多數(shù)法則级零、最省力的法則断医、不平衡原則、被廣泛應(yīng)用于社會(huì)學(xué)及企業(yè)管理學(xué)等妄讯。
是19世紀(jì)末20世紀(jì)意大利經(jīng)濟(jì)學(xué)家帕累托發(fā)現(xiàn)的孩锡。他認(rèn)為，在任何一組東西中亥贸，最重要的只占其中一小部分躬窜，約20%，其余80%盡管是多數(shù)炕置，卻是次要的荣挨，因此又稱二八定律男韧。
如何跟蹤缺陷：
首先，圈定該系統(tǒng)的應(yīng)用范圍默垄，是單一的項(xiàng)目此虑，是一個(gè)部門，還是多個(gè)組口锭。 其次朦前，商定跟蹤模型，這是核心所在鹃操。這一步需要和項(xiàng)目成員一起討論確定一個(gè)大家都接受的模型韭寸，包括設(shè)計(jì)變更的生命周期等一系列定義。接下來要設(shè)定一些角色荆隘，比如提出者恩伺，管理者，質(zhì)量保證工程師或測(cè)試人員等椰拒。然后需要制定一個(gè)執(zhí)行計(jì)劃晶渠；再下來部署該缺陷跟蹤系統(tǒng)，一個(gè)原則是盡量少的對(duì)系統(tǒng)進(jìn)行修正燃观；最后確保該系統(tǒng)正常運(yùn)轉(zhuǎn)褒脯，達(dá)到最初的目標(biāo)。
缺陷的狀態(tài)：
新建仪壮，已修復(fù)憨颠，關(guān)閉，重新打開积锅，推遲，不能復(fù)現(xiàn)养盗，重復(fù)缚陷，不是缺陷
缺陷的等級(jí)：
系統(tǒng)崩潰 ：嚴(yán)重，一般往核，次要箫爷，建議
分別為：致命的(Fatal)，嚴(yán)重的(Critical)聂儒，一般的(Major)虎锚，微小的(Minor)。
A類—致命的軟件缺陷(Fatal):造成系統(tǒng)或應(yīng)用程序崩潰衩婚、死機(jī)窜护、系統(tǒng)掛起，或造成數(shù)據(jù)丟失非春，主要功能完全喪失柱徙，導(dǎo)致本模塊以及相關(guān)模塊異常等問題缓屠。如代碼錯(cuò)誤，死循環(huán)护侮，數(shù)據(jù)庫發(fā)生死鎖敌完、與數(shù)據(jù)庫連接錯(cuò)誤或數(shù)據(jù)通訊錯(cuò)誤，未考慮異常操作羊初，功能錯(cuò)誤等
B類—嚴(yán)重錯(cuò)誤的軟件缺陷（critical）：系統(tǒng)的主要功能部分喪失滨溉、數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失长赞。問題局限在本模塊业踏，導(dǎo)致模塊功能失效或異常退出。如致命的錯(cuò)誤聲明涧卵，程序接口錯(cuò)誤勤家，數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則柳恐、缺省值未加完整性等約束條件
C類—一般錯(cuò)誤的軟件缺陷（major）：次要功能沒有完全實(shí)現(xiàn)但不影響使用伐脖。如提示信息不太準(zhǔn)確，或用戶界面差乐设，操作時(shí)間長讼庇，模塊功能部分失效等，打印內(nèi)容近尚、格式錯(cuò)誤蠕啄，刪除操作未給出提示，數(shù)據(jù)庫表中有過多的空字段等
D類—較小錯(cuò)誤的軟件缺陷（Minor）:使操作者不方便或遇到麻煩戈锻，但它不影響功能過的操作和執(zhí)行歼跟，如錯(cuò)別字、界面不規(guī)范（字體大小不統(tǒng)一格遭，文字排列不整齊哈街，可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志），輔助說明描述不清楚
E類-?建議問題的軟件缺陷（Enhancemental）：由問題提出人對(duì)測(cè)試對(duì)象的改進(jìn)意見或測(cè)試人員提出的建議拒迅、質(zhì)疑骚秦。
常用的軟件缺陷的優(yōu)先級(jí)表示方法可分為：立即解決P1、高優(yōu)先級(jí)P2璧微、正常排隊(duì)P3作箍、低優(yōu)先級(jí)P4。立即解決是指缺陷導(dǎo)致系統(tǒng)幾乎不能使用或者測(cè)試不能繼續(xù)前硫，需立即修復(fù)胞得；高優(yōu)先級(jí)是指缺陷嚴(yán)重影響測(cè)試，需要優(yōu)先考慮开瞭；正常排隊(duì)是指缺陷需要正常排隊(duì)等待修復(fù)懒震；而低優(yōu)先級(jí)是指缺陷可以在開發(fā)人員有時(shí)間的時(shí)候再被糾正罩息。
缺陷單應(yīng)該包含這些要素：
軟件缺bai陷報(bào)告單的意義是測(cè)試人員將發(fā)現(xiàn)du的BUG以書面的形式zhi提交給開發(fā)人員，作為定dao位缺陷的依據(jù)（zhuan明確職責(zé)个扰，避免口角的方法之一）瓷炮，也作為日后缺陷度量的數(shù)據(jù)依據(jù)。之后递宅，開發(fā)人員會(huì)依據(jù)缺陷報(bào)告但重現(xiàn)缺陷進(jìn)行修改娘香。
缺陷報(bào)告單就是由一個(gè)個(gè)附帶多種屬性的bug組成的。軟件缺陷的相關(guān)屬性一般有這些：1缺陷發(fā)現(xiàn)人 2缺陷發(fā)現(xiàn)時(shí)間 3缺陷狀態(tài) 4缺陷的嚴(yán)重程度 5缺陷所屬軟件的版本 6缺陷修改時(shí)間
測(cè)試報(bào)告的主要內(nèi)容：
（一）bai測(cè)試項(xiàng)目背景介紹
主要介紹這份測(cè)試報(bào)告具體的編寫目的办龄、測(cè)試系統(tǒng)名稱烘绽、測(cè)試環(huán)境、文中用到的專業(yè)術(shù)語俐填，以及列出該份測(cè)試報(bào)告中引用的參考資料安接。
（二）測(cè)試計(jì)劃
列出詳細(xì)的測(cè)試計(jì)劃，通過表格標(biāo)出測(cè)試內(nèi)容英融，逐項(xiàng)說明系統(tǒng)功能盏檐、系統(tǒng)輸出等質(zhì)量指標(biāo)，以及測(cè)試進(jìn)度等驶悟；
（三）測(cè)試結(jié)果及發(fā)現(xiàn)
逐項(xiàng)分析本項(xiàng)測(cè)試中實(shí)際得到的動(dòng)態(tài)輸出（包括內(nèi)部生成數(shù)據(jù)輸出）結(jié)果同對(duì)于動(dòng)態(tài)輸出的要求進(jìn)行比較胡野，陳述其中的各項(xiàng)發(fā)現(xiàn)。
（四）測(cè)試分析摘要
記錄測(cè)試過程中軟件缺陷和限制痕鳍，同時(shí)說明每項(xiàng)缺陷和限制對(duì)軟件性能的影響硫豆，并說明全部測(cè)得的性能缺陷的累積影響和總影響，最后統(tǒng)計(jì)本次測(cè)試過程中的資源損耗情況笼呆。軟件測(cè)試報(bào)告也可以找測(cè)試機(jī)構(gòu)做熊响，需要第三方軟件測(cè)試報(bào)告可以咨詢卓碼軟件測(cè)評(píng)，獨(dú)立的第三方測(cè)試機(jī)構(gòu)抄邀，擁有完善的測(cè)試環(huán)境和先進(jìn)的測(cè)試技術(shù)耘眨，幫助企業(yè)做好軟件測(cè)試工作。
如何定位bug：
1境肾、發(fā)現(xiàn)bug，首先要查看bug的詳細(xì)信息胆屿，根據(jù)描述初步分析是哪個(gè)模塊哪段代碼的問題
2奥喻、檢查引發(fā)bug的測(cè)試環(huán)境、測(cè)試代碼段和測(cè)試數(shù)據(jù)非迹，排除測(cè)試人員的誤操作導(dǎo)致的程序異常
3环鲤、確認(rèn)測(cè)試代碼、測(cè)試環(huán)境和數(shù)據(jù)都正確后憎兽，再進(jìn)一步分析bug根源冷离。這里就需要看具體的測(cè)試業(yè)務(wù)了吵冒，可借助相關(guān)的工具進(jìn)行分析，比如firebug插件等
4西剥、如果產(chǎn)品或業(yè)務(wù)有相關(guān)的日志記錄痹栖，可通過分析日志來確認(rèn)bug
5、當(dāng)測(cè)試人員經(jīng)過一系列的分析瞭空，可以基本確認(rèn)bug產(chǎn)生的原因后揪阿，就可以直接找開發(fā)提bug了（注意溝通技巧）
6、如果各方面都分析完還不能確認(rèn)bug的原因咆畏，可以找開發(fā)一起定位（注意保留bug現(xiàn)場(chǎng)或者可以復(fù)現(xiàn)bug場(chǎng)景）
7南捂、確認(rèn)bug后，提單給開發(fā)進(jìn)行bug跟蹤旧找。
?問題單上要描述清楚以下信息：?
具體的測(cè)試時(shí)間溺健、測(cè)試環(huán)境、測(cè)試場(chǎng)景钮蛛、測(cè)試的具體業(yè)務(wù)和功能鞭缭、使用的測(cè)試代碼和測(cè)試數(shù)據(jù)、測(cè)試執(zhí)行步驟愿卒、測(cè)試結(jié)果缚去、bug現(xiàn)象（最好截圖）、日志記錄琼开、預(yù)期結(jié)果易结、bug確認(rèn)相關(guān)人員等
8、跟蹤bug柜候，等開發(fā)人員修復(fù)bug后進(jìn)行回歸測(cè)試搞动。
開發(fā)沒時(shí)間修復(fù)，如何推進(jìn)bug的修復(fù)：
開發(fā)不修改bug的原因有四：bug路徑較深渣刷、上線時(shí)間緊急鹦肿、改動(dòng)影響范圍大、第三方應(yīng)用問題辅柴。我們逐條分析解決方案
1箩溃、 針對(duì)路徑較深的bug，測(cè)試在推動(dòng)開發(fā)修復(fù)bug時(shí)碌嘀，需要注意以下幾點(diǎn)
a) 從用戶的角度分析問題的嚴(yán)重性涣旨，分析用戶的遇到此問題的概率，引導(dǎo)開發(fā)站在用戶角度去思考股冗，從而使開發(fā)意識(shí)到問題的嚴(yán)重性
b) 可以和開發(fā)人員列舉一個(gè)之前的類似問題霹陡，為開發(fā)提供參考
c) 產(chǎn)品是負(fù)責(zé)這個(gè)軟件的人員，當(dāng)測(cè)試與開發(fā)意見無法達(dá)成一致時(shí)，不要因?yàn)闊o法推動(dòng)開發(fā)修改而放棄烹棉，一定要找產(chǎn)品確認(rèn)攒霹，最終的決定權(quán)交給產(chǎn)品人員。
2浆洗、 上線時(shí)間緊張催束，開發(fā)來不及修改了，這個(gè)時(shí)候測(cè)試應(yīng)該分析問題的嚴(yán)重性辅髓，和產(chǎn)品人員商議是否需要修改
3泣崩、 修改bug改動(dòng)較大，影響范圍廣洛口，沒有最優(yōu)的解決方案等情況在項(xiàng)目即將上線的節(jié)點(diǎn)比較忌諱這種事情的發(fā)生矫付。面對(duì)這種情況，建議開發(fā)人員做調(diào)研工作第焰，請(qǐng)教其他的同事买优，或者組織一個(gè)臨時(shí)會(huì)議，集眾人之力研究好的修改方案
4挺举、 第三方應(yīng)用問題杀赢，開發(fā)無法修改。確認(rèn)原因之后需要找相關(guān)的工作人員湘纵，例如產(chǎn)品脂崔，聯(lián)系第三方輸入法的工作人員，反饋問題梧喷，盡量推動(dòng)應(yīng)用解決問題
軟件測(cè)試流程：
我們一般在項(xiàng)目進(jìn)行開立項(xiàng)會(huì)（產(chǎn)品砌左，項(xiàng)目，開發(fā)铺敌，測(cè)試）的時(shí)候進(jìn)行參與汇歹，討論需求并提出建議，在立項(xiàng)會(huì)中執(zhí)行
需求文檔偿凭，由UI設(shè)計(jì)原型圖产弹，開發(fā)根據(jù)需求文檔進(jìn)行編碼，我們測(cè)試會(huì)根據(jù)需求文檔進(jìn)行編寫 測(cè)試設(shè)計(jì)弯囊，根據(jù)模塊模
塊的（顆粒度） 劃分并編寫測(cè)試用例岂津，開發(fā)結(jié)束后測(cè)試對(duì)主要功能進(jìn)行冒煙測(cè)試寡夹，執(zhí)行測(cè)試用例谢床，提交bug開發(fā)進(jìn)行
修改修改成功后關(guān)閉bug源哩，用例執(zhí)行結(jié)束后進(jìn)行回歸測(cè)試，在上線進(jìn)行測(cè)試總結(jié)奄毡。
項(xiàng)目介紹：
對(duì)一支圓珠筆進(jìn)行測(cè)試，要從哪些方面進(jìn)行測(cè)試贝或？
1.功能測(cè)試：圓珠筆按下是否能正常書寫吼过。
2.性能測(cè)試：筆芯彈出彈回的快慢锐秦。
3.負(fù)載測(cè)試：連續(xù)按，看彈簧能經(jīng)受多少次伸縮盗忱。
4.兼容性測(cè)試：看是否可以使用其他筆芯酱床。
5.強(qiáng)度測(cè)試：用力過度會(huì)有什么影響
6.可恢復(fù)性測(cè)試：長時(shí)間按住彈簧，松開后看彈簧是否可以恢復(fù)
7.界面測(cè)試：筆的外觀趟佃，舒適度
8.安全性測(cè)試：是否會(huì)對(duì)使用者造成傷害
三角形測(cè)試用例設(shè)計(jì):
1扇谣、 當(dāng)三邊不可能構(gòu)成三角形時(shí)提示錯(cuò)誤，可構(gòu)成三角形時(shí)計(jì)算三角形周長闲昭。
2罐寨、若是等腰三角形打印“等腰三角形”，若兩個(gè)等腰的平方和等于第三邊平方和序矩，則打印“等腰直角三角形”鸯绿。
3、若是等邊三角形簸淀，則打悠亢：“等邊三角形”。
4租幕、畫出程序流程圖并設(shè)計(jì)一個(gè)測(cè)試用例舷手。
1、構(gòu)成三角形的條件：任意兩邊之和大于第三邊劲绪；
2男窟、構(gòu)成等腰三角形的條件：任意兩邊相等；
3珠叔、構(gòu)成等腰直角三角形的條件：任意兩邊相等蝎宇，而且兩條邊的平方和等于第三邊的平方和；
4祷安、構(gòu)成等邊三角形的條件：三條邊都相等姥芥。
在項(xiàng)目中發(fā)現(xiàn)哪些經(jīng)典bug？什么原因?qū)е碌模?/h3>
第一汇鞭，出現(xiàn)這個(gè)bug,可以判斷研發(fā)在最后保存數(shù)據(jù)時(shí),并沒有對(duì)數(shù)據(jù)的有效性進(jìn)行判斷,而是在相關(guān)控件進(jìn)行操作時(shí)進(jìn)行判斷的.這樣風(fēng)險(xiǎn)有點(diǎn)大,因?yàn)榭丶g對(duì)數(shù)據(jù)也會(huì)有影響,如果僅在操作控件時(shí)判斷凉唐，會(huì)產(chǎn)生問題.
第二，這種臟數(shù)據(jù)雖然不會(huì)在視圖展示霍骄，但保存在服務(wù)器上,在各個(gè)平臺(tái)上均會(huì)進(jìn)行同步.這還需要保證其他平臺(tái)對(duì)于臟數(shù)據(jù)進(jìn)行處理台囱，且不會(huì)出現(xiàn)問題.風(fēng)險(xiǎn)較大.
基于這兩個(gè)原因，研發(fā)還是解決了這個(gè)問題.這對(duì)我還是有一定啟發(fā)的.
看問題可能會(huì)更考慮多方面的影響.不單純只是現(xiàn)象.
一個(gè)項(xiàng)目完成時(shí)读整，有多個(gè)重要的缺陷沒有被修復(fù)簿训，但是項(xiàng)目負(fù)責(zé)人說可以不修改，你認(rèn)為測(cè)試是不通過的，請(qǐng)簡述你的理由强品。
在需求文檔不太詳細(xì)的情況下膘侮，如何開展測(cè)試：
軟件生命周期中，需求是整個(gè)項(xiàng)目的源頭的榛。俗話說良好的開端是成功的一半琼了，但是，不是每個(gè)項(xiàng)目都能遵從流程夫晌，花太多時(shí)間在需求分析上雕薪，而把精力投入到代碼的編寫中。這可能導(dǎo)致什么問題呢晓淀？開發(fā)和測(cè)試對(duì)需求理解都不充分所袁，開發(fā)出來的功能與實(shí)際需求不符，測(cè)試要么憑自己的經(jīng)驗(yàn)一步一步發(fā)掘潛藏的功能點(diǎn)要糊，把項(xiàng)目往良性的軌道上引纲熏，要么就聽從開發(fā)的腳步，亦步亦趨锄俄。那么測(cè)試人員要如何在需求不明確或者文檔不全的情況下著手測(cè)試才能保證軟件的質(zhì)量呢局劲？
一、參考同類型的網(wǎng)站：一般情況下奶赠，我們測(cè)的系統(tǒng)總會(huì)有原型可參考鱼填，比如我目前測(cè)的訂票系統(tǒng)，就可以參照攜程毅戈，主要功能基本一樣苹丸，細(xì)節(jié)可能有出入，攜程上操作一遍苇经，然后再看看它提供的幫助赘理，再有可以網(wǎng)上搜索資料，參考下行業(yè)的基礎(chǔ)知識(shí)扇单，這都是收集需求的方法商模，這樣子下來也基本對(duì)訂票系統(tǒng)也就有個(gè)認(rèn)識(shí)了，然后與開發(fā)經(jīng)理確認(rèn)蜘澜，再和開發(fā)一起把功能定下來施流，該改的改，該修的修鄙信，BUG一點(diǎn)不含糊瞪醋。弱弱的吐槽下，這個(gè)項(xiàng)目的開發(fā)居然都不知道有需求說明書装诡，雖然寫的基本沒太大的價(jià)值银受。
二践盼、根據(jù)經(jīng)驗(yàn)和常識(shí)判斷：做項(xiàng)目多了就知道，萬變不離其宗蚓土，系統(tǒng)不一樣宏侍，思路可以套用，所謂的學(xué)以致用蜀漆，舉一反三。我上個(gè)項(xiàng)目做的銀行測(cè)試咱旱，我照樣可以測(cè)現(xiàn)在的訂票系統(tǒng)确丢，就在一個(gè)字：活。有需求照需求測(cè)吐限，沒有需求找參照鲜侥，說個(gè)例子吧，訂票系統(tǒng)中有個(gè)功能是積分诸典，需求上就一句話提到有積分功能描函，怎么測(cè)？難道看到有這個(gè)功能就算過了狐粱？我后來就參照了淘寶的積分抵扣舀寓，下單了積分就被臨時(shí)凍結(jié)了，取消訂單又釋放出來肌蜻，但開發(fā)在做這個(gè)功能的時(shí)候也沒有跟他們的頭溝通互墓，直接是要等支付完成后才扣除積分，這導(dǎo)致一個(gè)什么問題呢蒋搜，可以重復(fù)使用積分篡撵，如果真上線使用了，說不定會(huì)造成不小的經(jīng)濟(jì)損失的豆挽。類似這樣的問題太多太多育谬，你總可以從一些地方獲得參照，或者說是靈感帮哈，項(xiàng)目測(cè)的怎么樣膛檀，跟測(cè)試人員的素養(yǎng)有很大的關(guān)系，尤其是在沒有規(guī)范的流程下但汞。
三宿刮、溝通：毋庸置疑，這太重要了私蕾，需求不一定在文檔中寫出來僵缺，但道理上開發(fā)肯定知道需求的，但一般不會(huì)主動(dòng)和測(cè)試溝通踩叭，因此磕潮，我們作為測(cè)試就要主動(dòng)和開發(fā)人員溝通翠胰，不僅可以對(duì)系統(tǒng)有更深的了解，還可以對(duì)項(xiàng)目進(jìn)度有把握自脯。
四之景、多和同事討論
如何盡快找到軟件中的bug：
盡快熟悉公司的產(chǎn)品業(yè)務(wù)
根據(jù)產(chǎn)品的業(yè)務(wù)屬性來熟悉產(chǎn)品的業(yè)務(wù)流程，這樣才能迅速找出軟件中存在的一些重要的缺陷膏潮，這樣發(fā)現(xiàn)的軟件的價(jià)值才是有價(jià)值的锻狗，否則即使你能找到一些軟件缺陷，那也是純軟件的缺陷焕参，價(jià)值不大轻纪。
把自己當(dāng)成是用戶
把自己當(dāng)成用戶去使用該軟件，比如在試用軟件的過程中叠纷，思考用戶是這樣操作的么刻帚；
2.1 比如大量要求用戶輸入的軟件界面中，有一些用戶喜歡使用Tab鍵采用全鍵盤的輸入涩嚣，此時(shí)正確的接口應(yīng)該是從左到右崇众，從上到下的順序。
2.2 比如有的用戶喜歡使用快捷鍵進(jìn)行操作（Ctrl+C）航厚，但是實(shí)際情況下一些開發(fā)出來的軟件的快捷鍵根本不起作用顷歌。
2.3 比如軟件在需要用戶輸入信息的時(shí)候（特別是在填寫個(gè)人資料的時(shí)候），必填選項(xiàng)后面一律要用*等醒目的表示要讓知道這個(gè)地方必須要填寫阶淘。
2.4 下拉框不選的時(shí)候衙吩，應(yīng)該有個(gè)默認(rèn)值，并且要多檢查程序中的多處下拉框溪窒，因?yàn)楹芏嗲闆r下下拉框取不到值坤塞。
善于懷疑
世界上沒有絕對(duì)正確的，總有錯(cuò)誤的地方澈蚌，具有叛逆心理摹芙，別人認(rèn)為不可能發(fā)生的事，我卻認(rèn)為可能發(fā)生宛瞄；別人認(rèn)為是對(duì)的浮禾，我卻認(rèn)為是錯(cuò)的。假如一個(gè)水平很高的程序員編寫的程序份汗，不要有“他寫的這個(gè)程序應(yīng)該沒有問題吧”這種想法盈电，這樣很容以遺漏軟件中的Bug。
不用讓程序開發(fā)員“用戶不會(huì)這樣操作”的觀點(diǎn)說服自己
遇到這樣的情況杯活，你要堅(jiān)持自己的正確的觀點(diǎn)匆帚，把這種現(xiàn)象作為一個(gè)Bug。
在測(cè)試的過程中要跟蹤一條數(shù)據(jù)的完整流程旁钧。
比如“點(diǎn)擊商品—收藏商品—加入購物車—訂單結(jié)算—付款—消費(fèi)二維碼—消費(fèi)—二維碼失效”吸重，如果在測(cè)試軟件過程中業(yè)務(wù)流程邏輯都走不通的話互拾，還么這個(gè)軟件測(cè)試與不測(cè)試就沒有什么區(qū)別的。
回歸測(cè)試要注意的事項(xiàng)
程序員提交新的版本后嚎幸，作為測(cè)試人員應(yīng)該立即與程序員溝通這個(gè)修改的功能颜矿，并了解這個(gè)新修改的功能影響那些功能。而被影響的功能嫉晶，是在回歸測(cè)試中優(yōu)先重點(diǎn)測(cè)試的地方骑疆，而且也是最容易產(chǎn)生Bug的地方。
與使用者互動(dòng)的缺陷
7.1 如填寫資料錯(cuò)誤的時(shí)候车遂，應(yīng)該能夠提示錯(cuò)誤的位置封断，讓用戶知道這個(gè)地方輸入的數(shù)據(jù)不對(duì)；
7.2 刪除數(shù)據(jù)前一定要給定出是否刪除的確認(rèn)提示舶担；
7.3 不要在軟件中使用中英文混合的提示：比如對(duì)于用戶在進(jìn)行某個(gè)操作的錯(cuò)誤提示，不要一會(huì)用“Error”彬呻，一會(huì)又用“錯(cuò)誤”衣陶，一定要統(tǒng)一；
7.4 要對(duì)程序員的錯(cuò)別字進(jìn)行檢查闸氮，比如吧“登錄”寫成“登陸”剪况；
7.5 在軟件中不要對(duì)用戶使用很專業(yè)的術(shù)語；
7.6 新增/修改信息白村提交后系統(tǒng)給出“保存/提交/修改成功”的提示信息蒲跨，并自動(dòng)更新顯示译断；
7.7 在用戶進(jìn)行大量的輸入后，點(diǎn)擊保存按鈕或悲，僅僅是因?yàn)槟硞€(gè)地方輸入選擇不正確孙咪，點(diǎn)擊確定后所有的輸入信息都被清空了，這樣的Bug會(huì)大大降低軟件的易用性巡语；
7.8 對(duì)于軟件的查詢功能翎蹈，測(cè)試的時(shí)候設(shè)置開始時(shí)間>結(jié)束時(shí)間，看看能否查詢出記錄男公；
軟件的邊界值
眾所周知軟件最容易在邊界值上出現(xiàn)問題荤堪，所以作為測(cè)試人員一定要在邊界值上多測(cè)試，比如測(cè)試用戶輸入框中的數(shù)值的最大數(shù)和最小數(shù)枢赔，以及為空的情況澄阳；
非法容錯(cuò)性
比如在需要輸入數(shù)字的地方輸入字母，在需要輸入字母的地方輸入數(shù)字踏拜，在需要用戶輸入的文本框中拷貝字?jǐn)?shù)很多的整編文章到這里測(cè)試看看軟件是如何做處理的碎赢；
軟件接口測(cè)試
如果軟件不同部部分是由不同程序員共同完成的，那么要在他們程序接口相關(guān)聯(lián)的地方多檢查执隧，避免雙方程序員互相認(rèn)為做了接口處理揩抡，最后誰也沒有做接口的處理户侥，導(dǎo)致軟件在運(yùn)行中產(chǎn)生缺陷；
兼容性測(cè)試
軟件測(cè)試要在不同的硬件峦嗤、軟件下（包括操作系統(tǒng)蕊唐、瀏覽器）下的測(cè)試；
11.1 硬件 有時(shí)候軟件在配置很高的機(jī)器上烁设，有時(shí)會(huì)隱瞞一些錯(cuò)誤替梨，由于CPU運(yùn)行過快的時(shí)候，很多現(xiàn)象一閃而過装黑，發(fā)現(xiàn)不了缺陷副瀑；
11.2 軟件 有時(shí)軟件在不同版本的瀏覽器中的界面與權(quán)限是不一樣的，這樣的例子就是軟件中的一個(gè)Bug了恋谭；
軟件在壓力之下容易出錯(cuò)
軟件在壓力之下容易產(chǎn)生的錯(cuò)誤糠睡，是作為一名測(cè)試人員必須要知道的事情。所以在測(cè)試過程中疚颊，將軟件在壓力之下長時(shí)間運(yùn)行狈孔，然后看看軟件是否能在壓力之下正常工作；
隨機(jī)測(cè)試：
即使經(jīng)過大量的充分測(cè)試材义，也不能發(fā)現(xiàn)軟件中的所有缺陷均抽，所以在測(cè)試的時(shí)候可以做一些隨機(jī)測(cè)試，比如胡亂在界面上亂點(diǎn)其掂，有時(shí)也會(huì)發(fā)現(xiàn)一些意想不到的軟件缺陷油挥；
學(xué)習(xí)他人經(jīng)驗(yàn)：
什么是bug：
1.產(chǎn)品說明書中規(guī)定要做的事情，而軟件沒有實(shí)現(xiàn)款熬。
2.產(chǎn)品說明書中規(guī)定不要做的事情深寥，而軟件確實(shí)現(xiàn)了。
3.產(chǎn)品說明書中沒有提到過的事情华烟，而軟件確實(shí)現(xiàn)了翩迈。
4.產(chǎn)品說明書中沒有提到但是必須要做的事情，軟件確沒有實(shí)現(xiàn)盔夜。
軟件很難理解负饲，很難使用，速度超慢喂链，測(cè)試人員站在最終用戶的角度看到的問題是平常的但不是正確的返十。
注：產(chǎn)品說明書中沒有提到但是必須要做的事情，軟件確沒有實(shí)現(xiàn)椭微。軟件實(shí)現(xiàn)了產(chǎn)品的功能洞坑，但是沒有考慮軟件在弱網(wǎng)絡(luò)、低電量的情況下也能正常使用蝇率，而做出來的產(chǎn)品在弱網(wǎng)絡(luò)或低電量的情況下報(bào)錯(cuò)迟杂，那么這也是一個(gè)bug刽沾。
ATM機(jī)吞卡的吞卡現(xiàn)象是不是BUG：
這個(gè)不能絕對(duì)的說BUG.應(yīng)為比如說輸入三次錯(cuò)誤的密碼，需求上就是需要吞卡排拷。那這個(gè)就是正常的侧漓，不是BUG。那如果說一直沒有考慮到的操作监氢，導(dǎo)致了吞卡布蔗，那這個(gè)就可以定位成BUG
如何減少非問題單的提交：
有個(gè)程序，在windows上運(yùn)行很慢浪腐，怎么判斷是程序存在問題纵揍，還是軟硬件系統(tǒng)存在問題:
1、檢查系統(tǒng)是否有中度的特征议街，如：瀏覽器窗口連續(xù)打開泽谨，系統(tǒng)中文件圖標(biāo)改成統(tǒng)一圖標(biāo)，CPU使用率保存90%以上等
2特漩、檢查軟件/硬件的配置是否符合軟件的推薦標(biāo)準(zhǔn)
3隔盛、確認(rèn)當(dāng)前的系統(tǒng)是否是獨(dú)立，即沒有對(duì)外提供什么消耗CPU資源的服務(wù)拾稳，如：虛擬機(jī)運(yùn)行
4、如果是C/S或者B/S結(jié)構(gòu)的軟件腊脱，需要檢查是不是因?yàn)榕c服務(wù)器的連接有問題访得，或者訪問有問題造成的；
5陕凹、在系統(tǒng)沒有任何負(fù)載的情況下悍抑，查看性能監(jiān)視器，確認(rèn)應(yīng)用程序?qū)PU/內(nèi)存的訪問情況杜耙。
你們發(fā)現(xiàn)bug會(huì)怎么處理:
發(fā)現(xiàn)BUG后搜骡，接下來你提交到BUG管理平臺(tái)，提交一個(gè)BUG包含哪些內(nèi)容佑女？
BUG標(biāo)題—標(biāo)題要清晰簡潔记靡，寫明BUG描述；如果沒有選擇功能模塊团驱，最好在標(biāo)題中標(biāo)注功能模塊朽们。讓查看BUG的人員清楚知道你所表達(dá)的意思朦蕴。BUG的功能模塊+BUG的操作+BUG的結(jié)果
重現(xiàn)步驟—步驟—簡單寫下發(fā)現(xiàn)BUG的測(cè)試過程，羅列下。能指導(dǎo)開發(fā)重現(xiàn)這個(gè)BUG蚊锹。附上測(cè)試數(shù)據(jù)實(shí)際結(jié)果----出項(xiàng)BUG的結(jié)果，粘貼BUG截圖，日志截圖，截圖直接粘貼就可以了道逗，不要添加附件，附件：日志献烦、測(cè)試數(shù)據(jù)（文件）圖片滓窍，比如上傳頭像，就把圖片放在文件中當(dāng)附件上傳仿荆，開發(fā)要重現(xiàn)這個(gè)BUG贰您，那么根據(jù)你附件的圖片來重現(xiàn)。預(yù)期結(jié)果----記得寫清楚預(yù)期
BUG類型和嚴(yán)重程度-----便于后續(xù)測(cè)試結(jié)果分析拢操，BUG的統(tǒng)計(jì)
BUG測(cè)試環(huán)境---例如：什么系統(tǒng)锦亦；哪個(gè)版本等。兼容性問題令境、難以重現(xiàn)問題
附件----日志文件杠园、文件測(cè)試數(shù)據(jù)
所有以上的如何提交BUG，參考公司前輩寫的BUG舔庶，依葫蘆畫瓢抛蚁，拓展測(cè)試思維。
測(cè)試的BUG備注修改方案和操作信息
如果寫了兩條一摸一樣的BUG或者提交的BUG不是BUG而是操作錯(cuò)誤惕橙，問同事怎么刪除瞧甩，或者是在BUG標(biāo)題前面?zhèn)渥ⅰ靶鑴h除”，然后跟老大說弥鹦，老大會(huì)批量刪除肚逸。或者不刪除自己編輯下其他BUG.
BUG的跟蹤管理-狀態(tài)處理
1.已經(jīng)指派的BUG---已經(jīng)指派給開發(fā)的彬坏，請(qǐng)大家注意自己BUG的走向朦促，隨時(shí)關(guān)注并進(jìn)行跟蹤！如果一直未修復(fù)栓始，提醒開發(fā)修改务冕，以免開發(fā)忘記；如果已經(jīng)修復(fù)等待測(cè)試環(huán)境更新后進(jìn)行驗(yàn)證幻赚。催著改BUG
2.已解決的BUG----等待測(cè)試環(huán)境更新后進(jìn)行驗(yàn)證禀忆，驗(yàn)證通過則關(guān)閉；驗(yàn)證不通過則重新開發(fā)指派給開發(fā)
3.重復(fù)BUG----先去查看下是否跟開發(fā)指定的BUG重復(fù)坯屿？如果確定時(shí)重復(fù)則關(guān)閉油湖；如果不重復(fù)，說明原因领跛，重新打開指派給開發(fā)乏德。
4.不是缺陷----確認(rèn)開發(fā)環(huán)境是否分測(cè)試環(huán)境一致，如果如開發(fā)所說不是缺陷則進(jìn)行關(guān)閉；如果確認(rèn)是缺陷跟開發(fā)溝通喊括，溝通未達(dá)一致找產(chǎn)品/反饋老大確認(rèn)胧瓜，確認(rèn)是BUG注明情況并在次指派給開發(fā)。
5.無法重現(xiàn)----確認(rèn)開發(fā)環(huán)境是否跟測(cè)試環(huán)境一致郑什？包括操作步驟府喳，瀏覽器、環(huán)境蘑拯、特定賬號(hào)等钝满，如果多個(gè)版本驗(yàn)證之后，如開發(fā)所說重現(xiàn)不了申窘，依據(jù)BUG的嚴(yán)重程度跟產(chǎn)品弯蚜，開發(fā)一起確認(rèn)關(guān)閉；如果找到重現(xiàn)原因剃法，注明清楚并再次指派給開發(fā)碎捺。
6.不予解決---找產(chǎn)品經(jīng)理進(jìn)行確認(rèn)。確認(rèn)不予解決進(jìn)行關(guān)閉贷洲；確認(rèn)需要解決請(qǐng)備注原因并打開指派給開發(fā)
7.設(shè)計(jì)如此---找產(chǎn)品經(jīng)理進(jìn)行確認(rèn)收厨。確認(rèn)設(shè)計(jì)如此進(jìn)行關(guān)閉；確認(rèn)是問題优构，備注原因重現(xiàn)指派給開發(fā)诵叁。
8.延期修改---請(qǐng)看下BUG嚴(yán)重程度，是否影響當(dāng)前版本發(fā)布钦椭？與產(chǎn)品經(jīng)理進(jìn)行確認(rèn)黎休。不予延期請(qǐng)根據(jù)情況進(jìn)行激活與情況說明；確定延期則做好記錄玉凯，后續(xù)版本進(jìn)行關(guān)注。
