web-dev-qa-db-ja.com

コードを適切に検証する方法は？

JavaScript/PHP/CSS/HTMLのWebアプリケーション用に約4000行のコードがあります。正しくテストするにはどうすればよいですか？

私はIEとSafariの最新バージョンのみをサポートしています。すべてのバグを解決しました。コードを堅牢と呼ぶことができるようにテストする良い方法はありますか？ ？

Perl Mechanizeを使用してフォームに自動入力するか、同様のことを行うことを検討しました。

また、PHPテストクラスを使用して、PHPクラスの内部動作をテストします。ただし、満たすべき標準または適合ガイドラインのようなものはありますか？このコードがコードの不明瞭さなどに関するIEEExxx foo標準に合格していると言う方法はありますか？

W3バリデーターを使用してHTMLを検証し、jslint.comを使用してJavaScriptを検証しました。

勤勉項目のリストはここにあります：

  1. HTML/CSSがW3検証に合格
  2. JavaScriptはjslintを渡します
  3. PHPは内部に合格PHPテストクラス

ユーザーテスト

  1. 一連のユーザーアクションを作成し、Perlの機械化などを使用して実装します。

コードをWebにリリースするための標準または手順はありますか？

phpjavascripthtmlcsstesting
8
user44388

ソフトウェアの検証は非常に大きな領域であり、質問に対する明確な答えはありません。さらに、ソフトウェア検証エンジニアは通常、開発よりもはるかに多くの知識と、開発者コミュニティで現在一般的である多くのスキル（たとえば、非常に重要な「デバッグ仕様」など）を必要とする特別な役職です。

第二に、ソフトウェア検証（およびその本質的な部分としてのコード検証）はテストではありません。ダイクストラによる有名な引用があります：

テストでは、バグがないことではなく、存在することが示されています

したがって、これはソフトウェアの検証（つまり、ソフトウェアが有効であり、エラーが含まれていないことを示す）とテスト（潜在的なエラーやバグがないか）との主な違いです。

質問を「PHPベースのWebアプリケーションを適切に検証する方法」に絞ると、私は次の答えを出すことができます：

汚染分析

PHPで汚染分析を実行するためのいくつかのきちんとしたツール（ 1 、 2 ）があります。これは、機密情報の考えられるシンク（リーク）を特定する静的分析です（つまり、コードを実行せずに実行されます）。

私はこれらのツールのいくつか（ Pixy ）を自分の実践で使用しており、静的分析の他のすべてのツールと同様に、潜在的な危険性を過大評価しているようです。それでも、気付いていない可能性のあるセキュリティの問題を特定するのに役立ちます。これは、一部の機密データを処理するWebアプリケーションにとって特に重要です。

これは、XSSのように考えられるすべての脆弱性を排除するわけではありませんが、PHPコードやSQLインジェクションなど、多くの一般的な脆弱性をカバーします。

適合性検証。

このステップは、完全なWebサイトに対してJSLintおよびCSS/HTMLバリデーターを実行することによって既に実行しました。

負荷テスト。

Webアプリケーションの可用性が問題（またはSLAの一部）である場合は、いくつかの負荷テストも実行します。これらは、Visual Studioなどの一部のIDEで生成することも、この目的でオープンソース JMeter フレームワークを使用することもできます。

2
Alexander Galkin

答えは人気がありません。

あなたはユーザーにそれから生きている地獄を打ち負かしてもらう必要があります。テストを何度も繰り返した後に報告されたバグのリストを使い尽くした後は、コードをロバストとしか呼び出せません。

あなたはそれを単独でテストすることはほとんど役に立たないでしょう。なぜならあなたは木のコーディングにいて、森を見ることができないからです。

開発者が史上最悪のテスターであることをご存知ですか？私は開発者であり、「これは私のラップトップで完全に機能します」と誇らしげに述べた後、何年にもわたって私の顔に落ちた後で初めてこれを知っています。

1
Jason Sebring

基準は、それを実施する人々と同じくらい良いだけです。 （特にISO品質規格に当てはまります...）

ソフトウェアを完全にテストする場合は、すべてのタスク/機能/その他を実装する必要があるため、それらを実行/実装したという事実を検証するために使用できる優れた要件仕様が必要です。また、品質保証/ソフトウェアテストの観点（コードレビューから探索的ユーザーテストまで）からプロジェクトを他の誰かに見てもらうことも役立ちます。

あなたが考慮したいと思うかもしれないもう一つの注意は、開発者としての明確な要件仕様がなければ、おそらく「バグ」ではなく「機能」として物事を想定することが多いという事実です:)

要件仕様（IEEE 830）およびテスト計画（IEEE 829）にはIEEE標準があります。しかし、私はそれらが多くのプロジェクトにとって少しOTTだと思います。

（データベースがないことにも少し驚いていますか？）

1
rks