プライベートリポジトリで外部の無料CIツールを使う

Jenkins 好きなのでずっと使ってきましたが Jenkins 離れの空気を感じたので取り急ぎ調査。 基本は非公開、無料で探します。 大体有料(少額) or 公開必須ですが magnum-ci という無料でプライベートリポジトリのCIができるサービスを発見。 Magnum CI

プロジェクトの登録

  1. ログイン後ページのDashboard の右上「Add a New Project」

  2. 色々入力して「Create Project」

  • 雑な説明ですが見ればわかる簡単な画面です。

  • Project type では Ruby, Node.js, Go, PHP, Clojure, あと Generic と、あれな言語ばかりです。

  • Java は未対応の空気あり。

  • 今の自分のブームは Node なのでとりあえず問題なし。

  1. web hook, deploy key, build 設定を言われたとおりにします。わかりやすい。
  • 一応細かく書いておくと、 web hook を bitbucket の リポジトリ設定ページの Webhooks で 「Add webhook」で追加

  • deploy key を bitbucket のリポジトリ設定ページの Development keys で「Add key」で追加

  • それぞれの title, label は任意です。 magnum-ci のだとわかればいいので「magnum-ci」などにしておいたらいいと思います。

  1. 「Test build」でビルド成功したらとりあえず枠は完成。あとはプロジェクトのテストやビルドのコマンドを登録して完成です。

雑感

  • 今までのプロジェクトは Java やら Scala やらなので Jenkins も運用することになりそう。

  • とはいえ Jenkins 落ちてるとか他のビルドに引っ張られてるとか、自前ならではの苦しみはあったので Node 系はそれからは解放されそう。

  • コレ系のツールの設定、どんどんわかりやすく、開発者に優しくなっていてありがたい。

  • とりあえず、Free & Private で使わせてくれるところがあってよかった。

Markdown を Ubuntu の vim で書いて Chrome で確認する

経緯

Mardown で書くときは Chrome の Extension Minimalist Markdown Editorで書いていましたが最近何でもvimにしようとしているので環境を整えました。 ちなみに、拡張機能のエディタはかなり使いやすかったので vim にこだわった以外の乗り換え理由はありません。

使っている環境、ツールなど

  • NeoBundle

  • Chrome

  • Ubuntu 12 LTS

 

作業したこと

Markdownのハイライト、プレビュー

こちらを参考にさせて頂きました。   シンプルでわかりやすくで、ほぼこの内容通りです。  

Chrome でプレビューしたい

普段使っているのが Chrome なので Firefox は入れていません。   しかもこれは Mac 用のコマンドかな。   Chrome で起動するように変更。
  • 変更前
 
  • 変更後
  ターミナルからブラウザを起動するときのコマンドが入ります。多分。   そのように変えれば Opera 等でも動くかと。  

vim-markdown をもう少しいいかんじぽい方に変更

fork 版が良さそうに見えたので書き換えました。   rcmdnk’s blog様ありがとうございます。  
  • 変更前
   
  • 変更後
   

折りたたまないように設定

普段から折りたたみが嫌いです。   Option で disable 。  
  • 追加
          :w での即時反映がほんとに便利です。  

Ubuntu 12 を再起動すると画面の明るさが最大になる

経緯

ハードウェアの開発をするにあたり、中古ノートパソコンに Ubuntu をのせて使っています。   毎日起動時に明るさが最大になっているので、暗くし忘れて気がついたら目が痛いという事が何度かありました。   今日も忘れて目が痛いので rc.local にバックライト設定のコマンドを書いてマシンの起動時に無理やり暗くします。  

環境

  • PC: Toshiba 中古

  • OS: Ubuntu 12 LTS

 

設定方法

  どんなバックライトがあるのか確認 今の眩しい状態の値を確認 明るさを変えてみてどちらが使われているか確認 名前からしてもそうですが intel_backlight が使われていました。   なので、rc.local に設定します。 再起動しても眩しくないはず。    

vim でarduino を使う

Arduino でガジェットを作っています。 IDE が使いにくかったので vim をもっと使いこなしたいついでに ino を導入しました。 ※バージョンアップで IDE も使いやすくなってきたと思います。   http://inotool.org/   インストールや使い方は既にわかりやすいサイトがたくさんあるので割愛します。   ディレクトリ構造が違うので ino で作ると本家の IDE は使いにくいです。 チーム開発の方はお気をつけ下さい。  

ino のために導入した Plugin

  https://github.com/sudar/vim-arduino-syntax   [code lang=HTML] NeoBundle ”sudar/vim-arduino-syntax” [/code]

Compile & Upload

コンパイルとアップロードは編集中の画面を閉じて [code lang=HTML] ino build ino upload [/code] でいいのですが、 IDE の Ctrl+U で保存 & コンパイル & アップロード してくれるのが便利だったのでプラグインを書いてみました。   [code lang=HTML] function! Inoupload() let buildmsg = system(’ino build’) echo buildmsg let uploadmsg = system(’ino upload’) echo uploadmsg endfunction nmap <silent><C-u> :call Inoupload()<CR> [/code] これだけなので慣れていると早いのでしょうが vim のスクリプト、プラグインは初なのでかなり時間かかりました。   これを .vimrc に追記でもいいと思います。 編集中に Ctrl + U で保存済みまでのところがコンパイル & アップロードされます。   かなり便利になりました。   下記少し不満ですがまたモチベーション出てきた時に。。。
  • 自動で保存して欲しい

  • アップロード後のメッセージが邪魔

  • コンパイルに失敗してもアップロードしている

 

インフラエンジニア・書籍学習まとめ

こんにちはよしときです。 本日はインフラについて勉強したことをまとめてみたいと思います。使用した教科書はこちら   それでは第一章から見ていきます。  

第一章 インフラエンジニアの仕事

まず、始めにインフラエンジニアとはどんな仕事か、というところから始まります。 インフラエンジニアの仕事は大きく分けて三つあり、
  • インフラ設計
  • インフラ構築
  • インフラ運用
に分けられます。 さらにITインフラを構成する要素として
  • ファシリティ
  • サーバ・ストレージ
  • ネットワーク
が挙げられます。 これらの用語に加え技術者、選定者としてのインフラエンジニアのするべきことを簡易的に挙げていきます。 まず、技術者としてのインフラエンジニアの側面として
  • サーバハードウェア
  • サーバOS
  • ストレージ
  • ネットワーク設計と構築
  • ネットワーク機器
を押さえておくべきだと挙げています。 次に 選定者としてのインフラエンジニアの側面として
  • システム構成
  • サーバスペック選定
  • ネットワーク構成
  • データベース設計
  • 運用体制
  • 社内での責任範囲
が挙げられています。 上記の内容としてはかるく触れる程度で、順次章ごとに説明していきます。  

第二章 サーバ

サーバの説明、構成になります。 まずサーバの種類としてラックマウント型とタワー型についての説明があります。 ラックマウント型は拡張が用意でサーバルームなどに常設される時に使用される物で、タワー型は店舗運営のような場所で使用される前提で作られます。 つぎにエントリ・ミドル・ハイエンドサーバについてです。 これらは名前の通り、区分となっており順次値段が高くなり、性能もあがります。 更にIAサーバ、エンタープライズサーバについて簡易的に説明があります。   それら説明の後サーバの選定を行う上でのポイントを挙げていきます。
  • サーバ要件
  • サーバスペックの決め方
    • 実際の環境を試験的に構築し、測定結果から判断する。
    • 仮決めしたサーバスペック機器を本番投入し、実際のハードウェアリソース利用状況を測定した上でサーバやサーバのパーツを増減していく。
    • 消去法でスペックを絞り込んでいく
  • スケールアップとスケールアウト
  • ベンダーを選ぶ
次に書く要件の説明と選ぶポイントとなります
  • CPU
    • パフォーマンスと発熱・消費電力
    • CPU用語
      • ソケット数
      • 動作周波数
      • コア
      • キャッシュ
      • ハイパースレッディング
      • ターボブーストテクノロジー
    • CPU選定のポイント
      • パフォーマンス
      • 価格対比
      • 使うソフトウェアのライセンス体系
  • メモリ
    • パフォーマンス
    • メモリ用語
      • スロット数
      • ECC(Error Correcting Code)memory
      • チャネル
      • ランク
      • UDIMM
      • RDIMM
      • LRDIMM
      • LV(低電力)
    • メモリ表記の見方
    • メモリの挿し方
    • メモリ選定のポイント
      • 搭載容量
      • パフォーマンス
      • 拡張性
  • ディスクの種類
    • SATAハードディスク
    • SASハードディスク
    • FC(Fibre Channel)ハードディスク
    • その他
      • 二アラインハードディスク
      • SSD(Solid State Drive)
      • エンタープライズフラッシュメモリストレージ
  • RAID
    • RAIDレベル
    • RAIDのパフォーマンス
    • RAID5 vs RAID10
    • RAID5 vs RAID6
  • 仮想化
    • 物理サーバと仮想サーバの特性
      • 物理サーバは使用容量が大きい用途に向いています
      • 仮想サーバは使用容量が小さい用途に向いています
    • 物理サーバを仮想化する場合のメリットとデメリット
      • メリット
        • コストダウンが可能
        • ゲストOSのハードウェアリソース増減を容易に行える
        • 他の新しい物理サーバに仮想化環境を用意し簡単に移行できる
      • デメリット
        • 他のゲストOSが大量のハードウェアリソースを使うと、他のゲストOSの動作が不安定になる。
        • 一度作られたゲストOSがその後に使われなくなっても撤去されずに残りがちになる。
    • 仮想化モデル
    • 仮想化環境の種類
      • VMware vSphere
      • Hyper-V(Windows Server 2012)
      • Xen
      • KVM
    • 仮想化環境の選び方
  • クラウド(IaaS)
    • IaaSの特徴
      • 自社で物理サーバを持たずに使えるため、物理サーバを管理するエンジニアが不要
      • 利用申請後、短期間でOSがインストールされた状態ですぐ使える
      • 自社で物理サーバを持たないため、物理的制約を意識せず利用したい分だけサーバ増強が可能
      • 使った分だけ費用が発生する従量課金制
      • 自社で資産を持たずに済むので、サーバを買うと発生する減価償却処理が不要で、かつクラウド利用費はそのまま費用処理が行える
    • クラウド環境でのインフラの利用
    • Amazon Web Services(AWS)
      • Amazon Elastic Compute Cloud(Amazon EC2)
      • Amazon Simple Storage Service(Amazon S3)
    • クラウドに向かない用途
      • 機密情報を置く
      • 大容量ファイルの転送
      • 大規模システム
    • クラウドベンダーの選び方
    • 会計処理から考えるクラウド
これら要点を選定するポイントとして挙げられています。具体的な型番が多く載せられており、より選定者の視点に立って書かれています。  

第三章 OS

第三章では利用されるOSについて説明されています。 まず第一にLinuxです Linuxのディストリビューションとその価格について説明されております。具体的にRedHat Enterprise Linuxの価格とOracle Linuxの価格が挙げられています。   次にWindows Serverです。 Windows Server選定理由としていくつか挙げられています
  • Windows Server上で稼働するソフトウェアを使いたい
  • .NET(ドットネット)基盤を使いたい
  • Active Directory環境を使いたい
さらにWindows Serverのライセンス体系について説明されています。   次にUNIXです。 代表的なUNIX OSとして
  • AIX
  • Solaris
  • HP-UX
が挙げられています。  

第四章 ネットワーク

ネットワーク機器について学び、選ぶ基準を説明していきます。こちらもポイントポイントを押さえていきます。 まずルータの役割が説明されています。ルータは一言で言うとネットワークを論理的に分ける機器となります。 そしてルータを選ぶポイントを5つ挙げています
  • ISPやデータセンターなど、ルータを接続する先から提供される上位回線のインタフェースと一致したWAN側インタフェースを持つこと
  • WAN側での通信帯域
  • スループット
  • セキュリティ機能をルータに求めるか
  • 導入コスト
となります。 次にL2/L3スイッチの役割について説明があり、選ぶポイントが4つ挙げられます。
  • インタフェースの速度とポート数
  • インテリジェントorノンインテリジェント
  • スイッチング能力とスイッチング容量
  • ハードウェア処理 vs ソフトウェア処理
となります。 更にL4/L7スイッチ(ロードバランサー)を選ぶということでロードバランサー(負荷分散機能)付きのL3スイッチのことで、選択肢の一つとして挙げられています。   次はネットワーク設計において良く採用されるパターンをいくつか紹介されています。
  • フロントエンド/バックエンド 2階層構造
  • コア/ディストリビューション/アクセス 3階層構造
  • ネットワークファブリック構造
の三つが挙げられています。   ここからネットワーク用語の解説があります。
  • TCP/IP(Transmission Control Protocol/Internet Protocol)
  • OSI参照モデル
  • TCPとUDP(User Datagram Protocol)
  • 3ウェイハンドシェイク/SYNとACK
  • スイッチングとルーティング
  • IPv4とIPv6
  • ネットワークインタフェースを束ねる
    • ボンディング
    • チーミング
    • リンクアグリゲーション
    • イーサチャンネル
    • ポートトランキング
これらの解説後、インターネットとの接続、ネットワークケーブルについて説明されています。 接続する料金体系はおおよそ二種類で
  • 固定帯域使い放題
  • 従量課金
となります。ネットワークケーブルは
  • LANケーブル
  • 光ファイバーケーブル
の二種類について説明されています  

第五章 ストレージ

ストレージにはサーバ内部のローカルストレージとサーバ外の外部ストレージがあり、外部ストレージにはサーバに直接接続するもの(DAS:Direct Attached Storage)とネットワーク経由で接続するもの(NAS:Network Attached Storage・SAN:Storage Area Network)があります。更にFC-SAN(Fibre Channel SAN),IP-SAN(Internet Protocol SAN)という種類があります。 次にRAIDとホットスペアについてです。ホットスペアとは他のディスクが壊れたときの為に待機しているスタンバイディスクのことです。その動きも解説されています。 次は外部ストレージの利用と題して導入する動機が4つ挙げられます。
  • 記憶領域を大きく取りたい
  • ディスクI/O性能の向上
  • ストレージの統合・集中管理
  • 複数サーバ間でのデータ共有
となります。 また、ストレージの高度な機能として
  • シンプロビジョニング(Thin Provisioning)
  • 自動階層化
  • デデュープ(De-duplication)
  • スナップショット
の説明と使いどころが挙げられています。    

第六章 購買と商談

この章では名前の通り、インフラ整備する上での購買と商談についてのポイントが書かれています。 まず、購買先の選定をし、来訪してもらう目的を考えておき、ベンダーを選定、そして相見積もりを出し、導入テストをするという流れを説明しています。そして、グローバル購買の検討もするように書かれています。 次に資産管理として大事なポイントが挙げられます。
  • 資産管理対象
  • 資産管理の方法
  • 在庫
  • 減価償却
  • 棚卸し
  • 機器の廃棄
について書かれています。  

第七章 データセンター

ネット上や書籍で情報の少ないデータセンターの選定方法などを紹介されています。 まずデータセンターの空調設備の種類をみていきます
  • 床下冷気方式
  • 排熱吸引方式
  • 外気空調方式
があります。そこを見つつ、データセンターの選定をしていきます。 データセンターを選ぶポイント
  • データセンターの立地
  • サーバ設置台数
  • ラックは持ち込みか、貸し出しか
  • 利用可能ボルト数
  • 重荷重機器への対応
  • 防災レベルUPS(無停電装置)や発電機の性能
  • 産廃処理
  • 搬入スペースや駐車場の有無
  • リモートハンドサービスの有無
  • ユーザルームの有無
  • ケージ(金網)の有無
  • ネットワーク回線のコネクティビティー
  • イレギュラーな要望に強い
  • 備品貸し出し柔軟性
  • 売店や宿泊施設の有無
  • 費用
が挙げられています。実際に使用してきた経験で書かれていて参考になります。   そしてデータセンターで行われることとしてラックに機器を取り付ける方法が載せられています。 次に自社サーバールームを使う為のポイントを挙げられています
  • 面積
  • 電力容量
  • 冷却
  • 耐荷重
  • 地震対策
  • 騒音対策
  • ホコリ対策
  • 法定点検対策
  • セキュリティ
  • 備品置き場
これらを考えてサーバルームを作ることが必要だと書かれています。  

第八章 ソリューションとセキュリティ

次に管理の方法としてソリューションの種類を挙げていきます。
  • 監視ソリューション
    • Nagios(ナギオス)
    • Zabbix(ザビックス)
    • Cacti(カクタイ)
  • 資産管理ツール
  • 配信システム
  • セキュリティ
  • ファシリティ管理システム
  • ストレージ管理システム
つぎにセキュリティ対策について書かれています。 セキュリティにはセキュリティ担当者とサーバ担当者の連携をしっかり行うこと、外部セキュリティ企業の活用、データのハッシュ化と暗号化が必要であると書かれています。  

第九章 インフラ運用

インフラ運用についてまず、障害対応についてかかれています。 ハードウェアは必ずいつか壊れるという考えのもとで障害対応を行っていくことが大事であるとあります。 次にボトルネックを解消するということで、システムのレスポンスを向上することはもちろん、計画的に行い、対策を行わなければハードウェアリソースが枯渇するような状況になってしまうため、重要だと書かれています。さらにネットワーク機器のボトルネックの解消、サーバ機器のボトルネックの解消について調べ方と対策が書かれています。 次に MSP(Managed Service Provider)業者の選び方として
  • 企業としての信頼性
  • コミュニケーション力
  • 柔軟性
  • 技術力
  • 費用対効果
が挙げられ、その具体的なコストが書かれています。 次にファームウェアについてです。 ファームウェアについて注意すべきこととして
  • ファームウェアのバージョンとレベル
  • ファームウェアのバージョンアップの要否を判断する
  • 最新ファームウェアの情報を収集する
  最後にハードウェアの保守として、あるといいサービスなどが書かれています。  

第十章 大規模インフラ

この章では大規模インフラの管理として必要なポイントを挙げていきます。 システム構成を決めるポイントとして
  • ベンダーサポートの必要性
  • 使用言語
  • アクセス量
  • 可用性
が挙げられ、さらに外部業者を活用する場面として
  • 納品機器の開梱とラックへのマウント
  • 配線
  • 機器のセットアップ
  • 障害対応サポート
  • サーバルームの清掃
  • インフラ運営システムの開発
  • ハードウェア故障時の自動対応
が挙げられます。 次にCDN(Contents Delivery Network)についてです。静的コンテンツの配信に使われます。 また、CDNを使うことで外部からの不正アクセスや攻撃を軽減する効果も期待されます。 CDNを提供している代表的な業者も挙げられています。 業者の選び方のポイントは
  • 品質
  • サービスは国内限定かそれとも世界を対象か
  • コスト
が挙げられています。   次にDSR(Direct Server Return)構成を用いた負荷分散について書かれています。 前述したロードバランサーで用いられる負荷分散手法の一つで、大規模WEBサイトなどで用いられます。 一般的な構成とDSR構成の違いを図で説明されており、DSR構成のメリットが三つ挙げられています
  1. リクエスト量に対するL4スイッチのキャパシティが増える
  2. ネットワーク構成が比較的自由になる
  3. 使用するポート数は1ポートのみ
となります。 そのなかで、DSR構成が一般的でない理由として、全てのサーバに対してループバックと呼ばれる仮想ネットワークインタフェース設定を行っていく必要があるので、設定項目が増えることに加えて、不慣れな人が多いということが挙げれています。   最後にリソース不足対策についてかかれます。 まずリソース不足の種類です
  • 人的リソース不足
  • データセンタースペース不足
  • 機器不足
  • ネットワーク帯域不足
  • 資金不足
があげられます。そして、LINEサービスを例に大規模インフラの具体案を説明されています。    

第十一章 インフラエンジニアの成長

最後の章ではインフラエンジニアはどうしていくべきかということが書かれています。 まずインフラエンジニアが身につけるべきこととして
  • ドキュメントを読み込み力を付ける
  • カタログを読み込む力を付ける
の二つが挙げられています。 さらに小規模インフラと大規模インフラで身につく経験の違いなどが挙げられます。 最後にインフラエンジニアの育成についてタイプ別に書かれており、好奇心が強い方、好奇心が弱い方の2つのタイプ別にどのような育成をおこなうとよいかが書かれています。   以上まとめとなります。 項目ごとに最低限の情報を分かりやすくかいてあるので、ハンドブックとしても活用できそうな本でした。

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 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自体とかを調べるのでかなり歩みが遅くなってしまいますね。。ただその分得られる物がおおいと思いますのでこれからも頑張っていこうと思います!!!   仕様参考書はこちら