![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
#author("2019-03-08T16:09:41+09:00","","") #author("2019-03-08T16:10:15+09:00","","") [[吉富]] *Goal [#x170d127] *研究のイメージ [#x170d127] -ソフトウェアテストは，ソースコードが期待通りに機能するか検証するために実施される．しかしながら，作成したテストコードには欠陥が混入する可能性があり，多くの開発者がテストコードはプロダクトコードよりも欠陥を含む可能性が高いと述べられている --テストコードはソースコードと同量かそれ以上の量を記述するのが望ましいとも言われている．． --テストコードに欠陥が混入すると，欠陥が見逃されたり，プロダクトコードに問題がないにもかかわらずテストが失敗することがある． -W. Cunninghamは，テストコードの欠陥が原因で生じる問題を以下の2つに分類している． --1．偽陰性(Silent Horror)：テストコードに欠陥があるためにテストが成功する．すなわちプロダクトコードの欠陥を見逃している． --2．偽陽性(False Alarm)：テストコードに欠陥があるためにテストが失敗する．すなわちプロダクトコードに欠陥は混入していない． -偽陰性はテスターが発見しにくいため．のちに品質に問題があることが判明し，手戻りコストがかかる恐れがある． -対象プロジェクトとしてApacheの10プロジェクトを使用する．ASFのプロジェクト中でテストコードの欠陥数が多いプロジェクトである(Vahabzadehらの分析を参照)． *本研究によって解決される問題 [#f62e1bd2] -テストの欠陥がどの程度の影響を与えるのか？ *興味あり用件 [#m5eb250e] -TravisCIについての本が無いので、自分で書いてしまうのも面白い（ネットの説明では不十分・煩雑で使いにくい。また、ビルドツールとの連携方法が微妙） -テストスメルとテストの欠陥にはどのような関係性があるのか？検出する際の指標になりうるのか？ * B4ミーティング [#hb323ab0] -毎週木曜13:00〜 * 独習コーナー [#hb323ab0] -[[吉富/Java独習]] *研究会参加 [#x170d127] -ソフトウェアエンジニアリングシンポジウム2018 IPSJ/SIGSE Software Engineering Symposium (SES2018) 開催日程：2018年9月5日(水)〜9月7日(金) ワークショップ日：2018年9月5日(水) 開催場所：東洋大学 白山キャンパス --査読なし一般論文 ＋ ポスター展示 --〆切: 2018年7月27日(提出済み) --提出原稿(PDF) : &attachref(ses2018_silenthorrors.pdf); -FOSE2018 第２５回ソフトウェア工学の基礎ワークショップ 日程: 2018年11月15日（木）- 17日（土） 場所: 函館湯の川温泉 花びしホテル（北海道函館市） --【カテゴリ3】ポスター・デモ発表 --〆切: 2018年9月22日(採択決定) --発表用ポスター(PDF) : &attachref([FOSE2018]Yoshitomi.pdf); -IWESEP2018 The 9th International Workshop on Empirical Software Engineering in Practice 日程：2018年12月4日(火) 場所：奈良市春日野町101 奈良春日野国際フォーラム 甍〜I・RA・KA〜 --ポスター発表 --発表用ポスター(PDF) : &attachref(?富_IWESEP2018.pdf); *研究会参加目標 [#o93cce52] * 活動報告 [#hb323ab0] **3/07 [#u173fc05] -白浜研修・テーマ決め **1/25 [#u173fc05] -目視完了 **1/10 [#u173fc05] -サイレントホラーの目視開始(JCR) **1/08 [#meac75ba] -サイレントホラーの目視開始(ACCUMULO) **1/3 [#meac75ba] -316プロジェクトのBUDATAの取得開始 **1/2 [#qe58d88a] -SilentHorrordataを取得 -卒論に対して --1・２・3・６章の内容追加 **12/27 [#ia897c1c] -作戦会議 --動機を何にするのか:Silent HorrorとFalse Alarmsに関するExtended Study -Silent Horrorがどのようなインパクトをもたらすのか？ --クリティカルなバグが発見できるのかどうか？ **12/25 [#we176558] -データセットをApacheプロジェクト全体にした(447プロジェクト) --データセットとして使えるのは316プロジェクト **12/22〜24 [#i25d4e99] -データの収集 -Silent horror detecter --対象プロジェクトを10に拡張-->分析 -BUGDATAの収集 --対象プロジェクトを10に拡張 **12/21 [#y4522d3a] -卒論２章を改編 --ソフトウェアテストとは？ --不具合管理システムについて --ソフトウェアテストにおける不具合とは **12/20 [#r537a720] -バグデータの収集 --Hadoop_HDFS・Jackrabbit **12/19 [#fb997b6f] -バグデータの収集 --Accumulo・Derby **12/15・16 [#p70727f6] -卒業論文について --目次の作成 --２章について ---ソフトウェアテストとは ---ソフトウェアテストにおける欠陥について **12/14 [#g0e037dd] -先生と柏さんの３人で会議 --偽陰性をどのように定義するのか？ **12/13 [#j35ffe97] -バグ番号の割り当て(derby) -%%derbyの検証(５０件)%% **12/12 [#ue044785] -%%バグ番号の割り当て(accumulo)%% -%%accumuloの検証(５０件)%% **12/11 [#uef7cf4f] -バグ番号の割り当て作業開始(jackrabbit・hadoop-hdfs・accumulo・derby) --※jackrabbitとhadoop-hdfsは柏さんが担当 **12/10 [#jdc6487f] -ベン図の作成．およびTexでアルゴリズムを記述 **12/07 [#i909aa59] -土日のタスク --今週に作成したJavaソースコードに対して，JUnitのテストを作成．JUnitで自分のコードが正しいかをチェックし，Aizu onlineJudgeに投げる．エラーを吐いた場合はJUnitに間違いがある(テストバグがどのような場合に発生するのかを実感する) **12/03 [#xdea003b] -興味がある論文 --Works For Me! Characterizing Non-reproducible Bug Reports(pdf)：&attachref(mona-msr14.pdf); --Automated Detection of Test Fixture Strategies and Smells(pdf)：&attachref(TUD-SERG-2013-021.pdf); --Finding Bugs is Easy(pdf)：&attachref(p132-hovemeyer-3.pdf); **11/28 [#hd5d1da0] -今週のタスク --%%ポスター作成%% --%%ポスター発表に向けた原稿作成%% --%%柏さんの偽陰性抽出ツールを理解する%% ---JAVAのコードを理解できるように，コードを書く練習から **11/21 [#f223bcda] -今日のタスク --%%Derbyの欠陥報告IDを収集できる状態にする%% --卒論：既存研究の内容を書き進める(今週中で既存研究の章は書き終わらせる) **11/20 [#u98111f8] ***Done [#ae6772ff] -DERBYの全てのバグを抽出できる状態になった -DERBYのテストコードのバグの一覧を抽出できた ***Todo [#l4e6a377] -プロダクトコードとテストコードを同時に修正しているコミットを抽出する **11/05 [#w01d0956] -やることリスト -13日、15日用にコミットログ、OPEN〜CLOSEDまでの日付、欠陥内容及びパッチ内容をリスト化する -ソフトウェアテスト及び既存研究用いる参考文献を読み、卒論の肉付けをする **11/01 [#w01d0956] -進捗状況 --(pdf)：&attachref(進捗状況【11月01日 (木) 】.pdf); **10/27 [#w01d0956] -テストの独立性や依存性について論文に書く方が良いかもしれない --「Empirically Revisitingthe Test Independence Assumption」を読む **10/18 [#o37376e7] -既存研究の項目を書き進めている -目的とリサーチクエスチョンを考えてみた --(pdf)：&attachref(進捗状況【10月18日】.pdf); **10/15 [#jd1b1c3a] -「Software Unit Test Coverage and Adequacy」によると，ソフトウェアテストには３つのアプローチがある --構造テスト ---プログラムまたは使用の構造における要素の特定での観点からテスト要件を指定 --欠陥ベースのテスト ---ソフトウェアテストのフォルト(すなわち欠陥)の検出に焦点をあてる．この手法の妥当性の基準は，テストセットの障害検出能力の測定 --エラーベースのテスト ---プログラムが一般的に仕様からどのように逸脱しているかについて企業での知識に従い，エラーの起こりやすい点についてプログラムをチェックするテストケース が必要 -偽陰性について「癌検査における偽陽性と偽陰性の違い」という記事を発見 --https://qiita.com/steel_code/items/101c9d037d5e8c2b7876 --偽陰性と偽陽性の説明の参考にできるかも？ -卒業論文を書き始めた **10/11 [#vaae4417] ***Done [#ud083772] ***Todo [#jcfe6b06] -研究の目的を文章で表す -%%TEXの使い方を学ぶ%% **10/03 [#p1f47ae3] ***Done [#pc1faabf] ***Todo [#ga66d8ee] -発生原因が明らかになることで何が解決できるのかを具体的に -卒業論文を書き始める(頭の中の整理をするために) **10/02 [#v3996b30] ***Done [#gfeed5d7] -追加した３項目の分析を始めた **10/01 [#vc193b0e] ***Done [#y0c5aec6] -分析項目を追加した --テストがパスしているか？(Y/N) --Silent Horror(偽陰性)の原因となるテストコードの欠陥であるか？(Y/N) --(上記の２項目を満たしている場合)Silent Horrorの原因となるテストコードの欠陥分類 -新規性は，"Missing Assertion"と"Assertion Fault"以外のカテゴリが発見できるかどうか **9/25 [#za7d7dc4] ***Done [#s5e3c476] -66件目まで目視した． ***Todo [#o7256e6a] -既存研究ではSilent Horrorを"Missing Assertion"と"Assertion Fault"の2種類に分類していたので，今回の目視結果の中でSilent Horrorの原因になったテストコードの欠陥を既存研究の2種類に分け，当てはまらないものは新たなジャンルに分ける． **9/20 [#t3b83631] ***Done [#k05d1fc6] -57件目まで目視した． ***Todo [#c7ff28a0] -来週の研究発表会までに70件の目視を終わらせる **9/10 [#b58d40d3] ***Done [#ua856fbc] -JUnitの応用的な勉強をした -スタブやモックなど，代用を用いた際のテスト手法について学んだ **8/28 [#n664b23f] ***Done [#x716412f] -45件目まで目視 -テストコードに(明らかに)欠陥が見られるタイプは45件中5件 -その他興味深いエラーも見受けられる -"An Empirical Study of Bugs in Test Code"の著者がICSE2018に提出した論文を読んでいる(次回の輪講で発表予定) --内容自体は前内容とは全く異なる(テストコードの冗長性をいかにしてなくすかといった内容の論文) ***Todo [#b69b7ea9] -50件目までは最低でも進めたい -宮崎さんにSESの原稿を託したので，そのサポートをする -院入試が終わって体調が回復したら，TEXの使い方を学習したい **8/21 [#wf6831f4] ***Done [#r18b2d48] -データについて，重複しているデータを発見．正しくはREOPENEDのステータスがつけられたデータは"70"件 -全体の半分の調査が終わった(不明なものや調査に時間がかかりそうなものは後回しにしているが...) -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証2_3.xlsx); -ペースを上げていく(1日5件は調査することを目標に(1〜2週間で終わる計算)) **8/20 [#wf6831f4] -30個目まで進めた **8/06 [#f09d1bf7] ***Done [#v2ee855c] -10個目まで進めた -原因が不明なものが1つ発見された(コメントが少ない上に変更点が少なく判断しにくい) -現在は2回REOPENEDのステータスがつけられたものの分析を行っている(逆にデータが多すぎてしんどそう) ***Todo [#iafaca4b] -%%次に分析するデータベースプロジェクトを決める%% -ガントチャート作ってみる -そろそろ卒論の背景を描いてみてもいいかも -SES2018に向けてポスターを作成する -%%10日までにSES2018の原稿を完成させる(スペルミスはチェック済み)%% -%%お盆休みに入るので最低30個は分析する%% -SES2018において，ワークショップにおいてどのような内容を話すかを決めておく **8/05 [#f09d1bf7] ***Done [#z58bd2a5] -DeFlaker: Automatically Detecting Flaky Testsを読んだ -(pdf)：&attachref(DeFlaker: Automatically Detecting Flaky Tests.pdf); **7/30 [#f09d1bf7] ***Done [#m4e2b879] -論文頑張って書いた -SQLの知識を身につけながらなので，なかなかペースが上がらない -少しずつ分析のやり方がわかってきた -先週の研究発表会＋論文執筆によって，頭の中を整理することができた． **7/23 [#f09d1bf7] ***Done [#m4e2b879] -今回の研究発表会で指摘された内容を見返して，頭の中を整理しなければならない． -思い込みが起きているので，研究の目的を振り返る必要がある． ***Todo [#o9df6c4f] -分析を続ける **7/17〜20 [#neb6cc09] ***Done [#z67b38a3] -SIGSS研究発表会に参加 -熱い議論が交わされ，非常に興味深いものであった． -SIGSS研究会論文概要と所感: &attachref(SIGSS活動報告.rtf); **7/13 [#c0566ac0] ***Done [#nb68fab0] -ICSE勉強会で発表 -統計の勉強はしっかりしておいたほうが良い -ビルドツールについて、自動で原因ファイルを自動で特定するフレームワークReplocが提案されていた -継続的インテグレーションの論文があった！！ **7/11 [#g28a1ac6] ***Done [#z67b38a3] -テストコードを調査中。3つ目が非常に多いので時間がかかっている -(Excel): &attachref(プロダクトコードとテストコードのバグ修正検証2_2.xlsx); ***Todo [#e164709d] - **7/08 [#g28a1ac6] ***Done [#z67b38a3] -研究進捗状況(pdf): &attachref(研究進捗状況４_0.pdf); -ファイルログが非常に多いためログをたどっていくのが大変。テストコードの変更を１つずつ見ていくためコミットが大量にされているものは時間がかかりそう。 **7/05 [#g28a1ac6] ***Done [#z67b38a3] -Excelの項目を追加(なぜ欠陥が見逃されたのか？・テストコードにおける変更内容・ファイルパス・ファイルログ) -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証2_1.xlsx); **7/03 [#g28a1ac6] ***Done [#z67b38a3] -リサーチクエスチョンを考えてみた --RQ1:re-openedにとしてタグ付けされたテストコードは, 再修正される前と後ではどのように変化しているか？ --RQ2:re-openedにタグ付けされたテストコードのバグは(一般的なカテゴリとして)分類することはできるのか？ --RQ3:re-openedにタグ付けされたテストコードで発見されたバグは未発見のバグを発見することができるのか？ **7/02 [#g28a1ac6] ***Done [#z67b38a3] -今後どのように分析を行っていくのか？ -そろそろリサーチクエスチョンを設定すべきか？ ***TODO [#kd1f96e1] -REOPENED前のテストコードとその後のコードを比較する -GITの勉強をする -大まかなリサーチクエスチョンを立ててみる(３年間でやりたいこと) -再修正された原因をみる **6/29 [#g28a1ac6] ***Done [#z67b38a3] -REOPENED(テスト再修正)分析の終了 -リグレッションにおけるテストの失敗が最も多い結果となった -今後はなぜ再修正することになったのか、その原因を探る -リグレッションについて論文を読む必要がある -再修正については大平先生*伊原先生の論文を参考にする(その他再修正に関する論文は適宜参考にしたい) -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証2_0.xlsx); **6/24 [#g28a1ac6] ***Done [#z67b38a3] -REOPENED(テスト再修正)73件を分析中(現在40件) -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証2.xlsx); **6/19 [#g28a1ac6] ***Done [#z67b38a3] -REOPENED(テスト再修正)73件を分析中(現在19件) -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_8.xlsx); ***TODO [#kd1f96e1] -73件の分析を終了させる -とりあえずカテゴリ分けをしてみる **6/13 [#g28a1ac6] ***Done [#z67b38a3] -DERBYの3496件(タグ：Bug 状態：Closed Component/s::Test)を分析、このうちREOPENEDされていたものは73件(2%)存在していた -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_7.xlsx); **6/11 [#g28a1ac6] ***Done [#z67b38a3] -JUnitについて最低限の基礎知識が理解できた -継続的インテグレーションへの応用を行うことができた -今後の対象を発見する際の指標を考えた -研究進捗状況(pdf): &attachref(研究発表スライド3.pdf); **6/07 [#g28a1ac6] ***Done [#z67b38a3] -JUnitを用いて、バグが混入したソースコードに単体テストを実行し、デバッグを行った -Junit入門(pdf)：&attachref(Junit入門【効率的な単体テストの実行】.pdf); -JUnitの使い方の学習は以上とし、以降、ビルドツールの使い方について学習する。 -JUnitとTravisCIを連携させることに成功した(Antを用いて実行成功した) **6/05 [#g28a1ac6] ***Done [#z67b38a3] -JUnitの使い方について概ね理解することができた -Junit入門(pdf)：&attachref(Junit入門【技法の実践方法】_0.pdf); -今回の例はカバレッジも完璧なものでバグも入っていなかったので、次はバグが混入した場合についてどのように対処するのかを学習する **6/04 [#g28a1ac6] ***Done [#z67b38a3] -JUnitの学習を継続中。基本的なところが理解できてきた -Junit入門(pdf)：&attachref(Junit入門【技法の実践方法】.pdf); -「An Empirical Study of Bugs in Test Code」をもう一度読み直し, 忘れていたところや重要な点を再確認した -研究発表会(輪講)の修正版(pdf)：&attachref(An Empirical Study of Bugs in Test Code_0.pdf); --データの抽出について、今回の研究に使えそうな感じがした（バグ管理ツールもJiraを使っているのでちょうど良い） ***TODO [#kd1f96e1] -CCTのテストを試してみる -JUnitの学習を継続。使える段階にはしたい（今後使うことになるので） -Antの使い方, Jiraの見方も合わせて学習する **5/31 [#g28a1ac6] ***Done [#z67b38a3] --Junit入門(pdf)：&attachref(JUnit入門【テストコードを書く】_0.pdf); ---Junitの基本的な使い方についてまとめた **5/29 [#g28a1ac6] ***Done [#z67b38a3] -もう少しでTravisCIが動きそうな気がする -https://github.com/hyo-hyo-tommy **5/28 [#g28a1ac6] ***Done [#z67b38a3] -現地点の状況 -(excel): &attachref(研究発表スライド2.pdf); --→図があまり正確ではない。テストにバグありきの図だけではなくて、テストコードの欠陥が見逃されているのに成功した場合についても記述すべき。 ***TODO [#kd1f96e1] -「An Empirical Study of Bugs in Test Code」の読み直し→来週の輪講で発表する -Derbyを用いる（Apacheプロジェクト） --jiraの見方を学習 --Bugラベル・test・REOPENEDになっているものを探す。（見つけられそうな気がする） -JUnitを勉強する（単体テストについて） -- -Jenkinsとsonarcubeも学習できれば **5/24 [#g28a1ac6] ***Done [#z67b38a3] -TravisCIの使い方についてまとめた -(pdf): &attachref(TravisCI入門.pdf); **5/22 [#g28a1ac6] ***Done [#z67b38a3] -新しいプロジェクトの候補を決めた -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_6.xlsx); -https://jira.sonarsource.com/browse/SONAR-2102?jql=project%20%3D%20SONAR%20AND%20status%20%3D%20Closed%20AND%20text%20~%20%22test%22%20ORDER%20BY%20priority%20DESC -https://issues.apache.org/jira/browse/DERBY-5072?jql=project%20%3D%20DERBY%20AND%20text%20~%20%22test%22 ***TODO [#kd1f96e1] -GithubとtravisCIの学習をする - **5/21 [#g28a1ac6] ***Done [#z67b38a3] -bugラベルが貼り付けられているものを集めた -REOPENされているものの分析を始めた -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_5.xlsx); ***TODO [#kd1f96e1] -Mybatisはまずかったかもしれない -テストの研究が盛んに行われているプロジェクトを研究する **5/17 [#g28a1ac6] ***Done [#z67b38a3] -分析項目を増やした(「テストの誤り」という言葉が曖昧すぎるため、細分化する) -テストコードの欠陥がどのようなものがあるか分類する必要がある -欠陥分類の参考：http://ece.ubc.ca/~arashvhb/testbugs-study/ -enhancementにbugラベルがあるもの、かつclosedしているものを調査するように変更 -テストにも様々な種類があるため、これも細分化する必要あり。 -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_4.xlsx); *** Todo [#hb323ab0] -バグの種類の細分化について学習する -どのようなソフトウェアテスト が行われているのかを分析する **5/14 [#g28a1ac6] ***Done [#z67b38a3] -SIGSS７月研究会@帯広の原稿 -(pdf): &attachref(SIGSS帯広発表原稿_1.pdf); -分析を幾つか進めたが、テストコードに誤りがあるものは発見できなかった。 -別のプログラムで検証する必要がありそう。 -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_3.xlsx); **5/11 [#g28a1ac6] ***Done [#z67b38a3] -「SIGSS７月研究会@帯広」に向けて準備を開始 -現段階の状況をまとめる ***TODO [#kd1f96e1] -論文に記入する項目を口語体で箇条書きする -5月15日〆切。これまでに考えをまとめる **5/7 [#g28a1ac6] ***Done [#z67b38a3] -サンプリングの分析を続行中(Javaの障壁を目の前に足踏みしている状態) -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_2.xlsx); -次次回に発表予定の研究進捗状況 -(pdf): &attachref(研究発表スライド.pdf); -単体テストでは研究対象は見つかりにくいかも -依存関係が複雑なものを探して見ることを考慮すべき *** Todo [#hb323ab0] -引き続き分析を続ける(75個ぐらいまで進んだら一旦ストップ) **5/1 [#g28a1ac6] ***Done [#z67b38a3] -サンプリングの分析を続行中 -わからないものが多数存在する(テストかプロダクトかどちらが先なのかを判断しにくい) -1つ怪しいもの(テストコードにバグが存在すると考えられるもの)を発見した -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_1.xlsx); **4/25 [#g28a1ac6] ***Done [#z67b38a3] -150個のサンプリングを終了 -テストコードの分析を開始 -現地点の状況 -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証_0.xlsx); **4/23 [#g28a1ac6] ***Done [#z67b38a3] -１週間で、プロダクトコードとテストコード共に誤りが見られるものを50個発見した(全体の約1/3のコミットを目視した) -(excel): &attachref(プロダクトコードとテストコードのバグ修正検証.xlsx); ***TODO [#kd1f96e1] -タイプ分けをする(カテゴリ分け) -何をテストされているのかの中身を分析する -さらに検証を進める(最終的には150個くらいのデータは欲しい) **4/17 [#g28a1ac6] ***Done [#z67b38a3] -テストコードとプロダクトコードともに誤りがあるものの調査を開始した。（とりあえずプロダクトコードとテストコードが同時に存在するものを集めた） **4/15 [#g28a1ac6] ***Done [#z67b38a3] -論文の比較を行った（研究の立ち位置を整理する） -(excel): &attachref(論文比較シート.xlsx); ***TODO [#kd1f96e1] -GithubのMybatisにおいて、プロダクトコードとテストコード共に誤りが見られるものを目視で数個発見し説明できるようにまとめる． -SIGSE/SIGSS＠北海道投稿準備 --背景 ---様々なオープンソースプロジェクトの開発が進むなか、多くのプロジェクトでは, 大量のテストコードが開発中にプロダクトコードとともに進化している(A. Zaidman, B. Van Rompaey, A. van Deursen, and S. Demeyer, “Studying the co-evolution of production and test code in open source and industrial developer test processes through repository mining,” Empirical Software Engineering, 16(3), pp. 325-364, June 2011. )。テストコードとプロダクトコードの比が1：1とも報告されている（A. van Deursen, L. Moonen, A. van den Bergh, and G. Kok, “Refactoring test code,” 2nd Int. Conf. on Extreme Programming and Flexible Processes in Software Engineering (XP 2001), 2001. ）このような不具合は信頼性などに対して悪影響を及ぼす。 --先行研究（問題定義） ---プロダクトコードやテストコードそれそれがコミットされた際に発生するバグについて研究がされている。しかし、テストコードの誤りによって発生した誤りについては研究がされていない。本研究では積集合で発生するバグについて目視で発見することを試みる。 --RQ（分析方法） --結果 --考察（議論） **4/13 [#g28a1ac6] ***Done [#z67b38a3] -Java独習を始めた -「Comparing White-box and Black-box Test Prioritization」についてまとめた -(word): &attachref(Comparing White-box and Black-box Test Prioritization_1.docx); -当分の目標を柏先輩のアドバイスを頂いて決定した -目標：GithubのMybatisにおいて、プロダクトコードとテストコード共に誤りが見られるものを目視で発見し、テストコードの意味を理解する。最終的には、このようなケースを自動的に発見できるツールを作る、あるいは、目視と機械的な作業との間にどのくらいの差分があるのかを調査する、など。 -そのために、「基本から学ぶソフトウェアテスト」（理論の理解）、「現場で使えるソフトウェアテスト」（テストコードを実際に作成する）を学ぶ -そのためにJAVAの復習を行う。 **4/10 [#g28a1ac6] ***Done [#z67b38a3] -「Comparing White-box and Black-box Test Prioritization」を読み始めた -(word): &attachref(Comparing White-box and Black-box Test Prioritization_0.docx); - 回帰テストについて調べた -(word): &attachref(回帰テスト.docx); **4/09 [#g28a1ac6] ***Done [#z67b38a3] -ホワイトボックステストについてまとめた -(word): &attachref(ホワイトボックステスト.docx); **4/08 [#g28a1ac6] ***Done [#z67b38a3] -「Automated Static Analysis of Unit Test Code」をまとめた - (word): &attachref(Automated Static Analysis of Unit Test Code.docx); -テストコードを読む練習を始めた（Java）・・・難しい ***メモ [#p6b8c498] -１週間の活動を通じて判明した自分の立ち位置 -ソフトウェアテストに関する研究は全体的に浅く研究はされている。が、深くは研究されていない。特に、面倒な作業が待っている研究については手を触れていないのが現状である。しかし、それこそが最も重要で現状の問題を根本的に解決する可能性のあるものであり、研究が行われるべき部分である。 -また、テストコードに関する研究は、従来はプロダクトコードにばかり注目が集まっていたようであるが、最近はテストコードに関する研究も増加している。「Automated Static Analysis of Unit Test Code」にもあるように、プロダクトコードが発展するにつれてテストコードも同様に発展するが、テストコードで起こるバグは解決しにくいものであり、それでいてこれに問題点があれば意味がないという、非常に複雑な立場にあるものである。学校の期末試験に問題があれば生徒の学力レベルを測ることができないのと同様に、テストコードに問題があれば製品の質は上がらない。 -以上のことより、本研究を完成させることによりテストコードの信頼性が増し、より信頼性のある製品を作るための、品質そのものを保証することに繋がると予想される。 ***TODO [#u688aa92] -研究の立ち位置を整理する -JAVA勉強会しようぜ（オブジェクト指向演習の復習） -TOEIC勉強会しましょう（院試に備えて） **4/06 [#g28a1ac6] ***Done [#z67b38a3] - 確率統計「入門統計学」第1章を読み終えた - 入門統計学第1章（pdf）：&attachref(データの整理と簡約化.pdf); - 「The Impact of Coverage on Bug Density in a Large Industrial Software Project」をまとめた - (word): &attachref(The Impact of Coverage on Bug Density in a Large Industrial Software Project-2.docx); - 「Automated Static Analysis of Unit Test Code」を読み始めた **4/05 [#g28a1ac6] ***Done [#z67b38a3] - アサーションについてまとめた - （pdf）：&attachref(期待される挙動のアサーション.pdf); - 確率統計「入門統計学」第1章を読み進めた（来週にまとめたものを発表する） **4/02 [#g28a1ac6] ***Done [#z67b38a3] -「The Impact of Coverage on Bug Density in a Large Industrial Software Project」を読み進めた ***Todo [#c09709b8] - 自分の立場を確認する（研究をするにあたって、何が研究されていて何が掘り進められていないのか） **3/28 [#g28a1ac6] ***Done [#z67b38a3] -「The Impact of Coverage on Bug Density in a Large Industrial Software Project」に目を通した -疑問点がかなり多い。特にわからないワードが多く出てきた - - ***Todo [#c09709b8] -論文まとめに記載している疑問点について解消する ***メモ [#p6b8c498] -検定（確率・統計）の勉強会を4年生で近々開催すべき（取り纏め：大東） **3/27 [#g28a1ac6] ***Done [#z67b38a3] -春休み成果報告資料 -（pptx）：&attachref(春休み成果報告_0.pptx); -（pdf）：&attachref(春休み成果報告-3.pdf); -「An Empirical Study of Bugs in Test Code 」を読んだ ***Todo [#c09709b8] - **3/26 [#g28a1ac6] ***Done [#z67b38a3] -「An Empirical Study of Bugs in Test Code 」導入部分を読んだ ***Todo [#c09709b8] - **3/24 [#lc762971] ***Done [#z67b38a3] -「OSS 開発における欠陥数とカバレッジ（範囲）の関係に基づく. 継続的インテグレーションの有効性検証」を読んだ ***Todo [#k14463e8] - **3/16 [#lc762971] ***Done [#z67b38a3] -読むべき論文を決めた - ***Todo [#k14463e8] -読むべき論文を読む（４月上旬までに） **テンプレ [#g28a1ac6] ***Done [#z67b38a3] - - ***Todo [#c09709b8] - **論文メモ [#g28a1ac6] ***Empirically Revisiting the Test Independence Assumption [#y8c42078] -依存テストには悪影響があると唱えた論文 -依存テストが及ぼす影響を分析した -依存テストを抽出するためのツールを提案し様々なプロジェクトで評価実験を行った ***Software Unit Test Coverage and Adequacy [#f7f4fa79] -ソフトウェアテストの３つのアプローチ --構造テスト ---プログラムまたは使用の構造における要素の特定での観点からテスト要件を指定 --欠陥ベースのテスト ---ソフトウェアテストのフォルト(すなわち欠陥)の検出に焦点をあてる．この手法の妥当性の基準は，テストセットの障害検出能力の測定 --エラーベースのテスト ---プログラムが一般的に仕様からどのように逸脱しているかについて企業での知識に従い，エラーの起こりやすい点についてプログラムをチェックするテストケース が必要 -プログラムベースの構造テストの妥当性基準 --制御フロー基準 --データフロー基準 ***Time to Clean Your Test Objectives [#ea3b1f81] -汚染されたテスト目標(実行不可能・冗長なテストコードが存在)によって入力の選択を誤る可能性がある -汚染されたテスト目標は検出が難しく，城名することが困難 -本研究では汚染されたテスト目標を自動検出し，除去するツールを提案し，既存の手法と比較して実行時間や効率がどの程度改善されたのかを示す． ***Fine-Grained Test Minimization [#w6ec49a7] -テストスメル(test smell)等のエラーとして検出しにくい問題が解決できそう --冗長性の危険性について学ぶことができた -より依存性が高いテストは冗長性を除去できるのだろうか ***DeFlaker: Automatically Detecting Flaky Tests [#o079b4b9] -Flaky testの検出の難しさ -DeflakerによってFlaky testを手軽に，負荷をかけず検出することが可能 -従来手法のRerunに比べてより検出がしやすくなった ***Oops, My Tests Broke the Build:An Explorative Analysis of Travis CI with GitHub [#z67b38a3] -Travis CIの分析: 1/3が使用、結構普及している -ビルド破壊がテストの失敗を招く ***Comparing White-box and Black-box Test Prioritization [#z67b38a3] -ブラックボックスについての研究があまりされていないことが判明した -回帰テストの最適化に関してホワイトボックスは２０年近く研究されている ***Automated Static Analysis of Unit Test Code||SANER16 [#z67b38a3] -JfreeChartについては検証されたが、他のプロジェクトについては実験されていないため、比較実験をすると他の展望が見えてくるかもしれない。 -まとめでレビューの重要性についても述べていたので、自動静的解析とレビューを相互利用できるような手法を探すのも面白いかもしれない ***The Impact of Coverage on Bug Density in a Large Industrial Software Project [#z67b38a3] -カバレッジとはそもそも何なのか？ -ウィルコクソンの符号順位検定とは何でどんな時に使うのか？他の検定はあるか？帰無仮説と対立仮説とは何か？ -カバレッジ率と不具合出現率にはどのような関係があるのか？ ***An Empirical Study of Bugs in Test Code [#z67b38a3] -テストケースは、テストされるコードよりもエラーを含む可能性が高い -テストバグの蔓延、影響、主要な原因カテゴリを特徴付けるテストバグに関する広範な研究 -テストコードの欠陥は３％のSilent horrorと９７％のFalse alermsに分けられる -開発者はテストコードの欠陥修正に対して積極的に貢献することが判明した ***OSS 開発における欠陥数とカバレッジ（範囲）の関係に基づく. 継続的インテグレーションの有効性検証 [#z67b38a3] -見逃し欠陥の怖さと発見の難しさを感じた。また、プロジェクトにおけるテストカバレッジの重要性も理解できた。
