軟件測試技術工作總結(精選多篇)

第一篇：軟件測試技術總結

it公司面試手冊提供最全的it類面試題, 包括

java：java面試題 j2ee面試題 hibernate面試題 spring面試題struts面試題ejb面試題 : 面試題 面試題 c#面試題

數據庫：數據庫面試題oracle面試題 sql server面試題 mysql面試題

網絡：網絡技術面試題 網絡安全面試題

web開發：php面試題 web開發面試題

linux unix：unix面試題linux面試題

軟件測試： 軟件測試面試題

其他類： 英語面試 外企面試 python面試題 程序員面試

更多面試題請訪問： http://

軟件測試技術總結

軟件測試就是爲了發現程序中的錯誤而分析和執行程序的過程。——概念

+基本知識+軟件開發過程-定義-計劃-實現-穩定化-部署

一、軟件開發模型(四種典型的模型)

1、瀑布模型

概述：包括計劃，需求分析，設計，編碼，測試，運行維護六個階段。六個階段自上而下、相互銜接，以固定的次序進行。

特點：1.階段的順序性和依賴性；2.文檔驅動；3.推遲實現的觀點； 4.質量保證。

缺點：不適合需求模糊的系統

2、原型模型

概述：先建立一個能夠反映用戶需求的原型系統，使得用戶和開發者可以對目標系統的概貌進行評價和判斷，然後對原型系統進行反覆的擴充、改進、求精，最終建立符合用戶需求的目標系統。

特點：1.快速開發工具；2.循環； 3.低成本。

分類：按照對原型的處理方式，可以分爲漸進型和拋棄型。

3、增量模型

概述：在增量模型中每個階段都生成軟件的一個可發佈版本，階段交錯進行，版本逐漸完善。同原型模型的最大區別在於，在原型模型中每個階段發佈一個原型而在增量模型中則完成一個正式版本。

4、螺旋模型

概述：適用於大型軟件的開發，它將瀑布模型和快速原型模型結合起來，並加入了風險分析。特點：1.每個階段都包括制定計劃，風險分析，實施工程，評審四個階段；2.開發過程迭代進行，每迭代一次螺旋線增一週，工程前進一個層次，系統生成一個新版本， 投入新的時間成本，最終得到客戶滿意的版本。-軟件測試從需求開始：現代的軟件測試將測試滲入到軟件開發的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設計階段，測試人員便已經開始了他們的工作，如：瞭解軟件需求，編寫測試計劃，搭建測試環境。

二、測試用例

1、三要素：前提條件和操作步驟、預期結果、實際結果。2、必須以需求爲依據。

三、軟件測試分類

1、是否關注軟件結構和算法

-黑盒測試：基於軟件需求的測試方法。-白盒測試：基於軟件內部設計和程序實現的測試方法。

2、是否執行被測試軟件

-動態測試：在測試過程中執行被測試軟件的測試方法。-靜態測試：------------不----------------------。

3、基於不同的測試階段：

1、單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅動程序，採用白盒測試的方法，一般由 開發人員完成。

2、集成測試：將一些“構件”集成在一起時測試他們是否能正常運行，構件可以是程序模塊，也可以是客戶機-服務器程序等，需要編寫測試仿真程序，採用白盒和黑盒相結合的方式，通常由 開發人員承擔。

3、系統測試：測試軟件系統是否符合所有的需求，包括功能性測試和非功能性測試。一般由獨立的測試人員完成，通常採用黑盒測試方法。

4、驗收測試：(α、β)與系統測試類似，但由客戶或最終用戶執行，測試軟件是否符合需求規格說明書。

5、迴歸測試：指在軟件開發過程中，每次錯誤被修正後或軟件的功能、環境發生變化後進行的測試。

四、軟件測試的三個步驟：

1、測試計劃：測試人員首先對需求進行分析，最終定義一個測試集合，通過刻畫和定義測試發現需求中的問題，然後根據軟件需求同測試主管制定並確認“測試計劃”。

2、測試設計和開發：軟件測試人員根據軟件需求和軟件設計說明書完成測試用例的設計和必要的測試驅動程序的開發。

3、執行測試：需要做的工作包括搭建測試環境、運行測試、記錄測試結果、報告軟件缺陷、跟蹤軟件缺陷、分析測試結果，必要時進行迴歸測試。

五、測試工程師的能力要求：

1、5c

-controlled /ken'treuld/ 接受管理，有條理的

