第9回Quesに参加してのメモ #Ques9

2016/11/17（木） 株式会社サイバーエージェント セミナールーム にて 第9回Ques が開催されました。
https://atnd.org/events/82188

サイバーエージェントの関根さん、medibaの山本さんが講演をされました。
講演の中で出てきたワードで知らなかったものを調べてみました。
自分用のメモ的な内容なので、会場の雰囲気などを感じたかったら、Twitterのハッシュタグ #Ques9 を追ってみると良いと思います。

以下、知らなかったワード。

crashlytics

• http://try.crashlytics.com/
• iOSやAndrooidアプリのクラッシュレポートを収集したり管理してくれるサービス
• アプリにSDKを組み込んで使う

testflight

• https://developer.apple.com/testflight/
• iOS、watchOS、およびtvOSアプリをApp Storeでリリースする前にテストすることができるサービス
• ベータ版のアプリを端末に配信できる

Charles

• https://www.charlesproxy.com/
• HTTP Proxyツール
• Wiresharkみたいなツール

GQM

• ソフトウェア工学における計測の枠組みおよびモデル化の手法。
• ゴール層、クエスチョン層、メトリクス層からなる。

ゴール層 （G 概念レベル）	測定の目的を定義 測定の対象、理由、観点およびコンテキストを定める
クエスチョン層 （Q 運用レベル）	目的達成のために評価すべき質問の定義 ゴールが達成されたか否かを判断する具体的な基準
メトリクス層 （M 定量レベル）	前提となるモデルに基づいて測定可能なメトリクス 上記の質問に対する答えを提供するのに必要な情報を提供する

Five Core Metrics

• 初めて学ぶソフトウェアメトリクスの原書名
• 時間、工数、ソフトウェアの機能量、ソフトウェアの欠陥率、そのソフトウェアのプロセス生産性からなる

ETSS

• http://www.ipa.go.jp/sec/softwareengineering/std/etss.html 
• 組込みスキル標準
• 組込みソフトウェア開発に必要なスキルを明確化・体系化したもの

ESQR

• http://www.ipa.go.jp/sec/softwareengineering/std/emb-esqr.html
• 組込みソフトウェア開発向けの品質指標の定義、計測方法、評価の仕方をまとめたもの

感想

　講演を聞いてまだまだ、知識不足、経験不足を感じました。
　でも、それはまだまだ深掘りするところが沢山あるということでもあると思います。
　そして、講演の中で出てきた山本さんの言葉、

 「QA、テストが日本の産業を救う」

　という言葉にも大いに奮い立たせられました。
　この言葉を糧に毎日頑張ろうと思います。

第2回Ques ～QAエンジニアのためのQA専門イベント〜 に行ってきた

久々にブログ書きます。

先週、「第2回Ques　～QAエンジニアのためのQA専門イベント〜」 に行ってきました。
ソフトウェアQAエンジニアが集まって、いろいろ情報交換したりするイベントでとても楽しかったです。

以下、「アメーバにおけるスマートフォンQA（仮）」と題して、@tmasuhara さんがプレゼンしてくださった内容を箇条書きします。
（ほんとうは ㈱アットウェアの重田さんのプレゼンもあったのですが、ながくなるので割愛。すみません）

---

■自己紹介
* ますはらたかひで @tmasuhara
* デカグラフ のQAやってます

■はじめに
* ques登壇者超募集中です！（切実

■スマートフォンプラットフォームテストの取り組み
* リリース優先、スピード重視
→QAすっ飛ばされることが多い
* リリース情報とかスケジュールは管理共有されていない
* QAは期日からテスト期間・内容を提案
→QAは主体的に動くのが重要。こんなテストをしようぜ！とQA側から提案する
* 仕様書は無い
→仕様の伝達など情報共有はRedmine使っている

■リリースサイクルって？
* ブラウザ版デカグラフの場合
→週一回
* 対応するチケットの数
→ 10 から15 [チケット/週]

■試験環境は？
* QA環境はステージング
→たまーに、本番でやってるw

