カテゴリー: 技術情報

今回の「動的テストの自動化を考える」は、前回の「番外編」に続く「番外編 第二弾」として、先日パシフィコ横浜で開催されたET2018で展示を行った「DT-ACE」の新しいデモ環境をご紹介したいと思います。この「DT-ACE」の新しいデモ環境では、テスト対象となる組込み機器を専用ハードウェアを使用して直接I/Oレベルで「駆動」させて自動テストを行うことができます。

最近、種類の異なる複数の信号を同時にキャプチャしてPCに転送してデータを可視化する案件が増えて来ています。入力する信号のチャンネル数や帯域が増えれば増えるほど、それに比例するようにデータ量も増え、PCへの転送方式もより高速なものが望まれます。その転送レートは現行のDynamic Tracerの転送レートを優に超えています。図らずとも、次世代Dynamic Tracerへ向けての検討は進んでいる!?ということになるのかもしれません・・・

今回は「パイプライン」です。Jenkins2.0から標準で使えるようになったとはいえ、この「パイプライン」のメリットは何でしょうか？概して「Pipeline as Code」にメリットを感じている方が多いようです。自動化の潮流でCI/CDが当たり前となった昨今、CI/CDを構築する手順も複雑になり、あるスクリプトに修正を加えたら今まで動いていたものが動かなくなった、といったケースも増えてきているのではないでしょうか。

以前、DT10のオプションである「Multi Tracer」が誕生するまでの経緯を記事にした「Multi-Tracer 開発エピソード」を掲載いたしました。しばらく間が空いてしまいましたが、今回はその続編というかたちで、同じくDT10のハードウェアのオプションである「GPIO NoiseIsolator」をフォーカスしていきたいと思います。また、今さらながら、なぜ「GPIO NoiseIsolator」を改めて紹介するに至ったかの理由も併せてご紹介したいと思います。

今回は、同じWindows環境で複数スレッドを対象としたときの最速の「ファイル書き出し」の手法は何かを検証してみてみたいと思います。特に、複数スレッドを対象するときは、情報を書き出すファイルもしくはリソースに対して複数のスレッドからの同時アクセスが発生します。このため、各スレッドのアクセス権限の調停をはかるため「排他処理」が必須になります。

第6回では、第5回で設計したJenkinsのJobを実際に動かして行きたいと思います。Jenkinsは2.0のバージョンから「パイプライン」機能が標準で使用できるようになっています。せっかくですので、この「パイプライン」機能を使いたいところですが、また違う設計が必要になりますので今回は「パイプライン」は使わずに「フリースタイル」でJobを実行して行きます。

比較的オーバーヘッドが小さく、導入時の手間が掛からないため、Linux機器を開発しているユーザー様は、特に「ファイル書き出し」接続をDT10で使用するユーザー様が多いです。
今回は、Linuxのアプリケーションをターゲットとして、「ファイル書き出し」接続におけるオーバーヘッドの削減について検証します。

先日、ビッグサイトで開催されましたESEC(第21回 組込みシステム開発技術展)で、「動的テストの自動化」の一環として、組込み機器の動的テストを自動で行うためのソリューションの展示を行いました。組込み機器のテストを自動で行うためのツールとの連携を強めたソリューションとなります。今回は、このテスト自動化ソリューションを少しだけご紹介します。

DT10の「ファイル書き出し」方式は、オーバーヘッドが小さく、ハードウェアによる接続も無く、ドライバの合わせ込みも無く、気軽に直ぐに導入できることを理由に、カバレッジ計測において活用されています。データの取り扱いを工夫することで、さらなるオーバーヘッドの削減ができないものか考えました。今回は、Windowsアプリをターゲットにして検証します。

第5回は、JenkinsのJobがテーマです。動的テストをJenkinsから行うためには、動的テストに関する一連の作業内容をJobとして登録しておく必要があります。具体的には、DTシリーズ製品特有のテストポイント挿入から、動的テストの結果の集計までの一連の作業を行うためのコマンドをJob内に記述していくことになります。そこで、このJenkinsのJobを設計する上で押さえておくべきポイントについて考えて行きたいと思います。