-competent /'kcmpitent/瞭解正確的測試技術

-critical /'kritikel/專注於發現問題

-comprehensive /ri'hensiv/ 注意細節

-considerate /ken'siderit/能夠和開發人員很好的交談

2、職業素質 -責任心-學習能力-懷疑精神 -溝通能力 -專注力-洞察力 -團隊精神-注重積累

六、制定測試計劃的五個步驟：

1、分析和測試軟件需求2、定義測試策略3、定義測試環境4、定義測試管理

5、編寫和審覈測試計劃

如果在需求分析階段發現並結果問題需要花費$1，則在設計階段解決同樣的問題需花費$5，在編碼階段需$10，交付後解決同樣的問題需花費$200。——越早測試越好

七、在需求分析過程中測試人員需要進行如下工作：

1)理解需求，參與審覈需求文檔；2)理解項目的目標、限制，瞭解用戶的應用背景；

3)編寫測試計劃；4)準備測試資源。

八、需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進行測試。

九、好的需求文檔的特徵

1、具有清晰的格式和文檔結構2、需求的內容正確3、需求的內容完整

4、需求具有可行性需求的必要性5、對不同的需求優先等級進行定義 6、描述明確

7、可證性和可測試性8、可修改性-可追蹤9、需求文檔被及時更新

十、需求測試內容

1、需求文檔是否符合公司的格式要求2、是否正確

3、要保證需求文檔中所描述的內容是真實可靠的

4、這是“真正的”需求嗎？描述的產品是否是要開發的產品？

5、需求是否完備？第一個發佈的版本是否需要更多的功能？列出的需求可以減少一部分？

6、需求是否兼容？需求有可能是矛盾的。

7、需求是否可實現？如：需求設想的設備是否比實際運行的要快？需求要求的內存、i/0設備是否太多？需求的輸入或輸出設備要求的分辨率是否要求過高？

8、需求是否合理？在開發進度、開發費用、產品性能、可靠性和內存使用之間存在着平衡關係。

9、需求是否可測？對於軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。

十一、需求測試方法

1、複查review2、走查walkthrough3、審查inspection

十二、測試策略的內容

1、確定測試範圍 軟件是無法被完全測試的2、確定測試方法 不同的系統需要不同的測試方法

3、定義測試標準 入口標準，暫停和繼續的標準，出口標準等

十三、軟件測試結束的標準

-基於測試用例的使用規則

1)構造測試用例（由相關人員進行評審）

2)執行測試用例中，當測試用例的不通過率達到20%則拒絕繼續測試，待開發人員修正軟件後再繼續。

3)當功能性測試用例通過率達到100%，非功能性測試用例通過率達到90%時，允許正常結束。

-基於“測試期缺陷密度”規則---------含義：對軟件測試一個cpu小時發現的缺陷數，比較適用於系統測試-基於“運行期缺陷密度”規則---------含義：把軟件運行一個cpu小時發現的缺陷數，比較適用於驗收測試注：一個階段的出口標準!=下一個階段的入口標準

系統測試結束的標準!=軟件的發佈標準發佈標準!=軟件0缺陷

-選擇測試工具 是否需要，需要什麼工具，怎麼獲取

-降低軟件測試代價是企業普遍關注的問題，可通過

a.減少冗餘和無價值的測試；b.減少測試階段(萬般無奈下)

十四、測試環境

-基本內容：設備環境、軟件環境、數據環境

-需考慮的因素 -計算機平臺-操作系統 -瀏覽器 -軟件支持平臺 -外圍設備 -網絡環境 -其他專用設備 -搭建測試環境時的配置原則：-使用的頻度或範圍-實效的可能性-最大限度的模擬真實環境

十五、測試管理

由於測試工程中設計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進行管理 -選擇缺陷管理工具和測試管理工具-定義工作進度

-建立風險管理計劃

(1)可能遇到的風險

1.由於設計、編碼階段出現大量質量問題，導致測試工作量時間增加

2.開始測試時所需的硬件、軟件沒有準備好3.未能完成對測試人員的技術培訓

4.測試時的人力資源安排不足5.測試過程中，發生了大量的需求變更

6.測試過程中，項目的開發計劃被大幅度調整7.不能及時準備好測試所需的環境

8.不能及時準備好測試數據

(2)風險管理的過程

1.識別風險2.評估風險3.制定對策4.跟蹤風險

+測試設計與開發

+總體設計

