Trabalho Resume História da Computação

Prévia do material em texto

FASAM – Faculdade Sul-Americana 
Sistemas de informação 
Qualidade de Teste de Software 
5º período 
Aluno: Leandro Silva 
Profª.: Dianne Silva 
1.0 Historia da computação 
1.1introdução 
A História da Computação está marcada por interrupções repentinas, por mudanças 
inesperadas e imprevistas, tornando-se difícil a visão da evolução dos computadores mediante 
uma mera enumeração linear de invenções- nomes-datas. O desejo de conhecer as vinculações 
que o trabalho de determinados homens estabeleceram no tempo vem acompanhado do impulso 
de compreender o peso desses atos no conjunto da História da Computação. Buscar uma 
compreensão dos fatos através dos acontecime ntos que o precederam é um dos principais 
objetivos que estará presente neste estudo da História da Computação. 
 procurar compreender e estabelecer as diretrizes para uma disciplina de História da 
Computação, mediante a seleção das ideias, teorias e conceitos que ajudaram os homens em sua 
busca da automatização dos processos aritméticos e que conduziram à tecnologia dos 
computadores. 
 No Brasil ainda não existem livros que tratem do assunto História da Computação, 
observando-se uma lacuna cultural que países do primeiro mundo preocupam-se em preencher já 
faz alguns anos. Pretende-se que este trabalho seja uma contribuição nesse sentido e um ponto de 
partida para novos estudos de História, pois são muitos os campos que poderão ser abertos. 
 
1.2 Alan Mathison Turing: o berço da Computação 
 A revolução do computador começou efetivamente a realizar-se no ano de 1935, em uma 
tarde de verão na Inglaterra, quando Alan Mathison Turing (1912 - 1954), estudante do K ing’s 
College, Cambridge, durante curso ministrado pelo matemático Max Neumann, 
tomouconhecimento do Entscheidungsproblem de Hilbert.Uma parte da comunidade dos 
matemáticos buscava um novo tipo de cálculo lógico, que pudesse, entre outras coisas, colocar 
em uma base matemática segura o conceito heurístico do que seja proceder a um cômputo. O 
resultado destas pesquisas era fundamental para o desenvolvimento da matemática: tratava-se de 
saber se é possível haver um procedimento efetivo para se solucionar todos os problemas de uma 
determinada classe que estivesse bem definida. O conjunto desses esforços acabou por formar a 
fu n d a m e n ta ç ã o te ó ric a d a q u e v e io a se r c h a m a d a “C iê n c ia d a C o m p u ta ç ã o ”. 
 Os resultados de Gödel e o problema da decisão motivaram Turing primeiramente a 
tentar caracterizar exatamente quais funções são capazes de ser computadas. Em 1936, Turing 
consagrou-se como um dos maiores matemáticos do seu tempo, quando fez antever aos seus 
colegas que é possível executar operações computacionais sobre a teoria dos números por meio 
de uma máquina que tenha embutida as regras de um sistema formal. Turing definiu uma 
máquina teórica que se tornou um conceito chave dentro da Teoria da Computação. Ele enfatizou 
desde o início que tais mecanismos podiam ser construídos e sua descoberta acabou abrindo uma 
nova perspectiva para o esforço de formalizar a matemática, e, ao mesmo tempo, marcou 
fortemente a História da Computação. 
 A percepção genial de Turing foi a substituição da noção intuitiva de procedimento 
efetivo por uma ideia formal, matemática. O resultado foi a construção de uma conceituação 
matemática da noção de algoritmo, uma noção que ele mode lou baseando-se nos passos que um 
ser humano dá quando executa um determinado cálc ulo ou cômputo. Ele formalizou 
definitivamente o conceito de algoritmo. 
 
1.3 A Máquina de Turing 
 Um dos primeiros modelos de máquina abs trata foi a Máquina de Turing. Conforme o 
próprio T uring escreveu: “C om putar é norm a lmente escrever símbolos em um papel. Suponha 
que o papel é quadriculado, podendo ser ignorada a bidimensionalidade, que não é 
essencial.Suponha que o número de símbolos é finito. [...]. O comportamento do(a) 
computador(a) é determinado pelos símbolos que ele(a) observa num dado momento, e seu 
estado mental nesse momento. Suponha que exista um número máximo de símbolos ou 
quadrículas que ele(a) possa observar a cada momento. Para observar mais serão necessárias 
operações sucessivas. Admitamos um número finito de estados mentais [...]. Vamos imaginar 
que as ações feitas pelo(a) computador(a) serão divididas em operações tão elementares que são 
indivisíveis. Cada ação consiste na mudança do sistema computador(a) e papel. O estado do 
sistema é dado pelos símbolos no papel, os símbolos observados pelo(a) computador(a) e seu 
estado mental. A cada operação, não mais de um s ímbolo é alterado, e apenas os observados são 
alterados. Além de mudar símbolos, as operações devem mudar o foco da observação, e é 
razoável que esta mudança deva ser feita p ara símbolos localizados a uma distância fixa dos 
anteriores. [...] Algumas destas operações implicam mudanças de estado mental do 
com putador(a) e portanto determ inam qual será a próxim a ação”. 
 Turing definiu que os cálculos mentais consistem em operações para transformar 
números em uma série de estados intermediários que progridem de um para outro de acordo com 
um conjunto fixo de regras, até que uma resposta seja encontrada. Algumas vezes se usa o papel 
e lápis, para não se perder o estado dos nossos cálculos. As regras da matemát ica exigem 
definições mais rígidas que aquelas descritas nas d iscussões metafísicas sobre os estados da 
mente humana, e ele concentrou-se na definição desses estados de tal maneira que fossem claros 
e sem ambigüidades, para que tais definições pudessem ser usadas para comandar as operações 
da m áquina †. Turing começou com uma descrição precisa de um sistema formal, na forma de 
“tabela de instruções” q ue espec ificaria os movimentos a serem feitos para qualquer 
configuração possível dos estados no siste ma. Provou então que os passos de um sistema 
axiomático formal semelhante à lógica e os estados da máquina que perfaz os “m ovim entos” em 
um sistema formal automático são equivalentes entre si. Estes conceitos estão todos subjacentes 
na tecnologia atual dos computadores digitais, cuja construção tornou-se possível uma década 
depois da publicação do matemático inglês. 
 Um sistema formal automático é um dispositivo físico que manipula automaticamente os 
símbolos de um sistema formal de acordo com as suas r egras. A máquina teórica de Turing 
estabelece tanto um exemplo da sua teoria da computação quanto uma prova de que certos tipos 
de máquinas computacionais poderiam ser construídas. 
Efetivam ente, um a M áquina de Turing U niversal ‡, exceto pela velocidade, que depende 
do hardware, pode emular qualquer computador atual, desde os supercomputadores até os 
computadores pessoais, com suas complexas estr uturas e poderosas capacidades computacionais, 
desde que não importasse o tempo gasto. Ele provou que para qualquer sistema formal existe 
uma Máquina de Turing que pode ser programada para imitá- lo. Ou em outras palavras: para 
qualquer procedimento computaciona l bem definido, uma Máquina de Turing Universal é capaz 
de simular um processo mecânico que execute tais procedimentos. De um ponto de vista teórico, 
a importância da Máquina de Turing está no fato de que ela representa um objeto matemático 
formal. Através dela, pela primeira vez, se deu uma boa definição do que significa computar 
algo. E isso levanta a questão sobre o que exatamente pode ser computado com tal dispositivo 
matemático, assunto fora do escopo do presente trabalho e que entra no campo da complexidade 
computacional 
 
1.4 Decifrando códigos de guerra 
 Em 1940 o governo inglês começou a interessar-se de maneira especial pelas idéias de 
Turing. Ele foi convocadopela Escola de C ifras e Códigos, do governo, cuja tarefa era decifrar 
mensagens codificadas do inimigo. Q uando a guerra começou, a Escola Britâ nica de Códigos era 
dominada por lingüistas e filólogos. O Ministério do Exterior logo percebeu que os teóricos dos 
números tinham melhores condições de dec ifrar os códigos alemães. Para começar, nove dos 
mais brilhantes teóricos dos números da Inglaterra se reuniram na nova sede da Escola de 
Códigos em Bletchley Park, uma mansão vitoriana em Bletchley, Buckinghamshire. Turing teve 
que abandonar suas máquinas hipo téticas com fitas telegráficas infinitas e tempo de 
processamento interminável, para enfrentar problemas práticos, com recursos finitos e um limite 
de tempo muito real. 
 Devido ao segredo que cercava o trabalho realizado por Turing e sua equipe, em 
