FACULDADES INTEGRADAS SANTA CRUZ
TESTES E DEPURAÇÃO DE SOFTWARE
BRUNO MENDES CAEL RAMOS EDSON DONIZETE PAULO ELIS ANGELA MEDEIROS JOSÉ CLEBSON DA SILVA
CURITIBA – 2012 0
FACULDADES INTEGRADAS SANTA CRUZ
TESTES E DEPURAÇÃO DE SOFTWARE
BRUNO MENDES CAEL RAMOS EDSON DONIZETE PAULO ELIS ANGELA MEDEIROS JOSÉ CLEBSON DA SILVA PROFESSOR RONALDO
CURITIBA 2012 1
Abstract In the last decades, technological scenarios have been part of our lives and more intensely in the global market, and software market is not an exception. This whole process has created new rules, policies and standardization in the field of Software Engineering. The aim of this article is to demonstrate analysis, taking into consideration the strategies and practices adopted, and the challenges identified in testing and debugging of software, including the quality, market and infrastructure. Keywords: software engineering, information technology, debugging, testing.
Resumo Nas últimas décadas, cenários tecnológicos tem feito parte de nossas vidas e mais intensamente no mercado global, e não é exceção o mercado do software. Todo este processo tem criado novas regras, políticas e padronizações na área de Engenharia de Software. O objetivo deste artigo é apresentar análise, levando-se em consideração as estratégias e práticas adotadas, e os desafios identificados nos testes e depurações de softwares, incluindo sua qualidade, mercado e infraestrutura. Palavra-chave:
engenharia
de
software;
tecnologia
da
informação;
depuração; testes.
2
Lista de Abreviaturas e Siglas TI – Tecnologia da Informação SQL – Structured Query Language IEEE – Institute of Electric and Electronic Engineers ISO – International Organization for Standardization IBM – International Business Machines LOG – Logarítimo IE – Internet Explorer HTTP – Hyper Text Transfer Protocol HTTPS – Hyper Text Transfer Protocol Security SOAP – Simple Object Access Protocol JDBC – Java Database Connectivity LDAP – Lightweight Directory Access Protocol JMS – Java Message Service POP3 – Post Office Protocol Recente IMAP – Internet Message Access Protocol GPL – General Public License / Licença Pública Geral SQS – Space of Quantum States IEC – International Electrotechnical Commission BSI – British Standards Institution WG26 – Cabo do Tipo 6, consiste em um cabo blindado formado por dois pares de fios trançados, mais flexível do que o cabo do Tipo 1(WG22) FIS – Financial Information System Std – Standard EUA – Estados Unidos da América NIST – Instituto Nacional de Medidas e Tecnologia CAD – Computer Aidded Design 3
CIA – Central Intelligence Agency SEC – Securities & Exchange Commission EDS – Electronic Differential System CSA – Canadian Space Agence FBI – Federal Bureau of Investigation EDA – European Defence Agency
4
Sumário Abstract ....................................................................................................................... 2 Resumo ....................................................................................................................... 2 Lista de Abreviaturas e Siglas ..................................................................................... 3 1. Introdução ............................................................................................................... 7 2. O mercado de software no Brasil ............................................................................ 7 2.1 As necessidades individuais .............................................................................. 8 2.2 Softwares abertos prejudicam a empresa. ......................................................... 9 3. Padronização ........................................................................................................ 10 4. Custos de Erros..................................................................................................... 10 5. Categoria de Software ........................................................................................... 10 5.1 Definição da categoria de produto: .................................................................. 11 5.2 Características ................................................................................................. 11 6. Qualidade do Software .......................................................................................... 12 7. Abordagem histórica para Desenvolvimento de Software ..................................... 14 8. Testes de Software ............................................................................................... 15 8.1 Infraestruturas destes testes ............................................................................ 16 8.2 Inadequações................................................................................................... 16 8.2.1IEEE 829 Documentação............................................................................ 16 8.3 Ferramentas para Testes de Software ............................................................. 17 8.4 Estágios de Testes de Software....................................................................... 18 8.5 Fases de Testes de Software........................................................................... 19 8.6 Tipos de Testes de Software............................................................................ 19 8.7 Padrões para Testes de Software .................................................................... 21 8.8 Custos .............................................................................................................. 22 8.9 Reduções de Custos ........................................................................................ 23 8.10 Valor dos Erros .............................................................................................. 23 8.10.1 Alguns dos mais famosos erros de softwares da história ........................ 24 9. Descrições e Modelo Conceitual ........................................................................... 30 10. Depuração .......................................................................................................... 30 10.1 A Arte da Depuração ...................................................................................... 31 10.2 O Processo de Depuração ............................................................................. 32 10.2.1 Por que é tão difícil depurar? ................................................................... 33 5
10.3 Abordagens utilizadas .................................................................................... 33 11. Exemplo Prático .................................................................................................. 34 11.1 Software Cadastral......................................................................................... 34 11.2 Desenvolvimento............................................................................................ 34 11.2.1 Linguagem e Banco de Dados ................................................................. 35 11.3 Testes de Software ........................................................................................ 37 11.3.1 BUG ......................................................................................................... 37 11.4 Depuração ..................................................................................................... 38 11.4.1 Criação da nova Tabela “TIPO” ............................................................... 38 11.5 Relatórios Finalizado e Corrigido ................................................................... 41 11.6 Resultado ....................................................................................................... 41 12. Conclusão ........................................................................................................... 42 Referências: .............................................................................................................. 43
6
1. Introdução
Nosso objetivo é identificar as questões que afetam a infraestrutura de teste de software e as deficiências que estas falhas possam causar. Os engenheiros de software recebem uma pressão enorme diante do mercado competitivo e de seus clientes que leigos que não entendem as diferenças de um software de qualidade, exigem preço, qualidade, tempo e satisfação num conjunto de impossibilidades. A padronização é crescente no mercado e a necessidade da tecnologia também. Vamos englobar neste artigo as ferramentas para tais desenvolvimentos, ferramentas de depuração e o mercado. Vamos comprovar o que uma infraestrutura inadequada para teste de software pode oferecer prejuízos a uma empresa e seu bem-estar econômico, além do desfavorecimento do profissional e a insatisfação do cliente final. Teste exige planejamento, execução e avaliação. Planejamento de teste requer selecionar o teste específico a ser executado e organização destes. A execução do teste é o processo de condução, veremos dentro deste artigo a instalação de pré-execução, execução e análise. Uma infraestrutura inadequada para teste de software vai levar a erros sendo identificados mais tarde no processo de desenvolvimento e mais recursos sendo necessárias para localizar e corrigir a fonte do erro, vamos mostrar impacto e custos no mau desenvolvimento destes softwares. O objetivo deste estudo é investigar o a importância dos testes e depurações de um software, incluindo sua qualidade, técnicas, custos, infraestrutura e padrões exigidos destes desenvolvedores.
2. O mercado de software no Brasil
Sabemos que para acessar alguma página online, provavelmente o fará através do seu computador pessoal executando qualquer versão do sistema operacional Windows e com a probabilidade de um navegador chrome ou Explorer, mas e se perguntássemos pelas aplicações que mais usam, poderíamos facilmente arriscar uma ferramenta como Microsoft Office. 7
Atualmente ferramentas como a Microsoft Office tornaram-se estandartes que demonstraram a hegemonia indiscutível do mercado globalizado de software pessoal, que é acentuado quando na maioria dos casos os seus produtos são apresentadas para os utilizadores como as únicas alternativas viáveis. Os efeitos da dependência generalizada a produtos específicos, bem como outras deficiências deste modelo de software será analisado aqui. Se a Microsoft perdesse sua posição dominante amanhã, não seria amanhã que outro software assumiria este buraco. Em contraste com modelo de software proprietário surge movimento do software livre, baseada na liberdade e cooperação entre os programadores e outros usuários de software, revolucionando o uso e desenvolvimento de programas de computador. Por razões um estratégico, econômico ou filosófico número crescente de governo, empresas e os consumidores optam por se deslocar para esta nova opção.
2.1 As necessidades individuais
As pessoas têm muitas necessidades, mas são diferentes dependendo de onde vivem, estatuto, dinheiro que têm, etc. As necessidades são geralmente ilimitadas, mas os recursos são limitados e escassos. Assim bens valem a pena e quem quer que eles tenham de pagar. E não há a necessidade de outras pessoas fornecerem bens que a sociedade. Este é o ponto de partida para a empresa como uma unidade econômica de produção, mas precisa de alguns grupos sociais (famílias) que têm a função de produção e consumo, em particular. Produção: qualquer processo que se destina a criar ou disponibilizar para os bens públicos e serviços necessários para satisfazer as suas necessidades. Empresas: um conjunto de elementos organizados e coordenados pela administração, visando a obtenção de um conjunto de metas, sempre trabalhando em condições seguras.
8
2.2 Softwares abertos prejudicam a empresa. Tudo que é grátis (free) causa impacto na sociedade. Como vimos anteriormente, até governos usam este meio. Open source é popular, seu código fonte está disponível ao público em geral, potencialmente importante neste momento de necessidade. Assim podem pensar os leigos e inexperientes em matéria de estratégia financeira e empresarial, um estagiário de TI pode impressionar seu chefe com esta ideia genial, mas como tudo que é fácil demais sempre tem um porém, neste caso não fugimos a esta regra. Open source tem complexas restrições legais que podem criar problemas de direitos autorais e patentes de conformidade e os desafios de transações corporativas para empresas que dependem fortemente de software personalizado ou que distribuem o software para parceiros ou clientes. Existem cerca de 70 licenças de código aberto, estas licenças geralmente exigem que o reconhecimento da autoria do software seja incluído, de alguma maneira, como em comentários de código fonte e arquivos de ajuda e/ou se a empresa que utiliza código aberto quer modificar ou distribuir este open source, deverá assegurar o cumprimento dos requisitos de licenciamento aplicáveis. “The study, carried out by Fortify Software with help from consultant Larry Suto, evaluated 11 open-source software packages and each community's response to security issues over the course of about three months. The goal was to find out if the community for each open-source software package was responsive to security questions or vulnerability findings, published security guidelines, and maintained a secure development process, for example. “Infoworld – July 21, 2008".
Além do valor moral da empresa, ainda existe um grande risco de segurança significativo para as empresas que o utilizam, porque em muitos casos, a comunidade open source não adere às práticas recomendadas de segurança mínima. Open source tem sido alvo constante de ataques de injeção SQL, estes ataques comprometem servidores Web, carregando-os com códigos maliciosos para seus próprios projetos. 9
3. Padronização As constantes faltas de padronização aumentam o tempo e os custos que este software pode chegar ao mercado, estas situações são sinônimos de perdas e constantes vindos diretamente do cliente final.
Os compradores de software
incorrem em dificuldades em comparar e avaliar sistemas. Infelizmente, este problema não é incomum e os consumidores são cautelosos dito que a obtenção de um software particular depende de um profissional proativo e de muita comunicação engenheiro-empresa. Os testes padronizados aliviam esta incerteza e riscos associados com a avaliação de opções de software proprietário, prevendo métodos consistentes e métricas para comparação. Além dos testes, verificaremos que a qualidade influencia o preço de mercado e a quantidade depende da capacidade dos utilizadores finais para avaliar a qualidade do software e claro, os custos.
4. Custos de Erros Mesmo realizando testes, há um custo durante o processo para identificar e corrigir erros de percurso. Estes erros, se testados regularmente podem vir em determinadas fazes do projeto.
5. Categoria de Software “O teste de software é uma das atividades mais custosas do processo de desenvolvimento de software, pois pode envolver uma quantidade significativa dos recursos de um projeto. O rigor e o custo associado a esta atividade dependem principalmente da criticalidade da aplicação a ser desenvolvida. Diferentes categorias de aplicações requerem uma preocupação diferenciada com as atividades de teste.” (Arílio Carlos Dias Neto)
A revisão e os testes do software em projeto medem o quão fácil é para atualizar, alterar, ou manter o desempenho do produto de software. O que se há de 10
levar em conta são os custos de fixação de qualquer bugs que emergem do processo de teste. Manutenção, flexibilidade e capacidade de teste são três subcaracterísticas que se encaixam nesta categoria.
5.1 Definição da categoria de produto:
Funcionalidade: Capacidade para fornecer funções que atendam
às necessidades específico ou implícita, quando o software é utilizado sob certas condições.
Confiança: Capacidade de manter um nível especificado de
desempenho quando usado sob condições especificadas.
Usabilidade:
Capacidade
de
ser
atraente,
compreendido,
aprendido e utilizado pelo usuário em condições específicas.
Eficiência:
Capacidade
para
fornecer
um
desempenho
adequado, em relação à quantidade de recursos utilizados, em condições especificadas.
Manutenção: Capacidade do produto a ser modificado.
Portabilidade: Capacidade de ser transferido de um ambiente
para outro.
5.2 Características Cada categoria tem um conjunto associado de recursos que definem as áreas-chave para satisfazer, alcançar e assegurar o controle de qualidade no produto e do processo. Algumas características deste processo:
Cliente – Fornecedor: Este é constituído por processos que
impactam diretamente o cliente, acompanha o desenvolvimento e a transição do software até o cliente e fornece o funcionamento adequado e à utilização do produto ou serviço de software.
Engenharia:
Consiste
em
processos
que
diretamente
especificam, implementam ou mantém o produto de software, sua relação com o sistema e sua documentação. 11
Suporte: Compreende processos que podem ser usados por
qualquer dos processos (incluindo os de suporte) em vários níveis do ciclo de vida de aquisição.
Gestão: Inclui processos que contenham práticas genéricas, que
possam ser utilizados por qualquer profissional que gerencie qualquer projeto ou processo.
Organizacional: Grupos dos processos estabelecidos como
metas comerciais da organização, este desenvolve bens e valores do processo, produto ou recurso, o que ajudará a organização a alcançar seus objetivos no projeto.
6. Qualidade do Software Qualidade é um termo que ganhou grande importância ao longo do tempo, pois é considerada um dos principais ativos que um país pode melhorar sua posição competitiva global (Ivanisevich, 1997). Comparado a um processo de software, a boa qualidade é essencial para estabelecer um programa de medidas a tomar. É também importante a utilização de modelos e métodos adequados para controlar o processo de desenvolvimento. Os usuários colocam valores diferentes em cada atributo, dependendo da utilização do mesmo, é importante que os atributos de qualidade sejam visíveis para os consumidores. No entanto, com o software não existe apenas problemas de informação assimétrica (onde um desenvolvedor tem mais instâncias de informação sobre a qualidade do que o consumidor), mas também onde o desenvolvedor realmente não conhece a qualidade do seu próprio produto. Não é incomum para o software tornar-se tecnicamente obsoleto antes de seus atributos de desempenho forem totalmente demonstrados em condições reais de operação. Em 1988, 1996 o IEEE apresentou numerosas métricas que podem ser usados para testar cada atributo. Essas métricas incluem:
Densidade de falha
Cumprimento dos requisitos
Cobertura de teste
Tempo médio de falha. 12
“Em todas as abordagens à qualidade, incluindo qualidade de software, a organização precisa ser considerada como organização orgânica ao invés de mecânica, usando seus recursos, ideias e esforços para transformar entradas em bens e serviços de qualidade. Assim, as características e as tecnologias para atingir este tipo de abordagem deve ser determinada. Esta é a razão pela qual o projeto de desenvolvimento de software é considerado o elemento da organização através do qual administra o desenvolvimento de software” (E.G. Guimarães, 2008).
De acordo com os autores Edward Yourdon (1992), Ivar Jacobson (1999), Len Bass (2003) e Roger Pressman (2002), um projeto de software consiste nos seguintes elementos: • Entradas: requisitos (necessidades, qualidade), recursos (tempo, custo, pessoas), objetivos, regras de negócio; • Processo: paradigma de fluxo de trabalho de engenharia de software, processo cultural do processo de determinação e aprendizado organizacional; • Saídas: Produto, metas alcançadas; Assim, o projeto pode ser considerado como o sistema que define o contexto que molda a qualidade do processo e a qualidade do produto, respectivamente. Tal como indicado por Humphrey (1997), a qualidade do processo assegura a qualidade do produto e, portanto, não pode separar essas duas qualidades. O software tem evoluído ao longo do tempo assim como seus atributos de qualidade. McCALL; RICHARDS; WALTERS, 1977 avaliaram atributos de qualidade de software, seu modelo de qualidade caracteriza-se em três categorias: operação do produto, revisão do produto e transição do produto. Em 1991, a Organização Internacional de Normalização (ISO) adotou ISO 9126 como o padrão para a qualidade do software (ISO, 1991). “Qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido” (Pressman, 2002).
13
Ao definir a qualidade do software, temos que diferenciar entre a qualidade do produto e da qualidade do processo desenvolvido neste (qualidade de desenho e fabricação). No entanto, os objetivos estabelecidos para a qualidade do produto irá determinar os objetivos do processo de desenvolvimento, uma vez que são interligados. Sem um processo de desenvolvimento é quase impossível obter um bom produto. “A ausência de defeitos, adequação ao uso, segurança, confiabilidade e especificações de coleta são elementos que estão envolvidos no conceito de qualidade de software. No entanto, a qualidade do software deve ser construída a partir do início, algo que não pode ser adicionado depois”. (Humphrey, 1997).
7. Abordagem histórica para Desenvolvimento de Software “A tabela abaixo é uma categorização esboçada de abordagens históricas para o desenvolvimento de software. Traça o movimento de desenvolvimento de software como uma “arte” até “engenharia” para a concepção presente “open source”. Terceira ordem aparece como o pacote desenvolvimento de um computador pessoal. Organizações teóricas afirmam que o processamento de informações e coordenação das tarefas de trabalho são características centrais de uma organização” (Galbraith, 1977; Minzberg, 1979; Groth, 1999). Fonte: Adaptive Evolutionary Information Systems – Pag. 19
Concepção e método Referências de desenvolvimento
Lógica e os desenvolvedores
Programando por arte Estrutura
Circa. 1950
Engenharia de Software
NATO Science, 1968
Considerado arte no início Desenvolvedores Refletivos Aplicação de ferramentas de Engenharia. BCS Desenvolvedores Refletivos em
Gerenciamento de Projeto
Dijkstra, 1968
Ordem de atividades de projeto Segunda ordem Segunda ordem Segunda ordem
Segunda ordem 14
Quarta Geração de linguagens Códigos de Open Source
Grindly, 1986
Pacotes de Software COTS
Brincklin, 2000
Raymond, 1999
projetos de negócio Desenvolvedores em ação Desenvolvedores Refletivos, mas na prática comunitária, ligado a nenhum projeto Desenvolvedores Refletivos e ativos
Terceira Ordem Segunda ordem Terceira Ordem
Segunda ordem Terceira Ordem
Há informações que o Departamento de Justiça dos Estados Unidos forçou a IBM em 1969 a desmembrar o software do hardware, tornando este um divisor de águas na história do desenvolvimento do Software. Em 1950 e por uma década os desenvolvedores trabalharam por conta, criando assim uma personalização. Depois do desmembramento e ordem dos Estados Unidos emergiram os desenvolvedores de software e engenheiros. Desde então as empresas se forçam a usar o meio de informação automatizados de processo de tarefas e com isso surgiu uma dependência tecnológica e a importância da programação para as atividades das empresas. Com isso introduziram-se meios de desenvolver melhores softwares e maneiras de testar e depurar os mesmos, ferramentas simples como linguagens de programação e ferramentas de depuração foram introduzidos. Com a demanda de computadores pessoais por volta de 1980, a demanda acelerou as melhorias na produtividade.
8. Testes de Software
Teste de software é qualquer atividade tem como objetivo avaliar um atributo ou capacidade de um programa ou sistema e determinar que ele atenda seus resultados necessários. (Hetzel, 1988) Apesar de crucial para a qualidade do software e amplamente utilizado por programadores e testadores, testes de software continuam sendo uma arte, devido à limitada compreensão dos princípios de software. A dificuldade em testes de software resulta da complexidade do mesmo: não podemos testar completamente um programa com complexidade moderada. O 15
teste é mais do que apenas a depuração, pode ser garantia de qualidade, verificação e validação, ou estimativa de confiabilidade. O teste pode ser utilizado como uma métrica genérica. Teste de correção e testes de confiabilidade são duas grandes áreas de teste. Teste de software é uma corrida entre tempo, orçamento e qualidade.
8.1 Infraestruturas destes testes Quando se fala de infraestrutura, se deve automaticamente pensar em custos, de maneira que, recursos extras são utilizados para detecção, localização e correção do produto. Em qualquer produto, sem importar qual seja, erros e defeitos afetam negativamente a qualidade do produto e como resultado as vendas. Isso aconteceu com os softwares que tiveram uma queda de receitas porque muitos usuários renunciaram os benefícios de softwares desenvolvidos só para eles. E tudo isso para descrever a infraestrutura inadequada que recebem hoje os testes de software.
8.2 Inadequações 8.2.1IEEE 829 Documentação Os tipos de documentos: Há oito tipos de documentos no padrão IEEE 829, que pode ser utilizado em três fases distintas de testes de software: 1. Elaboração das provas
Plano de teste: Plano como o teste vai prosseguir.
Especificação do Projeto de teste: Decida o que precisa ser testado.
Especificação de Caso de teste: Criar os testes a serem executados.
Procedimento de Teste: Descrever como os testes são executados.
Relatório de teste item Transmissão: Especifique os itens liberados
para testes. 2. Execução dos testes 16
Teste de Log: Anote os detalhes dos testes em ordem de tempo.
Relatório de Teste de Incidentes: Registrar os detalhes de eventos que
precisam ser investigadas. 3. Conclusão do Teste
Relatório de Teste Resumo: resumir e avaliar testes Fonte: Édipo Maciel – 20902181 Diovane Monteiro – 20902238
Pode-se ainda contar as pressões que exercem dentro da competitividade do mercado globalizado, a automação aumentou e a manufatura é realizada em quantidades absurdas onde a qualidade é uma síndrome pouco detectada, onde o universo da globalização exerce um poder fundamental em lucros excessivos. Por outro lado, outra força empurra a complexidade, confiabilidade, interoperabilidade aos requisitos do desenvolvimento de software, no entanto, estas forças levaram insuficiências a vários softwares testando a tecnologia de infraestrutura para emergir e tornar-se problemático para a indústria de software.
8.3 Ferramentas para Testes de Software Existem várias ferramentas de qualidade de software "estática" (isto é, analisadas, sem correr o software) e "caixa branca" (analisa com base na fonte). Ainda existe a ferramenta chamada “caixa preta”, qual não mencionaremos neste artigo. Destacaremos três de importância: Selenium, JMeter e Testlink. Os dois primeiros, Selenium e Jmeter, trabalham em automação de testes funcionais, o Testlink, na gestão de casos de teste. Selenium: Composto de duas ferramentas: Selenium IDE e Selenium Web Driver. O primeiro, um plugin do Firefox que irá gerar um ambiente de desenvolvimento que permite criar casos de teste para aplicações web. O segundo executa os testes. Este ambiente de automação de teste automático opera nos principais navegadores (IE, Mozilla, Chrome e Opera). Ele também permite testes para dispositivos móveis, iPhone e Android. Usa as seguintes línguas: Python, Ruby, Java e C #. A licença é "Apache License 2.0". 17
JMeter. Aplicação desktop em Java e dentro do Projeto Jakarta. Esta ferramenta permite realizar testes funcionais (e de rendimento) para aplicações web. Trabalha com os seguintes protocolos: HTTP, HTTPS, SOAP, JDBC, LDAP, JMS, Mail - POP3 (S) e IMAP (S). A licença é "Apache License 2.0". Testlink. Permite criar e gerenciar casos de teste, organizá-los em planos de teste, acompanhar resultados, estabelecer rastreabilidade de requisitos, gerar relatórios, etc. Integra-se com outros sistemas de monitorização "bugs", como Bugzilla, Mantis, etc Licença: GPL. Deve-se levar em consideração que a ferramenta de teste de software é um veículo para facilitar a execução de uma fase de testes. A combinação de tipos de ferramentas de teste e ensaio permite a fase de testes a ser executada (Perry, 1995).
8.4 Estágios de Testes de Software
“Será mais fácil e mais barato aplicar a qualidade desde os primeiros estágios de projeto de software, antes de iniciar os testes finais.” (Tecnologia de Informação e Gestão Empresarial – Pag 157)
Ao longo do ciclo de desenvolvimento e das fases do software são encontrados vários defeitos de requisitos, design, codificação unidade, testes, testes de integração, teste de sistema, instalação / aceitação, operação e até mesmo nas fases de manutenção encontram-se erros.
18
8.5 Fases de Testes de Software
Cobertura de Seguimento (Instruções sem ponto de decisão) Cobertura de Ramos (Todas as possibilidades de resultados) Cobertura de Condição/Decisão (Expressão Boleana Correta) Cobertura de Laços (While, Do while...) Cobertura de Requisitos Prova da Caixa Opaca Caixa Preta Prova Funcional (Códigos) (Funcionalidade) Prova de E/S Prova incluída pelos dados
Fases de testes
Caixa Branca (Código escrito)
Testes de módulo
Incluem módulos: Estruturais, Funcionais e Testes Finais Testes de integração
Testes de aceitação
Técnica de Desenho: Desenho Descendente Desenho Ascendente Codificação Incremental
Realizado pelo cliente antes de ser reproduzido Existem erros que somente o cliente consegue detectar Técnicas: Alfa e Beta
8.6 Tipos de Testes de Software Tipo de Teste
Descrição
Teste de Unidade
Provar o correto funcionamento de um módulo de código.
Teste de Integração
Testes de todos os elementos unitários que compõe o processo de uma só vez.
Teste Operacional
Garante que a aplicação pode rodar muito tempo sem falhar.
Teste Positivo-negativo
Garante
que
a aplicação
vai
funcionar no conforme execução. Teste de regressão
Toda vez que algo for mudado, 19
deve ser testada toda a aplicação novamente. Teste de caixa preta
Testar todas as entradas e saídas desejadas.
Teste caixa-branca
O objetivo é testar o código.
Teste Funcional
Testar
as
requerimentos,
funcionalidades,
regras
de
negócio
presentes na documentação. Validar as funcionalidades
descritas
na
documentação. Teste de Interface
Verifica se a navegabilidade e os objetivos
da
tela
funcionam
como
especificados e se atendem normas. Teste de Desempenho
Verifica se o tempo de resposta é o desejado para o momento de utilização da aplicação.
Teste de carga
Verifica
o
funcionamento
da
aplicação com a utilização de uma quantidade
grande
de
usuários
simultâneos. Teste de aceitação do usuário
Teste de Volume
Testes de stress
Testes de Configuração
Testes de Instalação Testes de Segurança
Testa se a solução será bem vista pelo usuário. Ex: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes. (aqui, cabem quesitos fora da interface, também). Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande, ou além de grande). Testar a aplicação sem situações inesperadas. Testar caminhos, às vezes, antes não previstos no desenvolvimento/documentação. Testar se a aplicação funciona corretamente em diferentes ambientes de hardware ou de software. Testar se a instalação da aplicação foi OK. Testar a segurança da aplicação 20
das mais diversas formas. Utilizar os diversos papéis, perfis, permissões, para navegar no sistema.
8.7 Padrões para Testes de Software
“Se eu pedir para você para testar um software, certamente você vai conseguir cumprir essa solicitação. Mesmo não tenho nenhuma noção sobre as técnicas existentes para que o teste seja bem conduzido. Ou seja, você pode testar um software usando apenas a sua intuição. É claro que entre a sua intuição e a norma ISO/IEC 29119 existe uma distância muito grande, tão grande quanto estar no nível do mar ou no topo do Monte Everest.” (Emerson Rios –
[email protected]) - sic
Existem várias regras que grandes organizações de normalização (ISO, IEEE, BSI, etc.) publicaram nos últimos anos, relacionados direta ou indiretamente com a verificação e validação de software. No entanto, em maio de 2007, quando a ISO criou um grupo de trabalho (WG26) para desenvolver um novo "Teste de Software Standard" com objetivo principal desta norma, atualmente em desenvolvimento, de servir como referência internacional na área de teste de software que permita tanto eliminar as inconsistências existentes entre as normas existentes e cobrir aquelas áreas "testing" que simplesmente não foram tratadas até agora nos outros padrões publicados. Esta norma futura é conhecida como "Teste de Software ISO / IEC 29119", cuja publicação em versão FIS (Final International Standard) está prevista para meados de 2012. O 29119 ISO / IEC cobre o ciclo de vida, através da análise, concepção, implementação e manutenção de testes de software. Com base nas regras principais que atualmente são líderes em testes de software, modelos de processos e ciclos de vida, a saber:
BSI (British Standards Institution): BS 7925-1, Software Testing: Part 1-
Vocabulary BS 7925-2, Software Testing: Part 2-Software Component Testing. 21
IEEE: IEEE Std. 829, Software Test Documentation y IEEE Std 1008,
Software Unit Testing, IEEE Std 1012-1998 Software Verification and Validation y IEEE Std 1028-1997 Software Reviews.
ISO/IEC: ISO/IEC 12207, Software Life Cycle Processes, ISO/IEC
15289, System and Software Life Cycle Process Information Products y ISO/IEC TR 19759, Guide to the Software Engineering Body of Knowledge. Esperamos que esta nova regra sirva para orientar a tendência que existe em torno de melhorar os testes de software, que permita padronizar a forma de planejar, projetar, implementar e manter evidência de um processo geralmente esquecido de "teste".
8.8 Custos
Custo das Falhas Detectadas pelo Cliente
Requerimentos
Desenho
Codificação
Testes
Manutenção Satisfação do cliente
22
8.9 Reduções de Custos
Qualquer análise de um processo de desenvolvimento de software suporta e justifica a necessidade de automatizar o processo de testes. A este respeito, os dados reais demonstram que os projetos SQS automatizam o processo de teste e podem atingir reduções de até 75% do custo da fase de manutenção. Portanto, o custo total de um projeto que tem sido feito com um sistema de teste eficaz pode ser reduzido a metade.
8.10 Valor dos Erros
“Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a newly released study commissioned by the Department of Commmerce’s National Institute of Stardars and Technology (NIST). / Bugs de software, ou erros são tão comuns e tão prejudiciais que eles custam a economia dos EUA cerca de US $ 59,5 bilhões anuais, ou cerca de 0,6 por cento do produto interno bruto, segundo um estudo recémdivulgado encomendado pelo Departamento Nacional de Comércio do Instituto
de
Padrões
e
Tecnologia
(NIST)”.
Fonte:
http://www.abeacha.com/NIST_press_release_bugs_cost.htm
Um estudo publicado pelo Departamento de Comércio dos Estados Unidos indica que erros de software causam a economia dos EUA uma perda anual de cerca de 59,5 bilhões. Este estudo indica que nem todos os erros podem ser eliminados e estimados em 22,5 bilhões de perda e que poderia ter sido evitado quando o desenvolvimento de aplicações foi aplicado estrategicamente adequado à qualidade. Considerando o fato de que quase todos os sistemas que usamos no dia a dia são incorporados a um software, esse valor é absolutamente verdadeiro. 23
Vamos pegar o exemplo de um telefone público. Os telefones têm embutido o software, mas quais são as consequências de um erro de desenvolvimento de software para este aparelho? Vamos supor que este é um erro de tarifa, o que significa que o telefone pode ainda funcionar, mas incorretamente calculou o custo da chamada. O primeiro impacto é derivado de seu erro na tarifa. No momento da localização do erro, seja o utilizador final, seja a companhia telefônica, já sofreram uma perda econômica. Perda facilmente quantificável. O segundo fator de custo é dada pela necessidade de reparar a falha. Consideremos em primeiro lugar, no caso mais favorável, ou seja, que o telefone permita que o software seja instalado nele mesmo a distância através da linha telefônica. Neste caso, o custo para reparar o erro pode ser calculado somando o tempo e adicionando o esforço associados com o relatório de erro, o tempo e o esforço requeridos para localizar o erro no software e o tempo e o esforço requeridos para a reparação adicionados ao tempo e esforço dos testes necessários para verificar a operação correta do sistema. Na pior das hipóteses, ou seja, o telefone não suporta o reparo ou transferência de software a distância, aos custos acima será adicionado o custo de novos dispositivos e os custos da translado de um instalador para onde cada telefone necessite a instalação apropriada . Todos estes custos deve-se acrescentar que durante o período de reparo estes telefones não funcionarão e podem causar danos claros para os usuários e uma perda econômica clara para a telefonia. Este exemplo simples pode ser facilmente aplicado a outros sistemas, de modo que o prejuízo econômico decorrente de erros de software pode ser verdadeiramente astronômico.
8.10.1 Alguns dos mais famosos erros de softwares da história 1. Problemas no Mariner (1962) Custo: 18,5 milhões dólares 24
Desastre: Mariner, um foguete com uma sonda espacial para Vênus, foi desviado de seu percurso de voo logo após lançamento. O controle da missão destruiu o foguete 293 segundos após a decolagem. Causa: Um programador, ao passar para o computador uma fórmula que haviam lhe entregado escrita manualmente, se esqueceu de uma barra. Sem ela, o software tratava variações normais de velocidade como se fossem sérios problemas, causando falhas por tentativas de correções que acabaram por enviar o foguete fora do curso. 2. Hartford Coliseu Desmorona (1978) Custo: 70 milhões de dólares, além de outros danos de 20 milhões para a economia local. Desastre: Poucas horas depois de milhares de fãs deixarem o Coliseu Hartford, o teto de treliça de aço desabou pela pesada neve molhada. Causa: O programador do software CAD, utilizado para projetar o coliseu, incorretamente assumiu que o suporte do telhado de aço enfrentaria apenas compressão natural. Mas quando um dos suportes inesperadamente recebeu um bloco de neve, este desencadeou uma reação em cadeia que derrubou o telhado de outras seções como dominós. 3. CIA distribui gás aos soviéticos (1982) Custo: Milhões de dólares e danos significativos a economia soviética Desastre: O software de controle se descontrolou e produziu uma intensa pressão no gasoduto Trans-Siberian, resultando na maior explosão não nuclear da história. Causa: Agentes da CIA supostamente acusaram um bug em um sistema de computador canadense adquirido pelos soviéticos para controlar seus oleodutos gás. A compra foi parte de um plano estratégico Soviético para roubar ou veladamente obter tecnologia dos EUA. Quando a CIA descobriu a compra, eles sabotaram o software para que ele passasse na inspeção Soviética, mas falhasse em operação. 4. 3ª Guerra Mundial (1983) Custo: Quase toda a humanidade Desastre: O sistema de alerta precoce soviético falsamente indicou que os Estados Unidos tinham lançado cinco mísseis balísticos. Felizmente, o oficial de 25
serviço soviético tinha uma “sensação esquisita no estômago” e fundamentalmente, se EUA estavam realmente atacando, eles lançariam mais de cinco mísseis, por isso ele relatou o aparente ataque como um alarme falso. Causa: Um bug no software soviético falhou ao detectar reflexos solares como falsos mísseis. 5. Máquina medicinal mata (1985) Custo: Três mortos e três seriamente feridos Desastre: A máquina de radiação canadense Therac-25 irradiou doses letais em pacientes. Causa: Por causa de um bug sutil chamado de “condição de corrida“, um técnico acidentalmente configurou o Therac-25de modo que o feixe de elétrons seria como um fogo de alta potência. 6. Crash na Wall Street (1987) Custo: $500 bilhões em um dia Desastre: Em 19 de outubro de 1987, o índice Dow Jones caiu 508 pontos, perdendo 22,6% de seu valor total. Esta foi a maior perda que Wall Street já sofreu em um único dia. Causa: Um mercado em grande alta foi interrompido por uma série de investigações conduzidas pela SEC e por outras forças do mercado. Como os investidores fugiram de ações investigadas, um número muito grande de ordens de venda foram gerados pelos computadores, quebrando sistemas e deixando os investidores efetivamente cegos. 7. Linhas da AT&T “morrem” (1990) Custo: 75 milhões de ligações perdidas e 200 reservas aéreas perdidas Desatre: Um switch dos 114 centros de swiches da AT&T sofreu um problema mecânico que fez com que todo o seu centro fosse desligado. Quando o seu centro voltou a ativa, enviou uma mensagem aos outros, o que causou o desligamento dos outros centros e deixou a empresa parada por 9 horas. Causa: Uma única linha de código em uma atualização de software implementada para acelerar chamadas causou um efeito cascata que desligou a rede. 8. Patriot Acaba com Soldados (1991) Custo: 28 soldados mortos e 100 feridos. 26
Desastre: Durante a primeira Guerra do Golfo, um sistema (Patriot) americano de mísseis na Arábia Saudita falhou ao interceptar um míssel vindo do Iraque. O míssel destruiu acampamentos americanos. Causa: Um erro de arredondamento no software calculou incorretamente o tempo, fazendo com que o sistema Patriot ignorasse os mísseis Scud de entrada. 9. Pentium Falha em uma Divisão Longa (1993) Custo: $475 milhões e a credibilidade de uma empresa Desastre: O altamente promovido Pentium, da Intel, ocasionalmente cometeu erros ao dividir números de ponto flutuante em um intervalo específico. Por exemplo, dividindo 4195835.0/3145727.0 obteve 1,33374 ao invés de 1,33382, um erro de 0,006%. Embora o bug afetasse apenas alguns usuários, se tornou um pesadelo nas relações públicas. Com uma estimativa de 5 milhões de chips defeituosos em circulação, a Intel se ofereceu para substituir os chips Pentium apenas para os consumidores que poderiam provar que eles precisavam de alta precisão. Contudo a Intel acabou substituindo os chips de qualquer um que reclamou. Causa: O divisor na unidade de ponto flutuante do Pentium tinha uma tabela de divisão falha, faltando cerca de cinco mil entradas, resultando nestes erros de arredondamento. 10. Ariane Rocket Goes Boom (1996) Custo: $500 milhões Desastre: Ariane 5, o mais novo foguete da Europa não tripulado, foi intencionalmente destruído segundos após seu lançamento em seu voo inaugural. Também foram destruídos quatro satélites científicos para estudar como o campo magnético da Terra interage com os ventos solares. Causa: O desligamento ocorreu quando o computador de orientação tentou converter a velocidade do foguete de 64-bits para um formato de 16 bits. O número era muito grande, o que resultou em erro de estouro. Quando o sistema de orientação desligou, o controle passou para uma unidade idêntica redundante, que também falhou porque nele estava correndo o mesmo algoritmo. 11. Skynet Traz o Dia do Juízo Final (1997) Custo: 6 bilhões de mortos e quase a destruição de toda a civilização humana e ecossistemas terrestres (ficção). 27
Desastre: Alguns operadores, na tentativa de desligar a Skynet (rede mundial de computadores), acabam fazendo a empresa responder disparando mísseis nucleares dos EUA à Rússia, iniciando uma guerra nuclear global que ficou conhecida como Dia do Juízo Final (29 de agosto de 1997). Causa: Cyberdyne, o principal fabricante de armas, instalou a tecnologia Skynet em todos os equipamentos militares, incluindo bombardeiros e sistemas de defesa antimísseis. A tecnologia Skynet formava uma rede contínua e efetivamente removia recursos humanos de defesa estratégica. Eventualmente o Skynet se tornou consciente, foi ameaçado quando um homem tentou colocá-lo offline, procurou sobreviver, e revidou com uma guerra nuclear. 12. Estudo Desastroso (1999) Custo: Credibilidade da ciência Desastre: Neste caso, o software utilizado para analisar os desastres tinha um desastre próprio. O jornal The New England Journal of Medicin relatou aumento das taxas de suicídio depois de graves desastres naturais. Infelizmente, estes resultados mostraram-se incorretos. Causa: Um erro no programa mostrava a taxa de suicídios por ano como o dobro do seu valor real, o que foi suficiente para inutilizar toda a pesquisa. 13. Passaportes britânicos para lugar nenhum (1999) Custo: £12.6 millões Desastre: A agência de passaportes do Reino Unido implementou um sistema da Siemens que falhou ao emitir documentos para meio milhão de cidadãos britânicos. A agência teve que pagar milhões ao governo para compensar a raiva da população. Causa: A Agência lançou seu novo sistema sem testá-lo de forma adequada ou treinar seus funcionários. Ao mesmo tempo, uma mudança na lei exigia que todos os menores de 16 anos viajando ao exterior deveriam obter um passaporte, resultando em um aumento enorme na procura de passaportes, o que sobrecarregou o sistema. 14. Bug do Milênio (1999) Custo: $500 bilhões Desastre: O desastre de um homem é a fortuna de outro, como demonstra o Bug do Milênio. Empresas gastaram bilhões com programadores para corrigir uma 28
falha no software legado. Embora nenhuma falha significativa ocorreu, a preparação para o Bug do Milênio teve um custo significativo e impacto no tempo em todas as indústrias que usam a tecnologia computacional. Causa: Para economizar espaço de armazenamento de computador, softwares legados muitas vezes armazenavam anos para datas com números de dois dígitos, como 99 para 1999. Esses softwares também interpretavam 00 para significar 1900, em vez de 2000, por isso, quando o ano de 2000 veio, bugs apareceriam. 15. Tratamento de Câncer Mortal (2000) Custo: 8 pessoas mortas e 20 seriamente feridas Desastre: O software de radiação da empresa Multidate calculou mal a dosagem de radiação que deveria ser enviada, expondo pacientes a níveis fatais de radiação. Os físicos que foram indicados para checar as máquinas foram condenados a morte. Causa: O software calculava a dosagem de radiação baseando-se na ordem de entrada dos dados, e algumas vezes enviava o dobro da dose do que deveria. 16. EDS Drops Child Support (2004) Custo: £539 milhões (e a conta ainda cresce!) Desastre: A grande empresa de serviços EDA desenvolveu um sistema para o Centro de Suporte à Crianças do Reino Unido (CSA) que acidentalmente pagou a mais 1.9 milhões de pessoas, recebeu em menos de 700.000 casos, registrando uma lista incansável de erros. Causa: A EDS apresentou um sistema de TI complexo e grande demais para o CSA, ao mesmo tempo em que tentava reestruturar a agência. 17. Desastre no FBI (2005) Custo: $105 milhões jogados fora! Desastre: O FBI desistiu da revisão de um sistema após quatro anos de esforço. O projeto Arquivo Virtual foi um maciço sistema de software integrado para agentes compartilharem arquivos de casos e outras informações. Causa: Má gestão e uma tentativa de construir um projeto de longo prazo sobre tecnologia ultrapassada resultou em um sistema complexo e inutilizável. Fonte: http://www.profissionaisti.com.br
29
9. Descrições e Modelo Conceitual As funções dos modelos conceituais vêm sendo grandemente ampliada de uma documentação de dados para o modelo de ponto de partida ao projeto ao projeto de base de dados. O modelo conceitual procura ser um modelo abstrato da área da organização representada na base de dados o qual contém detalhes de sua implementação.
10. Depuração “Em uma típica organização de desenvolvimento comercial, o custo de fornecimento (garantia de que o programa irá funcionar satisfatoriamente em termos funcionais e não funcionais de suas especificações dentro dos ambientes de implementação esperados) com via de depuração adequada, testes e atividades de verificação podem variar de 50 a 75 por cento com facilidade do custo total de desenvolvimento”. (Brent Hailpern, Padmanabhan Santhanam, 2002)
30
A depuração ou debugging é o processo metodológico de encontrar e reduzir bugs (defeitos) ou defeitos em um programa de computador ou uma peça de hardware. A tarefa de depuração de um bug de software, geralmente requer as seguintes etapas.
Reconhecer que este bug existe (um programa pode conter erros que
jamais serão detectados).
Isolar a fonte de erro.
Identificar a causa do erro.
Determinar uma solução para o erro.
Aplique a solução.
Programa de teste.
Em geral, as tarefas de depuração, são muitas vezes complicadas e cansativas. Existem aplicações que permitem que o programador auxilie nas tarefas, mas é a capacidade do determinante mais importante para a eficácia e eficiência do processo de tratamento. Os programas de depuração são chamados de purificadores ou depuradores (também o nome dado para o programador que realiza esta tarefa). Permitem que você execute um programa, pause, volte a iniciá-lo, executá-lo por partes, ver ou alterar valores de variáveis, etc. A depuração de hardware é muitas vezes usado em baixo nível de software, firmware, instrumentos específicos (osciloscópios, analisadores lógicos e circuitos emuladores, etc.). O que se tem que levar em conta é que testes e depuração são atividades diferentes, mas a depuração se deve incluir em todos os processos de testes.
10.1 A Arte da Depuração “A depuração é uma das partes mais frustrantes da programação. Contém elementos de resolução de problemas ou quebra-cabeça, juntamente com o desagradável reconhecimento que se há cometido um erro. A ansiedade enorme e a inclinação de não aceitar
a
possibilidade
de
cometer-se
erros,
torna
a
tarefa
31
extremamente difícil. Felizmente, existe também uma grande alívio e reduz a tensão quando o erro é finalmente ... corrigido”. (Shneiderman, 1979)
Teste de software é um processo que pode se planificar e especificar sistematicamente. Pode-se desenhar casos de teste, pode-se definir uma estratégia e avaliar os resultados comparados com as expectativas previstas. A depuração ocorre como uma consequência de um teste eficaz. Isto é, quando um caso de teste detecta um erro, a depuração é o processo que provoca a eliminação de erro. Mesmo que a depuração possa e deva ser um processo metódico, ainda tem muito de arte. Um engenheiro de software, na avaliação dos resultados de um teste, muitas vezes se encontra com uma indicação "sintomática" de um problema no software. Isto é, a manifestação externa de um erro e a causa interna do erro podem não estar relacionadas de uma maneira óbvia. O processo mental, apenas em conhecimento e experiência, conecta um sintoma com a causa e isso é a depuração.
10.2 O Processo de Depuração A depuração não é um teste, mas sempre ocorre como consequência do teste. O processo de purificação começa com a execução de um caso de teste. Os resultados são avaliados e aparece uma falha na correspondência entre os esperados e os encontrados realmente. Em muitos casos, os dados que não correspondem são um sintoma de uma causa subjacente continua escondida. O processo de depuração tenta fazer a correspondência do sintoma com a causa, levando assim a correção do erro. O processo de depuração sempre tem um dos seguintes resultados:
Encontra-se a causa, corrige-se e se elimina.
Não se encontra a causa.
Neste último caso, a pessoa que realiza a depuração deve suspeitar a causa, desenhar um caso de teste que ajude a confirmar suas suspeitas e o trabalho retrocede à correção do erro de uma forma interativa.
32
10.2.1 Por que é tão difícil depurar? Parece que a resposta tem mais a ver com a psicologia humana do que com a tecnologia de software. No entanto, várias características dos erros nos dão algumas pistas: O sintoma e a causa podem ser geograficamente remoto entre si, isto é, os sintomas podem aparecer em uma parte do programa, enquanto a causa está localizado muito longe em outro lugar. Estruturas de programas fortemente acoplados destacam esta situação. O sintoma pode desaparecer (temporariamente) ao corrigir outro erro. O sintoma pode realmente ser causado por algo que não é um erro (por exemplo, imprecisão de arredondamento). O sintoma pode ser causado por erro humano que não é facilmente detectado. Os sintomas podem ser resultados de problemas de temporização em vez de problemas de processo. Pode ser difícil de reproduzir exatamente as condições de entrada (por exemplo, uma aplicação de tempo real em que a ordem de entrada não é determinada). Os sintomas podem aparecer de forma intermitente, isto é particularmente comum em sistemas incorporados que acoplam hardware e software de maneira confusa. O sintoma pode ser devido a causas que se distribuem por uma série de tarefas executadas em diferentes processadores. Durante a depuração encontrar erros que vão desde o menos inesperado (por exemplo: formato de saída incorreta) até o mais catastrófico (por exemplo, o sistema falha, causando danos econômicos graves ou físicos). A medida que as consequências do erro aumentam, há uma pressão crescente para encontrar a causa. Muitas vezes, a pressão força um engenheiro de software corrigir um erro e introduzir mais dois.
10.3 Abordagens utilizadas 33
Qualquer que seja a abordagem utilizada, a depuração tem um único propósito primordial: encontrar e corrigir a causa de um bug no software. O objetivo é alcançado por uma combinação e avaliação sistemática de intuição e sorte. Vejamos um exemplo simples que nada tem a ver com o software: na minha não funciona a luz. Se nada funciona em casa, a causa deve estar no fusível ou disjuntor principal da casa, também observo outras casas da rua para ver se há um apagão e assim segue a sequência de hipóteses e provas. Em geral, três abordagens podem ser propostas para depuração: Análise do Programa Entrada e Saída do Programa Rastreamento Interno do Programa Cada uma das abordagens acima referidas pode ser suplementada com ferramentas de depuração. Usam-se vários compiladores de depuração, suporte dinâmico para depuração ("tracers"), gerador automático de casos de teste, despejos de memória e mapas de referência cruzada. Baseado num completo documento de desenho do software e um código fonte claro Qualquer discussão sobre abordagens e ferramentas de depuração não seria completa sem mencionar um poderoso aliado: as outras pessoas, outros conhecimentos!
11. Exemplo Prático 11.1 Software Cadastral Empresa do ramo veterinário solicita a criação de software para o cadastramento de clientes e seus Animais, com relatórios de consultas e informações sobre os registros.
11.2 Desenvolvimento Premissas do Desenvolvimento
Cliente quer um software simples e leve.
Irá trabalhar em apenas uma maquina.
Necessita de Banco de Dados. 34
Cliente não quer investir em softwares e hardwares.
Cliente possui office professional e hardware compatível.
Desenvolvimento
Cadastrar Clientes
Cadastrar Animais
Emitir Relatórios
11.2.1 Linguagem e Banco de Dados Tendo em vista as premissas o desenvolvedor optou: Bando de Dados Access Linguagem Visual Basic
Tabelas do Banco de Dados
35
Interface do Sistema
36
11.3 Testes de Software
Os Testes Executados no Software foram: Novos Cadastros de Clientes Novos Cadastros de Animais Geração dos Relatórios
No laboratório os desenvolvedores observaram um Bug no Software. O Relatório de Animais por Tipo não obteve um agrupamento correto: Observe:
11.3.1 BUG
37
11.4 Depuração O erro foi ocasionado por não haver um padrão de cadastro do “Tipo de Animal” A Solução é criar um padrão fixo, obrigando a escolha de um tipo. Necessidade da implementação de mais uma tabela, chamada TIPO. Tabela já contendo todos os tipos existentes que receberão atendimento clinico. Necessidade de alterar a tabela de Animais, fazendo o cruzamento com a tabela tipo. Necessidade de alterar a interface de cadastramento de animais. Necessidade de atualizar os registros dos animais. Necessidade de alterar o relatório de Animais por Tipo.
11.4.1 Criação da nova Tabela “TIPO”
38
Definição dos Tipos Usados
Alteração da Tabela Animal e Cruzamentos
39
Alteração da Interface
Atualização dos Registros de Animais
40
11.5 Relatórios Finalizado e Corrigido
11.6 Resultado
O problema foi corrigido, criando um padrão de cadastramento. O problema poderia ter se tornado imenso: Imagine o sistema implementado com 10.000 registros. A atualização cadastral poderia levar dias. Haveria a paralisação do cliente com o software.
41
12. Conclusão Desenvolvedores e usuários finais, junto com a qualidade e custos do software é influenciado pela infraestrutura de teste de software. Descobrimos que por mais automatizado que os softwares estejam, testes e depurações ainda são trabalhos artesanais de muito conhecimento que requer de muita atenção e cuidado do desenvolvedor. Ainda estamos longe da perfeição e do vasto conhecimento embora as ferramentas existam e as técnicas estejam disponíveis, há uma série de observações a serem vistas para que a qualidade e a importância de um bom software sejam reconhecidas pelo usuário final. Em todos os testes ocorrem depurações, ou seja, um faz parte do outro, o teste é usado não somente para localizar defeitos e corrigi-los, também utilizado na validação, processo de verificação, e medição fiabilidade. O teste é caro, automação é uma boa maneira de reduzir custo e tempo. Teste de eficiência e eficácia é o critério para as técnicas de cobertura à base de teste.
42
Referências:
SENAC (SP) - Perspectivas da Tecnologia da Informação – 2003 http://vqv.com.br/es/esm01_IntroducaoATesteDeSoftware.pdf - 1/05 (14 horas). ALAN C. SHAW - Sistemas e Software de Tempo Real – 2001 ANDREAS ZELLER - Why Programs Fail: A Guide to Systematic DebuggingSegunda Edição – 2009 ALLAN GILLIES - Software Quality: Theory and Management – Segunda Edição – 1997 http://143.106.50.145:8080/Cursos/EA976/02-08/sd-comp.pdf - 02/05 - (00:25 horas) IVAR JACOBSON - Object Oriented Software Engineering: A Use Case Driven Approach– 1992 EDWARD YOURDON – Análise Estruturada Moderna – Terceira Edição – 1990 LEM BASS Clements,Rick Kazman - Software Architecture in Practice – Terceira Edição – 2004 ROGER PRESSMAN – Engenharia de Software – Sexta Edição – 2006 HUMPHREY - Managing the software process – 1989 NANDISH PATEL - Adaptive Evolutionary Information Systems - 2003 http://pt.scribd.com/doc/63004346/Pesquisa-Normas-Iso-Ieee-Engenharia-Sofware 15/05 - 11 horas http://www.iteste.com.br/LinkClick.aspx?fileticket=6wabhUPo1Ig%3D&tabid=249&mi m=440 - 15/05 - 12 horas WILLIAM C. HETZEL - The Complete Guide to Software Testing - Segunda Edição 1988. http://www.abeacha.com/NIST_press_release_bugs_cost.htm 16/05 - 5:50 horas http://www.profissionaisti.com.br/2012/01/alguns-dos-mais-famosos-erros-desoftwares-da-historia/ 16/05 – 7 horas
43
