ただ闇雲にテストしていてもバグを見つけることは難しいです。
そこでどこを重点的にテストするれば良いか説明します。

##　テストの前提
まずテストはまったくバグの無いソフトウェアを作ることはできません。
なので全てをテストしようとするのではなく、十分なテストをすることが大切です。

まずはいくつかテスト手法を紹介します。
##　ホワイトボックステスト
ホワイトボックステストとはプログラムの理論構造が正しいかを分析するテストです。
ホワイトボックステストですべての処理をテストすることでカバレッジ100%となります。
しかしカバレッジ100%になるまでテストするには、多くの予算と時間がかかる上、カバレッジ100%にしてもバグの無いプログラムとはならないので、一般的なソフトウェアなら60~90%で十分という説が多いです。
カバレッジを何%にするかはROIを考慮して決めるといいと思います。

ROIとは、Return On Investmentの略語で、投資したコストに対する効果を見る指標です。計算式としては下記になります。
ROI＝利益÷投資コスト×100

TDD再考 (2) – 何故、ほとんどのユニットテストは無駄なのか？

ステートメントカバレッジ

if文など含む処理はフローチャートで表すことができます。
そのフローチャートにある命令文（ステートメント）を少なくとも1回は実行するようにテストケースを書きます。
しかしif文の処理が間違えている場合などにはバグを見つけることはできないので、このテスト手法は弱いテスト手法です。

ブランチカバレッジ

ブランチカバレッジは、分岐コードに対してそれぞれの判定条件がTRUE,FALSEの結果を少なくとも一回ずつも打つようにテストケースを書きます。
そうすることによりステートメントカバレッジでテストしきれなかった部分をテストすることができますが、テストケースの数がかなり増えてしまうというデメリットがあります。

カバレッジでテストできないバグ

プログラムのループに関するバグ
要求仕様自体が間違っていたり、機能が備わっていないバグ
データに関するバグ
タイミングに関するバグ

ブラックボックステスト

ブラックボックステストとはプログラムの仕様が正しいかをテストすることです。
ブラックボックステストは、ソースコードを利用したり見ることなく、様々な入力を行うことで、テストを行います。
ブラックボックステストでよく使われる手法として同値分割法と境界値分析法があります。
詳しくは同値分割・境界値分析の解説に書いてあります。

テストする際に気を付ける点

自分が行ったテストで、どこまでテストが出来ていてどこがテスト出来ていないかを把握する。
テストケースを書くときはいつ、誰がやっても同じうような結果が得られるように書くように心がける。
境界値にバグが潜んでいることが多いので、境界値周辺を念入りにテストする。
複雑な処理をしている箇所にバグがあることが多いので、複雑な処理をしている箇所を念入りにテストする。
適切なテスト手法を使うようにする。

##　まとめ
テストとして十分なパターンを出してテストする。
ただしパターンをすべて出していては量が多すぎて時間が足りなくなるので、バグが出そうな箇所や、絶対にバグを出してはいけない箇所を、選別して、テストする必要があります。