Bletchley, a imensa contribuição que prestaram ao esforço de guerra não pôde ser reconhecida 
publicamente por muitos anos após o conflito. C ostuma-se dizer que a Primeira Guerra Mundial 
foi a guerra dos químicos e a Segunda Guerra M undial, a guerra dos físicos. De fato, a partir da 
informação revelada nas últimas décadas, provavelmente é verdade dizer que a Segunda Guerra 
Mundial também foi a guerra dos matemáticos. E no caso de uma terceira guerra mundial sua 
contribuição seria ainda mais crítica. 
 Em toda sua carreira como decifrador de códigos, Turing nunca perdeu de vista seus 
objetivos matemáticos. As máquinas hipotéticas tinham sido substituídas por máquinas reais, 
mas as questões esotéricas permaneciam. Quando a guerra terminou, Turing tinha ajudado a 
construir um computador, o Colossus, uma máquina inteiramente eletrônica com 1.500 válvulas 
que eram muito mais rápidas do que os re lês eletromecânicos usados nas bombas. Colossus era 
um computador no sentido moderno da palavra. Com sua sofisticação e velocidade extra, ele 
levou Turing a considerá-lo um cérebro primitivo. Ele tinha memória, podia processar 
informação, e os estados dentro do computador se assemelhavam aos estados da mente. Turing 
tinha transformado sua máquina ima ginária no primeiro computador legítimo. Depois da guerra, 
Turing continuou a construir máquinas cada vez mais complexas tais como o Automatic 
Computing Engine. 
 
1.5 O triste fim 
O trabalho de Turing na Computação e na Matemática foi tragicamente encerrado por seu 
suicídio em junho de 1954, com a idade de 42 anos. Turing era homossexual e, depois da fuga de 
dois espiões britânicos de igual tendência para a então União Soviética, nos inícios da década de 
1950, houve uma especial pressão sobre ele para corrigir sua condição através do uso de 
hormônios. Turing, não aguentando a forte pressão, tomou cianeto. 
 
1.6 Pré-História tecnológica 
 Como já foi dito, só foi possível chegar aos computadores pelas descobertas teóricas de 
homens que, ao longo dos séculos, acreditaram na possibilidade de criar ferramentas para 
aumentar a capacidade intelectual humana, e dispositivos para substituir o s aspectos mais 
mecânicos do modo de pensar do homem. E desde sempre essa preocupação se manifestou na 
construção de mecanismos para ajudar tanto nos processos de cálculo aritmético quanto nas 
tarefas repetitivas ou demasiado simples, que pudessem ser s ubstituídas por animais ou 
máquinas. Por isso, os dispositivos físicos que precederam o computador, principalmente as 
máquinas analógicas que incentivaram a corrida final até o aparecimento dos computadores 
digitais. 
 
2.0 Noções básicas de qualidade de teste de software 
2.1 Fundamentos do Teste 
Objetivos de estudo para os fundamentos do teste 
Os objetivos identificam o que você estará apto a fazer após o término de cada módulo. 
 
2.2 Porque é necessário testar? 
• D escrever co m exem p lo s, a m aneira co m q ue o d efeito no so ftw are p o d e 
causar danos a pessoas, companhias ou ambientes.) 
• D istin g u ir entre a causa raiz d o d efeito e seus efeito s. 
• Justificar a necessid ad e d e testar utiliza nd o exem p lo s 
• D escrever porque teste é parte da garantia da qualidade e dar exemplos 
de como o teste contribui para atingir um nível de qualidade superior. 
• R eco rd ar term o s co m o engano, defeito, falha e seus termos correspondentes erro e bug. 
 
1.2 O que é teste? 
Palavras-Chave 
Código, depuração, desenvolvimento (de software), requisitos, revisão, base de 
testes, caso de teste, teste, objetivos do teste. 
• Recordar os objetivos comuns do teste. 
• Descrever os propósitos do teste no desenvolvimento, manutenção e operação de software 
como um meio de encontrar defeitos, prover confiabilidade, informações e prevenir defeitos. 
 
Conceito 
Uma visão comum do processo de teste é de que ele consiste apenas da fase de execução, como 
executar o programa. Esta, na verdade, é uma parte do teste, mas não contempla todas as 
atividades do teste. Existem atividades de teste antes e depois da fase de execução. Por exemplo: 
planejamento e controle, escolha das condições de teste, modelagem dos casos de teste e 
checagem dos resultados, avaliação do critério de conc lusão, geração de relatórios sobre o 
processo de teste e sobre sistema alvo de teste e encerramento ou conclusão (exemplo: após a 
finalização de uma fase de teste). Teste também inclui revisão de docume ntos (incluindo o 
código fonte) e análise estática. Testes dinâmicos e estáticos podem ser usados para atingir 
objetivos similares e provêem informações para melhorar o sistema a ser testado e o próprio 
processo de teste. Testes podem possuir objetivos diferentes: 
• E nco ntrar d efeito s. 
• G anhar co nfiança so b re o n ível d e q ualid ad e e p ro ver info rm açõ es. 
• P revenir d efeito s. 
O processo mental de projetar testes de forma antecipada no ciclo de vida (verificando a 
base de teste através da mode lagem de teste), pode ajudar a prevenir defeitos que poderiam ser 
introduzidos no código. Revisão de documentos (ex: requisitos) também ajuda a prevenir 
defeitos que possam aparecem no código. No processo de teste, diferentes pontos de vista levam 
em conta diferentes objetivos. Por exemplo, no teste feito em desenvolvimento (teste de 
componente, integração e de sistemas), o principal objetivo pode ser causar o maior número de 
falhas possíveis, de modo que os defeitos no software possam ser identificados e resolvidos. N o 
teste de aceite o objetivo principal pode ser confirmar se o sistema está funcionando conforme o 
esperado, ou seja, prover a confiabilidade de que esteja de acordo com o requisito. 
Em alguns casos o principal objetivo do teste pode ser avaliar a qualidade do software 
(não com a intenção de encontrar defe itos), para prover informações sobre os riscos da 
implantação do sistema em um determinado momento aos gestores. Testes de manutenção 
podem ser usados pa ra testar se não foram inseridos erros durante o desenvolvimento de 
mudanças. Durante os testes operacionais, o principal objetivo pode ser avaliar características 
como confiabilidade e disponibilidade. Depuração (debbuging) e teste são atividades diferentes. 
Testes podem demonstrar falhas que são causadas por defeitos. Depuração é a atividade de 
desenvolvimento que identifica a causa de um de feito, repara o código e checa se os defeitos 
foram corrigidos corretamente. Depois é feito um teste de confirmação por um testador para 
certificar se a falha foi eliminada. As responsabilidades de cada atividade são bem distintas: 
testadores testam e desenvolvedores depuram. 
 
1.3 Fundamentos do processo de teste 
• R eco rd ar as a tiv id ad es fu nd a m e nta is de teste desde planejamento ao encerramento de teste e as 
principais tarefas de cadaatividade de teste. 
 
1.4 A psicologia do teste 
• R eco rd ar q ue o suces so d o teste é influe nc iad o p o r fato res p sico ló gico s 
o Objetivos claros; 
o Equilíbrio entre teste independente e teste por conta própria. 
o Reconhecimento da necessidade da comunicação cortês e retorno 
das informações sobre os defeitos. 
• D iferenc iar a fo rm a d e p ensar d o s testad o res e d o s d esenvo lved o res. 
 
1.1 Porque é necessário testar? 
Palavras-Chave 
“B ug”, defeito, erro, falha, dano, engano, qualidade, risco, software, teste. 
 
1.1.1 Contexto dos sistemas de software 
Sistemas de software tornam-se cada vez mais parte do nosso dia-a-dia, desde aplicações 
comerciais (ex: bancos) até produtos de consumo (ex: carros). A maioria das pessoas já teve 
alguma experiência com um software que não funcionou como esperado. Softwares que não 
funcionam corretamente podem levar a muitos problemas, incluindo financeiro, tempo e 
reputação das empresas. Podem, inclusive, chegar a influe nciar na integridade das pessoas 
ou até mesma em mortes. 
 
1.1.2 Causas dos defeitos de software 
O ser humano está sujeito a cometer um erro (engano), que produz um defeito (dano, 
bug), no código, em um software ou sistema ou em um documento. Se um defeito no código for 
executado, o sistema falhará ao tentar fazer o que deveria (ou, em algumas vezes, o que não 
deveria), causando uma fa lha. Defeitos no software, sistemas ou documentos resultam em falhas, 
mas nem todos os defeitos causam falhas. Os defeitos ocorrem porque os seres humanos são 
passíveis de falha e porque existe pressão no prazo, códigos complexos, complexidade na infra-
estrutura, mudanças na tecnologia e/ou muitas interações de sistema. 
Falhas também podem ser causadas por co ndições do ambiente tais como: radiação, 
magnetismo, campos eletrônicos e poluição, que podem causar danos em software embarcado 
(firmware) ou influenciar a execução do software pela mudança das características de hardware. 
 
1.1.3 Função do teste no desenvo lvimento, manutenção e operação 
de software 
Rigorosos testes em sistemas e documentações podem reduzir os riscos de ocorrência de 
problemas no ambiente operaciona l e contribui para a qualidade dos sistemas de software, se os 
defeitos encontrados forem corrigidos antes de implantados em produção. O teste de software 
pode também ser necessário para atender requisitos 
contratuais ou legais ou determinados padrões de mercado. 
 
1.1.4 Teste e qualidade 
Com a ajuda do teste é possível medir a qualidade do software em termos de defeitos 
encontrados, por características e requisitos funcionais ou não-funcionais do software 
(confiabilidade, usabilidade, eficiênc ia e manutenibilidade). Para mais informações sobre testes 
não-funcionais veja o resultado da execução dos testes pode representar confiança na qualidade 
do software, caso sejam encontrados poucos ou nenhum defeito. Um testeprojetado 
adequadamente e cuja execução não encontra defeitos reduz o nívelde riscos em um sistema. Por 
outro lado, quando os testes encontram defeitos,a qualidade do sistema aumenta quando estes 
são corrigidos. Projetos anteriores devem prover lições aprendidas. Através do entendimento 
da causa raiz dos defeitos encontrados em outros projetos, os processos 
podem ser aprimorados de modo a prevenir reincidência de erros e,conseqüentemente, melhorar 
a qualidade dos sistemas futuros.Testes devem ser integrados como uma das atividades de 
garantia daqualidade (ex: juntamente aos padrões de desenvolvimento, treiname nto e 
análise de defeitos). 
 
1.1.5 Quando teste é suficiente? 
Para decidir quanto teste é suficiente, deve-se levar em consideração o nível 
do risco, incluindo risco técnico, do negócio e do projeto, além das restrições do projeto como 
tempo e orçamento. Teste deve prover informações suficientes aos interessados ( stakeholders) 
para tomada de decisão sobre a distribuição do software ou sistema, para as próximas fases do 
desenvolvimento ou implantação nos clientes. 
 
2.0 Princípios gerais do teste 
Princípios 
Alguns princípios foram sugeridos ao longo dos últimos 40 anos, oferecendo um guia geral para 
o processo de teste como um todo. 
 
Princípio 1 – Teste demonstra a presença de defeitos 
Teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. O 
Teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se 
nenhum defeito for encontrado, não prova que ele esteja perfeito. 
 
Princípio 2 – Teste exaustivo é impossível 
Testar tudo (todas as combinações de entradas e pré-condições) não é viável, exceto para casos 
triviais. Em vez do teste exaus tivo, riscos e prioridades são levados em consideração para dar 
foco aos esforços de teste. 
 
Princípio 3 – Teste antecipado 
A atividade de teste deve começar o ma is breve possível no ciclo de desenvolvimento do 
software ou sistema e deve ser focado em objetivos definidos. 
 
Princípio 4 – Agrupamento de defeitos 
Um número pequeno de módulos contém a ma ioria dos defeitos descobertos durante o teste antes 
de sua entrega ou exibe a maioria das falhas operacionais. 
 
Princípio 5 – Paradoxo do Pesticida 
Pode ocorrer de um mesmo conjunto de testes que são repetidos várias vezes não encontrarem 
novos defeitos após um determinado momento. Para superar este “parado xo do pesticida”, o s 
casos de testes necessitam ser freqüentemente revisado e atualizado. Um conjunto de testes novo 
e diferente precisa ser escrito para exercitar diferentes partes do software ou sistema com 
objetivo de aumentar a possibilidade de encontrar mais erros. 
 
Princípio 6 – Teste depende do contexto 
Testes são realizados de forma diferente conforme o contexto. Por exemplo, softwares de 
segurança crítica (por exemplo, software do computador de bordo de aeronaves) são testados 
diferentemente de um software de comércio eletrônico. 
 
Princípio 7 – A ilusão da ausência de erros 
Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas e 
necessidades dos usuários.