MySQL,Java,Eclipseで困り果てる。

こんにちはよしときです! 今日はWebアプリケーションの第一歩としてEclipse上でJavaとMySQLを使おうと設定を行いました。 が。 なんでか全くうまくいかない・・   JDBCをダウンロードしてビルドパスに設定してもMySQL側でユーザーに全権限を与えてもどうしてもEclipse上で接続できないのです。 ターミナルでパスを通してみたりもしたのですが駄目。 Eclipseのプラグインでも駄目。 Tomcatのserver.xmlで接続を試みても駄目。   ターミナル上では問題なくMySQLは動くのですが、、、   原因をさがしてもさがしても見つからずほとほと困り果てています。   果たして進めるのだろうか・・・   XamppのMySQLのせいか??   本当に一日中試行錯誤したのにうまくいかないのは初めてで頭を抱えています。。。   どうしたらいいのだろう・・・   以前通ったリカレントスクールに聞きにいくことを検討。

セキュリティについて(まとめ)

こんにちは、よしときです!今回はセキュリティについて書籍にて学習したのでそのまとめを行いたいと思います。 使った書籍はこちら それでは章ごとに見ていきたいと思います。    

第一章 WEBアプリケーションの脆弱性とは

この章では導入として脆弱性とは何かというところから説明をはじめて、脆弱性が生まれる理由、セキュリティバグとセキュリティ機能の違いが説明されています。   まず脆弱性とは「悪用できるバグ」のことであり、経済的損失、利用者が回復不可能なダメージを受ける、サイト利用者に嘘をつくことになる、ボットネットワーク構築に加担することがあり、それを防ぐ必要があります。また、法的要求を満たすためでもあります。 脆弱性が生まれる理由として
  1. バグによるもの
  2. チェック機能不足によるもの
が挙げられています。 セキュリティバグとセキュリティ機能の違いは一方はバグであり、もう一方は通信路を暗号化するように積極的に安全性を強化する物です。  

第二章 実習環境のセットアップ

この章では本の実習環境をセットアップをします。この本では脆弱性を体験できる環境をVMware上の仮想マシンを用いて行います。そのツールのセットアップ方法となります。 環境はLinux,Apache2.2,PHP,PostgreSQL,Sendmail等メールサーバーを使う物として書いており、今回は使用OSがMacなのでこちらは省略いたします。  

第三章 WEBセキュリティの基礎

この章はWEBアプリケーションセキュリティの基礎となるHTTPやクッキー、セッション管理などの知識、同一性元ポリシーという考え方について説明されています。 まずHTTPとクッキー、セッション管理について、
  • どのような順序で動いているかの説明
    • リクエストメッセージ、レスポンスメッセージ、ステータスライン、レスポンスヘッダの説明
  • POST,GET方式の使い分け
    • GETは参照のみに用いる、POSTは機密情報の送信に用いる
  • HTTP認証の流れ
    • Basic認証をつかってみる
  • クッキーとセッション管理について
    • クッキーとはサーバー側からブラウザに対して名前=変数の組を覚えておくように指示するもの
    • セッション管理はクッキーが保持できる値などに制限があるため、また、秘密情報保持の為につかわれるものです。さらにそこからクッキーについての説明があります。
次に同一生成元ポリシーについてとなります。同一生成元ポリシーとはネットワークアクセスの制限であり、サンドボックスで制限されます。サンドボックスとはこれらのように制限をかける仕組みのことです。 ここから実際に同一生成元ポリシーについてのJavaScriptを例に説明が続きます。 同一生成元である条件として
  1. URLのホストが一致している。
  2. スキームが一致している
  3. ポート番号が一致している
の三つが挙げられています。   この節でブラウザを介して受動的攻撃をうけるという手法とその制限について説明されたことになります。  

第四章 WEBアプリケーションの機能別に見る

この章がこの本の中心となる章で、WEBアプリケーションの機能毎に発生しやすい脆弱性パターンについて、原理から対策方法まで説明されています。 まず、WEBアプリケーションの機能と脆弱性の対応からはじまります。 脆弱性の発生箇所として例が挙げられていてそれらをまとめると
  • 脆弱性には処理に起因する物と出力に起因するものがある。
  • 入力に起因する脆弱性はない
  • 出力に起因する脆弱性には「インジェクション」という単語がつくものが多い
となります。そこで、「インジェクション系脆弱性」とはデータの中に引用府やデリミタなどのマークが混入させられ、その後の文字列の構造が変化させられてしまうものです。   次に入力処理についてで、入力された処理についての処理についての説明があります ソースをみて流れを説明しています。そこから入力値の検証の説明となります。 流れとして大まかに
  1. 入力値検証はアプリケーション仕様に基づいて行う
  2. 文字エンコーディングの検証
  3. 制御文字を含む文字種の検証
  4. 文字数の検証
となり、その実地の手順として
  1. 設計段階で各パラメータの文字種および最大文字数を仕様として決める
  2. 設計段階で入力値検証の実装方針をきめる
  3. 開発段階では仕様に従い入力値検証を実装する
となります。   つぎは表示処理に伴う問題としてXSS(クロスサイト・スクリプティング)の説明となります。 XSSとは外部からの入力などに応じて変化する箇所があり、その部分のHTML生成の実装に問題があると起こる脆弱性のことで、成りすまし被害や、個人情報を盗まれる恐れがあります。 XSSは表示方法の間違いが主な発生要因なので正しいHTMLを生成することがXSS解消の第一歩となります。XSS脆弱性は後からの対処が大変な労力がかかることも書かれています。   次にSQL呼び出しに伴う脆弱性です。前述したインジェクションのひとつSQLインジェクションについてかかれています。これは全てのページが影響をうけ、情報漏洩からデータ改ざんなど様々な影響に繋がってしまうので絶対回避すべき脆弱性です。こちらもソースで攻撃方法の説明があり、そこから原因と対策の説明があります。 原因は前述した「文字列リテラル」、数値項目にたいするSQLインジェクションが挙げられ、対策としてプレースホルダとしてSQL分を組み立てること、リテラルを正しく構成することなどが挙げられています。なかでも静的プレースホルダ(文がそのままデータベースエンジンに送られ、次にバインド値が送られる。エンジン側で値を当てはめた後に文が実行される)を推奨しています。   次は「重要な処理」の際に混入する脆弱性で、「重要な処理」とは取り消しが出来ないような重要な処理のことについて説明されています。 まずCSRF(クロスサイト・リクエストフォージェリ)についての説明で、これは、利用者の意図したリクエストであることを確認するべき所でその確認処理が抜けていると勝手に「重要な処理」を実行される可能性があり、それCSRF脆弱性と呼びます。 CSRF対策は設計段階から盛り込む必要があり、対策が進んでいない項目でもあります。 対策としてあげられるのは
  • CSRF対策の必要なページを区別する
  • 正規利用者の意図したリクエストを区別するよう実装する
となります。   次はセッション管理の不備についてで、セッションハイジャックについて書かれています。 セッションハイジャックとはセッションIDが第三者に知られると成り済ましてアクセスする可能性があり、それを悪用することです。 セッションハイジャックをされてしまう要因として
  • セッションIDの推測
  • セッションIDの盗み出し
  • セッションIDの強制
が挙げられ、それぞれ概要が書かれています。 それぞれ対策としてまとめると
  1. セッション管理機構を自作せずWEBアプリケーション開発ツールのものを使う
  2. クッキーにセッションIDを保存する
  3. 認証成功時にセッションIDを変更する
  4. 認証前にはセッション変数に秘密情報を保存しない
