ASKUEモジュールの開発とテスト

ASKUE-エネルギー資源の監視と会計のための自動システム。 このようなシステムのタスクには、エネルギー計測デバイス（ガス、水、暖房、電気）からデータを収集し、分析と制御に便利な形式でこれらのデータを提供することが含まれます。



そのようなシステムは多くの異なるデバイスとコントローラーを処理することを余儀なくされるため、ほとんどの場合、それらはモジュールベースで構築されます。 少し前まで、計量デバイスの1つと通信するシステム用のモジュールを作成するように依頼されました（三相電子エネルギーメーター2753 ）。

ナレーションの過程で、コメントがこのように強調表示されます。 彼らの唯一の目標は、記事を知る過程で眠らないことです。

私は長い間自動テストを適用したいと考えていました。 今は良い機会だと思いました。 なぜそう決めたのですか？

テストを試すのにこのケースが便利なのはなぜですか？

• モジュールにはユーザーインターフェイスがありませんでした。厳密に定義されたAPIのみで、テストに非常に便利です。
• プロジェクトの日程はそれほど厳しくなかったので、実験する時間がありました。
• ASKUEシステムは産業システムのクラスに属し、過剰な信頼性はそれを妨げません。

自動テストに賭けることで、実際に書く必要があるコードの量を2倍にしました。 今後は、デバイスエミュレータを作成する必要がありました。 しかし、最終的には価値があったと思います。

興味深い結果の1つは、生きているデバイスなしで開発を行うことができたということです-手元にそのプロトコルの説明だけがあります。 もちろん、生きているデバイスが登場しましたが、コードの大部分が作成された後です。

開発はDelphi 7の環境で実行されました。自動化されたテストでは、DUnitライブラリが使用されました。 バージョン管理システム-Mercurial。 リポジトリ-BitBucket。

システム内のモジュールの場所に関するもう少しの情報

モジュールの主なタスクは、低レベルのプロトコルに従ってメーターと通信し、この通信の結果をASKUEシステムが理解できる形式で提供することです。 物理通信チャネルは、原則として、その機能を拡張するさまざまな種類のデバイス（モデム、インターフェイスコンバーター）を備えたCOMポートです。 非常に一般的なRS-232 / RS-485の束。 時々TCP / IPが可能です。 通信チャネルの編成のニュアンスについては、特別なASKUEモジュール（チャネルドライバ）が責任を負います。



プロトコル自体に関しては、一般的に言えば、一連のバイト形式のリクエストとレスポンスのシーケンスです。 ほとんどの場合、要求と応答の後にチェックサムが続きます。 もっと具体的なことを言うのは難しいです。 この通信方法の最も特徴的な代表はMODBUS仕様です。

MODBUSプロトコルは、灰色の人と退屈な人の運命です。 あなたが明るく創造的な人であれば、もちろん、あなたは信頼できる実証済みのソリューションを使用せず、それとはまったく異なる独自のバージョンのプロトコルを考え出してください。 そして、この場合、マーケティング部門は、デバイスがMODBUSのようなプロトコルを使用して通信することをデバイスの将来の購入者を怖がらせないように、広告パンフレットに慎重に書き込みます。 もちろん-MODBUSとの互換性についての話はありません。

モジュールの内部構造

モジュールの内部構造を示します。これは、開発とリファクタリングを数回繰り返した結果判明しました。 あなたはそれが非常にオリジナルではないことに気付くかもしれません。



メインのDeviceオブジェクトには、デバイスでの一般的なアクションと、ASKUEデータを必要な形式で返すためのコードが含まれています。







Deviceオブジェクトは、複数のOnlinerオブジェクトを所有しています。 各Onlinerは、デバイスとの完全に完了した通信セッションを担当します。 さまざまなタイプのオンラインユーザーが、デバイスのさまざまな典型的な操作を担当します。 最も一般的なのは、パラメーターのグループのポーリングです。 私のデバイスの場合、パラメーターの6つのグループがあり、それぞれに独自のOnlinerがありました。



Onlinerは、作業でQueryオブジェクトを使用します。 Queryオブジェクトは、単一の要求応答サイクルを担当します。 Queryオブジェクト操作の結果は、デバイスから受信した特定の情報であり、使いやすい形式に縮小されます。 さらに、Queryオブジェクトは、不正で壊れた機器の応答を認識し、必要に応じてクエリを繰り返します。 このロジックはクエリレベルでは非表示であり、Onlinerはこれについて心配していません。