■保証ブラウザについて
* 試験するスマフォのバージョンについて
→統合ログ解析ツールでシェアを計測してシェアの高いものを対応
→Android 6〜7 台で試験
→iOSは4〜5 台で試験
→アメーバ全体だと保証ブラウザの統制がとれていない（サービスが多すぎるためらしい）

■QAメンバーについて
* デカグラフのQAは1人でやってる
→ぶっちゃけギリギリの人数
→厳しい場合はパートナー会社にお願いしてる
* 子会社にデバッグ部門を作った
→メンバー固定することでノウハウ蓄積
→とはいえ、教育にはいろいろ大変なことがあった

■QAの依頼とかドキュメント関連について
* QAの依頼は試験項目書を作った上で依頼している（Redmineにファイルをアップしてやってる）
→試験表はExcelという伝統的なツールを採用
* 仕様書のクオリティはプロデューサーによってまちまち

■試験実施について
* アメーバもL○NEも人力テストが多い
→実機で人力（実機で試験するのは、エミュレータだとスペック差による問題がわかりにくいからとのこと）

■appleの申請・リジェクトまわりってどうやって対策してるの？
* リジェクト情報と対策のDB作りました
→今後は申請業務も一元管理してく

■テスト自動化は？
* 各プロジェクトで好き勝手にやってる
→ノウハウ共有出来てない
* webのキャプチャツールを作った
→phantom js を使って作った
→時間指定して実施可能、日またぎの表示確認もできるすぐれもの

---

感想など

* 仕様をはじめとした情報の共有ってRedmineだけで事足りてるのかな。もっと突っ込んで質問してみれば良かった
* 保証ブラウザについての絞り込みは真似したいな
* ソースコードの管理も重要なQAの要素だとおもうけど、どうやってるんだろう？Gitとかつかってるのかな？ってのを質問すれば良かった
* 懇親会、名刺忘れたのは致命的だったorz もっといろんな人と話したかった

Jenkins 使って SeleniumRC のテストを実行しようとしたら PHPUnit が動かない

Jenkins 使って SeleniumRC のテストを実行しようとしたら PHPUnit が動かないという現象に出会ったのでメモ。
ちなみにバージョンは

• Jekins : 1.442
• SeleniumRC : selenium-server-standalone-2.12.0
• PHPUnit : 3.6.4

まず、テスト実行すると Jenkins のテスト結果に

失敗


