系統測試范文

導語：如何才能寫好一篇系統測試，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

三年以上工作經驗|男|29歲（1987年3月11日）

居住地：曲阜

電　話：158******（手機）

E-mail：

最近工作[1年7個月]

公　司：XX有限公司

行　業：通信/電信/網絡設備

職　位：系統測試

最高學歷

學　歷：本科

專　業：通信工程

學　校：曲阜師范大學

自我評價

本人畢業于軟件工程專業，在學校經過多年的努力，有著扎實的計算機基礎。目前一直從事于IT 行業，熱愛軟件測試，有多年的測試經驗，熟悉軟件的開發的流程和測試流程，熟悉b/s 框架系統和C/框架的區別，有豐富的測試經驗，了解 QTP 和 loadrunner 的工作原理。XX年測試經理，XX年的測試主管，積累了豐富的管理經驗。希望從事測試經理以上職位（最好是高級測試經理和測試總監）的測試管理工作。

求職意向

到崗時間：一個月之內

工作性質：全職

希望行業：通信/電信/網絡設備

目標地點：曲阜

期望月薪：面議/月

目標職能：系統測試

工作經驗

2013/11 — 2015/6：XX有限公司[1年7個月]

所屬行業：通信/電信/網絡設備

測試部系統測試

1.熟悉手機功能機，智能機（MTK，展訊，高通，瑞芯微/INTEL 6321/SOFIA平臺）方案，手機軟件研發流程。熟悉安卓系統，將針對產品制定出全面測試案例，專項測試案例，壓力測試案例。

2.測試報告的提出，回復，驗證及BUG問題詳細記錄，做到可以追溯。

3.版本號規則命名，軟件存儲路徑規范，軟件測試流程的商討等

4.協助和推動項目組將產品軟件改善達到穩定狀態。

2011/9 — 2013/8：XX有限公司[1年11個月]

所屬行業：通信/電信/網絡設備

測試部 系統測試

1.及時了解項目進度,及時了解軟件狀態，減少軟件問題延誤進度

2.未處理的嚴重問題,及時反饋,跟催.已改善的嚴重問題,反復測試驗證,重點關注

3.硬件/軟件問題及時與工程師溝通,反饋到所有相關人員.該重視問題會重點強調.

4.建立BUG數據匯總,讓相關人員了解每周BUG處理情況

教育經歷

2006/9— 2011/6 曲阜師范大學 通信工程本科

證書

2007/12 大學英語四級

篇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個人員（甲、乙、丙、丁）對系統5個功能打一個從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

關鍵詞：項目管理；系統測試

1項目管理與系統測試的各種定義

項目是為提供某項獨特的產品、服務或成果所進行的臨時的一次性努力。更詳細的解釋是用有限的資源、有限的時間為特定客戶完成特定目標的一次性工作。系統測試的定義：一般就是在軟件項目開發完成之后，根據系統需求分析說明書給出的規則進行驗證的過程，需求測試人員編寫testcase（測試用例），一一進行驗證，若發現問題，則提交bug（缺陷）。我們可以把系統測試理解為一個項目，就是在規定的時間內，把軟件項目的各種功能與性能需求根據需求分析說明書的定義進行一一驗證的過程。項目管理的思想可以很好的應用于系統測試的整個流程。下面我們進行逐步分析。項目管理，就是把各種知識、技能、手段和技術應用于項目活動之中，以達到項目的要求。項目管理是通過應用和綜合諸如啟動、規劃、實施、監視與控制和結尾等項目管理過程進行的。項目管理過程包括：啟動、規劃、執行、監督與控制、收尾過程。系統測試過程包括：測試申請、測試用例編寫與評審、測試執行、測試控制與監督、測試報告編寫與。上述過程是一一對應的關系。項目管理的過程同樣適應于系統測試過程的管理與控制。

2系統測試在項目生命周期的位置與作用

一般軟件項目的生命周期有：需求調研、軟件設計、概要設計、詳細設計與編碼、單元集成測試、系統測試、版本。系統測試在整個軟件開發的生命周期是排在靠后的位置，但是測試工作應該在最初的需求調研就開始涉足，否則進入的越晚，后期發現bug進行修正的成本就會越高。當需求分析說明書進行定義的一個功能，開發人員未能完成開發，在測試申請進行提交后，進行系統測試用例編寫，如果在此過程中未發現此問題。則后期必然出現嚴重bug（因功能需求未能實現，定義為嚴重bug），后期開發人員需求加班加點進行增加新功能，這樣會導致開發成本成幾何級別的增加。因此建議測試工作項目的開始就進行工作任務的分配。系統測試的作用，就是為了保證項目軟件的質量，能夠達到用戶的要求，符合市場需求。不僅僅只能為了走一個流程而設定，這里確實需要我們測試工程師做出很多工作與努力的。前期發的bug越多，解決的越多，就能夠更好的保證產品質量。

3現代項目管理的思想

現代軟件項目管理思想有傳統的瀑布模式管理、敏杰開發兩種模式。瀑布模式：是1970年溫斯頓•羅伊斯提出的模型。瀑布模型將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試、運行維護等六個基本活動，并且規定了他們自上而下、相互銜接的固定次序，如同瀑布一樣，逐級下落。從本質上來講，他是一個軟件開發模式，開發流程是通過各種階段展開的，從系統需求分析到產品維護運行，每個階段都會產生各種循環反饋，因此，如果有的信息未被完全覆蓋或者發現了個別問題，那么最好返回上一階段并進行修改，開發進程從一個階段流動到下一個階段。敏捷開發模式：敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分為多個小項目，各種小項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個互相聯系但也可以獨立運行的子項目，并分別完成，在此過程中軟件一直處于可使用狀態。兩者各有所長，根據軟件項目的大小，我們可以詳細將系統測試所用的模式進行分類。一般的大型項目需要長周期的，則可以考慮瀑布模式管理，這樣可以很好的分配資源，有文檔和流程管理，可以保證項目系統測試能夠正常的進行。若是項目比較小巧靈活，可以考慮敏捷開發的模式，邊開發邊測試邊修改。開發與測試同時進行工作，也能方便溝通交流，有問題就可以吼一聲，確認了bug之后，進行修改，驗證，能夠縮短項目系統測試的時間，使得產品版本盡快，使得產品部門，銷售部門能有充足的時間進行宣傳與運作。

4傳統的系統測試現狀與弊病

現在的系統測試一般情況是在項目開發之前的15天，提交項目測試申請；測試人員根據項目需求分析說明書編寫，系統測試用例與系統測試計劃；然后執行項目系統測試；編寫測試報告進行。但是往往因為項目管理的原因，需求各種變化，所以在提交測試申請的時間一般只有5天左右的時間，進行項目測試計劃與測試用例編寫、評審。在5天的時間內，測試人員進行系統需求分析說明書的理解，往往不夠徹底，在評審工作中，會出現修改測試用例的情況發生。這樣會造成測試時間減少的壞處。在測試執行過程中，因為測試人員對需求分析理解的不透徹，需求跟產品設計、技術經理、開發人員各種溝通交流，會影響測試質量的提高。在測試執行過程中，也會發生因為老板決定要版本，讓步放行，連帶bug一起的情況發生，這都是傳統的系統測試存在的問題。

