Get Started. It's Free
or sign up with your email address
Rocket clouds
CTAL-TAE by Mind Map: CTAL-TAE

1. Consideram o aumento da complexidade dos testes como algo bom

2. Chamam de "decomposição do SUT" o fator que permite a manipulação do SUT pelo TAS

3. É esperado de um TAE

3.1. Conhecer padrões de codificação, documentação e melhores práticas

3.1.1. Regras AUTOSAR para MathWorks Matlab / Simulink®

3.1.1.1. Arquitetura para Sistemas Automotivos Abertos. Descreve módulos básicos e uma metodologia de desenvolvimento

3.1.2. MISRA para C ou C++

3.1.2.1. Facilitar a portabilidade e a confiabilidade de código no contexto de sistemas embarcados

3.1.3. Padrão de codificação JSF para C ++

3.1.3.1. Should, Will and Shall (obrigatório) são usados para dizer como é uma codificação em C++ que seguem boas práticas

3.1.3.2. * Joint Strike Fighters

3.2. Que tenha habilidades, experiências e especializações em engenharia de software

3.3. Entenda o ciclo de vida de desenvolvimento do software

3.4. Projetar um TAS onde informações possam ser extraídas facilmente ou automaticamente relatadas ao gerenciamento de projetos

3.5. Fornecer insumos para a análise do ROI, fornecendo avaliações técnicas e comparações de diferentes arquiteturas e abordagens de automação de teste com relação ao tempo, custos, esforços e benefícios

3.6. TAE precisa apoiar um TAM nas estimativas, fornecendo boas estimativas para o tempo e a complexidade de um projeto TAA

3.7. abordar questões de usabilidade para um TAS

3.8. Ao perceber que novas features serão implementadas no SUT, solicitar feedback de modeladores de teste com perícia de domínio e determinar se o TAS atual atenderá às necessidades dos novos recursos

4. Atenção total

4.1. Execução automatizada é apenas uma parte da automação de testes

4.2. Comparar resultados, controlar e configurar pré-condições de teste

4.3. Testes de API são testes em código, não de serviços!

4.4. Adoram siglas!

4.5. Testabilidade é o sucesso do projeto

4.6. Em sistemas embutidos, não preciso separar automação de testes do SUT

4.6.1. Dizem que nem todos os fatores de sucesso são necessários

4.7. Na estratégia de testes, olhe pra GUI e API para validar consistência dos resultados

4.8. Consideram viável começar a automação pequena e simples, mesmo para SUTs grandes e complexos

5. Extras

5.1. Falhas de tradução

5.1.1. 1.1. Não fica claro se devo ou não separar o software de teste do SUT

5.1.2. 1.2. Ativar facilmente a solução de problemas na verdade trata-se de troubleshooting, ou seja, quando encontro um erro, deve ser fácil identificar o motivo

5.1.3. 1.2. Rastrar o teste automatizado

5.1.4. 3.2.1. Requisitos de captura necessários para definir um TAA apropriado deveria ser ˜Capturar os requisitos"

5.2. Erros em figuras

5.2.1. Figura 1. Automação de Este ao invés de Geração de Teste

6. Siglas

6.1. SUT é o sistema em teste, ou seja, aquele que estou testando

6.2. TAS é solução de automação de testes

6.3. TAA é arquitetura de automação de testes

6.4. TAE é o engenheiro de automação de testes

6.5. TAF framework de automação de testes

6.6. TAM é o gerente de automação de testes

6.7. gTAA é a arquitetura genérica de automação de testes

6.8. SDLC é o ciclo de desenvolvimento de software

7. Mnemônicos

8. Capítulo 1 (4 páginas)

8.1. Mindset

8.1.1. Testware é usado em todo o ciclo de automação de testes. Ele é mais do que apenas scripts de teste, incluem...

8.1.1.1. Documentação

8.1.1.2. Ambientes

8.1.1.3. Software

8.1.1.4. Dados de teste

8.1.1.5. Software

8.1.2. Um TAF legal possui

8.1.2.1. Facilidade de identificar o motivo da falha, ou seja, facilitar a solução de problemas

8.1.2.1.1. A causa pode ser

8.1.2.2. Relatórios

8.1.2.3. Abordar corretamente o ambiente de testes, ou seja, controle total dele

8.1.2.4. Documentar os casos de teste automatizados, ou seja, o que e como estamos automatizando

8.1.2.5. Fácil de rastrear os casos de teste e métodos

8.1.2.6. Manutenibilidade

8.1.2.7. Casos de testes constantemente atualizados

8.1.2.8. Fáceis de implementar, retirar (quando não forem mais úteis) e alterar

8.1.2.9. Recuperar-se quando uma falha ocorrer e pular pro próximo teste

8.1.3. Objetivos, vantagens e desvantagens

8.1.3.1. Objetivos da Automação: - Custo, - tempo, + frequência, + eficiência, + cobertura e + testes impossíveis de se fazer manualmente

8.1.3.1.1. Tempo real, paralelo e remotos são considerados impossíveis de se fazer manualmente

8.1.3.2. Vantagens da Automação: + Complexidade dos testes, - erros humanos, feedback rápido, + confiança no sistema

8.1.3.3. Desantagens da Automação: + Custos configuração inicial, testers mais técnicos, manutenção dos scripts, scripts ficarem complexos e erros de automação

8.1.4. Fatores de sucesso a longo prazo

8.1.4.1. TAA

8.1.4.1.1. Alinhada com a arquitetura do produto

8.1.4.1.2. Definir requisitos funcionais e não funcionais é o mais importante

