軟件測試面試的題目

1、面試題一、您以為做好測試用例設計工作的關鍵是什么？參考答案：測試用例應百分百覆蓋需求。白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果。 黑盒法用例設計的關鍵一樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時刻內發(fā)覺最多的問題。二、您所熟悉的測試用例設計方式都有哪些？請別離以具體的例子來講明這些方式在測試用例設計工作中的應用。參考答案：1等價類劃分劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)關于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,能夠把全數(shù)輸入數(shù)據(jù)合理劃分

2、為假設干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就能夠夠用少量代表性的測試數(shù)據(jù).取得較好的測試結果.等價類劃分可有兩種不同的情形:有效等價類和無效等價類.2邊界值分析法邊界值分析方式是對等價類劃分方式的補充。測試工作體會告知我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內部.因此針對各類邊界情形設計測試用例,能夠查出更多的錯誤.利用邊界值分析方式設計測試用例,第一應確信邊界情形.通常輸入和輸出等價類的邊界,確實是應著重測試的邊界情形.應被選取正好等于,方才大于或方才小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).參考答案：3錯誤

3、推測法基于體會和直覺推測程序中所有可能存在的各類錯誤, 從而有針對性的設計測試用例的方式.錯誤推測方式的大體思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情形,依照他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發(fā)覺的錯誤等, 這些確實是體會的總結. 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情形. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情形. 可選擇這些情形下的例子作為測試用例.4因果圖方式前面介紹的等價類劃分方式和邊界值分析方式,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 彼此組合等. 考慮輸入條件之間的彼此組合,可能

4、會產生一些新的情形. 但要檢查輸入條件的組合不是一件容易的情形, 即便把所有輸入條件劃分成等價類,他們之間的組合情形也相當多. 因此必需考慮采納一種適合于描述關于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方式最終生成的確實是判定表. 它適合于檢查程序輸入條件的各類組合情形.4、什么是并發(fā)？在lordrunner中，如何進行并發(fā)的測試？集合點失敗了會怎么樣？參考答案：在同一時刻點，支持多個不同的操作。LoadRunner中提供IP假裝，集合點，配合虛擬用戶的設計，和在多臺電腦上設置，能夠比較好的模擬真實的并發(fā)。集合點，即是多個用戶在某個時

5、刻，某個特定的環(huán)境下同時進行虛擬用戶的操作的。集合點失敗，那么集合點的才操作就會取消，（五）寫出bug報告當中一些必備的內容。參考答案：硬件平臺和操作系統(tǒng)測試應用的硬件平臺（Platform），通常選擇“PC”。測試應用的操作系統(tǒng)平臺（OS）。a) 版本提交缺點報告時通過該字段標識此缺點存在于被測試軟件的哪個版本。b) Bug報告優(yōu)先級c) Bug狀態(tài)d) Bug的編號e) 發(fā)現(xiàn)人f) 提交人g) 指定處理人h) 概述i) 從屬關系j) 詳細描述k) 嚴重程度l) 所屬模塊m) 附件n) 提交日期（六）簡述一下缺點的生命周期？參考答案：發(fā)覺-提交-確認-分派-修復-驗證-關閉7、（1）發(fā)覺錯誤

6、是軟件測試的目的（） （2）白盒測試能夠找出軟件遺漏功能和代碼錯誤功能。（）（3）在設計測試用例時，應包括合理的應用條件和不合理的應用條件。 （）（4）軟件缺點必然是由編碼引發(fā)的錯誤。 （） （5）文檔測試是對系統(tǒng)提交給用戶的文檔進行驗證，并非是一樣性的審查活動。（）參考答案：錯錯對錯對（八）如何編寫提交給用戶的測試報告？參考答案：隨著測試工作愈來愈受重視，開發(fā)團隊向客戶提供測試文檔是不可幸免的情形。很多人會問：“咱們能夠把工作中的測試報告提供給客戶嗎？”答案是不是定的。因為提供內部測試報告，可能會讓客戶失去信心，乃至否定項目。測試報告一樣分為內部測試報告和外部測試報告。內部報告是咱們在測試工

