詳解 コピー＆ペースト＆モディファイ法

※推奨してません

「コピー＆ペースト＆モディファイ法」は2012年現在、日本国内において最も普及しているテスト開発手法である。手法の名前で全てのアクティビティを表してしまっている、あるいは、バカバカしすぎて解説する気にもなれない、等の理由から、その普及度合いに反してなかなか陽の目をみなかったこの手法について、"せっかくだから" この場を借りて正面から取り組んでみたい。

「コピー＆ペースト＆モディファイ法」はテスト開発手法であるから、当然テストプロセスのいずれかのフェーズを担うことになるのだが、この手法の最も画期的な点は、テストベースからテスト設計を無配慮にすっとばし、機械的にテスト実装できるところにある。その意味においては、「考えていない」というささいな点以外は近未来テスト技術の寵児たるモデルベースドテストと思想を同じくする。では、その実際の様子を順を追って解説していこう。

1.テストベースを準備する 

テスト開発における設計工程はテストベースを準備するところから。これはこの天衣無縫なテスト手法においても変わりはないが、他のテスト設計技法においては無上の入力となる図表やテーブルが、本手法においてはゴミ同然であることに注意されたい。我々が求めているのは母国語でベタ書きされた仕様書である。もしそれが構造化されておらず、ただひたすら「〜しなければならない」調であるなら言うことなしである。そういう意味では、原則テキストベースで提供されるRFC文書等は要求強度が明示されている点からも非常に有力なテストベースとなる。実際筆者もやったが10年前なので時効であろう。たぶん時効である。時効なんじゃないかな。ま、ちっとは後略。

2.テストベースから要求っぽいところをみつけてコピーする

賢明な読者ならとうにお気づきのことと思うが「コピー＆ペースト＆モディファイ法」の第一ステップは、「コピー」である。ここで肝要なのはその操作ではなく、テストベースとなる文書から「要求っぽいところ」を見つける点にある。この手法のクオリティを保つためにも、ぜひ「っぽい」にこだわって欲しい。決して、開発チームに「これって要求ですかね？だとしたらどういう条件で発火してどういう振る舞いを…」などと確認してはいけない。ここでも、本手法のポリシーたる「考えていない」を遵守するためのテクニックが存在する。すなわち、「生成する」「変更する」「削除する」「xxしないこと」「xxすること」など、「ソフトウェアのふるいまい」+「サ変活用」に注目しながら仕様書を追っていき、発見次第無心でコピーしていく。考えるな、捉えるんだ。

3.テスト仕様書にペーストする

賢明な読者ならとうにお気づきのことと思うが「コピー＆ペースト＆モディファイ法」の第二ステップは、「ペースト」である。本ステップにおいても肝要なのは操作ではなく、ペースト先である。本手法を適切に運用した結果生まれる出力は「最高にいけてないテスト仕様書」であるから、テスト仕様書そのものにペーストすることが望ましい。この時、決して機能の構造に対応させたテスト仕様書の構造化などを考えてはならない。断じて、機能の親子関係やそこに与えられるパラメータの種別、などをスプレッドシートに、大、中、小項目と振り分けていく過程で網羅性に不安をもちはじめた挙句、「もう少し列挙した項目に合理的な理由をつける方法を考えよう」などと思ってはいけない。繰り返すが、本手法を駆使して我々が目指すのは「最高にいけてないテスト仕様書」である。

4.語尾を書き換える

賢明な読者ならそろそろこの枕にも辟易していることと思うが「コピー＆ペースト＆モディファイ法」の最後のステップは「書き換え」=「モディファイ」である。ステップ2を適切に行えていればここでも「考える」ことなく機械的な作業に徹することが可能となる。具体例を見てみよう。

コピー＆ペーストされた仕様記述の例:

　1.入力された年齢が18歳未満の場合は入場不可のメッセージを表示したあとYahooに遷移する

　2.プルダウンメニューからジャンルを選択すると、そのジャンルのタグがついた作品のみを表示する

　3.新着、高評価、視聴履歴で並べ替えができる 

モディファイしたテストケースの例:

　1.入力された年齢が18歳未満の場合は入場不可のメッセージを表示したあとYahooに遷移することを確認する

　2.プルダウンメニューからジャンルを選択すると、そのジャンルのタグがついた作品のみを表示することを確認する

　3.新着、高評価、視聴履歴で並べ替えができることを確認する

いかがであろうか。筆者がこの間違い探しのようなテスト仕様を開発するのに掛かった時間は約4秒である。驚異的な速さではなかろうか。入力する年齢も、そもそも受け付けている文字種すらも、メッセージの文言も、Yahooがどこなのかも、ジャンルには何があるのかも、並べ替えはジャンルと併存できるのかも一切問わない、実行するテストオペレータの腕に100％依存する、ある意味人間賛歌なテスト仕様であるとも言えよう。だったら仕様記述だけで良くないですか、などと考えたそこの君は、まだ信心が足りないようだ。

以上が、国内の底辺ソフトウェア企業を中心に最も普及している「コピー＆ペースト＆モディファイ法」の全貌である。紙面の関係上、まったく省略することなくつまびらかにしたつもりではあるが、この座興の粋を尽くしたテスト手法のいけてなさの一端でも感じて頂ければ、これに勝る幸せはない。

…え。これでもけっこうバグが見つかる？それはたぶん、作り方の方を先に考えなおしたほうがよい。

あとで見る的にURLとタイトルを自分にDMするブックマークレット

戯れに書いたのが案外ものすごく使ってるのでしぇあ。

javascript:location='http://twitter.com/home?status='+encodeURIComponent('d ★ココを自分のIDにする★ '+document.title+' '+location.href);

任意の名前のブックマークのURLを上記に書き換えてください。★をIDにするのをお忘れなく。

ところで

見ての通り window オブジェクトにぶら下がっている encodeURIComponent() はメジャーブラウザ全てで利用できるようです。この window オブジェクトはずっとブラウザベンダの好き放題の拡張がされてきたのですが、HTML5 でようやく規定されました。HTML5 で一番嬉しい仕様のひとつ。良かったね！ navigator とか location オブジェクト！

http://www.w3.org/TR/html5/browsers.html#the-window-object

ちなみに HTML5 では window オブジェクトは browsing context という実装上の概念から WindowProxy 経由でアクセスすることになっています。これは、iframe の中 や open された window から見てどの window が親なのか、はたまた先祖なのか仕様を整理するためにあるようです。history オブジェクトも session history という概念でここに定義されていますが、実体は window.history で返せとあるので特に戸惑うことなく利用できるでしょう。

と、ここまで書きながら仕様を眺めてて、locaion オブジェクトに href が無い！と焦ったのですが implements URLUtils; の先にありました。ふう。

Rubyのメモ

「初めてのRuby」でいろいろ新鮮だったのでメモ。なお、本書は「(他言語をやってるヒト向けの)Ruby入門書」であり、決してプログラミング初心者向けではないことに注意。プログラミング自体はじめての方は「作りながら学ぶ Ruby入門」とかオススメっぽいです。

初めてのRuby

作りながら学ぶ Ruby入門

1 がオブジェクト

Rubyの洗礼というかなんというか。「何でもオブジェクト」っぷりはJavaScriptの上行ってました。

hortensia:~ snsk$ ruby -v
ruby 1.8.7 (2011-12-28 patchlevel 357) [universal-darwin11.0]
hortensia:~ snsk$ irb
>> 1.to_s(10) #引数は基数。この場合、10進数で文字列に変換。
=> "1"

もう少し詳しく書くと整数はFixnum、少数はFloatというオブジェクトにになります。巨大な数はBignumで、どこまでがFixでどこからがBigか、は実行系によって異なるようです。

>> 1.class
=> Fixnum
>> 1.1.class
=> Float
>> 

なお、rubyでは変数がオブジェクトではなく格納されているアドレスへのポインタであるため、インクリメントが利用できないそうです (参考)

> num = 1
=> 1
>> num++
?> p num
SyntaxError: compile error
(irb):22: syntax error, unexpected tIDENTIFIER, expecting kDO or '{' or '(' from (irb):22
>> num+=1
=> 2

制御文 じゃなくて 制御式

if(hoge != 0){/*do something*/} という擬似コードがあったとき、他の多くの言語では hoge != 0 だけが「式」ですが、Rubyではこの手の制御構文が「式」として定義されています。 先ほどの擬似コード例では、 if(hoge != 0){/*do something*/} 全体が「式」です。式なので評価され、時に値を返します。if式においては実行された文の戻り値が if 式の左辺に入ります。よって、下記のような書き方が可能で、わりと一般的なんだそうな。

status = if unitTestResult == "green" then
    "passed"
else
    "failed"
end
p status #=> "passed"

また、rubyでは繰り返し処理にイテレータを使うのが一般的で、each、times、upto、downto、など専用のメソッドが豊富に用意されています。これをブロック付きメソッド呼び出しと一緒に使うことでオブジェクト(のメンバ)に対する繰り返しを表現するようです。ここ初心者詰まりそう。

1から100まで出力する一例は以下のとおり

100.times do |i|
  puts i
end

"||"で囲まれたローカル変数iに対してブロック内の処理を行う。ちなみに、do と end の代わりに { と } を使うこともできますが、基本的には「rubyっぽい」do と end を使い、

• ブロック付きメソッドがインラインの場合
• ブロック付きメソッドの戻り値を利用する場合
• ブロック付きメソッドからメソッドチェーンを利用する場合
• openが自動的にリソースを開放することを明示するためにブロックを使う場合

に限り波括弧を使う、という使い分けが本書で提示されていました。
特に思想ないのでこれにしようと思います。

nil と false のふたつの擬似変数以外は全て"真"

「0」も「""」も全部 "真"。
「0以外」が全部"真" なCいくつだかの仕様の真逆ですね。これは他言語からのヒト引っかかりそう。

File::open はブロックを渡すと自動的に開放してくれる

おお！便利！と思ったのですが、これだけ覚えてると「ブロックを渡さない場合は明示的にclose呼ぶ必要がある」が抜けそうで怖いです。

=== は Object#== の別名

PHPやJSから来たヒトがよく引っかかるところです。Good partsでは「常に === を使え」って書いてあるし。Rubyの === は型チェックしません。な、なんだってー！とつぶいたところ「ビルトインクラスと比較することで一応型チェック的なことはできるけど、言語の思想自体がダックタイピング推奨っぽい」とレスいただきました。なるほど。

軽量品質保証 - Lightweight Quality Assurance In Software Development-

はじめに

「ソフトウェア品質保証」という活動や技術分野にみなさんはどのような印象をお持ちでしょうか。工業製品で無敵を誇った品質大国ニッポンの志はソフトウェア品質保証にも受け継がれ、特に「モノづくり」の課程に対する姿勢は欧米からも範とされています。世界初のソフトウェア品質知識体系ことSQuBOKも日本の編纂によるものであり、その多くの知識エリア、特にテスト技法や経営まで視野にいれた品質マネジメントについては日本発の考え方や方法論が存在感を示しています。それだけに、「何かとっても難しそう」「具体的にどうしたら”出来た”と言えるのか、言っていいのかわからない」と感じる方も多いのでは無いでしょうか。特に、組織からの支援や潤沢な資金を与えられることの少ない非クリティカルシステム、超短期開発の現場において。さらに懸念されることは、そういう印象を持った結果、「ソフトウェア品質保証」という取り組み自体を諦めてしまう、または目の前にあるいくつかのそれらしい方法を組み合わせてお茶を濁してしまうことです。

”正しい”方法は、対象とする製品に見合った適切な品質の見極めとそれを保証する方策自体をデザインすることです。しかし、それにはソフトウェア品質保証技術に対するそれなりの造詣と経験が求められます。だからこその技術分野なのですが、余裕のない現場がこの技術分野への取り組み自体を諦めてしまう、おざなりにしてしまうのはとても残念なことに感じます。言うなれば、いまこれから「ソフトウェア品質保証」を学ぼうとする人には「富士山」しかない状況です。これから登山を嗜んでみようかと考える人が「富士山以外は山と呼ばない」と言われたら多くの人は怯むと思います。おそらく、これが現状です。

ソフトウェア品質保証の「高尾山」を

はじめて登山をする人が周りに居たら、関東なら誰もが「まずは高尾山に登ってみたら？」と薦めるハズです。山登りの厳しさではなく、楽しさを先に実感してもらうことで、さらなる高みを目指すモチベーションの土台を作る意図がそこにはあると思います。これをソフトウェア品質保証の世界にも当てはめられないか。もっと言えば、非クリティカルシステム、超短期開発の現場で悩むQAエンジニアにいったん「それでいいんだよ」「しっかりやってるよ」と言ってあげたい。そうして、まず小さな、確実な成果を出してもらうことで、プロセス自体の改善や、さらなる高みを目指すモチベーションを持って貰いたいと考えました。

