TOP /  運用管理/運用自動化 /  失敗例から見る、JUnitによる単体テストの課題と、工数削減の方法~Jtestとは~

失敗例から見る、JUnitによる単体テストの課題と、工数削減の方法~Jtestとは~ | 運用管理/運用自動化

講演資料を見るには、 プライバシーポリシーに同意して、送付先メールアドレスをご入力しご請求ください。

またご入力いただきました情報は、当該イベントの主催・共催・協賛・講演企業とも共有させていただき、 当社及び各社のサービス、製品、セミナー、イベントなどのご案内に使用させていただきます。

メールアドレス


法人様向けの資料のため、フリーアドレスをご利用の場合は、会社名、お名前を入力してください。
会社名
お名前

失敗例からみるJunit単体テストのあれこれ  (テクマトリックス株式会社‎ )

JTestによる単体テストの工数削減とROIを向上させる秘策

テクマトリックスが提供するソリューションのご紹介

講演資料を見るには、 プライバシーポリシーに同意して、送付先メールアドレスをご入力しご請求ください。

またご入力いただきました情報は、当該イベントの主催・共催・協賛・講演企業とも共有させていただき、 当社及び各社のサービス、製品、セミナー、イベントなどのご案内に使用させていただきます。

メールアドレス


法人様向けの資料のため、フリーアドレスをご利用の場合は、会社名、お名前を入力してください。
会社名
お名前

セミナー全体の評価と、参加者からのコメント

参加者によるこのセミナーの評価は、
3.7 でした!(5点満点中)
セミナー名 失敗例から見る、JUnitによる単体テストの課題と、工数削減の方法~Jtestとは~
講演企業 テクマトリックス株式会社‎
開催日 2019年09月13日
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
ご丁寧に対していただき、ありがとうございます。
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし
匿名の参加者
コメントなし

失敗例からみる JUnit 単体テストのあれこれ
テ ク マ ト リ ッ ク ス 株 式 会 社
ソフトウェアエンジニアリング事業部
2
本セッションのねらい
ソースコードを対象した”単体テスト”は効果のいテストとわれており、
Javaにおいては、テスティングフレームワークのJUnitが多く使われています。
本セッションでは、JUnitを使った単体テストの失敗例から、
単体テストのコストを減らし、効率的に効果を出す法をご紹介します。
効果
コスト
効果
コスト
Copyright2019TechMatrixCorporation.Allrightsreserved.
1.
単体テストとは
4
単体テストとは①
定義
プロダクトを構成する最単位における振る舞いを確認するためのテスト
最単位メソッド、関数、機能、ビルドなど。
振る舞いメソッドが特定の引数の組合せで正しく動作するか、例外が発したときの動きが正しいか、など。
システム
テスト
要件定義
基本設計
結合テスト
詳細設計
単体テスト
実装
コード
レビュー
Copyright2019TechMatrixCorporation.Allrightsreserved.
5
単体テストとは②
なぜおこなうのか
プロダクトを構成する部品が設計通りに動作することを早期に確認できるため
陥がつかっても、原因の箇所を特定しやすく、修正コストが安くすむ。
結合テスト・システムテスト程における戻りが予防できる。
どうやっておこなうのか




テスティングフレームワーク
動テスト
ログ出
デバッグ
単体テスト程での不具合摘出率がい例
40
38
4500
35
系列1
系列2
4000
3500
30
3000
25
2500
20
2000
15
1500
10
1000
2
5
0
0
500
0
1
2
3
“単体テスト実による品質向上(短納期対応)” - SQiP研究会, 2005年 を元にグラフを再作成
Copyright2019TechMatrixCorporation.Allrightsreserved.
6
単体テストとは②
なぜおこなうのか
Java開発では、JUnit がよく使われています
プロダクトを構成する部品が設計通りに動作することを早期に確認できるため

問題がつかっても、原因の箇所を特定しやすく、修正コストが安くすむ。
2000年に初回リリースされ、今も現役のテスティングフレームワーク。
結合テスト・システムテスト程における戻りが予防できる。
Javaで書かれたプログラムに対して繰り返し可能なテストを作成、実するため
の機能を持ち、Javaの単体テストでは最も有名です。
どうやっておこなうのか
Eclipse や IntelliJ IDEA などの統合開発環境(IDE)に標準で搭載されています。




