軟件測(cè)試重要知識(shí)點(diǎn)概述

1、軟件測(cè)試的概念？ 軟件測(cè)試就是利用測(cè)試工具按照測(cè)試方案和流程對(duì)產(chǎn)品進(jìn)行功能和性能測(cè)試， 甚至根據(jù) 需要編寫不同的測(cè)試工具， 設(shè)計(jì)和維護(hù)測(cè)試系統(tǒng)， 對(duì)測(cè)試方案可能出現(xiàn)的問題進(jìn)行分析 和評(píng)估。執(zhí)行測(cè)試用例后，需要跟蹤故障，以確保開發(fā)的產(chǎn)品適合需求。八、軟件測(cè)試的目的？從用戶的角度出發(fā)， 普遍希望通過軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷， 以考慮是否 可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)， 則希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過程， 驗(yàn)證該 軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對(duì)軟件質(zhì)量的信心。（1）/、測(cè)試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；（2）、一個(gè)好的測(cè)試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；

2、（3）、一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。想以最少的時(shí)間和人力， 系統(tǒng)地找出軟件中潛在的各種錯(cuò)誤和缺陷。 如果我們成功地實(shí) 施了測(cè)試，我們就能夠發(fā)現(xiàn)軟件中的錯(cuò)誤。測(cè)試的附帶收獲是，它能夠證明軟件的性能與需求說明相符合。 實(shí)施測(cè)試收集到的測(cè)試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。測(cè)試不能表明軟件中不存在錯(cuò)誤，它只能說明軟件中存在錯(cuò)誤。 九、軟件測(cè)試的對(duì)象？軟件測(cè)試并不等于程序測(cè)試。軟件測(cè)試應(yīng)貫穿于軟件定義與開發(fā)的整個(gè)期間。 需求分析、 概要設(shè)計(jì)、 詳細(xì)設(shè)計(jì)以及程序編碼等各階段所得到文檔， 包括需求規(guī)格說明、 概要設(shè)計(jì)規(guī)格說明、詳細(xì)設(shè)計(jì)規(guī)格說明以及源程序，都應(yīng)成為軟件測(cè)試的對(duì)象。十、軟件測(cè)試

3、的重要性？（1）、保證軟件質(zhì)量 （2）、研發(fā)成本和上線時(shí)間，節(jié)約預(yù)算。十一、 測(cè)試的職責(zé)？ 測(cè)試經(jīng)理：制定測(cè)試計(jì)劃，確保測(cè)試工作正常進(jìn)行 測(cè)試人員：編寫測(cè)試用例，搭建測(cè)試環(huán)境，執(zhí)行測(cè)試并提出問題單，模塊測(cè)試總結(jié)。十二、 軟件的分類？ 按功能劃分：系統(tǒng)軟件、應(yīng)用軟件 按技術(shù)架構(gòu)劃分：?jiǎn)螜C(jī)版、 B/S、 C/S 按目標(biāo)用戶劃分：產(chǎn)品軟件、項(xiàng)目軟件十三、 B/S 模式的特點(diǎn)？?jī)?yōu)點(diǎn)： 具有分布性特點(diǎn)， 可以隨時(shí)隨地進(jìn)行查詢、 瀏覽等業(yè)務(wù)處理； 業(yè)務(wù)擴(kuò)展簡(jiǎn)單方便， 通過增加網(wǎng)頁即可增加服務(wù)器功能； 維護(hù)簡(jiǎn)單方便， 只需要改變網(wǎng)頁， 即可實(shí)現(xiàn)所有用 戶的同步更新；開發(fā)簡(jiǎn)單，共享性強(qiáng)。缺點(diǎn)： 個(gè)性化特點(diǎn)明顯

