時間：2023-05-30 09:39:27
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇電子測試報告，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
【關鍵詞】軟件測試 測試報告 測試流程
1 引言
軟件測試是軟件開發過程的重要組成部分，是用來確認一個產品的品質或性能是否符合開發之前所提出的要求。對軟件需求分析、設計規格說明和編碼的最終復審，某種程度上測試工作的好壞直接影響了軟件產品的交付和用戶的滿意度。因此，如何做好測試工作，使測試在軟件工程中順利進行，輔助軟件開發工作是我們每個軟件人員應該考慮的問題。
2 軟件測試的目的
（1）確認軟件的質量，確認軟件做了你所期望的事情，確認軟件以正確的方式來做了這個事件。
（2）提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。
（3）軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。軟件測試的第三個目的是保證整個軟件開發過程是高質量的。
3 軟件測試的對象
軟件測試并不等于程序測試。軟件測試應該貫穿整個軟件定義與開發整個期間。因此需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應該是軟件測試的對象。
4 軟件測試流程
軟件測試工作并不是在軟件代碼開發完畢后才開始的，這一點是很多軟件人員的誤區，需要明確一下，它其實是在項目進入軟件實現階段就開始了，項目進入軟件實現階段的時候，就應該啟動軟件測試工作了。
下面根據筆者的測試經驗，詳細闡述一下軟件測試的流程、每個階段需要做的工作及整個測試過程產生的文檔。
4.1 計劃與設計階段
4.1.1 召開測試啟動會議
當項目進入軟件實現階段（編碼），測試經理召集項目經理、開發經理開會確定測試交接時間，開發團隊與測試團隊交接測試內容，對測試目標達成一致，商討測試計劃的可行性，統一項目組的目標和測試的工作重點。進行規模預估并成立測試團隊，完成《測試計劃》和《測試方案》。
4.1.2 設計測試用例
明確了測試需求和測試計劃，在需求分析文檔確立基線以后，測試組需要針對測試需求編寫全部測試用例，在實際的測試中，測試用例將是唯一實施標準。
4.2 實施測試階段
4.2.1 實施測試用例
實施測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。當測試用例全部編寫完成后，測試工程師根據測試計劃中分配給自己的測試任務，實施相應的測試用例，并記錄測試結果。
4.2.2 填寫測試記錄
測試人員在進行具體的測試工作時，需要將測試內容填寫在測試記錄表中，直到所有的測試執行工作結束。
4.2.3 提交BUG清單
在具體的測試過程中，測試人員發現BUG后，需要將BUG記錄在清單里，并及時提交給測試經理。
4.2.4 提交測試報告
在約定的測試周期完成之后，測試工程師需要總結此測試的結果，編寫測試報告。測試工程師根據此輪測試的結果，編寫測試報告，主要應包含以下內容：
（1）測試報告的版本。
（2）測試的人員和時間。
（3）測試所覆蓋的缺陷――測試組在這輪測試中所有處理的缺陷， 不僅要寫出覆蓋缺陷的總數，還要寫明這些缺陷的去向。
（4）上一版本活動缺陷的數量。
（5）經過此輪測試，所有活動缺陷的數量及其狀態分類。
（6）測試評估――寫明在這一版本中，哪些功能被實現了，哪些還沒有實現，這里只需寫明和上一版本不同之處即可。
（7）急待解決的問題――寫明當前項目組中面臨的最優先的問題，可以重復提出。
在每輪測試結束之后應盡快將符合標準的測試報告發給測試經理。
4.3 總結階段
測試工作結束或即將結束時，測試組就要開始著手準備進行總結的工作。
4.3.1 編寫測試總結報告
在測試結束之后，測試經理編寫測試報告，對測試進行總結，并且提交給項目經理，為產品的后續工作提供重要的信息支持。
測試經理根據測試的結果及測試工程師提交的測試報告編寫測試總結報告，測試總結報告必須包含以下重要內容：
（1）測試資源概述―多少人、多長時間。
（2）測試結果摘要―分別描述各個測試需求的測試結果，產品實 現了哪些功能點，哪些還沒有實現。
（3）缺陷分析―按照缺陷的屬性分類進行分析。
（4）測試需求覆蓋率―原先列舉的測試需求的測試覆蓋率，可能 一部分測試需求因為資源和優先級的因素沒有進行測試，那么 在這里要進行說明。
（5）測試評估―從總體對項目質量進行評估。
（6）測試組建議―從測試組的角度為項目組提出工作建議。
4.3.2 測試驗收
測試驗收工作是在以上工作全部結束后，測試經理對測試的過程、效果進行驗收，簽發測試驗收報告，宣布測試結束。由測試經理進行測試驗收，驗收內容包括：
（1）測試效果驗收―測試是否達到預期目的。
（2）測試文檔驗收―測試過程文檔是否齊全，符合標準。
（3）測試評估―從總體對測試的質量進行評估。
（4）測試建議―對本次測試工作指出不足，需要在以后工作中改 進的地方。
（5）宣布測試結束―測試組成員簽字宣布本次測試結束。
4.3.3 測試歸檔
測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸檔，主要包括測試計劃、測試用例、測試報告、驗收報告等。這些文檔的編寫保障了測試的順利進行，同時作為整個測試項目的痕跡，被保留下來，供查閱。
參考文獻
[1]佟偉光.軟件測試[M].北京：人民郵電出版，2008.
[2]Rex Black.測試流程管理[M].北京：北京大學出版社，2001.
[3]Robert V.Binder著，華慶一等譯.面向對象系統的測試[M].北京：人民郵電出版社，2001.
[4]Mark Fewster， Dorothy Graham著，舒智勇等譯.軟件測試自動化技術與實例詳解[M].北京：電子工業出版社，2000.
[5]Karl E.Wiegers著，陸麗娜，王忠民，王志敏譯.軟件需求[M].北京：機械工業出版社，2000.
關鍵詞 智能變電站；二次設備；自動測試
中圖分類號 TM77 文獻標識碼 A 文章編號 1673-9671-（2012）111-0183-01
1 自動測試系統的原理與方案
智能變電站智能電氣設備通信采用IEC61850標準。按照該標準，站內網絡分為三層：過程層、間隔層和站控層。過程層采用SV報文傳輸交流采樣數據，采用GOOSE報文傳輸遙信和控制信息；在站控層則采用MMS協議傳輸信息。IEC61850支持智能電子設備的互聯和互操作。因此，以IEC61850標準為基礎，可以實現實現向二次設備輸入故障信息并觀測其相應的動作情況。根據IEC61850標準，IED需要對裝置進行建模，將功能模塊和各類數據信息寫入ICD模型文件。ICD文件包含了裝置的功能描述和通信接口描述，詳細描述了裝置的輸入輸出數據特征。自動檢測系統借助ICD文件可以讀取裝置內部參數。通過讀取保護定值，自動設定測試用列模擬不同故障情況，產生相應的SV和GOOSE報文發送至二次設備，結合保護動作接點和動作報文自動評估測試結果，測試完畢后，自動形成用戶格式的測試報告。
自動測試系統以PC機作為硬件平臺，通過交換機與數字式繼電保護測試儀和保護裝置進行通信。通過網絡通信，自動測試系統讀取保護裝置定值參數，自動生成測試方案，驅動數字式保護測試儀輸出故障電壓電流，然后監視保護裝置動作情況并給予相應的評價，并生成測試報告，實現保護裝置的自動測試。
上位機采用PC機，實現測試系統的建立、測試方案編制和加載、測試任務下裝、測試過程監視、測試結果評價和生成報告等。測試系統通過與被測裝置的通信讀取ICD文件，獲得被測裝置的信息模型，從而完成自動讀取保護裝置的定值、自動投退保護壓板、自動讀取動作報文。根據被測裝置的信息編制自動測試方案或加載已經編制完成的測試方案，并設定需要監視的信號和評價標準。
數字式測試儀是自動測試任務的執行單元。數字式測試儀通過與上位機的通信，接收測試任務，根據任務完成故障模擬，通過SV報文和GOOSE報文將信息輸出至被測裝置。同時測試儀通過接收被測裝置發出的GOOSE報文信息判斷被測裝置的動作情況。
2 系統軟件架構
自動測試系統軟件采用Visual C++6.0進行開發。程序采用模塊化設計，各個測試功能模塊被設計為獨立組件可以單獨加載和卸載。組件功能明確，相互獨立，便于維護和使用。測試過程中根據需要動態加載和卸載所需的組件，方便實現任意類型的保護裝置測試。同時，允許用戶根據規程編制測試模板，用戶可以根據需要靈活編寫，實現了測試過程的自動化和標準化。
測試系統主要由測試計劃制定模塊、測試計劃監控模塊、試驗報告處理模塊以及通訊規約解析模塊組成。應用自動測試軟件平臺，按照檢驗規程或作業指導書、保護說明書、設計圖紙，按照檢驗項目和程序編寫每個項目的測試模板；基于測試模板，組織測試流程，定義測試方法，計算測試參數，自動實現測試過程。測試模塊包括軟件功能組件的調用命令、測試數據與定值數據進行鏈接的公式及數學表達式、程序運行控制參數、試驗結果數據的鏈接參數等，還包括測試過程中的操作提示、安全注意事項等內容。一個測試模塊可以完成一種保護功能的測試，全部測試模塊組成一套完整的測試模板，就可以完成整套保護裝置的測試任務。
系統在應用結構上劃分為三個層次，分別為硬件接口層、測試接口層、測試層。
2.1 硬件接口層
負責與繼電保護測試儀硬件進行通訊，控制繼電保護測試儀進行電壓、電流模擬量的輸出和開關量翻轉反饋的信息；從測試儀開入量翻轉獲取保護裝置的動作時間。硬件接口層開放電壓、電流發生數據接口和硬件通訊接口。
2.2 測試接口層
在硬件接口層進行一次封裝，派生出保護的測試功能算法，例如距離定值校驗、過流保護試驗等。此層根據保護測試功能的需要，計算出測試儀需要輸出的電壓、電流值，通過硬件接口層接口與測試儀進行通訊。
2.3 測試層
測試層是測試系統在測試標準化、自動測試方面開發的測試平臺軟件，它通過數據庫來管理設備、裝置測試方案、測試報告等。測試層包括自動測試平臺和模板開發平臺等。
自動測試平臺應用數據庫和模塊化結構技術，采用測試模板方式定制測試程序。整個測試過程將全部自動完成，實現測試過程的自動化。
模板開發平臺是針對具體型號保護裝置開發專用繼電保護測試程序的平臺。依照繼電保護檢驗規程，并結合保護裝置的說明書、設備圖紙，生成保護裝置的測試模板（測試方案）和報告模板（標準試驗報告格式）。
3 自動測試系統的特點和應用
自動測試系統具有以下特點：
1）測試平臺軟件的模板文件中，測試參數與保護定值相關聯。通過讀取保護定值，使用數學公式和邏輯運算式將保護定值轉化為測試參數。試驗時打開模板文件，通過MMS接口與保護裝置建立通訊鏈接讀取當前運行定值后，即可開始試驗，不需要人工對試驗參數進行計算和設置，大大簡化了測試過程。
2）系統通過設置評估判據，可以對測試結果自動進行評估。評估的判據包含：跳閘、重合、后加速是否動作，動作誤差是否滿足要求，動作時間是否在允許范圍內以及動作邏輯是否正確。設置了評估判據后，測試結束后，程序將自動給出“合格”或“不合格”的結論。
自動測試系統可應用于智能變電站間隔層二次設備的檢測。不同類型、不同型號的裝置對應的測試項目、測試方法、測試參數各不相同，通過模板開發平臺為不同的裝置開發測試模板，可以方便地實現各種類型和型號的二次裝置的自動測試。
4 結束語
智能變電站二次設備的調試和校驗直接影響著二次設備運行的可靠性和智能變電站的運行維護水平。智能變電站二次設備自動測試系統能夠自動完成二次設備的大部分測試項目，極大提高了設備的測試效率；通過測試模板標準化定制，確保測試過程規范、全面，提升了設備測試質量。實現智能變電站二次設備自動測試能有效提高二次設備的檢修水平，對智能變電站二次設備的運行維護具有積極的意義。
參考文獻
摘 要:隨著汽車電子市場的快速發展，汽車控制器的電子控制單元(ECU)已越來越多，對ECU的功能測試也變得日趨復雜。為解決車載ECU功能測試，研究了基于控制器局域網絡(CAN)的ECU自動測試方法。以NI公司的軟硬件為開發平臺、CAN總線為通信平臺搭建測試系統與被測ECU形成閉環結構。通過CAN總線傳輸測試信息，可實現對同型號ECU的批量測試。此系統采用了新的測試方法來降低測試誤差，并支持ECU的流水線測試，大大降低了測試的復雜度，減少了工作量。同時，在完善仿真信號產生模塊和測試模塊用例庫后，也能適用于其他類型ECU的功能測試。
關鍵詞:
控制器局域網絡；電子控制單元；批量測試；汽車電子；車載網絡
中圖分類號: TP206.1 文獻標志碼:A
Abstract: With the rapid development of automotive electronic market, more and more Electronic Control Units (ECU) for vehicle controller appear and the functional test also becomes more complex. In order to solve the problem of ECU functional test, the ECUs automatic test method based on Controller Area Network (CAN) was studied. The system included the software and hardware platform of National Instrument (NI) and communication platform of CAN bus, by which the system and ECU formed a closed-loop structure. To transmit the test message through CAN bus, the system could achieve batch test of ECUs with the same type. By using the new test method, the system can reduce the test errors, and support assembly line test of ECU, which greatly reduces the complexity of ECU functional test and test work. At the same time, the system can also apply to other types of ECU functional test by improving the generation module of simulated signal and use case library.
Key words: Controller Area Network (CAN); Electric Control Unit (ECU); batch test; vehicle electronic; vehicle network
0 引言
隨著汽車電子的不斷發展，汽車已進入電子控制時代，其標志為電子控制單元(Electric Control Unit, ECU)的廣泛應用。現如今，車輛上電控單元數量不斷增加，功能越發復雜，多個處理器之間相互連接、協調工作并共享信息構成了汽車車載互聯通信網絡。其中控制器局域網絡(Controller Area Network, CAN)是汽車中應用較多的現場總線。其良好的實時性、可靠性和經濟性能很好地滿足汽車ECU之間數據通信的需要，已成為最有發展前景的現場總線之一［1-2］。因此，帶CAN總線功能的ECU測試也將變得更加復雜。ECU功能測試屬應用層功能測試范疇，是為了檢測ECU是否符合給定的協議規范，能否進行正常的控制工作。這種測試在系統級開發中占據了很大的比重，成為應用層測試中最為關鍵的部分［3］。
在傳統的ECU功能測試中，一種方式是利用測試面板產生ECU各種信號后連接到ECU各輸入引腳，觸發它的各驅動模塊進行控制工作，有專門的線路負責數據交換，但這樣的測試系統隨著傳感器數量的增多，連線非常困難，且需要高速的數據采集和信號調理設備，使整體成本增加［4-5］；另一種則改進了信號的產生方式，即通過虛擬儀器模擬ECU的控制信號來代替傳統的觸發信號，采用人工對控制效果進行直接的觀察和記錄。這些測試方法都加大了測試過程中的測試誤差、復雜度和測試工作量，且無法進行自動測試和結果的自動生成，也不能同時對多個ECU進行測試，給ECU廠商進行批量生產時帶來很大的不便。
由此，引發了對新的測試方法的思考和探索。基于CAN總線的ECU功能測試方法以CAN總線的傳輸作為關鍵技術，采用閉環測試方法對同型號的ECU進行自動和批量測試。
1 基于CAN總線的ECU功能測試介紹
車載控制系統主要任務就是要解決車身電器設備的功能性問題，所以，首先應關注ECU是否能實現功能上的控制，即測試其是否滿足控制協議的要求。ECU在控制功能上包括了通信服務功能、傳送數據功能、診斷信息及標定信息功能、設備監控和網絡管理功能等，具體的要求規范則由各ECU生產廠商自行制定。
目前應用層協議制定分為以測試為重心的模式和以設計為重心的模式。不論哪種模式，控制器開發過程中，都需要通過測試來驗證功能的正確性，確定ECU工作正常并不干擾總線正常通信［6］。
由圖1的控制器開發“V”模式圖可見，控制器開發過程包括多個環節，其中的應用層功能測試是其重要組成部分，它包括ECU功能測試、網絡管理功能測試、故障診斷測試等，是進行實車測試前的重要環節。在引入CAN總線后，將大大降低ECU功能測試的復雜度和測試工作量，是CAN總線測試的重要組成部分［7］。
在基于CAN總線的ECU測試系統中，通信網絡是進行數據傳輸，實現各模塊協調工作的橋梁［8］。利用LabVIEW［5,7,11］虛擬儀器產生仿真信號代替數據采集卡采集的真實信號，并在此基礎上引入CAN總線作為測試的關鍵技術，充分發揮CAN總線在傳輸上的高可靠性和實時性等優點。通過總線對仿真信號的測試報文進行有效傳輸，如表1所示。
表1中：Message表示報文名稱；ID表示報文仲裁場；DLC表示報文長度；Data表示報文數據。
將報文與同型號ECU進行連接，形成閉環測試結構，模擬實車中ECU的各種傳感器信號來驅動其進行控制工作（于3.2節詳細描述），將仿真報文數據和CAN總線上反饋回來的ECU控制報文數據進行解析，提取出Data的值，并自動進行多次對比和測試后，在人機界面上對測試結果和各種信號量進行直觀顯示，并利用測試結果自動生成測試報告，優化和改進了傳統的測試方法。
2 設計方案
此方法采用仿真信號序列代替采集卡采集的真實信號，利用CAN總線的特點對數據進行傳輸，并將整個測試構建成閉環結構，大大降低測試的復雜性。
2.1 方法總體框架
由CAN2.0協議可知，CAN報文的基本要素是報文ID、周期和信號與消息的映射關系。因此對ECU的協議功能測試，主要任務就是測試ID、消息周期、確定信號與消息的映射關系是否滿足要求，并測試在循環執行多次之后，ECU是否具備在控制功能上的穩定性［8］。
選用以LabVIEW為軟件平臺實現ECU的功能測試。測試系統整體框架包括三部分：上位機仿真和測試、CAN網絡和底層待測ECU模塊。如圖2所示。
工業計算機仿真給定ECU的各種信號量，驅動ECU進行控制工作。由于各ECU之間是相互獨立的，“測試與結果顯示模塊”采集不同ECU廣播的控制信息，并通過ID對它們進行識別。對采集到的控制信息進行分析、對比原始輸入來判定各個ECU在功能控制中是否滿足協議要求。
具體測試方法如下：
首先，通過上位機LabVIEW模擬仿真信號（如：轉向燈信號、溫度信號等）,通過NI 6259板卡，與待測ECU各引腳進行對接；
然后，發送仿真信號，驅動ECU進行控制工作，并發送出相應的CAN控制信息；
再次，通過NI 8473s板卡與上位機LabVIEW進行對接，接收采集到的CAN報文，并通過LabVIEW實現報文的解析、處理和ECU控制效果的同步顯示；
最后，把原始仿真數據和處理后的數據進行對比，驗證ECU在功能控制上是否滿足預期效果，并對以上測試步驟循環多次，得出測試結論，生成測試文檔。
在此，根據測試大綱要求，選用一個由實驗室和整車廠聯合開發的ECU作為應用實例，仿真信號由模擬信號和開關量信號組成，主要分為：轉向燈信號、報警信號、狀態信號、門信號、溫度信號和壓力信號控制信號。具體的控制量與變化范圍因測試ECU功能要求進行定制化處理。測試ECU仿真控制信號如表2所示。
2.2 軟件設計流程
上位機軟件整體分為7部分：虛擬儀器配置、模擬信號仿真、同步信號顯示、測試結果顯示、系統數據判斷、數據處理、測試報告生成。模塊示意圖如圖3所示。
1）虛擬儀器配置。對測試時使用的板卡進行初始化配置，設定參數和使用通道。
2）模擬信號仿真。產生ECU仿真信號（如轉向燈信號，水溫信號等）。
3）同步信號顯示。將采集到的CAN報文，進行處理之后，在人機界面上進行控件顯示，方便測試者進行直接觀察和分析。
4）測試結果顯示。在人機界面上進行測試結果的顯示，以表格和BOOL數組的形式顯示出每個信號在多次測試之后的通過情況。
5）系統數據判斷。將處理后的CAN報文數據與預先保存的仿真信號數據進行對比，得出測試結果。
6）數據處理。處理NI 8473s板卡采集到的CAN報文，提取數據信息。
7）測試報告生成。在人機界面上顯示測試結果后，將測試結果以網頁（.html）格式的文檔進行保存，便于后期的分析和處理。
軟件設計流程如圖4所示。
3 系統分析
由圖2測試方法總體框架圖可知，此系統主要包含三部分：上位機仿真和測試、CAN網絡和底層待測ECU模塊。其中上位機仿真和測試模塊又分為仿真信號產生模塊和測試與結果顯示模塊兩部分。
3.1 仿真信號產生模塊
使用NI 6259板卡和上位機LabVIEW構建仿真信號產生模塊。此板卡可支持48路數字信號輸出和4路模擬信號輸出。在調用接口函數模塊后，可產生需要的仿真信號，在板卡對應引腳輸出對應電壓信號。
由表2的ECU控制信號表可知，此待測ECU具有兩種不同類型的信號：模擬信號和開關量信號。所以需要在LabVIEW中使用DAQmx各模塊仿真出ECU需要的模擬信號和開關量信號。
1）產生模擬仿真信號［10］。需要把模擬信號轉化為ECU能識別的電壓信號，一般范圍在5V以內。
如：仿真發動機冷卻水溫度信號，水溫與電壓之間的關系如圖5所示。
通過最小二乘法線性擬合得出公式：
y=－4×10－10x5+7×10－8x4－3×10－6x3+0.0002x2－0.0642x+4.2044
其中：y為輸出電壓值；x為冷卻水溫度值。
如：進氣歧管壓力信號，壓力與電壓之間的關系式：
V=V參（0.0023P-0.015）
其中：P為上位機模擬的壓力值；V參為參考電壓5V。關系如圖6如示。
由圖5~6可知模擬信號與電壓值之間的轉換特性，由上位機進行轉換后通過板卡進行輸出，傳遞對應電壓值到待測ECU,驅動其進行控制工作。
2）產生開關量仿真信號。
在LabVIEW中定義各種開關量信號，通過板卡產生高/低電平。一般情況下，ECU檢測到高邊信號（ECU有效電平分兩種：H、L，即高電平有效或低電平有效）后進行控制工作（一般情況下，ECU的高電平判斷電壓在2.5V~5V），控制信號的開啟或關閉，并同步使用CAN模塊廣播CAN報文。
如：DriverDoorStatus（左前門狀態）,根據ECU手冊可知，其為BOOL量，所以在前面板中放置一個BOOL型控件。在對信號進行操作處理后調用NI6259板卡的接口函數并配置通道信息，與此板卡進行通信，產生所需仿真信號（此功能是否正常可通過示波器進行驗證）。
3.2 待測ECU模塊
車載ECU控制功能工作原理：ECU外接12V工作電壓，在人為進行操作或發生狀態變化（如開啟轉向燈、水溫變化）時電路接通，然后產生電壓值傳遞到ECU的模擬輸入引腳，如圖7所示。
此系統使用板卡產生的各種電壓信號代替左側虛線部分圖中未見虛線，請補充或說明。，ECU檢測到信號后進行控制工作。
3.3 測試與結果顯示模塊
上位機LabVIEW調用NI 8473s板卡接口函數采集CAN報文［12］。根據ECU控制協議，對CAN報文進行解析、分析、處理，提取出周期、ID、DATA等控制信息。然后對比原始數據（3.1節部分），進行多次測試后，如果每次測試都全部通過，則判斷為Pass，否則為False，并在前面板中進行顯示。
其中：原始數據包括報文周期、ID和控制信號數據等；報文周期和ID由ECU控制協議決定；控制信號數據由仿真控制信號模塊在產生仿真信號時提供。
4 測試實現
測試ECU在控制功能上是否滿足給定的協議和規范，并測試在循環測試多次之后，ECU控制功能是否具有較好的穩定性。測試系統人機界面如圖8所示。
“仿真信號控制部分”產生表1的ECU控制信號。“ECU控制顯示部分”是對接收到的CAN報文進行解析、處理之后用控件進行形象的顯示，并與“仿真信號控制部分”進行對比。結果顯示，在循環測試100次之后，信號量“左前門狀態”和“進氣歧管壓力信號”控制出錯，在BOOL數組和測試表格中都有明確顯示。“ECU控制顯示部分”顯示出“左前門狀態”燈不亮以及進氣歧管壓力信號數據不一致，這些也同樣說明了信號控制的錯誤。在生成的測試報告(.html格式)中也有明確顯示，如圖9所示。
從測試過程中得知，各個ECU的觸發電平有可能不一樣，大致在5V~12V。NI 6259板卡的工作電壓需小于10V，所以在需要觸發電平高于10V的ECU上進行測試時，則需要在板卡的輸出端加入一個增壓電路。
同時，為了保證測試的正確性，在使用示波器確認仿真部分的輸出電壓無誤后，采用車載網絡測試專用工具CANoe對ECU控制報文進行監測，觀察結果如圖10如示。
由圖8和圖10可知，使用CANoe監測的總線報文與測試系統監測到的報文一致，驗證了本文所設計測試方法的可行性和準確性。在對比分析圖8和圖10中的監測數據，驗證了數據一致性和通信協議的可行性。
根據不同ECU的控制協議，制定不同的仿真信號產生模塊和測試模塊，并在使用過程中，不斷完善ECU的測試用例庫，在完善后進行不同ECU功能測試時，進行規格選擇后，即可實現對不同ECU的功能測試。
5 結語
本文介紹了ECU功能測試的現狀，優化和改進了傳統測試方法。此方法以仿真信號代替采集的真實信號來驅動ECU進行控制工作，并引入閉環結構和CAN總線，使測試過程更加簡單和智能化。所測結果準確可靠，能運用于ECU生產線，提高ECU批量測試的工作效率，為整車廠進行ECU測試帶來了方便。在完善仿真信號模塊和測試模塊用例庫后可擴展到對不同型號ECU的功能測試。同時，此方法的思想，還可以應用于車載網絡的測試、故障診斷等方面，具有較好的理論價值和實際意義。
參考文獻:
[1]
夏巍，嚴輝，丁剛.CAN網絡的實時性與可靠性的研究［J］.安徽建筑工業學院學報：自然科學版,2007,15(1):65-68.
[2]
KONG FENG, ZHANG LIYAN, ZENG JIE, et al. Automatic measurement and control system for vehicle ECU based on CAN bus ［C］// Proceedings of the IEEE International Conference on Automation and Logistics. Washington, DC: IEEE Computer Society, 2007: 964-968.
[3]
王立萍.CAN網絡在汽車控制方法的應用［J］.工業儀表與自動化裝置,2009(5):77-79.
[4]
WU WEI-BIN, HONG T S, LUO CAI-RU, et al. Hardware-in-loop of alternative fuel engine ECU ［C］// Proceedings of the Second International Conference on Computer Modeling and Simulation. Washington, DC: IEEE Computer Society, 2010: 291-294.
[5]
陳彥豐，朱君.基于PXI的汽車測試方案［J］.汽車制造與裝備,2005(3):44-46.
[6]
程躍,康勁松,徐國卿.一種車用CAN總線網絡測試系統的研究［J］.電子應用,2008,27(1):83-86.
[7]
梁銳.NI軟硬件平臺在汽車ECU開發和測試中的應用［J］.世界電子元器件,2007(12):61-63.
[8]
WEI WEN-XIONG, GUO JIANG-WEI, LIU SHENG-LONG, et al. Design of CAN communication network in automobile ECU testing system ［C］// Proceedings of the Second Pacific-Asia Conference on Circuits, Communications and System. Washington, DC: IEEE Computer Society, 2010: 1-3.
[9]
CAN Specification 2.0,Part A ［EB/OL］. ［2011-02-15］. can-cia.de/fileadmin/cia/specifications/CAN20A.pdf.
[10]
曹更彥.汽車燃氣發動機電控系統實時仿真技術研究［D］.重慶:重慶郵電大學,2009.
[11]
阮奇楨.我和LabVIEW［M］.北京:北京航空航天大學出版社,2009.
[12]
Society of Automotive Engineers. SAE J1939 ［EB/OL］. ［2011-03-03］. 省略/PDFs/manual/drehgeber/M36X8/M3658_J1939.pdf.
[13]
胡思德.汽車車載網絡（VAN/CAN/LIN）技術詳解［M］.北京：機械工業出版社，2006.
收稿日期:2011-06-16;修回日期:2011-08-21。
基金項目:
國家“核高基”重大專項（2009ZX01038-002-002-2）；重慶高校優秀成果轉化項目(KJZH08210)。
關鍵詞：自動化測試；自動化測試管理平臺
中圖分類號：TN98 文獻標識碼：A文章編號：1009-3044(2011)28-7003-05
1 概述
目前中國大部分電信運營商都是以省為單位建設業務支撐系統（以下簡稱BSS系統），BSS系統包括客戶關系管理子系統（簡稱CRM系統），計費賬務子系統以及與其它系統的各種接口。省級運營商市場部門以及下屬分公司市場部門為了市場的需要會不斷提出各種業務需求，這就需要不斷在BSS系統進行修改、增加功能，而BSS系統的支撐既要保障相關的功能修改或增加都必須是安全可靠，又要保障支撐的速度能跟上市場快速發展的需要。但由于軟件開發往往采取模塊化設計和增量集成的方式，測試版本的和系統上線時間非常有限，大量的變更問題需要驗證，還需要進行大量回歸測試，這些工作都存在大量的重復性勞動，容易讓測試人產生疲憊感，要保證質量難度很大，有必要引入和運用自動化測試方法，將自動化測試和人工測試相結合，讓測試人員更好的關注新功能或者改造的功能，做更有意義的測試，降低重復測試投入的成本，提前發現問題，保障系統穩定，提高用戶感知。所以本文結合運營商的實際情況和自動化測試在業務支撐系統不斷更新過程中的運用，對功能自動化測試在電信運營支撐系統中的引入和具體實施進行闡述。
2 電信行業自動化測試需求
作為運營商的核心生產系統之一，BSS系統的穩定性運行非常關鍵，其每次發生的重大故障都會給運營商帶來嚴重的經濟損失。而BSS系統的穩定運行，與應用開發/集成商提供的應用軟件本身的穩定性密切相關。
BSS系統穩可以分為3個方面：系統功能穩定，不要動輒操作失敗；系統運行效率好，實時性高；系統運行平穩，不要動輒重啟服務器解決嚴重性能故障問題。而要做到這三方面，不對應用軟件進行充分的測試，是無法保證的。
在BSS的實際建設和維護過程中，關于應用軟件導致的系統不穩定（主機、存儲等設備，數據庫、中間件等系統軟件導致的不穩定，本文不作討論），可以大致歸結為以下幾種：
1）運營商的業務需求繁雜多變，開發周期短，難以進行充分的測試即被迫匆匆上線。每次系統升級前除了進行需求確認測試外，還應進行全量回歸測試，以保障變更不會影響到其他功能，這在管理上是很難實現的！
2）新上線系統的BUG過多，功能不穩定。某個新系統上線后，才發現應用軟件的BUG很多，營業員時不時的操作失敗，而又不是每次都操作失敗，讓人難以琢磨該系統的“性格”。
3）新上線業務功能導致原有正常業務功能出錯。這可以說是BSS系統維護中最常發生的不穩定問題，實際上就是新功能開發時，只對新功能進行了測試，而沒有對原有功能的影響進行大量的測試，導致上線前沒有發現問題，而倉促上線所致。
4）系統BUG修復后，因回歸測試不全面，在上線時會產生新的BUG，得不償失。
5）新上線業務越來越多，系統越來越慢，直至系統后臺死機不處理。這屬于典型的性能、壓力的測試和分析不夠，并進而對系統支撐業務能力估算不足所致
這5個問題，從另一個角度來看，可以理解為解決當前BSS應用軟件測試問題的三個步驟。
首先必須加強上線前開發/集成商的軟件測試，建立完整的測試流程和測試環境。
在此基礎上，對每個新上線的業務功能，除了執行新功能本身的測試外，還通過建立豐富的測試用例庫來確保執行嚴格的功能回歸測試，才能確保新上線業務沒有對原有正常業務功能產生不良影響;
同時，引入適當的測試工具軟件。一方面，即使針對正在研發中的軟件，由于在開發過程中不斷引入的變更（發現錯誤進行的變更，業務需求變化引起的變更等），對于已經測試通過的功能，也需要在每次修改代碼后進行回歸測試，只有這樣才能保證即使在代碼不斷修改的情況下，軟件時相應的功能測試仍然是通過的。而這種回歸測試的工作量非常之巨，以至于如果完全人工來做，是不可能實際做到的，自動化測試可以解決回歸測試、重復測試的問題。這樣才能解決以上問題中1、2、3和4；
最后，有了這些測試流程、測試環境、測試用例庫，才可以進行嚴格的性能測試和分析，為新業務上線對系統荷載造成的影響進行科學客觀的分析，從而準確地把握系統實際運行荷載的變化趨勢，并進而盡早發現系統支撐能力的“臨界點”。
因此，電信行業的業務運營支撐系統有必要啟用自動化測試。
3 自動化測試的好處
自動化測試長久以來，一直是軟件測試領域的熱點，而今從事或者具有自動化測試技能的工程師更是就業市場非常需要的人才。這是因為自動化測試可以帶來很多好處。
將精力投入更有意義的測試。自動化測試的引入會減輕重復的工作，使得測試人員有更多的時間去分析測試需求、設計詳細的測試計劃、測試用例、構建更復雜的測試。可以說這是自動化測試帶給我們的最大好處之一。
回歸測試，降低測試成本。這可能是自動化測試最主要的任務，特別是在程序修改比較頻繁時，效果是非常明顯的。由于回歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動運行，可以極大提高測試效率，縮短回歸測試時間。
充分利用資源。可以在無人時定時執行自動化測試腳本，到時候直接看執行結果即可。人工測試和自動化測試相結合使用，可以在白天上班時間進行新功能的手工測試，原有功能的自動化測試可以在晚上或者周末執行，第二天就可以看到執行的結果。即避免了開發和測試之間的等待，又充分利用時間資源，提高測試效率。
測試具有一致性和可重復性。由于測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，從而達到測試的可重復的效果。
測試的復用性。由于自動測試通常采用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。
加大軟件信任度。由于測試是自動執行的，所以不存在執行過程中的疏忽和錯誤，完全取決于測試的設計質量。一旦軟件通過了強有力的自動測試后，軟件的信任度也會增加。
公司實力的象征。自動化測試也從一定程度上體現出一個公司對測試質量的重視和實力，增強用戶對軟件的信任度。
自動化測試是對手工測試的一種補充，自動化測試不可能完全替代手工測試，因為很多數據的正確性、界面是否美觀、業務邏輯的滿足程度等都離不開測試人員的人工判斷。而僅僅依賴手工測試，則會讓測試過于低效，尤其是回歸測試的重復工作量對測試人員造成了巨大的壓力。自動化測試的意義不是為了取代人在手工測試中的位置，而是將人從重復繁瑣的工作中解放出來，做更有價值的測試工作。
4 自動化測試框架
前面章節介紹了電信行業業務支撐系統對于自動化測試的需求，下面來介紹自動化測試在某省BSS系統支撐過程中的實際應用。
4.1 自動化測試框架整體介紹
建立自動化測試框架就是為了把測試數據與測試用例的分離、測試數據與業務流程的分離、測試用例與業務流程的分離，讓自動化測試更容易維護、用例的重復利用率更高，最后再和需求管理、開發進度管理統一起來，整個質量控制體系就更加完善。
自動化測試框架包括：自動化測試管理和自動化測試工具。自動化測試管理包配置管理、組件管理、測試用例管理、測試計劃管理、數據管理，自動化測試報告管理。在本自動化測試框架中使用的是SilkTest測試工具和自主配套研發的自動化測試管理工具平臺。運用在實際的電信行業中的框架如圖1所示。
5 自動化測試工具選用
自動化測試的工具很多，當前主流的自動化測試工具有Mercury Interactive Corporation、IBM Rational、Compuware Corporation、Segue Software等公司的系列產品。產品簡介如下，這里選用的是Borland Software SilkTest（原SegueSoftware產品）
SilkTest 是面向 Web 應用、 Java 應用和傳統的 C/S 應用，進行自動化的功能測試和回歸測試的工具。它提供了用于測試的創建、定制的工作流設置、測試計劃和管理、直接的數據庫訪問及校驗等功能，使用戶能夠高效率地進行軟件自動化測試。為提高測試效率， SilkTest 提供多種手段來提高測試的自動化程度，包括：從測試腳本的生成、測試數據的組織、測試過程的自動化、測試結果的分析等方面來進行規范。
SilkTest的腳本語言采用面向對象的編程語言 4Test 來編寫靈活的測試腳本，并且SilkTest 有較好的跨平臺性。
6 自動化測試管理平臺
為了能夠讓自動化測試入門更簡單，維護更加簡單容易。我們自主研發了自動化測試管理平臺，是基于自動測試工具的自動測試統一工作平臺。自動化測試管理平臺為B/S結構的系統包括組件管理、測試用例管理、測試計劃管理，測試報告管理等。自動化測試工具和自動測試統平臺的交互，能夠很好的維護自動測試腳本及工程文件，并能以更加直觀方式對自動測試結果進行展示。統一的自動化測試平臺有如下特點:
通過自動測試平臺對象管理功能，可以顯示對象的增量修改功能；
SilkTest工具編寫的腳本，可以導入到自動測試平臺，并通過可視化界面對腳本進行維護；
自動測試平臺可以對腳本進行有效的管理，保證腳本的唯一性；
自動測試平臺可以對SilkTest整個工程進行管理，方便整個工程的讀取；
自動測試平臺可以將測試結果文件以pdf文件的形式導出，便于對測試結果的閱讀和分析。
6.1 組件管理
組件管理包括：對象導入、對象維護、對象導出。
對象獲取。要管理對象，就要先獲取取對象。對象獲取和整理是編寫用例的前提。整理好對象會對在平臺上編寫用例有很大幫助。也會對接手維護的人員有很大幫助。對象是通過SilkTest工具來獲取的，獲取對象有兩種途徑：Window Declarations（獲得整個頁面的對象）和Window Identifiers（獲取單個對象的屬性）。Window Declarations獲取的對象，結果如圖2所示。
對象導入。通過自動化測試平臺的導入對象功能，將SilkTest獲取的對象存儲到數據庫中，以便后期維護和部署。頁面如圖3所示。
對象導出。通過自動化測試平臺導出對象文件以便部署到服務器上。頁面如圖4所示。
對象維護。對導入的對象進行修改或者添加新的元素，頁面如圖5所示。
6.2 自動化測試用例管理
自動化測試用例的管理包括：測試用例添加，測試用例維護，測試用例導出。
用例添加。需要填寫用例名稱、用例說明、期望結果和用例類型。操作頁面如圖6所示。
用例維護。添加用例完成后，在用例維護中將SilkTest中的腳本寫成操作步驟。此時頁面右邊的樹就是我們導入的對象，點擊對象就可以添加操作步驟。補換卡業務的測試步驟截圖如圖7所示。
用例導出。將用導出為SilkTest可執行的腳本文件，以后需要調試該用例時，直接通過自動測試管理平臺導出用例執行，直接部署到自動化測試機上。操作頁面如圖8所示。
6.3 數據管理
在編寫測試用例的過程中，一定會涉及到數據的交互，例如測試用例的輸入數據從哪里獲得，如何對輸出結果進行驗證等。
通常有兩種方法：數據寫到腳本里面；將數據與腳本分離，存放到excel或數據庫中。我們現在選擇的是將腳本和數據分離的方式，這樣做有如下好處：
1）便于腳本的維護；
2）便于一個腳本支持多個用例，當編寫一個新用例時，只需去配置與該用例相關的數據即可；
3）利于擴展和組織測試計劃。
6.4 測試計劃管理
測試計劃管理包括：計劃新增、計劃維護和計劃生成。
計劃新增。自動化測試管理平臺上有測試計劃管理功能，查詢出用例并放到新計劃中。同時系統還提供了對測試計劃維護的功能。如圖9。
計劃維護。自動化測試管理平臺上有測試計劃維護功能，即修改已經存在的計劃里面包含的用例，可增加或者刪除，操作頁面如圖10所示。
計劃生成。由測試計劃生成功能，生成腳本、生成計劃。即可部署到自動化測試主機上執行。如圖11。
6.5 自動化定時執行
編寫一個bat文件，定時執行即可，如圖12。
6.6 自動化測試報告管理
結果數據的抽取、匯總與展示。在測試執行過程中，通過特定的數據采集組件以及事件觸發，獲得我們關心的中間結果數據，并且將數據全部入庫，根據客戶需求，展現一份客戶能夠看得懂的報告。避免了工具原有報告難理解的問題。同時，記錄下來的中間數據可以很好的體現出每個步驟地詳細信息和過程時間，這樣可以提供一段時間內的橫向和縱向的對比，為系統特別是生產系統上的性能漸變提供有力的監控和依據。
自動化測試平臺從數據庫中撈出測試結果進行處理，根據需要生成用戶容易看懂的PDF格式的自動化測試報告，如圖13，圖14所示。
7 自動化測試流程
有了上面自動化測試管理平臺的支撐，自動測試流程中編寫測試腳本、執行自動化測試的開展就會更加順利。
表1為自動化測試流程角色表。自動化測試流程如圖15所示。
1）制定測試計劃。測試經理要制定測試計劃，明確測試對象、測試目的、測試的項目內容、測試的方法、測試的進度要求，并確保測試所需的人力、硬件、數據等資源都準備充分。制定好測試計劃后，分派給QA；
2）分析測試需求。QA根據測試計劃和需求說明書，分析測試需求，設計測試需求樹，以便用例設計時，能夠覆蓋所有的需求點；
3）設計測試用例。QA通過分析測試需求，設計足夠多能夠覆蓋所有需求點的測試用例，形成專門的測試用例文檔。并不是所有的測試用例都能用自動化來執行，所以需要將能夠執行自動化測試的用例匯總成自動化測試用例；
4）搭建測試環境。自動化測試人員在用例設計工作開展的同時即可著手搭建測試環境。包括被測系統的部署、測試硬件的調用、測試工具的安裝和設置、網絡環境的布置等等；
5）編寫測試腳本。自動化測試人員在自動化測試管理平臺的支持下，編寫自動化測試用例步驟，通過自動化測試工具編輯腳本插入檢查點和異常判定反饋語句，調試腳本；
6）執行自動測試。自動化測試人員測試測試計劃，驗證軟件功能，執行回歸測試、流程測試等，以替代重復性的手工測試工作；
7）分析測試結果。自動化測試人員根據執行結果，分析測試通過與沒通過的情況，通過自動化測試平臺生產用戶容易讀懂的自動化測試報告；
8）記錄測試問題。QA在測試腳本執行完畢之后，即可查看測試工具的測試報告，然后將沒有通過的地方提取出來，描述成BUG，反饋給開發人員；
9）跟蹤測試BUG。QA將測試中發現的BUG記錄到BUG管理工具中去，以便定期跟蹤處理。開發人員修改后，需要對此問題執行回歸測試，即重復執行一次該問題對應的腳本，通過則關閉，否則繼續修改。如果問題（BUG）的修改方案與客戶達成了一致，但與原來的需求有所偏離，那么回歸測試前，還需對腳本進行必要的修改和調試。
8 系統軟硬件環境
系統的軟硬件基本要求如表2所示。
9 結束語
電信行業業務支撐系統隨著電信業務的發展和計算機技術的日新月異，系統功能不斷擴充和更新。每次需求變更，系統缺陷，都會給系統帶來大大小小的頻繁更新。在需求管理、測試流程管理、測試環境這些都具備的條件下，要滿足運營商給開發商預留的項目工期越來越緊，對軟件的質量要求越來越高，對開發商軟件正式上線前盡量減少程序BUG這些要求，這就必須要提高軟件測試的質量和效率，在手工測試的基礎上引入自動化測試，建立完善的自動化測試管理平臺，統一管理測試用例庫，讓自動化測試完成大量的回歸測試和重復性測試，讓測試人員將精力投入更有意義的測試，制定更加合理的測試計劃、設計更完善的測試用例，使得測試覆蓋率更高，發現更多的問題，最終保障BSS系統的質量、降低業務支撐系統給運營商帶來的風險，也將對電信運營商的業務支持起到非常積極的作用。
參考文獻：
[1] 科茲納.項目管理：計劃、進度和控制的系統方法[M].10版.楊愛華,譯.北京:電子工業出版社,2010:19-102.
[2] 柳勝.軟件自動化測試框架設計與實踐[M].北京:人民郵電出版社,2009.
[3] 陳能技.軟件自動化測試成功之道[M].北京:人民郵電出版社,2010.
[4] Paul C.Jorgensen. 軟件測試[M].韓柯,杜旭濤,譯.北京:機械工業出版社,2003.
[5] 胡貝蒂.軟件質量和軟件測試[M].馬博,趙云龍,譯注.北京:清華大學出版社,2003.
[6] 布萊克.軟件測試實踐[M].郭耀,譯.北京:清華大學出版社,2008.
[7] 朱少民.輕輕松松自動化測試[M].北京:電子工業出版社,2009.
[8] 蔡為東.贏在測試[M].北京:電子工業出版社,2010.
[9] 溫伯格.完美軟件[M].宋銳,譯.北京:電子工業出版社,2009.
[10] 惠特克.探索式軟件測試[M].方敏,張勝,鐘頌東,等,譯注.北京:清華大學出版社,2010.
[11] 曹向志.軟件測試項目實戰[M].北京:電子工業出版社,2010.
[12] Dennis M.Ahern.CMMI精粹[M].3版.北京:清華大學出版社,2009.
【關鍵詞】湘潭站 空調工程 問題 辦法
中圖分類號：TB657 文獻標識碼： A
湘潭站是集建筑、旅游、商業、辦公于一體的地標性建筑。2009年在拆除老火車站的原址上重建，站房建筑面積為19234m2，其中公共區域面積 17759 m2、辦公區域面積1475 m2。站房主體為兩層，主體建筑高24.15m、長215m、寬51.6m，包括廣廳、候車廳、售票廳、出站廳、貴賓候車室、行包庫等。夾層東西兩側為辦公及設備用房。旅客服務區采用中央空調，貴賓候車室和售票辦公區采用多聯式空調，其他分散生產辦公區采用分體熱泵空調。集中空調冷熱源采用地源熱泵加水冷冷水機組的復合冷熱源形式，夏季空調用冷凍水供/回溫度7/12℃，冬季采暖用熱水供/回溫度45/40℃，最大冷負荷為2673KW， 最大熱負荷為1347KW。
工程從2009年12月開始建設， 2011年5月站房主體封頂， 2012年12月站房及相關配套工程竣工驗收并投入運營。空調工程在站房主體驗收合格后進場施工，同站房同步通過驗收。湘潭站改擴建工程總投資77840萬元，其中空調工程投資約1100萬元。
一、室外地埋管系統因場地問題需要進行調整。
湘潭站采用國內最先進、最環保的地源熱泵空調系統。本工程采用豎直埋管系統，按滿足冬季供暖負荷設計，采用DN25單U型埋管，正方形分布，間距4m×4m，孔徑D150，鉆孔深度100m， 總計鉆孔313口井，占地面積6470 m2。
地埋管主要布置在站房東側130m×40m區域和東南側70m×20m區域，其中東側區域鉆井277口、東南側區域鉆井36口。由于拆遷不能及時到位，站房東側只能利用80m×40m區域進行室外地埋管施工，約有130口井無法按照設計圖紙布置到位。按照當時情況，最簡單的辦法是要求湘潭市政府重新騰出一塊地出來，專門用來鋪設室外地埋管。然而，要在商業價值極高的車站附近騰出一塊地來談何容易，雖然湘潭市政府做出很大的努力，最后還是無果而終。在此情況下，只能另辟蹊徑。對照設計圖紙，重新對室外計算參數、室內空調設計參數、工程冷熱負荷等參數進行了仔細的復核，沒有發現任何問題。但在查看設計文件的土壤熱物性的設計數據時，發現與土壤熱物性測試報告成果數據不一致。檢測單位的巖土體導熱性能測試報告結果：冬季吸熱為三口測試井的平均值46W/延米、夏季放熱為三口測試井的平均值60W/延米。而設計數據是按照“冬季吸熱量50W/延米、夏季放熱量35W/延米”經驗數據進行估算的。對照兩組數據，夏季放熱量的差距比較大，但設計已考慮了一臺水冷冷水機組，夏季冷負荷足以保證。為確保冬季熱負荷，設計按照冬季最大設計熱負荷1347kw為指標值，來確定室外地埋管井的數量。根據測試報告 “冬季吸熱量46W/延米”為依據，并考慮管道的1%的熱量損失，計算出地埋管長度29575米，按照100m/口井計，整個湘潭站只要296口井就能滿足設計要求，雖然減少了17口井，但由于場地的局限性，也綜合考慮地源熱泵機組電輔助加熱功能，最終室外地埋管調整到287口井。設計重新布置室外地埋管，其中站房東側區域鉆井191口、東南側區域鉆井96口。總計減少鉆井26口，室外地埋管工程節約投資50余萬元。
二、空調控制系統因設計不完善而需要進行調整。
建筑耗能是一個國家總耗能的重要組成部分，約占全國總能耗的30%左右。而在建筑耗能中，采暖、通風和空調能耗占40%-60%。可見，空調節能是當今世界關注的問題。眾所周知，空調節能主要是通過控制水泵流速進行的，水泵流量、轉速、功率之間有如下關系：
………………………………….（1）
……………………………….（2）
式中，Q-水泵實際運行流量，m/h； n-水泵實際運行轉速，rpm；N-水泵實際運行功率，kw；Q-水泵設計流量，m/h； n-設計工況下水泵轉速，rpm；N-設計工況下水泵功率，kw。由上式可以看出，當Q=0.8 Q，則有N=0.512 N，通過變速裝置改變水泵流量，水泵運行能耗下降50%左右。因此，當室外氣象參數變化時，通過減少冷水機組水量調整機組制冷量，最有效地辦法通過變頻裝置控制水泵轉速達到節能目的。
為了實現空調的節能，湘潭站空調工程設計了智能節電裝置，具體實施對象為各立柜式風機盤管機組、組合式空調器、冷熱主機、屋頂冷卻塔、水泵等，而受控設備為空調器、配套的蜂巢型電子過濾器、納米凈化裝置、機組配套電動風閥及水閥。并對空調器、配套的蜂巢型電子過濾器及納米凈化裝置、配套回風閥、配套動態平衡電動調節閥進行監控，并通過通訊接口接受BAS指令后上傳相關設備運行狀態及故障報警信號，各智能節電裝置接受BAS指令執行設備啟停、冬夏季供冷熱模式的轉換。
在工程實施過程中，智能節電裝置作為一種非標產品，施工圖紙沒有具體的控制原理及設備構造圖，只提出了一些粗略的要求，并要求中標廠家進行二次深化設計。智能節電裝置作為一種空調設備進行了物質設備招標，開標后和中標廠家進行了溝通，認為BAS控制對象太多，系統容易產生誤啟動等問題，因此對設備及控制方式進行了改善。首先，各智能節電裝置由BAS集中控制改為分區控制，設備的啟停改由人工操作。各立柜式風機盤管機組、組合式空調器、空調冷卻水系統、空調冷凍水系統各自設置一套智能節電裝置，通過各自的智能節電裝置達到空調設備節能的效果。而BAS主機只接受運行參數，不對空調主機、水泵、屋頂冷卻塔進行控制和開關。雖然系統自動化程度有所減弱，設備管理人員工作強度加大，但這大大減少了設備因天氣原因頻繁啟動及誤啟動。集中控制改為分區控制，減少各個設備之間的相互干擾，系統的穩定性大大提高。其次，取消風機盤管的動態平衡電動二通閥，改為手動閥。由于整個站房風機盤管只設有40臺，設有風機盤管的房間面積不到1000 m2，占整個站房面積的5%左右，空調能耗相對較小。對于這片區域，主要考慮運行期間系統的穩定性及空調效果，基本忽略節能方面的措施，這樣根本消除了空調末端設備因自動化程度高而產生的故障。通過這兩個方面的改造，整個控制系統穩定性大大增強，避免了系統聯動控制產生的誤啟動。這樣既達到了系統節能目的，又減少了工程投資。
關鍵詞：技術性貿易措施 壁壘 印度
一、引言
技術性貿易措施是指確定工業產品或消費品的某些特性的強制性或非強制性的規定、標準和法規，以及檢驗產品是否符合這些技術法規和確定產品質量及適用性能的認證、審批和試驗程序。
二、印度技術性貿易措施概要
（一）主管部門及職責
根據《印度標準局法規》，印度標準及認證事務的主管部門是印度標準局（以下簡稱BIS），BIS下設5個地區局和19個分局。地區局監管對應分局。印度標準局的主要職能有：制定國家標準；認證管理，包括產品認證和質量體系認證；認可和管理實驗室，包括檢測、校準及管理；標準推廣和培訓；國際合作；標準及認證的信息服務；消費者事務等。同時還負責對強制性認證產品的市場監督。
（二）法律法規體系
《印度標準局法》是印度管理標準及認證事務的基本法律。該法規定了印度標準局的設立、機構設置及職能。此外，有關標準及認證管理的法規還有：《印度標準局規則》規定了標準的制定和管理；《印度標準局（認證）規則》規定了產品認證和系統認證的管理。
（三）產品質量認證制度
1、認證原則
印度的產品認證實行自愿認證原則，旨在為最終消費者提供有質量保證、安全可靠的產品。考慮到公共衛生和安全以及大眾消費等因素，印度政府通過即時法令，對特定產品施行強制認證。BIS僅就申請授予認證證書，強制的具體工作由相關權力機構執行。
2、認證模式
BIS的產品認證模式是通過對工廠質量管理體系的初次檢驗和評定，對工廠質量管理體系的監督，及對工廠和市場上抽取樣品進行檢測，來決定產品是否與印度標準一致。
3、認證領域
BIS認證適用于任何國家制造商，認證領域主要有：1.紡織品；2.化學藥品和殺蟲劑；3.水泥和混凝土；4.金屬制品；5.機械設備；6.電氣電子和光學設備；7.汽車配件；8.農產品，食品，飲料和煙草；9.皮制品；10.木制品；11.紙和紙漿產品；12.測試器械；13.建筑材料；14.抽水、灌溉、排水和污水裝置。
4、其他產品認證制度
除常規產品認證外，對于環境友好產品，BSI執行特殊的認證并授予ECO標志。印度也是國際電工委員會IEC成員國。BIS代表印度參加IEC的各項活動。國際電工委員會電工產品安全認證組織接受的BIS產品目錄有：電纜、電容，低電壓高功率開關設備，安裝保護設備，電子產品等。
5、BIS產品認證證書授予程序
第一步，申請。填寫專用申請書并遞交以下文件：1.工廠分布圖；2.生產廠房的證明文件；3.現有生產設備及檢驗設備列表；4.使用的測試檢驗方案，遵守BIS認可的測試檢驗方案的承諾函；5.支付規定標志費的承諾函；6.遵從中止標志使用的承諾函；7.描述生產和檢驗步驟的流程表；8.現有技術人員的詳細情況。
第二步，記錄。BIS將把申請記錄在案，并分配給申請者一個申請號，申請因此成立。
第三步，初次檢驗。BIS通過對公司生產能力和控制水平、質量控制技術、現有設備、工作人員技能的評估以及樣品測試等，確定產品是否符合印度標準。樣品測試可在工廠進行，同時也會在BIS或其他認可的實驗室進行。
第四步，頒發證書。如果初次檢驗及樣品測試結果滿足條件，將頒發給申請者證書。證書有效期一年。如果執行證書無誤，經申請一次可延期兩年。如果執證人希望擴大證書同一標準所覆蓋的產品范圍，經常規測試，符合條件者即可變更。
第五步，認證后監督。證書授予后，如果執證人全部履行了測試檢驗方案，產品與印度標準一致，樣品測試記錄保持完整，經授權即可在產品上加蓋標志。BIS將對執證人就證書執行情況進行定期的監督檢查。這種監督檢查主要看測試檢驗方案是否完整履行，質量控制系統是否嚴格按技術標準執行，同時測試生產樣品，將抽取的樣品送至BIS或獨立實驗室進行檢驗。定期檢查和產品測試的結果，會以適當的方式告知執證人。
國外生產商在印度的產品認證也是建立在自我認證的基礎上。但在申請前，國外生產商須經印度儲備銀行許可在印度設有聯絡處或分公司或在印度指定一個授權。該聯絡處或分公司或應服從BIS法令、章程和規則并對此負責。
三、印度技術性貿易壁壘
（一）進口強制檢驗制度
目前，印度規范進口強制檢驗制度的法律依據就是商工部第29號通告。凡是進口屬于BIS強制認證產品范圍內的109種進口產品，外國生產商或印度進口商必須事先向BIS申請產品質量認證，并獲得認證證書，海關依據認證證書對進口產品予以放行 。
印度進口商申請的進口質量檢驗在下列三種情況下可以由印度商申請進口質量檢驗：該進口產品的消費是必須的；該進口產品的需求是持續的；該進口產品從預先確認的渠道獲得。對于印度生產商申請的進口質量檢驗，印度進口商必須首先建立一個檢驗設備符合BIS要求的實驗室，申請進口質量檢驗時應在申請表后附上進口商對進口樣品的檢驗報告。BIS認為必要時也可派出一個不超過2人的檢驗組到進口產品的生產廠實地檢驗，進口商承擔檢驗組的所有旅途費用。
（二）進口自愿檢驗制度
凡是進口屬于強制進口認證產品范圍之外的產品，是否檢驗由外國生產商或印度進口商自愿決定，政府不加干預。
（三）認證與標志要求
印度STQC強制性認證：安全認證（STQC標志）體系是一個針對電子產品的第三方認證體系，主要由印度政府主管，遵照國際標準ISO/ IEC guide 40和EN 45011標準，須由被認可的實驗室來執行測試（特別是由IECEE-CB認可的實驗室），測試報告采用CB測試報告的模式。
印度ISI標志認證：印度在進口下列24類159種產品時需事先獲得印度標準協會的認證才能進口，這些產品包括浸入式加熱器、電熨斗、電爐、散熱器、家用開關、電燈泡、斷路器、保險絲、開關設備、電纜、儀表和變壓器等，外國生產商或貿易商必須先向BIS申請注冊其產品，在符合BIS認證標準后，可獲準貼上ISI標志。
2011年中印貿易額突破700億美元。印度作為一個新興經濟體引起多國關注。中國出口企業要想搶占先機就應該多了解印度技術性貿易措施，才可以讓中國產品順利進入印度市場，本文對印度技術性貿易措施做了概要介紹，以期對相關企業有所幫助。
參考文獻：
①葉柏林，陳志田．技術引進與進出口商品標準化[M]．北京：對外經濟貿易大學出版社，2004年版，第38―43頁
②張錫暇. 外國技術性貿易壁壘及其應對[M]．對外經濟貿易大學出版社，2004
③BIS.Product Certification Schemes[EB/OL].［2007－05－21］
省略.in/cert/fms.htm.
④王愛華. 印度市場準入／認證制度介紹[J]．認證技術.2011.7.P52―53
⑤STQC．STQC Product Certification[EB/Ol]．［2007－05－21］
stqcnicin/index3asp?sslid=561&subsublinkid=356&langid
=1&plid=63&pplid=140
1電子產品開發概述
電子產品的開發離不開企業這個實體，開發項目管理理念需要結合企業的自身實際情況，如企業的行政組織架構，開發項目團隊的組織架構等來制定最適合企業的一套產品開發項目管理流程。本文以圖1所示的開發項目團隊組織架構框來闡述電子產品開發項目管理流程。產品開發整體流程實際上包含一系列階段步驟，把一組需求和思想轉化為市場上成功產品的流程。本文介紹的電子產品開發項目整體流程框圖如圖2所示。由圖2所述，電子產品開發首先要進行市場調研階段對產品作出準確的市場定位，項目管理者需要進行產品評估設計階段仔細分析產品功能指標、性能指標、技術參數、系統規格確定準確的項目開發文檔作為產品開發的輸入，需要對整體設計進行開發計劃的制定，系統規格等進行產品開發目標的確定，同時組織設計開發項目團隊成員分配，設計開發人員項目責任分配，制定團隊各成員的詳細準確的設計參數任務書，設置各個階段時間節點，進行產品成本、時間的控制目標和措施，生產過程中文件控制的實施，產品標準化制定計劃等。隨后進行產品設計實施階段，進行設計評審、開發執行，接著進入制作ES樣機階段制作樣機進行測試，測試成功隨后進行產品小批量生產階段進行生產小批量樣機測試，產品大批量生產階段，產品更新維護階段直至產品全生命周期結束。
2電子產品開發技術的詳細流程
2.1硬件設計流程
產品硬件設計流程如圖3所示，硬件項目組根據產品的技術定義，準確的系統技術參數規格、功能指標、電氣性能指標等，進行硬件電路實現方案的設計工作，方案的設計可以提出幾套實現方案，最好能引用原有生產產品上的經典的電路模塊從而更有力保證產品的設計的穩定可靠性，項目協調員組織相關責任人進行硬件電路設計的評審，評審的原則是以最低的成本最可靠的方案為原則進行方案選定。選定后由硬件工程師進行原理圖的設計，設計完成后需要進行原理圖的評審工作，評審合格后再進行PCBlayout設計，在進行PCB設計的同時硬件工程師需要與結構工程師一同協調確定產品的開口，孔位，接口位置等信息進行PCB設計。PCB設計完成后需要進行PCB圖的評審，PCB評審成功后再進行BOM表的整理，進行元器件的采購，焊接PCB后與軟件設計人員進行硬件單板功能調試工作，與結構設計人員進行裝配組裝調試，發現問題填寫問題報告，反饋協調到具體的相關設計人員進行整改工作。最后輸出的原理圖、PCB、BOM表等資料歸檔作為下一階段產品ES樣機資料發放的輸入。
2.2軟件設計流程
產品軟件設計流程圖如圖4所示，軟件項目組軟件系統需求分析得出的系統需求說明按軟件設計流程進行軟件方面的設計工作，設計的方案首先根據具體的硬件設計電路模塊進行各個模塊的軟件設計驅動及測試工作，如發現問題及時反饋給硬件設計人員進行協商修改，如果沒問題則提出系統軟件框架的設計方案，項目協調員組織相關責任人進行軟件方案評審，評審的時候需要仔細根據需求實現的技術細節來核實軟件是否能達到相應的技術指標。評審成功后則根據具體的功能實現模塊逐個進行軟件設計，每個功能模塊設計完成后，再進行軟件整體模塊代碼兼容軟件集成設計調試工作，調試成功后需要在幾套硬件上進行反復的測試，測試完成各方面達到系統要求指標后進行程序整理歸檔及初次發放版本管理。最后輸出的軟件說明文件、源程序、燒錄程序等作為下一階段ES樣機資料發放的輸入。
2.3結構設計流程
根據產品的技術定義，提出的準確的系統參數規格，結構項目組進行結構設計工作，根據產品的外觀要求，整體尺寸大小、開孔位置、按鍵、LED燈、屏的位置、端子開孔、電氣要求等，選擇合適的殼體，進行結構圖紙的繪制，繪制的過程中需要與硬件設計人員一同確定產品的一些細節問題，繪制完成后通過軟件模擬，模擬成功項目協調員協調相關責任人進行結構設計方案的評審，評審成功后進行結構圖紙的釋放進行快速成型制作一套結構結合PCB板、結構開孔、按鍵、屏、端子等進行組裝測試。測試沒有問題后進行結構圖紙的歸檔工作，最后輸出的結構裝配圖、部裝總裝文件等作為下一階段ES樣機資料發放的輸入。
2.4產品ES樣機流程
產品ES樣機流程如圖6所示，技術工程部在產品開發設計實施階段完成了硬件、軟件、結構設計之后，將硬件設計的輸出、軟件設計的輸出、結構設計的輸出作為產品ES樣機的輸入文件，相關技術設計工程師完成ES樣機的測試、調試、組裝、裝配工作，同時將遇到的問題記錄到樣機問題反饋表中，隨后進行產品功能測試、產品電氣測試、產品整機測試，測試過程中如發現問題及時反饋給相關責任技術設計人員進行修改，如果沒問題則將產品設計文件，ES樣機反饋問題，功能測試報告，電氣測試報告，ES樣機整機檢驗報告等進行歸檔工作，同時將ES樣機進行拍照錄像存檔工作作為下一階段小批量生產的輸入，完成產品ES樣機流程。
2.5產品的小批量生產
產品ES樣機階段結束后，接下來的階段就是進行產品的小批量生產試制階段，工藝部門與技術工程部門進行輸入輸出文件交接工作，工藝部門根據產品ES樣機流程階段的輸出得到的各種歸檔資料作為產品小批量生產的輸入。產品小批量生產試制其流程如圖7所示。工藝部門獨立按計劃按流程制作小批量樣機，完成后質檢部門QC對小批量樣機進行整機全檢，并公布遇到的所以問題，工藝部門完成解決相關問題無法解決的問題反饋到技術部門相關設計人員解決相關問題，解決完成后公布處理結果，工藝、質檢進行協調測試直至一致通過，接著進行修改完善相關資料，最后進行工藝、質檢、技術三部門共同認證小批量生產的樣機是否合格，合格則完成產品的小批量生產流程。
2.6產品的大批量生產
電子產品經過工藝部門小批量生產后完善了產品的配套的工藝生產指導文件，但是有時在大批量生產會暴露出批量的相同的問題如電子元器件采購出錯，芯片批次不同造成性能不同，結構件的加工誤差無法組裝等等，所以在大批量生產之前除了需要根據工程樣機及配套的工程樣機文件來指導大批量生產之外，在大批量生產進行頭幾臺生產時仍然需要仔細進行整機制造后進行整機全檢，持續修改完善工藝資料后，接著就將完善后的工藝資料正式轉為生產指導資料指導流水線進行大批量生產進程。大批量生產的流程圖如圖8所示。
2.7產品維護階段
產品開發大批量生產階段結束后，整個項目并未結束，此后由于客戶需求，技術更新，降低成本等因素進行產品修改更新，都會在原產品基礎上提出些設計的更新變更方案，這個階段就是項目產品維護更新階段，需要對項目設計更新，設計人員修改設計文檔，在ES樣機上進行測試，測試合格是否正式，正式發放升級通知及更新套件處理等，以及進行產品更新升級批次的管理工作等一系列跟蹤直到項目生命周期的結束。其中產品修改更新流程如圖9所示。
3結束語
關鍵詞：嵌入式系統開發，Matlab/Stateflow/RTW，系統建模，自動代碼生成，代碼測試
0 本文意義
傳統的手寫代碼式嵌入式系統開發方法不夠直觀，開發周期長，測試和維護困難。圖形化編程和自動代碼生成技術將成為本世紀嵌入式系統開發的趨勢和主流。科技論文。本文結合車載智能能源分配器的開發，利用Matlab/Stateflow/RTW工具包完成系統建模和代碼生成。完成測試后自動燒錄到微型控制器中，從而起到降低成本和縮短開發周期的作用。
1 系統建模及代碼生成
根據廠方要求編輯技術規范并劃分子系統，使其成為通用的兩種模式：真值表（TrueTable），有限狀態機（StateMachine）。子系統獨立建模可以使得單個模型容易測試和維護，通常完成建模后應該有自動生成的以下4個文件作為分析備份：
1)測試通過報告（SubSystem_Report.txt）
2)MCDC測試報告（SubSystem_cov.html）
3)Test Case VS Requirment報告（SubSystem_tseq.xls）
4)系統模型 （SubSystem_Report.mdl）
所有的模型都使用模型庫進行維護，TLC將保證生成子系統代碼只包含.h和.c文件（腳本和TLC只對庫進行操作，不對模型進行操作）。這樣可以保證代碼的唯一性和方便管理。所有模型完成后必須通過功能整合測試。
以下是能源分配器中短路監測中的一個模塊為例子：
短路監測功能是輸出處理（Output Process）庫中的一個子模塊，針對不同的控制功能對應不同的監測方案，控制功能包括：前后燈，轉向燈，中央控制鎖，喇叭，頂棚折疊，座椅折疊等。
Figure 1 RETRY/NO_RETRY Controller State Transition Diagram
如果考慮到大量短路檢測和繼電器控制，短路檢控就變得非常困難。RETRY/NO_RETRY模塊將自動控制是否繼續對晶閘管進行供電，如果僅依賴硬件過載自動復位將嚴重影響硬件的壽命。軟件控制的原理是短時間內連續檢測其短路次數（FETShort_Cnt[n]），如果在極短時間內達到伐值就判斷系統確實短路，不再供電。
一旦一個晶閘管達到短路次數達到其壽命的1/3，2/3或者3/3伐值，控制器也將永久關閉對它的供電（NO_RETRY），只有測試工具才能再將其激活。RETRY/NO_RETRY模塊的執行順序永遠在Short DetectionController 模塊之前。
Figure 2 Short Detection Controller State Transition Diagram
Short DetectionController內部是兩個平行的狀態機，執行順序為AàB。科技論文。A狀態機用來追蹤是否有電流輸出及讀取晶閘管的反饋以判斷是否存在一個短路。B狀態機則追蹤A狀態機的狀態并與A前一狀態的比對。在算法上A狀態機會將短路次數累加Intergrate[n]直到255（不同模塊配置不同的累加速率），然后B狀態機立刻捕捉到短路情況并終止電流輸出。
Figure 3 Short Detect Process Integration
值得一提的是Matlab/Stateflow中提供的計時函數編譯完成后有一個機器時鐘的延時，對高速信號處理狀態機有影響。必須手寫嵌入式代碼并在編譯目標中內嵌手寫代碼。
Figure 4 Configure Embed Code forComplier Target
自動代碼生成腳本中應該注意：
1) 自動腳本的編寫應該先驗證所有模型變量和數據字典的兼容性并自動生成錯誤報告；
2) 自動修改模型中的變量類型并選擇適合的芯片類型及相關時鐘配置設置；
3) TLC的編寫和引用并設置代碼類型（GRT或者ERT）；
4 )數據類型別名的定義應該和代碼測試中所用到的一致。
2 代碼測試
由于數據截斷和可能存在的實際代碼和行為模型的不一致將導致自動生成的代碼在實際運行中發生錯誤。如何才能有效地檢測自動生成代碼，是一個亟需解決的問題。本文給出了在VC++2005編譯環境下使用MxVDev作為測試工具的嵌入式系統高效測試機制。
具體操作步驟如下：
1) 將要測試的模型在Matlab中完成系統整合并通過測試，在Signal Builder中保留所有的Test Case。這一步至關重要，開發人員必須保證Test Case的質量，否則將直接影響軟件在環測試，硬件在環測試以及最后代碼的質量。
2) 完成之后通過Matlab腳本自動將所有的Test Case轉化為.xmc文件供測試工具調用（通用機器建模語言）。自動化腳本轉換工具可以避免手寫代碼的失誤并大大減少開發時間，特別對于包含大量Test Case的系統開發非常有益。
Figure 5 M-Script Convert tool and VC++ Environment Setup
3) 把驅動層代碼，應用層代碼，任務調用函數，自動生成的代碼，數據流定義（DFA）等文件(所有的代碼除了驅動層以外都均可通過Matlab操作API函數完成)在VC++2005環境下配置好，并將調試器設置為MxVDev而不是VC++2005。完成編譯后系統會自動啟動MxVDev。
4) 啟動MxVDev后導入已經完成的.xmc文件，就可以進行軟件在環測試，代碼級測試非常嚴格，所有潛在問題均可以顯現出來。科技論文。如果測試不通過MxVDev會自動生成測試報告，用于問題分析和方案修改。如果測試通過就可以導出.asv文件進行硬件在環測試。
Figure 6 Software In Loop and HardwareIn Loop Test
3 結束語
本文介紹的嵌入式系統開發和測試機制具有極高的實用價值，有利于整個項目可以有序，分階段地開展，獨創的代碼測試機制并使代碼質量得到極大的提高。整套開發機制依靠Matlab為核心，過程嚴謹縝密，為實現嵌入式系統的自動化開發提供了一條新方案。
參考文獻：
[1] Robert Bosch GmbH. Autoelektrik, Autoelektronik [M].Braun-schweig: Vieweg Verlag, 2002.
[2] 楊滌.系統實時仿真開發環境與應用[M].北京:清華大學出版社, 2002.
[3] 蘇濤,等.DSP 實用技術[M].西安:西安電子科技大學出版社, 2001.
[關鍵詞]創新精神;學科競賽;實踐能力;獨立院校
[中圖分類號] G64 [文獻標識碼] A [文章編號] 2095-3437（2016）11-0064-03
全國大學生電子設計競賽是面向大學生的群眾性科技活動，而且是一項需要參賽選手在規定時間內制作出實物的競賽。北京郵電大學世紀學院自建院以來，組織學院學生參加了四屆全國大學生電子設計競賽（2009年、2011年、2013年、2015年）、四屆北京市電子設計競賽（2008年、2010年、2012年、2014年），共有49隊參賽，其中有23支隊伍曾分獲北京賽區一、二、三等獎，26支隊伍獲成功參賽獎，學院還獲得了北京市賽區優秀組織獎，在北京市獨立院校中名列前茅。回首八年的參賽之路，很多不足之處需要我們思考，很多經驗也要進一步總結和探討。
一、電子設計競賽的特點
（一）內容多、知識廣、要求高
電子設計大賽與課程優化、課程內容改革緊密結合，競賽內容不僅包含理論方案設計，還包括實際制作與作品調試兩部分。完善理論方案設計時需要涉及多學科知識，而實際制作與作品調試部分對學生的要求則更高：在4天（北京賽為1天）的競賽時間里，參賽學生需要將前期理論設計方案的內容轉化成能夠實際操作的作品。從競賽內容的角度來看，電子設計就是考查學生是否具備綜合運用日常所學得的理論知識，并順利將其轉為實際可用作品的能力，這不但要求學生要深入理解理論知識，知道知識怎么用、怎么恰當用、怎么更好用，還要求學生在制作實際電子工藝作品時，要踏實耐心、有條不紊。
最終的競賽成績由三方面評定，分別是理論部分、實踐部分以及發揮部分，成績總分為100分，理論部分和實踐部分各半，附加分數最高為50分，根據作品發揮部分情況進行評定。理論部分主要從設計思路是否清晰，所應用的理論知識是否準確無誤，參賽作品是否有新技術的應用，方案驗證是否嚴密，設計報告、測試報告及總結報告是否完整幾個方面進行評分;實踐部分則依照參賽團隊是否按設計要求制作出樣機，工藝要求是否完美、結構是否合理、是否有完整的調試改進報告幾點來進行評分;發揮部分為附加部分，該部分得分為附加分，即在完成基本要求后進行擴展。發揮部分的設定可以充分調動參賽學生的積極性和創造性。由于難度大、時間緊，發揮部分并不易得分。從成績評定的角度來看，該競賽對參賽隊員提出了很高的要求，既要從不同的院系和專業中選拔具備相應能力的學生，又要讓每個參賽學生在備賽的過程中熟悉相關學科的知識、掌握相關技術，從而確保參賽團隊在完成理論部分和實踐部分的基本要求后，盡量完善作品，爭取更多附加分。[1]
（二）時間短、工作量大、競爭激烈
根據競賽內容特點，參賽學生的專業主要有電子信息類專業、電氣及自動化專業和一般工程專業。按電子設計競賽組委會的規定，競賽必須在4天（北京賽為1天）內完成方案設計、電路制作、軟件編程和設計報告（北京賽不用）各項工作。這就要求參賽學生必須熟練掌握電子技術和計算機等課程的基本知識、基本電路、基本分析和設計方法，而且對指標、誤差、系統等工程概念非常熟悉，還要求學生有很強的實踐動手能力和創新能力，熟練使用儀器、儀表及迅速判斷故障和調試電路的能力。[2]參賽團隊不僅需要在短時間內完成大量的工作，同時還要和來自北京賽區30多所高校派出的約500多支隊伍進行比拼，競爭極其激烈，不可掉以輕心。
二、電子設計競賽的籌備和組織
學生是電子設計競賽的主要參與者，一直采用固定的選拔方法以及不變的培養方式不再適用于新時代的學生，整體素質的變化決定了參賽學生的選拔和培養過程的動態化和更替化。結合八年的參賽經驗，競賽的籌備和組織工作可分為以下幾個階段：
（一）組織和動員階段
電子設計競賽得以順利開展，組織和動員階段的工作至關重要。學院應成立教師競賽指導小組，組織學生工作教師積極宣傳及通過微信公眾平臺宣傳，采取教師推薦以及學生自愿報名兩種方式。不過，需要注意的是，第一次參與競賽的學生熱情雖高，但他們對比賽的性質、內容、規則以及必備知識等方面都還有所欠缺，因此在報名結束后，要由教師競賽指導小組統一對報名參賽的學生進行系統性的宣講和培訓，并在培訓結束后安排理論考試，并通過本次考試完成第一輪選拔工作。
競賽的組織和宣傳將競賽精神普及到學生中，讓更多學生意識到自己所學究竟如何應用，知道所學專業知識的實際意義，不僅如此，競賽精神的普及能進一步改善學院學風，并對學院原本枯燥的理論課堂教學起到改進作用，讓更多學生逐漸理解并喜歡自己選擇的專業。
（二）面試及實踐能力測試階段
第一輪的選拔工作主要以理論考試的方式進行，從而選拔出理論基礎較好的學生，但是電子設計競賽對參賽學生的綜合素質有極高的要求，基于此，我們在第二輪的選拔中選擇面試的方式來考查參賽學生的綜合素質。[3]面試問題由競賽指導小組來確定，主要圍繞學生特點，以語言表達能力、是非的判斷能力以及心理承受能力為考查方向。
通過第二輪選拔的學生還必須通過最后一輪選拔，也是最重要的一輪，即實踐能力測試。本輪測試主要以考查學生對電路的設計與焊接能力、電路的調試能力以及解決實際問題的能力為目的。設置本輪測試，一方面是幫助競賽指導小組確定適合參賽的隊員，一方面也給報名參賽的學生一個提前感受競賽的機會，幫助他們審視自身能力。我們認為，只有通過上述三輪測試的學生才具備成為正式隊員的基礎條件。
（三）基本技能練習階段
經過前三輪的選拔，入選學生的數量少但質量精，因此在接下來的訓練環節中，將針對學生現有的知識掌握情況進行基本技能練習（電路焊接、基礎電路的設計、應用電路仿真軟件進行仿真、編寫基礎單片機程序等），同時學生可根據自身特長，選擇合適的隊友進行組隊。
（四）集中培訓階段
集訓的時間一般會安排在暑假，但也會根據正式比賽時間進行調整，集訓內容基本為歷年競賽試題。參賽團隊經過集訓后就會逐漸確定自己團隊的隊長，隊長是整個團隊的核心，決定著團隊的設計方向和整體規劃。參賽學生在集訓中可以加深對專業知識的理解，也能加強對理論知識的應用，更重要的是通過這段時間的磨合，團隊協作能力有了很大提升，這種長時間的集訓學習是參賽團隊學生大學四年中不可多得的鍛煉經歷。
（五）臨戰準備階段
賽前主要進行臨戰前的準備工作。在臨戰準備期間，學院領導深入到學生中進行賽前動員，為參賽學生鼓勁打氣。而競賽指導小組會要求參賽團隊匯總各類資料并和其他團隊進行資源共享。需要注意的是，比賽期間所使用的電子元器件需要自己準備，為避免出現準備不足的情況，指導小組也會要求各團隊在這個階段準備充足的電子元器件。除此之外，指導小組將為所有參賽團隊準備參賽實驗室，其中配備參賽所需的各種儀器設備，如打印機、電源、示波器、信號發生器等。
最后根據電子設計競賽的要求，競賽指導小組給各參賽團隊進行具體分工：一人負責程序設計;一人負責硬件設計、制作與調試;一人負責繪制電路圖和書寫理論報告，并制訂“先保基本，再求發揮”的戰術要求。各參賽團隊可以根據指導小組的建議結合團隊實際情況進行合理安排，力求在場上發揮到最好。
（六）競賽階段
正式比賽期間，參賽團隊在電子設計競賽委員會的要求下接受半封閉管理，監督競賽也指定專人進行，帶隊教師在比賽期間不可以對參賽團隊進行競賽指導。各參賽團隊根據競賽要求和賽前集訓學習到的經驗，進行選題并盡快設計正確的實現方案。在這個過程中，整個團隊要明確分工，穩扎穩打，有條不紊，互相鼓勵，不要因為一時的困惑而氣餒。參賽團隊需要在規定的時間內完成設計構思、方案論證、繪制電路、選擇器件、實際制作、測試調整、改進性能、寫出測試報告等系列工作，并爭取在滿足試題規定的內容后思考是否可以進一步優化團隊方案，并進行可行性實施，這樣一來團隊除抓住基本得分外，還可以在發揮部分得分。前面已經提到過，電子設計競賽時間短、任務重，所以比賽期間學生都盡量不出實驗室，而且基本上每天僅有四到五個小時的休息時間，即便如此，最后一天他們依舊會通宵苦戰，所以比賽期間團隊協作至關重要。
（七）測試答辯階段
準備測試和正式測試答辯是測試答辯階段的兩個組成部分。競賽要求參賽團隊不僅會理論設計、實踐焊接，更要求團隊制作的作品在實際中能夠可靠運行，并且具有更高的性能指標，同時要求參賽團隊掌握適合本隊所選題目的全套測試方法。
（八）總結階段
在全國電子設計競賽北京賽區的結果公示后的時間里，學院競賽領導小組需盡快根據取得的成績進行競賽總結，整理競賽成果，記錄競賽體會并討論下一屆競賽籌備與培訓的改進方向。
三、獨立學院在學科競賽方面的問題
獨立學院目前在開展學科競賽中遇到的主要問題有：
（一）訓練經費不足
我們認為，如果學院僅將學科競賽視為學生的課外科技活動，會直接導致學校經費投入的不足。然而，在獨立學院中開展學科競賽是證明學生培養質量的一種有效途徑，如果學生通過培訓不斷獲得較好的電子設計競賽成績，這可以成為考量獨立學院學生培養質量的依據。另外，據我院的最終考研數據分析，假如學生曾在大學期間參加過電子設計競賽，那么其不論是在備考時的堅韌毅力，還是最終的考研成績都會強于未參加過競賽的學生，而且擁有出眾的實踐動手能力會更容易獲得導師的青睞。[4]
（二）訓練系統性不強
電子設計競賽開展的時間在獨立學院中并不長，有科研經歷的教師數量也并不多，因此學院的技術積累不強，對團隊的綜合訓練也存在系統性不強、涉及面不廣的問題。若想提高電子設計競賽的質量和競爭力，需要由有經驗的教師牽頭，堅持開展持續性的電子設計競賽，不斷積累參賽經驗，不斷改進培訓方案，增強綜合訓練的系統性，擴展綜合訓練的涉及面，不斷積累，不斷創新，保證獨立學院在電子設計競賽上不是曇花一現。[5]
四、結語
北京郵電大學世紀學院的電子設計競賽綜合實力并不輸北京市其他獨立院校，這和學校領導對電子設計競賽等實踐環節的極大重視和支持是分不開的。在領導的重視和支持下，競賽指導小組和參賽學生共同努力，在過去的八年中，參賽學生不但在電子設計競賽中取得了不錯的成績，還得到了很好的培養和鍛煉，同時為學風建設打下夯實基礎。不過，在電子設計競賽的征程中，獨立學院起點低，參與時間不長，相比于其他高校仍有相當大的差距，在未來的參賽路上仍需把握好形勢，堅持不懈地開展電子設計競賽的組織和管理工作。長此以往，獨立學院必會在電子設計競賽領域取得更好的成績。
[ 參 考 文 獻 ]
[1] 高吉祥主編.全國大學生電子設計競賽培訓系列教程――基本技能訓練與單元電路設計[M].北京：電子工業出版社，2007：2-5.
[2] 向夕品，別其璋.試析全國大學生電子設計競賽[J].重慶工商大學學報（自然科學版），2004（4）.
[3] 黎建輝，劉超良.高校學科競賽的管理與運行機制探討[J].湖南人文科技學院學報，2010（5）：119-121.
【關鍵詞】網頁制作；交互設計
技工院校的人才培養，不僅要求學生完成人才目標的學習任務和技能要求，更重要的是，知識儲備和技能要求必須得到就業崗位的認可。
一、技工院校網頁制作課程教學現狀
網頁制作課程是技工院校計算機和電子商務專業的核心課程，這是一門操作性極強、注重知識與應用相結合的課程。目前，傳統的教學觀念上，強調教師的“教”，缺乏交互意識，同時也缺乏合理的交互設計，課堂上課件、教案泛濫，課程的活動基本沒有經過完整的設計，把學生與內容的交互、師生之間的交互孤立起來，教師或學生自以為在完成任務的時候，卻沒有對學生的學習起到促進作用。
二、“交互設計”式網頁制作課
交互設計是從“目標導向”的角度解決用戶產品設計。在網頁制作課程中，網頁就是產品，是這門課程的輸出物，課堂教學對結果負責，也是技工教育的目標之一。如何實現網頁易用、有效而讓人愉悅的目標，如何將目標用戶的需求在網頁制作過程中體現，本文以某企業網頁制作為例，力求通過“交互設計”式的課堂，使學生在自己動手的實踐中，掌握技能要求，學習專業知識，構建自己的知識經驗和能力體系。
（一）需求獲取
這一階段輸出物主要是企業網頁的功能需求文檔和時間文檔，用以描述初步目標的提出，假想可能的解決方案，預估資源等。在這個階段，可將學生分為若干個討論小組，假想自身作為企業，對為何要制作網頁進行討論分析，并對制作方向形成初步思路，形成材料文檔。
（二）需求分析
本階段，要關注企業網頁的相關歷史數據，基于企業網頁制作本身，針對不同競爭對手、不同的行業特性做更詳盡的資料收集和分析，清晰的分析相似網站的性能和運行情況，同時，這個過程中要關注主流，才能吸引大眾。對學生的關鍵考核點是做必要的頭腦風暴，學生能否拿出具有競爭力的分析報告，是交互設計在這個階段的重要體現。
（三）用戶訪談
在企業網頁制作過程中，對于一些項目，建議學生能在項目初期尋求一些具體用戶的信息，對一些用戶屬性做好定義，和“客戶”交流，正確引導客戶將自己的實際需求用較為適當的技術語言進行表達，要求學生主動介入訪談問卷的設定工作，并客觀的參與用戶調研報告的完成。理解用戶，再思考合適的設計，能傾聽用戶的意見，但決不能盲從。
（四）需求修正
此前所做的需求分析和用戶訪談都是為此而準備，這個階段，要求學生進一步和需求方討論研究需求的合理性、可行性，做出一定的分析判斷，對功能需求文檔、企業網頁制作目標的設計重點進行明確，并將內容修正。在做到符合滿意策略的前提下，不漏掉關鍵環節。
（五）設計草稿
通過草圖設計，學生進入本課程的關鍵環節，這個階段的交互對線框草圖的形成至關重要。本階段核心設計點在于需求修正階段確認的設計重點，要求學生不匆忙著手設計。當學生在電腦前做設計的時候，會不自覺的考慮很多與設計本身無關的因素，而與設計本身聯系緊密的因素卻容易被忽略，筆和紙能讓學生把心思放在設計上，完成此項步驟時不拍腦袋繪制，而是針對核心設計點做調研和分析，在頭腦中形成一個即將制作的網頁的大概印象，通過手繪出樣稿形式，為下一步設計做準備。
（六）設計細化
在設計細化階段，學生完成核心設計的詳細說明，對企業網頁制作過程的交互做整體說明。由此制作企業網頁的雛形，并基本達到設計目標。在這個階段，每一個細節都至關重要，尤其是網頁頁面的完成，學生在進行實操的過程中，教師在一旁進行必要的指導。
（七）“專家評審”
本階段，交互設計體現在“聽、說、想”這三個方面上，教師耐心的聽學生講述網頁制作過程中的想法、做法，并做好相關評審記錄，結合溝通的內容，確認最終網頁制作的方向。學生之間也可以進行相互的“評審”，評審時間不宜太長，抓住關鍵點即可。
（八）設計優化
設計優化階段，將網頁線框圖到核心設計的詳細說明再進行一遍過程的完善，這個階段的投入程度和輸出物，直接影響到后續測試的效果，與最終的設計也息息相關。這個階段可以作為此前除需求分析后各階段內容再現。
（九）測試驗證
一個優秀的網站，一定要測試，測試會提醒你，不是每個人的想法都和你一樣，測試總是會有效果。這個環節能夠幫助學生最后把關整個網頁制作過程中交互設計的合理性，可以采用用戶測試，將這個問題轉換成測試者的一種認識，要求學生親自跟進測試并給出最終的測試報告和評估報告，哪些地方是前期沒有考慮周全的，哪些點是成功的，哪些點又是必須立即改進的等等……這個階段要求學生用“雞蛋里挑骨頭”的精神，保證最佳的輸出效果。測試是一個迭代的過程，不是做一次就可以了的，這也是要求學生進行數次測試的原因。
（十）完成設計
這是最后的設計階段，根據前期的測試驗證評估報告，要求學生對所有之前的輸出物做一次嚴格的檢查和修正，并完成企業網頁的最后輸出。
至此，交互設計式的網頁制作課結束，回顧以下關鍵輸出物：企業網頁文件，功能需求目標確認文檔、競爭分析報告、頭腦風暴產出物、項目初期用戶調研報告、核心設計點調研及分析報告、“專家”評審和評估報告、測試報告及頁面線框圖、核心設計點說明文檔。
三、“交互設計”設計策略
摘 要： 控制器是電動車的核心部件，其質量的好壞直接影響電動車的整體性能，針對其特點給出一種適用于電動車控制器在線自動檢測系統的設計方案與實現方法。該測試系統是由一個智能測試設備和一套運行于個人計算機上的控制分析軟件組成。給出了智能測試設備的結構組成與電路實現，設計出被測控制器提供各類測試條件的控制電路以及從被測控制器讀取結果的各類測量電路。同時也詳細介紹了控制分析軟件的開發。
關鍵詞： 智能測試設備； 控制電路； 測量電路； 控制分析軟件
中圖分類號： TN911.7?34； TP29 文獻標識碼： A 文章編號： 1004?373X（2013）09?0136?04
0 引 言
目前國內外電動車技術高速發展，歐美許多國家已經將向年長者及殘障人士提供電動車作為社會保障體系的一部分，其中控制器是電動車的核心零部件，決定了電動車的穩定性與可靠性。如何保障電控零件的質量穩定性和一致性，是本文研究的重點。
對于控制器的傳統測試，大多只測試電路板的電氣特性，普遍存在著測試點測試工序繁瑣，部分特性很難檢測；數據量大，處理困難；人工檢測效率低，人為因素加大；產品追溯困難等問題。針對上述不足，本文設計并實現了能對電動車控制器各功能在線自動檢測的智能測試系統。該系統能通過控制分析軟件的調度[1]，結合模擬負載裝置，自動進行功能測試，可以基本消除人為不確定因素。人機界面友好，顯示的測試參數豐富，可自動出具測試報告，并將測試結果存在數據庫中，留作歷史數據記錄以待查詢。
1 電動車控制器測試系統的組成及工作原理
本文所針對的電動車控制器包括串口通信模塊，前后燈及喇叭的控制與故障檢測， 速度控制與檢測模塊，電源控制模塊，電機功率驅動等。由于電子元器件本身存在質量缺陷及生產中出現各種工藝問題，將會導致控制器硬件在某方面工作不正常，因此測試系統必須能夠檢測出硬件的所有問題，并快速定位[2]。控制器輸入信號有開關量、模擬量、脈沖量等，輸出信號為驅動電機的模擬量，并有雙向通信的串口信號。
該智能測試設備由系統電源模塊，主控制器PIC18F65J10，通信模塊，車燈與喇叭的負載模擬與檢測模塊，電機信號模擬與反饋檢測模塊，行駛信號與速度傳感器模擬模塊組成。測試系統的結構圖如圖1所示。
測試系統工作原理：測試人員在PC 機界面選擇要測試的條目， PC 機通過串口1將此命令發送給測試設備；測試設備解析控制分析軟件的條目命令，模擬出該模塊的信號并輸入至控制器，同時，測試設備通過串口2和控制器進行通信，命令控制器啟動該模塊的功能。由測試設備采集數據將結果實時發送至PC機[3]；PC的控制分析軟件通過對比信號的檢測值與預設值是否一致來判定控制器是否工作正常，并將該產品的測試數據保存到數據庫中，以待查詢。
開發方：xx電子有限公司 (以下稱乙方)
甲乙雙方就甲方委托乙方設計開發______________________項目 事宜達成以下協議:
一、 乙方同意按甲方委托的技術要求為甲方開發，甲方保證在所委托項目功能符合協議要
求后_______月內向乙方訂購___________項目所使用含程序芯片數量_________套，本項目每套芯片價格和名稱如下：_________，型號：______________，價格人民幣__________元;(備注：以上價格不含任何稅費,在每次定單數量大于5000套另行協商); 協議在簽定后甲方必須向乙方支付保證金人民幣_____________元，如果甲方在______月內向乙方訂購此項目含程式芯片低于_________套，則乙方不退還保證金;在______月內定單數量超過_______套，乙方退還甲方所付全額保證金;
二、 乙方向甲方提供的MCU全部為______級，環境適應溫度為-_____℃~+_____℃; 三、 協議簽定后，甲方需將相應樣品提供給乙方或提品外殼尺寸及內部空間尺寸以及
相關資料，本項目需要甲方提供的資料包括：______________________ ;甲方并支付保證金人民幣________元匯到乙方指定帳戶內;乙方在確定款項到帳后在7天內快遞保證金收據給甲方。 四、乙方在收到甲方提供本項目需要的樣機或相關資料后，開始進行該項目的電路硬件設計
以及軟件設計，并在________天內提供按甲方要求設計的樣品________ 套給甲方測試確認;每套樣品價格人民幣_______元，如果甲方只要樣片，則提供五套給甲方制作樣機測試;(注:如果甲方不能及時提供該項目乙方需要的資料，請及時通知并協商處理) 五、乙方可為甲方提供整套PCB電路設計修改，并按具體情況協商酌情收取一定費用。 六、對項目中所使用語音芯片及內容由甲方提供，同時甲方需要提供給乙方該語音芯片控制
協議，乙方也可以提供給甲方語音芯片設計相關單位，由甲方與其聯系。
七、如果乙方在收到甲方提供的相關該項目完整資料之日起，在________日內(如果因甲方
相關資料不及時或其它甲方因素耽擱項目開發進度，則所耽擱的時間需要原定開發時間上增加;國家規定的節假日除外)設計的軟件不符合甲方項目功能描述要求，則視為研發失敗,乙方在七日內退還全額保證金給甲方;如果乙方設計的軟件符合甲方的功能要求，則視研發成功，甲方必須兌現在協商時段內向乙方訂購該項目規定含程式芯片的承諾，否則乙方不退還保證金;
八、樣片或樣機經甲方測試認可后，甲方可向乙方定貨。甲方定貨需先付全款后將訂購單傳真給乙方，乙方根據甲方傳真訂購單發貨;乙方在樣片或樣機經甲方確認后七日內提供以下資料給甲方：
1、 整機的原理圖、PCB設計文件; 2
、 整機產品物料清單;
3、 產品相關性能測試報告;
4、 部分材料供應商名單;
5、 產品外圍接線圖和說明;
九、甲方在小批量生產時，乙方將指定專人協助甲方生產，提供生產中技術指導和工程問題
協助處理，如果甲方要求乙方派人到甲方生產現場指導，所產生的差旅費用包括：每天________元生活補助、薪資補助每天 元以及車旅費用由甲方承擔。 十、 本協議一式兩份，經雙方簽字蓋章后方為有效，甲乙雙方各執一份;
十一、以上未盡事宜，可經雙方協商后簽定補充協議，該補充協議連同本協議具有同等法定
效律。
