プログラミングとテストの要点

ここでは、プログラミングのときに注意するポイントやテストの手法について解説します。

プログラミング

プログラム言語を学ぶとき、まず最初にその文法や構文を習得します。
最初のうちは、文法を覚え、実際に動くプログラムを書くことが精一杯で、良いプログラム を書くことなど考える余裕もありませんが、プロのプログラマーとして少しずつ良いプログラムを書くことを意識していく必要があります。
良いプログラムを書 くにあたって、いくつかのポイントがありますので、それらを説明します。

正しく動くプログラム

ここで言う「正しく動く」とは「仕様どおりに動く」と言う意味です。
プログラムの仕様とは、そのプログラムで網羅しなければならない内容のことを言い、処理 手順、処理内容、処理結果などがそれに該当します。
通常、仕様書(設計書)に処理手順や処理内容が詳細に記述されてあります。
プログラミングの第一歩は、 仕様どおりに動くプログラムを作成することです。
それでは、仕様どおりのプログラムを書くためには、どのようにすれば良いでしょうか。

仕様の理解

仕 様どおりのプログラムを書くためには、まず、仕様を確実に理解することです。
ユーザや設計者の要件を的確に把握し、また設計書の内容を全て漏れなく理解す ることが必要になります。
設計書を良く読むこと、ユーザもしくは設計者と十分にコミュニケーションをとることが必要です。
仕様の中で、不明確なことがあれ ば、明確にして、プログラム作成を行わなければいけません。
仕様どおりに作成することができた後は、設計書どおりにプログラムを作成するだけでなく、その プログラムの業務的な背景などを理解し、仕様の不備や改善ポイントを発見し、設計者に相談するなどして、適切に対処できるようになれば一人前のプログラ マーと言えるでしょう。

技術と業務知識の習得

仕 様の理解の他、仕様どおりにプログラムを書くための技術力と業務知識を身に付ける必要があります。
自分が配属された(アサインと言います)システム開発案 件(プロジェクトと言います)に必要な技術要素や業務知識は常に一定ではないことがほとんどです。
プロジェクトが変われば、必要な技術や業務知識は異なっ てきます。
例えば、汎用系システムの場合、プログラミング言語はCOBOLであったり、Web系システムの場合、プログラミング言語はJavaであったり します。
一方業務で言えば、銀行の外為業務だったり、製造業の生産管理業務であったりすることもあります。
一口にプログラミングと言っても、様々な技術で 様々な業務をシステム化するわけですから、プログラマーは大変な職種です。
良いプログラムを書くためには、高い技術力と豊富な業務知識を有していることが 必要となりますので、弛まぬ日々の努力の積み重ねが大切です。

プログラムテストの実施

プログラム作業の後は、必ずプログラムテストを行います。
プログラムが仕様どおりに処理されているかを一つひとつ確認していく作業です。

見やすいプログラム

見 やすいプログラムは、分かりやすいプログラムです。
自分が作成したプログラムを後で修正したりする場合に、すぐに分かるように記述することが必要になりま す。
実際のプロジェクトでは、自分が作成したプログラムを他の技術者が修正したり、処理を追加したりすることもありますので、尚更、分りやすいプログラム を作成する必要があります。
では、どのようにすればそのようなプログラムを作れるようになるのでしょうか。

コメントの記述

見 やすいプログラムの要素として、コメントが適切に記述されていることが挙げられます。
コメントとは、プログラムの中に記述する日本語注釈のようなもので、 プログラムの要所要所で何の処理を行っているか、簡潔に記述します。
実際のプログラムを追うことで、処理内容を把握することは可能ですが、日本語よりは理 解するのに時間がかかります。
コメントがあるプログラムは、各処理の概要や要所要所の変数などが、日本語で記述されているので、他の技術者が修正する場合 にも、分かりやすく、メンテナンス性の高いプログラムとなるのです。

インデントと改行

