軟件測試公司面試題+概念等

1、黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：1） 是否有不正確或遺漏的功能？2） 在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？3） 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？4） 性能上是否能夠滿足要求？5） 是否有初始化或終止性錯誤？軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進(jìn)行如下檢查：1） 對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。2） 對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。3） 在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體。4） 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。?單元測試的主要目的是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗證過程中的邊界值的錯誤。?集成測試主要目的是針對詳細(xì)設(shè)計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。系統(tǒng)測試主要針對概要設(shè)計，檢查了系統(tǒng)作為一個整體是否有效地得到運行，例如在產(chǎn)品設(shè)置中是否達(dá)到了預(yù)期的高性能驗收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要（需求）。2、您認(rèn)為做好測試計劃工作的關(guān)鍵是什么？1） 明確測試的目標(biāo)，增強(qiáng)測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確2） 堅持“5W”規(guī)則，明確內(nèi)容與過程“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團(tuán)隊理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。3） 采用評審和更新機(jī)制，保證測試計劃滿足實際需求測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊，測試計劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導(dǎo)測試執(zhí)行人員。4） 分別創(chuàng)建測試計劃與測試詳細(xì)規(guī)格、測試用例應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。3、你認(rèn)為公司的BUG測試流程是什么？1） 當(dāng)測試工程師發(fā)現(xiàn)了一個bug而且在bugtrackingtool里面沒有相同的bug，他需要填寫所有需要的bug信息并且把這個bug分配給testleader2） 如果這個bug不是一個真正的bug,testleader需要close這個bug3） testleader需要審查bug的各種信息都完備，如果有信息不完整，他需要把狀態(tài)改成"feedback"并重新assign給提交者4） 如果這個bug是一個真正存在的bug,testleader需要把這個bug分配給相關(guān)的開發(fā)團(tuán)隊的PM,并且把bug狀態(tài)改成Assigned5） 如果這個bug屬于另外一個開發(fā)團(tuán)隊，PM需要把這個bug重新分配給那個開發(fā)團(tuán)隊的PM6） PM審查bug，并且分配給相應(yīng)的開發(fā)人員去改正。7） 開發(fā)人員收到bug以后，對相關(guān)的缺陷進(jìn)行改正，并且重新分配給提交bug的測試人員并且把狀態(tài)改成"Fixed”8） 測試人員需要對這個bug進(jìn)行重新測試，保證相關(guān)的缺陷已經(jīng)改正，測試人員可以reopen這個bug如果缺陷依然存在并且重新分配給相關(guān)的開發(fā)人員或者close這個bug如果缺陷已經(jīng)改正。4、測試人員所應(yīng)具備的知識1）基本的測試知識，測試方法，測試用例，缺陷的概念2） 測試計劃3） 數(shù)據(jù)方面（數(shù)據(jù)庫/XML/Hibernate/LDAP）4） 表現(xiàn)層知識（JSP/HTML/Struts/CSS）5） EAI（中間件/SOA概念，項目相關(guān)的經(jīng)驗）6） 測試自動化知識7） 設(shè)計模式知識（UML等等）8） 敏捷實踐（TDD,Refectoring,CI等等）9） 軟件生命周期經(jīng)驗（分析，設(shè)計，團(tuán)隊開發(fā)，測試，部署）10） 管理經(jīng)驗（Estimation,Mentoring,團(tuán)隊組織）11） 學(xué)習(xí)能力5、測試類型共劃分為哪些？1）功能測試：對軟件功能進(jìn)行測試，檢查軟件的各項功能是否實現(xiàn)了軟件功能說明書（軟件需求）上的要求。2）界面測試：對用戶界面進(jìn)行測試，檢查用戶界面的美觀度、統(tǒng)一性、易用性等方面的內(nèi)容。3）流程測試：按操作流程進(jìn)行測試，主要有業(yè)務(wù)流程、數(shù)據(jù)流程、邏輯流程、正反流程，檢查軟件在按照流程操作時是否能夠正確處理。4）并發(fā)測試：在網(wǎng)絡(luò)環(huán)境、并發(fā)環(huán)境和多用戶條件下對軟件進(jìn)行的測試。5）極限測試：在軟件的極限條件下進(jìn)行的測試，主要有對數(shù)據(jù)的極限值、邊界值操作，對軟件進(jìn)行致命操作等。6） 數(shù)據(jù)處理測試：對軟件數(shù)據(jù)接口進(jìn)行的測試，主要檢查軟件數(shù)據(jù)處理中輸入、處理、輸出數(shù)據(jù)過程。7） 安全測試：對軟件安全性方面的測試，主要檢測軟件中加密、解密、數(shù)據(jù)備份、恢復(fù)、病毒檢測等問題。8）性能測試：對軟件整體性能的測試，測試內(nèi)容有適應(yīng)性、健壯性、可恢復(fù)性、災(zāi)難恢復(fù)能力等9）安裝測試：在不同PC條件、操作系統(tǒng)、模擬客戶機(jī)等條件下進(jìn)行軟件的安裝測試，主要檢查軟件打包或發(fā)布之后存在的問題。10）性能測試：對軟件整體性能進(jìn)行測試，測試的內(nèi)容有適應(yīng)性、健壯性、可恢復(fù)性、災(zāi)難恢復(fù)能力6、你是怎么看待測試的？1）試想一下如果一個系統(tǒng)開發(fā)完畢后不能正常運行可能造成的后果，損失錢財，損失時間，損失客戶2）介紹一下軟件測試的意義發(fā)現(xiàn)軟件錯誤；有效定義和實現(xiàn)軟件成分由低層到高層的組裝過程；驗證軟件是否滿足任務(wù)書和系統(tǒng)定義文檔所規(guī)定的技術(shù)要求為軟件質(zhì)量模型的建立提供依據(jù)。3）介紹一下軟件測試的目的？確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Dotherightthing），并且確認(rèn)軟件以正確的方式來做了這個事件（Doitright）。提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險評估所準(zhǔn)備的信息。軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。正是基于以上所述，我認(rèn)為軟件測試是整個軟件質(zhì)量保證過程中重要的一部分，這也就是我選擇軟件測試這個行業(yè)的原因如何撰寫集成測試計劃？1） 確定集成測試對象2） 確定集成測試策略3） 確定集成測試驗收標(biāo)準(zhǔn)4） 確定集成測試掛起和恢復(fù)條件5） 估計集成測試工作量6） 估計集成測試所需資源7） 進(jìn)行集成測試任務(wù)劃分（包括任務(wù)名、責(zé)任人、輸入和輸出、風(fēng)險及應(yīng)對措施、進(jìn)度安排等）1、階段評審與同行評審的區(qū)別？參考答案：同行評審目的：發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤，只要是找錯誤；階段評審目的：評審模塊階段作品的正確性可行性及完整性同行評審人數(shù)：3-7人人員必須經(jīng)過同行評審會議的培訓(xùn)，由SQA指導(dǎo)階段評審人數(shù)：5人左右評審人必須是專家具有系統(tǒng)評審資格同行評審內(nèi)容：內(nèi)容小一般文檔<40頁，代碼<500行階段評審內(nèi)容：內(nèi)容多，主要看重點同行評審時間：一小部分工作產(chǎn)品完成階段評審時間：通常是設(shè)置在關(guān)鍵路徑的時間點上2、 什么是軟件測試及其目的？參考答案：軟件測試是使用人工或自動化手段來運行或測定某個系統(tǒng)的過程。其目的是：在于檢驗它是否能滿足規(guī)定的需求或是弄清楚預(yù)期結(jié)果與實際結(jié)果之間的差別。3、 簡述集成測試的過程？參考答案：集成測試流程：在完成軟件的概要設(shè)計后，即開始制定集成測試計劃-》設(shè)計集成測試用例和測試過程-》實施集成測試，設(shè)計所需驅(qū)動和樁-》執(zhí)行集成測試，記錄測試結(jié)果-》評估集成測試，根據(jù)測試結(jié)果評估此次測試，生成評估報告文檔。（驅(qū)動或樁函數(shù)是做單元測試時要用到的。驅(qū)動函數(shù)是所測4函數(shù)的主程序，它接收測試數(shù)據(jù)，并把數(shù)據(jù)傳送給所測試單元，最后再輸出實測結(jié)果。當(dāng)被測單元能完成相關(guān)功能時，也可以不要驅(qū)動單元。樁，是用來代替所測試單元調(diào)用的子單元。）4、 白盒測試有哪幾種方法？參考答案：代碼審查，語句覆蓋，判定覆蓋，條件覆蓋，組合覆蓋，基本路徑，形式化方法，符號執(zhí)行5、 簡述測試目標(biāo)有哪些類型？參考答案：功能測試，負(fù)載測試，性能測試，安全性測試，恢復(fù)測試，安裝測試，兼容性測試，可用性測試，可靠性測試，國際化測試，本地化測試。6、 怎么樣做好文檔測試？參考答案：文檔的測試主要采用靜態(tài)測試即走查的方法，可以依據(jù)的是同行評審，列出一個檢查表，然后大家一起坐下來對著被測試的文檔進(jìn)行閱讀排錯。通常文檔都很長，而一般的建議是一次同行評審步的時間不能超過兩個小時，因此可以對被測試文檔執(zhí)行測試時，列個計劃，將總的文檔分解，按照計劃多次對被測試的文檔進(jìn)行走查。一、軟通動力面試筆答1?白箱測試和黑箱測試是什么？什么是回歸測試?2?單元測試、集成測試、系統(tǒng)測試的側(cè)重點是什么?單元測試的重點是系統(tǒng)的模塊，包括子程序的正確性驗證等。集成測試的重點是模塊間的銜接以及參數(shù)的傳遞等。系統(tǒng)測試的重點是整個系統(tǒng)的運行以及與其他軟件的兼容性。3?設(shè)計用例的方法、依據(jù)有那些？白盒測試用例設(shè)計有如下方法:基本路徑測試\等價類劃分\邊界值分析\覆蓋測試\循環(huán)測試\數(shù)據(jù)流測試\程序插樁測試\變異測試?這時候依據(jù)就是詳細(xì)設(shè)計說明書及其代碼結(jié)構(gòu)吧；黑盒測試用例設(shè)計方法：基于用戶需求的測試\功能圖分析方法\等價類劃分方法\邊界值分析方法\錯誤推測方法\因果圖方法\判定表驅(qū)動分析方法\正交實驗設(shè)計方法?依據(jù)是用戶需求規(guī)格說明書，詳細(xì)設(shè)計說明書4?一個測試工程師應(yīng)具備那些素質(zhì)和技能？掌握基本的測試基礎(chǔ)理論本著找出軟件存在的問題的態(tài)度進(jìn)行測試,即客觀吧,不要以挑刺形象出現(xiàn)可熟練閱讀需求規(guī)格說明書等文檔以用戶的觀點看待問題有著強(qiáng)烈的質(zhì)量意識細(xì)心和責(zé)任心良好的有效的溝通方式（與開發(fā)人員及客戶）具有以往的測試經(jīng)驗?zāi)軌蚣皶r準(zhǔn)確地判斷出高危險區(qū)在何處.5?集成測試通常都有那些策略？大爆炸集成；自頂向下集成；自底向上集成；三明治集成；分層集成；基干集成；基于功能的集成；基于消息的集成；基于風(fēng)險的集成；基于進(jìn)度的集成.6?你用過的測試工具的主要功能、性能及其他？7?—個缺陷測試報告的組成？缺陷跟蹤報告:編號，如：ut-dt00016標(biāo)題，如：文字排版功能.字間距.MarchCalculator計算錯誤版本號，如：V1.3執(zhí)行狀態(tài)，如：空白障稿/提交/審批/分發(fā)/正在修改/修改完畢/正在確認(rèn)/關(guān)閉…修改記錄，如：2003年7月2日；肖睿編制/修改；原因測試環(huán)境和版本號碼、程序編寫人員錯誤嚴(yán)重程度和優(yōu)先級別錯誤詳細(xì)描述重現(xiàn)步驟和方式、對應(yīng)的測試記錄編碼附件建議修改方式修改內(nèi)容、結(jié)果及修改人員簽字/日期8?基于WEB信息管理系統(tǒng)測試時應(yīng)考慮的因素有哪些？1）功能測試鏈接測試表單測試Cookies測試設(shè)計語言測試數(shù)據(jù)庫測試2）性能測試連接速度測試負(fù)載測試壓力測試3）可用性測試①導(dǎo)航測試②圖形測試內(nèi)容測試整體界面測試4）客戶端兼容性測試①平臺測試②瀏覽器測試5）安全性測試軟件本地化測試比功能測試都有哪些方面需要注意？軟件測試項目從什么時候開始，？為什么？軟件測試應(yīng)該在需求分析階段就介入，因為測試的對象不僅僅是程序編碼，應(yīng)該對軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試，并且軟件缺陷存在放大趨勢.缺陷發(fā)現(xiàn)的越晚，修復(fù)它所花費的成本就越大.需求測試注意事項有哪些？一個良好的需求應(yīng)當(dāng)具有以下特點：?完整性：每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計和實現(xiàn)這些功能所需的所有必要信息。?正確性：每一項需求都必須準(zhǔn)確地陳述其要開發(fā)的功能。?一致性：一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。?可行性：每一項需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實施的。?無二義性：對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達(dá)出來。?健壯性：需求的說明中是否對可能出現(xiàn)的異常進(jìn)行了分析，并且對這些異常進(jìn)行了容錯處理。?必要性：“必要性”可以理解為每項需求都是用來授權(quán)你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如UseCase或別的來源。?可測試性：每項需求都能通過設(shè)計測試用例或其它的驗證方法來進(jìn)行測試。?可修改性：每項需求只應(yīng)在SRS中出現(xiàn)一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明書更容易修改。?可跟蹤性：應(yīng)能在每項軟件需求與它的根源和設(shè)計元素、源代碼、