できるの？そんなこと

直接的な動機の面は以上ですが、本当にそんなプロセスを定義することが出来るのでしょうか？先人たちの研究の成果や、ツールの発達によって、品質保証技術自体の適用も低コストで行える芽が出てきたと感じています。例えば一昔前に「レビュー指摘数」というメトリクスを採取するのはかなりのコストを必要としました。しかし、現在レビューはSCMに付属の機能や、専用のOSSツールを利用することが特に非クリティカルシステム、超短期開発の現場においては当たり前になっており、指摘数とその対応程度、及びターンアラウンドタイムなどを採取することが容易になっています。

ここがキモで、こういう現場はツールの導入やプロセスを変えることを厭いません。ということは品質保証技術を適用するためのツールや技術の導入のハードルも低く、残りの関門は「何があるのか、何を選べばいいのか知らない」だけである可能性が高いのです。であれば、そこだけビシっと定義してあげれば割と容易に成果を出すことが可能になるのではないでしょうか。

具体的なプロセスや利用する技術の選定はこれからですが、本ブログや書籍で何度か触れたことがある品質モデルの定義は最初のステップとして入れたいと考えています。ハードルを下げると言っているのにそんな難しそうな手順を入れて大丈夫なのかと感じられるかもですが、ここを外すとすべてを大きく間違えてしまう、外せない技術のひとつであると考えています。もちろん、1, 2時間で出来るようにデザインします。

軽量品質保証 - Lightweight Quality Assurance はどんな特徴を持つか

現時点での要件やメッセージを考えてみました。

• ひとり、またはふたり程度で実現可能であり、組織を必要としない
• 2週間程度のプロジェクトにゼロから適用出来る
• 極限まで人的、調達的コストを掛けない
• 省いた部分のリスクを明らかにする
• 継続的改善へのアプローチを盛り込む
  • 何度も行うことを前提とする
• 正確に間違えるよりも、漠然と正しくありたい
• 安い、早い、うまい

検討を進める中で落ちるかも知れませんがまずはここを達成したいなと思います。

軽量品質保証 - Lightweight Quality Assurance は何で無いか

いまあるソフトウェア品質保証を革新/刷新するものではない

ミッションクリティカルな製品や多くの組み込み系など、いまある体系を正しく理解し、適切に設計すべき分野もたくさんあります。そういう分野ではどうしても軽量というわけには行かないことが多いと思われます。

対立軸ではない

もし仮に重量品質保証というものがあり、そう感じておられる方がその対立軸として本件を捉えられているとしたらそれは明確に誤りです。どちらも単なる現場へのアプリケーションであり、重視する品質概念自体に違いはありません。

特定の開発プロセスを前提とするものではない

適用出来る開発プロセスの種類を限定するつもりは無いです。結果として向き不向きが生まれてしまう可能性がありますが、継続的改善は盛り込みたいと思っています。

興味があるので議論に加わりたい

ありがとうございます。下記にグループを作成しましたので、お気軽にご参加ください。ほとんどの資料、議事録等の管理にGoogleのインフラを利用する予定です。他のメールアドレスをご利用の方は、Googleのアカウントに、現在ご利用頂いているアドレスをひもづける形で、インフラを利用できる体制を整えて頂けますよう、お願い致します。

https://groups.google.com/group/Lightweight-QA

もしかしたらこのアドレスは取れない(他の人が取ってる)かなと思いましたが、案外あっさり取れました。

その一歩先にあるもの

この考えの大本は、各地の非クリティカル、超短納期開発に関わる若手のQA、テストエンジニアから「本当にできているのか自信がない」「やり方がわからない」という生の声をたくさん聞いたことがキッカケになっています。中には「おお！すごいじゃないですか！」と手放しで称賛できるプロセスもあったのですが、僕が言うだけでは何の足しにもなりません。いったん、公で作られた低いハードルを超えてもらうことで、ソフトウェア品質保証技術者としての矜持をきちんと持ってもらい、その先の探求に興味を持ってもらうことで、これがスコープとしないクリティカルシステムや大規模開発の分野における研究とも対流が発生するようになると考えています。そうして、この技術分野全体の活性化とさらなる発展に繋がっていくと良いな、とも考えてはいますが、達成できなくてもいいです。ゲンバの人たちが楽しく仕事できることがゴールです。