最下位レベルはStructオブジェクトです。 さまざまな低レベルのバイト形式をプログラミング言語で使用される値に変換する責任があります。 バイトストリームがStructオブジェクトの入力に送られます-出力では、Integer、Float、String型の値。 時々（ほぼ常に）、Structオブジェクトは重要なことをしなければなりません。 したがって、Structレベルでは、データのシリアル化と逆シリアル化の数学的な作業がすべてカプセル化されます。 彼はこのハードワークのすべてのニュアンスをより高いレベルから隠しています。



CrcProcessorオブジェクトも図で強調表示されています。 その名前によれば、チェックサムの計算を担当します。 ケースは、一見すると思われるほど単純ではありません。



以下では、データ変換（Struct）とチェックサム計算（CrcProcessor）についてもう少し詳しく説明します。トピックは興味深いものであり、話すべきことがあるからです。

計量デバイスのデータ形式

メータリングデバイスの要求と回答にない情報をエンコードする方法を指定することは困難です。



最も無害なのはタイプ全体です。 すべてのタイプのアドレス、ポインター、カウンターは、1つのタイプ全体としてエンコードされます。ターゲットパラメーターは整数タイプの場合もあります。 特定の整数型は、バイト長と、これらのバイトがチャネルを介して送信される順序が異なります。

数学、またはむしろ慎重に開発されたセクション-組み合わせ論は、オブジェクトの順列の数に厳密な制限を設定します（n！）。 たとえば、3バイトは6通りの順序で配置できます。 この克服できない（量子コンピューティングに頼らない場合）理論的限界は、計量デバイスのプロトコルの作成者をひどく混乱させます。 3バイトを20通りの方法で送信できた場合、遅かれ早かれそれぞれのバイトに遭遇すると思います。

私の意見では、固定点を持つタイプは、計測デバイスで最も成功しています。 この考え方は、小数点を左に数桁シフトする必要があるという条件で、チャネルを介して整数値を送信することです。 さまざまな変換の下で正しく動作する非常に優れたタイプ。 銀行コンピューティングの標準として使用されるほど良い。 （VisualBasicに通貨型があることを誰かが知っている場合-それはちょうどそのように構成されています）。

基本的な型はそのままなので、リラックスして組み合わせ論やバイト順序を忘れることはできません。

もちろん、すべての点で、多くの問題は浮動小数点型です。 レシピは1つしかありません-それが何を意味するのか、それがどこにあるのか、どのようなオプションがあるのか​​を完全に理解するためです。 そして再び-バイトオーダーについて覚えておいてください。

浮動小数点型が、プラットフォームの標準型の1つと内部表現で偶然に一致することを期待することが、障害の高さです。 そのような考えがあなたを訪ねるなら、あなたはプログラミングをするべきではありませんが、リスクの少ないクラフト-ルーレットをプレイする、宝くじを買う、ワールドカップに賭けるべきです。

最も興味深いオプションは、通信チャネルでタイムスタンプを送信しようとするときに発生します。 日付と時刻のさまざまな部分は、最も任意の形式で送信されます。

年、月、日、時間、分、秒の順序は、すべて同じ理論上の限界（n！）に自信を持って努力しています。 あなたはまだその年についていくつかの言葉を言うことができます。 2000年の問題は誰にも何も教えなかったため、ほとんどの場合、年は2桁で送信されます。

多くの場合、プロトコルを介して送信されるバイトストリームは、さまざまなマイクロ回路（タイマー、ADC、ポート、レジスタ）の内部メモリの直接ダンプです。

マイクロチップを作成する人は、各ビットの注意深い使用について多くを知っています。 したがって、個々のビットとビットのセットを任意の場所からカットアンドペーストし、接着し、マスクを適用し、さまざまな方向にシフトし、実際のプログラマーの仕事が一連の顔のない日になるような多くのことを行う必要があるという事実に備えてください互いの上に。

ほとんどの形式に注意しましたが、これはすべての微妙な点からはほど遠いです。 最も予期せぬ瞬間に、プロトコルによる通信をまったく新しいレベルに引き上げる特別な手法を適用できます。 たとえば、BCD（バイナリ10進形式）などのエキゾチックなものや、ASCII文字による数値の送信を適用できます。 同じ値の部分が異なる要求で送信される場合があります（たとえば、値の全体を取得するには、デバイスに1つの要求を送信し、部分的な要求を取得する必要があります）。

