CE-229 – Teste de Software
Prof. Dr. Luiz Alberto Vieira Dias
Prof. Dr. Adilson Marques da Cunha
LISTEX 05
Relatório de Lista de Exercícios
Sistema de Controle de Acessos Indevidos (SCAI)
Plano de Teste
i
Histórico e Distribuição de Documentos
1. Histórico da Revisão
Versão Data Descrição Autor(es)
1.0 15/06/2012 Primeira versão Roberto Pepato Mellado
Juvenal Silva Neto Reginaldo Rangel Luma Maia Ferreira Marcio Cravo
Luiz Felipe Simões Hoffmann Ednelson Oliveira
Luiz Eduardo Guarino Robson Cassol
ii
SUMÁRIO
1. IDENTIFICADOR DO PLANO DE TESTE ...1
2. REFERÊNCIAS ...1
3. INTRODUÇÃO ...2
4. ITENS DE TESTE ...3
5. QUESTÕES DE RISCO DE SOFTWARE ...4
6. CARACTERÍSTICAS A SEREM TESTADAS ...4
7. CARACTERÍSTICAS QUE NÃO SERÃO TESTADAS ...5
8. ABORDAGEM ...5
9. CRITÉRIOS DE APROVAÇÃO E FALHA ...6
10. CRITÉRIOS DE ENTRADA E SAÍDA ...7
11. CRITÉRIOS DE SUSPENSÃO E REQUISITOS DE REINÍCIO ...7
12. ENTREGÁVEIS DE TESTE ...7
13. TAREFAS DE TESTES RESTANTES ...7
14. NECESSIDADES DE AMBIENTE ...8
15. NECESSIDADES DE PESSOAL E TREINAMENTO ...9
16. RESPONSABILIDADES ...9
17. PLANEJAMENTO DE RISCOS E CONTINGÊNCIAS ...9
18. APROVAÇÕES ...9
1
1. IDENTIFICADOR DO PLANO DE TESTE
SCAI-PTM-01.0
2. REFERÊNCIAS
[1] Project Backlog (PJB) – SCAF, Versão 1.4. Disponível em: https://sites.google.com/site/projetoscaf/
[2] Documento da Arquitetura de Software, Versão 1.0. Disponível em: https://sites.google.com/site/projetoscaf/
[3] Planilha Gerenciamento_Scrum_SCAF.xls. Disponível em: https://sites.google.com/site/projetoscaf/
[4] Modelo de plano de teste para projetos de software. Disponível em: http://www.softwaretestingvídeos.com/
[5] IEEE 829 – 2008. IEEE Standard for Software and System Test Documentation. [6] Test Plan Outline. Disponível em:
http://www.computing.dcu.ie/~davids/courses/CA267/ieee829mtp.pdf [7] Software Test Plan Template. Disponível em:
http://www.epmo.scio.nc.gov/library/docs/TESTPLAN.doc
[8] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/rpepato/ce-229.
[9] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/juvsnt
[10] ListEx4 – Casos de Teste. Disponível em:
https://sites.google.com/site/rerangel2012/home/ce-229
[11] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/lumamaia229/
[12] ListEx4 – Casos de Teste. Disponível em:
https://sites.google.com/site/macramo229/disciplinas/ce-229---teste-de-software
[13] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/lfelipesh/
[14] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/ednelsonoliveira/
[15] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/luizeduardoguarino/
2
3. INTRODUÇÃO
Este é o Plano de Teste Mestre com o objetivo de testar a integração do componente de Sistema de Controle de Acessos Indevidos (SCAI) do Projeto do Sistema de Controle de Acessos e Fraudes (SCAF). Este plano abordará os seguintes módulos:
• Gerenciamento de Versões de Software (GVS); • Gerenciamento de Interface (GDI);
• Gerenciamento de Permissões (GDP);
• Gerenciamento de Segurança de Dados (GSD); • Gerenciamento de Middleware (GDM);
• Gerenciamento de Interoperabilidade (GRI); • Gerenciamento de Mídias de Validação (GMV); • Gerenciamento de Registros de Acesso (GRA).
O escopo deste plano de teste é verificar e validar as User Stories com o objetivo de atender aos requisitos estabelecidos definidos no documento de backlog do projeto [1].
O plano de teste será desenvolvido em níveis de Unidade, Integração, Sistema e Aceitação. Os detalhes estão especificados na seção “Abordagem”.
A Figura 3.1 ilustra a visão geral dos componentes do sistema SCAF.
3
4. ITENS DE TESTE
Serão testadas as User Stories conforme especificação do documento
“Gerenciamento_Scrum_SCAF.xls”, planilha “PRODUCT BACKLOG”. São estas:
• item 11: “Como GDP, devo receber a lista de códigos de permissão de um usuário pedindo acesso, enviada pelo GSD.”;
• item 12: “Como GDP, devo verificar todos os setores autorizados ao usuário, correspondentes aos códigos de permissão associados a seu nome e senha.”;
• item 13: “Como GDP, devo liberar a permissão de acesso do usuário a todos os setores da lista de setores autorizados.”;
• item 14: “Como GRI, é necessário cadastrar os contratos entre funções, serviços e usuários, dizendo quais usuários podem acessar quais serviços através de quais métodos.”;
• item 15: “Como GRI, é necessário validar o pedido de acesso de certo usuário, utilizando certa função a um serviço ativo.”;
• item 16: “Como GRI, é necessário liberar o acesso ao serviço pedido a quem tem direitos ou retornar uma mensagem dizendo que o acesso foi negado.”;
• item 17: “Como GSD, é necessário capturar o nome e a senha digitados pelo usuário e verificar se os mesmos são válidos.”;
• item 18: “Como GSD, é necessário descobrir o código de permissão deste usuário cadastrado que entrou como nome e senha para obter acesso.”;
• item 19: “Como GSD, é necessário enviar estes códigos (podem ser vários) em uma lista ao módulo GDP.”;
• item 28: “Como GMV, devo permitir cadastro e listagem de emissores”; • item 29: “Como GMV, devo permitir cadastro e listagem de mídias”; • item 30: “Como GMV, devo permitir cadastro e listagem de acessos”; • item 31: “Como GMV, devo permitir listagem de validações”;
• item 32: “Como GDI, é necessário disponibilizar ambiente de autenticação para o usuário.”;
• item 33: “Como GDI, é necessário disponibilizar informações do gerenciamento de interface a quem necessitar.”;
• item 34: “Como GDI, é necessário receber as informações necessárias para devida integração dos demais módulos”;
• item 35: “Como GVS, é necessário receber a informação passada pelo GSD e validá-las.” • item 36: “Como GVS, é necessário descobrir os níveis deste usuário cadastrado que entrou com nome e senha para obter acesso e gerenciar as versões do software disponível.”;
• item 37: “Como GVS, é necessário disponibilizar as informações das versões (podem ser várias) a quem necessite utilizar.”.
Observação: O módulo GDM não foi previamente listado como item de teste, pelo fato de
não existir um profissional responsável pela camada de apresentação (web) deste módulo. Os testes aplicados ao módulo GDM são os previamente descritos em [8], derivados dos casos de uso descritos no mesmo documento.
4
5. QUESTÕES DE RISCO DE SOFTWARE
As seguintes questões têm impacto direto no processo de desenvolvimento e testes:
• Backup e restauração de arquivos de código, documentação e base de dados devem ser verificados;
• Disponibilidade de infraestrutura de rede para testes;
• Disponibilidade e integridade dos arquivos de código fonte armazenados no repositório do projeto.
• Segurança da base de dados.
6. CARACTERÍSTICAS A SEREM TESTADAS
Seguem-se abaixo as características que serão focadas durante os testes da aplicação: • acesso e segurança do sistema;
• acesso e segurança do módulos; • acesso e validação de serviços; • atribuição das permissões de acesso; • verificação das permissões de acesso; • verificação dos registros de acesso; • gerenciamento das interfaces;
• integração dos softwares de interface; • interface da listagem e cadastro de versões;
• interface da listagem e cadastro de emissores e mídias; • inclusão de uma nova versão;
• inclusão de um novo usuário; • inclusão de um novo middleware; • inclusão de um novo contrato; • inclusão de uma nova mídia; • inclusão de um novo emissor;
• associação de um usuário a um grupo; • conexão de uma middleware ao sistema; • métodos de acesso ao banco de dados;
5
7. CARACTERÍSTICAS QUE NÃO SERÃO TESTADAS
Seguem-se abaixo as características que não serão focadas durante os testes da aplicação. Estas características não serão validadas por não fazerem parte do escopo do componente SCAI, ou por ainda não estarem completamente implementadas:
• nenhuma função não relacionada ao componente de software SCAI; • operações de alteração e exclusão de versões;
• operações de alteração e exclusão de usuários; • operações de alteração e exclusão de middleware; • operações de alteração e exclusão de contratos; • operações de alteração e exclusão de mídias; • operações de alteração e exclusão de acessos; • operações de alteração e exclusão de validações; • operações de alteração e exclusão de emissores.
8. ABORDAGEM
8.1 Níveis de Testes
Os testes para o componente de software SCAI ocorrerão em níveis de Unidade, Integração, Sistema e Aceitação.
Os testes de Unidade serão realizados pela equipe de desenvolvimento. Deverão ser provados e aprovados pelo Prof. Dr. Adilson Marques da Cunha.
Os testes de Integração e Sistemas serão realizados pela equipe de testes com a assistência da equipe de desenvolvimento, quando necessário. Deverão ser aprovados pelo Project Owner (PO) e pelo Prof. Dr. Luiz Alberto Vieira Dias.
Os testes de Aceitação serão realizados pelo PO, com a assistência dos times de desenvolvimento e testes.
O componente de software SCAI entrará na fase de teste de Aceitação somente quando todos os defeitos críticos forem corrigidos.
8.2 Ferramentas
É indispensável a utilização de uma ferramenta de suporte, como “Selenium Web Browser Automation”, para automação dos testes de regressão baseados na camada de apresentação.
6
8.3 Reuniões
Os times de desenvolvimento de testes deverão manter-se atualizados através do Software de Gerenciamento de Projetos “Pivotal Tracker”.
Os membros do time deverão, sempre que necessário, solicitar reuniões presenciais para alinhamento de atividades e esclarecimento de dúvidas que não puderem ser resolvidas remotamente.
8.4 Medidas e Métricas
As seguintes informações serão coletadas pela equipe de desenvolvimento durante os testes de Unidade:
• Defeitos por módulo e gravidade;
• Origem dos defeitos (requisitos, design, codificação).
As seguintes informações serão coletadas pela equipe de testes durante todas as fases de testes:
• Defeitos por módulo e gravidade;
• Origem dos defeitos (requisitos, design, codificação);
• Defeitos identificados em níveis mais altos que deveriam ser identificados em níveis inferiores.
9. CRITÉRIOS DE APROVAÇÃO E FALHA
O percentual de falhas durante a execução dos testes deve ser inferior a 55% para assegurar a finalização deste evento.
Os resultados obtidos na execução de cada caso de teste serão disponibilizados pela Equipe de Teste no final da atividade de execução de cada evento permitindo o acompanhamento do progresso dos testes e reporte das métricas de execução.
Os códigos de status definidos para o reporte das métricas de execução são apresentados na Tabela 9.1.
Status de Execução Descrição
Não executou O caso de teste não foi executado.
Passou O caso de teste foi executado com sucesso de acordo com os
resultados esperados.
Com falha O caso de teste foi executado e não atingiu os resultados
esperados.
Bloqueado O caso de teste não pode ser executado porque depende de um
caso de teste anterior cuja execução falhou ou estão esperando por dados ou recursos que não estão disponíveis.
7
10. CRITÉRIOS DE ENTRADA E SAÍDA
10.1 Critérios de Entrada
Cronograma de desenvolvimento, prevendo quantas horas serão utilizadas com testes (e em quantas iterações). Tal cronograma será elaborado pelo Gerente do Projeto de Software.
10.2 Critérios de Saída
Revisão formal do mesmo com todos os membros do time de software. Uma vez revisado, qualquer modificação deverá seguir o fluxo do Gerenciamento de Mudanças.
11. CRITÉRIOS DE SUSPENSÃO E REQUISITOS DE REINÍCIO
11.1 Alterações no Cronograma
Alterações no cronograma (internos e do cliente), que necessitem de replanejamento das atividades de desenvolvimento e testes.
11.2 Indisponibilidade de Função / Módulo
Módulos ou funções não implementadas podem exigir tanto a suspensão de um teste específico, como de um grupo de testes relacionados.
11.3 Falhas Graves
Falhas que impeçam a continuidade dos testes ou gerem “falsos positivos” no resultados de testes subsequentes.
12. ENTREGÁVEIS DE TESTE
Os seguintes itens de teste serão entregues: • Plano de Teste de Aceitação;
• Plano de Teste de Sistema;
• Plano de Teste de Aplicação de Banco de Dados; • Plano de Teste de Integração das Camadas; • Plano de Teste de Unidade;
• Casos de Teste;
• Relatórios de Falhas (Log de Testes).
13. TAREFAS DE TESTES RESTANTES
Tarefa Atribuído a
Criar Plano de Teste de Aceitação TT
Criar Plano de Teste de Aplicação de Banco de Dados TT
Criar Plano de Teste de Unidade TD
8
14. NECESSIDADES DE AMBIENTE
O sistema SCAF deve ser instalado em computador local padrão, com sistema operacional que suporte as ferramentas “Apache” e “PHP”, como Windows e Linux.
O banco de dados pode ser local.Neste caso é necessária a instalação da ferramenta “MySQL”. No entanto recomenda-se a utilização da base de dados de homologação (http://mysql06.logistica.servicos.ws).
É importante também que o código-fonte esteja sempre atualizado. Para isto, é necessário o uso da ferramenta de controle de versões “Subversion”, através do link: https://scaf.googlecode.com/svn/trunk/.
A Figura 14.1 apresenta o ambiente de desenvolvimento.
9
15. NECESSIDADES DE PESSOAL E TREINAMENTO
É recomendável que os testadores se mantenham atualizados em relação ao Projeto SCAF, através:
• do site oficial do projeto (https://sites.google.com/site/projetoscaf/);
• do Software de Gerenciamento de Projetos “Pivotal Tracker” (http://www.pivotaltracker.com/).
A equipe de teste deverá ter suporte dos alunos da disciplina CE-240 e CE-245 e ter conhecimento das técnicas de software a serem executadas.
16. RESPONSABILIDADES
TD TT PO Cliente Teste de Aceitação X X X Teste de Sistema X Teste de Integração X X Teste de Unidade X X Teste de Regressão X X Revisões de Requisitos X X X XRevisões de Design Interno X X X
17. PLANEJAMENTO DE RISCOS E CONTINGÊNCIAS
Em função de o projeto SCAF ser baseado na metodologia de desenvolvimento ágil de software Scrum, os requisitos estão sendo definidos de forma iterativa e incremental. Neste caso, estes poderão sofrer alterações durante todo o processo de testes.
Assim, torna-se imprescindível que os testadores se mantenham constantemente atualizados e adaptem-se às mudanças. O processo de teste deve ser ágil e automatizado para alcançar resultados positivos.
Além disto, os testadores devem estar familiarizados com todo projeto (e não somente com os seus módulos), para darem continuidade ao processo de testes, em caso de indisponibilidade do principal testador em um módulo específico.
18. APROVAÇÕES
A estrutura de aprovações para o componente SCAI envolve a figura de um PO, responsável por clarificar a visão do cliente aos membros da equipe. O PO pode aprovar uma entrega no controle de qualidade interno, para apresentação cliente, entretanto, somente o cliente pode formalizar o aceite do produto.
Roberto Pepato Mellado – PO
Prof. Dr. Luiz Alberto Vieira Dias – Cliente Prof. Dr. Adilson Marques da Cunha – Cliente
10
19. GLOSSÁRIO
Termo Definição
GDI Gerenciamento de Interface
GDM Gerenciamento de Middleware
GDP Gerenciamento de Permissões
GMV Gerenciamento de Mídias de Validação
GRA Gerenciamento de Registros de Acesso
GRI Gerenciamento de Interoperabilidade
GSD Gerenciamento de Segurança de Dados
GVS Gerenciamento de Versões de Software
PJB Project Backlog
PO Project Owner
PTM Plano de Teste Mestre
SCAF Sistema de Controle de Acessos Indevidos e Fraudes
SCAI Sistema de Controle de Acessos Indevidos
TD Time de Desenvolvimento