テスティングフレームワーク
動テスト
ログ出
デバッグ
単体テスト程での不具合摘出率がい例
主な機能 40
38
35
プロダクトコードが期待する結果であることをテストするためのアサーション
系列1
系列2
30
テストデータやオブジェクトを複数のテストで共有するためのテストフィクスチャー
25
テストを実するためのテストランナー
20
4500
4000
3500
3000
2500
2000
15
1500
10
1000
2
5
0
0
500
0
1
2
3
“単体テスト実による品質向上(短納期対応)” - SQiP研究会, 2005年 を元にグラフを再作成
Copyright2019TechMatrixCorporation.Allrightsreserved.
7
JUnit を使うことのメリットとデメリット
メリット
(= 効果)
度作成したテストを何度でも実できる




何をテストしたかをJUnitのテストコードとして残すことができる
実環境に依存しないテストを作成できる
度作成したテストコードを回帰テストとして利できる
EclipseやIntelliJ IDEAに標準で搭載されており、導が簡単にできる
デメリット
(=コスト)
JUnit特有の癖があり、使いこなすのが難しい




JUnit や関連するライブラリやツールの知識が必要になる
テストコードの実装には数がかかる
例外処理など、特殊なパターンのテストはテストコードが複雑になる
できない、向いていないテストがある
3つの失敗例からJUnitの単体テストを
おこなうコツをご紹介します。
Copyright2019TechMatrixCorporation.Allrightsreserved.
2.
単体テストの失敗例と対策
失敗とは
10
失敗とは
JUnit 単体テストを上く導・運できていないことを「失敗」としています。
失敗例 1
JUnit 単体テストを導したが、数が増えて続かなかった
失敗例 2
プロダクトコードの修正に追われて、テストコードがメンテナンスされない
失敗例 3
単体テストの本来の的を忘れ、カバレッジ100%を指してしまう
Copyright2019TechMatrixCorporation.Allrightsreserved.
失敗例1.
JUnit 単体テストを導したら数が増した
12
失敗した原因と課題
失敗
JUnit 単体テストを導したら数が増した
原因
JUnit コードの実装に時間がかかる
JUnit コードの書きがわからない
課題
1. プロダクトコードを単体テストがしやすいコードにする
2. JUnit を使いこなせるようになる
Copyright2019TechMatrixCorporation.Allrightsreserved.
1. プロダクトコードを単体テストがしやすいコードにする
13
対策
可読性のい(読みやすい)プロダクトコードを実装する
コーディング規約を設けるなど、可読性のいコードを実装するためのルールを策定し順守します。
1メソッドを短くする

メソッドがくなればなるほど、データーの状態を意識す
るなどテストコード実装時の考慮が必要になる
コードを独させる

依存関係の強いコードのテストにはモックオブジェクトを
利するなどの夫が必要になる
分岐条件をシンプルにする

分岐条件が複雑になればなるほど、テストケースが必
要になる
重複コードをまとめる

複数ある同じ実装をまとめることができれば、テストする
べきコードを削減できる
デッドコードを削除する

使われない不必要なコードをわざわざテストする必要は
ない
分岐を減らす