4、降低， 無法實(shí)現(xiàn)具有個(gè)性化的功能要求； 操作是以鼠標(biāo)為最基本 的操作方式，無法滿足快速操作的要求； 頁面動(dòng)態(tài)刷新， 響應(yīng)速度明顯降低；無法實(shí)現(xiàn) 分頁顯示， 給數(shù)據(jù)庫訪問造成較大的壓力； 功能弱化， 難以實(shí)現(xiàn)傳統(tǒng)模式下的特殊功能 要求。十四、 C/S 模式的特點(diǎn)？?jī)?yōu)點(diǎn)： 由于客戶端實(shí)現(xiàn)與服務(wù)器的直接相連， 沒有中間環(huán)節(jié)， 因此響應(yīng)速度快；操作界 面漂亮、形式多樣，可以充分滿足客戶自身的個(gè)性化要求； C/S 結(jié)構(gòu)的管理信息系統(tǒng)具 有較強(qiáng)的事務(wù)處理能力，能實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)流程。缺點(diǎn)： 需要專門的客戶端安裝程序， 分布功能弱， 針對(duì)點(diǎn)多面廣且不具備網(wǎng)絡(luò)條件的用 戶群體，不能夠?qū)崿F(xiàn)快速部署安裝和配置；兼容

5、性差，對(duì)于不同的開發(fā)工具，具有較大 的局限性；若采用不同工具，需要具有一定專業(yè)水準(zhǔn)的技術(shù)人員才能完成。十五、 測(cè)試工作的基本原則？ 所有的軟件測(cè)試都應(yīng)追溯到用戶需求； 應(yīng)當(dāng)把 “盡早地和不斷地進(jìn)行軟件測(cè)試” 作為軟 件測(cè)試者的座右銘； 完全測(cè)試是不可能的， 測(cè)試需要終止； 測(cè)試無法顯示軟件潛在的缺 陷；充分注意測(cè)試中的群集現(xiàn)象； 程序員應(yīng)避免檢查自己的程序； 盡量避免測(cè)試的隨意 性。十六、 UML 的解釋？它的全稱是 “統(tǒng)一建模語言” ，它是一種用于描述， 構(gòu)造軟件系統(tǒng)以及商業(yè)建模的語言。 簡(jiǎn)單的理解就是它可以以一種直觀的方式表示出一個(gè)系統(tǒng)地各項(xiàng)內(nèi)容。十一、軟件開發(fā)模型？1、瀑布模型； 2、快

6、速原型模型； 3、增量模型； 4、螺旋模型 十二、為什么軟件會(huì)有毛病？交流錯(cuò)誤或者沒有進(jìn)行交流；軟件的復(fù)雜性；編碼錯(cuò)誤；需求變更；時(shí)間壓力；代碼 文檔質(zhì)量差；軟件開發(fā)工具十三、在軟件開發(fā)過程中 5 個(gè)常見的問題及解決方法？ 需求說明差；不切實(shí)際的時(shí)間表；測(cè)試不充分；不斷增加功能；交流問題 可靠的需求；合理的時(shí)間表；適當(dāng)?shù)臏y(cè)試；盡可能堅(jiān)持最初的需求；溝通十四、什么是 CMM ？CMM=Capability Maturity Model ，即“性能完善模型” ，由 SEI 開發(fā)。它是一個(gè)分 5 級(jí) 的、可以描述結(jié)構(gòu) 完善程度的模型， 用它來說明所交付的軟件的效能。 它適用于大的機(jī)構(gòu)， 例如美國(guó)國(guó)防

