量測程序如何編寫

㈠ 想用JAVA語言，或是C語言、C＋＋語言編寫一個測量圖片中物體尺寸大小的小程序，求大神帶路

寫這東西很麻煩的，給你個2思路：
方案1：要知道攝像頭距物體的距離，在攝像頭焦距不變的情況下，拍照獲取圖片，分析出圖片中物體的長度，即物體像素的長度，然後根據距離轉換成實際長度。
方案2：測量物體的附近有參照物，參照物已知長度。拍照後物體的像素和參照物的像素長度來計算。
類似這種測量精度不會很高。

㈡ 西門子plcs7-200SMART SR20怎麼編寫測速程序

編寫方式如下：
要是用的是測速電機的話，得用電壓變換模塊通過AD模塊輸入PLC，得測一下實際轉速和測速電機的電壓對應關系，然後根據測量的電壓計算出電機轉速。如用編碼器，根據編碼器一轉的脈沖數，單位時間內（如1秒做為一個測量周期）測量所得的脈沖數計算出實際每分鍾的轉速。再用比較指令判定輸出即可。

㈢ 試述測量工作的基本程序和原則是什麼，其目的分別是什麼

一、測繪工作的基本程序

(1)、建立施工控制網；

(2)、依據設計圖紙要求進行建（構）築物的放樣；

(3)、每道施工工序完成後，通過測量檢查各部位的實際平面位置及高程是否符合設計要求；

(4)、隨著施工的進展，對一些大型、高層或特殊建（構）築物進行變形觀測，作為鑒定工程質量和驗證工程設計、施工是否合理的依據。

二、原則

施工場地上有各種建築物、構築物，且分布面較廣，往往又是分期分批興建。為了保障建築物、構築物的平面位置和高程都能滿足設計精度要求，相互連成統一的整體，施工測量和地形圖測繪一樣也必須遵循測繪工作的基本原則。

測繪工作的基本原則是：在整體布局上「從整體到局部」；在步驟上「先控制後碎步」；在精度上「從高級到低級」。即首先在施工工地上建立統一的平面控制網和高程式控制制網。然後，以控制網為基礎測設出每個建築物、構築物的細部位置。

另外，施工測量的檢校也是非常重要的，如果測設出現錯誤，將會直接造成經濟損失。測設過程中要按照「步步檢校」的原則，對各種測設數據和外業測設結果進行校核。

三、目的

是直接為工程施工服務的，它既是施工的先導，又貫穿於整個施工過程。從場地平整、建（構）築物定位、基礎施工，到牆體施工、建（構）築物構件安裝等工序，都需要進行施工測量，才能使建（構）築物各部分的尺寸、位置符合設計要求。

(3)量測程序如何編寫擴展閱讀

施工測量注意事項：

