汎用編集用メモリエリアとして、DOMもいいかも。。

　エディタをつくるとかいう場合・・

　それは、あるプログラム言語のエディタでも、
　テキストエディタでも、
　DTP用のエディタでも、

　なんでもいいんだけど、そー言う場合。

　内部的に持っているメモリエリアが必要で、
　それを連結リストなどで実現し、編集操作に応じて、そのメモリを操作するプログラムを書く。

---

でも、そのプログラム言語、テキスト、DTPで表現される内容が、
XMLで表現できるなら、それを読み込み、操作するDOMで表現
できるわけで。。

　ならば、DOMでメモリ上に表現してしまったほうが、
早い気がする。

　たとえ、外部出力フォーマットとしては、XMLにしないにしても。。

テストについて、簡単にまとめる

テストについて、簡単にまとめると、こんなかんじかしら
(独断と偏見なので、解釈違いもあるかも・・）

---

■テストのレベル
・単体テスト
・結合テスト
・システムテスト
・運用テスト

それぞれの内容は、
ここ　http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/?SS=imgview&FD=-192991770&ST=system

---

■テストの種類

ホワイトボックステスト＝ソースを見て行うテスト
　　　　命令網羅、分岐網羅、条件網羅
http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/?SS=imgview&FD=3561930&ST=system

ブラックボックステスト＝ソースを見ないで、入出力から行う
同値分割、境界値分割
http://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/?SS=imgview&FD=4485451&ST=system

※単体テストはソースを見て行うので、ホワイトボックステストが可能。
　（単体でも、JUnitで入出力だけチェックするような、ブラックボックステストも可能）
　それ以上は、必ずしもソースが来る保証がないので、ブラックボックスしかできない場合も多い。

---

■ホワイトボックステストの場合
・命令網羅、分岐網羅、条件網羅のどれで行くか？
・網羅率を考え、テストの縮退など・・

---

■ブラックボックステストの場合
同値、境界値＝入力する字種がきまった上での話。そこにいたるまで、いたった後にもテストあり。

●形式的なチェック
・文字種チェック・フォーマットチェック
数字（実数、負の数？）、文字（漢字？カナ？）
　　　　フォーマットチェック（数字３桁のあと、ハイフン、数字４桁など）

・桁数／文字数チェック
バッファオーバーフロー
未入力

・SQLインジェクション

●意味的なチェック
・文字／数値範囲チェック
同値、境界値

・項目間チェック
項目間に関連があるとき

・存在チェック


※形式的なチェックは正規表現などで出来る場合も多いが、意味的なチェックは値をとって吟味する必要がある。
　存在チェックは、クライアント側で(JAVASCRIPTで)は出来ず、サーバーアクセスが必要なことが多い。

---

あっさりまとめると、こんなかんじ・・