Baixe o app para aproveitar ainda mais
Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original
introdução à engenharia de software/sliders prova 2/IEC993-Aula24-testes.pdf 18/02/2014 1 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 TESTES DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 72 Arilo Claudio Dias Neto Análise do Valor Limite Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no “centro” Análise do Valor Limite é uma técnica de teste que explora os limites dos valores para preparar os casos de teste Está técnica complementa o particionamento em classes de equivalência 18/02/2014 2 Arilo Claudio Dias Neto Análise do Valor Limite Um dos critérios de teste mais básico que existe. Auxilia na seleção de um pequeno subconjunto de casos de teste que mantém um boa cobertura do código. Exemplo (mesmo usado para particionamento por equivalência) ◦ Observe que os limites, tal como o 16, aparece em duas classes de equivalência. ◦ O mesmo ocorre com o 18 e o 55. Arilo Claudio Dias Neto Análise do Valor Limite As condições anteriores, na verdade, deveriam ser escritas como: ◦ Na primeira regra, 16 não deve ser incluído. ◦ Na segunda, 16 pode ser empregado em tempo parcial. 18/02/2014 3 Arilo Claudio Dias Neto Análise do Valor Limite A implementação abaixo implementa as regras: VALORES LIMITES: •REGRA 1 (não empregar): Inferior (-1 e 0) e Superior (15 e 16) •REGRA 2 (parcial): Inferior (15 e 16) e Superior (17 e 18) •REGRA 3 (integral): Inferior (17 e 18) e Superior (54 e 55) •REGRA 4 (não empregar): Inferior (54 e 55) e Superior (99 e 100) Arilo Claudio Dias Neto Análise do Valor Limite Passos de Aplicação 1. Identificar as classes de equivalência. 2. Identificar os limites de cada classe. 3. Criar casos de teste para os limites escolhendo: ◦ Um ponto abaixo do limite inferior. ◦ O limite inferior. ◦ O limite superior. ◦ Um ponto acima do limite superior. 4. Observe que “acima” e “abaixo” são termos relativos e dependente do valor dos dados. ◦ Números inteiros: limite = 16; abaixo = 15; acima = 17. ◦ Números reais: limite = $5,00; abaixo = $4,99; acima = $5,01. Se os valores fora da classe invadem “outra” classe, não precisamos repeti- los 18/02/2014 4 Arilo Claudio Dias Neto Análise do Valor Limite Arilo Claudio Dias Neto Análise do Valor Limite: Exemplo Consideremos a seguinte situação: ◦ "... o cálculo do desconto de IR por dependente é feito da seguinte forma: A entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5%; e dos 22 aos 24 de 3%..." ◦ Aplicando o teste de valor limite convencional serão obtidos casos de teste semelhantes a este: (-1 {inválido}, 0 {15%}, 12 {15%}, 13 {12%}, 18 {12%}, 19 {5%}, 21 {5%}, 22 {3%}, 24 {3%}, 25 {0%}) 18/02/2014 5 Arilo Claudio Dias Neto Análise do Valor Limite: Exercício Teste um programa que calcula o índice de massa corporal (IMC) de uma pessoa, através da fórmula IMC = peso / altura2. Para o resultado, considere a tabela a seguir: Condição IMC em Mulheres IMC em Homens abaixo do peso < 19,1 < 20,7 no peso normal 19,1 – 25,8 20,7 - 26,4 marginalmente acima do peso 25,9 – 27,3 26,5 - 27,8 acima do peso ideal 27,4 – 32,3 27,9 - 31,1 obeso > 32,3 > 31,1 Arilo Claudio Dias NetoArilo Claudio Dias Neto Análise do Valor Limite: Exercício (Resposta) HOMEM MULHER 20,6: Abaixo 20,7 : Normal 26,4 : Normal 26,5: Marginalmente Acima 27,8: Marginalmente Acima 27,9 : Acima 31,1: Acima 31,2: Obeso 19,0: Abaixo 19,1 : Normal 25,8 : Normal 25,9: Marginalmente 27,3: Marginalmente 27,4 : Acima 32,3: Acima 32,4: Obeso 81 18/02/2014 6 Arilo Claudio Dias Neto Análise do Valor Limite: Exercício (Resposta) E quais casos de teste testam essas condições? 82 ID SEXO PESO ALT RESULTADO 1 H 20,6 2 H 20,7 3 H 26,4 4 H 26,5 5 H 27,8 6 H 27,9 7 H 31,1 8 H 31,2 Arilo Claudio Dias Neto Análise do Valor Limite: Exercício (Resposta) E quais casos de teste testam essas condições? 83 ID SEXO PESO ALT RESULTADO 1 M 19,0 2 M 19,1 3 M 25,8 4 M 25,9 5 M 27,3 6 M 27,4 7 M 32,3 8 M 32,4 18/02/2014 7 Arilo Claudio Dias Neto Análise do Valor Limite Limitação em testes baseados em partições de equivalência ou análise de valores- limite: ◦ consideram cada valor de entrada isoladamente ... e se existirem combinações de valores que constituam situações interessantes a serem testadas? Arilo Claudio Dias Neto Grafo de Causa-Efeito Critério necessário quando se deseja testar combinações de entradas Utiliza tabelas de decisão e árvores de decisão ◦ grafo causa-efeito como modelo auxiliar Técnica para identificação de casos de teste que explora as condições lógicas e as ações correspondentes 18/02/2014 8 Arilo Claudio Dias Neto Grafo de Causa-Efeito Para cada módulo, Causas (condições de entrada) e efeitos (ações realizadas às diferentes condições de entrada) são relacionados, atribuindo-se um identificador para cada um. Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado. Neste ponto, transforma-se o grafo numa tabela de decisão. As regras da tabela de decisão são, então, convertidas em casos de teste. Arilo Claudio Dias Neto Grafo de Causa-Efeito Definições ◦ Causas: condições de entrada (valor lógico) ◦ Efeitos: ações realizadas em resposta às diferentes condições de entrada Exemplo: ◦ causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 (restrição do sistema) ◦ efeito: fornecer 5% de desconto 18/02/2014 9 Arilo Claudio Dias Neto Árvore de Decisão Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto qtd preço Preço normal Desconto Mensagem de erro Arilo Claudio Dias Neto Tabela de Decisão 18/02/2014 10 Arilo Claudio Dias Neto Construção da Tabela de Decisão Causas Efeitos Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto Arilo Claudio Dias Neto Construção da Tabela de Decisão Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto Causas Preço ≥ 50 0 ≤ Qtd ≤ 99 Efeitos 18/02/2014 11 Arilo Claudio Dias Neto Construção da Tabela de Decisão Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto Causas Preço ≥ 50 0 ≤ Qtd ≤ 99 Efeitos Fornecer desconto Valor normal Mensagem de Erro Arilo Claudio Dias Neto Construção da Tabela de Decisão Causas Preço ≥ 50 V F V F 0 ≤ Qtd ≤ 99 V V F F Efeitos Fornecer desconto Valor normal Mensagem de Erro Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto 18/02/2014 12 Arilo Claudio Dias Neto Construção da Tabela de Decisão Causas Preço ≥ 50 V F V F 0 ≤ Qtd ≤ 99 V V F F Efeitos Fornecer desconto Valor normal Mensagem de Erro Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto Arilo Claudio Dias Neto Construção da Tabela de Decisão Causas Preço ≥ 50 V F V F 0 ≤ Qtd ≤ 99 V V F F Efeitos Fornecer desconto Valor normal Mensagem de Erro Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto 18/02/2014 13 Arilo Claudio Dias Neto Construção da Tabela de Decisão Causas Preço ≥ 50 V F V F 0 ≤ Qtd ≤ 99 V V F F Efeitos Fornecer desconto Valor normal Mensagem de Erro Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto Arilo Claudio Dias Neto Construção da Tabela de Decisão Causas Preço ≥ 50 V F V F 0 ≤ Qtd ≤ 99 V V F F Efeitos Fornecer desconto Valor normal Mensagem de Erro Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 Efeito: fornecer 5% de desconto 18/02/2014 14 Arilo Claudio Dias Neto Limitação das Tabelas de Decisão Tamanho! ◦ nº de regras = 2N, onde N é o nº de causas Arilo Claudio Dias Neto Geração de testes Tabela de decisão ◦ critério: exercitar cada regra pelo menos 1 vez Árvore de decisão ◦ critério: exercitar cada caminho da raiz até a folha pelo menos 1 vez 99 18/02/2014 15 Arilo Claudio Dias Neto Exemplo Supor um sistema bancário que trate somente duas transações: ◦ depósito nº da conta quantia ◦ saque nº da conta quantia Requisitos: ◦ se o comando é depósito e o nº da conta é válido então a quantia é depositada ◦ se o comando é saque e o nº da conta é válido e a quantia é válida (0 < quantia ≤ saldo) então a quantia sacada ◦ se o comando ou nº da conta ou a quantia for inválido então exibir mensagem de erro apropriada 100 Arilo Claudio Dias Neto Exemplo Causas: ◦ c1. Comando é depósito ◦ c2. Comando é saque ◦ c3. Nº da conta é válido ◦ c4. Quantia é válida Efeitos: ◦ e1. Exibir “comando inválido” ◦ e2. Exibir “nº da conta inválido” ◦ e3. Exibir “quantia inválida” ◦ e4. Depositar a quantia ◦ e5. Sacar a quantia 101 Nº de regras = 24 = 16 Será que todas interessam? 18/02/2014 16 Arilo Claudio Dias Neto Exemplo Grafo de Causa-Efeito: 102 comando conta Conta inválida Quantia Depositada inválida Comando inválido saque conta Conta inválida quantia Saque realizado Quantia inválida Arilo Claudio Dias Neto Exemplo Tabela de decisão: 103 Causas Comando é depósito Comando é saque Nº da conta é válido Quantia é válida Efeitos comando inválido nº da conta inválido quantia inválida Depositar a quantia Sacar a quantia 18/02/2014 17 Arilo Claudio Dias Neto Exemplo Tabela de decisão: 104 Causas Comando é depósito F V V Comando é saque F V V V Nº da conta é válido F V F V V Quantia é válida F V Efeitos comando inválido x nº da conta inválido x X quantia inválida X Depositar a quantia X Sacar a quantia X Arilo Claudio Dias Neto Grafo Causa-Efeito: Exercício Considere uma função com duas variáveis de entrada: Cliente e Qtd, e uma variável de saída, Desconto. Cliente pode ser do tipo A, B ou C e Qtd pode variar de 1 a 1000. A função calcula Desconto de acordo com as seguintes regras: ◦ Clientes do tipo A não recebem desconto se nº de itens comprados for inferior a 10; recebem 5% desconto para compras entre 10 e 99 itens; 10% de desconto a partir de 100 itens. ◦ Clientes do tipo B recebem 5% de desconto para compras abaixo de 10 itens; 15% de desconto entre 10 e 99 itens; 25% de desconto a partir de 100 itens. ◦ Clientes do tipo C não recebem desconto se nº de itens comprados for inferior a 10; 20% de desconto entre 10 e 99 itens; 25% de desconto a partir de 100 itens. 18/02/2014 18 Arilo Claudio Dias Neto Teste de Software Diferente tipos de aplicações (ex: 00, aplicações web, software embarcados) possuem características específicas ◦ Isso impacta nas atividades desenvolvimento e testes Técnicas diferenciadas para desenvolvimento e testes Por exemplo, Software Orientado a Objetos: ◦ trabalha com o encapsulamento das estruturas de informações e seus comportamentos ◦ Não existe um fluxo de execução definido para o software ◦ utiliza um modelo homogêneo para representação do software introdução à engenharia de software/sliders prova 2/IEC993-Aula20-projeto.pdf 05/02/2014 1 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 PROJETO E MODELAGEM DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 1 Arilo Claudio Dias Neto Da Análise ao Projeto Elicitação de Requisitos Análise do Sistema Projeto Codificação Executar Testes A análise se concentra na questão "O quê?" •Objetivo é prover um entendimento dos requisitos, conceitos e operações relacionados a um sistema 05/02/2014 2 Arilo Claudio Dias Neto Da Análise ao Projeto •A próxima fase é a de Projeto, onde a questão "Como?" é abordada Elicitação de Requisitos Análise do Sistema Projeto Codificação Executar Testes Arilo Claudio Dias Neto Projeto de Software O que é? ◦ Conjunto de princípios, conceitos e práticas técnicas que levam ao desenvolvimento de um sistema com qualidade ◦ É o lugar em que a criatividade impera! ◦ Cria uma representação ou modelo de software que fornece detalhes sobre a estrutura dos dados, arquitetura, interface e componentes do software Quem faz? ◦ Arquiteto ou projetista 4 05/02/2014 3 Arilo Claudio Dias Neto Projeto de Software Importância do Projeto “ ... tentamos resolver o problema passando rapidamente pelo projeto (design) para que sobre tempo suficiente no final para detectar e corrigir defeitos que foram introduzidos porque dedicamos pouco tempo ao projeto.” Arilo Claudio Dias Neto Projeto de Software • Transforma elementos estruturais da arquitetura de software em uma descrição dos componentes Projeto em Nível de componente • Descreve como o software se comunica com outros sistemas e com seus usuários Projeto de Interface • Define o relacionamento entre os principais elementos estruturais do software, estilos arquiteturais e padrões de projeto Projeto Arquitetural • Transforma modelo de análise em classes de projeto e nas estruturas de dados dos requisitos Projeto de dados/classes 6 05/02/2014 4 Arilo Claudio Dias Neto Projeto de Software “Há dois modos de construir um projeto de software: um é fazê-lo tão simples que obviamente não haja deficiências, o outro é fazê-lo tão complicado que não haja deficiências óbvias. O primeiro modo é muito mais difícil.” C.A.R. Honre 7 Arilo Claudio Dias Neto Projeto de Software Conceitos de Projeto de Software ◦ Abstração É um dos modos fundamentais pelos quais nós, seres humanos, enfrentamos a complexidade ◦ Arquitetura Estrutura global do software, representada por modelos ◦ Padrão Descreve um problema que ocorre repetidas vezes em nosso ambiente, e então descreve o núcleo de solução daquele problema 8 05/02/2014 5 Arilo Claudio Dias Neto Projeto de Software Conceitos de Projeto de Software ◦ Modularidade Divisão do software em componentes nomeados separadamente e endereçáveis ◦ Ocultamento de Informações Definição e imposição de restrições de acesso aos módulos de um sistema ◦ Independência Funcional Consequência da modularidade e ocultamento de informações Desenvolvimento de módulos independentes 9 Arilo Claudio Dias NetoArilo Claudio Dias Neto PROJETO DE DADOS/CLASSES Modelagem conceitual 10 05/02/2014 6 Arilo Claudio Dias Neto Modelagem Conceitual A Modelagem de Dados Conceitual é a etapa responsável pela identificação dos requisitos de informação no negócio e pela estruturação do banco de dados em um nível lógico. Arilo Claudio Dias Neto Modelagem Conceitual Utilizaremos o diagrama de classes da UML como ferramenta para desenhar o modelo de dados conceitual do sistema que desejamos projetar. 05/02/2014 7 Arilo Claudio Dias Neto Diagrama de Classes da UML Utilizado na construção do modelo de classes, desde o nível de análise até o nível de especificação É o diagrama mais rico da UML, em termos de notação É o diagrama mais utilizado da UML Pode ser mapeado diretamente para uma linguagem OO Ajuda no processo transitório dos requisitos para o código Pode representar visualmente o código do sistema Arilo Claudio Dias Neto Diagrama de Classes da UML Diagrama de casos de uso: ◦ Fornece uma perspectiva do sistema do ponto de vista Externo Diagrama de Classes ◦ Visão interna: descrição do funcionamento interno do software ◦ Dois aspectos internos: dinâmico e estrutural estático 05/02/2014 8 Arilo Claudio Dias Neto Diagrama de Classes da UML Aspecto Estrutural Estático: ◦ Permite compreender como o sistema está estruturado internamente, para que as funcionalidades externamente visíveis sejam produzidas. ◦ Estático: Não apresenta informações de como os objetos interagem no decorrer do tempo ◦ Estrutural: Representação da estrutura das classes e de suas relações Arilo Claudio Dias Neto Diagrama de Classes da UML Aspecto Dinâmico: ◦ Descreve a troca de mensagens entre os objetos, e a sua reação a eventos que ocorrem no sistema. É realizada pelas modelagens de interação e de estados. 05/02/2014 9 Arilo Claudio Dias Neto Diagrama de Classes da UML À medida que o sistema é desenvolvido, o modelo de classes é incrementado com novos detalhes. Ele evolui em três níveis de abstração: ◦ Modelo de classes de domínio ◦ Modelo de classes de especificação ◦ Modelo de classes de implementação Arilo Claudio Dias Neto Diagrama de Classes da UML Modelo de classes de domínio ◦ Construído na fase de análise ◦ Representa as classes no domínio do negócio em questão ◦ Não leva em consideração aspectos inerentes à tecnologia de implementação (tecnologia perfeita e custo zero) 05/02/2014 10 Arilo Claudio Dias Neto Diagrama de Classes da UML Modelo de classes de especificação ◦ Construído na fase de projeto ◦ Adiciona ao modelo de classes de domínio detalhes específicos, conforme a solução de software escolhida ◦ Pode definir novas classes necessárias para desenvolver a solução do problema Arilo Claudio Dias Neto Diagrama de Classes da UML Modelo de classes de implementação ◦ Estende o modelo de classes de especificação ◦ Corresponde à implementação das classes em alguma linguagem de programação 05/02/2014 11 Arilo Claudio Dias Neto Diagrama de Classes da UML Classe: grupo de objetos semelhantes. Uma classe descreve esses objetos através de atributos e operações. ◦ Os atributos correspondem às informações que um objeto armazena. ◦ As operações correspondem às ações que um objeto sabe realizar. Arilo Claudio Dias Neto Diagrama de Classes da UML A 1Km de distância... ◦ Caixas representando as classes ◦ Linhas representando os relacionamentos 05/02/2014 12 Arilo Claudio Dias Neto Diagrama de Classes da UML A 1metro de distância... ◦ As classes são representadas por caixas contendo: Nome (obrigatório) Lista de atributos Lista de operações Arilo Claudio Dias Neto Diagrama de Classes da UML A 1cm de distância dos atributos... ◦ Atributos são descritos via Visibilidade Nome Tipo Multiplicidade Valor padrão 05/02/2014 13 Arilo Claudio Dias Neto Diagrama de Classes da UML A 1cm de distância das associações... ◦ Guarda as mesmas informações dos atributos ◦ Utiliza uma notação gráfica ◦ Deve ser utilizado para propriedades que são relevantes ao diagrama ◦ Determina o papel das classes na associação ◦ Tipos: Generalização, Composição, Agregação, Dependência e Classe de Associação Arilo Claudio Dias Neto Diagrama de Classes da UML Dicas: Inicie com um diagrama simples O que normalmente tem em todo diagrama ◦ Classes ◦ Atributos ◦ Operações ◦ Associações Use os demais recursos da linguagem somente quando for realmente necessário 05/02/2014 14 Arilo Claudio Dias Neto Diagrama de Classes da UML Dicas: Possíveis candidatos à classes Entidades externas que produzem ou consomem informações (ex.: sistema de validação do cartão de crédito) Conceitos que são parte do problema e que são informações compostas (ex.: Produto) Eventos que ocorrem durante a operação do sistema (ex.: Pedido) Papéis que interagem com o sistema (ex.: Cliente) Unidades organizacionais relevantes (ex.: Rede de lojas) Lugares que fornecem o contexto do problema ou do sistema (ex.: Loja) Estruturas definidas no problema (ex.: Estoque) Arilo Claudio Dias Neto Diagrama de Classes da UML Dicas: Possíveis candidatos a: Atributos ◦ Informação primitiva que precisa ser memorizada (ex.: Preço) Associações ◦ A classe A precisa se relacionar com a classe B para atender a operações específicas (ex.: Cliente – Pedido) Operações ◦ Funcionalidades que devem ser providas por uma classe para viabilizar o uso do sistema (ex.: calculaTotal em Pedido) 05/02/2014 15 Arilo Claudio Dias Neto Diagrama de Classes da UML Exemplo Arilo Claudio Dias NetoArilo Claudio Dias Neto PROJETO ARQUITETURAL 30 05/02/2014 16 Arilo Claudio Dias Neto Projeto de uma arquitetura O que é um projeto arquitetural? ◦ Decisões estratégicas que terão consequências profundas ◦ As decisões são tomadas num alto nível Observe que sempre deve-se ter um olho na satisfação dos requisitos levantados ◦ Principalmente requisitos NÃO-FUNCIONAIS!!! Arilo Claudio Dias Neto Projeto de Alto Nível Os modelos de projeto arquitetural devem: ◦ Especificar a decomposição do sistema em subsistemas (modelo da arquitetura do sistema) ◦ Mostrar o relacionamento entre os subsistemas (modelo de controle do sistema) ◦ Decompor os subsistemas em módulos (modelo da arquitetura dos módulos) 05/02/2014 17 Arilo Claudio Dias Neto Projeto de uma arquitetura Exemplos de decisões: ◦ Modularização do projeto em subsistemas ◦ Escolha da divisão de trabalho entre membros de uma equipe ou entre equipes de desenvolvimento ◦ Definição das interfaces entre subsistemas para possibilitar o trabalho paralelo de desenvolvimento ◦ Escolha de uma estratégia de persistência, incluindo SGBD ◦ Determinação de oportunidades para reuso de software ◦ Atendimento a requisitos não-funcionais Arilo Claudio Dias Neto Modularização Característica do software que permite a sua inteligibilidade, permite dividi-lo em componentes menores, chamados módulos. Leva a um esforço menor para resolver problemas C(x)=complexidade do problema E(x)=esforço para resolver o problema C(P1) > C(P2) E(P1) > E(P2) C(P1+P2) > C(P1)+C(P2) E(P1+P2)>E(P1) + E(P2) Como saber se eu dividi o suficiente? 05/02/2014 18 Arilo Claudio Dias Neto Decomposição do sistema: partições e camadas Lembre que subsistemas devem ser coesos (trata de responsabilidades fortemente relacionadas) ◦ Tem forte acoplamento dentro de um subsistema ◦ Tem fraco acoplamento entre subsistemas Para minimizar o acoplamento, camadas frequentemente se comunicam apenas com as camadas "vizinhas“ Decomposição pode terminar quando atingir subsistemas com temas claros que sejam simples de entender Alguns sistemas muito pequenos não necessitam de camadas e partições Arilo Claudio Dias Neto Coesão e Acoplamento Coesão: medida da funcionalidade de um módulo; o quanto ele realiza uma tarefa específica ◦ Deve ser maximizado Acoplamento: mede o grau de interdependência entre módulos ◦ Deve ser minimizado 05/02/2014 19 Arilo Claudio Dias Neto Arquiteturas em N camadas Para sistemas de informação que incluam uma interface com o usuário e persistência (isto é, quase todos!), usa-se frequentemente uma arquitetura em 3 camadas Arilo Claudio Dias Neto Arquiteturas em N camadas As camadas verticais são: ◦ Apresentação: janelas, relatórios, etc. Também chamada de Camada de Interface/Serviço com o Usuário ◦ Lógica da Aplicação: tarefas e regras que governam o processo Também chamada de Camada de Aplicação ◦ Dados: mecanismo de armazenamento persistente Também chamada de Camada de Gerência de Dados ou Camada de Armazenamento 05/02/2014 20 Arilo Claudio Dias Neto Arquiteturas em N camadas Arquitetura em 3 camadas permite: ◦ Usar o browser como cliente universal, levando ao conceito de Intranet ◦ Evitar instalação em computadores de clientes, parceiros, fornecedores, etc. ◦ Implementar serviços automáticos de persistência, tolerância a falhas com failover, gerência de transações, balanceamento de carga, resource pooling, etc. Enterprise JavaBeans, COM+ Arilo Claudio Dias Neto Uso de UML para modelar a arquitetura UML provê diagramas que possibilitam representar a estrutura ou comportamento de sistemas Notação que pode ser usada para representar a arquitetura do software 05/02/2014 21 Arilo Claudio Dias Neto UML – Breve Revisão Significa Linguagem de Modelagem Unificada; Notação para especificação de sistemas; Surgiu nos anos 1990s como um esforço para reunir o melhor dos principais modelos existentes na época; Virou logo um padrão para modelagem de software e design; Arilo Claudio Dias Neto Sucesso da UML Facilita a compreensão de sistemas complexos durante todo o ciclo de vida; Simplifica o reuso de modelos e código; Orientada por natureza para programação OO (além disso a UML não depende da plataforma); 05/02/2014 22 Arilo Claudio Dias Neto O que mudou da 1.x para a 2.0 Diagrama de Classes quase nada; Diagrama de Sequencia praticamente igual; Diagramas de Colaboração e de Estados só mudaram a nomenclatura; São os mais novos diagramas: o de Tempo e o de Estrutura Composta; Arilo Claudio Dias Neto Diagramas providos pela UML 2.0 São 13 diagramas, divididos em 3 grupos: 44 Diagramas Estruturais Classes Objeto Componentes Instalação Pacotes Estrutura Diagramas Comportamentais Casos de Uso Transição de Estados Atividade Diagramas de Interação Sequência Interatividade Colaboração ou Comunicação Tempo 05/02/2014 23 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 PROJETO E MODELAGEM DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 45 introdução à engenharia de software/sliders prova 2/IEC993-Aula26-manutencao.pdf 24/02/2014 1 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 MANUTENÇÃO DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 1 Arilo Claudio Dias Neto O que é a manutenção? O processo de modificar um sistema de software ou componente, depois da entrega, para corrigir falhas, melhorar desempenho ou outros atributos, ou adaptar a mudanças no ambiente. IEEE Std 620.12 1990 2 24/02/2014 2 Arilo Claudio Dias Neto Definição Manutenção de Software: “atividade durante a qual ocorrem modificações em um ou mais artefatos resultantes do desenvolvimento de um software, buscando mantê-lo disponível, corrigir suas falhas, melhorar seu desempenho e adequá-lo aos requisitos novos ou modificados.” (ANSI/IEEE, 1993) 3 Arilo Claudio Dias Neto Definição Manutenção de Software: “o custo associado à modificação de um sistema de software ou componente depois de entregue para corrigir falhas, melhorar o desempenho ou outros atributos, ou para adaptá-lo a um ambiente modificado.” (SEI, 2005) 4 24/02/2014 3 Arilo Claudio Dias Neto Motivações Modificação de software – inevitável ◦ Surgem novos requisitos ◦ O ambiente do negócio muda ◦ Erros devem ser reparados ◦ Novo equipamento deve ser incorporado ◦ O desempenho do software pode ser melhorado 5 Arilo Claudio Dias Neto Por que fazer bem feito? Por que é mais barato! ◦ Historicamente, 60% a 80% do esforço total ocorre na manutenção Por que é mais rápido! ◦ Não ter tempo para fazer bem feito agora significa ter tempo para refazer depois Por que é mais fácil! ◦ Desenvolvimento ocorre uma única vez ◦ Manutenção é para sempre 6 24/02/2014 4 Arilo Claudio Dias Neto Sistemas Legados Software antigos, e que são modificados para satisfazer mudanças de requisitos e novas plataformas. Características de sistemas legados: ◦ Normalmente de baixa qualidade ◦ Projetos não-extensíveis, dificultando evoluções ◦ Documentação pobre ou inexistente ◦ Casos de teste e resultados não arquivados ◦ Histórico de modificações mal geridos ◦ Porém, muito importantes para o negócio da empresa!!! 7 Arilo Claudio Dias Neto Processo de Software O Trabalho em ES pode ser dividido em 3 fases genéricas (Pressman, 2001): ◦ Definição: foco – O que? Quais são os requisitos funcionais e não-funcionais? Quais são as regras de negócio? Quais são os dados de entrada e saída? Atividades: Análise de Requisitos. ◦ Desenvolvimento: foco – Como? Como os dados devem ser estruturados? Como deve ser a arquitetura do sistema para atender aos atributos de qualidade estabelecidos? Como as funções devem ser realizadas na arquitetura? Atividades: Projeto (Projeto de Alto Nível e Projeto Detalhado ou de Baixo Nível), Codificação (ou Implementação) e Testes. ◦ Suporte: foco – Mudança. A fase de suporte reaplica as atividades definidas nas fases de Definição e Desenvolvimento no contexto de um software existente. Atividades:Manutenção (corretiva, adaptativa, evolutiva e preventiva). 8 24/02/2014 5 Arilo Claudio Dias Neto Quando inicia a manutenção? Leonardo Murta Introdução à ES 9 Desenvolvimento ManutençãoRelease Arilo Claudio Dias Neto Quando inicia a manutenção? 10 Desenvolvimento ManutençãoRelease Desenv. Manut. Release Desenv. Release Manut. Desenv. 24/02/2014 6 Arilo Claudio Dias Neto Quais são os tipos de manutenção? 11 Manutenção Correção Corretiva Emergencial Preventiva Evolução Adaptativa Perfectiva Arilo Claudio Dias Neto Quais são os tipos de manutenção? Manutenção corretiva ◦ Reativa ◦ Corrige problemas reportados ◦ Faz o software voltar a atender aos requisitos Manutenção emergencial ◦ Não programada ◦ Mantém temporariamente o sistema funcionando ◦ Necessita uma manutenção corretiva posterior Manutenção preventiva ◦ Pró-ativa ◦ Corrige problemas latentes 12 24/02/2014 7 Arilo Claudio Dias Neto Quais são os tipos de manutenção? Manutenção adaptativa ◦ Mantém o software usável após mudanças no ambiente Manutenção perfectiva ◦ Provê melhorias para o usuário ◦ Melhora atributos de qualidade do software 13 Arilo Claudio Dias Neto Quanto consome? 14 25% Adaptativa 50% Evolutiva 21% Corretiva/ Emergencial 4%Preventiva 24/02/2014 8 Arilo Claudio Dias Neto Características da Manutenção Atividades Gerais: ◦ Análise do Problema (categorização/priorização da manutenção); ◦ Avaliação do pedido de manutenção (análise do esforço, riscos, custos); Avaliação da documentação de projeto e Análise de impacto das mudanças (partes do software atingidas, efeitos colaterais); ◦ Implementação das mudanças (modelos e código); ◦ Revisão e Aceitação: Testes de Regressão e Inspeções; ◦ Migração. 15 Arilo Claudio Dias Neto Evolução do Software Software evolui com o tempo ◦ Independentemente do seu tamanho, complexidade ou domínio de aplicação Manutenções fazem parte da vida de um software Razões para evolução: ◦ Adaptação a um novo ambiente ◦ Cliente solicitando novas funcionalidades ◦ Reengenharia da aplicação para um contexto moderno 16 24/02/2014 9 Arilo Claudio Dias Neto Evolução do Software Lehman propôs “leis” que se aplicavam a software quando eles evoluiam: 1. Lei da modificação contínua (1974) 2. Lei da complexidade crescente (1974) 3. Lei da auto-regulação (1974) 4. Lei da conservação da estabilidade organizacional (1980) 5. Lei da conservação da familiaridade (1980) 6. Lei do crescimento contínuo (1980) 7. Lei da qualidade declinante (1996) 8. Lei de realimentação do sistema (1996) 17 Arilo Claudio Dias Neto Evolução do Software 18 24/02/2014 10 Arilo Claudio Dias Neto Evolução do Software 19 Arilo Claudio Dias Neto Evolução do Software 20 24/02/2014 11 Arilo Claudio Dias Neto Evolução do Software 21 Arilo Claudio Dias Neto Evolução do Software 22 24/02/2014 12 Arilo Claudio Dias Neto Evolução do Software 23 Arilo Claudio Dias Neto Evolução do Software 24 24/02/2014 13 Arilo Claudio Dias Neto Evolução do Software 25 Arilo Claudio Dias Neto Ferramental de Apoio à Manutenção Ferramentas de bug tracking ◦ Software projetado para apoiar desenvolvedores a rastrear issues (defeitos e pedidos de mudança) em projetos. 26 24/02/2014 14 Arilo Claudio Dias Neto Processo de Manutenção “Conjunto de etapas bem definidas, que direcionam as atividades de manutenção de software, com o objetivo primordial de satisfazer às necessidades dos usuários de maneira planejada e controlada”. (Pigosky, 1996) 27 Arilo Claudio Dias Neto Processo de Manutenção Objetivo: ◦ Modificar um produto de software existente, preservando a sua integridade (norma NBR ISO 12207). Início: ◦ quando uma necessidade de modificação é identificada ou seja, quando se necessita corrigir problemas, realizar adaptações ou melhorias. Término: ◦ No momento da descontinuação do software, ou seja, quando não se vai mais utilizá-lo. 28 24/02/2014 15 Arilo Claudio Dias Neto Processo de Manutenção 29 Solicitação de Modificação Análise da Requisição de Modificação Implementação da Modificação Aceitação/Revisão da Modificação Planejamento Migração Descontinuidade Arilo Claudio Dias Neto Processo de Manutenção Planejamento: ◦ Nesta etapa, são estabelecidos planos e procedimentos para registrar e controlar a atividade de manutenção e os pedidos feitos pelos clientes. Solicitação de Modificação: ◦ Este evento ocorre quando alguma solicitação de modificação é feita, ou pelos clientes, ou pelos próprios mantenedores. Análise da Requisição de Modificação: ◦ Nesta etapa, é feita uma verificação minuciosa da solicitação por parte do mantenedor, para que este possa oferecer opções de solução para o problema identificado. 30 24/02/2014 16 Arilo Claudio Dias Neto Processo de Manutenção Implementação da Modificação: ◦ nesta etapa, são realizadas as tarefas propriamente ditas de alteração do produto de software, incluindo código, documentação etc. Nela, deve-se garantir a perfeita execução para se chegar à solução proposta. Aceitação/Revisão da Modificação: ◦ Nesta etapa, são feitas as revisões e testes a fim de garantir a integridade do produto, bem como a homologação e aprovação junto ao solicitante para que o produto possa ser liberado. 31 Arilo Claudio Dias Neto Processo de Manutenção Migração: ◦ Nesta etapa, o produto gerado é colocado no ambiente de produção e uma avaliação deve ser conduzida para confirmar a execução perfeita da alteração. Descontinuação do Software: ◦ nesta etapa, o software chega ao seu último estágio no ciclo de vida, onde não haverá mais modificações no mesmo. 32 24/02/2014 17 Arilo Claudio Dias Neto Manutenibilidade Facilidade com que um software pode ser entendido, corrigido, adaptado e/ou aumentado. Representa um requisito não-funcional ou atributo de qualidade de um software (ISO/IEC 9126-1). Características relacionadas a manutenibilidade do software: Refere- se ao esforço necessário para fazer modificações específicas no software. São elas: ◦ Modificabilidade: Avalia o esforço necessário para a modificação e remoção de defeitos; ◦ Testabilidade: Avalia o esforço necessário para validar as modificações realizadas. 33 Arilo Claudio Dias Neto Manutenibilidade Fatores que influenciam: ◦ Arquitetura da aplicação: Camadas, MVC, Tubos e Filtros, Cliente-Servidor etc. ◦ Adoção de Princípios de Projeto: Modularidade (Coesão e Acoplamento), Ocultação de Informação, Encapsulamento, Separação de Objetivos, Generalização (Abstração). ◦ Utilização de Padrões de Projeto. ◦ Utilização de Padrões de Programação. ◦ Comentários em Programas. ◦ Documentação de Análise e Projeto atualizadas. 34 24/02/2014 18 Arilo Claudio Dias Neto Manutenibilidade Medida indireta de software. ◦ Medida através dos atributos da atividade de manutenção que podem ser medidos. Métricas: ◦ Tempo gasto para o reconhecimento do problema. ◦ Tempo gasto na análise do problema (análise da solução, análise de impacto) ◦ Tempo gasto na especificação das mudanças (documentos). ◦ Tempo de correção ou modificação (implementação). ◦ Tempo de testes. 35 Arilo Claudio Dias Neto Problemas na Manutenção Geralmente, a única fonte de informação disponível sobre o software é o código fonte. ◦ Código é complexo e de difícil leitura sem uma documentação de apoio. ◦ Documentação de análise (requisitos) e projeto desatualizada. ◦ Dificuldade em avaliar o impacto da manutenção pela falta de modelos do software. Dificuldade em se realizar Testes de Regressão quando não existe nenhum registro de testes. Os mantenedores, em geral, não são os mesmos profissionais que desenvolveram o software e os desenvolvedores originais nem sempre se encontram disponíveis. 36 24/02/2014 19 Arilo Claudio Dias Neto Problemas na Manutenção Baixa estima dos mantenedores: geralmente os profissionais acham que é mais “nobre” a tarefa de desenvolver novos sistemas do que a tarefa de manter sistemas existentes. A maioria do software não é projetada para sofrer mudanças. 37 Arilo Claudio Dias Neto Métodos para Apoio à Manutenção Engenharia Reversa. Reengenharia. Gerência de Configuração. Reutilização de Software. 38 24/02/2014 20 Arilo Claudio Dias Neto Engenharia Reversa Engenharia Reversa: ◦ Processo de análise dos componentes do sistema e dos seus relacionamentos, a fim de descrever este sistema em um nível de abstração mais alto do que o código fonte original (GANNOD, 1999). 39 Arilo Claudio Dias Neto Reengenharia Reengenharia: ◦ Recuperação de informações de projeto de um software existente, a fim de reconstituir o sistema de modo a melhorar a sua qualidade global. Envolve: Engenharia Reversa, Reestruturação e Engenharia Progressiva. 40 24/02/2014 21 Arilo Claudio Dias Neto Gerência de Configuração Gerência de Configuração: ◦ “Disciplina para identificar e documentar as características físicas e funcionais de um item de configuração, controlar as modificações sobre estas características, gravar e relatar o processamento da mudança e o status da sua implementação, e verificar a sua adequação aos requisitos especificados.” [IEEE] 41 Arilo Claudio Dias Neto Reutilização de Software Reutilização: ◦ Processo de Incorporar em um novo Produto: código, especificações de requisito e de projeto, planos de teste, qualquer produto gerado durante desenvolvimentos anteriores (Werner, 2002). 42 24/02/2014 22 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 MANUTENÇÃO DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 43 introdução à engenharia de software/sliders prova 2/IEC993-Aula23-testes.pdf 15/02/2014 1 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 TESTES DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 29 Arilo Claudio Dias Neto Estratégias para Re-Teste Podem ocorrer para qualquer estratégia de teste, em caso de mudanças no software no planejamento dos testes Dois tipos: ◦ Regressão ◦ “Fumaça” (smoke testing) 15/02/2014 2 Arilo Claudio Dias Neto Teste de Regressão Estratégia importante para redução de “efeitos colaterais” Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. ◦ Execute testes de regressão toda vez que uma modificação maior é realizada no software (incluindo a integração de novos módulos) ◦ Efetue a gerência de configuração Arilo Claudio Dias Neto Teste “Fumaça” Pode ser caracterizado como estratégia de integração incremental. O software é reconstruído (com novos componentes incorporados) e exercitado diariamente. 15/02/2014 3 Arilo Claudio Dias Neto Teste de Aceitação Foco nos requisitos – nas características imediatamente aparentes para o usuário final Testes realizados, geralmente, por um grupo restrito de usuários finais do sistema Teste conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação definidos pelo cliente ◦ Critérios para Teste de Aceitação A funcionalidade (caso de uso) ou características de desempenho estão de acordo com o especificado e são aceitas Uma variação da especificação é descoberta e uma lista de discrepâncias (deficiências) é criada Arilo Claudio Dias Neto Teste de Aceitação Teste Alfa e Beta ◦ Alfa: executado na instalação do desenvolvedor pelo cliente ◦ Beta: executado na instalação de um ou mais clientes pelo usuário final do software 15/02/2014 4 Arilo Claudio Dias Neto Teste de Instalação Consiste em instalar o sistema nos locais em que estão os usuários ◦ Dispensado no caso do teste de aceitação ter sido executado no ambiente do usuário Focam: ◦ A integridade do sistema instalado; e ◦ A verificação quanto a se alguma característica funcional ou não funcional foi afetada pelas condições do local de operação Arilo Claudio Dias NetoArilo Claudio Dias Neto MÓDULO II Técnicas de Teste de Software 15/02/2014 5 Arilo Claudio Dias Neto Módulo II: Roteiro Técnicas de Teste: ◦ Funcional x Estrutural x Baseada em Erros Particionamento Por Equivalência Análise do Valor Limite Grafo de Causa-Efeito Exercícios Arilo Claudio Dias Neto Técnicas para Teste de Software Técnicas: ◦ Funcional (ou caixa preta/caixa fechada) ◦ Estrutural (ou caixa branca/caixa aberta) ◦ Baseada em erros A questão não está em qual delas utilizar e sim como combiná-las de forma a maximizar os benefícios das atividades de teste! 15/02/2014 6 Arilo Claudio Dias Neto Técnica Estrutural É baseada no conhecimento da estrutura interna da implementação Teste dos detalhes procedimentais A maioria dos critérios dessa técnica utiliza uma representação de programa conhecida como grafo de programa ou grafo de fluxo de controle Dependente de apoio ferramental Detalhes: DISCIPLINA IEC484 – TESTE DE SOFTWARE (7º PERÍODO) Arilo Claudio Dias Neto Técnica Estrutural (Grafo de Programa) Detalhes considerados: ◦ nó ◦ arco ◦ caminho: simples completo livre de laço ◦ fluxo de controle 15/02/2014 7 Arilo Claudio Dias Neto Técnica Estrutural (Grafo de Programa) Nós: ◦ blocos “indivisíveis” não existe desvio para o meio do bloco uma vez que o primeiro comando do bloco é executado, os demais comandos são executados seqüencialmente Arestas ou Arcos: ◦ representam o fluxo de controle entre os nós Arilo Claudio Dias NetoArilo Claudio Dias Neto Técnica Estrutural Critérios de Fluxo de Controle ◦ Todos-Nós: 1,2,3,4,5,6,7,4,8,9,11 1,3,4,8,9,10,11 ◦ Todos-Arcos: <1,2>,<2,3>,<3,4>,<4,5>,<5,6>,<6,7> ,<7,4>,<4,8>,<8,9>,<9,11> <1,3>,<3,4>,<4,5>,<5,7>,<7,4>,<4,8> ,<8,10>,<10,11> ◦ Todos-Caminhos ?????? 15/02/2014 8 Arilo Claudio Dias Neto Técnica Funcional Baseia-se na especificação do software para derivar os requisitos de teste Aborda o software de um ponto de vista macroscópico Envolve dois passos principais: ◦ identificar as funções que o software deve realizar (especificação dos requisitos, casos de uso) ◦ criar casos de teste capazes de verificar se essas funções estão sendo executadas corretamente Arilo Claudio Dias Neto Técnica Funcional 15/02/2014 9 Arilo Claudio Dias Neto Técnica Funcional Problema: ◦ Dificuldade em quantificar a atividade de teste - não se pode garantir que partes essenciais ou críticas do software foram executadas Critérios da Técnica Funcional: ◦ Particionamento em Classes de Equivalência ◦ Análise do Valor Limite ◦ Grafo de Causa-Efeito Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Critério utilizado para reduzir o número de caso de teste procurando garantir uma boa cobertura do código do produto em teste. Empregado intuitivamente pelos programadores mesmo sem conhecer o critério. Exemplo: ◦ sistema de recursos humanos – empregar pessoas com base na idade Como deveriam ser derivados casos de teste para o exemplo acima? 15/02/2014 10 Arilo Claudio Dias Neto Particionamento em Classes de Equivalência O módulo deveria ser testado considerando as idades: 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 90, 91, 92, 93, 94, 95, 96, 97, 98, 99? Considere que o módulo que resolve o problema anterior tenha sido implementado como ilustrado abaixo: Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Caso o programa tenha sido implementado desta forma, a única forma de testá-lo adequadamente seria executar o módulo com valores de idade de 0..99. Caso haja tempo suficiente, esse é o melhor teste a ser realizado. O problema é que da forma como o código acima foi implementado, a execução de um dado caso de teste não diz nada a respeito da execução do próximo. 15/02/2014 11 Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Agora considere essa outra implementação (bem melhor) do mesmo problema: Dada essa implementação, fica claro que não é necessário testar para todos os valores 0, 1, 2, · · · , 14, 15 e 16, por exemplo. Apenas um valor precisa ser testado. Qual seria esse valor? Arilo Claudio Dias Neto Particionamento em Classes de Equivalência RESPOSTA: ◦ Qualquer valor dentro do intervalo tem a mesma importância, ou seja, qualquer valor escolhido é adequado. ◦ O mesmo se aplica para os demais intervalos de dados ◦ Tais intervalos determinam o que é chamado de classe de equivalência ◦ Qualquer valor no intervalo de uma classe é considerado equivalente em termos de teste. Assim sendo: Se um caso de teste de uma classe de equivalência revela uma falha qualquer caso de teste da mesma classe também revelaria e vice-versa. 15/02/2014 12 Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Tal critério de teste assume que na especificação de requisitos existe uma indicação precisa das classes de equivalência. Observe que com esse critério de teste o número de casos de teste é reduzido de 100 para 4 (um para cada classe de equivalência). Além disso, também é assumido que o programador não implementou algo estranho como ilustrado abaixo: Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Divide o domínio de entrada do programa em classes de dados (classes de equivalências) Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada ◦ Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica. Os dados de teste são derivados a partir das classes de equivalência ◦ Eventualmente, pode se considerar o domínio de saída como referência 15/02/2014 13 Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Arilo Claudio Dias Neto Particionamento em Classes de Equivalência 2 Passos 1. Identificar classes de equivalência (é um processo heurístico) Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, 1 classe de equivalência válida e 2 inválidas são definidas; Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas 2. Definir os casos de teste enumeram-se as classes de equivalência casos de teste para as classes válidas casos de teste para as classes inválidas 15/02/2014 14 Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Arilo Claudio Dias Neto Particionamento em Classes de Equivalência 15/02/2014 15 Arilo Claudio Dias Neto Particionamento em Classes de Equivalência Em geral, não há tempo para a criação de um caso de teste para cada classe válida. Solução: ◦ Criar o menor número possível de casos de teste que cubram todas as classes válidas. ◦ Criar um caso de teste para cada classe inválida Arilo Claudio Dias Neto Exemplo 1 Função: ◦ Considere uma função que aceita como entradas de 4 a 6 valores inteiros de 2 dígitos maiores do que 10. Identificação das variáveis de entrada e das condições que estas devem satisfazer: ◦ nro_entradas ∈ [ 4, 6 ] ◦ valor ∈ [ 10, 99 ] 58 15/02/2014 16 Arilo Claudio Dias Neto Exemplo 1 Determinação das classes de equivalência: Número de entradas (nro_entradas) Condições de Entrada Classes Válidas Classes Inválidas 4 nro_entradas 6 (C1) Valor informado (valor) nro_entradas < 4 (C3) nro_entradas > 6 (C4) 10 valor 99 (C2) valor < 10 (C5) valor > 99 (C6) Arilo Claudio Dias Neto Exemplo 1 Casos de teste: ◦ Selecionar casos de testes cobrindo as classes válidas das diferentes variáveis 60 nro-entradas C1 C2 C3 C4 C5 C6 4..6 < 4 > 6 valor 10..99 < 10 > 99 15/02/2014 17 Arilo Claudio Dias Neto Exemplo 1 Casos de teste: ◦ Dica: “Congela” uma variável como válida e alterna as outras 61 nro-entradas C1 C2 C3 C4 C5 C6 4..6 < 4 > 6 valor 10..99 < 10 > 99 Arilo Claudio Dias Neto Exemplo 1 Casos de teste: ◦ Selecionar casos de testes cobrindo as classes válidas das diferentes variáveis 62 nro-entradas C1 C2 C3 C4 C5 C6 4..6 X < 4 > 6 valor 10..99 X < 10 > 99 15/02/2014 18 Arilo Claudio Dias Neto Exemplo 1 Casos de teste: ◦ Para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez 63 nro-entradas C1 C2 C3 C4 C5 C6 4..6 X < 4 X > 6 valor 10..99 X X < 10 > 99 Arilo Claudio Dias Neto Exemplo 1 Casos de teste: ◦ Para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 de cada vez 64 nro-entradas C1 C2 C3 C4 C5 C6 4..6 X X X < 4 X > 6 X valor 10..99 X X X < 10 X > 99 X 15/02/2014 19 Arilo Claudio Dias Neto Exemplo 2 Verificação de uma senha válida: ◦ Considere o teste do procedimento: Valida_Nova_Senha que recebe como entrada uma senha e valida-a conforme as seguintes regras: uma senha deve ter de 6 a 10 caracteres o primeiro caractere dever ser alfabético, numérico ou um “?” os outros caracteres podem ser quaisquer, desde que não sejam caracteres de controle a senha não pode existir em um dicionário Exemplo: acdn25 (válido); senha*1 (inválido); 1pass (inválido); a12345678910 (inválido) Arilo Claudio Dias Neto Exemplo 2 Classes de equivalência 15/02/2014 20 Arilo Claudio Dias Neto Exemplo 2 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 10 11 12 C la ss e s d e e q u iv al ê n ci a Casos de Teste Casos de Teste 1. 2. 3. 4. 5. 6. 7. 8. 9. Arilo Claudio Dias Neto Exemplo 2 1 2 3 4 5 6 7 8 9 1 X X X X X X X X 2 X X 3 X X 4 X X 5 X X X X X X X X 6 X X X X X X X X 7 X 8 X 9 X 10 X 11 X 12 X C la ss e s d e e q u iv al ê n ci a Casos de Teste Casos de Teste 1. senhaok 2. 1senha 3. ?senha 4. senha 5. senhacorreta 6. [esc]senha 7. *senha 8. senha[esc]ok 9. invalida [no dicionário] 15/02/2014 21 Arilo Claudio Dias Neto Classe de Equivalência: Exercício Verificação de um número primo: O programa deve determinar se um número natural é primo ou não. Um número primo é divisível por ele e por 1. Exemplo: 5 (primo); 2 (primo); 4 (não primo); 15 (não primo) Classes de Equivalência Não Primo Primo Casos deTeste Resultado Esperados 4 Não Primo 7 Primo Caso 0 Caso 1 0 Não Primo 1 Não Primo 0 nem 1 são números primos!!! Arilo Claudio Dias Neto Classe de Equivalência: Exercício Problema do dia, mês e ano: ◦ Dado o seguinte problema: "um programa recebe 3 valores pela linha de comando: dia, mês, ano e imprime a data do dia seguinte. ◦ O dia, o mês e o ano tem valores numéricos inteiros: 1<= dia <= 31, 1<= mês <= 12 e 1812 <= ano <= 2012“. ◦ Determine as classes de equivalência e os casos de teste para esse programa. introdução à engenharia de software/sliders prova 2/IEC993-Aula14-qualidade.pdf 07/01/2014 1 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 QUALIDADE DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 1 Arilo Claudio Dias Neto Engenharia de Software Conjunto de princípios, métodos e técnicas que tratam o software como produto de engenharia que requer planejamento, projeto, implementação e manutenção. Objetivo: ◦ Produzir software de alta qualidade! Mas... ◦ O que é qualidade de software? 07/01/2014 2 Arilo Claudio Dias Neto Qualidade de Software Pensamento de alguns desenvolvedores: ◦ Qualidade de software é algo com que você começa a se preocupar depois que o código foi gerado. ◦ Resultado esperado do projeto seguido por estes profissionais... Arilo Claudio Dias Neto Qualidade de Software Gestão da Qualidade (ou apenas Garantia da Qualidade de Software) é uma atividade guarda-chuva que é aplicada ao longo de todo o processo de desenvolvimento. Análise Projeto Codificação Testes Qualidade de Software 07/01/2014 3 Arilo Claudio Dias Neto Qualidade de Software Qualidade de Software abrange: 1. Um processo de garantia de qualidade de software. 2. Tarefas específicas de garantia e controle de qualidade (incluindo revisões técnicas e estratégias de teste). 3. Prática de Engenharia de Software efetiva (métodos e ferramentas adequados). 4. Controle dos produtos de trabalho de software e suas modificações. 5. Procedimento para garantir satisfação a normas estabelecidas. 6. Mecanismos de medição e análise do desenvolvimento. Arilo Claudio Dias Neto Qualidade de Software Quem faz? ◦ Todos os envolvidos no processo de engenharia de um software são responsáveis pela qualidade. Por que é importante? ◦ Temos 2 opções: (1) fazer direito , (2) fazer novamente. ◦ Se uma equipe enfatiza qualidade em todas as atividades, reduz a quantidade de retrabalho. menores custos e melhor prazo para entrega do produto! 07/01/2014 4 Arilo Claudio Dias Neto Qualidade de Software O que seria? ◦ Estar em conformidade com especificações e padrões de desenvolvimento documentados. ◦ Prover o atendimento das necessidades dos usuários. Como fazer? ◦ Conjunto de atividades técnicas aplicadas durante todo o processo de desenvolvimento. Qual o objetivo? ◦ Garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam níveis de qualidade especificados. 7 Arilo Claudio Dias Neto Verificação & Validação de Software (V&V) Definições (IEEE): ◦ Verificação: Avalia um sistema para determinar se os produtos de uma dada atividade de desenvolvimento satisfazem as condições impostas no início desta atividade. ◦ Validação: Avalia um sistema para determinar se ele satisfaz os requisitos para ele especificados. 8 07/01/2014 5 Arilo Claudio Dias Neto Verificação & Validação de Software (V&V) Esclarecendo: ◦ Verificação: “Estamos construindo certo o produto?”; Os artefatos construídos devem estar de acordo com a especificação do software. ◦ Validação: “Estamos construindo o produto certo?”; O software deve atender às necessidades dos usuários. 9 Arilo Claudio Dias Neto Métodos de V&V Principais Métodos para Verificação e Validação: ◦ Verificação: Estática: Revisões de Software. Dinâmica: Testes de Software. ◦ Validação: Revisões e Testes de Software. 10 07/01/2014 6 Arilo Claudio Dias Neto Métodos de V&V Por que utilizar métodos de Verificação e Validação? ◦ Indústria de Software: Seu uso tem mostrado resultados positivos considerando tanto produtividade quanto qualidade. ◦ Pesquisa científica: Estudos experimentais evidenciam benefícios da utilização destes métodos no desenvolvimento de software. 11 Arilo Claudio Dias Neto Curiosidade sobre V&V Inspeções aumentam significativamente a produtividade, qualidade e estabilidade dos projetos (Fagan, 1976). Inspeções e Testes encontram diferentes tipos de defeitos (Boehm e Basili, 2001). Qualidade melhora a produtividade (Travassos e Kalinowski, 2008). ◦ Se sei encontrar defeitos, evito sua inserção... Prevenção de defeitos é melhor do que remoção de defeitos (Mays, 1990). 12 07/01/2014 7 Arilo Claudio Dias Neto Curiosidade sobre V&V Corrigir um defeito após a entrega do produto é frequentemente 100 vezes mais caro do que corrigi-lo durante as atividades de requisitos e projeto do sistema (Boehm e Basili, 2001). 13 Arilo Claudio Dias Neto Curiosidade sobre V&V Em projetos recentes de software, teríamos um esforço de retrabalho entre 35% e 50% do esforço total (Boehm e Basili, 2001). 14 10% 20% 15% 20% 35% Análise Projeto Codificação Testes Retrabalho 07/01/2014 8 Arilo Claudio Dias Neto Curiosidade sobre V&V Em projetos recentes de software, teríamos um esforço de retrabalho entre 35% e 50% do esforço total (Boehm e Basili, 2001). Projeto de 10 meses 3 meses e meio até 5 meses do projeto foi usado para RETRABALHO!!! 15 Arilo Claudio Dias Neto Curiosidade sobre V&V Esta é (talvez) a área da Engenharia de Software que possui mais evidências científicas sobre seus benefícios e impacto positivo em um projeto de software. Exemplo de evidências: Inspeções de software (qualquer artefato) revelam cerca de 60% dos defeitos Testes funcionais de software revelam cerca de 55% das falhas Combinar Inspeções + Teste é uma estratégia positiva Cada método identifica um tipo diferente de defeito/falha 16 07/01/2014 9 Arilo Claudio Dias Neto Terminologia - Padrão IEEE 610.12-1990 Conceitos importantes da qualidade do software: 17 Engano [mistake] (causado pela equipe) Leva a um Defeito [fault] (inserido em algum artefato) Irá provoca r Falha [failure] (durante a execução do software) Deixará o sistema em estado de Erro [error] (inserido em algum artefato) Arilo Claudio Dias Neto Terminologia - Padrão IEEE 610.12-1990 Engano (mistake): ◦ Ação humana que produz um resultado incorreto. ◦ Exemplo 1: o analista esqueceu de especificar uma regra de negócio dizendo que a quantidade de um produto deve ser verificada antes da venda. ◦ Exemplo 2: o desenvolvedor interpretou um requisito de forma incorreta e entendeu que valores maiores que 10 eram válidos (o correto é menor que 10). 18 07/01/2014 10 Arilo Claudio Dias Neto Terminologia - Padrão IEEE 610.12-1990 Defeito (fault): ◦ Deficiência mecânica ou algorítmica que se ativada pode levar a uma falha. Passo, processo ou definição de dados incorretos ◦ Exemplo 1: não existe regra de negócio informando que apenas produtos em estoque podem ser vendidos. ◦ Exemplo 2: um IF no código está incorreto com X > 10 em vez de X < 10. 19 Arilo Claudio Dias Neto Terminologia - Padrão IEEE 610.12-1990 Falha (failure): ◦ Evento notável onde o sistema viola suas especificações. Produção de uma saída incorreta com relação à especificação. ◦ Exemplo 1: o sistema aceita uma venda de um produto que não está em estoque ◦ Exemplo 2: o sistema permitiu que operações com valores maiores que 10 fossem aceitas 20 07/01/2014 11 Arilo Claudio Dias Neto Terminologia - Padrão IEEE 610.12-1990 Erro (error): ◦ Diferença entre o valor obtido e o valor esperado. Qualquer estado intermediário incorreto ou resultado inesperado. ◦ Exemplo 1: o sistema possui uma venda que não pode ser atendida ◦ Exemplo 2: o sistema possui uma operação inválida aceita como válida 21 Arilo Claudio Dias Neto Terminologia adotada Defeito: não faremos distinção entre os termos defeito, engano e erro. Todos serão tratados como defeito, que estará associado à causa de um comportamento incorreto. Falha: usaremos este termo para designar um comportamento incorreto, ou seja, a consequência. 22 07/01/2014 12 Arilo Claudio Dias Neto Defeitos de Software A maior parte é de origem humana. São gerados na comunicação e na transformação de informações. Permanecem presentes nos diversos produtos de software produzidos e liberados. A maioria encontra-se em partes do produto de software raramente utilizadas e/ou executadas. 23 Arilo Claudio Dias Neto Defeitos de Software Principal causa: ◦ tradução incorreta de informações. Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente. ◦ Solução: Introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento. 24 07/01/2014 13 Arilo Claudio Dias Neto Monitorando Introdução & Detecção 25 0 50 100 150 200 250 300 Análise de Requisitos Projeto Codificação Integração Testes de Aceitação Em produção Estimado Introdução Detecção Real Introdução Detecção Arilo Claudio Dias Neto Defeitos de Software Taxonomia definida por Shull (1998) a partir do padrão IEEE (IEEE 830, 1998) para documentos de requisitos: 26 Tipo de Defeito Definição Omissão Informação necessária não incluída Ambiguidade Informação passível de ter múltiplas interpretações. Inconsistência Informações conflitantes Fato Incorreto Informação que não é verdadeira para as condições especificadas. Informação Estranha Informação desnecessária 07/01/2014 14 Arilo Claudio Dias Neto Defeitos de Software Taxonomia aplicável também a outros artefatos. 27 Arilo Claudio Dias Neto Defeitos de Software Omissão ◦ (1) Algum requisito importante relacionado à funcionalidade, ao desempenho, às restrições de projeto, ao atributo, ou à interface externa não foi incluído; ◦ (2) não está definida a resposta do software para todas as possíveis situações de entrada de dados; ◦ (3) faltam seções na especificação de requisitos; ◦ (4) faltam referências de figuras, tabelas, e diagramas; ◦ (5) falta definição de termos e unidades de medidas. 28 07/01/2014 15 Arilo Claudio Dias Neto Defeitos de Software Exemplo de Omissão: 29 Caso de Uso – CONSULTAR MENSAGEM FP. O sistema exibe todas as informações da mensagem com detalhes. Quais informações? Como saber isso? -Para poder realizar o cadastro, projetista/testadores/desenvolvedores precisam saber quais campos fazem parte do cenário. - Esta informação foi omitida da descrição da funcionalidade, logo temos um defeito. Arilo Claudio Dias Neto Defeitos de Software Ambiguidade ◦ Um requisito tem várias interpretações devido a diferentes termos utilizados para uma mesma característica ou vários significados de um termo para um contexto em particular. 30 07/01/2014 16 Arilo Claudio Dias Neto Defeitos de Software Exemplo de Ambigüidade: 31 Caso de Uso – CADASTRAR CLIENTE [RN1] O sistema verifica os dados informados. O mesmo contato não pode ser cadastrado mais de uma vez. A informação pode ser traduzida incorretamente. Como verificar se o contato está cadastrado (nome, email, ambos)? Arilo Claudio Dias Neto Defeitos de Software Inconsistência ◦ Dois ou mais requisitos apresentam informações conflitantes. 32 07/01/2014 17 Arilo Claudio Dias Neto Defeitos de Software Exemplo de Inconsistência 33 Caso de Uso –ALERTAR MENSAGEM [RN1] O sistema avisa as mensagens a serem repassadas aos destinatários 1 hora antes da data prevista pelo cliente. [RN2] Serão exibidas apenas as mensagens cuja data e hora de envio seja menos que 1 hora antes da data atual do sistema. A informação foi descrita de forma inconsistente Como o conhecimento de domínio não nos permite saber qual a informação está correta, temos um defeito. Arilo Claudio Dias Neto Defeitos de Software Fato Incorreto ◦ Um requisito descreve um fato que não é verdadeiro, considerando as condições solicitadas para o sistema. 34 07/01/2014 18 Arilo Claudio Dias Neto Defeitos de Software Exemplo de Fato Incorreto: 35 A informação não foi traduzida corretamente. Em nossa entrevista, definimos mais formas de consulta, lembra? Mais escolhidas, preço, etc... Em seguida, escolho o opção e clico consultar? Não preencho nenhum dado de consulta? Caso de Uso – CONSULTAR MENSAGEM 1. O sistema exibe uma tela com opções de busca por título ou por categoria. 2. O usuário escolhe a opção desejada e clica em consultar. Arilo Claudio Dias Neto Defeitos de Software Informação Estranha ◦ As informações fornecidas no requisito não são necessárias ou mesmo usadas. 36 07/01/2014 19 Arilo Claudio Dias Neto Defeitos de Software Exemplo de Informação Estranha: 37 Uma informação estranha foi introduzida. Uma informação que, apesar de poder estar correta, pode causar problemas já que não faz parte do sistema. Como isto pode ser testado? Caso de Uso – CONSULTAR CLIENTE 1. O ator passa o mouse em cima do cliente e o sistema lista os dados do usuário 2. O ator confirma se os dados confere com os dados registrados em sua pasta Arilo Claudio Dias Neto Defeitos de Software Considerações sobre documentos de requisitos: ◦ Primeiro artefato tangível a ser produzido. ◦ Descreve todas as características e as funções que o software a ser desenvolvido deve possuir. ◦ Atua como um contrato entre o cliente e o desenvolvedor. ◦ Base para todas as etapas subsequentes do desenvolvimento. ◦ Normalmente escrito em linguagem natural. 38 07/01/2014 20 Arilo Claudio Dias Neto Ambiguidade em Linguagem Natural 39 “O vendedor disse ao cliente que seu preço estava incorreto” O meu preço estava incorreto!! O meu preço estava incorreto!! Vendedor Cliente Arilo Claudio Dias Neto Defeitos de Software Defeitos em Documentos de Requisitos: Distribuição varia de acordo com a realidade da organização. 40 Adaptado de (DAVIS,1990). Tipo Percentagem(%) Fato Incorreto 40 Omissão 31 Inconsistência 13 Ambiguidade 5 Localização Incorreta 2 07/01/2014 21 Arilo Claudio Dias Neto Defeitos de Software Tipos de Defeito 10% 17% 11% 35% 11% 16% Informações Inconsistentes Ambiguidades Fatos Incorretos Omissões Informações Estranhas Outros Defeitos 41 (Kalinowski et al., 2007). Arilo Claudio Dias Neto Defeitos de Software Consequências: ◦ Estimativas de esforço e prazo deixam de fazer sentido. ◦ Desperdício de recursos. ◦ Produto final não atende as necessidades do usuário; ◦ Corrigir defeitos após a entrega do produto pode ser até cem vezes mais caro que corrigi-los nas primeiras fases do desenvolvimento (em projetos menores, 5:1). ◦ Em projetos recentes de software, teríamos um esforço de retrabalho entre 40% e 50% do esforço total. 42 07/01/2014 22 IEC400 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/1 QUALIDADE DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 43 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 QUALIDADE DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 44 introdução à engenharia de software/sliders prova 2/IEC993-Aula16-revisao.pdf 11/01/2014 1 IEC993 – INTRODUÇÃO À ENGENHARIA DE SOFTWARE – 2013/2 REVISÕES DE SOFTWARE D.Sc. Arilo Claudio Dias Neto arilo@icomp.ufam.edu.br 1 Arilo Claudio Dias Neto Revisões de Software Definição: ◦ Processo ou atividade para leitura de um artefato de software visando assegurar que ele cumpre sua especificação e atende às necessidades de seus usuários. Objetivo: ◦ Realizar verificação e validação estática de artefatos de software. Pode ser aplicada a qualquer artefato produzido ao longo do processo de desenvolvimento de software. 2 11/01/2014 2 Arilo Claudio Dias Neto Revisões de Software Revisões por pares (peer-reviews) aumentam a probabilidade de defeitos serem encontrados. Comumente utilizam: ◦ Anonimidade; Relacionamentos pessoais não afetam a revisão. ◦ Independência dos revisores em relação ao artefato a ser revisado. Permite uma avaliação objetiva sem conflitos de interesse. 3 Arilo Claudio Dias Neto Revisões de Software Quando e em que tipos de artefato aplicar revisões de software? 4 Revisão 11/01/2014 3 Arilo Claudio Dias Neto Revisões de Software Utilização na Prática ◦ De acordo com resultados de um survey descritos em Ciolkowski et al. (2003): Muitas organizações realizam revisões de software. Realização pouco sistematizada e potencial raramente é explorado. ◦ No Brasil também tem sido muito utilizado (SBQS e MPS.BR) Tipos de Revisão de Software: ◦ Walkthroughs. ◦ Inspeções de Software. 5 Arilo Claudio Dias Neto Walkthroughs Reuniões informais para avaliação dos produtos Pouca ou nenhuma preparação requerida O desenvolvedor guia os presentes através do produto O objetivo é comunicar ou receber aprovação São úteis principalmente para requisitos e modelos. 11/01/2014 4 Arilo Claudio Dias Neto Walkthroughs Alternativa com um processo menos rigoroso do que o de inspeções de software. Papéis sugeridos: ◦ Líder: conduz a revisão do artefato indicando os eventuais defeitos identificados. ◦ Autor: profissional que criou o documento a ser revisado. ◦ Escrivão: toma nota dos eventuais defeitos sugeridos pelos revisores. ◦ Revisores: quem irá ler o documento com o propósito de identificar eventuais problemas que podem ser classificados futuramente como defeitos. 7 Arilo Claudio Dias Neto Walkthroughs Participantes – O autor seleciona os participantes, porém papeis específicos não são estabelecidos. Passos: ◦ O líder seleciona os revisores, obtém o aceite do convite e agenda a reunião. ◦ Normalmente, os participantes recebem o documento com certa antecedência para efetuar sua leitura. ◦ É marcada uma reunião onde todos os revisores devem participar para expor os problemas que identificaram. ◦ O líder apresenta o produto de trabalho aos inspetores durante a reunião. ◦ Durante a reunião devem interromper a apresentação caso encontrem possíveis não-conformidades ou tenham comentários/sugestões. ◦ Baseado nas informações apresentadas o autor faz as devidas correções ◦ defeitos. 11/01/2014 5 Arilo Claudio Dias Neto Walkthroughs Possuem custo aproximadamente igual ao de inspeções mas seus resultados são inferiores (SEI, 2005): ◦ Não providenciam resultados mensuráveis; ◦ Não fornecem base para a aplicação de controle estatístico de processos, necessário para evoluir na maturidade de processos de software. Podem ser utilizados para atividades de brainstorming, para explorar alternativas de projeto e resolução de problemas. ◦ Inspeções são mais focadas em encontrar defeitos. 9 Arilo Claudio Dias Neto Exercício Prático Revisar uma receita de bolo de chocolate usando walkthrough 10 11/01/2014 6 Arilo Claudio Dias Neto Fazendo um bolo de chocolate... Nossa meta é fazer um bolo de chocolate para o aniversário do Joãozinho, só que não sei como fazer... Que artefato me ajudaria a fazer um bolo? ◦ RECEITA DO BOLO Sem saber como fazer o bolo, como saber se a receita de fato me ajudará? ◦ REVISAR A RECEITA 11 Arilo Claudio Dias Neto Revisando a receita do bolo... Ingredientes ◦ 2 xícaras de chá de açúcar ◦ 1 1/2 xícara de chá de leite ◦ Ovos ◦ 100g de manteiga sem sal ◦ 1 xícara de chocolate em pó ◦ 1 xícara de suco de laranja ◦ 1/2 colher de sopa de fermento em pó 12 11/01/2014 7 Arilo Claudio Dias Neto Revisando a receita do bolo... Modo de Preparo 1. Misture a manteiga com açúcar e bata por 5 minutos 2. Separe claras e gemas dos ovos e bata
Compartilhar