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 so verificados procura de erros, anomalias ou informaes sobre os atributos
no funcionais do programa.
O processo de teste tem dois objetivos distintos:
1. Demonstrar ao desenvolvedor e ao cliente que o software atende a seus requisitos.
2. Descobrir situaes em que o software se comporta de maneira incorreta, indesejvel
ou de forma diferente das especificaes. Essas so consequncias de defeitos de
software. O teste de defeitos preocupa-se com a eliminao de comportamentos
indesejveis do sistema, tais como panes, interaes indesejveis com outros
sistemas, processamentos incorretos e corrupo de dados.
O primeiro objetivo leva a testes de validao, o segundo leva a testes de defeitos. O
teste parte de um amplo processo de verificao e validao (V&V), que no so a
mesma coisa embora sejam confundidos:
Validao: Estamos construindo o produto certo?
Verificao: Estamos construindo o produto da maneira certa?
Os processos de verificao e validao objetivam verificar se o software em
desenvolvimento satisfaz suas especificaes e oferece a funcionalidade esperada pelas
pessoas que esto pagando pelo software. Esses processos de verificao iniciam-se assim que
os requisitos esto disponveis e continuam em todas as fases do processo de
desenvolvimento.
O objetivo final dos processos de verificao e validao estabelecer a confiana de que
o software est pronto para seu propsito. Geralmente, sistemas de software tm de passar
por trs estgios de teste:
1. 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;
2. Teste de release, em que uma equipe de teste independente testa uma verso
completa do sistema antes que ele seja liberado para os usurios;
3. Teste de usurio, em que os usurios ou potenciais usurios de um sistema testam o
sistema em seu prprio ambiente.
Testes de desenvolvimento incluem todas as atividades de testes que so realizadas
pela equipe de desenvolvimento do sistema. Durante o desenvolvimento, o teste pode
ocorrer em trs nveis:
1. Teste unitrio, em que as unidades individuais de programa ou classes de objetos so
testadas individualmente. Testes unitrios devem centrar-se em testar a
funcionalidade dos projetos ou mtodos.
2. Teste de componente, em que vrias unidades individuais so integradas para criar
componentes compostos. Testes de componentes devem centra-se em testar as
interfaces dos componentes.
3. Teste de sistema, em que alguns ou todos os componentes de um sistema esto
integrados e o sistema testado como um todo. O teste de sistema deve centrar-se
em testar as interaes entre os componentes.
Testes de desenvolvimento so essencialmente um processo de testes de defeitos, em que
o objetivo do teste descobrir bugs no software.
Teste unitrio o processo de testar os componentes de programa. Funes individuais
ou mtodos so o tipo mais simples de componente. Seus testes devem ser chamados para
essas rotinas com parmetros diferentes de entrada.
O teste e custoso e demorado, por isso importante que voc escolha casos efetivos de
teste unitrio. A efetividade, nesse caso, significa duas coisas:
1. Os casos devem mostrar que, quando usado como esperado, o componente que
voc est testando faz o que ele proposto a fazer;
2. 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 usurios.
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
lanado como um produto ou entregue aos clientes. Portanto, o teste de release precisa
mostrar que o sistema oferece a funcionalidade, o desempenho e a confiana especificados e
que no falhar durante o uso normal. Deve levar em conta todos os requisitos de sistema, e
no apenas os requisitos de usurios finais do sistema.
Um dos princpios gerias das boas prticas de engenharia de requisitos que os
requisitos devem ser testveis, isto , o requisito deve ser escrito de modo que um teste possa
ser projetado para ele. Testes baseados em requisitos so mais uma validao 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, possvel 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 esto
interessados tanto em demonstrar que o sistema atende seus requisitos quanto em descobrir
problemas e defeitos do sistema.
Teste de usurio ou de cliente um estgio no processo de testes em que os usurios
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 usurios experimentam um produto de software novo para ver se gostam e verificar se
faz o que eles precisam. O teste de usurio essencial, mesmo em sistemas abrangentes ou
quando testes de release tenham sido realizados. A razo para isso que as influencias do
ambiente de trabalho do usurio tm um efeito importante sobre a confiabilidade, o
desempenho, a usabilidade e a robustez de um sistema.
Na prtica, existem trs tipos de testes de usurio:
1. Teste alfa, em que os usurios do software trabalham com a equipe de
desenvolvimento para testar o software no local do desenvolvedor;
2. Teste beta, em que um release do software disponibilizado aos usurios para que
possam experimentar e levantar os problemas que eles descobriram com os
desenvolvedores do sistema;
3. Teste de aceitao, em que os clientes testam um sistema para decidir se est ou no
pronto para ser aceito pelos desenvolvedores de sistemas e implantado no ambiente
do cliente.

