Bibliotheken: MultiTester - Seite 15

[fxsaber]

Сергей Таболин:

Ist es bereits möglich, gezippt oder nicht? (Es ist wie - was, wenn es funktioniert ))))

Ja, die Zips in KB wurden still und leise repariert - die Updates kommen dort an. Die Datumsangaben der Dateien darin entsprechen dem Datum der Aktualisierung. Anhand dieser Daten können Sie also sofort erkennen, welcher Zeit der Inhalt entspricht.

[Good Beer]

fxsaber:

Die Protokolle der Tester müssen eingesehen werden.

Ein Neustart des Terminals und eine Wartezeit von etwa 10 Minuten helfen. Es erscheint sogar eine Warnung. Sie sollten sofort nach dem Öffnen des Terminals mit dem Testen beginnen; blättern Sie nicht einmal durch Trends. Aber mit der Zeit kann alles unterbrochen oder geloopt werden. Das letzte Mal hatte ich einen normalen 172er Durchlauf. Sollte sich die Situation wiederholen, werde ich das Protokoll schicken. Ich habe dort bisher keine Abweichungen von der Norm festgestellt.

[fxsaber]

Good Beer:
Sie sollten sofort nach dem Öffnen des Terminals mit dem Testen beginnen; blättern Sie nicht einmal durch die Trends.

Dies ist keine normale Situation. Der Normalfall ist, dass alles ohne jegliche Bedingungen funktioniert.

[fxsaber]

Anhand von MTTester können Sie die Effizienz verschiedener Handelslogiken vergleichen.

Zum Beispiel gibt es TS1 und TS2. Wir müssen verstehen, welche davon besser ist (natürlich nur bedingt).

Wir nehmen Optimierungen an jeder TS vor und lassen dann die besten Passagen als Singles in verschiedenen OOS-Intervallen laufen.

All dies kann automatisch mit MTTester durchgeführt werden.

Wir vergleichen die OOS-Ergebnisse und entscheiden, welcher TS besser ist.

[traveller00]

Ein interessantes Protokoll ist gerade erschienen

2019.12.21 13:38:35.994 Tester  Ready to set
2019.12.21 13:38:36.617 Tester  i=100

über den Code.

  static bool ClickStart( const bool Check = true, const int Attempts = 100 )
  {
    bool Res = !Check || MTTESTER::IsReady();

    if (Res)
    {
      static const int ControlID[] = {0xE81E, 0x804E, 0x2712, 0x4196};
      GET_HANDLE

      user32::SendMessageW(Handle, BM_CLICK, 0, 0);

      Res = !Check || !MTTESTER::IsReady();

      int i = 0;
      for (i = 0; (i < Attempts) && (!Res)/* && !::IsStopped() */; i++) // Der globale Destruktor muss möglicherweise
        if (Res = !Check || !MTTESTER::IsReady())
          ::Sleep(100);
      Print("i="+(string)i);
    }

    return(Res);
  }

Print("Ready to set");
MTTESTER::SetSettings2(TesterInput);
MTTESTER::ClickStart();

Idealerweise bei i=100 sollte es für 10 Sekunden Minimum schlafen. Wie es das in einer Sekunde geschafft hat (und im Grunde falsch ausgeführt wurde), habe ich noch nicht herausgefunden. Aber es ist wichtig zu sagen, dass die Taste gedrückt wurde, ja. Offenbar gibt es eine Verzögerung bei der Tastenanzeige. Denn es gibt eine zweite Instanz, die parallel zum Test läuft und die CPU zu 100% belastet.

[traveller00]

Ich glaube, ich habe es verstanden. Die Bedingungen waren nicht in Ordnung. Wahrscheinlich mussten sie deshalb beim letzten Mal die Anzahl der Versuche auf 50 erhöhen. Er schläft nur, wenn er erfolgreich ist, wenn er sowieso auf dem Weg nach draußen ist. Und es geht schnell vorbei, wenn es eine gute Zeit zum Schlafen ist. Das muss ein Bug sein. Und der Fehler ist traurig, offensichtlich hat er sich fast einen Monat lang nicht gezeigt, und ich habe gehofft, dass die Passagen in Ordnung sind. Ich werde alles noch einmal testen müssen. Und ich habe mich immer wieder gefragt, warum selten, aber manchmal passen Passagen nicht zusammen.

Ich denke, es muss sein

if (!(Res = !Check || !MTTESTER::IsReady()))

[fxsaber]

traveller00:

Offenbar soll es so sein

Ja, die Schleife hat durch meine Unaufmerksamkeit an Bedeutung verloren. Danke, dass Sie sich die Sache angesehen und mich auf die Stelle aufmerksam gemacht haben. Ich werde sie, wenn möglich, erneut hochladen.

[fxsaber]

fxsaber:

Ja, die Schleife hat durch meine Unaufmerksamkeit an Bedeutung verloren. Danke, dass Sie das geklärt haben und klar darauf hingewiesen haben. Ich werde sie nach Möglichkeit wieder hochladen.

Aktualisiert.

[Good Beer]

Während ich auf das Update wartete, fand ich die Gründe für die Schleifenbildung in der Multitester-Taskliste heraus.

Der erste Grund war der Task-Manager "process lasso" eines Drittanbieters auf meinem Computer. Er hilft bei der drahtlosen Maus und Tastatur, mag es aber nicht, wenn eine Anwendung alle CPU-Kerne belegt. Die Prozesse des Testagenten wurden einfach unterbrochen und die Ergebnisse gingen verloren. Man bekam eine unvollständige Aufgabe, jedes Mal mit einem neuen Ergebnis. Die Erhöhung der Metatester-Priorität brachte Abhilfe.

Das zweite Problem ist, dass Multitester die Vorwärtsfunktion nicht unterstützt. Wenn die Weiterleitung nicht aktiviert ist, funktioniert alles einwandfrei. Wenn es aber aktiviert ist, beginnt die Aufgabenliste zu stagnieren. Die Vorwärtsprüfung beginnt, wenn am Ende eines Durchlaufs die Meldung "DONE" erscheint. Multitester will durch die Liste blättern, aber der Vorlauf beginnt. Und wenn die Schaltfläche "START" gedrückt wird, wird die alte Aufgabe gestartet. Was ist das Kriterium Ihres Algorithmus für das Ende eines Durchgangs?

Bitte berücksichtigen Sie den Vorlauf in zukünftigen Versionen von Multitester.

[fxsaber]

Good Beer:

Bitte berücksichtigen Sie den Forward in zukünftigen Versionen von multitestera.

Ich habe den Vorwärtsmodus noch nie in meinem Leben benutzt. Ich werde ihn wahrscheinlich eines Tages ausprobieren.