Safety-Critical Systems: Como Testar Software

Galera, imagina o seguinte cenario: voce da deploy numa sexta-feira e o sistema cai. O que acontece? O usuario reclama, voce faz rollback, conserta na segunda. Agora imagina que em vez de um SaaS, voce ta deployando o software de freio de um carro a 120 km/h. Rollback nao e opcao.

E exatamente essa a diferenca entre software comum e safety-critical software. Quando falha, nao e ticket no Jira — e pessoa no hospital. E por isso que industrias como aviacao, medicina e automotivo desenvolvem software de um jeito radicalmente diferente.

Nesse artigo vou explicar o que sao safety-critical systems, as normas que regem cada industria, as tecnicas de teste que usam e — mais importante — o que voce pode copiar pra melhorar seu software comum.

O que sao safety-critical systems

Safety-critical system e qualquer sistema cuja falha pode resultar em morte, lesao grave, dano ambiental significativo ou perda economica catastrofica. A classificacao nao depende da complexidade do software — depende da consequencia da falha.

Cada industria tem sua escala de criticidade. Os nomes mudam mas o conceito e o mesmo: quanto mais grave a consequencia da falha, mais rigoroso o processo de desenvolvimento.

O nivel de criticidade define tudo: quantos testes precisa, que tipo de cobertura, quantos revisores independentes, se precisa verificacao formal. Software DAL A (aviacao) pode custar ate 100x mais por linha de codigo que software comercial.

As normas que regem cada industria

Cada dominio tem sua norma regulatoria. Nao sao opcionais — se voce quer colocar software dentro de um aviao, dispositivo medico ou carro, precisa seguir a norma correspondente. Sem certificacao, sem produto no mercado.

MC/DC Coverage: o teste que ninguem faz

Voce provavelmente mede cobertura de testes por linhas (statement coverage) ou branches. Em software critico de aviacao, o padrao e MC/DC: Modified Condition/Decision Coverage.

MC/DC exige que cada condicao individual dentro de uma decisao demonstre, de forma independente, que pode afetar o resultado da decisao. Isso e muito mais rigoroso que branch coverage.

// Decisao: if (A && B || C)
// Branch coverage: 2 testes bastam (true e false)
// MC/DC precisa provar que CADA condicao afeta o resultado:
//
// Teste 1: A=true,  B=true,  C=false -> true  (baseline)
// Teste 2: A=false, B=true,  C=false -> false (A mudou resultado)
// Teste 3: A=true,  B=false, C=false -> false (B mudou resultado)
// Teste 4: A=false, B=false, C=true  -> true  (C mudou resultado)
//
// Precisa de N+1 testes onde N = numero de condicoes
// Pra uma decisao com 10 condicoes: 11 testes minimo
// Branch coverage: 2 testes. MC/DC: 11. Grande diferenca.

Na pratica, MC/DC forca voce a testar combinacoes que branch coverage ignora completamente. E justamente nessas combinacoes que os bugs criticos se escondem. O Boeing 737 MAX talvez tivesse pego o problema do MCAS se MC/DC tivesse sido aplicado com rigor na interacao entre sensor e atuador.

Verificacao Formal: prova matematica de que funciona

Testes provam a presenca de bugs — nunca a ausencia. Voce pode rodar um milhao de testes e ainda ter um caso de borda que nao testou. Verificacao formal e diferente: usa matematica pra provar que o software se comporta corretamente em TODOS os inputs possiveis.

Na pratica, verificacao formal e usada em componentes especificos, nao no sistema inteiro (seria caro demais). Exemplos: o microkernel seL4 foi formalmente verificado — provaram matematicamente que a implementacao C corresponde exatamente a especificacao. O driver de criptografia da Amazon s2n-tls usa verificacao formal com SAW.

Voce pode usar TLA+ no seu projeto? Da pra sim. Leslie Lamport (criador do TLA+) projetou a linguagem pra engenheiros, nao pra matematicos. Amazon usa TLA+ pra modelar sistemas distribuidos como DynamoDB e S3. Nao precisa verificar formalmente cada linha de codigo — basta modelar os componentes mais criticos.