Em testes alfa, usurios e desenvolvedores trabalham em conjunto para testar um sistema
em que est sendo desenvolvido. Isso significa que os usurios podem identificar os problemas
e as questes que no so 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 usurios para avaliao.
O teste de aceitao uma parte inerente ao desenvolvimento de sistemas customizados,
que ocorre aps o teste de release. Engloba o teste formal de um sistema pelo cliente para
decidir se ele deve ou no ser aceito. A aceitao designa que o pagamento pelo sistema deve
ser feito.
Pontos importantes:
Os testes s podem anunciar a presena de defeitos em um programa. No podem
demonstrar que no existem defeitos remanescentes;
Testes de desenvolvimento so de responsabilidade da equipe de desenvolvimento de
software, outra equipe deve ser responsvel por testar o sistema antes que ele seja
liberado para os clientes. No processo de testes de usurio, clientes ou usurios do
sistema fornecem dados de teste e verificam se os testes so bem-sucedidos;
Testes de desenvolvimento incluem testes unitrios, nos quais voc testa objetos e
mtodos especficos; e testes de sistema, nos quais voc testa sistemas parciais ou
completos.
Ao testar o software, voc deve tentar quebrar o software usando sua experincia e
diretrizes para escolher os tipos de casos de teste que tm sido eficazes na descoberta
de defeitos em outros sistemas;
Sempre que possvel, voc deve escrever testes automatizados. Os testes so
incorporados em um programa que pode ser executado cada vez que uma alterao
feita para o sistema;
O desenvolvimento test-first uma abordagem de desenvolvimento na qual os testes
so escritos antes do cdigo que ser testado. Pequenas alteraes no cdigo so
feitas, e o cdigo refatorado at que todos os testes sejam executados com xito.
Testes de cenrio so teis quando replicam o uso prtico do sistema. Trata-se de
inventar um cenrio tpico de uso e usar isso para derivar casos de teste;
Teste de aceitao um processo de teste de usurio no qual o objetivo decidir se o
software bom o suficiente para ser implantado e usado em seu ambiente
operacional.
Capitulo 9 Evoluo de Software

Introduo:

Os objetivos deste captulo so explicar por que a evoluo uma parte importante da
engenharia de software e descrever os processos de evoluo de software.
O desenvolvimento de software no 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 inevitvel que ocorram mudanas , mudanas nos negcios e nas
expectativas dos usurios, que geram novos requisitos para o software. Partes do software
podem precisar ser modificadas para corrigir erros encontrados na operao, para que o
software se adapte as alteraes de sua plataforma de hardware e software, bem como para
melhorar seu desempenho ou outras caractersticas no funcionais.
Uma evoluo de software pode ser desencadeada por necessidades empresariais em
constante mudana, por relatos de defeitos de software ou por alteraes de outros sistemas
em um ambiente de software. Por tanto, a evoluo de um sistema raramente pode ser
considerada de forma isolada. Alteraes no ambiente levam a mudanas nos sistemas que
podem, ento, provocar mais mudanas ambientais. Assim, voc deve pensar na engenharia
de software como um processo em espiral com requisitos, projeto, implementao e testes
que dura toda a vida til do sistema.
Durante a evoluo, o software usado com sucesso, e existe um fluxo constante de
propostas de alteraes de requisitos. No entanto, como o software modificado, sua
estrutura tende a degradar e as mudanas ficam mais e mais caras.
A evoluo dos processos de software pode variar dependendo do tipo de software
que esteja sendo mantido, dos processos de desenvolvimento usados em uma organizao e
das habilidades das pessoas envolvidas. Em todas as organizaes, as propostas de mudana
no sistema so os acionadores para a evoluo. As propostas de mudana podem vir de
requisitos j existentes que no tenham sido implementados no release de sistema,
solicitaes de novos requisitos, relatrios de bugs do sistema, e novas ideias para melhoria do
software vindas da equipe de desenvolvimento. Os processos de identificao de mudanas e
de evoluo de sistema so cclicos e continuam durante toda a vida de um sistema.
Durante o processo de evoluo, os requisitos so analisados detalhadamente, e as
implicaes das mudanas surgem onde no eram aparentes no processo anterior de anlise.
s vezes, as solicitaes de mudana so relacionados a problemas do sistema que devem ser
resolvidos com urgncia. Essas mudanas urgentes podem surgir por trs motivos:
1. Se ocorrer um defeito grave no sistema;
2. Se as alteraes no ambiente operacional dos sistemas tiverem efeitos inesperados
que interrompam o funcionamento normal;
3. Se houver mudanas inesperadas no funcionamento do negocio que executa o
sistema.
Dinmica da evoluo de programas As leis de Lehman:

A primeira lei afirma que a manuteno de sistema um processo inevitvel. 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 mudana no ambiente, de modo que o processo de evoluo recomea;
A segunda lei afirma que, quando um sistema alterado, sua estrutura se degrada. A
nica maneira de evitar que isso acontea investir em manuteno preventiva.
A terceira lei , talvez, a mais interessante e a mais controversa das leis de Lehman. Ela
sugere que sistemas de grande porte tm uma dinmica prpria, estabelecida em um
estagio inicial do processo de desenvolvimento. Isso determina a tendncia geral do
processo de manuteno de sistema e limita o numero de possveis alteraes no
mesmo.
A quarta lei de Lehman sugere que a maioria dos grandes projetos de programao
trabalha em um estado saturado. Ou seja, uma mudana de recurso ou de pessoal
tem efeitos imperceptveis sobre a evoluo do sistema a longo prazo;
A quinta lei de Lehman est preocupada com o aumento das mudanas em cada
release de sistema. Adicionar nova funcionalidade a um sistema inevitavelmente
introduz novos defeitos. Quanto mais funcionalidade for adicionada em cada verso,
mais falhas haver.
A sexta e a stima lei so semelhantes e, essencialmente, dizem que os usurios de um
software estaro 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 no esteja claro como isso pode ser
aplicado em desenvolvimento prtico de software.
Manuteno de software:

A manuteno de software o processo geral de mudana em um sistema depois que
ele liberado para o uso. As alteraes feitas no software podem ser simples mudanas
para correo de erros de codificao, at mudanas mais extensas para correo de erros
de projeto, ou melhorias significativas para corrigir erros de especificao ou acomodar
novos requisitos. As mudanas so implementadas por meio da modificao de
componentes do sistema existente e, quando necessrio, por meio da adio de novos
componentes:
Existem trs tipos diferentes de manuteno de software:
1. Correo de defeitos;
2. Adaptao ambiental;
3. Adio de funcionalidade.
Na pratica, no existe uma distino clara entre esses tipos de manuteno. Ao adaptar o
sistema a um novo ambiente, voc pode adicionar funcionalidade para tirar proveito de novas
caractersticas do ambiente. Os defeitos de software so frequentemente expostos porque os
usurios 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 manuteno de software ocupa uma proporo
maior dos oramentos de TI que o desenvolvimento. Elas tambm concordam que se gasta
mais do oramento de manuteno na implementao de novos requisitos do que na correo
de bugs.
Geralmente, vale a pena investir esforos no projeto e implementao de um sistema para
reduo de custos de mudanas futuras. Portanto, o trabalho feito durante o desenvolvimento
para tornar a compreenso e a mudana no software mais fceis provavelmente reduzir os
custos de evoluo.
Pontos importantes:

O desenvolvimento e a evoluo 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 manuteno de software geralmente
excedem os custos de desenvolvimento de software;
O processo de evoluo do software dirigido pelas solicitaes de mudana e inclui a
anlise do impacto da mudana, o planejamento de release e implementao da
mudana;
As leis de Lehman, como a noo de que a mudana continua, descrevem uma srie
de consideraes provenientes de estudos, de longo prazo, de evoluo de sistema;
Existem trs tipos de manuteno de software, ou seja, correo de bugs, modificao
do software para funcionar em um novo ambiente e implementao de requisitos
novos ou alterados.
A reengenharia de software preocupa-se com a reestruturao e redocumentao do
software para torna-lo mais fcil de se entender e mudar;
Refatorao e pequenas alteraes no programa que preservam sua funcionalidade,
podem ser pensadas como manuteno preventiva;
O valor de negcio de um sistema legado e a qualidade do software de aplicao e seu
ambiente devem ser avaliados para determinar se o sistema deve ser substitudo,
transformado ou mantido.