5如何將項目管理應用于系統測試

我們把系統測試理解為一個項目管理的過程。在系統測試的過程中應用于項目管理的思想，就可以很好的解決上述問題。利用新的項目管理的思想，進行項目任務的分配分解，很好的疏通各種人員關系，合理的分配時間、人力各種資源，就看可以很好的項目系統測試的正常進行。系統測試計劃的編寫，就是整個項目的規劃設計，需求制定測試時間安排、人員配備，系統測試各個階段（輪數）的詳細時間人力投入。利用項目管理的思想解決系統測試的問題，可以將系統測試的各個階段，能夠保證在測試經理的控制之中，可以詳細的了解系統測試過程中，遇到的各種問題，及時與項目經理進行溝通，保證項目質量的問題。系統測試用例的編寫，利用項目管理的思想，進行分類分模塊編寫，覆蓋整個項目需求分析說明書。在用例編寫后，進行測試用例評審的過程中，利用項目管理的思想，選擇技術、產品、分析、設計、開發人員進行評審，保證后續測試執行能夠正常完成。系統測試的執行過程中，可以用項目管理的范圍控制、進度管理進行詳細管理。如果碰到項目需求分析發生變更，利用項目管理的流程變更，進行相應的系統測試變更，需要各級領導同意。在系統測試執行過程中，也要考慮到成本控制的問題，同樣在項目管理思想中也有相應的解決方法。系統測試的控制過程，如果發生了一些意外情況，比如說項目延期，則需要測試經理進行郵件說明，向各級領導申請同意。項目的系統測試延期，可能會影響很大，在項目管理思想當中，有項目失敗的經驗可以借鑒，具體操作方法，各位可以參考一些項目的書籍。

6總結

篇4

關鍵詞：系統測試；軟件測試；功能測試；測試方法

中圖分類號：TP315 文獻標識碼：A 文章編號：1009-3044（2017）04-0057-02

1 軟件測試概述

軟件測試是通過檢測給定的輸入和預期的輸出之間的差異來評價軟件產品的過程。同時，評估一個軟件項目的特點。測試評估產品的質量。軟件測試是一個過程，應在開發過程中進行。換句話說軟件測試是驗證和確認過程。

軟件測試的目的在于想從軟件研發的角度出發，從而盡可能地找到軟件之中的缺陷。欲發現程序之中的不足之處，就要盡可能從最大水平上發現可顯示出的錯誤用例、測試用例，其通常可以通過測試信息以及預期效果進而被創造出來。測試主要是通過較少的用例，從而找出軟件之中可能存在的形形的問題。其根本目標就是用盡量少的時間，動用盡可能少的人力資源發現軟件中盡可能多的問題。

由測試階段對軟件測試進行劃分，可以對應的分成單元、集成以及確認等多方面的測試。就方法上來劃分，則可以分成黑盒與白盒兩種測試形式。

2 居民信息管理系統的測試方法與測試環境

分析以.NET為基礎的該系統研發過程，綜合考慮技術、人力以及當地現實情況等多方面的內容，最終決定使用黑盒測試方式來完成測驗階段的工作。

從南疆農村當前的硬件設備、互聯網以及設備角度考慮，我們采用了下列的測試環境：

2.1 測試硬件環境

硬件配置涵蓋了服務器端和客戶端兩方面的硬件配置。

1）服務器端硬件選擇

CPU：Intel XEON E5 2600/1.6GHz

內存：8GB DDR4

磁盤：RAID 3/80GB SATA

顯示器：1024*768，256 Colors

2）客戶端硬件選擇

CPU：酷睿i3

RAM：2GB

硬盤空間：320GB

2.2 測試軟件環境

1）服務器端軟件配置

操作系統：MicrosoftWindows Server 2008

Web服務器：IIS8.0

數據庫系統：Microsoft SQL Server 2008

其他：.NET Framework 4.0

2）客戶端軟件配置

操作系統：Microsoft Windows 7/Windows 8

瀏覽器：Internet Explorer 8.0及以上版本。

3 系統功能測試及用例

3.1 測試大綱

3.2 測試用例

對于下述用例介紹的檢測階段，符合測試條件的用戶登錄，根據測驗的步驟運行。測試結果滿足預估的需要，在列表當中的最后一欄之中測試結果之中挑打√，反之則畫×。

3.3 界面測試用例

1）操作過程中系統顯示的各種提示、警告信息

結果：以上屏幕信息都正常、合理。

2）判斷系統運行過程產生的各種問題，并確定發生問題的位置有無提示

結果：產生的問題都有錯誤提示并顯示錯誤發生的位置和愿意，防止無提示長時間等待。

3）對用戶的錯誤輸入有誤正確的判斷和相應的提示

結果：判斷正確，有提示。