7、部的承包商。 所以， 它所涉及的許多質(zhì)量控制過程適用于任何機(jī)構(gòu)，如果合理地利用它，將會(huì)獲益不淺。一個(gè)機(jī)構(gòu)經(jīng)過權(quán)威評(píng)審機(jī)構(gòu)的評(píng)估，可以得到 CMM 等級(jí)。 十五、軟件測(cè)試的生命周期？項(xiàng)目啟動(dòng)、測(cè)試分析與計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、測(cè)試評(píng)估、驗(yàn)收測(cè)試、項(xiàng)目關(guān)閉 輸出文檔：測(cè)試計(jì)劃、測(cè)試用例、問題單、評(píng)估報(bào)告、用戶使用手冊(cè)及操作指引十六、 V 模型及其特征？V 模型：需求、功能、設(shè)計(jì)、編碼（單元測(cè)試） 、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試 特征： 每個(gè)開發(fā)活動(dòng)都有右邊的測(cè)試活動(dòng)相對(duì)應(yīng)； 軟件開發(fā)過程是一個(gè)自頂向下， 逐步 細(xì)化的過程；測(cè)試過程是依相反順序安排的自底向上，逐步集成的過程。十七、 W 模型及其特

8、征？ 需求（需求測(cè)試） 、功能（功能測(cè)試） 、設(shè)計(jì)（設(shè)計(jì)測(cè)試） 、編碼（單元測(cè)試） 、集成測(cè)試 （構(gòu)建）、系統(tǒng)測(cè)試（集成） 、驗(yàn)收測(cè)試（安裝）特點(diǎn)： 軟件測(cè)試并不等于程序測(cè)試。 軟件測(cè)試應(yīng)貫穿于軟件定義與開發(fā)的整個(gè)期間； 需 求分析、概要設(shè)計(jì)、 詳細(xì)設(shè)計(jì)以及程序編程等各階段所得到的文檔， 包括需求規(guī)格說明、 概要設(shè)計(jì)規(guī)格說明、詳細(xì)設(shè)計(jì)規(guī)格說明以及源程序，都應(yīng)成為軟件測(cè)試的對(duì)象。十八、軟件測(cè)試的分類，及解釋？ （1）、單元測(cè)試：集中對(duì)用源代碼實(shí)現(xiàn)的每一個(gè)程序單元進(jìn)行測(cè)試，檢查各個(gè)程序模 塊是否正確地實(shí)現(xiàn)了規(guī)定的功能（ 2）、集成測(cè)試：把已測(cè)試過的模塊組裝起來，主要對(duì)與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)進(jìn) 行

9、測(cè)試。（ 3）、系統(tǒng)測(cè)試：把已經(jīng)經(jīng)過確認(rèn)的軟件納入實(shí)際運(yùn)行環(huán)境中，與其它系統(tǒng)成份組合 在一起進(jìn)行測(cè)試（4）、驗(yàn)收測(cè)試：十九、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試解釋？（ 1）單元測(cè)試又稱模塊測(cè)試， 是針對(duì)軟件設(shè)計(jì)的最小單位程序模塊， 進(jìn)行正確性 檢驗(yàn)的測(cè)試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。單元測(cè)試需要從 程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測(cè)試。（ 2）集成測(cè)試： 在運(yùn)行（可能是不完整） 的應(yīng)用中保證軟件單元被結(jié)合后能正常操作 的測(cè)試執(zhí)行的階段；主要測(cè)試模塊與模塊之間的借口，看能否結(jié)合沒有差錯(cuò)（ 3）系統(tǒng)測(cè)試： 是將通過確認(rèn)測(cè)試的軟件，作為整個(gè)基于計(jì)

10、算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、 某些支持軟件、 數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際 運(yùn)行環(huán)境下， 對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。 系統(tǒng)測(cè)試的目的在于 通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。（4）驗(yàn)收測(cè)試：a測(cè)試和3測(cè)試；在軟件交付使用之后，用戶將如何實(shí)際使用程序， 對(duì)于開發(fā)者來說是無法預(yù)測(cè)的。a 測(cè)試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試， 也可以是公司內(nèi)部的用戶在模擬實(shí)際 操作環(huán)境下進(jìn)行的測(cè)試。 a測(cè)試的目的是評(píng)價(jià)軟件產(chǎn)品的 FLURPS （即功能、局域化、 可使用性、可靠性、性能和支持） 。尤其注重產(chǎn)品的界面和特色。 a 測(cè)試可