8.1.4.1.3. Preza por manutenibilidade

8.1.4.2. Testabilidade

8.1.4.2.1. Desacoplar dados da GUI nos testes de GUI

8.1.4.2.2. Métodos públicos nos testes de API

8.1.4.2.3. Devo começar a automatizar a partir dos componentes com maior testabilidade

8.1.4.2.4. É a chave para o sucesso

8.1.4.2.5. * Requisito não-funcional

8.1.4.3. * Antes do início do projeto, analise todos eles. Isso mostrará as chances de sucesso do projeto.

8.1.5. Estratégia de testes

8.1.5.1. Manutenção e consistência do SUT

8.1.5.2. Devo considerar os custos, benefícios e riscos

8.1.6. Conceitos comuns

8.1.6.1. Há mais que execução automatizada na automação de testes

8.1.6.2. Nem tudo pode ser automatizado

8.1.6.3. Scripts de teste não fazem testes exploratórios

8.1.6.4. Podemos ter tanto código no TAF quanto no SUT

8.1.6.5. Bad smells

8.1.6.5.1. Testes sensíveis a mudança de layout

8.1.6.5.2. Testes sensíveis a alteração de dados criados por outros testes, dependência entre testes

8.1.6.5.3. Testes sensíveis a informações do ambiente, como hora, localicação e etc. Use simuladores, mano!

8.2. Termos

8.2.1. Abordagens de teste

8.2.1.1. Interface pública de código (classe, libs, etc)

8.2.1.2. interface de usuário (GUI, CLI)

8.2.1.3. serviços ou protocolos

9. Dicas de brother

9.1. Quando não entender algo no Syllabus, olhe para a versão americana dele

9.2. Saiba diferenciar: TAS, TAF, TAA e gTAA

9.2.1. TAS é o ambiente de testes e os scripts

9.2.2. TAF é usado para criar um TAS

9.2.3. TAA refere-se a forma com que o TAS foi organizado

9.2.4. gTAA é um modelo de TAA que pode ser usado em muitos TAS

9.3. Decore as 7 camadas do gTAA e seus componentes. Além de sua imagem!

9.3.1. Camadas do gTAA.png

10. Capítulo 2 (5 Páginas)

10.1. Atenção total

10.1.1. Geralmente as TAT não atendem 100% às necessidades

10.1.2. Testabilidade é o sucesso do projeto

10.1.3. Níveis de intrusão fazem testes ficarem mais simples mas aumentam custos e riscos

10.1.4. A maior parte da automação deve começar antes do SUT estar disponível. Nesse caso, o TAE deve especificar as interfaces que ele precisa e estimar o esforço e tempo

10.1.5. TAE precisa especificar ao desenvolvedor quais são as interfaces necessárias para automação

10.1.6. Interfaces alternativas ou personalizadas são aquelas construídas para possibilitar testes antes que as reais sejam construídas.

10.1.7. Lembre-se de verificar a compatibilidade do SUT com o TAS desde o início

10.2. Mindset

10.2.1. O que influencia a automação?

10.2.1.1. Interfaces do SUT

10.2.1.1.1. * Como controlo o SUT através da automação de testes

10.2.1.2. Softwares de Terceiros

10.2.1.2.1. Podemos usar uma API caso a automação faça sentido

10.2.1.3. Níveis de intrusão

10.2.1.3.1. Nenhum: Consigo automatizar testes sem alterar o SUT Médio: Preciso alterar o SUT para conseguir automatizar Alto: Uso de hardware

10.2.1.3.2. * Falhas podem surgir pelas alterações feitas no SUT para possibilitar a automação, não aconteceriam em produção * Quanto maior o nível de intrusão, mais fácil é de automatizar

10.2.1.4. Tamanho e complexidade do SUT

10.2.1.4.1. Consideram viável começar a automação pequena e simples, mesmo para SUTs grandes e complexos

10.2.1.5. Arquitetura do SUT

10.2.1.5.1. Exige diferentes TAS, ou TAS híbridos (ex. TAS que suporta Python e C++, ou Web e Desktop)

10.2.2. Antes do SUT estar pronto

10.2.2.1. Se já conheço os requisitos funcionais e não funcionais, elenco o que irei automatizar a partir deles

10.2.2.2. Durante a arquitetura e a modelagem técnica, devo fazer testes na interface

10.2.3. Testabilidade

10.2.3.1. Desenvolvedor implementa isso, mas o TAE pode ajudar.

10.2.3.2. Modelagem disso consiste em

10.2.3.2.1. Observabilidade, ou seja, a interface possui elementos para validar se o SUT comporta-se como esperado

10.2.3.2.2. Controle (ou, capacidade), a interface é visível ao TAS e ele a pode controlar

10.2.3.2.3. Arquitetura claramente definida, o TAS tem acesso a todos os níveis do SUT

10.2.3.3. Interfaces usadas para testar aplicações ainda não prontas podem ser Planilhas, Mocks, Controladores e Simuladores

10.2.4. Seleção de ferramentas

10.2.4.1. É o TAM que faz isso, com ajuda do TAE

10.2.4.2. O que o TAE faz

10.2.4.2.1. Identifica, analisa e estima

10.2.4.2.2. Recomenda qual é a TAT mais apropriada

10.3. Termos

10.3.1. Quando não há interfaces disponíveis ao usuário (por exemplo, durante a construção de um componente). Criamos interfaces personalizadas, chamamos isso de Ganchos de Teste.

10.3.2. Eficácia é achar o bug certo, eficiência é fazer com pouco esforço

11. Capítulo 3 (21 páginas)

11.1. Mindset

