ブラウザからメールを送る方法

ちょっと、メモ

ブラウザで、フォームを表示して、入力内容をメールとして送りたい場合

ＦＯＲＭ文で、actionのところにmailto:アドレス名を書く
＜FORM name=mail_form action=mailto:メールアドレス method=post＞
なまえ＜INPUT size=30 name=name＞＜BR＞
メッセージ＜INPUT size=30 name=msg＞＜BR＞
　　　＜INPUT type=submit name=sub value=実行＞
＜/FORM＞
＜/form＞

＜＞は、ほんとうは、半角にする

うざいメッセージが出た後、おくれる。

Excelのファイルから、ＥＲ図やＲＤＢのテーブル構造を出す方法（試案）

　今、業務でExcelをつかっていて、それをシステム化したいといわれた場合、
　まあ、Excelのファイルを分析して、ＥＲ図なりを書いて、テーブルに落とし込むわけですが、帳票の場合とちがって、やりにくくないですか？
・表のなかの一部が、ぜんぜん違う意味につかっている
・どれが入力項目で、どれが出力項目なんだかよくわからない。
　→どちらも、計算式でなく、値が入っている。
・そもそも、複雑にリンクされていて、どれが入力項目だか、どれが出力項目だか、よくわからない。
なんてかんじで。。。

　そこで、（紙の帳票分析みたいに）ExcelのファイルからＥＲ図を割り出す方法について（まだ考えただけだけど。。。）

---

（１）ＥＲ図をとにかく構造にわける。
　シートにかかれている表の関係は
　　　　　　Excelファイル
　　　　　　　｜
　　　　　　シート
　　　　　　　｜
　　　　　　　表
　の関係にあり、この表のなかに、部分的に表があったりする。
　その外見的なまとまりを、図にしてしまい、項目をあげる
　このとき、ただの計算項目としてあがっている項目もあげておく。
　（そうしないと、あとでこまる）

（２）で、そうやってできた表、そして表の中に書かれた項目のまとまりを
　クラスと考える。
　　で、各項目に関して、計算式の場合、それはgetterとして、get項目名のメソッドを作成し、項目に、Ｘ印をつける。そして、getterの引数になっている項目（その項目が亜リンクしている項目）の値に、アンダーバーを付ける（べつにマーカーでいろをつけてもいいけど）：それが入力になる。


（３）この操作をくりかえすと、最終的に、入力値がわりだせる。そこで、その時点で、入力項目が存在しているクラスを、エンティティとみなし、ＥＲ図を作成する。同時に、これが、テーブルとなる。。

---

いまいちだなあ。。。入出力項目（一応計算で求めるけど、書き換え可能）も抽出できてないし。。。

Excelのコメントを取得する・設定するVBAマクロ

　Excelで、コメントってつけられますよね。
　セルをクリックして右ボタン、「コメントの挿入」で、つけられるやつです。
　つけると、セルの右肩に赤い三角印がつき、そこのセルをクリックすると、コメントが見えます。

　で、そのコメントの設定方法について、VBAのサイトなんかをみると、かいてありますよね。
たいてい書いてあるのは、こんなかんじ

    Range("A1").AddComment
    Range("A1").Comment.Text Text:="コメント１：コメントです"

ただ、このやりかただと、コメントがすでについていると、エラーになります。
それと、今、書いてある、コメントを取得するには、どうするの？？

---

　で、NoteText()を使うと便利かも！

　以下のような形で、コメントの値が取得できます（メッセージボックスにコメントを表示します）。
　

Private Sub Worksheet_SelectionChange(ByVal Target As Range)
    Dim com As String
    com = Target.NoteText()
    If (com <> "") Then
        MsgBox com
    End If
End Sub

逆に、コメントを設定するには、

　Target.NoteText("設定したいコメントを引数に！")

でＯＫです。

上司の頭の中にあるテスト方法の考え方３ 想定の範囲外のテストは、どうするのか？

