最近、テストプロジェクトの開発が完了し、もともとセルフテスト数日直接オンラインで、それは内部のプロジェクトなので、私は非常に厳格なテストを行うことはありません。しかし、今週はちょうどテストのマンパワーを解放し、具体的にテストするWebテストの子供のために配置。まだいくつかのバグを発見し、次のように自分の書かれたバグを共有しています。

文字の長さ

テストケースの作成と編集では、ユースケース名は、いくつかの長さの制限があります、それは32の長さで十分であることが期待された、あまりにも長いリストを表示するには良いことではありませんので、それはまた、開発の32の長さの一般的な名前に従ってされています。その結果、今日のテストでは、製品のドキュメントが明確に1〜60の長さに書かれていることが判明し、変更する必要がありました。また、新しいライブラリテーブルのために慎重に考慮しなかったので、データベースの設定を変更する必要があり、本当に面倒です。

結論から言うと、やはり開発プロセス、機能の実装にフォーカスしすぎて、プロンプトの一部を含む製品の細部への理解不足などが原因です。製品会議では、私はプロンプトの言語にあまり注意を払わなかったので、いくつかの境界値テストケースが通過できませんでした。

技術文書

たとえば、ユースケースフィルタリング、フィルタ項目：環境、サービス、モジュール、インターフェイス、人物かどうか、利用可能かどうか、関連プロジェクトなどです。各オプションは必須ではありませんが、すべてのデフォルト値が必要で、サーバー側からの基本データのほとんどが必要です。このデフォルト値には2つの状態があります:1, ページのデフォルトは空で、インターフェイスのデフォルトは空の文字列を渡します; 2, ページのデフォルトはすべてで、インターフェイスのデフォルトはint値を渡します。で、フロントエンドは、インターフェイスのドキュメントに合意し、2つの状態は、より多くのトラブルに対処するために発見したので、統一されたこのプログラムで使用されている1、製品ドキュメントとの矛盾を持って、主張の専門的なテストでは、修正で勝つことにした2つのフィルタリング状態が同時に存在することです。

要約すると、この種の問題は、実際に統一されたプログラムを取る必要があり、バックエンドとフロントエンドは、多くの作業を保存し、より便利です。特に、パラメータの検証では、バックエンドは、非常に大きなメンテナンスコストを節約できます。現在、パラメータの検証を完了するために検証アノテーションを使用している、同じパラメータは、異なるインタフェースが異なる検証ルールを持って、私のために、それは人々が頭に乾燥させます。