-
____rina____
- 5002
- 2
- 1
- 10
-
- いいね！10
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@____rina____ 以前、ドリル本の勉強会をした時に気がついたのだけれど、CEGTestの回で悩んでいる人は、みんな、画面の左にたくさんの原因ノードを置いて「それらをどう繋ごう？」って苦労していました。 そうではなく、右端に１つだけ結果ノード（テストしたいもの）を置いてそれを左方向に分解して行くと良いです。
2018-01-12 06:29:24
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@____rina____ 例えば、 《以下の条件のパスワードを受け付ける》 ・8文字以上15文字以下 ・英数/記号 ただし、 ・英字は大文字/小文字混在すること ・数字を含むこと ・記号を含むこと ・過去3回のパスワードと同じものでないこと のテストをCEGTestで描いてみて。〉リナさん これができたら問題ないですよ。
2018-01-12 07:21:25
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@____rina____ それは、分解の段階を飛ばしているかもしれないです。 少しずつ左へ分解するイメージで。
2018-01-12 07:26:25
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@____rina____ @softest 練習問題なんだから間違えていいんです。 むしろ間違えてもらう（自分の弱点を知る）ための問題だから。
2018-01-17 13:41:49
Kazu SUZUKI
@kz_suzuki
@akiyama924 @____rina____ @softest あの～ わたしも赤ペンしていただけますか・・・？
2018-01-17 20:49:19
Kazu SUZUKI
@kz_suzuki
@akiyama924 @____rina____ @softest これってAND以外使うんですかね・・・？ なんだか完全に忘れている。。。
2018-01-17 20:51:57
Kazu SUZUKI
@kz_suzuki
@____rina____ @akiyama924 @softest これ以上複雑になるのかな・・・？ pic.twitter.com/UxGzQraTE1
2018-01-17 20:55:12
拡大
リナ？
@____rina____
@kz_suzuki @akiyama924 @softest 秋山さんの模範解答にはONE 制約をつかったノードがあったよ！とヒントを出してみる
2018-01-17 21:04:13
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@kz_suzuki @____rina____ @softest もう一つヒント。 【文字種OK】のところのデシジョンテーブルを見直してみて。
2018-01-17 22:04:56
Kazu SUZUKI
@kz_suzuki
@akiyama924 @____rina____ @softest 「英数/記号のみ」は、「英数と記号どちらでもいい」の意味ですよね？ 排他ではなくて・・。
2018-01-17 22:19:32
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@kz_suzuki @____rina____ @softest コントロールコードや半角カナや2バイト文字はパスワードに使えませんという意味です。
2018-01-17 22:21:59
Kazu SUZUKI
@kz_suzuki
@akiyama924 @____rina____ @softest 「文字種OK」を作る4つのノード間に関係があるんだろうなとは思うのですが、まだわかりません。。。お時間ください。。
2018-01-17 22:25:51
Kazu SUZUKI
@kz_suzuki
@akiyama924 @____rina____ @softest すみませんが、今日はここまでで。。使用ルールがNGになるには、入力した文字列が正しくなければならないので、REQを入れました。文字列のデシジョンテーブルがダメな点はまだわからないし、ONEもでてきてません。。。 やはりCEGに苦手意識。。。 pic.twitter.com/CspKEnAoLh
2018-01-17 22:59:06
拡大
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@kz_suzuki @____rina____ @softest 描いて頂いたものが間違いということではありません。これも正解です。 ただ、このままですと、例えば［大文字/小文字混在］という条件がそのままDTの原因の行に現れますので、テストケースを作るときに［大文字/小文字混在］について、どんなデータを作るか考える必要があるのでちょっと面倒です。
2018-01-18 04:09:49
Masaki Kase
@softest
@akiyama924 @kz_suzuki @____rina____ こんな感じで作ってみました。"パスワード判定（加瀬）"で保存。 pic.twitter.com/VC5mAIS3V3
2018-01-18 09:31:48
拡大
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@softest @kz_suzuki @____rina____ 正しそうだけど、このデシジョンテーブルを読んでテストケースを作る過程で間違いが起こりそうです。
2018-01-18 10:33:31
Keizo Tatsumi
@KeizoTatsumi
@softest @akiyama924 @kz_suzuki @____rina____ 中間ノードの「文字列条件」「例外条件」「過去パスワード条件」は因子、原因ノードは状態に対応付けることができそうです(因子→状態と原因→中間は方向が逆ですが)。まず、因子、状態を考え、それらの関係を検討しながら原因結果グラフを作成するとよいと思うのですが、そうでもないですか?
2018-01-18 10:45:02
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@softest @kz_suzuki @____rina____ 加瀬さんは開発者だから、「どうモデリングしたら1番シンプルな論理構造になるかな」の視点で描くのですね。 一方でテスターとしては、「どうモデリングしたら1番誤りが入りにくいか」を優先してしまいます。 状態遷移図の演習時にはいつも思うことだけど原因結果グラフでも同じなのですね。
2018-01-18 12:07:41
Kazu SUZUKI
@kz_suzuki
@akiyama924 @____rina____ @softest なるほど、そういうことですか！ 何となく仕様をそのままノードにしていましたが、分解必要ですね。加瀬さんの例のように、何回目のと重複しているかも分解すべきかなと感じていました。 一方で、「重複」から「文字列としての不正」へのreqは必須でしょうか？ 最初に思いつけなかった原因を考えてます
2018-01-18 12:12:23
あきやま🏃🏻♂️=͟͟͞͞
@akiyama924
@kz_suzuki @____rina____ @softest 制約についてですが、【ONE】以外の制約はDTを見てから付ける方が良いと考えています。 《理由》 1. EXCLはONEに書き換えることで全部がFの時の条件が明確になる 2. INCLは使う場面が無いし使ってもDTが小さくなることが滅多にない 3. REQとMASKはDTを小さくするが付け忘れても使いにくい表になるだけ
2018-01-18 12:24:31
Masaki Kase
@softest
@akiyama924 @kz_suzuki @____rina____ そうかもしれません。あとはグラフからテストケースを作成するのも自分なのでそこでの誤りはあまり気にしていないかもしれません。
2018-01-18 12:49:26