RESUMO EGENHARIA DE SOFTWARE II

Prévia do material em texto

RESUMO EGENHARIA DE SOFTWARE – Ian Somerville
Autor: Paulo Norberto
Capitulo 8 – Testes de Software
O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, os resultados do teste são verificados à procura de erros, anomalias ou informações sobre os atributos não funcionais do programa.
O processo de teste tem dois objetivos distintos:
Demonstrar ao desenvolvedor e ao cliente que o software atende a seus requisitos.
Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma diferente das especificações. Essas são consequências de defeitos de software. O teste de defeitos preocupa-se com a eliminação de comportamentos indesejáveis do sistema, tais como panes, interações indesejáveis com outros sistemas, processamentos incorretos e corrupção de dados.
O primeiro objetivo leva a testes de validação, o segundo leva a testes de defeitos. O teste é parte de um amplo processo de verificação e validação (V&V), que não são a mesma coisa embora sejam confundidos:
Validação: Estamos construindo o produto certo?
Verificação: Estamos construindo o produto da maneira certa?
Os processos de verificação e validação objetivam verificar se o software em desenvolvimento satisfaz suas especificações e oferece a funcionalidade esperada pelas pessoas que estão pagando pelo software. Esses processos de verificação iniciam-se assim que os requisitos estão disponíveis e continuam em todas as fases do processo de desenvolvimento.
O objetivo final dos processos de verificação e validação é estabelecer a confiança de que o software está pronto para seu propósito. Geralmente, sistemas de software têm de passar por três estágios de teste:
Teste em desenvolvimento, em que o sistema é testado durante o desenvolvimento para descobrir bugs e defeitos. Projetistas de sistemas e programadores podem estar envolvidos no processo de teste;
Teste de release, em que uma equipe de teste independente testa uma versão completa do sistema antes que ele seja liberado para os usuários;
Teste de usuário, em que os usuários ou potenciais usuários de um sistema testam o sistema em seu próprio ambiente.
Testes de desenvolvimento incluem todas as atividades de testes que são realizadas pela equipe de desenvolvimento do sistema. Durante o desenvolvimento, o teste pode ocorrer em três níveis:
Teste unitário, em que as unidades individuais de programa ou classes de objetos são testadas individualmente. Testes unitários devem centrar-se em testar a funcionalidade dos projetos ou métodos.
Teste de componente, em que várias unidades individuais são integradas para criar componentes compostos. Testes de componentes devem centra-se em testar as interfaces dos componentes.
Teste de sistema, em que alguns ou todos os componentes de um sistema estão integrados e o sistema é testado como um todo. O teste de sistema deve centrar-se em testar as interações entre os componentes.
Testes de desenvolvimento são essencialmente um processo de testes de defeitos, em que o objetivo do teste é descobrir bugs no software.
Teste unitário é o processo de testar os componentes de programa. Funções individuais ou métodos são o tipo mais simples de componente. Seus testes devem ser chamados para essas rotinas com parâmetros diferentes de entrada.
O teste e custoso e demorado, por isso é importante que você escolha casos efetivos de teste unitário. A efetividade, nesse caso, significa duas coisas:
Os casos devem mostrar que, quando usado como esperado, o componente que você está testando faz o que ele é proposto a fazer;
Se houver defeitos nos componentes, estes devem ser revelados por casos de teste.
Teste de release é o processo de testar um release particular de um sistema que se destina para uso fora da equipe de desenvolvimento. Geralmente, o release de sistema é para uso dos clientes e usuários.
O objetivo principal do processo de teste de release é convencer o fornecedor do sistema de que esse sistema é bom o suficiente para uso. Se assim for, o sistema poderá ser lançado como um produto ou entregue aos clientes. Portanto, o teste de release precisa mostrar que o sistema oferece a funcionalidade, o desempenho e a confiança especificados e que não falhará durante o uso normal. Deve levar em conta todos os requisitos de sistema, e não apenas os requisitos de usuários finais do sistema.
Um dos princípios gerias das boas práticas de engenharia de requisitos é que os requisitos devem ser testáveis, isto é, o requisito deve ser escrito de modo que um teste possa ser projetado para ele. Testes baseados em requisitos são mais uma validação do que um teste de defeitos – você está tentando demonstrar que o sistema implementou adequadamente seus requisitos.
Uma vez que o sistema tenha sido totalmente integrado, é possível testá-lo para propriedades emergentes, como desempenho e confiabilidade. Os testes de desempenho precisam ser projetados para assegurar que o sistema possa processar a carga a que se destina.
Tal como acontece com outros tipos de testes, testes de desempenho estão interessados tanto em demonstrar que o sistema atende seus requisitos quanto em descobrir problemas e defeitos do sistema.
Teste de usuário ou de cliente é um estágio no processo de testes em que os usuários ou clientes fornecem entradas e conselhos sobre o teste de sistema. Isso pode envolver o teste formal de um sistema que foi aprovado por um fornecedor externo ou processo informal em que os usuários experimentam um produto de software novo para ver se gostam e verificar se faz o que eles precisam. O teste de usuário é essencial, mesmo em sistemas abrangentes ou quando testes de release tenham sido realizados. A razão para isso é que as influencias do ambiente de trabalho do usuário têm um efeito importante sobre a confiabilidade, o desempenho, a usabilidade e a robustez de um sistema.
Na prática, existem três tipos de testes de usuário:
Teste alfa, em que os usuários do software trabalham com a equipe de desenvolvimento para testar o software no local do desenvolvedor;
Teste beta, em que um release do software é disponibilizado aos usuários para que possam experimentar e levantar os problemas que eles descobriram com os desenvolvedores do sistema;
Teste de aceitação, em que os clientes testam um sistema para decidir se está ou não pronto para ser aceito pelos desenvolvedores de sistemas e implantado no ambiente do cliente.
Em testes alfa, usuários e desenvolvedores trabalham em conjunto para testar um sistema em que está sendo desenvolvido. Isso significa que os usuários podem identificar os problemas e as questões que não são aparentes para a equipe de testes de desenvolvimento.
O teste beta ocorre quando um release antecipado, por vezes inacabado, de um sistema de software é disponibilizado aos clientes e usuários para avaliação.
O teste de aceitação é uma parte inerente ao desenvolvimento de sistemas customizados, que ocorre após o teste de release. Engloba o teste formal de um sistema pelo cliente para decidir se ele deve ou não ser aceito. A aceitação designa que o pagamento pelo sistema deve ser feito.
Pontos importantes:
Os testes só podem anunciar a presença de defeitos em um programa. Não podem demonstrar que não existem defeitos remanescentes;
Testes de desenvolvimento são de responsabilidade da equipe de desenvolvimento de software, outra equipe deve ser responsável por testar o sistema antes que ele seja liberado para os clientes. No processo de testes de usuário, clientes ou usuários do sistema fornecem dados de teste e verificam se os testes são bem-sucedidos;
Testes de desenvolvimento incluem testes unitários, nos quais você testa objetos e métodos específicos; e testes de sistema, nos quais você testa sistemas parciais ou completos.
Ao testar o software, você deve tentar ‘quebrar’ o software usando sua experiência e diretrizes para escolher os tipos de casos de teste que têm sido eficazes na descobertade defeitos em outros sistemas;
Sempre que é possível, você deve escrever testes automatizados. Os testes são incorporados em um programa que pode ser executado cada vez que uma alteração é feita para o sistema;
O desenvolvimento test-first é uma abordagem de desenvolvimento na qual os testes são escritos antes do código que será testado. Pequenas alterações no código são feitas, e o código é refatorado até que todos os testes sejam executados com êxito.
Testes de cenário são úteis quando replicam o uso prático do sistema. Trata-se de inventar um cenário típico de uso e usar isso para derivar casos de teste;
Teste de aceitação é um processo de teste de usuário no qual o objetivo é decidir se o software é bom o suficiente para ser implantado e usado em seu ambiente operacional.
Capitulo 9 – Evolução de Software
Introdução:
Os objetivos deste capítulo são explicar por que a evolução é uma parte importante da engenharia de software e descrever os processos de evolução de software.
	O desenvolvimento de software não é interrompido quando o sistema é entregue, mas continua por toda a vida útil do sistema. Depois que o sistema é implantado, para que ele se mantenha útil é inevitável que ocorram mudanças –, mudanças nos negócios e nas expectativas dos usuários, que geram novos requisitos para o software. Partes do software podem precisar ser modificadas para corrigir erros encontrados na operação, para que o software se adapte as alterações de sua plataforma de hardware e software, bem como para melhorar seu desempenho ou outras características não funcionais.
	Uma evolução de software pode ser desencadeada por necessidades empresariais em constante mudança, por relatos de defeitos de software ou por alterações de outros sistemas em um ambiente de software. Por tanto, a evolução de um sistema raramente pode ser considerada de forma isolada. Alterações no ambiente levam a mudanças nos sistemas que podem, então, provocar mais mudanças ambientais. Assim, você deve pensar na engenharia de software como um processo em espiral com requisitos, projeto, implementação e testes que dura toda a vida útil do sistema.
