Google のマーケティング活動について

この文、読んで意味分かる？

Google のマーケティング活動について
http://googlejapan.blogspot.com/2009/02/google.html

（以下斜体は上記サイトより引用）

Google Japan では、製品を多くのユーザーに知ってもらうために、さまざまなプロモーション活動を実施しています。
今回、そのプロモーション活動の一部でブログを活用したことが、Google のサーチに関するガイドラインに違反することが判明し、このプロモーションに関しては中止しました。ご迷惑をかけた関係者各位とユーザーの皆さまにお詫びするとともに、再発防止に向けて、透明性の高いコミュニケーションに努めてまいります。


問題は、
グーグル日本法人「急上昇ワード」の汚い宣伝手法で自滅
http://slashdot.jp/it/09/02/11/1149213.shtml
にかかれているように（以下の枠内は、上記サイトのまとめ）

・Googleは「急上昇ワード」を宣伝したい！！ 　　　↓ ・そっか！宣伝のために、ブロガーにお金を払って口コミ記事を書かせよう！！ 　　　↓ ・でも、これって、googleガイドラインの 　　サイトの順位や PageRank を上げることを目的としたリンク プログラムに参加しない。 　　に違反してない？

ってことらしい。

flogっていうのかしら、「PayPerPost」っていうのかしら・・・

に関しては、日本でも、ちょっと前に話題になったけど・・・

まあ、人の金儲けに関しては、法律の範囲内であれば、とやかく言う立場にはない。
しかし、上記のGoogleの文章は、はたして、

透明性の高いコミュニケーション


なの？この文だけ読んだ人に、こーいうことになっているって言うのは、多分想像できなくて、ひとつも透明性でないような気が・・

　これ、全部をちゃんと書けば（急上昇ワードに関して、「PayPerPost」したと）、いいのに、こうやって、隠そうとするような文章を書いちゃったから、逆に燃料投下しちゃってると思う。

・・・これなら、書かなかったほうがよかった気も・・・

.NETで、au,iPhone,Androidが動く・・・残るはドコモとソフトバンク？

ここの記事
OSS実装「Mono」で広がる.NETの応用
iPhoneでC#アプリが審査に通るワケ
http://www.atmarkit.co.jp/news/200901/29/mono.html

Monoを使って、C#で開発しても、iphone上で動かせるらしい。

そしてこの記事では（以下斜体は上記サイトより引用）

さらに、すでに述べたようにMonoはiPhoneやXBox360でも動くほか、Androidで稼働したという報告もある。AndroidのMono上では、PythonやRubyの処理系（それぞれIronPython、IronRuby）まで動いているようだ。

とのことで、.NetでandroidもＯＫらしい。

以前、auは、
Visual Studio 2008で開発
au端末上で.NETアプリ実行、KDDIがランタイム提供へ
http://www.atmarkit.co.jp/news/200901/21/au.html
ということで、.net by auというのを出すといっている。
これなら、.netが動くのであろう・・

後、残るは、docomo,softbank

テスト項目と、テスト内容の体系的抽出法 その１

デグレードを防ぐための、リグレッションテスト（回帰テスト）を自動化するツールとして、
Seleniumというのがあるらしい。

Selenium AES入門
http://codezine.jp/article/detail/3084

そして、このSeleniumテストデータ自動生成法として

Excelマクロによる、seleniumテストケースの自動生成（1）
http://codezine.jp/article/detail/2345

というのが載っている。しかし、テスト項目とテスト内容（上記の記事では、「コマンド」に相当？）の選び方に、体系的な手法が載っていないように思える。

　そこで、一般的なテスト項目と、テスト内容の体系的抽出法を書いてみたいと思う（Seleniumについては知らないので、Seleniumのタイプとあっているかどうかは？？）

---

■一般的にテストは・・・

　テストは、正常系、異常系、例外と３種類に分かれると思います（単体、結合、総合、運用などのテスト分類とは別に。なので、（単体、結合、総合・運用）Ｘ（正常系、異常系、例外）の組み合わせとなる）。

　ここで、正常系、異常系、例外を以下のように分けます（分け方はいろいろあると思うけど）

正常系・・・正常なケースとして、処理するもの
異常系・・・データが正常なものでなく、エラーとして、本来はじくべきもので、
　　　　　　仕様書にチェック方法などの記載のあるモノ（つまり、想定の範囲内のもの）
例外・・・・想定の範囲外のエラー

