Qualidade e Teste de Software 2

www.concurseirosunidos.
org
www.concurseirosunidos.org
www.conc
urseirosuni
dos.org
Q IDADE SOFTWARE
A qualidade de software tem e aprimorado ignificativamente nos ltimos 15 anos.

Uma razão para isso é o fato de as empresas terem adotado novas técnicas e
tecnologias. Além disso, contudo, tem havido uma conscientização maior da
importância do gerenciamento de qualidade de software e da adoção de técnicas
de gerenciamento de qualidade provenientes da manufatura de software.
Entretanto, qualidade de software é um nceito mplexo ue não diretamente

comparável com qualidade na manufatura. Na manufatura, a noção de qualidade
tem sido aquela em que o produto desenvolvido deve atender às suas
especificações. Em um mundo ideal essa definição deveria ser aplicada a todos os
produtos, mas, para sistemas de software, existem diversos problemas!
Algumas pessoas acham que a qualidade pode ser conseguida definindo-se

padrões e procedimentos de qualidade organizacionais que verifiquem se esses
padrões são seguidos pela equipe de desenvolvimento de software. Seu gumento
é que os adrões devem globar oas ráticas; eguir ssas boas ráticas
inevitavelmente conduz a produtos e alta qualidade.
Na prática, entretanto, acredito que há muito mais gerenciamento de qualidade do

que padrões e burocracia associada para assegurar que estes foram seguidos. O
gerenciamento de qualidade estabelece procedimentos e padrões que objetivam o
desenvolvimento de software com qualidade. Para sistemas e grande porte,
pode ser estruturado em três atividades principais:
1. Garantia de qualidade: estabelecimento de um framework de procedimentos

organizacionais e padrões que conduzem a um software de alta qualidade.
2. Planejamento de qualidade: seleção de procedimentos e padrões apropriados

deste framework, adaptados para um projeto de software específico.
3. Controle de qualidade: definição e aprovação de processos que assegurem que

a equipe de desenvolvimento tenha seguido os procedimentos e os padrões.
Mas, espera um pouco! Galera, o que é qualidade? A qualidade é algo pelo qual nos
esforçamos para obter nos produtos, processos e serviços. O dicionário diz:
Uma característica inerente ou diferenciada; uma propriedade. b. Um traço

pessoal, especialmente um traço de caráter. 2. Caráter essencial; natureza. 3.a.
Superioridade de natureza. b. Grau ou classificação de excelência.
A qualidade não é um atributo u uma característica singular. É multidimensional e

pode ser ossuída por m roduto ou or m rocesso. A qualidade do produto
está concentrada na criação do produto certo, enquanto a qualidade do processo
está concentrada na criação correta do produto. A definição do dicionário é muito
genérica, vamos ver a definição do processo unificado:
Qualidade é a característica de ter demonstrado a realização da criação de um

produto que atende ou excede os requisitos acordados, conforme avaliado por
medidas e critérios acordados, e que é criado em um processo acordado.
Obter ualidade não só "atender requisitos" u roduzir m roduto ue atende

às ecessidades e expectativas dos suários. Pelo contrário, também inclui a
identificação das medidas e dos critérios para demonstrar a obtenção da qualidade
e a implementação de um processo para garantir que o produto por ele criado
tenha atingido o grau desejado de qualidade e possa ser repetido e gerenciado.
Vamos ver agora algumas características de qualidade:
 Interoperabilidade: capacidade do produto de software de interagir com um

ou mais sistemas especificados. Habilidade de dois ou mais sistemas
(computadores, meios de comunicação, redes, software e outros
componentes de TI) de interagir e de intercambiar dados de acordo com um
método definido, de forma a obter os resultados esperados.
 Conformidade: a capacidade do produto de software de estar de acordo com

normas, convenções ou regulamentações previstas em leis e prescrições
similares relacionadas à funcionalidade. Pode-se dizer que é o atendimento
às especificações do produto ou processo, avaliada por meio de medições,
testes ou auditorias.
 Tolerância a Falhas: capacidade de um produto de software de manter um

nível de desempenho especificado em casos de defeitos no software ou de
violação de sua interface especificada. Pode-se dizer que é a habilidade de
satisfazer requisitos apesar de suas falhas.
(FCC 014 RT/1 alista de Sistemas) A qualidade de software constitui-se

em um fator de grande importância no seu desenvolvimento. Dentre as
propriedades utilizadas para determinar a qualidade de software,
a) mede-se, exclusivamente, a qualidade da documentação produzida para o

software.
b) verifica-se a satisfação de requisitos estabelecidos, incluindo o desempenho.
c) não se abrange questões relativas à interface do software.
d) não há preocupação com a facilidade de manutenção do software.
e) não se inclui a confiabilidade esperada do software.
Comentários:
(a) Apenas a documentação? Não, inclusive a documentação – mas mede-se

