ﾃｽﾄﾁｰﾑによる結合機能ﾃｽﾄの実施 - @IT
@IT[=>]
@IT CORE[=>]
@IT情報ﾏﾈｼﾞﾒﾝﾄ[=>]
@IT MONOist[=>]
@IT自分戦略研究所[=>]
JOB@IT[=>]
ITmedia[=>]
TechTarget[=>]
誠[=>]
{img:ｱｯﾄﾏｰｸ･ｱｲﾃｨ ITｴｷｽﾊﾟｰﾄのための問題解決ﾒﾃﾞｨｱ}[=>]
@IT総合ﾄｯﾌﾟ[=>]
> @IT CORE[=>]
> Insider.NET[=>]
> BOOK Preview[=>]
> VS 2005によるWebｱﾌﾟﾘﾃｽﾄ技法[=>]
> 第5章 ﾃｽﾄﾁｰﾑによる結合機能ﾃｽﾄの実施[=>]
{img:ｽﾗｯｼｭﾄﾞｯﾄ}[=>]
{img:はてなﾌﾞｯｸﾏｰｸ}[=>]
{img:Yahoo!ﾌﾞｯｸﾏｰｸに登録}[=>]
{img:印刷}[=>]
BOOK Preview
Microsoft Visual Studio 2005による
Webｱﾌﾟﾘｹｰｼｮﾝﾃｽﾄ技法
第5章 ﾃｽﾄﾁｰﾑによる結合機能ﾃｽﾄの実施
ﾏｲｸﾛｿﾌﾄﾌﾟﾚｽの書籍紹介ﾍﾟｰｼﾞ[=>]
日経BPｿﾌﾄﾌﾟﾚｽの書籍紹介ﾍﾟｰｼﾞ[=>]
書籍情報(書籍目次)のﾍﾟｰｼﾞ[=>]
2007/04/23 Page1[=>]
Page2[=>]
Page3
5.2.2ﾃｽﾄ手順書作成に関するTips & Tricks さてこのﾃｽﾄ手順書は､ﾃｽﾄｹｰｽとしての網羅性などを意識しながら作成する必要がある｡なぜなら､場当たり的で散発的なﾃｽﾄ(ﾓﾝｷｰﾃｽﾄなど)では､製品の品質を定量的に正しく評価することができないからである｡ 基本的にﾃｽﾄ手順書は､個別業務要件定義書(業務仕様書)に基づいて作成していけばよいが､網羅的なﾃｽﾄｹｰｽを作成していくために､以下のようなﾎﾟｲﾝﾄに注意するとよい｡ ｴﾝﾄﾞﾕｰｻﾞｰがよくやってしまう｢ありがちな異常系ｼﾅﾘｵ｣を追加する｡ ｸﾞﾚｲﾎﾞｯｸｽﾃｽﾄの観点を入れてﾃｽﾄｹｰｽを追加する｡ よくある不具合やﾊﾞｸﾞ一覧表を活用する｡ ﾃｽﾄ手順書の作成方法を規定しない｡ これらについて以下に解説する｡ A.ありがちな異常系ｼﾅﾘｵの追加
通常､業務設計担当者は｢正常系にﾌｫｰｶｽしながら｣個別業務要件定義書を書いていくことが多い｡しかし実際のｴﾝﾄﾞﾕｰｻﾞｰは､｢ﾘｾｯﾄﾎﾞﾀﾝやｳｨﾝﾄﾞｳのｸﾛｰｽﾞﾎﾞﾀﾝを押してしまう｣､｢誤ってﾘﾀｰﾝｷｰやﾊﾞｯｸｽﾍﾟｰｽを入力してしまう｣､などのように､異常動作を引き起こすような操作を行うことが少なくない｡想像力を発揮し､｢ｴﾝﾄﾞﾕｰｻﾞｰがついやってしまいそうな｣異常系ｼﾅﾘｵをたくさん追加することが望ましい｡ B.ｸﾞﾚｲﾎﾞｯｸｽﾃｽﾄの考え方によるﾃｽﾄｹｰｽの追加
結合機能ﾃｽﾄはﾊﾞｲﾅﾘﾌｧｲﾙを対象としてﾃｽﾄを実施するもの(=ｿｰｽｺｰﾄﾞを見ないﾃｽﾄ)であるため､そのﾃｽﾄｹｰｽ設計も､基本的にﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄの考え方のみに基づいて行われる｡ しかし､ｼｽﾃﾑの主要ｺﾝﾎﾟｰﾈﾝﾄの動作や仕組みを理解した上で､特に弱点となりそうな部分について重点的にﾃｽﾄｹｰｽを追加することは極めて有効である｡このような､(ｿｰｽｺｰﾄﾞを直接見ることはないものの)ｱﾌﾟﾘｹｰｼｮﾝｱｰｷﾃｸﾁｬやｼｽﾃﾑｱｰｷﾃｸﾁｬを理解した上でﾃｽﾄｹｰｽを考えていく方式を､ｸﾞﾚｲﾎﾞｯｸｽﾃｽﾄの考え方と呼ぶ(図 5-6)｡ 図 5-6 ｸﾞﾚｲﾎﾞｯｸｽﾃｽﾄの考え方 具体的なﾃｽﾄｹｰｽの追加例を挙げよう*173｡ このｱﾌﾟﾘｹｰｼｮﾝでは､ﾃﾞｰﾀｱｸｾｽ部分にﾃｰﾌﾞﾙｱﾀﾞﾌﾟﾀを利用せず､自力でのADO.NETのｺｰﾃﾞｨﾝｸﾞを行っている｡
この場合､ﾊﾟﾗﾒﾀﾗｲｽﾞﾄﾞｸｴﾘの利用がずさんになっている可能性がある｡入力値として ' (ｱﾎﾟｽﾄﾛﾌｨ)を利用し､SQL挿入脆弱性を使った不正動作を誘発できないかを確認してみるのがよさそうである｡ このｱﾌﾟﾘｹｰｼｮﾝでは､ﾃﾞｰﾀの受け渡しに型付きﾃﾞｰﾀｾｯﾄを利用している｡
ﾃﾞｰﾀｾｯﾄを利用したｱﾌﾟﾘｹｰｼｮﾝでﾄﾗﾌﾞﾙを引き起こしやすいﾎﾟｲﾝﾄとしては､0件ﾃﾞｰﾀの取り扱い(中身が空のﾃﾞｰﾀｾｯﾄｲﾝｽﾀﾝｽを使うのかnullを使うのか)や､大量ﾃﾞｰﾀの取り扱い(ﾃﾞｰﾀｾｯﾄが巨大化するとﾌﾟﾛｾｽ間での引渡しに時間がかかる)などが挙げられる｡これらのﾄﾗﾌﾞﾙを誘発するような入力ﾊﾟﾗﾒｰﾀを考えてみる｡ このｱﾌﾟﾘｹｰｼｮﾝは､ﾕｰｻﾞｰから受け付けたｱｯﾌﾟﾛｰﾄﾞﾌｧｲﾙをﾃﾞｨｽｸに書き込ん
■Next Page
･Full Browser
ja.abc-yoga.podzone.org | Contact