<   2012年 10月 ( 8 )   > この月の画像一覧
「失敗のないファンクションポイント」を読んでみた
■よんだ本
失敗のないファンクションポイント

■ひとこと
プロジェクトの規模を表現するファンクションポイントの解説と演習問題が載っている。
例が豊富なので覚えやすい。

見積もりの本はいくつかよんだが一番チンときた。

■マインドマップ
b0232065_429556.png

FunctionPoint.mm


■ちなみに
IPAのソフトウェア開発データ白書とかにあるFPは調整前の値を使っている。
[PR]
by mima_ita | 2012-10-08 04:29 | book
Subversionの属性について調べた
■属性
Subversionには2種類の属性を設定できます。

1つはバージョン管理を行う属性でファイル、ディレクトリに設定できる属性です。
もうひとつはバージョン管理を行わない属性で、各リビジョンとトランザクションに設定できる属性です。

バージョン管理を行う属性の変更では、コミットをおこなわない限りレポジトリに反映されません。

属性には属性名と値で構成されています。

属性値にはいくつか予約されている名前があります。
「svn:XXX」と記述されている属性名はSubversionが使用している属性です。
具体的には第9章 Subversion 完全リファレンス Subversionの属性に記述してあります。

また、属性名は人間によめるテキストである必要がります。
属性の名前は 文字、コロン(:) あるいはアンダースコア(_) で始まり、その後では数字、ハイフン(-)、ピリオド(.) も使えます

値はテキストだけでなく、バイナリデータをも指定できます。
たとえば、jpegファイルの属性値としてサムネイルの画像ファイルを与えることもできます。

なお、ファイルに与える属性はファイルに埋め込まれるわけでなく、隠しフォルダ「.svn」の中にあります。
つまり、電子メールなどでファイルのみを送信した場合に、その属性値はなくなるということです。

その他詳細は下記を参照してください。
http://www.caldron.jp/~nabetaro/svn/svnbook-1.7/html-chunk/svn.advanced.props.html


More
[PR]
by mima_ita | 2012-10-04 23:53 | subversion
ペグリビジョンを使用して過去に消したファイルの中身を確認する
■目的
ペグリビジョンを使用して過去に消したファイルの中身を確認する

■手順
以下のような操作をおこなったとする。
1. 下記のファイルが存在する
http://127.0.0.1/svn/SampleProject/WebProject/trunk/readme.txt

2. rev7で上記のファイルを削除した。

このときにreadme.txtの内容を確認する。

ペグリビジョンを指定しない場合

$svn cat -r 6 http://127.0.0.1/svn/SampleProject/WebProject/trunk/readme.txt
svn: REPORT リクエスト (相手: '/svn/SampleProject/!svn/bc/7/WebProject/trunk/readme.txt') が失敗しました
svn: パス '/svn/SampleProject/!svn/bc/7/WebProject/trunk/readme.txt' が見つかりません


現在のバージョンに存在しないので、取得することができない。
ここで、readme.txtのあとにペグリビジョンを指定する。
ペグリビジョンは@の後にリビジョンを記述することで指定できる。

$svn cat -r 6 http://127.0.0.1/svn/SampleProject/WebProject/trunk/readme.txt@6
・・・readme.txtの内容が表示

[PR]
by mima_ita | 2012-10-04 19:57 | subversion
PSRの規約でコーディングをするために必要な調査
■目的
PHP figが策定したPHPの規約であるPSRがある。

PHP fig
PHPのコーディング規約、PSRについての発表をしました : candycane development blog


この規約でPHPのコードを記述するために必要なことを以下に示す。

More
[PR]
by mima_ita | 2012-10-03 23:59 | php
PHP Security を読んだメモ
■概要
CodeProjectのPHP Securityを読んだときのいい加減な訳とメモ

More
[PR]
by mima_ita | 2012-10-03 19:37 | php
実際にやったDBの自動テスト方法
■目的
ここでは実際にやった、Databaseの自動テストにまわりについて記述する。
OracleとSQLServerが対象になる。

■環境について
ベストは開発者毎のインスタンスを用意する。
インスタンスが1つしか用意できない場合はスキーマーを区切る。

最悪は全ての開発者が1つの環境を使うことである。
なぜ最悪かというと、ある開発者がおこなったテストが別の開発者に影響をあたえる可能性があるからだ。
これは非常にリスクが高い。

また、開発者毎のPCにデータベースをおくかどうかは議論が出るところである。
少人数で制御がきくなら個人の端末に環境を用意したほうが望ましい。
しかし、その制御が利かない場合、必ず古い環境で開発を続行し続けるという人間がでる。
・・・であれば、DB管理者が全ての開発者のDBを管理するというのが望ましいかもしれない。

このあたりは開発者の力量しだいだろう。開発者を信頼できない場合は、絶対にローカルにDBを作らせない。
ローカルにDBをつくるメリットをはるかに超える余計な問題を生む。

■環境の同期
開発者毎に環境を用意した場合、問題になるのはDBの同期である。
ストアドプロシージャーはスクリプトで管理する。
これを自動で適用する。

なお、ほぼ全てのDBはストアドプロシージャーはシステム用のテーブルに格納されているので、そこから取得できる。
つまり、全てのファンクションを抜き出してMD5で表現してしまえば、自分の環境が最新かどうかチェックするのは容易だ。

問題はテーブル構成などが変わった場合。
これは自動で行うのは危険だ。慎重に行うべきだ。

なお、勘違いしている人もいるが、列の追加とか削除も大抵スクリプトでできる。


■テストの方法
自動テストは3段階にわかれる。

1.テストデータの準備
2.テストの実行
3.結果の検証。

1は確実に行える。
やりかたとしては2通りあり、テーブルを空にしたあと、INSERTのスクリプトを投げてテストデータを作る方法。
次にフルバックアップをリストアする方法だ。
フルバックアップは管理者権限がないと厳しいのでスクリプトをなげる方法のほうがいい。
あと、生データだとどんなデータか確認できるが、バイナリだと厳しい。

2テストの実行は任意のストアドなり、プログラムを動かせばよい。
ADO経由すればWSH経由でストアドだろうがなんだろうが実行できる。


3結果の検証が一番困難だ。
テストの実行の内容によってここは2種類ある。
1つは参照系のテスト実行だ。
これは、期待値を外部ファイルなりに保持しておき、それと参照した内容をつき合わせて確認する。
この時、注意すべきはどのデータを取得するべきかだ。
可変の列は比較から除いたほうがいい。たとえば、更新日やユーザー名は変わる可能性があるので、比較に使用しない方が望ましい。
ちなみにORDERBYを聞かせたほうがテストはらくだ。テスト対象のファンクションが行の順番不動の場合、結果の検証はめんどくさい。

つぎに更新系のテストだ。
これは更新をおこなったあと、テーブルを参照して期待どおりに更新されているか確認する必要がある。
理想を言えばのテーブルの内容を抜き出して関係ないテーブルに影響がないことを確認すべきだろう。
しかし、これは時間がかかるのでやめておいたほうがいい。
更新ロックがかかっているかどうかの試験もやろうと思えばできる。
これは、スクリプトで指定のテーブルに更新ロックを掛けて待機する。
その間にテスト対象の処理を実行して例外がかえってくることを確認する。
テストがおわったらスクリプトを終了してやって、再度、実行して今度は正常に動作することを確認すればよい。
これは、更新ロックのチェックがNOWAITの場合のみできる。

これらは、WindowsであればWSHでADOを使用すればスクリプト言語で全て記述できるし、おおくのDBの場合、コマンドプロンプトから実行できるようなツールが提供されている。

なお、どの環境でも、動くテストを記述することが重要だ。
ユーザー名とかはテスト用のユーザを共通でつかったほうが楽だろう。

■DBの自動テストの問題
DBのテストの最大の問題は時間がかかることだ。
テストデータの準備、テストの実行などは通常の単体テストよりコストのかかる処理だ。
自動テストを入れている場合、このDBのテストを行うかどうかはオプションで指定できるようにしたほうがのぞましい。


あと自動化のつねとして、本番環境を飛ばさないような工夫が必要だ。
本番環境とテスト環境のログインユーザーなどが同じなどは本番データを吹き飛ばす可能性があって危険だ。
とくにテストデータをスクリプトで管理していると、それをまちがって本番に流しかねないリスクがある。
可能なら、テストデータのスクリプトの先頭に想定以外のDBではテストを中断するなどのロジックが必要かもしれない。


以上
[PR]
by mima_ita | 2012-10-03 00:40 | テスト
PHPUnitのマニュアルを読んだ
PHPUnitのマニュアルを読んだときに記録したメモを記述する。

PHPUnitはPEARのライブラリ。PHP5.3.1ではインストールできななかった。5.3.17にしたらインストールできた。

イメージ的にJUnitとJMockとdbUnitを合体させたような感じ

More
[PR]
by mima_ita | 2012-10-02 23:38 | php
VBAUnitを使用した単体テスト
■目的
VBAUnitを使用した単体テストについて記述する。

■確認環境
Office 2010
※おそらく Office2000以降なら動くはず

■概要
VBAUnitというVBA用のxUnitが提供されているが下記の問題がある。

1.コマンドラインから実行できない
2.vbaUnitのフレームワークとテストコードの分離ができていない、

これらを改造した。

■サンプル
http://needtec.sakura.ne.jp/vba/vbaunit.zip

More
[PR]
by mima_ita | 2012-10-02 02:09 | VBA



実験ですお
検索
カテゴリ
最新の記事
.NET4.5におけるasy..
at 2014-07-02 00:46
.NETでTwitterを検..
at 2014-06-29 00:49
Redmineのプラグインで..
at 2014-06-28 03:29
IO.popenのwrite..
at 2014-06-28 03:25
RedmineのWikiでU..
at 2014-06-28 03:16
以前の記事
最新のトラックバック
その他のジャンル
ブログパーツ