私が会ったことのない唯一のことは、国別文字のUTF形式での送信です。 しかし、それは善意の問題ではないと思いますが、UTFでの作業はリソース集約型のビジネスであり、マイクロコントローラーのリソースは限られているという事実です。

上記のすべてが、数百のデバイスを使用した私の膨大な経験の結果であると思われる場合、これに反論する必要があります。 これのほとんどすべてはメーターで出会ったので、そのためにモジュールを書きました。 信じられない人のために、私はデバイスにパスポートとプロトコルの説明を送ることができます。 あなたは私が書いたすべてが真実であることがわかります。

チェックサム計算

上で述べたように、チェックサムについても、一見すると思えるほど単純ではありません。 CRC8、CRC16、CRC32という確立された用語があるという事実にもかかわらず、それらはチェックサムがどのように考慮されるべきかを明確に理解していません。 したがって、常に微妙な違いが生じます。 通信プロトコルの作成者自身がこれを知っており、プロトコル記述で標準への参照を示していませんが、チェックサムの計算方法を示すコード（!!!）を通常Cで提供します。



CRC計算を共有ライブラリに入れることはお勧めしません。 アルゴリズムが複数のケースで一致する場合でも、いつかCRCカウントについて完全に気が変になるバリアントに出くわすでしょう。 小さなコピーペーストを行う必要がある場合でも、各デバイスに独自のアルゴリズムを作成することをお勧めします。

私のデバイスの場合、何らかの理由で、CRCをカウントするシーケンスに要求の最初のバイトを含めるべきではありません。 プロトコルの説明にある短いメモに注意を払ったことは、大きな成功だと思います。 そうしないと、デバイスとの接続を確立できなくなるからです。 どうやら、私は間違いのない最初のバイトの証人の活動に出会いました。 別の方法で、これをすべて説明することはできません。

モジュールテストスキーム

モジュールの内部構造とその開発のいくつかの機能について説明しましたが、次にモジュールのテストスキームを紹介します。 このスキームはオブジェクトの構造を繰り返しませんが、情報フローの論理スキームとその検証を反映しています。 これは記事の中で最も重要な数字だと思うので、これについて詳しく説明します。

最初は、これはかなり独創的なスキームであるように思われましたが、それから私の古い研究所の知識から生まれたことに気付きました（情報理論にはいくつかのコースがありました）。

ジェネレーターは参照値を生成して保存し、デバイスの擬似エミュレーターによって受け入れられ、低レベルのプロトコルに変換します。 プロトコルはモジュールによって認識され、参照値はそこから復元されます。 値がテスト環境に返されます（デバイスモジュールの場合は、ASKUEのように見えます）。 次に、テスト環境はモジュールから取得した値を参照値と比較します。 比較に基づいて、モジュールの正常性について結論が出されます。



赤で強調表示されている2つのモジュールは、ストレステストに関連しています。 特に、通信不足、切断、パケット歪みの状況を再現できます。 主なタスクは、デバイスへの繰り返しリクエストのメカニズム、および予期しない状況の場合のメモリの正しい割り当てと解放を確認することです（これはメモリリーク監視ユニットによって監視されます）。

リファレンスジェネレーター

それほど複雑ではありませんが、重要なユニットは参照値ジェネレーターです。 ジェネレーターの本質は、測定されたASKUEパラメーターの値を取得することです。 この値は、一方では変化し、予測不能（良好な分布を持つ）であり、他方では決定論的（つまり、エラーを効率的に検索できるようにするために、テストごとに再現可能）である必要があります。



考えすぎずに、これはある種のハッシュ関数であるべきことが明らかになります。 私自身の自転車モデルで少し実験して、最終的にMd5を台無しにしました。 仕事に関する苦情はありません。 以下はDelphiのコードです。