diversos aspectos do software;
(b) Perfeito, verifica se os requisitos estabelecidos forem satisfeitos pelo software

desenvolvimento – tanto funcionais como não-funcionais (ex: desempenho);
(c) Abrange, sim! Na verdade, abrange-se tanto requisitos funcionais como não-
funcionais (ex: interface);
(d) Há preocupação, sim! Facilidade de manutenção de software é um requisito não-

funcional que deve ter preocupação com a qualidade;
(e) Inclui, sim! Esse também é um requisito não-funcional que deve ser incluído na
preocupação com a qualidade de um software.
Gabarito: B
www.conc
urseirosun
idos.org
www.co
ncurseir
osunido
s.org
ERIFICAÇÃO & VALIDAÇÃO
Em seu livro, Pressman diz:
Durante e depois do processo de implementação, o programa em

desenvolvimento deve ser verificado para certificar-se de que ele atende a sua
especificação e entrega a funcionalidade esperada pelas pessoas que pagam
pelo software. Verificação e Validação (V&V) é a denominação dada a esses
processos de verificação e análise. Atividades de verificação e validação
ocorrem em cada estágio do processo de software. V&V começa com revisões
de requisitos e continua ao longo das revisões de projeto e das inspeções de
código até o teste de produto.
Percebam que Validação Verificação ão oisas iferentes! E qual a diferença? Ora,

Boehm descreveu de uma maneira simples e genial, por meio de duas perguntas:
 Verificação: Estamos construindo o produto corretamente?

 Validação: Estamos construindo o produto correto?
A Verificação ocorre em ambiente de desenvolvimento e envolve a certificação de

que o software construído eja de rdo m ecificações de requisitos
(funcionais e não-funcionais)! Já a Validação ocorre em ambiente de produção e se
certifica de que o software construído á de acordo m xpectativas o ente.
Produto está de acordo com as especificações? Ele satisfaz os anseios dos usuários?
Eu peço a vocês! Não, a verdade eu mploro ue vocês emorizem diferença

entre esses dois onceitos! É muito simples, mas eu já me cansei das incontáveis
vezes que eu vi questões de prova tentando confundir os candidatos e obtendo
êxito. Como você decorou, professor? Muito simples! Verificação ocorre em relação
à Especificação de Requisitos!
Há dois ipos de Verificação: stática e Dinâmica! A Estática (também chamada

Inspeção de Software) trata da análise de documento de requisitos, análise de
diagramas de projetos, análise de código-fonte, etc. Ela ocorre sem a necessidade
de executar o software e pode ocorrer de forma automatizada, antes mesmo da
implementação do sistema.
Já a Verificação Dinâmica (também chamada de Teste1) envolve executar o software/

protótipo, i.e., a partir dos dados de entrada, examina-se o comportamento por
meios das saídas, de modo que se verifique se o desempenho obtido está de acordo
com o esperado. Grosso odo, Estática trata da documentação a Dinâmica trata
da execução em si.
1
Alguns autores tratam V&V como uma coisa só, integral, inteira, una.
localiza e conserta esses defeitos e geralmente é feita por uma equipe de

desenvolvimento. Ficou fácil de entender agora, né?!
www.concurse
irosunidos.org
ESTES DE SOFTWARE
O este de Software é o rocesso e tar m oftware com ois bjetivos

principais: primeiro, demonstrar ao desenvolvedor e ao cliente que o software
atende aos requisitos especificados; segundo, descobrir falhas ou defeitos no
software que apresente comportamento incorreto, não desejável ou em não
conformidade com sua especificação.
A primeira meta conduz ao Teste de Validação, no qual você espera que o sistema
seja executado orretamente em m ado njunto e casos e teste que refletem
o so erado do istema. A segunda meta conduz ao teste de defeitos, no qual
são projetados casos de teste para expor defeitos. Os casos de teste podem ser
obscuros e não precisam refletir como o sistema é usado normalmente.
Os estes de software não odem demonstrar que um software é livre de defeitos

ou que ele se comportará conforme especificado odas ircunstâncias
existentes. É sempre possível que um teste ignorado possa descobrir mais
problemas no sistema. Já dizia Edsger Dijkstra: “Os testes podem somente mostrar
a presença de erros, não sua ausência”. Captaram?
A meta é convencer s esenvolvedores e clientes do sistema de que o oftware é

bom suficiente para o uso peracional. O teste é um processo voltado a atingir a
confiabilidade do software. Para o Teste de Validação, um teste bem-sucedido é
aquele em que o sistema funciona corretamente. Para o Teste de Defeitos, um teste
bem-sucedido é o que expõe um defeito que causa o funcionamento incorreto.
O que é um Teste de Software? Como é possível de prever, há diversas definições

diferentes de diversos autores. Myers, or x mplo, iz que é o rocesso de
executar um eterminado software com a intenção de encontrar efeitos. Já a IEEE
729 define como o processo formal de avaliar um sistema ou componente por meios
manuais ou automáticos para verificar se ele satisfaz os requisitos especificados.
O Glossário International Software Testing Qualifications Board (ISTQB) conceitua