7、作中的項目文檔，反映了測試工作的實施情形，那個地址只是量討論，讀者能夠參考相關教材。那個地址要緊討論一下外部測試報告的寫法，一樣外部測試報告要知足下面幾個要求：-依照內部測試報告進行編寫，一樣能夠摘錄；-不能夠向客戶報告嚴峻缺點，即便是已經修改的缺點，開發(fā)中的缺點也沒有必要讓客戶明白；-報告上能夠列出一些缺點，但必需是中級的缺點，而且這些缺點必需是修復的；-報告上面的內容盡可能要真實靠得住；-整個測試報告要認真審閱，力爭不給項目帶來負面作用，尤其是性能測試報告?？傊?，外部測試報告要警惕謹慎的編寫。（九）測試產品與測試項目的區(qū)別是什么？適應上把開發(fā)完成后進行商業(yè)化、幾乎不進行代碼修改就能夠夠售給

8、用戶利用的軟件成為軟件產品，也確實是能夠買“賣拷貝”的軟件，例如Windows2000。而通常把針對一個或幾個特定的用戶而開發(fā)的軟件成為軟件項目，軟件項目是一種個性化的產品，能夠是依照用戶要求全數(shù)從頭開發(fā)，也能夠修改已有的軟件產品來知足特定的用戶需求。項目和產品的不同特點，決定咱們測試產品和測試項目仍然會有很多不同的地址：-質量要求不同。通常產品的質量要高一些，修復發(fā)布后產品的缺點本錢較高，乃至會帶來很多負面的阻礙。而做項目通常面向某一用戶，盡管質量越高越好，可是一樣只要知足用戶要求就能夠夠了。-測試資源投入多少不同。做軟件產品一般是研發(fā)中心來開發(fā)，進度壓力要小些。同時由于質量要求高，因此會投

9、入較多的人力、物力資源。-項目最后要和用戶一起驗收測試，這是產品測試不具有的特點。另外，測試產品與測試項目在缺點治理方面、測試策略制定都會有專門大不同，測試治理者應該結合具體的環(huán)境，恰如其分的完成工作。（十）沒有產品說明書和需求文檔地情形下能夠進行黑盒測試嗎？參考答案：那個問題是國內測試工程師常常碰到的問題，本源確實是國內軟件開發(fā)文檔治理不標準，對變更的治理方式就更不合理了。事實上沒有任何文檔的時候，測試人員是能夠進行黑盒測試的，這種測試方式咱們能夠稱之為探討測試，具體做法確實是測試工程師依照自己的專業(yè)技術、領域知識等不斷的深切了解測試對象、明白得軟件功能，進而發(fā)覺缺點。在這種做法大體上把軟件

10、當做了產品說明書，測試進程中要和開發(fā)人員不斷的進行交流。尤其在作項目的時候，進度壓力比較大，能夠作為加急測試方案。最大的風險是不明白有些特性是不是被遺漏（11）在測試一個web頁面時，頁面顯示為空白頁，如何定位問題所在？可能是哪些緣故引發(fā)的？參考答案：一、本身頁面代碼確實是空白的。閱讀器按F12查看2，本地無網(wǎng)絡，閱讀器是不是緩存是不是為空白頁3，發(fā)送超時，接收超時，效勞器超時。4，域名錯誤，ip解析不了。（12）軟件的評審一樣由哪些人參加？其目的是什么？參考答案：在正式的會議上將軟件項目的功效（包括各時期的文檔、產生的代碼等）提交給用戶、客戶或有關部門人員對軟件產品進行評審和批準。其目的是找

11、出可能阻礙軟件產品質量、開發(fā)進程、保護工作的適用性和環(huán)境方面的設計缺點，并采取補救方法，和找出在性能、平安性和經濟方面的可能的改良。 人員：用戶、客戶或有關部門開發(fā)人員，測試人員，需求分析師都能夠，就看處于評審那個時期（13）描述測試用例設計的完整進程？參考答案：需求分析 需求變更的保護工作；依照需求 得出測試需求；設計測試方案，評審測試方案；方案評審通事后，設計測試用例，再對測試用例進行評審；（14）面試官問用安卓系統(tǒng)和ios系統(tǒng)進行軟件測試，會有哪些不同1 . Android長按home鍵呼出應用列表和切換應用，然后右滑那么終止應用；2. 多分辨率測試，Android端20多種，ios較少

