Enquanto programadores de automação, não sentimos uma sensação de satisfação quando ouvimos a equipa de testes manuais ou o cliente falar sobre os benefícios que obtiveram ao utilizar a automação que desenvolvemos? Para isso, apostamos numa suite de automação de elevada qualidade, que não seja apenas robusta, mas também facilmente adaptável às atualizações necessárias de acordo com quaisquer alterações nos requisitos empresariais ou técnicos. A manutenção deve ser fácil — é algo que estamos constantemente a recordar a nós próprios. Quais são as formas de garantir isto?
Entre as várias formas de garantir a elevada qualidade de uma suite de automação de testes, uma delas consiste em garantir a reutilização — não apenas através da reutilização de passos de teste utilizados frequentemente, mas também da reutilização de objetos de interface do utilizador utilizados frequentemente. Neste artigo, explicarei como podemos utilizar repositórios de objetos para melhorar a reutilização, reutilizando objetos num projeto de automação de testes de interface do utilizador.
- O que é um repositório de objetos nos testes de automação?
- Porque é importante?
- Boas práticas a seguir ao utilizar repositórios de objetos
- Como criar repositórios de objetos (exemplos)
O que é um repositório de objetos nos testes de automação?
Quando começamos a conceber uma suite de automação de testes, a maioria de nós garante que não está a reescrever blocos de código. Para isso, criamos funções reutilizáveis e disponibilizamos os blocos de código reutilizáveis em bibliotecas de código. No entanto, já reutilizou objetos de interface do utilizador utilizados frequentemente? Se não, deixe-me explicar como o pode fazer utilizando um repositório de objetos como base.
Um repositório de objetos é uma coleção de objetos de interface do utilizador normalmente associados entre si. Isto não só melhora a reutilização, como também garante a fiabilidade e a gestão dos elementos da interface do utilizador na suite de automação.
Ao criar os scripts de automação de testes, teria associado passos dos scripts de teste a cada um destes objetos de interface do utilizador. Por exemplo, –
- Introduzir texto num objeto de interface do utilizador do tipo caixa de texto
- Obter o texto de um objeto de interface do utilizador do tipo etiqueta
- Clicar no objeto de hiperligação ... e assim por diante.
Agora, como pode melhorar a reutilização reutilizando os objetos de interface do utilizador nos quais os seus scripts trabalham?
Bem, se a ferramenta de automação de testes que está a utilizar tiver um “repositório de objetos”, é fácil. Utilizando um repositório de objetos, pode reunir os objetos de interface do utilizador e adicionar, eliminar, gerir ou atualizar esses objetos a partir do repositório de forma organizada. Pode, eventualmente, reutilizar os objetos através de referências.
Vamos analisar uma situação em que não utilizou um OR na sua suite de automação de testes. Nesse caso, para scripts de automação de testes separados que utilizam o mesmo componente da interface do utilizador, teria de adicionar várias cópias do mesmo objeto de interface do utilizador a cada um dos scripts de teste para realizar operações sobre ele.
Agora, vamos considerar uma situação em que utilizamos um OR. Nesse caso, teria uma única localização/repositório onde armazenaria os objetos de interface do utilizador. Assim, em cada script de teste que necessitasse de operar sobre o mesmo objeto/componente da interface do utilizador, este seria associado ao mesmo objeto de interface do utilizador armazenado no OR. Existe apenas uma cópia do objeto de interface do utilizador na suite de testes, com vários scripts de teste a referenciar/chamar o mesmo objeto de interface do utilizador. E é aqui que a reutilização entra em ação!
Have an account? Log In
Porque é importante?
A minha primeira experiência com a utilização de um OR foi quando o utilizei na ferramenta IBM Rational Functional Test Automation. Desde então, sempre que aprendo a utilizar uma nova ferramenta, procuro verificar se essa ferramenta dispõe ou não da funcionalidade de OR.
A primeira vez que utilizei um OR foi quando a nossa equipa estava a automatizar uma extensa consola Web de administração, com várias páginas. Tínhamos mais de 100 casos de teste para automatizar. Se não tivéssemos utilizado o OR, teria sido um enorme desafio automatizá-los. Analisámos a situação e concluímos que a suite de automação de testes que pretendíamos criar era o caso ideal para utilizar um OR.
As razões?
1. Cada um dos casos de teste que estávamos a automatizar tinha vários subfluxos em comum e, por isso, tinha componentes de interface do utilizador associados em comum.
Como existiam subfluxos comuns, era evidente que havia objetos de interface do utilizador comuns nos cenários. Não queríamos adicionar cópias dos mesmos objetos de interface do utilizador repetidamente, por isso decidimos reutilizá-los.
Por exemplo, um conjunto de casos de teste teria de navegar pelas mesmas hiperligações do menu de navegação antes de executar um conjunto de passos. Assim, planeámos ter um repositório com o objetivo exclusivo de armazenar e gerir todas as hiperligações de navegação. Dessa forma, conseguimos reutilizar as hiperligações do menu de navegação num ficheiro OR.
2. Fomos informados de que, no futuro, poderiam ocorrer situações de atualização da interface do utilizador — ao nível de hiperligações, etiquetas, etc.
Por isso, queríamos garantir que, quando ocorresse uma atualização deste tipo na interface do utilizador, a suite de automação de testes pudesse adaptar-se facilmente à alteração e que qualquer esforço de manutenção fosse rápido e simples.
Foi aqui que o OR veio em nosso auxílio: não tivemos de efetuar alterações aos repositórios de objetos da interface do utilizador em cada cópia do mesmo objeto de interface do utilizador. Sempre que ocorria uma alteração, bastava atualizar o objeto associado no OR e os scripts de teste eram executados de acordo com o objeto de interface do utilizador atualizado.
3. Tivemos de criar um conjunto de automatização de testes com mais de 100 scripts num mês!
Foi aqui que surgiu outra vantagem de utilizar um OR: ao adotarmos a abordagem de criar um OR, sem que todos tivéssemos de voltar a adicionar os mesmos objetos da IU, poupámos tempo. Criámos um OR bem organizado e tudo o que tivemos de fazer foi desenvolver o nosso código com base nos objetos que tínhamos organizado no OR.
Concentrámo-nos no objetivo do caso de teste e na lógica empresarial dos casos de teste, em vez de perdermos tempo a reinventar a roda ao adicionar objetos para cada script de teste. Poupámos tempo e, no final, entregámos o conjunto de automatização de testes dentro do prazo previsto de um mês!
Melhores práticas a seguir ao utilizar repositórios de objetos
Agora que já conhece situações em que um repositório de objetos da IU seria útil, não quer saber o que o faz funcionar?
1. Enquanto equipa, definam um objetivo comum de reutilização. Em conjunto, compreendam por que razão isso pode ajudar a sua equipa de automatização, a equipa de testes manuais e, por fim, o cliente.
2. Durante o desenvolvimento do conjunto de automatização de testes, mantenham-se sempre alinhados enquanto equipa e informados sobre os objetos que estão a criar. Definam um conjunto de regras de agrupamento e convenções de nomenclatura que todos irão cumprir. Quando começarem, podem elaborar um plano sobre a forma como pretendem organizar e armazenar cada um dos ficheiros OR. Por exemplo, objetos do menu de navegação num ficheiro OR, objetos da IU da página de início de sessão noutro ficheiro OR, etc. Também podem decidir as convenções de nomenclatura dos objetos, para que sejam fáceis de encontrar.
3. Certifiquem-se de que dão aos objetos da IU nomes legíveis, fáceis de encontrar e de associar. Dêem aos objetos da IU nomes que permitam a qualquer outra pessoa que consulte o repositório da IU com a intenção de o atualizar encontrar facilmente o objeto da IU. No exemplo abaixo, apresentarei uma situação deste tipo.
Como criar repositórios de objetos (exemplos)
Vejamos agora, na prática, como pode começar rapidamente a utilizar repositórios de objetos. Ferramentas como UFT, IBM RFT, UiPath Test Automation Suite e Power Automate incluem repositórios de objetos. Por isso, por que esperar? Acredite em mim, é extremamente fácil!
Eis um exemplo em que criei um OR relacionado com o site da QAL:
Observe a IU acima – agrupei todos os elementos associados à realização de ações nos elementos da IU de início de sessão, uma vez que seriam comuns a vários casos de teste. Em seguida, agrupei as ligações de navegação. Se registarmos estes objetos num grupo, quando todos os scripts de teste utilizarem este grupo de objetos de ligação no início de cada caso de teste, estes objetos poderão ser reutilizados em vez de serem novamente adicionados ao repositório
Exemplo de utilização do repositório de objetos no UiPath
Eis o aspeto do repositório de objetos na ferramenta UiPath:
Neste exemplo de repositório de objetos, organizei os objetos da “Página de início de sessão” num conjunto e as “Ligações de navegação principais” noutro conjunto. Assim, se tivesse de criar vários scripts de teste para testar a Página de início de sessão, todos os scripts de teste “chamariam” os mesmos objetos que tinha colocado na “Página de início de sessão”.
More Articles
- 10 Melhores Serviços de Testes Automatizados Analisados em 2026
- 10 melhores ferramentas de gestão de testes de código aberto analisadas em 2026
- Análise do QMetry 2026: Prós, Contras, Funcionalidades e Preços
- Avaliação da Tricentis 2026: vantagens, desvantagens, funcionalidades e preços
- 12 Melhores Certificações de Testes Automatizados para 2026
Exemplo de utilização do repositório de objetos no PowerAutomate
Eis o aspeto do repositório de objetos na ferramenta PowerAutomate:
Como mencionei anteriormente, a chave para a reutilização passa também por garantir que atribui aos objetos nomes que lhe permitam encontrá-los facilmente mais tarde. Observe o objeto da IU “meprmath_quiz”. Ao contrário dos outros campos, não conseguimos identificar facilmente a que objeto da IU se refere. Assim, num caso como o acima, embora, quando adicionei o objeto da IU para a caixa de texto “quiz”, o nome do campo apresentado tenha sido “meprmath_quiz”, poderíamos talvez atribuir-lhe o nome “login_add” ou semelhante, para tornar o objeto fácil de localizar durante a automatização e a manutenção do OR.
Conclusão
Então, como está a utilizar o OR na sua ferramenta favorita de automatização de testes? Gostaríamos muito de saber.
Espero que este artigo o ajude a compreender como o OR ajuda a equipa a longo prazo. Temos a sorte de viver numa era em que a maioria das ferramentas de automatização de testes tem a funcionalidade OR disponível. Por isso, tudo o que tem de fazer é explorar o seu funcionamento na sua ferramenta favorita!
Aprendeu algo novo neste artigo? Se gostaria de ler mais artigos deste tipo, não se esqueça de subscrever o boletim informativo da QA Lead!
Artigos relacionados:
Lista de ferramentas relacionada: SOFTWARE DE TESTES DE DESEMPENHO PARA EQUIPAS DE QA
Também vale a pena consultar:
