100日後にエンジニアになるキミ - 48日目 - テスト - テストについて

昨日までのはこちら

100日後にエンジニアになるキミ - 42日目 - クラウド - クラウドサービスについて

100日後にエンジニアになるキミ - 36日目 - データベース - データベースについて

100日後にエンジニアになるキミ - 24日目 - Python - Python言語の基礎1

100日後にエンジニアになるキミ - 18日目 - Javascript - JavaScriptの基礎1

100日後にエンジニアになるキミ - 14日目 - CSS - CSSの基礎1

100日後にエンジニアになるキミ - 6日目 - HTML - HTMLの基礎1

テスト(試験)とは

ソフトウェア開発におけるテスト(試験)とは仕様にない振舞またはバグを見つけ出す作業のことで
ソフトウェアが正しく動作するのかを確認する事になります。

テストは目的や手法などによりいくつかの段階に分かれます。

手法によるテスト

テストの仕方による区分のものです。

動的テストと静的テスト

動的テスト : プログラムを実際に動かして行うテスト
静的テスト : プログラムを実際に動かさずソースやオブジェクトコードを検証する作業

どちらも人手やツールを使っておこなう。

機能試験と性能試験

機能試験は規定した機能を果たすかどうかを試す試験で
関数であれば、規定した引数を与えると、想定した戻り値を返すかどうかといったブラックボックス試験が
機能試験に相当し、単体試験の一部となる。

性能試験はソフトウェアシステムの性能を測り、必要な性能が出ることを確かめる試験。

性能試験は書き込み性能や通信速度、処理件数などプログラム単体では見つける事ができず
ミドルウェアやデータベースを交えた段階で行う事が多い。

過負荷に対する性能試験をストレステストともいう。

ストレステスト
ソフトウェアシステムに対して高い負荷を与え、処理の低下・抜け、データの破壊、発熱など
致命的な問題が、どういう条件で発生するかを試験する。ストレステストを行うことである。

高い負荷が加わっている状況でしか発生しない不具合や、発生確率の低い欠陥、
著しい性能の低下を発見することがある。性能試験の一部として実施する。

ホワイトボックステストとブラックボックステスト

プログラムの内部構造に注目したテストをホワイトボックステスト (white box test)
プログラムの入力と出力に注目したテストをブラックボックステスト (black box test) と呼ぶ。

ホワイトボックステスト (white box test)
内部の条件分岐、判定条件などをすべてチェックする。
網羅率によりテスト状況をチェックする事がある。

ブラックボックステスト (black box test)
様々な入力値を適宜入力し、限界値付近のチェックなどを徹底して行う。

開発段階におけるテスト

開発の段階におけるテストの区分で、開発では以下のような段階でテストを行う事が多い。

1.単体試験 (unit test)
2.結合試験 (integration test)
3.システムテスト (system test)
4.受入試験 (acceptance test)

段階とは別にアルファテスト、ベータテストというものもある。

単体試験

関数、メソッドなどの小さな単位で行うテスト
通常はテストコードを書き、そこから関数などを呼び出して入出力が妥当かどうかを判定する。

Java言語ではJUnitなどのテストツールを導入して行う事が多い。

結合試験

単体テストが終わったプログラムを組み合わせて行う試験

システムテスト

プログラム単体でなく、ミドルウェアやハードウェア、通信ネットワーク、データベースなどと
組み合わせて行う試験。

本番稼働用の環境ではテストは難しく
テスト用の環境(サーバー等)を用意して実際に稼働するよう構築してからテストを行う。

本番環境とは環境構成が違っている事もあり、シミュレーターなどを用いて
模擬試験を行う事もある。

受入試験

検収テスト、承認テストとも呼ばれ、顧客などがシステムを受け入れるかどうかを判定する試験。
システムの実際の利用者が行う場合と受け入れ試験をシステム運用・保守会社が実施する場合がある。

アルファテストとベータテスト

完成前のソフトウェアを開発者以外に利用してもらいバグを発見してもらうテストのこと。

アルファテストはベータテストよりも完成度の低い段階（アルファ版）で行うテストで
アルファテストは内部でベータテストは外部でという区分をすることがある。

ベータ版は基本的な性能は製品版とは変わらないものの、未完成品であるため
バグが存在している事を利用者に注意喚起しなければならない。

回帰試験

プログラムを修正・変更した場合に、過去に実施したテストを再度実施することを
回帰試験または退行テストという

実施する回数も多く省略することがないようにテストを自動化して効率化する事がほとんど。

再現試験

事故が起きた際に手順に従って現象・実験結果を確認する事である。

同様事象でユーザー報告が多く寄せられた場合はバグが存在する事が疑われるため
手順から再現を試みる。

セキュリティーテスト

システム脆弱性を見つけるためのテスト
WEBアプリなどは外部ネットワークに晒されているためにかなり重点的に行う必要がある。

セキュリティー診断をすべて行うことは難しく
専門業者に依頼してセキュリティーのチェックを行う事がよくある。
ただし、値段は高め。

主なセキュリティーテストの観点

以下のような観点で攻撃されないかどうかをチェックする。

クロスサイトスクリプティング XSS(Cross Site Scripting)
アプリケーションの表示上のバグを悪用して、利用者のブラウザー上で任意のJavaScriptを実行する。

クロスサイトリクエストフォージェリ CSRF(Cross Site Request Forgery)

リクエスト強要の事でWebアプリケーションのサーバー側機能を
利用者の意図に反して勝手に実行させる。

SQLインジェクション
アプリケーションが想定しないSQL文を実行させることによりデータベースシステムを不正に操作する攻撃方法。
正規の認証なくデータベースにアクセスすることが可能になる。

ディレクトリ・トラバーサル
../のような文字列を使ってWebサーバーのディレクトリ・パスを横断して
公開されていないディレクトリにアクセスする手法。

OSコマンド・インジェクション
ディレクトリ・トラバーサルの手法を用いてOSコマンドがあるディレクトリにアクセスしOSコマンドを実行する手法。

認証チェック
ログインする際の認証方法に問題がないかどうかをチェックする。
外部サイトデータを用いた認証などで勝手に認証できてしまう問題もある。

総当たり攻撃
同じIDに対してパスワード候補を総当たりでぶつけて突破しようとする手法。
ログインの認証などが何度も行える状態だと、総当たり攻撃により認証突破される可能性があります。

hiddenフィールドの不正操作
アプリケーションロジックで用いられている値が表示画面に組まれていると改竄できてしまう。
商品の価格などをHiddenで受渡ししている場合に価格を任意に変更されてしまうなどの可能性がある。

パラメータ改ざん
HTTPリクエストのパラメータ値で操作できてしまうような構造の場合
データの改ざんや削除など大きな被害を被るケースがあります。

データ改ざん
アプリケーションで用いられているデータベースがアクセス可能だとデータ改竄できてしまう。

バッファ・オーバフロー
アプリケーションの予期しないデータを送り、アプリケーションを異常終了させる手法。
ウェブサーバのサービスを停止させられたり、ウェブサーバを乗っ取られる危険性があります。

不適切なコメント記載
HTMLやJSファイルのコメントの消し忘れにより情報漏洩や外部侵入のきっかけを与えてしまいます。

セッション推測
セッション情報の推測による商人やアクセス権限の奪取。
セッション情報が推測しやすい値の場合、管理者やユーザに成りすますことができてしまいます。

まとめ

個人で開発をしているとあまりテストに気が回らないかもしれませんが
ソフトウェアの品質を上げるにはテストは重要です。

ここをきっちりやれるかどうかで最終的な品質が変わってきます。

特にWEB系のアプリケーションにバグがあると
データが消えたりユーザーの使い勝手が悪くなったりして
ユーザー離れにつながってしまうので、常にテストには気を配りましょう。

君がエンジニアになるまであと52日

作者の情報

乙pyのHP：
http://www.otupy.net/

Youtube：
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMw

Twitter：
https://twitter.com/otupython