Automação de testes para sistemas complexos e distribuídos
Descreva um teste em linguagem simples. O TS Factory escreve-o na sua suite do Test Environment e envia-o para um branch. O Midair executa a suite fixada nesse branch.
Os testes correm em dispositivos, máquinas e serviços. Cada execução guarda a sua configuração, os logs e os veredictos.
mcp midair_start_run wifi-ts @ ts/ping-latency midair run 518 started on node lab-2 test wifi/connect_ping PASSED test wifi/ping_latency FAILED expected PASSED verdict 5% of the packets to the gateway were lost mcp midair_run_failures run 518 mcp midair_get_log wifi/ping_latency page 1 log Sent 20, received 19, lost 5% midair run 518 saved: configuration, logs, verdicts
O que é a automação de testes.Para sistemas com muitas partes.
A automação de testes usa software para preparar, executar e verificar testes que, de outra forma, alguém repetiria à mão.
Num sistema complexo, o teste é a parte pequena. As máquinas, os dispositivos, a rede e a ordem entre eles têm de estar prontos antes do teste e registados depois dele.
O Test Environment faz esse trabalho: agentes em várias máquinas executam juntos um cenário. O TS Factory trata da escrita: transforma uma descrição simples em testes na mesma suite.
Do prompt ao branch.Quatro passos, um exemplo.
Este exemplo junta um teste a uma suite de Wi-Fi. Avance passo a passo, ou carregue em Reproduzir.
Escrever a especificação em linguagem simples
Abra a suite no ecrã Test suites e carregue em Run. Escreva o que a alteração deve fazer e escolha o Claude Code ou o Codex CLI como ferramenta.
wifi-tsts/ping-latencyClaude CodeJunta um teste ao pacote wifi. Liga-te à rede da bancada e faz ping ao gateway 20 vezes. Falha se houver perda de pacotes, ou se o tempo médio de ida e volta passar de 50 ms. O número de pings e o limite são parâmetros do teste.
O TS Factory altera a suite
O Midair envia o prompt para a ferramenta com o contexto do framework Test Environment. A ferramenta clona o repositório da suite e altera-o no local. O ecrã mostra a saída da ferramenta enquanto ela trabalha.
ts factory · wifi-ts · claude code clone wifi-ts → ts/ping-latency read wifi/connect_ping.c bench settings, ping write lib/wifi_bench.c join steps, shared write wifi/ping_latency.c new test edit wifi/package.xml count, max_avg_ms edit trc.xml expected PASSED commit wifi: add ping_latency 4 files changed
Ler o teste gerado
O resultado é um teste em C normal, sobre a API do Test Environment. Os seus engenheiros revêem-no como qualquer outra alteração.
/** @page wifi-ping_latency Ping the gateway over WiFi */ #define TE_TEST_NAME "wifi/ping_latency" #include "wifi_bench.h" #include "tapi_ping.h" int main(int argc, char **argv) { unsigned int count; double max_avg_ms; wifi_bench bench = WIFI_BENCH_INIT; tapi_ping_app *ping = NULL; tapi_ping_report report; TEST_START; TEST_GET_UINT_PARAM(count); TEST_GET_DOUBLE_PARAM(max_avg_ms); TEST_STEP("Join the bench network"); CHECK_RC(wifi_bench_join(&bench)); TEST_STEP("Ping the gateway %u times", count); CHECK_RC(wifi_bench_ping(&bench, count, &ping, &report)); TEST_STEP("Check loss and round trip"); if (report.lost_percentage != 0) TEST_VERDICT("%u%% of the packets to the gateway were lost", report.lost_percentage); if (report.rtt.avg > max_avg_ms) TEST_VERDICT("Average round trip %.1f ms is over %.1f ms", report.rtt.avg, max_avg_ms); TEST_SUCCESS; cleanup: if (ping != NULL) CLEANUP_CHECK_RC(tapi_ping_destroy(ping)); wifi_bench_leave(&bench); TEST_END; }
Enviado para um branch, executado nesse branch
A ferramenta envia a alteração para o branch indicado no registo da suite. Uma execução fixada nesse branch arranca a partir de um modelo, da CI ou por MCP. O branch principal fica como estava.
git push origin ts/ping-latency branch ts/ping-latency 4 files changed run 519 template wifi-nightly suite branch ts/ping-latency node lab-2 · env.lab-2 wifi/connect_ping PASSED expected PASSED wifi/ping_latency PASSED expected PASSED avg 7.4 ms, 0% lost 2 as expected · main unchanged
O que vale a pena automatizar.E o que pode esperar.
Automatizar primeiro
- Verificações que repete em cada build
Arrancar, ligar à rede, passar tráfego básico. São as que correm mais vezes, por isso compensam primeiro.
- Cenários que precisam de várias máquinas
Um dispositivo, os seus pares e uma fonte de tráfego, arrancados pela ordem certa. Os agentes mantêm a mesma ordem em todas as execuções.
- Falhas que teve de reproduzir à mão
Escreva os passos como teste uma vez. A próxima regressão aparece numa execução, com o seu log.
- Sessões longas e noturnas
As execuções planeadas arrancam um modelo segundo um horário, por exemplo todos os dias úteis às 02:00.
Deixar manual por agora
- Testes cujo resultado esperado ainda não está claro
Primeiro, acordem no que deve acontecer. Um teste gerado não resolve uma pergunta a que ninguém respondeu.
- Verificações pontuais durante o bring-up
Uma placa que fica um dia na bancada ainda não precisa de uma suite.
- Decidir o que uma ocorrência significa
O ciclo de vetores de ataque marca cada ocorrência como demonstrada por uma execução ou apenas suspeita. Uma pessoa confirma-a.
Use o que já tem.Suites, scripts, pipelines e logs.
Suites do Test Environment que já existem
O Midair executa as suites feitas sobre o Test Environment tal como estão. O TS Factory altera-as com commits normais num branch.
Scripts e especificações como dados de origem
O registo de uma suite pode indicar um repositório de origem só de leitura. O gerador lê-o como fonte para a alteração, junto com o prompt.
A sua CI
As execuções arrancam a partir do Jenkins com o plugin, da API ou de um assistente de IA por MCP.
Logs de outro sistema
Importe um log em bruto do Test Environment para um registo de execução. O Midair lê-o da mesma forma que um log que ele próprio recolheu.
Perguntas.Respostas curtas.
O que é a automação de testes?
A automação de testes usa software para preparar, executar e verificar testes que, de outra forma, alguém repetiria à mão. Em sistemas complexos, prepara também as máquinas, os dispositivos e a rede de que o teste precisa.
O que é o TS Factory?
O TS Factory é o gerador de suites de testes do Midair. Passa um spec prompt em linguagem simples ao Claude Code ou ao Codex CLI. A ferramenta altera uma suite do Test Environment e envia a alteração para um branch.
Temos de aceitar os testes gerados tal como vêm?
Não. A alteração chega como commits num branch. Revê-a como qualquer outra alteração e decide quando a integrar.
Um assistente de IA também pode executar os testes?
Sim. Por MCP, um assistente pode criar suites, lançar execuções fixadas num branch e ler as falhas e as páginas de log.
O que é o ciclo de vetores de ataque?
Executa o gerador em ciclo: analisar, planear, escrever testes, executar, avaliar. O ciclo nunca altera o código em teste, e uma pessoa confirma cada ocorrência.
O TS Factory consegue testar dispositivos físicos?
Sim. Os testes chegam ao dispositivo através de uma máquina ao lado dele, que controla a alimentação, a gravação e a consola série. O dispositivo não precisa de agente.
Comece por um teste que repete à mão.Escreva-o uma vez e execute-o em cada build.
Compare os planos na página de preços. Os preços são mensais, em euros.
Iniciar o seu piloto