1：B/S架構(gòu)和C/S架構(gòu)區(qū)別：
b/s：是瀏覽器和服務(wù)端? ?c/s：是客戶端和服務(wù)器
2：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頭信息
3：POST與GET區(qū)別：
get請(qǐng)求沒(méi)有請(qǐng)求體，通過(guò)url攜帶數(shù)據(jù)，大小有限制，不安全
post請(qǐng)求通過(guò)請(qǐng)求體傳輸數(shù)據(jù)，大小沒(méi)有限制，比get安全
4：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)訪問(wèn)增多會(huì)比較占用你的服務(wù)器的性能，考慮減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookin
單個(gè)cookin保存的數(shù)據(jù)不能超過(guò)4K很多瀏覽器限制一個(gè)站點(diǎn)最多保存20個(gè)cookin
5：測(cè)試的目的：
軟件測(cè)試的目的是為了保證軟件產(chǎn)品的最終質(zhì)量，在軟件開(kāi)發(fā)的過(guò)程中，對(duì)軟件產(chǎn)品進(jìn)行質(zhì)量控制一般來(lái)說(shuō)軟件測(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è)試情況撰寫(xiě)測(cè)試報(bào)告。測(cè)試是為了證明程序有錯(cuò)，而不能保證程序沒(méi)有錯(cuò)誤。
6：軟件測(cè)試原則：
1.測(cè)試證明軟件存在缺陷：無(wú)論執(zhí)行什么樣的測(cè)試操作都能證明軟件是有缺陷的
2.不能執(zhí)行窮盡測(cè)試：有些功能是沒(méi)有辦法將所有的測(cè)試情況都邏輯出來(lái)，所以任何的測(cè)試操作都有結(jié)束時(shí)間
3.缺陷存在群集現(xiàn)象：對(duì)于軟件功能來(lái)說(shuō)，核心功能占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è)試工作盡早開(kāi)展
6.殺蟲(chóng)劑現(xiàn)象：同樣的一個(gè)測(cè)試用例不能重的執(zhí)行多次，因此軟件會(huì)對(duì)他產(chǎn)生免疫
7.不存在缺陷謬論：任何軟件不可能是完美的
7：軟件測(cè)試分為哪幾個(gè)階段：
單元測(cè)試：按模塊劃分后的顆粒度進(jìn)行分類測(cè)試
集成測(cè)試：功能模塊的測(cè)試
系統(tǒng)測(cè)試：多個(gè)模塊合成測(cè)試
驗(yàn)收測(cè)試：客戶以及產(chǎn)品經(jīng)理進(jìn)行
單元測(cè)試與集成測(cè)試的側(cè)重點(diǎn)
單元測(cè)試：比如說(shuō)對(duì)Java中的類和方法的測(cè)試，一般由軟件開(kāi)發(fā)人員實(shí)施（盡可能保證測(cè)試用例相對(duì)獨(dú)立，測(cè)試過(guò)程中不要調(diào)用其他類的方法，而是在測(cè)試用例中重寫(xiě)模擬方法）
集成測(cè)試：（測(cè)試各個(gè)單元模塊的接口）在單元測(cè)試的基礎(chǔ)上，把軟件單元按照概要規(guī)格說(shuō)明書(shū)要求，組裝模塊，測(cè)試看是否模塊達(dá)到了規(guī)格技術(shù)指標(biāo)。
系統(tǒng)測(cè)試：（黑盒測(cè)試）在經(jīng)過(guò)集成測(cè)試的單元模塊，按照整體需求規(guī)格說(shuō)明書(shū)，進(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)過(guò)但已修復(fù)好的缺陷不再重新出現(xiàn)。
冒煙測(cè)試：（是自由測(cè)試的一種）是指開(kāi)發(fā)者功能完成后的完整性功能測(cè)試，發(fā)現(xiàn)問(wèn)題后反饋給開(kāi)發(fā)者進(jìn)行修改，然后看這次修改是否真的修復(fù)解決了這bug，或者對(duì)其他模塊造成了影響，這個(gè)時(shí)候就需要冒煙測(cè)試來(lái)進(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è)試：用戶在開(kāi)發(fā)者的場(chǎng)所進(jìn)行測(cè)試，是一個(gè)可控的環(huán)境中測(cè)試的。
Beta測(cè)試：是用戶在對(duì)軟件產(chǎn)品進(jìn)行測(cè)試，開(kāi)發(fā)者不在現(xiàn)場(chǎng)，用戶對(duì)測(cè)試過(guò)程中遇到的bug進(jìn)行記錄，開(kāi)發(fā)并對(duì)它進(jìn)行修改，再測(cè)試，直到用戶覺(jué)得可以了，就部署上線。
8：?jiǎn)卧獪y(cè)試與集成測(cè)試的側(cè)重點(diǎn)：
單元測(cè)試
? ? ? ?是在軟件開(kāi)發(fā)過(guò)程中要進(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ú)地工作，但并不能保證連接起來(lái)也能正常的工作。程序在某些局部反映不出來(lái)的問(wèn)題，在全局上很可能暴露出來(lái)，影響功能的實(shí)現(xiàn)。測(cè)試重點(diǎn)是模塊間的銜接以及參數(shù)的傳遞等。
9：a測(cè)試與?測(cè)試的區(qū)別：
α測(cè)試是指軟件開(kāi)發(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)過(guò)α測(cè)試調(diào)整的軟件產(chǎn)品稱為β版本。
β測(cè)試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試，這些用戶返回有關(guān)錯(cuò)誤信息給開(kāi)發(fā)者。測(cè)試時(shí)，開(kāi)發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)。因而，β測(cè)試是在開(kāi)發(fā)者無(wú)法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場(chǎng)應(yīng)用。在β測(cè)試中，由用戶記下遇到的所有問(wèn)題，包括真實(shí)的以及主觀認(rèn)定的，定期向開(kāi)發(fā)者報(bào)告。β測(cè)試主要衡量產(chǎn)品的FLURPS，著重于產(chǎn)品的支持性，包括文檔，客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力。 只有當(dāng)α測(cè)試達(dá)到一定的可靠程度時(shí)，才能開(kāi)始β測(cè)試。它處在整個(gè)測(cè)試的最后階段。同時(shí)，產(chǎn)品的所有手冊(cè)文本也應(yīng)該在此階段完全定稿。
10：驗(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è)試的參與者：用戶，還可能有軟測(cè)工程師等。
1 、驗(yàn)收測(cè)試的過(guò)程和主要內(nèi)容
前提: ? ? 系統(tǒng)或軟件產(chǎn)品已通過(guò)了系統(tǒng)測(cè)試的軟件系統(tǒng)。
測(cè)試內(nèi)容: ?? ?驗(yàn)證系統(tǒng)是否達(dá)到了用戶需求規(guī)格說(shuō)明書(shū)（可能包括項(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)收通過(guò)準(zhǔn)則，并經(jīng)過(guò)客戶參與的計(jì)劃評(píng)審。
建立測(cè)試環(huán)境，設(shè)計(jì)測(cè)試用例，并經(jīng)過(guò)評(píng)審。
準(zhǔn)備測(cè)試數(shù)據(jù)，執(zhí)行測(cè)試用例，記錄測(cè)試結(jié)果。
分析測(cè)試結(jié)果，根據(jù)驗(yàn)收通過(guò)準(zhǔn)則分析測(cè)試結(jié)果，作出驗(yàn)收是否通過(guò)及測(cè)試評(píng)價(jià)。 測(cè)試項(xiàng)目通過(guò)； 測(cè)試項(xiàng)目沒(méi)有通過(guò)，并且不存在變通方法，需要很大的修改； 測(cè)試項(xiàng)目沒(méi)有通過(guò)，但存在變通方法，在維護(hù)后期或下一個(gè)版本改進(jìn)； 測(cè)試項(xiàng)目無(wú)法評(píng)估或者無(wú)法給出完整的評(píng)估。此時(shí)必須給出原因。如果是因?yàn)樵摐y(cè)試項(xiàng)目沒(méi)有說(shuō)明清楚，應(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)得到修改并且通過(guò)了測(cè)試或者經(jīng)過(guò)評(píng)估留待下一版本中修改。
完成軟件驗(yàn)收測(cè)試報(bào)告。
注意事項(xiàng)：
必須編寫(xiě)正式的、單獨(dú)的驗(yàn)收測(cè)試報(bào)告
驗(yàn)收測(cè)試必須在實(shí)際用戶運(yùn)行環(huán)境中進(jìn)行 由用戶和測(cè)試部門共同執(zhí)行。
如公司自開(kāi)發(fā)產(chǎn)品，應(yīng)由測(cè)試人員，產(chǎn)品設(shè)計(jì)部門，市場(chǎng)部門等共同進(jìn)行。
11：白盒、黑盒和灰盒測(cè)試區(qū)別：
白箱測(cè)試或白盒測(cè)試(White-box?testing 或glass-box testing)是通過(guò)程序的源代碼進(jìn)行測(cè)試而不使用用戶界面。這種類型的測(cè)試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點(diǎn)或者錯(cuò)誤，進(jìn)而加以修正。
黑箱測(cè)試或黑盒測(cè)試(Black-box testing)是通過(guò)使用整個(gè)軟件或某種軟件功能來(lái)嚴(yán)格地測(cè)試, 而并沒(méi)有通過(guò)檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的。測(cè)試人員通過(guò)輸入他們的數(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è)試一樣是通過(guò)用戶界面測(cè)試，但是測(cè)試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的。甚至于還讀過(guò)部分源代碼。 因此測(cè)試人員可以有的放矢地進(jìn)行某種確定的條件/功能的測(cè)試。這樣做的意義在于:如果你知道產(chǎn)品內(nèi)部的設(shè)計(jì)和對(duì)產(chǎn)品有透過(guò)用戶界面的深入了解，你就能夠更有效和深入地從用戶界面來(lái)測(cè)試它的各項(xiàng)性能。
12：冒煙測(cè)試的目的：
為正式測(cè)試前，驗(yàn)證是否產(chǎn)品或系統(tǒng)的主要需求或預(yù)置條件是否存在bug。
13：回歸測(cè)試怎么做：
1、在測(cè)試策略制定階段，制定回歸測(cè)試策略
2、確定需要回歸測(cè)試的版本
3、回歸測(cè)試版本發(fā)布,按照回歸測(cè)試策略執(zhí)行回歸測(cè)試
4、回歸測(cè)試通過(guò)，關(guān)閉缺陷跟蹤單（問(wèn)題單）
5、回歸測(cè)試不通過(guò)，缺陷跟蹤單返回開(kāi)發(fā)人員，開(kāi)發(fā)人員重新修改問(wèn)題，再次提交測(cè)試人員回歸測(cè)試
14：全部回歸與部分回歸的區(qū)別：
15：需求分析的目的：
第一、把用戶需求轉(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è)試過(guò)程中可能遇到的風(fēng)險(xiǎn)等等。測(cè)試需求需要做到盡可能的詳細(xì)明確，以避免測(cè)試遺漏和誤解。
16：測(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）開(kāi)發(fā)有效的測(cè)試模型，能正確地驗(yàn)證正在開(kāi)發(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)所帶來(lái)的損失。
17：什么時(shí)候開(kāi)始寫(xiě)測(cè)試計(jì)劃：
測(cè)試需求分析前總體測(cè)試計(jì)劃書(shū)/測(cè)試需求分析后詳細(xì)測(cè)試計(jì)劃書(shū)
18：由誰(shuí)來(lái)編寫(xiě)測(cè)試計(jì)劃：
具有豐富經(jīng)驗(yàn)的項(xiàng)目測(cè)試負(fù)責(zé)人
19：測(cè)試計(jì)劃的內(nèi)容：
1.簡(jiǎn)介 2.參考文檔和提交文件 3.進(jìn)度安排 4.測(cè)試資源 5.嚴(yán)重程度和優(yōu)先級(jí) 6.風(fēng)險(xiǎn)分析 7.測(cè)試策略
20：結(jié)束條件(項(xiàng)目上線的條件)：
1、軟件經(jīng)過(guò)充分的測(cè)試
?? 開(kāi)發(fā)人員測(cè)試---〉交叉測(cè)試---〉測(cè)試人員測(cè)試---〉用戶的業(yè)務(wù)專家測(cè)試---〉一定數(shù)量的用戶業(yè)務(wù)專家集中測(cè)試---〉上線前試運(yùn)行----〉上線。
?? 壓力測(cè)試是必須的
2、用戶培訓(xùn) ：管理員，一定廠或地區(qū)必須有一個(gè)人經(jīng)過(guò)了培訓(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)的切換必須提前演練過(guò)，各種老數(shù)據(jù)的導(dǎo)入工作完成。
6、應(yīng)急方案必須有。
21：常見(jiàn)的測(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é)果
22：測(cè)試用例級(jí)別的劃分：
? ? ? 高，中，低
23：怎樣保證覆蓋用戶需求？
分類：一次告知類，個(gè)人喜好，不合理需求類，合理需求類拓展關(guān)鍵詞
24：寫(xiě)好測(cè)試用例的關(guān)鍵 /寫(xiě)好用例要關(guān)注的維度：
做好測(cè)試用例工作的關(guān)鍵是要充分考慮測(cè)試計(jì)劃的實(shí)用性，采用評(píng)審和更新機(jī)制，確保測(cè)試計(jì)劃滿足實(shí)際需求。因?yàn)檐浖?xiàng)目是一個(gè)漸進(jìn)的過(guò)程，中間不可避免地會(huì)發(fā)生需求變化，為滿足需求變化，測(cè)試計(jì)劃也需要及時(shí)地進(jìn)行變更。測(cè)試策略要作為測(cè)試的重點(diǎn)進(jìn)行描述。測(cè)試策略是測(cè)試計(jì)劃中的重要組成部分，測(cè)試計(jì)劃是從宏觀上說(shuō)明一個(gè)項(xiàng)目的測(cè)試需求、測(cè)試方法、測(cè)試人員安排等因素。
25：測(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é)工作表的意見(jiàn)欄記錄下阻塞的狀態(tài)。你可以把阻塞理解為：我希望運(yùn)行測(cè)試，但是目前還不能運(yùn)行測(cè)試。
你決定在當(dāng)前測(cè)試階段跳過(guò)某個(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ì)量的疑問(wèn)。一個(gè)或多個(gè)測(cè)試錯(cuò)誤需要記錄下來(lái)。
在很多情況下，測(cè)試人得到預(yù)料之外的測(cè)試結(jié)果，狀態(tài)或行為，但是這些結(jié)果與測(cè)試目標(biāo)差別不是很大另一種想法是，警告意味著當(dāng)前的錯(cuò)誤是無(wú)關(guān)緊要的，或者對(duì)正在測(cè)試的特征是沒(méi)有意義的。系統(tǒng)報(bào)出了更多的錯(cuò)。我處理這個(gè)問(wèn)題的一個(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è)試用例后，沒(méi)有錯(cuò)誤出現(xiàn)。將這類測(cè)試標(biāo)記為關(guān)閉而不是通過(guò)，使得你可以跟蹤測(cè)試在某一個(gè)測(cè)試發(fā)布中失敗的實(shí)事
26：常見(jiàn)的測(cè)試用例設(shè)計(jì)方法：
等價(jià)類劃分法，邊界值分析法，錯(cuò)誤推測(cè)法，因果圖法，正交實(shí)驗(yàn)法，場(chǎng)景法
27：判定表用在哪些時(shí)候/哪些功能：
判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況下的工具.在程序設(shè)計(jì)發(fā)展的初期，判定表：編寫(xiě)程序的輔助工具
28：什么時(shí)候用到場(chǎng)景法：
基本流和備選流，一般基本流為正常的測(cè)試，測(cè)試結(jié)果為成功的測(cè)試，備選流為異常的情況測(cè)試
29：測(cè)試環(huán)境怎么搭建的：
1，在搭建測(cè)試環(huán)境前是需要和開(kāi)發(fā)人員做個(gè)溝通交接工作的，一般他們會(huì)給到相應(yīng)的系統(tǒng)發(fā)布手冊(cè)，我們會(huì)根據(jù)這個(gè)手冊(cè)操作流程來(lái)搭建。
2，雖然在當(dāng)下，越來(lái)越多的平臺(tái)開(kāi)始使用linux操作系統(tǒng)，但也存在差異性，常見(jiàn)的linux包含redhat、centos以及ubuntu等。同樣，不同平臺(tái)使用的web服務(wù)器也不一樣，當(dāng)今主流的web服務(wù)器包括Tomcat，apache、nginx以及weblogic。而數(shù)據(jù)庫(kù)則分為MySQL和oracle.
這個(gè)要看不同軟件是采用什么類型的要素來(lái)進(jìn)行開(kāi)發(fā)的。
3，由于源碼程序是使用JAVA編寫(xiě)的，所以在事先需要向開(kāi)發(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即可。
30：偶然性問(wèn)題的處理
一、一定要提交！！
1． 記得有這么個(gè)缺陷，以后再遇到的時(shí)候可能就會(huì)了解發(fā)生的原因。
2． 盡力去查找出錯(cuò)的原因，比如有什么特別的操作，或者一些操作環(huán)境等。
3． 程序員對(duì)程序比測(cè)試人員熟悉的多，也許你提交了，即使無(wú)法重現(xiàn)，程序員也會(huì)了解問(wèn)題所在。
4． 無(wú)法重現(xiàn)的問(wèn)題再次出現(xiàn)后，可以直接叫程序員來(lái)看看問(wèn)題。
5． 記錄bug要盡量描述清楚發(fā)生問(wèn)題時(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ā)布出來(lái)的軟件到達(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è)大皮球踢給開(kāi)發(fā)人員，不僅喪失了一次提高測(cè)試水平的機(jī)會(huì)，還有可能破壞和開(kāi)發(fā)人員之間的關(guān)系。
要想復(fù)現(xiàn)不可復(fù)現(xiàn)的Bug，需要先提到一個(gè)概念就是ET（Exploring Test），也就是探索式測(cè)試，這種測(cè)試方法是由James Bach首先提出來(lái)的，在所掌握的被測(cè)對(duì)象的信息不是很充分的情況下，這是一種很有效的測(cè)試方法.當(dāng)出現(xiàn)不可復(fù)現(xiàn)的Bug時(shí)，大家可以從以下五個(gè)方面來(lái)進(jìn)行考慮：
1、被測(cè)對(duì)象的版本信息
我測(cè)試的到底是哪個(gè)版本，這主要是有兩個(gè)作用：一是確認(rèn)我測(cè)試的是正式的軟件版本，如果不是就先記錄下該問(wèn)題，然后選擇正式的版本進(jìn)行測(cè)試（開(kāi)發(fā)人員基于嘗試的一次非正規(guī)的修改可能會(huì)導(dǎo)致不可復(fù)現(xiàn)的Bug）；二是可以和其它版本進(jìn)行對(duì)比，如果其它的版本沒(méi)有類似的問(wèn)題，就可以去對(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)類似的問(wèn)題，也就是說(shuō)通過(guò)環(huán)境的改變來(lái)進(jìn)一步搜集不可復(fù)現(xiàn)Bug的相關(guān)信息。
3、模式
這里的模式是指我對(duì)這個(gè)Bug如何出現(xiàn)的一個(gè)理解，先給這個(gè)Bug設(shè)定一個(gè)模式，比如是不是<u>[<u>數(shù)據(jù)庫(kù)</u>](javascript:;)</u>通信中斷，然后再進(jìn)行測(cè)試，收集更多的信息去修改和完善這個(gè)模式，這樣不斷進(jìn)行，最終直到Bug能完全復(fù)現(xiàn)為止，這個(gè)時(shí)候只要使用這個(gè)模式就可以復(fù)現(xiàn)出Bug了。
4、人
這里提到的人有兩個(gè)含義：一是測(cè)試是由人來(lái)進(jìn)行的，人的操作、人的思維方式會(huì)有不同，通過(guò)分析這些信息也有可能找到這些不可復(fù)現(xiàn)的Bug的蛛絲馬跡；二是想復(fù)現(xiàn)不可復(fù)現(xiàn)的Bug，往往需要多<u>個(gè)人</u>之間的相互協(xié)作，比如測(cè)試人員、開(kāi)發(fā)人員等，通過(guò)大家的溝通和協(xié)作就能更容易去復(fù)現(xiàn)了。
5、測(cè)試工具
通過(guò)一些debug工具或者log工具等搜集內(nèi)存等信息，根據(jù)這些信息來(lái)進(jìn)行分析，找出不同信息之間的共同點(diǎn)，比如某一塊內(nèi)存始終都會(huì)被改寫(xiě)等，通過(guò)這種方式來(lái)去復(fù)現(xiàn)Bug。
上面的五個(gè)方面都是和ET的思想緊密相關(guān)的，通過(guò)不斷的測(cè)試和不斷的信息收集和分析，逐步的把模糊的、不確定的測(cè)試變成清晰的、確定的測(cè)試，這樣就能復(fù)現(xiàn)那些不能復(fù)現(xiàn)的Bug了?？紤]信息時(shí)可以從以上五個(gè)方面來(lái)進(jìn)行考慮。
三、實(shí)在沒(méi)辦法重現(xiàn)
問(wèn)題無(wú)法重現(xiàn)，也要提出，程序員那里可以回復(fù)無(wú)法再現(xiàn)。問(wèn)題放在那里，等到再次出現(xiàn)的時(shí)候，就立刻叫程序員過(guò)來(lái)查看。
31：當(dāng)我們認(rèn)為某個(gè)地方是bug，但開(kāi)發(fā)認(rèn)為不是bug，怎么處理？
1.找到需求文檔或者是原型圖進(jìn)行匹對(duì)
2.嘗試多種測(cè)試環(huán)境和多種測(cè)試方式來(lái)確認(rèn)是否為bug
3.整理bug的復(fù)現(xiàn)的步驟和出現(xiàn)的頻率
4.開(kāi)發(fā)堅(jiān)持不認(rèn)為是bug的時(shí)候找項(xiàng)目經(jīng)理測(cè)試經(jīng)理進(jìn)行溝通來(lái)確認(rèn)是否為bug
5.將客戶經(jīng)理 測(cè)試 測(cè)試經(jīng)理和項(xiàng)目經(jīng)理進(jìn)行開(kāi)確認(rèn)會(huì)來(lái)判定是否為bug
6.測(cè)試人員需要將bug整理并寫(xiě)入測(cè)試總結(jié)中
32：產(chǎn)品在上線后用戶發(fā)現(xiàn)bug，這時(shí)測(cè)試人員應(yīng)做哪些工作？
1.測(cè)試人員可以做的是重現(xiàn)這個(gè)問(wèn)題并及時(shí)反饋給開(kāi)發(fā)人員，找到解決方案進(jìn)行修復(fù)
2.由于疏忽造成測(cè)試用例執(zhí)行遺漏，測(cè)試人員需要在下次執(zhí)行測(cè)試的過(guò)程和下個(gè)版本上線的前要補(bǔ)全測(cè)試用例并避免這樣的情況發(fā)生，
分析bug的根本原因，考慮如何避免此類問(wèn)題再次發(fā)生
分析bug是在哪個(gè)階段引入？是設(shè)計(jì)階段、開(kāi)發(fā)階段、測(cè)試階段？
分析bug引入的原因是什么？是流程問(wèn)題、技術(shù)問(wèn)題、管理問(wèn)題？
處理問(wèn)題的流程是否合理？是否有問(wèn)題預(yù)警、是否有緊急上線規(guī)范。
出現(xiàn)問(wèn)題后，根據(jù)問(wèn)題的緊急性而決定解決方案，如有的必須的幾個(gè)小時(shí)內(nèi)解決，有的可以幾天內(nèi)解決，有的必須立刻修改錯(cuò)誤數(shù)據(jù)讓業(yè)務(wù)能繼續(xù)運(yùn)作......
你也可以談根據(jù)問(wèn)題嚴(yán)重程度而使用不同的修復(fù)、測(cè)試流程。
對(duì)于測(cè)試通過(guò)的補(bǔ)丁，也可以談安裝窗口的選擇。
其實(shí)發(fā)現(xiàn)bug后的行動(dòng)很多，不可能全部談，找?guī)讉€(gè)行動(dòng)談，讓雇主相信你真的有運(yùn)維經(jīng)驗(yàn)就行。
33：二八定理
二八定律又名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ù)，卻是次要的，因此又稱二八定律。
34：如何跟蹤缺陷
首先，圈定該系統(tǒng)的應(yīng)用范圍，是單一的項(xiàng)目，是一個(gè)部門，還是多個(gè)組。 其次，商定跟蹤模型，這是核心所在。這一步需要和項(xiàng)目成員一起討論確定一個(gè)大家都接受的模型，包括設(shè)計(jì)變更的生命周期等一系列定義。接下來(lái)要設(shè)定一些角色，比如提出者，管理者，質(zhì)量保證工程師或測(cè)試人員等。然后需要制定一個(gè)執(zhí)行計(jì)劃；再下來(lái)部署該缺陷跟蹤系統(tǒng)，一個(gè)原則是盡量少的對(duì)系統(tǒng)進(jìn)行修正；最后確保該系統(tǒng)正常運(yùn)轉(zhuǎn)，達(dá)到最初的目標(biāo)。
35：缺陷的狀態(tài)
新建，已修復(fù)，關(guān)閉，重新打開(kāi)，推遲，不能復(fù)現(xiàn)，重復(fù)，不是缺陷
36：缺陷的等級(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)模塊異常等問(wèn)題。如代碼錯(cuò)誤，死循環(huán)，數(shù)據(jù)庫(kù)發(fā)生死鎖、與數(shù)據(jù)庫(kù)連接錯(cuò)誤或數(shù)據(jù)通訊錯(cuò)誤，未考慮異常操作，功能錯(cuò)誤等
B類—嚴(yán)重錯(cuò)誤的軟件缺陷（critical）：系統(tǒng)的主要功能部分喪失、數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失。問(wèn)題局限在本模塊，導(dǎo)致模塊功能失效或異常退出。如致命的錯(cuò)誤聲明，程序接口錯(cuò)誤，數(shù)據(jù)庫(kù)的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件
C類—一般錯(cuò)誤的軟件缺陷（major）：次要功能沒(méi)有完全實(shí)現(xiàn)但不影響使用。如提示信息不太準(zhǔn)確，或用戶界面差，操作時(shí)間長(zhǎng)，模塊功能部分失效等，打印內(nèi)容、格式錯(cuò)誤，刪除操作未給出提示，數(shù)據(jù)庫(kù)表中有過(guò)多的空字段等
D類—較小錯(cuò)誤的軟件缺陷（Minor）:使操作者不方便或遇到麻煩，但它不影響功能過(guò)的操作和執(zhí)行，如錯(cuò)別字、界面不規(guī)范（字體大小不統(tǒng)一，文字排列不整齊，可輸入?yún)^(qū)域和只讀區(qū)域沒(méi)有明顯的區(qū)分標(biāo)志），輔助說(shuō)明描述不清楚
E類-?建議問(wèn)題的軟件缺陷（Enhancemental）：由問(wèn)題提出人對(duì)測(cè)試對(duì)象的改進(jìn)意見(jià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í)是指缺陷可以在開(kāi)發(fā)人員有時(shí)間的時(shí)候再被糾正。
37：缺陷單應(yīng)該包含這些要素
軟件缺bai陷報(bào)告單的意義是測(cè)試人員將發(fā)現(xiàn)du的BUG以書(shū)面的形式zhi提交給開(kāi)發(fā)人員，作為定dao位缺陷的依據(jù)（zhuan明確職責(zé)，避免口角的方法之一），也作為日后缺陷度量的數(shù)據(jù)依據(jù)。之后，開(kāi)發(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í)間
38：測(cè)試報(bào)告的主要內(nèi)容
（一）bai測(cè)試項(xiàng)目背景介紹
主要介紹這份測(cè)試報(bào)告具體的編寫(xiě)目的、測(cè)試系統(tǒng)名稱、測(cè)試環(huán)境、文中用到的專業(yè)術(shù)語(yǔ)，以及列出該份測(cè)試報(bào)告中引用的參考資料。
（二）測(cè)試計(jì)劃
列出詳細(xì)的測(cè)試計(jì)劃，通過(guò)表格標(biāo)出測(cè)試內(nèi)容，逐項(xiàng)說(shuō)明系統(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è)試過(guò)程中軟件缺陷和限制，同時(shí)說(shuō)明每項(xiàng)缺陷和限制對(duì)軟件性能的影響，并說(shuō)明全部測(cè)得的性能缺陷的累積影響和總影響，最后統(tǒng)計(jì)本次測(cè)試過(guò)程中的資源損耗情況。軟件測(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è)試工作。
39：如何定位bug：
1、發(fā)現(xiàn)bug，首先要查看bug的詳細(xì)信息，根據(jù)描述初步分析是哪個(gè)模塊哪段代碼的問(wèn)題
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)的日志記錄，可通過(guò)分析日志來(lái)確認(rèn)bug
5、當(dāng)測(cè)試人員經(jīng)過(guò)一系列的分析，可以基本確認(rèn)bug產(chǎn)生的原因后，就可以直接找開(kāi)發(fā)提bug了（注意溝通技巧）
6、如果各方面都分析完還不能確認(rèn)bug的原因，可以找開(kāi)發(fā)一起定位（注意保留bug現(xiàn)場(chǎng)或者可以復(fù)現(xiàn)bug場(chǎng)景）
7、確認(rèn)bug后，提單給開(kāi)發(fā)進(jìn)行bug跟蹤。
?問(wèn)題單上要描述清楚以下信息：?
具體的測(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，等開(kāi)發(fā)人員修復(fù)bug后進(jìn)行回歸測(cè)試。
40：開(kāi)發(fā)沒(méi)時(shí)間修復(fù)，如何推進(jìn)bug的修復(fù)：
開(kāi)發(fā)不修改bug的原因有四：bug路徑較深、上線時(shí)間緊急、改動(dòng)影響范圍大、第三方應(yīng)用問(wèn)題。我們逐條分析解決方案
1、 針對(duì)路徑較深的bug，測(cè)試在推動(dòng)開(kāi)發(fā)修復(fù)bug時(shí)，需要注意以下幾點(diǎn)
a) 從用戶的角度分析問(wèn)題的嚴(yán)重性，分析用戶的遇到此問(wèn)題的概率，引導(dǎo)開(kāi)發(fā)站在用戶角度去思考，從而使開(kāi)發(fā)意識(shí)到問(wèn)題的嚴(yán)重性
b) 可以和開(kāi)發(fā)人員列舉一個(gè)之前的類似問(wèn)題，為開(kāi)發(fā)提供參考
c) 產(chǎn)品是負(fù)責(zé)這個(gè)軟件的人員，當(dāng)測(cè)試與開(kāi)發(fā)意見(jiàn)無(wú)法達(dá)成一致時(shí)，不要因?yàn)闊o(wú)法推動(dòng)開(kāi)發(fā)修改而放棄，一定要找產(chǎn)品確認(rèn)，最終的決定權(quán)交給產(chǎn)品人員。
2、 上線時(shí)間緊張，開(kāi)發(fā)來(lái)不及修改了，這個(gè)時(shí)候測(cè)試應(yīng)該分析問(wèn)題的嚴(yán)重性，和產(chǎn)品人員商議是否需要修改
3、 修改bug改動(dòng)較大，影響范圍廣，沒(méi)有最優(yōu)的解決方案等情況在項(xiàng)目即將上線的節(jié)點(diǎn)比較忌諱這種事情的發(fā)生。面對(duì)這種情況，建議開(kāi)發(fā)人員做調(diào)研工作，請(qǐng)教其他的同事，或者組織一個(gè)臨時(shí)會(huì)議，集眾人之力研究好的修改方案
4、 第三方應(yīng)用問(wèn)題，開(kāi)發(fā)無(wú)法修改。確認(rèn)原因之后需要找相關(guān)的工作人員，例如產(chǎn)品，聯(lián)系第三方輸入法的工作人員，反饋問(wèn)題，盡量推動(dòng)應(yīng)用解決問(wèn)題
41：軟件測(cè)試流程
我們一般在項(xiàng)目進(jìn)行開(kāi)立項(xiàng)會(huì)（產(chǎn)品，項(xiàng)目，開(kāi)發(fā)，測(cè)試）的時(shí)候進(jìn)行參與，討論需求并提出建議，在立項(xiàng)會(huì)中執(zhí)行
需求文檔，由UI設(shè)計(jì)原型圖，開(kāi)發(fā)根據(jù)需求文檔進(jìn)行編碼，我們測(cè)試會(huì)根據(jù)需求文檔進(jìn)行編寫(xiě) 測(cè)試設(shè)計(jì)，根據(jù)模塊模
塊的（顆粒度） 劃分并編寫(xiě)測(cè)試用例，開(kāi)發(fā)結(jié)束后測(cè)試對(duì)主要功能進(jìn)行冒煙測(cè)試，執(zhí)行測(cè)試用例，提交bug開(kāi)發(fā)進(jìn)行
修改修改成功后關(guān)閉bug，用例執(zhí)行結(jié)束后進(jìn)行回歸測(cè)試，在上線進(jìn)行測(cè)試總結(jié)。
42；項(xiàng)目介紹
43：對(duì)一支圓珠筆進(jìn)行測(cè)試，要從哪些方面進(jìn)行測(cè)試？三角形測(cè)試用例設(shè)計(jì)
1.功能測(cè)試：圓珠筆按下是否能正常書(shū)寫(xiě)。
2.性能測(cè)試：筆芯彈出彈回的快慢。
3.負(fù)載測(cè)試：連續(xù)按，看彈簧能經(jīng)受多少次伸縮。
4.兼容性測(cè)試：看是否可以使用其他筆芯。
5.強(qiáng)度測(cè)試：用力過(guò)度會(huì)有什么影響
6.可恢復(fù)性測(cè)試：長(zhǎng)時(shí)間按住彈簧，松開(kāi)后看彈簧是否可以恢復(fù)
7.界面測(cè)試：筆的外觀，舒適度
8.安全性測(cè)試：是否會(huì)對(duì)使用者造成傷害
44：在項(xiàng)目中發(fā)現(xiàn)哪些經(jīng)典bug？什么原因?qū)е碌模?/p>
第一，出現(xiàn)這個(gè)bug,可以判斷研發(fā)在最后保存數(shù)據(jù)時(shí),并沒(méi)有對(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)生問(wèn)題.
第二，這種臟數(shù)據(jù)雖然不會(huì)在視圖展示，但保存在服務(wù)器上,在各個(gè)平臺(tái)上均會(huì)進(jìn)行同步.這還需要保證其他平臺(tái)對(duì)于臟數(shù)據(jù)進(jìn)行處理，且不會(huì)出現(xiàn)問(wèn)題.風(fēng)險(xiǎn)較大.
基于這兩個(gè)原因，研發(fā)還是解決了這個(gè)問(wèn)題.這對(duì)我還是有一定啟發(fā)的.
看問(wèn)題可能會(huì)更考慮多方面的影響.不單純只是現(xiàn)象.
45：一個(gè)項(xiàng)目完成時(shí)，有多個(gè)重要的缺陷沒(méi)有被修復(fù)，但是項(xiàng)目負(fù)責(zé)人說(shuō)可以不修改，你認(rèn)為測(cè)試是不通過(guò)的，請(qǐng)簡(jiǎn)述你的理由。
46：在需求文檔不太詳細(xì)的情況下，如何開(kāi)展測(cè)試？
軟件生命周期中，需求是整個(gè)項(xiàng)目的源頭。俗話說(shuō)良好的開(kāi)端是成功的一半，但是，不是每個(gè)項(xiàng)目都能遵從流程，花太多時(shí)間在需求分析上，而把精力投入到代碼的編寫(xiě)中。這可能導(dǎo)致什么問(wèn)題呢？開(kāi)發(fā)和測(cè)試對(duì)需求理解都不充分，開(kāi)發(fā)出來(lái)的功能與實(shí)際需求不符，測(cè)試要么憑自己的經(jīng)驗(yàn)一步一步發(fā)掘潛藏的功能點(diǎn)，把項(xiàng)目往良性的軌道上引，要么就聽(tīng)從開(kāi)發(fā)的腳步，亦步亦趨。那么測(cè)試人員要如何在需求不明確或者文檔不全的情況下著手測(cè)試才能保證軟件的質(zhì)量呢？
一、參考同類型的網(wǎng)站：一般情況下，我們測(cè)的系統(tǒng)總會(huì)有原型可參考，比如我目前測(cè)的訂票系統(tǒng)，就可以參照攜程，主要功能基本一樣，細(xì)節(jié)可能有出入，攜程上操作一遍，然后再看看它提供的幫助，再有可以網(wǎng)上搜索資料，參考下行業(yè)的基礎(chǔ)知識(shí)，這都是收集需求的方法，這樣子下來(lái)也基本對(duì)訂票系統(tǒng)也就有個(gè)認(rèn)識(shí)了，然后與開(kāi)發(fā)經(jīng)理確認(rèn)，再和開(kāi)發(fā)一起把功能定下來(lái)，該改的改，該修的修，BUG一點(diǎn)不含糊。弱弱的吐槽下，這個(gè)項(xiàng)目的開(kāi)發(fā)居然都不知道有需求說(shuō)明書(shū)，雖然寫(xiě)的基本沒(méi)太大的價(jià)值。
二、根據(jù)經(jīng)驗(yàn)和常識(shí)判斷：做項(xiàng)目多了就知道，萬(wàn)變不離其宗，系統(tǒng)不一樣，思路可以套用，所謂的學(xué)以致用，舉一反三。我上個(gè)項(xiàng)目做的銀行測(cè)試，我照樣可以測(cè)現(xiàn)在的訂票系統(tǒng)，就在一個(gè)字：活。有需求照需求測(cè)，沒(méi)有需求找參照，說(shuō)個(gè)例子吧，訂票系統(tǒng)中有個(gè)功能是積分，需求上就一句話提到有積分功能，怎么測(cè)？難道看到有這個(gè)功能就算過(guò)了？我后來(lái)就參照了淘寶的積分抵扣，下單了積分就被臨時(shí)凍結(jié)了，取消訂單又釋放出來(lái)，但開(kāi)發(fā)在做這個(gè)功能的時(shí)候也沒(méi)有跟他們的頭溝通，直接是要等支付完成后才扣除積分，這導(dǎo)致一個(gè)什么問(wèn)題呢，可以重復(fù)使用積分，如果真上線使用了，說(shuō)不定會(huì)造成不小的經(jīng)濟(jì)損失的。類似這樣的問(wèn)題太多太多，你總可以從一些地方獲得參照，或者說(shuō)是靈感，項(xiàng)目測(cè)的怎么樣，跟測(cè)試人員的素養(yǎng)有很大的關(guān)系，尤其是在沒(méi)有規(guī)范的流程下。
三、溝通：毋庸置疑，這太重要了，需求不一定在文檔中寫(xiě)出來(lái)，但道理上開(kāi)發(fā)肯定知道需求的，但一般不會(huì)主動(dòng)和測(cè)試溝通，因此，我們作為測(cè)試就要主動(dòng)和開(kāi)發(fā)人員溝通，不僅可以對(duì)系統(tǒng)有更深的了解，還可以對(duì)項(xiàng)目進(jìn)度有把握。
四、多和同事討論
47：如何盡快找到軟件中的bug?
盡快熟悉公司的產(chǎn)品業(yè)務(wù)
根據(jù)產(chǎn)品的業(yè)務(wù)屬性來(lái)熟悉產(chǎn)品的業(yè)務(wù)流程，這樣才能迅速找出軟件中存在的一些重要的缺陷，這樣發(fā)現(xiàn)的軟件的價(jià)值才是有價(jià)值的，否則即使你能找到一些軟件缺陷，那也是純軟件的缺陷，價(jià)值不大。
把自己當(dāng)成是用戶
把自己當(dāng)成用戶去使用該軟件，比如在試用軟件的過(guò)程中，思考用戶是這樣操作的么；
2.1 比如大量要求用戶輸入的軟件界面中，有一些用戶喜歡使用Tab鍵采用全鍵盤的輸入，此時(shí)正確的接口應(yīng)該是從左到右，從上到下的順序。
2.2 比如有的用戶喜歡使用快捷鍵進(jìn)行操作（Ctrl+C），但是實(shí)際情況下一些開(kāi)發(fā)出來(lái)的軟件的快捷鍵根本不起作用。
2.3 比如軟件在需要用戶輸入信息的時(shí)候（特別是在填寫(xiě)個(gè)人資料的時(shí)候），必填選項(xiàng)后面一律要用*等醒目的表示要讓知道這個(gè)地方必須要填寫(xiě)。
2.4 下拉框不選的時(shí)候，應(yīng)該有個(gè)默認(rèn)值，并且要多檢查程序中的多處下拉框，因?yàn)楹芏嗲闆r下下拉框取不到值。
善于懷疑
世界上沒(méi)有絕對(duì)正確的，總有錯(cuò)誤的地方，具有叛逆心理，別人認(rèn)為不可能發(fā)生的事，我卻認(rèn)為可能發(fā)生；別人認(rèn)為是對(duì)的，我卻認(rèn)為是錯(cuò)的。假如一個(gè)水平很高的程序員編寫(xiě)的程序，不要有“他寫(xiě)的這個(gè)程序應(yīng)該沒(méi)有問(wèn)題吧”這種想法，這樣很容以遺漏軟件中的Bug。
不用讓程序開(kāi)發(fā)員“用戶不會(huì)這樣操作”的觀點(diǎn)說(shuō)服自己
遇到這樣的情況，你要堅(jiān)持自己的正確的觀點(diǎn)，把這種現(xiàn)象作為一個(gè)Bug。
在測(cè)試的過(guò)程中要跟蹤一條數(shù)據(jù)的完整流程。
比如“點(diǎn)擊商品—收藏商品—加入購(gòu)物車—訂單結(jié)算—付款—消費(fèi)二維碼—消費(fèi)—二維碼失效”，如果在測(cè)試軟件過(guò)程中業(yè)務(wù)流程邏輯都走不通的話，還么這個(gè)軟件測(cè)試與不測(cè)試就沒(méi)有什么區(qū)別的。
回歸測(cè)試要注意的事項(xiàng)
程序員提交新的版本后，作為測(cè)試人員應(yīng)該立即與程序員溝通這個(gè)修改的功能，并了解這個(gè)新修改的功能影響那些功能。而被影響的功能，是在回歸測(cè)試中優(yōu)先重點(diǎn)測(cè)試的地方，而且也是最容易產(chǎn)生Bug的地方。
與使用者互動(dòng)的缺陷
7.1 如填寫(xiě)資料錯(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)行檢查，比如吧“登錄”寫(xiě)成“登陸”；
7.5 在軟件中不要對(duì)用戶使用很專業(yè)的術(shù)語(yǔ)；
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è)置開(kāi)始時(shí)間>結(jié)束時(shí)間，看看能否查詢出記錄；
軟件的邊界值
眾所周知軟件最容易在邊界值上出現(xiàn)問(wèn)題，所以作為測(cè)試人員一定要在邊界值上多測(cè)試，比如測(cè)試用戶輸入框中的數(shù)值的最大數(shù)和最小數(shù)，以及為空的情況；
非法容錯(cuò)性
比如在需要輸入數(shù)字的地方輸入字母，在需要輸入字母的地方輸入數(shù)字，在需要用戶輸入的文本框中拷貝字?jǐn)?shù)很多的整編文章到這里測(cè)試看看軟件是如何做處理的；
軟件接口測(cè)試
如果軟件不同部部分是由不同程序員共同完成的，那么要在他們程序接口相關(guān)聯(lián)的地方多檢查，避免雙方程序員互相認(rèn)為做了接口處理，最后誰(shuí)也沒(méi)有做接口的處理，導(dǎo)致軟件在運(yùn)行中產(chǎn)生缺陷；
兼容性測(cè)試
軟件測(cè)試要在不同的硬件、軟件下（包括操作系統(tǒng)、瀏覽器）下的測(cè)試；
11.1 硬件 有時(shí)候軟件在配置很高的機(jī)器上，有時(shí)會(huì)隱瞞一些錯(cuò)誤，由于CPU運(yùn)行過(guò)快的時(shí)候，很多現(xiàn)象一閃而過(guò)，發(fā)現(xiàn)不了缺陷；
11.2 軟件 有時(shí)軟件在不同版本的瀏覽器中的界面與權(quán)限是不一樣的，這樣的例子就是軟件中的一個(gè)Bug了；
軟件在壓力之下容易出錯(cuò)
軟件在壓力之下容易產(chǎn)生的錯(cuò)誤，是作為一名測(cè)試人員必須要知道的事情。所以在測(cè)試過(guò)程中，將軟件在壓力之下長(zhǎng)時(shí)間運(yùn)行，然后看看軟件是否能在壓力之下正常工作；
隨機(jī)測(cè)試：
即使經(jīng)過(guò)大量的充分測(cè)試，也不能發(fā)現(xiàn)軟件中的所有缺陷，所以在測(cè)試的時(shí)候可以做一些隨機(jī)測(cè)試，比如胡亂在界面上亂點(diǎn)，有時(shí)也會(huì)發(fā)現(xiàn)一些意想不到的軟件缺陷；
學(xué)習(xí)他人經(jīng)驗(yàn)：
48：什么是bug？
1.產(chǎn)品說(shuō)明書(shū)中規(guī)定要做的事情，而軟件沒(méi)有實(shí)現(xiàn)。
2.產(chǎn)品說(shuō)明書(shū)中規(guī)定不要做的事情，而軟件確實(shí)現(xiàn)了。
3.產(chǎn)品說(shuō)明書(shū)中沒(méi)有提到過(guò)的事情，而軟件確實(shí)現(xiàn)了。
4.產(chǎn)品說(shuō)明書(shū)中沒(méi)有提到但是必須要做的事情，軟件確沒(méi)有實(shí)現(xiàn)。
軟件很難理解，很難使用，速度超慢，測(cè)試人員站在最終用戶的角度看到的問(wèn)題是平常的但不是正確的。
注：產(chǎn)品說(shuō)明書(shū)中沒(méi)有提到但是必須要做的事情，軟件確沒(méi)有實(shí)現(xiàn)。軟件實(shí)現(xiàn)了產(chǎn)品的功能，但是沒(méi)有考慮軟件在弱網(wǎng)絡(luò)、低電量的情況下也能正常使用，而做出來(lái)的產(chǎn)品在弱網(wǎng)絡(luò)或低電量的情況下報(bào)錯(cuò)，那么這也是一個(gè)bug。
49：ATM機(jī)吞卡的吞卡現(xiàn)象是不是BUG?
這個(gè)不能絕對(duì)的說(shuō)BUG.應(yīng)為比如說(shuō)輸入三次錯(cuò)誤的密碼，需求上就是需要吞卡。那這個(gè)就是正常的，不是BUG。那如果說(shuō)一直沒(méi)有考慮到的操作，導(dǎo)致了吞卡，那這個(gè)就可以定位成BUG
50：如何減少非問(wèn)題單的提交？
51：有個(gè)程序，在windows上運(yùn)行很慢，怎么判斷是程序存在問(wèn)題，還是軟硬件系統(tǒng)存在問(wèn)題？
1、檢查系統(tǒng)是否有中度的特征，如：瀏覽器窗口連續(xù)打開(kāi)，系統(tǒng)中文件圖標(biāo)改成統(tǒng)一圖標(biāo)，CPU使用率保存90%以上等
2、檢查軟件/硬件的配置是否符合軟件的推薦標(biāo)準(zhǔn)
3、確認(rèn)當(dāng)前的系統(tǒng)是否是獨(dú)立，即沒(méi)有對(duì)外提供什么消耗CPU資源的服務(wù)，如：虛擬機(jī)運(yùn)行
4、如果是C/S或者B/S結(jié)構(gòu)的軟件，需要檢查是不是因?yàn)榕c服務(wù)器的連接有問(wèn)題，或者訪問(wèn)有問(wèn)題造成的；
5、在系統(tǒng)沒(méi)有任何負(fù)載的情況下，查看性能監(jiān)視器，確認(rèn)應(yīng)用程序?qū)PU/內(nèi)存的訪問(wèn)情況。
方法一：ctrl+ait+del 找性能 看看你的CPU占用率還有內(nèi)存的使用率！
方法二：查看系統(tǒng)日志，查看任務(wù)管理器-程序負(fù)載都是那些
52：你們發(fā)現(xiàn)bug會(huì)怎么處理
發(fā)現(xiàn)BUG后，接下來(lái)你提交到BUG管理平臺(tái)，提交一個(gè)BUG包含哪些內(nèi)容？
BUG標(biāo)題—標(biāo)題要清晰簡(jiǎn)潔，寫(xiě)明BUG描述；如果沒(méi)有選擇功能模塊，最好在標(biāo)題中標(biāo)注功能模塊。讓查看BUG的人員清楚知道你所表達(dá)的意思。BUG的功能模塊+BUG的操作+BUG的結(jié)果
重現(xiàn)步驟—步驟—簡(jiǎn)單寫(xiě)下發(fā)現(xiàn)BUG的測(cè)試過(guò)程，羅列下。能指導(dǎo)開(kāi)發(fā)重現(xiàn)這個(gè)BUG。附上測(cè)試數(shù)據(jù)實(shí)際結(jié)果----出項(xiàng)BUG的結(jié)果，粘貼BUG截圖，日志截圖，截圖直接粘貼就可以了，不要添加附件，附件：日志、測(cè)試數(shù)據(jù)（文件）圖片，比如上傳頭像，就把圖片放在文件中當(dāng)附件上傳，開(kāi)發(fā)要重現(xiàn)這個(gè)BUG，那么根據(jù)你附件的圖片來(lái)重現(xiàn)。預(yù)期結(jié)果----記得寫(xiě)清楚預(yù)期
BUG類型和嚴(yán)重程度-----便于后續(xù)測(cè)試結(jié)果分析，BUG的統(tǒng)計(jì)
BUG測(cè)試環(huán)境---例如：什么系統(tǒng)；哪個(gè)版本等。兼容性問(wèn)題、難以重現(xiàn)問(wèn)題
附件----日志文件、文件測(cè)試數(shù)據(jù)
所有以上的如何提交BUG，參考公司前輩寫(xiě)的BUG，依葫蘆畫(huà)瓢，拓展測(cè)試思維。
測(cè)試的BUG備注修改方案和操作信息
如果寫(xiě)了兩條一摸一樣的BUG或者提交的BUG不是BUG而是操作錯(cuò)誤，問(wèn)同事怎么刪除，或者是在BUG標(biāo)題前面?zhèn)渥ⅰ靶鑴h除”，然后跟老大說(shuō)，老大會(huì)批量刪除?；蛘卟粍h除自己編輯下其他BUG.
BUG的跟蹤管理-狀態(tài)處理
1.已經(jīng)指派的BUG---已經(jīng)指派給開(kāi)發(fā)的，請(qǐng)大家注意自己BUG的走向，隨時(shí)關(guān)注并進(jìn)行跟蹤！如果一直未修復(fù)，提醒開(kāi)發(fā)修改，以免開(kāi)發(fā)忘記；如果已經(jīng)修復(fù)等待測(cè)試環(huán)境更新后進(jìn)行驗(yàn)證。催著改BUG
2.已解決的BUG----等待測(cè)試環(huán)境更新后進(jìn)行驗(yàn)證，驗(yàn)證通過(guò)則關(guān)閉；驗(yàn)證不通過(guò)則重新開(kāi)發(fā)指派給開(kāi)發(fā)
3.重復(fù)BUG----先去查看下是否跟開(kāi)發(fā)指定的BUG重復(fù)？如果確定時(shí)重復(fù)則關(guān)閉；如果不重復(fù)，說(shuō)明原因，重新打開(kāi)指派給開(kāi)發(fā)。
4.不是缺陷----確認(rèn)開(kāi)發(fā)環(huán)境是否分測(cè)試環(huán)境一致，如果如開(kāi)發(fā)所說(shuō)不是缺陷則進(jìn)行關(guān)閉；如果確認(rèn)是缺陷跟開(kāi)發(fā)溝通，溝通未達(dá)一致找產(chǎn)品/反饋老大確認(rèn)，確認(rèn)是BUG注明情況并在次指派給開(kāi)發(fā)。
5.無(wú)法重現(xiàn)----確認(rèn)開(kāi)發(fā)環(huán)境是否跟測(cè)試環(huán)境一致？包括操作步驟，瀏覽器、環(huán)境、特定賬號(hào)等，如果多個(gè)版本驗(yàn)證之后，如開(kāi)發(fā)所說(shuō)重現(xiàn)不了，依據(jù)BUG的嚴(yán)重程度跟產(chǎn)品，開(kāi)發(fā)一起確認(rèn)關(guān)閉；如果找到重現(xiàn)原因，注明清楚并再次指派給開(kāi)發(fā)。
6.不予解決---找產(chǎn)品經(jīng)理進(jìn)行確認(rèn)。確認(rèn)不予解決進(jìn)行關(guān)閉；確認(rèn)需要解決請(qǐng)備注原因并打開(kāi)指派給開(kāi)發(fā)
7.設(shè)計(jì)如此---找產(chǎn)品經(jīng)理進(jìn)行確認(rèn)。確認(rèn)設(shè)計(jì)如此進(jìn)行關(guān)閉；確認(rèn)是問(wèn)題，備注原因重現(xiàn)指派給開(kāi)發(fā)。
8.延期修改---請(qǐng)看下BUG嚴(yán)重程度，是否影響當(dāng)前版本發(fā)布？與產(chǎn)品經(jīng)理進(jìn)行確認(rèn)。不予延期請(qǐng)根據(jù)情況進(jìn)行激活與情況說(shuō)明；確定延期則做好記錄，后續(xù)版本進(jìn)行關(guān)注。
53.三角形測(cè)試用例設(shè)計(jì)：
1、 當(dāng)三邊不可能構(gòu)成三角形時(shí)提示錯(cuò)誤，可構(gòu)成三角形時(shí)計(jì)算三角形周長(zhǎng)。
2、若是等腰三角形打印“等腰三角形”，若兩個(gè)等腰的平方和等于第三邊平方和，則打印“等腰直角三角形”。
3、若是等邊三角形，則打?。骸暗冗吶切巍薄?/p>
4、畫(huà)出程序流程圖并設(shè)計(jì)一個(gè)測(cè)試用例。
1、構(gòu)成三角形的條件：任意兩邊之和大于第三邊；
2、構(gòu)成等腰三角形的條件：任意兩邊相等；
3、構(gòu)成等腰直角三角形的條件：任意兩邊相等，而且兩條邊的平方和等于第三邊的平方和；
4、構(gòu)成等邊三角形的條件：三條邊都相等。
