導(dǎo)讀一、測試用例1.測試用例制定的原則？答：測試用例要包括欲測試的功能、應(yīng)輸入的數(shù)據(jù)和預(yù)期的輸出結(jié)果。測試數(shù)據(jù)應(yīng)該選用少量、高效的測試數(shù)據(jù)進(jìn)行盡可能完備的測試；....一、 測試用例

1. 測試用例制定的原則？

答：測試用例要包括欲測試的功能、應(yīng)輸入的數(shù)據(jù)和預(yù)期的輸出結(jié)果。測試數(shù)據(jù)應(yīng)該選用少量、高效的測試數(shù)據(jù)進(jìn)行盡可能完備的測試；基本目標(biāo)是：設(shè)計(jì)一組發(fā)現(xiàn)某個(gè)錯(cuò)誤或某類錯(cuò)誤的測試數(shù)據(jù)，測試用例應(yīng)覆蓋方面：

1、 正確性測試：輸入用戶實(shí)際數(shù)據(jù)以驗(yàn)證系統(tǒng)是滿足需求規(guī)格說明書的要求；測試用 例中的測試點(diǎn)應(yīng)首先保證要至少覆蓋需求規(guī)格說明書中的各項(xiàng)功能，并且正常。

2、 容錯(cuò)性（健壯性）測試：程序能夠接收正確數(shù)據(jù)輸入并且產(chǎn)生正確（預(yù)期）的輸出， 輸入非法數(shù)據(jù)（非法類型、不符合要求的數(shù)據(jù)、溢出數(shù)據(jù)等），程序應(yīng)能給出提示 并進(jìn)行相應(yīng)處理。把自己想象成一名對產(chǎn)品操作一點(diǎn)也不懂的客戶，在進(jìn)行任意操作。

3、 完整（安全）性測試：對未經(jīng)授權(quán)的人使用軟件系統(tǒng)或數(shù)據(jù)的企圖，系統(tǒng)能夠控制的程度，程序的數(shù)據(jù)處理能夠保持外部信息（數(shù)據(jù)庫或文件）的完整。

4、 接口間測試：測試各個(gè)模塊相互間的協(xié)調(diào)和通信情況，數(shù)據(jù)輸入輸出的一致性和正確性。

5、 數(shù)據(jù)庫測試：依據(jù)數(shù)據(jù)庫設(shè)計(jì)規(guī)范對軟件系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)、數(shù)據(jù)表及其之間的數(shù)據(jù)調(diào)用關(guān)系進(jìn)行測試。

6、 邊界值分析法：確定邊界情況（剛好等于、稍小于和稍大于和剛剛大于等價(jià)類邊界值），針對我們的系統(tǒng)在測試過程中主要輸入一些合法數(shù)據(jù)/非法數(shù)據(jù)，主要在邊界值附近選取。

7、 壓力測試：輸入10條記錄運(yùn)行各個(gè)功能，輸入30條記錄運(yùn)行，輸入50條記錄運(yùn)行。。。進(jìn)行測試。

8、等價(jià)劃分：將所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個(gè)等價(jià)類。

9、錯(cuò)誤推測：主要是根據(jù)測試經(jīng)驗(yàn)和直覺，參照以往的軟件系統(tǒng)出現(xiàn)錯(cuò)誤之處。

10、效率：完成預(yù)定的功能，系統(tǒng)的運(yùn)行時(shí)間（主要是針對數(shù)據(jù)庫而言）。

11、可理解（操作）性：理解和使用該系統(tǒng)的難易程度（界面友好性）。

12、可移植性：在不同操作系統(tǒng)及硬件配置情況下的運(yùn)行性。

13、回歸測試：按照測試用例將所有的測試點(diǎn)測試完畢，測試中發(fā)現(xiàn)的問題開發(fā)人員 已經(jīng)解決，進(jìn)行下一輪的測試。

14、比較測試：將已經(jīng)發(fā)版的類似產(chǎn)品或原有的老產(chǎn)品與測試的產(chǎn)品同時(shí)運(yùn)行比較，或與已往的測試結(jié)果比較 。

2. 測試用例是否納入測試基線管理？測試用例發(fā)生變更的流程？測試用例如何進(jìn)行標(biāo)識？

答：是。測試用例沒有變更流程

測試用例的標(biāo)識為ST-001這種格式標(biāo)識

3. 什么時(shí)候編寫測試用例？依據(jù)是什么？如何保證測試用例與需求的一致性？需要同行評審嗎？

答：在測試計(jì)劃完成之后，按照計(jì)劃進(jìn)度編寫測試用例。

依據(jù)是軟件需求規(guī)格說明書

通過同行評審來對用例進(jìn)行評審，需要同行評審

4. 測試用例如何設(shè)計(jì)的？

答：在測試用例的設(shè)計(jì)之前首先要仔細(xì)閱讀開發(fā)的詳細(xì)設(shè)計(jì)文檔，充分了解產(chǎn)品的詳細(xì)功能，不清的地方與開發(fā)人員進(jìn)行溝通，搞懂每個(gè)功能，盡量詳細(xì)到輸入框、按鈕等小功能，功能點(diǎn)清楚之后按照功能模塊分類進(jìn)行用例編寫。在具體的用例設(shè)計(jì)中會(huì)運(yùn)用到等價(jià)類 邊界值等黑盒測試方法

5. 如何保證用例覆蓋到罕見缺陷？

答：充足的設(shè)計(jì)時(shí)間 充分的需求分析 每一個(gè)功能點(diǎn)都有用例覆蓋

嚴(yán)格的評審流程 保障輸出都是有效的

在測試執(zhí)行過程中 會(huì)根據(jù)實(shí)際的項(xiàng)目情況 對用例做增加和修改

6. 什么時(shí)候編寫測試用例？依據(jù)是什么？如何保證測試用例與需求的一致性？需要同行評審嗎？

答：在測試計(jì)劃完成之后，按照計(jì)劃進(jìn)度編寫測試用例。

依據(jù)是軟件需求規(guī)格說明書

通過同行評審來對用例進(jìn)行評審，需要同行評審

二、 缺陷報(bào)告

1. 缺陷報(bào)告的優(yōu)先級別

答：最高優(yōu)先級：立即修復(fù)，停止進(jìn)一步測試

次高優(yōu)先級：在產(chǎn)品發(fā)布之前必須修復(fù)

中等優(yōu)先級：如果時(shí)間允許應(yīng)該修復(fù)

最低優(yōu)先級：可能會(huì)修復(fù)，但是也能發(fā)布

2. 簡單概述缺陷報(bào)告

答：現(xiàn)在缺陷報(bào)告一般不再使用紙質(zhì)檔文檔編寫，而是專用測試管理工具（如TestDirector），這樣便于缺陷管理。在這些工具中，每個(gè)缺陷作為一條記錄輸入指定的缺陷管理系統(tǒng)中。

3. 缺陷報(bào)告包括哪些項(xiàng)？

答：缺陷報(bào)告包括：軟件名稱、版本號、功能模塊、缺陷編號、對應(yīng)的用例編號、編寫時(shí)間、編寫人、測試員、預(yù)期結(jié)果、實(shí)際結(jié)果、缺陷描述、嚴(yán)重級別、優(yōu)先級別

三、 測試總結(jié)報(bào)告

1. 測試總結(jié)報(bào)告包括哪些項(xiàng)？

答：主要是：測試過程的總結(jié) 版本質(zhì)量的評估

四、 缺陷（Bug）

1. 軟件缺陷的原則

答：A、軟件缺陷區(qū)別于軟件bug,它是在測試過程中出現(xiàn)的對系統(tǒng)有影響的,但是在設(shè)計(jì)中沒有的或者對修改后的bug測試和開發(fā)人員有不同意見等

B、軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能。

C、軟件出現(xiàn)了產(chǎn)品說明書指明不會(huì)出現(xiàn)的錯(cuò)誤。

D、軟件功能超出產(chǎn)品說明書指明范圍。

E、軟件未達(dá)到產(chǎn)品說明書雖未指出但應(yīng)達(dá)到的目標(biāo)。

F、軟件測試員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢，或者最終用戶認(rèn)為不好。

2. 軟件缺陷的特征。

1) “看不到”

2) ——軟件的特殊性決定了缺陷不易看到

3) “看到但是抓不到”

4) ——發(fā)現(xiàn)了缺陷，但不易找到問題發(fā)生的原因所在

軟件缺陷產(chǎn)生的原因

1) 軟件產(chǎn)品說明書（需求）——56%

2) 設(shè)計(jì)——27%

3) 編寫代碼——7%

4) 其他——10%

3. 什么是Bug？

答：軟件的Bug指的是軟件中（包括程序和文檔）不符合用戶需求的問題。

常見的軟件Bug分為以下三類：

沒有實(shí)現(xiàn)的功能

完成了用戶需求的功能，但是運(yùn)行時(shí)會(huì)出現(xiàn)一些功能或性能上的問題

實(shí)現(xiàn)了用戶不需要的多余的功能

4. 缺陷處理流程

答：測試人員提交新的Bug入庫，錯(cuò)誤狀態(tài)為New。 高級測試人員驗(yàn)證錯(cuò)誤，如果確認(rèn)是錯(cuò)誤，分配給相應(yīng)的開發(fā)人員，設(shè)置狀態(tài)為Open。如果不是錯(cuò)誤，則拒絕，設(shè)置為Declined(拒絕)狀態(tài)。 開發(fā)人員查詢狀態(tài)為Open的Bug，如果不是錯(cuò)誤，則置狀態(tài)為Declined；如果是Bug則修復(fù)并置狀態(tài)為Fixed。不能解決的Bug，要留下文字說明及保持Bug為Open狀態(tài)。對于不能解決和延期解決的Bug，不能由開發(fā)人員自己決定，一般要通過某種會(huì)議（評審會(huì)）通過才能認(rèn)可。 測試人員查詢狀態(tài)為Fixed的Bug，然后驗(yàn)證Bug是否已解決，如解決置Bug的狀態(tài)為Closed，如沒有解決置狀態(tài)為Reopen。

5. 缺陷的等級劃分

答：嚴(yán)重： 系統(tǒng)崩潰 數(shù)據(jù)丟失 數(shù)據(jù)毀壞

較嚴(yán)重：操作性失誤 錯(cuò)誤結(jié)果 遺漏功能

一般： 小問題 錯(cuò)別字 UI布局 罕見故障

建議：不影響使用的瑕疵或更好的實(shí)現(xiàn)

6. 開發(fā)人員修復(fù)缺陷后，如何保證不影響其他功能？

答：重新執(zhí)行用例、看是否出現(xiàn)錯(cuò)誤結(jié)果。并對周圍的一些相關(guān)功能點(diǎn)追加新的測試用例。

7. 狀態(tài)為已修改的缺陷，實(shí)際沒有修改怎么辦？

答：加強(qiáng)項(xiàng)目質(zhì)量管理，提高項(xiàng)目執(zhí)行能力。如果測試人員發(fā)現(xiàn)了這樣的問題，首先要弄清楚是什么原因?qū)е逻@種情況，最終還是要督促開發(fā)人員，修改掉這些問題。如果是不能重現(xiàn)的問題或者是老版本中遺留下來的問題不能修改的 要做好標(biāo)示。

8. 生產(chǎn)軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質(zhì)量的標(biāo)準(zhǔn)，認(rèn)為軟件缺陷（ Software Bug ）的具體含義包括下面幾個(gè)因素

答：

1) 軟件未達(dá)到客戶需求的功能和性能；

2) 軟件超出客戶需求的范圍；

3) 軟件出現(xiàn)客戶需求不能容忍的錯(cuò)誤；

4) 軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境。

五、缺陷評估

評估軟件質(zhì)量的重要指標(biāo)，通常評估模型假設(shè)缺陷的發(fā)現(xiàn)是呈泊松分布的；嚴(yán)格的缺陷評估要考察在測試過程中發(fā)現(xiàn)缺陷的間隔時(shí)間長短。評估要估計(jì)軟件當(dāng)前的可靠性并預(yù)測隨著測試的繼續(xù)進(jìn)行，軟件可靠性會(huì)怎樣提高。

SQA Suite 提供四種形式進(jìn)行缺陷評估：

1) 缺陷分布報(bào)告可以生成缺陷數(shù)量與缺陷屬性的函數(shù)。如測試需求和狀態(tài)。

2) 缺陷趨勢報(bào)告可以看出缺陷增長和減少的趨勢；

3) 缺陷年齡報(bào)告展示一個(gè)缺陷處于某種狀態(tài)的時(shí)間長短

4) 測試結(jié)果進(jìn)度報(bào)告展示測試過程在被測應(yīng)用的幾個(gè)版本中的執(zhí)行結(jié)果以

5) 測試周期。

具體步驟

1) 回顧測試日記

2) 評估測試需求的覆蓋率

3) 分析缺陷

4) 決定是否達(dá)到完成測試的標(biāo)準(zhǔn)，沒有滿足標(biāo)準(zhǔn)時(shí)

5) 再測試

6) 降低標(biāo)準(zhǔn)

7) 確定軟件的一個(gè)滿足標(biāo)準(zhǔn)的子集，看是否可以發(fā)布。

感謝每一個(gè)認(rèn)真閱讀我文章的人！！！

如果下面這些資料用得到的話可以直接拿走：

1、自學(xué)開發(fā)或者測試必備的完整項(xiàng)目源碼與環(huán)境

2、測試工作中所有模板（測試計(jì)劃、測試用例、測試報(bào)告等）

3、軟件測試經(jīng)典面試題

4、Python/Java自動(dòng)化測試實(shí)戰(zhàn).pdf

5、Jmeter/postman接口測試全套視頻獲取

我個(gè)人整理了我這幾年軟件測試生涯整理的一些技術(shù)資料，包含：電子書，簡歷模塊，各種工作模板，面試寶典，自學(xué)項(xiàng)目等。如果在學(xué)習(xí)或工作中遇到問題可以直接進(jìn)群詢問，群里也會(huì)有大神幫忙解答，需要的可以找我謝謝。