-投入產出：測試設計的輸入是測試計劃，輸出是評審過的測試用例集合

-定義設計目標遵循的原則

(-清楚地說明沒項測試的目標-使每項測試的目標單一，可以對應到規格說明書中的一項需求-只說明測試應該完成什麼工作，而不說明如何完成)

-流程：總體設計-開發測試用例-評審測試用例

i.定義設計目標ii.定義輸入說明iii.定義測試環境和配置

iv.測試設計文檔v.開發測試用例

+測試用例——概念：爲特定目標開發的測試輸入、執行條件和預期結果的集合。

+好的測試用例：

1.容易發現軟件的錯誤2.精確的重複某測試失敗的情景，可重複性

3.清晰的定義一個或多個期望的結果4.沒有冗餘

+測試用例的作用

-指導測試的實施 -作爲編寫測試腳本的“設計規格說明書”-評估測試標準的度量基準-分析缺陷的標準 +白盒測試用例設計

+設計方法

+邏輯覆蓋法

( -語句覆蓋 -判定覆蓋 -條件覆蓋 -判定-條件覆蓋-條件組合覆蓋 -路經覆蓋-基本路經法)

+輔助模塊設計

(1.驅動模塊：相當於被測程序的主程序。接受測試數據，把這些數據傳給被測模塊然後輸出實際測試結果。

2.樁模塊：用於調用被測模塊調用的子模塊。可以做少量的數據操作，不需要把子模塊的所有功能都帶進來，但不容許什麼都不做。)

+黑盒測試用例設計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落裏，聚集在邊界上。”

-因果圖法彌補等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,clearcase等實現，以保證測試是可重複的。

+常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數據狀態，甚至對用戶產生誤導。

·表達不清或過於模糊的信息提示。

·要求用戶輸入多餘的本來系統可以自己得到的數據。

·爲了得到某個設置或對話框用戶必須做許多冗餘的操作，如對話框嵌套太多。

·不能記憶用戶的設置或操作習慣，使每次進入系統用戶都需重新操作一次初始環境。

·不經用戶確認就對系統或數據進行了重大修改。

-形象類問題

·不符合用戶的操作習慣。如，快捷鍵定義不科學不實用，甚至無快捷鍵。

·不夠專業，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業：中英文不對應，標點的半全角問題，沒有排版準則。

·界面元素參差不齊，文字不能完全顯示。

－穩定性問題

·不可重現的死機，或不斷申請但不能完全釋放資源，使系統性能越來越低。

·主系統和子系統使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數據庫字段名或登陸帳號。

·不能重現的錯誤，許多與代碼中的未初始化變量有關，有些與系統不檢查異常情況(網絡中斷、內存申請不成功、長時間無響應等)有關。

-其他問題

·運行時不檢查內存、硬盤空間、數據庫等。

·無根據的假設用戶環境：硬件/網絡情況；有些動態庫；假設網絡隨時都是聯通的。

·提供的版本帶病毒。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現場開放和修改，又沒有記錄和保留。

·版本中部分內容或接口倒退，或出現版本管理混亂。

·有些選項永遠都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗餘的嗎？

-每個測試步驟都有清楚描述的預期結果嗎？

+優先級

+3級

優先級1：此測試用例必須執行-2：有時間就執行-3：可以不執行

+5級

1：此測試必須通過，否則產品發佈存在危險2：在發佈前必須執行3：時間允許就執行4：此測試可以在下一次發佈或發佈後短期內執行5：可以不測試

第二篇：軟件測試技術面試總結

軟件測試就是爲了發現程序中的錯誤而分析和執行程序的過程。——概念

+基本知識+軟件開發過程-定義-計劃-實現-穩定化-部署

+軟件開發模型(四種典型的模型)

+瀑布模型

-概述：包括計劃，需求分析，設計，編碼，測試，運行維護六個階段。六個階段自上而下、相互銜接，以固定的次序進行。

-特點：1.階段的順序性和依賴性；2.文檔驅動； 3.推遲實現的觀點；4.質量保證。-缺點：不適合需求模糊的系統

+原型模型-概述：先建立一個能夠反映用戶需求的原型系統，使得用戶和開發者可以對目標系統的概貌進行評價和判斷，然後對原型系統進行反覆的擴充、改進、求精，最終建立符合用戶需求的目標系統。

-特點：1.快速開發工具；2.循環； 3.低成本。

-分類：按照對原型的處理方式，可以分爲漸進型和拋棄型。

+增量模型

-概述：在增量模型中每個階段都生成軟件的一個可發佈版本，階段交錯進行，版本逐漸完善。

-同原型模型的最大區別在於，在原型模型中每個階段發佈一個原型而在增量模型中則完成一個正式版本。+螺旋模型

-概述：適用於大型軟件的開發，它將瀑布模型和快速原型模型結合起來，並加入了風險分析。

-特點：1.每個階段都包括制定計劃，風險分析，實施工程，評審四個階段；

2.開發過程迭代進行，每迭代一次螺旋線增一週，工程前進一個層次，系統生成一個新版本， 投入新的時間成本，最終得到客戶滿意的版本。

-軟件測試從需求開始：現代的軟件測試將測試滲入到軟件開發的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設計階段，測試人員便已經開始了他們的工作，如：瞭解軟件需求，編寫測試計劃，搭建測試環境。

-測試用例

-三要素：前提條件和操作步驟、預期結果、實際結果。

-必須以需求爲依據。

-軟件測試分類

-是否關注軟件結構和算法

-黑盒測試：基於軟件需求的測試方法。

-白盒測試：基於軟件內部設計和程序實現的測試方法。

-是否執行被測試軟件

-動態測試：在測試過程中執行被測試軟件的測試方法。

-靜態測試：------------不----------------------。

-基於不同的測試階段：

-單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅動程序，採用白盒測試的方法，一般由 開發人員完成。

-集成測試：將一些“構件”集成在一起時測試他們是否能正常運行，構件可以是程序模塊，也可以是

客戶機-服務器程序等，需要編寫測試仿真程序，採用白盒和黑盒(收藏好 範 文，請便下次訪問：)相結合的方式，通常由 開發人員承擔。

-系統測試：測試軟件系統是否符合所有的需求，包括功能性測試和非功能性測試。一般由

獨立的測試

人員完成，通常採用黑盒測試方法。

-驗收測試：(α、β)與系統測試類似，但由客戶或最終用戶執行，測試軟件是否符合需求規格說明書。

-迴歸測試：指在軟件開發過程中，每次錯誤被修正後或軟件的功能、環境發生變化後進行的測試。

-軟件測試的三個步驟：

-測試計劃：測試人員首先對需求進行分析，最終定義一個測試集合，通過刻畫和定義測試發現需求中的

問題，然後根據軟件需求同測試主管制定並確認“測試計劃”。

-測試設計和開發：軟件測試人員根據軟件需求和軟件設計說明書完成測試用例的設計和必要的測試驅動 程序的開發。

-執行測試：需要做的工作包括搭建測試環境、運行測試、記錄測試結果、報告軟件缺陷、跟蹤軟件缺陷、

分析測試結果，必要時進行迴歸測試。

-測試工程師的能力要求：

+5c

-controlled /ken'treuld/ 接受管理，有條理的

-competent /'kcmpitent/瞭解正確的測試技術

-critical /'kritikel/專注於發現問題

-comprehensive /ri'hensiv/ 注意細節

-considerate /ken'siderit/能夠和開發人員很好的交談

+職業素質 -責任心-學習能力-懷疑精神 -溝通能力 -專注力-洞察力 -團隊精神-注重積累 +制定測試計劃的五個步驟：-分析和測試軟件需求-定義測試策略

-定義測試環境

-定義測試管理

-編寫和審覈測試計劃

如果在需求分析階段發現並結果問題需要花費$1，則在設計階段解決同樣的

問題需花費$5，在編碼階段需$10，交付後解決同樣的問題需花費$200。——越早測試越好 -在需求分析過程中測試人員需要進行如下工作：

1)理解需求，參與審覈需求文檔；

2)理解項目的目標、限制，瞭解用戶的應用背景；

3)編寫測試計劃；

4)準備測試資源。

+需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進行測試。

+好的需求文檔的特徵 -具有清晰的格式和文檔結構 -需求的內容正確 -需求的內容完整-需求具有可行性需求的必要性

-對不同的需求優先等級進行定義 -描述明確-可證性和可測試性 -可修改性-可追蹤-需求文檔被及時更新

+需求測試內容

-需求文檔是否符合公司的格式要求

-是否正確

-要保證需求文檔中所描述的內容是真實可靠的

-這是“真正的”需求嗎？描述的產品是否是要開發的產品？

