系統測試精品(七篇)

序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇系統測試范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于web的系統測試方法。/kF?RZNAX4^''''8gnv[本資料來源于貴州學習網計算機網絡技術]/kF?RZNAX4^''''8gnv

隨著internet和intranet/extranet的快速增長，web已經對商業、工業、銀行、財政、教育、政府和娛樂及我們的工作和生活產生了深遠的影響。許多傳統的信息和數據庫系統正在被移植到互聯網上，電子商務迅速增長，早已超過了國界。范圍廣泛的、復雜的分布式應用正在web環境中出現。web的流行和無所不在，是因為它能提供支持所有類型內容連接的信息，容易為最終用戶存取。

yogeshdeshpande和stevehansen在1998年就提出了web工程的概念。web工程作為一門新興的學科，提倡使用一個過程和系統的方法來開發高質量的基于web的系統。它"使用合理的、科學的工程和管理原則，用嚴密的和系統的方法來開發、和維護基于web的系統"。目前，對于web工程的研究主要是在國外開展的，國內還剛剛起步。

在基于web的系統開發中，如果缺乏嚴格的過程，我們在開發、、實施和維護web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基于web的系統變得越來越復雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對web和internet的信心可能會無法挽救地動搖，從而引起web危機。并且，web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加廣泛。

在web工程過程中，基于web系統的測試、確認和驗收是一項重要而富有挑戰性的工作?；趙eb的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，internet和web媒體的不可預見性使測試基于web的系統變得困難。因此，我們必須為測試和評估復雜的基于web的系統研究新的方法和技術。

一般軟件的周期以月或以年計算，而web應用的周期以天計算甚至以小時計算。web測試人員必須處理更短的周期，測試人員和測試管理人員面臨著從測試傳統的c/s結構和框架環境到測試快速改變的web應用系統的轉變。

一、功能測試

1、鏈接測試

鏈接是web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的url地址才能訪問。

鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個web應用系統的所有頁面開發完成之后進行鏈接測試。

2、表單測試

當用戶給web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。

3、cookies測試

cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用cookies訪問了某一個應用系統時，web服務器將發送關于用戶的信息，把該信息以cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。

如果web應用系統使用了cookies，就必須檢查cookies是否能正常工作。測試的內容可包括cookies是否起作用，是否按預定的時間進行保存，刷新對cookies有什么影響等。

4、設計語言測試

web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的html等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了html的版本問題外，不同的腳本語言，例如Java、JavaScript、activex、vbscript或perl等也要進行驗證。

5、數據庫測試

在web應用技術中，數據庫起著重要的作用，數據庫為web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在web應用中，最常用的數據庫類型是關系型數據庫，可以使用sql對信息進行處理。