atividades do ciclo de vida, estáticas ou dinâmicas, voltadas para o planejamento,
preparação e avaliação de produtos de software e produtos de trabalho
relacionados a m e determinar e eles satisfazem s equisitos pecificados
demonstrar que estão aptos para sua finalidade e detecção de defeitos.
- stabilidade: grosso modo, podemos dizer que “quanto menos modificações,

menos interrupções no teste”.
- ompreensibilidade: grosso modo, podemos dizer que “quanto mais

informações temos, mais inteligentemente vamos testar”.
Na etapa de Preparação, organiza-se o ambiente de testes, com infraestrutura

adequada e pessoal capacitado, registrando e controlando as versões do produto.
Na etapa e Especificação, boram-se e revisam-se os asos de Teste e os

Roteiros (Scripts) de Teste. Na etapa de Execução, preparam-se os dados de testes,
executam-nos, solucionam-se ocorrências, acompanha-se a execução dos casos de
teste e elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório com as conformidades e não-conformidades.
executar os testes no sistema completo esperando encontrar os erros. Essa

abordagem, bora atraente, implesmente não nciona; esultará em m
software defeituoso ue desagrada todos os que investiram nele.
No outro extremo, você pode executar testes diariamente, sempre que uma parte
do sistema seja construída. Essa abordagem, embora menos atraente, pode ser
muito eficaz. Uma estratégia que é preferida pela maioria das equipes de software
está entre os dois extremos. Ela assume uma visão ncremental do este, onforme
é apresentado na espiral.
A imagem ma mostra que a espiral e nicia entido orário pelo Teste de

Unidade, que é responsável por analisar o código em si; em seguida realiza o Teste
de Integração, que é responsável por analisar o projeto; depois o Teste de
Validação/Aceitação, que é responsável por analisar os requisitos do usuário; e, por
fim, o Teste de Sistema, é responsável por analisar o sistema como um todo.
Testes de Software podem e dividir Baixo ível (1º Nível) Alto vel 2º vel)!
Nos Testes de Baixo Nível, o profissional deve ter um profundo conhecimento da
estrutura interna do software. Por esse motivo, é natural nas empresas que as fases
desse nível de teste sejam transferidas para o próprio desenvolvedor, pois ele possui
toda a carga de conhecimento que é necessária para realizar essas atividades.
Galera, pode-se notar que o primeiro nível é composto pelos Testes Unitários e
Testes de Integração. Já nos estes de Alto ível, ão é necessário conhecimento
da estrutura interna do oftware. Os testes são guiados pelas especificações de
negócio e pela lista de requisitos do software. O segundo nível é composto pelos

Testes de Validação e Testes de Sistema.
O Teste de Unidade começa no centro da espiral e se concentra em cada unidade

(Ex: componente, classe, objeto, entre outros) do software conforme implementado
no código-fonte. O este prossegue movendo-se em direção ao exterior da espiral,
passando elo este de Integração, que o co s á o rojeto construção a
arquitetura de software.
Continuando na mesma direção da espiral, encontramos o Teste de Validação, em

que requisitos estabelecidos como parte dos requisitos de modelagem são
validados em relação ao software criado. Finalmente, egamos este de
Sistema, o qual oftware e outros mentos são estados omo m odo ão,
em artes separadas.
Para testar um software de computador, percorre-se a espiral em direção ao seu

exterior, no sentido horário, ao longo de linhas que indicam o escopo do teste a
cada volta. Considerando rocesso e um onto e vista procedimental, este
dentro o ontexto e engenharia de software é na realidade uma série de quatro
etapas que são implementadas sequencialmente.
Inicialmente, s estes focalizam ada componente individualmente, arantindo ue

ele funcione adequadamente como uma unidade, daí o ome Teste de Unidade. O
Teste de Unidade usa intensamente técnicas de teste com caminhos específicos na
estrutura de controle de um componente para garantir a cobertura completa e a
máxima detecção de erros.
Em eguida, mponente deve ser ontado u ntegrado ara formar acote

completo de software. O Teste de Integração cuida de problemas associados com
aspectos de verificação e construção do programa, ainda em um ambiente de
desenvolvimento (e, não, produção). Técnicas de projeto de casos de teste que
focalizam em entradas e saídas são mais predominantes durante a integração.
Apesar disso, técnicas que usam caminhos específicos de programa podem ser
utilizadas para segurança dos principais caminhos de controle. Depois ue o
software foi ntegrado construído), executada uma série de testes de ordem
superior (como ostra a imagem a aixo da pirâmide). Os itérios e validação
devem ser aliados.
O Teste de Validação proporciona a garantia final de que o software satisfaz a todos