12、；3. 電話操作系統(tǒng)，Android較多，ios較少且不能降級，只能單向升級；新的ios系統(tǒng)中的資源庫不能完全兼容低版本中的ios系統(tǒng)中的應用，低版本ios系統(tǒng)中的應用挪用了新的資源庫，會直接致使閃退（Crash）；4. 操作適應：Android，Back鍵是不是被重寫，測試點擊Back鍵后的反饋是不是正確；應用數(shù)據(jù)從內存移動到SD卡后可否正常運行等；5. push測試：Android：點擊home鍵，程序后臺運行時，現(xiàn)在接收到push，點擊后喚醒應用，現(xiàn)在是不是能夠正確跳轉；ios，點擊home鍵關閉程序和屏幕鎖屏的情形（紅點的顯示）；6. 安裝卸載測試：Android的下載和安裝的平臺和工

13、具和渠道比較多，ios要緊有app store，iTunes和testflight下載；7. 升級測試：能夠被升級的必要條件：新舊版本具有相同的簽名；新舊版本具有相同的包名；有一個標示符區(qū)分新舊版本（如版本號），關于Android假設有內置的應用需檢查升級以后內置文件是不是匹配（如內置的輸入法）（15）LoadRunner分哪三部份？參考答案：用戶動作設計；場景設計；測試數(shù)據(jù)分析；（16）數(shù)據(jù)庫內聯(lián)接和外連接，自聯(lián)接有什么區(qū)別？參考答案：內聯(lián)接一般是2個表存在主外鍵關系時利用的，內聯(lián)接查詢有2種方式實現(xiàn)，1是在WHERE 子句中指定聯(lián)接條件2是在FROM子句中利用join.on內聯(lián)接查詢通常不

14、單單聯(lián)接2表，能夠3表乃至更多的表參與內聯(lián)接的表的地位是平等的而外聯(lián)接中參與聯(lián)接的表有主從之分。以主表的每行數(shù)據(jù)去匹配從表的數(shù)據(jù)列，符合條件的數(shù)據(jù)將直接返回到結果集中，不符合的用NULL（空值）填充后再返回到結果集中（17）測試打算工作的目的是什么？測試打算工作的內容都包括什么？其中哪些是最重要的？參考答案：軟件測試打算是指導測試進程的綱領性文件，包括了產品概述、測試策略、測試方式、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試打算，參與測試的項目成員，尤其是測試治理人員，能夠明確測試任務和測試方式，維持測試實施進程的順暢溝通，跟蹤和操縱測試進度，應付測試進程中

15、的各類變更。測試打算和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試打算要緊從宏觀上計劃測試活動的范圍、方式和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。因此其中最重要的是測試測試策略和測試方式（最好是能先評審）（18）當開發(fā)人員說不是BUG時，你如何應付？參考答案：開發(fā)人員說不是bug，有2種情形，一是需求沒有確信，因此我能夠這么做，那個時候能夠找來產品領導進行確認，需不需要改動，3方商量確信好后再看要不要改。二是這種情形不可能發(fā)生，因此不需要修改，那個時候，我能夠先盡可能的說出是BUG的依據(jù)是什么？若是被用戶發(fā)覺或出了問題，會有什么不良結果？程序員可能會給你很多理由，你

16、能夠對他的說明進行反對。若是仍是不行，那我能夠給那個問題提出來,跟開發(fā)領導和測試領導進行確認,若是要修改就改,若是不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，若是開發(fā)人員不修改也沒有大問題。若是確信是bug的話，必然要堅持自己的立場，讓問題取得最后的確認。（19）若是一個bug只顯現(xiàn)一次，該怎么處置？（1）bug顯現(xiàn)的同時當即截圖留下異樣的畫面（2）利用相同的環(huán)境、設備、測試步驟、方式，利用相同的輸入數(shù)據(jù)，看可否重 （3）不能重現(xiàn)，那么告知項目領導發(fā)覺bug的進程，分析優(yōu)先級，討論解決方案（20）軟件測試的缺點品級如何劃分？參考答案：A類嚴峻錯誤，包括以下各類錯誤：1