正常系と異常系をあわせて正常系にして、例外を異常系にしたり、
異常系と例外をあわせて異常系とするケースもあるかもしれない。
また、それぞれの定義が違うかもしれない。
が、とにかくここでは、上記のようにこの３つをわける。

---

■正常系、異常系、例外のテスト方法

　これらは、テスト方法が異なる。

・正常系：何か処理をおこなうので、仕様書に処理結果が書かれているはずである。
　そこで、入力項目に対して、同値分析、限界値分析などを行い、それぞれのケースに対して、入力値と出力値が妥当であるかチェックする。

・異常系：各入力項目に対し、項目の型からテスト内容を決定する＊。
　　　　　本来、エラーチェックしているはずである。
　　　　　＊に関して、「異常系のテスト内容」で後述する

・例外：想定の範囲外のものを想定してテストするのは不可能である（＾＾；）
　　　　そこで、かりに想定の範囲外の状況が起きた時どうなるか？というのを
　　　　確認する。

　　　　具体的には、呼び出し先のモジュールにおいて、例外を、たとえば

　　　　SQLException e = new SQLException();

　　　　のように発行し、例外が起きたらどうなるかを確認する。
　　　　（ＤＡＯからSQLExceptionを生成し、呼び出し先でどうなるか確認する）

　　　　なお、呼び出し先がないとき、自分の中でexceptionを書いて確認しようとする場合、
　　　　自分がThrowsしてなくても、RuntimeExceptionは、いつでもどこでも書けるので、
　　　　こいつを使ってとめることもある
　　　　（なんかへん・・・というとき、RuntimeExceptionをかき、stucktraceを出して確認する
　　　　　なんていう使い方もある）

---

■異常系のテスト内容

　ということで、正常系テスト、例外のテストは具体的に書いたが、異常系のテスト項目については書いていない。
　これは、実質、エラーチェック方法と同じになる。
　ＴＡＣのＩＴパスポート試験対策テキスト、６８ページには、試験用のエラーチェック一覧が載っているが、実際の開発では、これでは使いにくい。以下のように考える（なお、試験では、目視チェックというのがあるが、ふつうはマシンチェックのみ扱う）

・字種チェック
　全角かなのところに漢字が入っていないかとか、数字項目に文字が入っていないか（＝ニューメリックチェック）などを行う。
　１項目に１つのの字種しかは要らないこともあるが、郵便番号123-3210のように、複数の字種から成り立つこともある。この場合、フォーマットチェックとなる。
　字種チェック（とくにフォーマットチェック）においては、正規表現でチェックするのが、有効である

・範囲チェック
　字種チェックが終わったら、項目の範囲（があれば）をチェックする。
　この場合、数字が、いくつ以下のようなリミットチェックや、いくつからいくつといった、範囲チェックの場合もある（整数(short)の場合＝６万いくつか以下のように、暗黙のうちに範囲が決まる時、注意）。
　範囲チェックの１つとして、コードチェックがある。ＳＪＩＳコード体系内か？といった話。
　このコードチェックで、とくに、第３水準か？ＳＪＩＳ固有か？というのを簡単にまとめてチェックできる反則ワザ
　ＳＪＩＳをＵＴＦ－８にへんかん。その変換したＵＴＦ－８をもう一度ＳＪＩＳ変換。
　もし、はじめのＳＪＩＳと変換後のＳＪＩＳが同じならＯＫ．違えば、コード範囲外。

・論理チェック
　項目間で、ありえない項目とのチェック（後払いなのに、購入前に支払っている（＝実際には、銀行振り込みの場合、ありえる・・・今回はない例に挙げるけど）など）、チェックデジットなんかも、この一種。
　ただし、論理チェックはクライアント側だけでなく、サーバー間でもやることがあるが、
　今回、そのサーバーでの論理チェックは照合チェックにふくめる。

------------ここまで、クライアントでのチェック-----------
------------ここから、サーバーでのチェック---------------

・照合・論理チェック
　ＤＢ項目と入力項目間で、ありえない項目のチェック

　たとえば、ＩＤが重複している（重複チェック）や、データがちゃんと並んでいない（シーケンスチェック）ＤＢ項目と入力項目間で、データの矛盾がある（受注先の会社が取引先マスタにない）などのチェックを行う。

---

　長くなったので、ここまで。
　次回は、実際に画面から項目を出して、テスト内容を決定するまで。