11.1.1. gTAA é uma TAA que tornou-se um modelo que pode ser usada em um ou muitos TAS ;)

11.1.1.1. Define os componentes, conceitos, interfaces e recursos para usuários de um TAS

11.1.1.2. Camadas de um gTAA

11.1.1.2.1. Se essas camadas forem manuais, não necessitamos abordar essas camadas

11.1.1.2.2. Se essas camadas forem automatizadas, então usamos

11.1.2. Um TAS e seu respectivo TAA deve obedecer ao SOLID

11.1.2.1. Responsabilidade única

11.1.2.1.1. Quem loga é um componente diferente do que executa os testes, por exemplo

11.1.2.2. Extensão

11.1.2.2.1. Um componente está aberto a extensão mas fechado à modificação

11.1.2.2.2. Se tenho que tratar 3 arquivos diferentes com IFs, quando tiver um quarto, terei de criar mais um IF. Mas se fizer um laço que leia todos os arquivos existentes, posso adicionar quantos eu quiser, sem mexer no código inicial!

11.1.2.3. Substituição

11.1.2.3.1. Um componente pode ser substituído por outro desde que esse outro tenha o mesmo comportamento

11.1.2.4. Segregação de componentes

11.1.2.4.1. É melhor ter componentes mais específicos do que um componente geral multiuso

11.1.2.5. Inversão de dependência

11.1.2.5.1. Um componente deve depender de abstrações, não de objetos reais

11.1.2.5.2. Construtor espera receber uma interface de um objeto, então posso passar qualquer objeto que implemente aquela interface!

11.1.3. Modelagem do TAA

11.1.3.1. Requisitos de captura necessários para definir um TAA apropriado

11.1.3.1.1. Abordagem de testes

11.1.3.2. Comparar e contrastar diferentes abordagens de projeto / arquitetura

11.1.3.2.1. TAE deve olhar para as camadas do gTAA

11.1.3.3. Identificar áreas onde a abstração pode trazer benefícios

11.1.3.3.1. Permite a independência de fornecedores, facilidade de uso do TAS por não técnicos e etc.

11.1.3.4. Entenda as tecnologias SUT e como elas se interconectam com o TAS

11.1.3.4.1. Paradigmas de interação TAS a SUT, quando em API ou Serviços

11.1.3.5. Compreender o ambiente SUT

11.1.3.5.1. Podem ser softwares ou hardwares, que interagem com usuários, outros softwares ou mesmo com o ambiente.

11.1.3.5.2. TAS deve adaptar-se e simular as condições que validem as saídas do SUT dado uma entrada qualquer

11.1.3.6. Tempo e complexidade para uma determinada implementação de arquitetura de testware

11.1.3.6.1. Estimativa baseada em analogia, como pontos de funções, estimativa de três pontos, Wide Band Delphi e estimativa de testes

11.1.3.6.2. Estimativa pelo uso de estruturas de divisão de trabalho, como as encontradas em software de gerenciamento ou modelos de projeto

11.1.3.6.3. Estimativa paramétrica, como Modelo de Custo Construtivo (COCOMO)

11.1.3.6.4. Estimativas baseadas em tamanho, tais como Análise de Ponto de Função, Análise de Ponto de Estória ou Análise de Caso de Uso

11.1.3.6.5. Estimativas de grupo, como o Planning Poker

11.1.3.7. Facilidade de uso para uma determinada implementação de arquitetura de testware

11.1.3.7.1. Modelagem orientada ao testador

11.1.3.7.2. Facilidade de utilização do TAS

11.1.3.7.3. Suporte do TAS para outras funções no desenvolvimento de software, garantia de qualidade e gerenciamento de projetos

11.1.3.7.4. Organização eficaz, navegação e busca dentro ou com o TAS

11.1.3.7.5. Documentação útil, manuais e texto de ajuda para o TAS

11.1.3.7.6. Relatórios práticos por e sobre o TAS

11.1.3.7.7. Desenhos iterativos para abordar o feedback do TAS e insights empíricos

11.2. Termos

11.2.1. Analistas de Teste

11.2.2. Analisadores de Teste Técnicos

11.2.3. Configuração de teste -> Local e Configuração de teste virtual -> Nuvem

11.3. Atenção total

11.3.1. TAE é quem projeta, desenvolve, implementa e mantém o TAS

11.3.2. gTAA são conceitos, etapas e abordagens recorrentes na automação de testes

11.3.3. Entenda todos os pontos do SOLID

11.3.4. gTAA não predefine nenhum método, tecnologia, ferramenta ou abordagem de desenvolvimento (OO, Estruturada, etc)

11.3.5. Na Execução, considera a possibilidade de injeção de falha no SUT

11.3.6. Geração automática baseada em permutação pura e simples não é recomendada. Use riscos, etc

11.3.7. Tudo ter que ser analisado cuidadosamente, óbvio

11.3.8. SUTs podem ser: - um software - um software autônomo que funciona apenas em relação a outro software - um hardware - um componente ambiental (também hardware)

11.3.8.1. O TAS pode, nesses casos, simular os ambientes dos hardwares ou os usuários dos softwares

11.3.9. Estimativa paramétrica, como COCOMO, é baseado em linhas de código. Possui três formas de medir: básico, intermediário e avançado

11.3.10. Recomendam ter um caso de teste manual e um caso de teste automatizado para aumentar a abstração

11.3.11. Recomendam o uso de ferramentas que geram modelos a partir de scripts automatizados

11.3.12. Validação completa e exata são idênticas, mas a exata tem mais detalhes

