「ほっ」と。キャンペーン

<   2008年 03月 ( 2 )   > この月の画像一覧

特に仕事がないので、仕事を探す旅に出たところ、
T部長のところでお仕事をもらうことができた。
ああ良かった。
ブラブラしてても良いんだけど、
やっぱこう、居づらいじゃないの。

それがまたgdgdなプロジェクトでしてねー(笑)、
ま、色々あって、仕方ないと言えば、仕方ないと言えないこともないんですが。
結合テスト終わりましたねーってなところで、
動作条件の試験してないんですよって、をいをい。
メモリ 512MB のマシンで動作することってなっているのに、
512MB のマシンがなくて、テストしてないんですよねーって。
ですよねーじゃないってばさ。
自社内になかったら、レンタルしてやるでしょ、常考。
1年間の日ごとのレポートを作成するアプリなのだが、
365 日全部データが埋まった状態も、テストしてないって。
もうなんつーかgdgdすぎ。
そんなに忙しいプロジェクトじゃなさそうなんだが。
小霞さん入ってくれるなら、やってもらおうかなーだって。
良いでがすよ、やりますよ。

でまぁ「無料で 512MB のマシンぽい状態をエミュレートして試験をする」という
ミッションが与えられた。
プロジェクトのみなさんは、全然よい考えが浮かばなくて、
小霞さんよろしくーってな状態なので、
一人で勝手に考えて、勝手に実行しちゃうことにした。
特に問題なさそうだし(^^;;
貸してもらった試験用ノートパソコンは、
メモリ 768MB というもの(OS は WindowsXP)。

案1:RAMディスク作っちゃう→失敗


256MB + 512MB なのだから、
256MB を RAMディスクにしちゃえば、512MB のマシンになるんじゃね?という案。
ERAM(http://www.vector.co.jp/authors/VA000363/)というアプリを入れてみた
(結局採用しなかったので、インストール方法は書かないよ)。
256MB だから 256×1024=262144KB だよねーと設定してみたが、
再起動すると ERAM が無効になっちゃって、
RAMディスクができていない。
でも、20600KB(20MB) だとちゃんとRAMディスクができるので、
指定する数値が大きすぎるのかも。
どこまでなら設定できるのだ?
いや、設定できる上限値がわかっても、256MB が設定できなくては意味がない。
諦める。

ちなみに ERAM のアンインストールは、「プログラムの変更と削除」から。
♪杏仁どーふ、杏仁どーふ♪

案2:boot.iniを編集→成功


boot.ini を編集して、使用できる最大物理メモリ量を制限しちゃえという案。
boot.ini はエクスプローラでは表示されないので
(勿論、検索してもムダムダムダムダァァァァァ)、
どこにあるのか、場所を探してしまったりするけど、
見えなくても「c:\」にあります。
表示されないだけです。
システム側からすると、見せたくないほど大切なファイルなわけですね。

boot.ini を編集する方法はいくつかあるけれど、
とにかく大切なファイルなので、試す場合は自己責任でよろしく。
boot.ini のバックアップは必須ね。

コントロールパネル

システム

詳細設定タブ

起動と回復 設定ボタン

起動システム 編集ボタン

メモ帳が開くので、以下のように編集。
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /MAXMEM=512

太字の部分を追加。
こうすると、512MB しか働かなくなる。
再起動して、タスクマネージャで確認。
パフォーマンスの物理メモリの合計値が、
512MB ぽい数値になっているのが確認できたらおk。

あぁよかった。
これでテストに取り掛かれる。
[PR]
by xiaoxia | 2008-03-17 17:51 | コンピュータ関係 | Comments(2)

CPPUnit 導入のわけ


実は私は非常に大雑把で面倒くさがりな性格。
え? わかってた? そうだよなぁ(笑)
この大雑把で面倒くさがりな性格というのは、
プログラマに向いているような、向いていないような。

プログラマは面倒くさがりでなくてはいけない。
面倒くさいからこそ、楽チンにできる方法はないかなーと考えて、
それが発明の母となって、プログラムが生まれるわけ。

プログラマは面倒くさがりであってはいけない。
面倒くさがらずに、きっちりとドキュメントを揃え、
緻密なテストを行い、
慎重に慎重を重ねることで、
すべてを結合して動かした時に、意図した通りの動作をもたらすわけ。

サラリーマンプログラマの私には、
後者の性質の方を多く求められる。
なわけで、この性格は今の立場では「向いていない」と言われてしまう
(実際、先輩数人に言われたことがあるw)。
なんかさー、面倒くさいんだよねー。
特に単体テストってさー。
個々のパーツじゃ単独で動作しないから、
ドライバ作ったり、デバッガで止めたりしなきゃダメじゃん。
それでも一生懸命考えてやるけどさー、
超めんどーだよねー(笑)

そんな私にぴったりだったのが、テストツール CPPUnit。
プロジェクトとして導入が決まっていたわけじゃないのだが、
ちょっと前、お手伝いしたプロジェクトで CUnit でのテストをやって、
おやこれは便利、と思ったので、個人的に導入してみたのよ。
結果的にこれは正解だった。
結合試験で、単体試験レベルのバグが出て、
恥ずかしい思いをすることがあったのだが、
そんなことも発生しなかった。
一般的には、テストでバグが出ないのは、
テストが足りないということなので、必ずしも良いこととは言えない。
でも今回は、単体試験で、
社内の品質指標で定められている以上のテストケースを行ったので、
結合試験でバグが出なかったのは、
単体試験後にそれなりの品質が確保されていたと考えて
良いんじゃないかと。

ソース


んでは CPPUnit のソース。
参考にしたのはこのページ。
CppUnit Book [DRAFT]
// おまじない
#include <cppunit/extensions/HelperMacros.h>
#include <cppunit/ui/text/TestRunner.h>

// 必要なヘッダがあればこの辺に
#include <iostream>

// テスト対象のモジュールのヘッダ
#include "MyTest.h"

class MyTest : public CppUnit::TestFixture {
 CPPUNIT_TEST_SUITE( MyTest );

 //--- テスト関数を入れる【1】------------------
 // 正常系
 CPPUNIT_TEST( test_morphing );
 // 異常系(指定された例外が返る)
 CPPUNIT_TEST_EXCEPTION( test_morphing_e , MyClassException );
 //--- テスト関数を入れる【1】------------------

 CPPUNIT_TEST_SUITE_END();

public:
 MyTest() {}

 // 必須 ここから
 void setUp()
 {
  pMyobj* = new MyClass;
 }

 void tearDown()
 {
  delete pMyobj;
 }
 // 必須 ここまで

 //---テスト関数を入れる【2】-------------------
 void test_morphing()
 {
  // 正常系のテスト trueが返ること
  CPPUNIT_ASSERT( pMyobj->morph(1) );
 }

 void test_morphing_e()
 {
  // 異常系のテスト 例外が発生すること
  CPPUNIT_ASSERT( pMyobj->morph(0) );
 }
 //---テスト関数を入れる【2】-------------------

private:
 MyClass* pMyobj;
};


// ここより下は一度書いたら編集しなくてOK
int main() {
 CppUnit::TestSuite *suite = MyTest::suite();
 CppUnit::TextUi::TestRunner runner;
 runner.addTest(suite);
 bool retcode = runner.run();
 return !retcode;
}

MyClass の部分に、テストしたいクラスを入れる。
MyTest はこのテスト用のクラスなので、名前はお好みで。
test_*** という関数名もテキトウでおk。
【2】に関数を追加したら、【1】にも追加。
これを make して、実行ファイルを作ったら即実行、テスト終了。
いっぺんこのガワを作ってしまえば、
後はテストケースを【1】【2】に入れていくだけ。
んまぁ簡単!

導入のメリット


CPPUnit を使うメリットは、テストが簡単になるってことのほかにもある。

■ドライバ作りが楽、途中増員が楽
実は今回、初めての C++ 開発だったので
(おまけに C も 5 年前に書いたっきりさ!)、
スケジュールが大いに押してしまった。
そこで、誰かに単体試験のお手伝いをしてもらおう、という話になった。
単体試験というのは、プログラム中の全部の分岐を通す試験なので、
その関数1個だけでは動かすことができないというものは、
その関数を動かすもの(ドライバ)を作らなくてはいけないことが多い。
仕様の理解から、ドライバの作成からあって、
お手伝いの人が実際に試験可能になる立ち上がりまで、結構時間がかかる。
でも、CPPUnit は、それ自体がドライバみたいなものなので、
途中から入った人でも、立ち上がりがかなり楽になる。
ま、今回は結局私一人で終わらせたんだけど。

■ケース増加が楽
仕様検討不足の点があって、ギリギリになって仕様が追加されたが、
CPPUnit では、すべての関数のドライバができている状態なので、
正常系異常系上限下限なんかのケースを、ちょっと追加するだけで、
テストも簡単にできてしまった。

■試験が客観的
項目は作らなくても、試験の客観性が保証される。
ソース見れば、一目瞭然だから、
このテストケースが足りないね、というのが、すぐわかる。
そしてすぐ追加できる。

■テストドリブンぽい
テストドリブンもちょっと体験できた。
何しろ、初めての開発だもんで、
最初は全部の行にバグがあるような状態だった(笑)
だから一旦全部まっさらにして、
ちょっとずつソースを入れて、確認していく、というテスト方法を取った。
ちょびっとだけテストドリブンぽいでしょ。
時間はかかったけれど、結果的に品質は良くなったので、
手戻りがない分、良かったと思う。
結合試験でバグが出ると、試験全体が滞ってしまうからね。

■実行が楽
コマンド一発テスト終了!
何度もできるしね。
これは気持ち良いよー(笑)
[PR]
by xiaoxia | 2008-03-04 17:32 | プログラム言語 | Comments(0)

ダメ女プログラマ&主婦&腐女子&バイオリン弾き


by 小霞