最悪!オンラインバグからの知識解答PK!要約して要約する

最悪!オンラインバグからの知識解答PK!振り返ってまとめてみます。
主な問題は 2 つあります:
1. サーバーの問題: クラウド データベース監視監視エラーの報告;
2. カードのバグ問題: マッチングが成功するか pk が開始された後、誰かが途中で終了します;

クラウド データベース監視監視エラー報告
最初の質問については、によると、ユーザーからのフィードバックによると、時計では最近頻繁かつ不定期にエラーが発生しています: エラー: errCode: -402002。


問題が見つかりました


問題が判明しましたが、ここ2日ほどで時々発生しており、何度も試しましたが再現しなかったので、今のところ原因を特定する方法がありません。



まず、公式の技術文書を調べたところ、-402002 は「SDK データベース エラー: 初期化監視に失敗しました」に属し、私が開発した PK 応答アプレットのバグや、ユーザーの不安定または低品質のネットワークの問題ではないことがわかりました。それは可能性を排除できます。あとは公式サーバーの問題です。
 


それからコミュニティに行ってみると、誰かがそれに遭遇したのを見ました。その後、偶然にもこの問題に遭遇しました。Tencent公式クラウドサーバーメーカーにフィードバックして、この問題を解決します。
Tencent の公式クラウド サーバー メーカーもすぐに対応し、解決しました。


試してみましたが、問題は発生しませんでした。Tencent クラウド サーバー メーカーは正式にこの問題をすぐに解決してくれたので、私はすぐにユーザーに問題が解決したことを報告し、ユーザーもテストしましたが、問題は再発しませんでした。



マッチング成功またはPK開始後、誰かが途中で辞めてしまう
ユーザーのフィードバックによると、今回のPKでは、1人はマッチングに成功して質問に答え始め、もう1人はマッチングを続けているが、マッチングに成功した人は回答できなくなっているとのこと。質問に答え続けます。つまり、マッチングが成立した時点で、相手は終了するか、すでに開始しています。


確かに、この異常な動作プロセスを考慮するには、数日前に指摘した機能を追加する必要があります。
私がこれまでに行った1対1の招待PK戦留守番システムのほとんどは、開始前にA・B双方が開始するか終了するかを選択でき、試合終了後、Bが「承諾」を選択し、Aが「開始」を選択できます。 」と言ってPKを開始します。そのため、pk中に退場になることはほとんどなく、確率は非常に低いです。
なお、1vs1のpkを招待して質問に答える仕組みは、pkの数を制限せず、通常の操作プロセスに基づいて通常のpkのみをカウントするという点で異なります。そのため、たとえpkの途中でやめる人がいたとしても、影響はありません。


現在の 1v1pk 応答メカニズムまたはモードは自動マッチングです。実はイベント開始前に、先方の要望によりプログラムロジックの一部が変更されました。
 


実際には一定のリスクがあり、応答 pk アプレットは起動されて安定して動作していますが、短期間に大きな変更があった場合、必然的に不安定になります。一部の状況がカバーされていないため、時間が短く、回帰テスト、ストレス テスト、スモーク テストが十分ではありません。
危険箇所は事前に相手に伝えていますが、自分で開発・構築したものなので、ある程度の責任は自分にも負わなければなりません。したがって、私たちは、ほとんどの人々の通常の使用に影響を与えずに、可能な限り互換性を保つために、これらの特殊な場合にのみ戦略的な修理を行うことができます。
 


 


 



 


 


 


 


 


 


このレビューと要約を通じて、得るものもあります。メインプログラムは正常に実行されていますが、何らかの特別な状況が発生すると、ユーザーエクスペリエンスに影響を与えます。例えば、公式サーバーの不具合、個人ユーザーの異常な操作(pk戦中の退場)など。
公式サーバーの問題は、解決のために直ちに公式に報告する必要があります。

ユーザー操作の問題は、操作プロセスの設計、プログラム コードの制御、およびアクティビティ プランの調整戦略の 3 つの方法で解決または回避できます。
運用プロセスの設計で解決することが優先ですが、大きな変更であるため、修正・調整のための十分なプレビュー時間と、正式な活動開始までに多くのテストが必要となります。(最適解)
第二に、プログラムコードは様々な特殊な状況に対応し、それを阻止するために使用されますが、この方法では、状況に遭遇する前に考えられず、見逃してしまう場合があります。さまざまな携帯電話 機種や携帯電話システムにはいくつかの特徴があります。ユーザーからのフィードバックを学習して解決する前に、それを処理することも必要です。(次善の策)
また、イベントのルールやプランを調整することもでき、pkの回数に制限もありません。(次善の解決策)
 

おすすめ

転載: blog.csdn.net/qq_29528701/article/details/131477868