11、以從軟件 產(chǎn)品編碼結(jié)束之時(shí)開始， 或在模塊（子系統(tǒng)） 測(cè)試完成之后開始， 也可以在確認(rèn)測(cè)試 過程中產(chǎn)品達(dá)到一定的穩(wěn)定和可靠程度之后再開始。3 測(cè)試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。 這些用戶返回有關(guān)錯(cuò)誤信 息給開發(fā)者。測(cè)試時(shí)，開發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)。 因而， 3 測(cè)試是在開發(fā)者無法控制 的環(huán)境下進(jìn)行的軟件現(xiàn)場(chǎng)應(yīng)用。 在3 測(cè)試中， 由用戶記下遇到的所有問題， 包括真實(shí) 的以及主觀認(rèn)定的， 定期向開發(fā)者報(bào)告。3測(cè)試主要衡量產(chǎn)品的 FLURPS。著重于產(chǎn) 品的支持性， 包括文檔、 客戶培訓(xùn)和支持產(chǎn)品生產(chǎn)能力。 只有當(dāng) a 測(cè)試達(dá)到一定的可 靠程度時(shí)， 才能開始 3 測(cè)試。它處在整個(gè)測(cè)試

12、的最后階段。同時(shí)， 產(chǎn)品的所有手冊(cè)文 本也應(yīng)該在此階段完全定稿。二十、黑盒測(cè)試及白盒測(cè)試？黑盒測(cè)試： 黑盒測(cè)試又叫做功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。 這種方法是把測(cè)試對(duì)象看做一 個(gè)黑盒子， 測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明白盒測(cè)試： 此方法把測(cè)試對(duì)象看做一個(gè)透明的盒子， 它允許測(cè)試人員利用程序內(nèi)部的 邏輯結(jié)構(gòu)及有關(guān)信息， 設(shè)計(jì)或選擇測(cè)試用例， 對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。 通過在 不同點(diǎn)檢查程序的狀態(tài)， 確定實(shí)際的狀態(tài)是否與預(yù)期的狀態(tài)一致。 因此白盒測(cè)試又稱 為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。二十一、測(cè)試人員具體工作？軟件測(cè)試工程師

13、： 1、創(chuàng)作相關(guān)的測(cè)試計(jì)劃和測(cè)試案例； 2、識(shí)別可自動(dòng)測(cè)試的區(qū)域； 3、參與組內(nèi)的測(cè)試計(jì)劃 4、和測(cè)試案例以及測(cè)試腳本分析工作；5、手動(dòng)或自動(dòng)測(cè)試；6、按照需求規(guī)格說明查證并驗(yàn)證各項(xiàng)功能；7、發(fā)現(xiàn)并報(bào)告 bug，跟蹤其狀態(tài)；8、初步評(píng)估 bug 對(duì)產(chǎn)品其它部分的影響測(cè)試組長(zhǎng)： 1、確定測(cè)試的策略 2、參與對(duì)整個(gè)產(chǎn)品的完整測(cè)試計(jì)劃的制定3、參與并管理測(cè)試 4、評(píng)估 bug 對(duì)用戶的影響 5、跟蹤關(guān)鍵 bug 狀態(tài) 6、管理測(cè)試工作和對(duì)象 的資源 7、參與面試新人 8、交流狀態(tài)和存在問題，并驅(qū)動(dòng)問題的解決9、促進(jìn)組內(nèi)的交流軟件測(cè)試經(jīng)理： 1、定義時(shí)間進(jìn)度表 2、定義質(zhì)量標(biāo)準(zhǔn) 3、發(fā)起和計(jì)劃長(zhǎng)期的測(cè)