1、正確讀出刻度尺的零刻度、最小刻度(最小分度值）、測量范圍（量程）；

2、把刻度尺的刻度盡可能與被測物體接近，不能歪斜；

3、讀數時，視線應垂直於被測物體與刻度尺；

4、讀出最小刻度以上各位數字；

5、記錄的測量數據，包括准確值、估計值以及單位（沒有單位的數值是毫無意義的）

對於精密測量，要注意：

6、要考慮測量溫度及濕度對測量結果的影響，量具和被測工件應盡可能放在同一環境溫度中，1m以下不少於1.5h，1～3m的為3h，超過3m時應在4h以上。

7、要減小視力引起的誤差。一般常用多次測量求平均值的辦法減小誤差。

㈣ 測試怎麼做

最近，很多小夥伴正在面試新工作做准備。所以我整理一下軟體測試的基本工作流程和一些測試用例編寫方法。大致內容如下，希望這些內容對大家有幫助。

首先，作為測試人員需了解業務，分析需求點

為什麼測試人員要參加需求分析？也就是進行測試需求分析的目的是什麼？

第一、把用戶需求轉化為功能需求

1）對測試范圍進度量

2）對處理分支進行度量

3）對需求業務的場景進行度量

4）明確其功能對應的輸入、處理和輸出

5）把隱式需求轉變為明確

第二、明確測試活動的五個要素

測試需求是什麼、決定怎麼測試、明確測試時間、確定測試人員、確定測試環境、測試中需要的技能，工具以及相應的背景知識，測試過程中可能遇到的風險等等。測試需求需要做到盡可能的詳細明確，以避免測試遺漏和誤解。

那麼，接下來怎麼進行測試需求分析？

1）確認功能

（業務功能、輔助功能、數據約束、易用性需求、編輯約束、參數需求、許可權需求、性能約束）

1、業務功能：與用戶實際業務直接相關的功能或者細節；

2、輔助功能：輔助完成業務功能的一些功能或者細節，例如：設置過濾條件；

3、數據約束：功能的細節，主要是用於控制在執行功能時，數據的顯示範圍，數據之間的關系等；

4、易用性需求：功能的細節，產品中必須提供，便於功能操作使用的一些細節，例如：快捷鍵等；

5、編輯約束：功能的細節，在功能執行時，對輸入數據項目的一些約束條件，例如：只能輸入數字等；

6、參數需求：功能的細節，在功能執行時，需要根據參數設置不同，進行不同處理的細節；

7、許可權需求：功能的細節，在功能執行的過程，根據不同的許可權進行不同的處理，不包括直接限制某個功能的許可權；

8、性能約束：功能的細節，執行功能時，必須滿足的性能需求；

2）場景分析

1、考慮場景的調用者：考慮每一個場景提供的服務是供哪些外部模塊或者系統調用的，找出所有調用者。調用前提，約束都要考慮。每一個調用都可以考慮成一個大的業務流程（一般和外部有交互的業務出錯率比較大，需要重點關注）。

2、考慮系統內部各個場景之間的聯系：形成內部業務流程，需要分析每個場景之間的約束關系，執行條件，組織出各種業務流程圖。

3）挖掘隱性需求

這需要測試工程師的經驗積累：

1）常用的或者規定的業務流程

2）各個業務流程分支的遍歷

3）明確規定不可使用的業務流程

4）沒有明確規定但是應該不可使用的業務流程

5）其他異常或者不符合規定的操作

接下來，一起說說測試用例設計那點事兒

1、如何進行測試用例的設計？

編寫測試用例之前，我們需要對項目的需求有清晰的了解，對要測試什麼，按照什麼順序測試，覆蓋哪些需求做到心中有數，作為測試用例的編寫者不僅了解要有常見的測試用例編寫方法，同時需要了解被測軟體的設計、功能規格說明、用戶使用場景以及程序/模塊的結構。

步驟

1）測試需求分析：從項目部拿到軟體的需求規格說明書後，開始對項目的需求進行分析，通過自己的分析、理解，整理成為測試需求， 清楚分析出被測試對象具有哪些功能。明確測試用例中的測試集用例與需求的關系，即一個或多個測試用例集對應一個測試需求。

2）業務流程分析：分析完需求後，明確每一個功能的業務處理流程，不同的功能點做業務的組合，以及項目的隱式需求。如遇復雜的測試用例設計前，先畫出軟體的業務流程。從業務流程上，應得到以下信息：

A、主流程是什麼?

B、條件備選流程是什麼?

C、數據流向是什麼?

D、關鍵的判斷條件是什麼?

3）測試用例設計：

完成以上兩步則可進行測試用例設計，功能測試用例，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。設計測試用例的常見方法：

等價類 → 邊界值 → 因果圖 → 判定表 → 狀態遷移 → 正交實驗 → 場景法 → 錯誤推斷（注意：編寫測試用例時，我們盡可能取的不應該是有效等價類而應該是無效等價類）

4）編寫完成後自我檢查以及部門內部評審：

①測試用例本身的描述是否清晰，語言准確；是否存在歧義性；

②測試用例內容是否完整，是否清晰的包含輸入和預期輸出的結果；測試步驟是否清晰；

③測試用例中使用的測試數據是否恰當，准確；

④測試用例是否具有指導性，是否能靈活的指導軟體測試工程師通過測試用例發現更多的缺陷，而不是限制他們的思維；

⑤是否考慮到測試用例執行的效率。對於不斷重復執行的步驟，是否保證了驗證點相同；或者測試用例的設計是否存在冗餘性等。這些都可能導致測試用例執行效率低下；

⑦畫出軟體需求跟蹤矩陣，驗證測試用例是否完全覆蓋了需求，驗證測試用例的覆蓋性；

⑧測試用例是否完全遵守了軟體需求的規定。這一點其實有一些難做到。考慮到時間/成本的關系，應該視具體情況而定。

5）測試用例更新完善：

測試用例編寫完成之後需要不斷完善，如遇需求更改或功能新增時，測試用例必須配套修改更新，同時在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善;在軟體交付使用後客戶反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。

緊接著，測試用例執行的過程

首先搭建測試環境，准備好測試數據，進行預測，預測通過之後，按照測試用例進入正式測試，有效的測試執行可以將測試用例發揮最大的價值。因此，測試用例規范執行有助於更好的發現代碼中存在的缺陷。根據個人測試工作經驗，好的測試執行應該包含如下內容：

①測試執行中評估測試執行時間不足，需及時上報風險。滿足質量優先，進度其次原則。

②測試用例按優先順序順序執行，通常是基本、詳細和異常順序執行。

③未執行用例、標志為刪除或者無效的用例，需註明原因。

④執行過程中有疑問的測試用例（場景、操作步驟、檢查點等）需找測試設計人員澄清。

⑤測試執行需對用例描述的檢查點逐一檢查，避免遺漏。

⑥重視不易重現的缺陷場景，可能是一個bug。

⑦執行過程中發現有前期設計遺漏用例需補充到用例文檔並執行驗證。

⑧建議測試人員交叉執行重復測試用例，用例執行對相同測試人員有免疫性。避免可能的缺陷一直遺漏到現在。如有需要，建議保留測試結果，結果可視。以便於不同版本間的測試結果對比。已確認問題需及時按照問題單提單要求（規范和缺陷定級）提單。

⑨跟蹤問題單修復情況並回歸驗證問題單。每輪次測試結束，find一下是否有core文件產生。測試結束，將最終測試用例文檔上傳到歸檔目錄，實現用例重用。

以上是針對一般的軟體測試流程，如果是自動化測試的話，應該還有根據測試用例進行腳本編寫，運行腳本等。此處可能寫的不詳細，希望大家可以在下方評論讓我完善。

最後已達到准確要求的，根據測試情況寫測試報告，對整個測試過程和版本的質量做一個評估。

測試報告是指把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。測試報告是測試階段最後的文檔產出物。優秀的測試經理或測試人員應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。

㈤ 如何用canape編寫測試程序

CANape

ECU測量、標定和診斷的綜合工具
CANape為開發者提供了一種可用於ECU開發、標定、診斷和測量數據採集的綜合性工具。
特點和優勢

CANape主要用於電控單元（ECU）的參數優化（標定）。它在系統運行期間同時標定參數值和採集測量信號。CANape與ECU的物理介面可以是使用CCP（CAN標定協議）的CAN匯流排，或者是使用XCP協議的FlexRay實現。另外，通過集成的診斷功能集（Diagnostic Feature Set），CANape提供了對診斷數據和診斷服務的符號化訪問。這樣，它就為用戶提供了完整的診斷測試儀功能。CANape使用標准協議的特性使其成為了覆蓋ECU開發所有階段的一種開放而靈活的平台。
功能

CANape的基本功能包括：
同步地實時採集和顯示ECU內部信號（通過CCP/XCP），CAN、LIN、FlexRay匯流排信號以及來自外部測量設備的信號
通過CCP/XCP進行在線標定和通過XCP進行實時激勵（Stimulation）
離線標定
快速而安全地使用二進制文件和參數組刷寫Flash（Flash編程）
無縫集成KWP2000和UDS診斷函數
強大的標定數據管理、參數組比較和合並功能
在測量、離線分析或旁通（bypassing）過程中使用集成的MATLAB/Simulink模型進行計算
ASAM MCD3 測量和標定自動化介面
與ECU測量數據一起同步採集視頻、 音頻、GPS和外部測量設備的環境數據
使用集成的編程語言自動執行用戶輸入序列和處理測量值與信號

㈥ 測試流程規范

1.概述

1.1目的 2

1.2適用范圍 2

1.3執行原則. 2

1.4角色和職責 2

1.4.1 測試leader 2

1.4.2 測試工程師 3

2.軟體測試流程 3

2.1軟體測試流程圖 3

2.2 流程圖解析 4

3.軟體測試周期人員活動 7

3.1軟體測試准備 7

3.2 測試執行階段 8

3.2.1軟體執行階段流程圖 8

3.2.2軟體測試執行階段人員活動 9

3.2.3測試掃尾工作 11

4.結語 12

 

 1.概述

1.1目的

1、有效的保證軟體質量；

2、有效的制定不同測試類型（軟體系統測試、主觀性測試、專項測試、（自動化測試）、性能測試、用戶體驗測試）的軟體測試計劃；

3、按照計劃進行測試，發現軟體中存在的問題；

4、對軟體中已經解決的問題進行有效的驗證;

5、判定測試過程和問題驗證的有效性。

1.2適用范圍

適用范圍是參與產品軟體測試的各測試工程師。

1.3執行原則.

1、標准化作業，尊重事實；

2、測試工程師需要對產品各項功能持有疑問的態度來思考軟體；

3、測試工程師需要主動與項目組的所有成員保持有效的溝通，以便更好地完成測試任務；

4、盡早發現問題，及時跟蹤問題；

1.4角色和職責

1.4.1 測試leader

負責審核測試計劃,參與計劃的實施過程，確保計劃的實施和按計劃完成測試任務；

制定、更新和維護軟體測試流程；

對發現的部門需要改進的問題提供解決方案；

制定短期、長期的改進措施；進行評審和監督；

參與版本風險評估

參與軟體需求與UI評審

編制STP（軟體測試計劃），組建測試團隊

根據軟體測試申請單的要求判定是否接受軟體測試版本；達到軟體測試標准安排系統測試；對測試需求進行組內培訓。

9.測試任務的分配，保證測試計劃的按時完成，保障軟體測試質量；測試過程進行跟蹤；處理異常情況；定期發送測試報告（每一個升級版本）到開發、PM各管理人員

10.跟進BUG的修改情況，組織BUG評審

11.組織版本風險評估

1.4.2 測試工程師

按照測試計劃進行測試的執行,測試用例在編寫、評審。

測試記錄的整理，

Bug的跟蹤【包括：提交、驗證、關閉Bug】。

參與BUG的評審

定時完成學習計劃並提交學習報告給測試leader

2. 軟體測試流程

2.1軟體測試流程圖

2.2 流程圖解析

立項

對於版本，立項的條件只需要滿足：

測試部收到版本立項通知，軟體產品功能需求/設計說明書都已提供到位

版本進度表

當立項條件滿足時，由測試部門經理指定測試，由測試組織立項與後續的測試工作。

需求初審

    測試Leader組織測試進行需求審閱，完成三個任務：一是對文檔進行評審，如對需求有疑問，或者對需求有建議要求要與需求輸出人進行溝通，直到需求定稿；二是確定測試所需配置、資源、樣機、以及需求對應的DEV等；三是確定好軟體測試策略，策略主要包括如下方面：

1.測試依據

   a,軟體需求文檔

b,其他，如參考其他競品等

測試資源

   a,測試人員需求

   b,測試配置需求（需要前期的配置）

   c,測試樣機需求（例如特殊需求需要特殊的手機）

測試策略

a,採取測試方法

b,採取哪些測試工具以及測試管理工具

       c,對測試人員進行培訓等

測試人員安排

    測試Leader根據在需求初審過程中各功能模塊提供的測試人員名單，完成測試人員安排。

需求分析

   安排完畢後，測試Leader組織組員進行需求分析，完成兩項任務：一是進行組內需求培訓，保證所有組員完全理解需求；二是分配測試用例編寫或維護任務，確認測試用例完成日期。

請注意：測試用例完成日期必須在軟體版本發布測試之前。

測試設計

測試設計主要包括測試用例的編寫與評審。由於常規的測試點的用例都已經具備，這里主要針對新的需求。

測試計劃

當所有測試前的准備工作已經完成，測試leader就要根據開發時間表以及測試策略制定一個完整的軟體測試計劃（STP文檔），測試計劃的依據主要是版本開發計劃和測試需求分析結果。

測試執行

測試執行一般分為以下階段：

確認測試→系統測試→驗收測試→產品文檔check，其中每個階段還有回歸測試驗證問題。

     從測試的角度而言，測試執行過程是要考慮量和度的問題，就是指測試的范圍與測試的程度的問題。

從管理的角度而言，在有限的時間內，在人員有限甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來開展測試。當然如下幾個問題也需要考慮：

a, 當測試人員測試的執行不到位、敷衍了事時該如何解決？

b, 測試效率問題，怎樣提高測試效率?

c, 根據版本的不同採取怎麼樣的測試策略，是全面測試、自由測試還是針對模塊的測試

軟體評估

這里評估指軟體經過一輪又一輪測試後，確認軟體無重大問題或者問題很少的情況下，對准備上線的版本進行評估，以確定是否能夠上線。軟體評估會議由PM？組織，評估成員一般由DEV、PM、QA等組成。

測試總結

版本已經上線後，測試可以通過各種方式對整個測試過程進行總結，可以是做的好的方面的經驗，也可以是不足之處以便後續版本避免。

測試維護

      由於測試的不完全性，當軟體正式release後，用戶在使用過程中，難免遇到一些問題，有的甚至是嚴重性的問題，這就需要DEV修改有關問題，修改後需要再次對軟體進行測試、評估、上線。

3.軟體測試周期人員活動 

3.1軟體測試准備

目的

有效的做好測試准備工作，為測試的執行做好前期所需；

按照需求制定好測試策略與測計劃；

進入條件

版本正式啟動

需求文檔已經進行歸檔

輸入

軟體開發計劃、軟體開發時間表、軟體產品功能需求/設計說明書等相關需求文檔。

作業流程及其管理方法

No. 作業過程名 作業內容/管理方法 作業人 輸出

1.立項當立項條件達到，測試leader指定測試組員，測試組員整理相關資料組織立項動作測試leader、測試組員測試計劃

2需求初審測試leader組織需求的初審，邀請測試組員一起對需求進行審讀，確認該版本對應的配置、資源，確認對應的測試策略測試leader、測試組員

3測試安排測試leader根據需求安排測試人員進行需求分析與培訓，並分配測試用例編寫與維護任務

4測試設計測試進行TestCase的編寫，然後由測試leader制定測試用例的評審計劃並按照計劃進行評審；（要求開發人員、測試工程師）；測試要將每次Case的評審結果進行記錄，測試leader在使用Case前進行評審結果的確認；

測試leader確認最終的Testcase和評審記錄。

測試leader、測試組員測試用例

Case編寫的依據：

軟體需求文檔；相關規范和標准；

Case 編寫基本規則；

1. 以相關需求文檔為編寫依據；

2. 使用條件和路徑覆蓋法判定Case的覆蓋率；

3. Case的易理解和易操作性；

4. 針對不同測試目的編寫測試用例；

5. 根據不同的測試類型編寫測試用例（界面一致性、功能符合性、兼容性、性能穩定性）

5.測試計劃編寫和評審當測試用例完成後需要組織開發、PM等相關人員進行評審；

當計劃定稿後，測試leader需要嚴格按照制定的計劃安排測試；

測試leader

測試計劃評審注意事項：

1. 保證測試計劃要符合開發計劃

2. 測試的全面性；

輸出

測試用例

3.2 測試執行階段

3.2.1軟體執行階段流程圖

流程圖解析

     1．根據整個軟體測試執行過程，按時間分成三等分，分別為T1：測試初期、T2：測試中期、T3：測試後期

T1：測試初期這個階段，主要執行確認測試、基本功能的測試。確認測試的目標需要確保軟體完全符合設計文檔。基本功能的測試的重點是執行測試用例，盡可能多的去暴露基本功能的問題，測試的執行方式以執行測試用例為主。

T2：測試中期採用自由測試為主，除了測試基本功能外，還需要重點測試性能、用戶體驗性測試、兼容性測試。其中性能測試可藉助於Perfdog工具進行測試。

T3：測試後期階段，這個階段仍然需要執行多遍測試用例以確保基本功能的實現完全沒有問題。

系統測試分為三個階段，並不是單純的時間三等分，而是每個時間段都需要達到測試目標。若沒有達到測試目標，測試leader需要及時調節計劃，並組織分析問題，避免因為測試不到位的原因導致版本延期。

3.2.2軟體測試執行階段人員活動

目的

有效的制定系統測試的軟體測試計劃；

按照計劃進行測試，發現軟體中的存在的問題（包括：界面、需求、功能、兼容性、性能等方面問題）。

對軟體中已經解決的問題進行有效的驗證;

判定測試過程和問題驗證的有效性；

進入條件

完成測試計劃和測試用例;

已確認軟體測試申請、軟體版本

輸入

軟體測試計劃和軟體測試用例。

軟體版本；

作業流程及其管理方法

NO 作業過程名 作業內容 / 管理方法 作業人 輸出結果

1測試任務安排測試leader獲得軟體版本後，確認後根據測試目的制定版本測試計劃；

測試計劃完成後，向組內成員介紹版本基本情況、測試時間安排等 

測試leader每個新版本軟體測試計劃

2系統測試測試接收到軟體測試申請並確認版本在發布時已提供相關信息後，安排測試依據測試用例進行系統測試或進行自由測試；

在測試階段，版本的第一輪和最後一輪測試必須至少執行一個完整的周期。包括過一遍完整的case；

測試leader

組員

測試報告

3驗證測試每個版本對以前已修改的BUG進行驗證，若確認已經修改，可執行關閉操作。組員

4性能測試測試leader安排組員，按照《性能測試用例》進行測試，主要採用與對比機對比測試得出內存峰值結果；組員內存峰值測試報告

6兼容性測試測試PM安排工程師，按照《兼容性測試用例》進行對不同型號不同系統版本進行驗證測試組員兼容性測試報告

 

輸出

每個新版本軟體測試計劃、測試報告、內存峰值測試報告、兼容性測試報告

3.2.3測試掃尾工作

目的

根據測試結果，組織版本評估

做好測試總結，積累好的經驗，去除不好的東西

進入條件

完成了測試執行階段，PM申請上線

作業流程及其管理方法

NO 作業過程名 作業內容 / 管理方法 作業人 輸出結果

1版本評估上線前，測試leader書寫軟體測試報告並組織版本評估會議，邀請開發leader、項目經理等管理人員組織版本評估會議，最終由項目經理確認軟體是否能夠上線。項目經理（PM）

測試leader

測試組員

軟體開發leader等

評估結果

2測試總結測試leader組織測試進行總結性會議，總結測試經驗測試leader

測試組員

3維護測試當收到用戶反饋的嚴重性問題，測試leader組織測試驗證並提交問題到JIRA跟蹤；

開發人員重新集成版本修改問題，測試leader驗證後並組織一次全面的測試確保版本

測試leader

測試組員

測試報告

 

 

4.結語

      軟體測試是程序的一種執行過程，目的是盡可能發現並改正被測試軟體中的錯誤，提高軟體的可靠性。它是軟體生命周期中一項非常重要且非常復雜的工作，對軟體可靠性保證具有極其重要的意義。測試流程制定的總目標是充分利用有限的人力和物力資源，高效率、高質量地完成軟體測試任務。避免不足的測試使軟體帶著一些未揭露的隱藏錯誤投入運行，這將意味著更大的危險讓用戶承擔。然而一個規范實用的流程，往往可以改善軟體測試的效率。流程的制定為測試計劃的制定、測試過程的執行提供了文檔性的幫助。讓每一個測試很清晰的明白，軟體測試周期中每個時段該去怎麼做。

     該流程的制定不是一成不變，在執行過程中若發現有不足之處，我們將更新此文檔，直到完全適用於我們的項目流程。