Zpracovávání výsledků testů

Tato obrazovka se postará o případy, kdy máme testovací zařízení, které ukládá výsledky do lokálního adresáře. Předpokládá se, že zařízení neumožňuje přihlášení a výběr výrobní objednávky, o to se stará obrazovka TracePRO. Myšlenka je ta, že před začátkem práce se spustí obrazovka Zpracování výsledků TracePRO. Do ní se pracovník přihlásí, vybere výrobní objednávku a operaci. Pak se spustí vlastní testovací program a testuje se.

Testovací zařízení pro každý výsledek zapíše na disk soubor. TracePRO soubor najde, vyčte z něj barkód výrobku, výsledek, a případně další data, a uloží do TracePRO.

Pokud testovací zařízení nenačítá barkód, dostane TracePRO výsledek bez barkódu, a na barkód se zeptá.

Nastavení

V klientovi TracePRO jsou dvě obrazovky:

  • tccli.pgtestwatcher - použijte jej pokud tester přidává data stále do stejného souboru (nebo do sady souborů).

  • tccli.pgtestsinglefilewatcher - použijte, pokud jeden soubor obsahuje výsledky jednoho testu. Tato obrazovka umí soubory s výsledky archivovat do zip souborů.

V konfiguračním souboru je třeba definovat, kde najde TracePRO výsledky testování, a jak je má zpracovávat. Tato sekce je navržena a vytvořena během instalace systému TracePRO. Příklad nastavení:

test_watcher.name=JMENO
test_watcher.dir=/home/test/results
test_watcher.glob=*.json
test_watcher.processor=tccli.testprocessors.json_result_processor
# pouze pro pgtestsinglefilewatcher:
test_watcher.backup_dir=/home/test/results/backup
test_watcher.ask_repair_barcode=0

Detailně:

  • test_watcher.name: Může to být libovolné jméno (bez diakritiky). Toto jméno se použije pro soubor, do kterého si TracePRO ukládá pozice zpracovaných souborů.

  • test_watcher.dir: Adresář, ve kterém jsou výsledky testů.

  • test_watcher.glob: Maska pro příkaz glob, pomocí které se najdou testovací soubory. Např. *.json bude hledat jen v aktuálním adresáři soubory s koncovkou .json. Pokud chcete hledat v podadresářích, použijte **/*.json. Může zde být více masek oddělených čárkou.

  • test_watcher.processor: Jméno procedury pro vyčtení výsledků ze souborů. Musí to být jméno funkce dostupné v klientovi TracePRO.

  • test_watcher.backup_dir: Sem se budou zálohovat zpracované soubory. Pokud se zálohují, tak se také smažou.

  • test_watcher.ask_repair_barcode: Pokud z testeru nepřišel barkód nebo přišel špatný barkód, TracePRO může vyžádat načtení správného barkódu. Výchozí hodnota je 0 (NE), když nechceme dovolit, aby uživatel cokoliv načítal.

Kontrola programu

Pokud je u operace nastaven program (parametr operace s názvem PROGRAM nebo PROGRAM_něco) a pokud TracePRO vyčte z logu testeru jméno programu, tak také jméno programu zkontroluje (musí přesně odpovídat), a pokud neodpovídá, odmítne výsledek zapsat.

Rozhraní

Rozhraní test_watcher.processor je jednoduché, až primitivní. Je to funkce, která bere parametry:

  • fn: pathlib.Path objekt - soubor, ve kterém by měla být nová data

  • last_sz: Poslední známá velikost souboru, neboli pozice, za naposledy zpracovanými daty.

  • sz: Aktuální délka souboru.

Návratová hodnota:

  • Předpokládá se, že přes návratovou hodnotu funkce se bude iterovat, takže může vracet list nebo něco takového, nebo yield.

  • Vrácené hodnoty jsou: (barcode, test_datetime, result, data_list, file_processed_seek):

    • barcode je barkód vyčtený z test reportu

    • test_datetime je datetime objekt testu, praktická hlediska ale ukazují, že na téhle hodnotě nezáleží, protože server nejčastěji zapisuje operace s časem server.

    • result: 0 - OK, jiné číslo (nejlépe 1) - NG

    • data_list: seznam trojic: (typ, jméno, hodnota)

    • file_processed_seek: Příští volání této funkce dostane tuto hodnotu jako parametr last_sz.

Poznámky:

  • Obrazovka pgtestsinglefilewatcher se použije, pokud každý výsledek testu zapíše nový soubor. Pak na hodnotách last_sz a sz nezáleží. Zpracovaný soubor je zazálohovnán a smazán.

  • Naopak, pgtestwatcher předpokládá, že výsledky se připisují do jednoho souboru dál a dál. Takže potřebujeme, aby zpracující funkce vrátila správný seek.

  • Vhodné místo na definici Vašich funkcí pro zpracování test reportů je Váš modul. Ten byl předán při implementaci. Bude to pravděpodobně tccli_<companyname> nebo tccli_<companyname>ext.

Příklad:

def processjson(fn, sz_from, sz_to):
    """
    Tohle je jednoduchý příklad, kdy výsledek by měl v json souboru
    obsahovat pole "barcode" a pole "result" a jméno program v "PROGRAM".
    """
    try:
        now = None
        with fn.open() as f:
            data = json.load(f)
            LOGGER.info("Read json: %s => %s", fn, data)
            result = data["result"]
            data = [(defs.OPDATA_PARAM, "PROG", data["PROGRAM"]), ]
            if result != "OK":
                data.append((defs.OPDATA_E_DEFECT, "RESULT", result))
            yield (data["barcode"], now, 0 if result == "OK" else 1, data, sz_to)
        return
    except Exception:
        LOGGER.exception("Error processing %s", fn)
    return []

Důležitá data:

  • defs.OPDATA_PARAM - nějaký parametr, např. program.

  • defs.OPDATA_INFO - nějaká informace patřící k testu nebo k výrobku

  • defs.OPDATA_ENV - nějaká hodnota prostředí. Teplota, vlhkost, …

  • defs.OPDATA_VAL` - nějaká hodnota patřící k testu nebo k výrobku

  • K jednotlivým měřícím bodům nebo krokům testu:

    • defs.OPDATA_E_VAL` - jiná hodnota, než se očekává, např. mimo meze

    • defs.OPDATA_E_AOI` - chyba z AOI

    • defs.OPDATA_E_DEFECT` - chyba, nejedná se o měřenou hodnotu, ale spíš textový popis

    • defs.OPDATA_I_VAL` - naměřená hodnota, ne chyba

    • defs.OPDATA_I_DEFECT` - nějaká hodnota, ale ne chyba

    • defs.OPDATA_I_AOI` - výsledek z AOI, ne chyba

    • defs.OPDATA_I_AOIFP` - falešná chyba z AOI