references

• @nekoasuka さんが当初これに先行する概念として提唱していた「軽品質」について感想を書いてくれました。根本の思想やインスタンスとなり得るものをよく捉えてくださってます。
  • 『軽品質』というもの
• Twitterの議論
  • https://twitter.com/search/realtime?q=%E8%BB%BD%E5%93%81%E8%B3%AA&src=typd

ISO/IEC25010 品質モデル

長らくソフトウェア品質モデルとして親しまれてきた ISO/IEC9126 が ISO/IEC25010(ISO/IEC 25000 SQuaRE シリーズの一部) として補強、改訂されましたので、ここで紹介したいと思います。参考文献 *1 がかなりイケているのでそちらを直接参照されても良いかと思います。

利用時の品質

9126時点では主特性のみの定義であった「利用時の品質」に副特性が定義されました。主特性自体も「効率性」「有効性」「安全性」「満足性」から多少の変更が見られます。

ISO9126時点での利用時品質の定義

注目すべきはコンテキストカバレッジで、システムの利用が机の前に限らなくなってきた昨今の状況がよく反映されているように思います。

データ品質

データ品質は主特性というより、以下の様なカテゴリに分かれます。

• 固有のデータ品質特性
  • システムが介在しなくても存在、評価できるデータが本来持つ品質特性。例えば紙の書類の回覧でも同様の品質が求められる

• システム依存のデータ品質特性
  • データをシステム上で運用する段になってはじめて問われはじめる特性

• 固有及びシステム依存のデータ品質特性
  • 前述のふたつの側面を併せ持つ特性。例えば「日付データ」などは、年号/日付 の記述方式といったデータ自体の特性と、システムで扱われる際のフォーマットの側面からの特性の両方を併せ持つ

システム/ソフトウェア製品品質

こちらは9126でもおなじみ、品質モデルというとこれを想起される方も多いでしょう。注目すべきはセキュリティが主特性として昇格している点や、9126では全主特性の子に存在した標準適合性が削除されている点などです。

テスト計画やテスト基本設計を考えるときについそのまま当てはめようとしてしまいますが、保守性や移植性など、テストよりプロセス、プラクティスで保証されるべき性質のものがあったり、その製品に本当に「互換性」が求められるのか？など、何段も製品に寄った運用が必要になります。

*1:システム／ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書 2011 年 3 月 経済産業省 ソフトウェアメトリクス高度化プロジェクト プロダクト品質メトリクス WG

テストの本書きました。

Androidアプリテスト技法

「書店で見掛けました！知ってる人が表紙に載っているのって嬉しいですね」

と会社の同僚に言われてふと、昔小劇場演劇に関わっているころ、同じように他の劇団のチラシの演者やスタッフ欄に知り合いの名前見つけて嬉しくなったことを思い出しました。本件に限らず「知っている人」の著作は受信精度が全く異なるものですよね。

記念すべき1冊め。下記目次のうち、僕は1章、および2章のテスト分析の部分までを書きました。あまり予算が取れない種のスマートフォンアプリ開発プロジェクトに向けた軽量なテスト分析の方法を提案しています。なお、僕の執筆部分については、Androidにまったく限定しておりません。逆に3章以降はテスト部がこれまで蓄積してきた"いますぐ使える"テスト実行のためのTips満載ですので、お好みに合わせてどこからでも拾い読みして頂ければと思います。

