スライド 1
|
|
|
- ゆずさ ゆきしげ
- 5 years ago
- Views:
Transcription
1 ユニットテストの保守性を作りこむ ~ 設計 実装の工夫で支えるユニットテストの継続的活用 ~ 井芹 洋輝
2 謝辞 声をかけて頂いた細谷さん 機会を提供頂いている XPJUG 関西の皆様 素晴らしい場を作り上げている登壇者 参加者の方々 今回のテーマに関して様々なことを学ばせて頂いている xutp 読書会の方々 深くお礼申し上げます
3 自己紹介 井芹洋輝 ( いせりひろき ) 組込みエンジニア 所属 WACATE 実行委員 / 派生開発推進協議会研究会 /TDD 研究会など 対外活動 JaSST 11 Tokyo/WACATE2011 冬 / とちぎテストの会議 / 並列プログラミングカンファレンスなど
4 概要 ユニットテストの保守性を作りこむアプローチを いくつかの具体例を交えて俯瞰的に見ていきます
5 概要 1. 背景 ユニットテストの現状と課題 2. 目標 ユニットテスト継続活用における目標 3. ユニットテストの保守性向上アプローチ テストコードの実装の工夫 テストコードの構造設計の工夫 テスト設計の工夫 4. まとめ
6 背景
7 ユニットテストの用途
8 軽快なチェック
9 // コードから無視する文字を削除する string reformat(string line)...( 複雑なロジック )... 複雑なメソッドを書いたきちんと動くか不安だ
10 // コードから無視する文字を削除する string reformat(string line)...( 複雑なロジック )... 安心できるまでテストを書く TEST(CodeAnalyzer, test_reformat_containcomment) EXPECT_EQ("#hoge", reformat("#hoge /* fuga */")); TEST(CodeAnalyzer, test_reformat_containspace") EXPECT_EQ("void function()", reformat("void function ()")); TEST(CodeAnalyzer, test_reformat_containemptyline") EXPECT_EQ("test; n", reformat("test; n n n n"));
11 // コードから無視する文字を削除する string reformat(string line)...( 複雑なロジック )... 安心できるまでテストを書く TEST(CodeAnalyzer, test_reformat_containcomment) EXPECT_EQ("#hoge", reformat("#hoge /* fuga */")); TEST(CodeAnalyzer, test_reformat_containspace") EXPECT_EQ("void function()", reformat("void function ()")); TEST(CodeAnalyzer, test_reformat_containemptyline") EXPECT_EQ("test; n", reformat("test; n n n n")); リスクや不安を即時に解消して前進できる
12 リファクタリング
13 // うるう年か判定する bool isleapyear(unsigned int year) if (year % 4 == 0) if (year % 100 == 0) if (year % 400 == 0) return true; return false; return true; return false; 実装が汚い
14 1. テストで保護する // うるう年か判定する bool isleapyear(unsigned int year) if (year % 4 == 0) if (year % 100 == 0) if (year % 400 == 0) return true; return false; return true; return false; TEST(TestYear, test_isleapyear_divisibleby4) EXPECT_EQ(true, isleapyear(8)); EXPECT_EQ(false, isleapyear(9)); EXPECT_EQ(true, isleapyear(0)); TEST(TestYear, test_isleapyear_divisibleby400) EXPECT_EQ(true, isleapyear(800)); EXPECT_EQ(false, isleapyear(900)); TEST(TestYear, test_isleapyear_divisibleby100) EXPECT_EQ(false, isleapyear(500));
15 1. テストで保護する // うるう年か判定する bool isleapyear(unsigned int year) if (year % 400 == 0) return true; if ((year % 4 == 0) && (year % 100!= 0)) return true; return false; 2. テストでチェックしつつリファクタリング TEST(TestYear, test_isleapyear_divisibleby4) EXPECT_EQ(true, isleapyear(8)); EXPECT_EQ(false, isleapyear(9)); EXPECT_EQ(true, isleapyear(0)); TEST(TestYear, test_isleapyear_divisibleby400) EXPECT_EQ(true, isleapyear(800)); EXPECT_EQ(false, isleapyear(900)); TEST(TestYear, test_isleapyear_divisibleby100) EXPECT_EQ(false, isleapyear(500));
16 1. テストで保護する // うるう年か判定する bool isleapyear(unsigned int year) if (year % 400 == 0) return true; if ((year % 4 == 0) && (year % 100!= 0)) return true; return false; 2. テストでチェックしつつリファクタリング TEST(TestYear, test_isleapyear_divisibleby4) EXPECT_EQ(true, isleapyear(8)); EXPECT_EQ(false, isleapyear(9)); EXPECT_EQ(true, isleapyear(0)); TEST(TestYear, test_isleapyear_divisibleby400) EXPECT_EQ(true, isleapyear(800)); EXPECT_EQ(false, isleapyear(900)); TEST(TestYear, test_isleapyear_divisibleby100) EXPECT_EQ(false, isleapyear(500)); 安全に記述改善
17 学習テスト
18 boost::xpressive 初使用でよくわからない
19 boost::xpressive テストで動作を確認する 不安がなくなるまで試す TEST(regex, test_regex_fileseek) namespace xp = boost::xpressive; string target; xp::smatch match; xp::sregex rex = xp::sregex::compile ("(.c.h)$"); target = "test"; EXPECT_EQ(false, xp::regex_search(target, match, rex)); target = "test.c"; EXPECT_EQ(true, xp::regex_search(target, match, rex)); target = "test.h"; EXPECT_EQ(true, xp::regex_search(target, match, rex)); target = "./../source/_svn/text-base/main.c.svn-base"; EXPECT_EQ(false, xp::regex_search(target, match, rex)); target = "test.cpp"; EXPECT_EQ(false, xp::regex_search(target, match, rex));
20 boost::xpressive テストで動作を確認する 不安がなくなるまで試す TEST(regex, test_regex_fileseek) namespace xp = boost::xpressive; string target; xp::smatch match; xp::sregex rex = xp::sregex::compile ("(.c.h)$"); target = "test"; EXPECT_EQ(false, xp::regex_search(target, match, rex)); target = "test.c"; EXPECT_EQ(true, xp::regex_search(target, match, rex)); target = "test.h"; EXPECT_EQ(true, xp::regex_search(target, match, rex)); target = "./../source/_svn/text-base/main.c.svn-base"; EXPECT_EQ(false, xp::regex_search(target, match, rex)); target = "test.cpp"; EXPECT_EQ(false, xp::regex_search(target, match, rex)); 動作チェック 用例ドキュメントとして活用
21 デバッギングテスト
22 class MacroWord バグがでた
23 class MacroWord 1. テスト上でバグを再現する TEST_F(TestMacroWord, test_macrodata_macroword_bug21) MacroData macrodata; macrodata.push_back("auto_debug_1"); macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); macrodata.push_back( BB_H_"); MacroWord macroword(macrodata); EXPECT_EQ("AUTO_DEBUG_1", macroword.data_[0].macroname_); EXPECT_EQ(1, analyzer.data_[0].number); EXPECT_EQ("AUTO_DEBUG_2", macroword.data_[1].macroname_) EXPECT_EQ(3, analyzer.data_[1].number); EXPECT_EQ( BB_H_", macroword.data_[2].macroname_); EXPECT_EQ(1, analyzer.data_[2].number);
24 class MacroWord 1. テスト上でバグを再現する 2. テストでバグを絞込み特定する TEST_F(TestMacroWord, test_macrodata_macroword bug21) MacroData macrodata; macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); MacroWordProxy::wordCount(macroData); EXPECT_EQ(3, MacroWordProxy::getSize(0));
25 class MacroWord 1. テスト上でバグを再現する 2. テストでバグを絞込み特定する TEST_F(TestMacroWord, test_macrodata_macroword bug21) MacroData macrodata; macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); MacroWordProxy::wordCount(macroData); EXPECT_EQ(3, MacroWordProxy::getSize(0)); 3. 修正後テストがパスすることを確認する
26 class MacroWord 1. テスト上でバグを再現する 2. テストでバグを絞込み特定する TEST_F(TestMacroWord, test_macrodata_macroword bug21) MacroData macrodata; macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); macrodata.push_back("auto_debug_2"); MacroWordProxy::wordCount(macroData); EXPECT_EQ(3, MacroWordProxy::getSize(0)); 3. 修正後テストがパスすることを確認する バグを再現バグを特定バグ修正のチェック
27 その他ユニットテスト テスト駆動開発 CI による自動回帰テスト RED REFACT OR GREEN
28 ユニットテストの効能 バグを検出する バグ発生箇所を絞り込む バグ混入を監視する 機能的な保証を行う 設計支援を行う ドキュメントとなる
29 ツール 方法論が発達した今ではプログラミングとユニットテストが一体となり プログラマはプログラミングの最初から最後まで継続的にユニットテストのサポートを受けられるようになっている
30 ユニットテストの継続活用 における課題
31 ユニットテストの継続活用においては保守性がクリティカルな問題となりえる保守性に問題を持つユニットテストは 再利用の度に冗長なコストを累積させる
32 可読性の悪いテスト
33 TEST(TestHoge, test_hoge) stringstream ss; int i, j; Inspector inspector("hoge", "fuga"); EXPECT_EQ(false, inspector.isempty()); inspector.pushline("this is test."); inspector.pushline("this is test."); EXPECT_EQ(6, inspector.getwords()); for (j = 0; j < 100; j++) for (i = 0; i < j; i++) ss << j; ss << " "; ss << i; inspector.pushline(ss.str()); EXPECT_EQ(INFO, inspector.getstate()); inspector.addsection(); EXPECT_EQ(j, inspector.getsection()); EXPECT_EQ(0, inspector.runinspection());
34 TEST(TestHoge, test_hoge) stringstream ss; int i, j; Inspector inspector("hoge", "fuga"); EXPECT_EQ(false, inspector.isempty()); inspector.pushline("this is test."); inspector.pushline("this is test."); EXPECT_EQ(6, inspector.getwords()); for (j = 0; j < 100; j++) for (i = 0; i < j; i++) ss << j; ss << " "; ss << i; inspector.pushline(ss.str()); EXPECT_EQ(INFO, inspector.getstate()); inspector.addsection(); EXPECT_EQ(j, inspector.getsection()); EXPECT_EQ(0, inspector.runinspection()); 何を検証しているのか分からない バグはどこにあるのか分からない 正しいのかどうかわからない Assertion Roulette
35 TEST(TestHoge, test_hoge) stringstream ss; int i, j; Inspector inspector("hoge", "fuga"); EXPECT_EQ(false, inspector.isempty()); inspector.pushline("this is test."); inspector.pushline("this is test."); EXPECT_EQ(6, inspector.getwords()); for (j = 0; j < 100; j++) for (i = 0; i < j; i++) ss << j; ss << " "; ss << i; inspector.pushline(ss.str()); EXPECT_EQ(INFO, inspector.getstate()); inspector.addsection(); EXPECT_EQ(j, inspector.getsection()); EXPECT_EQ(0, inspector.runinspection()); テストの再利用コストを増大させる 何を検証しているのか分からない バグはどこにあるのか分からない 正しいのかどうかわからない Assertion Roulette
36 変更性の悪いテスト ( テストコードの重複 / Fragile Test)
37 TEST(testHoge, test_inspectionfuga_piyo) MotorStatus motorstatus(0, 0); MaintenanceData mtdata; MaintenanceType mttype(createregionid(eu)); setinitialdata(mtdata, mttype); InspectionFuga inspector; inspector.set(createmaintenanceinfo(mtdata, mttype), motorstatus); TEST(testHoge, test_inspectionfuga_fuga) MotorStatus motorstatus(-1, 2); MaintenanceData mtdata; MaintenanceType mttype(createregionid(asia)); setinitialdata(mtdata, mttype); InspectionFuga inspector; inspector.set(createmaintenanceinfo(mtdata, mttype), motorstatus);
38 TEST(testHoge, test_inspectionfuga_hoge) MotorStatus motorstatus(133, 232); MaintenanceData mtdata; MaintenanceType mttype(createregionid(japan)); setinitialdata(mtdata, mttype); InspectionFuga inspector; inspector.set(createmaintenanceinfo(mtdata, mttype), motorstatus);
39 TEST(testHoge, test_inspectionfuga_hoge) MotorStatus motorstatus(133, 232); MaintenanceData mtdata; MaintenanceType mttype(createregionid(japan)); setinitialdata(mtdata, mttype); InspectionFuga inspector; inspector.set(createmaintenanceinfo(mtdata, mttype), motorstatus); Fragile Test テストコードの変更箇所も特定困難 製品コードの変更コストが大きい テストが製品コードの変更コストを増大させる テストがテストコードの変更コストを増大させる
40 テストコードもレガシーコード化するユニットテストを継続活用する環境では レガシーコード化したユニットテストは最悪テストの効果をマイナスに反転させる
41 ユニットテストのコストモデル ユニットテスト規模 ユニットテストの利益 ユニットテスト保守コスト 時間 時間 時間
42 ユニットテストのコストモデル ユニットテストの利益 ユニットテスト規模 レガシーコード化 ユニットテスト保守コスト 時間 レガシーコード化 時間 時間
43 ユニットテストのコストモデル ユニットテストの利益 ユニットテスト規模 レガシーコード化 ユニットテスト保守コスト 時間 レガシーコード化 時間 使えないテストの放棄という手段に 時間
44 ユニットテストの継続活用 のための目標
45 目標 ユニットテスト規模 ユニットテストの利益 ユニットテスト運用コスト 時間 時間 保守性改善 時間
46 ユニットテストの保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース
47 ユニットテストの 保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース テスト対象 テスト設計が変更されても テストコードの変更が小さく済む
48 ユニットテストの 保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース テストコードからテストの設計や意図を容易に読み取れる
49 ユニットテストの 保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース 構造軸 : 他のテストメソッド テストクラスの影響を受けない時間軸 : テストの実行順序の影響を受けない
50 ユニットテストの 保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース Setup テスト実行 結果の検証 Teardown の一連の処理が細か粒度で完結している
51 ユニットテストの 保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース テストを実行する処理を完全に自動化できる
52 ユニットテストの 保守性を支える原則 変更に対する堅牢性に優れる 可読性に優れる 独立性に優れる 自己完結している 完全自動化している 細粒度なテストケース テストメソッドが十分に細分化されている
53 ユニットテストの保守性作りこみアプローチ 1. 実装の工夫 2. 構造設計の工夫 3. 設計の工夫
54 ユニットテストの保守性作りこみ アプローチ 1 実装の工夫
55 ユニットテストの実装はプログラミング行為そのものである保守性を高めるパターンを適用し継続的に記述改善する必要がある
56 コードの共通化 重複する記述は共通化する 便利なロジックは汎用化する
57 TEST(Buyer, test_add_samestatus) Buyer buyer; Customer customer1("taro", "Yamada", 15, 2, "HOGE FUGA"); customer1.addcategory(state_active); Customer customer2("taro", "Yamada", 15, 2, "HOGE FUGA HOGEHOGE"); customer2.addcategory(state_active); buyer.add(customer1); buyer.add(customer2); 似た記述が大量に散在 EXPECT_EQ(0, buyer.getsection());
58 TEST(Buyer, test_add_samestatus) Buyer buyer; Customer customer1("taro", "Yamada", 15, 2, "HOGE FUGA"); customer1.addcategory(state_active); Customer customer2("taro", "Yamada", 15, 2, "HOGE FUGA HOGEHOGE"); customer2.addcategory(state_active); buyer.add(customer1); buyer.add(customer2); EXPECT_EQ(0, buyer.getsection()); Parameterized Creation Method 似た記述が大量に散在 Customer createcustomer(string status) Customer customer("taro", "Yamada", 15, 2, status); customer.addcategory(state_active); return customer;
59 TEST(Buyer, test_add_samestatus) Buyer buyer; Customer customer1 = createcustomer("hoge FUGA"); Customer customer2 = createcustomer("hoge FUGA HOGEHOGE"); buyer.add(customer1); buyer.add(customer2); 重複部分を Creation Method で共通化 EXPECT_EQ(0, buyer.getsection()); Parameterized Creation Method Customer createcustomer(string status) Customer customer("taro", "Yamada", 15, 2, status); customer.addcategory(state_active); return customer;
60 TEST(TestItemList, test_itempush) EXPECT_EQ(expectItem.getName(), item.getname()); EXPECT_EQ(expectItem.getID(), item.getid()); EXPECT_EQ(expectItem.getSize(), item.getsize()); TEST(TestItemList, test_itempush) EXPECT_EQ(expectItem2.getName(), item2.getname()); EXPECT_EQ(expectItem2.getID(), item2.getid()); EXPECT_EQ(expectItem2.getSize(), item2.getsize()); 似た記述が大量に散在
61 TEST(TestItemList, test_itempush) EXPECT_EQ(expectItem.getName(), item.getname()); EXPECT_EQ(expectItem.getID(), item.getid()); EXPECT_EQ(expectItem.getSize(), item.getsize()); TEST(TestItemList, test_itempush) EXPECT_EQ(expectItem2.getName(), item2.getname()); EXPECT_EQ(expectItem2.getID(), item2.getid()); EXPECT_EQ(expectItem2.getSize(), item2.getsize()); Custom Assertion 似た記述が大量に散在 #define EXPECT_ITEM_EQ(expect, actual) EXPECT_EQ((expect).getName(), (actual).getname()); EXPECT_EQ((expect).getID(), (actual).getid()+1); EXPECT_EQ((expect).getSize(), (actual).getsize());
62 TEST(TestItemList, test_itempush) EXPECT_ITEM_EQ(expectItem, item); TEST(TestItemList, test_itempush) EXPECT_ITEM_EQ(expectItem2, item2); 重複部分を拡張 Assertion で共通化 Custom Assertion #define EXPECT_ITEM_EQ(expect, actual) EXPECT_EQ((expect).getName(), (actual).getname()); EXPECT_EQ((expect).getID(), (actual).getid()+1); EXPECT_EQ((expect).getSize(), (actual).getsize());
63 可読性の向上 重要なものを目立たせる 適切な名前に置き換える 小さくする
64 Customer customer2("taro", "Yamada", 15, 2, "HOGE FUGA HOGEHOGE"); 何でもいいダミー値 テストしたい値
65 Customer customer2("taro", "Yamada", 15, 2, "HOGE FUGA HOGEHOGE"); 何でもいいダミー値 テストしたい値 Parameterized Creation Method Customer customer2 = createcustomer("hoge FUGA HOGEHOGE"); ダミー値を隠し 重要なパラメータを強調する重要なものを目立たせる 隠ぺいはトレードオフなので要注意
66 TEST(testHoge, test_fuga) MotorStatus motorstatus(133, 232); InspectionFuga inspector; inspector.set(createmaintenanceinfo(motorstatus); EXPECT_EQ(START, inspector.getstate()); EXPECT_EQ(true, inspector.isempty()); inspector.initialize(); EXPECT_EQ(INFO, inspector.getstate()); EXPECT_EQ(false, inspector.isempty());
67 TEST(testHoge, test_fuga) InspectionFuga inspector = createinspectionfugadummy(); EXPECT_EQ(START, inspector.getstate()); EXPECT_EQ(true, inspector.isempty()); inspector.initialize(); EXPECT_EQ(INFO, inspector.getstate()); EXPECT_EQ(false, inspector.isempty()); 重複部分をメソッドに抜き出す
68 TEST(testHoge, test_fuga_constractor) InspectionFuga inspector = createinspectionfugadummy(); EXPECT_EQ(START, inspector.getstate()); EXPECT_EQ(true, inspector.isempty()); TEST(testHoge, test_fuga_initialize) InspectionFuga inspector = createinspectionfugadummy(); inspector.initialize(); EXPECT_EQ(INFO, inspector.getstate()); EXPECT_EQ(false, inspector.isempty()); テストメソッドを小さくする 意図を読み取りやすい名前をつける
69 ユニットテストの実装はプログラミング行為そのものである保守性を高めるパターンを適用し継続的に記述改善する必要がある
70 ユニットテストの保守性作りこみ アプローチ 2 構造設計の工夫
71 ユニットテストのテストコードは Assertionのリストではないテストコードも構造を持ち それがユニットテストの保守性に影響を与えるため 構造設計の視点が必要になる
72 内部設計
73 テストのツリー構造 ユニットテスト Test Suite Test Suite Test Case Test Case Assertion Assertion
74 テストのツリー構造 細粒度 可読性 ユニットテスト Assertion Test Case Assertion Test Suite Test Suite Test Case 少数の Assertion で TestCase を構成する (1 条件 /1テストケースなどテスト設計の最小構成単位を反映 ) テスト設計やテストの意図が分かりやすくなる
75 テストのツリー構造 ユニットテスト 独立性 自己完結性の確保 Test Suite 独立 無干渉 Test Suite Test Case 独立 無干渉 Test Case Assertion Assertion 変更や流用の影響を局所化できる
76 テストのツリー構造 可読性など Test Suite: テスト対象 Class = n : 1 Fixture/ 外部コンポーネント等で分離通常は 1:1 ユニットテスト Test Suit Test Suit 構造に対する網羅を チェックしやすくする Test Case Test Case Assertion Assertion
77 ユニットテストの内部構造は一般的にツリー構造をとるそこで葉のコンパクト化 枝の独立性向上 適切な分割を進めることでモジュール性や可読性が向上し ユニットテストの保守性が作りこまれる
78 外部インターフェース設計
79 外部インターフェース 外部コンポーネントは保守性を低下させるリスクになる テスト テスト テスト対象 外部 IF ブラックボックス
80 外部インターフェース 外部コンポーネントは保守性を低下させるリスクになるブラックボックスを介してテストが結合 テスト テスト テスト対象 外部 IF ブラックボックス 状態を持つ
81 ユニットテストの保守性を損なう外部コンポーネントは 外部インターフェースの改善で分離する必要がある 外部コンポーネントを使用しないテスト Stub や Mock など 外部コンポーネントを使用するテスト 外部コンポーネント テスト対象
82 構造設計による改善
83 ユニットテストの内部構造や外部インターフェースはその保守性に影響するため 構造設計 アーキテクチャ設計を俯瞰的に洗練する視点が要求される ただし留意点が 2 つある
84 1: 柔軟なズームアウト / ズームインが必要 ユニットテストを継続活用する場合 ユニットテストはしばしばボトムアップに実装されるため 構造設計は実装状況に応じて柔軟に行わなければならない 構造設計 ズームアウト ズームイン 実装
85 2: 改善対象として製品コード / テストコードを区別しない ユニットテストの障害は 製品コード / テストコード両方から除去する 両者のインターフェースを統合的に洗練させる
86 class CameraCtrl void CameraCtrl::hoge() _motorctrl.run(); void CameraCtrl::fuga() _motorctrl.stop(); 外部コンポーネントを制御 テスト対象が外部コンポーネントに依存している 構造設計 実装
87 Test Suite テストが外部コンポーネントを共有している CameraCtrl 構造設計 ズームアウト MotorCtrl ( 外部コンポーネント ) 実装
88 Test Suite Test Suite 外部コンポーネント Mock や Stub 等 テスタビリティの作りこみ CameraCtrl 外部コンポーネントを置換可能にする 構造設計 実装
89 Test Suite Test Suite MotorCtrl Dependency Injection CameraCtrl 構造設計ズームイン実装 void CameraCtrl::CameraCtrl() _motorctrl.open(...):... void CameraCtrl::CameraCtrl(MemoryCtrl memoryctrl) _motorctrl = motorctrl; _motorctrl.open(...):...
90 右以外のテスト Mock Stub 等 外部コンポーネントを用いるテスト MotorCtrl Dependency Injection CameraCtrl 実装 構造設計
91 ユニットテストのテストコードは Assertionのリストではないテストコードも構造を持ち それがユニットテストの保守性に影響を与える継続的な構造設計の改善で テストの保守性を高めよう
92 実装 構造設計の参考図書 xunit Test Patterns Refactoring Test Code 読書会サイトに翻訳情報あり < xutp 読書会 で検索
93 ユニットテストの保守性作りこみ アプローチ 3 設計の工夫
94 設計の工夫 1. テスト設計を洗練する 2. トップダウンのテスト設計で保守性を作りこむ
95 テスト設計の洗練
96 ユニットテストの継続的活用 においての留意点 作りすぎたテストを継続的に保守しようとすると保守性に悪影響を与える テストコード 製品コード void Hoge() 製品コードを変更すると大量のテストがビルドエラー TEST( ) EXPECT_EQ(, Hoge()); TEST( ) EXPECT_EQ(, Hoge()); TEST( ) EXPECT_EQ(, Hoge()); テスト設計を変更すると修正が複数にまたがる
97 保守性を高めるにはコンパクトなテストで十分な網羅性を確保する必要があるその実現にテスト設計技法やテスティングリテラシーの素養は有効である
98 境界値分析 入出力値をグルーピング ( 例えば同値分割 ) して グループの境界の値を抽出する 欠陥が境界付近に偏在するという経験則に立脚
99 境界値分析 6 歳未満は無料 6 歳以上 12 歳以下は半額 13 以上は定額
100 境界値分析 6 歳未満は無料 6 歳以上 12 歳以下は半額 13 以上は定額 - + ありえない -1 0 無料 半額 13 定額
101 カバレッジ分析 制御フローの網羅度を基準にテスト設計を行う
102 カバレッジ分析 start 入力 : ループ回数 任意の回数ループ end
103 カバレッジ分析 start 入力 : ループ回数 任意の回数ループ カバレッジレベル 6(C6) テストで用いるループ回数 : 0 回 1 回頻出する代表値最大回 end
104 テストの目的に応じて柔軟に 設計技法を使い分ける 仕様 テスト設計 その他 コード構造
105 テストの目的に応じて柔軟に 設計技法を使い分ける 仕様 4で割り切れる N Y Y Y 100で割り切れる N N Y Y 400で割り切れる N N N Y うるうどし N Y N Y 機能的な保証テストファースト etc.. テスト設計 その他 コード構造 // うるう年か判定する bool isleapyear(unsigned int year) if (year % 400 == 0) return true; if ((year % 4 == 0) && (year % 100!= 0)) return true; return false; 機械的なリファクタリングテスタビリティの評価 etc..
106 テストの目的に応じて柔軟に 設計技法や考え方を応用する 任意の値でいいけど取り合えず境界値を指定しよう TEST( ) EXPECT_EQ(?,?); 仕様が厳密なので仕様ベースのテスト設計ですまそう 仕様が不明だけど単純な分岐構造なので C3 のテストを用意してリファクタリングしよう /** 詳細な関数仕様 */ void fuga( ) bool hoge(unsigned int year) if (year % 400 == 0) return true; if ((year % 4 == 0) && (year % 100!= 0)) return true; return false;
107 テスト設計の技法や考え方のレパートリーが増えればより洗練されたテストが書けるようになり ユニットテストの保守性向上につながる
108 テスト設計技法 参考図書
109 2. トップダウンのテスト設計で 保守性を作りこむ
110 テスト設計フロー テストコード実装フロー テスト設計フロー テストコードの構造設計 テスト設計 テストコードの実装 テスト実装 ユニットテストの継続的活用におけるテスト設計フロー
111 テスト設計フロー テスト設計 テスト条件 テスト設計技法等を整理するテストケースを求める 等 テスト実装 テストケースの選定を行うテストに用いる具体値を求める 等
112 俯瞰的なテスト設計もユニットテストの保守性の作りこみに有効であるテストコードの構造設計と同様 柔軟なズームアウト / ズームインで洗練されたテスト設計を組み込もう
113 テスト条件の抽出による 外部インターフェースの洗練 テストコード実装フロー テスト設計フロー テストコードの構造設計 テスト設計 テストコードの実装 テスト実装 ユニットテストの継続的活用におけるテスト設計フロー
114 2. トップダウンでインターフェース設計 1. テスト条件を抽出 DB スタブ 通常テスト UART スタブ DB テスト DB UART テスト UART テスト条件リスト DB タッチパネル メカニカルボタン UART 通信. ユニットテストの制約となる テストコードの実装外部コンポーネントを抽出し 構造設計に反映させるテスト設計プロセス テストコードの構造設計 テスト設計 テストコードの実装 テスト実装 全体整合のとれた外部インターフェースを構築
115 テスト対象の安定度分析による ユニットテストの作りこみ テストコード実装フロー テスト設計フロー テストコードの構造設計 テスト設計 テストコードの実装 テスト実装 ユニットテストの継続的活用におけるテスト設計フロー
116 2. 変更リスクの少ないテストを作りこみ 1. テスト対象の安定度評価 ストの品質 ゴールとなる水準 Hoge Fuga Piyo 1 ファイル 変更 step/week Hoge.cpp 0 2 Fuga.cpp 23 3 PIyo.cpp 133 開発時間 安定したプログラムユニットを抽出し イテレーティブなユニットテストの作りこみに反映するテストコードの実装テスト設計プロセス テストコードの構造設計 テスト設計 テストコードの実装 テスト実装 テストの作りすぎによるデメリットを軽減する
117 テストコードと同じく テスト設計も上位構造を持つ保守性の障害となるテスト条件や制約 テスト設計の抽象構造を抽出し 下位の設計に反映させていこう
118 まとめ
119 ユニットテストの実装はプログラミング行為そのもの保守性を高めるパターンを適用し 継続的に記述改善しよう
120 テストコードはAssertの羅列ではない保守性に優れたアーキテクチャ 構造をテストコードに持たせようまた構造のズームアウト / ズームインを柔軟に行って 継続的にテストコードの設計を改善させていこう
121 テスト設計はテストコードの保守性を左右する保守性に優れたテストを書けるように テスト設計技法 リテラシーをどんどん身につけようまたテスト設計でも柔軟にズームイン / ズームアウトを行い トップダウンでテスト設計の改善をすすめよう
122 ご清聴ありがとうございました
テスト駆動開発入門 ネクストステップ
テスト駆動開発入門 ネクストステップ 井芹洋輝 謝辞 主催の今給黎さん 和田さん 会場提供 スタッフの方々 参加者の皆さま 深くお礼申しあげます 自己紹介 井芹洋輝 (@goyoki/id:goyoki) 組み込みエンジニア WACATE 実行委員 /TDD 研究会 講演 / 執筆 : XP 祭り関西 ユニットテストの保守性を作りこむ Androidテスト祭り テストの活用による開発効率化 並カン
テスト駆動開発入門
テスト駆動開発入門 ハンズオン講座 goyoki 概要 イントロダクション ハンズオン課題 1 TDDの概要 定義 / 手順 / 利益など ハンズオン課題 2 ソフトウェアテストとしてのTDD 後編について 以下は後編で扱う予定です TDDが抱える課題 レガシーコード上でのTDD テストコードの改善 TDDで確保したテストコードの活用 TDDの諸目的 イントロダクション テスト駆動開発 (TDD)
040402．ユニットテスト
2. ユニットテスト ユニットテスト ( 単体テスト ) ユニットテストとはユニットテストはプログラムの最小単位であるモジュールの品質をテストすることであり その目的は結合テスト前にモジュール内のエラーを発見することである テストは機能テストと構造テストの2つの観点から行う モジュールはプログラムを構成する要素であるから 単体では動作しない ドライバとスタブというテスト支援ツールを使用してテストを行う
JUnit 概要 2015/4/16 版今泉俊幸 2015 bbreak Systems 1
JUnit 概要 2015/4/16 版今泉俊幸 1 目次 1. 手動テストと自動テスト 2. JUnitの機能 3. 検証用メソッド 4. 基本的なJUnitテストケース 5. 実践的なJUnitテストケース 6. よく使う検証用メソッド 7. テストクラスの命名 配置など 2 手動テスト 手動テストと自動テスト テスト仕様書に基づいて 人手で値を入力 結果を検証する プログラム修正の度に実施するのはコストが高い
メソッドのまとめ
メソッド (4) 擬似コードテスト技法 http://java.cis.k.hosei.ac.jp/ 授業の前に自己点検以下のことがらを友達に説明できますか? メソッドの宣言とは 起動とは何ですか メソッドの宣言はどのように書きますか メソッドの宣言はどこに置きますか メソッドの起動はどのようにしますか メソッドの仮引数 実引数 戻り値とは何ですか メソッドの起動にあたって実引数はどのようにして仮引数に渡されますか
2 概要 市場で不具合が発生にした時 修正箇所は正常に動作するようにしたけど将来のことを考えるとメンテナンス性を向上させたいと考えた リファクタリングを実施して改善しようと考えた レガシーコードなのでどこから手をつけて良いものかわからない メトリクスを使ってリファクタリング対象を自動抽出する仕組みを
メトリクス利用によるリファクタリング対象の自動抽出 ローランドディー. ジー. 株式会社 第 4 開発部 SC02 小林光一 e-mail:kouichi.kobayashi@rolanddg.co.jp 2 概要 市場で不具合が発生にした時 修正箇所は正常に動作するようにしたけど将来のことを考えるとメンテナンス性を向上させたいと考えた リファクタリングを実施して改善しようと考えた レガシーコードなのでどこから手をつけて良いものかわからない
Visual Studio と.NET Framework 概要 Runtime Libraries Languag es Tool.NET Visual Studio 概要 http://download.microsoft.com/download/c/7/1/c710b336-1979-4522-921b-590edf63426b/vs2010_guidebook_pdf.zip 1.
スライド 1
SPI Japan 2013 in 東京 Software Product Line の実践 ~ テスト資産の構築 ~ 住友電工情報システム株式会社 QCD 改善推進部品質改善推進グループ服部悦子 2013.10.17 P.1/24 目次 1. テスト資産構築に至る背景 2. テスト資産の構築 ~ 自動テストの実現 ~ 3. 結果と評価 P.2/24 テスト資産構築に至る 背景 P.3/24 背景
Microsoft PowerPoint - ●SWIM_ _INET掲載用.pptx
シーケンスに基づく検索モデルの検索精度について 東京工芸大学工学部コンピュータ応用学科宇田川佳久 (1/3) (2/3) 要員数 情報システム開発のイメージソースコード検索機能 他人が作ったプログラムを保守する必要がある 実務面での応用 1 バグあるいは脆弱なコードを探す ( 品質の高いシステムを開発する ) 2 プログラム理解を支援する ( 第 3 者が書いたコードを保守する ) 要件定義外部設計内部設計
システム操作インターフェイス最適化によるテスト自動化ROI向上
システム操作インターフェイス最適化によるテスト自動化 ROI 向上 株式会社 Codeer 石川達也 e-mail:ishikawa-tatsuya@codeer.co.jp ご相談を受けた企業様の悩みで多いもの システムテスト自動化やったことあるんだけど 効果が出なくて 作業と ROI 要素を分析 仕様変更等でメンテ 作成 成功 指定のケースではデグレがなかったという情報を取得できた! エラー!
CodeRecorderでカバレッジ
株式会社コンピューテックス Copyright 2016 Computex Co.,Ltd. 2017.11 カバレッジ と 単体テスト カバレッジとは プログラムがどれだけ実行されているかを示す指標です プログラム全体に対して実行された比率をカバレッジ率で表します カバレッジの基準として 一般的にC0 C1が使われております C0カバレッジは 全体のうち何 % が実行されたかで求めます C1カバレッジは
智美塾 ゆもつよメソッドのアーキテクチャ
ゆもつよメソッドのテスト要求分析とテストアーキテクチャ設計 JaSST13 東京智美塾 2013 年 1 月 30 日 湯本剛 ( 日本 HP) tsuyoshi.yumoto@hp.com ゆもつよ風テスト開発プロセス テスト計画 実現したい品質の具体的把握 テスト箇所の選択 テストの目的設定 テスト対象アイテム特定 テスト分析 テストタイプ特定 機能の整理 & 再分類 テスト条件となる仕様項目特定
An introduction and future of Ruby coverage library
Ruby の テストカバレッジ 測定機能の 改良と展望 クックパッド株式会社遠藤侑介 yusuke-oh@cookpad.com RubyWorld Conference 2017 (2017/11/01) 発表概要 発表内容 カバレッジとは カバレッジとの付き合い方 Ruby でのカバレッジ測定方法 クックパッドでのカバレッジ利用事例 発表者について フルタイム Ruby コミッタ (2017/09~)
IBM i ユーザーの課題 モバイルや IOT に対応した新しい開発案件への対応 RPG COBOL など既存アプリのメンテナンス 要員の確保 属人化しない運用 管理体制 2
Arcad ご紹介資料 三和コムテック株式会社 IBM i ユーザーの課題 モバイルや IOT に対応した新しい開発案件への対応 RPG COBOL など既存アプリのメンテナンス 要員の確保 属人化しない運用 管理体制 2 情報資産の継承と継続 24h365d 監視運用保守 Power プラットフォーム & クラウド Web インターフェースの利用モバイル対応 逆コンパイルソースコンバージョン 既存業務アプリケーション
どのような便益があり得るか? より重要な ( ハイリスクの ) プロセス及びそれらのアウトプットに焦点が当たる 相互に依存するプロセスについての理解 定義及び統合が改善される プロセス及びマネジメントシステム全体の計画策定 実施 確認及び改善の体系的なマネジメント 資源の有効利用及び説明責任の強化
ISO 9001:2015 におけるプロセスアプローチ この文書の目的 : この文書の目的は ISO 9001:2015 におけるプロセスアプローチについて説明することである プロセスアプローチは 業種 形態 規模又は複雑さに関わらず あらゆる組織及びマネジメントシステムに適用することができる プロセスアプローチとは何か? 全ての組織が目標達成のためにプロセスを用いている プロセスとは : インプットを使用して意図した結果を生み出す
<4D F736F F F696E74202D20835C CC967B8EBF2E B8CDD8AB B83685D>
ソフトウェアテストの本質を振り返る 43 Agenda ソフトウェアテストとは ソフトウェアのテスト技法とは 技法の振り返り 同値分割法 境界値分析 デシジョンテーブルテスト CFD 法 まとめ 44 1 ソフトウェアテストとは? 1. 欠陥を検出する 検出した欠陥を修正すれば ソフトウェアの品質が確保できる 2. 対象となるソフトウェアの品質レベルが十分であることを確認し その情報を示す 適切に設計したテストを実施して欠陥が検出されなければ
システム操作インターフェイス最適化によるテスト自動化ROI向上
SQiP2014 システム操作インターフェイス最適化によるテスト自動化 ROI 向上 Improvement in test automation ROI by system manipulation interface optimization 石川達也 Ishikawa-tatsuya@codeer.co.jp 株式会社 Codeer 発表要旨 : 本発表ではシステムテストを自動化する際に アプリケーションをテストプログラムから操作するインターフェイスを最適化する手法と
intra-mart Accel Platform — イベントナビゲータ 開発ガイド 初版 None
クイック検索検索 目次 Copyright 2013 NTT DATA INTRAMART CORPORATION 1 Top 目次 intra-mart Accel Platform イベントナビゲータ開発ガイド初版 2013-07-01 None 改訂情報概要イベントフローの作成 更新 削除をハンドリングするイベントフローを非表示にする回答を非表示にするリンクを非表示にするタイトル コメントを動的に変更するリンク情報を動的に変更するナビゲート結果のリンクにステータスを表示する
intra-mart Accel Platform — イベントナビゲータ 開発ガイド 初版
Copyright 2013 NTT DATA INTRAMART CORPORATION 1 Top 目次 intra-mart Accel Platform イベントナビゲータ開発ガイド初版 2013-07-01 改訂情報概要イベントフローの作成 更新 削除をハンドリングするイベントフローを非表示にする回答を非表示にするリンクを非表示にするタイトル コメントを動的に変更するリンク情報を動的に変更するナビゲート結果のリンクにステータスを表示する
Microsoft PowerPoint - A1-2_株式会社ネクスト_藤澤正通_S _005.pptx
SQiP シンポジウム 2012 ページオブジェクトパターンによる 動テストメンテナンスの効率化 株式会社ネクスト HOMEʼS事業本部 サービス推進部 品質管理グループ 藤澤 正通 FujisawaMasamichi@next-group.jp 1 動化への取組み 2011 年 4 : リグレッションテストの 動化検討を開始 6 :Selenium IDE を採 動化に着 7 : 機能カバレッジ
Oracle Un お問合せ : Oracle Data Integrator 11g: データ統合設定と管理 期間 ( 標準日数 ):5 コースの概要 Oracle Data Integratorは すべてのデータ統合要件 ( 大量の高パフォーマンス バッチ ローブンの統合プロセスおよ
Oracle Un お問合せ : 0120- Oracle Data Integrator 11g: データ統合設定と管理 期間 ( 標準日数 ):5 コースの概要 Oracle Data Integratorは すべてのデータ統合要件 ( 大量の高パフォーマンス バッチ ローブンの統合プロセスおよびSOA 対応データ サービスへ ) を網羅する総合的なデータ統合プラットフォームです Oracle
SQiP シンポジウム 2016 アジャイルプロジェクトにおけるペアワーク適用の改善事例 日本電気株式会社小角能史 2016 年 9 月 16 日 アジェンダ 自己紹介ペアワークとはプロジェクトへのペアワークの適用方法 スクラム適用ルール作成 最適化の流れ KPTを用いたふりかえり 適用ルールの改善事例 適用プロジェクトの概要ペアワーク適用ルール ( 初期 ) 改善例 1 - ペアのローテーション改善例
Microsoft PowerPoint - A3② JaSST_MISRA2004ソースコード品質診断.ppt
ISO/IEC9126 & MISRA-C:2004 ベースソースコード品質診断 ~ MISRA-C:2004 ベース品質診断のご紹介 ~ 株式会社東陽テクニカソフトウェア ソリューション MISRA とは Motor Industry Software Reliability Association の略 ヨーロッパ自動車技術会 (MIRA) の下部組織 MIRA: Motor Industry
過去問セミナーTM
ALTM 過去問題解説 May 22, 2017 JSTQB Technical Committee 委員長谷川聡 Agenda 試験問題の出題について K2 TM-4.4.1 欠陥マネジメント K3 TM-2.7.2 テストマネジメント K4 TM-2.3.3 テストマネジメント 勉強を進めていくにあたって 2 試験問題の出題について 学習の目的 (L.O) に従ってシラバスのそれぞれの課題を試験する
PowerPoint プレゼンテーション
ソフトウェア品質シンポジウム 15 継続的システムテストについての 理解を深めるための 開発とバグのメトリクスの分析 15/9/18 荻野恒太郎 kotaro.ogino@mail.rakuten.com Test Engineering Team Service Support Section Group Core Service Department http://www.rakuten.co.jp/
プログラミング入門１
プログラミング入門 1 第 5 回 繰り返し (while ループ ) 授業開始前に ログオン後 不要なファイルを削除し て待機してください Java 1 第 5 回 2 参考書について 参考書は自分にあったものをぜひ手元において自習してください 授業の WEB 教材は勉強の入り口へみなさんを案内するのが目的でつくられている これで十分という訳ではない 第 1 回に紹介した本以外にも良書がたくさんある
ML 演習 第 4 回
ML 演習第 4 回 おおいわ Mar 6, 2003 今回の内容 補足 Ocaml のモジュールシステム structure signature functor Ocaml コンパイラの利用 2 識別子について 利用可能文字 先頭文字 : A~Z, a~z, _ ( 小文字扱い ) 2 文字目以降 : A~Z, a~z, 0~9, _, 先頭の文字の case で 2 つに区別 小文字 : 変数,
個人依存開発から組織的開発への移行事例 ~ 要求モデル定義と開発プロセスの形式化 による高生産性 / 高信頼性化 ~ 三菱電機メカトロニクスソフトウエア ( 株 ) 和歌山支所岩橋正実 1
個人依存開発から組織的開発への移行事例 ~ 要求モデル定義と開発プロセスの形式化 による高生産性 / 高信頼性化 ~ 三菱電機メカトロニクスソフトウエア ( 株 ) 和歌山支所岩橋正実 iwahashi@est.hi-ho.ne.jp Iwahashi.Masami@wak.msw.co.jp 1 改善効果 品質 : フロントローディングが進み流出不具合 0 継続生産性 : 平均 130% 改善 工数割合分析
効率の良いテストシナリオ? テストの進め方 テストプロセス テストの設計 より少ないテストケースで より多くのバグを見つける Mercury Interactive Japan KK all rights reserved. 2
効率の良いテストシナリオ -ソフトウェアテスト ミーティング - マーキュリー インタラクティブ ジャパン ( 株 ) 小崎将弘 効率の良いテストシナリオ? テストの進め方 テストプロセス テストの設計 より少ないテストケースで より多くのバグを見つける Mercury Interactive Japan KK all rights reserved. 2 応する工程単体テスト対開発工程とソフトウェアテスト
デベロッパーテスティング ソフトウエア開発者の基礎体力
デベロッパーテスティング ~ ソフトウエア開発者の基礎体力 タワーズ クエスト株式会社プログラマ兼取締役社長和田卓人 2006 年 6 月 29 日 @ オブジェクト倶楽部 2006 夏イベント 自己紹介の前に 4 年前の出来事 ワールドカップ イングランド vs. アルゼンチンの日 IBM のイベント テスト関係のセッション そこで出会った人は 故石井勝さん (a.k.a masarl さん )
スライド 1
Test Driven Development Visual Studio 2008 でやる テスト駆動開発 2008/04/26 biac http://bluewatersoft.cocolog-nifty.com/ 機材協力 : 日本ンフォメーション 自己紹介 山本康彦 ( biac ) いまだにプログラムを書きたがる 50 歳 http://bluewatersoft.cocolog-nifty.com/blog/cat8051143/
トレーニングのプレゼンテーション
XDDP の概要について (Vol.0.1) 2012 年 10 月 18 日佐藤創 Rights Reserved. 1 更新履歴 版数日付内容担当 0.1 2012/10/18 新規作成佐藤創 Rights Reserved. 2 XDDP とは? Rights Reserved. 3 XDDP とは? XDDP(eXtreme Derivative Development Process) 主に組込み系の派生開発の作り込み品質の向上を目的とした
intra-mart Accel Platform — IM-Repository拡張プログラミングガイド 初版
Copyright 2018 NTT DATA INTRAMART CORPORATION 1 Top 目次 1. 改訂情報 2. はじめに 2.1. 本書の目的 2.2. 対象読者 2.3. サンプルコードについて 2.4. 本書の構成 3. 辞書項目 API 3.1. 最新バージョン 3.1.1. 最新バージョンの辞書を取得する 3.2. 辞書項目 3.2.1. 辞書項目を取得する 3.2.2.
JBoss と Arquillian で実現する 究極のテスト環境 レッドハット株式会社 JBoss サービス事業部 コンサルタント 山 田義和
JBoss と Arquillian で実現する 究極のテスト環境 レッドハット株式会社 JBoss サービス事業部 コンサルタント 山 田義和 Who am I? Hi, I m glad to see you! 2 Arquillian??? インテグレーションテストのための テスティングプラットフォーム http://www.jboss.org/arquillian.html 3 テスティングプラットフォーム?
発表内容 背景 コードクローン 研究目的 4 つのテーマ 研究内容 テーマ毎に, 概要と成果 まとめ 2
2012 年度ソフトウェア工学分野の先導的研究支援事業 コードクローン分析に基づくソフトウェア開発 保守支援に関する研究 大阪大学大学院情報科学研究科 楠本真二 1 発表内容 背景 コードクローン 研究目的 4 つのテーマ 研究内容 テーマ毎に, 概要と成果 まとめ 2 研究背景 ソフトウェアシステムは社会基盤として必須のもの. 現代社会で人々の日々の暮らしを支える 例 : 銀行オンラインシステム
Using VectorCAST/C++ with Test Driven Development
ホワイトペーパー V2.0 2018-01 目次 1 はじめに...3 2 従来型のソフトウェア開発...3 3 テスト主導型開発...4 4...5 5 TDD を可能にするテストオートメーションツールの主要機能...5 5.1 テストケースとソースコード間のトレーサビリティー...5 5.2 テストケースと要件間のトレーサビリティー...6 6 テスト主導型開発の例...7 2 1 はじめに 本書では
15288解説_D.pptx
ISO/IEC 15288:2015 テクニカルプロセス解説 2015/8/26 システムビューロ システムライフサイクル 2 テクニカルプロセス a) Business or mission analysis process b) Stakeholder needs and requirements definieon process c) System requirements definieon
PowerPoint プレゼンテーション
JaSST 16 Tokyo テクノロジーセッション AUTOSAR Acceptance Test の自動化の取り組み 株式会社ベリサーブ オートモーティブ検証サービス開発部 須原秀敏 1 自己紹介 項目 所属 内容 株式会社ベリサーブ 名前須原秀敏 ( すはらひでとし ) 経歴 車載電子機器 ( 以後 ECU) のシステムテストを 6 年 活動 SNS WACATE STAC JaSST SQiP
Oracle Business Rules
Oracle Business Rules Manoj Das(manoj.das@oracle.com) Product Management, Oracle Integration 3 Oracle Business Rules について Oracle Business Rules とはビジネスの重要な決定と方針 ビジネスの方針 実行方針 承認基盤など 制約 有効な設定 規制要件など 計算 割引
Microsoft PowerPoint - Session4古賀様.ppt
Windows Embedded CE の テスト環境と活用 マイクロソフト Windows Embedded Partner ( 株 ) サムシングプレシャス代表取締役社長古賀信哉 普段の開発の立ち位置 はじめに ミドルウェア層の開発が主 (DLNA 関連など ) 必要に応じてデバイスドライバ ( カーネルモジュール ) 概要 特定ターゲット向けの BSP も 開発環境及び開発環境を用いた動作確認
HIGIS 3/ﾌﾟﾚｾﾞﾝﾃｰｼｮﾝ資料/J_GrayA.ppt
品質保証部における W モデル適用の検討と実践 2013/09/13 株式会社日立製作所情報 通信システム社 IT プラットフォーム事業本部開発統括本部プラットフォーム QA 本部ソフト品質保証部 富田貴仁, 秦泉寺貴文, 高山啓 0 品質保証部における W モデル適用の検討と実践 Contents 1. 章はじめに 2. 章現状の品質保証工程の分析 3. 章 Wモデルの適用の検討 4. 章実施と評価
短納期開発現場への XDDP 導入手法
短納期開発現場への XDDP 導入手法 日本科学技術連盟ソフトウェア品質管理研究会 2012 年度第 6 分科会 B グループ 富士ゼロックスアドバンストテクノロジー株式会社南迫祐樹 メンバー紹介 2/18 日本科学技術連盟ソフトウェア品質管理研究会 2012 年度第 6 分科会 B グループ < 主査 > 清水吉男 < 副主査 > 飯泉紀子 足立久美 株式会社システムクリエイツ
スライド 1
OSC2008Tokyo/Fall CodeIgniter を使った MyNETS2 の概要 日付 2008/10/04 発表者 株式会社エムズリンク辻岡国治 copy rights All Right Reserved. -2008 基本ベースは WEB 会員管理システム 会員登録されているかの判定を行う 会員向けページ リクエスト DB 非会員向けページ copy rights All Right
Exam : 1z1-809-JPN Title : Java SE 8 Programmer II Vendor : Oracle Version : DEMO Get Latest & Valid 1z1-809-JPN Exam's Question and Answers 1 from Ac
Actual4Test http://www.actual4test.com Actual4test - actual test exam dumps-pass for IT exams Exam : 1z1-809-JPN Title : Java SE 8 Programmer II Vendor : Oracle Version : DEMO Get Latest & Valid 1z1-809-JPN
PowerPoint プレゼンテーション
5 月 Java 基礎 1 タイトル Java 基礎 2 日間 概要 目的 サーバサイドのプログラミング言語で最もシェアの高い Java SE の基本を習得します 当研修ではひとつの技術ごとに実用的なアプリケーションを作成するため 効果的な学習ができます Java SE の多くの API の中で 仕事でよく利用するものを中心に効率よく学びます 実際の業務で最も利用される開発環境である Eclipse
プログラミング実習I
プログラミング実習 I 05 関数 (1) 人間システム工学科井村誠孝 m.imura@kwansei.ac.jp 関数とは p.162 数学的には入力に対して出力が決まるもの C 言語では入出力が定まったひとまとまりの処理 入力や出力はあるときもないときもある main() も関数の一種 何かの仕事をこなしてくれる魔法のブラックボックス 例 : printf() 関数中で行われている処理の詳細を使う側は知らないが,
目次 1: 安全性とソフトウェア 2: 宇宙機ソフトウェアにおける 安全 とは 3:CBCS 安全要求とは 4: 宇宙機ソフトウェアの実装例 5: 安全設計から得た新たな知見 6: 今後 2
宇宙機ソフトウェアにおける 安全要求と設計事例 宇宙航空研究開発機構 (JAXA) 情報 計算工学センター (JEDI) 梅田浩貴 (Hiroki Umeda) 目次 1: 安全性とソフトウェア 2: 宇宙機ソフトウェアにおける 安全 とは 3:CBCS 安全要求とは 4: 宇宙機ソフトウェアの実装例 5: 安全設計から得た新たな知見 6: 今後 2 1.1 安全性とは 安全性と信頼性の違いの例開かない踏切りは
IronPython による柔軟なゲーム開発 筑波大学 AmusementCreators
IronPython による柔軟なゲーム開発 筑波大学 AmusementCreators 自己紹介 Amusement Makers ではありません 注意 IronPython って?.Net Framework および Mono 上で動作する Python.NetFramework Mono は共通中間言語 (CIL) のための仮想マシン CIL が動く仮想マシンの仕様は共通言語基盤 (CLI)
文字列操作と正規表現
文字列操作と正規表現 オブジェクト指向プログラミング特論 2018 年度只木進一 : 工学系研究科 2 文字列と文字列クラス 0 個以上の長さの文字の列 Java では String クラス 操作 文字列を作る 連結する 文字列中に文字列を探す 文字列中の文字列を置き換える 部分文字列を得る 3 String クラス 文字列を保持するクラス 文字列は定数であることに注意 比較に注意 == : オブジェクトとしての同等性
ＪａｖａプログラミングⅠ
Java プログラミング Ⅱ 10 回目への出力 ストリーム ストリームとは入力または出力の流れをもつデータの連鎖ですストリームは異なる機器からのデータを統一的に扱う考え方です 文字ストリーム 文字ベースの入出力をサポートします - Unicode(Java 内部 ) とローカルコード (Java 外部 ) の変換が行われ プログラマはその違いを意識しなくてすみます バイトストリームバイナリデータの入出力をサポートします
はじめてのコンコリックテスト
JaSST 15 Tokai はじめてのコンコリックテスト ~ 基本原理から知るホワイトボックステストの新技術とその応用 ~ 2015 年 11 月 6 日植月啓次 はじめに コンピュータの処理能力の飛躍的な向上により プログラムコードにたいする解析技術は大きく進化しています 近年 実用段階に入り盛り上がりを見せている解析技術およびその応用技術が コンコリックテスト (Concolic Test)
デザインパターン第一章「生成《
変化に強いプログラミング ~ デザインパターン第一章 生成 ~ 梅林 ( 高田明宏 )@ わんくま同盟 デザインパターンとは何か (1) デザインパターンの定義 ソフトウェア開発におけるデザインパターンとは 過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し 名前をつけ 再利用しやすいように特定の規約に従ってカタログ化したもの (Wikipedia) 参考書籍 オブジェクト指向における再利用のためのデザインパターン
Secure iNetSuite for .NET 4.0Jの新仕様について
Secure inetsuite for.net 4.0J の新仕様について グレープシティ株式会社 2013 年 8 月初版 メール送受信とファイル転送機能を実現する通信コンポーネント Secure inet Suite の通信モードの仕様が新しくなりました 本資料では従来のバージョンとの違いとメリットをコードを使って詳しく解説します はじめに 2013 年 9 月発売の Secure FTP for.net
Visual Studio 2013 による単体テスト 2014 Microsoft Corporation. All rights reserved. 1
Visual Studio 2013 による単体テスト 2014 Microsoft Corporation. All rights reserved. 1 目次 Visual Studio 2013 による単体テスト... 1 1.1. テスト自動化の重要性... 4 1.2. 単体テストの基本的な手順... 7 1.3. カバレッジ分析を活用した単体テスト... 17 1.4. Fake を利用した高度な単体テスト...
Microsoft Word - Training10_プリプロセッサ.docx
Training 10 プリプロセッサ 株式会社イーシーエス出版事業推進委員会 1 Lesson1 マクロ置換 Point マクロ置換を理解しよう!! マクロ置換の機能により 文字列の置き換えをすることが出来ます プログラムの可読性と保守性 ( メンテナンス性 ) を高めることができるため よく用いられます マクロ置換で値を定義しておけば マクロの値を変更するだけで 同じマクロを使用したすべての箇所が変更ができるので便利です
Boost.Preprocessor でプログラミングしましょう DigitalGhost
Boost.Preprocessor でプログラミングしましょう DigitalGhost http://d.hatena.ne.jp/digitalghost/ http://twitter.com/decimalbloat 私のこと hatena のプロフィールとか 見てください とりあえず FizzBuzz 書いてみた #define FIZZBUZZ_OP(z, n, d) \ FIZZBUZZ_OP_I(
Microsoft Visual Studio 2010 Professional Data Sheet
Microsoft Visual Studio 2010 Professional はビジネスの要件やユーザ ーのニーズに最適なアプリケーションを選択し それを構築するために必須の機能を提供します RIA ベースのリッチな Web アプリケーション SharePoint ベースの高度な Web ポータル Windows Azure ベースのクラウドアプリケーションなど 最新テクノロジに対応したアプリケーションを既存の知識や経験を活かして開発することができます
このルールをそのまま正規表現として書くと 下記のようになります ^A[0-9]{2}00[0-9]{3}([0-9]{2})?$ ちょっと難しく見えるかもしれませんが 下記のような対応になっています 最初 固定 年度 固定 通番 ( 枝番 ) 最後 ルール "A" 数字 2 桁 0 を 2 桁 数字
![このルールをそのまま正規表現として書くと 下記のようになります ^A[0-9]{2}00[0-9]{3}([0-9]{2})?$ ちょっと難しく見えるかもしれませんが 下記のような対応になっています 最初 固定 年度 固定 通番 ( 枝番 ) 最後 ルール A 数字 2 桁 0 を 2 桁 数字](/thumbs/84/90379032.jpg "このルールをそのまま正規表現として書くと 下記のようになります ^A[0-9]{2}00[0-9]{3}([0-9]{2})?$ ちょっと難しく見えるかもしれませんが 下記のような対応になっています 最初 固定 年度 固定 通番 ( 枝番 ) 最後 ルール A 数字 2 桁 0 を 2 桁 数字")
正規表現について 作成日 : 2016/01/21 作成者 : 西村 正規表現? 正規表現 (Regular Expression Regex) というと難しいもののように感じますが 正規表現 というのは 文字のパターンを表したもの です ( 例 ) これはソエルで使用している見積書の番号です A1500033 この番号は 下記のルールで付けられています 固定 年度 固定 通番 ( 枝番 ) ルール
メソッドの外部設計とテストファースト
メソッドの外部設計と テストフゔースト ~ 上手く TDD するために ~ 2009.9.12 biac http://www.tdd-net.jp/ 自己紹介 山本康彦 ( biac ) いまだにプログラムを書きたがる 52 歳 http://bluewatersoft.cocolog-nifty.com/ ハンドルでぐぐってもらえば見つかる ( 経済産業諮問委員会じゃないほう ) 名古屋のとある
TestDesign for Web
発行日 2012/6/21 発行元 株式会社アープ 本書は Web でのテスト自動化における Test Design の一連の操作方法まとめたものです Test Design のメニューの説明やより詳細な使い方については ユーザーズガイド を参照してください 目次 1. はじめに... 1 2. 環境構築... 2 2.1. Selenium のサイトについて... 2 2.2. Selenium
Visual Studio2008 C# で JAN13 バーコードイメージを作成 xbase 言語をご利用の現場でバーコードの出力が必要なことが多々あります xbase 言語製品によっては 標準でバーコード描画機能が付加されているものもあるようで す C# では バーコードフォントを利用したりバー
Visual Studio2008 C# で JAN13 バーコードイメージを作成 xbase 言語をご利用の現場でバーコードの出力が必要なことが多々あります xbase 言語製品によっては 標準でバーコード描画機能が付加されているものもあるようで す C# では バーコードフォントを利用したりバーコード OCX や バーコード対応レ ポートツールが豊富にありますので それほど困ることは無いと思われます
8 / 0 1 i++ i 1 i-- i C !!! C 2
C 2006 5 2 printf() 1 [1] 5 8 C 5 ( ) 6 (auto) (static) 7 (=) 1 8 / 0 1 i++ i 1 i-- i 1 2 2.1 C 4 5 3 13!!! C 2 2.2 C ( ) 4 1 HTML はじめ mkdir work 作業用ディレクトリーの作成 emacs hoge.c& エディターによりソースプログラム作成 gcc -o fuga
<4D F736F F F696E74202D DD8D8782ED82B98B5A8F7082F B582BD835C F E707074>
プロセス改善ベストプラクティス ( テスト ) ワークショップ 組み合わせ技術利用したテストケース生成ツールと適用事例の紹介 2009 年 3 月 27 日東芝ソフトウェア技術センター小笠原秀人 中野隆司 Copyright 2009, Toshiba Corporation. すべてをテストすることはできない 論理的な問題 組み合わせが膨大 バグがこれで最後と証明することができない コスト 時間の問題
基礎プログラミング2015
応用プログラミング 第 5 回 テキスト入力処理 2017 年 10 月 18 日 ( 水 ) 第 7 章 テキスト入力処理 1 文字ずつの処理 (P.58) char 型などに入力する cin >> x や fin >> x はホワイトスペースが読み飛ばされる仕様 ホワイトスペース : スペース ( 空白 ), Tab( タブ ), 改行 // sample.cpp char ch; while(cin
プログラミング入門１
プログラミング入門 1 第 6 回 Switch 文 プロジェクトの持ち運び 授業開始前に ログオン後 不要なファイルを削除し て待機してください Java 1 第 6 回 2 前回のテーマ while 文を用いた繰り返し実行 for 文との使い分け 複雑な条件判定 && かつ または を使って Java 1 第 6 回 3 復習 : while 文はfor 文から 初期化式 を外に出し ステップを進める式
はじめてのPFD
はじめての PFD 派生開発 WG アンリツエンジニアリング株式会社文書番号 :AE-RAEB00000063 初版 Copyright 2016 Anritsu Engineering Co.,Ltd. Publicly available 演習概要 PFDの書き方 : 15 分 演習 : 30 分 + 発表 ( 講評 ) 20 分 まとめ 2 参考文献 PFD(Process Flow Diagram)
フローチャート自動生成ツール yflowgen の使い方 目次 1 はじめに 本ツールの機能 yflowgen.exe の使い方 yflowgen.exe の実行方法 制限事項 生成したファイル (gml ファイル形式 ) の開
フローチャート自動生成ツール yflowgen の使い方 目次 1 はじめに...2 2 本ツールの機能...2 3 yflowgen.exe の使い方...3 3.1 yflowgen.exe の実行方法...3 3.2 制限事項...3 3.3 生成したファイル (gml ファイル形式 ) の開き方...4 3.3.1 yed Graph Editor を使って開く...4 3.3.2 yed
プログラミング基礎
C プログラミング Ⅰ 授業ガイダンス C 言語の概要プログラム作成 実行方法 授業内容について 授業目的 C 言語によるプログラミングの基礎を学ぶこと 学習内容 C 言語の基礎的な文法 入出力, 変数, 演算, 条件分岐, 繰り返し, 配列,( 関数 ) C 言語による簡単な計算処理プログラムの開発 到達目標 C 言語の基礎的な文法を理解する 簡単な計算処理プログラムを作成できるようにする 授業ガイダンス
Rmenuフレームワーク
ジェネレーティブプログラミングの世界 データマッピングフレームワーク Rmenu 特徴プログラムから データとプロセスを完全分離 疑問本当にデータとプロセスが完全分離できるのか? どんな仕組みで業務システムが動くのか? 日本オフィスクリエイション株式会社下地忠史 2014 年 2 月 15 日 Agenda 1. アプリケーションの基本 2.Json の特徴を利用した項目移送 3. アプリケーションのデータフロー
目次 ペトリネットの概要 適用事例
ペトリネットを利用した状態遷移テスト 和田浩一 東京エレクトロン SDC FA グループ 目次 ペトリネットの概要 適用事例 ペトリネットの概要 - ペトリネットとは ペトリネット (Petri Net) とは カール アダム ペトリが 1962 年に発表した離散分散システムを数学的に表現する手法である 視覚的で 数学的な離散事象システムをモデル化するツールの一つである ペトリネットの概要 - ペトリネットの表記と挙動
基礎計算機演習 実習課題No6
実習課題 No.6 課題は 3 題ある. 課題 6-1 時間内提出 次の実行例のように, 名簿を出力するプログラムをつくりたい. このプログラムでは, まず人数をたずね, 次にその人数分の名前を入力し, それを再びコンソールに出力する. なお, 空の名前が入力されても終了せずにその欄は空欄で出力するものとする. 注意とヒント この課題では,string 型の配列をまず宣言する. このとき, 配列の要素はちょうど名簿に入力する人数分だけを宣言すること
プログラミングA
プログラミング A 第 5 回 場合に応じた処理 繰り返し 2019 年 5 月 13 日 東邦大学金岡晃 場合に応じた処理 1 こういうプログラムを作りたい 5 教科のテスト 100 点以上各科目の点数の合計が 100 点未満 おめでとう! これで 100 点越えのプレゼントを獲得! というメッセージを出力 残念!100 点越えのプレゼントまであと ** 点! というメッセージを出力 5 教科の点数の合計が
はじめに 原因結果グラフ技法を学ぼう まずは 原因結果グラフ について解説します 例題を使って 原因結果グラフ を描いてみます 演習問題のグラフを作ってみよう まずは一人で描いてみよう 近くの人とグラフの違いを見比べてみよう ツールを使って使ってみよう 支援ツール CEGTest を使って 演習問題
原因結果グラフ技法を学んでみよう! 使ってみよう! 2010 年 7 月 2 日加瀬正樹 ( ニフティ株式会社 ) はじめに 原因結果グラフ技法を学ぼう まずは 原因結果グラフ について解説します 例題を使って 原因結果グラフ を描いてみます 演習問題のグラフを作ってみよう まずは一人で描いてみよう 近くの人とグラフの違いを見比べてみよう ツールを使って使ってみよう 支援ツール CEGTest を使って
f2-system-requirement-system-composer-mw
Simulink Requirements と新製品 System Composer によるシステムズエンジニアリング MathWorks Japan アプリケーションエンジニアリング部大越亮二 2015 The MathWorks, Inc. 1 エンジニアリングの活動 要求レベル システムレベル 要求分析 システム記述 表現 高 システム分析 システム結合 抽象度 サブシステム コンポーネントレベル
Java講座
~ 第 1 回 ~ 情報科学部コンピュータ科学科 2 年竹中優 プログラムを書く上で Hello world 基礎事項 演算子 構文 2 コメントアウト (//, /* */, /** */) をしよう! インデントをしよう! 変数などにはわかりやすい名前をつけよう! 要するに 他人が見て理解しやすいコードを書こうということです 3 1. Eclipse を起動 2. ファイル 新規 javaプロジェクト
テスト設計コンテスト
テスト設計コンテスト 17 話題沸騰ポット (GOMA-1015 型 ) テスト設計 目次 Page 2/25 1. はじめにチーム紹介チームの立ち位置テスト設計の流れ 2. テスト要求分析テスト要求分析の流れ仕様把握と機能要求分析非機能要求分析因子水準表 3. テストアーキテクチャ設計アーキテクチャ設計の流れテストアーキテクチャ全体俯瞰図機能アーキテクチャ非機能アーキテクチャシステム全体俯瞰図 4.
2. 目的 1RationalRose を利用する場合にプログラム仕様書としての最低限必要な記述項目を明確にする 2 プログラム仕様書として記載内容に不足がない事をチェックする 3UML の知識があるものであれば 仕様書の内容を理解できること 4Rose にて入力した内容を SoDaWord を利用
プログラム仕様書 (UML 表記法 ) ガイドライン 本仕様書に UML(Rational Rose 使用 ) を用いてプログラム仕様書を作成する際のガイドラインを記す 1. ドキュメントの様式について 1 ドキュメントは制御単位で作成する 2 表紙 及び変更履歴は SWS にて指定されたものを付加すること 3 下記の目次内で指定している UML 図 記述項目は必須項目とする 4SoDa にてドキュメントを出力する場合は
C#の基本
C# の基本 ~ 開発環境の使い方 ~ C# とは プログラミング言語のひとつであり C C++ Java 等に並ぶ代表的な言語の一つである 容易に GUI( グラフィックやボタンとの連携ができる ) プログラミングが可能である メモリ管理等の煩雑な操作が必要なく 比較的初心者向きの言語である C# の利点 C C++ に比べて メモリ管理が必要ない GUIが作りやすい Javaに比べて コードの制限が少ない
28th Embarcadero Developer Camp
RAD Studio で実践する 継続的インテグレーション アプリとデベロッパーの価値 を拡張するエッセンス 長沢 智治 テクニカル エバンジェリスト アトラシアン株式会社 re-workstyle.com @tomohn ビジネスとアプリケーションの進化 90s 00s Business 10s Business Business Apps Apps Apps C/S コード品質 開発者中心 分業
D5-2_S _003.pptx
JaSST 14 Tokyo セッション D5-2 10:30~11:00(30 分 ) キーワード駆動テストを用いた GUI テスト自動化による工期短縮実現への取り組み 2014 年 3 月 8 日 株式会社 NTT データ 技術開発本部プロアクティブ テスティング COE 小林由依 0. 自己紹介 n 氏名 Ø 小林由依 n 所属 Ø 株式会社 NTT データ技術開発本部 プロジェクトマネジメント
NEXCESS基礎コース01 組込みソフトウェア開発技術の基礎 ソフトウェア開発プロセス編
JaSST 12 Tokai SIG テストエンジニアだからこそ気を付けるテスト仕様書と報告書の書き方 2012 年 11 月 30 日 山本雅基 (ASDoQ/ 名古屋大学 ) E-mail: myamamoto@nces.is.nagoya-u.ac.jp 1 トイレは いつ行ってもいい 気楽に 自己紹介 16:10-16:20 お話 16:20-16:40 個人作業 16:40-16:55 グループ作業
(1) プログラムの開始場所はいつでも main( ) メソッドから始まる 順番に実行され add( a,b) が実行される これは メソッドを呼び出す ともいう (2)add( ) メソッドに実行が移る この際 add( ) メソッド呼び出し時の a と b の値がそれぞれ add( ) メソッド
メソッド ( 教科書第 7 章 p.221~p.239) ここまでには文字列を表示する System.out.print() やキーボードから整数を入力する stdin.nextint() などを用いてプログラムを作成してきた これらはメソッドと呼ばれるプログラムを構成する部品である メソッドとは Java や C++ などのオブジェクト指向プログラミング言語で利用されている概念であり 他の言語での関数やサブルーチンに相当するが
デバッグの工夫
バグを減らす デバッグの工夫 ~ プログラミング実習で生き残るために ~ 2013/02/12 金森由博 よくあるプログラミングの風景 課題めんどくさい とりあえず適当に書くか エラーチェック めんどくさい あとまわし ちゃんと動くかわかんないけど全部書いちゃお ふー やっと全部書けた コンパイルしよ!? エラーメッセージの意味がわからん!! はぁ やっとコンパイルが通った 実行しよ えっ!? なんでセグメンテーション違反!?
A Bit flipping Reduction Method for Pseudo-random Patterns Using Don’t Care Identification on BAST Architecture
29 年 2 月 4 日日本大学大学院生産工学研究科数理情報工学専攻修士論文発表会 BAST アーキテクチャにおけるランダムパターンレジスタント故障ドントケア抽出を用いた擬似ランダムパターンのビット反転数削減法に関する研究 日本大学院生産工学研究科数理情報工学専攻万玲玲 背景 概要 BAST アーキテクチャ 目的と提案手法 ハンガリアンアルゴリズム ランダムパターンレジスタント故障検出用ドントケア抽出法
PowerPoint プレゼンテーション
GSN を応用したナレッジマネジメントシステムの提案 2017 年 10 月 27 日 D-Case 研究会 国立研究開発法人宇宙航空研究開発機構 研究開発部門第三研究ユニット 梅田浩貴 2017/3/27 C Copyright 2017 JAXA All rights reserved 1 目次 1 課題説明 SECI モデル 2 GSN を応用したナレッジマネジメントシステム概要 3 ツリー型チェックリスト分析
プログラミングA
プログラミング A 第 5 回 場合に応じた処理 繰り返し 2017 年 5 月 15 日 東邦大学金岡晃 前回の復習 (1) このプログラムを作成し実行してください 1 前回の復習 (2) このプログラムを作成し実行してください 2 前回の復習 (3) 3 前回の復習 演算子 代入演算子 インクリメント シフト演算子 型変換 4 場合に応じた処理 5 こういうプログラムを作りたい 5 教科のテスト
ビッグデータ分析を高速化する 分散処理技術を開発 日本電気株式会社
ビッグデータ分析を高速化する 分散処理技術を開発 日本電気株式会社 概要 NEC は ビッグデータの分析を高速化する分散処理技術を開発しました 本技術により レコメンド 価格予測 需要予測などに必要な機械学習処理を従来の 10 倍以上高速に行い 分析結果の迅速な活用に貢献します ビッグデータの分散処理で一般的なオープンソース Hadoop を利用 これにより レコメンド 価格予測 需要予測などの分析において
基礎プログラミング2015
応用プログラミング 第 4 回 ファイル操作 2017 年 10 月 11 日 ( 水 ) 第 6 章 ファイル操作 標準入出力とファイル (P.50) これまでのプログラム 入力 : キーボード 出力 : ディスプレイ Input an integer 1024 1024 標準入出力とファイル (P.50) 今回のプログラム 入力 : ファイル ( の内容 ) 出力 : ファイル Input a
GEC-Java
Copyright (C) Junko Shirogane, Waseda University 2019, All rights reserved. 1 プログラミング初級 (Java) 第 14 回継承 白銀純子 第 14 回の内容 継承 オーバーライド ポリモーフィズム Copyright (C) Junko Shirogane, Waseda University 2019, All rights
ソフトウェアテストプロセスに関する一考察 － Ｖ ⇒ Ｗ ⇒ Ｖ３ －
ソフトウェアテストプロセスに関する一考察ー V W V3 W ー 小川秀人 ( 株式会社日立製作所 ) ソフトウェアテストシンポジウム 2007 東京 2007 年 1 月 30 日 モチベーション 自己紹介 ( 主に ) 大規模組込みソフトウェアを対象とした開発技術の研究 開発プロセス, アーキテクチャ, コーディング, テスト 種々の製品やプロジェクトに対して技術開発 導入 問題意識 違う組織に行くと,
Java知識テスト問題
Java 知識テスト SDAS プログラマ(Java 編 ) 運営事務局 このテストは J2EE プログラマとしての Java の知識を評価するものです 問題は 30 問, テスト時間は J2EE 知識テストとあわせて 90 分です 問題は全て択一式です 選択肢から 1 つだけ選択してください 資料の閲覧は禁止です テストが終わり次第 答案用紙を提出していただいてかまいません テスト終了後, 本テストの内容を他の方に話さないでください
Agenda 1. 本コースで学習したこと 2. 挑戦 3. テスト対象アプリケーションソフト 4. テスト分析 - マインドマップ 5. テスト実施内容 1. 同値分割 境界地分析 2. All-Pair 法 3. 状態遷移 4. CFD 法 5. シナリオテスト 6. まとめ 2
ソフトウェアテスト演習コース Ⅱ 2011.2.25 Member 主査 : 堀田文明 ( 有 ) デバッグ工学研究所副主査 : 小池利和ヤマハ ( 株 ) 構成員 : 秋山友秀 キヤノンソフトウェア ( 株 ) 阿部祐輔 株式会社インテック 小野寺秀利 ソニー ( 株 ) 発表者 佐藤光紀 ( 株 ) 日本オープンシステムズ 清水剛史 株式会社ユニケソフトウェアリサーチ 高塚大作 株式会社 NTTデータ三洋システム
(Microsoft PowerPoint - Java\221\3462\225\224\211\357\224\255\225\\\216\221\227\ ppt)
システム開発における 生産性の検証 平成 19 年度 OISA 技術研究会 JAVA 第 2 部会 1 2008.02.19 目次 1. 部員紹介 2. 生産性向上に向けて 3.Seasar2 4. テストプログラムによる検証 5. 考察 6. まとめ 2 1. 部員紹介 3 部員紹介 葛城啓之 ( 株式会社オーイーシー ) 工藤寿彦 ( 九州東芝エンシ ニアリンク 株式会社 ) 白石和稔 ( 大銀コンヒ
アスペクトの相互作用を解消するアスペクトの提案
アスペクトの相互作用を解消する アスペクトの提案 武山文信千葉滋東京工業大学大学院情報理工学研究科数理 計算科学専攻 2009/03/11 武山文信, 千葉滋, アスペクトの相互作用を解消するアスペクトの提案 @PPL2009 in 高山 1/21 アスペクト指向プログラミング (AOP) 横断的関心事をアスペクトとしてモジュール化 オブジェクト指向 (OOP) では上手く分離できない クラス階層に
Microsoft PowerPoint - 09.pptx
情報処理 Ⅱ 第 9 回 2014 年 12 月 22 日 ( 月 ) 関数とは なぜ関数 関数の分類 自作関数 : 自分で定義する. ユーザ関数 ユーザ定義関数 などともいう. 本日のテーマ ライブラリ関数 : 出来合いのもの.printf など. なぜ関数を定義するのか? 処理を共通化 ( 一般化 ) する プログラムの見通しをよくする 機能分割 ( モジュール化, 再利用 ) 責任 ( あるいは不具合の発生源
PowerPoint プレゼンテーション
BRMS への取り組みと導入事例 2013 年 11 月 15 日 ( 金 ) SCSK 株式会社 IT エンジニアリング事業本部ミドルウェア部 本日の内容 BRMS 適用のポイント BRMS の可能性 Page 1 Page 2 アプリケーション連携基盤 SCSKのRed Hat JBoss / ミドルウェア技術に関する取り組みの取り組み 世界のオープンソース コミュニティーから製品化されたソフトウェア
文字コード略歴 よこやままさふみ社内勉強会 2012/05/18 文字コード略歴 Powered by Rabbit 2.0.6
文字コード略歴 よこやままさふみ社内勉強会 2012/05/18 自己紹介 横山昌史 入社 4 年目 プログラマ etc... 所属プロジェクト Java UNIX 雑用 etc... 文字コードの " るつぼ " Rabbit について プレゼンテーションツール 実装 : Ruby/GTK 動作 : UNIX/Win/Mac 文章とデザインの分離 バージョン管理しやすい 文字コードとは 文字をコンピュータで扱うための符号化方式
Oracle Enterprise Linux 5における認証
Oracle Enterprise Linux 5 における認証 ORACLE Oracle Enterprise Linux 5 Oracle Enterprise Linux 5 は Red Hat Enterprise Linux 5 と完全互換 ( ソース バイナリとも ) Oracle Enterprise Linux 5 は完全 kabi 準拠 オープン ソースとしてご利用いただける Oracle
Microsoft PowerPoint - sakurada3.pptx
チュートリアル :ProVerif による結合可能安全性の形式検証 櫻田英樹日本電信電話株式会社 NTT コミュニケーション科学基礎研究所 アウトライン 前半 :ProVerif の紹介 後半 :ProVerifを用いた結合可能安全性証明 [Dahl Damgård, EuroCrypt2014, eprint2013/296] の記号検証パート 2 ProVerif フランス国立情報学自動制御研究所
JaSST'16 Tokai 特別講演
システムテスト自動化の技法 小井土亨 アジェンダ システムテスト GUIテスト自動化 キーワード駆動テスト システム自動テストのアーキテクチャ システムテストの自動化について 2016.12.02 システムテスト 1. システムテスト 2. エンドツーエンドテスト 3. システムテストの自動化について システムテスト開発プロセス内のシステムテストの位置づけ 要求定義 要求のテスト システムの導入 受け入れテスト