2006-12

なんとなく書く。

自立したメンバーと自立していないメンバー
レベルの高いメンバーと低いメンバー

この組み合わせが混じった状態でどれだけいいパフォーマンスを発揮させることができるか、どれだけ成長させることができるか？

そう考えるとフレームワークは有効。フレームワークは自立していないメンバーとレベルの低いメンバーを普通のメンバーにまで引き上げることができる。

その分自立したメンバー、レベルの高いメンバーが、その他のメンバーの世話に使っていた時間を自分の時間として利用できるようになる。

powered by performancing firefox

ルートになれるユーザーを制限する
http://www.jitaku-server.net/root.html

powered by performancing firefox

sqlplus [ [<option>] [<logon>] [<start>] ]

<logon>は次のとおりです: (<username>[/<password>][@<connect_identifier>] | /)
              [AS SYSDBA | AS SYSOPER] | /NOLOG

例えば、sqlplus user/pass@connect と実行する

DBサーバーなら @connect の connect を省略できるが、クライアントからならあるていど必要らしい。

<blockquote cite=”http://www2.ocn.ne.jp/~links4pg/newpage2.htm#SQLPLUS” title=”SQL*Plus Guide Book”>ＤＢサーバでは「＠ホスト文字列」を省略できる。クライアントでは「ORACLE network administrator」 ≫「Easyconfig」等で定義したネットサービス名に該当する。
（この定義がない運用の場合はクライアントでも「＠ホスト文字列」を省略できる）</blockquote>

powered by performancing firefox

今まで何度やってもしっくりこなかった結合テストが最近ようやくわかるような気がしてきたのでそのメモ。

テストには以下の種類があると考える。

１．単体テスト
２．機能別の結合テスト
３．複数の機能をまたがる結合テスト

１．単体テスト

ユニットテストのレベル。
関数、モジュール単位のテスト。

２．機能別の結合テスト

マスターメンテならユーザー管理という機能単位でのテスト。
全ての機能をコンディションとして洗い出し、
そのコンディションを満たすためのテストケースを作成し、
テストを行う。

この段階で機能別では完璧に動作する

３．複数の機能をまたがる結合テスト

複数の機能を連携させてテストする。
例えば管理ツールで更新して、フロント側でチェックするとか。
クライアントからAPIを呼んで、ちゃんとクライアントが動くとか

以上のテストでだいたい結合テストに漏れはないかなと。

あとは、業務シナリオに沿ったテストをして、
ユーザーに実際に使ってもらって、テスト終了かなと思います。

以上。

powered by performancing firefox