となります。これらは設計の段階から計画的に行うことで少ない箇所で対策することが出来ます。   次はリダイレクト処理にまつわる脆弱性とあり、リダイレクト処理時におこる脆弱性として
  • オープンリダイレクタ脆弱性
  • HTTPヘッダ・インジェクション脆弱性
が挙げられています。 オープンリダイレクタ脆弱性とはリダイレクトする機能(リダイレクタ)の中で任意のドメインにリダイレクトできるものをオープンリダイレクタと呼び、その際に知らないうちに別ドメインに遷移する場合にフィッシングという詐欺に悪用される可能性があることです。 対策として
  • リダイレクト先のURLを固定にする
  • リダイレクト先のURLを直接指定せず番号指定にする
  • リダイレクト先のドメインをチェックする
とあります。 次にHTTPヘッダ・インジェクション脆弱性とは、リダイレクトやクッキー発行など外部からのパラメータをもとにレスポンスヘッダを出力する際に発生する脆弱性で、改行などを挿入する攻撃によって
  • 任意のクッキーの生成
  • 任意のURLへのリダイレクト
  • 表示内容の改変
  • 任意のJavaScript実行によるXSSと同様の被害
という影響があります。 対策として
  • 外部からのパラメータをHTTPレスポンスヘッダとして出力しない
  • リダイレクトやクッキー生成を専用APIに任せる、ヘッダ生成するパラメータの改行文字をチェックする
のいずれかを実地することです。   つぎにクッキー出力にまつわる脆弱性で、クッキーの不適切な利用について説明されています。 脆弱性の例として「クッキーのセキュア属性不備」があげられています。これはクッキーのSecureという属性をつけないと盗聴される可能性があるというものです。 対策としてあげられるのは
  • セッションIDのクッキーにセキュア属性をつける
  • トークンを用いた対策
があげられています。   つぎはメール送信についての問題で、メールヘッダインジェクション脆弱性、hiddenパラメータによる宛先保持、メールサーバによる第三者中継という三つの問題について取り上げています。 メールヘッダインジェクション脆弱性は宛先や件名などヘッダフィールドに改行を挿入することによって改ざんする攻撃手法です。hiddenパラメータによる宛先保持は送信先アドレスを任意のアドレスに変更することによって悪用される可能性があることです。メールサーバーによる第三者中継はアプリケーション起因のものではなく、一つの脆弱性として説明だけされています。 さて、上記の対策をみていきます。 まずメールヘッダインジェクションでは
  • メール送信には専用のライブラリを使用する
その上で
  • 外部からのパラメータをメールヘッダに含ませないようにする
  • 外部からのパラメータには改行を含まないようにメール送信時チェックする
という対策をとります。   ファイルアクセスにまつわる問題についてを見ていきます。 ファイルを取り扱う際に以下の問題があります。
  • WEBサーバー内のファイルに対する不正アクセス(ディレクトリ・トラーサル)
  • OSコマンドの呼び出し(OSコマンドインジェクション)
ディレクトリ・トラーサルとは外部からパラメータの形でサーバー上のファイル名を指定できるアプリケーションで、ファイル名に対するチェックが不十分であると、意図しないファイルに対して改ざん、削除が出来るという脆弱性のことをいいます。 対策として
  • ファイル名を外部から指定することができる仕様を避ける
  • ファイル名にディレクトリ名が含まれないようにする
  • ファイル名を英数字に限定する
とあります。 次にOSコマンドインジェクションはアプリケーションよりシェル経由でOSコマンドを呼び出す際に、問題があることをいいます。 これら脆弱性があると、外部の攻撃者から様々な攻撃を受けることとなり、非常に危険であると言えます。 対策としては
  • OSコマンド呼び出しを使わない実装方法を選択する
  • シェル呼び出し機能のある関数の利用を避ける
  • 外部から入力された文字列をコマンドラインのパラメータに渡さない
  • OSコマンドに渡すパラメータを安全な関数によりエスケープする
とあります。これらは採用すべき順に並べていいます。 どの対策を採用すべきかは設計フェーズで方針を決定します。   ファイル不アップロードにまつわる問題として挙げられるのが
  • アップロード機能に対するDoS攻撃
  • サーバー上のファイルをスクリプトとして実行する攻撃
  • 仕掛けを含むファイルを利用者にダウンロードさせる工芸
  • ファイルの制限を超えたダウンロード
という攻撃です。 そのうちアップロードファイルによるサーバー側スクリプト実行という問題があります。 これは名前の通りで利用者がアップロードしたファイルをスクリプトとしてWEBサーバー上でじっこうされ影響が出ます。 対策としては、スクリプトとして実行可能な拡張しを利用者が指定できること、ファイルを公開ディレクトリに保存すること、これらどちらかをつぶすことになります。 次にファイルダウンロードによるXSSです。 これはダウンロードの際にファイル形式を誤認識することでJavaScriptを実行してしまうもので、自動でアップロードされてしまうなどの危険があります。 対策はアップロード時に
  • 拡張子が許可されたものかをチェックする
  • 画像の場合はマジックバイト(画像の中身)も確認する
ダウンロード時に
  • Content-Typeを正しく設定する
  • 画像の場合は、マジックバイトを確認する
  • 必要に応じてContent-Dispositionヘッダを設定する
という対策を撮る必要があります。   次にインクルードにまつわる問題とあり、アプリケーションが意図しないファイルを指定することにより脆弱となることがあります。対策として
  • インクルードするパス名に外部からのパラメータを含めない
  • インクルードするパス名に外部からのパラメータを含む場合は英数字に限定する
とあります。 これらは影響の大きな脆弱性の為、十分な対策を推奨されています。   最後に共有資源に関する問題として 競合状態の脆弱性についてかいてあります。 共有資源とは複数のプロセスから同時に利用している変数、共有メモリ、ファイル、データベースなどのことです。 競合状態の脆弱性の例として
  • 別人の個人情報などが画面に表示される
  • データベースの不整合
  • ファイルの内容破壊
です。 対策として挙げられているのが
  • 可能であれば共有資源を使用しない
  • 共有資源に対して排他制御を行う
   

第五章 代表的なセキュリティ機能

この章では題名の通り代表的なセキュリティ機能として、認証、アカウント管理、認可、ログ出力について説明されいています。 まず認証についてです 認証とは利用者が確かに本人であることを確認することです。 その対策と注意点として以下が挙げられています
  • ログイン機能
  • 総当たり攻撃への対策
  • パスワードの保存方法
  • 自動ログイン
  • ログインフォーム
  • エラーメッセージ
  • ログアウト機能
次にアカウント管理について説明されており以下の機能について注意点を説明しています
  • ユーザ登録
  • パスワードの変更
  • メールアドレスの変更
  • パスワードリマインダ
  • アカウントの停止
  • アカウントの削除
認可、制御についての説明と成ります。 認可とは認証された利用者にのみ権限を与えることです。認可不備があると個人情報漏洩や権限の悪用などの問題に直結してしまいます。 そこで認可制御の正しい実装方法として
  • このスクリプト(画面)を実行してよいユーザか
  • リソースに対する操作の権限があるか
を確認することだと記されています。   ログ出力についてです。 ログ出力が重要である理由は
  1. 攻撃や事故の予兆をログから把握し、早期に対策するため
  2. 攻撃や事故の事後調査のため
  3. アプリケーション運用監査のため
