测试知识点总结
1. B/S架構和C/S架構區(qū)別
一. B/S和C/S的定義
1.什么是B/S？
B/S結構（Browser/Server）是瀏覽器服務器這種開發(fā)模式，
就是只安裝維護一個服務器(Server)，而客戶端采用瀏覽器(Browse)運行軟件
2.什么是C/S?
C/S又稱Client/Server或客戶/服務器模式。需要做客戶端服務器端 。服務器通常采用高性能的PC、工作站或小型機，并采用大型數(shù)據(jù)庫系統(tǒng)，如Oracle、Sybase、Informix或 SQL Server。客戶端需要安裝專用的客戶端軟件。
3.B/S和C/S的區(qū)別
-
Client/Server是建立在局域網(wǎng)的基礎上的。
-
Browser/Server是建立在廣域網(wǎng)的基礎上的.
-
C/S響應速度快，安全性強，用戶體驗好，一般應用于局域網(wǎng)中，但是開發(fā)維護成本高，；
B/S可以實現(xiàn)跨平臺，客戶端零維護，但是個性化能力低，響應速度較慢 -
安全要求不同
C/S 一般面向相對固定的用戶群, 對信息安全的控制能力很強.一般高度機密的信息系統(tǒng)采用C/S 結構適宜.
可以通過B/S發(fā)布部分可公開信息.B/S 建立在廣域網(wǎng)之上, 對安全的控制能力相對弱, 面向是不可知的用戶群.
-
對程序架構不同
C/S 程序可以更加注重流程, 可以對權限多層次校驗, 對系統(tǒng)運行速度可以較少考慮.B/S 對安全以及訪問速度的多重的考慮, 建立在需要更加優(yōu)化的基礎之上. 比C/S有更高的要求 B/S結構的程序架構是發(fā)展的趨勢, 從MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持網(wǎng)絡的構件搭建的系統(tǒng). SUN 和IBM推的JavaBean 構件技術等,使 B/S更加成熟.
-
軟件重用不同
C/S 程序可以不可避免的整體性考慮, 構件的重用性不如在B/S要求下的構件的重用性好.
B/S 對的多重結構,要求構件相對獨立的功能. 能夠相對較好的重用.就入買來的餐桌可以再利用,而不是做在墻上的石頭桌子
-
系統(tǒng)維護不同
系統(tǒng)維護是軟件生存周期中,開銷大, -------重要
C/S 程序由于整體性, 必須整體考察, 處理出現(xiàn)的問題以及系統(tǒng)升級.升級難. 可能是再做一個全新的系統(tǒng)
B/S 構件組成,方面構件個別的更換,實現(xiàn)系統(tǒng)的無縫升級. 系統(tǒng)維護開銷減到最小.用戶從網(wǎng)上自己下載安裝就可以實現(xiàn)升級.
-
處理問題不同
C/S 程序可以處理用戶面固定, 并且在相同區(qū)域, 安全要求高需求, 與操作系統(tǒng)相關. 應該都是相同的系統(tǒng)。 B/S 建立在廣域網(wǎng)上, 面向不同的用戶群, 分散地域, 這是C/S無法作到的. 與操作系統(tǒng)平臺關系最小
-
用戶接口不同
C/S 多是建立的Window平臺上,表現(xiàn)方法有限,對程序員普遍要求較高
B/S 建立在瀏覽器上, 有更加豐富和生動的表現(xiàn)方式與用戶交流. 并且大部分難度減低,減低開發(fā)成本.
-
信息流不同
C/S 程序一般是典型的中央集權的機械式處理, 交互性相對低
B/S 信息流向可變化, B-B B-C B-G等信息、流向的變化, 更象交易中心
二、CS和BS結構各自的優(yōu)、缺點
1.C/S的優(yōu)點是能充分發(fā)揮客戶端PC的處理能力，很多工作可以在客戶端處理后再提交給服務器。對應的優(yōu)點就是客戶端響應速度快。缺點主要有以下幾個：
? 只適用于局域網(wǎng)。而隨著互聯(lián)網(wǎng)的飛速發(fā)展，移動辦公和分布式辦公越來越普及，這需要我們的系統(tǒng)具有擴展性。這種方式遠程訪問需要專門的技術，同時要對系統(tǒng)進行專門的設計來處理分布式的數(shù)據(jù)。
? 客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進行安裝或維護。特別是有很多分部或專賣店的情況，不是工作量的問題，而是路程的問題。還有，系統(tǒng)軟件升級時，每一臺客戶機需要重新安裝，其維護和升級成本非常高。
? 對客戶端的操作系統(tǒng)一般也會有限制。可能適應于Win98, 但不能用于Win2000或WindowsXP。或者不適用于微軟新的操作系統(tǒng)等等，更不用說Linux、Unix等。
2.B/S最大的優(yōu)點就是可以在任何地方進行操作而不用安裝任何專門的軟件。只要有一臺能上網(wǎng)的電腦就能使用，客戶端零維護。系統(tǒng)的擴展非常容易，只要能上網(wǎng)，再由系統(tǒng)管理員分配一個用戶名和密碼，就可以使用了。甚至可以在線申請，通過公司內部的安全認證（如CA證書）后，不需要人的參與，系統(tǒng)可以自動分配給用戶一個賬號進入系統(tǒng)。
2. HTTP協(xié)議
1、https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協(xié)議，信息是未加密的，明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全。
3. POST與GET區(qū)別
4. Cookie和Session的區(qū)別與聯(lián)系
Cookie，Session 也會失效（但是可以通過其它方式實現(xiàn)，比如在 url 中傳遞 Session ID）。
5. 測試的目的
1）軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。
2）測試是為了證明程序有錯，而不是證明程序無錯。（發(fā)現(xiàn)錯誤不是唯一目的）
3）一個好的測試用例在于它發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。
4）一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。
注意：
1、測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征。可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，通過分析也能幫助我們設計出有針對性的檢測方法，改善測試的有效性。
2、沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。詳細而嚴謹?shù)目煽啃栽鲩L模型可以證明這一點。例如Bev Littlewood發(fā)現(xiàn)一個經(jīng)過測試而正常運行了n個小時的系統(tǒng)有繼續(xù)正常運行n個小時的概率。
6. 軟件測試原則
1）應當把“盡早地不斷地進行軟件測試“作為軟件開發(fā)者的座右銘。
2）測試用例應由測試數(shù)據(jù)和與之對應的預期輸出結果這兩部分組成。
3）程序員應避免檢查自己的程序。
4）在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。
5）充分注意測試中的群集現(xiàn)象。
6）嚴格執(zhí)行測試計劃，排除測試的隨意性。
7）應當對每一個測試結果做全面的檢查。
8）妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便
7. 軟件測試分為哪幾個階段？
軟件測試分類
按照階段
單元測試：是指對軟件中的最小可測試單元進行檢查和驗證
集成測試：集成測試是單元測試的下一個階段，是指將通過測試單元模塊組裝成系統(tǒng)或者子系統(tǒng)，再進行測試，重點測試不同模塊的接口部分。
系統(tǒng)測試：指的是將整個軟件系統(tǒng)看做一個1個整體進行測試，包括對功能、性能，以及軟件所運行的軟硬件環(huán)境進行測試。
驗收測試：以用戶為主的測試，軟件開發(fā)人員和質量保證人員參加
按照是否查看源代碼劃分
白盒測試:指的是把盒子蓋打開，去研究里邊源代碼和程序結構(單元測試，ui/接口自動化測試)
黑盒測試:把被測試的軟件看做一個黑盒子，我們不去關心盒子里邊的結構是什么樣子，只關心軟件的輸入數(shù)據(jù)和輸出結果
功能測試
**邏輯功能測試:**測試應用是否符合邏輯，比如應該先注冊賬號之后，才能進行登錄,登錄之后才能看我的購物車
界面測試:窗口大小，按鈕大小，點擊按鈕彈出什么樣的提示框，是否有滾動條，下拉菜單是否有展示內容
易用測試:從軟件使用的合理性和方便性等角度對軟件系統(tǒng)進行檢查,比如，軟件窗口長寬比例是否合適，顏色色彩是否賞心悅目，字體大小是否合適
**安裝測試:**安裝磁盤空間不足，安裝中斷(關閉程序，關機，，)下次安裝時是否繼續(xù)上次的安裝等。。。
兼容測試:硬件兼容性測試和軟件兼容性測試（硬件兼容性:比如一款軟件在pc機，筆記本,主機上是否兼容，軟件兼容性測試:比如一款軟件在window8和window10上是否兼容）
性能測試
一般性能測試
穩(wěn)定測試:
負載測試: 讓被測系統(tǒng)在其能夠忍受的壓力范圍之內連續(xù)運行，來測試系統(tǒng)的穩(wěn)定性。（測試載重）
壓力測試:持續(xù)不斷的給被測試的系統(tǒng)增加壓力，直到被測試的系統(tǒng)壓垮為止，用來測試系統(tǒng)所承受的最大壓力。（測試強度）
其他
回歸測試：回歸測試是指修改了舊代碼后，重新在新環(huán)境上進行測試以確認修改沒有引入新的錯誤或導致其他代碼產(chǎn)生錯誤。
冒煙測試：指對一個軟件進行系統(tǒng)大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現(xiàn)，是否具備可測性。
隨機測試：是指測試中所有的輸入數(shù)據(jù)都是隨機生成的，其目的是模擬用戶的真實操作，并發(fā)現(xiàn)一些邊緣性的錯誤
8. 單元測試與集成測試的側重點
單元測試
是在軟件開發(fā)過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試，測試重點是系統(tǒng)的模塊，包括子程序的正確性驗證等。集成測試
也叫組裝測試或聯(lián)合測試。在單元測試的基礎上，將所有模塊按照設計要求，組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現(xiàn)。測試重點是模塊間的銜接以及參數(shù)的傳遞等。9. 系統(tǒng)測試范圍
指的是將整個軟件系統(tǒng)看做一個1個整體進行測試，包括對功能、性能，以及軟件所運行的軟硬件環(huán)境進行測試。
系統(tǒng)測試由黑盒測試人員在整個系統(tǒng)集成完畢后進行測試，前期主要測試系統(tǒng)的功能是否滿足需求，后期主要測試系統(tǒng)運行的性能是否滿足需求，以及系統(tǒng)在不同的軟硬件環(huán)境的兼容性等
10. a測試與?測試的區(qū)別
α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試不能由程序員或測試員完成。
β測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。
它們都是驗收測試！
α測試是指把用戶請到開發(fā)方的場所來測試
β測試是指在一個或多個用戶的場所進行的測試。
α測試的環(huán)境是受開發(fā)方控制的,用戶的數(shù)量相對比較少,時間比較集中。
β測試的環(huán)境是不受開發(fā)方控制的, 用戶數(shù)量相對比較多,時間不集中。
α測試先于β測試執(zhí)行。通用的軟件產(chǎn)品需要較大規(guī)模的β測試,測試周期比較長
11. 驗收測試怎么做？
驗收測試主要包含兩個階段：二輪測試和冒煙測試。在測試階段的先后順序上，二輪測試在一輪測試(需求的系統(tǒng)性測試)之后，在冒煙測試之前。在測試粒度上，按照由細到粗的順序，依次為二輪測試和冒煙測試;冒煙測試，眾所周知是對功能主路徑的回歸驗證，而二輪測試則是執(zhí)行較冒煙更細粒度的測試，另外也包含了一輪測試階段中出現(xiàn)bug較多的場景等等。
一輪測試：系統(tǒng)的測試驗證需求的階段，包含全部功能點的驗證、兼容性驗證、性能驗證等等;
二輪測試：作為一輪測試后的整體回歸驗證階段，主要側重驗證功能的主流程和一輪測試中問題較多的場景的相關用例
開始標準
一、測試自身
1、一輪測試執(zhí)行完畢;
2、一輪階段的待檢驗bug回歸完畢;
3、發(fā)起內核代碼遷移郵件，確認內核開發(fā)要集成到正式發(fā)布分支的代碼，且均已驗證完畢。
二、配合方
1、各配合方均已上線驗證完畢;
2、例如：產(chǎn)品配置項、服務端、前端、第三方等;
3、反例：小編最近碰到個問題，由于沒有在二輪測試開始前做好上線驗證工作，導致在二輪執(zhí)行階段遇到多方聯(lián)調問題，影響項目進度。
4、具體表現(xiàn)：在二輪測試執(zhí)行階段，發(fā)現(xiàn)已經(jīng)上線了的服務端和第三方相關功能無法順利走通，經(jīng)過定位排查發(fā)現(xiàn)是在上線時，服務端和第三方的接口沒有聯(lián)調成功。
5、三方(開發(fā)、產(chǎn)品、測試)確認無阻塞二輪測試的bug;
6、代碼集成完畢;(視具體項目組而定)
7、新功能或有較大改動模塊，產(chǎn)品&交互驗收通過并已回復郵件;
8、新功能或有視覺改動模塊，視覺走查通過并已回復郵件;
9、備注：當項目發(fā)版緊張時，開發(fā)評估一輪未結束的模塊對其他模塊均無影響(如，獨立插件的功能模塊)，可以先執(zhí)行其他不受影響的模塊的二輪測試
12. 白盒、黑盒和灰盒測試區(qū)別
白盒測試:指的是把盒子蓋打開，去研究里邊源代碼和程序結構(單元測試，ui/接口自動化測試)
黑盒測試:把被測試的軟件看做一個黑盒子，我們不去關心盒子里邊的結構是什么樣子，只關心軟件的輸入數(shù)據(jù)和輸出結果
灰箱測試或灰盒測試(Gray-box testing):灰箱測試就像黑箱測試一樣是通過用戶界面測試，但是測試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的。甚至于還讀過部分源代碼。 因此測試人員可以有的放矢地進行某種確定的條件/功能的測試。這樣做的意義在于:如果你知道產(chǎn)品內部的設計和對產(chǎn)品有透過用戶界面的深入了解，你就能夠更有效和深入地從用戶界面來測試它的各項性能
13. 冒煙測試的目的
冒煙測試：指對一個軟件進行系統(tǒng)大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現(xiàn)，是否具備可測性。
使用冒煙測試是為了正式測試前，驗證是否產(chǎn)品或系統(tǒng)的主要需求或預置條件是否存在bug
14. 回歸測試怎么做？
回歸測試：回歸測試是指修改了舊代碼后，重新在新環(huán)境上進行測試以確認修改沒有引入新的錯誤或導致其他代碼產(chǎn)生錯誤。
1、在測試策略制定階段，制定回歸測試策略
2、確定需要回歸測試的版本
3、回歸測試版本發(fā)布,按照回歸測試策略執(zhí)行回歸測試
4、回歸測試通過，關閉缺陷跟蹤單（問題單）
5、回歸測試不通過，缺陷跟蹤單返回開發(fā)人員，開發(fā)人員重新修改問題，再次提交測試人員回歸測試
15. 全部回歸與部分回歸的區(qū)別？
對軟件的新版本測試時，重復執(zhí)行上一個版本測試時使用的測試用例，防止出現(xiàn)“以前應用沒有的問題現(xiàn)在出問題了”，這是全部回歸；當在測試過程中，發(fā)現(xiàn)某個模塊存在缺陷，開發(fā)修復后，測試人員重新驗證該缺陷是否被修復，以及驗證相關聯(lián)的模塊是否受影響，這叫部分回歸。
16. 需求分析的目的
1、把用戶需求轉化為功能需求：
1）對測試范圍進度量 2）對處理分支進行度量 3）對需求業(yè)務的場景進行度量 4）明確其功能對應的輸入、處理和輸出 5）把隱式需求轉變?yōu)槊鞔_。2、明確測試活動的五個要素：測試需求是什么、決定怎么測試、明確測試時間、確定測試人員、確定測試環(huán)境：測試中需要的技能，工具以及相應的背景知識
，測試過程中可能遇到的風險等等。測試需求需要做到盡可能的詳細明確，以避免測試遺漏和誤解。17. 測試計劃的目的
1、測試的目的是為了bai發(fā)現(xiàn)du盡可能多的缺陷，不是為了說zhi明軟件中沒有缺陷。
2、成功的測試在于發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷。所以測試人員的職責是設計這樣的測試用例，它能有效地揭示潛伏在軟件里的缺陷
18. 什么時候開始寫測試計劃
在項目開始后，在前期你需要了解測試的背景，范圍和工作量，以及人員的分工，所需的資源，工期等，在這些了解清楚后開始撰寫測試計劃
19. 由誰來編寫測試計劃
測試計劃一般由資深的測試人員來做， 要對整zhi體的項目有非常好的掌控，有豐富的測試經(jīng)驗的人員來編寫測試計劃。
1. 測試計劃一般由測試經(jīng)理來編寫。2. 測試組其他人員， 會針對自己分配的任務估算自己任務的時間，統(tǒng)一匯總到測試經(jīng)理那里20. 測試計劃的內容
測試背景 測試目標 測試范圍 測試輸出文檔 測試策略 測試規(guī)模工作量分析 測試進程 測試進度及時間安排 測試資源 人力，設備， 風險管理
（1）測試環(huán)境：測試環(huán)境+生產(chǎn)環(huán)境
（2）測試范圍：新增需求+全功能回歸
（3）測試重點：優(yōu)先級為high的
（4）注意事項：開發(fā)提供修改點
（5）測試級別：常規(guī)啥的
（6）測試方法：功能測試？性能測試
（7）測試文檔：測試依據(jù)、測試條件、測試用例
（8）計劃測試資源：人員以及安排的工作日
（9）是否需要外部支持：是/否
（10）測試出口：發(fā)布時間
21. 結束條件(項目上線的條件)
結束條件：
1.測試用例執(zhí)行比例，一般功能測試用例全部執(zhí)行完畢，非功能測試用例執(zhí)行達95%以上
2.測試缺陷修改數(shù)量，一般及以上的用例全部修復并驗證通過，已修復缺陷占比95%以上
3.測試覆蓋需求程度，測試覆蓋全部的需求且達到上線的要求或標準
上線條件：
1.編寫目的：明確軟件測試工作的開始和結束標準。
2.軟件測試合格標準：以上比例為錯誤占總測試模塊的比例。
3.缺陷修復率標準
1) A、B、C級錯誤修復率應達到100%
2) D級錯誤修復率應達到96%以上
4.覆蓋率標準
測試需求執(zhí)行覆蓋率應達到100%（業(yè)務測試用例均以執(zhí)行）。
5.錯誤級別
A級：不能完全滿足系統(tǒng)要求，基本功能未完全實現(xiàn)；或者危及人身安全。系統(tǒng)崩或掛起等導致系統(tǒng)不能繼續(xù)運行。
B級：嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有更正辦法（重新安或重新啟動該軟件不屬于更正辦法）。使系統(tǒng)不穩(wěn)定、或破壞數(shù)據(jù)、或產(chǎn)生錯誤結果，或部分功能無法執(zhí)行，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的主要問題。
C級：嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，但存在合理的更正辦法（重新啟動該軟件不屬于更正辦法）。系統(tǒng)性能或響應時間變慢、產(chǎn)生錯誤的中間結果但不影響最終結果等影響有限的問題
22. 常見的測試風險
D級：使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。界面拼寫錯誤或用戶使用不方便等小問題或需要完善的問題
23. 測試用例的要素
字符和數(shù)字組合成的字符串，用例編號應具有唯一性、易識別
系統(tǒng)測試：產(chǎn)品編號-ST-系統(tǒng)測試項名-系統(tǒng)測試子項名-XXX
集成測試：產(chǎn)品編號-IT-集成測試項名-集成測試子項名-XXX
單元測試：產(chǎn)品編號-UT-單元測試項名-單元測試子項名-XXX
當前測試用例所在測試大類、被測試需求、被測模塊、被測單元等
系統(tǒng)測試用例測試項目
軟件需求項
集成測試用例測試項目
集成后的模塊名或接口名
單元測試用例測試項目
被測函數(shù)名
簡單描述，需要用概括的語言描述用例的出發(fā)點和關注點，原則上每個用例的標題不能重復
對基本和普通測試項的區(qū)分
高級別
保證系統(tǒng)基本功能、核心業(yè)務、重要特性、實際使用頻率比較高的用例
中級別
重要程度介于高和低之間的測試用例
低級別
實際使用的頻率不高，對系統(tǒng)業(yè)務功能影響不大的模塊或功能的測試用例
執(zhí)行當前測試用例需要的前提條件，如果這些前提條件不滿足，則后面測試步驟無法進行或無法得到 預期結果
7.操作步驟
執(zhí)行當前測試用例需要經(jīng)過的操作步驟，需要明確的給出一個步驟的描述，測試用例執(zhí)行人員可以根據(jù)該步驟完成測試用例執(zhí)行
8.預期輸出
當前測試用例的預期輸出結果，包括返回值內容，界面的響應結果，輸出結果的規(guī)則符合度等
測試用例額外的要素
1.用例設計者
能準確的找到測試用例設計人員，對用例修改時能方便找準人員
2.用例設計日期
方便檢查用例設計的進度
3.用例版本號
方便用例設計人員對用例的跟蹤
24. 測試用例級別的劃分
優(yōu)先級一般都是和缺陷的嚴重程度對應的。
一般可以把優(yōu)先級分為三種：
高：保證功能性是穩(wěn)定的，是按照需求的正常使用和實現(xiàn)點進行用例設計的，重要的錯誤和邊界測試的測試用例的集合。
中：更全面的驗證功能的各方面，包括流程中的各個節(jié)點出錯情況、異常情況測試、中斷、UI展示、用戶體驗等方面的測試用例設計
低：不常被執(zhí)行的測試用例。比如壓力和性能測試用例設計，接口測試用例設計隨著時間的推移已經(jīng)從低級別變化到了中級別
25. 怎樣保證覆蓋用戶需求？
覆蓋用戶的需求；
從用戶使用場景出發(fā)，考慮用戶的各種正常和異常的使用場景；
用例的顆粒大小要均勻。通常，一個測試用例對應一個場景；
用例各個要素要齊全，步驟應該足夠詳細，操作應該明確，容易被其它測試工程師讀懂，并能順利執(zhí)行；
做好用例評審，及時更新測試用例。
測試完成應找業(yè)務人員進行驗收，便于發(fā)現(xiàn)非測試角度的問題
26. 寫好測試用例的關鍵 /寫好用例要關注的維度
測試用例：測試用例為驗證某一特定軟件產(chǎn)品準備的一組有編號，輸入，預期輸出的描述 //記得《軟件測試過程與管理》上是這樣寫的,而我個人覺得應該是有編號，輸入，預期輸出，測試步驟，測試描述等等一些信息的描述
以下Shared by Mikhail Rakhunov
好的測試用例：一個發(fā)現(xiàn)Bug概率很大的用例就是一個好的測試用例
測試用例設計應該具備的以下的特點
Test Case ID:
用來標記測試用例的編號，這個編號必須是唯一的
測試描述:
用來描述你將要進行的測試是怎樣實施的
修訂歷史:
為了明確測試用例由誰創(chuàng)建或者修改，所以每個測試用例都應該有其修訂歷史
功能模塊:
測試功能模塊的名字
測試環(huán)境:
用來描述你的測試環(huán)境，當然包括硬件環(huán)境和軟件環(huán)境
測試準備:
測試之前除了你所測試的程序之外還應該準備的東西，如打印機，網(wǎng)絡等等
測試執(zhí)行:
用來詳細描述你的測試步驟.
期望結果:
The deion of what you expect the to do.
描述該功能所要實現(xiàn)怎樣的結果
實際結果:
通過/失敗
如果成功——紀錄實際運行的過程
如果失敗——描述你觀察到的現(xiàn)象，這將有利于發(fā)現(xiàn)Bug的起源
----------
一個很好的測試所應具有的特征:
發(fā)現(xiàn)Bug的幾率很大
沒有多余
不是太簡單也不會太復雜
----------
ps.當你的期望結果有很多的時候，測試用例就會變得很復雜
27. 測試用例的狀態(tài)
排隊（In Queue）：
測試用例已經(jīng)指定給某個測試人，不準備在這一個測試階段運行。
進行中（IP）：
該測試正在進行，并且會持續(xù)一段時間。（如果一個測試所需要的時間少于一天，我就不會講一個測試標為進行中，因為我每天會跟蹤測試用例的狀態(tài)）
阻塞（Block）：
一些因素會導致測試不能進行到底，例如某個功能欠缺或者測試環(huán)境的某個部分欠缺。我通常會在測試用例總結工作表的意見欄記錄下阻塞的狀態(tài)。你可以把阻塞理解為：我希望運行測試，但是目前還不能運行測試。
跳過（Skip）：
你決定在當前測試階段跳過某個測試，可能是因為它的優(yōu)先權相對較低。（同樣地，我會在測試用例總結工作表的意見欄記錄下我跳過這個測試的原因。）你可以把跳過理解為：我現(xiàn)在可以運行這個測試，但是我不想運行它。
通過（Pass）：
測試運行結束，測試人得到了預料中的測試結果狀態(tài)和測試行為。
失敗（Fail）：
在很多情況下，測試人得到預料之外的測試結果，狀態(tài)或行為，這些結果與測試目標相差甚遠。這就引發(fā)了關于系統(tǒng)質量的疑問。一個或多個測試錯誤需要記錄下來。
警告（Warn）：
在很多情況下，測試人得到預料之外的測試結果，狀態(tài)或行為，但是這些結果與測試目標差別不是很大（我通常會在測試包總結工作表的通過一欄記為警告，而不是另加一欄）。另一種想法是，警告意味著當前的錯誤是無關緊要的，或者對正在測試的特征是沒有意義的。系統(tǒng)報出了更多的錯。我處理這個問題的一個標準是只和延期的或不是一定要改的錯誤相關的測試可以標記為警告，而不是失敗。
關閉（Close）：
一個測試在第一個循環(huán)中被標為失敗或警告，第二個測試發(fā)布中將第一個測試循環(huán)出現(xiàn)的錯誤修改了。重新運行了整個測試用例后，沒有錯誤出現(xiàn)。將這類測試標記為關閉而不是通過，使得你可以跟蹤測試在某一個測試發(fā)布中失敗的實事（同標記為警告的測試一樣，我在測試包總結工作表中將標記為關閉的測試也納入成功的范疇）。
28. 常見的測試用例設計方法
用例編寫步驟：
拿到測試需求 -> 分析需求（畫思維導圖） -> 編寫用例 -> 劃分用例優(yōu)先級
用例編寫特性：
· 一致性：主要包括用例模板一致；各同事的編寫手法一致；以及用例的細粒度一致。
· 覆蓋率：主要包括對需求的覆蓋（也包含隱含的需求）；新需求可能對那些功能會產(chǎn)生影響的覆蓋；對各種場景的覆蓋等 。
·可執(zhí)行性：主要是指步驟易于理解、信息描述準確、且能快速識別出測試點 。
·執(zhí)行準確性：是指用例執(zhí)行的準確度，本身沒什么技術含量。但這里需要注意的是執(zhí)行人對待執(zhí)行用例的態(tài)度。不要因為用例簡單或者一些外界的因素，導致部分用例未實際執(zhí)行標為通過的情況。
·持續(xù)更新：要及時不斷的更新，要盡量減少用例庫中失效的用例 。
·復用性：主要用例可以被不斷的復用，從而減少維護成本
用例設計方法：
1. 等價類與邊界值**（重點方法）**
等價類：等價類劃分法是把所有可能輸入的數(shù)據(jù)，有無效等價類和有效等價類（即正確輸入和非法輸入），即程序的輸入域劃分策劃國內若干部分（子集），然后從每一個子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例。方法是一種重要的、常用的黑盒測試用例設計方法。
邊界值：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。
與等價類區(qū)別：
? · 邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
? · 邊界值分析不僅考慮輸入條件，還要考慮輸出空間產(chǎn)生的測試情況。
等價類與邊界值的結合使用：
? 例：一個文本框的輸入長度為 6-10 個字符
? 分析：有效等價類： >=6個字符，<=10個字符
? 無效等價類：<6個字符，>10個字符
? 邊界值：5,6,7,9,10,11個字符
2. 場景法**（重點方法）**
定義：通過運用場景來對系統(tǒng)的功能點或業(yè)務流程的描述，從而提高測試效果的一種方法。用例場景來測試需求是指模擬特定場景邊界發(fā)生的事情，通過事件來觸發(fā)某個動作的發(fā)生，觀察事件的最終結果，從而用來發(fā)現(xiàn)需求中存在的問題。
基本流：是經(jīng)過用例的最簡單的路徑（無任何差錯，程序從開始直接執(zhí)行到結束）
備選流：一個備選流可能從基本流開始，在某個特定條件下執(zhí)行，然后重新加入基本流中，也可以起源于另一個備選流，或終止用例，不在加入到基本流中；（各種錯誤情況）
場景法的運用：
? 例：有一個在線購物的實例，用戶進入一個在線購物網(wǎng)站進行購物，選購物品后，進行在線購買，這時需要使用帳號登錄，登錄成功后，進行付錢交易，交易成功后，生成訂購單，完成整個購物過程。
? · 基本流
? · 備選流： 1) 進入購物網(wǎng)站，選擇物品，登錄賬號，付費，生成訂單
? 2）賬號不存在
? 3) 賬戶余額不足
? 更多的備選流。。。。。。
\3. 正交排列驅動法
定義：在界面中有多個控件，控件之間有多種組合關系，如果組合的數(shù)量巨大（一般超過20種），沒有必要將所有組合都測試，可以通過正交排列法將組合中最優(yōu)，最少的組合進行測試。
正交表公式：
? Ln（m^k）
? · L（line）行
? n:表示正交表的行數(shù)
提示：正交表確定后，n值是固定的，不需要測試人員計算
m：表示正交表中數(shù)據(jù)的最大值
測試時：m表示每個控件的取值個數(shù)
K:表示正交表的列數(shù)
測試時：k表示參與組合的控件的個數(shù)
與判定表驅動法的區(qū)別：正交表一般用于組合較多的場合（一般>20種），判定表一般用于組合較少的情況
判定表示例：https://baike.baidu.com/pic/%E6%AD%A3%E4%BA%A4%E8%A1%A8/948850/0/ac345982b2b7d0a2394108ccc9ef76094a369ad2?fr=lemma&ct=single#aid=0&pic=ac345982b2b7d0a2394108ccc9ef76094a369ad2
4. 因果圖
1.定義：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。
2.因果圖法產(chǎn)生的背景：
? 等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經(jīng)測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
? 如果在測試時必須考慮輸入條件的各種組合，則可能的組合數(shù)目將是天文數(shù)字，因此必須考慮采用一種適合于描述多種條件的組合、相應產(chǎn)生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。
3.因果圖介紹
4種符號分別表示了規(guī)格說明中向4種因果關系。
因果圖中使用了簡單的邏輯符號，以直線聯(lián)接左右結點。左結點表示輸入狀態(tài)（或稱原因），右結點表示輸出狀態(tài)（或稱結果）。
Ci表示原因，通常置于圖的左部；ei表示結果，通常在圖的右部。Ci和ei均可取值0或1，0表示某狀態(tài)不出現(xiàn)，1表示某狀態(tài)出現(xiàn)。
\4. 因果圖概念
? ①恒等：若ci是1，則ei也是1；否則ei為0。
? ②非：若ci是1，則ei是0；否則ei是1。
? ③或：若c1或c2或c3是1，則ei是1；否則ei為0。“或”可有任意個輸入。
? ④與：若c1和c2都是1，則ei為1；否則ei為0。“與”也可有任意個輸入。
? 輸入狀態(tài)相互之間還可能存在某些依賴關系，稱為約束。例如, 某些輸入條件本身不可能同時出現(xiàn)。輸出狀態(tài)之間也往往存在約束。在因果圖中,用特定的符號標明這些約束。
A.輸入條件的約束有以下4類：
? ① E約束（異）：a和b中至多有一個可能為1，即a和b不能同時為1。
? ② I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。
? ③ O約束（唯一）；a和b必須有一個，且僅有1個為1。
? ④R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。
? B.輸出條件約束類型
? 輸出條件的約束只有M約束（強制）：若結果a是1，則結果b強制為0。
\5. 采用因果圖法設計測試用例的步驟：
1)分析軟件規(guī)格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 并給每個原因和結果賦予一個標識符。
2)分析軟件規(guī)格說明描述中的語義，找出原因與結果之間, 原因與原因之間對應的關系，根據(jù)這些關系,畫出因果圖。
3)由于語法或環(huán)境限制, 有些原因與原因之間,原因與結果之間的組合情況不可能出現(xiàn)，為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件。
4)把因果圖轉換為判定表。
5)把判定表的每一列拿出來作為依據(jù),設計測試用例。
5. 判定表
定義：判定表是分析和表達多邏輯條件下執(zhí)行不同操作的情況的工具。
判定表的優(yōu)點
· 能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。
·在一些數(shù)據(jù)處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執(zhí)行不同的操作。判定表很適合于處理這類問題。
判定表通常由四個部分組成如下圖所示：
1)條件樁（Condition Stub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。
2)動作樁（Action Stub）：列出了問題規(guī)定可能采取的操作。這些操作的排列順序沒有約束。
3)條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。
4)動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
6. 錯誤推測法
定義：基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法
錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例
29. 判定表用在哪些時候/哪些功能
判定表比較多用在多層條件判斷組合的場景，比如嵌套的if語句這種
使用場景：
1：等價類和邊界值無法覆蓋到控件與控件之間的聯(lián)系，此時我們需要判定表來覆蓋控件與控件之間的影響
什么是判定表：
判定表是分析若干輸入條件下，被測試對象根據(jù)不同的條件作出不同的響應的工具，適用于業(yè)務邏輯關系和多種條件組合情況
判定表的結構：
名詞解釋：
- 條件樁：被測對象所有的輸入
- 動作樁：針對條件樁所有的動作
- 條件項：被測對象可能輸入的真假值 T F
- 動作項：針對條件項的動作T F
使用判定表的步驟
1.列出所有的條件和動作 2.根據(jù)提取出來的條件樁和動作樁，設計判定表確定規(guī)則的個數(shù)（假如有n個條件，每個條件有2個取值 （0、1），就可以產(chǎn)生2的n次方種規(guī)則） 3.填寫判定表 4.簡化判定表【合并判定表會減小測試的充分性，8條以內的規(guī)則不建議合并】 5.一個規(guī)則就可以轉成一個測試用例 12345以登錄模塊為例
正確的賬號密碼登錄成功
用戶名和密碼為空：提示用戶名或密碼不能為空
用戶名輸入錯誤：提示用戶名或密碼錯誤，用戶名和密碼清空
用戶名正確，密碼錯誤，提示：密碼錯誤，用戶名保留，密碼清空
生成判定表如下圖
判定表優(yōu)點
判定表法主要針對功能需求中的處理過程，處理過程越是復雜，就越有必要使用判定表法。判定表法充分考慮了輸入條件間的組合，對組合情況覆蓋充分，且可得出每個組合的預期輸出。其實，做測試需求分析的目的也就是得出完整的測試用例。重測試需求分析，輕測試執(zhí)行過程。
判定表缺點
當被測試特性輸入較多時，會造成判定表的規(guī)模很龐大。當輸入條件間的約束條件不能有效區(qū)分輸入是否需要進行組合測試時，有可能產(chǎn)生冗余。需手工剔除冗余用例。
30. 什么時候用到場景法
- 場景法適用于解決業(yè)務流程清晰和業(yè)務比較復雜的系統(tǒng)或功能，場景法是一種基于軟件業(yè)務的測試方法。
- 使用場景法，目的是用業(yè)務流把各個孤立的功能點串起來，為測試人員建立整體業(yè)務感覺，從而避免陷入功能細節(jié)忽視業(yè)務流程要點的錯誤傾向。例：語音通話典型業(yè)務流程就把語音通話、同振順振、語音留言、呼叫保持、呼叫轉移這些功能都串到一起來。
- 基本上每個軟件都會用到場景法，因為每個軟件背后都有業(yè)務的支撐。
- 場景法主要用來測試軟件的業(yè)務邏輯和業(yè)務流程。當拿到一個測試任務時，我們并不是先關注某個控件的細節(jié)測試（等價類+邊界值+判定表等），而是要先關注主要業(yè)務流程和主要功能是否正確實現(xiàn)，這就需要使用場景法。當業(yè)務流程和主要功能沒有問題，我們再從等價類、邊界值、判定表等方面對控件細節(jié)進行測試（先整體后細節(jié)）。
**Note：**場景法測試用例設計的重點是測試業(yè)務流程是否正確，測試時需要注意的是，業(yè)務流程測試沒有問題并不代表系統(tǒng)的功能都正確，還必須對單個功能進行詳細的測試，這樣才能保證測試的充分性。
31. 測試環(huán)境怎么搭建的？
關于軟件測試的測試環(huán)境搭建，需要根據(jù)實際的需求來進行安裝特定的軟件，下面就簡單介紹下java+tomcat+mysql安裝方法。
1.java的安裝
因為很多程序的代碼都是通過java編程語言進行編寫的，因此為了測試需要，我們需要安裝支持java編程語言的安裝包，即jdk。下載好指定的安裝包后雙擊安裝包，默認下一步即可。完成這些步驟后需要配置環(huán)境變量，右鍵點擊我的電腦-屬性-高級系統(tǒng)設置-環(huán)境變量-系統(tǒng)變量(s)-選中path-編輯 將安裝好的java中的bin和jre的路徑添加到環(huán)境變量中即可。在cmd中輸入java -version和javac -version驗證是否安裝成功。
2.tomcat的安裝
在java安裝無誤的情況下，下載好tomcat安裝包，直接點擊下一步即可。
3.mysql的安裝
下載好安裝包，將其解壓到想要安裝的盤符中；按照1中的方法，將mysql中bin的路徑添加到環(huán)境變量中；打開cmd，切換到英文，輸入mysqld -install(安裝命令)；輸入mysqld --initialize-insecure(初始化命令)；輸入net start mysql(啟動數(shù)據(jù)庫命令)，如果能夠順利執(zhí)行這些命令無報錯，則數(shù)據(jù)庫安裝成功。倘若已經(jīng)存在舊版本的mysql想將其卸載替換可依次執(zhí)行net stop mysql和mysqld -remove，然后再進行mysql的安裝。
32. 偶然性問題的處理
一、一定要提交!!
1. 記得有這么個缺陷，以后再遇到的時候可能就會了解發(fā)生的原因。
2. 盡力去查找出錯的原因，比如有什么特別的操作，或者一些操作環(huán)境等。
3. 程序員對程序比測試人員熟悉的多，也許你提交了，即使無法重新，程序員也會了解問題所在。
4. 無法重現(xiàn)的問題再次出現(xiàn)后，可以直接叫程序員來看看問題。
5. 對于測試人員來說，沒有操作錯誤這條.既然遇到，就是問題。即使真的操作錯了，也要推到程序員那里，既然測試人員犯錯誤，用戶也可能會犯同樣的錯誤。錯誤發(fā)生的時候，Tester最大。
二、程序不是測試人員寫的，出問題也不是測試人員的原因。
至于無法重現(xiàn)，可能的原因很多，因為測試人員看到的只是程序的外部，無法深入程序內部，所以把責任推給測試人員是不對的。
測試人員的任務只是盡力重現(xiàn)問題，而不是必須重現(xiàn)!!
三、下次再遇到的時候，拉他們來看就可以了。
因為問題如果無論如何無法重現(xiàn)，程序員確實也沒有什么好的解決方法。
而且此類問題即使程序員說修改了，測試員也沒有好的方法去驗證是不是。 : )
四、你可以告訴程序員，測試過程是沒有錯誤的。
測試人員只是檢查程序中可能存在的問題，雖然測試人員使用一定的手段方法努力去覆蓋所有的情況，但這些都是理論的推測。在實際中，可能因為人員、環(huán)境、配置等種種原因出現(xiàn)各種各樣的問題，在測試人員這里發(fā)現(xiàn)問題是公司內部的事情，程序發(fā)到外面可就是公司的形象問題了。
需要讓程序員理解，測試人員是幫助他們的，不是害他們的。
客戶那里發(fā)現(xiàn)問題比測試員發(fā)現(xiàn)問題結果要嚴重的多。
五、測試部門是獨立與開發(fā)部門的呀，真的打交道，也是經(jīng)理對經(jīng)理。
在我們這里，工作上面的事情，和程序員相互只能商議解決，并沒有誰高誰低。
問題無法重現(xiàn)，也要提出，程序員那里可以回復無法再現(xiàn)。問題放在那里，等到再次出現(xiàn)的時候，就立刻叫程序員過來查看。
實在沒有再次出現(xiàn)，最后可以寫到報告中，說出現(xiàn)了什么現(xiàn)象，但無法再現(xiàn)(比較嚴重的問題才如此處理，小問題經(jīng)理之間商量商量可能就算了)。
至于測試人員必須重現(xiàn)bug，你殺了我好了，我每次測試項目都有無法重現(xiàn)的問題，很多我能找到大概的原因，有些根本無法重現(xiàn)(僅僅出現(xiàn)一次)。
這種事情是無法避免的，并不能說測試人員無法重現(xiàn)問題，就是工作不到位(哼，程序有bug，是否可以說程序員工作不到位的呀)。
六、測試部門要獨立，最好不受開發(fā)的制約。其實真正要重視，就應該有否決的權利。
我們公司就是項目承包，要拿最后的項目尾款，就要測試部簽字通過，這樣就避免了很多的問題。
其實只要自己盡到心就可以了，管別人怎么說呢。
七、我們使用的狀態(tài)有：
程序員處理的狀態(tài)(由測試員提交的Action)：等待處理的，再次出現(xiàn)的。
測試員處理的狀態(tài)(由程序員提交的Action)：已經(jīng)修改的，暫不修改的，系統(tǒng)限制的，使用錯誤的，無法再現(xiàn)的。測試員可以修改記錄。
經(jīng)理處理的狀態(tài)(由測試員提交Action)：管理員處理的。經(jīng)理還可以刪除記錄。
按照比較標準的說法，其實對于缺陷還應該有“等待確認的”、“已經(jīng)確認的”和“重復提交的”的狀態(tài)，我們?yōu)榱耸∈?#xff0c;統(tǒng)一使用了“等待處理的”。
最后結項的時候，缺陷的狀態(tài)對我們來說有兩種，“已經(jīng)關閉的”(由測試員或經(jīng)理確認)和“暫不修改的”(比如下一個版本處理等)。
呵呵，狀態(tài)多，有些煩瑣，特別是程序員很多的時候都不清楚應該回復什么狀態(tài)，但我個人覺得對測試人員來說，這些狀態(tài)比較清晰明了，容易處理。
八、一個叫doer_ljy(可戰(zhàn))的網(wǎng)友回復了一些內容，我個人認為不很妥當，就回復了一些內容，綠顏色的是doer_ljy(可戰(zhàn))的內容：
關于“無法重現(xiàn)”我看是有這么個問題存在。
首先如果你在測試之前有嚴格的測試計劃，就很難出現(xiàn)“無法重現(xiàn)”這種現(xiàn)象。“無法重現(xiàn)”的意思是不知道怎么操作才能再次看見這個BUG。那么這個BUG多半是“計劃外”的。
不清楚你是否是測試人員。“計劃外”這個詞，對測試員來說應該不存在。測試用例的粒度一直是個在討論中的問題，測試人員很難有時間和精力寫出包含內容、數(shù)據(jù)、步驟等等全部操作一切的測試用例(說白了，只要一個長手識字的人，按照測試單做，就能發(fā)現(xiàn)所有的問題，呵呵，有軟件藍領的感覺了)。即使真的有，意義也不大，測試很多的時候，是發(fā)散性的思維，帶點創(chuàng)造性，想事先考慮完全，很難。所以更多時候，是在測試過程中逐步對用例等進行完善，所以說“計劃外”最好不要提。
說說我現(xiàn)在測試的一個項目，有一個業(yè)務，首先查詢出人員，有個“全選”按鈕，“全選”后，再用鼠標一個一個取消選擇，這個時候進行業(yè)務辦理的時候，就會提示“沒有選擇人員”，至今為止一切都正常，但是這個時候再次點選人員進行業(yè)務處理，仍然會提示“沒有選擇人員”，這就是一個缺陷了。這個問題我想一般人都不會在測試用例中考慮到吧，因為發(fā)生的條件很苛刻：不用“全選”按鈕的時候不會發(fā)生;全選后點擊“取消全選”按鈕再辦理業(yè)務不會發(fā)生;全選全消后，先點擊人員再辦理業(yè)務也不會發(fā)生。
其次，成熟的測試人員及時無法再現(xiàn)BUG，也能準確的描述出BUG發(fā)生之前幾個步驟的操作方法，測試用例情況。這些對開發(fā)人員分析BUG原因很重要。所謂的BUG發(fā)現(xiàn)環(huán)境。
呵呵，看來我不是成熟的測試人員。手工測試，比較熟練的時候，和打字可以說差不多，應該進行到哪里，心中是有數(shù)的，但讓我完全從頭到尾的重復，不容易呀。寫測試缺陷報告單的時候，也只是說明操作步驟和發(fā)生的現(xiàn)象。其實無法重現(xiàn)的問題，既然說“無法重現(xiàn)”，也就是測試人員已經(jīng)對這個現(xiàn)象進行了多次的驗證，一般從程序外部來說，測試人員的操作比程序員要熟練的。
最后，我不同意測試人員不假思索把發(fā)現(xiàn)的“問題”直接推給編碼人員的做法。畢竟是大家合作，目標是一致的。測試人員總是處在BUG發(fā)生的第一現(xiàn)場，應該幫助分析出現(xiàn)問題的原因。確認是不是自己的此時Miss.
測試人員提交任何一個問題，都會經(jīng)過反復的驗證，如果容易重現(xiàn)，早就提出來了。絕對不是在推脫責任，還是那句話，對程序的結構，做的人當然比不做的人要清楚。另外，除非程序員詢問，否則我不會給程序員提出修改分析和建議!!測試人員的任務是發(fā)現(xiàn)問題，解決問題是程序員的事情。這么做可能會影響程序員思考問題的思路;而且測試人員做的多了，程序員不但不感激，可能反而會反感(好像程序員對測試人員有好印象的不多)。
再說兩個我這兩天遇到的問題。第一個就是我們的程序有一個鎖定數(shù)據(jù)的功能。鎖定后，在其它的業(yè)務，此數(shù)據(jù)將不能再使用。我當時發(fā)現(xiàn)這個功能無效，而且經(jīng)過了幾次的驗證都不行，我當然就提出了。但是程序員那里說此功能好使，我再驗證的時候，就沒有問題了，這個問題當時可以重現(xiàn)(但是我不可能遇到問題就拉程序員來看吧)，后來卻沒有了，只能放在那里，最后關閉掉。第二個就是在一個界面中，錄入有順序要求，必須先選擇一個ListBox(必填)再進行Edit的錄入，但一次操作我沒有選擇 ListBox就錄入的Edit，也正常保存了。后來無論我怎么操作此問題都沒有出現(xiàn)(不夠成熟呀)，我就放棄了，也沒有提交記錄(為了避免麻煩)。
測試人員的時間是有限的，進度給的都很少，一般連用例都沒有時間寫，還要去花很多時間驗證“無法重現(xiàn)”的問題?反正10分鐘如果試驗不出來，我就會放棄。嚴重的就提交，不影響的就當不知道。
下面是其它一些人的觀點：
doublefalse(散諸懷抱)：如果不能重現(xiàn)的bug確實比較麻煩，但最好在測試過程中注意干凈環(huán)境、正確的操作、相同的數(shù)據(jù)源，只要真的有問題，一定能否復現(xiàn)的。呵呵，多試試!!!我們以前一直有客戶反映入庫的數(shù)據(jù)經(jīng)常有無關數(shù)據(jù)，但在家里測試沒有問題，后來才發(fā)現(xiàn)是漢字編碼錯位，這樣同樣的字，錯位后就變成另外的東西了。
liuxiaoyuzhou(蟀哥)：遇到過同樣的問題!主要是記住BUG出現(xiàn)的環(huán)境!測試的時候這是關鍵!在我們這里不能從現(xiàn)的BUG，是測試人員的工作不到位!我們這里程序員比測試人員說話有力度!郁悶呀!
ericzhangali(另一個空間)：首先一定要提交bug;其次不要企圖RD一定去解這個bug;某些時候還得關閉這個bug。如果RD認為是測試錯誤，(不明白什么叫測試錯誤，是不是說他從測時要告訴你千萬不要怎么怎么做，否則后果自負啊，)那也沒什么辦法，如果溝通解決不了，愛咋認為就咋認為吧。
darkcat_c(錯了重來)：沒有bug是不可以重現(xiàn)的，bug本事是建立在標準的規(guī)程上所出現(xiàn)的異常，如果你按test case步驟做的話不太可能出現(xiàn)此類bug。作為測試人員一定要具備良好的記憶能力，一旦出現(xiàn)一些不知如何產(chǎn)生的bug，至少你要知道剛才你大致進行了那些操作。良好的分析能力，盡管你只是測試，但你應該全面的了解程序的架構，和一些重要的內部細節(jié)，不然你這個測試就是不合格的。定位bug是開發(fā)的事情，而重現(xiàn)一個bug是測試的本職工作，不要把所有的事情推給開發(fā)，不然你的確比開發(fā)要低一等。(編者按：這種話，不愿意去辯駁，標準開發(fā)人員的看法，也許應該讓他們也來做做測試)
liyan_1014(雁子)：我覺得應該是這么處理：
1、一定提交bug，必須由負責bug的tester詳細描述測試操作步驟，bug發(fā)生的癥狀，并將bug發(fā)生的具體環(huán)境也描述清楚;這樣對于再次重現(xiàn)也有一定的參考性。
2、測試和開發(fā)之間是需要良好溝通的，如果得到的回復是操作錯誤，那么請開發(fā)人員解釋，為什么會允許存在操作錯誤，一般來說，對于錯誤控制，開發(fā)那邊應該能很好的把握。
3、溝通方面是需要方式的，開發(fā)人員對于自己完成的程序有一種滿足感，一般來說是不允許別人來破壞他的這種感覺，如果溝通的時候盡可能是一種建議的形式，讓開發(fā)人員自己指出自己的程序缺陷，這樣對于開發(fā)人員來說是可以接受。
33. 當我們認為某個地方是bug，但開發(fā)認為不是bug，怎么處理？
1.找到需求文檔或者是原型圖進行匹對
2.嘗試多種測試環(huán)境和多種測試方式來確認是否為bug
3.整理bug的復現(xiàn)的步驟和出現(xiàn)的頻率
4.開發(fā)堅持不認為是bug的時候找項目經(jīng)理測試經(jīng)理進行溝通來確認是否為bug
5.將客戶經(jīng)理 測試 測試經(jīng)理和項目經(jīng)理進行開確認會來判定是否為bug
6.測試人員需要將bug整理并寫入測試總結中
34. 產(chǎn)品在上線后用戶發(fā)現(xiàn)bug，這時測試人員應做哪些工作？
首先測試人員可以做的是重現(xiàn)這個問題并及時反饋給開發(fā)人員，找到解決方案進行修復。
如果問題只在線上才出現(xiàn)，測試環(huán)境重現(xiàn)不了，那么可能是版本或環(huán)境配置的問題；
如果問題不僅線上能重現(xiàn)，測試環(huán)境也存在，那么很有可能是測試人員在測試過程中未發(fā)現(xiàn)的Bug。
總之，項目組成員需要盡快修復Bug。
開發(fā)人員修復Bug之后，測試人員需要反思。
若是由于疏忽造成測試用例執(zhí)行遺漏，測試人員需要在下次執(zhí)行測試的過程中避免這樣的情況。
若是由于用例評審的不嚴格、中途需求變更或者某些其他因素造成的測試用例覆蓋不全，測試人員需要補全測試用例。
在測試過程中遇到未發(fā)現(xiàn)的Bug，測試人員不要自怨自艾，
也不要像沒回事兒一樣，需要正確對待“線上Bug”、汲取經(jīng)驗教訓、不斷提高測試能力。
測試人員需要不斷學習，不斷擴充，掌握測試工具、提升測試技能，從而設計出更全面的測試場景和測試用例。
35. 二八定理
80%的缺陷出現(xiàn)在20%的代碼中，體現(xiàn)了軟件缺陷群集現(xiàn)象
36. 如何跟蹤缺陷
在執(zhí)行用例的過程中發(fā)現(xiàn)了跟預期實際不符的情況，就提交缺陷,跟蹤缺陷修改，跟蹤缺陷流程主要有四個(一個正常的修改結束的流程，三個特殊處理流程)
新建 – 開啟 – 修改 – 關閉 提交缺陷后開發(fā)人員確認修改后回歸通過；
新建 – 拒絕 開發(fā)人員未確認缺陷拒絕修改，這個時候需要在確認需求理解正確(跟產(chǎn)品確認)和復現(xiàn)步驟(多次復現(xiàn))的基礎上, 跟開發(fā)人員溝通是否需要修改；
新建 – 開啟 – 修改 – 重開 修改后提交的版本回歸不通過，這是需要重新打開缺陷,為了加快缺陷正確修改，可以跟開發(fā)人員溝通，協(xié)助開發(fā)人員定位缺陷；
新建 – 開啟 – 延期 部分開啟的缺陷，由于無法復現(xiàn), 難以修改，進度壓力等原因,可能需要延期修改，這個時候，是否延期，是需要多方確認的(測試、產(chǎn)品、開發(fā)、領導)。
37. 缺陷的狀態(tài)
New（新的）：bug提交到缺陷庫中會自動的被設置成New狀態(tài)
**Assigned（已指派）：**當一個bug被認為New之后，將其分配開發(fā)人員，開發(fā)人員將確認這是否是一個bug，如果是，開發(fā)組的負責人就將這個bug指定給某位開發(fā)人員處理，并將bug的狀態(tài)設定為“Assigned”
Open（已打開）：開發(fā)人員開始處理bug時，他將這個bug的狀態(tài)設置為“Open”，表示開發(fā)人員正在處理這個“bug”
**Fixed（已修復）：**當開發(fā)人員進行處理（并認為已經(jīng)解決）之后，他（她）就可以將這個bug的狀態(tài)設置為“Fixed”并將其提交給開發(fā)組的負責人，然后開發(fā)組的負責人將這個bug返還給測試組
Rejected(被拒絕)：測試組的負責人接到上述bug的時候，如果他（她）發(fā)現(xiàn)這是產(chǎn)品說明書中定義的正常行為或者經(jīng)過與開發(fā)人員的討論之后認為這并不能算作bug的時候，開發(fā)組負責人就將這個bug的狀態(tài)設置為“Rejected”
**Postponed（延期）：**有些時候，對于一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發(fā)生，比如無效的測試數(shù)據(jù)，一些特殊的無效的功能等等，在這種情況下，bug的狀態(tài)就被設置為“Postponed”
Closed（已關閉）：測試人員經(jīng)過再次測試后確認bug已經(jīng)被解決，將bug的狀態(tài)設置為“Closed”
**Reopen（再次打開）：**如經(jīng)過再次測試發(fā)現(xiàn)bug仍然存在，測試人員將bug再次開發(fā)組，將bug的狀態(tài)設置為“Reopen”
38. 缺陷的等級
bug缺陷等級一般劃分為四個等級，致命、嚴重、一般、提示
? 致命（一級bug） **通常表現(xiàn)為:主流程無法跑通，系統(tǒng)無法運行，崩潰或嚴重資源不足，應用模塊無法啟動或異常退出，主要功能模塊無法使用。
比如：1.內存泄漏；2.嚴重的數(shù)值計算錯誤；3.系統(tǒng)容易崩潰；4.功能設計與需求嚴重不符；5.系統(tǒng)無法登陸；6.循壞報錯，無法正常退出。
? **嚴重（二級bug） **通常表現(xiàn)為：影響系統(tǒng)功能或操作，主要功能存在嚴重缺陷，但不會影響到系統(tǒng)穩(wěn)定性。
比如：1. 功能未實現(xiàn)；2.功能存在報錯；3.數(shù)值輕微的計算錯誤。
? 一般（三級bug）** 通常表現(xiàn)為：界面、性能缺陷。
比如：1.邊界條件下錯誤；2.容錯性不好；3.大數(shù)據(jù)下容易無響應；4.大數(shù)據(jù)操作時，沒有提供進度條。
? 提示（四級bug） 通常表現(xiàn)為：易用性及建議性問題
比如：1.界面顏色搭配不好；2.文字排列不整齊；3.出現(xiàn)錯別字，但是不影響功能；4.界面格式不規(guī)范。
39. 缺陷單應該包含這些要素
缺陷標題，缺陷描述，重現(xiàn)步驟，預期結果，實際結果，缺陷優(yōu)先級，缺陷嚴重程度，附件
40. 測試報告的主要內容
41. 如何定位bug：
1. 查看狀態(tài)碼2. 查看服務器日志3. 查看需求文檔4. F12（開發(fā)者工具）5. 前臺UI界面，我所提到的界面，包括界面的顯示，兼容性，數(shù)據(jù)提交的判斷以及頁面的跳轉等等，這些bug基本都是一眼可見的，不太需要定位。42. 開發(fā)沒時間修復，如何推進bug的修復：
導致開發(fā)不修改bug的因素
? 1、 開發(fā)與測試對bug的定義理解不一致產(chǎn)生的問題，例如暴力操作、非常規(guī)操作出現(xiàn)的問題、問題路徑深、服務器返回的數(shù)據(jù)不規(guī)范、競品同樣有的問題、個別機型問題等情況，開發(fā)可能會不愿意修改。
? 2、 工作流程方面的原因，例如開發(fā)有更高優(yōu)先級的任務沒有時間修改、上線時間緊急，來不及修改、開發(fā)不關注名下的bug、開發(fā)認為目前的實現(xiàn)比產(chǎn)品需求好等情況
? 3、 當然還有個人能力原因，例如找不到好的解決方案、影響范圍大、找不到bug原因，沒有解決方案、技術實現(xiàn)難，不知道怎么修改等等原因
? 4、 另外還有一些不可抗力的客觀因素，例如系統(tǒng)問題，第三方應用問題等等
? 開發(fā)不修改bug的原因有四：bug路徑較深、上線時間緊急、改動影響范圍大、第三方應用問題。解決方案
? 1、 針對路徑較深的bug，測試在推動開發(fā)修復bug時，需要注意以下幾點
? a) 從用戶的角度分析問題的嚴重性，分析用戶的遇到此問題的概率，引導開發(fā)站在用戶角度去思考，從而使開發(fā)意識到問題的嚴重性
? b) 可以和開發(fā)人員列舉一個之前的類似問題，為開發(fā)提供參考
? c) 產(chǎn)品是負責這個軟件的人員，當測試與開發(fā)意見無法達成一致時，不要因為無法推動開發(fā)修改而放棄，一定要找產(chǎn)品確認，最終的決定權交給產(chǎn)品人員。
? 2、 上線時間緊張，開發(fā)來不及修改了，這個時候測試應該分析問題的嚴重性，和產(chǎn)品人員商議是否需要修改
? 3、 修改bug改動較大，影響范圍廣，沒有最優(yōu)的解決方案等情況在項目即將上線的節(jié)點比較忌諱這種事情的發(fā)生。面對這種情況，建議開發(fā)人員做調研工作，請教其他的同事，或者組織一個臨時會議，集眾人之力研究好的修改方案
? 4、 第三方應用問題，開發(fā)無法修改。確認原因之后需要找相關的工作人員，例如產(chǎn)品，聯(lián)系第三方輸入法的工作人員，反饋問題，盡量推動應用解決問題
43. 軟件測試流程
在立項會中制定需求文檔，由UI設計原型圖，開發(fā)根據(jù)需求文檔進行編碼，我們測試會根據(jù)需求文檔進行編寫測試計劃，根據(jù)模塊的顆粒度劃分并編寫測試用例以及對用例的評審，開發(fā)結束后測試對主要功能進行冒煙測試，執(zhí)行測試用例，提交bug開發(fā)進行修改，修改成功后關閉bug，進行回歸測試，在上線前進行測試總結。
44. 項目介紹
45. 對一支圓珠筆進行測試，要從哪些方面進行測試？三角形測試用例設計
圓珠筆
三角形測試用例設計
（參考）
https://blog.csdn.net/junjunba2689/article/details/82587612
https://www.cnblogs.com/jpr-ok/p/6374742.html
1、構成三角形的條件：任意兩邊之和大于第三邊；
2、構成等腰三角形的條件：任意兩邊相等；
3、構成等腰直角三角形的條件：任意兩邊相等，而且兩條邊的平方和等于第三邊的平方和；
4、構成等邊三角形的條件：三條邊都相等。
一、等價類劃分：三角形三條邊A、B、C的數(shù)據(jù)類型不同
我們再分析一下三角形的等價類：
? 有效等價類：
? 輸入3個正整數(shù)或正小數(shù)：
? 1、兩數(shù)之和大于第三數(shù)，如A<B+C；B<C+A；C<A+B
? 2、兩數(shù)之和不大于第三數(shù)
? 3、兩數(shù)相等，如A=B或B=C或C=A
? 4、三數(shù)相等，如A=B=C
? 5、三數(shù)不相等，如A！=B，B！=C，C！=A
? 無效等價類：
? 1、空
? 2、負整數(shù)
? 3、非數(shù)字
? 4、少于三個數(shù)
? 等價類表：
? [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VrI2AoI6-1609163124810)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1609157470669.png)]
測試用例
? [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-mbBNcWyo-1609163124813)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1609157510149.png)]
46. 在項目中發(fā)現(xiàn)哪些經(jīng)典bug？什么原因導致的？
注冊信息中的錯誤提示信息：如手機信息欄應填入11位有效電話號碼，但提示信息卻為“13位電話號碼”，這是因開發(fā)人員粗心大意造成的
接口bug：傳的字段值為空，但是開發(fā)沒給默認值設個0導致接收不到數(shù)據(jù)
47. 一個項目完成時，有多個重要的缺陷沒有被修復，但是項目負責人說可以不修改，你認為測試是不通過的，請簡述你的理由。
1. 影響用戶體驗 2. 如果不修改，在上線時可能會引起其他bug發(fā)生 3. 如果在版本迭代在修改，時間久了對bug的認知就沒有現(xiàn)在清楚了 4. 拖得越久越難修復 5. 不符合需求產(chǎn)品需求48. 在需求文檔不太詳細的情況下，如何開展測試？
軟件生命周期中，需求是整個周期的源頭。良好的開端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企業(yè)中，并沒有對需求引起足夠的重視。原因并不是PM們不知道需求的重要性，而是商業(yè)競爭中不得不裁剪某些看似不能獲得很大利益的步驟。
什么是需求？很多PM和開發(fā)人員都未必真正考慮過這個問題。IEEE對需求有以下兩種定義的方式。
1. 解決用戶問題或達到用戶目標需要具備的條件或能力
2. 遵守合同、協(xié)議、規(guī)范或其他要求
然后用規(guī)范的文檔描述出來，就成了我們熟悉的SRS。
我們常說的需求，其實并不是我們認為的SRS。SRS應該叫做需求規(guī)格說明書。那需求是什么呢？與需求規(guī)格有什么區(qū)別？
需求：對要實現(xiàn)的功能的粗略描
需求規(guī)格：對需求的精確定義
我們知道，在軟件開發(fā)過程中，只有得知了需求的精確定義，才能開展工作。比如功能方面，編輯框能支持多少位字符。性能方面，時間和容量規(guī)定等。當然還包含其他非功能，性能方面的定義。
除了以上所說的需求，對于測試人員，還必須有測試需求。這個環(huán)節(jié)，很少有企業(yè)會重視。測試需求分為2方面：
需要測試哪些方面
軟件是否可測，需要增加哪些開發(fā)需求
其中第一條，很多企業(yè)都列到了測試計劃中，這也可以，沒有規(guī)定一定要放到哪個文檔里。但是對于第二條，可以說幾乎沒有多少企業(yè)去做。
接下來，在沒有明確需求，需求規(guī)格，測試需求的情況下，我們怎么去做測試呢？現(xiàn)在很多企業(yè)，其實就是在這種情況下做項目的。
當測試人員接手一個項目后，第一件事情一定是想了解這個系統(tǒng)的功能，背景，架構。于是，馬上就會想得到需求文檔。但結果往往是失望的，根本沒有文檔，或者文檔根本不具備參考價值。此時不必太失望，因為這種情況實在是太常見啦。這時，請試著從以下幾個步驟著手。
查閱文檔：文檔是最具權威的，也是記憶最長久的。有時，我們的項目可能是在原有產(chǎn)品的基礎上，進行版本升級。這時，先去找找，有沒有原有版本留下的需求，或者是用戶手冊等文檔。從這些文檔中，了解項目的背景，系統(tǒng)的基本功能。這對了解新項目是有很大好處的。并且，在產(chǎn)品升級的項目中，驗證老版本的功能在新版本中是否正常，也是一個必要的工作。可以先參考老版本的相關文檔，設計新版本中的用例。
也有時，我們的項目是一個行業(yè)項目，比如金融項目。我們可以參
考一些行業(yè)知識的書籍，文檔。這對理解系統(tǒng)也有很大的好處。
實在沒有文檔，那只好暫時跳過這一步驟了。
在進入下一步驟之前，你可能得到了一些相關文檔，也可能什么也沒得到。無論如何，你可能對系統(tǒng)已經(jīng)有了一些了解。這時，請記錄下來，寫成文檔。無論是對自己，還是對別人，在以后都可能極有參考價值。試想一下，如果前人已經(jīng)給你留下了這些文檔，你是否可以輕松很多？還要注意及時更新你的文檔。因為你對系統(tǒng)的理解，隨時都在變化著，一定要保證你的文檔和當前你對系統(tǒng)的理解是一致的。
試著使用系統(tǒng)，根據(jù)經(jīng)驗和常識猜測：既然沒有需求，那可以推測，該項目的管理一定是很糟糕的，對測試也不會投入很大的成本。因此，測試人員一般都是在編碼完成后才進入項目。這時，應該已經(jīng)可以看到成型的系統(tǒng)了。在沒有需求的情況下，試著先“玩”一下系統(tǒng)吧。在這過程中，你應該對系統(tǒng)有可更深入的認識，在上一階段中，你可能留下很多疑惑或是猜測，這時應該能排除一部分了。
使用系統(tǒng)的同時，你應該具備行業(yè)知識。系統(tǒng)可能是針對某個專業(yè)領域設計的。例如一個期貨交易系統(tǒng)。你沒有基本的期貨知識，比如什么是持倉，什么是平倉。那么你如何能真正理解這個系統(tǒng)呢？當你有了業(yè)務知識以后，你會進行更深入的思考，來全面測試系統(tǒng)。
你還需要具備良好的軟件知識。比如某些控件的特性。單選框只能單選，不能多選。日歷控件是否可以手工輸入非法格式等。這些都是應具備的意識。
最后加上你的主觀判斷，你對系統(tǒng)的整體感覺怎么樣？是否越用越厭煩，為什么厭煩。系統(tǒng)的反應速度是否可以容忍，細節(jié)處理是否圓滑，等等。
在你認識系統(tǒng)的時候，可以使用一些方法，來幫助你更有效率地學習。比如可以畫一些流程圖。一圖勝萬語。同時，你也留下寶貴的文檔。當然，這個步驟中，你也要隨時注意保留和更新文檔，以備后用。
溝通：需求規(guī)格不一定非要以文檔的形式表現(xiàn)出來。軟件既然能做出來，那肯定是有需求的。而最清除需求的，一定是軟件的直接制造者，開發(fā)人員。開發(fā)人員自己知道需求，但一般不會主動和測試人員溝通。因此，測試一定要主動和開發(fā)人員溝通。可以安排會議，讓開發(fā)人員給測試人員介紹系統(tǒng)，并演示系統(tǒng)。讓測試人員對系統(tǒng)有一個整體了解。然后測試人員能進行更細致的測試。在進行細致測試的時候，一定會有更多不明確的地方。這時就需要利用自己的行業(yè)知識，計算機知識等，猜測一
部分。不需要每個細節(jié)都去詢問開發(fā)人員。因為開發(fā)人員也有自己的工作，他們不希望花太多時間來給你解釋。
有些項目中，客戶會直接參與到項目組來。這時，測試人員在權限允許的情況下，可以和客戶進行溝通。客戶那得來的需求，是最原始的需求。但是，客戶未必有良好的表達能力來描述希望的功能，也未必有計算機知識，因此不能描述出一些隱式的需求。在被允許的情況下，測試人員可以和客戶進行交流，不僅可以幫助客戶正確描述出真實需求，測試人員也能詳細了解需求。但是項目是要考慮成本的，客戶的期望是無限制的。在客戶提出需求以后，測試人員要先和PM或其他相關負責人協(xié)商后，才能將與客戶交流得來的需求，作為測試的依據(jù)。同事，第一時間告知相關開發(fā)人員最新的信息，也記錄成文檔。這時，你就將非文檔形式的需求，轉換為文檔形式了。至于文檔的格式，不一定要按照標準SRS的格式。因為它本身就不是個規(guī)范的SRS。以任何容易理解的方式，組織你的文檔。
有時候，會根本找不到可以溝通的人。不要奇怪，確實就是有這種時候。比如：
1. 測試一個開源軟件
2. 接到一個測試外包，但又沒有得到相關文檔，為了追求利益，還是接下了
3. 軟件項目組的部分人員已經(jīng)聯(lián)系不上等等
這時候，一方面需要PM協(xié)調獲取相關資料，聯(lián)絡相關人員。另一方面，測試人員也可組織頭腦風暴，利用集體的智慧，共同探討和猜測軟件中的各個環(huán)節(jié)。也可以安排Bug Bash，讓盡可能多的人員參與隨機測試。一定會有人提出具有創(chuàng)造性的意見的。
在進行以上步驟的時候，利用良好的工具，能讓你事半功倍。我經(jīng)常在使用的一個工具，就是Mindjet MindManager。這是一個很好的，幫助擴展思維的工具。它以分支的形式，來表現(xiàn)你的思維層次。你可以先列出個最基本的系統(tǒng)整體結構，然后逐步細化，增加分支。不要急于一次就將真?zhèn)€系統(tǒng)分析透徹，這是不可能的。你在進行以上步驟的時候，隨時會細化這個結構。當項目結束后，看看這個結構圖，簡直可以當作SRS來參考。
49. 如何盡快找到軟件中的bug?
1、盡快熟悉公司的產(chǎn)品業(yè)務，根據(jù)產(chǎn)品的業(yè)務屬性來熟悉產(chǎn)品的業(yè)務流程，這樣才能迅速找出軟件中存在的一些重要的缺陷，這樣發(fā)現(xiàn)的軟件的價值才是有價值的，否則即使你能找到一些軟件缺陷，那也是純軟件的缺陷，價值不大。
2、把自己當成是用戶，把自己當成用戶去使用該軟件，比如在試用軟件的過程中，思考用戶是這樣操作的么
3、善于懷疑 ，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發(fā)生的事，我卻認為可能發(fā)生；別人認為是對的，我卻認為是錯的。假如一個水平很高的程序員編寫的程序，不要有“他寫的這個程序應該沒有問題吧”這種想法，這樣很容以遺漏軟件中的Bug。
4、不用讓程序開發(fā)員“用戶不會這樣操作”的觀點說服自己，遇到這樣的情況，你要堅持自己的正確的觀點，把這種現(xiàn)象作為一個Bug。
5、在測試的過程中要跟蹤一條數(shù)據(jù)的完整流程，比如“點擊商品—收藏商品—加入購物車—訂單結算—付款—消費二維碼—消費—二維碼失效”，如果在測試軟件過程中業(yè)務流程邏輯都走不通的話，還么這個軟件測試與不測試就沒有什么區(qū)別的。
**6、在測試的過程中要跟蹤一條數(shù)據(jù)的完整程，**要注意的事項 ，程序員提交新的版本后，作為測試人員應該立即與程序員溝通這個修改的功能，并了解這個新修改的功能影響那些功能。而被影響的功能，是在回歸測試中優(yōu)先重點測試的地方，而且也是最容易產(chǎn)生Bug的地方。
7、軟件的邊界值 ，眾所周知軟件最容易在邊界值上出現(xiàn)問題，所以作為測試人員一定要在邊界值上多測試，比如測試用戶輸入框中的數(shù)值的最大數(shù)和最小數(shù)，以及為空的情況；
8、非法容錯性，比如在需要輸入數(shù)字的地方輸入字母，在需要輸入字母的地方輸入數(shù)字，在需要用戶輸入的文本框中拷貝字數(shù)很多的整編文章到這里測試看看軟件是如何做處理的；
9、學習他人經(jīng)驗：三人行必有我?guī)熝?#xff0c;人外有人，天外有天。
50. 什么是bug？
-
當且僅當規(guī)格說明是存在的并且正確，程序與規(guī)格說明之間的不匹配才是錯誤。
-
當沒有需求規(guī)格說明書時，判斷標準以最終用戶為準：當程序沒有實現(xiàn)其最終用戶合理預期的功能要求時，就是軟件錯誤。
-
和預期不一致的軟件行為。
一個軟件行為既可能是bug也可能不是bug，那是因為預期的主體千姿百態(tài)。
和測試員預期不一致的軟件行為。
和程序員預期不一致的軟件行為。
和文檔預期不一致的軟件行為。
和管理者預期不一致的軟件行為。
和客戶預期不一致的軟件行為。
51. ATM機吞卡的吞卡現(xiàn)象是不是BUG?
1.由于保護機制，你一次取錢數(shù)額有限，需要多次操作的時候每次現(xiàn)出卡你會覺得麻煩無比。
2.吞卡當然是為了安全，這沒有什么爭論吧。
3.至今從沒見過吞了的卡還能吐出來的，根據(jù)后邊ATM機的構造，也不可能再退出來，是直接掉在一個小盒子里的。
4.不可能你隨時去取吞卡別人就給你取，首先ATM必須雙人操作才能進，第二營業(yè)廳也必須雙人在場，不能一人在營業(yè)廳，所以一般都是加鈔的時候順便取出來。
5.現(xiàn)在在任何地方應該都不會有不核實情況直接給人吞卡的，外行卡除外，外行卡被吞，本行毫無辦法核實任何信息，只能讓你出示身份證信息并登記，確保是被你這個人取走的。
52. 如何減少非問題單的提交？
熟悉項目需求，充分了解各個各個功能模塊的功能、參數(shù)、約束條件，弄清存在數(shù)據(jù)交互的模塊之間的數(shù)據(jù)來源、數(shù)據(jù)流向；
53. 有個程序，在windows上運行很慢，怎么判斷是程序存在問題，還是軟硬件系統(tǒng)存在問題？
同類型軟件在你的操作系統(tǒng)硬件環(huán)境上運行，如果一慢一塊，則是軟件問題
同一軟件在別人的操作系統(tǒng)上，如果運行速度加快，則是你的操作系統(tǒng)或硬件的問題
54. 你們發(fā)現(xiàn)bug會怎么處理。
首先要做的是重現(xiàn)這個問題并反饋給研發(fā)人員，盡快出patch或者解決方案。
當BUG解決且上線沒有問題之后，我們再看后續(xù)的處理。
追查原因及處理方法：這個BUG出現(xiàn)的原因是什么。這有分為幾種情況：
1）測試環(huán)境無法重現(xiàn)：可能是線上的環(huán)境造成的BUG或者是測試環(huán)境無法模擬的 情況。
解決方法：盡量完善測試方法、盡量模擬測試環(huán)境、增加線上測試。2）漏測：
a.測試用例裁剪過度：錯誤預估優(yōu)先級或者時間過于緊迫裁剪了用例解決方法：在后續(xù)版本或者其他項目啟動時重新評估測試時間，要求專家介入對優(yōu)先級進行評估，避免此類事件再次發(fā)生。b.測試用例執(zhí)行期間遺漏：由于測試人員疏忽造成測試用例執(zhí)行遺漏。解決方法：調查該名測試人員的整個測試過程的工作情況，并隨機抽測其他模塊，對該名測試人員進行綜合評估，給出結論，是因為偷懶漏測，還是因為負責模塊過多漏測，還是有其他原因 ，對該名測試人員發(fā)出警告，對相關測試主 管，項目經(jīng)理，產(chǎn)品經(jīng)理發(fā)出警告。c.測試用例覆蓋不全：由于用例評審的不嚴格造成的；中途需求變更造成的；由于某些其他因素造成的。解決方法：找到原因，并進行記錄，在以后的項目或者下一版本重點關注。最最重要的：補測試用例！
總結
- 上一篇： 计算机硬件个人总结,计算机硬件课程设计个
- 下一篇： 从0 到1开发一款App（三）：设计