　前のブログで、境界値をチェックして、単体テストが終わった！というと、怒られるケースがあるという話をかきました。具体的にどういうケースかというと、まえ、どこかのブログかなんかであったと思うけど、

　チルダを含むＵＲＬを入力すると、おかしくなるというケース。

　これのユーザーからのクレームに「単体テストはしてるのか！」とか、あったと思います。
　してると思います。というか、先ほどの考え方だと、チルダを含むＵＲＬというのは、単体テストで、はじけません。というか、永遠にはじけません。
　理由は、先ほどの同値（や限界値）という考え方では、想定の範囲内のテストはできるのですが、想定の範囲外のテストは、ひっかかってこないです。

---

　チルダのＵＲＬの例だと、多分、そこの入力項目の指定は、

　英数字、記号で、１０００文字以下などという、字種と、文字長の指定となると思います。
　したがって、同値、限界値について考えると、１０００文字なら

文字長にかんして、９９９文字（有効）、１０００文字（有効）、１００１文字（無効）
字種にかんして、英字（有効）、数字（有効）、記号（有効）、スペース（無効？有効？）、漢字（無効）、機能文字（改行など、無効）
となると思います。で、この組み合わせで、適当にチェックするということになる。

　このとき、記号のなかに、チルダだけ、違った動きをするので、同値でないということには気がつきません。気がつく情報がありません。

　チルダのところで、おかしくなりそうな理由は２つあります。
　昨日、特命リサーチ２００Ｘで、スリップとミステイクというのをやっていましたが、
それでいうと、

（１）スリップ：ＵＲＬエンコードの部分で、チルダだけ、変換する対象から書き忘れていた。
（２）ミステイク：そもそも、ＵＲＬエンコーディングするさいに、チルダもエンコーディング対象になることを知らなかった。

　前者の場合は、テストで、気づく可能性がありますが、後者のばあい、みんな知らなかったら、仕様書にもかかれないし、だれもテストしません。だけど、実際にリリースすると、たいへんなことになります。

---

　同じような、単体テストで怒られそうなネタでバッファオーバーフローがあります。

　文字数に関して、９９９文字、１０００文字、１００１文字に関しての情報はありますが、１０２５文字について、なにか特定のことが書いてあるわけでもありません。でも、もし、この領域を

　char komoku[1024];

としていたら、１０２５文字で、バッファオーバーフローします。
なんで、これも、「単体テストやってんのか！？」って、怒られるでしょう。

---

　Javaで、NULLについて、なにも仕様書に書いておかないで、NULLをテストのときに入れて、「ほら、ＮＵＬＬでおちるじゃないか、この会社、単体テストもやってねー」と、ののしるプログラマやＳＥも同じです。

　ただ、この場合、「じゃあ、ＮＵＬＬが入ってきたら、どのように処理するべきなんでしょう？」

　ふつう、このケース、ののしってるやつだけが知らなくて、ほかのみんなは、このケースではＮＵＬＬをいれれば落ちることは、しっていて、でも、勝手に処理すると怒られるから、仕様書どおりに作っているケースがおおい気がします。
　これは、そう作らないと、結合テストのときに、こまるからです。

　なぜ、結合で、こまるかについては、機会があったら書きますけど。。。

---

　じゃあ、これを防ぐには、どうしたらいいか。。。なんですけど、

　仕様書に書かれている、想定の範囲内チェックと、かかれていない、想定の範囲外チェックに分けるというのが、無難かと思います。

　想定の範囲内チェックは、従来の限界値チェックです。
　で、想定の範囲外チェックは、ある字種、ケースに対しては、ここで、エラーがおきやすいからそれも確認しておくという形でしょう。

たとえば、