在使用了數據庫的web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。,l/u,H*wjY-gM8-[此文轉貼于我的學習網計算機網絡技術

二、性能測試

1、連接速度測試

用戶連接到web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。

另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。

2、負載測試

負載測試是為了測量web系統在某一負載級別上的性能，以保證web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問web系統的用戶數量，也可以是在線數據處理的數量。例如：web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？web應用系統能否處理大量用戶對同一個頁面的請求？

3、壓力測試

篇(2)

引言

隨著嵌入式系統硬件體系結構的變化，嵌入式系統的發展趨勢向嵌入式系統高端，即嵌入式軟件系統轉移，具體體現在嵌入式操作系統趨于多樣和應用軟件日漸復雜。由于嵌入式系統軟硬件功能界限模糊，研究如何進行系統測試和進行質量評估來保證嵌入式系統的產品質量具有重要意義。

首先，這里明確嵌入式系統的系統測試定義，是將開發的軟件系統（包括嵌入式操作系統和嵌入式應用軟件）、硬件系統和其它相關因素（如人員的操作、數據的獲取等）綜合起來，對整個產品進行的全面測試。嵌入式系統的系統測試比PC系統軟件測試要困難得多，主要體現如下：

①測試軟件功能依賴不需編碼的硬件功能，快速定位軟硬件錯誤困難；

②強壯性測試、可知性測試很難編碼實現；

③交叉測試平臺的測試用例、測試結果上載困難；

④基于消息系統測試的復雜性，包括線程、任務、子系統之間的交互，并發、容錯和對時間的要求；

⑤性能測試、確定性能瓶頸困難；

⑥實施測試自動化技術困難。

1 測試方法

根據Goodenough和Gerhart提出的軟件測試充分性準則可知，軟件測試具有非復合性的特點，也就是說，即使以軟件所有成分都進行了充分的測試，也并不意味著整個軟件的測試已經充分。所以，即使通過了需求測試、設計測試、編碼測試，并不意味著已經完全了充分的測試，還要進行軟硬件全面測試，即系統測試。正確的系統測試方法能設計出良好的測試事例，而良好的測試事例是測試成功的關鍵。測試事例質量特性主要有以下幾點。

*檢驗性：檢測軟件缺陷的有效性，是否能發現缺陷或至少可能發現缺陷。

*可仿效性：可以支持測試多項內容，減少測試事例的數量。

*開銷：測試事例的執行、分析和調試是否經濟。

*修改性：每次軟件修改后對測試事例的維護成本。

測試方法不僅要保證測試事例具有發現缺陷的高可移植性，而且還要保證測試事例設計的經濟有效。因此，在實際測試工作中，將嵌入式系統的測試方法分類如下：根據測試是否動態運行被測程序分為靜態測試方法和動態測試方法；根據測試階段分為需求測試方法、設計測試方法、編碼測試（單元測試、集成測試）方法及系統測試方法；根據測試目的分為功能測試、性能測試、可靠性測試（容錯性、可恢復性、成熟度測試*及信息安全保護等測試。參看表1嵌入式軟件測試方法對照。其中“√”代表相關性。所有這些方法的具體定義這里不一一介紹。由于不同的嵌入式系統面向的應用不同，測試方法的側重也很不相同。本文后面將對一個具體的便攜式信息處理嵌入式系統（PDA、便攜式翰林電子書）的系統測試方法詳細說明。

表1 嵌入式軟件測試方法及階段對照表

測試方法分類

需求測試設計測試編碼測試系統測試靜態測試方式；基本思想Yourdon的結構化走通結構化審閱√√　√Fagan檢查測試檢查并評估√√　√動態測試方法；基本思想控制流測試語句測試　√√　路徑測試

√　條件測試

√　數據流測試數據定義引用

√√分域測試劃分子域測試√√　√功能測試劃分功能測試

√√隨機測試不限定范圍

√2 可靠性評估

可靠性是嵌入式系統最重要的質量指標。ISO9000國示質量標準（ISO/IEC 9126-1991）規定，軟件產品的可靠性含義是：在規定的一段時間和條件下，軟件能維持其性能水平的能力有關的一組屬性，可用成熟性、容錯性、易恢復性三個基本子特性來度量。根據我們在評估嵌入式系統中的成功經驗，一般采取以下簡單有效的評估方法（可以采用百分制或十分制）。

（1）成熟性度量

①錯誤發現率DDP（Defect Detection Percentage）。在測試中查找出來的錯誤越多，實際應用中出錯的機會就越小，軟件也就越成熟。

DDP=測試發現的錯誤數量/已知的全部錯誤數量

已知的全部錯誤數量是測試已發現的錯誤數量加上可能會發現的錯誤數量之和。

②測試覆蓋率度量。測試的覆蓋率，可以用測試項目的數量和內容進行度量。除此之外，如果測試軟件的數量較大，還要考慮數據量。測試的覆蓋率，可以根據表2所示在測試指標進行評價。通過檢查這些指標達到的程度，就可以度量出測試內容的覆蓋程度。

表2 測試覆蓋程度表

測試覆蓋項測試覆蓋率指標測試描述測試結果界面覆蓋符合需求（所有界面圖標、信息區、狀態區）　靜態功能覆蓋功能滿足需求　動態功能覆蓋所有功能的轉換功能正確　正常測試覆蓋所有硬件軟件正常時處理　異常測試覆蓋硬件或軟件異常時處理（不允許的操作）測試結束判斷表3 可信度測試表

測試功能甲乙丙丁平均最大值-最小值功能1

功能2

功能3

功能4

功能5

注意，對于最大值與最小值的差值超過5的情況，應該重新測試響應功能。

（2）容錯性評估

容錯性評估分為控制容錯性評估、數據容錯性評估、硬件故障恢復容錯性評估：

容錯性=以下各條款評分之和÷條款數

控制容錯性度量

①對并發處理的控制能力；

②錯誤的可修正性和處理可繼續進行能力。

數據容錯性度量

①非法輸入數據的容錯；

②對相互沖突的要求和非法組合容錯；

③輸出數據是否合理容錯。

硬件故障中恢復容錯性度量

故障后恢復能力容錯。

（3）易恢復性度量

與易恢復性緊密相關的測試是強度測試和健壯測試。強度測試又稱為力度測或極限測試，主要測試系統對空間強度和時間強度的容忍極限；健壯測試又稱異常測試，是很重要的可靠性測試項目。通過易恢復性測試，一方面使系統具有異常情況的抵抗能力，另一方面使系統測試質量可控制。

易恢復性=以下各條款評分之和÷條款數

①空間強度可恢復；

②時間強度可恢復；

③數據強度可恢復；

④異常通信可恢復；

⑤數據破壞可恢復；

⑥電池極限可恢復。

（4）測試可信度評估

測試可信度是對測試質量的有效評估，是保證質量的必要步驟。目前雖然很難有量化的指標，但我們采取積分的方式顯示可信度。例如，請4個人員（甲、乙、丙、?。ο到y5個功能打一個從0（不信任）到10（完全信任）之間的分數，那么，可信度度量可以用表3進行計算。

3 測試實例

（1）電流測試

電流測試是嵌入式系統的系統測試中首先要進行的重要測試，也是最容易被忽視的測試。主要是測試系統的工作電流、待機電流。人們一般把它當成與系統測試無關的硬件測試。但是對于嵌入式系統，軟件與硬件不可能清晰地劃分，硬件的性能直接影響軟件的運行。實例1說明了電流測試對系統運行的影響及不可替代的作用。

測試現象描述：進行同一廠商PDA系統測試，有幾臺PDA在名片子系統、行程子程序的操作過程中隨機死機。

我們當時的錯誤分析定位是：①懷疑操作系統中斷處理錯誤；②懷疑內存泄漏，堆棧溢出；③懷疑應用程序錯誤。

在軟件開發人員為解決這個問題檢查軟件時，硬件開發人員提出應首先測試一下這幾臺機器的工作電流。結果發現，PDA的工作電流低于正常工作電流。加電容調整后隨機死機問題消失。

由此例還可以看出，嵌入式系統測試的軟硬件測試不可分性。絕對的將硬件測試和軟件測試區分開來的測試思想是不正確的。我們在系統測試時的電流測試設計如表4。

表4 電流測試

測試電流項目測試結果（不同的產品對電流要求不同）備  注預期值實測值待機電流/mA

關機后電流測試啟動電流/mA

開機瞬間電流測試工作電流/mA

正常工作電流測試（2）兼容性測試

考慮到嵌放式系統軟硬件的開發成本高于通用PC系統，因此，提高軟件對硬件的兼容及軟件升級版本的兼容性極為重要。表5是便攜林翰林電子書升級版本兼容性測試實例。

表5 兼容性測試

兼容性測試分類

硬件兼容性操作系統兼容性應用軟件兼容性PC制書軟件兼容性BIOS兼容測試

BIOSV1.0

BIOSV2.0

操作系統兼容測試

VOLF V.1.0

VOLF V.2.0

應用軟件兼容測試

READER V.1.0

READER V.2.0

PC制書軟件兼容測試

PCREADRE V1.

PCREADER V2.

實例2：現在的嵌入式系統的層次結構一般分為硬件層、BIOS層、操作系統層、應用系統層。有的還需要通用PC應用軟件支持。因此，嵌入式系統的兼容性測試要考慮硬件兼容性、BIOS兼容性、操作系統兼容性，還需考慮與相應PC應用軟件的兼容性。

篇(3)

關鍵詞：青島地鐵；AFC系統標準規范；標準符合性驗證；測試平臺；線網化建設

中圖分類號：U231 文獻標識碼：A

一、AFC系統測試平臺建設的必要性

新線正式開通前的驗證測試是未來線網化建設中新線接入并網運行必不可少的工作之一，該測試主要包括功能測試、性能測試及接口測試等內容。

目前，大多數城市并未建設正式的AFC系統測試平臺，每當舊線進行改造升級或新線即將投入運營時，通常利用維修培訓中心的設備對即將上線的AFC系統進行反復測試，以驗證期可靠性、準確性、安全性等各項指標。該方式只能實現線路內部的一些基本測試功能，相對簡單，無法完整模擬AFC系統五層架構。

青島建立一套相對完整的AFC系統檢測體系，能夠在AFC系統工程的各個階段，對模塊、設備和系統等進行檢測與調試，有利于提高AFC系統的技術水平、建設效率和運營質量，促進AFC系統技術的公平競爭和有序發展是非常有必要的。

二、AFC系統測試平臺一期實施方案

1青島地鐵AFC系統建設概況

伴隨著青島地鐵M3線、M2線、R1線的陸續開工建設，以及后續其它線路的規劃實施，青島地鐵將逐步形成互聯互通、多線路交叉換乘的線網化建設新局面。青島地鐵第一條線路M3線AFC系統建設，分為兩個標段，ACC系統（含標準編制、票卡采購）為一個標段，M3線AFC系統為一個標段。兩個標段均采用設備采購、集成、安裝為一體的總包方式進行招標。青島地鐵秉持標準建設先行原則，在第一條線路建設時將標準化建設納入ACC集成采購標段，由ACC系統集成商主編，并負責AFC系統標準的貫標、修訂、驗證及完善工作，同時為體現AFC系統標準規范的通用性和公正性，線路AFC系統集成商及設計院等單位作為參編單位積極配合。業主負責統一組織對標準問題所產生的爭端進行裁決。

2 AFC系統測試平臺一期實施方案

測試平臺既指物理上的場地測試環境，又指待測AFC系統或設備的運行環境，能完全模擬從清分系統到線路中央計算機系統，再到車站計算機系統及終端設備的運行環境。測試時將待測設備接入到該測試環境，配置到所在層進行測試。

青島地鐵在軌道交通線網建設初期，受到技術條件、人員經驗、投資等制約，將分別部署在控制中心和車輛段兩處的ACC模擬測試系統和線路AFC模擬測試系統進行整合，兩個測試系統間通過通信傳輸通道進行連接，組成一個典型的AFC五層架構體系，主要包括1個清分中心系統、1個線路中央計算機系統、2個車站計算機系統及2套各型車站終端設備。使用與運營系統相同的的操作系統、數據庫、AFC系統設備，測試工作站安裝仿真系統及其它測試工具。在測試任務中可在仿真系統、實際測試系統和生產系統中靈活切換，構成一套完整的AFC系統測試環境。整個平臺運行環境架構如圖1所示。

2.1測試依據

測試依據是進行測試的必要條件，它通常是產品的技術規格書、用戶需求書等。對于AFC這類專用系統，在滿足本系統通用技術標準或規范的基礎上，需符合用戶需求，即響應招標合同文件里的技術要求條款。

目前，針對軌道交通AFC系統，國家已經出臺了GB 50381-2010《城市軌道交通自動售檢票系統工程質量驗收規范》和GB/T 20907-2007《城市軌道交通自動售檢票系統技術條件》。這些均可最為測試依據。同時，青島地鐵已經制定了自己的企業標準《青島市軌道交通自動售檢票系統標準規范》，在系統界面、設備功能要求、性能指標等方面形成了標準化要求。這不僅是產品的衡量標準，更是測試工程設計的有效依據。

2.2 AFC系統測試平臺功能

該模擬測試平臺可用于：

（1）系統開發

提供二次開發所需的硬件、軟件開發環境，為系統（包括接口等）的開發、維護創造條件。每當AFC系統應用軟件版本更新、升級時，均需要在測試平臺上進行系統功能、性能等各方面測試后，方可正式上線應用，以確保應用軟件在修改后具有良好的穩定性、可靠性。

（2）系統測試

測試平臺系統與運營系統、異地數據備份系統有網絡連接，可從運營系統、異地數據備份系統獲得真實的運營數據，用于系統的測試調試。測試平臺系統配有測試用的系統仿真軟件，可生成大量的模擬交易數據，用于系統的功能測試和性能測試。

（3）生產系統的接入測試

新線AFC系統通過仿真測試及模擬環境系統測試后，調整網絡配置可快速的接入清分生產系統，與已開通線路進行全路網兼容性測試，確保新線的順利開通。

（4）票卡測試

票卡測試設備通過數據接口控制讀寫器的相關操作，檢驗讀寫器相關功能及各類票卡的操作速度，驗證被測設備是否符合AFC系統標準規范定義的功能及性能要求。

2.3 AFC系統測試知識庫

對測試過程中的測試需求和測試用例進行整理，形成測試需求和測試用例知識庫。通過測試過程管理，更新、完善、充實知識庫，并加入問題跟蹤等內容。建立測試知識庫有利于對測試經驗的整理和積累、提高，將以前松散的無結構的積累變成嚴謹的、有結構的、系統數據方式的積累。

建立青島地鐵AFC系統軟硬件知識庫，至少包括設備品牌、部件品牌、操作系統及其版本、應用程序及其版本等。有利于網絡化設備的兼容性、一致性和維護保養及其備品備件的本地化。

三、青島地鐵AFC系統測試平臺二期建設規劃

為了《青島市軌道交通自動售檢票系統標準規范》的貫徹、驗證等目的，目前，青島地鐵解決方式是在第一條線路AFC系統建設的同時，對分別在控制中心和車輛段的一套摸擬測試系統進行整合，這些系統的造價均包含在該條線路AFC系統的總造價中。該方案僅為線網建設初期的一種過渡方案，每條新線建設時均在車輛段建立一套摸擬測試系統會造成相當的浪費，不符合集約化建設的要求。

青島地鐵在AFC系統一期測試平臺及《青島市軌道交通自動售檢票系統標準規范》基礎上，將考慮在線網達到一定規模，并且人員、經驗、技術等方面有充足儲備后，單獨招標，在一個專門的物理位置建設青島地鐵AFC系統二期測試平臺，并充分考慮青島地鐵規劃建設的19條線路終端設備的容納空間，可完整實現AFC系統檢測業務、標準宣貫、技術培訓、AFC技術研發等一系列功能。

二期平臺可以用技術手段嚴格地驗證各個系統集成商和供貨商的AFC設備是否符合《青島市軌道交通自動售檢票系統標準規范》的要求、定義。其功能、性能指標等通過測試的AFC系統（ACC、LCC、SC）和設備（E/S、TVM、BOM、GATE、TCM等），可以發放設備的AFC網絡準入證。只有擁有準入證的設備才能安裝在青島地鐵AFC線網內運行。另一方面，也可提供測試過程管理功能和大量的測試需求、測試用例等知識庫，可用于規范測試過程的進行，提高測試質量和工作效率。

另外，有利于保證分期投入設備的兼容性，有利于有效降低人員培訓費用、降低備品備件種類和數量，有利于引入設備廠商間的競爭機制，降低設備采購費用。從而能為青島地鐵AFC系統的建設、運維、管理帶來現代化的手段，進而極大地提高AFC系統建設的質量并降低建設管理成本。

結語

目前，國內各地城市軌道交通建設方興未艾，對AFC系統測試平臺的關注度也越來越高。AFC系統作為與乘客直接接觸的系統，直接關系到乘客在地鐵用的用戶體驗，是地鐵服務的展示窗口，越來越受到重視。另外，各地都制定了自己的標準規范，為實現全線網的互聯互通、一票換乘等功能在網絡化建設中分期建設的各條線路AFC系統，都有進行線路接入測試、標準符合性驗證，同時手機移動支付、金融IC卡小額支付等新技術在AFC系統中也逐步得到應用，這些都要經過嚴格的測試驗證后才能正式應用，因此對AFC系統測試能力提出了更高的需求。

本文通過分析新興城市軌道交通線網建設不同階段，AFC系統測試平臺建設需求，給出一些AFC系統建設過程中的建議，為軌道交通建設管理工作提供一些參考。

參考文獻

[1] GB 50381-2010 城市軌道交通自動售檢票系統工程質量驗收規范 [S].北京：中國計劃出版社，2010：46-54.

[2] GB/T 20907―2007 城市軌道交通自動售檢票系統技術條件[S].北京： 中華人民共和國質量監督檢驗檢疫總局，中國國家標準管理委員會，2007.

[3] 青島地鐵集團有限公司.青島市軌道交通自動售檢票系統標準規范 [S].青島，2012.

[4] 李昱見，管宏.新建軌道交通第二條線路AFC系統并網的關鍵問題[J] .中國鐵路，2013：76-80.

[5] 徐曄.自動售檢票系統由單線路向網絡化遷移的實現[J].都市快軌交通，2013，26（3） ：116-118.

[6] 呂毅.西安地鐵AFC系統線網化建設[J].都市快軌交通，2013，26（1） ：107-110.

篇(4)

關鍵詞：構件化；軟件開發；過程；開發實例；系統測試技術；構件測試方法；問題

中圖分類號：TP311文獻標識碼：A文章編號：1007-9599 (2012) 03-0000-02

Component-based Software Development and System Testing TechnologyExploration

Ye Wei

(Ningbo Dahongying University,Ningbo315175,China)

Abstract:Along with the social demand for software continues to increase,as well as the difficulty and cost of software development increase,the technology of component-based software development and system testing is more extensive,component-based software development process to explore,while the use a development instance,the last component-based software system testing and component testing methods,

and come to the problems in the testing techniques.

Keywords:Component-based;Software development;Process;Development instance;System testing technology;Component test methods;Problem

近年來由于軟件系統困難度及復雜性不斷加大，以及不斷增加的軟件開發規模，同時軟件開發機構不僅對開發軟件的成本有了日益增高的要求，還對開發周期提出更多要求。當軟件開發面向對象分析以及設計方法以后，構件化的軟件開發形式已變為新發展趨勢。把外部開發的構件集成至實際具體應用中，進而面向固定應用的軟件系統得以合理構建，對軟件集成以及重用產生相當重要的影響，其已變為目前軟件研究領域的熱點以及主流技術。另外在構件應用前進行相關測試，也被實踐證明了其正確性。

一、構件化軟件開發過程分析

對于基于構件的開發，其指開發軟件系統的時候，把這個過程視為基于體系結構指導，合理運用構件組裝形式，進行軟件系統開發的一種軟件開發方法。下述的四個階段構成了構件化軟件開發過程。

第一個階段就是進行問題域分析與建模的階段。針對具體的問題情形，合理實施分析以及建模，與此同時，能夠利用合適的UML模型進行表示說明。

第二個階段就是求解域模型設計階段。針對問題域，合理實施分析建模，隨后得到求解域模型，就是系統需要的構件以及系統的體系結構。針對那些可以進行復用的構件，對其接口進行合理分析，然后確認是否應該進行擴展，要是增加一些新的構件，進行恰當的分析設計，進而保證構件可以達到求解域的需求。還要盡可能地保證構件有著可復用性。

第三個階段就是構件的開發及組裝階段。在構件庫內，進行可以達到需求構件的選用，并對其接口進行擴展，使之于目前工程相適應；針對新研發出來的軟件構件，可以把它儲存到構件庫內，保證日后的方便復制使用，還應把它運用到目前的工程里[1]。組裝完成后，完整的系統便得出，進行測試合格之后，就能夠運行。

最后階段就是應用系統的演化階段。針對構件的應用系統的演化，換句話說就是構件的替換、升級以及擴充的過程，按照具體的運行效果，同時根據用戶的實際要求，合理調整軟件，以保證期對新的環境的適應性。

二、開發實例分析

當進行某個系統開發的時候，積極采用構件復用技術，進而確保權限配置管理功能的實現。通過合理的分析，對于系統的權限管理，“用戶-角色-功能”方式得以確定，其為基于角色的訪問控制模式，對已有構件的復用可以確保此功能的合理實現。

角色管理以及用戶管理構件、角色節點配置構件、節點管理構件及用戶角色配置構件，這五個構件都存在于構件庫中，其中角色管理構件對系統制定的角色進行維護，與此同時就角色的名稱以及描述等信息進行合理管理；用戶管理構件則是對一個系統用戶信息進行管理的，主要由登陸名、登陸密碼構成的；對于角色節點配置構件，其重點應用在進行節點與角色之間對應關系的配置，保證一個角色能夠顯示幾個功能節點的制定，進而間接的對某個角色具有的功能進行合理限定；節點管理構件主要作用在管理系統功能樹上的節點中；用戶角色配置構件則用于用戶和角色對應關系的配置。以上五個構件不是單獨運行的，而是相互合作的，正是由于它們的互相合作才使系統中權限管理的相關功能得以實現。

三、構件化軟件系統測試技術研究

由于構件自身具有的特點，實施測試人員主要由構件的開發方以及構件的使用方來組成的，由于他們在測試中占據不同的立場，在實施測試的內容方面多少會存在一定的差異性：一是測試目的是不相同的，構件的開發方對構件的所有功能進行測試，構件使用方則更多的關心與其有關部分的功能。二是使用的環境存在差異性；三是具有的資源存在差異性，對于構件開發方，其對構件源代碼有著一定擁有權，但是對于構件的使用方，只具有構件的可執行代碼；于是，當對構件軟件進行實施測試時，要分別站在構件的開發方以及構件使用方等兩個角度上展開[2]?；跇嫾氖褂梅浇嵌?，測試方法是通過測試構件類型進而得出，具有兩種主要類型的構件：首先源代碼不確定，只給予使用方測試的信息當作所提供服務的COTS構件；另外一種是源代碼具有可訪問性的構件。當構件類型不同時，對測試方法的選用也是不同的。

（一）對構件測試方法的分析

目前，對構件的測試主要是通過以下幾個方法：

1.基于構件使用規范說明的測試。以下方法都與構件開發方有著一定聯系，本方法按照構件運用方就應用環境與規范給予的數據當作測試用例，只局限于黑盒測試中來使用。

2.內置測試。對于構件開發方，他們把有著可執行性的測試用例內置于構件內，同時當作構件的常用功能，在構件集成于實際應用環境的情況下，對其中測試用例進行運行，進而進行集成測試；

3.元數據。針對在集成測試的時候，構件信息缺乏等一些問題，構件開發方將關于構件的基本信息通過元數據這一合理形式，給予構件測試或者使用方，確保測試順利地實施，提升構件的可測試性是它的核心內容；

4.可測試體系結構。由構件開發方會提供與構件相配套的可測試體系，這樣構件使用方在實施測試的情況下，能對測試用例進行直接執行，和上述各個方法相比，不同的是，該測試信息通過規范的形式附加于構件之上，當運行的時候，沒有占用內存[3]。

5.證明策略。一般情況下，由于構件證明不同的承擔方，構件證明主要包括以下幾類：首先是構件使用方構件證明，其次是第三方構件證明，最后為構件開發方構件證明。

（二）構件測試技術中存在的一些主要問題

對于構件集成測試，很難對其實施，主要有兩方面的原因：異構性的存在以及相關信息的缺少。針對異構性，其表現為：同一個構件處于相同規范下，具有不相同的實現方法；不相同的構件能使用不同平臺的不同程序語言進行實現；由于構件使用方與開發方兩方很少進行交換信息，便導致了信息缺乏，構件開發方主要對開發構件的應用環境沒有足夠了解，所以，它進行的構件測試只可以面對假設的應用環境，但是實際環境和假設的環境之間一定具有差別，在實際的應用中，各個構件在動態交互過程中可能會出現數據交換不能有效兼容等問題。從另一方面，構件的源代碼因為相對構件運用方法有著某些未知性，于是，對其實施靜態分析是很難進行的。更別說對相關數據依賴以及控制依賴關系的獲得，進行有關測試用例的構造，進行測試，確認出進行測試需要的充分性準則是很難的。所以，在構件測試技術中，應該考慮以下幾個問題：

1.怎樣利用系統方法對測試驅動程序與插針進行構建。對于構件測試驅動程序，其一定是基于腳本的程序，同時僅僅對其黑盒功能進行執行。主要有基于場景以及規范的測試驅動程序；各個測試探針進行構件行為或者黑盒功能的合理模擬，在當前，還是主要通過基于操作腳本以及基于模型的方法。

2.怎樣合理構造出可重用的構件。就是開發系統方法以及工具安裝可重用的測試程序，進而進行各種測試資源的存儲及管理，主要有測試腳本、測試用例以及數據[4]。在當今，兩個方向較為突出，一個為于構件內部中進行構件測試的創建，內置測試就是實例；另外方向是使用可直接插拔技術進行一套測試程序的創建，不僅牽涉了測試訪問接口以及標準化測試信息格式，還牽涉到測試數據庫模式與定義以及開發新的可插拔技術支持構件單元測試。

3.怎樣正確進行可重用及通用的構件測試平臺的構建。在一般情況下，測試檢索以及執行、測試結果檢查以及報告組成了測試執行環境。此測試平臺可以根據不同語言及不同技術開發實現的構件是它的主要問題。

4.怎樣合理進行可測試構件的構建。其牽涉到三個問題，就是定義及設計可測構件的測試接口與公共結構、開發系統方法進行可測構件的構建、最小化系統資源及開銷。

四、總結

由于社會對軟件的需求一直增加，軟件復雜度及規模一直加大，因此，人們就不斷探索創新軟件開發技術，進而滿足軟件發展的需要。對于構件技術，其要經過創建及復用構件，還要通過組裝構件保證軟件系統開發的完成，能使系統的開發效率提高，系統的開發成本還減少，進而達到軟件復用的要求。于是，構件化的軟件開發方法能夠作為一種有效途徑，使軟件危機得以解決。與此同時，更要引起構件測試技術中的一些主要問題。

參考文獻：

[1]梅宏,楊芙清.構件化軟件設計與實現[M].北京:清華大學出版社,2008

[2]許幀．基于構件的軟件開發方法及實現[J].軟件導刊,2009,11:17-19

篇(5)

1 簡介

1.1 范圍

測試用例的執行覆蓋高原夏菜無公害胡蘿卜栽培管理專家系統、日光溫室黃瓜無公害栽培管理專家系統、特色產業決策系統（綿花產業）、特色產業決策系統（綿花羊產業）等。

系統測試自2011年9月7日起對系統的功能及業務流程、界面風格、安全訪問控制等進行了黑盒測試，對系統的用戶使用數、頁面性能要求進行了相應的性能測試。

1.2 定義、首字母縮寫詞和縮略語

EXP 為特色產業專家系統與決策支持系統的英文簡寫。

1.3 概述

本測試評估從功能測試和性能測試的兩個角度來對我省特色產業專家系統與決策支持系統進行評估。內容主要包括：基于需求的測試覆蓋、建議的措施以及相關的測試結果圖示說明。

2 測試設備

PC1：硬件 CPU：PIV 1.50G，內存：512M硬盤：40G，軟件：Winserver 2003/IE8.0；

PC2：硬件 CPU：PIV 2G，內存：2G硬盤：300 G，軟件Winxpsp2 Winserver 2003/IE8.0。

3 測試環境

3.1 硬件配置

Web服務器硬件配置：TOMCAT服務器，CPU：PIV2.80，內存：1 G；硬盤：300 G；網卡：10/100 M自適應。

數據庫服務器硬件配置：PC臺式機，CPU：P43G，內存：1 G；硬盤：300 G；網卡：10/100 M自適應。

3.2 軟件配置

服務器軟件配置：開發工具：IBMWSAD5.0；JDK環境：j2se1.5或更高；

系統環境：Windows 2000/XP/2003；

Web服務器：Apache 2.4+tomcat6.0

數據庫系統：SERVER 2008。

3.3 測試方法

以黑盒測試為主，測試的重點集中在業務流程、數據提取和各功能模塊間的接口。其中單元測試由開發人員直接完成；功能模塊采用黑盒測試的常用方法；集成測試模塊采用非漸增式測試，偏重系統的接口和數據提取方面；系統測試主要體現在業務流程的測試，主要采用回歸測試。包括數據測試、功能測試、用戶界面測試、性能評測、安全性和訪問控制測試。

4 測試覆蓋分析

需求覆蓋率是指經過測試的需求/功能和系統分析中所有需求/功能的比值，通常情況下要至少達到99 %的目標。

被驗證通過的需求26個，需求總數26個。

需求覆蓋率=通過驗證的需求/需求總數=26/(26)×100 %=100 %(詳見表1)。

4.1 缺陷收斂曲線圖

4.2 缺陷生命周期圖

從缺陷生存周期來分析：整個缺陷數占比最多的是生存周期在1周的缺陷,總共161個，約占總數的75.23 %,說明開發組對缺陷的響應時間相對較快，能在較短的時間內對bug進行修復。

5 測試結論

5.1 安全性 做了用戶登錄安全訪問控制測試，即各種條件下的用戶登錄測試，系統安全性高。

篇(6)

關鍵詞：操作系統測試；缺陷處理流程；缺陷接受方案

一、序論：缺陷的生命周期

操作系統測試是操作系統開發項目中的重要組成部分，是通過人工或自動的方法，來確認一個操作系統的質量或性能是否符合開發之前所提出的要求。在操作系統開發項目中，測試屬于項目質量管理的角色。而無論在操作系統測試還是其他普通軟件測試項目中，缺陷（bug）管理都是測試項目的重中之重。

本文將簡要介紹操作系統測試項目中的bug生命周期、bug處理的一般流程、bug等級劃分，以及在不同情況（是否需要兼容多家廠商的硬件平臺及板卡）下，bug的接受方案的選擇及處理的建議。

首先，我們需要簡要介紹一下bug的生命周期。bug的產生到消失，存在一個生命周期。每個操作系統廠商或者測試項目小組對bug的生命周期劃分不盡相同。但在業界一般會把bug的生命周期大致分為以下幾個狀態：

1.提交

當測試工程師發現新bug，并提交到bug管理系統中時，該bug的狀態標記為new。提交時應注明其詳細信息，并根據規定對此bug標記嚴重程度。此時，該bug的生命周期正式開始。

2.接受

項目經理接收到這個bug后，首先要判斷這個問題是否是bug。

如果是bug，則接受該bug，此時，其狀態應由項目經理標記為open。在這個階段，項目經理應協調開發人員，分配軟硬件及時間資源，并由開發人員來修復這個bug。直到開發工程師完成修復（fixed）或拒絕修復（rejected）為止。

3.拒絕處理（Rejected）

開發人員認為該問題不是Bug、現象描述不清、與現有bug重復、不能復現，或可忽略不計，從而拒絕處理該問題。則將這個bug標記為rejected，并通知測試工程師，之后由項目經理關閉（closed）。

4.修復（Fixed）

開發工程師在修復完該bug后，該bug即進入fixed狀態（由開發工程師標記，后轉入retest階段。

5.重新測試（Retest）

在開發工程師修復該問題后，測試工程師需要重新測試。確認是否完成修復，并檢查是否有新問題出現。測試成功，則轉入新版本測試階段（new build retest）；否則，轉入重新開啟（reopen）階段。

6.新版本測試（New build retest）

該操作系統產品在新的內部版本時，重新測試該bug。檢查問題是否重現。該狀態應由測試工程師標記。若未重現，則轉入關閉（closed）狀態；否則轉入（reopen）狀態。

7.重新開啟（Reopen）

測試工程師對修復后的問題進行驗證，若不通過，或者又因此重新出現新的錯誤，則bug的狀態應該由測試工程師標記為reopen。并交由開發工程師重新修復。

8.關閉（Closed）

所有測試流程通過，則應由項目經理將bug狀態標記為closed，并對此操作負責。

根據項目及bug的實際情況不同，測試項目經理對本公司的產品的bug生命周期劃分可能略有不同。在上面介紹的生命周期中，new build retest狀態就有很多公司沒有采用。但筆者仍認為該步驟是必要的。因為在新的內部版本后，重新檢測已知bug會對產品的穩定性提供相應保障。

二、缺陷處理流程分析

根據bug生命周期，我們可以采用以下流程來提交、接收、處理、關閉bug：

（1）測試工程師發現新bug，并提交到相應的bug管理系統中。

（2）項目經理確認。并指派相應的研發工程師進行修復。

（3）研發工程師判斷是否需要修復該bug。若需修復，則修復后將修復結果轉交給測試工程師重新測試；若拒絕修復，則說明理由，并請項目經理關閉該bug。

（4）測試工程師核實該修復結果。若通過核實，則在操作系統的新版本后，再次測試；若不通過，則將該bug回退給開發工程師重新修復。

（5）在操作系統的新版本中測試該bug后，若測試成功，則關閉該bug。若失敗，仍然回退給開發工程師重新修復。

在上述的流程中，我們可以看到，被bug接受（open）后，項目經理會指定相應的工程師來完成修復。這是在操作系統只運行在本公司所生產的硬件平臺上的情況下，通常所采取的bug處理流程。此時，項目的復雜程度較低，各方面資源的協調相對容易。項目經理可以獨自分析并定位該問題出現的原因，同時協調相應的部門及工程師來對bug進行修復。即使bug現象模糊，不能準確判斷，也能比較方便地通過協調各研發部門的資源來共同定位。

而如果該操作系統需要與其他廠商的硬件平臺兼容，則需要判斷該bug究竟是操作系統本身的問題，還是與合作廠商的硬件平臺的兼容性問題，或者只是硬件平臺本身的問題。此時，測試項目組作為第三方質量管理角色，對bug的處理流程就需要相對復雜一些?？梢酝ㄟ^增加部分流程，來對bug進行處理：

（1）在bug的open狀態下，項目經理確認是硬件問題還是操作系統問題。若合作廠商的問題，則在其相應的bug管理系統中提交并登記。

篇(7)

【關鍵詞】網絡 布線系統 纜線 檢驗 設備

眾所周知對于計算機網絡較為廣泛的說法是：通過通信線路將地域上分布的、擁有獨立功能的計算機系統和網絡設備按一定的規定連接在一起，成為功能較完備的應用軟件和通用協議，進而實現共享資源和傳遞信息的系統。同時也是計算機技術與通信技術相結合的產物，為了使網絡實現信息交換和資源共享，要對布線系統進行測試和驗收，事實上其貫穿整個工程的始終，因為可以及時發現構建網絡過程中存在的質量問題，減少通信線路潛在的隱患，此過程是確保網絡工程質量的關鍵，下面我就逐一進行講解與說明。

1 布線環境的檢查

在對工程實施之前，應該對專用交接間、設備安裝間以及工作區基礎建筑和現有環境狀況進行排查，達到要求條件才能動工：

基礎工程是否已全部竣工，室內墻壁要充分干燥，地面平整干凈，房門設備齊全。

房間預制地上坑槽、各種暗管、墻體孔洞和通體豎井設計位置、預留數量、相關尺寸應該達到要求規格。

設備間是否接入電源，針對安裝活動地板的房間，必須實施全面檢查，每平米水平誤差應不大于2mm，做好防靜電處理且接地達到工程需求。

設備安裝間、交接間等應安裝帶接地保護的220V單相預留電源插孔。安裝位置、使用面積、光線照明、房頂高度、通風狀況、防水火處理及周邊溫、濕度等應充分考慮。

預留好交接間垂直通道電纜孔孔洞，并應檢查水平通道管道、電纜橋架和環境條件狀況。

施工器材及測試工具檢查。

2 相關器材、管制品與金屬套件的檢測應遵照下列要求

（1）所用材料的型號尺碼、規格限定、材質構成應滿足工程設計的需要，器材表面需光滑且平整，無明顯破損、斷裂、變形。預制各種線槽、穿線盒、接線盒及橋架等表面涂層或鍍層也需均勻、平整，無走形、破損。

（2）所需管材采用金屬制品或塑膠制品時，其通體管件應完好、無損壞，管孔無明顯變形，孔徑直徑、管壁厚度應遵循設計要求。如果我們用金屬管槽應按照工程環境需要做好防止腐蝕處理。塑膠制管槽必須采用阻燃材質且附有阻燃標識。

（3）對于室外相關管道必須依照工程質量驗收的標準進行檢測，并進行防火、防水以及防腐蝕處理。

（4）金屬件無變形、明顯彎曲、細小毛刺、重創開裂或壞損等。外表面及鍍層應均勻、細滑，無脫皮、無渣泡等。

工程纜線的檢測應遵照下列要求：

（1）工程所需的各種纜線型號尺碼、材質構成、規格限定、防火級別應滿足設計需求。

（2）纜線上面標簽、標識內容必須明確、清楚，且包裝應注明出廠日期、型號、長度等。

（3）所用纜線應配備本次批量的反應電氣性能的檢驗報告，施工前需進行數據鏈路或信道傳輸的電氣性能檢測，纜線長度的抽檢也是必須的。

（4）檢查光纜合格證書及檢驗數據，必要時應進行衰減測試與長度測試。

3 工程設備安裝檢驗

機柜、機架安裝位置應符合具體設計要求，垂直偏差度應不大于2.5毫米；各種零件不得損壞，漆面如有脫落及時補修，各種標志應清晰完整；設備的安裝應牢固，達到一定抗震要求。

信息模塊插座應設計在活動地板或水平地面上，需在接線盒內固定，插座面板可采用豎立形式，也可水平安裝；但接線盒蓋需具有開啟功能，并做好抗潮、抗塵、抗壓處理。固定螺絲需擰緊， 各種插座面板附有鮮明圖形符號、中英文字等標識指示出所接設備終端類型。

電纜橋架及預制暗槽的設計左右偏差不超過45毫米，水平度每米偏差不超過1.5毫米；且應與地面保持垂直，線槽截斷處及兩線槽拼接處應平滑、無毛刺；采用懸空支撐柱布放纜線時，支撐點盡可能繞開地面溝槽或暗槽。

4 纜線的架設及日常維護檢驗

纜線的連接需自然伸直，不得出現交叉纏繞、接頭交錯等現象； 兩端應貼有清晰標簽，纜線應有余量以適應終接、檢測和變更；纜線的彎曲半徑不同的材質應符合相關規定。

架設線槽和暗管的兩頭需標識出廠日期、序列編號、范圍尺度等項目；預制道槽宜采用堅固類金線槽，截面利用率不超過50%；暗管宜采用鋼管或阻燃PVC管，布放多層傳輸介質。

施工中如果需纜線垂直架設時，最上端和間隔1.8米處需安全固定；而水平架設時，在纜線的始、末、轉向處及間隔8米處需進行安全固定；光纜在橋架敞開敷設時應在綁扎固定段加裝墊套。

5 工程保護措施

預埋金屬線槽符合保護要求。

預埋暗管符合保護要求。

合理設置纜線橋架和線槽保護。

設計網絡地板纜線敷設。

干線子系統纜線敷設保護方式應符合要求。

6 工程竣工驗收材料

工程竣工后，施工方應在驗收之前，將工程竣工相關資料交付建設方。詳細材料必須包括如下文件：全部工程詳細說明書；所用器材及設備明細表；施工設計圖；相關測試記錄；檢查記錄及雙方協商記錄；隨工驗收記錄；隱蔽工程簽證；工程決算。

參考文獻

[1]林生.計算機網絡與因特網[M].北京：機械工業出版社，2009（6）.

[2]歐陽廣.網絡建設與施工[M].北京：中國勞動保障出版社，2003（4）.

[3]孫建華.網絡系統管理---Linux 實訓篇[ M].北京：人民郵電出版社，2003（2）.