ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

単体テストと結合テストのテスト項目の違い

2018-04-16 14:18:45 | Weblog
「単体テストのUI部分のテスト項目と結合テストのテスト項目が一緒になっちゃうんですけど・・」
とかいう話を聞くが、「なぜ一緒になるのか」とか、「どこに違いがあるのか」については、
学校でも、職場でも教えてもらえないような気がする。

ので、単体テスト項目と、結合テスト項目を書いて説明してみる。

そうすると、これは、「テスト項目合成の話」ということが分かると思う。




■お題

・以下のWebシステムの単体・結合テスト項目を考える

  画面Aは、表示後、項目a,bを入力し、ボタンAをクリックすると、
  サーバーのサービス1とサービス2にアクセスし、
    サービス1,2が正常終了すると、画面Bを表示する
    サービス1,2ともに正常終了しないと、エラーメッセージを表示する

 サービス1は、DB1を検索し、項目a,bのレコードが存在すればOK、ない・異常時 エラー
 サービス2は、DB2に項目a,b,現在時刻cをキーとするレコードを生成できればOK、異常時 エラー

(例:画面A:ログイン画面、a=ユーザー名、b=パスワード、ボタンA=ログイン、
   画面B:メニュー、サービス1:ログインチェック、サービス2:ログイン初期化
   DB1=ユーザーテーブル DB2=セッションテーブル)




■単体テスト【C0,C1,100%】

・画面のポイント

 画面Aの単体テスト
   画面Aがa,bからで表示されるときを平常状態、
   イベントが上がったら、(平常状態からの)分岐と考える。

   各項目の入力チェックは、
     チェック自体は別関数をつかわず(C0項目にはならない)
     結果はOK,NGのみ→C1項目

   ボタンAクリック後、
     入力チェック
     サービス1実行
     サービス2実行
   となる(C1)。各ステップで、OK、NGの2種類がある。

・サーバー側(サービス)について

   マイクロサービス化されていて、
   サービス1、2とも、正常、異常の分岐しかないとする→C1項目

「テストでのC0、C1、C2に対応した仕様書の書き方」って、学校で教えないよね
https://blog.goo.ne.jp/xmldtp/e/55d32a4a623e92481567a9b477521556


に書いた感じで、合成した状態で書いてみる


   テスト項目1
      テスト観点:画面A表示(C0 & C1正常)
      テスト条件:特になし(初期状態)
      テスト内容:画面Aが表示されている

   テスト項目2
      テスト観点:画面A 項目a入力(フォーカス喪失イベント) :正常(C1)
      テスト条件:画面A表示
      テスト内容:項目aに適切な値を入力、タブを入力

   テスト項目3
      テスト観点:画面A 項目a入力(フォーカス喪失イベント) :異常(C1)
      テスト条件:画面A表示
      テスト内容:項目aになにも入力しないで、タブを入力

   →項目aの字種チェック(不適切な値入力)等は、ここにテスト項目が追加されるが、今回はその話題
    ではないので省略

   テスト項目4
      テスト観点:画面A 項目b入力(フォーカス喪失イベント) :正常(C1)
      テスト条件:画面A表示
      テスト内容:項目bに適切な値を入力、タブを入力

   テスト項目5
      テスト観点:画面A 項目b入力(フォーカス喪失イベント) :異常系(C1)
      テスト条件:画面A表示
      テスト内容:項目bになにも入力しないで、タブを入力

   →項目bの字種チェック(不適切な値入力)等は、ここにテスト項目が追加されるが、今回はその話題
    ではないので省略

   テスト項目7
      テスト観点:画面A ボタンA(クリックイベント)(c0) &入力チェック正常(C1)
      テスト条件:画面A表示、項目a,bに適切な値を入力
      テスト内容:ボタンAをクリックして、入力チェックを行う
      予測結果:サービス1を呼び出す(ログ確認)

   ※ここは合成したけど、合成しないほうがふつうかなあ~

   テスト項目8
      テスト観点:画面A ボタンA(クリックイベント) :入力チェック異常(C1)
      テスト条件:画面A表示、項目a,bに「不適切」な値を入力(または入力しない)
      テスト内容:ボタンAをクリックして、入力チェックを行う
      予測結果:エラー表示           
 

   テスト項目9
      テスト観点:画面A ボタンA(クリックイベント):サービス1正常(C1)
      テスト条件:画面A表示項目a,bに適切な値を入力し、ボタンAをクリックして、入力チェック正常で通過
            (スタブ利用する場合、サービス1に正常値がかえるように設定)
      テスト内容:サービス1を呼び出す
      予測結果:サービス2を呼び出す(ログ確認)


   テスト項目10
      テスト観点:画面A ボタンA(クリックイベント):サービス1異常(C1)
      テスト条件:画面A表示項目a,bに適切な値を入力し、ボタンAをクリックして、入力チェック正常で通過
            (スタブ利用する場合、サービス1に異常値がかえるように設定)
      テスト内容:サービス1を呼び出す
      予測結果:エラー表示


   テスト項目11
      テスト観点:画面A ボタンA(クリックイベント):サービス2正常(C1)
      テスト条件:画面A表示項目a,bに適切な値を入力、ボタンAクリック、入力チェック・サービス1正常で通過
            (スタブ利用する場合、サービス2に正常値がかえるように設定)
      テスト内容:サービス2を呼び出す
      予測結果:画面B表示

   テスト項目12
      テスト観点:画面A ボタンA(クリックイベント):サービス2異常(C1)
      テスト条件:画面A表示項目a,bに適切な値を入力、ボタンAクリック、入力チェック・サービス1正常で通過
            (スタブ利用する場合、サービス2に異常値がかえるように設定)
      テスト内容:サービス2を呼び出す
      予測結果:エラー表示