の3点です。 ログの中でもアプリケーションログのエラーログ、アクセスログ、デバッグログについて説明されており、その使い方などが説明されています。有効なログを取得する為には4W1Hの項目を取得し、安全性を確保することが重要とされています。    

第六章 文字コードとセキュリティ

六章は文字コードとセキュリティとなっており、WEBアプリケーションの脆弱性の中には文字コードの扱い起因するものが多くあり、そのために文字コードの基礎から脆弱性が生まれる原因と対策の概要を説明されています。   まずは語句の説明としていくつか挙げられています。 文字集合とはその名の示すように文字をあつめたものです。それを各文字に符号をつけて識別したものが文字集合とよばれます。その例としてUnicodeやISO-8859-1などがあります。 文字エンコーディングとは文字集合についた符号の符号化のことです。例はShift-JISやUTF-8です。   文字コードによる脆弱性として
  • 文字エンコーディングとして不正なバイト列による脆弱性
  • 文字エンコーディングの扱いの不備による脆弱性
  • 文字集合の変更に起因する脆弱性
が挙げられています。以下は文字コードを正しく扱うためのポイントが4つ挙げられています。
  1. アプリケーション全体を通して文字集合を統一する
  2. 入力時に不正な文字エンコーディングをエラーにする
  3. 処理の中で文字エンコーディングを正しく扱う
  4. 出力時に文字エンコーディングを正しく指定する
これらを注意して脆弱性を対策することが大切だと説明されています。    

第七章 携帯電話向けWEBアプリケーションの脆弱性対策

この章では携帯電話特有の脆弱性問題として、認証とセッション管理の問題を取り上げています。   まず、ゲートウェイの説明からです。 ゲートウェイは以下の役割をもつものです
  • 携帯電話網からインターネットへの橋渡し
  • 携帯IDの付与
  • クッキー保持
  • 絵文字への変換
などです。これらは携帯電話事業者によって変わることがあります。   携帯のブラウザの機能の特徴として
  • クッキーが使えない
  • JavaScriptが使えない(一部)
  • Refererなどリクエストヘッダの制限
  • HTTPレスポンスの容量制限
があります。これを前提にセキュリティについて見ていきます。 その中にクッキーが使えないことによりURL埋め込みのセッションIDによる問題があります。 この方法には成り済ましのリスクがあり、使わないようにするべきですが、携帯では使わざる得ないことがあります。そこで対策を説明しています。以下が対策になります。
  • クッキーが使える機種にはクッキーを使う
  • 外部ドメインに極力リンクしない
  • 外部リンクにはクッションページを挟む
  • ログイン後にセッションを開始する
  • 検索エンジン対策
そして、携帯電話は今後も環境が変化していくのでその都度対策を行うべきとあります。    

第八章 WEBサイトの安全性を高める為に

八章ではWEBアプリケーション意外の側面から、WEBサイトの安全性を高めるための施策の全体像を説明されています。   まずWEBサーバーへの攻撃経路と対策として、基盤ソフトウェア(OSやWEBサーバー)の脆弱性をついた攻撃があります。さらに不正ログインなどの攻撃も考えられます。それらの対策として以下が重要であるとせつめいがあります。
  • サービス提供に不要なソフトウェアは稼働させない
  • 脆弱性の対処をタイムリーに行う
  • 一般公開する必要のないポートやサービスはアクセス制限する
  • 認証強度を高める
つぎに成り済まし対策について考えていきます。 まず事例として まずDNSに対する攻撃、ARPスプーフィング、フィッシングが挙げられています。 そしてその対策として
  • ネットワーク的な対策
    • 同一セグメント内に脆弱なサーバーを置かない
    • DNS運用強化
  • SSL/TLSの導入
  • 確認しやすいドメインの採用
が挙げられています。   次に盗聴・改ざんの対策としては正規の証明書を導入してSSLを運用することに尽きる。とあり、その注意点として入力画面からHTTPにすることであると書かれています。   次はマルウェア対策です。マルウェアとはウィルスなど不正プログラムのことで、その感染経路の実態図があります。そこから対策を挙げており、その概要は
  • サーバーの脆弱性対処をタイムリーに行う
  • 出所不明なプログラムをサーバーに持ち込まない
  • サーバー上では運営に直接関係のない操作をしない
  • サーバーにUSBメモリなど外部メディアを装着しない
  • WEBサーバーのネットワークを執務スペースのLANと切り離す
  • サーバーに接続するクライアントPCにウィルス対策ソフトを導入してパターンファイルを最新に保つ
  • Windows UpdateなどによりクライアントPCに最新のセキュリティバッチを導入する
となります。    

第九章 安全なWEBアプリケーションの為の開発マネジメント

最後に安全なWEBアプリケーション開発のための開発プロセスについて説明されています。 流れとしてはまず、開発マネジメントにおけるセキュリティ施策の全体像をおさえ、次に開発体制についての書かれています。そして開発プロセスの留意点を挙げて、基本設計、詳細設計の時の留意点が挙げられています。 そしてその他としてウェブ健康診断仕様の紹介、受注者側テスト、発注者側テスト、運用フェーズの留意点について軽く触れられています。 これらは実用に関しての留意点が主で、その具体的な方法については書かれていません。   以上。長いものでしたが、PHPのソースコードは省いて、かつ重要な点のみをまとめてみました。

iOS まとめ

こんにちは、うさです。 本日で一応iOSについての勉強を終えて、 次回からもう一度サーバーサイドの勉強をしたいと思います。 そして、本日学んだことは昨日と同じくObjective-Cを用いての家計簿のアプリ作りです。 昨日はひたすら書籍に書いてあることを真似して書くというもので 頭にはなかなか入らなかったので、 本日はひたすらノートにコードを書き、わからないクラスやメソッドを調べながら頭に叩き込んでいきました。 このようにやっていくとある程度形式的にコードが書かれていることが多いのだなと思いました。 例えば、メソッドで長くて絶対理解できないと思っていた ですが、 これはデータベースにおいて必要な挿入・削除・更新・入れ替えの4パターンそれぞれ対して、 この後の それぞれの処理に対応しています。 また、サンプルで使用されているメソッドを調べてみると 使用をおすすめしてないようなものもあった。 例えば、 [NSCalendar currentCalendar]はカレンダーを使うクラスになるのですが、 iPhoneの設定で「設定」-> 「一般」->「言語環境」->「カレンダー」から和暦の設定にすると 4000年4月1日(土) ←2012年4月1日は日曜日 こんな感じに表示がおかしくなることがある。 (平成2012年として表示しているため) 今回は、おかしくならなかったが、 上みたいになったら、 dateFormatter.calendar = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; で記載することで、西暦に統一することができる。 まだまだ、iOSやObjective-Cについてはわからないことだらけだが、 徐々に学んでいこうと思う。 以上うさでした。
スクリーンショット 2015-02-19 15.17.42

iOS学習 家計簿を作る