-需求是否完備？第一個發佈的版本是否需要更多的功能？列出的需求可以減少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可實現？如：需求設想的設備是否比實際運行的要快？需求要求的內存、i/0設備是否太多？

需求的輸入或輸出設備要求的分辨率是否要求過高？

-需求是否合理？在開發進度、開發費用、產品性能、可靠性和內存使用之間存在着平衡關係。

-需求是否可測？對於軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。+需求測試方法-複查review-走查walkthrough -審查inspection

+測試策略的內容

-確定測試範圍 軟件是無法被完全測試的

-確定測試方法 不同的系統需要不同的測試方法

-定義測試標準 入口標準，暫停和繼續的標準，出口標準等

+軟件測試結束的標準

-基於測試用例的使用規則

1)構造測試用例（由相關人員進行評審）

2)執行測試用例中，當測試用例的不通過率達到20%則拒絕繼續測試，待開發人員修正軟件後再繼續。

3)當功能性測試用例通過率達到100%，非功能性測試用例通過率達到90%時，允許正常結束。

-基於“測試期缺陷密度”規則

--------------含義：對軟件測試一個cpu小時發現的缺陷數，比較適用於系統測試-基於“運行期缺陷密度”規則

--------------含義：把軟件運行一個cpu小時發現的缺陷數，比較適用於驗收測試注：一個階段的出口標準!=下一個階段的入口標準

系統測試結束的標準!=軟件的發佈標準

發佈標準!=軟件0缺陷

-選擇測試工具 是否需要，需要什麼工具，怎麼獲取

-降低軟件測試代價是企業普遍關注的問題，可通過

a.減少冗餘和無價值的測試；

b.減少測試階段(萬般無奈下)

+測試環境

-基本內容：設備環境、軟件環境、數據環境

-需考慮的因素 -計算機平臺-操作系統 -瀏覽器 -軟件支持平臺 -外圍設備 -網絡環境 -其他專用設備

-搭建測試環境時的配置原則：-使用的頻度或範圍-實效的可能性-最大限度的模擬真實環境 +測試管理 由於測試工程中設計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進行管理

-選擇缺陷管理工具和測試管理工具

-定義工作進度

-建立風險管理計劃

+可能遇到的風險

·由於設計、編碼階段出現大量質量問題，導致測試工作量時間增加

·開始測試時所需的硬件、軟件沒有準備好

·未能完成對測試人員的技術培訓

·測試時的人力資源安排不足

·測試過程中，發生了大量的需求變更

·測試過程中，項目的開發計劃被大幅度調整

·不能及時準備好測試所需的環境

·不能及時準備好測試數據

+風險管理的過程

·識別風險

·評估風險

·制定對策

·跟蹤風險

+測試設計與開發

+總體設計

-投入產出：測試設計的輸入是測試計劃，輸出是評審過的測試用例集合

-定義設計目標遵循的原則

-清楚地說明沒項測試的目標

-使每項測試的目標單一，可以對應到規格說明書中的一項需求

-只說明測試應該完成什麼工作，而不說明如何完成

-流程：總體設計-開發測試用例-評審測試用例

i.定義設計目標

ii.定義輸入說明

iii.定義測試環境和配置

iv.測試設計文檔

v.開發測試用例

+測試用例

-概念：爲特定目標開發的測試輸入、執行條件和預期結果的集合。

+好的測試用例：

-容易發現軟件的錯誤

-精確的重複某測試失敗的情景，可重複性

-清晰的定義一個或多個期望的結果

-沒有冗餘

+測試用例的作用

-指導測試的實施

-作爲編寫測試腳本的“設計規格說明書”

-評估測試標準的度量基準

-分析缺陷的標準

+白盒測試用例設計

+設計方法

+邏輯覆蓋法

-語句覆蓋

-判定覆蓋

-條件覆蓋

-判定-條件覆蓋

-條件組合覆蓋

-路經覆蓋

-基本路經法

+輔助模塊設計

-驅動模塊：相當於被測程序的主程序。接受測試數據，把這些數據傳給被測模塊然後輸出實際測試結果。

-樁模塊：用於調用被測模塊調用的子模塊。可以做少量的數據操作，不需要把子模塊的所有功能都帶進來，但不容許什麼都不做。

+黑盒測試用例設計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落裏，聚集在邊界上。”

-因果圖法彌補等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,clearcase等實現，以保證測試是可重複的。 +常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數據狀態，甚至對用戶產生誤導。

·表達不清或過於模糊的信息提示。

