id:logy0704です。
もうすぐJava14がリリースされますね。
いくつかの変更が予定されていますが、その中でも今回はswitch文の変更についてご紹介しようと思います。*1
Javaを学んだことのある方ならば一度は触れたことがあるかと思います。
以下のような形式で複数分岐を表現することができ、特にEnumと組み合わせて使われることが多いです。
switch(case) {
case1:
hoge;
break;
case2:
huga;
break;
default:
piyo;
}
*1:Java12からプレビュー版として提供されていた内容ですが、フィードバックを経てJava14で正式導入されます。
こんにちは！遅くなってしまいましたが、今回は1月21日に行われたビアバッシュのご紹介をします。
今回のビアバッシュは自由枠の発表とLTの構成となっております。
git switch & git restore
PHPerKaigi2019の参加がきっかけで社内勉強会を主催するようになった話
サンフランシスコにオフィスを構えるNotion社が開発した情報管理アプリ「Notion」について紹介してくださいました。
議事録などのテンプレートを用意することができるなど便利な機能がそろっています。
非常に柔軟でアイディア次第で何でもできるアプリですが、柔軟すぎるがゆえに迷うこともあるそうです。
今月もScalaが好きなエンジニアがScalaについて語ってくださいました。本発表ではScalaの処理系について紹介してくださいました。
ScalaをJSにトランスパイルすることができます。
Javaスタンダードライブラリを一部使用することができます。
Scalaでスクリプトを書くことができます。replだけでなく、shellも書くことができます。
NET用の実行ファイルを作成します。公式サポートされていましたが、2012年でサポートが終了しました。
2/16に開催されたOOC2020の先取りの発表をしてくださいました。 Java とアーキテクチャテストツールの ArchUnit を用いたドメイン駆動なアーキテクチャ設計を運用する方法についてのお話です。 また、PHPのアーキテクチャテストツールの紹介もしてくださいました。 こちらが実際にOOCで発表されたスライドなので気になる方はどうぞ。
Git2.23の新機能で、gitのブランチを変更する「switch」とファイルを変更する「restore」コマンドについて紹介して頂きました。
「switch」と「restore」は「checkout」を分割した機能です。
ただ本人曰くcheckoutの方が打ちやすいらしいです
若手エンジニアがPHPerKaigi2019に参加したことがきっかけで開催した社内勉強会についてのお話です。 勉強会を開催したきっかけや開催してよかったこと、気づいたことなどを語ってくださいました。 勉強会の開催を実行、継続する難しさを発表から感じました。
今回のビアバッシュではGitの便利な機能など、業務の役に立ちそうなものや、 勉強会開催で得たものについての発表などためになる話を聞くことができました。 今後もビアバッシュの内容をブログに掲載しますので、どうぞお楽しみに！
こんにちは、MasaKuです。
PHPer による PHPer のためのお祭り、 PHPerKaigi が今年も開催されました。 （弊社もスポンサーをさせていただいております）
今回は LT にチャレンジさせていただいたのですが、登壇にあたり様々な学びがありました。
本記事では、LT にチャレンジする上で学びにつながった以下のポイントについて記載していきたいと思います。
去年の PHPerKaigi2019 には一般参加という形で参加させていただいており、大変興味深い発表ばかりだったので、「来年こそはぜひスピーカーに！」と意気込んでおりました。
去年の参加レポートはこちら
実は昨年開催された PHPerKaigi2019 のプロポーザルにも挑戦していたのですが、残念ながら非採択という結果になってしまっていました。
そのため、今年の開催でトークが採択された時は嬉しさ半分驚き半分といった気持ちでした。
なお、昨年度のトークテーマは以下です。
今回のプロポーザル募集にあたり、話したいトークテーマはすぐに思いつきました。
というのも、PHPerKaigi の参加がきっかけで社内で行った上映会からいろいろな活動を開始するようになったので、その経過報告をしようと考えていたからです。
社内のビアバッシュでも何度か発表したテーマでしたが、今回の PHPerKaigi2020 でも発表することができれば最高だなあと考えていたためです。
しかし、どのような展開で話していけば盛り上がるかという視点はサッパリだったので、トークの方向性についてはブレブレでした。
テーマ検討でトークを聞いてくださる方に受けそうなのはどちらか、自分として話しやすいのはどちらか、という視点でテーマ選定を行っていきました。
トークが採択された後は発表資料の準備を始めましたが、弊社で定期的に開催している MeetUP という社内イベントで登壇した経験があったため、どのように話を構築していくと資料が作りやすいかというノウハウがあったため、資料作りはスムーズに進みました。
イベントページ
登壇資料
今回の登壇資料の作成は以下のような流れで進めました。
個人的に一番大切だと思うのは 4 番目の内容です。
箇条書きレベルで話がまとめられていると、それをスライド化するのは非常に容易です。
「それならスライドを作りながら内容を整理しても同じなのでは？」と思うかもしれません。
これは個人的な感覚ですが、グラフィカルなアウトプットができてしまうと伝えたいポイントが見えにくくなる気がするので、まずは文字ベースのアウトプットを作成するのが良いと思っています。
逆に、文字ベースでも自分の話たい内容がきちんと整理できていればそれをスライド化するのは難しくなく、むしろ、図的な説明も可能になるので、自分としてもより納得できる説明を組み立てられるようになります。
発表練習は個人でやるのも大切だと思いますが、やはりフィードバックをもらえる環境で実践するのが最適です。
幸いにも今回は発表練習をする機会が豊富だったので、実践的な練習を繰り返すことができました。
今回、発表練習を通して得た教訓としては、LT で登壇するう上で特に気をつけなければならないポイントは以下のように感じました。
特に、5分間をフルで使い切ることは大切だと感じました。
通常の発表の場合は話たい内容を時間内に収められるように簡潔に話すことが重要かと思いますが、様々なカンファレンスのLTを見て感じることとしては、LT では 5 分間という時間を綺麗に使い切ることのほうが芸術点が高いように感じておりました。
そのため、タイムキーパーの「終了です！」の一言と同時に発表をキレイに切れるように、最後のスライドに向けてどれくらいの時間を残すかということを意識して練習するようにしました。
LT の会場には推定 200 人を超える参加者の方がいらっしゃったように思います（もっと多かったかも）
このような大勢の前で発表した経験がこれまでなかったこともさることながら、カンファレンスでの登壇も初めてでしたので非常に緊張した 5 分間でした。
練習通りにできたところもあれば、自分で何を話しているのかすらわからなくなるような場面もありましたが、非常にいい経験になったと思っています。
会場内から笑いの声や拍手が聞こえてくると勇気づけられるような感覚があったので、今後、こういったカンファレンスに出席する際は、リアクション増しを意識していきたいと思いました。
いつかはスピーカーとして登壇したいと思っていたカンファレンスに出ることができてとても良い経験ができたと思っております。
発表内容について Twitter でたくさんのリアクションをいただいておりましたが、自分が想像していた以上に発表内容に共感していただけたようで嬉しかったです。
イベントを通して様々な方と交流することができたこともとても良い経験になったと思います。
今回の PHPerKaigi2020 での登壇をきっかけとして、また次のステップに向けて再チャレンジしていければと思います。
こんにちは。新卒2年目のbadaikiです。業務でできることが徐々に増えていくなかで、まだまだ自分はできていないなと感じる日々を過ごしております。
前回ではテストの網羅率の向上、可視化するディシジョンテーブルについて記事を書きました。
ディシジョンテーブルは網羅率は高められるものの、ターゲットによってはすべてのケースを消化するだけでとんでもない工数がかかってしまうことがわかりました。 そこで今回はどうすればケース数を減らし、効率的にテストを実施できるかについて調べてみました。
以前私がテスト実施から参入した開発で、先輩社員がケースを作成したものを複数人で実施していくということがありました。条件がかなり複雑に絡み合う機能であったため、ケース数が爆発しているんだろうなーと予測していたのですが、いざケースを確認してみると予測していたケース数の1/3ほどのケース数で驚きました。聞くとオールペア法を活用していました。
オールペア法についてはケース数が減るよ。という知識しかなく、なぜ減らせるのか、漏れは起きないのかということまで理解できておりませんでしたので、この機に調べてみようと思いました。
オールペア法（ペアワイズ法ともいう）とは組み合わせテストの技法の1つです。
組み合わせテストとは、多数の入力条件の値をいろいろと組み合わせて実施するテストです。しかし前項でも述べたように、全ての入力条件で値の組み合わせを考えると、膨大な数になり全てをテストするのは現実的ではありません。例えば3つの選択肢があるプルダウンが4つあり、その組み合わせだけで 3の4乗 = 81ケース となるわけです。81ケースと聞くとできそうな気がしますが、それぞれが4つの選択肢になるだけで256ケースと3倍以上に増えてしまいます。
以降ではプルダウンのような入力条件を因子、その値を水準と呼びます。
ある文献*1ではソフトウェアのバグの7割から9割が1つまたは2つの因子の組み合わせによって発生していることが記されています。以下がそれを示した表です。
| 要因数 | 組込み機器（医療系） | ブラウザ（Netscape） | サーバ（Apache） | データベース |
|---|---|---|---|---|
| 1 | 66 | 29 | 42 | 68 |
| 2 | 31 | 47 | 28 | 25 |
| 3 | 2 | 19 | 19 | 5 |
| 4 | 1 | 2 | 7 | 2 |
| 5 | 2 | 0 | ||
| 6 | 1 | 4 |
そこで2つの因子の組み合わせをつくり、すべての水準の組み合わせのケースを作成するのがオールペア法という技法です。
例えば、プルダウンが3つの組み合わせを考えてみます。
| 因子 | 水準 |
|---|---|
| プルダウンA | 0,1 |
| プルダウンB | 0,1 |
| プルダウンC | 0,1,2 |
これの全組み合わせは 2 * 2 * 3 = 12ケース 。
これをオールペア法で作成するには
１. まずそれぞれの因子のペア（AB、AC、BC）を作成し、水準の組み合わせの全パターンを作成します。
| AB | AC | BC |
|---|---|---|
| 00 | 00 | 00 |
| 01 | 01 | 01 |
| 10 | 02 | 10 |
| 11 | 10 | 11 |
| 11 | ||
| 12 |
２. 1で作成した水準の組み合わせをAB列から順に取り出します。
| No | Ａ | Ｂ | Ｃ |
|---|---|---|---|
| 1 | 0 | 0 | |
| 2 | 0 | 1 | |
| 3 | 1 | 0 | |
| 4 | 1 | 1 |
３. 次にAC列、BC列と順に当てはまる行に割り付けていきます。このときに着目しているペア以外のペアも同じ組み合わせが現れないように割り付ける必要があり、これがケース数を最小にするために重要です。←これがややこしいです。例えばAC列の(10)を割り付けるとき、(1,0,0)の組み合わせではなく、(1,1,0)の組み合わせにします。AC列の(00)を割り付けるときに(0,0,0)の組み合わせが既に出来上がっており、BC列の(00)が2か所で作成されてしまうためです。
| No | Ａ | Ｂ | Ｃ |
|---|---|---|---|
| 1 | 0 | 0 | 0 |
| 2 | 0 | 1 | 1 |
| 3 | 1 | 0 | 1 |
| 4 | 1 | 1 | 0 |
| 5 | 0 | 0 | 2 |
| 6 | 1 | 1 | 2 |
このようにオールペア法で作成すると今回の例ではケース数が12ケースから6ケースと半分になりました。ただし、理屈がわかっても実際自分で作成しようとすると難しいです。。。加えて、実際のシステムでケース作成を行う場合には、A=0のときはB=0になるなどの制約条件があるとさらに複雑になってきます。上記の例は簡単な例でしたが、複雑になっていくと考えるを諦めてしまいそうですよね。実は制約条件も考慮して自動生成してくれるツールが提供されています！
オールペア法のテストケース生成ツールは多く提供されており、以下のサイトにまとめられていました。ここで紹介されているツールだけで現在51種類もあり、驚きました。この中でPICTとpairwiserについて使い方を紹介したいと思います。
Pairwise Testing - Available Tools
特徴：
使い方：
１. パラメータを定義する
PICTではモデルファイルと呼びますが、txtファイルで作成します。
基本的なモデルファイルは、末尾が:で終わるパラメータと、,で区切られた値の並びとからなるモデル定義部のみで構成されます。
A: 0,1 B: 0,1 C: 0,1,2
２. 1で作成したファイルをpict.exeで実行する。
pict test.txt
これだけです。
すると以下の結果が出力されます。
A B C 1 1 1 0 0 0 1 0 1 1 1 0 1 1 2 0 0 2 0 1 1
結果をリダイレクトする場合には以下で実行できます。
pict test.txt 1>result.txt 2>error.txt
1は出力結果、2はエラーが発生したときにエラー内容が出力されます。
制約条件を設定する場合にはモデルファイルの末尾に制約条件を追記します。記述方法は独自のスクリプト言語が用いられており，因子を [] で囲み，水準が文字列の場合は，"で囲み，ステートメントの末尾は;で終わります。条件にはパラメータと値の関係を評価する関係式を用いて条件付き制約と必ず成立する無条件制約があります。
#パラメータ定義 A: 0,1 B: 0,1 C: 0,1,2 #制約条件定義 #条件付き制約 if [A] = 1 then [C] <> 2; #無条件制約 [A] <> [B] or [A] <> [C] or [B] <> [C];
上記のモデルファイルで実行すると以下のケースが出力されます。制約条件通り、A=1の場合はC=2にはならず、A=B=Cになるケースは作成されません。
A B C 0 0 1 0 0 2 0 1 0 0 1 1 1 0 0 0 1 2 1 0 1 1 1 0
Pairwiser - Pairwise Testing and Test Generation Tool
特徴：
使い方：
基本的に、左から右へタブに必須情報を入力してテストケースを生成します。それぞれのタブの「Save」ボタンを押さないとデータが保存されません。また、データが保存されていないタブよりも右側のタブの内容は更新が効かないようになっています。Webアプリのため、直感的に操作がやりやすいです。
Define Parametersタブでパラメータ定義や制約条件を設定でき、Generate Testsタブでケース作成ができます。Generate Testsタブの上部にあるExport to ExcelボタンをクリックすることでExcelファイルもダウンロードすることができますので、業務でテストケースをExcelで書かれている場合にはそのまま活用することができて便利ですね！
また、公式ページにはチュートリアルやヘルプもあるので、初めてさわる場合でも安心ですね！
前回のディシジョンテーブルに引き続き、今回は組み合わせテストのオールペア法について調べ、自動生成ツールを使ってみました。オールペア法について知ることで、なぜそのケース数で十分なのか、どのように作成されているのかが理解できました。また、自動生成ツールを用いることで制約条件など細かな設定も行え、ツールによってはExcelファイルに変換してくれるなど、人手で行うよりもとても効率的にケース作成が可能だとわかりました。今後、条件が複雑に絡み合う機能のテストではオールペア法を用いて網羅性を保証しつつ、効率的に進めていこうと思います。
こんにちは。choreiiです。最近自チームで扱っている商材のフロントエンドのテストコードを大量に書く機会がありました。その中で大きくハマった３点について紹介します。
次週、都内ではPHPerKaigi 2020が開催されます！
ラクスからは3名のエンジニアが登壇することとなりました！
また、Silverスポンサーとしてイベント協賛をさせていただいております。
イベント概要
セッション内容とエンジニア3名からのコメントをご紹介します！
また、イベント中にはPHPerチャレンジという企画が開催されます。
会場や関連サイトに散らばった #任意の文字列 形式のPHPerトークンを探して合計スコアを競う、というものです。
本ブログを読んでいただいた皆様には、ラクスからのPHPerトークンを受け取っていただければと思います！
ラクスのPHPerトークンはこちらです！
↓
#RAKUSMeetup2020
それでは皆様、当日は弊社エンジニア陣の登壇にご期待ください！
itoken1013でした！