こんにちは、うさです。 昨日と今日でiOSの家計簿アプリを作りました。 ページの構成としてはこんな感じ スクリーンショット 2015-02-19 15.17.42 ページ数が多くてなんだかややこしいですね そしてデータベースはCoreDataのSQLiteを用いてデータの保存を行います。 では、CoreDataで使用するクラスを確認していきます。
  • NSManagedObject:CoreDataで永続化されるデータの全てをこのクラスをインスタンス化して使用。 SQLiteの場合は、1つのモデルが1つのテーブルに対応してインスタンスがそのテーブルの各レコードに対応
  • NSManagedObjectContext:CoreDataを扱う際に中心となるクラス。 データの保存・削除・移動などを管理
  • NSEntityDescription:エンティティの定義を管理するクラス。 データを新規作成する時に使用
  • NSManagedObjectModel:各エンティティの情報やエンティティ同士の関連を管理するクラス。 Xcode上のGUIのエディタで編集したものを読み込んで初期化
  • NSPersistentStoreCoordinator:NSManagedObjectModelとSQLiteなどのファイルを関連づけして永続化を行う
  • NSFetchRequest:データの検索に使用するクラス。 検索条件やソート、取得件数などを指定
  • NSFetchedResultsController:NSFetchRequestを元にデータを取得しUITableViewで扱いやすいようなAPIを提供。 delegateを指定した場合には、NSManagedObjectContextを監視して指定のNSFetchRequestに関連のある変更が合った場合にdelegateに処理を委譲する
といった感じでクラスを利用していきます。 ソースコードは全部書くと膨大な量になってしまうため、ある1ページのソースコードを書いてどんな処理を行っているのか見ていきます。   このソースコードは下の画像のページにおける処理を行います。 スクリーンショット 2015-02-19 15.45.57 家計簿における項目の入力を行うページになります。 今回、このアプリをつくってみて感じたことは、
  • ページ数が多いとどのページとどのページか関連し合っているのかがわからなくなる
  • エラーが出ている時は基本的にはスペルミス(笑) →本格的に開発を始めたら、予測変換を最大限の活用!!
  • とにかくクラスやメソッドを覚えないことには開発は難しい
です。 とりあえず、このアプリを何度も作ってみたりしてObjective-Cの記述方式に慣れていきます。 以上うさでした。
iOS Simulator Screen Shot 2015.02.18 10.15.57

iOS基本動作その2@よしとき

こんにちは。よしときです。 今回は前回の続きでiOSの基本的なUIを使って勉強をしていきました。 まず最初にシーン遷移を行いました。 いくつかのシーンを行き来するというものです。 iOS Simulator Screen Shot 2015.02.18 10.15.57   上の画面がHome画面でそれぞれボタンを押すと対応した画面に移動します。 Frogシーンへ移動すると iOS Simulator Screen Shot 2015.02.18 10.16.00 この画面に。 GotoHomeを押すと戻ります。   シーンを移動するボタンと戻るボタンは別の書き方をしているのがポイントとなりそうです。 ここで初めてHeaderファイルを使いました。全シーンで使うような場合はヘッダーファイルに記述するんですね!   さらに、シーンごとのアニメーションなどはそれぞれにビューコントローラーファイルを生成して、そこに書き込むことで動くことが分かりました。   続いて行ったのがタブでのシーン選択です iOS Simulator Screen Shot 2015.02.18 10.15.38   下部に出るタブを選択することでそれぞれのシーンに移行することが出来ます。 こちらはシーン同士を繋いだりするだけで出来たので分かりやすかったです。     続いて学んだのが「デリゲート」というものなのですが、これが分かりづらい・・・ なにがしのイベントが選択された時に代理として呼ばれるものがデリゲートというものらしいのですが、どーも分かりづらい。。   今回やったのはまず、テキストフィールドのデリゲートということでテキストを入力しようとするとキーボードが出てきて、エンターを押すとキーボードが引っ込むというもの。 今回はこの「キーボードが引っ込む」ところがデリゲートの動作に当たる部分のようです。 iOS Simulator Screen Shot 2015.02.18 11.06.08     テキストフィールドだけでなく、アクションシートの選択肢を選んだりするのにもデリゲートを使います。 iOS Simulator Screen Shot 2015.02.18 11.20.21   下部に出てくる選択肢を選んだ際に行う動作がデリゲートメソッドとなります。   つまり、なんらかの選択をしたときに他のメソッドを利用できる?ってことなのでしょうか。。 デリゲートには種類が沢山あるようで例えば広告を表示させたりすることも出来るようです。   デリゲートはiOSアプリを作る上で大切だとどこでも書いてあるので、どんどん使って理解していきたいと思います。   さて、次に行ったのはモーションイベントを使った動作ということで、iPhoneを振るとサイコロが振られる。というものを作りました。   iOS Simulator Screen Shot 2015.02.18 12.11.57   今回はシュミレーターで動作させたので実際には振りませんが、しっかり動いたのでよかったです。 サイコロの動作等は簡単なプログラムで動きますが、モーションのイベント処理(振った時どうするか)を結構しっかりかかなくてはならないのがポイントでした。 単純にモーションイベントの勉強だけでなく、久々に論理の勉強にもなりました。   続いて、上記同様でシェイクすると音が鳴って画面が変わるというもの。 iOS Simulator Screen Shot 2015.02.18 12.27.34 この画面のときシャキーンと鳴ってますw 音を使うときはフレームワークを追加してサウンドファイルを使用できるようにしなくてはならないことがポイントでしょうか。 サウンドの設定、モーションイベントの設定、バイブレーションの設定について学ぶことができました。     最後に行ったのがMAP関連の動作です。 mapを使う為のフレームワークを追加してマップビューで表示。。 というところまでは良かったのですが、位置情報がでない・・・ どうしても動作しなかったのですが、調べてみるとiOS8から位置情報の取得の種類が増えたらしく、少し追記しなくてはならない部分が出てきたようです。   Info.plist   ファイルに NSLocationAlwaysUsageDescription NSLocationWhenInUseUsageDescription というものを追加してやることで、このアプリケーションで位置情報の選択が設定から出来るようになります。 これを追記して、設定 プライバシー 位置情報 アプリ名 で位置情報の取得の選択をしてやることでついに動作することが出来ました。   iOS Simulator Screen Shot 2015.02.18 13.39.39   今回はシュミレータを使用しているので場所は手入力した座標になります。   左下のfollowを押すと現在地に追従する動きとなります。   Mapを使ったものはAndroidしかり毎回苦労させられます。。。 なんとか攻略したいものですね!!   以上でiOSの基本的な動作は終了しました! 次回は今までやった物を組み合わせてなにか作ってみるつもりです!乞うご期待!  

備忘録:ソフトウェアテストを学ぶ

こんにちは。ヨシトキです。   今回はソフトウェアソフトの書籍で学んだことを章ごとにまとめてみます。    

第一章:自己診断テスト

ここでは簡単なプログラムを実際にテストしてみて自分の実力を判断するという物です。 実はこのテスト。熟練のプログラマでも50点ほどしかとれないもので、プログラムテストがいかに容易ではないか。ということを目の当たりにします。    

第二章:プログラムテストの心理学と経済学

この章ではプログラムテストを心理学的、経済学的に考えてみよう。となっています。 まず、テストの心理学として 「プログラムはエラーをふくんでいるという仮定のもとでテストをはじめるべきである。」 「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 という定義で行うことが大切であると説いています。 つぎにテストの経済学として 「プログラムの全てのエラーをみつけることは、非現実的であり、不可能である」 「テストする人がそのプログラムに対して持つ仮定と、テストケースのを設計する方法をどうするか」 とあります。 経済学についてはすこし分かりづらいのですが、ここからこの定義に戦略をたてています。 これらを前提にソフトウェアテストの原則を述べているのもこの章で、それぞれ
  1. テストケースの必須条件は、予想される出力または結果を定義しておくことである。
  2. プログラマは自分自身のプログラムをテストしてはならない。
  3. プログラム開発グループは、自分たちのプログラムをテストしてはならない。
  4. それぞれのテストの結果を完全に検査せよ。
  5. テストケースは、予想できる正しい入力条件ばかりでなく、予想しない誤った場合も考えなて書かなくてはならない。
  6. プログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功しただけにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることである。
  7. プログラムが本当に使い捨てのもので無い限り、そのテストケースも使い捨てにしてはならない。
  8. エラーは見つからないだろうという仮定のもとにテストの計画をたててはいけない。
  9. プログラムのある部分でエラーがまだ存在している確率はすでにその部分で見つかったエラーの数に比例する。
  10. テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である。
という原則を根本原則としていくことが大切である。と説いています。    

第三章:プログラムの検査、ウォークスルー、検討

ここではまず、コンピュータによらないテスト仮定、つまり人間によるテスト、を扱っており、その技法を説いています。 まず最初に「検査」と「ウォークスルー」についてです。 これらは人間によるテストの基本的な物で共通点がおおい似たものになっています。 共通点としてあげられることを先に挙げると
  • 準備をし、チームの人々がプログラムを読む(会合)
  • 開発者のグループ3、4人で行われる。
  • 机上チェック作業の改良である
となっています。 次に、それぞれについて詳しくみていっています。

検査

4人の検査チームを構成し、検査会を開きます。検査会はそれぞれがプログラムのリストと設計仕様を調べておき、次の活動を行います。
  1. プログラマはプログラムの論理を1命令ずつ読み上げる。そして参加者が疑問点をあげ、エラーがあるかどうか判定する。
  2. 共通のプログラムエラーリスト(よくあるプログラムの間違いのリストのようなもの)を見ながら分析する。
という内容で行われます。検査後再び見つかったエラーをリストとし、再検査を行うか検討します。 大事なことはエラーの発見に集中し、その場でエラーを修正しないということである。と説いています。 検査の為のエラーリストを大まかにあげると
  • データ参照エラー
  • データ宣言エラー
  • 計算エラー
  • 比較エラー
  • 制御流れエラー
  • インタフェイスエラー
  • 入力・出力エラー
  • その他のエラー
となっています。  

ウォークスルー

3人から5人のチームで構成され、検査同様に勉強した状態で会合を行います。 しかし検査と違い読み上げたりエラーチェックリストを使ったりするのではなく、参加者がコンピュータを演じることとなります。 すなわち、前もって準備されたテストケースを頭の中、または紙、黒板で実行されます。 その中で質問が投げられエラーを見つける手法です。 ウォークスルーもまた、追試仮定をもつことが大切だとあります。  

更なる方法

さらに挙げられる方法として机上チェック仲間内の検討というものが挙げられています。効果が高いとは言えないがプログラマが自己評価できる。という点で役に立つそうです。    

第四章:テストケースの設計

  さて、実際にテストケースを設計する手法を挙げていく章となります。まず今回の前提条件としてあげられているのが 「可能なテストケースのどのようなサブセットがもっともエラーを発見できる確率が高いか」 となります。 そして、それに当てはまる解をそれぞれの手法を精査し検討していきます。 検討する手法は以下の通りで
  • ブラックボックステスト
    1. 同値分割
    2. 限界値分析
    3. 原因-結果グラフ
    4. エラー推測
  • ホワイトボックステスト
    1. 命令網羅
    2. 判定条件網羅
    3. 条件網羅
    4. 判定条件・条件網羅
    5. 複数条件網羅
となっています。 まずそれぞれの手法を検討していきますが、それぞれいいところ悪いところが挙げられています。 そこでそれぞれをうまく使い解を得る戦略がまとめとして載っています。 それは
  1. 仕様が入力条件の組み合わせを含んでいる場合は原因-結果グラフの作成からはじめる
  2. どんな場合でも限界値分析を行う。これは入力及び出力限界の分析である。しかし、これらの大部分は原因-結果テストに統合されうる
  3. 入力と出力の有効と無効の同値クラスを見分け、もし必要なら見分けたテストケースを補足する
  4. さらにテストケースを得る為にエラー推測を行う
  5. テストケースのセットを考慮にいれながら、プログラムの論理を調べる。判定条件網羅、条件網羅、判定条件・条件網羅、複数条件網羅基準のうちどれかを使う。この基準が十分満たされるだけのテストケースをつくる。
となっています。 しかし、繰り返し、全てのエラーがみつかることは保証されないということ、プログラムテストは簡単なものではんく厳しい仕事であること。ということを説いています。    

第五章:モジュール(単体)テスト

  ここまではプログラム大きさを考えずに勉強してきましたが、大きなプログラムについてはテスト過程を構造化する必要があります。 その最初の段階としてモジュールテストを考えてみます。 まずモジュールテストとは一つのプログラムのサブプログラム・サブルーチンのテスト過程を言うものです。つまり全体をいきなりテストするのではなく小さい構成をテストしていくことです。 モジュールテストの過程を三つにわけて書いてあります
  1. テストケースを設計する方法
  2. モジュールをテストして統合すべき順序
  3. このテストを行ううえでの実際的助言
1.2.をまとめると  

テストケースを設計する方法

一言で言えばホワイトボックステストであり、そして、その設計は、あるモジュールの仕様とは関係のないエラーを発見する為であるから。とあります。ホワイトボックステストは仕様とは関係のないエラーを発見するのに適しています。 ホワイトボックステストが終了したら補足的にブラックボックステストを行います。  

モジュールをテストして統合すべき順序

これは非常に重要なもので、費用などにも関わってくるものです。 さて、実際統合の順序とはどうするのでしょうか。 各モジュールを別々にテストしてからそのモジュールを結合していくのか、またはテストすべきモジュールをテストが終わったものと統合してからテストすべきなのか。前者を非増加テスト。後者を増加テストと呼ぶが、一般的に増加テストのほうがエラーを見つけることが出来るが、最終的に作業量が少なくなる。 どちらも一長一短があるが、近年の動向では増加テストの方が優れているとされている。    

第六章:上級テスト

  この章ではモジュールテストが終了した後、本格的なテスト過程について述べている。 そしてここで一つの定義を挙げている。 「ソフトウェアのエラーは、プログラムを使うユーザが当然のこととして期待していることを実行しない場合にあらわれる。」   つまりモジュールテストだけでは不完全であるからさらにテストが必要です。ということです。 そしてこれを上級テストと呼んでいます。   この上級テストをはじめる前にソフトウェア生産の開発サイクルについて書いてあり、その段階ごとにエラーを発見していくことが大切であると書いてあります。 そしてその理由として、一つの段階が終わった後次の段階では、前の段階のエラーと比較しながらテストをするという方法を取れるからであるとあります。 そしてそれぞれ適した方法のテストをすることが大切であるというものです。
  • 機能テスト
  • システムテスト
    • 機能部分テスト
    • 大容量テスト
    • ストレステスト
    • 有用度テスト
    • 秘密保護テスト
    • 効率テスト
    • 記憶域テスト
    • 構成テスト
    • 互換性テスト
    • 設置テスト
    • 信頼性テスト
    • 回復テスト
    • サービス性テスト
    • 文章テスト
    • 手続きテスト
  • 認可テスト
  • 導入テスト
  • モジュールテスト
  • 統合テスト
