Relatório ListEx 03
CE
‐
‐237
‐
‐
Tópicos Avançados em Teste de Software
Prof. Dr. Luiz Alberto Vieira Dias
Prof. Dr. Adilson Marques da Cunha
Alunos : Eduardo Mena Barreto Alonso
e Jorge Luís Guedes Alves
Setembro/2010
Pós-Graduação em Engenharia Eletrônica e Computação
Área Informática (EEC-I)
Lista de Exercícios 3 (ListEx 03)
CE-237 Tópicos Avançados de Teste de Software
Prof. Dr. Luiz Alberto Vieira Dias
Laboratório 03 – LABTEC da FCMF – ou em casa
Requisitos
PARTE I
• Preencher o Work Paper 3-1, Structural Risk Assessment – Test
Document, com dados referentes ao Segmento do seu Grupo da Missão
Lunar 2010-2
PARTE II
• Preencher o Work Paper 3-2, Technical Risk Assessment – Test
Document, com dados referentes ao Segmento do seu Grupo, da Missão
Lunar 2010-2
PARTE III
• Preencher o Work Paper 3-3, Size Risk Assessment – Test Document, com
dados referentes ao Segmento do seu Grupo da Missão Lunar 2010-2
PARTE IV
• Preencher o Work Paper 3-4, Risk Score Analysis – Test Document, com
sugestão de dados referentes ao Segmento do seu Grupo, da Missão Lunar
2010-2
PARTE V
• Preencher o Work Paper 3-5, Testing Tactics Checklist, com dados
referentes ao Segmento do seu Grupo da Missão Lunar 2010-2
• ATENÇÃO – Serão chamados aleatoriamente elementos individuais de
cada grupo para justificar algumas respostas aos questionários. Espera-se
que todos participem nos preenchimentos.
PARTE VI
• Preencher o Work Paper 4-1, Selecting Tools, com dados referentes ao
Segmento do seu Grupo da Missão Lunar 2010-2
PARTE VII
• Preencher o Work Paper 4-2, Documenting Tools, com dados referentes à
sugestão de ferramentas reais de Teste de Software para o seu Segmento
da Missão Lunar 2010-2. Este WP 4-2 deve ser preenchido
individualmente por cada aluno.
ENTREGA (publicação na página): 10/09/2010 – 23:59h
PROCEDIMENTOS REALIZADOS
Para completar os WorkPapers 3-1, 3-2 e 3-3, vamos executar os seguintes passos: 1. Compreender os riscos e as avaliações previstas para o risco. Quanto maior a avaliação predefinida, maior o risco. Na maioria dos casos, as avaliações serão entre 1 e 4.
2. Determinar a classificação aplicável para o sistema de software que está sendo testado. Selecionar uma das avaliações constantes para cada risco e colocá-lo na coluna Ratings. Por exemplo, na avaliação de riscos estruturais WorkPaper (3-1), se deter- minado que a quantidade de tempo desde a última mudança importante para a área existente da empresa foi superior a dois anos, você nota que a classificação indicada foi baixa, e coloque um 1 na coluna Classificação.
3. Calcular e acumular o escore de risco. As classificações previstas na coluna Avaliações deve ser multiplicada pelo peso para obter uma pontuação. A pontuação para cada Workpaper deve ser acumulado com o escore total colocado WorkPaper 3-4. Quando os três WorkPapers forem concluídos, você terá três contagens para o escore de risco de análise do paper.
Para concluir o WorkPaper 3-4, execute os seguintes passos:
1. Calcule o escore de risco médio por área de risco. Para fazer isso, o número total de riscos WorkPapers 1, 2 e 3 e se dividem em que a pontuação total no WorkPaper 3-4 para obter uma pontuação média para as três áreas de risco.
Faça o mesmo para o escore de risco total para o software.
2. Poste avaliações comparativas. Depois de ter usado estes WorkPapers uma série de vezes, você irá desenvolver escores médios para os sistemas de sua aplicação. Pegue os totais de pontuação para os seus sistemas de aplicação e classifique-os de cima para
baixo para cada uma das três áreas de risco. Então, determinar uma média para a terceira alta da pontuação, no terço médio das pontuações, e a terceira baixa da pontuação.
Esta averidade é a avaliação cumulativa para as aplicações da sua empresa e pode ser permanentemente gravadas no WorkPaper 3-4. Isto irá permitir que você compare a pontuação do sistema que você está testando contra avaliações comparativas para que você possa determinar que o sistema que você está trabalhando é alto, médio ou de baixo risco em cada uma das três áreas de risco e global.
3. Lista na parte inferior do WorkPaper 3-4 todos os atributos de risco a partir dos três planilhas que recebeu uma classificação de alto risco. Identificar a área (por exemplo, estrutura) e a lista de risco específico que foi dada uma pontuação elevada. Então, para cada desses riscos, determine a preocupação de teste específic o e listá-la em WorkPaper 3-4.
PARTE I
•
Baseado no
Segmento da Missão Lunar 2010 - COLETA DE
AMOSTRAS – CAVAL, vamos preencher o Work Paper 3-1
WORK PAPER 3-1 Avaliação de risco estrutural
Classificação:B – Baixa - M – Media - A – Alta - NA – Não se aplica
RISCO CLASSIFICAÇÃO/SCORE PESO
1 -Quantidade de tempo desde a última grande Alteração na área de negócios existente
2 1
• Mais de 2 anos
• 1 a 2 anos M = 2
• Desconhecido menos de 1 ano • Nenhum sistema automatizado
2 - Freqüência estimada das alterações de sistema propostas/existentes
4 2
• Não existe sistema automatizado; ou os esforços de desenvolvimento são insuficientes para a estimativa
• Mais de 2 por ano M = 2
• 2 a 10 por ano • Mais de 20 por ano
3 - Medida estimada do total de alterações nos métodos de área de negócios no ano passado, em percentagem de métodos afetados
0
• Menos de 10% • 10 a 25% • Mais de 25%
4 - Magnitude das mudanças na área de negócios associadas a este projeto
1 1
• Menores alterações B = 1
• Mudanças significativas mas gerenciáveis • Maiores mudanças na funcionalidade do sistema e/ou necessidades de recurso
5 - Desempenho do Projeto 9 3
• Facilidade da empresa M =3
• Facilidade fora do local da empresa • Não na área local
6 - Crítica pessoal do projeto 1 1
• In-House B = 1
• Contratante única fonte
• Contratante, oferta competitiva
7 - Tipo de organização do projeto 4 2
• Linha e pessoal: projeto tem controle total de gerenciamento de pessoal
M = 2 • Mistura de linha e pessoal com elementos de matriz
gerenciada
• Matrix: nenhum controle de gerenciamento transferido ao projeto
8 - Problemas potenciais com relacionamento com a subcontratante
0 2
• Não aplicáveis a este projeto NA = 0
• Subcontratante não atribuído uma tarefa isolada ou crítica: principal contratada anteriormente conseguiu com sucesso subcontratante
• Subcontratante atribuído a todas as tarefas de desenvolvimento em papel subalterno um contratante principal: empresa tem experiência favorável com subcontratante em outros effort(s)
• Subcontractor tem uma responsabilidade exclusiva pela tarefa crítica subcontratante nova empresa
9 - Status do projeto em curso de treinamento 15 3
• No plano de treinamento necessário
• Alguma formação no local • No treinamento disponível
10. Nível de pessoal especializado disponível para treinar a equipe do projeto
15 3
• Treinamento não necessário • Capacitados em todos os sistemas
• Capacitados nos principais componentes M = 5 • Alguns componentes entendidos
11. Acessibilidade dos documentos de referência e ou de conformidade e outras informações de suporte no sistema proposto/existentes
2 2
• Prontamente disponíveis B = 1
• Detalhes disponíveis com alguma dificuldade e atraso
• Grande dificuldade na obtenção de detalhes, muito atraso
12. Status de documentação nas áreas de usuário 4 2
• completa e atual
• mais de 75% completa e atual
• Não existente ou desatualizados M = 2
13. A natureza da relação com os usuários no que diz respeito à atualização de documentação do projeto para refletir as alterações que podem ocorrer durante o desenvolvimento do projeto
4 2
• Coordenação fechada •
• Coordenação gerenciável M = 2
• Má coordenação
14. Grau estimado para o projeto de
documentação que reflete a real necessidade da empresa
2 1
• Excelente documentação
• Boa documentação mas alguns problemas com a confiabilidade
M = 2 • Documentação pobre ou inadequada
15. Qualidade da documentação para o sistema proposto:
6 3
• Excelentes normas: cumprimento e execução são parte integrante do sistema e programas padrões adequados de desenvolvimento.
• Padrões adequados: Adesão não é consistente
• Pobres ou sem padrões: adesão é mínima. 16. Normas de qualidade do desenvolvimento e produção de biblioteca de controle
4 2
• Padrões excelentes : superiores de aderência e de execução
• Padrões adequados: adesão não é consistente
M = 2
• Pobres ou sem padrões: adesão é mínima 9 3
17. Disponibilidade de instalações especiais para o subsistema de teste
9 3
• Completa ou não é necessária A = 3
• Limitada
• Nenhuma disponível
18. Status de planejamento de manutenção do projeto
1 1
• Atual e completa • Sob desenvolvimento
• Não existe B = 1
19. Plano de contingência no local para apoiar a missão operacional a falha do aplicativo
2 1
• Nenhum necessário • Plano completo
• Subsistemas principais abordados M =2
• Não existe
20. Aprovação do usuário das especificações do projeto
4 2
• Formal, aprovação com base na análise estruturada e detalhada revisão dos processos
• Formal, aprovação escrita baseada em um informal
não estruturado processo de revisão detalhado M = 2 • Sem aprovação formal; revisão superficial
• No sistema externo envolvido
• Comunicações entre sistemas crítica controladas através de documentos de controle de interface de ; protocolos padrão utilizados: interface estável • Comunicações entre sistemas crítica controladas através de documentos de controle de interface: alguns protocolos não padrões: interfaces raramente são alteradas
M = 3
• Não em todas as comunicações entre sistemas críticos controlado através de interface de controle de documentos: alguns protocolos padrões: algumas interfaces mudam freqüentemente
22 Tipo de adequação do gerenciamento de configuração do planejamento
9 3
• Completa e funcionamento M = 3
• Revisões submetidas de insuficiências • Nenhum disponível
23. Tipo de normas e orientações a seguir pelo projeto
Utilizar conceitos e padrões de programação estruturada, refletem a atual metodologia e
permite adaptar a natureza e o alcance do projeto de desenvolvimento
15
• Normas exigem uma abordagem de cima para baixo e oferecem alguma flexibilidade na aplicação
3 • padrões são desatualizados e inflexível M = 5
24. O grau em que o sistema é baseado em requisitos bem formulados
15 3
• Transações detalhadas e dados paramétricos em requisitos de documentação
• Dados de transações detalhado em requisitos de
documentação A = 5
• Documentação das exigências vaga
25. Relações com aqueles que estão envolvidos com o sistema (por exemplo, usuários, clientes, patrocinadores, interfaces) ou que devem ser tratadas durante o esforço do projeto
• Necessidades conflitantes não importantes: sistema atende principalmente uma unidade organizacional • Sistema atende limitadas necessidades em conflito de unidades de organizações cooperativa
• Sistema deve atender as importantes necessidades conflitantes de várias unidades de organizações cooperativa
M = 3
• Sistema deve satisfazer necessidades conflitantes importantes de várias unidades organizacionais não cooperantes
26. Alterações na área de usuário necessária para atender aos requisitos
2 2
• Não aplicável
• Mínimo B = 1
• Um pouco • Maior
27. Atitude geral de usuário 2 2
• Bom: valores de solução de processamento de dados
B= 1 • Justo: alguma relutância
• Pobre: não apreciam a solução de processamento de dados
28. Status de pessoas, processos, conhecimento, disciplina e divisão dos detalhes dos escritórios que irão utilizar no contexto do sistema
9 3
• bom
• Situação boa para excelente
• Situação satisfatória, mas poderiam ser melhorada M = 3 • Situação menos satisfatória
29. Compromisso do gerenciamento sênior de usuário de sistema
6 3
• Extremamente entusiasta • Adequada
M = 2
• Alguma relutância ou nível de compromisso desconhecido
30. Dependência do projeto sobre as contribuições dos esforços técnico de outras áreas (por exemplo, administração de banco de dados)
9 3
• Nenhum
• De dentro da TI M = 3
• De fora da TI
31. Conhecimento e experiência do usuário de TI 9 3
• Altamente capaz A = 3
• Exposição anterior mas limitado conhecimento • Primeira exposição
32. Conhecimento e experiência do usuário na área de aplicativos
9 3
• Experiência anterior M = 3
• Compreensão conceitual • Conhecimento limitado
33. Conhecimento e experiência da equipe do projeto na área de aplicativos
9 3
• Experiência anterior M = 3
• Compreensão conceitual • Conhecimento limitado
34. Grau de controle pelo gerenciamento do projeto • Autoridade formal proporcional à responsabilidade atribuída
9 3
• Autoridade informal proporcional à responsabilidade atribuída
• Responsabilidade mas nenhuma autoridade
M = 3
35. Eficácia da comunicação do projeto 9 3
• Fácil acesso ao gestor(es) do projeto; Alterar informações prontamente transmitidas para cima e
para baixo M = 3
• Acesso limitado ao gestor (es) do projeto; comunicação descendente limitada
• Gerenciamento de projeto alheio; informações sobre planejamento de perto realizada
36. Parecer da equipe de teste sobre a conformidade das especificações de sistema necessário para o negócio com base em testes iniciais e/ou avaliações
• Testes operacionais indicam que os procedimentos e operações produzam resultados desejados
M = 5 • Testes limitados indicam que procedimentos e
operações diferem de especificações em menores aspectos somente
• Procedimentos e operações diferem de especificações em importantes aspectos:
especificações insuficientes para usar para testes
37. Sensibilidade das informações 9 3
• Nenhuma
• Alta M = 3
Total Score =Soma da Classificação x Peso de cada ítem
242 Preparado por: Eduardo M. B. Alonso e
Jorge Luís Guedes Alves
PARTE II
•
Baseado no
Segmento da Missão Lunar 2010 - COLETA DE
AMOSTRAS – CAVAL, vamos preencher o Work Paper 3-2
WORK PAPER 3-2 Avaliação de riscos técnicos
Classificação:B – Baixa - M – Media - A – Alta - NA – Não se aplica
RISCO CLASSIFICAÇÃO/SCORE PESO
1.Capacidade para cumprir a missão durante a falha de hardware ou software
6 3
• Pode ser realizada sem sistema
• Pode ser realizada sem sistema operacional plenamente, mas alguma capacidade mínima exigida
M = 2
• Não pode ser realizada sem sistema completamente automatizado
2. Disponibilidade de sistema necessário 4 2
• Uso periódico (semanal ou com menos freqüência)
• Uso diário (mas não 24 horas por dia)
M = 2 • Uso constante(24 horas por dia)
3. Grau ao qual a capacidade de funcionamento do sistema baseia-se na troca de dados com sistemas externos
• Funções de forma independente: envia dados não necessários para o funcionamento de outros
sistemas
• Deve enviar e/ou receber dados para ou de outro sistema
M = 3
• Deve enviar e/ou receber dados para ou de vários sistemas
4. Natureza do sistema para comunicações 2 2
• Sistema não tem nenhum interfaces externas B = 1 • Link de comunicação automática usando o
protocolo padrão
• Link de comunicação automática usando o protocolo não padrão
5. Limitações estimada de tamanho de programa 2 2 • Capacidade substancial não utilizada
• Dentro da capacidade
B = 1 • Próximo do limite da capacidade
6. Grau de procedimentos especificados para controle de dados de entrada
6 3
• Verificação detalhada de erro M = 2 • Verificação geral de erro
• Não verificação de erro
7.Tipo de hardware do sistema a ser instalado 2 2
• Nenhum hardware necessário B = 1 • Lote padrão ou sistemas on-line
• Periféricos não standard
• Periféricos e mainframes não standard
8. Base para seleção de software de programação e do sistema
4 2
• Construção da análise funcional e desempenho de requisitos
M = 2
• Experiência em desenvolvimento de sistema similar
• Inventário de software do sistema atual e as competências linguísticas
9. Complexidade do sistema projetado 9 3
• Única função (por exemplo, processamento de texto apenas)
•várias funções relacionados (por exemplo, geração de mensagem, edição e difusão)
• Múltiplos mas não estreitamente relacionadas com funções (por exemplo, consulta de banco de dados, manipulação estatística, gráficos, plotagem, edição de texto)
10. Nível projetado de linguagem de programação
6 3
• Alto nível, amplamente utilizado M = 2 • Baixo nível ou linguagem de máquina, amplamente
utilizado
• Linguagem de propósito especial, uso extremamente limitado
11. Adequação da linguagem para aplicativos 6 3
• Todos os módulos podem ser codificados de maneira
simples no idioma escolhido
• Todos os módulos podem ser codificados de uma maneira simples com algumas rotinas de saída, técnicas sofisticadas e assim por diante
M = 2
• Número significativo de rotinas de saída, técnicas sofisticadas e assim por diante são necessários para compensar as deficiências no idioma selecionado
12. Familiaridade da arquitetura do hardware 2 2
• Mainframe e periféricos amplamente utilizados B = 1 • Periféricos familiarizados
• Mainframe familiarizados
13. Grau de pioneirismo (extensão para que novas e difíceis e não comprovadas técnicas sejam aplicadas)
6 3
• Conservador: nenhum dos componentes do sistema é inexperiente; nenhum pioneirismo no objetivo do sistema ou técnicas
• Moderada: alguns componentes importantes do sistema e funções são inexperiente; alguns pioneiros sistema de objetivos e técnicas
M = 2
• Agressivamente pioneiro: mais alguns componentes de hardware ou software não comprovados ou objetivos do sistema
14. Adequação de hardware para o ambiente do aplicativo
6 3
• Hardware padrão
• Arquitetura altamente comparável com funções necessárias
• Arquitetura suficientemente poderosa mas não particularmente eficiente
• Arquitetura dita rotinas de software complexa
15. Margem de erro (necessidade de perfeito funcionamento, loading timing e uma cooperação e coordenação
significativa)
6 3
• Margem confortável
• Realisticamente exigente M = 2
• Muito exigente; irrealista
16. Familiaridade da equipe de projeto com funcionamento do software
9 3
• Experiência considerável M = 3
• Alguma experiência ou experiência desconhecida
• Pouca ou nenhuma experiência
17. Familiaridade da equipe de projeto com o ambiente do sistema de suporte a
aplicativos
9 3
• Experiência considerável M = 3
• Alguma experiência ou experiência desconhecida
• Pouca ou nenhuma experiência com: Sistema operacional
DBMS
Data Communications
18. Conhecimento da equipe do projeto na área do aplicativo
9 3
• Experiência anterior A = 3
• Compreensão conceitual • Conhecimento limitado
19. Tipo de ferramentas de testes usadas 6 3
• Abrangente teste/estréia de software, incluindo o caminho de analisadores
M = 2 • Formal, somente instrumentos processuais
documentados • Nenhuma
• Testes executados no sistema operacional: total de ambiente de banco de dados e ambiente de comunicação
• Testes efetuados no sistema de
desenvolvimento separado: banco de dados total, comunicações limitadas
M = 3
• Testes efetuados nos diferentes sistemas de desenvolvimento: banco de dados e
comunicações limitadas
21. Teste nas mudanças de interface de comunicações
9 3
• Não há interfaces necessárias
• Teste na linha real em taxa de transação operacional
• Loop de testes na linha real, transações simuladas
M = 3
• Linha de simulações no sistema de desenvolvimento
22. Importância do treinamento para o sucesso do sistema
6 3
• Pouco treinamento necessário para usar ou operar o sistema do usuário: documentação é suficiente para treinamento
• Usuários e ou operadores não necessitam nenhum treinamento formal, mas é
necessária além de documentação
M = 2
• Usuários essencialmente incapazes de operar o sistema sem treinamento prático formal de experiência de documentação 23. Grau estimado de adaptabilidade para mudança no sistema
4 2
• Alto: técnicas de programação estruturada utilizadas: relativamente não remendada, bem documentados
• Moderado
M = 2
• Baixo: design de programa monolítico, alto grau de interior / dependência entre sistemas, não-estruturado de desenvolvimento,
documentação mínima
Total Score =Soma da Classificação x Peso de cada item
137 Preparado por: Eduardo M. B. Alonso e
PARTE III
•
Baseado no
Segmento da Missão Lunar 2010 - COLETA DE
AMOSTRAS – CAVAL, vamos preencher o Work Paper 3-3
WORK PAPER 3-3 Avaliação do Tamanho do Risco Avaliações:
L - Baixo – M - Médio – H - Alto – NA - Não Aplicável Classificação de risco RATING x PESO = SCORE RISCO
1. Ranking deste projeto no total de horas de trabalho dentro dos limites estabelecidos pela organização para pequenos e grandes projetos de sistema de desenvolvimento (em número de horas de trabalho) 2 peso = 1 score = 2
• Baixa - projetos de desenvolvimento de sistemas por terceiros L = 1 • Médio - projetos de desenvolvimento de sistemas por terceiros M = 2 • Alto - projetos de desenvolvimento de sistemas por terceiros H = 3 2. Tempo de execução do Projeto 3 peso = 2 score = 6
• 12 meses ou menos L = 1
• 13 a 24 meses M = 2
• Mais de 24 meses, com implementação faseada H = 3 • Mais de 24 meses, sem eliminação H = 4
3. Programação de estimativa de projeto 3 peso = 1 score = 3
• Antes da programação L = 1
• Na programação M = 2
• atraso (por três meses ou menos) H = 3 • atraso (mais de três meses) H = 4
4. Número de sistemas de interligação com a aplicação 2
peso = 2 score = 4
• 1-2 L = 1
• 3-5 M = 2
• Mais de 5 H = 3
5. Percentual dos recursos alocados ao projeto de teste do sistema 2 peso = 1 score = 2
• Mais de 40% L = 1 • 20 a 40% M = 2 • Menos de 20% H = 3
6. Número de inter-agrupamentos lógicos de dados (uma estimativa, se desconhecido)
3 peso = 1 score = 3
• Menos de 4 L = 1
• 4-6 M = 2
• Mais de 6 H = 3
7. Número de tipos de transação 3 peso = 1 score = 3
• Menos de 6 L = 1
• 6-25 M = 2
• Mais 25 H = 3
8. Número de relatórios de saída 3 peso = 1 score = 3
• Menos de 10 L = 1
• 10-20 M = 2
• Mais de 20 H = 3
9. Ranking do número de linhas de código do programa a ser mantida dentro dos limites estabelecidos pela organização para menores e maiores projetos de desenvolvimento de sistemas (em número de linhas de código) 2
peso = 2 score = 4
• Baixo - projetos de desenvolvimento de sistemas por terceiros L = 1 • Médio - projetos de desenvolvimento de sistemas por terceiros M = 2 • Alto - projetos de desenvolvimento de sistemas por terceiros H = 3
Score Total 30 Contagem Total / Peso Total = Média de Risco
PARTE IV
•
Baseado no
Segmento da Missão Lunar 2010 - COLETA DE
AMOSTRAS – CAVAL, vamos preencher o Work Paper 3-4
WORK PAPER 3-4
ANÁLISE DO SCORE DO RISCO
DOCUMENTO DE TESTE Pontuação de Análise de Risco
Sistema de aplicação : MÓDULO LUNAR - CAVAL - COLETA DE AMOSTRAS
SCORE TAXAS COMPARATIVAS COM
ÁREA DE RISCO APLICAÇÕES DA EMPRESA COMENTÁRIOS
TOTAL MÉDIA ALTO MÉDIO BAIXO
ESTRUTURA 242 0,59168 N/A N/A N/A N/A
TECNOLOGIA 137 0,33496 N/A N/A N/A N/A
TAMANHO 30 0,07334 N/A N/A N/A N/A
SCORE TOTAL DE RISCO 409
ATRIBUTOS DE ALTO RISCO
ÁREA DE RISCO ATRIBUTOS DO RISCO PREOCUPAÇÕES DO TESTE
Estrutura
Disponibilidade de instalações especiais para o subsistema de teste
O grau em que o sistema é baseado em requisitos bem formulados
Conhecimento e experiência do usuário de TI
Ambiente deverá estar preparado em tempo hábil
Sistema altamente complexo exige requisitos precisos
Perda de cientistas
especialistas nas regras de negócio do sistema
Tecnologia
Complexidade do sistema projetado
Conhecimento da equipe do projeto na área do aplicativo
Elaborar plano de teste q atenda a complexidade do sistema
Equipe com alto grau de desenvolvimento técnico
Tamanho
Tempo de execução do projeto Programação de estimativa de projeto
Estouro do tempo para entrega do projeto Elaborar com cuidado previsão orçamentaria
PARTE V
• Preencher o Work Paper 3-5, Testing Tactics Checklist, com dados
referentes ao Segmento do seu Grupo da Missão Lunar 2010-2
• ATENÇÃO – Serão chamados aleatoriamente elementos individuais de
cada grupo para justificar algumas respostas aos questionários. Espera-se
que todos participem nos preenchimentos.
Work Paper 3-5 Testing Checklist Tactics
Responda: SIM / NÃO - COMENTÁRIOS
1. Você usou sua estratégia de teste como um guia para o desenvolvimento das táticas de teste? SIM
2. Você decompôs sua estratégia em táticas de teste? SIM
(Pode não ocorrer integralmente até a etapa de planejamento de teste.)
3. Será que você considere os trade-offs entre os fatores de teste quando realiza o desenvolvimento de táticas de teste (por exemplo, escolher entre a continuidade de processamento e precisão)? SIM
4. Será que você compara suas táticas de teste para a estratégia de teste para garantir que o apoio à estratégia? SIM
5. Você identificou os indivíduos que podem realizar os testes? SIM 6. Você quis compor uma estratégia para recrutar os indivíduos? NÃO
7. Será que a gestão concorda em deixar os membros da equipe de aceitação com as responsabilidades propostas pela equipe do projeto? SIM
8. Foi criado um plano de teste para o teste? SIM
Se assim for: que a equipe de teste tenha as seguintes atribuições:
Objetivos testes definidos, Desenvolver uma estratégia de teste, Desenvolver as táticas de teste, Definir os recursos de teste, Execute os testes necessários para atingir o plano de teste.
9. Modificar o plano de teste e execução de teste quando ocorrer mudanças SIM Manejar o uso de recursos de teste, Emissão de relatórios de ensaios,
10. A equipe de teste representa adequadamente:NÃO
Pessoal do usuário, Pessoal de operação, Administração de dados,
Os auditores internos, Pessoal de alta qualidade, A tecnologia da informação, Gestão, Administrador de segurança, Testadores Profissionais
11. Será que você desenvolve as atribuições da equipe de teste para cada membro teste? A equipe de teste aceita a responsabilidade de encontrar defeitos no cliente? SIM
12. A equipe de teste assume a responsabilidade de encontrar defeitos? NÃO
13. A equipe de reconhece o benefício de remoção de defeitos no início do processo de ciclo de vida de correção? SIM
14. Vai começar a testar, quando começar o processo de desenvolvimento? NÃO 15. Será que uma pessoa tem a responsabilidade primária para o teste? SIM 16. Será que a equipe de teste executa testes de validação? SIM
17. Poderá a equipe de teste executar testes de verificação? SIM 18. Será que os testes de verificação incluem revisões exigência? SIM 19. Será que os testes de verificação incluem revisões de design? SIM 20. As verificações incluem orientações ao código? SIM
21. Será que os testes de verificação incluem inspeções de código? SIM 22. Será que os testes de validação incluem testes de unidade? SIM 23. Os testes de validação incluem testes de integração? SIM
24. Será que os testes de validação incluem teste do sistema? SIM
25. Será que os testes de validação incluem testes de aceitação do usuário? SIM 26. Testadores desenvolvem teste de bancada? SIM
27. A bancada identifica as entregas / produtos a serem testados? SIM 28. Será que a bancada inclui procedimentos de teste? SIM
29. Vai verificar a exatidão da implementação no teste de bancada? SIM 30. Você pode identificar os resultados do teste? SIM
31. A sua bancada identifica as ferramentas que você vai usar? SIM
32. Tem os testadores identificado alguma fonte dessas ferramentas de teste genéricas? SIM
PARTE VI
• Preencher o Work Paper 4-1, Selecting Tools, com dados referentes ao
Segmento do seu Grupo da Missão Lunar 2010-2
Ferramenta / utilização Sim Não Análise do valor limite
Divide-se o sistema em segmentos lógicos e, em seguida, testa os limites dentro dos limites de cada segmento.
Captura / reprodução
Teste utilizado para capturar as transações do processo de teste de reutilização em futuros testes.
Gráfico Causa-efeito
Limita o número de operações de teste, determinando que o número de condições variáveis representam o mínimo risco com base em ações do sistema ..
Checklist
Fornece uma série de perguntas destinadas a sondar potenciais problemas nas áreas do sistema
Comparação de Código
Compara duas versões de um mesmo programa, a fim de identificar as diferenças entre as duas versões.
Análise baseada em compilador
Detecta erros durante o processo de compilação do programa. Confirmação / exame
Verifica se uma condição ocorreu, ou não ocorreu. Análise de fluxo de controle
Identifica inconsistências no processamento, como rotinas com nenhum ponto de entrada, loops potencialmente infinitos, problemas no meio de uma rotina, e assim por diante.
Prova correta
Requer uma hipótese a prova a ser definida e utilizada para avaliar a justeza do sistema.
Dicionário de dados
Gera dados de teste para verificar os programas de validação de dados com base nos dados contidos no dicionário.
Análise do fluxo de dados
Identifica dados não utilizados e os dados utilizados, e o que não está
X X X X X X X X X X X
definido.
Banco de dados
Repositório de coleta de informações sobre testes ou para uso em posterior análise
Desenvolvimento baseado no Teste Funcional
Avalia funções atribuíveis ao processo de design ao contrário do projeto exigências, por exemplo, a capacidade pode ser um processo de design.
Revisão de Projeto
Requer opiniões em pontos pré-determinados durante o desenvolvimento de sistemas, a fim de examinar os progressos e assegurar que o processo de desenvolvimento seja seguido.
Posto de controle
Fornece uma avaliação pelo programador ou analista de propriedade da lógica do programa depois que o programa é codificado ou o sistema foi concebido.
Desastroso teste
Simula uma falha operacional ou de sistemas para determinar se o sistema pode ser corretamente recuperado após a falha.
Erro / adivinhação
Confia na experiência de testadores e histórico da organização dos problemas para criar operações de teste que têm uma elevada probabilidade de detecção de um erro ..
Executando specs
Fornece uma interpretação de alto nível das especificações do sistema em especificações para criar a resposta ao teste de dados. Interpretação dos pacotes de software exige que as especificações do sistema seja escrito em uma linguagem de alto nível.
Uma averiguação
Executa as diligências necessárias para obter os fatos para apoiar o processo de teste.
Fluxograma
Pictoricamente representa a lógica de sistemas computacionais e fluxo de dados.
Inspeções
Requer uma explicação passo-a-passo do produto e a cada passo é verificado contra uma lista de critérios pré-determinados.
X X X X X X X X X X
Instrumentação
Mede o funcionamento de uma estrutura do sistema usando os contadores e outros instrumentos de acompanhamento.
Integrado instalação de ensaio
Permite a integração de dados de teste em um ambiente de produção para permitir o teste a ser executado durante o processamento da produção.
Mapeamento
Identifica que parte de um programa é executado durante um teste e com que freqüência.
Modelagem
Simula o funcionamento do ambiente ou sistema de estrutura, a fim de determinar a eficiência do sistema de solução proposta ( se funcionará). Operação paralela
Verifica que na versão antiga e nova do sistema de aplicação, produz resultados iguais ou conciliáveis.
Simulação Paralela
Aproxima os resultados esperados do tratamento por simulação do processo para determinar se os resultados dos testes são razoáveis.
Revisão por pares
Fornece uma avaliação por pares da eficácia, estilo, aderência aos padrões, e assim por diante do produto que visa melhorar a qualidade. Razões / relacionamentos
Para fornecer uma prova de alto nível quantitativo de que alguns aspectos do software ou do teste é razoável.
Matriz de risco
Produz uma matriz que demonstre a relação entre o risco do sistema, o segmento do sistema em que o risco ocorre, e a presença ou ausência de controles para reduzir esse risco.
Scoring
Identifica áreas de aplicação que requerem testes através da avaliação de critérios que foram mostrados para correlacionar os problemas.
Snapshot
Mostra o conteúdo do armazenamento em computador de pontos predeterminados durante o processamento.
X X X X X X X X X X X
Execução simbólica
Identifica os caminhos de transformação por meio de testes com os programas simbólicos ao invés de dados de testes reais.
Logs do sistema
Fornece uma trilha de auditoria de eventos monitorados (ocorrem em área do ambiente controlado pelo software do sistema).
Dados de teste
Cria operações para uso na determinação do funcionamento de um sistema de computador.
Gerador de dados de teste
Operações de teste com base nos parâmetros que precisam ser testados Os scripts de teste
Criando as operações de teste na seqüência em que as operações serão processadas por um sistema de software online.
Rastreamento
Segue a lista e os fluxos de processamento de dados e pesquisas. Os casos de uso
Preparar as condições de ensaio que representam o mundo real usado no software.
Teste de volume
Identifica a restrição do sistema (por exemplo, o tamanho da tabela interna) e depois cria um grande volume de transações que excedam os limites.
Walkthroughs
Lidera uma equipe de teste através de uma simulação manual de operações utilizando o teste do produto.
X X X X X X X X X
PARTE VII
• Preencher o Work Paper 4-2, Documenting Tools, com dados referentes à
sugestão de ferramentas reais de Teste de Software para o seu Segmento
da Missão Lunar 2010-2. Este WP 4-2 deve ser preenchido
individualmente por cada aluno.
WORK PAPER 4-2