※画面Bの話は、今回は関係ないので省略

サービス1の単体項目は、101から採番することにします。

   テスト項目101
      テスト観点:正常(C1)
      テスト条件:特になし
      テスト内容:適切なパラメータを設定して、サービス1を実行する
      予測結果:正常値を返す

   テスト項目102
      テスト観点:異常(C1)
      テスト条件:特になし
      テスト内容:不適切なパラメータを設定して、サービス1を実行する
      予測結果:異常値を返す

  →実際には異常値には、DBエラーとか、該当件数0件のときとかいろいろあるけど、今回は、
   話を簡単にするため省略(「お題」で、そういう単純ケースを設定した)

サービス2の単体項目は、201から採番することにします。

   テスト項目201
      テスト観点:正常(C1)
      テスト条件:特になし
      テスト内容:適切なパラメータを設定して、サービス2を実行する
      予測結果:正常値を返す。DB2が更新される

   テスト項目202
      テスト観点:異常(C1)
      テスト条件:特になし
      テスト内容:不適切なパラメータを設定して、サービス2を実行する
      予測結果:異常値を返す

  →実際には異常値には、DBエラーとか、該当件数0件のときとかいろいろあるけど、今回は、
   話を簡単にするため省略(「お題」で、そういう単純ケースを設定した)




■結合テストの合成について

 画面から行うものとする。

 そうすると、テスト項目7「ボタンAをクリックして、入力チェックを行う」は、その後
   テスト項目9→テスト項目101→テスト項目11→テスト項目201
 と進むので、結合テストでは、テスト項目7が

   テスト項目7
      テスト観点:画面A ボタンA(クリックイベント)(c0)
      テスト条件:画面A表示、項目a,bに適切な値を入力
      テスト内容:ボタンAをクリック
      予測結果:画面Bを表示、DB2が更新される
          (ログで、サービス1、2が起動されていることを確認する場合も多い)

 となる。そして、テスト項目9、テスト項目101、テスト項目11、テスト項目201は、
 結合テストでは書かれない(結合してしまった場合、これらを単体では調べられないため)
  →消すというのは原則:残る場合もある。それについては、別にまた今度かく




