「第一回 システムテスト自動化 標準ガイド 読書会」に参加してきた
第一回 システムテスト自動化 標準ガイド 読書会に参加してきました。
今回は1、2章がテーマ。
1章
http://www.slideshare.net/fujisawa_y/20150418-46648838
- テスト管理
- TestLinkとか
- テスト設計
- モデルベースドテスト
- 開発に使ったモデルからテストを作るのでなく、テストのためのモデルを再設計する?
- まだリンク先の資料を読んでいない
- PictMasterやCEGTestなどのツールがある
- モデルベースドテスト
- ブラウザテスト
- 負荷テストはJMeterよりGatlingが良いらしい
- 要件や設計のテストって、レビューとは違う?
- シーケンス図や業務フロー図を書いてみることがテストの一つに該当する
- CEGTest使うと漏れが見える
- ただ手法が難しいらしい
2章
スライドはどこかに上がっているのでしょうか?
- ソフトウェア設計自体が、テスティングの自動化自体の成功を左右する
- 最初からテストを意識して設計すると良いよね
- 前述のブラウザテストで例えると、idやclassを最初から振っておくとか
- 最初からテストを意識して設計すると良いよね
- テスターとテストオートメーターが分かれている経験ある人?
- テスターは派遣とか外注、オートメーターは自社というパターンがあるみたい
- テスターとテストオートメーターの分業について
- 賛成/反対に分かれて参加者で意見出し
- 2章の話は原著当時の背景が強く影響している?
- MSのWindowsテスト?(うろ覚え)
- テストスクリプトが複雑になる = メンテコストが高くなる
- あるある
- アドホックテストの自動化は無意味。自動化の前にテスト手法/設計を見直すべき
- 詳細なテストスクリプトから自動化する
- テスト自動化をプロジェクトで導入するには
- 実際に見せる。画面テストを100ケースとか
- QAの世界では4つのコスト(予防、評価、外部失敗、内部失敗)という考えがある
- 気合い
感想
Gitで'fatal: object {hash} is corrupted'になった際の復旧手順
Macがフリーズする現象がたまにあって、そうなるとgitの状態が壊れることがある。
その時の修復手順を記録として残しておく。
現象
git操作を行おうとするとfatal: object <hash> is corrupted
が出る。
/home/kanno/repository% git status fatal: object 43a1c7ca8e29251954a806714bd1db24ddcf1905 is corrupted
復旧手順
念のためバックアップを取っておく
/home/kanno/repository% cp -rp .git git-old
表示されたhashのオブジェクトファイルを消す
/home/kanno/repository% rm .git/objects/04/313fa358eabb459b0c9ea1f48709f1cbb88118
git操作でfatal: bad object HEAD
が出るまでオブジェクトファイルを消すのを繰り返す
/home/kanno/repository% git status fatal: bad object HEAD
該当ブランチのrefs/headsの中身を見る
(.git/logs/refs/heads/20432-hoge-branch
のところは見たいブランチを指定)
/home/kanno/repository% tail -n 2 .git/logs/refs/heads/20432-hoge-branch dcba72adc7078cfcced387a69246f0b29ea589b6 74e8aa0c09550804b40024ab33a98321627e1b4a kannokanno <...> 1429095527 +0900 commit: [#20432] WIP 74e8aa0c09550804b40024ab33a98321627e1b4a 43a1c7ca8e29251954a806714bd1db24ddcf1905 kannokanno <...> 1429096095 +0900 commit: [#20432] WIP
2行目の左のhash値を使ってHEAD
を戻す
/home/kanno/repository% git update-ref HEAD 74e8aa0c09550804b40024ab33a98321627e1b4a
git操作が出来るようになっているのでcommitしなおしておく
MySQLでSQLの実行時間のみを調べる
SQL設計やチューニングで実行時間を計測する際に以下のような状況がよく出てくる。
- SQLの実行時間が知りたい
- 実行結果はいらない
方法1 mysql -vvvを使う
/home/kanno% cat sample.sql | mysql -vvv hoge_db | tail -n 3 1 row in set (3.62 sec) Bye
- 対象のSQLを書いたsample.sql(ファイル名は何でも)を用意
- 単純なSQLなら
echo "select ..." | mysql ...
で十分
- 単純なSQLなら
- mysqlコマンドの標準入力に渡す
-vvv
オプションで実行時間を出すようにする
- tailで実行時間以降の行だけ表示させる
Bye
とかも邪魔ならheadで更に絞るcat sample.sql | mysql -vvv hoge_db | tail -n 3 | head -n 1
方法2 timeコマンドを使う
/home/kanno% time (cat sample.sql | mysql hoge_db > /dev/null) real 0m12.526s user 0m0.079s sys 0m0.009s
プログラミングにおける設計の難しさについて考える
前提
この記事における設計
は主に以下の4点をイメージして書いています。
(具体的にどうこう、という話は出てきません)
- REST設計
- レイヤー設計
- MVCとかDDDにおけるレイヤーみたいなやつ
- クラス/インターフェース設計
- どういう処理/データを持たせるのが適切かとか
- コード設計
- for文で書くかeach使うかとかそういう細かい話
目的
- 設計に悩んだり微妙な設計をすることがあって改善したい
- 設計に関する本を読んでいる中で、私にとってなぜ設計が難しいのか見えてきたので勢いで書き出す
- あくまで現時点での私が思う難しさなので、1年後は別の原因で難しさを感じてるかもしれない
設計の何が難しいか
以下の要素により明確な正解がないから
ではないかと感じています。
- 選択肢がいくつもある
- 選択肢が浮かばない
- 判断基準がいくつもある
- 捨てる決断が必要なことがある
- 技術的負債を恐れる
難しい要因1: 選択肢がいくつもある
プログラミング覚え立ての頃は数少ない方法でコードを書きます。
- (Javaから入ったので)繰り返しといえばfor文を回すだけ
- whileは無限ループ怖いので理由がない限り書かない
- 再代入バリバリ
- メソッドの引数を書き換えることも
- メソッド/クラスを分けない
- クラスの責務を分けない
- 変数名/メソッド名/クラス名が適当
他人が見れば汚いコードですが、少なくとも書いている本人は設計で迷うことは少なかったはずです。
設計していなかったので。
迷うのはアルゴリズムというか手続き的なところで、単純に「どう書けば仕様を満たすのか」という点でした。
それが経験や学習を経て、色々な方法を学んでいきます。
- map/filter/reduceなどを覚える
- 変数は不変を保つ。再代入とか辞めてほしい
- ifが文ではなく式である言語に喜びを覚える
- 「このクラス/メソッドの責務って何だ」を考え始める
- 名前を考えるのに時間を費やす
携わる仕事は大概ありがちなCRUDなので難しいコードを書く事は少ないです。
ただ昔と違い色々な手法を知ってしまったため設計に時間がかかるようになっています。
ちなみにコード寄りの例を出しましたが、コードに限らず設計全般です。
たぶん中途半端に色々知っている状態のため判断に迷っているのだと思います。
難しい要因2: 選択肢が浮かばない
ざくっとした言い方ですが。
- 経験として何か良くないのは分かる
- いわゆる
コードの臭い
とか - コードじゃなくても、何となくこの設計イケてないよなあ感
- いわゆる
- けどどうしたら良いかが分からない
これは単純に経験に知識が追いついていないのでしょうね。
難しい要因3: 判断基準がいくつもある
※以下に出している例は例であって、今の現場がそうだということではありません
- 現メンバーのスキル
- 今後保守するかもしれない人のスキル
- xx言語が向いているけど、書ける人が少ないのにxx言語で社内ツール作るべきか
- 既存コード(アーキテクチャ)との調和
- xxの方が
良い
設計なんだけど、そうすると既存の他の部分と統一性がなくなるとか - 統一性を重視してそっちに合わせるか、ゼロベースでの最善を取って
良い
設計にするか
- xxの方が
- 予算
- カスタマイズしやすいようにオンプレがいいけど予算がとか
- 人的リソース
- 単純に人が足りない
- 時間リソース
- 単純に時間が足りない
- タスクの優先度(重要度)
- 急ぎでやるべきなものは「とりあえず」でやりがち
- 「あとでやる」はまずやらない
- やらなくて困らないならそもそも不要だったのではという考えもある
- 急ぎでやるべきなものは「とりあえず」でやりがち
- 難易度
- 簡単なものほど飛びつきやすい
難しい要因4: 捨てる決断が必要
上記判断基準と併せて。
多くの場合において捨てる決断が求められます。
上記と重複する部分がありますが、捨てる理由としては主に以下の3つが浮かんでいます。
- 人が足りない
- 増やせばいいってものではないですが
- 時間が足りない
- さっさとリリースしたいねんという圧力
- 緊急時の対応
- 知識/経験が足りない
- xxがいい気がするけどやったことないから怖いね
- もしくは時間がかかるね
- xxという簡単な解決策(手法、ソフトウェア、サービスなど)があるのに知らない
- xxがいい気がするけどやったことないから怖いね
難しい要因5: 技術的負債を恐れる
苦悩の末に決断をしてそれがその時の最適解だったとしても、
時が経ったり新しく入ってきた人からするとそれは技術的負債になり得ます。
自分が関わった部分を指して「これはひどい」とか言われたくなくて、
見えない未来に思いを巡らせてあれこれ悩むのかもしれません。
プロとしてのありかた
こういった難しい要素に対して、私のプロ像はどう振る舞うだろうかというのを考えてみます。
色々なケースで最適解を出す
正解はない(と思う)けど、最適解は必ずある(と思う)。
その場その場で、色々なコストを考慮して最適解を出せる人がプロ。
幅広い知識と多くの経験と理路整然とした思考が必要。
責任を持つ
理想を語るのは簡単です。
理想を振りかざして既存のコードをけなすのは簡単ですし、
自分が高尚に感じるし、責任から逃れられているような感覚になります。
(参画した時点で自分もコードの責任者だと思う)
ですがきっとプロはグチグチ言わない。その方がモテるから。
プロはアウトプットで語る。
変えられるなら変えていくだろうし、
それが出来ないなら「これが今出来る最高の状態」と決断に誇りを持つ。
設計の難しさにどう立ち向かうか
- チームとしての立ち向かい方
- 個人としての立ち向かい方
チームとしての立ち向かい方
- レビューを挟む
- 自分が見えていない観点で指摘してくれるかもしれない
- 人に説明することで抜け漏れに気付きやすいかも
- 議論は前提の認識を明確にしておく
- お互いが見ているもの、目指しているものが違うと議論もすれ違う
- 「こっちの方が開発が早い」と「こっちの方が保守性が高い」みたいなことを言い合っても平行線
- 「急ぎでやる必要あるの?」「一度しか使わない機能で保守性とか必要?」みたいなところから認識合わせるとか
難しい要因
のほとんどはチーム内レビューとか相談で解決する気がします。
そのためにチームでもありますし。
ですが、出来ることなら自分一人でも最適解を出せるようにはなりたい。
「最適解の判断に迷う」という相談ではなくて、
「こういう理由でこれが最適解だと判断したのだけどどう思う?」という相談にしたい。
個人としての立ち向かい方
- 知識を増やす
- 悩まないという点では知識は少ない方がいいかもしれない
- でも最適解を出すには知識は必要
- 経験を増やす
- 「知っている」と「やったことがある」では全然違う
- 常に考える
- 本やネットの知識を鵜呑みにして受け売り野郎にならない
- 手法やサービスなどについて何がいいのか、何故いいのかを自分の言葉で説明できるようにする
感想
何が難しいと感じているかは分かった気がして書き出してみたけど、
個人については結局勉強しろという当たり前かつ抽象的な結論しか出ていなかった。
「入門Puppet」を読んだ
自社ではPuppetを使っています。
私が直接いじることはほとんどないけど、
基礎の基礎ぐらいは知っておきたいなということで「入門Puppet」を読みました。
入門Puppet - Automate Your Infrastructure
- 作者: 栗林健太郎
- 発売日: 2013/04/29
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
事前知識
- Chef-soloをほんの少しだけ使ったことがある
- Ansibleをほんの少しだけ使ったことがある
- Puppetの存在は知っていたけど使ったことはない
- でもどういうものか概要は知っている
- Vagrantを使ったことがある
- 書籍ではVagrantを使って説明が進む
- どこかの勉強会かネットでPuppetはちょっと面倒みたいなことを聞いた気がする
- 外部DSLなので学習コストがーみたいな話だったかな
読み方
- 1回目: 全体をさらっと一読
- 2回目: 実際にコマンドを実行しながら読んだ
- 15章以降は一身上の都合により試してはいない
- 3回目: この記事のために流し読みで復習
最後に1章ずつserverspecやcapistranoとの連携があるけど、今知りたいことではないので流し読み。
知ったこと
全体的なこと
- 「システムのあるべき状態」を記述したmanifestを用いる
- 他の構成管理でも同じことなのだろうけど、状態っていう言葉がなんかしっくりきた
- 今までは「手順の自動化」っていう感覚だった
- あるべき状態を管理と捉えると、Puppetの宣言的なDSLは読みやすい気がした
- もっと複雑化してくると違うのかもしれない
- 基本的な記述でシンプルに使う分には簡単
- 最初に抱いていた面倒なイメージは消えた
- むしろ簡単で良いではないかという気分
- 基本的な機能はChef/Ansibleとさすがに違いなさそう
具体的なこと
- 一つの記述でyumやaptとかを自動的に判別して実行してくれる
- ChefよりAnsibleが好きだけど、この方法が分からなくてうーんってなったのを思い出す
- あるべき状態を表す
resource
- 具体的な種類を
resource type
と呼ぶ resource type
は独自に追加定義できる(defined type
)
- 具体的な種類を
resource
をまとめるclass
- 上記のmanifestファイルをまとめる
module
module
の組み合わせとしてのrole
- サーバー毎の役割
resource type
の依存関係を表す書き方- 事前にこれが必要だよ =>
require
- このあとこれをしてね =>
notify
- あれが変わったらこれしてね =>
subscribe
- 事前にこれが必要だよ =>
class
の場合は依存関係を->
や~>
で表すmodule
では命名やパスに色々ルールがある- 変数や条件分岐も使える
感想
説明のバランスが自分にはとても良かった。
動作環境もVagrantを使って「このbox使います」と簡単だった。
段階的に仕様を学んで行く構成も非常に分かりやすかった。
題材とか説明を飛ばしたりとか推奨しない項目について、きちんと理由が書かれていて納得感があった。
これは読みやすさの上で結構重要だったように思う。
各章の最後に「まとめ」として、要約が載っているのがとても良かった。
ハウツー本とかでは良く見る手法な気がするけど、技術本ではあまり見ないかも?
あくまで初歩ということで、扱う項目も最小限になっているっぽい。
- agent/masterモードは扱わない
- node情報を管理しない
- 標準的なディレクトリ構成を用いない
自分は初歩を知りたかったので好都合でした。
総じて言うとすごい説明上手だなーと感じました。