Minha abordagem ao teste de GUI está evoluindo, assim como o consenso do setor. Mas acho que algumas técnicas importantes estão começando a surgir.
Eu uso uma ou mais dessas técnicas, dependendo da situação (por exemplo, que tipo de GUI é, com que rapidez precisa ser criada, quem será o usuário final etc.).
Teste manual. Você sempre tem a GUI em execução enquanto trabalha no código e garante que ela esteja sincronizada com o código. Você testa e testa manualmente novamente a parte em que trabalha, alternando entre o código e o aplicativo em execução. Toda vez que você conclui uma parte significativa do trabalho, você faz um teste geral para toda a tela ou área do aplicativo, para garantir que não haja regressões.
Teste de unidade. Você escreve testes para funções ou pequenas unidades de comportamento da GUI. Por exemplo, seus gráficos podem precisar calcular diferentes tons de uma cor com base em uma cor 'base'. Você pode extrair esse cálculo para uma função e escrever um teste de unidade para ele. Você pode procurar por uma lógica como essa na GUI (especialmente lógica reutilizável) e extraí-la em funções discretas, que podem ser mais facilmente testadas em unidade. Mesmo comportamentos complexos podem ser extraídos e testados dessa maneira - por exemplo, uma sequência de etapas em um assistente pode ser extraída para uma função e um teste de unidade pode verificar se, dada uma entrada, a etapa correta é retornada.
Explorador de componentes. Você cria uma tela 'explorer' cuja única função é mostrar cada um dos componentes reutilizáveis que compõem sua GUI. Essa tela fornece uma maneira rápida e fácil de verificar visualmente que cada componente tem a aparência e a sensação corretas. O explorador de componentes é mais eficiente do que passar manualmente por todo o aplicativo, porque A) você só precisa verificar cada componente uma vez e B) não precisa navegar profundamente no aplicativo para ver o componente, basta visualizar e verifique imediatamente.
Teste de automação. Você escreve um teste que interage com a tela ou componente, simulando cliques do mouse, entrada de dados etc., afirmando que o aplicativo funciona corretamente, dadas essas manipulações. Isso pode ser útil como um teste de backup extra, para capturar possíveis erros que outros testes podem perder. Costumo reservar testes de automação para as partes da GUI mais propensas a quebrar e / ou altamente críticas. Peças onde eu quero saber o mais cedo possível se algo quebrou. Isso pode incluir componentes interativos altamente complexos, vulneráveis a interrupções ou telas principais importantes.
Teste de diferença / instantâneo. Você escreve um teste que simplesmente captura a saída como uma captura de tela ou como código HTML e a compara com a saída anterior. Dessa forma, você será alertado sempre que a saída for alterada. Testes difíceis podem ser úteis se o aspecto visual da sua GUI for complexo e / ou sujeito a alterações; nesse caso, você deseja obter um feedback rápido e visual sobre o impacto de uma determinada alteração na GUI como um todo.
Em vez de usar intensamente todos os tipos de testes possíveis, prefiro escolher a técnica de teste com base no tipo de coisa em que estou trabalhando. Então, em um caso, extrairei uma função simples e a testo na unidade, mas em outro caso, adicionarei um componente ao explorador de componentes, etc. Depende da situação.
Não achei a cobertura de código uma métrica muito útil, mas outros podem ter encontrado um uso para ela.
Eu acho que a primeira medida é o número e a gravidade dos bugs. Sua primeira prioridade é provavelmente ter um aplicativo que funcione corretamente. Se o aplicativo funcionar corretamente, deve haver poucos ou nenhum erro. Se houver muitos ou graves erros, presumivelmente, você não está testando ou seus testes não são eficazes.
Além de reduzir bugs, existem outras medidas, como desempenho, usabilidade, acessibilidade, capacidade de manutenção, extensibilidade etc. Elas diferem dependendo do tipo de aplicativo que você está construindo, dos negócios, do usuário final etc.
Tudo isso é baseado em minha experiência e pesquisa pessoal, além de uma excelente descrição dos testes de interface do usuário de Ham Vocke .