11.3.13. Script linear é gravação sem alteração do scripts. Já o estruturado é reutilizável.

11.3.14. No DDT scripts que consomem um arquivo externo é chamado "controle"

11.3.15. Acreditam que os arquivos do DDT permitem omitir os "procedimentos de teste negativos"

11.3.16. Nos testes baseados em palavras-chave os arquivos do DDT são chamados de ‘arquivos de definição de teste'.

11.3.17. Testes baseados em modelo são gerados automaticamente, não são executados automaticamente.

11.3.18. Todas as interfaces precisam ser testáveis

11.3.19. Acreditam que o código do TAA deve ser versionado junto com o do SUT para "seguir o mesmo modelo de revisão"

11.3.20. Acreditam que o TAS precisa ser testado, com testes de capacidade básica (interação entre SUT e TAS)

11.3.21. Os aspetos de reuso são estabelecidos antes do TAA eser definido

11.4. Abordagens para Automação de Testes

11.4.1. Criar sequências de teste

11.4.1.1. Casos de teste diretamente como scripts

11.4.1.1.1. Captura e reprodução pode ser usada aqui

11.4.1.2. Procedimentos posteriormente convertidos em scripts de teste manualmente

11.4.1.2.1. Script de teste estruturado

11.4.1.3. Procedimentos posteriormente convertidos em scripts de teste automaticamente

11.4.1.3.1. Script de teste estruturado

11.4.1.4. Ferramenta gera procedimentos ou extrai scripts de testes a partir de modelos de teste, automaticamente

11.4.1.4.1. Testes baseados em modelos

11.4.1.5. * 1 tem menos e 4 tem mais abstração e automação

11.4.2. Abordagens

11.4.2.1. Abordagem de captura e reprodução

11.4.2.1.1. Ferramentas são usadas para capturar interações com o SUT

11.4.2.1.2. Valida-se os resultados da execução

11.4.2.1.3. Prós e contras

11.4.2.2. Scripts lineares

11.4.2.2.1. Prós e contras

11.4.2.2.2. Não partem de casos de teste, os testers "conhecem" o procedimento. Faço os passos enquanto a ferramenta gerar o script a partir das ações e tira screenshots.

11.4.2.2.3. Ferramentas executam o script gerado

11.4.2.2.4. Posso adicionar verificações como comentários no código ou usar a linguagem de programação pra isso

11.4.2.3. Script estruturado

11.4.2.3.1. Prós e contras

11.4.2.3.2. Em comparação ao script linear, essa tem uma biblioteca de scripts. E seus scripts são reutilizáveis.

11.4.2.4. Teste orientado a dados

11.4.2.4.1. Prós e contras

11.4.2.4.2. Usa um script estruturado, chamado "controle", que consome um arquivo de dados externo e executa o teste "n" vezes, onde "n" é o número de linhas do arquivo.

11.4.2.5. Testes por palavras-chave

11.4.2.5.1. Prós e contras

11.4.2.5.2. Baseia-se na técnica de script orientada a dados.

11.4.2.5.3. Os arquivos são chamados ‘arquivos de definição de teste'.

11.4.2.5.4. Existe apenas um script de controle

11.4.2.5.5. Os arquivos de palavras-chave também conterão instruções de alto nível (as palavras-chave)

11.4.2.5.6. As palavras-chave devem ser escolhidas para serem significativas para o Analista de Testes além de representar interações de negócios de alto nível com um sistema.

11.4.2.5.7. Os analistas de teste podem adicionar testes "automatizados" simplesmente especificando-os em um arquivo de palavras-chave

11.4.2.6. Script direcionado a processo

11.4.2.6.1. Prós e contras

11.4.2.6.2. Representam casos de uso do SUT

11.4.2.6.3. Fluxos de alto-nível

11.4.2.7. Teste baseado em modelo

11.4.2.7.1. Prós e contras

11.4.2.7.2. Geração automática de casos de teste. Não executam eles automaticamente.

11.4.2.7.3. s

11.5. Considerações Técnicas sobre o SUT

11.5.1. Interfaces do SUT

11.5.1.1. Precisam ser testáveis: Observabilidade, Controle e Arquitetura clara

11.5.2. Dados SUT

11.5.2.1. Podem ser de um arquivo de configuração, de um usuário ou de um sistema externo

11.5.2.2. Devem ser configuráveis, para que tenhamos a possibilidade de altera-los e testar melhor

11.5.3. Configurações SUT

11.5.3.1. Pode ser uma configuração de teste ou configuração de teste virtual

11.5.3.2. Também pode-se usar simuladores e/ou emuladores de componentes

11.5.4. Padrões SUT e configurações legais

11.5.4.1. Respeitar os requisitos legais e/ou de normas de modo

11.5.4.2. Exemplo: Requisitos de privacidade para os dados de teste ou requisitos de confidencialidade que afetam as capacidades de log

11.5.5. Ferramentas e ambientes de ferramentas usados para desenvolver o SUT

11.5.5.1. Olhar para ferramentas do SUT e ver se conseguimos compatibilidade/rastreabilidade

11.5.6. Testar interfaces no produto de software

11.5.6.1. Não desabilitar as interfaces de teste, elas podem ajudar no debug de falhas em prod. Cuidado com riscos de segurança relacionados a elas.

11.6. Considerações para processos de desenvolvimento e qualidade

11.6.1. Requisitos de controle e execução -> Teste interativo, a execução do teste em modo batch ou a execução de teste totalmente automatizada

11.6.2. Requisitos de relatório -> Relatórios de teste fixos, parametrizados ou definidos em diferentes formatos e layouts

11.6.3. Papéis e direitos de acesso -> Fornecer um papel e sistema de direitos de acesso

11.6.4. Panorama de ferramenta estabelecida -> Código do TAA deve ser versionado junto com o do SUT

11.7. Desenvolvimento do TAS

11.7.1. Observações

11.7.1.1. Segue o mesmo flow de um prodjeto de desenvolvimento, inclusive com revisões

11.7.1.2. O SUT é afetado pela estratégia de testes, quando precisa ser alterado para testabilidade, por exemplo

11.7.2. Ciclo de Vida do TAS (Baseado no SDCL)

11.7.2.1. Análise

11.7.2.1.1. Requisitos devem ser coletados antes

11.7.2.2. Desenho

11.7.2.3. Desenvolvimento

11.7.2.4. Teste

11.7.2.4.1. Através de testes de capacidade básicos

11.7.2.5. Implantação

11.7.2.6. Evolução

11.7.2.6.1. Adição de testes ou manutenção dos já existentes quando o SUT muda

11.7.3. Compatibilidade TAS/SUT

11.7.3.1. Equipe

11.7.3.1.1. Membros com mesmo mindset e prontos a trabalhar com conjunto

11.7.3.2. Processo

11.7.3.2.1. Processos iguais com sincronização da automação e desenvolvimento do software

11.7.3.3. Tecnologia

11.7.3.3.1. Tecnologias semelhantes ou, quando isso não é possível, o uso de adaptadores, invólucros ou outras formas de intermediários

11.7.3.4. Ferramentas

11.7.3.4.1. Uso das mesmas ferramentas para facilitar a gestão do processo

11.7.4. Sincronização TAS/SUT

11.7.4.1. Requisitos

11.7.4.1.1. Que abordam o desenvolvimento do SUT

11.7.4.1.2. Que abordam os testes do SUT

11.7.4.2. Fases de desenvolvimento

11.7.4.2.1. Para ter o TAS pronto quando necessário para testar o SUT

11.7.4.3. Rastreamento de defeitos

11.7.4.3.1. Pois os defeitos podem estar relacionados

11.7.4.4. Evolução SUT/TAS

11.7.4.4.1. Qualquer alteração aplicada a um SUT ou a um TAS pode afetar o outro

11.7.4.4.2. Abordagens SUT/TAS

11.7.4.4.3. Abordagens SUT/TAS/Testes manuais

11.7.4.5. Reutilização do TAS

11.7.4.5.1. Reaproveitamento de seus artefatos

11.7.4.5.2. Os requisitos para reutilização resultam da relevância dos artefatos TAS para as outras variantes

11.7.4.5.3. Os aspetos de reuso são estabelecidos antes do TAA eser definido

11.7.4.5.4. TAS pode ajudar a aumentar a capacidade de reutilização, por seguir, atualizar, revisar, documentar os artefatos e corrigir falhas

11.7.4.5.5. Reutilização é principalmente uma questão para o TAA

11.7.5. Apoio a outros sistemas-alvo

11.7.5.1. Refere-se à capacidade do TAS para testar diferentes configurações de um produto de software

11.7.5.2. Impactam o TAS em qualquer nível de teste

11.7.5.2.1. Número e interligação de componentes do SUT

11.7.5.2.2. Ambientes (software e hardware) nos quais os componentes do SUT são executados

11.7.5.2.3. Tecnologias, linguagens de programação ou sistemas operacionais utilizados para implementar os componentes do SUT

11.7.5.2.4. Bibliotecas e pacotes que os componentes do SUT estão usando

11.7.5.3. Nível de componente e integração

11.7.5.3.1. Ferramentas usadas para implementar os componentes do SUT

11.7.5.4. A capacidade de um TAS para testar diferentes configurações de produto de software é determinada quando o TAA é definido

11.7.5.5. A manutenção e melhorias para esta variabilidade é uma preocupação de longo prazo no ciclo de vida do TAS

12. Capítulo 8 (4 páginas)

12.1. Opções para melhorar a automação de teste

12.1.1. scripts

12.1.1.1. simples estruturada às abordagens baseadas em dados e às mais sofisticadas orientadas por palavras-chave

12.1.1.2. Isso aumenta a capacidade de manutenção do testware

12.1.1.3. Esperas

12.1.1.3.1. Espera em um hard-coded, fixo

12.1.1.3.2. Espera dinâmica por sondagem, inteligente

12.1.1.3.3. assinar o mecanismo de evento do SUT

12.1.2. verificação

12.1.2.1. adote um conjunto de métodos de verificação padrão para uso em todos os testes automatizados

12.1.3. arquitetura

12.1.3.1. alterar a arquitetura para apoiar melhorias da testabilidade do SUT.

12.1.4. pré e pós-processamento

12.1.4.1. pré- processamento (configuração) e pós-processamento (desmontagem). Isso economiza as tarefas sendo

12.1.5. documentação

12.1.5.1. Recursos não usados devem ser eliminados, os não conhecidos ainda devem seu implementados

12.1.6. suporte a ferramentas

12.1.6.1. Ao atualizar o SUT, execuat en==c==ci

12.1.7. Execução de Teste

12.1.7.1. Quando o teste demora muito tempo, pode ser necessário testar simultaneamente em sistemas diferentes

12.2. Planejando a implementação da melhoria da automação de teste

12.2.1. Identificar alterações nos componentes do ambiente de teste

12.2.2. Aumente a eficiência e a eficácia das bibliotecas de funções principais do TAS

12.2.3. Funções de múltiplos alvos que agem sobre o mesmo tipo de controle para consolidação