これらを目的、終了基準、スケジュール、責任、道具、コンピュータの使用時間、ハードウェア構成、統合、追跡手続き、デバック手続き、復帰テストを考え計画をたてることが重要です。   もう一つ重要なことがテストの完了基準です。いつ終わりにするのか。ということです。前述したように全てのエラーを発見することは不可能だと言えますが、それだといつ終わりにするのかが問題になります。 ここでは 予定したテスト期間をがすぎた時に停止する すべてのテストケースを実行しエラーが発見出来ないとき停止する と書いてあります。 ただし前者の場合は無益であり、後者をすすめています。    

第七章:デバッグ

つぎにデバッグ作業です。これはテストケースに成功したあとの仕事です。 つまりプログラムに不具合が見つかった場合です。 そしてそれを修正することのことです。 まず述べているのは「力づくのデバッグ」は推奨しないということです。これは全てがうまくいかない時などに用いる物で、まず行うべきではないと述べています。 では何を行うのか。というところで 「帰納法によるデバッグ」
  • 適切なデータを見つける
  • データを組織化する
  • 仮説をたてる
  • 仮説を証明する
という方法が提案されています。次に 「推定によるデバッグ」
  • 可能な原因や仮説を列挙する
  • データを使って可能な原因を消去する
  • 残っている仮説を改善する
  • 残った仮説を証明する。
という方法。推理に近い考え方です。更に 「逆戻りデバッグ」 「テストによるデバッグ」 と挙げられています。 またデバッグの原則として心理的なものが挙げられています。   更に重要なこととしてエラー分析というものが挙げられています。 デバッグではエラーを取り除くだけでなく、分析することこそ有用である。というのです。 つまり「なぜこのようなエラーが起こったのか考えることで理解を深める」ということです。    

第八章エクストリーム・テスト

  エクストリームテストとはエクストリームプログラミングを利用して行われるテストであり、開発初期の段階の設計よりもコーディングとテストを重視したもので、各工程を常にフィードバックし、修正、再設計していくことを重視している物です。 具体的に 「エクストリーム単体テスト」モジュールが出来上がる前にテストケースを作る。 「受け入れテスト」設計・計画段階で作成する があり、これがエクストリームテストの概念となっています。 この方法は高速なアプリケーションの開発を支援することができます。    

WEBアプリケーションのテスト

  ここではWEBでのアプリケーションの重要性と手法を述べています。 WEBアプリケーションはパッケージアプリケーションに対し、並以上の品質を絶えず必要としており、その品質以下となるとすぐに顧客が流れてしまうという性質があるゆえにその品質の為にもテストの重要性が高いことが言えます。 そしてその基礎的な部分としてEC(電子商取引)の構造から説明されています。 主に図で説明されており構造は省略するが、問題の一つ目として、その構造の多くはWEBブラウザを介しておこなわれ、ブラウザの違いによる互換性の問題がある。というところが問題です。 問題の二つ目として、サーバの問題、三つ目としてデータベースの問題(データ層)についてとあります。   それらを考えテストの課題として、
  • 多種多様なユーザベース
  • ビジネス環境
  • 場所
  • テスト環境
  • セキュリティ
というものが挙げられています。   そしてそれらを解決する戦略として
  • プレゼンテーション層テスト
    • コンテンツ・テスト
      • 全体の美的感覚、フォント、色、綴り、コンテンツの正確さ
    • WEBサイト構造
      • 壊れたリンクか、表示
    • ユーザ環境
      • ブラウザ版とオペレーティングシステムの構成
  • ビジネス層テスト
    • パフォーマンス
      • 仕様をみたすかどうか
    • データの有効性
      • 顧客から集めたデータでのエラーを感知する
    • トランザクション
      • トランザクション処理でのエラー
  • データ層テスト
    • 応答時間
    • データ整合性
    • 無停止と復元性
を考えることが必要とされており、それぞれを行う際の考え方が述べられています。     これで全ての章となりますが、全体的に具体的なテスト方法というより考え方を述べている章が多いものでした。 使用した本はソフトウェアテストの元祖的な本なので時代にとらわれない方法を書いた故なのでしょう。   必要に応じて迷ったときなどに読むのが良さそうです。   使用した本はこちら     補足: この本は英語が原本なうえに翻訳者が技術者のせいか、翻訳が甘いところがあります。というか直訳ってかんじで日本語として破綻しているところがあります。 しかしながら、言いたいことは原則的なところであったり大切なことが多いので、都度その大切なところを読むことを重視して読みました。 それゆえにまとめに甘いところもあるかもしれませんが、自分がそれぞれの章で得た知識の要点をまとめたつもりです。   もし具体的なソフトウェアテストの技法を学ぶ場合は他の本がいいかなと思います。
iOS Simulator Screen Shot 2015.02.12 10.18.46

iOS基本動作その1@よしとき

こんにちは!よしときです。 水曜日が祭日なことをぎりぎりまで忘れていて予定が狂っちゃいました。カレンダーの確認は大事ですね。   さて、本日は前回からの続きで基本動作として標準のUI部品、アニメーション、ビューについて勉強しました。 まだまだ基礎から抜け出せてませんが、少しずつしっかり覚えていきたいと思います。   まず行いましたのはデートピッカーというもので、本日の日付の取得や、デートピッカー(日付がでるスクロール?)からの日付の取得。取得した日付からの日数計算なんかを行いました。 iOS Simulator Screen Shot 2015.02.12 10.18.46 これどんなときに使うかなーと思ってたのですが、ToDoアプリとか作る時に使いそうですね! 作り方は前回同様ほとんどマウスで出来てしまう感じ。こういうGUIはさすがマックと言った感じですねー   次はアニメーションの勉強をしました。 タップしたりと何かの条件でプロパティの値を何秒で変化させて〜みたいなのを書いていくもので、これはどこがなんの意味なのかをメモっていかないとはちゃめちゃになりそうでしたw やったのは
  • タップするとフェードインアウト
  • 上下に動きながらフェードインアウト
  • タイマーを使ってアニメーションを呼び出す
  • 複数のアニメーションを同時再生できるキーフレームアニメーション
  • イメージビューのタップとコマ送り
  • タップした位置に動く
  • ドラッグした位置に動く
というもの! いくつか画像を、といっても静止画だと分かりづらいのでコマ送りだけGIFにしました iOS Simulator Screen Shot 2015.02.12 10.29.15 画像のフェードインアウト!ボタンを押すとフェードイン・アウトします iOS Simulator Screen Shot 2015.02.12 13.14.33 タイマーを使ってアニメーション! 日時が右から登場して3秒待機して左に消えていきます!   これ、すごく苦労しました。。 何が苦労したかというと、初期位置の設定が起動するとリセットされてしまうらしくうまく動いてくれません。 これをうまく動かすのにかなり時間が・・・ 結局判明したのは、Xcode上でAutoLayoutというのにチェックが入っていると初期位置とかを勝手にずらしちゃうんですね!今回は初期位置が画面外だったのせいか誤作動が起きてしまいました。 そのチェックを外せばうまく動きました。 本に書いてあるのはXcode5なのでちょっとちがったのでしょうねー、、まぁ動いたのでよしとします! このエラーはしっかり覚えておこうと思います!   あとはコマ送りのGIF動画 frog おーかわいい。これは配列にいれたアニメーションが指定した秒数で自動でコマ送りになってるんです。さりげなくすごいことですよね。自動ですよ自動!w いやー便利w     お次にビューについて勉強しました。 今まではストーリーボードにオブジェクトをマウスでドラッグして視覚的に作っていた訳ですが、今回はほぼ手打ちで行いました。 もちろん上記の方法でもできるのですが、実際書いた方がやっぱり流れとかが理解しやすいきがします。 ということでやったのが
  • プログラムで絵を追加する
  • 絵を整列させて配置する
  • プログラムでラベルを追加する
  • 長押ししている位置に画像を追加する
  • サブビューを持ったビューを作る。
というもの。 どれもオブジェクトボックスからさくっとドラッグしてきて張っちゃったりすれば出来そうなものですが、ここでは全部手打ち!   まずは絵を表示させるのですが、いままでは画像をイメージボックス(?右下の画像ボックス)からドラッグしてビュー画面に張りつけて表示させいていたのですが、今回は手打ちしていきました。 手順としては
  1. イメージビューというイメージ用の箱みたいなものを用意
  2. イメージを読み込み
  3. イメージビューに読み込んだイメージを設定(セットする)
  4. イメージを設定したイメージビューをビュー(画面)に追加
という感じ。 ただ貼付けるだけじゃなく箱を用意してそこにいれてから追加するんです!! つぎにそれらをfor分で整列させて配置するということをやりました。まーこれは今まで通りなのでいうことなし! iOS Simulator Screen Shot 2015.02.12 14.13.30 こんな感じです。 次はプログラムでラベルを追加というもの。これも上記同様GUIで出来るのですが、手打ち! とはいえサクッと書くだけなのでなんとも。。w 乱数とfor文で色かえとサイズを変えました iOS Simulator Screen Shot 2015.02.12 14.24.01   つぎは新しいことです! 長押ししたところに画像を配置するというもの これは楽しい! 座標を取得してそこに画像をはりつけるって動きなんですが自分の中では結構難しかったです。 iOS Simulator Screen Shot 2015.02.12 14.52.42   最後にサブビューをもったビューを作る ということで、ビューの中にサブビューを追加してからそれを追加するというもの iOS Simulator Screen Shot 2015.02.12 15.05.46 画像を見ていただければ分かると思いますが オレンジ色のビューを作り、その中に写真を設定したイメージビューとラベル(文字)をサブビューとして追加して、それらをひとまとめに画面に設置しています。 こういうふうに組み合わせることもできるんですねー   以上!今回はここまでです。 サクサクいくところはいくのですが、たまにエラーが起きるとXcode自体とかを調べるのでかなり歩みが遅くなってしまいますね。。ただその分得られる物がおおいと思いますのでこれからも頑張っていこうと思います!!!   仕様参考書はこちら  

備忘録 〜ソフトウェアテスト〜

こんばんは、うさです。 本日は、「ソフトウェアテスト」について備忘録として 一冊の書籍から重要なことを書いていく。 今回参考にさせて頂いた書籍はこちら!!

第1章はじめに

第1章ではソフトウェアテストをするうえでの心得が書かれており、 ソフトウェアの「バグを全部見つけるのは無理だと心得ろ」と『Cem kaner』という方は言っている。 それは今完全なテスト手法がないからである。 では、テストエンジニアは何を心得てテストを行っていくべきなのか!! それは 「どの部分にバグが出やすいか、 そこにどのようなテスト手法を用いれば 十分な品質が得られるか」 を考えてやっていくことである。 なぜなら、バグの47%はプログラムの4%の部分に偏在しているという例もあるくらいに バグは一カ所に固まっているからである。

第2章ソフトウェアの基本

第2章ではホワイトボックステストについて書かれている。 業務では殆ど使う事はなくなったそうですが、 知っておくべきではある。 ホワイトボックステストとは 一言で言うと、 「プログラムの論理構造がを解析するテスト」である。 では、どんなことをするのかというと、 制御パステスト法を用いる。 これはカバレッジ率の値を取る為に用います。 カバレッジ率とは、ステートメントカバレッジ・ブランチカバレッジ・コンディションカバレッジの3つをどれだけ網羅出来たかを表す値である。
    • ステートメントカバレッジ:コード内の命令文を少なくとも一回実行する事 例を挙げると con1 = 0 とcon2 = 2 でそれぞれ一回命令文を実行します。 これがステートメントカバレッジである。
 
    • ブランチカバレッジ:ステートメントカバレッジでは対処できなかったもう一方の分岐も行う事
 
  • コンディションカバレッジ:書籍には説明が出てきませんでしたが、 コード内の条件式について「true/false」それぞれ一回ずつ出力させる事
ここまでだいぶ用語の説明になってしまいましたが、 ホワイトボックステストを用いてどうすればよいのか。 上記のカバレッジ率を上げる為にコード内の条件を一つ一つ確認していきます。 しかし、量は膨大であるため、カバレッジ率には基準が存在し、 一般商用ソフトウェアでは60〜90%あればよい。 しかし、そこの数値はソフトウェアの利用目的に大きく関わってくるため一概には言えないよう。 そして、意識しなければならないのは、
  • カバレッジテストはテストを行うのに時間がかかる
  • ソフトウェアの仕様が間違っていてもバグは発見できない
といったことです。 時間がかかると書きましたが、 テスト用フレームワークを用いて単体テストのコード書いてテストすることで飛躍的に時間は短縮されカバレッジ率も上がる。

第3章エンジニアが最も使う手法

ということで、続いてはブラックボックステストについて。 ソフトウェアテストの約8割がブラックボックステストを行う会社もあるので重要なテストである。 ソフトウェアとはデータを『入力・出力・計算・保存』という仕事で成り立っている。 まずは、その中の「入力・出力」についてのテストを見ていく
  • 同値分割法:入力領域を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす作業
  • 境界値分析法;同値分割で得た同値クラスの境目の値のバグを見つける作業 境界値分析法でのバグは4つに分けられる
    1. 「>」と「>=」の間違い
    2. 数字の書き間違い
    3. 境界がない(elseの書き忘れ等)
    4. 余分な境界
    これらのバグを発見するにはOn-Offポイント法を用いる これは異なる処理が行われる最も近い二点を選択してテストすること
  • ディシジョンテーブルテスト:表に、状態・状態の組み合わせ・アクションを書き、 この表の通りに「状態」をテストし、期待通りの「アクション」を起こすかを確認する作業
  • 状態遷移テスト:ある状態からイベント処理(入力が多い)を行い期待通りの遷移が行われるを確認する作業 このテストで、
      1. 期待通りでない状態に遷移
      2. 遷移自体を行わない
    という二つが検出される。
では、これらのテスト手法をどのように使っていくのか!! 例として、 もし、ダイアログボックスが一つだけあれば境界値テスト 複数のダイアログボックスがあればディシジョンテーブルテスト ダイアログボックスの遷移があれば状態遷移テストを行う これらを行いまだバグが見つかるようなら以下の理由が考えられる
  • ブラックボックステストのアプローチの仕方が間違っている
  • ホワイトボックステストでしか見つからないバグが存在した

第4章探索的テスト

探索的テストとは、ソフトウェア機能を学習しながらテスト設計とテスト実行を同時に行う事 どういんことか。 テストケースを書いて実際にテストを行ってバグが見つかるのは50%以下。 ならば、テストケースを書くのではなくてソフトウェアをテストしながら考えて実行してしまうということ。 どのように探索的テストを行っていくのか!!
  1. ターゲットソフトウェアを決める
  2. 機能をリストアップ
  3. バグが見つかりそうなエリアを見つける
  4. 各機能のテスト及びバグの記録
  5. 継続的にテストの実行
