22 de julho de 2026
Impacto da Implementação do Page Object Model na Qualidade de Testes Automatizados
Beatriz Ereno; Jamile Raquel Regazzo
DOI: 10.22167/2675-6528-202600592
Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
Resumo
A automação de testes de software foi amplamente adotada para aprimorar a qualidade e confiabilidade de aplicações, mas a estruturação inadequada dos testes automatizados frequentemente gerou altos custos de manutenção e baixa estabilidade. Nesse cenário, padrões de projeto como o Page Object Model (POM) foram empregados para otimizar a organização, reutilização e manutenibilidade dos testes de interface. Analisou-se o impacto da implementação do Page Object Model em testes automatizados desenvolvidos em TypeScript com o framework Playwright, com foco no desempenho de execução das suítes de teste. Para isso, conduziu-se um estudo experimental onde cenários de teste equivalentes foram implementados em duas abordagens distintas: com e sem o padrão POM. Os testes foram executados repetidamente em um ambiente controlado, permitindo a coleta de métricas de tempo de execução individual e total das suítes. Os resultados obtidos indicaram que não houve diferença significativa de desempenho entre as arquiteturas analisadas, apresentando variações pequenas e inconsistentes entre as execuções. Concluiu-se que a adoção do POM não impacta de maneira relevante o tempo de execução dos testes automatizados, devendo sua utilização ser orientada principalmente pelos benefícios relacionados à organização e manutenibilidade do código.
Palavras-chave: Automação de testes; Engenharia de software; Page Object Model; Playwright; Qualidade de software.
1. Introdução
A automação de testes de software tem se estabelecido como uma estratégia fundamental para organizações que visam otimizar a qualidade e a confiabilidade de suas aplicações. A adoção dessa prática permite uma significativa redução de retrabalho, proporciona feedback mais rápido sobre falhas nos sistemas e aumenta a cobertura de verificação, mesmo em ambientes de alta complexidade. A automação também otimiza o tempo dos testadores ao delegar tarefas repetitivas para ferramentas especializadas, embora sua implementação inicial exija um investimento considerável de tempo e esforço (Vincenzi et al., 2018).
No entanto, a simples automação não é suficiente para garantir a qualidade desejada. A estruturação inadequada dos testes automatizados frequentemente resulta em altos custos de manutenção e baixa estabilidade, comprometendo a eficácia das validações ao longo do tempo. Um planejamento meticuloso sobre como os testes serão construídos é, portanto, uma etapa crucial para assegurar que os casos de teste possam ser repetidos com facilidade e baixo esforço, mantendo sua relevância e utilidade (Bernardo, 2011).
Nesse contexto, padrões de design como o Page Object Model (POM) surgem como soluções para aprimorar a organização, a reutilização e a manutenibilidade dos testes de interface. O POM promove uma clara separação entre a lógica de interação da interface do usuário e a lógica dos testes, encapsulando os elementos da página e suas funcionalidades em classes dedicadas. Essa abordagem reduz o acoplamento entre as páginas e os casos de teste, resultando em um código mais reutilizável, legível e, consequentemente, mais fácil de manter (Stocco et al., 2015). A principal meta do POM é diminuir o impacto de mudanças na interface sobre os scripts de teste, contribuindo para uma maior estabilidade e manutenibilidade do sistema.
Apesar de sua ampla aceitação e uso, o POM é implementado de maneiras diversas por diferentes equipes de desenvolvimento. Em alguns cenários, a escolha do formato de implementação pode introduzir complexidade desnecessária ou até mesmo dificultar a evolução dos testes. Além disso, a literatura ainda carece de estudos comparativos que analisem o impacto das diferentes formas de aplicar o POM, especialmente no que diz respeito ao desempenho de execução. No ambiente corporativo, a agilidade e o tempo de execução dos testes são fatores críticos, pois influenciam diretamente o tempo de entrega de novas funcionalidades. A preocupação de que um padrão de código com múltiplas camadas possa gerar sobrecarga e impactar negativamente o desempenho dos testes é uma consideração válida para as equipes de desenvolvimento.
A compreensão do real impacto do POM no desempenho é fundamental para que profissionais de testes e desenvolvedores possam tomar decisões informadas sobre a arquitetura de seus testes automatizados. Ao analisar e comparar o tempo de execução de testes com e sem a aplicação do POM, este estudo oferece uma contribuição valiosa para a engenharia de software. Ele auxilia na escolha de abordagens que otimizem tanto a organização do código quanto a eficiência do processo de entrega de software, impactando positivamente o feedback e o ciclo de desenvolvimento.
Diante desse contexto, o presente trabalho teve como objetivo analisar o impacto da implementação do Page Object Model em testes automatizados desenvolvidos em TypeScript com o framework Playwright, com foco no desempenho de execução das suítes de teste, buscando verificar se a aplicação desse padrão pode contribuir para o aumento no tempo de execução de uma suíte de testes automatizados, em comparação com a não aplicação desse padrão.
2. Material e Métodos
A pesquisa foi delineada como um estudo experimental aplicado, com o propósito de comparar a utilização do padrão Page Object Model (POM) em testes automatizados de interface de aplicações web. O objetivo central foi analisar o impacto da implementação do POM no desempenho de execução das suítes de teste, verificando se sua aplicação poderia influenciar o tempo de execução em comparação com a abordagem sem o padrão.
O processo metodológico incluiu o desenvolvimento de uma aplicação web de teste simples, a definição de vinte e três casos de teste, a implementação de duas suítes de testes (com e sem POM), a configuração do ambiente de execução, a execução das suítes, a coleta e organização dos dados, e a análise dos resultados. A aplicação web simulava uma plataforma de gerenciamento de livros com quatro telas principais, escolhidas por suas interações comuns em sistemas web.
Os casos de teste foram planejados para garantir uniformidade entre as duas arquiteturas, assegurando ações idênticas, mas com organizações de código distintas. Uma suíte utilizou o padrão Page Object Model, encapsulando elementos e ações da interface em classes dedicadas, conforme a documentação do Playwright (Playwright, n.d.). A outra suíte implementou os comandos de interação diretamente nos testes.
A equivalência dos cenários de teste foi verificada por revisão manual estruturada, realizada teste a teste. Cada caso foi analisado considerando a sequência de ações, os elementos da interface e as validações. Para o desenvolvimento dessas suítes, empregou-se a linguagem TypeScript em conjunto com o framework Playwright, destinado à automação de testes end-to-end em aplicações web.
A variável independente do experimento foi a aplicação ou não do padrão Page Object Model. A variável dependente analisada foi o tempo de execução das suítes de testes, considerando tanto o tempo total da suíte quanto o tempo de execução de cada caso de teste individualmente.
O ambiente de execução foi configurado para garantir consistência. A aplicação foi executada via Docker, utilizando a imagem oficial do Node.js na versão 20. Os testes foram executados localmente em um sistema operacional Windows 11, com processador Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz (2.11 GHz) e 16 GB de RAM.
A execução dos testes ocorreu utilizando Node.js e o Playwright, exclusivamente com o navegador Chromium e em um único processo, sem paralelismo. Cada suíte de testes, com e sem POM, foi executada dez vezes, totalizando vinte execuções. Essa repetição visou identificar variações pontuais e aumentar a confiabilidade dos resultados por meio do cálculo de médias.
As execuções foram realizadas de forma intercalada, alternando entre as arquiteturas a cada rodada. Essa estratégia foi adotada para mitigar possíveis interferências de fatores como aquecimento do sistema, cache e variações ambientais ao longo do tempo, contribuindo para um maior equilíbrio nas condições experimentais e na validade dos dados coletados.
Durante cada execução, coletaram-se métricas de tempo de execução. Os dados brutos gerados incluíram a data e horário da execução, a arquitetura utilizada, o navegador, o caminho do arquivo, o nome do teste, o status de sucesso ou falha e a duração em milissegundos. Um gerador de relatórios customizado, construído com o framework Playwright, exportou esses dados em formato CSV, que foram organizados em planilhas para análise.
A análise dos resultados foi conduzida com base na comparação das médias e da variação dos tempos de execução, buscando identificar padrões de comportamento e diferenças consistentes entre as arquiteturas. Adotou-se uma abordagem de análise descritiva, sem a aplicação de testes estatísticos inferenciais, devido ao caráter exploratório do estudo e ao escopo limitado do experimento, que utilizou uma aplicação de baixa complexidade.
3. Resultados e Discussão
Os resultados obtidos a partir da execução das suítes de testes automatizados revelaram que não existem diferenças relevantes no tempo de execução entre as abordagens que utilizam e as que não utilizam o padrão Page Object Model (POM). Essa avaliação foi realizada por meio da comparação de valores médios e variações percentuais, sem a aplicação de análises estatísticas inferenciais, devido ao caráter exploratório do estudo e ao escopo limitado do experimento. A hipótese inicial de que o POM poderia influenciar o tempo de execução dos testes automatizados foi, portanto, parcialmente contrariada pelos achados.
A análise foi conduzida em um ambiente controlado, onde múltiplas execuções intercaladas de ambas as arquiteturas foram realizadas. Essa estratégia visou mitigar a influência de variáveis externas, como o aquecimento do sistema, o uso de cache e outras flutuações ambientais, garantindo maior equilíbrio nas condições experimentais. As métricas coletadas incluíram o tempo médio de execução por teste, o tempo total médio por suíte e a variação entre as execuções, que foram posteriormente organizadas para uma análise descritiva detalhada.
Ao observar os tempos totais de execução para cada uma das dez rodadas de testes, verificou-se que as durações para a arquitetura sem POM variaram entre 52005 milissegundos e 54139 milissegundos. Para a arquitetura com POM, os tempos totais de execução ficaram entre 52170 milissegundos e 53793 milissegundos. Esses dados brutos, coletados em milissegundos, já indicavam uma proximidade nos valores, sugerindo que a presença do padrão POM não introduzia uma sobrecarga significativa ou uma melhoria notável no desempenho geral.
A média do tempo de execução para a arquitetura sem POM foi de aproximadamente 52889,6 milissegundos, enquanto a média para a arquitetura com POM foi de cerca de 52699,9 milissegundos. A diferença entre essas médias totalizou 189,7 milissegundos. Essa variação representa menos de 1% do tempo total de execução, o que é considerado insignificante para evidenciar uma vantagem de desempenho de uma arquitetura sobre a outra no contexto deste estudo.
Essa pequena diferença observada entre as médias das execuções não é suficiente para sustentar uma conclusão de superioridade de desempenho de uma arquitetura sobre a outra. É plausível que tais variações estejam associadas a fatores inerentes ao próprio ambiente de execução, como o gerenciamento de memória, a concorrência entre processos do sistema operacional ou pequenas oscilações temporárias. Consequentemente, os resultados não permitem afirmar que a adoção do Page Object Model impacta de forma significativa o tempo de execução dos testes, seja positiva ou negativamente.
A análise detalhada dos tempos de execução por caso de teste individual reforça essa percepção de ausência de um padrão consistente. Dos vinte e três cenários de teste avaliados, aproximadamente metade apresentou tempos de execução ligeiramente menores com a aplicação do POM, enquanto a outra metade demonstrou ser mais rápida na abordagem sem o padrão. Por exemplo, o teste “Lista de leitura – Remover um de vários atualiza contagem” foi 109,5 milissegundos mais rápido sem POM, enquanto “Novo livro – Criação aparece no catálogo” foi 45,8 milissegundos mais rápido com POM.
Essa distribuição desigual das diferenças de tempo entre os casos de teste impede a constatação de um padrão de desempenho claro e consistente que favoreça uma das arquiteturas. Observou-se que testes mais complexos, que envolvem um maior número de ações e interações com a interface, como “Novo Livro – Criação aparece no catálogo” e “Lista de Leitura – Remover um de vários atualiza contagem”, apresentaram tempos de execução significativamente maiores, independentemente da arquitetura utilizada. Isso sugere que a complexidade do cenário e as interações com a interface da aplicação exercem maior influência sobre o tempo de execução do que a estrutura do código de teste.
Os achados deste estudo estão alinhados com a literatura sobre automação de testes, que frequentemente associa o Page Object Model à melhoria da organização, reutilização e manutenibilidade do código. O padrão propõe uma clara separação entre a lógica dos testes e os elementos da interface, encapsulando-os em classes dedicadas. Essa abordagem, conforme destacado pela documentação do Playwright (Playwright, n.d.), favorece a clareza estrutural e a facilidade de manutenção dos testes ao longo do tempo.
A arquitetura orientada a POM prioriza a centralização de elementos e ações em componentes reutilizáveis, o que contribui para a redução da redundância de código e simplifica futuras modificações. Esse princípio está em consonância com as diretrizes da engenharia de software que incentivam a reutilização e a minimização da duplicação de código (Graham et al., 2019). Dessa forma, o POM atua primariamente na organização estrutural do código de testes, e não na lógica de execução em si, o que explica a ausência de impacto significativo no desempenho.
Apesar de o Page Object Model adicionar uma camada extra de abstração ao código, essa camada não altera a quantidade fundamental de ações realizadas durante a execução dos testes, como cliques, preenchimento de campos ou carregamento de páginas. O custo computacional adicional gerado por essa abstração é, portanto, marginal quando comparado ao tempo despendido nas interações diretas com a interface do usuário e o processamento da aplicação. Isso reforça a ideia de que o overhead do POM é mínimo e não impacta a performance de forma perceptível.
Outra possível explicação para a ausência de um impacto negativo significativo no desempenho reside no tamanho e na complexidade da aplicação utilizada no experimento. Por se tratar de uma aplicação de pequeno porte com cenários relativamente simples, o impacto de uma camada de abstração adicional tende a ser menor. Em aplicações mais complexas, que envolvem interações com múltiplos sistemas e bancos de dados, a complexidade pode ser maior, e a literatura aponta que a utilização de técnicas de teste de baixo nível em testes de alto nível pode resultar em casos de teste mais complexos, difíceis de manter e com maior custo associado (Alégroth et al., 2016).
A dependência dos testes de interface em relação à estrutura da aplicação significa que mudanças na interface podem exigir atualizações nos Page Objects. Contudo, o uso do POM centraliza essas alterações em componentes específicos, o que, segundo Coppola et al. (2016), reduz o esforço de manutenção. Os resultados deste estudo confirmam que o padrão não introduz uma sobrecarga significativa na execução dos testes, validando empiricamente suas características de organização e manutenibilidade.
Em síntese, os dados coletados permitiram concluir que a adoção do Page Object Model não influencia de forma significativa o desempenho das suítes de testes automatizados. A decisão pela utilização desse padrão deve, portanto, ser orientada por fatores como a organização do código, a legibilidade e a manutenibilidade, que são cruciais para a sustentabilidade de suítes de testes a longo prazo, em vez de critérios de desempenho de execução.
4. Conclusão
Este trabalho buscou analisar o impacto da implementação do Page Object Model em testes automatizados desenvolvidos em TypeScript com o framework Playwright, com foco no desempenho de execução das suítes de teste. Verificou-se que não houve diferença significativa no tempo de execução entre as abordagens com e sem a aplicação do padrão POM. Os resultados indicaram variações pequenas e inconsistentes entre as execuções, sugerindo que a complexidade dos cenários de teste e as interações com a interface da aplicação exercem maior influência sobre o tempo de execução do que a estrutura do código de teste. Concluiu-se que o custo computacional adicional gerado pela abstração do POM é marginal e não impacta a performance de forma perceptível.
A principal contribuição deste estudo reside em fornecer evidências empíricas que desmistificam a preocupação de que a adoção do Page Object Model possa impactar negativamente o desempenho dos testes automatizados de interface. Isso permite que profissionais de engenharia de software tomem decisões mais informadas, priorizando os benefícios estruturais do POM, como a organização, legibilidade e manutenibilidade do código, que são cruciais para a sustentabilidade de suítes de testes a longo prazo. Contudo, é importante reconhecer que o experimento foi realizado em uma única aplicação de complexidade controlada e em um ambiente específico, o que limita a generalização dos resultados para sistemas mais complexos ou ambientes com maior variabilidade. Sugere-se, para estudos futuros, a ampliação da investigação para diferentes tipos de aplicações e ambientes de execução, além da inclusão de métricas como esforço de manutenção, legibilidade do código e consumo de recursos, para uma compreensão mais abrangente dos impactos do POM.
Referências Bibliográficas
Alégroth, E.; Feldt, R.; Kolström, P. 2016. Maintenance of automated test suites in industry: an empirical study on visual GUI testing. Information and Software Technology 73: 66-80.
Bernardo, P.C. 2011. Padrões de testes automatizados. Dissertação de Mestrado em Ciência da Computação. Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, SP, Brasil.
Coppola, R.; Raffero, E.; Torchiano, M. 2016. Automated mobile UI test fragility: an exploratory assessment study on Android. In: International Workshop on User Interface Test Automation (INTUITEST), 2016, Saarbrücken, Germany. Anais… p. 11-20.
Graham, D.; van Veenendaal, E.; Black, R. 2019. Foundations of Software Testing: ISTQB Certification. 4ed. Cengage Learning, Boston, MA, USA.
Playwright. n.d. Page object models. Disponível em: <https://playwright.dev/docs/pom>. Acesso em: 07 abr. 2026.
Stocco, A.; Leotta, M.; Ricca, F.; Tonella, P. 2015. Why creating web page objects manually if it can be done automatically? In: International Workshop on Automation of Software Test, 2015, Florence, Italy. Anais… p. 1-8.
Vincenzi, A.M.R.; Delamaro, M.E.; Dias Neto, A.C.; Fabbri, S.C.P.F.; Jino, M.; Maldonado, J.C. 2018. Automatização de teste de software com ferramentas de software livre. Elsevier, Rio de Janeiro, RJ, Brasil.
Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq
Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy
