時間：2023-06-04 10:46:22
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇軟件測試報告，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
關鍵詞：項目驅動法；軟件測試；教學方法
作者簡介：趙曉君（1979-），女，河南南陽人，鄭州輕工業學院軟件學院，講師；黃艷（1976-），女，河南信陽人，鄭州輕工業學院軟件學院，副教授。（河南 鄭州 450002）
基金項目：本文系鄭州輕工業學院校級青年教師教學改革項目的研究成果。
中圖分類號：G642.0 文獻標識碼：A 文章編號：1007-0079（2013）07-0101-02
隨著軟件產業的快速發展，軟件系統的規模越來越大，功能實現也越來越復雜，導致軟件中存在的缺陷數量大大增加，這些缺陷將會帶來各種損失，甚至出現災難性的后果。因此，如何保證軟件質量已成為所有使用軟件和開發軟件的人們關注的焦點。軟件測試作為軟件工程的一個重要組成部分，是目前用來驗證軟件是否能夠滿足用戶需求功能的唯一有效方法，是保證和提高軟件質量的重要環節。為適應軟件產業的發展趨勢和滿足軟件測試人才的大量需求，目前已經有許多大學在軟件工程專業添加軟件測試課程或者添加軟件測試專業方向。
軟件測試專業包含多門專業課程，有“軟件測試理論”、“軟件測試技術”和“軟件缺陷管理”等，其中，“軟件測試理論”課程重點為初學測試的同學講解測試的基礎理論知識，主要包括軟件測試基本理論、軟件測試方法和技術等，在多門專業課程中占有舉足輕重的地位。
一、“軟件測試理論”教學現狀
“軟件測試理論”課程重點介紹軟件測試的基本理論，因此整個課程主要以教師講授為主，在教學的過程中存在以下問題：
1.教學內容理論性較強，難以調動學生學習的主動性
對于初學軟件測試的學生，首先要向其講授相關測試理論，使其建立系統的測試理念。
但是學測試的學生大都是理科生，喜歡操作性強的課程，“軟件測試理論”課程的理論性太強，需要背誦很多概念性的知識，這對于他們來說是比較困難，不能激發學習的主動性，教學效果不理想。
2.測試方法和技術案例實際應用價值不足，學生很迷茫
測試方法和技術是“軟件測試理論”課程學習的重點和難點，這部分內容僅靠老師的講解和書本上的案例很難讓學生深入理解掌握測試技術的內涵，學生在學習這部分知識時會產生迷茫：學習這些知識有什么用處，在具體的項目測試中，應該怎樣應用這些知識？沒有實際的項目案例做支撐，學生會失去繼續學習下去的興趣。
針對上面的問題，本文提出將項目驅動法應用于“軟件測試理論”課程的教學中，學生在進行項目實踐的同時，根據需要學習軟件測試相關理論知識，這樣有助于提高學生的學習主動性，有助于理論知識的牢固掌握，有助于提高學生的實踐技術能力，改善該課程的教學效果。
二、項目驅動法
項目驅動法是目前中國教育領域中一種比較新的教育教學方法。
所謂項目驅動法，是師生通過共同實施一個完整的項目工作而進行的教學活動，它既是一種課程模式，又是一種教學方法。[1]這里的項目根據課程教學內容的不同所包含的涵義也不同。在“軟件測試理論”課程教學中，項目即指一個已經開發完成的軟件測試工作。通常，項目教學都是實踐導向的和任務驅動式的教學。
在項目驅動模式的教學活動中，教師根據學生現有的知識水平和項目經驗選擇一個合適的項目，以項目實施為主線展開教學活動，把課程相關的知識點的講解融入項目操作的每個步驟中。在項目實施的過程中，以學生為中心，教師主要做組織和指導工作，學生在整個項目的實施過程中處于探索知識的情景中，充分發揮主動性、積極性和創新精神，綜合運用所學的知識和技能解決實際問題，最終達到有效地將所學知識系統化深入化的目的。
這種模式從根本上將傳統課堂中老師滿堂灌轉變為“學生為主體，教師為主導”的教學模式。同時，學生通過一個具體項目的實踐，感受到了真實項目管理的思想和團隊協作的必要性，提高了學生的創新能力和項目實踐能力。擁有真實項目的實踐經驗使得學生在擇業時擁有很大競爭優勢。
將項目驅動法應用于“軟件測試理論”課程教學中，在課程理論教學中加入一個完整的項目測試實踐環節，通過項目實踐能夠很好地激發學生的學習主動性，使學生經歷了一個“先做，遇到問題，再學，解決問題，再做，獲得經驗”的學習過程，最終完成一個完整的軟件測試實踐，同時也學到了“軟件測試理論”課程應該掌握的理論知識。這樣，既解決了軟件測試理論課程理論性太強的問題，又解決了測試方法和技術案例實際應用價值不足的問題；而且豐富了學生的實踐經驗，提高了軟件測試理論課程的教學效果。
三、“軟件測試理論”課程教學目標和教學內容
1.教學目標
通過本門課程的學習和實踐，理解軟件測試理論與原則；掌握主流測試技術和方法，熟悉測試用例的編制、熟悉軟件測試的基本流程，熟悉軟件測試過程中各類技術文檔的編制規范，并能靈活運用測試技術解決實際問題。
對于一個具體項目軟件，每一個學生都能夠順利完成如下手工測試流程：根據軟件需求規格說明書撰寫測試計劃，設計測試用例、進行測試環境配置和測試數據準備工作、執行各種測試，撰寫缺陷報告、跟蹤并修復缺陷、進行測試評測，最后提交測試總結報告，達到軟件企業對測試專業人才的要求。
2.教學內容
“軟件測試理論”課程的教學內容主要包括軟件測試基本理論、軟件測試基本技術、軟件測試過程和軟件測試工具。[2]
軟件測試基本理論包括軟件測試、軟件缺陷和測試用例的基本概念，測試的目的、測試模型、測試分類和測試流程。
軟件測試基本技術包括白盒測試和黑盒測試；其中白盒測試包括靜態測試和動態測試，動態測試又包括程序插樁、邏輯覆蓋、基本路徑測試等；黑盒測試包括等價類劃分、邊界值分析、因果圖法、判定表法、場景法等。這些基本技術都是在進行測試用例設計時使用的。
軟件測試過程是指執行測試的過程，通常分為四個階段：單元測試、集成測試、系統測試和驗收測試。
軟件測試工具有多種：功能測試工具、性能測試工具和測試管理工具等。
四、項目驅動法的應用方案
1.項目的設計
實施項目驅動法，首先需要設計項目。項目的設計與選取直接影響到該教學模式的教學效果及學生的學習興趣。“軟件測試理論”課程項目的選取與其他課程又有所不同，學生要進行的操作是對現有的或者已經開發完成的軟件的測試工作，因此在設計項目時應遵循以下幾條原則：
第一，項目是現有的軟件或已經開發完成的軟件，軟件中有部分明顯錯誤，有部分隱藏錯誤；明顯錯誤有助于提高學生的測試積極性，隱藏錯誤有助于啟發學生進行更深入的測試。
第二，項目具有典型性，代表大部分軟件的共性。通過該項目的測試，學生可以掌握大多數軟件的測試流程和測試方法。
第三，項目中有多種情景元素，符合使用多種測試技術和方法，有助于學生在進行項目測試的同時，學習使用多種測試技術設計測試用例的方法。
第四，項目大小和難易適中。每個項目組的人數控制在3～5個人，設計的項目能使學生通過努力在一定的時間內完成。
根據以上原則，本課程目前選擇的項目是《企業薪酬管理系統》。
2.項目驅動法的實施
本課程通過讓學生進行企業薪酬管理系統完整的測試流程實踐的同時，講解測試需求編寫、測試計劃編寫、測試用例設計、測試環境配置、測試執行、缺陷跟蹤和管理、測試報告撰寫等內容。課程授課方式主要是分階段講解測試過程和測試要求，每一個階段開始，老師先講原理，選擇部分內容做例子進行講解，然后學生比照例子跟著做；階段內容完成時，學生提交完成的文檔，老師選擇典型的問題進行講評，然后進行下一個階段的內容，如此類推直至測試結束。
企業薪酬管理系統測試流程設計如圖1所示。
本課程課時為60學時，根據圖1系統測試流程圖安排，基于項目驅動法的“軟件測試理論”課程安排如表1所示。
在課程進行的過程中，必須嚴格按照項目的測試流程進行，測試流程為：先獲取項目測試需求，撰寫測試計劃，設計測試用例，執行測試，提交缺陷報告并跟蹤修復缺陷，最后提交測試總結報告。課程結束，要求學生提交項目測試報告，測試報告包括多個文檔，整個流程中每個階段的工作必須有撰寫規范的文檔提交，如：測試計劃、測試用例、測試執行報告、缺陷報告和測試總結報告等等。
測試報告既體現了教師項目教學的結果，也體現了學生對測試知識技能的掌握水平。通過評價學生作品，找出學生在學習過程中的薄弱環節，進一步改進項目驅動教學的教學安排，使其能夠發揮最大的教學效果。
五、結束語
本文針對軟件學院軟件工程專業的培養對象和教學特點，把真實項目引入“軟件測試理論”課程課堂教學中，采用項目驅動教學法，從項目的需求評審、測試計劃、測試用例設計、測試執行、缺陷報告、測試評測到測試總結一個完整的測試流程，交給學生組建測試團隊，按照流程進行任務分配和管理，最終完成整個項目的測試工作。通過一個完整項目測試流程的完成，有效提高學生的學習和實踐能力、解決問題的能力、團隊協作能力等，使學生在掌握軟件測試的各種測試技術和基本流程的同時，積累了一定的項目測試經驗，為他們今后的就業打下了良好的基礎。
參考文獻：
關鍵詞：實時嵌入式軟件；軟件測試；腳本
中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9599 (2011) 18-0000-02
Real-time Embedded Software Testing Research
Zhang Feng,He Yingjie,Wang Bin
(No.91413 Troops of PLA,Qinhuangdao 066000,China)
Abstract:The development and application of embedded real-time software is a hotspot of computer software nowadays.It’s very important to ensure the quality of embedded real-time software.This article analyzes the characteristics of embedded real-time software.Based on the analysis of the whole structure of the embedded real-time software testing and the architecture of host and target computer,this article discusses script language and its interpretation,at last introduces testing result analyze implement and creates testing report.
Keywords:Real-time embedded software;Software testing;Script
一、引言
當今社會信息化進程的快速發展，計算機軟件在各個領域得到了越來越廣泛的應用，尤其是在工業控制、電子信息以及武器裝備等很多嵌入式系統中發揮著核心作用。隨著嵌入式技術的發展和計算機硬件技術的進步，硬件元件的集成量也大大增加，從而使嵌入式設備的硬件性能得到了極大的提高。嵌入式系統的發展趨勢是：硬件逐漸向通用性平臺過渡，依靠軟件來完成系統的各種任務。因此，軟件已成為決定系統成敗的關鍵性因素。在嵌入系統開發中軟件的代碼質量對產品的最終質量起到了決定性的作用。
軟件質量是軟件的生命，軟件測試是保證軟件產品質量的重要手段。因此，要成功開發出高質量的軟件產品，必須加強軟件測試工作。本文將提出一種對實時嵌入式軟件進行測試與分析設計的一種測試方法。
二、實時嵌入式軟件的特點
（一）開發與運行環境分開
嵌入式軟件最終的運行平臺是在目標機上，但是由于目標機中的環境有種種限制，因此，嵌入式軟件的開發不能在目標機上進行，而是在目標機之外的PC上進行，即我們所說的宿主機。在宿主機上完成軟件開發后，再將軟件程序移植到目標機上運行。也就說，嵌入式軟件的開發環境和運行環境是不一致的。正是這個不同，給嵌入式軟件的測試帶來了不少的麻煩。
（二）開發平臺復雜多樣
因為嵌入式系統的一個突出特點是其專用性，即一個嵌入式系統只進行特定的一項或幾項工作，嵌入式軟件運行的硬件平臺都是為進行這些工作而開發出來的專用硬件電路，它們的體系結構、硬件電路，甚至所用到的元器件都是不一樣的，所以嵌入式軟件運行平臺（通常稱為開發平臺）也是復雜多樣的。
（三）硬件資源、時間有嚴格限制
由于嵌入式系統的專用性，嵌入式軟件運行的硬件平臺的硬件資源是相當有限的。另外，由于嵌入式系統的實時性，決定了嵌入式系統的運行時間也是嚴格限制的。實時軟件的時間約束主要表現為軟件或其中的進程的時間約束。通常，實時系統可分為：硬實時系統和軟實時系統。硬實時系統中，處理請求的時間約束異常關鍵，即未滿足約束的處理請求被認為是系統的失敗。而軟實時系統中的時間約束只是希望被滿足，即使不滿足也不會引發系統失敗。這種軟、硬實時系統的劃分，實際上是刻畫了實時軟件中時間特性強度，它對于軟件的時間特性設計和測試有著重要的影響，決定了它在測試中的花銷，即是否為時間特性進行單獨。
（四）缺乏可視化編程模式
由于嵌入式軟件最終要在目標機平臺上運行，而其開發只能在宿主機平臺上進行，編程的結果只能在代碼完成并通過相應的調試器和編譯器然后下載到目標機平臺上才能看到，無法實現可視化編程。
（五）不同的嵌入式軟件在不同環境下的可靠性、安全性的要求是不同的
一些嵌入式系統，比如軍隊的雷達、電子對抗系統，它們要在電磁很強的惡劣的環境下可靠地工作，而且要保證操作人員的安全。但是對于手機軟件來說，它的可靠性和安全性就不如電子武器軍事裝備要求的高。
三、實時嵌入式軟件測試
實時嵌入式軟件的突出特點在于其運行環境（目標機環境）和開發環境（宿主機環境）的不一致，這一特點也導致典型的實時嵌入式軟件測試要從宿主機下載到目標機上進行測試。
（一）實時嵌入式軟件測試的總體體系結構設計
實時嵌入式軟件測試的一般步驟是在主機上編寫測試代碼，然后把該代碼編譯下載到目標機，接著通過測試執行該測試目標代碼。測試工具運行在宿主機上，測試所需要的信息在目標機上產生，由于目標機的資源相當匱乏，測試后所得的信息在目標機上不便分析，通過主機和目標機之間的通信把測試所得信息上傳回主機，再由主機中的測試結果分析工具對測試信息進行分析。嵌入式測試基本結構如圖1所示。
（二）實時嵌入式軟件測試宿主機及目標機的體系結構設計
如圖2所示，在宿主機方，在測試開始前制定測試計劃，根據不同的測試目的選擇相應的測試用例，生成測試腳本，通過腳本解釋器實時解釋非實時生成的測試命令，并將測試命令和數據通過目標服務器發送至被測目標系統；同時將從目標機上的測試獲得測試結果數據后，可顯示測試結果，以提示測試人員，還可以由測試結果分析工具對測試結果進行分析，最后傳送回測試結果數據庫，并生成測試報告。在目標機方，測試接收測試命令后運行被測實時嵌入式應用軟件，被測應用軟件將測試后生成信息發送到測試中的一個專門任務的消息隊列中，此任務負責在適當的時候將這些信息發送到宿主機方。同時目標服務器中也有負責接收測試所得信息的專門任務，它從目標機上的測試獲得測試結果數據。
四、腳本語言及腳本語言解釋器
（一）腳本語言
實時嵌入式軟件測試腳本語言的設計：在腳本化的實時嵌入式軟件測試中，測試腳本語言的設計非常關鍵，根據實時嵌入式軟件測試的特點和腳本化的嵌入式軟件測試的實現機制，我們采用對結構化的腳本語言進行擴展的方式，即在通用結構化語言的詞法、語法的基礎上加入針對實時嵌入式軟件測試特性的描述。通用結構化語言是指在C語言的基礎上，進行C簡化，保留不可缺少的、可用于實時嵌入式軟件測試的結構化特性，而省去一些測試中不必要的特性。我們設計的腳本語言包括控制命令和消息命令兩大部分。控制命令是對測試執行的流程進行控制，如整數變量、循環（for）、條件判斷（if⋯else）、暫停（pause）、中止（stop）、腳本執行開始段（begin）、腳本執行中止段（end）等。而消息命令由一個主要的命令組成，就是msg命令，msg命令后面有五個參數，分別是被測試對象的進程號、發向被測試對象的消息號、被測試的消息內容、消息內容參數1、消息內容參數2。這五個參數就可以決定目標嵌入式系統執行何種測試。
（二）腳本語言解釋器
1.腳本語言。軟件測試中，實現軟件測試自動化技術的有效手段是腳本技術的引入。軟件測試腳本化可以減少測試人員的工作量，提高軟件測試的可維護性，實現軟件測試過程中用戶和被測軟件之間的交互。同時由于解釋性的腳本語言可移植性好，有利于實現跨平臺，可提高腳本代碼的可重用性，提高測試的可重復性。測試腳本是具有正規語法的數據和指令的集合。在軟件測試過程中，測試腳本通常以文本形式存在，由測試腳本組織用戶所施加的一系列軟件執行動作，達到驅動被測軟件運行的目的，從而完成測試。
2.腳本解釋器。根據實時嵌入式軟件測試腳本語言的設計，設計針對該語言的解釋器。腳本語言解釋器是腳本語言的支撐，解釋器設計的成功與否直接關系到能否實現腳本化的實時嵌入式軟件測試。針對上述腳本語言設計中所提到的用戶施加的測試命令及其特性，則需要處理測試中各命令的時間要求以及命令之間的并發同步等問題，解釋器應由兩部分組成，即控制部分和解釋部分。控制部分的作用在于對測試腳本進行預處理，提取各種命令的執行腳本，生成按時間排列的命令表，然后根據實時調度時鐘信號和條件判斷觸發解釋部分的調用，借助在控制部分中的多命令處理方式可以保證測試中各種命令的并發和同步的處理，從而保證了實時嵌入式軟件測試中對實時特性的要求；解釋部分的工作原理是在控制部分按時鐘信號觸發后，加載需要解釋的腳本執行代碼，腳本源代碼首先由詞法分析器進行詞法分析，分離出標識符、關鍵字和變量名等，然后由語法分析器根據語法定義，分析源程序的語法正確性并根據語義執行相應的語義動作。最后生成測試命令并通過目標服務器下載到目標機上，以驅動被測軟件的運行。
五、測試結果分析工具及測試報告生成
測試結果分析工具包括內存分析工具、性能分析工具、覆蓋分析工具等。
內存分析工具：在嵌入式系統中，內存約束通常是有限的。內存分析工具用來處理在動態內存分配中存在的缺陷。當動態內存被錯誤地分配后，通常難以再現，可能導致的失效難以追蹤，使用內存分析工具可以避免這類缺陷進入功能測試階段。
性能分析工具：在嵌入式系統中，程序的性能通常是非常重要的。經常會有這樣的要求，在特定時間內處理一個中斷，或生成具有特定定時要求的一幀。開發人員面臨的問題是決定應該對哪一部分代碼進行優化來改進性能，常常會花大量的時間去優化那些對性能沒有任何影響的代碼。性能分析工具會提供有關的數據，說明執行時間是如何消耗的，是什么時候消耗的，以及每個例程所用的時間。根據這些數據，確定哪些例程消耗大部分執行時間，從而可以決定如何優化軟件，獲得更好的時間性能。對于大多數應用來說，大部分執行時間用在相對少量的代碼上，費時的代碼估計占所有軟件總量的5%～20%。性能分析工具不僅能指出哪些例程花費時間，而且與調試工具聯合使用可以引導開發人員查看需要優化的特定函數，性能分析工具還可以引導開發人員發現在系統調用中存在的錯誤以及程序結構上的缺陷。
覆蓋分析工具：在進行白盒測試時，可以使用代碼覆蓋分析工具追蹤哪些代碼被執行過。分析過程可以通過插裝來完成，插裝可以是在測試環境中嵌入硬件.也可以是在可執行代碼中加入軟件，也可以是二者相結合。工具一般會提供有關功能覆蓋、分支覆蓋、條件覆蓋的信息。對于嵌入式軟件來說，代碼覆蓋分析工具可能侵入代碼的執行，影響實時代碼的運行過程。基于硬件的代碼覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測試代碼的數量。
以上測試結果分析工具可根據測試偏重點的不同選用相應比較成熟的商業分析工具。軟件測試報告的內容包括測試結果的統計信息，測試結果的分析、評判。我們可以用C語言中的fprintf函數實現測試報告的生成。
六、結束語
隨著我國軟件業的發展，作為軟件質量保證的重要組成的軟件測試已越來越受到重視，而軟件測試自動化工具由于可以提高軟件測試的有效性和效率，因此，軟件測試自動化工具的開發已成為軟件測試的一個重要研究領域。本文對實時嵌入式軟件測試進行了研究和設計，介紹了開發實時嵌入式軟件測試自動化中的一些關鍵技術的實現思想，該思想已成功地應用于公司的嵌入式操作系統軟件平臺測試，對該軟件平臺的質量和穩定性起到了很關鍵的作用。
參考文獻：
[1]康一梅,張永革.嵌入式軟件測試[M].機械工業出版社,2008,7
[2]于以序,何艷敏.實時嵌入式軟件測試研究[J].中國測試技術,2004,9
[3]飛思科技產品研發中心.實用軟件測試方法與應用[M].北京:電子工業出版社,2003
關鍵詞：.NET；軟件測試；業務管理系統；B/S模式
中圖分類號：TP3 文獻標識碼：A
1 引言（Introduction）
當前軟件項目需求飛速增長，軟件規模越來越大，軟件的質量問題也比較突出。多年以來，人們認識到要想高效率、高質量和低成本地開發軟件，必須以改善軟件生產過程為中心，全面開展軟件工程和質量管理手段，對軟件生產的管理亟待改進。因此，軟件測試在軍工、銀行、證券、保險、電信、控制、醫療軟件、電力等行業都得到的重視[1]。
根據國內專業的軟件測試技術網站在2014年做的2013年度軟件測試從業人員調查結果數據顯示，79%的軟件測試從業人員從事的測試工作類型為手工功能測試；其次是測試管理，比例為35%，如圖1所示。從數據分析，絕大多數的軟件測試從業人員都是從事手工功能測試工作，項目實施過程中難免涉及很多的信息交互、項目執行記錄等，此時測試過程的規范化管理就顯得尤為重要[2]。
開展軟件測試服務業務以來，積累的項目越來越多，所有的材料提交、補正、更新、進度查詢、報告或者證書領取通知等都通過工程師與企業聯系人的口頭交流方式（或者電話或者即時通訊軟件）來進行，經常一個項目做下來，需要經過與企業聯系人的多次、反復的溝通，既浪費人力物力又浪費時間，而且沒有辦法以書面的形式永久、正式記錄下每個軟件項目的實施過程。階段性統計幾乎全部靠人工計數，無法及時反應每個階段業務的分布情況。對軟件測試業務的過程管理亟待改進。
2 系統目標及需求（System goal and demand）
業務管理不只是管理業務、控制流程，還需要管理業務涉及的各個方面，例如：記錄業務執行過程中的狀態信息、相關附件等。而相應的，業務管理系統則是實現管理功能的軟件平臺[3]。本文預期實現的軟件測試業務管理系統整合現有資源，做到維護方便，改變目前重復勞動、記錄不便、無法電子存檔相關信息的狀況，實現后臺相關數據錄入方便，前臺數據展示及時全面。功能主要分為后臺錄入、編輯部分和前臺顯示、查詢部分。
前臺滿足用戶對軟件測試業務項目實施進度、相關新聞資訊的查詢。后臺實現對各軟件測試項目各類文檔的歸檔管理和各項目實施進度的記錄等功能，項目實施流程的監督和查詢，以及相關文件的上傳下載等功能。實現統計分析，支持統計數據Excel形式導入導出。
該項目的實施便于相關人員對各類文檔進行統一歸檔管理，記錄項目實施流程的各個環節一些需要備注的信息，進一步規范化工作。
3 系統設計（System design）
3.1 系統業務流程分析
系統的業務流程如圖2所示。
3.2 系統主要功能模塊
業務管理系統分為前臺展示查詢部分和后臺編輯管理部分，主要功能模塊有：業務數據錄入管理、統計分析、軟件企業信息庫、相關下載、系統管理等。其中業務數據錄入、統計分析、軟件企業信息庫為本項目的核心部分。
按照建設要求設計實現網站，對業務相關的各類文檔進行歸檔管理，并實現用戶對所實施軟件技術服務項目流程的監督和查詢。
（1）前臺頁面，企業或個人用戶通過輸入準確的軟件產品名稱和委托企業名稱即可查詢軟件測試項目的實施進度。在沒有登錄的情況下只能進行精確查詢，登錄了以后可以進行模糊查詢。
（2）前臺頁面，已經登錄的企業或個人用戶可以在線提交軟件測試或著作權登記需求，并上傳相關文件。
（3）軟件測試項目實施進度分為：電子文檔在審、電子文檔已審、紙質材料受理、紙質材料受理結束并已繳費開發票、測試過程中、回歸測試、測試過程結束、出具測試報告、企業領取報告、項目完結。
（4）后臺頁面：實施的軟件項目列表可詳細列出所有受理的項目信息，支持Excel導出；軟件項目對應可以上傳相關文檔，每個軟件對應一個文件夾。
（5）后臺頁面：可按照一個或者幾個所選年度內所申報的軟件進行查詢統計，年度以受理日期為準。實現按年度、產品類型統計項目個數。支持盡量多的字段進行查詢和排序，后臺支持模糊查詢。
3.3 數據存儲結構設計
本系統的數據庫服務器采用SQL Server2005，在.NET平臺上對數據的存取通過來實現。包括五個主要部分：Connection負責連接應用程序和需要訪問的數據庫，DataAdapter提交并獲取查詢結果，Command對象執行數據庫查詢、添加、刪除、或者返回特定表內容的直接請求。DataReader對象一次存取一條記錄，減少內存占用量，提高了應用程序的性能[5]。
根據需要實現的功能，為業務管理系統建立數據庫，主要由用戶信息表、軟件測試項目信息表、項目所處狀態類型表、軟件企業信息表、軟件測試類別表、文檔資源表等組成。
（1）軟件測試項目信息表：軟件測試項目信息表是整個業務系統的核心，主要記錄項目編號、產品名稱及版本號、委托單位、開發單位、項目開發平臺、開發語言、紙質材料受理日期及受理人員、測試項目繳費情況、項目進展狀態、測試人員、測試日期、測試地點、項目聯系人及聯系電話、測試報告編號、報告接收人、上傳的相關文檔等。此表以項目編號為主鍵，同時作為外鍵與其他表關聯。
1 . 軟件測試 的目的是盡可能多的找出軟件的缺陷。( Y)
2 .Beta 測試是驗收測試的一種。( Y)
Acceptance testing
驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。
3 .驗收測試是由最終用戶來實施的。( N )
是由測試人員來實施的
4 .項目立項前測試人員不需要提交任何工件。( Y ) 工件：加工過程中生產對象
5 .單元測試能發現約80% 的軟件缺陷。( Y )
6 .代碼評審是檢查源代碼是否達到模塊設計的要求。( N )
代碼評審也稱代碼復查，是指通過閱讀代碼來檢查源代碼與編碼標準的符合性以及代碼質量的活動。
7 .自底向上集成需要測試員編寫驅動程序。( Y )
自頂向下綜合測試的具體步驟為：
1 以主控模塊作為測試驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代;
2 依據所選的集成策略(深度優先或廣度優先)，每次只替代一個樁模塊;
3 每集成一個模塊立即測試一遍;
4 只有每組測試完成后，才著手替換下一個樁模塊;
5 為避免引入新錯誤，須不斷地進行回歸測試(即全部或部分地重復已做過的測試)。
自底向上綜合測試的步驟分為：
1 把低層模塊組織成實現某個子功能的模塊群(cluster);
2 開發一個測試驅動模塊，控制測試數據的輸入和測試結果的輸出;
3 對每個模塊群進行測試;
4 刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。
8 .負載測試是驗證要檢驗的系統的能力最高能達到什么程度。( N )
負載測試(Load testing)，通過測試系統在資源超負荷情況下的表現，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征。例如，響應時間、事務處理速率和其他與時間相關的方面。
9 .測試人員要堅持原則，缺陷未修復完堅決不予通過。( N )
10 .代碼評審員一般由測試員擔任。( N )
11 .我們可以人為的使得軟件不存在配置問題。( N )
是一種標識、組織和控制修改的技術。軟件配置管理應用于整個軟件工程過程。我們知道，在軟件建立時變更是不可避免的，而變更加劇了項目中軟件開發者之間的混亂。
12 .集成測試計劃在需求分析階段末提交。( N )
執行階段
1)時間安排 單元測試已經完成后就可以開始執行集成測試了
2)輸入 需求規格說明書 概要設計 集成測試計劃 集成高度設計 集成測試例 集成測試規程 集成測試代碼(如果有) 集成測試腳本 集成測試工具 詳細設計 代碼 單元測試報告
3)入口條件 單元測試階段已經通過基線化評審
4)活動步 驟 執行集成測試用例 回歸集成測試用例 撰寫集成測試報告
5)輸出 集成測試報告
6)出口條件 集成測試報告通過集成測試階段基線評審
二、選擇題
1 .軟件驗收測試的合格通過準則是：(ABCD)
A . 軟件需求分析說明書中定義的所有功能已全部實現，性能指標全部達到要求。
B . 所有測試項沒有殘余一級、二級和三級錯誤。
C . 立項審批表、需求分析文檔、設計文檔和編碼實現一致。
D . 驗收測試工件齊全。
2 .軟件測試計劃評審會需要哪些人員參加?( ABCD )
A .項目經理
B .SQA 負責人
軟件質量保證(SQA)是建立一套有計劃
目標 1: 軟件質量保證工作是有計劃進行的。
目標 2: 客觀地驗證軟件項目產品和工作是否遵循恰當的標準、步驟和需求。
目標 3: 將軟件質量保證工作及結果通知給相關組別和個人。
目標 4: 高級管理層接觸到在項目內部不能解決的不符合類問題。
C .配置負責人
D .測試組
3 .下列關于alpha 測試的描述中正確的是：( AD )
A .alpha 測試需要用戶代表參加
B .alpha 測試不需要用戶代表參加
C .alpha 測試是系統測試的一種
D .alpha 測試是驗收測試的一種
4 .測試設計員的職責有：( BC )
A .制定測試計劃
B .設計測試用例
C .設計測試過程、腳本
D .評估測試活動
5 .軟件實施活動的進入準則是：( ABC )
A .需求工件已經被基線化
工件加工過程中的生產對象。
基線化 一個文檔如果經過討論被通過了，被固定了，就可以說這個文檔被“基線化”了，然后所有人就可以在這個“基線”的基礎上工作。
B .詳細設計工件已經被基線化
C .構架工件已經被基線化
D .項目階段成果已經被基線化
三、添空
1. 軟件驗收測試包括：_正式驗收測試，alpha測試，beta測試。
2. 系統測試的策略有：功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試
(有的可以合在一起，分開寫只要寫出15 就滿分哦)
3. 設計系統測試計劃需要參考的項目文擋有：_軟件測試計劃，軟件需求工件和迭代計劃。
4. 對
面向過程的系統采用的集成策略有：自頂向下，自底向上兩種。
5. 通過畫因果圖來寫測試用例的步驟為：
(1)根據程序規格說明書描述，分析并確定因(輸入條件)和果(輸出結果或程序狀態的改變)，畫出因果圖。
(2)將得到的因果圖轉換為判定表。
(3)為判定表中每一列所表示的情況設計一個測試用例。
四、簡答
1. 區別階段評審的與同行評審
答：
同行評審目的:發現小規模工作產品的錯誤,只要是找錯誤;
階段評審目的:評審模塊 階段作品的正確性 可行性 及完整性
同行評審人數:3-7人 人員必須經過同行評審會議的培訓,由SQA指導
階段評審人數:5人左右 評審人必須是專家 具有系統評審資格
同行評審內容:內容小 一般文檔 < 40頁, 代碼 < 500行
階段評審內容: 內容多,主要看重點
同行評審時間:一小部分工作產品完成
階段評審時間: 通常是設置在關鍵路徑的時間點上!
2. 什么是軟件測試
答：測試是為發現錯誤而執行程序的過程
軟件測試就是利用測試工具按照測試方案和流程對產品進行功能和性能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。執行測試用例后，需要跟蹤故障，以確保開發的產品適合需求。
3 簡述集成測試的過程
答：系統集成測試主要包括以下過程：
1. 構建的確認過程。
2. 補丁的確認過程。
3. 系統集成測試測試組提交過程。
4. 測試用例設計過程。
5. 測試代碼編寫過程。
6. Bug的報告過程。
7. 每周/每兩周的構建過程。
8. 點對點的測試過程。
9. 組內培訓過程。
5 白盒測試有幾種方法
答：總體上分為靜態方法和動態方法兩大類。
靜態：關鍵功能是檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義。
動態：語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。
6 系統測試計劃是否需要同行審批，為什么
答：需要，系統測試計劃屬于項目階段性關鍵文檔，因此需要評審。
7Alpha 測試與beta 的區別
Alpha測試(α測試)是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由程序員或測試員完成。Alpha測試發現的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員及時分析和處理。目的是評價軟件產品的功能、可使用性、可靠性、性能和支持。尤其注重產品的界面和特色。Alpha測試可以從軟件產品編碼結束之后開始，或在模塊(子系統)測試完成后開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之后再開始。有關的手冊(草稿)等應該在Alpha測試前準備好。
Beta測試(β測試)是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。因而，Beta測試是在開發者無法控制的環境下進行的軟件現場應用。在Beta測試中，由用戶記下遇到的所有問題，包括真實的以及主管認定的，定期向開發者報告，開發者在綜合用戶的報告后，做出修改，最后將軟件產品交付給全體用戶使用。Beta測試著重于產品的支持性，包括文檔、客戶培訓和支持產品的生產能力。只有當Alpha測試達到一定的可靠程度后，才能開始Beta測試。由于Beta測試的主要目標是測試可支持性，所以Beta測試應該盡可能由主持產品發行的人員來管理。
答：Alpha 測試 在系統開發接近完成時對應用系統的測試;測試后仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。
Beta 測試 當開發和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。
8 比較負載測試，容量測試和強度測試的區別
答：負載測試：在一定的工作負荷下，系統的負荷及響應時間。
強度測試：在一定的負荷條件下，在較長時間跨度內的系統連續運行給系統性能所造成的影響。
容量測試：容量測試目的是通過測試預先分 析出反映軟件 系統應用特征的某項指標的極限值(如最大并發用戶數、數據庫記錄數等)，系統在其極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。容量測試 還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。容量測試的目的是使系統承受超額的數據容量來發現它是否能夠正確處理。容量測試是面向數據 的，并且它的目的是顯示系統可以處理目標內確定的數據容量。
9 測試結束的標準是什么?
答：用例全部測試。
覆蓋率達到標準。
缺陷率達到標準。
其他指標達到質量標準。
10 描述軟件測試活動的生命周期?
答：
測試周期分為計劃、設計、實現、執行、總結。其中：
計劃：對整個測試周期中所有活動進行規劃，估計工作量、風險，安排人力物力資源，安排進度等;
設計：完成測試方案，從技術層面上對測試進行規劃;
實現：進行測試用例和測試規程設計;
執行：根據前期完成的計劃、方案、用例、規程等文檔，執行測試用例。
總結：記錄測試結果，進行測試分析，完成測試報告。
11 軟件的缺陷等級應如何劃分?
A 類— 嚴重錯誤，包括以下各種錯誤：
1 . 由于程序所引起的死機, 非法退出
2 . 死循環
3 . 數據庫發生死鎖
4 . 因錯誤操作導致的程序中斷
5 . 功能錯誤
6 . 與數據庫連接錯誤
7 . 數據通訊錯誤
B 類— 較嚴重錯誤，包括以下各種錯誤：
1 . 程序錯誤
2 . 程序接口錯誤
3 . 數據庫的表、業務規則、缺省值未加完整性等約束條件
C 類— 一般性錯誤，包括以下各種錯誤：
1 . 操作界面錯誤(包括數據窗口內列名定義、含義是否一致)
2 . 打印內容、格式錯誤
3 . 簡單的輸入限制未放在前臺進行控制
4 . 刪除操作未給出提示
5 . 數據庫表中有過多的空字段
D 類— 較小錯誤，包括以下各種錯誤：
1 . 界面不規范
2 . 輔助說明描述不清楚
3 . 輸入輸出不
規范
4 . 長操作未給用戶提示
5 . 提示窗口文字未采用行業術語
6 . 可輸入區域和只讀區域沒有明顯的區分標志
E 類— 測試建議
4 怎么做好文檔測試
仔細閱讀，跟隨每個步驟，檢查每個圖形，嘗試每個示例。
檢查文檔的編寫是否滿足文檔編寫的目的
內容是否齊全，正確
關鍵詞：軟件單元測試 測試用例 模塊化
中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416(2012)02-0133-03
當前，對軟件工程領域的討論出現了很多優秀文章。軟件工程也作為一門重要的學科得到了快速的發展。在這些文章中對軟件的設計和開發都做了比較深刻的探討。但是，軟件測試技術作為軟件工程中的一個非常重要的環節卻經常得不到人們的深刻認識。往往人們在有些方面還對軟件測試的環節和作用有著不同程度的錯誤認識。
1、軟件測試的地位
測試在軟件開發的過程中到底應該占據一個什么樣的位置？許多人對此問題理解的并不十分深刻。人們有時對此問題的理解在某種程度上甚至還存在著錯誤。有些人認為軟件測試只是對做出的東西做一個功能的檢驗，此過程只要在開發過程中做好調試工作，這一模塊完全可以避免。軟件測試是為了測量軟件與需求和總體框架是否吻合以及吻合程度。一個軟件做的到底合不合格，此產品是否可以，是否能夠滿足用戶的需要，是否能給用戶留下良好的形象，其中測試起著舉足輕重的作用。由此我們可以看出，軟件的測試絕不是在開發過程中可有可無的模塊，它占據著一個十分重要的地位。
我們做測試是在軟件開發過程中與其它各模塊有機融合的測試，不是把其單獨拿出來看看它是什么，做了什么？而是看我們做這些功用在哪，做了這些為整個軟件開發帶來什么樣的益處。
2、測試技術
2.1 對測試認識的常見誤區
測試的目的是判斷軟件是否與預期目標相符及相符的程度。當然如果狹義的講我們也可以說測試就是盡可能早的、盡可能多的發現現有文件中的錯誤，并將錯誤提交給相關人員，使問題盡早得到解決。但是過去有許多人對軟件測試并不是認識的特別清楚，即使是現在也有一部分人對測試的理解和測試本質意義仍有很大偏差。以下我們將介紹兩種對測試理解的常見錯誤。
2.1.1 測試與調試的等同
有些人將測試和調試在一定程度上混為一談，他們認為如果在調試上多花些功夫，則測試是完全沒有必要的。這是一種極其錯誤的想法。此種錯誤的根源在于沒有對測試和調試的基本概念搞清楚。調試是指程序員在開發過程中對自己書寫的程序進行正誤的判斷，看自己的代碼是否能夠按照架構文檔描述正常工作。而測試的工作則是看得到的代碼或軟件是否按照需求文檔工作，這具體包括：各個功能是否得到了有效的實現，最終得到的軟件的整體性效果如何。軟件在一定的壓力條件下（比如：內存相對不足）是否能正常工作，輸入錯誤信息得到什么樣的回饋，系統在長時間工作的條件下是否還能正常運行等等。
對這些概念理解清楚了，自然就能夠正確區分測試和調試的差別。當然測試和調試有一些內容存在交匯點。
2.1.2 測試的起始介入時間
有些人認為測試是在軟件開發完成后進行一次總體的檢查，其起始時間是在其它工作都基本結束的時候，再致力于軟件的測試工作。其實則不然，軟件的測試工作是應該與需求分析同步起來，也就是說在做需求分析的過程中應當有測試人員介入，這樣使得測試人員對此系統具體要完成哪些工作做到心中有數。有一點大家一定注意，測試不只是看程序員寫的程序是否能夠正常工作，更重要的是看其是否滿足用戶需求，以及在各種條件下的滿足程度。
伴隨著需求分析文檔的誕生，測試人員的測試框架和測試文檔也應當相應的得到實現。當程序員完成部分工作，則測試人員就應該根據測試文檔書寫測試程序對得到的現有完成部分進行測試。這樣一旦發現bug，就及時提交給相關人員，通過這一過程，能使問題在最早的時間段內得到解決，同時也使損失盡可能的降到最低。軟件的開發就是這樣相互疊加式的前進過程。
在我們了解了測試的常見錯誤后，下面讓我們對測試的分類進行一下梳理。
2.2 測試分類
軟件的測試按照不同的分類方法可分成不同的類。按照測試人員的不同可分為：專業測試和用戶測試；按照軟件總體性可分為：黑盒測試和白盒測試；按照開發的不同階段可分為：軟件開發過程中測試和產品測試及后段測試；按照軟件性能可分為：功能測試，極限測試，容錯測試，壓力測試和時間測試等等。在下面向大家介紹幾種重要的測試類別。
2.2.1 黑盒測試和白盒測試
軟件測試從整體角度可分為黑盒測試和白盒測試。黑盒測試顧名思義就是我們對程序代碼內部機制不用管，我們關心的只是其功能。比如我們將其看成一個黑箱子，其內部放些什么東西我們并不了解。我們向其做一定的輸入，看其輸出結果會是什么樣子。通過這種方法我們來確定此模塊的功用是否與要求相符，這叫做黑盒測試。相反，我們不僅要知道盒子的輸入輸出反應，還要知道其內部實現機理，一旦在哪一塊出現錯誤，我們可以及時的修正。通過這樣的方法進行測試稱為白盒測試。
比如我們對于以下代碼模塊進行測試:
void swap(int *a，int *b) {
a += b;
b = a-b;
a = a-b;
}示例代碼2.1
當我們用黑盒測試的時候我們只看到盒子兩個入口，可以放兩個變量指針，所以我們就把變量&aValue，&bValue傳進去，而結果是交換了兩個內存單元的數據。而白盒測試則不然，它要求我們明白盒子（即程序具體代碼）的內在實現過程。比如我們發現使的是java語言，而不支持指針操作，所以我們作為測試員就可以把代碼修正，如下：
public static void swap(int & a，int &b) {
a += b;
b = a - b;
a = a - b;
}示例代碼2.2
這樣我們同樣實現了相同的功能。
2.2.2 功能測試
在軟件性能測試中最重要的就是功能測試，功能測試是看我們要測的模塊是否能夠完成要求的任務，是否在正常情況下給其一個合適的輸入能得到期望的回應。功能測試最重要，但在實現起來也最簡單。比如測試一個線程能否被正確建立我們可以用以下代碼:
void test() {
Thread t = Thread.instance();
if(t= = null) {
printfile(0);
return; }
Hresult hr = t.start();
if (hr != OK) printfile(0);
}示例代碼2.3
這樣我們就可方便地進行功能測試了，看其是否正常工作，如果不能正常工作，我們將會在輸出文件里得到0信息。
2.2.3 極限測試
極限測試是我們判斷軟件在給定邊界值的工作情況的，比如我們給定文檔說線程可以同時起動10個，則我們可以使用如下程序來實現此功能:
void test() {
Thread t = Thread.instace();
int count = 0;
if (t = =null) {
printfile(0);
return; }
bool b = true;
while(b) {
{保證線程不退出機制}
Hresult h = t.start();
if (h != OK) {
printfile(count);
printfileappend(count >= 10);
b=false; }
count++;}
｛線程退出，釋放資源｝
}示例代碼2.4
通過這樣的方法我們可以得到最多起動線程數和是否滿足了需求，如果滿足了用戶需求，則我們就會在輸出文件里得到兩個數，第一個為線程啟動數，第二個為true。比如(20 true)。
2.2.4 容錯測試
容錯測試則是我們不像設計者預期的那樣給定的系統值，比如在示例代碼2.1的時候我們給其為兩變量(a,b)或（pointa，b）(a，pointb)(pointa代表a為一指針)看結果會怎么樣，通過這樣看當給定錯誤代碼時系統界面是否友好，當然我們更不希望當接收錯誤信息時系統會崩潰掉。
2.2.5 壓力測試
壓力測試指我們的系統在不像我們設想的理想環境下運行時，會有什么效果。比如內存不足，系統運行一定時間，硬件兼容性低，硬件配置相對較低等等。例如我們做示例代碼2.4的壓力測試：
void test() {
{耗掉大部分內存}
示例代碼2.4
}示例代碼2.5
這時我們觀察看輸出文件是否還會得到第一個數大于10而第二個數為true。
2.2.6 時間測試
時間測試也叫耐力測試，是看我們設計的系統是否能夠長時間運作接收各種服務而仍能正常工作的測試。
2.3 測試過程
在軟件開發過程中，當進入需求分析階段，測試工作也將啟動。測試根據開發的各個階段不斷前進也將自己逐步推進到新的層次。
2.3.1 測試文檔的生成
測試文檔的生成包括兩個階段。第一階段是在需求分析及總體框架設計時測試員生成自己的測試框架，此框架根據需求分析文檔得到相應的需求測試文檔。當然在此階段不可能細化測試框架，因為我們還不知道我們的系統細節應該是個什么樣子。所以到了詳細框架設計時，我們就應該根據此框架設計我們的測試用例。
2.3.2 測試框架設計
在此階段我們得到一個整體的測試框架，我們不要求細化內容，當然也不可能在需求分析階段做到。我們按照需求分析文檔和整體框架設文檔設計測試框架。比如對于一個簡單的操作系統我們可以：
1文件測試
需求：網絡應用，……
2進程測試
需求：客戶請求啟動相應服務，……
3線程測試
需求：當某一任務啟動后又有用戶請求，啟動一線程為其服務，……
如此得到大致的測試方向，當軟件開發進發詳細框架設計時，我們就有可能根據相應的文檔產生出我們的測試文檔了。
2.3.3 測試用例設計
我們進入測試文檔書寫的時候，最重要的就是用例設計。我們對用例的選擇，一方面要進行全面性考慮，另一方面我們也要選擇那些有代碼性的用例來設計。即我們不僅要有數量，面面俱到，還要有質量，每個用例都有一個特定的代表，而并非簡單的用例重復。例如:線程測試的一個用例（用例1）
測試名稱
線程測試
測試類型
功能測試
預期結果
輸出（n，true）n>10
測試目的
在正常情況下線程的最大啟動數目應該在10以上
測試簡述
1．產生一個線程實例，看是否正確
2．注冊一個機制使啟動線程不退出
3．循環判斷最大啟動線程數
4．線程退出，釋放資源(如表1）
通過以上的設計，我們就可以方便地進行測試程序的編碼了。
2.3.4 測試程序的書寫
在此階段我們根據測試文檔書寫測試代碼。在書寫代碼時我們有幾點需要注意：
第一，結果簡單。我們需要的最終結果是個易于看易于理解的結果，而并非十分晦澀復雜難懂的文件。初學者最容易犯這個毛病，因為輸出多對調試增加了方便。但是我們需要的結果要盡可能簡單，因為在dailybuider里面要有生成結果和標準結果的比較，如果復雜了，則不易實現文件的比較。
第二，確保測試程序的正確性。在書寫測試程序時我們要確保我們所寫的程序是正確的。如果這個都保證不了，那我們就無從談起發現bug。因為真的發現了問題，我們不知道是自己的程序錯誤還是其他人犯的錯。這就要求我們對我們所測的內容有比較詳細的了解。
第三，正確取邊界值。在我們做極限測試時，要選取有代表性的邊界值用來測量。在此過程要防止單一化，要多選幾個靠近邊界的值，以達到有效的確定邊界。
2.3.5 測試報告的填寫
我們做好了以上幾步后，最終我們還要將測試的過程以文檔的形式保存起來，測試報告包括測試時的一些重要信息。比如：
測試報告：
測試題目：線程測試
測試過程：……
預期結果：……
實際結果：……
在測試階段是否異常：（是／否）
異常描述：……
文檔示例3.1
在填寫測試報告時要實事求是，把各項詳細填寫。這樣為bug責任人提供修復依據。
2.4 測試工具
隨著軟件工程和軟件測試技術的發展，軟件測試工具也層出不窮，種類繁多。如Eunit就是比較優秀了工具之一。軟件測試工具可分為動態測試分析工具，靜態測試分析工具和軟件測試管理工具。其中前兩項屬于軟件測試技術的范疇，是按靜態測試和動態測試兩種主要的測試方法進行分類的。
2.4.1 動態測試分析工具
由于動態測試是一項過程性工作，需要經過測試準備（包括測試計劃，測試設計和測試開發）測試執行和測試評價等各階段的工作才能完成，因此軟件動太測試工具的主要功能一般包括測試準備，測試執行和測試評價3類。
2.4.2 靜態測試分析工具
軟件的靜態測試工具是指在不執行被測程序的條件下，被測軟件進行分析的工具。軟件靜態測試工具主要具有4類功能：分析理解，質量度量，規則檢查和特殊檢查。
比較典型的測試工具有:QAC，McCabe，PolySpace，Eunit等。
總之，軟件測試就是為做出的軟件更好地滿足用戶需求而進行的一致性測評，即測量最終結果是否與需求分析中的用戶需求相吻合或吻合程度。軟件的測試絕不是在開發過程中可有可無的模塊，它占據著一個十分重要的地位，在軟件開發過程中我們應給予其足夠的重視和正確的認識。
參考文獻
[1]王家華.軟件工程[M].東北:東北大學出版社,2001,10-18,31.
[2]林寧,孟慶余.軟件測試實用指南[M].北京:清華大學出版社,2004,30-35.
[3]姚淑珍.用例分析技術(第二版)[M].北京:中信出版社,2002,50-56.
[4]張海藩.軟件工程導論（第四版)[M].北京:清華大學出版社,2003,20-24.
兩年以上工作經驗|男|27歲（1989年12月11日）
居住地：北京
電 話：135*******（手機）
E-mail：
最近工作[1年7個月]
公 司：XX有限公司
行 業：互聯網/電子商務
職 位：系統測試工程師
最高學歷
學 歷：本科
專 業：計算機科學與技術
學 校：北京農學院
自我評價
本人自中學開始就養成凡事應該從基層做起，并且不能把自己的能力定位過高的性格習慣，所以我在校期間無論從事什么工作都是從基層做起，盡量把工作約束在自己的能力之內，腳踏實地的工作。但只要有機會，我一樣會進行更高的嘗試，讓自己的能力繼續升級。
求職意向
到崗時間：可隨時到崗
工作性質：全職
希望行業：互聯網/電子商務
目標地點：北京
期望月薪：面議/月
目標職能：系統測試工程師
工作經驗
2013/10 – 2015/5：XX有限公司[1年7個月]
所屬行業：互聯網/電子商務
集成部
系統測試工程師
1.熟悉軟件測試理論、流程和方法，有較強的邏輯分析能力、測試用例設計能力。
2.能根據系統業務需求獨立完成測試用例設計、執行，缺陷跟蹤，風險分析，并根據結果執行回歸測試，分析測試結果，撰寫測試報告。
3.能從多角度考慮模塊設計的完備性，靈活性，可擴展性，并提出改進建議。
2012/6 – 2013/9：XX有限公司[1年3個月]
所屬行業：互聯網/電子商務
集成部
系統測試工程師
1.熟悉軟件測試理論、流程和方法，有較強的邏輯分析能力、測試用例設計能力。
2.能根據系統業務需求獨立完成測試用例設計、執行，缺陷跟蹤，風險分析，并根據結果執行回歸測試，分析測試結果，撰寫測試報告。
3.能從多角度考慮模塊設計的完備性，靈活性，可擴展性，并提出改進建議。
教育經歷
2008/8— 2012/6 北京農學院 計算機科學與技術 本科
證書
2009/12 大學英語四級
關鍵詞：軟件測試；過程管理
中圖分類號：TP311.5 文獻標識碼：A 文章編號：1007-9599 (2011) 22-0000-01
Analysis of Software Testing Process Work Request
Yuan Zhengjiang
(Jiangnan Institute of Mechanical and Electrical Engineering,Guiyang 550009,China)
Abstract:This paper divided software testing into requirements analysis,software testing planning,design and implementation,software testing and software testing summary execution phases,and the test process management requirements are described.
Keywords:Software test;Process management
一、前言
軟件測試是軟件質量保證的重要內容，隨著軟件規模的不斷擴大，復雜程度的不斷提高，測試質量更加難以度量。為促進軟件測試質量，應規范軟件測試過程管理。軟件測試過程包括：軟件測試需求分析、軟件測試策劃、軟件測試設計和實現、軟件測試執行和軟件測試總結等。本文對各軟件測試過程的工作要求進行了闡述。
二、軟件測試需求分析
根據軟件測試任務書、被測軟件的需求規格說明和設計文檔，對測試任務進行測試需求分析，分析的主要內容包括：
1.確定需要的測試類型及其測試要求。測試類型包括功能測試、性能測試、接口測試、安全性測試、人機交互界面測試、強度測試等；測試要求包括狀態、接口、數據結構、設計約束等。2.確定測試類型中各測試項及其優先級。3.確定每個測試項的測試充分性要求。根據被測軟件的重要性、測試項目和約束條件，確定每個測試項應覆蓋的范圍。4.確定每個測試項測試終止的要求，包括測試過程正常終止的條件和導致測試過程異常終止的可能情況。5.測試需求分析階段的工作產品：軟件測試需求規格說明文檔。
三、軟件測試策劃
根據軟件測評任務書、軟件需求規格說明和設計文檔、軟件測試需求規格說明文檔等進行測試策劃，策劃一般包括：
1.確定測試策略。2.確定測試需要的技術或方法，如測試數據生成與驗證技術、測試數據輸入技術、測試結果獲取技術。3.確定要受控制的測試工作產品，列出清單。4.確定用于測試的資源要求，包括軟硬件設備、環境條件、人員數量和技能等要求。5.進行測試風險分析，如技術風險、人員風險、資源風險和進度風險等。6.根據軟件測試任務書和被測軟件的特點確定測試任務結束條件。7.確定被測軟件的評價準則和方法。8.根據測試資源和測試項，確定進度。9.確定需采集的度量及采集要求。10.測試策劃階段的工作產品：軟件測試計劃文檔。
四、測試設計和實現
根據測試需求規格說明和測試計劃進行測試設計和實現，應完成如下工作：
1.按需求分解測試項。將需測試的測試項進行層次化的分解。2.說明最終分解后的每個測試項。說明測試用例設計方法的具體應用、測試數據的選擇依據等。3.設計測試用例；測試用例包括如下內容。（1）測試用例名稱和用例標識；（2）測試用例追蹤。說明測試所依據的內容來源，并跟蹤到相應的測試項；（3）測試用例說明。簡要描述測試的對象、目的和所采用的測試方法；（4）測試用例的初始化要求，包括硬件配置、軟件配置、測試配置、參數設置等初始化要求；（5）測試用例的輸入。包括：每個測試的名稱、用途和具體內容及其性質；測試輸入的來源，以及選擇輸入所使用的方法；測試輸入是真實的還是模擬的；測試輸入的時間順序或事件順序；（6）測試用例的期望結果；（7）測試用例的期望結果評估準則。評估準則用以判斷測試用例執行產生的中間或最后結果是否正確；（8）實施測試用例的執行步驟；（9）測試用例的前提和約束，如特別限制、參數偏差或異常處理；（10）測試終止條件。說明測試用例的測試正常終止和異常終止的條件；4.確定測試用例的執行順序；5.準備和驗證所有的測試用數據。針對測試輸入要求，設計測試用的數據；6.準備并獲取測試資源，如測試環境所必須的軟、硬件資源等；7.必要時，編寫測試執行需要的程序，如開發部件測試的驅動模塊、樁模塊以及測試支持軟件等；8.建立和校核測試環境，記錄校核結果，說明測試環境的偏差；9.測試設計與實現階段的工作產品：軟件測試說明文檔。
五、測試執行
按照測試計劃和測試說明的內容和要求執行測試。測試執行的要求如下：
1.如實填寫測試原始記錄，當結果有量值要求時，應準確記錄實際的量值；2.根據每個測試用例的期望測試結果、實際測試結果和評估準則，判定測試用例是否通過；3.當測試用例不通過時，應根據不同的缺陷類型，采取相應措施：對測試工作中得缺陷，進行記錄并實施相應的變更；對被測軟件的缺陷應記錄到軟件問題報告單中；4.當所有的測試用例都執行完畢后，根據測試的充分性要求和有關原始記錄，分析測試工作是否充分，是否需要進行補充測試；5.在執行測試的過程中，可根據測試的進展情況補充測試用例，但應留下用例記錄，并在執行測試后，變更測試說明；6.測試執行階段的工作產品：測試記錄、軟件問題報告單。
六、測試總結
根據軟件測試任務書、被測軟件文檔、測試過程文檔等，對測試工作和被測軟件進行分析和評價。測試總結的要求如下：
1.對測試工作進行分析和評價。總結測試是否符合過程管理要求，測試是否充分，是否滿足用戶要求等；2.對被測軟件進行分析和評價。總結被測軟件功能、性能、安全性、可靠性等是否滿足要求，對軟件缺陷影響進行描述，提出改進建議等；3.測試總結階段的工作產品：軟件測試報告。
七、結束語
只有把每個測試階段應完成的工作做好了，才能保證最終的軟件測試質量。軟件測試組織都應制定適合自己的軟件測試過程管理體系文件，確保過程管理規范，各階段工作做到位。
參考文獻：
[1]單錦輝,姜瑛,孫萍.軟件測試研究進展[J].北京大學學報(自然科學版),2005,1
自我介紹是向別人展示自己的重要途徑,是與他人進行溝通、增進了解、建立聯系的一種最基本、最常見的方式,是人與人進行溝通的出發點。在面試軟件測試工程師時該如何進行自我介紹呢？本文是小編整理的軟件測試工程師面試英文自我介紹范文以及關于軟件測試工程師面試的知識，僅供參考。
軟件測試工程師面試英文自我介紹范文
軟件測試工程師面試英文自我介紹范文1I’m Cheers.Lee, I’m twenty-six year old, I majored in E-business and with a bachelor degree.I’m single.And I love software testing, as the software quality is vital to the company’s customer, it also could improve the company’s image, so quality is the best policy.We must devote all my energy to assure the software quality.
The position which I’ve come to apply is senior software testing engineer.I have three years work experience, one year and a half of function testing experience and one year of performance and automation testing experience.I have been reading up on software testing, especially on performance testing and automation testing.I’m quite familiar with performance testing tool LoadRunner, and familiar with automation testing tool QTP.I’m good at developing performance testing script base on C language in web system, and also have good skills in develop QTP script.
As we all know that software performance has become more and more important, while thousands of the users log in the system or visit the website simultaneously, the problem may occurred, the system crash or the server deny to provide the service to the user, so the performance testing need to be done before the software delivered to our customers.
We also benefit from the automation testing.There is always a lot of function testing or regression testing need us to finish in a short time.But we do not have enough time and sufficient human resource to complete it, how should we do? So the automation testing is the best solution.It cut down the costs, improve the work efficiency, save our time and energy.Its advantage is not merely as so.
軟件測試工程師面試英文自我介紹范文2Good morning, ladies and gentlemen! It is really my honor to have this opportunity for an interview.I hope I can make a good performance today.I'm confident that I can succeed.Now I will introduce myself briefly.I am 26 years old, born in Shandong province.I graduated from Qingdao University.My major is electronics.And I got my bachelor degree after my graduation in the year of 2003.I spent most of my time on study, and I’ve passed CET-6 during my university.And I’ve acquired basic knowledge of my major.It is my long cherished dream to be an engineer and I am eager to get an opportunity to fully play my ability.
In July 2003, I began working for a small private company as a technical support engineer in Qingdao city.Because there was no more chance for me to give full play to my talent, so I decided to change my job.And in August 2004, I left for Beijing and worked for a foreign enterprise as an automation software test engineer.Because I want to change my working environment, I'd like to find a job which is more challenging.Moreover，Motorola is a global company, so I feel I can gain a lot from working in this kind of company.That is the reason why I come here to compete for this position.I think I'm a good team player and a person of great honesty to others.Also，I am able to work under great pressure.I am confident that I am qualified for the post of engineer in your company.
That’s all.Thank you for giving me the chance.
軟件測試工程師面試技巧核心提示：第一個問題：自我介紹(心理學首因效應告訴我們第一印象非常重要)，自我介紹最重要的是能夠在面試官心目中留下一個好的第一感覺。說得更直白一點是讓面試官舒服。但是我發現很多人就是直接簡單的介紹了一下過去的經歷，但是實際上一方面過去的經歷沒有很好的讓人發現優點。其實面試好比相親，你想說什么不重要，重要地是人家想聽什么。比較好的自我介紹套路是這樣：“您好，我叫XXX,很高興能獲得這次...
第一個問題：自我介紹(心理學首因效應告訴我們第一印象非常重要)，自我介紹最重要的是能夠在面試官心目中留下一個好的第一感覺。說得更直白一點是讓面試官舒服。但是我發現很多人就是直接簡單的介紹了一下過去的經歷，但是實際上一方面過去的經歷沒有很好的讓人發現優點。其實面試好比相親，你想說什么不重要，重要地是人家想聽什么。比較好的自我介紹套路是這樣：“您好，我叫XXX,很高興能獲得這次面試機會，今天來面試是想證明自己是最合適的人選，另一個方面是獲得您的認可，結合我過去的工作和學習經歷，我自信我能符合咱們公司的認可，接下來您看是我繼續介紹我做過的項目，還是您問您關心的問題?”
第二個問題：項目介紹(項目經驗直接決定一個人能否勝任一份工作，企業更應該看重一個人解決問題的思路和具體能力)，項目介紹部分最重要的思路是應該先整體后局部，介紹整體的時候要有量化的數據(從項目度量的五大維度：規模，包括項目代碼規模，需求規模、用例規模，工作量，進度，質量和成本)，然后是整體的測試流程，然后再是角色與職責，接下來是項目中自己的特色，比如做得最好的是、遇到最大的困難時、最差的是，最后是心得體會。
第三類問題：數據庫方面知識，最基本的要求是數據庫記錄的增刪改查(insert、delete、update、select)，表結構的增刪改查(create、drop、alter、describe)、存儲過程、觸發器等。
第四類問題：linux操作系統相關，最基本的目標是熟悉常見的50個命令，比如find命令(-name、-type、-perm、-user、-group、-ctime、-atime)等，熟悉vi、熟悉linux搭建測試環境。比如LAMP環境搭建。
第五類問題：缺陷相關知識，最基本的是缺陷跟蹤的流程(流程的基本要素)，整體的流程，最好能在紙上給面試官畫出來(尤其是男面試官，從男人好色的角度來看，寫得很清楚很重要)，缺陷單的屬性，至少能列出20個屬性，每個屬性的意義，如何描述好缺陷單，缺陷單描述的5C原則，比如缺陷重現步驟應該complete.如何描述一個你認為的最經典的bug單。
第六類問題：用例相關，最基本的包括用例的格式要素，用例設計工程方法論，每個方法要求(方法的背景，操作步驟，優缺點、適應范圍，與其他用例方法如何配合)，在項目中如何利用測試用例設計工程方法。如何評價、評審測試用例，評審從哪些維度?要設計好測試用例需要哪些方面的知識結構，比如技術、業務、方法。
第七類問題：軟件測試流程，系統測試相關規范和標準的流程：熟悉產品/項目，需求評審，測試需求，測試計劃，測試方案，測試用例，預測試，第一輪正式測試、第二輪回歸測試、第三輪測試，測試報告，測試總結，測試指南。
第八類問題，網絡相關，最基本的網絡基礎知識，比如TCP/IP協議。
第九類問題，測試工具，包括三個大的類型，第一類是性能測試工具、自動化測試工具、測試管理類工具。最起碼的要求是熟悉工具的使用。
第十類問題，給你一個軟件，比如QQ、QQ斗地主，你如何去測試，這類問題基本的思路是，從軟件質量模型、測試工具、測試方法、測試流程、探索式測試等角度先宏觀解決，然后再具體微觀講解用例如何設計等。
第十一類問題，一個優秀/卓越的軟件測試工程師應該具備哪些能力與素質，素質方面包括溝通、五心工程師、追求完美等
第十二類問題，最后一個問題，面試官一般會問，您還有什么想問的嗎?還有什么想了解的嗎?總體上來說最重要的是留下一個好的近因效應，就好比相親的時候，分手離開的時候，留下好的最后的印象，基本的思路應該分三種情況，第一種是面試官對你滿意，自己也感覺不錯的情況下，先表示感謝，然后積極主動的問題，比如，非常感謝您給的這次機會，但是我還是想問，如果我有下一輪面試，我想知道知道是什么時候，我應該再做哪些方面的準備。第二種情況是面試官和自己感覺都一般般，感覺自己是雞肋，這個時候說不說很重要，基本的套路是，非常感謝面試官給的這個機會，坦白地說我對自己今天的面試表現不是非常滿意，還可以表現得更好，但是如果我還是非常想得到這個機會，您能否給我一些建議。第三種情況是面試情況非常糟糕，這種情況下，很少有人能說出感謝，但這恰恰體現一個人的風度。基本的思路是，不管怎么樣，還是得感謝您給的機會，讓我自己認識到自己的不足，坦白地說我離這個崗位的要求還有些距離，但是我還是想知道，如果將來我還想來咱們公司面試，您能否給點具體建議。
總結，面試是一個相親的過程，相親的成敗取決于很多要素，但是好的、充分地準備，能夠讓我們更加從容地和主動的去面對壓力與挑戰，而不是簡單地把自己變成超市里面的菜，供人挑選。
軟件測試工程師面試經驗總結首先說明我算上找實習的時候的面試總共就經歷了不到5次，沒有多少經驗，就在網上和書上摘錄了些我認為比較重要的，分享給大家，希望各位都能找到一份適合自己的好工作。
1.筆試題
對于筆試，有的公司筆試題是不區分開發和測試崗位的，測試人員除了要掌握好測試的基本知識外最好也是有編程基礎，具有盡量多的計算機的知識，像操作系統的基本知識(線程等)，數據庫的基本操作(增刪改查，關聯查詢，授予權限等)，數據結構的知識(像二叉樹的前序、中序、后序查詢)。
2.面試
如果在筆試中沒有考測試的基本知識，那在面試中是肯定要被問到的。面試前一定要做好準備，可以在網上搜一下關于這個公司的筆試題和面試題，以供參考。如果時間充裕可以找一本自己能看的進去的講軟件測試的書，認真的有側重點的看看。軟件測試的幾個主要的階段，不一定死記硬背能用自己的話說出來也可以或者能舉例說明，那幾個主要的白盒和黑盒的測試方法能熟練的應用到實際的例子中，等價類劃分和邊界值分析經常被問到。
每個公司做的項目都不一樣，最好先了解下要應聘的那家公司主要是做哪方面的，比如對美外包的公司就要求英語水平，能看懂英文文檔甚至能同外國人交流，最好能提前先看些英語的文章，準備下英文的自我介紹，臨時提高下英語水平。
我被問到的面試題(答案僅供參考)
1.為什么不考研?
2.想要一份什么樣的工作
3.做軟件測試人員需要具備什么樣的職業素質
(1) 專業技能，包括測試的技能和開發的技能
(2) 積極的態度
(3) 良好的溝通能力
(4) 細心
(5) 耐心
(6) 團隊意識
4.對他們公司的了解
5.再就是些工作地點能否接受，有沒有男朋友之類的基本問題
以下是針對實習項目問的問題(答案僅供參考)
6.缺陷報告有幾個狀態，都包括哪些內容
狀態：新建，打開，修復，關閉，重復的bug，無效的bug，被拒絕的bug，其他 內容：：標題、模塊名稱、項目名稱、測試環境、重現步驟、期望結果、實際結果、嚴重級、優先級、發現人、接收人和附件(截圖，說明等)。
7.有一個文本框，只能輸入0-5個字母的組合，如何進行測試
從字符串的長度考慮，按照邊界值方法設計測試用例
從字符串的長度考慮，按照邊界值方法設計測試用例
從字符串的組成內容考慮，按照等價類劃分方法設計測試用例
8.簡單的說一下性能測試和壓力測試
9.寫過自動化測試的腳本嗎
10.我實習的項目是一個金融的網站，技術的面試官問我，商品的價格是左對齊還是右
對齊(對于這個問題我也不知道為啥會被問到，有什么具體的含義，猜想可能是判斷我的項目經驗是否真實)
下面是我網上摘錄的一些可能被問到的面試題
1.您認為做好測試用例設計工作的關鍵是什么?
答：白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
2.在您以往的工作中，一條軟件缺陷(或者叫Bug)記錄都包含了哪些內容?如何提交高質量的軟件缺陷(Bug)記錄?
3.談一些自己在以往的學習和工作中獲得的工作經驗和心得體會?(可以包括軟件測試、過程改進、軟件開發或者與此無關的其他方面
4.什么是軟件測試。
5.Alpha
測試與beta 測試的區別。
6.測試結束的標準是什么?
7.測試項目：杯子
需求測試:查看杯子使用說明書
界面測試:查看杯子外觀
功能度：用水杯裝水看漏不漏;水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子再不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
國際化：杯子上的圖案有沒有觸犯到某個國家或宗教的禁忌
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測試：將杯子盛上水(案例一)放24小時檢查泄漏時間和情況;盛上汽油(案例二)放24小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透
跌落測試: 杯子加包裝(有填充物),在多高的情況摔下不破損
震動測試: 杯子加包裝(有填充物),六面震動,檢查產品是否能應對惡劣的鐵路\公路\航空運輸
測試數據：測試數據具體編寫此處略(最討厭寫測試數據了)。其中應用到：場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法
期望輸出：該期望輸出需查閱國標、行標以及使用用戶的需求
說明書測試: 檢查說明書書寫準確性
給大家提三個產品:1.手機 2.電飯鍋 3.電梯
8.圖書(圖書號，圖書名，作者編號，出版社，出版日期)
作者(作者姓名，作者編號，年齡，性別)
用SQL語句查詢年齡小于平均年齡的作者姓名、圖書名，出版社。
9.軟件測試分為幾個階段
各階段的測試策略和要求是什么
10.您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果?維持測試人員同開發團隊中其他成員良好的人際關系的關鍵是什么?
11.請以您以往的實際工作為例，詳細的描述一次測試用例設計的完整的過程
12.您認為做好測試計劃工作的關鍵是什么?
13.您所熟悉的測試用例設計方法都有哪些?請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
14.測試計劃工作的目的是什么?測試計劃工作的內容都包括什么?其中哪些是最重要的?
答：軟件測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法(最好是能先評審)
15.為什么要在一個團隊中開展軟件測試工作?
答：因為沒有經過測試的軟件很難在之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將時，從測試報告中得出軟件的質量情況。
軟件測試工程師-個人簡歷個 人 簡 歷
基本信息：
姓 名：
出生年月：1991年7月
工作年限：2年
婚姻狀態：未婚
電子郵箱： 性 別：男 畢業學校：廣東建華學院 學 歷：大專 專 業：計算機專業 手 機：
專業技能：
1、熟悉軟件測試理論，軟件測試流程，編寫測試用例等;
2、熟練應用黑盒測試的方法，如邊界值法、等價類法、場景法等;
3、掌握自動化測試工具QTP、性能測試工具LoadRunner的基本使用，如錄制腳本，參數化設置，腳本優化等;
4、熟悉軟件測試的管理工具，如BugFree
缺陷管理工具、SVN版本控制、MindManager 思 維導圖等工具的使用;
5、熟悉Oracle和MySQL數據庫的基本操作，如增、刪、查、該等命令的使用;
6、熟悉Linux操作系統的基本操作;
7、對C語言有一定的了解，如9條基本語句、數組、指針等等的使用;
項目經驗：
項目一
項目名稱： 奔騰出租車
運行環境： Linux + MySQL + Apache
項目概述： 本系統是一套功能全面的出租車管理系統，通過該軟件可以讓出租車公司內部及時準確地采集各種數據信息，處理高速化和網絡辦公自動化。實現對出租車 公司司機的信息記錄，操作，出租車管理，提供精確查詢等多種查詢方式。主 要功能模塊有：首頁、基本信息設置、任務管理、統計圖表、輔助工具、幫助 菜單、用戶信息管理等。通過規范化管理來掌握車輛信息，處理車輛調度，將 很大程度上解決出租車公司在工作上的管理難度，讓車管理更上一個臺階。 責任描述： 1、根據項目需求文檔進行需求分析，寫出需求點;
2、針對責任模塊編寫有效的測試用例;
3、搭建測試環境，保證測試出的數據真實可靠;
4、執行測試用例，用BugFree提交Bug并跟蹤其狀態;
5、進行回歸測試;
6、編寫測試報告。
項目心得： 對軟件測試有了更深層的理解，當編寫用例時，要嘗試新的技術，新的思維，往往Bug就出現在意想不到的地方;明白了回歸測試的重要性，因為偶爾會有些模塊在上一版本沒有出現問題，但在修復某個Bug時卻出問題了，所以測試時需要考慮全局，不要只局限于某個小模塊。
項目二：
項目名稱： 金華酒店管理系統
運行環境： Linux + MySQL + Apache +PHP
項目概述： 金華酒店管理系統主要應用于中小型酒店，通過該軟件可以方便快捷的管理酒店，使酒店的工作質量和效率提高。軟件采用先進的計算機網絡通信技術，改變了酒店業務模式，大大提高了工作效率。本系統的功能包括房間狀況管理、添加房間信息、維修管理、退房管理、客戶入住等，是為了不讓人工繁瑣去操作，而設計的一個管理系統。
責任描述： 1、測試軟件是否達到需求規格書的要求，包括：各個功能點是否以實現，業務流程是否正確;
2、編寫測試用例，如用邊界值法、等價法、錯誤推斷法等方法編寫;
3、搭建測試環境(按照說明書搭建);
4、執行測試用例，用BugFree提交Bug并跟蹤其狀態。
項目心得： 測試的規范化是及其重要的。測試時要注意Bug的群集現象，因為往往百分之八十的問題都發生在百分之二十的模塊當中。
項目三：
項目名稱： 科達薪水助手
運行環境： Linux + MySQL + Apache +PHP
項目概述： 本系統基于B/S架構，主要用來支持企業薪酬管理，方便企業管理員工信息，統計日常支出，員工薪酬管理等等。主要功能模塊有員工信息管理、部門管理、工資管理、收支統計、系統設置、輔助工具、薪酬報表等。本系統的特色就是把員工的信息和薪酬等信息整合在一起，更方便快捷的操作，一套好的工資管理系統，有助于建立科學有效的薪酬體系。
責任描述： 1、編寫測試用例;
2、執行測試用例，用BugFree工具提交Bug，并跟蹤其狀態。
項目心得： 對黑盒測試的各種方法的應用更加得心應手了。
工作經歷：
2012/08—2021/01 創拓達科技有限公司 軟件測試工程師 自我評價：
本人性格隨和，適應能力強，有較強的學習能力，能獨立分析和解決問題。能快速融 入到團隊中去，工作積極上進，對于領導分配的任務認真完成。
軟件測試工程師面試英文自我介紹范文的人還看了：
1.軟件工程師面試自我介紹范文
2.應屆生軟件測試面試自我介紹范文
3.軟件測試面試自我介紹范文
4.軟件測試面試自我介紹
5.軟件測試工作面試自我介紹范文
6.軟件測試工程師簡歷自我評價
7.軟件測試工程師的自我評價
8.計算機專業英文自我介紹范文
關鍵詞：軟件測試；案例教學；項目驅動
中圖分類號：G642 文獻標識碼：B
近幾年專業性的軟件測試機構和組織迅速發展，隨之帶來了專業軟件測試人才的旺盛需求，軟件測試人才的培養正成為新的熱點。然而，軟件測試課程的理論與實踐脫節，現有許多軟件工程教材中關于軟件測試的章節只介紹軟件測試的理論方法，即使有案例也只是簡單說明，并沒有介紹軟件測試的具體方法和實現過程，這導致學生只會死記硬背軟件測試的條條框框而不懂如何活學活用。為此，我們嘗試進行改革，引入了新的教學思路和措施。
1案例教學
案例教學法比傳統的以教師為主導的教學法，更有利于提高學生分析問題和解決問題的能力，促進學生學會學習以及溝通合作。我們在教學的過程中，以可操作的軟件測試案例為中心，讓學生能在教學中體會實際的測試過程。
首先，一個好的測試案例所包含的內容必須完整，應包含測試目的、特殊的硬件要求、特殊的軟件要求、特定的配置、執行測試的描述、測試的預期結果或成功條件。
其次，根據測試的分類不同，可分為以下幾種：
對于單元測試案例，主要按照程序內部的結構測試程序，檢驗程序中的每條通路是否都能按預定要求正確工作。這類測試案例主要驗證模塊接口、模塊局部數據結構、模塊邊界條件、模塊中所有獨立執行通路、模塊的各條錯誤處理通路。掌握白盒測試/黑盒測試方法以及單元測試的用例設計；通用代碼編程規范、偽碼寫作規范的檢查；基本的代碼靜態檢查方法與工具運用；代碼覆蓋率檢查方法與工具運用；OO程序單元測試方法與過程；針對內存泄漏的檢查；掌握測試覆蓋分析方法和測試用例最小化的運用。
對于功能測試案例，用于鑒定執行后啟用的功能。這類測試案例驗證軟件是否提供了基本的單
元功能、是否提供集成后的功能，以及是否提供解決方案設計中指定的其他功能。
對于Web測試案例，Web系統是當前網絡環境下最多的應用系統，其主要內容設計為Web性能測試項目解析、性能測試流程、測試規劃與設計、性能測試需求分析、用戶事務分析、Web資源分析、網頁元素細化等。
對于集成測試案例，主要包括針對結構化軟件和面向對象軟件的集成測試，獨立開展集成測試用例設計和用例執行。具體分為基于結構化程序的集成測試方法和基于UML圖的面向對象的集成測試方法。
對于系統測試案例，掌握常見系統測試類型的基本測試方法，獨立設計系統測試用例，運用手工方式或測試工具完成系統測試，包括功能測試、性能測試、壓力(負載)測試、配置測試、易用性測試。
再次，教學案例的具體應用。我們根據難以程度，將測試案例大致可分為簡單的基礎性實驗案例和綜合實驗。簡單的基礎性實驗案例主要包括白盒測試和黑盒測試，通過學習讓學生掌握軟件測試最基本的一些方法。綜合性的實驗案例，特別是較大型的軟件項目測試實驗，讓學生在實驗的每一個步驟中理解軟件測試技術和各種具體的測試方法，增強實際操作能力，增加軟件項目測試的綜合經驗。
通過綜合性實驗的學習，可以讓學生感受大型軟件測試項目的工作流程和實施細節，掌握各種軟件測試方法在大型項目中的應用，體會軟件測試的規律；了解軟件測試項目的管理，熟悉軟件測試項目中人員的管理、產品的管理、軟件測試案例的管理以及缺陷的管理；能夠進行比較復雜的白盒測試或自動化測試，為從事要求較高的軟件測試打下很好的基礎。
2項目驅動
軟件測試是一項技術性較強的工作，規范的實施也是以工程的方式開展或進行。因此，最好的課程內容及教學設計是通過項目的活動及過程來呈現問題，運用相關理論知識解析問題，以及通過工程過程解決問題，通過項目闡明技術方法與策略的運用。
項目的復雜性通過分解得到局部的單一性和簡單化。項目包含了由易到難，由簡單到復雜，由單一到綜合，逐步實現的內容和過程。軟件測試本身就是理論與實踐緊密結合的一門技術學科或工程體現，貫徹項目教學法是該課程理論教學與實踐教學“一體化”的最好形式。通過項目教學，可落實教學的循序漸進原則、系統化原則、目標性原則、整體優化原則以及規范化原則。項目教學使教學內容的構建緊密圍繞課程總體目標展開，項目組成具有針對性強，目標具體明確、步驟清晰的特點。它按照組成技能教學內容及相互間的內在聯系，使各部分內容有所側重，互相銜接，
軟件測試項目大致可以分為以下三個方面：“軟件測試技術”等課程的實踐教學，強調案例教學法，強調實踐教學；課外實踐，強調綜合性、設計性實驗，由學生在課余時間完成，包括畢業設計；企業實習，和多個企業建立關系，供學生實習軟件測試。
3常用自動化測試工具使用
在理解軟件測試自動化原理基礎上，掌握業界常用的
Rational、WinRunner、LoadRunner、Junit、Panorama等系列測試組件的運用。在制定的測試策略中應用測試自動化工具開發、編輯、運行和調試自動測試腳本程序，建立測試過程、生成測試報告，分析測試結果，理解測試工具如何進行對測試數據進行自動評估分析，掌握測試工具如何對測試文檔生成和利用。如表1。
4結束語
我們對軟件測試的教改受到了學生和老師的普遍歡迎。通過調查，大多數學生認為使他們對課本知識的理解更加深入了，主動思考問題的能力也得到了提高。教師們也普遍反映“軟件測試”的教學質量和教學效果得到極大的提高。
參考文獻
[1] 鐘元生. 軟件測試實踐教學特色的構建實踐[J]. 電化教育研究,2006,162(10):62-65.
[2] 張小進,陳雄峰. 軟件工程課程改革探索―軟件測試在程序設計課程中的引入[J]. 高等理科教育,2006,70(6):91-94.
[3] 賀平. 軟件測試課程開發[J]. 計算機教育,2006,(12):53-56.
認清“第三方”的責任
第三方測試以合同的形式制約了測試方，使得它與開發方存在某種“對立”的關系，所以它不會刻意維護開發方的利益，保證了測試工作在一開始就具有客觀性。第三方一般都不直接參加開發方系統的設計和編程，為了能夠深入理解系統，發現系統中存在得問題，第三方測試必須按軟件工程的要求辦事，以軟件工程的標準要求開發方和用戶進行配合，從而較好地體現軟件工程的理念。引入第三方測試后，由于測試方相對的客觀位置，由用戶、開發方、測試方三方組成的三角關系也便于處理以往用戶、開發方雙方糾纏不清的矛盾，使得許多問題能得到比較客觀的處理。
第三方測試不同于開發方的自測試。由于他熟悉設計和編程等，往往習慣于按一定的“程式”考慮問題，以至思路比較局限，難于發現“程式”外存在的問題。因為第三方測試的目的就是為盡量多地發現程序中的錯誤而運行程序的過程，可以更多的發現問題。隨著系統越做越大，客觀上講開發人員也無精力參與測試，同時也不符合大生產專業分工的原則。
第三方測試不同于用戶的自測試。用戶是應用軟件需求的提出者，對于軟件應該完成的功能是非常清楚的，是進行功能驗證的最佳人選。客觀情況是，大部分的用戶都不是計算機的專業人士，很難對系統的內部實現過程進行深入的分析。對系統的全面測試，功能測試僅僅是一個方面，還要包括并發能力、性能等多種技術測試。
如何組織管理
在測試的過程中，用戶、開發方與測試方形成了一個三角關系，從最終目標來講，三方是完全一致的，都是希望保證系統穩定運行。但在測試過程中，三方的關系卻是既對立又合作。
軟件測試的過程
為了保證測試的順利進行，測試方必須強化內部的組織管理。根據我們的經驗，完整的測試機構必須包括業務分析部門、技術支持部門、規劃設計部門和綜合后勤部門。
“第三方”測試什么
根據軟件的特性，第三方軟件測試工程可劃分為三種類型四個層次。
第一類是系統軟件、環境軟件和各類工具軟件等的測評。對這類軟件的評測重點是軟件產品的功能、性能和特點評測。
第二類是面向應用軟件系統的測評。這類軟件，具有很強的行業應用特性，往往是要由用戶與開發商簽定項目合同，開發商負責開發，用戶負責驗收。對這類軟件的評測，根據用戶對第三方的依賴程度，又可分為兩個層次。第一個層次只對應用軟件系統進行綜合、性能測試。第二個層次是對應用軟件系統進行質量監理與評測。
承擔該類軟件質量監理評測的第三方，承擔軟件過程質量監理的責任，在軟件生命周期過程中，從軟件定義開始，要對軟件過程從質量保證角度進行規范化的監督、管理和控制。評測工作不僅包括軟件生命周期各階段的評審，而且還要對程序系統，進行包括模塊白盒測試在內的系統集成、系統驗收等測試。
第三類是對軟件企業的CMM評估認證,也是最高層次的軟件評測。
了解測試評估
測試評估是軟件測試的一個階段性的結論，用所生成的測試評估報告，來確定測試是否達到完全和成功的標準。在測度評估階段向用戶提供強有力的支持，包括通過測試報告，驗證測試結果是否符合測試計劃中制定的測試標準；根據缺陷報告提供的測試結果數據，給出軟件質量和測試完整性的評估報告；特別在以下幾方面對測試的過程進行評測：
評估測試用例覆蓋：測試的目標是確保100%的測試用例成功地執行。主要考慮風險和嚴重性、可接受的覆蓋百分比。
評估代碼覆蓋：需要斷定測試目標期望的總的測試代碼行數，在測試中真正執行的代碼行數及其百分比，將此結果記錄在測試評估報告中。
【關鍵詞】人力資源；信息系統；軟件測試
當前企業管理的主要基礎工作就是人力資源管理，多年來，不管是三項制度改革、工資分配改革，還是社會保障推行，以及下崗職工的安置，人事資源管理始終站在企業改革的前沿。為了適應現代化企業的發展和要求，人力資源管理工作也可以利用信息化平臺，開發出人力資源信息管理系統，可以利用人力資源開發性、有價性以及可配置性等特性進行合理的配置和綜合的開發。其中，為了能夠保障系統的可靠性與穩定性，軟件測試是必不可少的環節，對該系統投入運行起著決定性的作用。本文對人力資源信息系統與軟件測試技術進行了深入的探討和分析。
1人力資源管理系統綜述
人力資源管理系統利用信息化技術實現了許多管理功能，對人事檔案、員工考勤、人員變動、員工培訓、就業合同、保險、工資、招聘等人事行政事務，并拓展到資源開發、資源控制以及決策支持等高級功能領域。其作為一種對人才資本進行管理的產品，主要是提供一種兼具廣度和深度的解決方案。該系統能夠將許多管理功能匯集在一個數據庫當中，使數據庫具備最全的核心功能、功能層次和模塊領域，最多的管理模式、最佳實踐及細節功能。系統通過數據采集、挖掘、分析和可視化管理等，將數據靈活便捷的呈遞給各級管理人啊云進行人才管理等服務。
2人力資源管理系統軟件測試的目的
軟件測試的主要目的可以分為三個方面：（1）在于確定系統軟件的質量，即軟件能夠以正確的方式達到設計標準。（2）為開發人員和之后的風險評估提供信息。（3）軟件開發過程時符合高質量的。簡言之，對人力資源管理系統軟件進行測試的目的就是盡可能的尋找出最多的缺陷，因此在對測試用例進行選取時，要盡量去選擇容易發生異常的程序和數據，因而能夠有效的定義軟件成分，并實現從低層到高層的組裝過程，可以驗證此系統是否滿足任務計劃，以及其他規定的技術要求，并為建立軟件質量模型提供可靠依據。
3人力資源管理系統軟件測試過程分析
3.1軟件測試定義
人力資源管理系統進行軟件測試，是為了發現系統的運行錯誤而進行的測試。軟件測試是指根據系統開發階段涉及到的標準和說明，以及系統程序的結構而設計的測試樣本，一般將測試樣本輸入程序，然后運行程序，并對輸出結果進行分析，發現程序錯誤。軟件測試流程通常分為五步，當上一步完成并獲得批準之后可以進行測試的下一步流程。流程包括：制定測試計劃、設計測試用例、滿足啟動準則并進行測試、撰寫測試報告、完善軟件錯誤。
3.2測試功能點匯總
人力資源信息系統測試功能包括以下幾個方面：（1）電子檔案方面，需要測試功能點有人員信息的添加、修改、刪除以及查詢。（2）職位調動方面，需要測試的功能點有兩大點，一是單位內調動包括調動的辦理、調動批量辦理和歷史調單打印；二是單位之間的調動包括單位之間調動的申請和辦理、單位之間批量調動的辦理和申請、單位之間調動集團公司審批。（3）綜合查詢方面，需要測試的功能點包括綜合查詢條件組合、綜合查詢結果打印、綜合查詢任意字段顯示。（4）人員流動統計方面，需要測試的功能點包括統計單位工人調動人數和統計參加作業人數。（5）單位設置方面，需要測試功能點包括添加新單位、新單位修改、單位信息刪除。（6）工種設置方面，需要測試工種的添加、修改和刪除。（7）退休管理方面，需要測試功能點包括退休預警、預測、申報、分析等。（8）合同管理方面，需要測試合同預警和合同預測功能。（9）賬號管理方面，需要測試管理數據范圍和管理模塊使用范圍功能。除此之外，還應測試分組查詢功能、用功形式報表統計功能、人員減少辦理功能、政策法規查詢功能、人力資源統計分析功能、系統在線升級功能等等其他相關功能。測試主要檢測這些功能的窗口完成是否準確、數據是否準確、操作是否簡潔；功能鍵是否描述準確、操作是否方便；輸出結果是否正確；其業務流程說明書是否正確、軟件數據流是否流向正確；除此之外還要檢驗該系統的用戶容量等等。
3.3測試流程與方法
人力資源信息系統軟件測試主要采用黑白盒測試、單元測試、集成測試、系統測試和驗收測試。白盒測試主要測試軟件內部設計和程序，依靠設計文檔進行測試。黑盒測試可以直接跳過軟件內部，只測試輸入和輸出，依靠其他測試方法的結果進行測試。黑百盒測試相輔相成，可以對系統進行由大到小、由內而外的全面性測試。單元測試選取的粒度最小，常由開發小組通過白盒進行測試，檢驗測試單元是否合格。系統測試選取的粒度最大，常由獨立的測試組用黑盒進行測試，驗證整個系統是否滿足需求規格說明書。而集成測試選取的粒度居中，有承上啟下的作用，常由開發小組自行采用黑百盒進行測試，驗證設計和需求是否合格。驗收測試則由用戶進行測試，功能與系統測試相似。
4結語
隨著我國信息化建設的加快，為企業的發展既帶來了一定機遇，也帶來了許多挑戰。一個信息系統軟件，特別是人力資源信息系統對企業的工作運轉效率起著重要的作用，而軟件測試對于系統軟件能否可靠穩定的運行非常關鍵。人力資源信息系統的開發和使用，以及該系統的測試工作，對提升組織效率，完善組織功能至關重要.因此，應當增強對于信息系統軟件的測試工作的重視，提升軟件測試結果的質量。
參考文獻
[1]章建美.企業級信息系統(EIS)人力資源模塊的設置原則[J].華東電力,2008(05):97-99.
[2]李耀輝,利.機械制造企業人力資本投資風險評測與軟件開發[J].西安科技大學學報,2006(09):416-420.
[3]楊壽保.導入小型軟件企業小型軟件項目的研究[J].計算機工程與應用,2002,38(18):88.
關鍵詞：軟件測試流程；科學；缺陷報告；基本測試方法
中圖分類號：TP311
眾所周知，目前主流的軟件開發模式大致可以分為原型開發模型、流水模式（瀑布模型）、螺旋模型三種。其中，螺旋模型已被證實是目前開發軟件的最有效手段，是測試人員最喜愛的測試模型。然而，因目前國內測試人員缺口較大，大部分公司依舊采用傳統的瀑布模型或原型開發模型進行軟件開發，使得測試工作時間十分緊湊。測試員如何在短時間內檢測出軟件存在的問題，成為一個完整的軟件開發的重中之重。本文從計劃測試工作、制定測試用例、實際測試、報告缺陷四個方面來分析軟件測試周期。
首先，我們來明確一下軟件缺陷的五種判定依據：（1）軟件未達到產品說明書標明的功能。（2）軟件出現了產品說明書致命不會出現的錯誤。（3）軟件功能超出產品說明書指明范圍。（4）軟件未達到產品說明書雖未指出但應達到的目標。（5）軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。基于以上判定依據，我們開始進行測試流程分析。
1 計劃測試工作
測試同編程一樣，不可能毫無根據的進行。計劃測試過程的最終目標是交流軟件測試團隊人員的意圖、期望，以及對即將要執行的任務的理解。在計劃過程中，首先要明確測試的目標與內容，統一缺陷描述語句。其次，通過明確分配團隊人員的責任與任務來制定測試策略，建立良好的團隊依賴性。再次，編寫測試用例并執行測試工作。最后，報告軟件缺陷并檢查缺陷修復情況。
2 制定測試用例
測試用例的編寫是作為軟件測試員最重要的任務之一。不正確的測試用例可能導致測試量過大或者過小，甚至測錯目標。在編寫測試用例時，首先要明確測試計劃的目標并規劃測試的范圍。目標必須絕對，以避免說不清軟件是否能夠達到目標需求。規劃測試范圍時，要確認無需測試的內容，以防重復測試，節約測試時間。確定無需測試內容時，需要明確理由，以防由于誤解使某一部分在測試過程中漏掉，產生重大缺陷。
接下來，介紹幾個容易在測試規劃中易遺漏的測試部分。首先是硬件配置測試。比如打印機。商務類軟件對打印機的使用要比其它類的軟件更為頻繁，然而，許多商務類軟件的測試用例執行書中，常常忽略對打印機打印的測試，這可能使得用戶在使用過程中產生不滿（可能會出現無法打印或者軟件硬件不兼容的情況）。其次，測試軟件的兼容性。商務軟件可能需要大量的數據導入導出操作。數據導入導出文本格式以及對Windows Office或WPS各版本的文本兼容性也是測試的重點之一。再次，以使用者的角度測試軟件界面的易用性。比如，“回車鍵”的使用。許多人習慣以回車鍵代替確認按鈕。測試用例編寫人員在基于說明文檔編寫測試報告時，也應當從使用者的角度注意部分特殊按鍵對軟件功能的影響。
3 進行實際測試
3.1 靜態黑盒測試，是基于產品說明書進行的高級審查（即在代碼編寫前進行的測試，后簡稱審查），在軟件開發的初期進行。因其能以最快的速度將軟件缺陷的數量降至最低、損失降至最少，是軟件測試最重要的環節。如果時間充裕，應首先保證審查的執行。
審查時，主要注意以下五點：（1）注意產品說明書的用語。比如，當文中出現絕對一類的詞語時，測試人員應當開始考慮針鋒相對的案列進行分析；當文中出現等等、諸如此類、依此類推這種讓人迷惑的詞語時，我們也可以將其視為缺陷。（2）注意產品說明書是否具有完整性、準確性、精確性、一致性、合理性、代碼無關性，并且功能描述是否貼切、可測試。（3）注意定義產品開發設計界面與代碼以及產品用語（術語）的標準和規范。（4）注意了解客戶，從用戶角度審查產品說明書是否合理。（5）注意了解其他同類軟件。正所謂“知己知彼，百戰不殆”。在了解其它同類軟件的同時，有助于制定測試條件以及測試方法，甚至可以發現無法想到的潛在缺陷。
3.2 動態黑盒測試，在業內也被戲稱為“閉著眼睛測試軟件”，因為在測試過程中測試員不知道程序如何工作，只是按照用例說明標注的操作步驟進行行為操作，因此，動態黑盒測試也被稱為“行為測試”。在執行測試用例時，首先要進行通過測試，確定產品在普通情況下能正確運行并實現需求說明書中的基本功能。在確定軟件可以正常運行之后，采取各種手段以搞垮軟件為目的進行破壞性測試。
3.3 靜態白盒測試，也稱為結構分析，是在不執行軟件的情況下審查軟件設計、體系結構和代碼，首要目的是盡早發現動態黑盒測試難以遇到的軟件缺陷。審查的目標是要查找出出錯的代碼以及遺漏的項目。審查時要注意編碼是否符合編碼標準和規范；注意數據是否存在聲明、引用、計算、比較等方面的錯誤；注意軟件是否有錯誤處理相關代碼，注釋是否齊全，是否考慮兼容性等方面。
3.4 動態白盒測試，即在軟件執行的情況下檢查代碼并觀察其運行狀況。主要由四個部分組成：檢查API，從頂層起完整的測試軟件，通過訪問權限強制軟件以非正常方式運行，估算“命中”代碼并查缺補漏。動態白盒測試通過提供關于測試對象“內部”的信息，大幅的減輕測試工作，消除冗余的測試案例，增加測試案例的針對性，是一種非常強大的測試方法。
4 報告軟件缺陷
4.1 缺陷報告的基本原則。（1）盡快報告軟件缺陷。越早發現軟件缺陷，修復的時間越多，越能減少因軟件缺陷造成的損失。（2）有效的描述軟件缺陷。語言盡量簡短明確，便于查看；缺陷報告盡量單一、詳細；步驟描述盡量通俗易懂，易分離可再現。（3）報告缺陷時不夾雜個人感情。在進行軟件測試時，測試員常常會與開發人員產生沖突，在兩方人員相互對立的情況下開展的測試活動整個對項目的進行會產生惡劣的影響，甚至導致項目的失敗。因此在提交缺陷時要求測試員不夾雜個人感情、客觀的報告缺陷。（4）及時補充和完善缺陷報告。良好的測試員善于發現并記錄軟件缺陷，優秀的測試員在發現和記錄大量軟件缺陷之后，會繼續跟蹤其后續修復過程，以保證缺陷被完全修復。
4.2 分離和再現軟件缺陷。要想有效的報告缺陷，就要以明顯易用和再現的形式報告它，必要時可以使用windows自帶的問題記錄器或通過錄音錄像等方式提交Bug步驟說明。
我們可以通過以下幾種方法分離軟件的缺陷：（1）通過考慮軟件缺陷出現的時間點，內存及網絡的使用狀況，查找時間依賴和競爭條件產生的缺陷。（2）查看缺陷的產生是否與內存泄露或數據溢出等邊界條件相關。（3）查找特定狀態。在本人進行的軟件測試中，曾有一次系統崩潰在連續打開不同界面后突然返回某一主控制界面導致整個操作系統的數據庫被清空。（4）考慮硬件問題。主板松動，內存損壞，硬盤壞道，CPU溫度過高，硬件型號都有可能是導致軟件缺陷產生的原因。
5 結束語
軟件缺陷的報告是在軟件測試周期中的最后一步。從表面上來看，報告軟件缺陷似乎是測試周期中的最簡單一步。然而實際上，這一步有可能是測試員最重要甚至是最難完成的一步。由于時間、風險、缺陷報告的有效性等原因有可能導致軟件缺陷無法被修復。一個優秀的測試員不僅要有良好的技術能力，也要有良好的語言描述及公關能力，保證缺陷得到修復的機會。
參考文獻：
[1]（美）Rom Patton：Software Testing.
[2]（美）William E.Perry：Effective Methods for Software Testing.
[3]（美）William E.Perry，Randall W.Rice：Surviving the Top Ten Challenge of Software Testing.
