どのようにデバッグccbpmのバグシステムにasp.netをデバッグするためのヒントは、クラッシュプログラムが問題を引き起こしIIS

最近、実行時にccflowプログラムは、多くの場合、クラッシュにリードをIIS、シングルステップのデバッグは、問題を見つけることができません。

しかし、それはまた、プログラムの再起動対終了、しかし。最初の実行は、場所が開始する場所がわからない、この問題のために問題はありません。

このような理由から、私はあなたが上記のccflowでユニットテストコードを作成できるかどうかをテストするユニットテストを書くことを考えました。以下の

アップ1aa3f24f362ddeeedd6bf7343bbd2b5940d.png

default.aspxをスタート、それが失敗した第一、第二の時間の成功の実装として設定します。

したがって、私が思うに、むしろ問題IISのクラッシュ原因フロントJSよりも、基礎となるコードのエラーでなければなりません。

私は、狭い範囲、実行のdefault.aspxを入れて上記第一の伝送方式のコードが表示されますを見つけます。

BP.WF.Dev2Interface.Node_SendWork("001" 、workid、102、"黎平" )。

アプローチの問題、さらに範囲を狭め、それが私たちのコアコードNodeSend()です。NodeSendこの方法が比較的大きいので、私は途中で異常の数を書きました。

テストの後、このアプローチの大部分には、問題がないことが判明。

私は、中間部分の増加で、狭い半分で、コードの残りの半分を置換します

(「@ ERRここで実行し、それが問題、上記のコードに問題があることを示している場合、問題をチェックするためにページの下にそれを磨く。」)新しい例外を投げます。

この例外は、最終的にはあり、このメソッドは、イベントに問題を処理します。

アップ3e46b67aa38f5cf3a4fa30ca0ebef316ffc.png

、メソッド本体の真ん中に、例外がスローされた追加のと同じ方法では、最終的には問題が発生したメッセージを送信、見つけるために、数回繰り返します。

アップ835256158daae9a22d1e38067b45044f10d.png

使用を遅らせないために、私は彼をログオフしません。

要約:

  1. 遭遇した同様の問題、ユニットテストを記述する必要が、あなたはシーンを再現見つける必要があります。
  2. 見つかった再現シーン方法は2分、体によってコードセグメントを使用する必要がありますし、問題を見つけます。
  3. ユニットテストは、問題を解決するための最良の方法です。

おすすめ

転載: blog.51cto.com/14150825/2481839