1カ所の分岐のために最低1件以上のテストケースが必
要になる
複雑なプロダクトコードに対しては単体テストをあきらめる
テストコードも複雑となりメンテナンス性の問題があるため、UIテストなどの他のテストでカバーします。
Copyright2019TechMatrixCorporation.Allrightsreserved.
14
2. JUnit を使いこなせるようになる
対策
JUnitを学習する
たとえば、戻り値を検証するアサーションにもたくさんの種類があり、テストの内容に合わせて使い分ける必要があります。
テストしやすいコードからテストする
ユーティリティクラス、POJO (Plain Old Java Object) のクラス
字列の処理や数値の計算、オブジェクトの状態に依存しないメソッド
関連ツールを使いこなす
JUnitと緒に使えるフレームワークを有効的に活する
Mockito(モック化), DBUnit(DB接続), Jacoco(カバレッジ計測)
テスト技法について学習する
ブラックボックステスト、ホワイトボックステスト、同値分割法や境界値分析など
Copyright2019TechMatrixCorporation.Allrightsreserved.
15
ツールによる対策
単体テストの効果を出すためにはによる対策が必要です。
しかし、による対策では、異なる数がかかるだけでコスト削減にはつながりま
せん。
単体テストを援するツールによる対策も並しておこないましょう。
削減されたコスト
による対策
にかかるコスト
対策により削減
されたコスト
もともとのコスト
対策にかかるコスト
による対策後のコスト
対策によって削減されるコスト
開発者のコストが
少なく済む
削減効果が
きい
+ツールによる対策後のコスト
JUnit単体テストにかかるコスト
Copyright2019TechMatrixCorporation.Allrightsreserved.
16
Jtest による対策
ParasoftJtestは、テスト数の幅削減とセキュアで品質なJavaシステムの開発を強にサポートするJava対応テストツールです。
コード解析
コーディング規約の順守
致命的なバグ混の回避
テスト動化基盤 単体テスト
運の標準化 バグ混・デグレードの回避
数の削減・作業品質の向上 単体テストの作成数を削減
アプリケーション
カバレッジ計測
テストの網羅性の把握
テストの抜け漏れの改善
解析レポート
結果のHTMLやPDF出
Webブラウザーでの結果確認
Copyright2019TechMatrixCorporation.Allrightsreserved.
17
Jtest による対策
課題
1. プロダクトコードを単体テストがしやすいコードにする
2. JUnit を使いこなせるようになる
Jtestによる対策
JUnitテストコードの作成を補助し、コード作成のコストを下げる




テンプレート作成機能
モック化
単体テスト改善のナビゲーション
実の監視機能
Copyright2019TechMatrixCorporation.Allrightsreserved.
18
Jtest による対策①(テストコード作成の数削減)
テンプレート作成機能
でコード実装を簡単にできる
JUnitのテストメソッドのテンプレートやアサーションの作成を援
メソッドから成したテンプレートをいることで、テストコードの実装量を幅に削減
Simple.java
package examples.eval;
テスト対象クラス・メソッド
SimpleTest.java
テストクラス・メソッド
package examples.eval;
import static org.junit.Assert.assertEquals;
public class Simple
テスト対象メソッド
import org.junit.Test;
{
テストクラス
public static int map(int index)
public class SimpleTest {
{
作成
switch (index) {
@Test
case 0:
public void testMap() throws Exception {
case 10:
テストメソッド
// When
return -1;
パラメータの定義
テスト対象メソッドに渡すパラメータを設定 int index = 0; // UTA: デフォルト値
case 2:
int result = Simple.map(index);
case 20:
テスト対象メソッドの呼び出し
break;
// Then
default:
assert
テスト対象メソッドを呼び出した際の期待値を設定 // assertEquals(0, result);
return -2;
}
}
}
return 0;
}
開発者のは
をうだけで単体テストがえます。
Copyright2019TechMatrixCorporation.Allrightsreserved.
19
Jtest による対策②(テストコード作成の数削減)

インタフェースや複雑なオブジェクトを動的に
モック化
し、テストケースを作成できる
テスト対象メソッドを様々な依存関係から切り離してテストを実施
モック化したオブジェクトが必要とするクラスオブジェクトをさらにモック化(深いモック)
データベース関連の呼び出しを括でモック化
テスト対象メソッド
モック化が
必要なオブジェクト
JUnitテストメソッド
@Test
public void testGetItemDB() throws Throwable {
// Given
Cart underTest = new Cart();
public Item getItemDB(Connection con, String itemId) {
Item = new Item();
try {
Statement stmt = con.createStatement();
String sql = "select * from id";
ResultSet rs = stmt.executeQuery(sql);
if (rs.next()) {
item.setName(rs.getString("name"));
item.setId(rs.getString("id"));
item.setCount(rs.getInt("count"));
item.setPrice(rs.getInt("price"));
}
} catch (SQLException e) {
System.out.println("SQLException:" + e.getMessage());
}
return item;
}
モック化
// When
Connection con = mock(Connection.class);
Statement createStatementResult = mock(Statement.class);
括でモック化
ResultSet executeQueryResult = mock(ResultSet.class);
int getIntResult = 0; // UTA: デフォルト値
when(executeQueryResult.getInt(anyString())).thenReturn(getIntResult);
String getStringResult = ""; // UTA: デフォルト値
when(executeQueryResult.getString(anyString())).thenReturn(getStringResult);
boolean nextResult = false; // UTA: デフォルト値
when(executeQueryResult.next()).thenReturn(nextResult);
when(createStatementResult.executeQuery(anyString())).thenReturn(executeQueryResult);
when(con.createStatement()).thenReturn(createStatementResult);
String itemId = ""; // UTA: デフォルト値
Item result = underTest.getItemDB(con, itemId);
Copyright2019TechMatrixCorporation.Allrightsreserved.
20
Jtest による対策③(テストコードの改善)
単体テスト改善のナビゲーション
でテストコードを改善する法を確認できる
テストコードの改善を提案
モック化できるオブジェクト呼び出しのモックオブジェクト化、テスト実中に発した例外の対処など
モック化できるオブジェクトの提案
実環境に影響を与える恐れがあるテストコードの指摘
システムプロパティの変更後の復元漏れ、ファイルの削除漏れなど
発した NullPointerException への対処の提案
Copyright2019TechMatrixCorporation.Allrightsreserved.
21
Jtest による対策④(テストコードのデバッグ)
実の監視機能
でデバッグを効率化できる
JUnit実時に、処理の経路やテストメソッド内の変数の値、モックの呼び出し、例外の有無を監視
ブレークポイントやステップ実によるデバッグを軽減し、適切な単体テストの作成を援
実の監視機能
実時の処理の流れを追跡
変数の値や発した例外を表
Copyright2019TechMatrixCorporation.Allrightsreserved.
失敗例2.
テストコードがメンテナンスされない
23
失敗した原因と課題
失敗
テストコードがメンテナンスされない
原因
テストコードが複雑でどこを変更すればよいかわからない
プロダクトコードと緒に変更されないため、テストコードが古いまま
課題
1. わかりやすいテストコードを実装する
2. プロダクトコードと緒にテストコードを変更する
Copyright2019TechMatrixCorporation.Allrightsreserved.
24
1. わかりやすいテストコードを実装する
対策
プロダクトコードと同様に、わかりやすいテストコードを実装する
以下のような注意事項を設け、順守します。
重複コードをまとめる

データの値だけが異なるテストをパラメータライズでまとめ外部ファイルでテストデータのメンテナンスだけを実施する
値、期待値で仕様がわかるようにする

123、テスト1、では何のためのテストか、プロダクトコードはどういった仕様なのかがわかりづらい
コメントを残す

実装者以外もテストの内容を理解できるよう適切なコメント残す
ただし、過度な制約はテストコードの実装時間の増加につながるため、厳しすぎる成約は推奨しません。
Copyright2019TechMatrixCorporation.Allrightsreserved.
2. プロダクトコードと緒にテストコードを変更する
25
対策
開発プロセスとしてテストコードの変更を定め、順守する
テストコードの変更を徹底する


テストコードはプロダクトコードの変更と同時に変更するように徹底する
テストが成功しなければ、構成管理へのコミットを禁する
テストを動化する

プロダクトコードの変更後におこなうビルドで変更の有無を問わずテストコードを実する

ビルドツール、CIツールで動実する

テストが失敗したらすぐに原因を調査する
Copyright2019TechMatrixCorporation.Allrightsreserved.
Jtest による対策
26
課題
1. わかりやすいテストコードを実装する
2. プロダクトコードと緒にテストコードを変更する
Jtestによる対策
メンテナンス性のいテストコードを成する
パラメータライズテストテンプレートの作成
変更されたコードだけをテストする
テスト影響分析(Change Based Testing)
Copyright2019TechMatrixCorporation.Allrightsreserved.
27
Jtest による対策⑤(テストコードのメンテナンス性の向上)
パラメータライズテストテンプレートの作成 でコードとテストデータを簡単に分離できる
複数テストデータを度に実するパラメータライズドなテストメソッドテンプレートを作成
テスト対象メソッド JUnitテストメソッド
public int calc( int op, int i1, int i2 ) { CSVファイル読み込み設定
int result = 0; @Test
switch( op ) { @FileParameters(value =
case 0: "classpath:jp/co/tmx/sample/SimpleParameterizedTest_testCalc_parameters.csv", mapper
result = i1 + i2; = CsvWithHeaderMapper.class, encoding = "UTF-8")
break;
case 1
result = i1 - i2;
break;
case 2
result = i1 * i2;
break;
case 3
result = i1 / i2;
break;
default:
result = -1;
}
return result;
}
作成
public void testCalc( int op, int i1, int i2) throws Throwable {
Simple underTest = new Simple();
int expected 動で期待値を引数に追加
int result = underTest.calc(op, i1, i2);
// assertEquals(expected, result);
コメントを外す
}
テストケースCSV
op
作成
i1 i2 expected
0 0 1 1
1 1 10 -9
2 0 10 0
動で期待値をCSVに追加
Copyright2019TechMatrixCorporation.Allrightsreserved.
28
Jtest による対策⑥(変更したソースコードのテスト)
テスト影響分析(Change Based Testing) で変更したソースコードに依存するテ
ストコードを確認できる
プロダクトコードの変更に合わせて変更するべきテストを抽出、実
影響を受ける単体テスト
Copyright2019TechMatrixCorporation.Allrightsreserved.
失敗例3.
カバレッジ100%を指してしまう
30
失敗した原因と課題
失敗
カバレッジ100%を指してしまう
原因
カバレッジを有効活できていない
単体テストだけでカバレッジ100%を達成しようとする
課題
1. カバレッジを有効活するためにカバレッジの定義を直す
2. カバレッジの計測範囲を明確にする
Copyright2019TechMatrixCorporation.Allrightsreserved.
1. カバレッジを有効活するためにカバレッジの定義を直す
31
対策
カバレッジ計測でできること、できないことを理解する
できること
実装されたプロダクトコードが、テストコードでどれだけ実されたかを確認する
テストコードが不している箇所を特定する
できないこと
▲ カバレッジを計測したプロダクトコードに陥(バグ・不具合)が無いことを確認する
▲ プロダクトコードの実装漏れが無いことを確認する
▲ プロダクトコードの実装が仕様通りであることを確認する
カバレッジを 「テスト不を特定する」 ために活する
カバレッジ計測の結果、テストコードが不しているプロダクトコードを特定します。
テストコードが不しているコードは、テストの観点が不していることを疑い、テストパターンの追加を検討します。
Copyright2019TechMatrixCorporation.Allrightsreserved.
1. カバレッジを有効活するためにカバレッジの定義を直す
(参考)
32
カバレッジとは
前提
カバレッジ = テスト対象をどの程度カバーできたかをす”ものさし”
カバレッジは、プロダクトコードの実された/実されなかった部分を特定できますが、
実されたテストで、プロダクトコードが仕様通りに実装されていることを検証できたか
プロダクトコードに存在する陥を検出できるテストコードであるのか
をすものではありません。
カバレッジが「い」ことは、テストコードの「品質がい」ことにはならない
プロダクトコードに実装漏れがあってもカバレッジ100%になる
実装されたプロダクトコードが実されていれば、カバレッジは100%になる
カバレッジの値だけでテストを判断すると、実装漏れに気づくことができない
アサーションが無いテストコードでもカバレッジは100%になる
テストの内容にかかわらず、プロダクトコードが実されていればカバレッジは100%になる
テストが仕様に沿っているかはカバレッジから判断することはできない
そもそもカバレッジ100%を達成しても、陥をすべて潰したことにはならない
Copyright2019TechMatrixCorporation.Allrightsreserved.
33
2. カバレッジの計測範囲を明確にする
対策
JUnitのテストが不要なコードや、向かないコードはデバッグ実や画テストでカバーする
ビジネスロジック
新規・追加・修正した(保守の場合)
システムの重要な部分
陥が多そうなコード
JUnitのテストをう



JUnitでのテストは不要 変更を加えていない動成コード
保守期間が短い
JUnitテストに向いていない
(デバッグ実や画テストでカバー)




分岐条件やネストが多い複雑
多くのプログラムから参照されている
頻繁に変更される
例外処理をう
操作してテストしたほうが効率的な処理
画表部やGUI と密接に関わっている処理
結合度がいコード
Copyright2019TechMatrixCorporation.Allrightsreserved.
34
Jtest による対策
課題
1. カバレッジを有効活するためにカバレッジの定義を直す
2. カバレッジの計測範囲を明確にする
Jtestによる対策
テスト不の箇所を検知する
カバーされていないコードの指摘
単体テストと他のテストのカバレッジ計測結果をマージする
JUnit + UI テストのカバレッジを合算
Copyright2019TechMatrixCorporation.Allrightsreserved.
35
Jtest による対策⑦(カバレッジ向上のためのヒント)
カバーされていないコードの指摘でカバレッジを向上するのに必要なテストパターンを
確認できる
カバレッジ向上のためのテストコード実装数を削減
単体テストで
カバーされていない箇所

カバーするためのヒントを表
Copyright2019TechMatrixCorporation.Allrightsreserved.
36
Jtest による対策⑧(複数テストのカバレッジ計測を合算)
JUnit + UI テストのカバレッジを合算で複数の法で実施したテストのカバ
レッジの合計を確認できる
異なるテスト法でプロダクト全体の総カバレッジを表
単体テスト
Parasoft DTP(ダッシュボードツール)
単体テストカバレッジ
カバレッジデータ登録
クライアントマシン
UIテスト(動)
アプリケーションカバレッジ

カバレッジデータ登録
Webブラウザ
Webアプリケーション
Copyright2019TechMatrixCorporation.Allrightsreserved.
3.
まとめ
38
まとめ

Java開発で最も使われているJUnitにおいて、単体テストのコストがかかる要因である3つの失敗
例とその対策をご紹介しました。
般的なによる
対策
数が増した
テストコードの変更
プロセスを徹底する
カバレッジ100%を
指してしまう
実装するテストコードの
量を減らす
JUnitを学習する
テストコードが
メンテナンスされない
効果

による対策
テスト実の監視や
テスト影響分析を援
コスト
効果
コスト
効果
コスト
単体テストのコストを下げ、効率的に効果を出すには、による対策だけではなく、
効率的に単体テストを実施できる専のツールを活することを検討してみてはいかがでしょうか
Copyright2019TechMatrixCorporation.Allrightsreserved.
39
参考 失敗例と対策のまとめ
失敗例
原因
有効なJtestの機能
課題 般的な対策 プロダクトコードを単体テス 可読性がいプロダクトコードを実装する JUnit コードの書きがわ JUnit を使いこなせるよう テストコードが複雑 わかりやすいテストコードを 重複をまとめる パラメータライズドテン
トがしやすいコードにする そもそも単体テストをしない(別のテストでカバー) からない になる 実装する 値、期待値で仕様がわかるようにする プレートの作成
コメントを残す

プロダクトコードと緒に変 プロダクトコードと緒にテ テストコードの変更を徹底する テスト影響分析
更されない ストコードを変更する テストを動化する
カバレッジを有効活でき カバレッジを有効活する カバレッジ計測でできること、できないことを理解する カバーされていない
ていない ためにカバレッジの定義を テストコードが不しているプロダクトコードを減らす コードの指摘
直す ために活する
単体テストだけでカバレッジ カバレッジの計測範囲を明 JUnitのテストが不要なコードや、向かないコードはデ JUnit +UI テストのカ
を100%にしようとしている バッグやGUIからテストを実施する
確にする
バレッジを合算
JUnitコードの実装に時間
がかかる
JUnit 単体テストを導
したら数が増した
テストコードがメンテナンス
されない
カバレッジ100%を指し
てしまう
JUnitを学習する
テストしやすいコードからテストする
関連ツールを使いこなす
テスト技法について学習する




テンプレート作成
モック化
改善ナビゲーション
実の監視
Copyright2019TechMatrixCorporation.Allrightsreserved.
対策の後は
41
対策の後は
対策したことでどれくらい失敗が改善・解消されたのか、振り返りを
おこなうのを忘れないでください。
JUnit単体テストの数がどれだけ削減できたか
テストコードのメンテナンスが適切にわれるようになったか
カバレッジを効果的に利できているか
効果を測定する具体的な例は、次のセッションでお話します。
Copyright2019TechMatrixCorporation.Allrightsreserved.
42
ご清聴ありがとうございました。
Copyright2019TechMatrixCorporation.Allrightsreserved.
お問い合わせ先
テクマトリックス株式会社
ソフトウェアエンジニアリング事業部
03-4405-7853
03-6436-3553
se-info@techmatrix.co.jp
http://www.techmatrix.co.jp/product/jtest/

他のカテゴリから探す

IT業界の改革にご協力いただけませんか?

本サイトは、株式会社オープンソース活用研究所がプロデュースする、中小IT企業による”本気”の情報提供セミナー「マジセミ」の結果レポートページです。「マジセミ」は、次を目的として活動しています。

我々はITエンジニアが、今よりももっと「誇り」と「喜び」をもって仕事をし、今よりももっと企業や社会に貢献できる、そんなIT業界を創りたいと考えています。

そのためには、技術をもった中小のIT企業がもっと元気になる必要がある。その為には、技術をもった中小のIT企業を、もっと皆様に知って頂く必要がある、と考えました。

株式会社オープンソース活用研究所
代表取締役所長 寺田雄一

本当かウソか、あなたが見極めてください。

もし、我々のこの活動にご賛同していただけるのであれば、ぜひ下のセミナーに参加してください。

「なんだ、結局ただの売り込みセミナーじゃないか」

もしそう感じたら、アンケートなり、あなたのFacebookなりに、そのままお書き頂き、拡散して頂いて構いません。

参加者からのお褒めの言葉、お叱りの言葉が、我々中小IT企業を成長させ、それが日本のIT業界を変えていくのだと、強く確信しています。

あなたの行動が、日本のIT業界を変えるのです。

「マジセミ」のFacebookページ

今後のセミナー情報などを提供させていただきたますので、「マジセミ」のFacebookページに「いいね!」をお願いします。

日本のIT業界を変えるためのアクション、ありがとうございました!

関連するセミナーの講演資料
Kubernetesの設定は超大変、AIOpsで自動的にチューニングするツールの紹介 ~日本におけるビジネスパートナーを募集~ クラウドネイティブな時代のAWSの運用管理と、ベトナムオフショアでのAWSアプリ開発 ~サーバーレスで溢れ出した運用管理の課題と対策~ 「Webシステムにおける性能問題の原因調査」の難しさと、その対策について 失敗例から見る、JUnitによる単体テストの課題と、工数削減の方法~Jtestとは~ B2C、B2B向けWebサービスにおける認証基盤のあり方 ~便利と安全を両立させる認証・認可と、その最新技術~ OSSの監視ツール、本当にZabbixだけでよいのか? ~CactiやIcinga2など、他のOSS監視ツールが適しているケースとは~ RPAだけでは自動化できない業務を、どう効率化すればよいのか? ~Robochestrationという考え方について~ システム運用の効率化と、Zabbixによるクラウド環境、コンテナ環境の監視 【大阪開催】情シスアンケートから見たワークフロー製品の課題解説と、ワークフロー製品リプレースのポイント ~「2重入力」「連携できない」を解決する方法/他社製品からの移行ポイント~ 稼働管理超過で失敗しない、Redmineによるプロジェクト管理方法とは ~Redmineに、グローバル・ガントチャートや稼働時間管理の機能を追加~