12.2.4. Refatorar o TAA para acomodar mudanças no SUT

12.2.5. Convenções de nomenclatura e padronização

12.2.6. Avaliação de scripts existentes para revisão ou eliminação de SUT

12.3. Termos

12.4. Atenção total

13. Capítulo 7 (3 páginas)

13.1. Verificando componentes automatizados do ambiente de teste

13.1.1. Verificar se o ambiente de teste automatizado está funcionando como esperado

13.1.2. Por exemplo, antes de iniciar os testes automatizados

13.1.3. Etapas

13.1.3.1. Instalação, configuração, adequação e personalização da ferramenta de teste

13.1.3.1.1. Cada um dos componentes do TAS precisa ser contabilizado para garantir desempenho confiável e repetitivo

13.1.3.1.2. No núcleo de um TAS estão

13.1.3.1.3. O uso do repositório (Git, por exemplo) e o processo para atualizar para uma nova versão do TAS devem ser os mesmos que para as ferramentas de desenvolvimento padrão

13.1.3.2. Testar scripts com aprovações e reprovações conhecidas

13.1.3.2.1. É importante verificar a geração correta de arquivos de log e métricas de desempenho, bem como a configuração e desmontagem automatizada do caso ou script de teste.

13.1.3.2.2. Também é útil executar alguns testes dos diferentes tipos e níveis de teste (testes funcionais, testes de desempenho, testes de componentes, etc.).

13.1.3.2.3. Isso também deve ser realizado no nível da estrutura.

13.1.3.3. Repetibilidade na configuração ou desmontagem do ambiente de teste

13.1.3.3.1. Para garantir que o TAS funcione adequadamente em cada ambiente, é necessário ter uma abordagem sistemática para carregar e descarregar o TAS de qualquer ambiente

13.1.3.3.2. O gerenciamento de configuração dos componentes do TAS garante que uma determinada configuração pode ser criada de forma confiável.

13.1.3.4. Configuração do ambiente de teste e componentes

13.1.3.5. Conectividade contra sistemas ou interfaces internas e externos

13.1.3.5.1. verificações ou pré-condições para garantir que a conectividade com sistemas internos e externos, interfaces, etc

13.1.3.6. Nível de intrusão de ferramentas de teste automatizadas

13.1.3.6.1. Para maior compatibilidade, colocamos componentes dentro do SUT, isso é intrusão. Alta intrusão é quando os componentes influenciam na performance do SUT.

13.1.3.6.2. Tipos

13.2. Termos

13.3. Atenção Total

13.3.1. O TAS muitas vezes será fortemente acoplado com o SUT

13.4. Testar todos os componentes funcional e não funcionalmente

13.4.1. Compreensão da degradação do desempenho da estrutura

13.4.2. A utilização de recursos do sistema que podem indicar problemas como vazamentos de memória

13.4.3. Interoperabilidade dos componentes dentro ou fora do quadro

13.5. Verificando o Conjunto de Testes Automatizado

13.5.1. Testar quanto à integridade, consistência e comportamento correto

13.5.2. Etapas

13.5.2.1. Executar scripts de teste com aprovações e reprovações conhecidas

13.5.2.2. Verificar a suíte de testes

13.5.2.2.1. Valide a versão e configuração do SUT

13.5.2.3. Verificar novos testes que se concentram em novos recursos do framework

13.5.2.3.1. Monitorar para ver que realmente funciona

13.5.2.4. Considerar a repetibilidade dos testes

13.5.2.4.1. Ao repetir testes, o resultado ou veredito do teste deve ser sempre o mesmo

13.5.2.4.2. Condições de corrida não considerados testes que não dão um resultado confiável

13.5.2.4.3. Problemas podem estar no caso de testes, na estrutura ou até no SUT

13.5.2.5. Avaliar se há pontos de verificação suficientes no conjunto de testes automatizado ou casos de teste.

13.5.2.6. Avaliar se há pontos de verificação suficientes

13.5.2.6.1. A evidência pode incluir registro no início e no final de cada caso de teste, registrando o status de execução de teste para cada caso de teste concluído, verificação de que as condições de pós foram alcançadas, etc

14. Capítulo 6 (9 páginas)

14.1. Critério para automação

14.2. Implementar a automação em testes de regressão

14.3. Fatores a serem considerados ao implementar a automação no teste de novos recursos

14.3.1. É mais fácil automatizar novas features

14.3.2. Nenhuma funcionalidade do TAS deve influenciar negativamente o Testware existente

14.3.3. O TAS existente continuará a atender às necessidades atuais do SUT após as mudanças?

14.3.4. As novas funcionalidades do SUT serão testáveis? Pois precisam ser!

14.4. Fatores a considerar testando ao implementar automação de confirmação

14.4.1. Testes de confirmação são candidatos a automação como complementares, podem ser implementados a qualquer momento

14.4.2. Podem ser implementados como novos testes ou como parte de testes antigos

14.4.3. O rastreamento de testes de confirmação automatizados permite relatórios adicionais de tempo e número de ciclos gastos na resolução de defeitos.

14.4.4. A análise de impacto pode ser necessária para determinar o escopo apropriado dos testes de regressão

14.5. Identificar etapas necessárias para implementar a automação em testes de regressão

14.5.1. Suíte de teste de regressão cresce à medida que os testes funcionais de hoje se tornam testes de regressão de amanhã

14.5.2. Perguntas ao começar a automação de testes de regressão

14.5.2.1. Com que frequência os testes devem ser executados?

14.5.2.1.1. A mesma dos testes regressivos manuais

14.5.2.2. Qual é o tempo de execução para cada teste para o conjunto de regressão?