·要求用戶輸入多餘的本來系統可以自己得到的數據。

·爲了得到某個設置或對話框用戶必須做許多冗餘的操作，如對話框嵌套太多。·不能記憶用戶的設置或操作習慣，使每次進入系統用戶都需重新操作一次初始環境。·不經用戶確認就對系統或數據進行了重大修改。

-形象類問題

·不符合用戶的操作習慣。如，快捷鍵定義不科學不實用，甚至無快捷鍵。

·不夠專業，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業：中英文不對應，標點的半全角問題，沒有排版準則。·界面元素參差不齊，文字不能完全顯示。

－穩定性問題

·不可重現的死機，或不斷申請但不能完全釋放資源，使系統性能越來越低。

·主系統和子系統使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的

數據庫字段名或登陸帳號。

·不能重現的錯誤，許多與代碼中的未初始化變量有關，有些與系統不檢查異常情況(網絡中斷、內存申請

不成功、長時間無響應等)有關。

-其他問題

·運行時不檢查內存、硬盤空間、數據庫等。

·無根據的假設用戶環境：硬件/網絡情況；有些動態庫；假設網絡隨時都是聯通的。·提供的版本帶病毒。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現場開放和修改，又沒有記錄和保留。

·版本中部分內容或接口倒退，或出現版本管理混亂。

·有些選項永遠都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗餘的嗎？

-每個測試步驟都有清楚描述的預期結果嗎？

+優先級

+3級

優先級1：此測試用例必須執行-2：有時間就執行-3：可以不執行

+5級

1：此測試必須通過，否則產品發佈存在危險2：在發佈前必須執行3：時間允許就執行4：此測試可以在下一次發佈或發佈後短期內執行5：可以不測試

第三篇：軟件測試方法和技術—課程總結作業

軟件測試方法和技術 課程總結作業 2014-2014學年第一學期

軟件測試方法和技術

課程總結作業

1、提交期限和方法

期限：第17週週2晚。

方法：由各班學習委員收集所有學生的紙質作業上交到授課老師處，其中電子檔報告以e-mail提交給任課教師（可發郵箱： ）。

2、實驗任務

任務1：（30分）判斷三角形類的核心代碼如下：

/** 判斷三角形的類 */

public class triangletestmethod {

/** 判斷三角形的種類。參數a, b, c分別爲三角形的三邊，

* 返回的參數值爲0，表示非三角形；

* 爲1，表示普通三角形；

* 爲2，表示等腰三角形；

* 爲3，表示等邊三角形。

*/

public static int comfirm(int a, int b, int c) {

if((a + b > c) && (b + c > a) && (a + c > b)) // 判斷爲三角形{if((a == b) && (b ==c)) // 判斷爲等邊三角形

return 3;

if((a == b) || (b == c) || (a == c)) // 判斷爲等腰三角形

return 2;

else // 判斷爲普通三角形

return 1;

}

else { // 爲非三角形

return 0;

}

}

}

要求：1、首先畫出程序的流程圖；

2、爲以上所示的程序段設計一組測試用例，要求分別滿足語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋。

3、對上述程序用基本路徑測試法設計測試用例；具體按下列步驟進行：

①

②

③

④

依據代碼繪製流程圖（參考書的流程圖，必須類似） 確定程序環路複雜度； 確定線性獨立路徑的基本集合； 設計測試用例覆蓋每條基本路徑 第 1 頁 共 2 頁

軟件測試方法和技術 課程總結作業 2014-2014學年第一學期 任務2：（20分）設有一個檔案管理系統，要求用戶輸入以年月表示的日期。假設日期限定

在1990年1月~2014年12月，並規定日期由6位數字字符組成，前4位表示年，後2位表示月。現用等價類劃分法設計測試用例，來測試程序的"日期檢查功能"。 任務3：（50分）用你已經設計好的系統或借用其他系統，來進行軟件系統測試，編寫出系統測試報告。

3、補充說明

課程總結作業必須自己獨立、認真完成，不得抄襲，如發現抄襲別人，則視本門課程爲不及格處理。希望大家切記。

第 2 頁 共 2 頁

第四篇：軟件測試轉正工作總結

本人自2014年6月25日起進入夢龍移通公司從事手機軟件測試工程師一職，在不知不覺中已經經過了2個月的試用期。在這段時間裏，我感悟頗多，雖然這並不是我的第一份工作，但是在此期間，我對於工作一貫謙虛謹慎、認真負責的工作態度，從來沒有改變過。