■単体テストのUI部分のテスト項目と結合テストのテスト項目が一緒になる場合/違う箇所

 このように、画面から操作して結合テストを行う場合、
   ・クリックするというテストの操作までは単体と結合で、項目は一緒になる。

   ・しかし、その後、サーバーアクセスを行って何か処理をする場合、
       テストの操作に対する項目の予測結果は、DB更新など、サーバ処理結果が追加される

   ・画面から操作し、エラー表示など、画面で完結してしまう場合は、
       テストの操作に対する項目の予測結果まで一致する(単体とまったく同じ項目になる)
       →テスト項目自体が省略可能となる。



ここで、異常系の合成は、実は問題が起こる。それが「実行不能」問題になるんだけど、
話が長くなるので、また別の機会で・・
また、「結合テストの合成」のところでも、別の機械で・・と書いたので、気が向いたら、その辺をいつかかく。

P.S むかし、こんなの書いてたのでメモ
単体テスト、結合テスト、総合テストの違い
https://blog.goo.ne.jp/xmldtp/e/109e2e397ff8484af0b8ab1a5c1d040e


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

船にレーザー当てたら、フジツボとれるのでは?

2018-04-16 00:00:38 | Weblog
って、サイエンスZEROの

日本のインフラ老朽化の危機を救うべく開発されたレーザー技術。橋などのさびをあっという間にとり去り、大幅に寿命を伸ばすことを可能に。

を、みて、思った

(太字は、以下から引用)
サイエンスZERO「カガクの“カ”#1 旬!な現場に潜入」
http://www4.nhk.or.jp/zero/x/2018-04-15/31/27496/2136670/




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

遠隔操作できる無人重機で捜索再開

2018-04-15 20:32:06 | Weblog
大分県中津市耶馬渓町金吉で住宅に土砂が流れ込み、2人が死亡、4人が行方不明になった山崩れで、悪天候のため一時中断していた警察や消防などの捜索活動は15日午後、約500人態勢で21時間半ぶりに再開した。安否が分からない江渕優さん(21)らが暮らしていた住宅近くを、遠隔操作できる無人重機で慎重に掘り起こした。

なんでくずれたかわからないので、人が乗ると危険&人が乗ったら崩れるかも?

【引用元(太字は以下のリンク先から引用)】
山崩れ現場の捜索再開、大分 耶馬渓、不明4人


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「テストでのC0、C1、C2に対応した仕様書の書き方」って、学校で教えないよね

2018-04-15 12:58:53 | ネットワーク
「設計書」が書けない設計者
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00041/00005/

(太字は上記サイトより引用)に
機械設計には「設計書」の単語がないのでしょうか?


との答えに対し、

恐らく、実務経験のない学者か誰かがそうした設計フローの学術書、もしくは教科書を作成したのだと思います。それを実務経験の浅い執筆者が転記し、長年の間に日本企業から「設計書」が消えてしまったのでしょう。

ってあるけど、大学のソフトウェア工学とかの講義もそうで、
どこでも「テスト」のときの、命令網羅(C0)、分岐網羅(C1)、組み合わせ網羅(条件網羅)(C2)は教えるけど、
これが、テスト仕様書の書き方にどうかかわるか(変わるか)って、教えてないよね!

ってことで、書いてみる




【お題】

以下のテスト(単体テストということにする)

   スタート
    |
   条件A
    |---------
  はい|         |いいえ
    処理1       |
    |         |
    処理2       |
    |---------
    処理3



   
【C0(命令網羅)100%でお願いね!】
  一番小さいテスト観点は「命令」。この命令ごとに、テスト項目を挙げることになる

   テスト項目1
      テスト観点:処理1の実行
      テスト条件:条件Aが成立
      テスト内容:処理1が実行されていること

   テスト項目2
      テスト観点:処理2の実行
      テスト条件:条件Aが成立、処理1が実行※
      テスト内容:処理2が実行されていること

   テスト項目3
      テスト観点:処理3の実行
      テスト条件:特になし※
      テスト内容:処理3が実行されていること

※テスト条件は、条件分岐するような場合、その条件は上げられるけど、
  前の処理が完了しているかどうかを、書く・書かないは、仕様書のきめによる。
  ただし、書く場合、処理3でこまる。条件1・2は、やっても、やらなくてもいい?
  結局、この場合、まとめて「特になし」となる。