Durante a evolução, o software é usado com sucesso, e existe um fluxo constante de propostas de alterações de requisitos. No entanto, como o software é modificado, sua estrutura tende a degradar e as mudanças ficam mais e mais caras.
	A evolução dos processos de software pode variar dependendo do tipo de software que esteja sendo mantido, dos processos de desenvolvimento usados em uma organização e das habilidades das pessoas envolvidas. Em todas as organizações, as propostas de mudança no sistema são os acionadores para a evolução. As propostas de mudança podem vir de requisitos já existentes que não tenham sido implementados no release de sistema, solicitações de novos requisitos, relatórios de bugs do sistema, e novas ideias para melhoria do software vindas da equipe de desenvolvimento. Os processos de identificação de mudanças e de evolução de sistema são cíclicos e continuam durante toda a vida de um sistema.
	Durante o processo de evolução, os requisitos são analisados detalhadamente, e as implicações das mudanças surgem onde não eram aparentes no processo anterior de análise. Às vezes, as solicitações de mudança são relacionados a problemas do sistema que devem ser resolvidos com urgência. Essas mudanças urgentes podem surgir por três motivos:
Se ocorrer um defeito grave no sistema;
Se as alterações no ambiente operacional dos sistemas tiverem efeitos inesperados que interrompam o funcionamento normal;
Se houver mudanças inesperadas no funcionamento do negocio que executa o sistema.
Dinâmica da evolução de programas – As leis de Lehman:
A primeira lei afirma que a manutenção de sistema é um processo inevitável. Como o ambiente do sistema muda novos requisitos surgem, e os sistemas devem ser modificados. Quando o sistema modificado é reintroduzido no ambiente, este promove mais mudança no ambiente, de modo que o processo de evolução recomeça;
A segunda lei afirma que, quando um sistema é alterado, sua estrutura se degrada. A única maneira de evitar que isso aconteça é investir em manutenção preventiva.
A terceira lei é, talvez, a mais interessante e a mais controversa das leis de Lehman. Ela sugere que sistemas de grande porte têm uma dinâmica própria, estabelecida em um estagio inicial do processo de desenvolvimento. Isso determina a tendência geral do processo de manutenção de sistema e limita o numero de possíveis alterações no mesmo.
A quarta lei de Lehman sugere que a maioria dos grandes projetos de programação trabalha em um estado ‘saturado’. Ou seja, uma mudança de recurso ou de pessoal tem efeitos imperceptíveis sobre a evolução do sistema a longo prazo;
A quinta lei de Lehman está preocupada com o aumento das mudanças em cada release de sistema. Adicionar nova funcionalidade a um sistema inevitavelmente introduz novos defeitos. Quanto mais funcionalidade for adicionada em cada versão, mais falhas haverá.
A sexta e a sétima lei são semelhantes e, essencialmente, dizem que os usuários de um software estarão a cada dia mais descontentes com ele, a menos que ele seja mantido e que nova funcionalidade seja adicionada. A ultima lei reflete o mais recente trabalho com processos de feedback, embora ainda não esteja claro como isso pode ser aplicado em desenvolvimento prático de software.
Manutenção de software:
A manutenção de software é o processo geral de mudança em um sistema depois que ele é liberado para o uso. As alterações feitas no software podem ser simples mudanças para correção de erros de codificação, até mudanças mais extensas para correção de erros de projeto, ou melhorias significativas para corrigir erros de especificação ou acomodar novos requisitos. As mudanças são implementadas por meio da modificação de componentes do sistema existente e, quando necessário, por meio da adição de novos componentes:
Existem três tipos diferentes de manutenção de software:
Correção de defeitos;
Adaptação ambiental;
Adição de funcionalidade.
Na pratica, não existe uma distinção clara entre esses tipos de manutenção. Ao adaptar o sistema a um novo ambiente, você pode adicionar funcionalidade para tirar proveito de novas características do ambiente. Os defeitos de software são frequentemente expostos porque os usuários usam o sistema de formas inesperadas. Mudar o sistema para acomodar sua maneira de trabalhar é a melhor maneira de corrigir tais defeitos.
As pesquisas em geral concordam que a manutenção de software ocupa uma proporção maior dos orçamentos de TI que o desenvolvimento. Elas também concordam que se gasta mais do orçamento de manutenção na implementação de novos requisitos do que na correção de bugs.
Geralmente, vale a pena investir esforços no projeto e implementação de um sistema para redução de custos de mudanças futuras. Portanto, o trabalho feito durante o desenvolvimento para tornar a compreensão e a mudança no software mais fáceis provavelmente reduzirá os custos de evolução.
Pontos importantes:
O desenvolvimento e a evolução de software podem ser pensados como um processo integrado e interativo que pode ser representado por um modelo em espiral;
Para sistemas customizados, os custos de manutenção de software geralmente excedem os custos de desenvolvimento de software;
O processo de evolução do software é dirigido pelas solicitações de mudança e inclui a análise do impacto da mudança, o planejamento de release e implementação da mudança;
As leis de Lehman, como a noção de que a mudança é continua, descrevem uma série de considerações provenientes de estudos, de longo prazo, de evolução de sistema;
Existem três tipos de manutenção de software, ou seja, correção de bugs, modificação do software para funcionar em um novo ambiente e implementação de requisitos novos ou alterados.
A reengenharia de software preocupa-se com a reestruturação e redocumentação do software para torna-lo mais fácil de se entender e mudar;
Refatoração e pequenasalterações no programa que preservam sua funcionalidade, podem ser pensadas como manutenção preventiva;
O valor de negócio de um sistema legado e a qualidade do software de aplicação e seu ambiente devem ser avaliados para determinar se o sistema deve ser substituído, transformado ou mantido.