CEGTest脳が必要な気がする

Masaki Kase @softest

@KeizoTatsumi @akiyama924 @kz_suzuki @____rina____ 〇〇条件というノード名を使うのは僕の癖かも知れません。本当は「〇〇条件を満たす」ですね。というのもノード名は命題であるべきなので。

あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@softest @kz_suzuki @____rina____ ええ。ですから、利用のコンテキスト下でベターやワースの答えはあっても、絶対的な正解はありませんね。

Masaki Kase @softest

@akiyama924 @kz_suzuki @____rina____ なお、実際のプログラムを作成する際には、 1. 文字列の長さチェック、ダメなら NG 2. 文字種別チェック、ダメなら NG 3. N回前のパスワード文字列（のハッシュ値）とハッシュ値比較、ダメなら NG 4. 3 を繰り返す、ダメなら NG 5. それ以外に何か必要であればチェック、ダメなら NG 6. OK です。

Kazu SUZUKI @kz_suzuki

@____rina____ @akiyama924 @softest @KeizoTatsumi 僕も自分の思考過程のふりかえりのためにブログりたいのですが、リナっしーとかぶらないようにするので早く公開してくれｗ

リナ？ @____rina____

@kz_suzuki @akiyama924 @softest @KeizoTatsumi 今書きよるけん待って！！！

Kazu SUZUKI @kz_suzuki

@____rina____ @akiyama924 @softest @KeizoTatsumi じゃ僕も今夜中に書くかっていうか23時。。。

リナ？ @____rina____

@kz_suzuki @akiyama924 @softest @KeizoTatsumi 下書きにおいとけばいいよ！ いや、てか、いいよ。書いて。私TogetterのリンクとCEGTestの紹介と自分の解答とあきやまさんの解答紹介するよ　だから被ることはないのかも？

リナ？ @____rina____

はてなブログに投稿しました #はてなブログ CEGTest脳になろう！あらためてCEGTestを使ってみる - テストする人。 underscore42rina.hatenablog.com/entry/2018/01/…

リナ？ @____rina____

@kz_suzuki @akiyama924 @softest @KeizoTatsumi 書いたー(((o(*ﾟ▽ﾟ*)o))) underscore42rina.hatenablog.com/entry/2018/01/…

Kazu SUZUKI @kz_suzuki

@____rina____ @akiyama924 @softest @KeizoTatsumi 明日読む！

Kazu SUZUKI @kz_suzuki

@softest @akiyama924 @____rina____ 加瀬さんの決定表に、「文字列としてはNGなのに、過去のパスワードと一致する」が出てこないのはなぜなんでしょう？ 僕はそれでをREQで排除したのですが、それを使わなくても出てこないのは・・・？ CEGの決定表導出の内容を忘れてしまったので、自分が昔考えて書いた記事とか読みます。。。

Masaki Kase @softest

@kz_suzuki @akiyama924 @____rina____ "文字列として NG" と "過去のパスワードと一致" はいずれもパスワードを受け付けないテスト条件だと思います。それを僕は "例外条件" という中間ノードで兄弟にしてるので、CEGTest の実装上は出てこないですね。

あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@____rina____ @kz_suzuki @softest @KeizoTatsumi ありがとうございます。 私の解答例、CEGとDTが無いのでツイートしておきます。 pic.twitter.com/kANJA4Q2SC

拡大

拡大

Masaki Kase @softest

@____rina____ クラウドに秋山さんの模範解答を保存しておきました

Kazu SUZUKI @kz_suzuki

@softest @akiyama924 @____rina____ OR条件でノードが接続されている場合、全ノードがfalseであるケースと、1つのノードだけがtrueになるケースが出ると思うのですが、他の論理式の真偽パターンを組み合わせる際に、複数ノードがtrueになるものが「たまたま」出ることはないんでしょうか？ 偶然ではなく必然的に出ていないんでしょうか？

Masaki Kase @softest

@kz_suzuki @akiyama924 @____rina____ 前半部分は、その通りです。後半部分については、たまたま出ることはあります（敗者復活）。ただ、この論理構造くらいシンプルな場合は出てこないと思います。

Kazu SUZUKI @kz_suzuki

@akiyama924 @softest @____rina____ はい、仕様変更のケースも考えてはいるのですが、仕様変更ない前提で、cegの仕組みを確認したいと思ってます。

あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@kz_suzuki @softest @____rina____ パスワードのルールは変わることがあるから、以前のパスワードと同じでも受け付けない文字列になることがあります。

Kazu SUZUKI @kz_suzuki

@softest @akiyama924 @____rina____ わかりました！ 一応理解は合っていたようです。敗者復活を許したくなけれはreqで排除ですね。

Masaki Kase @softest

@akiyama924 @kz_suzuki @____rina____ 「パスワード文字列規則が変わることと、過去のパスワードを許さない仕様の関係が崩れるかも」という気づきが原因結果グラフを作る一つの目的でもありますね。

Kazu SUZUKI @kz_suzuki

@softest @akiyama924 @____rina____ まさに同じルートを通りました。秋山さんの書かれた通り、3回前では許容していたパスワードが今は使えない場合、パスワード文字列として不適切かつ三回前と一致する、ありうるなと思いました。なのでreqは不適切か。

あきやま🏃🏻‍♂️=͟͟͞͞ @akiyama924

@kz_suzuki @softest @____rina____ この仕様でもREQをつけた方が良い実装のこともあります。 ただし、REQやMASKを正しくつけるためには実装の情報が必要となりますので注意がいります。