O documento apresenta um plano de treinamento sobre testes funcionais que inclui três dias de aulas. No primeiro dia serão abordados fundamentos de testes e derivação de casos de teste a partir de casos de uso. Nos dias seguintes serão apresentados recursos de uma ferramenta de teste funcional e realizados laboratórios sobre projeto de testes, criação de scripts manuais e automatizados e geração de relatórios.
7. Motivação financeira: perdas devido a erros US$ 1 milhão por minuto Charles Schwab (maior corretora on-line do mundo ) US$ 167 mil por minuto American Express US$ 50 mil por minuto Boeing Quedas do Sistema Queda de 26% no valor das ações Perdas de US$ 3,5 milhões Site fora do ar por 22 horas eBay (Online Marketplace) US$ 1,1 milhão por dia Problemas no sistema de controle de bagagem US$ 50 milhões Erro no sistema mostrando que todos os vôos estavam lotados US$ 20 mil por minuto Sistema SABRE fora do ar por 12 horas American Airlines
8. Motivação financeira: custo da qualidade Fe Fi Encontrar o maior número de erros com o menor retrabalho possível com os testes de regressão 92,9% 7,1% 0% 50% 100% Falhas Externas Falhas Internas
9. Vantagem: menor custo da correção de erros “ O Custo para encontrar e determinar um erro, aumenta exponencialmente com a fase do projeto.” Barry Boehm, criador do Software Economics
10.
11.
12.
13.
14. Motivações normativas: evidências ok Robustez (escalabilidade / performance) ok Integração ok Funcionalidade ok Segurança de Dados ok Autorização ok Autenticação Validação e Testes Requisitos de Conformidade em Tecnologia de Informação
16. Histórico: o 1 º Bug http://www. history . navy . mil/photos/images/h96000/h96566kc . htm O primeiro "Bug" de Computador Uma traça foi encontrada enroscada próxima ao Relay #70, Painel F, da Máquina Calculadora Mark II Aiken enquanto ela estava sendo testada na Universidade de Harvard, em 9 de Setembro de 1945. Os operadores afixaram a traça no diário de operação, com a frase: "O primeiro caso real de um bug encontrado". Eles descreveram o processo como tendo "debugado" a máquina, o que introduziu o termo "debugar um programa de computador". Desde 1988, o diário, com a traça colada, está no Museu do Computador do Centro de Guerra Naval em Dahlgren, Virgina, USA.
17.
18. O que é Teste? Uma investigação técnica executada para revelar informações relacionadas à “ qualidade” do produto Sob teste O Teste Funcional tem Por meta a verificação e Aceitação dos dados, do Processamento, da resposta A este processamento e a implementação Apropriada das regras De negócio
19.
20.
21.
22.
23.
24. Os focos da disciplina de testes Quality Control encontrar falhas Quality Assurance prevenir falhas Quality by Design evitar falhas
25. Quality Control (QC) Especificação de Requisitos Análise do projeto Desenho do projeto codificação Testes de unidade Testes de integração Testes de Sistema Teste de Aceitação Validação Validação Validação Quality Control encontrar falhas
26. Quality Control Testes de unidade Testes de integração Testes de sistema Testes formais conduzidos para determinar se um sistema satisfaz ou não os critérios de aceitação e que possibilita ao cliente/usuário determinar se aceita ou não o sistema Testes de aceitação do usuário Explora a menor unidade do projeto, procurando identificar erros de lógica e de implementação em cada módulo separadamente Descobrir erros associados às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto Identificar erros de função e características de desempenho que não estejam de acordo com a especificação
27. Técnicas de testes Técnicas de testes Visão Fontes de informação Métodos entradas saídas Caixa preta Caixa branca Domínio do problema Requisitos Especificações de projeto Dados de análise de defeitos Diagramas de projeto Detalhes de projeto Código fonte Grafos de fluxo de controle Complexidade ciclomática Particionamento de classe de equivalência Análise de valores limites Diagrama de estados Grafos de causa e efeito Statement testing Branch testing Path testing Data flow testing Mutation testing Loop testing Testes Funcionais no Processo de Software
28.
29.
30.
31.
32.
33.
34. Módulo 2: O processo de Testes de Software Juliana Maria Lopes
35. A disciplina de Validação e Testes Framework de Desenvolvimento de Sistemas
36. Papéis, Atividades e Artefatos de Teste Gerente de Testes Plano de Testes Responsável Por Aceitar Missão de Avaliação Identificar Motivadores de Teste Obter comprometimento de Testabilidade Avaliar e defender a Qualidade Avaliar e aprimorar os esforços de Teste Resumo de Avaliação de Testes
37. Papéis, Atividades e Artefatos de Teste Analista de Testes Lista de Idéias de Teste Responsável Por Identificar os Objetivos do Teste Identificar Idéias para os Testes Definir os Detalhes do Teste Definir Avaliação e Rastreamento de Necessidades Determinar Resultados de Teste Casos de Teste Verificar Mudanças na Construção Modelo de Análise de Carga de Trabalho Dados de Teste Resultados de Teste
38. Papéis, Atividades e Artefatos de Teste Projetista de Testes Arquitetura de Automação de Teste Responsável Por Definir a Abordagem do Teste Definir as Configurações do Ambiente de Testes Identificar Mecanismos de Testes Estruturar a Implementação dos Testes Definir Elementos de Testes Especificação de Interface de Teste Desenvolver Diretrizes de Teste Configuração de Ambiente de Teste Suíte de Teste Diretrizes de Teste
39. Papéis, Atividades e Artefatos de Teste Testador Scripts de Teste Responsável Por Implementar Testes Implementar Suíte de Testes Executar Suíte de Testes Analisar Falhas do Teste Log de Teste
40. Workflow da Disciplina de Testes Definir Missão de Avaliação Verificar Enfoque do Teste Validar Estabilidade da Construção [Outra Técnica] Testar e Avaliar Avaliar Missão de Aceitação Aprimorar Ativos de Testes [Outro Ciclo de Teste]
50. Testes Funcionais: Definição Uma maneira de avaliar o comportamento de um produto de software sem que o funcionamento interno do que está sendo testado seja conhecido pelo testador. Entrada Saída Programa Casos de Testes Resultados esperados
55. Escopo Atual do Framework Requisitos Gerência de Configuração (SCM) Análise & Desenho Construção Validação & Testes Implantação Documentação Gerência de Projetos Disciplinas Principais Disciplinas de Apoio Abordagem por Caso de Uso MSVisual Studio/ WSAD/TSO/ISPF Java 4GL(VAGen) COBOL Plataforma Distribuída Mainframe Plataforma Distribuída Mainframe Análise Estruturada Análise OO
56. Estratégia de Testes Requisitos A/D Construção Testes Implantação Testes Estruturais Repositório Requisitos Casos de Testes Funcionais Código
57.
58. Estratégia de Testes Requisitos A/D Construção Testes Implantação Construção codificação Tunning Testes Unidade Debug e Testes Estruturais Testes Estruturais Testes Estruturais Analista Programador
59. Estratégia de Testes Requisitos A/D Construção Testes Implantação Teste Testes Internos Correção Testes Aceitação Registro de Defeitos Testes Estruturais Testes Funcionais Testes de Carga Analista de Sistemas
61. Sistema de Rastreamento de Defeitos Instrumento de gerência de projetos Registra Líder de Projeto Equipe de Testes Gerencia Desenvolvedor Fixa Cancelado Em Solução Resolvido Fechado Adiado Aberto Ciclo de vida de Defeitos Base de defeitos
62.
63. Derivação de Especificação Cenário 1 Cenário 2 Cenário N Derivação de Casos de Uso em Casos de Testes Caso de Uso
64.
65.
66. Análise de Valores Limites Técnicas de Testes Funcionais 4 Classe Válida Classe Inválida 3 5 7 Classe Válida Classe Inválida 6 8 4 7 Classe Válida Classe Inválida Classe Inválida
70. Casos de uso são parte da UML 1967 Foundations of OO (Nygaard, Goldberg, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…) UML 1.1 (OMG Standard) UML 1.3 ( extensibility ) UML 1.4 ( action semantics ) UML 1.5 1996 1997 1998 2001 1Q-2003 3Q-2003 UML 2.0 (MDA) Evolução da UML Origem dos casos de uso Jacobson Booch Rumbaugh
71.
72.
73.
74. Exemplo de estilo de descrição de fluxo básico Estruture os fluxos em passos Numere o título de cada passo Descreva os passos (1-3 sentenças) Não referencie fluxos alternativos no fluxo principal
75. Exemplo de descrição de fluxo alternativo Informe o passo onde o fluxo alternativo inicia Caso de Uso: Registro em cursos Informe o que causa o início do fluxo Informe o que acontece Informe onde o fluxo termina Fluxos alternativos devem tratar apenas uma condição
76.
77.
78. Cenário 1 Cenário 2 Cenário N Casos de Teste são derivados a partir de casos de uso (relembrando...) Caso de Uso
79. Derivação de caso de uso em caso de teste Ação do Ator Passo Caso de Uso Caso de Teste Resposta do Sistema Ponto de Verificação
94. Módulo 3: Suíte de Testes Funcionais IBM Rational Functional Test Luís Felipe Cipriani
95.
96.
97.
98. Abordagem do Framework Software de Qualidade Ferramentas Processo B O A S P R Á T I C A s
99.
100. Integração das ferramentas Rational Testes Estruturais Repositório: Projeto Rational Course.dll People.dll Course User Register.exe Billing.exe Billing System
107. Gerenciando usuários e grupos de testes Para adicionar grupos: Insert > New User > New Group Para modificar grupos existentes: Right-click > Properties
112. Entradas e atividades do planejamento e projeto de testes Test Case Definir Missão Identificar Motivadores Identificar Alvos Definir avaliação e rastreabilidades Definir abordagem de teste Identificar opiniões Definir Detalhes Definir ambiente e configurações Obter compromisso com a testabilidade Especificações de sistema Requisitos Pedidos de alteração Lista de riscos Plano de Iteração Especificações de Projeto Modelos de casos de uso Test Plan Test-Ideas List Test Automation Architecture
113.
114.
115. TestManager: Plataforma central para gerência de testes Gerência de Resultados Pass Fail Relatórios integrados Scripts GUI e VU Scripts Java ou Basic Scripts para outros S.O. Projeto Iterações de teste Configurações Planos Casos Teste Entradas de Testes Rational TestManager Adapters Input Execution Adapters
116. Planejamento orientado à Casos de Testes Caso de Teste O que motiva os testes? Entradas de Testes Implementações Configurações Onde será testado? Quando será testado? Iterações Como será conduzido?
121. Definindo Iterações, Configurações e Computadores Define computadores que serão executados os testes Define iterações de para o plano de testes Define configurações das aplicações de teste Define atributos de configuração
127. Criando pasta de casos de testes Selecione Insert Test Case Folder Selecione o plano de teste na janela Test Plan, e clique com o botão direito do mouse
128. Criando Casos de Teste Selecione a pasta de caso de teste, e clique com o botão direito Selecione Insert Test Case
132. Casos de Testes Suspeitos Entrada 1 Entrada 2 Entrada 1 Entrada 2 Alteração significante Marcado como suspeito Associação Associação Caso de Teste A Caso de Teste B Caso de Teste C Caso de Teste A Caso de Teste B Caso de Teste C
147. Detalhando casos de testes no TestManager Impressão Clique para mudar para passos ou ponto de verificação Em iterações iniciais, detalhe o caso de teste em alto-nível
152. Criando um relatório de distribuição de casos de teste Reports > New Selecione um item sobre o qual será a distribuição Selecione o formato da exibição
160. A evolução de um teste Identificar Motivaçõesdo teste Identificar os alvos do teste Identificar idéias de teste Caso de Teste Detalhar o s testes Scripts Automáticos Test Suite Implementar Teste Scripts Manuais
165. Ícones de implementação Caso de Testes sem implementação associada Casos de testes com implementação manual Casos de testes configurados com scripts automáticos e herdados de um caso de teste pai
166.
167.
168.
169.
170. Rational Robot Permite a gravação e execução de scripts de testes automáticos que navegam pela aplicação e testa o estado dos objetos por meio dos pontos de verificação
171.
172. Gravação orientada a objetos visuais Objetos Buttons Menu Edit box Tree view Window region Window Label ComboBox
173.
174.
175.
176. Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
184. Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
185. Pontos de verificação do Rational Robot Imagem de janela Alfanuméricos Clipboard Scan no site Web Propriedade de objetos Comparação de arquivos Existência de arquivos Existência de módulos Existência de janela Menu Objeto de dados Região de imagem Comparação de site web
186.
187. GUI Insert Toolbar: Pontos de Verificação Propriedades de objetos Alfanumérico Objeto de dados Menu Clipboard Região de imagem Imagem de janela Existência de janela Scan de site web Comparação de site web Display GUI Insert Toolbar
188. Selecionando o objeto de teste Arraste o Object Finder sobre o objeto e libere o botão no mouse ou Clique em Browse para selecionar o objeto à partir de uma lista de todos os objetos no desktop
189.
190. Exemplo de Ponto de Verificação: Menu Seleção das células de teste Método de identificação Descrição de seleções Método de Verificação
191.
192. Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
193.
194.
195.
196. Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
197.
198.
199.
200.
201. Shell Scripts Execução Test Script 1 Test Script 2 Test Script 3 Test Script 4 Shell Script Test Script 1 Test Script 2 Test Script 3 Test Script 4
202.
203.
204. O comando CallScript Os s hell scripts adicionam comandos CallScript ou Adicione manualmente o comando CallScript Insert > Call Script
205.
206.
207. Módulo 5: Desenvolvimento de Scripts Automatizados: Pontos de Verificação, Datapools IBM Rational Robot Luís Felipe Cipriani
208.
209. Pontos de verificação Clique para expandir a GUI Insert toolbar Object Properties Alphanumeric Object Data Menu Clipboard Region Image Window Image Window Existence Web Site Scan Web Site Compare
210. Estado de espera e resultados esperados Nome do ponto de verificação Configuração do estados de espera Insert > Verification Point > Verification Point Type Especificação do resultado esperado
211. Selecionando o objeto de teste Arraste a ferramenta Object Finder sobre objeto e libere o botão do mouse ou Clique browse para selecionar o objeto na lista de todos os objetos visuais no desktop
212. A lista de objetos Duplo clique para expandir o objeto Duplo-clique para retrair o objeto Retorna ao método de seleção Object Finder A cor do objeto selecionado será invertida na aplicação Exibe os objetos escondidos no desktop
222. O ponto de verificação Data Grid Grid de dados para seleção das células que serão testadas Método de identificação Descrição da seleção Método de verificação
255. Passos para o testes de regressão Configurar Ambiente Criação Testes/ Suites Executar os Testes Recuperar os testes interrompidos Verificar os resultados esperados Investigar os resultados esperados Defeitos logados
256.
257.
258.
259.
260.
261.
262.
263.
264. Executandos os scripts no TestManager File > Run Test Script > Type of Script Computadores onde os scripts executarão Clique para alterar o computador Onde os resultados serão gravados Clique para alterar onde os resultados serão gravados
265.
266. Propriedades de um script de teste Visualizar uma baseline capturado pelo ponto de verificação
267. Running Test Cases from TestManager File > Run Test Case ou Botão-direito
268. Executando um caso de testes no TestManager (cont.) Casos de testes que serão executados Adicione casos de teste na lista Ignora as configurações de sistema – executa os casos de testes nos computadores disponíveis Computador onde o caso de testes será executado Clique Change para alterar o computador Onde os resultados serão gravados Clique para alterar onde os resultados serão gravados
269. Executando uma implementação manual Executa os passos no Rational ManualTest, e grava os resultados dos passos e pontos de verificação
Quality Control : a série de inspeções, revisões, verificações, validações e testes utilizados em pontos específicos do ciclo de desenvolvimento de software com o objetivo de achar falhas . Software Quality Assurance : uma abordagem planejada e sistemática de controle da qualidade para avaliação da aderência à padrões dos processos, procedimentos e artefatos envolvidos na produção de um software com o objetivo de prevenir falhas . Quality by Design : uma abordagem integrada e otimizada de produção correta de software, o que garante evitar de falhas .
O papel de Gerente de Testes desempenha atividades responsáveis pelo sucesso dos esforços de teste como um todo. Essas atividades envolvem: Negociar os objetivos em andamento e utilização dos esforços de teste adequados para cada iteração. Garantir um planejamento e gerenciamento apropriado dos recursos de teste que irão induzir os testes durante a iteração. Avaliar se os esforços de teste estão progredindo de forma efetiva e promovendo a criação de software testável para dar suporte às necessidades dos esforços de teste. Promover também a utilização de técnicas e ferramentas de automação apropriadas. Estabelecer um nível apropriado de qualidade efetuando as mudanças para a resolução de defeitos que afetam seriamente o sistema. Avaliar a produtividade, efetividade e completude dos esforços de teste, ajustando estratégias e táticas para aprimorar o processo de teste.
O papel de Analista de Testes desempenha atividades responsáveis por identificar e definir os requisitos de teste.
Nessa macro-atividade, o principal objetivo é identificar o foco apropriado do esforço de testes para a iteração, e entrar em acordo com os stakeholders acerca dos objetivos dos testes. Definir os artefatos que serão utilizados e gerados Utilização dos recursos de teste Acordo com os stakeholders sobre os objetivos dos testes Técnicas e tipos de teste que serão empregados Itens de hardware e software necessários para os testes Forma como serão avaliados os esforços de teste Listar idéias para testes em potencial que podem ser aplicados Rastreabilidade mantendo documentos e gravações comprovando que foram feitos testes suficientes
Nessa macro-atividade o principal objetivo é demonstrar que as várias técnicas sugeridas no Enfoque do Testes irão facilitar os testes requeridos. Significa obter um entendimento dos obstáculos e limitações de cada técnica e buscar uma solução de implementação apropriada para cada técnica ou encontrar técnicas alternativas. Isto ajuda a minimizar o risco de descobertas tardias no ciclo de vida do projeto de que as recomendações de testes são impraticáveis. Estabelecer o ambiente necessário para suportar os testes Identificar os mecanismos necessários aos testes (Ex.: persistência, concorrência, distribuição, segurança, gerenciamento de transação, tratar e reportar erro, controle e sincronização de sincronização), bem como as ferramentas necesárias. Identificar os elementos físicos da infra-estrutura de implementação de teste necessários para permitir os testes sob cada configuração de ambiente de teste Analisar os itens da “Lista de Idéias” identificando as condições necessárias para aplicar determinada idéia de teste Reunir e organizar os testes a serem executados Implementar testes que forneçam a solicitada validação do produto Garantir a obtenção do produto de software a ser testado junto à equipe de desenvolvimento Reunir e organizar os testes a serem executados
Nessa macro-atividade o principal objetivo é validar se a construção está estável o suficiente para o início da execução de testes detalhados e avaliação. Este trabalho é também conhecido como “ smoke test”, “build verification test”, “build regression test”, “sanity check” ou “acceptance into testing” . Este trabalho ajuda a prevenir que recursos de teste sejam perdidos em esforços de teste desnecessários e infrutíferos. Executar as coleções de testes necessárias para validar a qualidade do produto, capturando resultados de teste que facilitam a avaliação do produto Analisar as falhas que ocorreram durante a implementação e execução dos testes, corrigindo as falhas que resultaram dos procedimentos de teste. Fazer um resumo de avaliação de resultados de software, propondo ações corretivas para resolver as falhas de qualidade Identificar e requerer a resolução dos defeitos que causam impactos sérios na qualidade do software
Nessa macro-atividade, o principal objetivo é alcançar a largura e profundidade do esforço de testes para possibilitar uma avaliação suficiente dos itens de teste—onde uma suficiente avaliação é governada pelas motivações dos testes e Missão da Avaliação. Tipicamente executado um por ciclo de teste, este trabalho envolve executar o trabalho principal do esforço dos testes e avaliação de resultados: especialmente a implementação, execução e avaliação de testes específicos e o correspondente registro das ocorrências. Definir os artefatos que serão utilizados e gerados. Estruturar as suítes de teste necessárias, atribuindo responsabilidades para cada área de implementação de suítes de teste. Identificar os elementos físicos da infra-estrutura de implementação de teste necessários para permitir os testes sob cada configuração de ambiente de teste Verificar as requisições de mudança feitas e as construções (“builds”) liberadas para re-teste. Avaliar se os esforços de teste estão sendo produtivos, efetivos e completos, realizando, se necessário, ajustes táticos e estratégicos para que os esforços de teste se tornem mais efetivos.
Nessa macro-atividade, o principal objetivo é entregar uma avaliação útil dos resultados de testes aos stakeholders – onde uma avaliação útil é definida em termos da Missão de Avaliação. É o momento em que é feita uma avaliação dos esforços de teste em geral para verificar se os objetivos definidos na Missão de Avaliação da primeira macro-atividade estão sendo atingidos na iteração.
Nessa macro-atividade, o principal objetivo é manter e melhorar as necessidades dos testes. Isto é importante especialmente se a intenção é reutilizar os recursos desenvolvidos no ciclo corrente nos ciclos subseqüentes. A partir da avaliação feita na macro-atividade “Atingir Missão Aceitável”, o final de um ciclo de teste geralmente possui esse trabalho de aprimoramento das propriedades do teste que foi executado no ciclo.
Testes de regressão são as várias re-execuções de um teste após uma correção de bugs, mudanças ou manutenções evolutivas. É importante para manter a consistência entre as mudanças, pois muitas vezes algumas correções influenciam no comportamento de outras funcionalidades.
Estrutura utilizada pela gerência de requisitos. O primeiro passo é entender o problema sem pensar na solução. Buscar o acordo sobre esse entendimento. Descobrir as principais causas, segundo Pareto, se atacarmos 20% das principais causas solucionamos 80% dos problemas. Em seguida entendemos as necessidades do cliente. Ao mesmo tempo, vamos definindo as fronteiras do sistema, descobrindo os atores do sistema. O próximo passo é pensar em soluções para cada necessidade apresentada. O sistema deverá ter características (features) para atender às necessidades. Notamos que a partir das necessidades derivamos as características do sistema (rastreabilidade). Então analisamos o que cada ator espera usar do sistema (requisitos de software) e fazemos o mapeamento com as características do sistema (rastreabilidade).
Existem várias técnicas que permitem a execução de uma série de cenários ou exemplos diretamente na aplicação. Nessa situação o testador assume o papel do usuário, testando o software da maneira como ele será utilizado. Os bugs encontrados durante os testes dinâmicos são aqueles introduzidos pelos requisitos, projeto e codificação. Inclusive problemas gerados por interação com sistemas legados. Nos próximos slides serão detalhadas as técnicas de Derivação de Especificação, Particionamento de Equivalência e Análise de Valores Limite.
Para derivar casos de teste a partir de casos de uso, devem ser encontrados todos os cenários possíveis para o caso de uso. Cada cenário de caso de uso dá origem a um ou mais casos de teste. Quanto mais complexa for uma funcionalidade, mais cenários existirão. Casos de uso típicos têm entre 3 e 15 páginas, sendo que 70% a 90% são cenários de fluxos alternativos.
Pense em Quality by Design como qualidade por “objetivo”. Quality By Design é uma aproximação pró-ativa de desenvolvimento e teste de software que abrange boas práticas, processo e ferramentas que o ajudam a entregar aplicativos com maior qualidade e mais rápido.
A ferramenta Rational Administrator é responsável por armazenar as informações de um projeto de teste.
Para criar um projeto novo: Clique File > New Project. Entre com o nome e diretório Não selecione ClearCase/UCM Management Se quiser, coloque uma senha Cheque “Configure Project Now”
Utilize o botão Create para criar os artefatos de teste
O usuário pode adicionar Computadores para a realização de testes distribuídos.
O usuário pode implementar um Plano de Testes no nível de granularidade que quiser.
Profundidade: quantidade de dados usado nos testes. Muito poucos dados podem não refletir numa situação real. Amplitude: variações nos valores dos dados. Escopo: relevância dos dados de teste. O ideal é abranger todas as partições de equivalencia. Arquitetura: mecanismos que poderão ser utilizados para a execução dos testes. Ex.: persistencia, concorrencia, etc. Gerenciamento
.
Para acessar quando não estiver gravando: View > Toolbars > GUI Insert Toolbar