function TFECoreEmulator.GenNormalValue(const pTag:string):double; var A,B,C,D:longint; begin TFECoreMD5Computer.Compute(A,B,C,D,pTag+FE_CORE_EMULATOR_SECURE_MIX); result:=0; result:=result+Abs(A mod 1000)/1E3; result:=result+Abs(B mod 1000)/1E6; result:=result+Abs(C mod 1000)/1E9; result:=result+Abs(D mod 1000)/1E12; end; function TFECoreEmulator.ModelValueTag(const pGroupNotation, pParamNotation: string; const pStartTime, pFinishTime: TDateTime):string; begin result:=pGroupNotation+'@'+pParamNotation+'@'+DateTimeToStr(pStartTime)+'@'+DateTimeToStr(pFinishTime); end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

単純な変換の結果として、通常の値（0..1）を取得します。これは必要な範囲に到達し、軽いハートでエミュレータに送信します。 いつでも、値は絶対精度で再現できます。

擬似エミュレーターデバイス

擬似エミュレータの主な目的は、デバイスとの通信モジュールからの要求に対する応答を生成することです。 私たちは本当のエミュレーションについて話していないので、彼は「擬似」です（それは恩知らずで役に立たない仕事でしょう）。 彼がしなければならないことは、特定の要求に対する特定の回答を作成することです。 さらに、パラメーター値が必要な場合、彼は参照値のジェネレーターを使用します。



その中に異常なものは何もありません。答えを形成するための特別なスキームにのみ注目します。 最初に思い浮かぶのは、リクエストを解析してレスポンスを生成するための特定の手順（通常はParseという名前）です。 しかし、実際の実装では、この手順は信じられないほどのサイズに成長し、場合によっては、互いに強く埋め込まれています。



だから私は少し違うことをしました。







エミュレータにヘルパーオブジェクトのセットを提供しました—レプリカに名前を付けました。 各レプリカは、他のレプリカとは別にリクエストを解析しようとします。 要求が彼女に適用されないことを理解するとすぐに、彼女は例外をスローし、エミュレータは分析のために要求を次のレプリカに渡します。 したがって、リクエストの各バリアントのコードを個別のオブジェクトにローカライズすることができました。 単一のレプリカが機能していない場合は、デバイスモジュールまたはエミュレーターのいずれかにエラーがあります。



また、Structオブジェクト（構造の情報のエンコードおよびデコード方法を教えた）とCrcProcessorを再利用したこともわかります。 もちろん、これは信頼性の観点から行うべきではありません。 しかし、私はこの妥協を許してくれると思います。

信頼性の観点から、テスト対象のオブジェクトとテストインフラストラクチャで共通のコードを使用しないでください（エラーは相互に補償できるため）。 オブジェクトとそのテストは、一般に異なる人々によって書かれていることが望ましいです。 そして、彼らはお互いについて何も知らないことが望ましく、会議で握手をしないでください。 ご存知のように、私はこのすべてを単独で書きましたが、同様の方法論は利用できませんでした。

ストレス発生器

ストレスジェネレーターは、モジュールとデバイスエミュレーターの間のギャップに含まれています。 彼は次のことができます。

• エミュレーターの応答を完全にブロックする
• 途中で答えを打ち破る
• 応答バイトを歪める

回答が中断された場合、問題が発生しました-回答を中断する場所。 すべてのヘッダーとプリアンブルが送信され、モジュールが実際のデータを待機する場合、最も重要な場所で回答を中断しました。 すべてのヘルパーオブジェクトが既に作成されているはずです。 この場所で送信を中断すると、メモリリークの可能性が最大になります。



ライブデバイスを操作する過程で、非常に興味深いエラーに遭遇しました。デバイスの応答は、チェックサムが一致する場合でも、すべてのルールを正式に満たします。 ただし、データ自体は要求されたものと一致しません。 特にこのケースでは、デバイスの内部エラーと呼ばれる別のモードを導入しました。

長い熟考の末、どうすればこれができるのかというと、デバイスは単にリクエストの整合性を制御しないという結論に達しました。 また、マニュアルに多く記載されているチェックサムは、デバイス自体とは見なされません。 したがって、要求が歪められた場合（たとえば、要求されたメモリのアドレスが変更された場合）、純粋なハートを持つデバイスは正常なフォームを形成しますが、誤った応答をします。

メモリ割り当て制御

正しいメモリ割り当てについてモジュールをテストした方法を少し説明します。 多くのことが明らかであり、誰にも知られていますが、とにかくお話しします。 これのいくつかは興味深いかもしれません。