17、 由于程序所引發(fā)的死機,非法退出2 死循環(huán)3 數(shù)據(jù)庫發(fā)生死鎖4 因錯誤操作致使的程序中斷5 與數(shù)據(jù)庫連接錯誤6 數(shù)據(jù)通信錯誤B類較嚴峻錯誤，包括以下各類錯誤：1.程序接口錯誤2.系統(tǒng)可被執(zhí)行，但操作功能無法執(zhí)行（含指令）3.單項操作功能可被執(zhí)行，但在此功能中某些小功能（含指令參數(shù)的利用）無法被執(zhí)行（對系統(tǒng)非致命的）4.在小功能項的某些項目（選項）利用無效（對系統(tǒng)非致命的）5.業(yè)務流程不正確6.功能實現(xiàn)不完整，如刪除時沒有考慮數(shù)據(jù)關聯(lián)7.功能的實現(xiàn)不正確，如在系統(tǒng)實現(xiàn)的界面上，一些可同意輸入的控件點擊后無作用；對數(shù)據(jù)庫的操作不能正確實現(xiàn)；8.報表格式和打印內容錯誤（行列不完整，數(shù)據(jù)顯示不在所對應

18、的行列等致使數(shù)據(jù)顯示結果不正確的錯誤）C類一樣性錯誤，包括以下各類錯誤：1.操作界面錯誤（包括數(shù)據(jù)窗口內列名概念、含義是不是一致）2.打印內容、格式錯誤（只阻礙報表的格式或外觀，不阻礙數(shù)據(jù)顯示結果的錯誤）3.簡單的輸入限制未放在前臺進行操縱4.刪除操作未給出提示5.已被捕捉的系統(tǒng)崩潰，不阻礙繼續(xù)操作6.盡管正確性不受阻礙，但系統(tǒng)性能和響應時刻受到阻礙7.不能定位核心或定位有誤，阻礙功能實現(xiàn)8.顯示不正確但輸出正確9.增刪改功能，在本界面不能實現(xiàn)，但在另一界面能夠補充實現(xiàn)。D類較小錯誤，包括以下各類錯誤：1.界面不標準2.輔助說明描述不清楚3.輸入輸出不標準4.長時刻操作未給用戶提示5.提示窗口

19、文字未采納行業(yè)術語6.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志7.必填項與非必填項應加以區(qū)別8.轉動條無效9.鍵盤支持不行，如在可輸入多行的字段中，不支持回車換行；或對相同字段，在不同界面支持不同的快捷方式10.界面不能及時刷新，阻礙功能實現(xiàn)（21）軟件的平安性應從哪幾個方面去測試？(1)用戶認證機制：如數(shù)據(jù)證書、智能卡、雙重認證、平安電子交易協(xié)議(2)加密機制(3)平安防護策略：如平安日記、入侵檢測、隔離防護、漏洞掃描(4)數(shù)據(jù)備份與恢復手腕：存儲設備、存儲優(yōu)化、存儲愛惜、存儲治理(5)防病毒系統(tǒng)E類其他錯誤1.光標跳轉設置不行，鼠標（光標）定位錯誤2.一些建議性問題（22）邏輯題，一個是一個

20、6L水的水壺，一個5L水的水壺，隔壁有一個水池，如何用這兩個水壺，倒出3L水6L壺裝滿水，倒進5L壺里，6L壺里剩下1L水，倒掉5L壺里的水，把6L壺里剩下的水倒進5L壺里再把6L壺裝滿，倒水進5L壺，6L壺里剩下2L的水，倒掉5L壺里水，把6L壺里的水倒進5L壺里再次裝滿6L壺，倒水進5L壺，現(xiàn)在6L壺里剩下的水為3L。(23)想象一個登錄框，包括ID、密碼、登錄、取消，記住密碼（復選框），盡可能的寫出你想到的測試點？參看答案：ID測試要點：字符類型（包括：數(shù)字、字母、漢字、特殊字符）字符長度默許值空值字符集存在空格復制、粘貼密碼測試要點：密碼長度（例如：密碼不能少于7個字符，最長不能超過2