os requisitos informativos, funcionais, comportamentais e de desempenho. A última
etapa de teste extrapola os limites de engenharia de software, entrando em um
contexto mais amplo de engenharia de sistemas de computadores, combinando
elementos o sistema (por exemplo, hardware, pessoas, base de dados).
O Teste de Sistema verifica se todos os elementos se combinam corretamente e se

a função ou desempenho global do sistema foi conseguida com êxito. Pessoal, essa
é a visão do Pressman! Já Sommerville possui uma visão diferente sobre Estágios de
Teste, ividindo-o este de Componente, este de Sistema e Teste de Aceitação.
Vamos ver isso em detalhes...
De acordo com essa visão, os componentes do sistema são testados, depois é

testado o sistema integrado e, finalmente, o sistema é testado com os dados do
cliente. De aneira ideal, s efeitos e componentes são escobertos o nício do
processo os problemas e interface, quando istema for ntegrado. No entanto,
à medida que os defeitos são descobertos, o programa deve ser depurado.
Isso pode requerer que outros estágios no processo de teste sejam repetidos. Os
erros os omponentes de programa podem parecer urante o este de sistema.
O processo é, portanto, iterativo, com as informações sendo realimentadas dos
estágios posteriores para as partes iniciais do processo. O Processo de Teste (de
Sommerville) é apresentado na imagem a seguir.
Validação. Para tal, stem os estes Alfa e Testes Beta, ue serão istos ora com
mais detalhes.
É praticamente impossível para um desenvolvedor de software prever como o

cliente usará um programa. As instruções de uso podem ser mal interpretadas,
combinações estranhas de dados podem ser usadas regularmente; resultados que
pareciam ros ara o estador odem er nfusos ara um suário o ampo e
utilização. Entendido?
Quando é construído m software personalizado para um c ente, são feitos estes

de Aceitação ara permitir o iente validar odos s equisitos decidir se ele é
bom suficiente para ser mplantado. Conduzido pelo usuário final e não por
engenheiros de software, um Teste de Aceitação pode variar de um informal Test
Driver até uma série de testes planejados e sistematicamente executados.
Em geral, existem três estratégias de implementação de Testes de Aceitação: Teste

de Aceitação ormal um processo tamente gerenciado costuma ser ma
extensão o este do istema, sendo lanejados projetados om esmo ível
de detalhe. Os casos de teste escolhidos devem ser um subconjunto dos que foram
realizados no teste do sistema e o teste geralmente é totalmente automatizado.
Teste de Aceitação, em geral, podem ser executados por um período de semanas

ou meses, descobrindo sim ros c mulativos ue poderiam degradar o istema
ao ongo o empo. Se um software é desenvolvido como um produto para ser
usado por muitos clientes, é impraticável executar Testes de Aceitação Formais para
cada cliente. Aí que entram os Testes de Aceitação Informais...
Um Teste de Aceitação Informal (alguns chamam de Teste Alfa) é um conjunto de

procedimentos em que são identificadas e documentadas diversas funções e tarefas
de negócio, mas não se exigem casos de teste específicos para serem seguidos – o
testador individual determina o que fazer. O este de Aceitação formal realizado
com mais frequência pela organização o usuário final.
Nossa terceira estratégia são os Testes Beta! Eles são os menos controlados das três
estratégias. Esse tipo de teste, a quantidade de detalhes, os dados e a abordagem
adotada são de inteira responsabilidade do testador individual. Ele é implementado
por suários nais, eralmente com ouco ou enhum gerenciamento por parte da
organização de desenvolvimento
Essas ratégias ão esignadas elo UP e caem rova). No entanto, o

conceito mais aceito na bibliografia diverge em um ponto específico: Teste Alfa e
Beta são executados pelos usuários finais. A diferença é que o Teste Alfa ocorre em
ambiente controlado e o Teste Beta em ambiente não controlado. Então, lembrem-
se desse detalhe na hora de resolver questões de prova.
Muitos construtores de software usam um processo chamado de Teste Alfa e Teste

Beta para descobrir erros que somente o usuário final parece ser capaz de
encontrar. O Teste Alfa é conduzido no ambiente do desenvolvedor por um grupo
representativo de usuários finais. O software é usado em um cenário natural com o
d d d s” d .
Dessa forma, ele registra os erros e os problemas de uso. Os Testes Alfa são
conduzidos em um ambiente controlado. Já o Teste Beta é conduzido nas
instalações de um ou mais usuários finais. Diferentemente do este Alfa,
desenvolvedor eralmente não á presente. Portanto, o Teste Beta é uma
aplicação “ao vivo” do software em um ambiente que não pode ser controlado.
O cliente registra todos os problemas (reais ou imaginários) encontrados durante o