phpunit.xml.
過去 2ビルド失敗 ( 失敗#3 以降 )
所要時間 0 ms
説明を記入
スタックトレース

と表示されたので続いて、コンソール出力を確認したところ Fatal error が発生しているとのこと。

PHP Fatal error:  Call to undefined method PHPUnit_Framework_ExpectationFailedException::setCustomMessage() in /usr/share/php/PHPUnit/Extensions/SeleniumTestCase.php on line 1068

ソースコードを見てみると、確かに setCustomMessage() が無い。。。
PHPUnit のバージョンが上がってこのメソッドが削除されたみたい。

その変更は↓で見て取れる。

https://github.com/sebastianbergmann/phpunit/commit/7b37221b785dd5aeda8794e8ffdcbfd8cf3aad7b#PHPUnit/Framework/ExpectationFailedException.php

なんで削除したのかとかまでは追ってないですが、とりあえずこのメソッドを追加してエラー回避してナントカ解決。

追加した内容↓

/**
 * @param string $customMessage
 * @since Method available since Release 3.4.0
 */
public function setCustomMessage($customMessage)
{
    $this->customMessage = $customMessage;
}

Gmail から OpenPNE に携帯メール投稿する方法

Gmail のWebメーラーの設定に携帯メールアドレスを追加してあげると、Gmail からOpenPNE に携帯メール投稿ができるようになります。

■必要なもの、こと

• Gmail アカウント
• 携帯メールアドレス（このアドレスはOpenPNE側に登録してある必要がある）
• OpenPNE側のメール配信設定(postfixなど)

■やりかた

前提として、OpenPNEのメール配信設定(postfixなど)が出来てるものとします。

1. ブラウザを開いてGmailにログインする
2. Gmailのメール設定ページにアクセスする
3. メール設定の「アカウント」にある「名前」の項目に携帯メールアドレスを追加する
4. 携帯アドレスを入力し次へと進む。（途中、いろいろ設定を聞かれるが、すべてデフォルトのままでOK）
5. 登録できたら、Gmailのメール作成をクリックしメール作成画面を開く
6. Fromを登録した携帯アドレスのものにする
7. OpenPNEのメール投稿用のアドレスを調べて送信先に入力する
8. 件名、本文を入力し送信する(画像を添付すれば画像付きの投稿になる)

OpenPNE側をみると投稿できているとおもいます。

■投稿出来ていない場合の考えられるポイント

• まだメール投稿を処理中　→　ちょっと待てば表示されるはず。Reloadしてみて！
• メール配信設定が出来ていない
• 使用している携帯アドレスがOpenPNEにアカウント登録されていない

■まとめ

• SeleniumIDEなどと組み合わせればメール投稿も自動で確認できそうですね
• OpenPNE 3.6.x でしか確認してないけど2系もきっと同じでできるはず
• Fromを偽装出来ればどんなメーラーでもできそう（でも、Gmailだといろいろお手軽だよね！）

Macのhomebrewでapcを入れてみた・・・・が

2011/10/31のエントリで書く予告しちゃったので、書きます。
 前回のエントリを雛形に手抜きエントリです。。。ふぁ~(=o=;) というわけで、

OpenPNE3の動作テストで必要だったので、MacBookAir(Mac OS X 10.6.8 Snow Leopard)に apc を入れることに。
自分のMacにはhomebrewが入ってるので、もしかしたらbrew installできるかも？とおもって調べたらあった！

$ brew search apc
apc

というわけで、

$ brew install apc

で、インストール、そして問題なく完了！ ↓をphp.iniに追記して、apacheを再起動！

[apc]
    extension="/usr/local/Cellar/apc/3.1.9/apc.so"
    apc.enabled=1
    apc.shm_segments=1
    apc.shm_size=64M
    apc.ttl=7200
    apc.user_ttl=7200
    apc.num_files_hint=1024
    apc.mmap_file_mask=/tmp/apc.XXXXXX
    apc.enable_cli=1

セットアップ出来たかどうか、

<?php
phpinfo();
?>

みたいなファイル作って、ブラウザからアクセスすると・・・・・・



あれ？？(；・∀・)

php動いてない？(；´Д｀)


どうも brew install でいれた apc 3.1.9 はバグがあるっぽい？

$ brew uninstall apc

を実行してアンインストール完了。(php.iniに追記したものを消すのも忘れずに)


気を取りなおして pecl のサイトからパッケージダウンロードしてインストールすることに。。。

$ wget http://pecl.php.net/get/APC-3.1.7.tgz
$ tar -zxvf APC-3.1.7.tgz

で、パッケージ落として展開。

$ cd APC-3.1.7

で展開したディレクトリに移動して
PHP 拡張モジュールのビルド環境を準備するために、 phpize コマンドを実行。

$ phpize

んでもって、↓のコマンドでコンパイルおよびインストールをする。

$ ./configure
$ sudo make
$ sudo make install

あとは php.ini に↓を追記して、apache再起動すればおｋ。

[apc]                                                                                                                      
  extension_dir="/usr/lib/php/extensions/no-debug-non-zts-20090626"
  extension="apc.so"
  apc.enabled=1
  apc.shm_segments=1
  apc.shm_size=64M
  apc.ttl=7200
  apc.user_ttl=7200
  apc.num_files_hint=1024
  apc.enable_cli=1

できたー＼(^o^)／

Macのhomebrewでmemcachedを入れてみた

OpenPNE3の動作テストで必要だったので、MacBookAir(Mac OS X 10.6.8 Snow Leopard)にmemcachedを入れることに。

自分のMacにはhomebrewが入ってるので、もしかしたらbrew installできるかも？とおもって調べたらあった！

$ brew search memcached
libmemcached    memcached       memcached-php   memcachedb

というわけで、

$ brew install memcached

で、インストール、そして問題なく完了！

インストール出来たかどうか、phpinfo()を見てみると・・・・・




あれ？いない？(；・∀・)




どうも brew install だけではphpの拡張が入らないっぽい？

気を取りなおして

$ pecl install memcache

を実行して無事インストール完了。

後は /etc/php.ini に

extension=memcache.so

を追記してあげれば設定完了。
(自分は988行目あたりに追記した)

次回のエントリでは「homebrew で apc 入れてみた」を執筆予定です(^^)

リリース日とテスト日の関係

【メモ】
これはあくまでも自分用のメモです。

リリース日の2日前には、テストを終わらせる必要がある。
2日前にテスト終了し、1日前にはまた修正が入る可能性があるから。（というか確実に入る）
そして、リリース当日を迎えるのである。

OpenPNE2系のソースコードの行数を調べる

OpenPNE2系のソースコードの行数の調べ方

　$ find ./ \( -name "*.php" -o -name "*.inc" -o -name "*.tpl" \) | grep -v "^./lib/" | grep -v "^./var/" | xargs wc -l

うずら技術メモより

自分はsmartyファイルの行数も知りたかったので「*.tpl」を追加して実行した。
結果は129839 行だそうです。（OpenPNE2.14.xの場合）

ちなみにバグは1000行中に2とか４とか含まれる”らしい”ので、OpenPNEのソースコードには約259.678個～519.356個あると推測される。

１０００行中のバグ数は日本製のソースコードだともう少し良くて1.96個だそうなので、この値で計算すると

約254.48444個。

ほんまかいな？

メトリクスとは

メトリクスとは品質を測るものさしみたいなもの。
品質測定とか評価尺度という。
コードの行数などもメトリクスになる。
コードカバレッジとかもそうなのかな？？

私が普段やっているテストは

受け入れテストというものだろう。

JSTQBによると受け入れテストとは

システムがユーザーのニーズ、要件、ビジネスプロセスを満足するかチェックする公式のテストのことらしい。

要は仕様を満たしてるか？

ってことか。

いや、仕様が間違っている場合もあるから、一概に「仕様を満たす＝受け入れテストOK」というワケでは無いと思った。

エクセルテスト表 VS Testlink

ソフトウェアテストでエクセルとTestlinkをくらべて良いなと思った点。


■Testlinkの良い点

• 機能ごとや条件などのテストケースが見やすい
• テスト結果が自動でつくられる
• Redmineと連携できる
• 担当者ごとの進捗がわかる
• コミット入らずで共有がし易い
• 機能を横断するようなテストしても結果がわかり易い
  

■Excelの良い点

• 使い慣れている

くらい・・・？

もっと無いのか？

Testlinkの良い点について付け足すと

●機能ごとや条件などのテストケースが見やすい

　→　テストスイートというテストを階層化して作成＆表示するのでどの機能のどんなテストというのが見やすい

●テスト結果が自動でつくられる

　→　テスト結果のグラフ表示、テスト結果のレポート作成など自動で作成しHTML、Excelなどに出力してくれる。テスト報告書が短時間で作成できる。

●Redmineと連携できる

　→　バグチケットとのテスト結果との行き来が非常にラクにできるので、チケットを見返す作業をよりスムーズに行える。

●担当者ごとの進捗がわかる

　→　テストスイートごとやテストケースごとに担当者をアサインしてテストを実行するため、各担当者ごとのテスト結果を表示することができる。

●機能を横断するようなテストしても結果がわかり易い

　→　一つ前とかぶるが担当者をアサインしてテストするので、対応したテストがどのよう状態にあるのかテスト結果から追いやすい。

●コミット入らずで共有がし易い

　→　Webアプリケーションなので共有時に特に注意することも無い。余計な心配をしないですむ。

じゃあ、Testlinkの悪い点は？

• Webサーバーにインストールしないといけないので若干スキルが必要
• Testlink上では非常にテストスイートやテストケースの作成はしづらい

テストケースの作成はTestLinkCnvMacroというのを使えばいいのだが、ちょっと慣れが必要な気がする。