21、0個字符） 密碼復雜度、強度（例如：密碼必需包括特殊字符、數(shù)字字母大小寫等等，長度是不是長）密碼字符類型（例如：只許諾輸入數(shù)字、字母、特殊字符、下劃線）默許值密碼為空字符集存在空格復制、粘貼登錄測試要點 用戶名和密碼都符合要求（格式上的要求） 用戶名和密碼都不符合要求（格式上的要求） 用戶名符合要求，密碼不符合要求（格式上的要求） 密碼符合要求，用戶名不符合要求（格式上的要求） 用戶名或密碼為空 數(shù)據(jù)庫中不存在的用戶名，不存在的密碼 數(shù)據(jù)庫中存在的用戶名，錯誤的密碼 數(shù)據(jù)庫中不存在的用戶名，存在的密碼 輸入的數(shù)據(jù)前存在空格 輸入正確的用戶名密碼以后按enter是不是能登岸取消鼠標左鍵點擊“取消

22、”按鈕鼠標左鍵雙擊“取消”按鈕鼠標右鍵點擊“取消”按鈕鼠標右鍵雙擊“取消”按鈕鼠標指針移動到“取消”按鈕”，按回車鍵 鼠標指針停留在“取消”按鈕上記住密碼（復選框）點擊選中“記住密碼”按鈕，從頭登錄不選中“記住密碼”按鈕，從頭輸入密碼登錄輸入已存在ID和錯誤密碼，勾選“記住密碼”，點擊登錄 輸入錯誤ID和正確密碼，勾選“記住密碼”，點擊登錄 輸入正確ID和正確密碼，勾選“記住密碼”，點擊登錄 輸入錯誤ID和錯誤密碼，勾選“記住密碼”，點擊登錄.（23）訪問一個完整http請求會經歷哪些問題參考答案：1.域名解析2.發(fā)起TCP的3次握手3.成立TCP連接后發(fā)起http請求4.效勞器端響應http

23、請求，閱讀器取得html代碼5.閱讀器解析html代碼，并請求html代碼中的資源6.閱讀器對頁面進行渲染呈現(xiàn)給用戶。（24）https和http請求的區(qū)別？https協(xié)議需要到ca申請證書，一樣免費證書較少，因此需要必然費用。http是超文本傳輸協(xié)議，信息是明文傳輸，https那么是具有平安性的ssl加密傳輸協(xié)議。http和https利用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議25：http有哪些請求方式，get和post請求有什么區(qū)別參

24、看答案：get傳輸數(shù)據(jù)是通過URL請求，以field（字段）= value的形式，置于URL后，并用?連接，多個請求數(shù)據(jù)間用&連接，如&password=admin，那個進程用戶是可見的；post傳輸數(shù)據(jù)通過Http的post機制，將字段與對應值封存在請求實體中發(fā)送給效勞器，那個進程對用戶是不可見的；Get傳輸?shù)臄?shù)據(jù)量小，因為受URL長度限制，但效率較高，Post能夠傳輸大量數(shù)據(jù)，因此上傳文件時只能用Post方式；post較get平安性較高，get是不平安的，因為URL是可見的，可能會泄露私密信息，如密碼等.get方式只能支持ASCII字符，向效勞器傳的中文字符可能會亂碼，post支持標準字符

25、集，能夠正確傳遞中文字符。（26）cookie與session區(qū)別參考答案：cookie數(shù)據(jù)寄存在客戶的閱讀器上，session數(shù)據(jù)放在效勞器上；cookie不是很平安，他人能夠分析寄存在本地的COOKIE并進行COOKIE欺騙，考慮到平安應當利用session；session會在一按時刻內保留在效勞器上。當訪問增多，會比較占用你效勞器的性能。考慮到減輕效勞器性能方面，應當利用COOKIE；單個cookie在客戶端的限制是3K，確實是說一個站點在客戶端寄存的COOKIE不能超過3K；Cookie和Session的方案盡管別離屬于客戶端和效勞端，可是效勞端的session的實現(xiàn)對客戶端的cookie有依托關系的，上面我講到效勞端執(zhí)行ses