上級プログラマーなどの優秀なプログラマーが作成したプログラムはどれもインデント(字下げのことで、左側文字の開始位置を一定の法則でずらすこと)や改行が施されていて、見た目も非常にきれいなものが多いのですこれは一体何故でしょうか。
それは、きれいに書いた方が、プログラムの品質向上とメンテナンス性の向上に繋がるからです。
例えば、Javaで言うと、プログラムの中に括弧が多いので、きれいに書かないと、始まりの括弧がどの終わりの括弧と組み合わせになっているか が分からなくなったりします。
数学と同じように、括弧の位置や括弧の対応にも一つひとつ意味がありますので、間違ってしまうと、思った処理結果が得られな くなってしまいます。このようなことを未然に防ぐためにも、インデントや改行を施し、間違わないように記述していくのです。
またコメントと同様に、後で他 の技術者が自分の作ったプログラムを修正や追加処理を施す場合に、見やすくしておけば間違いも減少し、効率的に手を加えることができます。プログラミング 経験が浅いと、インデントや改行を入れずにプログラムを作成してしまいがちですが、最初から習慣付けるようにしておけば、自然にプログラムを記述しながら できるようになります。

変数名・メソッドなどの名称

変数やメソッドなどの名前を自身で命名する場合、分かりやすいものにすることも重要です。
後でプログラムを見直すときに、その名前から内容が想 像しやすいものにしておけば、間違いが起こりにくくなります。
無駄に長くなったり、意味不明な名前にならないようにしましょう。
尚、プロジェクトによって は、命名規約と呼ばれる、変数名の付け方などが細かく定義されているものがある場合もあります。

無駄のないプログラム構造

初心者にとっては、少しハードルが高いかも知れませんが、プログラムを記述する際は、プログラムの構造を複雑にしないことが重要となります。
例 えば同じ処理を何度も書かれているものや、無駄な変数を定義していたりすると、不具合(バグと言います)が発生した場合、それを取り除くこと(デバッグと 言います)に時間がかかったり、バグが出やすいプログラムになってしまいます。
プログラミングをする前に、処理構造をきちんと見定めから、プログラミング を始めるとこのようなことが少なくなります。


テスト

プログラム言語を学ぶとき、まず最初にその文法や構文を習得します。
最初のうちは、文法を覚え、実際に動くプログラムを書くことが精一杯で、良いプログラム を書くことなど考える余裕もありませんが、プロのプログラマーとして少しずつ良いプログラムを書くことを意識していく必要があります。
良いプログラムを書 くにあたって、いくつかのポイントがありますので、それらを説明します。

テスト工程の種類

システム開発では、テストを段階的に行うことにより、確認すべき事項を以下の順番で確認していきます。

プログラムテスト

プログラムがプログラム設計書どおりに正しく動いているかを確認します。
通常、システムは、何人もの技術者で何本ものプログラムによって、構成 されています。
プログラムテストは別名単体テストととも呼ばれ、その一つひとつのプログラムが、きちんと意図したとおりに動いているのかを検証するもので す。
実施にあたって、テストすべき項目(テストケースと言います)が記載されたプログラムテスト仕様書が必要になります。
この仕様書に従ってテストを実施 していきます。基本的にテストケースはプログラム構造設計書に記述されている、全処理パターンが対象となります。
すなわち、記述されたプログラムの全ルー トをテストすることになります。
また、そのテスト実施には、データ(値)を与えないとテストができないケースが多くあります。
その場合、テストを実施するためのデータ(テスト データと言います)を事前に用意しておく必要があります。
オンラインショッピングのログイン画面プログラムテストであれば、最低限ユーザIDとパスワード に該当するものを登録済みデータとして用意する必要があるといった具合です。
これらを踏まえて、テストを実施するわけですが、もし、経験の浅いプログラマーが、1,000行を超えるプログラムを作成し、そのプログラムテ ストの全てのテストケースで、一つもバグがなかったとしたら、それはおそらく、テストケースかテストデータが不完全である可能性が高いと推測できます。
な ぜならば、残念ながら人間はミスを犯す生物で、完璧ではありません。
長年の統計によって、プログラムの作成量に見合うバグの発生量を予め推測することがで きます。
バグ発生率やバグ検出率は開発標準で定められているものもあるくらいです。
要するに、テストを実施しないでバグはつぶせないということです。
も し、この標準的な値を大幅に下回る場合、テストケースやテストデータに不備を疑うべきです。

結合テスト

結合テストは、プログラムテストの後に行われるテストで、いくつかのプログラムを組み合わせて、1つの機能として正しく動いているかを確認します。
例えば、プログラム間のデータの受け渡しや、画面遷移が正しく行われているかなどを確認します。

システムテスト

システムテストは、結合テストの後に行われるテストで、全ての機能を組み合わせて、1つのシステムとして、正しく動いているかを確認しま す。
ユーザの要件どおりに動いているか、機能間の連携はとれているか、性能(処理の速さなど)は問題ないかなどを確認します。
システムテストは新規システムの場合、本番環境を使用して行われることもありますが、本番環境に限りなく近いテスト環境で行われる場合もあります。

運用テスト

運用テストは、システムテストの後に行われるテストで、実際にユーザ自身に本番環境で本番データを使用して実施してもらうテストです。
当初のコンセプトどおりのシステムとして仕上がっているか、使い勝手はどうかなどを最終的にユーザ自身にチェックしてもらいます。

テストケース

次にテストケースのあげ方について説明します。
テストケースが不足していると、テストが不十分になり、品質の悪いシステムになります。
逆に、テストケースが多すぎても、作業時間ばかりかかる非効率なテストになります。
システム開発において、品質を担保するためには、テストケースのあげ方が重要なポイントになります。

テストケースの考え方
上記の三角形の問題の解答のように、テストケースは、「正常系」と「異常系」の2パターンで洗い出し、「異常系」の中でも、「存在チェック」、「属性チェック」、「有効値・有効範囲チェック」などがあります。
正常系:仕様どおりの入力データや操作によるテストケース 異常系:仕様どおりでない入力データや操作によるテストケース 特に異常ケースは、テストケースの漏れが発生することが多いので、テストケースの洗い出しの際には、気をつけましょう。

 

ディシジョンテーブル
ディシジョンテーブルとは、入力データをプログラムが処理した結果、出力結果がどのようになるのかを一覧表にまとめたものです。
全てのパ ターン(場合によってはロジックに差異のある主要パターンのみ)を網羅するテストケースを導き出すのにも非常に有用で、開発者が仕様に基づき整理分類して おく必要があります。
文章だけではイメージしづらいと思いますので、下記仕様のディシジョンテーブルを作成してみることとします。
◆仕様(例)
このシステムは、ITスクールTech Fun.jpの「Android講座」の割引率を判定するものです。 下記注意事項に従って割引種別にチェックをし、割引率判定ボタンを押すと、割引率が判定結果欄に出力されます。
※注意事項※
・割引種別の適用は最大3つ(4つ選択した場合はエラー)
・割引率は最大35%(35%を超えた場合は35%を適用)
・初回割引と再受講割引は同時併用不可(両方選択した場合はエラー)
画面イメージとディシジョンテーブルは以下の通りとなります。
画面イメージ
◆ ディシジョンテーブル
今回のテストケース数は、入力データであるチェックボックスの状態が2通り(チェック済み、未チェック)あり、それが合計4つあることから、2の4乗通 り、すなわち16通りとなります。
ディシジョンテーブルでは、入力データ、この例では「割引種別(IN)」の該当する箇所に「Y」を記入することで、全て のパターンを洗い出すところから始めます。
そして、想定している処理結果を出力データ、この例では「割引率」(OUT)の該当する箇所に「Y」を入力します。 注意点としては、入力データの全てのパターンを洗い出す際、業務仕様上あり得ない組み合わせが存在する場合があります。
上記の例では、「初回割 引」と「再受講割引」が同一ケースに存在する場合です。
このような場合は、出力データの欄全てに「N/A」と記入します。「N/A」とは「Not Applicable」の略で、「該当なし」という意味です。画面上では、「初回割引と再受講割引の両方は選択できません」と言ったメッセージを表示する 必要があるでしょう。
更に、仕様では3つ以上選択するとエラーとするように記述がありますので、4つ選択された場合も「N/A」となります。
「割引種別は3つ以内を選択してください」と言ったメッセージが必要となります。
但し、「初回割引」と「再受講割引」が同一ケースに存在し得ないというルールにも抵触していますので、この場合はどちらのメッセージを出すかは、仕様決定者に委ねられることになります。