といった具合に行ってバグを見つけていく。 探索的テストの網羅率はプログラムの構造を理解していることによって、 テストケースベースののテストコード網羅率を上回る。 つまり、プログラミングエンジニアはこのテストを行う方がよいということである。

第5章非機能要求のテスト

今まで書いてきたテストは全て機能要求に対するテストのアプローチであり、 この章では非機能要求のテストを説明する。 非機能要求では品質特性の向上を図る。 まずは、期待通りの性能を引き出す為に、 パフォーマンステストについて行う。 パフォーマンステストとはソフトウェア設計・企画時の段階で設定された性能が期待通り出ているかをチェックするもので、 平均的なWebアプリケーションでは72%しか出ないといった結果となっている。 設計時のパフォーマンスの定義の例として、 要求:20Mバイトのデータを10秒で処理したい 結果:21Mバイトになったとたん30秒かかる(バグ)    1Mバイトに10秒かかる(バグ) といった具合に定量的に明確化して定義する。 パフォーマンステストは次の手順で行う。
  1. アーキテクチャバリデーション:机上でのチェック
  2. パフォーマンスベンチマーク:パフォーマンステストが出来る状態のソフトウェアが出来た時点でテストを行う
  3. パフォーマンス回帰テスト:プログラム開発途上で変更時に行う
  4. パフォーマンスチューニング、アクセプタンステスト:最終製品が要求定義に定められたパフォーマンスを出しているかのチェック
  5. 24×7パフォーマンスモニター:ERPアプリの際、顧客の使用するデータに近いダミーデータでのテスト

第6章ソフトウェアテスト運用の基本

テストを行う際重要になってくるのが、どれだけの時間を割くのかということである。 そして、テストに割く時間は開発のスピードによって左右されるという事。 そうなった場合の選択肢は以下の3通り
  • ソフトウェアの品質を下げる
  • 出荷を遅らせる
  • 機能を削る
もちろん、このような事態にならないように開発での期限は守らなければならないが、 対応策は考えなくてはならない。

第7章ソフトウェアテスト品質管理の基本

品質は目に見えないものである。 しかし、何らかの形に数値として表さなくてはならない。 それは「バグの数」である。 バグの数を数値化してグラフに表すと スクリーンショット 2015-02-12 2.21.01 こういった形でバグの数は徐々に減っていく。 また、重要度の高いバグもどんどん減っていく。 しかし、GUIアプリケーションではオンラインヘルプの文章や文字が欠けているといったUIの問題が継続的に出てくる場合もある。 もちろん、バグの数が減っていくとバグ修正にかかる時間も減っていく事になる。 もし、後の方でバグが見つかると致命的な場合がある。 例えば、設計上からくるバグは一個のバグ修正の為に何カ所もコードを変えなければならなくなる。 最後に、この書籍から学んだ事は、 バグは完全になくなりはしないという事。 重要の高いバグは徹底的に修正をして、 後は市場に出した後に少しずつ修正していく。 テストの種類は色々あり最初はどれを使えばいいのかわからなかったり、 どの程度までテストを行えばいいのかわからないと思われる。 ある程度コードを書いたら探索的テストやブラックボックステストを行うといった方法を使っていけばよいのかなと感じた。 テストの自動化もあるそうだが、それはテストに慣れてきてからだろう。 一番大切な事は、いかに完璧に近い設計書を書けるかだと感じた。 プログラミングでも同じ事が言えるが、 ソフトウェア完成間近で設計ミスによる変更等は時間(コスト)の大幅なロスである。 のちのち設計の仕方についても勉強をしていきたい。 以上、ソフトウェアテストについての備忘録??でした。

iOS 画像でスライドパズル

こんにちは、うさです。 本日からiOSの勉強を新しい参考書で行っていきました。 前回使っていた参考書が基本的なUI部品等の使い方だったのに対し、 本日から使いだした参考書はいきなり、画像を使ってのスライドパズルのアプリを作らされて 何を行っているのか理解する事が難しいです。 それでは、そのアプリのコードを載せます。 コメントを含めて書いていきましたが やっぱり難しい。 とりあえず、書いて見返してまた書くの繰り返しを行っていきます。 また、iOS8とiOS7ではだいぶライブラリが変更になっており、 iOS8では使えないものがたくさんあるので、 その辺も調べて、iOS8でも同じように表示できるようにしていきます。 因に今回利用させていただいた参考書はこちらです。 以上うさでした。
colorChange

iOSはじめました!@よしとき

こんにちは!お久しぶりです。よしときです!
最近はもっぱら卒業研究に追われて追われて追われて…..
  気を取り直して!本日よりようやくiOSのアプリの勉強をはじめることが出来ました。 使用するのはXcode6.1で言語はObjective-Cでやっていこうと思います。   最近Swiftが出てそっちでもよかったのですが、ライブラリが出来上がっていること、未だ全体的に使用されているのがObjective-Cの方が多いことからObjective-Cを勉強していくことにしました。 まずはAppStoreでインストールをしまして、HelloWorldがてらちょこちょこっと初期設定をしました。とはいえシミュレータを日本語にしたり程度ですがw   そして本格的にXcodeを触る訳ですが。。すごいですねー、、UIが充実しすぎてプログラミングって感じがしないです。マウスにこんなに長く触っていたのは久しぶりw   しかし逆に今までずっとソースみて動きを確認したりもしたので一目でソースで見れないのは違和感があります。 更に触ったことの無いC言語の流れのObjective-C。。いやー慣れないです。   なのでいつも通り分からないながらも進めていこうかなというところ! とにかくやってみるのです!!!     そしてまー最初は文字を表示させたり数字を表示させたりしてXcode自体に慣れていく作業をしました。 UIの章からは実際にちょっとしたツールを色々使ってみるというもの。ようやくコードを書く時がきましたw   最初は「スイッチで写真を表示/非表示」ってのをやりまして、boolean型の使い方なんかを同時に学ぶと 次に「スイッチで色を切り替える」というのを。これはif文の練習ですね。あとJavaで自インスタンスをthisとしてましたがObjective-Cではselfってなるんですよーっていうのを少し。この辺の方言というか、違いで間違えそう。。   次に「セグメントコントロールで3色を切り替える」ってのをやりました。 これは画像をとりましたよー!しかもGIFにしてみましたw colorChange こんな感じです! コードよりGIFに時間かかってしまいました^^;   こちらはSwitch文の練習も兼ねているんですが、switchはJavaと変わらずなので良かったです!   次は「スライダーで透明度を変更」 これもGIF!しかもかわいい!w ninjaAlfa こういうかんじでスライダーを調整すると透明度が変わるのです。透明度ってAlphaって言うんですねー知らなかったー こちらでは文法というより引数で設定しているsenderの使い方を学ぶって感じでした。引数と戻り値の書き方が一番厄介な気がします。   そして最後に「ステッパーでカウントアップ」というのをやりました。 iOS Simulator Screen Shot 2015.02.09 16.33.07 +をおすとどんどん数字が増えるだけのものです。 これも上記同様sender引数を使っているもの。うーーーーーんちょっとまだ慣れないけど慣れるまで書きます!!!   今日はあまり進みませんでしたが、次からがんがん進めていきたいと思います!!     使用参考書はこちら