4）針對數據清空、刪除等不可逆操作有`明確的警告并確保有放棄操作的機會

結果：有警告提示，用戶能夠取消操作

5）相關字體是否正常，風格一致

結果：字體顯示正常，一致。

6）所有頁面的背景和字體顏色是否正常、搭配合理

結果：正常、搭配合理

7）頁面文字有無拼寫錯誤

結果：無拼寫錯誤

8）所有頁面的說明性文字是否流暢

結果：語義清晰、語句順暢

9）所有頁面的窗口布局是否合理、正常

結果：結構設計合理、正常。

4 系統測試總結

經過對于居民信管系統之中的所有模塊對應的采取功能檢測，所有模塊的表現合理、正常，業務功能測試滿足業務的對應需要。

針對系統實施了全方位的性能檢驗，并對相關結果展開了深入的研究，項目組針對分析結果，對系統進行進一步的調整，現階段系統運行表現正常。

本文針對該系統的功能測試提出了測試方案，然后給出了系統測試硬件和軟件環境，最后給出了系統測試全過程和測試用例并進行了總結。

參考文獻：

[1] .NET Framework 概述[OL]， http：///zh-cn/library/zw4w595w.aspx.

[2] 劉曉華， 張健， 周慧貞. 應用開發[M]. 北京： 電子工業出版社， 2007.

[3] 虞益誠等. SQL Server 2005 數據庫應用技術[M]. 北京： 中國鐵道出版社， 2009.

[4] 郭靖等. 開發技術大全[M]. 北京： 清華大學出版社， 2009.

[5] 王華章. 2.0 網絡系統開發實用教程[M]. 北京： 中國鐵道出版社， 2006.

[6] 毛德祥， 羅榮閣. 基于技術的Web應用程序三層設計模型[J]. 微型電腦應用. 2002（3）.

[7] Christian Nagel， Bill Evjen， Jay Glynn， Morgan Skinner. Professional C# 2005 with .NET 3.0[M]. Wiley Publishing Inc， 2007.

[8] 牛立成. 交互式網頁編程技術（）[M]. 北京： 北京大學出版社， 2006.

篇5

關鍵詞安全管理,區間信號,數據庫設計,計算機輔助測試

城市軌道(簡稱城軌)交通區間信號系統是安全性苛求系統。在區間安全性控制和防護設備的研制、生產、使用過程中,運用現代技術手段對設備的可靠性和安全性進行科學、高效、全面、按標準的檢測和評估,以取代目前國內主要依靠專家經驗進行的手工測試和實際線路試運行的非完善的方法,是十分迫切和必需的。在我國城市軌道交通領域,這方面的研究尚處于起步階段。本文的研究正是基于這一背景。文中所建測試平臺對城際鐵路同樣適用。

1區間信號系統測試平臺的結構

城軌交通區間信號系統測試評估平臺(以下簡稱平臺)硬件采用分布式結構,如圖1所示。平臺由主控機、數據庫機和仿真機組成[1]。被測系統通過網絡與平臺互聯。網絡通信采用TCP/IP協議。

圖1平臺分布式硬件結構示意圖

平臺軟件系統結構框圖如圖2所示。其中:主控及測試案例自動生成子系統一方面向仿真子系統發送區間狀態的仿真設置命令,另一方面動態監控現場信號狀態等,實現測試案例的動態擴展和連續加載、測試結果的動態判定,并將測試結果存入數據

圖2區間信號測試系統的軟件結構庫。傳輸信道仿真及區間現場仿真子系統為被測系統提供了一個模擬的傳輸仿真及現場環境。數據采集與處理子系統在被測系統與仿真信道之間進行數據處理及轉換。測試用基礎數據生成子系統通過讀取區間拓撲數據文件,生成區間測試用基礎數據。專用數據庫子系統負責存儲各種測試用基礎數據和測試結果。本文重點闡述平臺專用數據庫子系統的研究與實現。

2平臺專用數據庫設計

平臺的數據庫不僅是一般意義上的數據庫應用,它還負責協調各個子系統之間的數據聯系。平臺數據的類型與結構在一定程度上反映了整個平臺的測試水平。基于對平臺數據以及平臺分布式結構的考慮,經過深入的比較,選擇SQLServer作為平臺的數據庫開發工具。數據庫設計一般分為四步:需求分析、概念設計、邏輯設計和物理設計。應用數據庫設計理論,平臺專用數據庫設計的具體步驟如圖3所示。

圖3數據庫的設計過程

2.1需求分析

平臺的數據按其對時效性的不同要求可以分為動態數據和靜態數據兩大類[2]。動態數據是指具有嚴格時效性的數據,并且隨著時間推移而動態刷新;靜態數據則指相對穩定,不隨時間變化的數據。

2.1.1動態數據及其傳輸

平臺動態數據是維持平臺正常運行的基礎,主要包括下列3類數據:

·列車運行仿真命令、故障及干擾仿真命令。由主控機發出,用于控制仿真子系統進行相應仿真活動。

·區間信號設備狀態及動作信息。指仿真機所模擬的實際區間信號設備的狀態(如軌道區段是否有車占用等),主控機采集這些信息用于動態判定及顯示測試過程的實際狀態。

·測試結果信息。平臺的測試結果記錄是一種比較特殊的動態數據,包括經信道傳輸前后的實時電信號(數據)。它們是評價被測系統的重要依據,必須完整、正確地記錄。

動態數據傳輸首先必須滿足實時性要求,當不能及時傳送時,根據數據特性的不同,或丟棄,或重發。例如被測系統發送的數據如不能及時傳送,或數據有誤,則該數據必須丟棄。主控機發給仿真子系統的故障及干擾仿真命令、列車運行仿真命令,在網絡傳輸出現差錯的情況下,為了確保命令被正確執行,必須重發。

2.1.2靜態數據及其復制

生成和校驗正確后的靜態數據,在平臺對被測系統進行測試的過程中不再變化,具有相對的穩定性。同樣需要對靜態數據進行存儲、查詢、校驗和修改等操作。平臺靜態數據可分為以下幾類:

·信號設備數據。記錄發送端、接收端、閉塞分區的排序序列號與設備名稱之間的映射關系,設備的一些屬性特征。例如:閉塞分區的編號、名稱、位置、長度,道岔的編號、名稱、位置、類型等。

·基本數據。包括區間基本特征、鋼軌線路的一次參數、鋼軌線路四端網參數、列車運行線路等重要數據。其中區間基本特征數據包括閉塞制式、軌道電路類型、道碴與枕軌類型、坡度、曲線及長度等。列車運行線路數據包括線路運行方向、經由閉塞分區編號、經由發送端、接收端編號。

·區間現場拓撲數據。包括閉塞分區、發送端、接收端的位置和相互關系。這種描述有兩方面用途,一方面用于現場仿真的動態顯示,另一方面是作為測試用基礎數據生成的原始依據。靜態數據的復制是通過開放式數據庫互連(ODBC)機制實現的。

2.2概念設計

在數據庫設計中,筆者使用實體-聯系(ER)模型作為概念設計的工具,得到概念設計的E-R圖。E-R圖由實體、聯系和屬性3個基本成分組成。測試用基礎數據所處理的基本實體是城市軌道交通區間的信號設備:接收端、發送端、閉塞分區;設備之間的關系也就是最直接的實體間聯系。通過E-R圖,可以十分清楚地描述測試用基礎數據的結構。圖4為列車運行線路數據的E-R圖。

圖4列車運行線路ER圖

2.3邏輯設計

關系數據庫的邏輯設計過程是把概念設計的結果(如E-R圖)轉換成關系模式的過程。為了消除關系模式的存儲異常問題,需要對其進行規范化。

在本子系統數據庫模式的規范化設計過程中,既要考慮減少數據冗余、消除存儲異常情況,也要考慮現場仿真、主控等子系統讀取數據及運算的花費。規范化測試用基礎數據的關系子模式包括:發送端表、接收端表、閉塞分區表、列車運行線路表、區間基本特征表、鋼軌線路一次參數表、鋼軌線路四端網參數表等。

2.4物理設計

物理設計要根據具體的數據庫管理系統(DBMS)和相應的操作系統、計算機硬件所能支持的存儲結構、存取方法以及資源來進行設計。SQLServer提供索引或表鍵機制來幫助SQLServer優化對查詢的響應。在測試平臺上,對結果數據的查詢,是將記錄計數號與測試項目的組合作為索引。這是因為大多數的查詢都要直接或間接地將該兩項作為SQL語句中WHERE子句后的首列。

3平臺專用數據庫接口的實現

平臺采用客戶端/服務器體系,后臺數據庫服務器采用SQLServer,前臺應用程序開發工具采用VisualC++。前臺應用程序對數據庫的訪問是通過ODBC機制實現的。

VisualC++對ODBC提供了兩種支持:一種是API函數[3];另一種是對API函數進行封裝的MFCODBC類,包括CDatabase(數據庫類),CRecordSet(記錄集類)和CRecordView(可視記錄集類)。兩種方式在平臺上分別應用于不同的場合。

·ODBCAPI使客戶應用程序能夠從底層設置和控制數據庫,完成一些高層數據庫技術無法完成的功能。例如檢測數據庫是否連接、數據源配置是否正確等。

·MFCODBC類封裝了多種數據庫訪問功能,使用簡單方便。平臺專用數據庫定義了11個CRecord2Set類的子類,每一個子類對應專用數據庫中的一個表,例如,B-JSSet類對應接收端表,B-BSFQSet類對應閉塞分區表。

4結語

建立在SQLServer上的平臺專用數據庫要兼顧通用數據庫的設計要求和區間測試平臺的特殊性。只有綜合考慮這兩方面的因素,才能使專用數據庫既高效又安全。當然,隨著平臺水平的不斷提高,專用數據庫的功能必將隨之擴展,日趨完善。

參考文獻

1吳芳美.鐵路安全軟件測試評估.北京:中國鐵道出版社,2001.23

2荊劍.基于計算機聯鎖安全軟件測試評估平臺的CLIENT/SERVER數據庫[學位論文].上海:上海鐵道大學電信系,1999:23

篇6

為了解決推廣的“后續問題”，很多網站推出了流量檢測統計服務。尤其是7月21日，全球最大的中文搜索引擎百度也推出了百度統計，百度的加入讓這個市場的競爭更顯激烈。

那么，現有的流量統計系統中，哪一款最適合您的需要?各自有什么優勢和劣勢呢?我們選擇了4款當前比較流行的系統進行了對比測試。

它們分別是：

Google Analytics：Google旗下的流量統計系統，其前身是Urchin，一款商業級的web分析軟件。被收購后，Google對其界面和易用性進行了改良，目前分為免費版和收費版兩個版本，提供不同的功能。

百度統計：百度剛剛的流量統計系統，屬于百度自主研發，目前主要提供給百度推廣的客戶。

太極鏈：國內老牌的友情鏈交換系統，首次引入了“數據倉庫技術”，使站長可以對自己的歷史統計、搜索引擎來訪進行深入的挖掘分析。

CNZZ：有比較好的口碑，目前有注冊用戶100萬，日統計量25億PV。

一、軟件主界面和易用性

企業網站多半其IT技術水平并不高，如果軟件的界面過于復雜，操作過于繁瑣，將大大提高用戶的門檻，讓很多企業主望而卻步。為此，我們將主界面的簡潔程度和易用性的考量放到了最重要的地位。

1、Google Analytics

界面表現：

易用性表現：

訪問速度：較快

Google Analytics是5款軟件中界面最標準的一款，各種統計功能分布較為合理，每個選項都以下拉框的方式涵蓋了大量的內容，點擊打開可以看到需要的內容。整個界面清晰、明了，但是這一系統有其很大的問題——操作過程以及數據的側重點與國內通用的模式不同，界面雖然標準，但上手比較困難，比較適合資深的網站管理者。

Google Analytics：功能結構清晰，但上手比較困難

2、百度統計

界面表現：

易用性表現：

訪問速度：很快

百度一貫以“簡單，可依賴”來要求自己的產品設計體系，百度統計依然秉承了這一原則。整個后臺系統非常簡潔，只簡單的分為“流量分析”、“來源分析”、“轉化分析”和“網站分析”四大模塊。

在易用性方面，可以說，即便是第一次使用流量統計系統的企業主，也可以輕松操作，非常傻瓜。

百度統計：界面簡潔，操作門檻極低

3、太極鏈

界面表現：

易用性表現：

訪問速度：偏慢

與百度統計類似，采用左右欄的展現方式，數據清晰。不過其統計結果的數據展示方式不夠明了，大都采用數字的方式，圖表較少，這為分析帶來了一定的麻煩。而且還有一點，太極鏈統計的訪問速度偏慢。

在易用性上，太極鏈表現出色，和百度統計基本上表現一致。

太極鏈：展示清晰，但不夠人性化，易用性好

4、CNZZ

界面表現：

易用性表現：

訪問速度：較快

CNZZ的界面也是采用的兩欄式，統計結果可以是數字、圖表等展現形式。而且它的易用性、訪問速度都讓人很滿意。

點評：毫無疑問，在系統界面、易用性和訪問速度上，百度統計都是表現最為搶眼的，這得益于百度對產品的一貫原則，而且百度統計的數據輸出都采用直接明了的圖表式。表現比較差的是太極鏈，尤其是它的訪問速度。如果對網站管理技術掌握不夠，不建議使用Google Analytics。而CNZZ是僅此于百度統計，表現較為平均的一款。

二、統計功能

功能也是我們最關注的因素之一，畢竟越翔實的功能，對于企業網站的參考意義就越大。

1、Google Analytics

功能強大：

統計項齊全：

Google Analytics可以說提供了所有網站統計的必要項目，它分為免費版和收費版，免費版有每月綜合瀏覽量的限制。

我們主要針對其免費版來加以評述。除了大家都有的IP、PV、新訪客等等統計數據，她的地域統計比較直觀，直接標注在地圖上。

Google Analytics：功能強大、完善、專業

Google Analytics還包括了市場分析功能，把你網站的流量，點擊量結合起來，算出這些廣告給網站帶來的價值，給出綜合的投資回報分析。各種數據是比較客觀的，網站在加入了統計代碼以后打開速度沒有大的影響。

2、百度統計

功能強大：

統計項齊全：

百度統計的功能也是4款產品中表現出色的，它不僅具有常規的統計功能，更將重點放在了對企業主更實用的推廣效果監控和網站頁面監控上。

比如，百度統計提供了“訪客忠誠度報告”，可以監測訪客訪問頻率、深度、時長;與百度推廣集成，對其整體轉化率和關鍵詞的轉化率都有詳細的統計;更提供了特有的“上下游報告”，能夠幫你找到訪客在網站的訪問習慣，從而有針對性地調整網站建設、推廣策略。

百度統計：針對搜索引擎關鍵詞的詳細分析

3、太極鏈

功能強大：

統計項齊全：

和前兩家的統計參數大同小異，不過整合了Alexa排名的情況，還提供了IP頭統計。不過對網站流量的來路分析和流量分布統計并不是非常出色。統計精確到了20分鐘。值得注意的是，在我們測試過程中，太極鏈還出現了一次系統故障。

太極鏈：每20分鐘可進行一次報告分析

4、CNZZ

功能強大：

統計項齊全：

CNZZ的功能和統計項目和百度統計幾乎一致，所不同的是，它在統計不同時段的流量表現時，不像百度那般傻瓜。而是單獨針對時間設置了相關的統計菜單。

值得一提的是，CNZZ提供了“用戶忠誠度”分析、“升降榜”和“短信報警”這3個特色功能。其中“用戶忠誠度”分析主要是針對流量的“回頭率”進行分析，“升降榜”則是對比不同的時間段的流量情況，“短信報警”是當流量達到某個上限或下限時，短信通知企業主。

點評：在統計項目和功能方面，4款產品中除了太極鏈明顯要弱一些之外，都各有特色，包括Google Analytics對轉化率的分析，CNZZ的短信報警，以及百度統計對關鍵字的詳細分析。考慮到百度統計剛剛才，其后期的功能更新非常值得期待。

當然，總體來講，Google Analytics在這一測試環節中的表現還是略勝一籌，給我們留下了較好的印象。

三、配套服務、使用感受

如果僅僅是個流量統計功能，根本就沒有必要在意它的配套服務，但問題是對于企業網站，流量統計不是目的，目的是通過流量統計來衡量推廣效果，并對當前的推廣策略進行優化。所以這方面的表現我們尤其關注。

1、Google Analytics

使用感受：

Goolge Analytics的幫助中心為用戶提供了使用步驟說明，由于說明比較簡單，雖然對每一個分步也做了說明，但并不是清晰明了，而且也沒有提供demo。根據Google Analytics提供的疑問向導，可以解決操作過程中碰到的問題，不過這個向導有點類似于Windows疑難解答的方式，顯得龐雜、繁瑣。

2、百度統計

使用感受：

百度統計的用戶體驗做得非常出色，整個操作、測試非常流暢，而且關鍵有兩點讓我們頗有好感：其一，提供了詳細的幫助頁面，解釋了每一個菜單、參數的含義;其二，提供了一個初學者入門教程，并提供了PPT格式的傻瓜向導，十分人性化。

在中國，由于有30多萬企業使用百度推廣，所以將百度推廣和百度統計聯合起來共同參考、決策非常有用。這一點算是給百度統計的額外加分。

3、太極鏈

使用感受：

由于速度一般，而且整體表現也偏弱，雖然操作不成問題，但太極鏈整體給人感覺還是偏向于平庸。操作過程中出現過兩次系統故障，證明其穩定性還有待加強。

4、CNZZ

使用感受：

CNZZ無論是易用性、界面表現還是功能，都讓人比較滿意，而且它提供了一些人性化特色功能給人印象深刻，是本次測試中綜合表現比較平均的一款。不過，如果加強一下它的客服幫助系統和demo演示方面的表現就更好了。

評測總結：

綜合表現獎：百度統計

篇7

關鍵詞：非安全級DCS；驗證系統測試；NicSys2000；核電廠；仿真樣機 文獻標識碼：A

中圖分類號：TP273 文章編號：1009-2374（2017）05-0194-03 DOI：10.13535/ki.11-4406/n.2017.05.094

核電廠非安全（NC）DCS驗證系統總體技術方案以實際百萬千瓦壓水堆核電廠全廠DCS系統設計為依托，通過“模擬”核電廠控制系統實際工程實施流程，建立核電廠全范圍DCS系統驗證系統，可實現測試DCS系統性能指標、核島和常規島等重要系統實施單步或關聯運行功能、邏輯預演以及定性分析等功能。本文提出了一種對于上述DCS系統的整體測試方法，通過優化的測試架構和全面的測試內容，在保障測試結果的嚴謹性、科學性和有效性的基礎上，顯著地減小了系統測試的周期，并提升了該項目管理上的高效性和簡潔性。

1 測試框架

系統測試框架包括測試計劃、測試大綱、測試用例和測試程序，如圖1所示。測試計劃描述了測試流程的范圍、實施途徑、進度節點；測試大綱根據測試計劃，以設計輸入文檔、項目相關文檔作為輸入文件，依據相關標準，詳細說明核電廠非安全級DCS驗證系統中各項測試執行時所需的步驟和判斷標準，指導測試工程師進行實際的測試活動。測試用例則是針對測試程序進行步序性的邏輯驗證，并將邏輯驗證結果與期望進行比對，隨時記錄邏輯異常。

2 測試內容

根據不同的測試目的，測試分為功能測試、性能測試、單體測試和設備控制邏輯測試。在普通項目中我們僅做單體測試及設備控制邏輯測試，由于NicSys2000系統是自主研發的DCS，是專為核電站研制的全廠非安全級分布式控制系統產品，是全廠核電運行控制系統專用平臺，故在測試工作中加入功能測試及性能測試，以驗證Nicsys2000系統的各項指標，為今后系統在核電廠可靠、穩定的運行提供保障以及為后續研發積累寶貴資料，以下為對功能測試和性能測試進行重點介紹。

2.1 功能測試

功能測試的目的是測試系統各項功能是否完備、是否符合要求。功能測試主要包括故障診斷測試、模塊熱插拔測試和冗余測試。

2.1.1 故障診斷測試。故障診斷測試包括控制器故障診斷測試、控制器網絡故障診斷測試和模塊故障診斷測試。實際操作如圖2所示，將控制器A拔掉，在操作員站檢查報警日志和設備故障列表，并打開系統狀態圖，找到對應控制站狀態圖，檢查相應控制器的變化。重新插上控制器A，在操作員站檢查報警日志和設備故障列表，檢查狀態圖中控制器A的變化。對控制器B重復以上操作。

2.1.2 模塊熱插拔測試。模塊熱插拔測試包括DI模塊熱插拔測試、DO模塊熱插拔測試、AI模塊熱插拔測試、AO模塊熱插拔測試。目的是測試IO模塊帶電拔出后再插上是否可以恢復正常工作。因為篇幅限制，不對IO模塊的熱插拔測試方法進行詳述。

2.1.3 冗余測試。冗余測試包括控制器冗余測試、電源模塊冗余測試、控制柜電源冗余測試、控制站網絡冗余測試、服務器網絡冗余測試。如圖3所示，選擇一個AI通道和AO通道作為驗證通道，在MULTIPROG中編程，使該AI點的值賦給AO點。在被測現場控制站，用多功能過程校驗儀給該AI通道發送三角波信號，用示波器監測AO通道的輸出信號。拔掉主控制器，檢查AO點輸出波形是否正常，此時另一臺控制器切換到主運行狀態，恢復拔掉的控制器，等待其正常運行后，拔掉另一臺為主的控制器，檢查AO點輸出波形是否正常。

2.2 性能測試

性能測試的目的是驗證系統各項性能指標是否符合要求。性能測試主要包括CPU負荷測試、內存裕量測試、網絡負荷測試、分辨率測試、時間相關性能測試和雪崩測試。

2.2.1 硬件負荷類測試。硬件負荷類測試包含CPU負荷、內存裕量及網絡負荷測試，其測試方法均通過監控器以及設備的運行軟件來讀取設備的CPU、內存、網絡的負荷數據，CPU負荷平均值小于40%為合格。

2.2.2 分辨率測試。分辨率測試包括報警分辨率測試和SOE分辨率測試。報警分辨率測試是通過制造幾個間隔時間分別為小于1s、等于1s、大于1s的報警，在報警日志中查看系統是否能夠分辨。SOE分辨率測試如圖4所示。在SOE（事件順序記錄）模塊的任意通道發送間隔時間分別為小于1ms、等于1ms、大于1ms的信號，在日志中查看系統日志，當間隔小于1ms時，系統不一定能夠分辨，間隔大于或等于1ms時，系統應當能夠分辨，且事件信息不丟失，發生順序排列與實際相符。

2.2.3 時間相關性能測試。時間相關性能測試包括畫面響應時間測試、數據采集顯示時間測試、控制功能響應時間測試和設備啟動響應時間測試。例如在現場控制站，用示波器查看開關量輸入信號和輸出信號波形變化的時間間隔，選擇任意開關量控制回路，在現場控制站將被測開關量控制回路的輸出端子和輸入端子分別連接示波器的兩個通道，在輸入通道加信號，在示波器查看輸入信號和輸出信號變位的時間差，響應時間小于500ms為合格。

2.2.4 雪崩測試。使用測試工裝連接幾個控制站，在工程師站、操作員站及服務器上，查看CPU負荷和網絡負荷。使用測試工裝制造雪崩工況：10s內6000個開關量狀態發生變化，峰值1200個開關量發生變化，60s后峰值每秒300個開關量狀態發生變化，模擬量每秒200個信號發生變化，模擬量和開關量變化峰值疊加。檢查雪崩工況期間的各負荷，控制器CPU負荷不大于50%，網絡負荷不大于20%；操作站、服務器CPU負荷不大于40%，網絡負荷值不大于20%。

2.3 單體測試

單體測試的目的是驗證系統硬件配置的完整性和有效性，驗證系統AI/AO模塊信號的精度是否達標和驗證DI/DO模塊通道是否正常。單體測試包括AI/AO模塊的精度測試和DI/DO模塊的通道測試。驗證系統單體測試與其他項目相同，因篇幅限制，此處不做詳述。

2.4 設備控制邏輯測試

設備控制邏輯測試的目的是驗證DCS系統軟硬件配置、邏輯組態的完整性和正確性。設備控制邏輯測試包括單點報警測試、邏輯顯示及報警測試，設備邏輯和連鎖測試。

3 測試效果

為驗證測試方案的效果，根據實施進度及DCS子系統的代表性，選取KSN系統作為測試對象進行上述測試。KSN系統作為核輔助廠房就地控制屏和控制盤，設有單獨的電子機柜間和輔助控制室。系統結構包含控制器、服務器、時鐘同步、環網等，具有很強的DCS系統代表性，符合驗證測試對象的條件。

3.1 功能測試

測試對全部14塊控制器、124塊IO模塊都進行了故障診斷和熱插拔的測試；對全部14塊控制器進行了冗余測試；對全部38塊電源模塊進行了冗余測試；對7臺功能柜的供電電源進行了冗余測試。功能測試共計76項，其中合格項46項、不合格30項。

測試發現的問題有三類：（1）故障診斷功能沒有實現；（2）LEVEL2軟件沒有趨勢圖功能，控制站和服務器網絡冗余無法測試；（3）8KSN901AR中有2塊DI211模塊熱插拔功能不完善，模塊拔掉后變量無法保持。

3.2 性能測試

在進行的51項性能測試中，合格項49項、不合格2項。測試發現的問題有2類：（1）開關量控制回路響應時間超過要求時間。要求響應時間小于500ms，部分回路在7次實測中有4次超過500ms；（2）雪崩時要求操作員站CPU負荷小于40%，而實測中部分CPU最大負荷為42.93%。

3.3 單體測試

KSN系統的首輪單體測試已完成。共完成124塊IO模塊的測試，測試結果全部合格。

3.4 設備控制邏輯測試

KSN系統的首輪設備控制邏輯測試已完成，共完成506項測試用例的測試，將全部邏輯組態都進行了演算和認證，其測試合格率為87.75%。

4 結語

通過上述方法對基于NicSys2000控制系統的核電廠仿真樣機驗證系統的KSN系統進行測試，從硬件、軟件和組態邏輯，全方面詳細地檢測出了當時系統尚存在的問題，其結果不但有助于工程師精準地消除系統故障和問題，保障系統正常運行，同時各項設備性能指標等測試數據，也為研發人員在今后NicSys2000產品的改進工作中提供了工作方向和數據，其對于完成核電廠全廠非安全級DCS控制系統的開發，在核電領域主控非安全級DCS自主化行程提供了有效的幫助和促進。

參考文獻

[1] 中華人民共和國國家質量監督檢疫總局，中國國家標準化管理委員會.工業過程測量和控制 系統評估中系統特性的評定 第1部分：總則和方法學（GB/T18272.1-2000）[S].北京：中國標準出版社，2000.

[2] 中華人民共和國國家質量監督檢疫總局，中國國家標準化管理委員會.工業過程測量和控制 系統評估中系統特性的評定 第2部分：評估方法學（GB/T 18272.2-2000）[S].北京：中國標準出版社，2000.

[3] 丁士昭.工程項目管理[M].北京：中國建筑工業出版杜，2007.

篇8

【關鍵詞】 外固定支架;步態分析系統;粗隆間骨折

我院自1984年開始應用三針鎖針加壓器外固定治療股骨粗隆間骨折以來取得了豐富的經驗和滿意的療效。自2005年12月～2006年3月，采用三針鎖針力臂式外固定支架治療老年股骨粗隆間骨折20例，并應用自行研制的下肢骨折步態分析系統進行測試，效果滿意。現報道如下:

1 臨床資料

1.1 一般資料

本組20例中，男12例，女8例;年齡50～65歲，平均年齡55±0.8歲，左側11例，右側9例，外傷原因:走路不慎滑倒11例，被車撞傷2例，騎車自行車摔傷7例。傷后就診時間2h～10d。骨折接受力方向和骨折線走行及位置分為:順轉子間型5例，順轉子間粉碎型12例，反轉子間型2例，轉子下型1例。其中穩定性骨折9例，不穩定性骨折11例。

1.2治療方法

入院后對骨折移位較大，位置不滿意，均行外展位30°股骨踝上牽引，牽引重量4～8kg，時間為3～7d。在周圍神經刺激儀神經阻滯麻醉狀態下，經C型臂電視下透視確認骨折復位或基本復位后，患側臀部墊高，以抵消股骨頸的前傾角，便于水平進針，術區常規消毒，鋪無菌巾，于大粗隆下方外側做小切口約0.5cm，止血鉗鈍性分開筋膜、肌肉直達骨膜，應用低速電鉆將直徑3.0或3.5mm的斯氏針在大粗隆下方進針，兩枚針的排列分別在股骨頸上皮質的下緣及下皮質的上緣，亦即股骨頸張力骨小梁及壓力骨小梁上，達股骨頭軟骨帽下5mm（若出現不穩定的內側皮質不齊，則行橇拔后;于此處在第二枚針下方約1.5cm～2.0cm加用一斯氏針固定，針尖以過股骨頸內側緣皮質5mm為宜）第三枚針直徑5mm長130mm的螺紋針于股骨外踝的上方10cm髂脛束的后緣水平進針過對側骨皮質約5.0mm，將上述三枚針尾穿過固定夾螺栓孔內;外應用三針鎖針力臂架固定，鎖緊固定夾，調整架的長短，使針體出現輕度彎曲。針孔無菌包扎，傷肢用屈膝架屈膝，外展30°位擺放。術后常規用抗生素2～3d。術后第2d可行股四頭肌收縮活動及踝關節、趾關節的屈伸活動，以改善局部的血液循環，防止肌肉進一步萎縮。術后7～15d在醫生的指導下，扶雙拐不負重進行功能鍛煉，每兩周應用下肢步態分析系統對傷肢進行步態測試，以掌握骨折愈合及行走步態的穩定性。

2 治療結果

本組20例，無并發癥針道感染發生。無松動現象發生。外固定4～6周后，骨折有明顯的骨痂形成或骨折線模糊，負重時間最早4周，最晚6周，平均住院天數29.8d。20例均得到隨訪，經6個月的隨訪，骨折均愈合。無髖內翻發生。由于治療過程中定期應用步態分析系統進行測試，分析骨折的愈合情況，并督促患者積極的進行正確的功能鍛煉，全部病例下肢關節功能恢復滿意，生活基本能自理。

3 討論

3.1 外固定架的治療特點

應用三針鎖針力臂式外固定支架治療老年股骨粗隆間骨折，具有損傷小，操作簡單，療效好等優點。早期能進行無痛性活動的功能鍛煉，具有動靜結合的復位固定于一身的特點。（1）本療法符合生物力學的原理，選用的針體變形較小與固定器間形成幾何不變體系，且支架主體形成一個牢固的懸梁，加強支撐負重作用，使斷端對位穩定［1、2］;（2）三針鎖針加壓器固定中的螺紋針與人體的親和力強的特點，同機體不起反應;（3）由于針在固定器上能交叉、水平或多方向固定或牽引加壓，使股骨粗隆間及骨干部恢復了拱式內負重系統的平衡狀態，保證骨折斷端相對穩定，使生理應力刺激較集中在骨的斷面上［2、3］，加速愈合。因此，具備了早期下地活動，早期愈合的條件;（4）本療法可進行閉式復位，手術并發癥少，減少內固定所帶來的并發癥，可以避免再手術取內固定所帶來的痛苦;（5）更適宜體弱多病老年患者。老年股骨粗隆部位骨折，常伴有轉子后及股骨矩的損壞而不穩定，獲得牢靠的內固定是困難的。作用于內固定的應力大，易發生釘或板折斷且手術創傷大及骨膜破壞而造成骨折不愈合的機會大，高齡的患者難以耐受，此療法同時配合本院的周圍神經刺激儀神經阻滯麻醉，降低了其它麻醉方式在老年骨折手術中造成的危險，手術的風險性小且固定穩定，是老年骨折病人更易于接受的優點。

3.2 應用步態分析系統測試

目前，我國臨床醫學領域，對骨折治療康復期，缺乏客觀的依據來對其臨床療效進行分析。尤其對于骨折應用外固定治療后的患者，臨床醫師很難準確的確定骨折愈合期與臨近關節功能鍛煉時，肌力訓練的強度及側重點，撤除固定的最佳時間。以往只能通過放射線檢查或憑借醫師的臨床經驗來判斷骨折的愈合情況、傷肢的功能鍛煉是否適當及撤除固定的時間。我院自行研制的步態分析儀是用于傷肢肌力檢測，負重步態無損測試研究的儀器。其具有操作簡單，實用性強。（1）本儀器是用于骨科疾病的治療與康復的負重步態無損測試研究。通過此儀器能夠測試出患者的傷 肢與健肢最大負重、最小負重、時間積分、占空比率、負重頻率、力峰值個數、負重總和等參數，并能給出帶負重曲線圖的測試報告單，通過此儀器能夠測試出患者的患側前足后足負重與健側及與正常人是否存在差別，并且隨著病情的好轉，步態是否隨之接近正常人;（2）本儀器通過傳感器測試患側外固定支架針體間的受力值，來判斷外固定支架的功能替代情況，確定骨折端的受力情況，從而分析出骨折的愈合情況。應用外固定治療的骨折患者初期，由于新生骨組織與外固定針體具有不同的彈性模量，針體的彈性模量遠大于新生骨組織的彈性模量，因而斷面愈合初期主要承受載荷的是鋼針。隨著新生骨組織的加強，骨針承載將逐漸減小，載荷將越來越多的被新生骨組織承載。當重建的骨組織接近正常生理狀態時，載荷將主要由修復后的骨組織所承擔。此時，外固定支架不再有作用。本儀器通過傳感器測試患側外固定支架針體間的受力值，來判斷外固定支架的功能替代情況，確定骨折端的受力情況，從而分析出骨折的愈合情況;（3）通過測試可以提供給臨床醫師一組客觀數據，來解決診斷、治療以及功能鍛煉過程中的量化問題。

總之，應用三針鎖針加壓器外固定治療老年股骨粗隆間骨折對于老年患者損傷小、安全系數高，能使病人最大限度恢復其功能，即使不能離床，也能使病人翻身活動時減輕疼痛，便于護理，提高生活質量，減少老年人長期臥床導致合并癥的發生，降低死亡率。通過應用我院自行研制的步態分析系統進行測試，能準確的測定患者的功能鍛煉情況及患者的骨折愈合情況，從而正確指導患者的功能鍛煉及準確的掌握撤除固定的時間，保證醫療質量，減少患者的經濟負擔，適合基層醫院，易于推廣普及。

參考文獻

［1］孟 和.中國骨折復位固定器療法［M］.北京:北京醫科大學.中國協和醫科大學聯合出版社，1999，158-160.

［2］孟 和，顧志華，顧研伯，等.骨折復位固定器療法針位與穩定性關系的生物力學研究［J］.中國骨傷，2000，13（1）:5-6.

篇9

相比之下，IPTV分發系統在信號起點和觀眾接收機之間包括許多有源設備（路由器、交換器等）。任何這些設備一路上都可能對IP視頻流產生損害，并且在它到達消費者時不留一點出現問題的痕跡。通過比較了三種不同視頻分配結構所要求的許多測試點，顯示IPTV系統可能要求在到觀眾路徑上的許多中間點進行監測。

另一復雜之處是IPTV碼流通常為通過一個網絡單獨發送的單節目傳輸流，而像CATV這樣的其它系統很大程度上依賴多節目傳輸流。這種差異導致需測試的碼流更多，降低比較不同碼流的價值，令測試問題進一步尖銳。

測試類型

物理層測試檢查電纜、光纜或其它傳輸介質及其上面承載的電或光信號。這些測試一般測量如誤碼率、抖動和延遲這樣的參數。物理層測試能夠決定兩個設備之間的某一連接是否有故障或受到干擾，或任一端的設備是否正在導致差錯。

網絡層測試處理正在網絡上的設備之間傳送的以太網數據幀。監測能夠決定幀是否損壞和是否需丟棄，以及業務層是否在物理連接的限度內。測試還能決定多播包是否用IGMP（因特網組管理協議）窺探被交換機正確轉發。

IP層監測檢查IP包（全體和個別碼流）。除了網絡正確處理多播加入和離開請求的能力外，還能驗證端到端尋址。丟包、網絡延遲和包抖動也是重要的監測參數。

視頻和音頻測試可在應用層進行，既可在壓縮域又可在碼流被解碼后。這種類型的測試能夠有助于決定視頻數據是否完整和語法正確，是否遵循音頻響度限制，以及非常重要的MPEG PCR（節目時鐘參考）是否一路正確傳輸。

“在MPEG碼流通過網絡各部分時監測它的PCR時鐘行為，就像一個可被用于執行性能問題取證分析的指紋，“泰克公司高級視頻應用工程師Karl Kuhn表示，“如果PCR平穩和表現良好，那么網絡傳輸MPEG碼流方面做得不錯。如果PCR以周期性的正弦方式變化，那么頭號嫌疑犯在射頻傳輸域。如果PCR經歷隨機、明顯的不連續，那么IP網絡丟包和過度包抖動可能是罪魁禍首。”

由于存在必須得到正確配置和正常操作的大量路由器和交換器，IPTV系統的性能監測和故障排除有難度。這些設備可能導致難以確定位置的敏感的下行故障，原因是它們可能僅僅發生在存在某些業務模式的時候。

“現代服務提供商必須在整個網絡的多個位置監測傳輸系統表現，并監視數據傳輸統計以及視頻和音頻信號質量，”IneoQuest技術公司產品管理總監Joel Daly表示，“這要求一個能夠從多個來源收集大量數據的系統，包括安裝于網絡重要位置的測試探測器、來自正在監測信號的系統操作員的報告，以及來自正碰到問題的用戶的咨詢。”

Daly補充道：“大型多頻道視頻節目分配商當前正在忙于建立能夠監視當前網絡狀態和歷史趨勢的大型數據分析系統，以便在問題出現時更準確地探明它們，并能夠事先預測未來故障可能發生的位置。”

演播室內

篇10

關鍵詞 無線通信；計量方式；自動測試系統；設計與實現

中圖分類號 TP3 文獻標識碼 A 文章編號 1674-6708（2017）188-0048-02

無線電的系統測試工作對社會發展的各個領域都會產生重要的影響，尤其是針對通信系統的應用工作，在應用之前，首先要對整個系統進行測試和檢驗工作，在測試過程中，必須要對通信系統進行優秀的設計以此來提高整個系統測試工作的高效性。為了加深對通信系統測試工作的了解，本文展開了研究，首先分析了無線電自動測試系統的研究背景，在此基礎上，對通信系統測試工作的系統設計進行詳細分析，分別具體分析了通信測試系統的系統需求、系統結構、系統硬件和系統軟件設計方案，希望通過本文研究，可以對通信計量自動測試系統的應用有一定的促進作用。

1 無線電自動測試系統的研究背景

無線通信設備自動測試系統的研究首先是從美國的研究機構發起的，這個自動測試系統主要針對通信領域，尤其是針對軍事的通信領域和航天航空的通信領域以及醫療衛生的通信領域等方面。針對軍事領域的應用主要是應用與軍事陸戰隊之中，在20世紀80年代，針對美國陸戰隊的應用，主要是應用最新便攜式自動測試系統，而且已經實際應用到具體的軍事指揮中。我國的自動測試系統發展較晚，所以導致現階段的自動測試系統發展緩慢，基礎薄弱也是導致自動測試系統不足以支撐起多領域應用的重要原因，針對自動測試系統的應用工作，我國國內目前的可靠性指標是3 000小時，而同等級的國外自動測試系統的可靠性指標已經到達1萬小時，可見我國的發展情況與發達國家的差距還比較大，尤其是針對自動測試化系統的標準來說，只有將軟硬件的配置跟上去，嚴格按照國際標準進行測試與兼容操作，有助于保證整個測試結果更加合理。

2 系統設計方案

2.1 系統需求分析

針對自動測試系統的性能和數據情況研究分析，主要對無線通信設備進行了測試，其中主要的測試項目主要包括對被測設備的工作頻段、信道帶寬等方面的測試和檢測，針對各個要素的檢測工作，本文主要對其所測試的結果進行記錄，并在后期對測試數據進行生成表格的方式，這樣對數據的分析和測試工作才能夠更加高效的進行。在測試到數據之后，并對測試數據進行高效分析，對測試系統的各個方面進行分析，并給出相關的研究數據報告。通過研究和分析，能夠發現整個電子計量自動測試系統要能夠擁有自檢與自動校準功能，從而保證整個測試工作的效率不斷提高。

2.2 系統結構分析

進行系統測試工作，主要采用的是基于PXI總線的虛擬儀器架，在實際的測試工作中，通過對PXI總線和頻譜分析儀等PXI模塊進行整合的基礎上，對整個測試系統中的部分GPIB程控儀器和專用測試設備進行融合，然后將整個測試系統與主控計算機進行連接，這樣可以有效提高整個測試系統工作的效率，保證整個電子計量系統中的總線結構測試系統的工作穩定性。

2.3 系統硬件設計方案

進行電子計量自動測試系統的硬件設計，主要采用的是將主控計算機與程控電源和儀器以及相關的適配器共同組合而成，形成一種通用的系統方案，在整個系統硬件設計中，不僅要包括有基于PXI總線的信號源、頻譜分析儀等儀器，還要配備有GPIB總線的功率計等儀器。同時要保證電子計量測試系統中具有主控計算機、程控電源、信號轉接電路等部件。

2.4 系統軟件設計方案

進行系統測試工作，除了硬件設計，而且要將整個系統的軟件設計工作進行更加詳細的設計，整個系統設計工作主要包括有核心控制、測試方法、儀器驅動、數據管理和人機交互界面模塊等5個部分。其中核心控制模塊主要負責是人機交互頁面。測試方法模塊是對系統的工作頻段進行測試，同時對信道寬帶進行測試工作，在這方面主要是借助虛擬儀器技術實現。儀器驅動模塊主要將整個測試系統中的上層核心控制模塊和測試方法模塊連接在一起，從而能夠將整個設備與應用程序之間進行更加具體靈活的轉變。針對測試系統的設計工作，不僅要對系統軟件進行設計，同時要對相關的數據庫進行設計。在實際的測試工作中，要采用Oracle 8i數據管理軟件作為數據處理庫，在此數據庫中，主要包括有自動測試結果數據表、故障診斷結果數據表、故障診斷專家知識庫標準參數表、故障信息細節表、圖片文字幫助信息表等5個表。這5種測試數據表對整個系統測試的技術編程工作能夠起到數據支撐作用。針對通信自動測試系統的流程設計，要對整個測試設備的性能進行測試，在實際的測試工作中要對整個測試工程進行完善，可以對整個測試工作進行參數調試和數據源分析和管理等工作，同時針對測試系統中的故障進行診斷，能夠有效簡化整個測試工作的流程。

3 結論

總體來說，無線電的系統測試工作對社會發展的各個領域都會產生重要的影響，尤其對通信系統的應用工作會產生更加重要影響，在應用之前，首先要對整個系統進行測試和檢驗工作，在測試過程中，必須要對通信系統進行優秀的設計以此來提高整個系統測試工作的高效性。為了更好的進行通信系統的測試工作，首先要分析無線電自動測試系統的研究背景，并具體分析通信測試系統的系統需求、系統結構、系統硬件和系統軟件設計方案，以此達到提高通信計量自動測試系統的應用效果的作用。

參考文獻

[1]孫宇.無線通信設備自動測試系統的設計[J].數字技術與應用，2016（7）：163.

[2]韓忠輝.基于GPIB的無線通信計量自動測試系統[J].自動化與儀器儀表，2016（6）：262-263.

[3]郭健，李書芳.無線局域網射頻自動測試系統的設計與實現[J].電子測量技術，2014（5）：105-108.