賢くソフトウェアをつつく・直す
ソフトウェアシステムに対する複雑な要件をどう整理し、保証するのか︖

探索・学習によるソフトウェア⼯学
複雑な要件の段階的分解と形式検証のための研究
ERATO-MMSDプロジェクト
グループ３「インテリジェンス協働形式⼿法」
⽯川冬樹 ⼩林努 Fernando Tarin ⽥辺良則 本位⽥真⼀

どんな問題︖

どんな研究︖

ソフトウェアが扱う領域はますます増えており、システムの不具合検出やその修正などの様々なタスクは⾮常に難しく⼈⼿で太⼑打ちできないものになりつつあります。

ソフトウェア⼯学における様々な問題を、探索・学習の技術を活⽤し、賢くポイントを絞り込んだり、傾向を学習したりすることによって効果的・効率的に解くことを⽬指しています。

探索・学習技術の活⽤

設定１でやってみたら歩⾏者まで最⼩８ｍ，設定２では３ｍだったぞ
例︓ ⾃動ブレーキソフトウェアの不具合発⾒ 設定２を少しいじるともっと危ないケースが出るかな︖
シミュレーションによりテストする
ときの多数のパラメータ・設定項⽬• 初期速度
• 先⾏⾞や歩⾏者の位置• 路⾯状況・カーブや坂• ドライバーのアクセル・ブレーキ・ハンドル操作ポイント絞り込みや傾向の把握により「欲しいもの」にどんどん近づけていく︕あぶり出す︕※ 遺伝⼦の進化を模倣した進化計算などメタヒューリスティックの考え⽅を適⽤
様々な応⽤• 危険なケースなど要件に違反するテストケースを⽣成する• バージョンアップで挙動が⼤きく変わってしまうテストケースを⽣成する• 網羅性や多様性が⾼いテストケースリスト（テストスイート）を⽣成する• 正しさの基準を満たすような設計やコードの断⽚や修正を⽣成する• ・・・
理論も活⽤してスピードアップも︕ → ポスターA14

機械学習システムのテスティング

強化学習によるテスティング

by ⽯川 冬樹

by 加藤 亙貴＜例＞• 各⼊⼒に対する出⼒の正解を決めるのが困難または不可能で，正解と照らし合わせられない• 少し⼊⼒（例︓画像）をいじるだけで，思いもしない形で出⼒が変わることがある• 原則不完全（100%になりえない）ので，どこまで制度を追い求めればよいかわからない危ないケースなどの「あぶり出し⽅」を訓練し少し環境・製品が変わってもさっと検査

新しい難しさがある︕→ ポスターA10「あぶり出し」テストケース⽣成を活⽤︕• 前のバージョンと⼤きく結果が変わるような⼊⼒を⾒つける• ⼩さな⼊⼒の変化で⼤きく出⼒が変わる場合を⾒つける• システム全体での問題（事故など）につながるような誤検出に絞って⾒つける

訓練︕
バリエーション
• 製品ファミリー
• 設計時のパラメータ等の試⾏錯誤• 想定環境Testing Cyber-Physical Systems (CPS)by Shaukat Alio Application Domains: Automotive, Avionics, Maritime, Oil&Gas, etc.
o Objective: Ensure dependable operation/behavior in real environment , e.g.,safety, security, correctness
o Challenges: Unpredictable physical environment, black-boxes, interactions
among software, hardware, human, information networks, …
o Methods: Model-based Testing, Search-based Testing, Machine Learning
CPS

Models(ExpectedBehavior)

Automated
Warehouse

SubseaTest
Case/Model
Execution

receives feedback
from CPS

executesCPS

GeoSports

Autonomous
Airplanetest cases
Test
Generator

Test Modeling

Testing

SysML

Reinforcement
Neural Networks
Learning
Particle Swarm
GeneticOptimization
Algorithms

UML

Domain Specific
MARTE Languages

Using Mutation for Testing and Repairing Code/Models
by Paolo Arcaini

Fault‐based testing• Some faults are more frequent than others. E.g.:• developer wrote if(var < 5) instead of if(var <= 5)• developer wrote [a‐z]* instead of [a‐z]+• Fault‐based testing is used for two purposes:• checking if a test suite detects all the faults• generating a test suite for detecting all the faults• Fault‐based testing is applied to: code, formal
models, regular expressions, feature models
Fault‐based test generation for regular expressions• We identified typical faults in regular expressions(e.g., wrong multiplicity operator)• The tool MutRex builds tests for capturing such faults
in a regular expression under test
• The user is the oracleAutomatic repair• Automatic repair aims at removing faults from SWartefacts
Automatic repair of feature models• We consider feature models and suppose to have aset of desired update requests (from failing tests)
Failing tests‐ Products with Camera and Basic
are wrongly accepted‐ Products without GPS arewrongly rejected• Evolutionary approach for automatic repair• In mutation testing, mutants are used to detect faults• If a SW artefact contains a fault, the corresponding mutant
does not: Let’s use it for repairing the feature model!

連絡先︓ ⽯川 冬樹 （国⽴情報学研究所 アーキテクチャ科学研究系 准教授）
Email : f-ishikawa@nii.ac.jp Web︓http://research.nii.ac.jp/~f-ishikawa/