【C1(分岐網羅)100%でお願いね!】
  一番小さいテスト観点は「条件分岐」。この分岐ごとに、テスト項目を挙げることになる

   テスト項目1
      テスト観点:条件A (はいのとき)※
      テスト条件:条件Aがはい
      テスト内容:条件Aのとき、処理1、処理2が実行され(たのち、処理3が実行され★)ていること

   テスト項目2
      テスト観点:条件A (いいえのとき)※
      テスト条件:条件Aがいいえ
      テスト内容:条件Aがいいえのとき、なにもせず処理3が実行されていること★

※テスト観点として、分岐があがるので、条件Aと書くことはたしかだけど、そこで止めるか、
(はいの場合)、(いいえの場合)などと、条件までかくかは、「きめ」による
★あとの処理を書くかどうかは、仕様書の「きめ」によるけど、書かない場合、テスト項目2のほうは、
 「なにもしない」となってしまい、(まあそれでいいんだけど)、変だから、次の処理を書いてしまうこともある




【C0,C1, 100%でお願いね!】

2つ合わせればいいのか・・・?合わせたのち、順番をいれかえ、それに合わせて採番しなおすと・・・

   テスト項目1
      テスト観点:条件A (はいのとき)※
      テスト条件:条件Aがはい
      テスト内容:条件Aのとき、処理1、処理2が実行され(たのち、処理3が実行され★)ていること

   テスト項目1-1
      テスト観点:処理1の実行
      テスト条件:条件Aが成立
      テスト内容:処理1が実行されていること

   テスト項目1-2
      テスト観点:処理2の実行
      テスト条件:条件Aが成立、処理1が実行※
      テスト内容:処理2が実行されていること

   テスト項目2
      テスト観点:条件A (いいえのとき)※
      テスト条件:条件Aがいいえ
      テスト内容:条件Aがいいえのとき、なにもせず処理3が実行されていること★

   テスト項目3
      テスト観点:処理3の実行
      テスト条件:特になし※
      テスト内容:処理3が実行されていること

学校的には、これでOK
でも、実務的には変。テスト項目1と、テスト項目1-1は、実質的には、
処理1のところに、ブレークポイントを置いて確かめるので、
全く同じテスト項目。なので、

・C1の分岐項目のテスト内容は、
     そこで処理を行っている場合で
     かつ、それがC0のテスト項目に上がって
 いたら、
    C1の項目に、分岐の中で初めに行うC0項目の内容を書き、
    そのC0項目は、合成する際にははずす。

今回の例では、
  C1の分岐=テスト項目1
  分岐の中で初めに行うC0項目=テスト項目1-1
なので、これが、上記の法則で、合成される。こんなかんじ


   テスト項目1
      テスト観点:条件A (はい)&処理1
      テスト条件:条件Aがはい
      テスト内容:条件Aのとき、処理1が実行されること

   テスト項目1-2
      テスト観点:処理2の実行
      テスト条件:条件Aが成立、処理1が実行
      テスト内容:処理2が実行されていること

   テスト項目2
      テスト観点:条件A (いいえのとき)
      テスト条件:条件Aがいいえ
      テスト内容:条件Aがいいえのとき、なにもせず処理3が実行されていること

   テスト項目3
      テスト観点:処理3の実行
      テスト条件:特になし※
      テスト内容:処理3が実行されていること

なお、実際の番号は1-2ではなく、1,2,3,4の通し番号になる。




つまり、合成処理が行われないと、全く同じテストを、テスト担当者は、2回やることになる・・
ってことを、学校では教えていない。
あ、でも2回わざとやることもある。この違いと判断は、別の機会に書きます。

ただし、この合成は、C0,C1の合成より、単体・結合テストでの合成のほうが重要。
それについては、またこんど

それで、C2については、組み合わせということなんだけど、
どのように組み合わせをするかというのは、テストケースの話になってしまい、
テストケースと項目の関係にについても、また今度かく。




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

求人が多いシニアエンジニアの条件

2018-04-14 14:30:31 | Weblog
1 現場にいた
2 コミュニケーション能力がある
3 プライドは控えめ
4 資格を取得している
5 健康である