長い間、プログラマは夜のメモリ割り当てに関連する悪夢を抱えています。 ガベージコレクタを備えたJavaとDotNetの発明により、状況は多少改善されました。 しかし、悪夢はまだ残っていると思います。 それらは単により洗練され洗練されたものになりました。

例外メカニズムに基づいた最新のエラー処理システムは非常に便利です。 しかし、リソースの割り当てと解放のプロセスは非常に複雑です。 これは、例外が発生すると、プロシージャの実行が中断されるためです。 例外は、条件、ループ、ルーチン、およびモジュールの境界を簡単に克服します。 そしてもちろん、プロシージャの最後にリソースを解放するためのコードは、特別な措置が講じられない限り実行されません。



この問題を解決するために、人類の最高の心が投げ出されました。 その結果、try..finallyコンストラクトが発明されました。 この設計は、ガベージコレクタを備えたシステムでも行われます。これは、リソースがメモリだけでなく、たとえば開いているファイルでもある可能性があるためです。



ケースの古典的なアプリケーションスキーム-リソースの場合-オブジェクトは次のようになります。

 myObject:=TVeryUsefulClass.Create; try ... VeryEmergenceProcedure; ... finally myObject.Free; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、私はこの方法がより好きです（コードに関係するすべてのオブジェクトを一度に処理でき、さらに、いつでもどこでもオブジェクトを作成できます）。

 myObject1:=nil; myObject2:=nil; try ... myObject1:=TVeryUsefulClass.Create; ... VeryEmergenceProcedure; ... myObject2:=TVeryUsefulClass.Create; ... VeryVeryEmergenceProcedure; ... finally myObject1.Free; myObject2.Free; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

適切なメモリ管理のレシピは単純です-リソースが割り当てられ、例外が発生する可能性がある場合はいつでも、try..finallyスキームを適用します。 しかし、不注意は簡単に忘れたり、何か間違ったことをしたりします。 したがって、テストすることをお勧めします。



私は次のようにしました。 彼はすべてのオブジェクトの共通の祖先を作成し、作成時にそれらを一般リストに登録し、破棄時にリストから自身を削除しました。 最後に、検出されていないオブジェクトのリストがチェックされます。 このそれほど複雑ではないスキームには、オブジェクトを識別し、コード内でそれが作成された場所を見つけるのに役立ついくつかの要素が追加されています。 このため、オブジェクトには一意のラベルが割り当てられ、作成と削除の瞬間がトレースファイルに表示されます。

 var ObjectCounter:integer; ObjectList:TObjectList; ... TFECoreObject = class (TObject) public ObjectLabel:string; procedure AfterConstruction; override; procedure BeforeDestruction; override; end; ... procedure TFECoreObject.AfterConstruction; begin inc(ObjectCounter); ObjectLabel:=ClassName+'('+IntToStr(ObjectCounter)+')' ObjectList.Add(self); Trace('Create object '+ObjectLabel) end; ... procedure TFECoreObject.BeforeDestruction; begin ObjectList.Delete(self); Trace('Free object '+ObjectLabel) end; ... procedure CheckObjects; var i:integer; begin for i:=0 to ObjectList.Count-1 do Trace('Bad object '+(ObjectList[i] as TFECoreObject).ObjectLabel); end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最も目の肥えた読者は、これがすでにガベージコレクターの初期のメカニズムであると言うでしょう。 もちろん、ガベージコレクターは遠く離れています。 これは良い妥協だと思います。 コードのスローダウンに気づきませんでした。 さらに、作業アセンブリで条件付きコンパイルディレクティブを使用して、このメカニズムを無効にすることができます。

このメカニズムには欠点があります-私の共通の祖先から生成されていないオブジェクトの作成を監視することはできません。 原則として、これらは標準ライブラリオブジェクトTStringList、TObjectListなどです。 オブジェクトのコンストラクターでのみ作成し、デストラクタで破棄するというルールを作成しました。 そして、テストはすでにオブジェクトを監視しています。 すべてを注意深く行うと、エラーの可能性が最小限に抑えられます。



3時間のストレステストのどこかで、重要な場所をすべて特定し、try..finallyを正しい方法で配置しました。

基準精度