14.5.2.2.1. Começar implementando a automação em testes mais demorados, assim cada teste seja executado de forma mais rápida e eficiente

14.5.2.3. Há sobreposição funcional entre os testes?

14.5.2.3.1. Um teste automatizado equivale a vários manuais agrupados

14.5.2.4. Os testes compartilham dados?

14.5.2.4.1. Sim, para não duplicar dados. Os testes devem avaliar perspectivas diferentes, óbvio.

14.5.2.5. Os testes são dependentes um do outro?

14.5.2.5.1. Sim

14.5.2.6. Que pré-condições são necessárias antes da execução do teste?

14.5.2.6.1. Sim, precisam fazer parte do processo de automação

14.5.2.7. Qual a percentagem de cobertura do SUT que os testes representam?

14.5.2.7.1. O máximo que conseguir. Ampliamos a cobertura dos unitários e de integração

14.5.2.8. Os testes são executados atualmente sem falha?

14.5.2.8.1. Antes de automatizar, teste para ver se os testes passam

14.5.2.9. O que deve acontecer quando os testes de regressão demorarem muito?

14.5.2.9.1. Faça a execução simultânea de casos de teste

14.6. ROI

14.6.1. Disponibilidade de ferramentas no ambiente de teste para automação de teste

14.6.2. Correção de dados de teste e casos de teste

14.6.3. Escopo do esforço de automação de teste

14.6.4. Educação da equipe de teste para a mudança de paradigma

14.6.5. Papéis e responsabilidades

14.6.6. Cooperação entre desenvolvedores e engenheiros de automação de testes

14.6.7. Esforço paralelo

14.6.8. Relatório de automação de testes

14.7. Atenção total

14.7.1. Não deixe o Testware existente quebrar!

14.7.2. Qualquer mudança exige análise de impacto nos Testwares existentes

14.7.3. Eles acham normal dependência entre casos de teste

14.7.4. Nem todos os testes podem ou devem ser automatizados

14.7.5. A automação não é recomendada para um sistema próximo ao fim de seu ciclo de vida, pois haverá pouco valor na realização de uma iniciativa de tão curta duração.

15. Capítulo 5 (7 páginas)

15.1. Mindset

15.1.1. Métricas do TAS são separadas das métricas de teste do SUT (para testes funcionais e não funcionais)

15.1.2. Métricas de teste do SUT são coletadas pelo TAM

15.1.3. Tipos de Métricas

15.1.3.1. Internas: eficácia e eficiência do TAS em seus objetivos. Defeitos, complexidade e desempenho dos scripts de teste

15.1.3.1.1. Métricas de script de ferramenta

15.1.3.1.2. Densidade de defeitos de código de automação

15.1.3.1.3. Velocidade e eficiência dos componentes TAS

15.1.3.2. Externas: impacto do TAS nas atividades de teste

15.1.3.2.1. Benefícios de automação

15.1.3.2.2. Esforço para construir testes automatizados

15.1.3.2.3. Esforço para analisar incidentes de teste automatizados

15.1.3.2.4. Esforço para manter testes automatizados

15.1.3.2.5. Relação entre falhas e defeitos

15.1.3.2.6. Tempo para executar testes automatizados

15.1.3.2.7. Número de casos de teste automatizados

15.1.3.2.8. Número de resultados de aprovação e falha

15.1.3.2.9. Número de falhas falsas e resultados de falso-passe

15.1.3.2.10. Cobertura de código

15.2. Implementação da Medição

15.2.1. Onde a abstração é combinada com testware estruturado, quaisquer aprimoramentos feitos subjacentes a ele podem ser utilizados por todos os scripts de teste automatizados de nível mais alto

15.2.2. Recursos de automação que suportam medição e geração de relatórios

15.2.2.1. Precisa ter um recurso de análise para levar em conta os resultados dos testes anteriores, para que ele possa destacar tendências

15.2.3. Integração com outras ferramentas de terceiros

15.2.3.1. Informações da execução de casos de teste automatizados são usadas em outras ferramentas podemos prover informações em formatos conhecidos pelas ferramentas

15.2.4. Visualização de resultados

15.2.4.1. Faze-los de forma gráfica, para gestão

15.3. Registro do TAS e do SUT

15.3.1. Os logs de teste são uma fonte que são frequentemente usados para analisar problemas potenciais

15.3.2. O que é importante ter no log?

15.3.2.1. Qual caso de testes está executando?

15.3.2.2. Passou ou Falhou?

15.3.2.3. Logs em alto nível (tempo)

15.3.2.4. O SUT quebrou? O que ocorreu?

15.3.2.5. Quantos vezes os casos de teste foram executados em testes não funcionais?

15.3.2.6. Se forem entradas aleatórias, registras o grupo de parâmetros usados em cada teste

15.3.2.7. Registrar todos os passos com evidências

15.3.2.8. Usar cores para sucesso, alerta ou falha

15.3.2.9. O log do SUT deve ter logs bem descritivos, logar interações do cliente e também registro da configuração do ambiente

15.4. Relatório de Automação de Testes

15.4.1. Deve ter

15.4.1.1. Visão geral dos resultados da execução, do sistema que está sendo testado e do ambiente em que os testes foram executados

15.4.1.2. Quais testes falharam e as razões para a falha

15.4.1.3. Responsável pelo teste

15.4.2. Também são usados para diagnosticar falhas dos componentes do TAF

15.4.3. Devem ser publicados (em ferramentas, sites, listas, e-mails, etc) para todos os interessados nos resultados da execução