・漢字の場合「表」を含む文字
（なんかの漢字コードで、表のうしろが、\マークとおなじコードになり、そこで、コンパイラによっては、漢字の表と理解しないで、エスケープかきたと判断して文字化けすることがある）
・英数字の場合の、ＵＲＬエンコードで変換される文字のかずかず
・文字数の場合、２５７、１０２５（バッファオーバーフロー対策）
・ＳＱＬ文（ＳＱＬインジェクション対策）
・数字の場合の４万、７万（チェック前に変換エラーになり、想定外の動きになることも）

とかは、（その値が入力可能なら）どんなときでも、チェック項目として、あらかじめ入れておいて、「想定の範囲内チェック」（境界値など）がおわったら、適当に（適切に！）、チェックするなんていう感じしかないかも。。。

---

　ただ、じゃあ、想定の範囲外で、どういうのがおこりやすいか？という情報交換はほどんどされてないしというか、できないよね。

　そもそも、こんなテストを上司がみとめるかどうか、わかんない
　なんの意味があるのといわれかねない。

　なぜなら、上司の時代は、想定の範囲外の値がはいってこないから
（汎用機は、画面側でチェックする。また、汎用機が想定外の動きをすることは、ほとんどない）

　ということで、想定の範囲外テストというのは、こっそりやる形になるかも。。。

　ちなみに、前のブログでかいた、「ホリエモンの名言」とは、もちろん「想定の範囲内」ということばを指してます。

上司の頭の中にあるテスト方法の考え方２ 上司の言ったとおりやると、怒られるかも？

　昨日、ホワイトボックステストについて書いたので、今日は、ブラックボックステストの話。
　ブラックボックステストは、単体だけでなく、結合テストでもありえるけど、基本的にブラックボックステストのやりかたは（はんいがちがうだけで）同じように考える。

　この方法に関しては、IPAのCAIT(中央情報教育研究所）が出した、プロダクションエンジニアテキスト（上）の５３１ページから５４２ページにそってまとめてある。

　ブラックボックステストにおいては、機能の入出力を操作して、その機能の妥当性を調べる。
　機能の入出力の最小単位は、データ項目になる。
　ここで、データ項目とは、
　　　画面の場合、入出力の項目１つ１つ
　　　ファイル、DBの場合、テーブルのフィールド（項目）
　　　メソッド、関数においては、引数と（出力項目のみだが）返り値
　　　通信の場合、電文のフィールド
　なんていうかんじになる。

　これらの項目１つ１つに対して、同値分析、あるいは境界値分析をかける。
　同値分析の場合、入力データを同値といわれる、おなじ特性をもった部分集合にわけ、その同値１つにたいして、１ケースを用意する。
　このとき、同値は２種類の同値に分けられる。
　有効同値と、無効同値である。
　有効同値は、正常入力の範囲、無効同値は、それ以外となる
　（ではない。と書いている人もいます。でも、そうやって教わるとおもうし、上述のテキストにも荘書いてある（５３４ページ下から２行目））

　同値は、同じ特性をもったもの、ということは、何種類にもわかれます。
　そのうち、仕様を満たすものが有効で、仕様を満たさないものが無効なので、有効同値にも何種類も、無効同値にも何種類もできます。
　そのうち、どこまでやるかが、テストのコストとの兼ね合いになります。

　同値の考えを発展させて、境界条件でもテストケースを作るのが、限界値分析です。

---

　で、個々の値のテスト範囲を決めたら、今度は、その値の組み合わせについて考えます。
　ここで、機能に着目して、テストケースを減らすのが、機能分割、あと、原因と結果に着目してへらす原因・結果グラフ技法などなどがあります。

　このへんのテストの減らし方は、いろいろあるみたいです。

---

　っていうかんじで、上司の時代はおそわっていたし、教わるときも（テストケースの減らし方はいろいろ違うにしろ）、たいてい、境界値とか教わってくると思います。
　で、そのとおりに単体のブラックボックステストをやると、「単体テストが終わってない」と怒られる可能性があります。。。
　いったとおりにやったのに。。。。

　この理由、実は、ホリエモンが、名言を残している。

　でも、今時間がないので、続きは、次の記事で