|
Twilog ホーム
» @akiyama924
» 2011年02月10日
いま稲穂を探してウロウロ。 posted at 19:02:34 『組込みソフトウェア開発技術』の「第8章 組込みソフトウェアのテスト技術」は片山先生が執筆されています!! posted at 18:52:46 @Tachi_4423 はい。私にとって神本の一つですからねー。たぶん特集号に掲載されていたやつで読んだことのあるものと思いますがうれしいです。早速買いました! posted at 12:42:29 ぎゃー!!!!!『グイン・サーガ外伝』の新刊がででる!!! posted at 12:06:51 僭越ながら塾長の反応を予想してみました――「ありがとう、でも、それ欲しいのとちょっと違う」 RT @koyaman2: 塾長ォーッ!愛してます!押忍ッ! RT @tulune: 愛なの。ちょっとした愛がね、欲しいのよ(謎 posted at 11:50:49 この寒いホームで12分も待つのかー。乗り換え電車の連絡悪すぎ! さむいよー。 posted at 11:19:19 ソフトウェア設計から考慮するのは大変だけれど、(モデルチェッキングを使わずに)状態遷移図でテストできる程度の状態遷移テストよりは、トータル工数を抑え、品質も向上するように思います。 posted at 11:01:47 だからこの方法が使えるのは簡単な機能の場合か、もしくは、初めから状態変数を意識してソフトウェア設計を行うかのどちらかです。 posted at 10:54:03 状態を状態変数として切り出せさえすれば、それは入力と同じように扱えますのでCEG、CFD、HAYST法が使えます。ただ、ここで一つの問題が生じます。それは出来上がったソフトウェアからリバースして状態変数を見つけることは簡単ではないという点です。 posted at 10:48:50 そのやり方は、「状態」の実体である「状態変数」を関数から分離するというものです。ラルフチャートで状態変数が処理を示す四角の外に(下に)分離していることを思い出してください。あれは、HAYST法で状態遷移まで扱うためなのです。 posted at 10:41:19 さて、「一般的に」と書いたのはそうでない方法も考えられるからです。つまり「入力→関数→出力」という形式で状態遷移を取り扱う方法があります。これができればCEGやCFDで状態遷移テストを設計できるので便利ですよね。HAYST法でも扱えるようになります。 posted at 10:35:22 一般的に、状態のテストでデシジョンテーブルを使わない理由は入出力の関数で表せないからです。だから状態とイベントのマトリックスを書いて総当たりのテストをしているのです。 posted at 10:29:23 ストップウォッチの動いているかいないかの情報のことを一般化していうと「状態」といいます。 posted at 10:26:02 例えば、ストップウォッチ。同じスタートボタンでも針が止まっているときと、動いているときでは、挙動や出力が異なります。何故かというと、関数が入力だけを使うのでなく、動いているかいないかの情報も使うからです。 posted at 10:23:36 ところが、機能のなかには「入力→関数→出力」では扱えないものがあります。同じ入力のセットを与えても違う結果が出力されるのです。と言われるとそんなのあるかなぁと思われる人もいらっしゃるかもしれません。 posted at 10:17:48 ブラックボックステストの一つの見方は、機能を「入力→関数→出力」というように関数として扱うものです。原因結果グラフはこの関数をブール関数(ブールグラフ)に置き換えたものということになります。 posted at 10:13:29 「もし君が一生分のお金を手に入れたら何をする?」 by 鈴木 みそ http://amzn.to/hcEQS9 posted at 05:50:22
|
last update 05/28 17:14
ツイート検索
Recent
Archives
Friends
Hashtags
Stats・Feed |