個人的な感触では、5がすべて・・・もしかすると、5が8割、2が2割くらいか・・?
最近は現場にいなくても、管理職・PMO募集も多いのでOK
プライドはないほうがいい
資格は、関係ない。

【引用元】
会社に引き留められるシニアSE、転職に苦労するシニアSE
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00224/032800003/?P=4

4ページ目(太字が引用箇所)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

TeraTermマクロのお勉強

2018-04-10 09:47:22 | ネットワーク
まずは、お勉強のネタをメモメモ

サンプルあり
Tera Termマクロ活用入門(1):各種ログインを自動化する
https://mag.osdn.jp/10/01/08/0825239

Tera Termマクロ コマンド一覧
http://www.macrosh.com/tera-termmakuronitsuite/komando-yi-lan

(直接関係ないけど)パスを追加する
パスに新しいディレクトリを追加するには
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/035addnewpath.html

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

テストにおける同値分割、境界値分割ー違いと必要性

2018-04-09 12:36:59 | Weblog

同値分割は「出力値の」違いに着目してテストを分割する方法
境界値分割は「入力値の」境界に着目して、境界とその前後あたりの場合のテストを行うこと

ここで、入力が同じであれば、出力は、乱数とか使わない限り、同じである。
っていうことは、同値分割で違いがあるということは、入力値が違うはずである
入力値が違うケースは境界値分割でケースが網羅されているはずである。

つまり、「境界値チェック」を完璧にすれば、例外系とかは別だけど、
「同値チェック」のケースはどこかでやっているので、
同値チェックはいらないんじゃないのかという考えが成り立つ

・・・同値チェックはしなくていい?しらなくていい?




この混乱は、フェーズの違いを意識してないから、起こる

同値チェックがうまくいっていない状態で、境界値チェックをしても、
同値チェックで、うまくいっていない状態は、境界値でうまくいくはずがない。

なので、簡単な同値チェックをさきにやり、同値ケースはバグがないことを保証してから、
境界値チェックを行う。

具体的には、出力値から入力値を推測するのは大変なので、デバッガ使って出力値のテストができる、
 単体テストで、同値ケースをつぶして置き

境界値チェックは入力なので、外部からデータが入れられる=ブラックボックスで十分なので
 結合テストで画面入力から、境界値チェックを行う


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AIは技術的負債がある?ない?

2018-04-09 00:24:28 | Weblog
技術的負債という言葉を出したのでついでに・・

AIの技術的負債という話題があって、どうも2つの考え方があるように見える

(1)AIの技術的負債があるという見方

例えば

AI導入に失敗する3つの落とし穴を現役講師が紹介「創業1年でセミナー登壇150回・受講生3,000名」の実績
https://www.kikagaku.co.jp/press_ai_introduction/

の中にでてくる。この立場に立つ場合、ソフトウェアというのは、本来説明ができるものであり、再利用可能、再現可能であると考える。
そう考えると、ディープラーニングなどで決定されるパラメータは説明つかないし、ハイパーパラメータでさえ、根拠がないので保守できない。これは技術的負債で、AIは、この部分が多くあるという考えかた


(2)AIの技術的負債はない

機械学習の人たちから、この言い方は聞いたことがある。
そもそも、技術的負債は

「技術的負債」とは何か。原典とその対応策を探る
http://www.publickey1.jp/blog/13/post_232.html


みても、よくわからない。

なので、技術的負債を「本来やらなきゃいけないことを、今していないので、後でしなきゃならなくなること」と考えると、
AIは、そもそも、パラメータはわからないものだし、ハイパーパラメータは適当に決めるべきものであり、
つねにやるべき作業。
っていうか、AIの場合、もともとコーディングしている部分は少なく、コード部分は変えない(データが変わる)
なので、コード部分の技術的負債はないという考え方。


どっちが正しいかと考えるのは、意外と不毛かも?

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

技術的負債を、女性の体で返すしかない昔の開発

2018-04-08 12:39:42 | Weblog
今の開発では、アジャイルでないにしろ、回帰テストの自動実行が(→jenkins)などが
進んできて、またGITを使う開発が進んできて、インターフェース間の誤解・不整合は気づきやすくなった。

