1. ソフトウェアの品質確保 | |||||||||
|---|---|---|---|---|---|---|---|---|---|
潜在している不具合を机上または実機で発見・摘出することで、品質を確保するためにおこなう モジュールごとにおこなうテストで、モジュールテストとも呼ばれる 複数のモジュールを組み合わせたプログラム単位でおこなうテストで、結合テストとも呼ばれる システムを構成するすべてのプログラムを連携させておこなうテストで、総合テストとも呼ばれる 運用時と同一条件下でおこなうテスト ホワイトボックステストとブラックボックステスト
|
ホワイトボックステスト | |||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
テスト対象となるモジュールのすべての命令が１回以上実行されるようにテストケースを作ること。 C0メジャーともいう。 テスト対象となるモジュールのすべての判定条件で、それぞれの分岐方向を少なくとも１回は辿るようにテストケースを作ること。 C1メジャーともいう。
<%
String user_name;
String mail_address;
int uid;
UserManager um;
user_name = (String)request.getParameter("user_name");
mail_address = (String)request.getParameter("mail_address");
um = new UserManager();
uid = um.search(user_name, mail_address);
if (uid != -1) {
String msg = "There is exactlly the same account(";
msg += user_name + " / " + mail_address + ")";
request.setAttribute("msg", msg);
%><jsp:forward page="login.jsp" /><%
}
uid = um.add(user_name, mail_address);
if (uid != -1) {
session.setAttribute("uid", Integer.toString(uid));
}
%>
<jsp:forward page="main.jsp" />
アカウント作成処理の上記のコードにおいて、um.search()はuser_name="iwasaki", mail_address="iwasaki@freebsd.org"の場合のみ1を返し、それ以外は-1を返す。
またum.add()はuser_nameおよびmail_addressの文字列長が1以上でないと-1を返し、それ以外は2以上の値を返す。
| |||||||||||||||||||||||||||||||||||||||||||||||
ブラックボックステスト |
|---|
対象となるモジュールへ与える入力値を、正常処理の対象となる有効同値クラスと、エラー処理の対象となる無効同値クラスに分け、 それぞれの代表的な値を使用してテストケースを作成すること。 対象となるモジュールへ与える入力値を、有効値と無効値の境界値を使用してテストケースを作成すること。 また、出力同値類を考慮することによってもテストケースが得られることが多い。 |
[演習]ソフトウェアの品質確保 |
|---|
２日めで作成したWebアプリケーションのsimpleAppパッケージUserManagerクラスのモジュールのテストケースを作成せよ。 作成基準は以下のとおり。 PCLの様式 ログインページlogin.jspをテストドライバとしてミッション1で作成したテストケースをすべて消化せよ。消化したテストケースは確認欄にチェックを入れること。 |
2. ロードバランサを利用したフェイルオーバ |
|---|
|
[演習]ロードバランサを利用したフェイルオーバ | ||||||
|---|---|---|---|---|---|---|
ロードバランサソフトウェアBalanceを使用して、以下の要件でフェイルオーバの 仕組みを構築する。
Balanceのインストール手順は以下の通り。 $ cd course/day-3/balance $ make $ su # make install [snip] # exit Balanceの使用方法については、man balanceでマニュアルページを参照するか、 開発元の以下のURLなどを参照。 http://www.inlab.de/balance.html今回は待機系サーバについては、サービス停止のメッセージを返すだけの 簡易SORRYサーバを以下の要領で設定して代用する。 # vi /tmp/sorry.sh 入力内容: ---- #!/bin/sh echo '<html><body>Sorry, the service is currently unavailable.</body></html>' ---- # chmod +x /tmp/sorry.sh # vi /etc/inetd.conf 追加内容: ---- sorry stream tcp nowait www /tmp/sorry.sh sorry.sh ---- # vi /etc/services 追加内容: ---- sorry 10001/tcp ---- # vi /etc/rc.conf 追加内容: ---- inetd_enable="YES" ---- # sh /etc/rc.d/inetd start Balanceのソース解析をおこない、アクセスログを出力できるように改造する。 今回は待ち受けポート番号とクライアントIPを、標準出力へ出力する。 ソース解析を支援する環境を構築する手順は以下の通り。 $ cd course/day-3/balance/work/balance-3.42 $ gtags $ htags $ w3m HTML/index.html 以下のようにTomcatのコンテンツとして配置してもよい。 $ su # cp -r HTML balance-src # mv balance-src /usr/local/apache-tomcat-6.0/webapps/ # exit ヒント: -gオプション付きでコンパイルするようMakefileを修正して、 gdbで動作を追跡すると理解が進む なお、アクセスログは標準出力を以下のようにloggerコマンドへ渡すことで、 system logへ記録される。 # balance -f 80 localhost:8180 | logger -t balance |
3. 運用監視ツールの開発 |
|---|
監視サーバからリモートで監視対象機器の監視情報を取得する 監視対象機器で監視エージェントを稼働させ監視情報を 監視サーバへ通知する 機器が正常に動作していることを定期的に監視。ICMP、TCPポーリング、 SNMPトラップなどによる監視対象機器の死活監視や、サービス稼働の監視。 CPU、ハードディスク、ネットワークトラフィックなどのシステムリソース を監視。 ファイアウォールの実装やその監視をおこなう。 |
[演習] 運用監視ツールの開発 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Server system status report: Wed Aug 18 02:54:28 JST 2010 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id 0 0 2 653432 83908 41 0 0 0 69 0 980 1148 2581 812 6 8 86 [Network status] #Connections: 24 SMTP status: OK connections: 0 SSH status: OK connections: 0 TOMCAT status: OK connections: 0 [Process status] #Processes: 126 SMTP status: OK SSH status: OK TOMCAT status: OK SLOG status: OK [Syslog messages] ------------------------------------------------ ------------------------------------------------ End of report
$ sh syswatch.sh $ su # sh syswatch.sh -m |
[演習] 運用監視ツールの開発(続き) |
|---|
現状ではPOSTGRESQLのサービスポート監視およびプロセス監視が実装されていない。 仕様を満たすようsyswatch.shを修正せよ。 system log(/var/log/messages)を監視し、タグ名syswatchの行をroot宛にメールしたい。 ログ監視ツールswatchコマンドを利用し、この仕組みを構築せよ。 このサーバはメンテナンスのためSSHを稼働させているが、 不正アクセス対策のため/var/log/auth.logを監視し、 不正アクセス試行の兆候を検出したら即座にそのIPからの パケットをすべて遮断したい。swatchコマンド、 ホストベースファイアウォール制御ツールipfwコマンドを利用し、 この仕組みを構築せよ。 ipfwの導入方法と特定IPのパケット遮断(および解除)の方法は以下の通り。 # kldload ipfw # ipfw add 32000 allow ip from any to any 32000 allow ip from any to any # ipfw list 32000 allow ip from any to any 65535 deny ip from any to any # ipfw add 30000 deny ip from 202.229.63.242 to any 30000 deny ip from 202.229.63.242 to any # ipfw list 30000 deny ip from 202.229.63.242 to any 32000 allow ip from any to any 65535 deny ip from any to any # ipfw delete 30000 deny ip from 202.229.63.242 to any # ipfw list 32000 allow ip from any to any 65535 deny ip from any to any なお、/var/log/auth.logに以下の文字列が記録されたら不正アクセスと判断する。 authentication error for root ミッション3で実装した特定IPのパケット遮断ルールの追加には、 SSH Brute-Force攻撃によるファイアウォールのルールの肥大化の 問題がある。ルール追加から一定時間(今回は1時間)経過後に そのルールを削除し、この問題を回避する機能を追加せよ。 ヒント1: 時刻を指定したコマンド実行の予約は、at(1)を使う(man at) ヒント2: 時間の計算および出力文字列の加工は、date(1)を使う(man date) SSH Brute-Force攻撃に対処する方法として、ミッション4で実装したような ログファイルの監視の方法の他に、特定のポートのアクセスパターンを監視する 方法がある。 knockdは特定ポートのアクセス順序を監視し、該当するアクセスを検知したら 対応したコマンドを実行することができるソフトウェアである。 http://www.zeroflux.org/projects/knockknockdのマニュアルページには以下のLinux用のサンプルが記述されているが、 使い勝手はあまりよくない。「ポート番号22を10秒間に3回連続アクセスがあったら、 そのIPアドレスからのパケットを1時間遮断する」という設定を追加せよ。
[options]
logfile = /var/log/knockd.log
[openSSH]
sequence = 7000,8000,9000
seq_timeout = 10
tcpflags = syn
command = /usr/sbin/iptables -A INPUT -s %IP% --dport 22 -j ACCEPT
[closeSSH]
sequence = 9000,8000,7000
seq_timeout = 10
tcpflags = syn
command = /usr/sbin/iptables -D INPUT -s %IP% --dport 22 -j ACCEPT
|