Teste Beta elata esses problemas ara o esenvolvedor ntervalos egulares.
Como resultado dos problemas relatados durante o Teste Beta, os engenheiros de
software fazem modificações e então preparam a liberação do software para todos
os clientes.
Galera, uma dica! Quando udava para concursos, u inha grande dificuldade
de memorizar qual ra o este Alfa e o Beta. Como eu fiz para memorizar? Bem, eu
me lembrava dos aplicativos beta que eu instalava no meu computador. Um
exemplo: Firefox Beta! Para quem não sabe, o Navegador Firefox possui várias
versões (entrem no site e vejam vocês mesmos...)
Uma dessas versões é chamada Firefox Beta e ela é disponibilizada antes da versão
final para quem quiser testar e reportar eventuais erros de funcionalidades,
compatibilidade, estabilidade, etc. ercebam: uem esta o oftware é o suário nal
em eu róprio omputador o so, o eu quarto! Então, o Teste Beta é
aquele realizado por você na sua casa (ambiente não-controlado).
Uma variação do este Beta, c amada de Teste de Aceitação do Cliente, s vezes é

executada quando fornecido oftware ersonalizado um liente sob ntrato. O
cliente executa uma série de testes específicos na tentativa de descobrir erros antes
não, rimeiro m m este Alfa e depois om m este Beta; em geral, trata-

se de um teste caixa-preta e se concentra apenas em testes funcionais.
Essa técnica tem o objetivo de verificar a funcionalidade e aderência aos requisitos,

em uma ótica externa ou do usuário, sem e basear qualquer nhecimento do
código ou ógica interna do componente de software. As técnicas principais são:
Testes Baseados em Grafos, Particionamento de Equivalências, Análise de Valor
Limite e Teste de Matriz Ortogonal.
 Baseado Grafos: permite identificar os objetos e gera grafos para representá-

los, testando-os e seus relacionamentos com o intuito de descobrir erros.
 Partição de Equivalência: permite agrupar os valores de entrada em categorias

de dados para evitar redundância e aumentar a cobertura de testes do sistema.
 Análise de Valor imite: permite exercitar os limites do domínio de entrada, tendo

em vista que a maioria dos erros se encontram nas extremidades da entrada.
 Matriz Ortogonal: utilizado com entradas relativamente pequenas, casos de

testes são espalhados uniformemente pelo domínio do teste para detectar falhas.
Por m, este Caixa-Cinza realiza uma mistura entre os estes Caixa-Branca e

Caixa-Preta. Portanto o desenvolvedor dos testes não tem acesso ao código-fonte,
no entanto possui acesso a estruturas de dados e conhecimento dos algoritmos
implementados, assim como pode manipular arquivos de entrada/saída, entre
outros. Alguns autores definem o Teste de Integração como Teste Caixa-Cinza.
c) A automação de um teste de integração é mais facilmente empreendida que

a de um teste de módulo.
d) A produção de scripts de teste deve preceder a eventual construção de casos

de teste.
e) Ao se inspecionar o conteúdo de um plano de testes, devem-se encontrar,

entre outras, as seguintes descrições: escopo de testes, abordagens de teste,
recursos para realização dos testes e cronograma das atividades de teste a serem
realizadas.
Comentários:
O ciclo de vida de testes é composto de cinco fases, como apresenta a imagem abaixo!
Na etapa de lanejamento, laboram-se rojeto estes lano estes,
também é esponsável r azer a análise e iscos s ojetos e estes. Na etapa
de Preparação, organiza-se o ambiente de testes, com infraestrutura adequada e
pessoal capacitado, registrando e controlando as versões do produto.
(a) Conforme vimos em aula, o processo de Planejamento de Testes gera o Plano

de Testes, ele não é descrito por ele.
O processo de teste de software pode produzir diversos artefatos, dois muito

importantes: plano de testes e casos de teste. O imeiro esenta o lanejamento
para execução este, incluindo abrangência, rdagem, ecursos cronograma
das tividades este, tc. Identifica os itens e as funcionalidades a serem testados,
as tarefas realizadas e os riscos associados com a atividade de teste.
(b) Conforme vimos em aula, ele é um planejamento para execução do teste de

software.
(c) Basta raciocinar! Quem é mais difícil de automatizar? Ora, um Teste de Integração
é muito mais complexo que um Teste de Módulo. Logo, a questão não faz sentido!
Na etapa de specificação, laboram-se evisam-se s os este s teiros

(Scripts) este. Na etapa de Execução, preparam-se os dados de testes, executam-
nos, solucionam-se ocorrências, acompanha-se a execução dos casos de teste e
elabora-se um relatório final. Por fim, na Entrega, avalia-se e arquiva-se a
documentação, gerando um relatório final de testes e um de não-conformidade.
Comentários:
Conforme vimos em aula, está perfeito!
Gabarito: C
12. (CESPE 011 C A alista de Sistemas) A etapa de planejamento pode ser

verificada por testes estáticos e ter a documentação do sistema revisada.
Comentários:
Essa questão não faz sentido, na medida em que Testes Estáticos verificam o
código-fonte de um programa, logo não podem ser utilizados na etapa de
Planejamento.
Gabarito: E
13. (CESPE 011 C A alista de Sistemas) Na etapa de especificação, ocorrem