しかし、一昔前の開発では、開発工程がある程度進まないと、テストしないし、
テスト修正後の回帰テストも自動的にすべて行われるわけではないので、
システム間でインターフェース間に不整合があっても(項目がずれていたり、削除されていたり)
 または仕様変更・バグ修正で、インターフェース修正が必要になっても
(その場でテストしないので)気づかれないということが、(結構)起こる。

これは、本来、発生時点で修正すべきことだから、これが残っているということは、技術的負債になる。

------

この技術的負債は、昔は開発者にベテランがいると、早く返済されていた
というのも、この手のインターフェースの矛盾は
  Segmantation fault
Null Pointer Exception
などになることが多く、それを経験している人は発見しやすいし、

そもそも、インターフェースの不整合が起こりにくくなったり、
変更等により不整合が発生すると(実行するとおかしくなるとか、コンパイルできなくなるとか)気づきやすいような
開発環境にしておく

------


ところが、ここ数年で、

・ベテランを希望退職で解雇、解雇された人は、フリーランス・派遣など、短期的・浅いかかわりになった
・開発現場の経験の少ない人が、開発したり
・開発現場の経験の少ない人が、プロジェクトマネージャーなど、ベテランよりはるかに高い地位に就くことになり
   →大手でも役職定年などで

開発の管理部には、技術的に詳しい人がいなくなってきた。
そのため、上記の技術的負債を積極的に返そうというモチベーションはなくなるし
発見しても、「いきなり落ちる」だけで、なにが原因なのだか、わからなくなってきた。

------

ということで、どうするか・・・
派遣、フリーランスは結構高いので、積極的に使えない
そこで、「おばさん」をやとうことになる。
「おばさん」は昔の教育を受けていて、ある程度の戦力になる。
で、「おばさん」を大量投入と長時間労働させる(体を使わせる)ことにより、
いつかは発見され、修正されるという戦略をとるようになった。

つまり、

インターフェースの整合性という技術的負債を、
おばさんの長時間労働という女性の体で返す

という手段をとっているわけで、実際、昔の開発手法を今やると、
こうならざるをえない



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

こんぐらをメモメモ

2018-04-08 00:34:31 | Weblog
NHKの

コングラ CGの教室 第1話「形づくる」
http://www4.nhk.or.jp/P4867/


をメモメモ

CG:3つの段階
 形づくる、動かす、似せる

形作る:モデリング
 立体的:ポリゴン(三角形・四角形)の面の組み合わせ
  手の長さを決める
  動き

 観察する

 自動より、作る

 ビデオでコンテを作る




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

スパコン京の次世代像

2018-04-07 13:44:57 | Weblog
プロセッサのアーキテクチャーをSPARCからArmに変更

見えたスパコン京の次世代像、理研の新センター長に東工大松岡氏
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00278/

(太字は上記サイトから引用)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

スマートホームスキル

2018-04-06 01:41:13 | Weblog
スマートホームスキルを作る (3) イベント通知機能の実装と、スキルの公開
https://developer.amazon.com/ja/blogs/alexa/post/dde2ef0e-1097-4e10-9a16-9a708ec6e67d/how-to-create-smart-home-jp-skill-3

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アマゾン配送料上げ

2018-04-05 09:26:07 | ネットワーク
そのうち、配送料のかからないリアル店舗が復権したりして・・

アマゾン配送料上げ 最大1.5倍、物流コスト転嫁
購入2000円未満対象
https://www.nikkei.com/article/DGXMZO28977050U8A400C1000000/

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

機械とインターネットをつなぎたいと言われたら、IoTではなく

2018-04-05 00:22:40 | ネットワーク
ModBusだよね~というお話・・・

「PLCでModbus通信 ~横河電機社製での実装例~」
http://www.softech.co.jp/mm_110302_plc.htm

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「第四次産業革命スキル習得講座認定制度」

2018-04-04 00:52:10 | Weblog
って、何?

「第四次産業革命スキル習得講座認定制度」の第2回申請受付を開始します-Connected Industries人材~未来へつなぐ-
http://www.meti.go.jp/press/2017/03/20180319003/20180319003.html

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする