« 2008年1月 | トップページ | 2008年3月 »

ceg2dtツール - 65%くらい完成

今日は深夜メンテナンス。少し休憩。

==

原因結果グラフをデシジョンテーブルにするツールを勉強のために作成しているが、6割くらいできた。未実装なのは、

  • 制約条件(REQとMASK)

  • Tとt、Fとfの違い

  • 最適化
  • 何とかなりそうな気がしているが、コードがまったくエレガントではないし、長い。。。。

    1. サンプル1:チケットの学割
    2. デシジョンテーブル(2) - たまゆら雑記の例を使わせていただきました。 Ceg2

      この例だと、なんかあってそうな感じ。でもよくみると、偏ってる。#5は「埼玉に在住でない」「学生証を提示していない」のほうがベターか。

    3. サンプル2:ログイン画面

    4. 原因結果グラフ - 論理点カバレッジの解剖の例を使ってます。
      Ceg3

      これは、マス目の埋まっていないところの決め方が偏っているため、テストケース数が多い。最適化の課題か。

    5. サンプル3:結婚

    6. 結婚できるかどうかの原因結果グラフ。
      Ceg4

      一見うまくいってそうだが、「16歳以上」「18歳以上」の組み合わせが矛盾。制約条件が中途半端だから。

    | | コメント (0) | トラックバック (0)

    制約条件からデシジョンテーブルを埋めていく

    今日はお風呂を掃除して、近所のスタバのドライブスルーでラテ買ってきて、和室でお勉強。amazonから本も届いたし読むかな。

    ==

    原因結果グラフを元にしてデシジョンテーブルを作成していく手順を自動化して、理解を深めようとしてるのだが、以下の例でいろいろ考え中。
    Ceg2
    Ceg

  • 制約条件(男性と女性)

  • まずは、3つのテストケースを列に組み込んでみた。これは論理接点1~3について、行列を転置したもの。ここで、制約条件(「男性」「女性」はONE制約)から、空欄となっている原因ノード「女性」は自動的に決定される。

  • 制約条件(年齢)

  • 原因ノード「18歳以上」がTrueである場合は、もうひとつの原因ノード「16歳以上」も自動的に決定される(REQ制約)。んー、年齢は「15歳以下」「16歳か17歳」「18歳以上」にしたほうがよかったかな。


    たぶん、こういうようにTrue/Falseを決定しつつ、カバレッジ率をあげて、未確定のマス目も埋めていく感じですすめていくかな。

    | | コメント (0) | トラックバック (0)

    原因結果グラフ→デシジョンテーブル(途中までツール化)

    JacaScriptが初心者向けなのかどうかは別として、手ごろだったので原因結果グラフからデシジョンテーブルを作成するツールをJavaScriptでためしに作り中。エクセルVBAとかのが使えるんだろうな。

    原因結果グラフ→デシジョンテーブル(v0.2)
    # Opera9.26で確認中。まだブラウザによっては動作しないかも。。。

    以下、TODOとして。

  • ブラウザ違いでのチェック

  • ノードやリンクの入力方法を考える

  • 制約条件の実装

  • Don't Care状態のマス目対応の実装

  • 検算の実装

  • | | コメント (0) | トラックバック (0)

    Don't write redundant tests, and don't write too few tests. - テストは無駄なく漏れなく

    昨日は社内では改正される特電法のお勉強会。社外ではWeb自動テストツールのお勉強会。

    ==

    TotT: Too Many Tests by Google Testing Blog

    単純な処理を例に挙げて、「テストケースが非常に多いこと」の考察をしている。int型の単純なべき数(=2^32のパラメータ数分のべき)では、多すぎる。条件分岐がTrueの場合とFalseの場合の2通り(100%ステートメントカバレッジ)は、少なすぎる。境界値と同値クラスを考慮した場合も、少し多そう。最後は、条件分岐(OR条件)がTrueになる場合(=3通り)とFalseになる場合(=1通り)を考え、そのサブ処理で各2通りを考えた10通り。


    | | コメント (0) | トラックバック (0)

    原因結果グラフ - 論理点カバレッジの解剖

    方針転換。JaSSTの「三賢人、テストを語る」のPDF資料にある、カバレッジ表を読み解く。

    また例題。
    Ceg

    IDとパスワードを入力して、ログインする画面についての原因結果グラフとします。ここでまず、網羅すべき論理展開式(論理接点、論理点?)がいくつあるかを調べる。これは、それぞれのエッジの交叉点に注目するとわかる。ANDであれば、Tになる1通りとFになるn通りがあるので、(n+1)通り。ORであれば、Fになる1通りとTになるn通りがあるので、(n+1)通り。ということはこのグラフで言えば、3+3+3+3+2=14通りとなる。14通りの論理展開式がどのように出現するかをマトリックスにするため、行には論理展開式を、列にはノードを並べた14×10行列を用意する。

    Photo

    ちなみに、薄緑色は原因ノード、イタリックは中間ノード、薄オレンジ色は結果ノード。ここにどんどんT/Fの組合せを記入していく。

    Photo_2

    ここからは、すべての論理展開式が出現するようにテストケースを組み立てていくのだが、この場合だと4組ですべて網羅した。

    Dt

    出現した論理展開式をチェックするとこんな形のマトリックスが完成する。「x」は1回だけ出現し、「#」は2回以上出現したことを表している。「#」は1回だけ出現し、「x」は2回以上出現したことを表している。

    Photo_3

    この流れでツールを作ってみるといいかな。ただ、PDF資料だと、最後のテストケースの選び方は割愛されている模様。

    | | コメント (4) | トラックバック (0)

    原因結果グラフを解剖 - 原因から?結果から?

    BlackBerryのメールは本文をBase64にするみたい。

    ==

    原因結果グラフをデシジョンテーブルに変換する際、まずは小さなテーブル(サブテーブル)を作成してから、全体のテーブルを作っていく手順で僕は行っていたが、サブテーブルはどちらから結合したほうが簡単なのだろうか。ごくごくシンプルな原因結果グラフであれば、中間ノードと結果ノードから大枠をサブテーブル化して、細部を組み立てるほうがわかりやすそうだけれども、制約条件が関係してくると、原因ノードと中間ノードからサブテーブルを作成して、制約条件を先に考慮したほうがよさそうにも思える。

    などと考えてみる。

    今のところの結論としては、原因側から右側へ結合させていくほうがよさそうに思える。原因ノードと中間ノードについてのサブテーブルを作成する際に、原因ノードと制約条件をもつ原因ノードも一緒にしてしまうといいのではないか。

    | | コメント (4) | トラックバック (0)

    [例題]同値分割・境界値分析観点でテスト設計する

    携帯の充電池が膨らんじゃって、ドコモショップに持っていったら、無料交換してくれた!やった!

    ==

    初心にもどって、同値分割、同値クラスを調べてみる。


    同値分割とは、入力データを「同じ出力結果が得られるグループ」に分割することをいいます。このグループのことを「同値クラス」と言います。また、正常処理を行う同値クラスを「有効同値クラス」と言い、エラー処理を行う同値クラスを「無効同値クラス」と言います。

    同値分割とは何か? - たまゆら雑記



    起こりうるすべての事象をいくつかのグループに分け、各グループから 代表値を選ぶ方法です。 このグループを「同値クラス」といい、同様の出力結果が得られる 入力値の集合です。 ・境界値分析 同値クラスの境界値付近を入力値として選んでテストする方法です。

    同値分割、境界値分析



    同値分割(equivalence partition): 仕様上、コンポーネントやシステムの動作が同じと見なせる入力定義域や出力定義域の部分。

    JSTQB ソフトウェアテスト標準用語集 日本語版Ver 1.1 PDFファイル


    事象をグループ分けして代表元のみテストを実施する。なのでグループ分けは結果が同じになるような入力集合になる。電源ボタン、リセットボタンについては、すでに単機能テストで結果について網羅できそうなので、ここではポイント(上)ボタンについて考えてみる。ポイント(上)ボタンを押すことでスコアボードはどんな結果を生じるか。

  • 上のプレイヤーのポイントが15増える

  • 上のプレイヤーのポイントが10増える

  • 上のプレイヤーのポイントが増える ※タイブレーク時

  • 上のプレイヤー側のアドバンテージ表示となる

  • DEUCE表示となる

  • 上のプレイヤーの勝利でゲームが終了する(ポイント欄がリセットされる
  • これら6つの同値クラスが考えられるため、各同値クラスの代表元を選択して、テストケースとする。

    Photo_6

    ポイント(下)ボタンについては上下を逆にしたテストケースを考えればよい。番号B-01-03がテストしにくいな。


    | | コメント (0) | トラックバック (0)

    [例題]単機能テストを設計する

    1. [例題]テニスのスコアボード
    2. [例題]分析する - 3色ボールペン版
    3. [例題]分析する - マインドマップ版

    仕様分析からテスト設計へ。まずは、単機能テストの設計をしてみる。
    ・・・
    ・・・
    ふと、単機能テストを検索してみると、けっこう「単機能テスト単体テスト、コンポーネントテスト」という記述があったりする。単なる用語の使い方の違い、という考え方もあるけれど、僕の認識では、単機能テストと単体テストは違うテストと思う。単体テストの目的は、「関数・メソッドといった”システムの一部”が正しく実装されているか」であり、やり方によっては組み合わせテストも含まれるし、主にホワイトボックステスト(あるいはグレーボックステスト)で設計されることが多い。一方、単機能テストの目的は「機能が単独で正しい動作をするかどうか」であり、組み合わせテストを含まず、実行結果が注目されるテスト。ブラックボックス的。

    # 当然、後者の意味で「単体テスト」と表現する場合もありました。

    などと思いをめぐらしながら、例題の単機能テストへ。



    1. 電源ボタン
    2. 仕様をみてみると、
      Photo
      電源の切り替えができるかどうかが単機能テストであろう。
      Photo


    3. リセットボタン
    4. 仕様より、
      Photo_2
      電源ONの状態で、画面がリセットされるかどうかが単機能テスト。
      Photo_3


    5. ポイント(上)ボタン
    6. ポイントボタンは仕様がやや複雑であるが、ここではもっとも基本的な動作である、電源ONの状態で、上のプレイヤーのPOINTSが追加されるかどうかを単機能テストとする。GAMESおよびSETSへの反映パターンはここでは考慮しない。という方針。
      Photo_4


    7. ポイント(下)ボタン
    8. ポイント(上)ボタンと同様。
      Photo_5

    こんな感じ。このスコアボードはボタンが4つしかなく、減点機能がないため、これらのテストケースの実施順序は最終的に変更する予定。


    | | コメント (0) | トラックバック (0)

    [例題]分析する - マインドマップ版

    例題を作って、テスト設計をしてみる。

  • [例題]テニスのスコアボード

  • [例題]分析する - 3色ボールペン版
  • ==

    Tennisscoreboardmm_2

    マインドマップから始めるソフトウェアテストでは、仕様分析~テスト計画~テスト設計~といった流れで、マインドマップをツールとして利用している。ここでは仕様分析+アプローチといったニュアンスでマインドマップを使ってみた。各メインブランチにふれてみると、

  • 単機能テスト
  • ここでは、ボタンを押すと仕様どおり(電源が切り替わったり、ポイントが増えたり)動作することを確認すること。スモークテスト的なテストでもいいかも。

  • 同値・境界値テスト
  • ポイント数、ゲーム数、セット数。ゲームが終わるとき、セットが終わるとき、試合が終わるとき。表示の桁数などなど。

  • 状態遷移テスト
  • 業務シナリオテストに近いイメージ。実際の試合を想定した利用。効果的、効率的なテストを目指す。

  • 組み合わせテスト
  • この状況でこのボタンを押したら、こうなる。

  • テストしない
  • ソフトウェアテストの例題なので、外部環境はできないですね。あと、数字がちゃんと表示されるか。とか。

  • テニスのルール
  • スコアのつけかたって、意外に複雑なのだよ。15ずつ増えたり、増えなかったり。タイブレークがあったり、なかったり。

    こういうのって数をこなしていくことも重要なのかな。ここ何日かは通勤バスの中でテキストを読んで復習してます。


    | | コメント (2) | トラックバック (0)

    原因結果グラフを解剖 - 制約記号

  • 原因結果グラフを解剖 - AND/ORなど
  • 引き続き、制約条件を表すグラフをチェック。制約とはありえない組合せを表現するための表記で、ソフトウェアテストではとても重要。

  • EXCLUSIVE OR(EXC、排他的)
  • 排他的EXCは、原因ノードのうち「T」になれるのはひとつだけ。「NHKを見るか、フジテレビを見るか、それともテレビを見ないか」。

    Cegexc


  • INCLUDE(INC、包含)
  • 包含INCは、原因ノードのうち、少なくともどれかが「T」でなければならない。「自動販売機の、コーヒーを押そうか、お茶を押そうか、それとも両方押しちゃおうか」。

    Ceginc


  • ONE(ONE、一方のみ)
  • ONE制約は、原因ノードのうち、どれかひとつだけが「T」でなければならない。「じゃんけんの結果は、勝ちか、負けか、あるいはあいこ」。

    Cegone


  • REQUIRE(REQ、必要)
  • REQ制約は、原因ノードが「T」ならば、かならず結果も「T」にならなければならない。「充電がなくなれば、携帯電話はつながらない」。ちょっと違うか。

    Cegreq


    この他にも、隠蔽(M)があるらしいのだが、お目にかかったことがない。どういうときに使う制約なんだろう。

    | | コメント (6) | トラックバック (0)

    原因結果グラフを解剖 - AND/ORなど

    NHKクローズアップ現代でソフトウェア品質のプログラムがこの前やってた。見逃した。

    「ソフトウエア危機 ~誤作動相次ぐハイテク製品~」

    ブログで少し検索したので、リストアップ。

  • ソフトウェアの欠陥はなぜ無くならないのか

  • NHKクローズアップ現代 ソフトウェア危機
  • ==

    原因結果グラフのテーブル作成をツール化する前に、基礎的なことを復習・まとめてみる。小さなテーブル作成をしているうちに何かいいことが気づけるかなあと。手持ち資料で原因結果グラフを勉強するとなると、マイヤーズ本くらいしかないが、わかりにくい表現が多い。自分なりの言葉でまとめてみる。

  • IDENTITY(同値)
  • 原因が「T」なら、結果も「T」。原因が「F」なら、結果も「F」。原因と結果が同値な状態をさしていて、デシジョンテーブルも非常にシンプル。

    Cegidentity

    これは中間ノードが入ってもデシジョンテーブルは同じ。

    Cegidentity2


  • NOT(否定)
  • 原因が「T」なら、結果は「F」。原因が「F」なら、結果は「T」。原因と結果の関係が逆になるケース。

    Cegnot


  • AND(積)
  • 原因が2ノード以上関係して、さらにその論理積で結果を決定するケース。「身長が高くて、学歴が高くて、高収入なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列(結果が「T」=1、「F」=3)となる。

    Cegand

    単純に考えてみると、原因(真/偽)が3つあるので、全数では2^3=8列になるはずである。しかし、原因の複数項目が「F」だと、どの原因が結果を決定しているかが判断できない。つまりは、#2、#3、#4の3列は、それぞれノード11、ノード12、ノード13が結果を「F」にする原因となっていることを確認することが目的であるため、下図#5のようなテストケースは適当ではないのだ。これは経路感光(path sensitizing)というそうです。

    Cegpathsensitizing


  • OR(和)
  • 原因が2ノード以上関係して、さらにその論理和で結果を決定するケース。「医者か、弁護士か、あるいはIT長者なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列(結果が「F」=1、「T」=3)となる。

    Cegor

    ORとANDは表裏の関係なのがポイント。高校のときに習った、ド・モルガンを思い出せ。

    さーて、続きはまた今度。次は制約記号だな>EXC、ONE、INCなどなど

    | | コメント (0) | トラックバック (0)

    [例題]分析する - 3色ボールペン版

    [例題]テニスのスコアボードのテストをしてみるのだが、まずテスト対象の分析をしてみる。分析をしてどんなテスト設計をするのか、テスト技法を使うのか、などなどを検討する。今回は、ソフトウェアテストPRESS Vol.2 「3色ボールペンで読む仕様書」にならってやってみようかな。

    1. 赤 - 客観的に見て、最も重要な箇所
    2. 今回は、同値分割や境界値などに使えそうな箇所もあげてみた。
    3. 青 - 客観的に見て、まあ重要な箇所
    4. 実は微妙に青色って難しい。。。
    5. 緑 - 主観的に見て、おかしいと感じた箇所
    6. おかしいというか仕様があいまいであったり、矛盾がある箇所としてみた。

    32


    次回はマインドマップを分析ツールとして使ってみる。予定。


    | | コメント (0) | トラックバック (0)

    [例題]テニスのスコアボード

    原因結果グラフをデシジョンテーブルにするツールを作ったら、理解が進むかなあ。

    ==

    テスト設計の例題。自分で出して、自分で考える。
    Tennisscoreboard_2

    テニスのスコアボードのテスト

    1. 電源でON/OFF切り替え
    2. 電源をONにすると初期状態で起動
    3. 電源OFF状態ではどのボタンも無効
    4. リセットを押すと初期状態
    5. ポイント(上)を押すと上のプレイヤーにポイント
    6. ポイント(下)を押すと下のプレーヤーにポイント
    7. デュースは「40-40」と表示
    8. アドバンテージはリード側に「AD」と表示し、反対側は無表示
    9. ゲーム終了時に「0-0」に戻る
    10. 5セットマッチ、最終セット以外はタイブレーク
    11. 3セット取った状態でポイントを押すと初期状態
    12. ポイント減点機能はない
    13. 2つ以上のボタンを押したら、後から押したボタンは無効
    14. 2つ以上のボタンを同時に押したら、1ボタンだけが有効で、優先順位は、電源>リセットボタン>ポイント(上)>ポイント(下)

    まずは、3色ボールペンとかで仕様チェーック、かな。

    | | コメント (0) | トラックバック (0)

    デシジョンテーブルの結合(具体例)

    [サイト]ソフトウェアテスト、HAYST法、などなどのサイト紹介で紹介したサイトにあった、原因結果グラフによるテストケース作成を実際に試してみたが、あきやまさんご指摘のとおり、間違えていた。もう一度順を追ってやり直してみたので、その結果を書いてみた。

    ==

    まずは、原因結果グラフを簡略化してみる。
    Ceg1_2

    中間ノードは存在しないので、4つの結果に対するデシジョンテーブルを作成。
    Dtsub_2

    そして、これらを単純に結合する。ここまでは素直。太枠の部分がそれぞれのサブテーブルにあたる。
    Dtmain1_4

    ここでONE制約があるので、必然的にT/Fが決定する部分を埋める。便宜上小文字のt/fとする。
    Dtmain2_2

    このデシジョンテーブルにはすでに重複する列があるので、それらを除外する。
    Dtmain3

    この時点でデシジョンテーブルを整理してみると、左側7列の中に、最初に作成したサブテーブルの組み合わせが全て出現していることがわかる。ということは残りの#12と#13の空欄をどのように組み合わせても重複する列になってしまうため、除外する。
    2008/02/06追記。#2のテストケースの結果が間違っていましたので、修正しています。あきやまさん、ご指摘ありがとうございます。
    Dtmain42

    あとは、ナンバリングしなおして、#7の13のマス目に適当なt/fを埋めて完成。今回は「f」とした。
    2008/02/06追記。上図同様#2のテストケースの結果を修正。
    Dtmain52

    ==

    さて、ここで自分への問題。どうしてテーブルの結合で誤りがあったのか。考えうる原因として、

  • 重複列の判断を間違えた(判断の仕方が適切でなかった)

  • 空欄・DCの考え方が間違っていた

  • 検算を忘れた(サブテーブルの組み合わせの確認)
  • あたりか・・・

    | | コメント (6) | トラックバック (0)

    [サイト]ソフトウェアテスト、HAYST法、などなどのサイト紹介

    2007年に引き続き、2008年もソフトウェアテストの重要な年になるかも?

    ==

    ブログ更新を怠っていましたが、その間にソフトウェアテストのサイトが立ち上がっているようです。

  • Software Testing
  • zohoで作られたソフトウェアテストのまとめ的サイト。主として動的テストに関する記述。体系的でもあり、用語の解説、参考文献なども付記されており、「興味を持ったから参考文献を調べてみよう」といった流れで勉強もできそう。文献以外にもインターえんっ途上に公開されている記事などもリンクされていて、非常にためになります。制御パステストテストツールのサイトもある模様。


  • 直交表によるソフトウェアテスト 『HAYST法』の解説と学習
  • 著者がHAYST法について、職場向けの資料を作成して、それを公開しているサイト。職場向けの資料ということで、非常に細かい説明が掲載されており、図表や演習問題まで揃っている。

    HAYST本とともに、自学用にはとても重要・貴重なサイトであろう。交互作用についての解説も少し載っているのは、HAYST本にはないポイントか。


    2008/02/04追記:

  • ソフトウェアテスト(ブラックボックステスト入門) - ディノオープンラボラトリ
  • ソフトウェアテストの社内勉強会資料を公開しているサイト。ブラックボックステストの「同値分割」「境界値分析」「デシジョンテーブル」「原因結果グラフ」についてのPDFが閲覧できます。pukiwikiの更新画面の原因結果グラフ、僕もためしにやってみました。僕はぱぱっとできないから、4テストケース7テストケースに落ち着くのに少し時間がかかりました。。。汗。続きが楽しみ~。


    2008/02/05追記:

    ちなみに、実際にやってみた感じの画像を貼る予定。(お昼過ぎに作成して一旦アップしたのですが、検算で間違い見つけたので、またやり直し~)

    | | コメント (4) | トラックバック (0)

    [ツール]TestLink - フリーのテスト管理ツール

    SQuBOKガイド読み中。お風呂で。

    ==

    昨年、TEF有志による日本語化プロジェクトが発足し、今ではばりばり日本語で利用できるようになったのが、このテスト管理ツール「TestLink」(2008年2月2日現在で、1.7.3版が安定版)。少し休みの日を使って、自分のPCに載せてみたりした。


    引用:TEF有志によるTestLink日本語化プロジェクトより

    特徴としては、

  • 簡単な導入手順(WindowsでもLinuxでも可)

  • テストプロジェクト、テスト計画、テストスイート、テストケースの管理支援

  • テストケースのデータ蓄積、再利用

  • テストドキュメント生成支援(ノーマルからWord/Excel、メールなど)
  • などがあげられ、リーダもマネジャーもプログラマもQAも一度は手にとって試してみたいツール。ソースからインポートファイルへの変換ツールが作成されたり、活動的なプロジェクトなのもよいですね。今後はSeleniumとの連携なども予定されているようですし、コードレビューやテストケースレビューなどへの応用など、興味深いプロジェクトです。

    | | コメント (2) | トラックバック (0)

    C言語の単体テスト、いろいろ

    ある意味、餃子ブームだ。

    ==

    メールサーバってCだから、C向けのテスト手法はいろいろと調べたりすることが多いし、自分でツールを作ったりします。せっかく調べたので、C言語をターゲットとした単体テスト/ユニットテストツールを枚挙してみる。

  • CUnit
  • http://sourceforge.net/projects/cunit/によるユニットテストフレームワーク。出力に「__FILE__」「__LINE__」を記載して、分析しやすく結果を表現する。XML出力モード(Automatedモード)で実行し、DTDとXSLスタイルシートによって、統計情報が見やすくなる。


  • CUnit for Mr.Ando
  • 安藤利和さんによる「言語技術者のC言語技術者によるC言語技術者のための C言語テスティングフレームワーク」。ソースはhttp://sourceforge.jp/projects/cunitforando/から入手。関数のスタブ生成でテストを実行していく。ドキュメントには使い方のほかに、単体テストの原理などの記事も。


  • CCUnit
  • Cのユニットテストツールはネーミングが特徴的なものが多い。CCUnitは「繰り返し可能なテストを書くため」のフレームワーク。CCUnit クックブックが、適用への近道か。ソースは、こちらから入手。


  • CuTest
  • ネーミングは、「C Unit Testing Framework」。このキュートなテストプログラムは、make-tests.shによって生成される。ソースはこちら


  • Cutter
  • マニュアルが充実している。テスト実行の進捗状況を「.」「F」を並べて見やすくしている。その他、テスト結果詳細として、テストケース数、テストパス数、テスト失敗数、テスト異常終了数、テスト保留数などがわかる。ソースはこちらから。


  • MinUnit
  • 3行だけのユニットテスト。「a minimal unit testing framework for C」は、個人的にはライトで小気味よく、重宝してます。


    --

    リファレンスやチュートリアルが充実しているのですが、より実践的な例があるといいなーなんて思ってたりして。こういったツールの活用と効果的なテスト設計によって、結合テスト・システムテスト、あるいは静的テストの負荷軽減を図っていこう。

    | | コメント (4) | トラックバック (0)

    « 2008年1月 | トップページ | 2008年3月 »