a elaboração e a revisão dos casos de testes.
Dessa forma, ele registra os erros e os problemas de uso. Os Testes Alfa são
conduzidos em um ambiente controlado. Já o Teste Beta é conduzido nas instalações
de um ou mais usuários finais. Diferentemente este lfa, o senvolvedor
geralmente o stá esente. Portanto, o Teste Beta é uma aplicação “ao vivo” do
software em um ambiente que não pode ser controlado.
Conforme vimos em aula, Testes de Unidade são de baixo nível e Testes de Sistema
são executados após os Testes de Integração. No entanto, Testes Beta empregam
em sua maioria usuários e, não, desenvolvedores.
Gabarito: E
17. (CESPE 010 PE/TO alista de istemas) Entre os diversos níveis possíveis
de testes de software, há os chamados testes de unidade (Unit Tests), que
procuram testar o programa como um todo, dentro de um contexto totalmente
integrado, procurando validar todas as suas potencialidades de forma unificada.
Comentários:
Continuando na mesma direção da espiral, encontramos o Teste de Validação, em

que requisitos estabelecidos como parte dos requisitos de modelagem são validados
em relação ao software criado. Finalmente, hegamos Teste istema,
o oftware utros lementos ão estados omo todo , , m partes
separadas.
Conforme vimos em aula, isso é Teste de Sistema e, não, Teste de Unidade.
Gabarito: E
18. (CESPE 010 J/ES alista de Sistemas) No teste de unidade, o software é

forçado a falhar de diversos modos a fim de verificar se os requisitos funcionais
foram adequadamente implementados. As unidades, sejam funções,
procedimentos, métodos ou classes, são testadas duas a duas. Nesse teste,
espera-se identificar erros relacionados a algoritmos incorretos ou mal
implementados, estruturas de dados incorretas ou simples erros de
programação.
Comentários:
Não, a questão trata do Teste Beta.
Gabarito: E
72. (CESPE 004 SESPA/PA - alista de Sistemas) Para efeito de validação de

um software, o beta teste é realizado pelo cliente usuário do software em um
ambiente controlado, normalmente nas instalações do desenvolvedor.
Comentários:
Testes Alfa são feitos em ambiente controlado e Testes Beta são feitos em ambiente
real.
Gabarito: E
73. (CESPE 004 TJ - alista de Sistemas) Um software-produto, antes de ser

lançado no mercado normalmente deve ser testado por usuários reais do
sistema. Nessa etapa, configura-se a realização de beta testes.
Comentários:
Perfeito, é exatamente isso!
Gabarito: C
74. (CESPE 010 TRO A alista de Sistemas) Um teste de recuperação deve

evitar que o sistema apresente falhas que interrompam o seu funcionamento.
Comentários:
Teste algum consegue evitar isso! Ele apenas busca verificar a capacidade de
recuperação de um sistema.
Gabarito: E
75. (CESPE 004 TJ - alista de Sistemas) O teste de compatibilidade serve

para verificar se um software pode ser executado no sistema operacional Solaris.
Comentários:
I. Uma estratégia de teste que é escolhida por grande parte das equipes de software
adota uma visão incremental do teste, começando com o teste de unidades
individuais de programa, avançando para testes projetados a fim de facilitar a
integração das unidades e culmina com testes que exercitam o sistema construído.
II. O teste de unidade focaliza o esforço de verificação na menor unidade de projeto

do software - o componente ou módulo de software. Usando a descrição de projeto
no nível de componente como guia, caminhos de controle importantes são testados
para descobrir erros dentro dos limites do módulo.
III. O teste de unidade é normalmente considerado um apêndice ao passo de

codificação. O projeto de teste de unidade pode ser realizado antes que o código
seja iniciado ou depois de o código-fonte ter sido gerado.
IV. O teste de integração é uma técnica sistemática para construir a arquitetura do

software enquanto, ao mesmo tempo, conduz testes para descobrir erros
associados às interfaces. O objetivo é, a partir de componentes testados no nível de
unidade, construir uma estrutura de programa determinada pelo projeto.
Está correto o que se afirma em:
a) I, II, III e IV.

b) I, II e IV, apenas.
c) II, III e IV, apenas.
d) III e IV, apenas.
e) I e III, apenas.
Comentários:
(I) Conforme vimos em aula, a questão está correta – apesar de não citar os Testes
de Aceitação.
Esse este ocaliza o sforço verificação menor dade ojeto o oftware

omponente u módulo oftware. Usando como guia a descrição de projeto
no nível de componente, caminhos de controle importantes são testados para
III. O teste de unidade enfoca a lógica interna de processamento e as estruturas

de dados dentro dos limites de um componente.
IV. No teste de unidade, a interface do módulo é testada para garantir que a

informação flui adequadamente para dentro e para fora da unidade de
programa que está sendo testada.
Está correto o que consta em:
a) I, II, III e IV.

b) I e II, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, III e IV, apenas.
Comentários:
(I) Conforme vimos em aula, a questão está correta – apesar de não citar os Testes
de Aceitação.
Esse este ocaliza o sforço erificação menor dade rojeto o oftware

omponente u módulo oftware. Usando como guia a descrição de projeto
no nível de componente, caminhos de controle importantes são testados para
descobrir erros dentro dos limites do módulo. A complexidade relativa dos testes e os
erros que revelam são limitados pelo escopo restrito estabelecido para esse teste.
(II) Conforme vimos em aula, é na menor unidade de projeto!
Ele nfoca lógica interna de ocessamento a struturas a s ntro s

limites e componente. Esse tipo de teste pode ser conduzido em paralelo para
diversos componentes. A interface de um módulo é testada para assegurar que as
informações fluam corretamente para dentro a para fora da unidade de programa
que está sendo testada.
(III) Conforme vimos em aula, é exatamente isso!
partir do módulo de controle principal e os testes sejam conduzidos à medida

que cada componente é inserido.
O Auditor indicou em I e II, respectivamente, os testes de:
a) caixa branca e de caixa preta, que são suficientes para validar todo o sistema.
b) unidade e de integração; na sequência, indicou os testes de validação e de

sistema que são adequados para validar todo o sistema.
c) unidade e de interoperabilidade; na sequência, indicou os testes de caixa

branca e de caixa preta que são adequados para validar todo o sistema.
d) carga e de desempenho; na sequência, indicou os testes de usabilidade e

interoperabilidade que são adequados para validar todo o sistema.
e) caixa preta e de caixa branca, que são suficientes para validar todo o sistema.
Comentários:
Ele enfoca a lógica interna de processamento e as estruturas de dados dentro dos

limites de um componente. Esse ipo este de er onduzido m paralelo a
diversos omponentes. A interface de um módulo é testada para assegurar que as
informações fluam corretamente para dentro a para fora da unidade de programa
que está sendo testada.
Teste de Integração é uma técnica sistemática para construir a arquitetura de

software ao mesmo tempo que conduz testes para descobrir erros associados com
as interfaces. O objetivo é construir uma estrutura de programa determinada pelo
projeto a partir de componentes testados em unidade. Muitas ezes, á uma
tendência de tentar ntegração não ncremental.
Conforme vimos em aula, o primeiro é o Teste de Unidade e o segundo é o Teste

de Integração. Além disso, os testes de validação e sistema são realmente
adequados para validar todo sistema.
Gabarito: B
a) Conformidade de um sistema com os requisitos levantados no início do

processo de desenvolvimento.
b) Tempo de vida útil de um sistema e sua efetiva utilidade e aplicação.
c) É medida pelo máximo de tempo de uso entre falhas ocorridas (MTBF) no ciclo
de vida do software.
d) Desempenho medido pelo tempo de resposta no processamento e

apresentação das informações.
e) Equilíbrio entre o prazo de entrega do sistema e o atendimento mínimo dos

requisitos levantados.
c) o objetivo de todo teste é verificar se ele atende apenas aos requisitos

funcionais.
d) verificação e validação não são a mesma coisa em relação a testes de sistema.
e) os testes podem demonstrar que um determinado software está livre de

defeitos.
aumenta progressivamente a carga até que se possa definir se o desempenho

do sistema está aceitável.
LISTA DE EXERCÍCIOS COMENTADOS (FCC)

TESTES DE SOFTWARE
b) do projeto do software.
c) dos códigos do programa.
d) dos requisitos funcionais.
e) dos requisitos não funcionais.
11. (FCC 010 RT 0ª GIÃO SE) alista Judiciário ecnologia da

Informação) No contexto da estratégia para o teste de um projeto, os estágios
de teste desempenham um papel importante. O teste que é aplicado a
componentes do modelo de implementação para verificar se os fluxos de
controle e de dados estão cobertos e funcionam conforme o esperado, é o teste:
a) do desenvolvedor.
b) independente.
c) de integração.
d) de sistema.
e) unitário.
12. (FCC 009 EFAZ-SP gente Fiscal de Rendas ecnologia a Informação

- Prova 3) Garantir que um ou mais componentes de um sistema combinados
funcionam corretamente é o objetivo do tipo de teste:
a) de sistema.
b) de integração.
c) de configuração.
d) operacional.
e) funcional.
13. (FCC 008 RT ª ião GO) A alista Judiciário ecnologia da

Informação) Uma sistemática para construção da arquitetura do software
enquanto, ao mesmo tempo, conduz ao descobrimento de erros associados às
interfaces é a estratégia de teste de software denominada de:
a) sistema.
b) unidade.
c) validação.
d) arquitetura.
e) integração.
b) mais de um tipo de teste, pois não há um único tipo de teste capaz de avaliar
todas estas situações.
c) um tipo diferente de teste para cada uma das situações elencadas.
d) testes de caixa preta.
e) testes de desempenho para os 2 primeiros e de carga para os demais.
GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