15.4.4. Se tiverem fácil acesso, serão visualizados, entendeu?

15.5. Atenção total

15.5.1. Analisar falhas da execução de testes automatizados pode ser mais complexo do que para um teste executado manualmente

15.5.2. O esforço de manutenção pode superar os benefícios obtidos pelo TAS, isso é um dos motivos de projetos falhos

15.5.3. O código de automação pode ter defeitos

15.5.4. Sobre métricas, as tendências (ou seja, a forma como as medidas mudam ao longo do tempo) que podem ser as mais valiosas

15.5.5. verificação do teste é obtida pela comparação de elementos específicos do resultado do teste com um resultado esperado predefinido

15.6. Termos

15.6.1. Defeitos de fiabilidade são aqueles que nunca seriam encontrados nos testes manuais

15.6.2. EMTE esforço de teste manual equivalente

15.6.3. Buffers cíclicos são frequentemente usados para arquivos de log no SUT, quebrar o log em pequenas partes

16. Capítulo 4 (7 páginas)

16.1. Implantação do TAS

16.1.1. Piloto

16.1.1.1. Preciso identificar um projeto adequado, planejar a forma com que o piloto será executado, conduzi-lo e avaliar os resultados

16.1.1.1.1. Quando os resultados são avaliados, já podemos implantar!

16.1.1.2. * garantir que o TAS alcance benefícios planejados

16.1.1.3. Objetivos

16.1.1.3.1. Mais detalhes do TAS, aderência ao contexto, encontrar padrões, definir métricas para monitoramento, avaliar benefícios e identificar as habilidades necessárias

16.1.1.4. Dicas

16.1.1.4.1. Envolva a gestão (de modo que se comprometam) e faça com que o projeto piloto seja referência para outros projetos

16.1.1.4.2. Envolva na implantação todos os que participaram da construção do TAS

16.1.2. Implantação

16.1.2.1. Identificar os projetos iniciais (pois não posso implantar o piloto em todos), depois implantar, monitorar e avaliar o TAS. Implementar nos demais projetos.

16.1.2.2. Tipos

16.1.2.2.1. Incremental, por etapas (ou ondas)

16.1.2.2.2. Adaptação e aperfeiçoamento dos processos

16.1.2.2.3. Fornecimento de treinamento, coaching e mentoring

16.1.2.2.4. Diretrizes, listas de verificação e FAQs

16.1.2.2.5. Deve haver uma maneira automatizada de coletar informações sobre o uso real do TAS. Não só o uso em si, mas também quais partes do TAS (certas funcionalidades) estão sendo utilizadas

16.1.2.2.6. Monitorar o uso do TAS e ver se é realmente usado. Usadas para recalcular o business case

16.1.2.2.7. Realizar reuniões de avaliação e retrospectiva com as diferentes equipes que utilizam o TAS, para melhorar

16.1.2.2.8. Melhorias são identificadas e implementadas com base no feedback da equipe e na monitoração do TAS

16.1.2.3. Um novo TAS ou uma nova versão é implantado no início do projeto ou ao atingir um marco

16.1.2.3.1. Para mitigar o risco do TAS não funcionar e interromper os processos

16.1.2.3.2. Se o TAS tiver de ser corrigido/alterado, a implantação será feita independentemente da fase de desenvolvimento do SUT

16.1.2.4. Modos

16.1.2.4.1. Implementação inicial

16.1.2.4.2. Implementação de manutenção

16.1.3. Manutenção da Automação

16.1.3.1. Tipos de manutenção

16.1.3.1.1. Preventiva

16.1.3.1.2. Corretiva

16.1.3.1.3. Perfeita

16.1.3.1.4. Adaptativa

16.1.3.2. Escolha e abordagem

16.1.3.2.1. Depende da complexidade do TAS, tamanho e risco da mudança

16.1.3.2.2. No TAS, tudo tem de ser documentado, scripts modularizados, componentizados, portáveis, geridos pela confirguação.

16.1.3.2.3. Considerações

16.1.3.3. * pode afetar todas as camadas e componentes de um TAS. Logo, ANÁLISE DE IMPACTO neles!

16.2. Riscos

16.2.1. Técnicos

16.2.1.1. Não seja abstrato demais

16.2.1.2. Dados complexos demais

16.2.1.3. Dependência de libs e componentes

16.2.2. Implantação

16.2.2.1. Pessoas certas para a coisa certa

16.2.2.2. SUT alterado

16.2.2.3. Atrasos

16.2.2.4. Observabilidade

16.2.3. Projeto

16.2.3.1. Migração para um ambiente diferente

16.2.3.2. Implantação no ambiente destino

16.2.3.3. Novas entregas do SUT

16.3. Atenção total

16.3.1. O TAS se adequa ao contexto, não o contrário

16.3.2. Não selecione um projeto crítico como piloto, mas também, não escolha um trivial

16.3.3. TAS bom é aquele alinhado o com o contexto e que funcione como planejado

16.3.4. Treinamento e workshops devem ser fornecidos aos usuários antes que eles realmente usem o TAS

16.3.5. TAS precisam ser precisam ser modulares, escaláveis, compreensíveis, confiáveis e testáveis.

16.3.6. Eficiência do tempo é o principal fator que contribui para o sucesso da automação de testes

16.3.7. Quanto a documentação, alguém a escreve e outro a mantém

16.3.8. Apenas o código da ferramenta de teste pode ser documentado automaticamente, os demais são feitos manualmente

16.4. Termos

16.4.1. Um marco pode ser o congelamento de código ou o fim de um sprint

16.4.2. Manutenção refere-se ao TAS em operação