Mutation Testing: testando os testes

100% de code coverage nao significa que seus testes sao bons. Significa que cada linha foi executada — nao que cada linha foi verificada. Mutation testing resolve isso: ele modifica seu codigo de proposito e verifica se seus testes detectam a mudanca.

O conceito e simples: troque == por !=, + por -, true por false. Se nenhum teste falhar com essa mudanca, seus testes nao estao verificando aquele comportamento. A mutacao 'sobreviveu' — e sinal de gap nos testes.

// Codigo original
function desconto(preco, percentual) {
  if (percentual > 50) return preco; // limite de 50%
  return preco * (1 - percentual / 100);
}

// Mutacao 1: trocar > por >=
if (percentual >= 50) return preco;
// Se nenhum teste falha, voce nao testa o caso percentual === 50

// Mutacao 2: trocar - por +
return preco * (1 + percentual / 100);
// Se nenhum teste falha, voce nao verifica o resultado do calculo

// Mutacao 3: remover o if
return preco * (1 - percentual / 100);
// Se nenhum teste falha, voce nao testa o limite de 50%

Em software critico, mutation testing e usado pra validar que a suite de testes e boa o suficiente. No seu projeto, vale rodar periodicamente pra encontrar gaps na cobertura que statement coverage nao revela.

Fault Injection: quebrando de proposito

Fault injection e a pratica de introduzir falhas no sistema de proposito pra ver como ele reage. E o oposto de teste funcional: em vez de verificar se funciona, verifica o que acontece quando nao funciona.

Na aviacao, fault injection e obrigatorio. O sistema precisa provar que consegue operar com falhas ativas — sensor defeituoso, link de comunicacao perdido, motor desligado. Em software comercial, Netflix popularizou o conceito com o Chaos Monkey (que desliga servidores aleatorios em producao).

Da pra comecar simples: injete timeout na sua API externa e veja se o sistema reage de forma controlada. Se a resposta for 'nunca testamos isso', voce acabou de encontrar um ponto cego real do seu sistema.

Ferramentas de teste pra software critico

O custo de testar software critico

Tudo tem preco, e teste de software critico e caro. Muito caro. Mas a alternativa e mais cara ainda.

Pra colocar em perspectiva: uma aplicacao DAL A com 100.000 linhas de codigo pode custar entre US$ 500 milhoes e US$ 2.5 bilhoes pra desenvolver e certificar. E por isso que a industria reutiliza codigo certificado sempre que possivel (e por isso que o Ariane 5 reutilizou codigo do Ariane 4 — so que sem re-validar as premissas).

O que devs comuns aprendem com safety-critical

Voce nao precisa certificar seu SaaS como DO-178C DAL A. Mas varias praticas de software critico melhoram qualquer projeto. Aqui vai o que faz sentido adotar:

Nenhuma dessas praticas e cara ou complicada. O dificil e ter a disciplina de fazer sempre. Mas se a industria que protege vidas usa essas praticas, provavelmente fazem sentido pro seu projeto tambem.

Perguntas frequentes

Preciso de certificacao pra vender software medico?

Sim. Nos EUA, a FDA regula software de dispositivo medico sob a IEC 62304. Na Europa, precisa de marcacao CE. A classificacao de risco (Classe I, II ou III) determina o rigor do processo. Software que faz diagnostico ou controla tratamento e Classe II ou III e exige aprovacao pre-mercado.

TLA+ e viavel pra time pequeno?

Sim. TLA+ nao e pra verificar todo o codigo — e pra modelar a parte mais critica do sistema. Um protocolo de consenso, uma maquina de estados complexa, uma logica de deploy. Amazon usa TLA+ com times de 2-4 pessoas modelando componentes especificos. O investimento de aprendizado e de umas 2-4 semanas.

Chaos engineering vale a pena pra startup?

Depende. Se seus clientes toleram downtime, talvez nao seja prioridade. Se seu sistema precisa de alta disponibilidade (fintech, saude, infraestrutura), comecar com fault injection basica cedo evita surpresas depois. Comece simples: teste o que acontece quando o banco cai e quando a API de pagamento retorna timeout.