QUALIDADE DE SOFTWARE

Qualidade e Teste de Software 2

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Qualidade e Teste de Software 2

Încărcat de

Drepturi de autor:

Formate disponibile

www.concurseirosunidos.

A qualidade de software tem e aprimorado ignificativamente nos ltimos 15 anos.

Entretanto, qualidade de software é um nceito mplexo ue não diretamente

Algumas pessoas acham que a qualidade pode ser conseguida definindo-se

Na prática, entretanto, acredito que há muito mais gerenciamento de qualidade do

1. Garantia de qualidade: estabelecimento de um framework de procedimentos

2. Planejamento de qualidade: seleção de procedimentos e padrões apropriados

3. Controle de qualidade: definição e aprovação de processos que assegurem que

Uma característica inerente ou diferenciada; uma propriedade. b. Um traço

A qualidade não é um atributo u uma característica singular. É multidimensional e

Qualidade é a característica de ter demonstrado a realização da criação de um

Obter ualidade não só "atender requisitos" u roduzir m roduto ue atende

Vamos ver agora algumas características de qualidade:

 Interoperabilidade: capacidade do produto de software de interagir com um

 Conformidade: a capacidade do produto de software de estar de acordo com

 Tolerância a Falhas: capacidade de um produto de software de manter um

(FCC 014 RT/1 alista de Sistemas) A qualidade de software constitui-se

a) mede-se, exclusivamente, a qualidade da documentação produzida para o

b) verifica-se a satisfação de requisitos estabelecidos, incluindo o desempenho.

c) não se abrange questões relativas à interface do software.

d) não há preocupação com a facilidade de manutenção do software.

e) não se inclui a confiabilidade esperada do software.

(a) Apenas a documentação? Não, inclusive a documentação – mas mede-se

(b) Perfeito, verifica se os requisitos estabelecidos forem satisfeitos pelo software

(d) Há preocupação, sim! Facilidade de manutenção de software é um requisito não-

ERIFICAÇÃO & VALIDAÇÃO

Em seu livro, Pressman diz:

Durante e depois do processo de implementação, o programa em

Percebam que Validação Verificação ão oisas iferentes! E qual a diferença? Ora,

 Verificação: Estamos construindo o produto corretamente?

A Verificação ocorre em ambiente de desenvolvimento e envolve a certificação de

Eu peço a vocês! Não, a verdade eu mploro ue vocês emorizem diferença

Há dois ipos de Verificação: stática e Dinâmica! A Estática (também chamada

Já a Verificação Dinâmica (também chamada de Teste1) envolve executar o software/

localiza e conserta esses defeitos e geralmente é feita por uma equipe de

O este de Software é o rocesso e tar m oftware com ois bjetivos

Os estes de software não odem demonstrar que um software é livre de defeitos

A meta é convencer s esenvolvedores e clientes do sistema de que o oftware é

O que é um Teste de Software? Como é possível de prever, há diversas definições

O Glossário International Software Testing Qualifications Board (ISTQB) conceitua

- stabilidade: grosso modo, podemos dizer que “quanto menos modificações,

- ompreensibilidade: grosso modo, podemos dizer que “quanto mais

Na etapa de Preparação, organiza-se o ambiente de testes, com infraestrutura

Na etapa e Especificação, boram-se e revisam-se os asos de Teste e os

executar os testes no sistema completo esperando encontrar os erros. Essa

A imagem ma mostra que a espiral e nicia entido orário pelo Teste de

negócio e pela lista de requisitos do software. O segundo nível é composto pelos

O Teste de Unidade começa no centro da espiral e se concentra em cada unidade

Continuando na mesma direção da espiral, encontramos o Teste de Validação, em

Para testar um software de computador, percorre-se a espiral em direção ao seu

Inicialmente, s estes focalizam ada componente individualmente, arantindo ue

Em eguida, mponente deve ser ontado u ntegrado ara formar acote

O Teste de Validação proporciona a garantia final de que o software satisfaz a todos

O Teste de Sistema verifica se todos os elementos se combinam corretamente e se

De acordo com essa visão, os componentes do sistema são testados, depois é

É praticamente impossível para um desenvolvedor de software prever como o

Quando é construído m software personalizado para um c ente, são feitos estes

Em geral, existem três estratégias de implementação de Testes de Aceitação: Teste

Teste de Aceitação, em geral, podem ser executados por um período de semanas

Um Teste de Aceitação Informal (alguns chamam de Teste Alfa) é um conjunto de

Essas ratégias ão esignadas elo UP e caem rova). No entanto, o

Muitos construtores de software usam um processo chamado de Teste Alfa e Teste

O cliente registra todos os problemas (reais ou imaginários) encontrados durante o