コンピューターの時点で、また、対数定規の時点で、信頼できる小数点以下3桁のみを人に小数点以下14桁でダンプするのは悪いと考えられていました。したがって、ASKUEシステムでは、各パラメーターに精度を設定できます。 すべてのパラメーターについて、それは異なり、デバイスとの通信モジュールによって決定されます。 値がどのように形成され、どのような許容精度が保証されるかを知っているのは彼だけです。 主な作業が完了した後、私は実験して、モジュールの最大能力を精度の観点から見つけることにしました。

なぜこれをしているのですか？ おそらくそれはすべて自然の好奇心に関するものです。 目の前で魔法のようなことが起こるのを見ました。 参照値は、これまで見たことのないcなフォーマットにパックされ、魔法の杖の波で、実際に灰から復元されます。 そして、魔法の杖を持っているなら、いつも少し振ってみたい。 好奇心がいつか私を台無しにすると思う。

したがって、値のタイプごとに、許容精度を変更し始めました。 詳細については説明しませんが、1つのケースについてのみ説明します。 私は、精度の限界の感じによれば、テストがまだ十分だったときに、テストが落ち始めたことに気付きました。



少し調べてみたところ、いくつかの場所でTruncを使用して、魂のシンプルさを仕上げました。 Roundに置き換えたところ、限界精度はすぐに1桁向上しました。

友人、数字を丸めるには、もちろんRoundとRoundToを使用する必要があります。 数学的な観点から見ると、Trunc関数はばかげた、不正な変換です。 Truncは、発明された1つの場合にのみ使用する必要があります。整数部分と分数部分の分離です。 他のすべての場合-ラウンド。 それ以外の場合、Vosはマイナーな、場合によってはメジャーなトラブルに直面します。

ライブデバイスへの接続

上で言ったように、作業の大部分が終わったときにこのデバイスに接続しました。 デバイスをRS-485経由で接続する必要があることを知ったので、私はとても幸せでした。 結局のところ、2本のワイヤしかありません。 私の後ろに無線電子機器のパイオニアサークルがあるので、どうにかして2本のワイヤに対処できると思いました。 インターフェイスコンバーターとデバイスを接続しようとしたときに、連絡先の指定を読んだ後、私は長い困惑に陥った写真を見つけました。







正式な論理の観点から、状況に解決策がないことを理解したので、インターネットを調べることにしました。

私は素朴で素朴な人です。 私はそれぞれの新しいプロジェクトを、良さの勝利と標準の不可侵性を信じて開始します。 そして、いつも残酷な失望が私を襲います。 最悪の場合、これは時々繰り返されます。 人生は私に何も教えてくれません。

インターネットでは、Aがマイナスとプラスの両方を接続すると言われていました。 それはすべて製造業者に依存します。 そのような混乱があった場合、間違った接続で、少なくとも何も燃やすべきではないと判断しました。 私はこれを試しました。 すべてがうまくいきました。



もちろん、実際のデバイスはプロジェクトに多くの改善をもたらしました。 実際の通信セッションは、彼らの場所に多くを置きました。 大きな変更は、エラー処理とストレステストに影響を与えました。 特に、ワ​​イヤレスモデム経由でデバイスに接続した場合（ほぼ3分の1の回答が歪んでいました）。

おわりに

ASKUEモジュールの開発とテストに関する私の短い話に興味を持っていただけたことを願っています。 私がテストを検討する最も重要なこと。 製品の品質はそれに直接依存します。 プロジェクトに加えられ、テストで確認されていないすべての変更は、時間と労力の無駄です。 結局のところ、コードのわずかな変更で、テストされていない問題が何度も返されます。



私の仕事はTDD方法論（テストによるテスト駆動開発開発）に触発されました。 しかし、もちろん、純粋なTDDでは成功しませんでした。 ここに私がしなかったことがあります：

• 事前にテストを作成しなかった
• クラスごとにテストを書いていません
• 短いテストを書いていない

プロジェクトで何が起こったのか、モジュラーまたは統合に起因するテストの種類がわかりません。 これはサブシステムの受け入れテストだと思います。

コメントを読んだ後、私が人生について不平を言っていると思わせたくありません。 それどころか、これがまさにプログラミングを世界で最も興味深い活動にしている理由です。 また、計測デバイスの作成者がすべてを心に留めていないことをお願いします。 インターフェイスの反対側では、人生も面白いことを知っています。 私の皮肉はすべて自分自身に向けられています。

皆様に楽しいプログラミングをお祈りします。