0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

インターンから学ぶ「テスト」

Posted at

この記事の位置づけ

先日まで行っていたインターン中に触れた事項について復習しながらまとめる記事となっています。自分の感じたことを残しておくという意味で書いている側面もあるので、誤りも多々あると思いますがご容赦ください。これら気が向いたらご指摘いただけると幸いです。

この記事ではテストについて記述します。インターンで行ったのはウォーターフォール開発における結合テストのテスト設計となります。このため、テスト設計全般に適用される内容のものと結合テストのみに適合した話と混同されていることも多々あるかと思いますがご了承ください。

テスト設計とは

テストは記述したコードが仕様(あるいは設計書・処理記述書)通りに動作するかを確認する過程を指します。このテストでどのような場合を確認するかを記述するのがテスト設計となります。このため、テスト設計では入力の条件とその結果の出力(画面の状態)をペアにして複数の場合を列挙する形を指します。

テスト設計書の記述

(企業などによって記述のフォーマットなどは異なるかと思いますが、私が経験した内容を基に以下を記述します)
テスト設計書には以下の2つの内容を記載します。

  • データパターン
    テストで確認する項目(因子と言います)ごとにその項目がテストにおいて取りうる値(水準と言います)を表として列挙します。後述する分析方法によって項目の記述内容は変化します。
  • テストパターン
    各項目に対して、データパターンで記述した値を割り当て、その割り当てに対して期待する結果を記述します。

データパターンの考え方

データパターンでは因子と各因子の水準の値を記述する必要があります。

因子の決め方

後述の水準ほどはっきりとした決め方はない印象ですが、しいて言うならテストで確認する内容に必要な入力を因子として洗い出すことになります。テスト設計書の記述を分かりやすくするために確認するエラーを「入力の欠損」「入力値の異常」などの項目に分けることがある(後述)ので、それに合わせて因子と水準を決めることになります。

水準の決め方

水準の決め方には同値分割・境界値分析があります。

  • 同値分割
    入力値に対する処理が同じになるように入力値をグループ分けし、グループ内で代表的な入力値を選択
  • 境界値分析
    入力値に対する処理が変化する境界の値をテストケースとして選択
    「内部のDB処理で検索条件に等号を含むか否か」など、境界で仕様とは異なる動作をする場合があるので、境界値分析は有効になります。

状況に応じて使い分けましょう。
(インターンだと境界値分析でテスト設計を組みました)

テストパターンの考え方

因子間の組み合わせ

テストパターンは2因子間網羅をするとよいとされています。
(2因子間網羅:2つの因子間の状態の組み合わせを網羅した状態となっています)
テストパターンとして全ての因子の組み合わせをテストする全網羅組み合わせを行うことも考えられますが、それをすると、(水準数)^(因子数)というとんでもないテストの数になるので、現実的には2因子間を考えるのが現実的です。
これは、因子単体では問題が起こらないが、複数因子の組み合わせでは問題が起こるという場合の検出に有効だからだったりします。
3因子間網羅など網羅するパターンを増やすことも考えられますが、テスト数が膨大になるので、工数とソフトウェアの重要度に合わせて考えるとよさそうです。
2因子間網羅を満たす組み合わせを作成する手法には直行法やAll-Pairs法などがあるようですが、ここでは割愛します。

(インターンでは時間の都合上各因子一つずつを変更したものと、複数項目による問題がないかだけ確認する設計をすることになりました)

テスト設計書の注意

前述の内容を多々含みます。

テストする項目は入力値の欠損・異常など複数の項目に分類することができます。そのため、各項目ごとにデータパターンとテストパターンを分けて記述するようにしましょう。これは、1つテストパターンに多くの項目を記述することにより表が膨れ上がり、わかりにくくなることを防止するためです。

この記事が触れていない内容について

以下は備忘録的に私が今後学ぶ必要がある内容がある内容について記述しておきます。

テストの種類について

テストは複数の軸によって以下に示すように分類できます。

  • 単体テスト・結合テスト・システムテスト
  • 開発者テスト・受け入れテスト
  • ホワイトボックステスト・ブラックボックステスト
  • リグレッションテスト
  • モンキーテスト・探索的テスト
    など

テスト自動化について

テストを自動化していない場合、製品を改良した後にテストをやり直すのがかなり面倒になります。また、リファクタリングで動作が変わらないことを保証するという点でもテストを固定することが有効になります。これに役立つのがテストの自動化ツールになります。Playwrightなどの自動化ツールの記述方法は覚えておいた方がよさそうです。(最も、Playwrightだとボタン操作を記録してテストコードを生成する機能とかあるので、あまり書かなくてもよいかもしれませんが)

終わりに

以上で「インターンから学ぶ『テスト』」は終了です。また、学習する機会がありましたら追記していきます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?