基本的に、限られた時間枠で他の人の助けを借りずにコードを十分にテストするためのヒントを誰かが持っているかどうか疑問に思っていますか?
以前は、自分のコードをテストしてくれる人を見つけたり、専任の品質保証チームにすべてを調べてすべてのエラーを見つけてもらったりしていました。
私は通常、かなり注意を払っていますが、見逃しているものを常に見つけて、それらをテストすると、それらが表示されません。
しかし、私の現在の仕事では、非常に限られた時間枠で 2 つの PHP Web アプリケーションを作成する必要があり、これは良い考えではないとのフィードバックにもかかわらず、すべてのテストを自分で行う必要があると言われました。
他の誰かが以前にこの問題を抱えていて、洞察を提供できるかどうか疑問に思っていましたか?
各領域をコーディングする前に簡単なテスト計画を作成し、テストを行う前に要件を再確認するとよいのではないかと考えていました。
確かに、単体テストは、テスト ファーストであろうとなかろうと、防御の最前線であるべきであり、アプリケーションの各部分が思いどおりに動作することを保証します。ただし、あなたが話しているテストの種類は、別の目を取得するのに役立つ場合がありますが、受け入れテストの領域にあります。アプリケーション全体が本来の方法で動作しますか。さまざまな奇妙なシナリオや動作などで機能しますか?
役立つアプローチの 1 つは、ペルソナを想像することです。最初にアプリケーションを自分自身としてテストしますが、次に自分が 85 歳で、ひどくよく見えず、マウスをそれほどうまく使用していないことを想像して、もう一度テストします。最も明るいものや最も大きなものをクリックする傾向があるかもしれません。今、あなたが 12 歳で、涙が出るほど急いでいると想像してみてください。指示を読むつもりはありません。それはまだ動作しますか？
特定のフィールドについて、人が入力する可能性のあるエッジ ケースは何ですか? スペースだけを入力するとどうなりますか? テキスト フィールドに数値のみを入力しますか? HTML を入力するとどうなりますか? ジャバスクリプト？非西洋アルファベットの何か？本当に長いものを入力するとどうなりますか?
重要なのは、ユーザーが思い描いていた方法でアプリケーションを通過する「ハッピー パス」をテストすることだけではありません。誰もすべきではない方法でアプリケーションを通過します。なぜなら...彼らはそうするでしょう。
もう 1 つの重要な点は、何も無視しないことです。奇妙な画面が表示されて、「ああ、それはまぐれだ」と自分に言い聞かせるのは簡単です。あるべき姿ではないことに気づき、追跡する必要があります。
実行できるテストの量には常に制約があります。制約内で、明らかにテストを構築する必要があります。最も重要な領域 (セキュリティ、損傷の可能性、データの損失、機能) のテストを最初に作成する必要があることは明らかです。
機能仕様を除けば、何をテストするかを決定するために多くの手動ヘルプを取得することはほとんどありません。ただし、テスト カバレッジ ツールの形で自動化されたヘルプを利用できます。これらのツールは、テストしたコードと、テストしていないコードを教えてくれます。テストされていないコードを検査することで、そのコードの重大度が高いか低いかを判断できます。したがって、リリース前にテストをコード化する価値があるかどうかを判断できます。テスト カバレッジ ツールは、テストされたコードとコード全体の比率も示します。この比率が 70% 以上であることを確認するのが業界のベスト プラクティスです。このデータを使用して、単純な策略で上司ともっと時間を交渉することができます。
PHP で動作するテスト カバレッジ ツールは、ここにあります: Semantic Designs PHP Test Coverage Tool
覚えておくべきことの1つは、開発者がコードの「最良のパス」をテストする傾向があるということです。言い換えれば、あなたはそれを書いたので、あなたはあなたが特定の場所をクリックし、特定のものをタイプすることになっていることを知っているので、あなたはそれをテストします。もちろん、これは重要です。
ここにはいくつかの良い提案がありますが、ほとんど（すべてではない）が見逃しているように見えるのは、否定的なテストです。基本的に、境界をテストする必要があり、悪意のあるものをテストする必要があります。前述のように、スクリプトコードを次のようなフィールドに入力します。
<script>alert('abc')</script>
アラートを受け取った場合、正しくエンコードできなかったことが明らかになります。もう1つのことは次のとおりです。
abc' or 'a' = 'a'
これにより、認証などでSQLインジェクションの問題が発生する可能性があります。次のような方法でSQLインジェクションをテストすることもできます。
abc'; drop table users; select * from dual where 'a' = '
テーブルがなくなったばかりの場合は、問題があります。非常に多くの例がありますが、少なくともOWASPトップ10のテストに時間を費やす必要があります。
テストしたい他の場所は、特に32ビットプラットフォームでの整数入力、負の値、値なしなどを期待する場合の非常に大きな数のようなものです。基本的に、目的のフローが機能することをテストしてから、それを破るためにできることをすべて行います。
TDDはまさにあなたが探しているものだと思います。最初にテストを書き、次にテストに合格するコードを書きます。あなた以外の人は必要ありません (ただし、テストの助けが推奨されます)。また、コーディングを開始する前であっても、ツールが何をすべきかについてより明確なアイデアを得ることができます。
言いたくないのですが、あなたの場合はアレックス・ティングルが正しいと思います。ありえない状況です。
JacobM と Santi は、単体テスト、受け入れテスト、およびテスト駆動型開発について言及している点で正しいです。そのリストに、コード カバレッジと静的解析ツールを追加します。
しかし、TDD または基本ユニット テストは、通常、テスト時間の短縮、欠陥率の低下、およびメンテナンスの容易さという点で効果がありますが、デスマーチで予定どおりに納品するのには役立ちません。これは、自動化されたテストの作成に慣れていない場合に特に当てはまります。
丁寧に言えば、上司は技術的負債を負うように求めています。正しく言えば、彼はあなたに職業倫理を無視するよう求めています。
笑顔で「はい」と言って、割り当てられた時間内に最善を尽くし、履歴書を更新してください。
あなたの雇用主は明らかに、テストが重要だとは考えていません。辞めてまともな仕事を見つけたほうがいい。
テスト駆動開発と単体テストの価値と有効性について投稿された以前の回答に同意します。正しく実行された場合、本番/成果物コードを記述する前に単体テストを記述する TDD プロセスは、集中力を維持し、設計とインターフェイスを検証するのに役立ちます。さらに、他の開発者は、非常に単純な方法でコードを使用および使用する方法から作業するための明確で一貫した方法を持つことができます。単体テストは同じではなく、完全な統合テストの代わりになるものではないことに注意してください。このアプローチでは、完全な統合テスト計画を作成する必要がある場合があります。
私は主に .NET で作業しており、NUnit での作業では良い結果しか得られませんでした。
私は以前に PHP で作業したことがありませんが、私が見てきたことから、SimpleTestまたは PHPUnit を検討することをお勧めします。
あなたが彼のために働いている間、そして彼の気が変わるまで尊重しなければならないあなたの上司の要件を考えると、あなたは質問に正しい答えを与えました.