在本部門工作中，我一直嚴格要求自己，認真及時地完成領導佈置的每一項任務，並虛心向同事學習，不斷改正工作中的不足；配合各部門負責人落實及完成公司各項工作，

在過去的2個月中，通過不斷的學習和自我提高，已經適應了本職的工作，但對於一個初入公司的新人，要全面融入企業的方方面面，可能在一些問題的考慮上還不夠全面，但我相信，通過公司領導及同事的悉心指導，我一定會在今後的工作中更好的提高自己的水平、素質，更好的完成本職工作。

在今後的工作中，我要繼續努力，克服自己的缺點，彌補不足，向白盒測試、內部代碼測試方向瞭解，加強 軟件測試、計算機語言方面的知識，不斷自我學習，力爭成爲學習型、創新型、實幹型兼備的新世紀人才。

第五篇：軟件測試工程師年終工作總結

2014年終工作總結

一：2014年工作回顧及總結

回顧2014年這一年來的工作，我在公司領導及各位同事的支持和幫助下，嚴格要求自己，按照公司要求，比較好地完成了本職工作。通過近一年的學習和工作，工作模式上有了新的突破，工作方式有了較大的改變。現將這一年的工作情況總結如下：

1、總體來說，2014年我主要完成了“……銀行系統”、“……渠道管理平臺”、“……”、“……”、“……”“……”的日常測試以及質量控制工作；“……”已經穩定上線運行6個多月，“……”即將上線。

2、日常我主要負責項目測試工作、測試文檔編輯、參與功能需求設計、協調開發進度、總結經驗分享、完成所需知識積累、工具學習及研究、兼容性軟件測試。就在銀聯項目工作來說，主要的工作內容有：a、測試項目案例、測試用例的設計與編寫；b、對測試過程中遇到的問題進行溝通，並提供意見；c、設計業務功能流程，提供參考意見，繪製關鍵業務流程；d、進行主要功能的界面測試、功能測試；e、按照測試用例執行測試計劃；f、進行需求驗證工作

3、知識的總結與分享，完成客戶端在安卓4.0/4.1，ios6.0以上系統上出現的兼容等問題，完成了兼容性測試案例的編寫以及兼容性測試的培訓工作。在日常工作中，發現兼容上重大問題，在測試部門羣中發佈分享。

4、完成所需知識積累，學習所需知識、工具以及技能。在工作中學習了銀行業務流程規範、學習公司研發規範、參加了公司組織的技術培訓、學習了各種

測試工具的使用。

二：對公司的建議與意見

對公司和部門建設上，我有以下幾點建議：

1、對員工進行金融知識的系統培訓，讓測試人員瞭解銀行業務流程，有助於測試人員更加詳細瞭解業務流程，測試過程會少走很多彎路。

2、部門內希望多組織技術交流討論，促進測試工作的開展和提高。一年至少有2次這樣的交流。

3、公司在項目開發前期，希望儘可能的明確需求，儘可能的詳盡需求說明書內容。在測試過程中發現很多項目缺少需求說明書，需求說明書不明確或者需求說明書內容錯誤，誤導了開發和測試，浪費了時間，影響了項目進度。

4、建議項目需求設計可以有測試員參與討論。

5、公司管理有點混亂，個人感覺公司對每位員工的重視程度不夠！節假日公司應該給每位員工一定的福利和關心。

6、個人感覺平時的效率比較低，希望測試部門能夠有所調整。希望公司能制定質量控制標準以及開發、測試工作流程，讓開發更好的瞭解測試的流程，增強開發團隊與測試團隊的配合，提高工作效率。

7、加強部門測試成果的積累與沉澱，提高團隊測試水準，希望我們的團隊能夠做的更好，能夠已團隊的形式參與軟件項目的開發，而不僅僅是一個項目中毫不起眼的小小測試員。

三：2014年工作計劃與學習計劃

2014年工作計劃就是希望通過自己的努力，讓我們的產品更加完美，讓自己在軟件測試技能上有所提高，更多的關注軟件產品的開發過程，提高工作效率、做到與用戶的需求一致，提高公司軟件產品用戶滿意度。

具體來說2014年工作計劃有：努力提高自身測試水準，努力學習金融知識以及業務流程，學會需求分析，掌握需求分析在測試中的作用，參與公司更多的開發項目的測試工作。

********

201*年^月^日