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ò)請求的時(shí)候，我們基本上使用http協(xié)議呜叫。
http協(xié)議包括請求和響應(yīng) ：
? ? 請求中包含：請求地址郑什，請求方式，請求方式包括get和post請求惰聂，get和post的區(qū)別是get請求在地址欄后邊跟隨請求參數(shù)，但是請求參數(shù)大小有限制咱筛，不同瀏覽器是不同的搓幌。一般是4KB。post請求主要用于向服務(wù)器提交請求參數(shù)迅箩。post請求參數(shù)是放到請求實(shí)體中的溉愁，相對get請求更為安全些。
? ?響應(yīng)包括：200（）饲趋，404（）拐揭，500（），304（）奕塑，307（）
? ?還有各種響應(yīng)頭信息堂污，比如設(shè)置緩存的響應(yīng)頭，Content-Type內(nèi)容類型龄砰，設(shè)置cookie頭信息
3：POST與GET區(qū)別：
get請求沒有請求體盟猖，通過url攜帶數(shù)據(jù)讨衣，大小有限制，不安全
post請求通過請求體傳輸數(shù)據(jù)式镐，大小沒有限制反镇，比get安全
4：Cookie和Session的區(qū)別與聯(lián)系：
cookie數(shù)據(jù)放在客戶端瀏覽器上，session數(shù)據(jù)存在服務(wù)器上
cookie不是很安全娘汞，別人可以分析存在本地的cookin并進(jìn)行欺騙歹茶，考慮到安全應(yīng)當(dāng)使用session
session會在一定時(shí)間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多會比較占用你的服務(wù)器的性能你弦，考慮減輕服務(wù)器性能方面惊豺，應(yīng)當(dāng)使用cookin
單個(gè)cookin保存的數(shù)據(jù)不能超過4K很多瀏覽器限制一個(gè)站點(diǎn)最多保存20個(gè)cookin
5：測試的目的：
軟件測試的目的是為了保證軟件產(chǎn)品的最終質(zhì)量，在軟件開發(fā)的過程中禽作，對軟件產(chǎn)品進(jìn)行質(zhì)量控制一般來說軟件測試應(yīng)由獨(dú)立的產(chǎn)品評測中心負(fù)責(zé)扮叨，嚴(yán)格按照軟件測試流程，制定測試計(jì)劃领迈、測試方案彻磁、測試規(guī)范，實(shí)施測試狸捅，對測試記錄進(jìn)行分析衷蜓，并根據(jù)回歸測試情況撰寫測試報(bào)告。測試是為了證明程序有錯(cuò)尘喝，而不能保證程序沒有錯(cuò)誤磁浇。
6：軟件測試原則：
1.測試證明軟件存在缺陷：無論執(zhí)行什么樣的測試操作都能證明軟件是有缺陷的
2.不能執(zhí)行窮盡測試：有些功能是沒有辦法將所有的測試情況都邏輯出來丽啡，所以任何的測試操作都有結(jié)束時(shí)間
3.缺陷存在群集現(xiàn)象：對于軟件功能來說努溃，核心功能占20%是鬼，非核心占80%学赛。在實(shí)際工作中我們會集中測試20%的核心功能，所以這個(gè)部分發(fā)現(xiàn)缺陷的幾率就會高于80%缩功。因此我們就回遇到缺陷都集中在20%功能模塊里的現(xiàn)象
4.某些測試需要依賴特殊的環(huán)境
5.測試應(yīng)盡早介入：為了更多的發(fā)現(xiàn)和更好的解決軟件中缺陷韭山。我們追求測試工作盡早開展
6.殺蟲劑現(xiàn)象：同樣的一個(gè)測試用例不能重的執(zhí)行多次功蜓，因此軟件會對他產(chǎn)生免疫
7.不存在缺陷謬論：任何軟件不可能是完美的
7：軟件測試分為哪幾個(gè)階段：
單元測試：按模塊劃分后的顆粒度進(jìn)行分類測試
集成測試：功能模塊的測試
系統(tǒng)測試：多個(gè)模塊合成測試
驗(yàn)收測試：客戶以及產(chǎn)品經(jīng)理進(jìn)行
單元測試與集成測試的側(cè)重點(diǎn)
單元測試：比如說對Java中的類和方法的測試嗤堰，一般由軟件開發(fā)人員實(shí)施（盡可能保證測試用例相對獨(dú)立戴质，測試過程中不要調(diào)用其他類的方法，而是在測試用例中重寫模擬方法）
集成測試：（測試各個(gè)單元模塊的接口）在單元測試的基礎(chǔ)上踢匣，把軟件單元按照概要規(guī)格說明書要求告匠，組裝模塊，測試看是否模塊達(dá)到了規(guī)格技術(shù)指標(biāo)离唬。
系統(tǒng)測試：（黑盒測試）在經(jīng)過集成測試的單元模塊后专，按照整體需求規(guī)格說明書，進(jìn)行一套有效嚴(yán)格的測試输莺，保證軟件的正常運(yùn)行戚哎。（集成測試偏重于技術(shù)角度裸诽，系統(tǒng)測試偏重于業(yè)務(wù)角度）
回歸測試：（回歸測試在測試生命周期中是很重要的一部分，會進(jìn)行多次回歸測試）建瘫，是指在發(fā)生修改之后崭捍，再重新回去測試一下尸折，避免修改的內(nèi)容導(dǎo)致了其他的錯(cuò)誤啰脚。驗(yàn)證之前出現(xiàn)過但已修復(fù)好的缺陷不再重新出現(xiàn)。
冒煙測試：（是自由測試的一種）是指開發(fā)者功能完成后的完整性功能測試实夹，發(fā)現(xiàn)問題后反饋給開發(fā)者進(jìn)行修改橄浓，然后看這次修改是否真的修復(fù)解決了這bug，或者對其他模塊造成了影響亮航，這個(gè)時(shí)候就需要冒煙測試來進(jìn)行驗(yàn)證荸实，缺點(diǎn)就是覆蓋率低。
驗(yàn)收測試：也叫交付測試缴淋，是針對用戶需求准给、業(yè)務(wù)流程進(jìn)行的整體測試，確認(rèn)是否滿足驗(yàn)收標(biāo)準(zhǔn)重抖，由用戶露氮、客戶看是否接受系統(tǒng)，可以部署上線钟沛。
Alpha測試：用戶在開發(fā)者的場所進(jìn)行測試畔规，是一個(gè)可控的環(huán)境中測試的。
Beta測試：是用戶在對軟件產(chǎn)品進(jìn)行測試恨统，開發(fā)者不在現(xiàn)場叁扫，用戶對測試過程中遇到的bug進(jìn)行記錄，開發(fā)并對它進(jìn)行修改畜埋，再測試莫绣，直到用戶覺得可以了，就部署上線悠鞍。
8：單元測試與集成測試的側(cè)重點(diǎn)：
單元測試
? ? ? ?是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動(dòng)兔综，在單元測試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試狞玛，測試重點(diǎn)是系統(tǒng)的模塊软驰，包括子程序的正確性驗(yàn)證等。?
集成測試
? ? ? ? 也叫組裝測試或聯(lián)合測試心肪。在單元測試的基礎(chǔ)上锭亏，將所有模塊按照設(shè)計(jì)要求，組裝成為子系統(tǒng)或系統(tǒng)硬鞍，進(jìn)行集成測試慧瘤。實(shí)踐表明戴已，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常的工作锅减。程序在某些局部反映不出來的問題糖儡，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)怔匣。測試重點(diǎn)是模塊間的銜接以及參數(shù)的傳遞等握联。
9：a測試與?測試的區(qū)別：
α測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶對即將面市軟件產(chǎn)品（稱為α版本）進(jìn)行測試，試圖發(fā)現(xiàn)錯(cuò)誤并修正每瞒。α測試的關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的 用戶操作方式金闽。經(jīng)過α測試調(diào)整的軟件產(chǎn)品稱為β版本。
β測試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測試剿骨，這些用戶返回有關(guān)錯(cuò)誤信息給開發(fā)者代芜。測試時(shí)，開發(fā)者通常不在測試現(xiàn)場浓利。因而挤庇，β測試是在開發(fā)者無法控制的環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。在β測試中贷掖，由用戶記下遇到的所有問題嫡秕，包括真實(shí)的以及主觀認(rèn)定的，定期向開發(fā)者報(bào)告羽资。β測試主要衡量產(chǎn)品的FLURPS淘菩，著重于產(chǎn)品的支持性，包括文檔屠升，客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力潮改。 只有當(dāng)α測試達(dá)到一定的可靠程度時(shí)，才能開始β測試腹暖。它處在整個(gè)測試的最后階段汇在。同時(shí)，產(chǎn)品的所有手冊文本也應(yīng)該在此階段完全定稿脏答。
10：驗(yàn)收測試怎么做：
驗(yàn)收測試(Acceptance Test)：在軟件產(chǎn)品完成了功能測試和系統(tǒng)測試之后糕殉、產(chǎn)品發(fā)布之前所進(jìn)行的軟件測試活動(dòng)。它是技術(shù)測試的最后一個(gè)階段殖告，也稱為交付測試阿蝶。
驗(yàn)收測試的目的：確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)黄绩。
驗(yàn)收測試的參與者：用戶羡洁，還可能有軟測工程師等。
1 爽丹、驗(yàn)收測試的過程和主要內(nèi)容
前提: ? ? 系統(tǒng)或軟件產(chǎn)品已通過了系統(tǒng)測試的軟件系統(tǒng)筑煮。
測試內(nèi)容: ?? ?驗(yàn)證系統(tǒng)是否達(dá)到了用戶需求規(guī)格說明書（可能包括項(xiàng)目或產(chǎn)品驗(yàn)收準(zhǔn)則）中的要求辛蚊，測試試圖盡可能地發(fā)現(xiàn)軟件中存留的缺陷，從而為軟件進(jìn)一步改善提供幫助真仲，并保證系統(tǒng)或軟件產(chǎn)品最終被用戶接受袋马。主要包括易用性測試、兼容性測試秸应、安裝測試虑凛、文檔（如用戶手冊、操作手冊等）測試等幾個(gè)方面的內(nèi)容灸眼。
任務(wù)：驗(yàn)證軟件的功能和性能符合用戶期待卧檐。
測試步驟：
制定測試計(jì)劃墓懂，測試項(xiàng)焰宣，測試策略及驗(yàn)收通過準(zhǔn)則，并經(jīng)過客戶參與的計(jì)劃評審捕仔。
建立測試環(huán)境匕积，設(shè)計(jì)測試用例，并經(jīng)過評審榜跌。
準(zhǔn)備測試數(shù)據(jù)闪唆，執(zhí)行測試用例，記錄測試結(jié)果钓葫。
分析測試結(jié)果悄蕾，根據(jù)驗(yàn)收通過準(zhǔn)則分析測試結(jié)果，作出驗(yàn)收是否通過及測試評價(jià)础浮。 測試項(xiàng)目通過帆调； 測試項(xiàng)目沒有通過，并且不存在變通方法豆同，需要很大的修改番刊； 測試項(xiàng)目沒有通過，但存在變通方法影锈，在維護(hù)后期或下一個(gè)版本改進(jìn)芹务； 測試項(xiàng)目無法評估或者無法給出完整的評估。此時(shí)必須給出原因鸭廷。如果是因?yàn)樵摐y試項(xiàng)目沒有說明清楚枣抱，應(yīng)該修改測試計(jì)劃。
提交測試報(bào)告辆床。
驗(yàn)收標(biāo)準(zhǔn)和注意事項(xiàng)：
驗(yàn)收測試完成標(biāo)準(zhǔn): 完全執(zhí)行了驗(yàn)收測試計(jì)劃中的每個(gè)測試用例佳晶。
在驗(yàn)收測試中發(fā)現(xiàn)的錯(cuò)誤已經(jīng)得到修改并且通過了測試或者經(jīng)過評估留待下一版本中修改。
完成軟件驗(yàn)收測試報(bào)告佛吓。
注意事項(xiàng)：
必須編寫正式的宵晚、單獨(dú)的驗(yàn)收測試報(bào)告
驗(yàn)收測試必須在實(shí)際用戶運(yùn)行環(huán)境中進(jìn)行 由用戶和測試部門共同執(zhí)行垂攘。
如公司自開發(fā)產(chǎn)品，應(yīng)由測試人員淤刃，產(chǎn)品設(shè)計(jì)部門晒他，市場部門等共同進(jìn)行。
11：白盒逸贾、黑盒和灰盒測試區(qū)別：
白箱測試或白盒測試(White-box?testing 或glass-box testing)是通過程序的源代碼進(jìn)行測試而不使用用戶界面陨仅。這種類型的測試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出铝侵，路徑灼伤，條件等等中的缺點(diǎn)或者錯(cuò)誤，進(jìn)而加以修正咪鲜。
黑箱測試或黑盒測試(Black-box testing)是通過使用整個(gè)軟件或某種軟件功能來嚴(yán)格地測試, 而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的狐赡。測試人員通過輸入他們的數(shù)據(jù)然后看輸出的結(jié)果從而了解軟件怎樣工作。通常測試人員在進(jìn)行測試時(shí)不僅使用肯定出正確結(jié)果的輸入數(shù)據(jù)疟丙，而且還會使用有挑戰(zhàn)性的輸入數(shù)據(jù)以及可能結(jié)果會出錯(cuò)的輸入數(shù)據(jù)以便了解軟件怎樣處理各種類型的數(shù)據(jù)颖侄。
灰箱測試或灰盒測試(Gray-box testing):灰箱測試就像黑箱測試一樣是通過用戶界面測試，但是測試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設(shè)計(jì)的享郊。甚至于還讀過部分源代碼览祖。 因此測試人員可以有的放矢地進(jìn)行某種確定的條件/功能的測試。這樣做的意義在于:如果你知道產(chǎn)品內(nèi)部的設(shè)計(jì)和對產(chǎn)品有透過用戶界面的深入了解炊琉，你就能夠更有效和深入地從用戶界面來測試它的各項(xiàng)性能展蒂。
12：冒煙測試的目的：
為正式測試前，驗(yàn)證是否產(chǎn)品或系統(tǒng)的主要需求或預(yù)置條件是否存在bug苔咪。
13：回歸測試怎么做：
1锰悼、在測試策略制定階段，制定回歸測試策略
2悼泌、確定需要回歸測試的版本
3松捉、回歸測試版本發(fā)布,按照回歸測試策略執(zhí)行回歸測試
4、回歸測試通過馆里，關(guān)閉缺陷跟蹤單（問題單）
5隘世、回歸測試不通過，缺陷跟蹤單返回開發(fā)人員鸠踪，開發(fā)人員重新修改問題丙者，再次提交測試人員回歸測試
14：全部回歸與部分回歸的區(qū)別：
15：需求分析的目的：
第一、把用戶需求轉(zhuǎn)化為功能需求：1）對測試范圍進(jìn)度量??? 2）對處理分支進(jìn)行度量?? 3）對需求業(yè)務(wù)的場景進(jìn)行度量?? 4）明確其功能對應(yīng)的輸入营密、處理和輸出?? 5）把隱式需求轉(zhuǎn)變?yōu)槊鞔_械媒。
第二、明確測試活動(dòng)的五個(gè)要素：測試需求是什么、決定怎么測試纷捞、明確測試時(shí)間痢虹、確定測試人員、確定測試環(huán)境：測試中需要的技能主儡，工具以及相應(yīng)的背景知識奖唯，測試過程中可能遇到的風(fēng)險(xiǎn)等等。測試需求需要做到盡可能的詳細(xì)明確糜值，以避免測試遺漏和誤解丰捷。
16：測試計(jì)劃的目的：
（1）為測試各項(xiàng)活動(dòng)制定一個(gè)現(xiàn)實(shí)可行的、綜合的計(jì)劃寂汇，包括每項(xiàng)測試活動(dòng)的對象病往、范圍、方法骄瓣、進(jìn)度和預(yù)期結(jié)果停巷。
（2）為項(xiàng)目實(shí)施建立一個(gè)組織模型，并定義測試項(xiàng)目中每個(gè)角色的責(zé)任和工作內(nèi)容累贤。
（3）開發(fā)有效的測試模型叠穆，能正確地驗(yàn)證正在開發(fā)的軟件系統(tǒng)少漆。
（4）確定測試所需要的時(shí)間和資源臼膏，以保證其可獲得性、有效性示损。
（5）確立每個(gè)測試階段測試完成以及測試成功的標(biāo)準(zhǔn)渗磅、要實(shí)現(xiàn)的目標(biāo)。
（6）識別出測試活動(dòng)中各種風(fēng)險(xiǎn)检访，并消除可能存在的風(fēng)險(xiǎn)始鱼，降低由不可能消除的風(fēng)險(xiǎn)所帶來的損失。
17：什么時(shí)候開始寫測試計(jì)劃：
測試需求分析前總體測試計(jì)劃書/測試需求分析后詳細(xì)測試計(jì)劃書
18：由誰來編寫測試計(jì)劃：
具有豐富經(jīng)驗(yàn)的項(xiàng)目測試負(fù)責(zé)人
19：測試計(jì)劃的內(nèi)容：
1.簡介 2.參考文檔和提交文件 3.進(jìn)度安排 4.測試資源 5.嚴(yán)重程度和優(yōu)先級 6.風(fēng)險(xiǎn)分析 7.測試策略
20：結(jié)束條件(項(xiàng)目上線的條件)：
1脆贵、軟件經(jīng)過充分的測試
?? 開發(fā)人員測試---〉交叉測試---〉測試人員測試---〉用戶的業(yè)務(wù)專家測試---〉一定數(shù)量的用戶業(yè)務(wù)專家集中測試---〉上線前試運(yùn)行----〉上線医清。
?? 壓力測試是必須的
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)急方案必須有躯枢。
21：常見的測試風(fēng)險(xiǎn)：
需求風(fēng)險(xiǎn)，測試用例風(fēng)險(xiǎn)，缺陷風(fēng)險(xiǎn)忧饭，代碼質(zhì)量風(fēng)險(xiǎn)狼牺，測試環(huán)境風(fēng)險(xiǎn)，測試技術(shù)風(fēng)險(xiǎn)
回歸測試風(fēng)險(xiǎn)败匹，溝通協(xié)調(diào)風(fēng)險(xiǎn)，研發(fā)流程風(fēng)險(xiǎn)讥巡，其他不可預(yù)計(jì)風(fēng)險(xiǎn)
測試用例的要素：
用例編號 用例描述?? 執(zhí)行條件? 預(yù)期結(jié)果 測試輸入? 實(shí)際結(jié)果
22：測試用例級別的劃分：
? ? ? 高掀亩，中，低
23：怎樣保證覆蓋用戶需求欢顷？
分類：一次告知類槽棍，個(gè)人喜好，不合理需求類抬驴，合理需求類拓展關(guān)鍵詞
24：寫好測試用例的關(guān)鍵 /寫好用例要關(guān)注的維度：
做好測試用例工作的關(guān)鍵是要充分考慮測試計(jì)劃的實(shí)用性炼七，采用評審和更新機(jī)制，確保測試計(jì)劃滿足實(shí)際需求布持。因?yàn)檐浖?xiàng)目是一個(gè)漸進(jìn)的過程豌拙，中間不可避免地會發(fā)生需求變化，為滿足需求變化题暖，測試計(jì)劃也需要及時(shí)地進(jìn)行變更按傅。測試策略要作為測試的重點(diǎn)進(jìn)行描述。測試策略是測試計(jì)劃中的重要組成部分胧卤，測試計(jì)劃是從宏觀上說明一個(gè)項(xiàng)目的測試需求唯绍、測試方法、測試人員安排等因素枝誊。
25：測試用例的狀態(tài)：
排隊(duì)（In Queue）：
測試用例已經(jīng)指定給某個(gè)測試人况芒，不準(zhǔn)備在這一個(gè)測試階段運(yùn)行。
該測試正在進(jìn)行叶撒，并且會持續(xù)一段時(shí)間绝骚。
一些因素會導(dǎo)致測試不能進(jìn)行到底，例如某個(gè)功能欠缺或者測試環(huán)境的某個(gè)部分欠缺痊乾。我通常會在測試用例總結(jié)工作表的意見欄記錄下阻塞的狀態(tài)皮壁。你可以把阻塞理解為：我希望運(yùn)行測試，但是目前還不能運(yùn)行測試哪审。
你決定在當(dāng)前測試階段跳過某個(gè)測試蛾魄，可能是因?yàn)樗膬?yōu)先權(quán)相對較低。
測試運(yùn)行結(jié)束，測試人得到了預(yù)料中的測試結(jié)果狀態(tài)和測試行為滴须。
在很多情況下，測試人得到預(yù)料之外的測試結(jié)果扔水，狀態(tài)或行為痛侍，這些結(jié)果與測試目標(biāo)相差甚遠(yuǎn)。這就引發(fā)了關(guān)于系統(tǒng)質(zhì)量的疑問魔市。一個(gè)或多個(gè)測試錯(cuò)誤需要記錄下來主届。
在很多情況下，測試人得到預(yù)料之外的測試結(jié)果待德，狀態(tài)或行為君丁，但是這些結(jié)果與測試目標(biāo)差別不是很大另一種想法是，警告意味著當(dāng)前的錯(cuò)誤是無關(guān)緊要的将宪，或者對正在測試的特征是沒有意義的绘闷。系統(tǒng)報(bào)出了更多的錯(cuò)。我處理這個(gè)問題的一個(gè)標(biāo)準(zhǔn)是只和延期的或不是一定要改的錯(cuò)誤相關(guān)的測試可以標(biāo)記為警告较坛，而不是失敗印蔗。
一個(gè)測試在第一個(gè)循環(huán)中被標(biāo)為失敗或警告，第二個(gè)測試發(fā)布中將第一個(gè)測試循環(huán)出現(xiàn)的錯(cuò)誤修改了丑勤。重新運(yùn)行了整個(gè)測試用例后华嘹，沒有錯(cuò)誤出現(xiàn)。將這類測試標(biāo)記為關(guān)閉而不是通過确封，使得你可以跟蹤測試在某一個(gè)測試發(fā)布中失敗的實(shí)事
26：常見的測試用例設(shè)計(jì)方法：
等價(jià)類劃分法除呵，邊界值分析法，錯(cuò)誤推測法爪喘，因果圖法，正交實(shí)驗(yàn)法纠拔，場景法
27：判定表用在哪些時(shí)候/哪些功能：
判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況下的工具.在程序設(shè)計(jì)發(fā)展的初期秉剑，判定表：編寫程序的輔助工具
28：什么時(shí)候用到場景法：
基本流和備選流，一般基本流為正常的測試稠诲，測試結(jié)果為成功的測試侦鹏，備選流為異常的情況測試
29：測試環(huán)境怎么搭建的：
1，在搭建測試環(huán)境前是需要和開發(fā)人員做個(gè)溝通交接工作的臀叙，一般他們會給到相應(yīng)的系統(tǒng)發(fā)布手冊略水，我們會根據(jù)這個(gè)手冊操作流程來搭建。
2劝萤，雖然在當(dāng)下渊涝，越來越多的平臺開始使用linux操作系統(tǒng)，但也存在差異性，常見的linux包含redhat跨释、centos以及ubuntu等胸私。同樣，不同平臺使用的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即可资铡。
30：偶然性問題的處理
一电禀、一定要提交！笤休！
1． 記得有這么個(gè)缺陷尖飞，以后再遇到的時(shí)候可能就會了解發(fā)生的原因。
2． 盡力去查找出錯(cuò)的原因店雅，比如有什么特別的操作政基，或者一些操作環(huán)境等。
3． 程序員對程序比測試人員熟悉的多闹啦，也許你提交了沮明，即使無法重現(xiàn)，程序員也會了解問題所在荐健。
4． 無法重現(xiàn)的問題再次出現(xiàn)后扛稽，可以直接叫程序員來看看問題帮匾。
5． 記錄bug要盡量描述清楚發(fā)生問題時(shí)的測試步驟螺句、測試環(huán)境芽唇、測試數(shù)據(jù)。
二炮捧、盡量重現(xiàn)bug
對于整個(gè)項(xiàng)目或者產(chǎn)品而言，如果這些不可復(fù)現(xiàn)的Bug是很嚴(yán)重的Bug撩幽，比如導(dǎo)致系統(tǒng)崩潰等，如果不能及時(shí)拜英、準(zhǔn)確的定位和解決，最終發(fā)布出來的軟件到達(dá)用戶手中后，一旦出現(xiàn)勢必會影響軟件在用戶心中的形象，嚴(yán)重的會“迫使”用戶選擇競爭對手的產(chǎn)品弄兜，這些顯然都是公司所不愿看到的语泽。而對于測試人員而言，出現(xiàn)了這些不可復(fù)現(xiàn)的Bug盛垦，實(shí)際上是一次很好的鍛煉和提高機(jī)會湿弦，如果只是提交缺陷報(bào)告將這個(gè)大皮球踢給開發(fā)人員，不僅喪失了一次提高測試水平的機(jī)會腾夯，還有可能破壞和開發(fā)人員之間的關(guān)系颊埃。
要想復(fù)現(xiàn)不可復(fù)現(xiàn)的Bug，需要先提到一個(gè)概念就是ET（Exploring Test）蝶俱，也就是探索式測試班利，這種測試方法是由James Bach首先提出來的，在所掌握的被測對象的信息不是很充分的情況下榨呆，這是一種很有效的測試方法.當(dāng)出現(xiàn)不可復(fù)現(xiàn)的Bug時(shí)罗标，大家可以從以下五個(gè)方面來進(jìn)行考慮：
1、被測對象的版本信息
我測試的到底是哪個(gè)版本积蜻，這主要是有兩個(gè)作用：一是確認(rèn)我測試的是正式的軟件版本闯割，如果不是就先記錄下該問題，然后選擇正式的版本進(jìn)行測試（開發(fā)人員基于嘗試的一次非正規(guī)的修改可能會導(dǎo)致不可復(fù)現(xiàn)的Bug）竿拆；二是可以和其它版本進(jìn)行對比宙拉，如果其它的版本沒有類似的問題，就可以去對比這兩個(gè)版本之間的區(qū)別丙笋。
2谢澈、環(huán)境
這里的環(huán)境是指出現(xiàn)不可復(fù)現(xiàn)的Bug時(shí)所對應(yīng)的測試環(huán)境等煌贴，比如測試所用的計(jì)算機(jī)，如果出現(xiàn)不可復(fù)現(xiàn)的Bug锥忿，那我換一臺機(jī)器是不是還會出現(xiàn)類似的問題牛郑，也就是說通過環(huán)境的改變來進(jìn)一步搜集不可復(fù)現(xiàn)Bug的相關(guān)信息。
3敬鬓、模式
這里的模式是指我對這個(gè)Bug如何出現(xiàn)的一個(gè)理解淹朋，先給這個(gè)Bug設(shè)定一個(gè)模式，比如是不是<u>[<u>數(shù)據(jù)庫</u>](javascript:;)</u>通信中斷列林，然后再進(jìn)行測試瑞你，收集更多的信息去修改和完善這個(gè)模式，這樣不斷進(jìn)行希痴，最終直到Bug能完全復(fù)現(xiàn)為止者甲，這個(gè)時(shí)候只要使用這個(gè)模式就可以復(fù)現(xiàn)出Bug了。
4砌创、人
這里提到的人有兩個(gè)含義：一是測試是由人來進(jìn)行的虏缸，人的操作、人的思維方式會有不同嫩实，通過分析這些信息也有可能找到這些不可復(fù)現(xiàn)的Bug的蛛絲馬跡刽辙；二是想復(fù)現(xiàn)不可復(fù)現(xiàn)的Bug，往往需要多<u>個(gè)人</u>之間的相互協(xié)作甲献，比如測試人員宰缤、開發(fā)人員等，通過大家的溝通和協(xié)作就能更容易去復(fù)現(xiàn)了晃洒。
5慨灭、測試工具
通過一些debug工具或者log工具等搜集內(nèi)存等信息，根據(jù)這些信息來進(jìn)行分析球及，找出不同信息之間的共同點(diǎn)氧骤，比如某一塊內(nèi)存始終都會被改寫等，通過這種方式來去復(fù)現(xiàn)Bug吃引。
上面的五個(gè)方面都是和ET的思想緊密相關(guān)的筹陵，通過不斷的測試和不斷的信息收集和分析，逐步的把模糊的镊尺、不確定的測試變成清晰的朦佩、確定的測試，這樣就能復(fù)現(xiàn)那些不能復(fù)現(xiàn)的Bug了庐氮÷来郑考慮信息時(shí)可以從以上五個(gè)方面來進(jìn)行考慮。
三旭愧、實(shí)在沒辦法重現(xiàn)
問題無法重現(xiàn)颅筋，也要提出，程序員那里可以回復(fù)無法再現(xiàn)输枯。問題放在那里议泵，等到再次出現(xiàn)的時(shí)候，就立刻叫程序員過來查看桃熄。
31：當(dāng)我們認(rèn)為某個(gè)地方是bug先口，但開發(fā)認(rèn)為不是bug，怎么處理瞳收？
1.找到需求文檔或者是原型圖進(jìn)行匹對
2.嘗試多種測試環(huán)境和多種測試方式來確認(rèn)是否為bug
3.整理bug的復(fù)現(xiàn)的步驟和出現(xiàn)的頻率
4.開發(fā)堅(jiān)持不認(rèn)為是bug的時(shí)候找項(xiàng)目經(jīng)理測試經(jīng)理進(jìn)行溝通來確認(rèn)是否為bug
5.將客戶經(jīng)理 測試 測試經(jīng)理和項(xiàng)目經(jīng)理進(jìn)行開確認(rèn)會來判定是否為bug
6.測試人員需要將bug整理并寫入測試總結(jié)中
32：產(chǎn)品在上線后用戶發(fā)現(xiàn)bug碉京，這時(shí)測試人員應(yīng)做哪些工作？
1.測試人員可以做的是重現(xiàn)這個(gè)問題并及時(shí)反饋給開發(fā)人員螟深，找到解決方案進(jìn)行修復(fù)
2.由于疏忽造成測試用例執(zhí)行遺漏谐宙，測試人員需要在下次執(zhí)行測試的過程和下個(gè)版本上線的前要補(bǔ)全測試用例并避免這樣的情況發(fā)生，
分析bug的根本原因界弧，考慮如何避免此類問題再次發(fā)生
分析bug是在哪個(gè)階段引入凡蜻？是設(shè)計(jì)階段、開發(fā)階段垢箕、測試階段划栓？
分析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ù)头遭、測試流程。
對于測試通過的補(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)用于社會學(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ì)變更的生命周期等一系列定義。接下來要設(shè)定一些角色烟具，比如提出者梢什，管理者，質(zhì)量保證工程師或測試人員等朝聋。然后需要制定一個(gè)執(zhí)行計(jì)劃嗡午；再下來部署該缺陷跟蹤系統(tǒng)，一個(gè)原則是盡量少的對系統(tǒng)進(jìn)行修正冀痕；最后確保該系統(tǒng)正常運(yùn)轉(zhuǎn)荔睹，達(dá)到最初的目標(biāo)。
35：缺陷的狀態(tài)
新建言蛇，已修復(fù)僻他，關(guān)閉，重新打開腊尚，推遲吨拗，不能復(fù)現(xiàn)，重復(fù)，不是缺陷
36：缺陷的等級
系統(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）：由問題提出人對測試對象的改進(jìn)意見或測試人員提出的建議、質(zhì)疑食零。
常用的軟件缺陷的優(yōu)先級表示方法可分為：立即解決P1困乒、高優(yōu)先級P2、正常排隊(duì)P3贰谣、低優(yōu)先級P4娜搂。立即解決是指缺陷導(dǎo)致系統(tǒng)幾乎不能使用或者測試不能繼續(xù)，需立即修復(fù)吱抚；高優(yōu)先級是指缺陷嚴(yán)重影響測試百宇，需要優(yōu)先考慮；正常排隊(duì)是指缺陷需要正常排隊(duì)等待修復(fù)秘豹；而低優(yōu)先級是指缺陷可以在開發(fā)人員有時(shí)間的時(shí)候再被糾正携御。
37：缺陷單應(yīng)該包含這些要素
軟件缺bai陷報(bào)告單的意義是測試人員將發(fā)現(xiàn)du的BUG以書面的形式zhi提交給開發(fā)人員，作為定dao位缺陷的依據(jù)（zhuan明確職責(zé)既绕，避免口角的方法之一）啄刹，也作為日后缺陷度量的數(shù)據(jù)依據(jù)。之后凄贩，開發(fā)人員會依據(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：測試報(bào)告的主要內(nèi)容
（一）bai測試項(xiàng)目背景介紹
主要介紹這份測試報(bào)告具體的編寫目的怎炊、測試系統(tǒng)名稱谭企、測試環(huán)境、文中用到的專業(yè)術(shù)語评肆，以及列出該份測試報(bào)告中引用的參考資料债查。
（二）測試計(jì)劃
列出詳細(xì)的測試計(jì)劃，通過表格標(biāo)出測試內(nèi)容瓜挽，逐項(xiàng)說明系統(tǒng)功能盹廷、系統(tǒng)輸出等質(zhì)量指標(biāo)，以及測試進(jìn)度等久橙；
（三）測試結(jié)果及發(fā)現(xiàn)
逐項(xiàng)分析本項(xiàng)測試中實(shí)際得到的動(dòng)態(tài)輸出（包括內(nèi)部生成數(shù)據(jù)輸出）結(jié)果同對于動(dòng)態(tài)輸出的要求進(jìn)行比較俄占，陳述其中的各項(xiàng)發(fā)現(xiàn)。
（四）測試分析摘要
記錄測試過程中軟件缺陷和限制淆衷，同時(shí)說明每項(xiàng)缺陷和限制對軟件性能的影響缸榄，并說明全部測得的性能缺陷的累積影響和總影響，最后統(tǒng)計(jì)本次測試過程中的資源損耗情況祝拯。軟件測試報(bào)告也可以找測試機(jī)構(gòu)做甚带，需要第三方軟件測試報(bào)告可以咨詢卓碼軟件測評她肯，獨(dú)立的第三方測試機(jī)構(gòu)，擁有完善的測試環(huán)境和先進(jìn)的測試技術(shù)鹰贵，幫助企業(yè)做好軟件測試工作晴氨。
39：如何定位bug：
1、發(fā)現(xiàn)bug碉输，首先要查看bug的詳細(xì)信息籽前，根據(jù)描述初步分析是哪個(gè)模塊哪段代碼的問題
2、檢查引發(fā)bug的測試環(huán)境敷钾、測試代碼段和測試數(shù)據(jù)枝哄，排除測試人員的誤操作導(dǎo)致的程序異常
3、確認(rèn)測試代碼闰非、測試環(huán)境和數(shù)據(jù)都正確后膘格，再進(jìn)一步分析bug根源。這里就需要看具體的測試業(yè)務(wù)了财松，可借助相關(guān)的工具進(jìn)行分析，比如firebug插件等
4纱控、如果產(chǎn)品或業(yè)務(wù)有相關(guān)的日志記錄辆毡，可通過分析日志來確認(rèn)bug
5、當(dāng)測試人員經(jīng)過一系列的分析甜害，可以基本確認(rèn)bug產(chǎn)生的原因后舶掖，就可以直接找開發(fā)提bug了（注意溝通技巧）
6、如果各方面都分析完還不能確認(rèn)bug的原因尔店，可以找開發(fā)一起定位（注意保留bug現(xiàn)場或者可以復(fù)現(xiàn)bug場景）
7眨攘、確認(rèn)bug后，提單給開發(fā)進(jìn)行bug跟蹤嚣州。
?問題單上要描述清楚以下信息：?
具體的測試時(shí)間鲫售、測試環(huán)境、測試場景该肴、測試的具體業(yè)務(wù)和功能情竹、使用的測試代碼和測試數(shù)據(jù)、測試執(zhí)行步驟匀哄、測試結(jié)果秦效、bug現(xiàn)象（最好截圖）、日志記錄涎嚼、預(yù)期結(jié)果阱州、bug確認(rèn)相關(guān)人員等
8、跟蹤bug法梯，等開發(fā)人員修復(fù)bug后進(jìn)行回歸測試苔货。
40：開發(fā)沒時(shí)間修復(fù)，如何推進(jìn)bug的修復(fù)：
開發(fā)不修改bug的原因有四：bug路徑較深、上線時(shí)間緊急蒲赂、改動(dòng)影響范圍大阱冶、第三方應(yīng)用問題。我們逐條分析解決方案
1滥嘴、 針對路徑較深的bug木蹬，測試在推動(dòng)開發(fā)修復(fù)bug時(shí)，需要注意以下幾點(diǎn)
a) 從用戶的角度分析問題的嚴(yán)重性若皱，分析用戶的遇到此問題的概率镊叁，引導(dǎo)開發(fā)站在用戶角度去思考，從而使開發(fā)意識到問題的嚴(yán)重性
b) 可以和開發(fā)人員列舉一個(gè)之前的類似問題走触，為開發(fā)提供參考
c) 產(chǎn)品是負(fù)責(zé)這個(gè)軟件的人員晦譬，當(dāng)測試與開發(fā)意見無法達(dá)成一致時(shí)，不要因?yàn)闊o法推動(dòng)開發(fā)修改而放棄互广，一定要找產(chǎn)品確認(rèn)敛腌，最終的決定權(quán)交給產(chǎn)品人員。
2惫皱、 上線時(shí)間緊張像樊，開發(fā)來不及修改了，這個(gè)時(shí)候測試應(yīng)該分析問題的嚴(yán)重性旅敷，和產(chǎn)品人員商議是否需要修改
3生棍、 修改bug改動(dòng)較大，影響范圍廣媳谁，沒有最優(yōu)的解決方案等情況在項(xiàng)目即將上線的節(jié)點(diǎn)比較忌諱這種事情的發(fā)生涂滴。面對這種情況，建議開發(fā)人員做調(diào)研工作晴音，請教其他的同事柔纵，或者組織一個(gè)臨時(shí)會議，集眾人之力研究好的修改方案
4段多、 第三方應(yīng)用問題首量，開發(fā)無法修改。確認(rèn)原因之后需要找相關(guān)的工作人員进苍，例如產(chǎn)品加缘，聯(lián)系第三方輸入法的工作人員，反饋問題觉啊，盡量推動(dòng)應(yīng)用解決問題
41：軟件測試流程
我們一般在項(xiàng)目進(jìn)行開立項(xiàng)會（產(chǎn)品拣宏，項(xiàng)目，開發(fā)杠人，測試）的時(shí)候進(jìn)行參與勋乾，討論需求并提出建議宋下，在立項(xiàng)會中執(zhí)行
需求文檔，由UI設(shè)計(jì)原型圖辑莫，開發(fā)根據(jù)需求文檔進(jìn)行編碼学歧，我們測試會根據(jù)需求文檔進(jìn)行編寫 測試設(shè)計(jì)，根據(jù)模塊模
塊的（顆粒度） 劃分并編寫測試用例各吨，開發(fā)結(jié)束后測試對主要功能進(jìn)行冒煙測試枝笨，執(zhí)行測試用例，提交bug開發(fā)進(jìn)行
修改修改成功后關(guān)閉bug揭蜒，用例執(zhí)行結(jié)束后進(jìn)行回歸測試横浑，在上線進(jìn)行測試總結(jié)。
42屉更；項(xiàng)目介紹
43：對一支圓珠筆進(jìn)行測試徙融，要從哪些方面進(jìn)行測試？三角形測試用例設(shè)計(jì)
1.功能測試：圓珠筆按下是否能正常書寫瑰谜。
2.性能測試：筆芯彈出彈回的快慢欺冀。
3.負(fù)載測試：連續(xù)按，看彈簧能經(jīng)受多少次伸縮萨脑。
4.兼容性測試：看是否可以使用其他筆芯脚猾。
5.強(qiáng)度測試：用力過度會有什么影響
6.可恢復(fù)性測試：長時(shí)間按住彈簧，松開后看彈簧是否可以恢復(fù)
7.界面測試：筆的外觀砚哗，舒適度
8.安全性測試：是否會對使用者造成傷害
44：在項(xiàng)目中發(fā)現(xiàn)哪些經(jīng)典bug？什么原因?qū)е碌模?/p>
第一砰奕，出現(xiàn)這個(gè)bug,可以判斷研發(fā)在最后保存數(shù)據(jù)時(shí),并沒有對數(shù)據(jù)的有效性進(jìn)行判斷,而是在相關(guān)控件進(jìn)行操作時(shí)進(jìn)行判斷的.這樣風(fēng)險(xiǎn)有點(diǎn)大,因?yàn)榭丶g對數(shù)據(jù)也會有影響,如果僅在操作控件時(shí)判斷蛛芥，會產(chǎn)生問題.
第二，這種臟數(shù)據(jù)雖然不會在視圖展示军援，但保存在服務(wù)器上,在各個(gè)平臺上均會進(jìn)行同步.這還需要保證其他平臺對于臟數(shù)據(jù)進(jìn)行處理仅淑，且不會出現(xiàn)問題.風(fēng)險(xiǎn)較大.
基于這兩個(gè)原因，研發(fā)還是解決了這個(gè)問題.這對我還是有一定啟發(fā)的.
看問題可能會更考慮多方面的影響.不單純只是現(xiàn)象.
45：一個(gè)項(xiàng)目完成時(shí)胸哥，有多個(gè)重要的缺陷沒有被修復(fù)涯竟，但是項(xiàng)目負(fù)責(zé)人說可以不修改，你認(rèn)為測試是不通過的空厌，請簡述你的理由庐船。
46：在需求文檔不太詳細(xì)的情況下，如何開展測試嘲更？
軟件生命周期中筐钟，需求是整個(gè)項(xiàng)目的源頭。俗話說良好的開端是成功的一半赋朦，但是篓冲，不是每個(gè)項(xiàng)目都能遵從流程李破，花太多時(shí)間在需求分析上，而把精力投入到代碼的編寫中壹将。這可能導(dǎo)致什么問題呢嗤攻？開發(fā)和測試對需求理解都不充分，開發(fā)出來的功能與實(shí)際需求不符诽俯，測試要么憑自己的經(jīng)驗(yàn)一步一步發(fā)掘潛藏的功能點(diǎn)妇菱，把項(xiàng)目往良性的軌道上引，要么就聽從開發(fā)的腳步惊畏，亦步亦趨恶耽。那么測試人員要如何在需求不明確或者文檔不全的情況下著手測試才能保證軟件的質(zhì)量呢？
一颜启、參考同類型的網(wǎng)站：一般情況下偷俭，我們測的系統(tǒng)總會有原型可參考，比如我目前測的訂票系統(tǒng)缰盏，就可以參照攜程涌萤，主要功能基本一樣，細(xì)節(jié)可能有出入口猜，攜程上操作一遍负溪，然后再看看它提供的幫助，再有可以網(wǎng)上搜索資料济炎，參考下行業(yè)的基礎(chǔ)知識川抡，這都是收集需求的方法，這樣子下來也基本對訂票系統(tǒng)也就有個(gè)認(rèn)識了须尚，然后與開發(fā)經(jīng)理確認(rèn)崖堤，再和開發(fā)一起把功能定下來，該改的改耐床，該修的修密幔，BUG一點(diǎn)不含糊。弱弱的吐槽下撩轰，這個(gè)項(xiàng)目的開發(fā)居然都不知道有需求說明書胯甩，雖然寫的基本沒太大的價(jià)值。
二堪嫂、根據(jù)經(jīng)驗(yàn)和常識判斷：做項(xiàng)目多了就知道偎箫，萬變不離其宗，系統(tǒng)不一樣溉苛，思路可以套用镜廉，所謂的學(xué)以致用，舉一反三愚战。我上個(gè)項(xiàng)目做的銀行測試娇唯，我照樣可以測現(xiàn)在的訂票系統(tǒng)齐遵，就在一個(gè)字：活胀瞪。有需求照需求測庶灿，沒有需求找參照，說個(gè)例子吧几缭，訂票系統(tǒng)中有個(gè)功能是積分想许，需求上就一句話提到有積分功能伶授，怎么測？難道看到有這個(gè)功能就算過了流纹？我后來就參照了淘寶的積分抵扣糜烹，下單了積分就被臨時(shí)凍結(jié)了，取消訂單又釋放出來漱凝，但開發(fā)在做這個(gè)功能的時(shí)候也沒有跟他們的頭溝通疮蹦，直接是要等支付完成后才扣除積分，這導(dǎo)致一個(gè)什么問題呢茸炒，可以重復(fù)使用積分愕乎，如果真上線使用了，說不定會造成不小的經(jīng)濟(jì)損失的壁公。類似這樣的問題太多太多感论，你總可以從一些地方獲得參照，或者說是靈感紊册，項(xiàng)目測的怎么樣比肄，跟測試人員的素養(yǎng)有很大的關(guān)系，尤其是在沒有規(guī)范的流程下囊陡。
三薪前、溝通：毋庸置疑，這太重要了关斜，需求不一定在文檔中寫出來，但道理上開發(fā)肯定知道需求的铺浇，但一般不會主動(dòng)和測試溝通痢畜，因此，我們作為測試就要主動(dòng)和開發(fā)人員溝通鳍侣，不僅可以對系統(tǒng)有更深的了解丁稀，還可以對項(xiàng)目進(jìn)度有把握。
四倚聚、多和同事討論
47：如何盡快找到軟件中的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下下拉框取不到值。
善于懷疑
世界上沒有絕對正確的仑荐，總有錯(cuò)誤的地方雕拼，具有叛逆心理，別人認(rèn)為不可能發(fā)生的事粘招，我卻認(rèn)為可能發(fā)生啥寇；別人認(rèn)為是對的，我卻認(rèn)為是錯(cuò)的洒扎。假如一個(gè)水平很高的程序員編寫的程序辑甜，不要有“他寫的這個(gè)程序應(yīng)該沒有問題吧”這種想法，這樣很容以遺漏軟件中的Bug袍冷。
不用讓程序開發(fā)員“用戶不會這樣操作”的觀點(diǎn)說服自己
遇到這樣的情況磷醋，你要堅(jiān)持自己的正確的觀點(diǎn)，把這種現(xiàn)象作為一個(gè)Bug胡诗。
在測試的過程中要跟蹤一條數(shù)據(jù)的完整流程邓线。
比如“點(diǎn)擊商品—收藏商品—加入購物車—訂單結(jié)算—付款—消費(fèi)二維碼—消費(fèi)—二維碼失效”，如果在測試軟件過程中業(yè)務(wù)流程邏輯都走不通的話煌恢，還么這個(gè)軟件測試與不測試就沒有什么區(qū)別的骇陈。
回歸測試要注意的事項(xiàng)
程序員提交新的版本后，作為測試人員應(yīng)該立即與程序員溝通這個(gè)修改的功能瑰抵，并了解這個(gè)新修改的功能影響那些功能你雌。而被影響的功能，是在回歸測試中優(yōu)先重點(diǎn)測試的地方二汛，而且也是最容易產(chǎn)生Bug的地方婿崭。
與使用者互動(dòng)的缺陷
7.1 如填寫資料錯(cuò)誤的時(shí)候拨拓，應(yīng)該能夠提示錯(cuò)誤的位置，讓用戶知道這個(gè)地方輸入的數(shù)據(jù)不對逛球；
7.2 刪除數(shù)據(jù)前一定要給定出是否刪除的確認(rèn)提示千元；
7.3 不要在軟件中使用中英文混合的提示：比如對于用戶在進(jìn)行某個(gè)操作的錯(cuò)誤提示，不要一會用“Error”颤绕，一會又用“錯(cuò)誤”幸海，一定要統(tǒng)一；
7.4 要對程序員的錯(cuò)別字進(jìn)行檢查奥务，比如吧“登錄”寫成“登陸”物独；
7.5 在軟件中不要對用戶使用很專業(yè)的術(shù)語；
7.6 新增/修改信息白村提交后系統(tǒng)給出“保存/提交/修改成功”的提示信息氯葬，并自動(dòng)更新顯示挡篓；
7.7 在用戶進(jìn)行大量的輸入后，點(diǎn)擊保存按鈕帚称，僅僅是因?yàn)槟硞€(gè)地方輸入選擇不正確官研，點(diǎn)擊確定后所有的輸入信息都被清空了，這樣的Bug會大大降低軟件的易用性闯睹；
7.8 對于軟件的查詢功能戏羽，測試的時(shí)候設(shè)置開始時(shí)間>結(jié)束時(shí)間，看看能否查詢出記錄楼吃；
軟件的邊界值
眾所周知軟件最容易在邊界值上出現(xiàn)問題始花，所以作為測試人員一定要在邊界值上多測試，比如測試用戶輸入框中的數(shù)值的最大數(shù)和最小數(shù)孩锡，以及為空的情況酷宵；
非法容錯(cuò)性
比如在需要輸入數(shù)字的地方輸入字母，在需要輸入字母的地方輸入數(shù)字躬窜，在需要用戶輸入的文本框中拷貝字?jǐn)?shù)很多的整編文章到這里測試看看軟件是如何做處理的浇垦；
軟件接口測試
如果軟件不同部部分是由不同程序員共同完成的，那么要在他們程序接口相關(guān)聯(lián)的地方多檢查荣挨，避免雙方程序員互相認(rèn)為做了接口處理溜族，最后誰也沒有做接口的處理，導(dǎo)致軟件在運(yùn)行中產(chǎn)生缺陷垦沉；
兼容性測試
軟件測試要在不同的硬件、軟件下（包括操作系統(tǒng)仍劈、瀏覽器）下的測試厕倍；
11.1 硬件 有時(shí)候軟件在配置很高的機(jī)器上，有時(shí)會隱瞞一些錯(cuò)誤贩疙，由于CPU運(yùn)行過快的時(shí)候讹弯，很多現(xiàn)象一閃而過况既，發(fā)現(xiàn)不了缺陷；
11.2 軟件 有時(shí)軟件在不同版本的瀏覽器中的界面與權(quán)限是不一樣的组民，這樣的例子就是軟件中的一個(gè)Bug了棒仍；
軟件在壓力之下容易出錯(cuò)
軟件在壓力之下容易產(chǎn)生的錯(cuò)誤，是作為一名測試人員必須要知道的事情臭胜。所以在測試過程中莫其，將軟件在壓力之下長時(shí)間運(yùn)行，然后看看軟件是否能在壓力之下正常工作耸三；
隨機(jī)測試：
即使經(jīng)過大量的充分測試乱陡，也不能發(fā)現(xiàn)軟件中的所有缺陷，所以在測試的時(shí)候可以做一些隨機(jī)測試仪壮，比如胡亂在界面上亂點(diǎn)憨颠，有時(shí)也會發(fā)現(xiàn)一些意想不到的軟件缺陷；
學(xué)習(xí)他人經(jīng)驗(yàn)：
48：什么是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)。
軟件很難理解蝶缀，很難使用丹喻，速度超慢，測試人員站在最終用戶的角度看到的問題是平常的但不是正確的翁都。
注：產(chǎn)品說明書中沒有提到但是必須要做的事情碍论，軟件確沒有實(shí)現(xiàn)。軟件實(shí)現(xiàn)了產(chǎn)品的功能柄慰，但是沒有考慮軟件在弱網(wǎng)絡(luò)鳍悠、低電量的情況下也能正常使用，而做出來的產(chǎn)品在弱網(wǎng)絡(luò)或低電量的情況下報(bào)錯(cuò)坐搔，那么這也是一個(gè)bug藏研。
49：ATM機(jī)吞卡的吞卡現(xiàn)象是不是BUG?
這個(gè)不能絕對的說BUG.應(yīng)為比如說輸入三次錯(cuò)誤的密碼，需求上就是需要吞卡概行。那這個(gè)就是正常的蠢挡，不是BUG。那如果說一直沒有考慮到的操作，導(dǎo)致了吞卡业踏，那這個(gè)就可以定位成BUG
50：如何減少非問題單的提交禽炬？
51：有個(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ú)立巫俺，即沒有對外提供什么消耗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)存的訪問情況叹卷。
方法一：ctrl+ait+del 找性能 看看你的CPU占用率還有內(nèi)存的使用率撼港！
方法二：查看系統(tǒng)日志，查看任務(wù)管理器-程序負(fù)載都是那些
52：你們發(fā)現(xiàn)bug會怎么處理
發(fā)現(xiàn)BUG后骤竹，接下來你提交到BUG管理平臺帝牡，提交一個(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的測試過程，羅列下个扰。能指導(dǎo)開發(fā)重現(xiàn)這個(gè)BUG瓷炮。附上測試數(shù)據(jù)實(shí)際結(jié)果----出項(xiàng)BUG的結(jié)果，粘貼BUG截圖递宅，日志截圖娘香，截圖直接粘貼就可以了冬筒，不要添加附件，附件：日志茅主、測試數(shù)據(jù)（文件）圖片，比如上傳頭像土榴，就把圖片放在文件中當(dāng)附件上傳诀姚，開發(fā)要重現(xiàn)這個(gè)BUG，那么根據(jù)你附件的圖片來重現(xiàn)玷禽。預(yù)期結(jié)果----記得寫清楚預(yù)期
BUG類型和嚴(yán)重程度-----便于后續(xù)測試結(jié)果分析赫段，BUG的統(tǒng)計(jì)
BUG測試環(huán)境---例如：什么系統(tǒng)；哪個(gè)版本等矢赁。兼容性問題糯笙、難以重現(xiàn)問題
附件----日志文件、文件測試數(shù)據(jù)
所有以上的如何提交BUG撩银，參考公司前輩寫的BUG给涕，依葫蘆畫瓢，拓展測試思維额获。
測試的BUG備注修改方案和操作信息
如果寫了兩條一摸一樣的BUG或者提交的BUG不是BUG而是操作錯(cuò)誤够庙，問同事怎么刪除，或者是在BUG標(biāo)題前面?zhèn)渥ⅰ靶鑴h除”抄邀，然后跟老大說耘眨，老大會批量刪除【成觯或者不刪除自己編輯下其他BUG.
BUG的跟蹤管理-狀態(tài)處理
1.已經(jīng)指派的BUG---已經(jīng)指派給開發(fā)的剔难，請大家注意自己BUG的走向，隨時(shí)關(guān)注并進(jìn)行跟蹤奥喻！如果一直未修復(fù)偶宫，提醒開發(fā)修改，以免開發(fā)忘記衫嵌；如果已經(jīng)修復(fù)等待測試環(huán)境更新后進(jìn)行驗(yàn)證读宙。催著改BUG
2.已解決的BUG----等待測試環(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)境是否分測試環(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)境是否跟測試環(huán)境一致碍粥？包括操作步驟，瀏覽器黑毅、環(huán)境嚼摩、特定賬號等，如果多個(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)需要解決請備注原因并打開指派給開發(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.延期修改---請看下BUG嚴(yán)重程度滋尉，是否影響當(dāng)前版本發(fā)布玉控？與產(chǎn)品經(jīng)理進(jìn)行確認(rèn)。不予延期請根據(jù)情況進(jìn)行激活與情況說明狮惜；確定延期則做好記錄高诺，后續(xù)版本進(jìn)行關(guān)注。
53.三角形測試用例設(shè)計(jì)：
1碾篡、 當(dāng)三邊不可能構(gòu)成三角形時(shí)提示錯(cuò)誤虱而，可構(gòu)成三角形時(shí)計(jì)算三角形周長。
2开泽、若是等腰三角形打印“等腰三角形”牡拇，若兩個(gè)等腰的平方和等于第三邊平方和，則打印“等腰直角三角形”穆律。
3惠呼、若是等邊三角形，則打勇驮拧：“等邊三角形”剔蹋。
4、畫出程序流程圖并設(shè)計(jì)一個(gè)測試用例辅髓。
1泣崩、構(gòu)成三角形的條件：任意兩邊之和大于第三邊少梁；
2、構(gòu)成等腰三角形的條件：任意兩邊相等矫付；
3凯沪、構(gòu)成等腰直角三角形的條件：任意兩邊相等，而且兩條邊的平方和等于第三邊的平方和；
4、構(gòu)成等邊三角形的條件：三條邊都相等豹悬。
