Este blog tem o objetivo de compartilhar conhecimento referente à Disciplina de Engenharia de Software e
Análise de Projeto de Sistemas da turma de Ciência da Computação da Faculdade Anhanguera de Campinas/SP - Unidade 3 - 1° sem/2011.
Email: computacaoes012011@googlegroups.com
terça-feira, 29 de março de 2011
[ATPS]
[ATPS] ATPS - Etapa 2
Faculdade Anhanguera de Campinas
FAC III
Edward Furumoto 0901413362
Lucas Santana Melo 1099433969
Suelen Cosma de Camargo 0950168
Wagner Martins Barbosa 0919400026
ATPS – Etapa 2
Engenharia de Software e Análise de Projeto de Sistemas
Professora Tânia Regina Ramires Bezerra
5º Ciências da Computação
Campinas 2011
REF. | FUNÇÃO | Grau |
RF01. 1 | Tela para cadastro de clientes poderá incluir, alterar ou excluir dados do cliente, como: Nome, CPF/CNPJ, tipo de pessoa (física ou Jurídica), Endereço completo ( Av /Rua, nº, complemento), código da cidade, UF, CEP, Bairro, código do país. | 1 |
RF01. 2 | Código do cliente deve ser fornecido pelo próprio sistema e não deve ser alterado ou excluído após que tenha um histórico com a empresa. | 1 |
RF01. 2 | O cadastro do cliente deve exigir alguns dados obrigatórios como (Endereço completo, CPF ou CNPJ, e-mail, código da cidade), para que caso haja necessidade de emissão de nota fiscal eletrônica esses dados são indispensáveis. | 1 |
RF01. 3 | Relatório que mostre todos os usuários com seus principais dados cadastrais citados na RF01.1, que poderá ser usado para emissão de etiquetas e mala-direta | 2 |
RF02. 1 | Tela para cadastro de serviços poderá incluir, excluir ou alterar um serviço. Cadastrar dados como: descrição do serviço e preço. | 1 |
RF02. 2 | Sistema deve gerar um relatório de serviços com seus respectivos preços para que seja enviado aos clientes. | 2 |
RF02. 3 | Código de serviço deve ser fornecido pelo próprio sistema. | 1 |
RF03. 1 | Tela de cadastro de produtos poderá incluir, alterar ou excluir dados como: descrição, código de tributação, NCM e preço. Deverá apresentar um Text field com a quantidade em estoque do produto, não poderá ter alteração neste campo. | 1 |
RF03. 2 | Código de produtos deve ser fornecido pelo próprio sistema e não deve ser alterado ou excluído caso haja histórico de compra ou venda do mesmo. | 1 |
RF03. 3 | O sistema deve ter uma tela para lançamento de compra de produtos. Será lançada de acordo com a nota fiscal do fornecedor, por isso a tela de compra deve receber os respectivos dados passados pela nota. | 1 |
RF03. 4 | Relatório de venda de produtos, por dia ou um período especifico. | 2 |
RF03. 5 | Sistema deve gerar um relatório de produtos com seus respectivos preços para que seja enviado aos clientes. | 2 |
RF04. 1 | Relatório de fechamento de caixa deverá conter informações de todos os lançamentos feitos no dia e no final, calcular entradas e saídas e mostrar o resultado final do dia. | 1 |
RF04. 2 | Tela para cadastro de conta corrente poderá incluir, alterar ou excluir uma conta corrente e pedir ao usuário que forneça os dados como: descrição da conta, tipo de conta corrente (caixa geral ou bancária). Apresentar em um Text field o saldo da conta e este campo não poderá sofrer alterações. | 2 |
RF04. 3 | O código de conta corrente deverá ser fornecido pelo sistema, iniciando pelo código 2, pois o código 1 será do caixa geral e receberá todos os movimentos diários. | 1 |
RF05. 1 | Tela para inventário de produtos apresentará uma coluna com o nome do produto, quantidade contábil (fornecida pelo sistema), quantidade escritural (que o cliente digitará) e uma coluna de diferença que será negativa ou positiva caso haja. | 2 |
RF05. 2 | O sistema deve gerar um relatório de trilha de auditoria, mostrando todas as alterações, inclusões, exclusões feitas, descriminando o usuário a data e o horário da determinada ação realizada no sistema. | 1 |
RF05. 3 | Tela de cadastro de usuários do sistema poderá incluir, excluir ou alterar um usuário. Dados solicitados nessa tela, são: nome e tipo de usuário. | 1 |
RF05. 4 | Cadastro de usuário deverá ter 3 tipos de usuário sendo que “máster” é o mais completo e possui todo acesso e permissão para fazer qualquer tipo de alteração, modificação e exclusão no sistema. | 1 |
|
REF. | FUNÇÃO | Grau |
RNF01. 1 | No cadastro de clientes, caso os campos obrigatórios não sejam preenchidos, deverá aparecer uma mensagem, informando ao usuário qual é o campo que está em branco ou preenchido errado. | 1 |
RNF01. 2 | Para a escolha da cidade, o sistema deverá ter uma lista com todas as cidades brasileiras, informando o código do IBGE. | 1 |
RNF01. 3 | Sempre que for inserido um novo CPF, CNPJ o sistema deverá fazer uma consulta no banco de dados, e verificar se já existe, caso não haja, fazer a inserção se já houver, informar ao usuário e bloquear o cadastro repetido. | 1 |
RNF01. 4 | Alteração, exclusão, inclusão de clientes, só podem ser feitas por usuários com perfis de administrador e máster. Usuários com perfil de operador só podem visualizar o cadastro. | 1 |
RNF02. 1 | Cadastro de usuários deve ser dividido em 3 níveis (máster, administrador e operador). Só é permitido cadastrar usuários do sistema, aqueles que possuem perfil máster. Administrador e operador não tem acesso a essa tela. | 1 |
RNF02. 2 | Nome do usuário deve conter apenas letras e senha deve conter letras (minúsculas) e números com no máximo 10 caracteres. | 1 |
RNF03. 1 | O lançamento da nota fiscal de compra de produtos poderá ser feita manualmente ou através da importação do DANFE. Para que seja importado o sistema deve ter um método de comunicação com o site da secretaria da fazenda do estado e um espaço para digitar o código de barras do DANFE. | 1 |
RNF03. 2 | Para importação da DANFE, deve levar em consideração a integridade dos dados. Ou importam todos os dados da nota ou não importa nada. | 1 |
RNF03. 3 | Ao clicar no botão “GRAVAR”, o sistema deverá fazer todos os cálculos, e verificar se não há divergência entre os valores lançados. | 1 |
RNF04. 1 | O estoque escritural (saldo dos produtos, baseado nas vendas e compras), deverá ser apresentado para o cliente e depois de feita a contagem e o lançamento no sistema, deverá ter um campo para mostrar se houve perda ou sobra no estoque. | 1 |
RNF05. 1 | Relatórios financeiros devem ser apresentados de forma mais simplificada possível, para que haja compreensão do usuário. | 1 |
RNF05. 2 | No relatório de fechamento de caixa, deverá aparecer o responsável, data e horário. | 1 |
RNF06. 1 | O Sistema deve ser instalado em Sistema operacional Windows XP ou 7,processador core2duo ou superior, memória RAM 2GB no mínimo e 160GB de HD no mínimo. | 1 |
RNF06. 2 | O instalador do sistema deve conter todos os aplicativos e arquivos necessários para seu funcionamento. | 1 |
RNF06. 3 | Deve ser instalado em um servidor e outras estações de trabalho acessarão o sistema através da rede, portando deverá ser desbloqueado a porta 4545 para que tenha total disponibilidade e exclusividade para tramitação de dados entre estação e servidor. | 1 |
RNF06. 4 | Todas as seleções, buscas, geração de relatórios, devem ser implementados de forma que tenham o menor tempo possível para que apresente um resultado para o usuário. | 1 |
RNF06. 5 | O sistema fará um backup a cada 15 dias, compactando-o para que ocupe menos espaço possível em disco. | 1 |
RNF06. 6 | Caso o cliente não queira fazer o backup quinzenalmente poderá ser parametrizado em um arquivo esta opção. | 1 |
RNF06.7 | O IP do servidor deve ser parametrizado e em um arquivo de configuração, este IP será solicitado durante a instalação do sistema. | 1 |
|
[Aula] Testes de Software
- Teste unitário e de cobertura para Java Script com JsUnit e JsCovarage
- Automatizando Testes Funcionais em Aplicações Web
Pesquisando sobre as novidades na área, me deparei com um vídeo interessante postado no blog Grupo de Testadores de Software, questionando se você é um bom testador ou não. Enfim, assistam o video a seguir e verifiquem se percebem alguma coisa não muito comum.
Boa sorte!!!
segunda-feira, 28 de março de 2011
[ATPS] Engenharia de Software - ATPS 2
| VANTAGENS | DESVANTAGENS |
PROVET STANDARD | CUSTO BAIXO | POUCO RECURSO |
PROVET PREMIUM | CUSTO BENEFICIO | SEM SUPORTE A ATUALIZAÇÕES POSTERIORES |
PROVET GOLD | SUPORTE A ATUALIZAÇÕES SEM CUSTOS | NÃO TEM |
Nivel | Tipos de permissões |
1 | - Permite cadastrar dados de clientes; - Cadastrar dados dos animais; - Alterar informações de ambos; - Abertura de caixa ; - Registrar vendas produtos/serviços - Selecionar qual vendedor foi responsavel pela negociação |
2 | - Permite acesso a todos os ambientes do software |
Requisitos | Nivel de prioridade |
Código de cliente | 1 |
Dados do cliente | 2 |
Dados do animal | 1 |
Ficha cadastral de fornecedores negativados | 3 |
Produtos | 1 |
Produtos não mais comercializados | 2 |
Extrato de caixa diario | 1 |
Notas de compras | 1 |
Notas a pagar | 1 |
Valores a receber | 1 |
Agenda de serviços | 2 |
Manutenção | 1 |
Segurança | 1 |
[Seminário] - Automatizando Testes Funcionais em Aplicações Web
Estratégias de Testes de Software
Durante o desenvolvimento de um software, diversas estratégias para teste podem ser aplicadas. Essas estratégias podem ser categorizadas da seguinte forma:
· Baseadas em Implementação: Utiliza o código como elemento para a geração dos testes. É uma atividade cara, sob o ponto de vista de recursos necessários para a sua realização, e bastante complexa quando o tamanho do código de torna bastante grande;
· Baseadas em especificação: utiliza um documento de especificação como base para geração dos testes. Assim, tenta-se cobrir as imposições e restrições descritas nos requisitos estabelecidos para o sistema. A automação da geração dos testes nesse caso é mais complicada, caso não de tenha um formalismo para a elaboração da especificação do sistema;
· Baseados em modelos: é uma subcategoria de estratégias baseada em especificação. Utiliza modelos desenvolvidos ao longo do processo de desenvolvimento que representam o comportamento ou estrutura do software.
Cada estratégia apresentada possui sua aplicabilidade, vantagens e desvantagens.
Teste funcional representa uma categoria de técnicas de teste em que o comportamento de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo.
Haverá sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas ou mesmo uma funcionalidade.
Um dos mecanismos para facilitar a realização de testes funcionais é pensar na automação de algumas tarefas que compõem o processo de testes.
Automação dos Testes
Automação dos testes consiste no uso de algum apoio computacional, ferramentas, para controlar a execução dos testes, a comparação dos resultados e comportamentos esperados, a configuração das pré-condições dos testes e outras atividades do controle dos testes e relato de seus resultados.
Apesar de os testes manuais poderem encontrar muitos defeitos em um software, essa tarefa é complexa, desgastante e consome muito tempo.
A automação dos testes é um processo de escrever um programa computacional para realizar testes que, caso contrário, seriam feitos manualmente, na maioria dos casos, o método de testes com custo mais efetivo para produtos que possuem uma longa vida, com muitas manutenções, pois pequenas modificações em certas partes do software que estariam funcionando anteriormente deixem de funcionar.
Existem duas abordagens gerais para automação dos testes:
· Testes dirigidos a código: as interfaces para classe, módulos ou bibliotecas são testadas com uma larga variedade de argumentos de entrada para validar se os resultados que estão sendo retornados estão corretos;
· Teste de interface: um framework de teste que gera eventos de interface do usuário tais como digitação de teclas ou cliques do mouse, e observa as mudanças que ocorrem na interface do usuário. Assim, podemos validar se o comportamento observado do software após tais eventos estão corretos.
Uma forma de gerar casos de testes automaticamente é utilizando a estratégia de Teste Baseado em Modelos, que adota modelos representando o sistema para geração de casos de testes, porem existem outras estratégias interessantes.
Importância da Automação dos Testes
Uma das principais características das atividades de teste de software, assim como a atividade de desenvolvimento de software em geral, é o fato de serem realizados por pessoas, e consequentemente possíveis erros. Diversos problemas relacionados aos testes a serem aplicados em um software podem ser evitados a partir da automação desta atividade, dentre os quais:
· Dados de entrada de teste incorretos, informando valores ou tipos de dados inválidos;
· Não perceber um comportamento incorreto do software a certo evento;
· Reportar os resultados dos testes incorretamente;
· Esquecer-se de executar alguns casos de teste;
· Esquecer-se de executar alguma pré-condição para execução dos testes;
· Alteração na execução da sequencia de casos de teste, o que poderia levar a execução dos testes a um fracasso;
Além de evitar problemas causados por eventuais falhas humanas, a automação dos testes pode ainda nos proporcionar:
· Uma forma de armazenar conhecimento sobre domínio do projeto ou sobre as funcionalidades que compõem o sistema;
· Garantira a acurácia dos relatórios de testes;
· Velocidade na execução dos testes;
· Realizar testes em momentos específicos e sempre que necessário;
· Simplificação nos testes de regressão;
· Possibilidade de testar o sistema com diferentes conjuntos de dados.
Teste de Interface (Graphical User Interface)
Muitas ferramentas de automação provêm funcionalidades de gravar a execução de um software e rodar esta gravação que permite aos usuários interativamente “filmar” as ações do usuário e repeti-la quantas vezes quiser, comparando os resultados e comportamentos obtidos com aqueles esperados. A vantagem desta abordagem, chamada capture-replay, é que ela requer pouco ou nenhum desenvolvimento de software. Os casos de entrada armazenados podem então ser usados para reproduzir os testes posteriormente. Alterar o nome de um botão ou movê-lo para outra parte da tela pode requerer que os testes tenham que ser regravados.
Uma variação deste tipo de ferramenta seriam as ferramentas para teste de aplicações Web.
Outra variação de automação de testes sem scripts que não usa a ideia de capture-replay, em vez disso constrói um modelo da aplicação a ser testada e então permite ao testador criar casos de teste simplesmente editando os parâmetros e condições de teste. Esta abordagem pode ser aplicada a qualquer software baseado em interfaces.
As ferramentas de automação de testes mais conhecidas podem ser caras, apesar de já existirem diversas ferramentas gratuitas e com um bom conjunto de funcionalidades de apoio à automação dos testes.
Ferramenta Selenium IDE
Selenium IDE é um ambiente de desenvolvimento integrado para testes com Selenium. Foi desenvolvido como uma extensão do Firefox e permite gravar, editar e depurar testes. O Selenium IDE inclui o Selenium Core, permitindo gravar e reproduzir os testes no ambiente que eles serão executados, de maneira fácil e rápida.
Entre suas funcionalidades, podemos citar:
· Gravação e reprodução dos testes de forma simples;
· Seleção de campo inteligente, que captura as informações cobre os campos a partir da página;
· Funcionalidade autocompletar para todos os comandos de Selenium;
· Possibilita navegar entre os testes;
· Possibilita configurar depuração e pontos de paradas para verificação durante os testes;
· Permite salvar os testes como HTML, scripts em Ruby ou outro formato.
Conclusão
Ferramentas automatizam o conhecimento técnico da equipe de teste, mas não conseguem passar sobre este conhecimento para aumentar a qualidade dos testes. Uma vez que este conhecimento é provido pela equipe de teste, ferramentas contribuem significativamente para a redução de esforços dos testes e aumento de sua qualidade.
Thiago de Marco Pinto 09194402322
Henrique Moreno 0947497522