1 Androidテスト基礎(そもそもテストとは?
　テストの重要性
　ソフトウェアテストの考え方
2 Androidテスト実践(挑戦!テスト分析
　テスト設計技法‐同値分割法・境界値テスト
　状態遷移テスト ほか)
3 AndroidテストTips(ロジックのテストをしたい
　Activityのテスト
　バックグラウンド ほか)

ありがたいことにAmazonでは既に入荷待ちになっていますが、もし街の書店で見かけたら是非お手にとってみてくださいね。執筆に関わられたみなさま、お疲れ様でした。レビューアのみなさま、およびテスト部を支えてくださった部員のみなさまへ、ご支援のほど感謝です。

OpenSSL メモ

OpenSSLとは

OpenSSL は Eric A. Young と Tim J. Hudson によって開発された暗号ライブラリ SSLeay を元に現在最もWeb上で普及しているセキュアなProtocolであるSSLv2/3,TLS1を実装したアプリケーションです。これひとつで、SSLサーバ/クライアントはもとより証明書の発行、管理(ちょっと面倒)、認証まで行えてしまいます。同様の機能(≠SSLeay)をもつ国産のソフトとしてはAiCAがあります。

OpenSSLの入手先

最新のOpenSSLバイナリは http://www.openssl.org/ より入手できます。Windows上で運用する場合は、精力的にWin32バイナリを配布しておられる(ありがたや) Shining Light Productions より入手してください。Win32バイナリの場合はインストーラがついてきます。インストールが完了したら、コマンドプロンプトより、

C:\>openssl version

と打って、正しくインストールされているかどうか確かめてみてください。

とりあえずSSLサーバしてみる

無事インストールとPATHの疎通確認が終わったら、とりあえずSSLサーバを起動してみましょう。コマンドプロンプトより、

C:\>openssl

と打って、プロンプトが OpenSSL> に変わればOKです。OpenSSL> に続けて

s_server -www -accept 5443 -cert C:\openssl\bin\PEM\demoCA\cacert.pem -key C:\openssl\bin\PEM\demoCA\privatecakey.pem

と入力してエンターキーを押下してください。ここでは便宜上C:\直下にopensslがインストールされている設定ですが、Windows7以降ではユーザフォルダ直下、MacOSでは which openssl などとしてインストール先のディレクトリに適宜読み替えて下さい。

(略)
Using default temp DH parameters
ACCEPT

と表示されればOKです。お手持ちのブラウザから、https://localhost:5443 にアクセスしてみてください。 今回はOpenSSLに付属してるデモ用の証明書と秘密鍵を利用しましたので、各種認証エラーでまくりだと思われますが、とりあえずのSSLサーバとして動作する事はご確認いただけたと思います。

s_server

先ほどの動作確認の際に打ち込んだコマンドです。指定されたポートで稼動するSSL/TLSサーバ(それとSimpleなHTTP応答機能)を実現します。OpenSSLはそれ自身を起動したのち、OpenSSL> プロンプトで、さまざななコマンドに無数のオプションとそれに伴う引数を指定のうえ、タスクを実現します。各種コマンド,オプション,引数に関しての正確な情報は OpenSSLのドキュメント を参照してださい。

以下にs_serverコマンドでよく利用する、いくつかのオプションを挙げておきます。

-accept port

待ち受けるTCPポート番号を指定します。このオプションが省略された場合は4433が利用されます。

-cert certname

設定するサーバでチェインの末端に位置する証明書(一般的にはそのサーバ自身を証明するもの)を指定します。Apache-SSLでいう、SSLCertificateFile ディテクティブに相当します。このオプションを省略した場合は"server.pem"が指定された、とみなされます。

-key keyfile

先ほどの -cert で指定したサーバ証明書の秘密鍵を指定します。Apache-SSLでいう、SSLCertificateKeyFile ディテクティブに相当します。

-verify depth, -Verify depth

Client認証時に辿るチェインの深さを指定します。Apache-SSLでいう、SSLVerifyDepth ディテクティブに相当しますが、OpenSSL単体の場合は SSLVerifyClient も同時に指定します。-verify とすると任意。-Verify とするとクライアント証明書の送付が必須となります。

-CAfile file

"-cert" で指定したサーバ証明書までの認証パスを持つ証明書チェインを、pemエンコードされた単一のファイルで指定します。Apache-SSLでいう、SSLCACertificateFile ディテクティブに相当。ちなみに先頭2文字は大文字でないとinvalid commandとなります。OpenSSLコマンドは大文字と小文字を区別するようです

-state

クライアントから接続があった際に、進行中のハンドシェイクの流れをおおまかに表示します。

-debug

レコードレイヤまで含めた広範なトラフィック情報を16進ダンプを含めて表示します。

-msg

プロトコルレイヤの情報を16進ダンプと一緒に表示します。
※古い版のOpenSSLには搭載されていません。

-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1

前者3つはServerHello送信時のサーバ側SSLバージョンを指定し、後者3つはそのサーバで無効とするSSLバージョンを指定します。

-cipher cipherlist

ServerHello送信時にサーバが指定するCipherのリストを指定します。
参照:http://www.openssl.org/docs/apps/ciphers.html#
ページ下部にあるCipherSuiteを単体で指定する事も可能で、clientがそれをサポートしてない場合はハンドシェイク失敗となります。