14、試過程， 使之規(guī)范化 4、積極開發(fā)測(cè)試人員的技術(shù)技能5、組建測(cè)試隊(duì)伍，招聘測(cè)試工程師6、合理安排各種資源 7、負(fù)責(zé)制定產(chǎn)品測(cè)試所需的預(yù)算二十二、什么時(shí)候停止測(cè)試？ 發(fā)現(xiàn)所有的漏洞時(shí)菜停止測(cè)試是不可能的，關(guān)鍵在于是否經(jīng)濟(jì) 1、市場(chǎng)壓力； 2、質(zhì)量目標(biāo)； 3、客戶要求； 4、費(fèi)用約束 錯(cuò)誤發(fā)現(xiàn)率：錯(cuò)誤被發(fā)現(xiàn)的頻率可以顯示出系統(tǒng)的測(cè)試階段是否接近完成 二十三、測(cè)試結(jié)束的標(biāo)準(zhǔn)是什么？1、用例全部執(zhí)行； 2、覆蓋率達(dá)到標(biāo)準(zhǔn)； 3、缺陷率達(dá)到標(biāo)準(zhǔn)； 4、其他指標(biāo)達(dá)到質(zhì)量 標(biāo)準(zhǔn)二十四、測(cè)試完成的標(biāo)準(zhǔn)？1、 系統(tǒng)測(cè)試與用戶需求說明書一致； 2、功能測(cè)試用例通過率達(dá)到 100%； 3、非功 能性測(cè)試用例通過率達(dá)

15、到 95%；4、一、二級(jí)錯(cuò)誤修復(fù)率應(yīng)達(dá)到 100%； 5、三、 四級(jí)錯(cuò)誤修復(fù)率應(yīng)達(dá)到 80%以上；五級(jí)錯(cuò)誤修復(fù)率應(yīng)達(dá)到 60%以上。二十五、什么是測(cè)試用例？ 測(cè)試案例是一份文檔，它描述了一個(gè)輸入、 反應(yīng)、 或者是與其相應(yīng)的預(yù)期的響應(yīng)，以 便來判斷應(yīng)用軟件的工作是否正常。測(cè)試案例應(yīng)當(dāng)包括測(cè)試標(biāo)識(shí)、測(cè)試案例的名稱、 目標(biāo)、測(cè)試條件 /設(shè)置、輸入數(shù)據(jù)要求、步驟、以及預(yù)期的結(jié)果。 注：開發(fā)一個(gè)以應(yīng)用軟件的測(cè)試案例的過程，需要全面、深入的考慮該軟件的操作， 所以有助于發(fā)現(xiàn)在其需求或設(shè)計(jì)里面的問題。因此， 如果有可能， 在開發(fā)周期中應(yīng)當(dāng)盡早準(zhǔn)備測(cè)試案例。二十六、如果錯(cuò)誤太多無法測(cè)試怎么辦 ? 在這種情況下

16、，測(cè)試人員最好仔細(xì)研究報(bào)告，看錯(cuò)誤或阻塞型的問題 (blocking-type problems) 最初出現(xiàn)的地方，并把注意力放在最嚴(yán)重的錯(cuò)誤上。由于這類問題會(huì)影響 進(jìn)度， 并能反映出軟件開發(fā)過程中的深層次的問題(例如，部件測(cè)試或集成測(cè)試不充分、設(shè)計(jì)不良、不適當(dāng)?shù)慕⒑桶l(fā)布過程，等等)，所以應(yīng)當(dāng)通知管理人員，并向他們提供一些證明文件。二十七、時(shí)間不夠，無法充分測(cè)試？ 使用風(fēng)險(xiǎn)分析，確定測(cè)試的重點(diǎn)。二十八、一個(gè)好的測(cè)試人員該具備的素質(zhì)？1、 溝通能力 2、移情能力 3、技術(shù)能力 4、自信心 5、外交能力 6、幽默感 7、很強(qiáng) 的記憶力 8、耐心 9、懷疑精神 10、自我督促 11、洞察力 二十九、開發(fā)與測(cè)試的關(guān)系？開發(fā)與