Testes Software curso técnico em informatica

8/16/2019 Testes Software curso técnico em informatica

1/62


2/62

Curso Técnico em Informáca

Testes de Software


3/62

Robson Braga de AndradePresidente da Confederação Nacional da Indústria

Rafael LucchesiDiretor do Departamento Nacional do SENAI

Regina Maria de Fáma TorresDiretora de Operações do Departamento Nacional do SENAI

Alcantaro Corrêa

Presidente da Federação da Indústria do Estado de Santa Catarina

Sérgio Roberto ArrudaDiretor Regional do SENAI/SC

Antônio José CarradoreDiretor de Educação e Tecnologia do SENAI/SC

Marco Antônio DociaDiretor de Desenvolvimento Organizacional do SENAI/SC


4/62

Confederação Nacional da Indústria

Serviço Nacional de Aprendizagem Industrial

Curso Técnico em Informáca

Testes de Software

Carlos Eduardo Carvalho

Florianópolis/SC2011


5/62

É proibida a reprodução total ou parcial deste material por qualquer meio ou sistema sem o prévio consenmentodo editor.

Autor

Carlos Eduardo CarvalhoFotograas

Banco de Imagens SENAI/SChp://www.sxc.hu/hp://oce.microso.com/en-us/ images/hp://www.morguele.com/hp://www.bancodemidia.cni.org.br/

Ficha catalográfica elaborada por Luciana Effting CRB14/937 - Biblioteca do SENAI/SC Florianópolis

C331t

Carvalho, Carlos Eduardo

Teste de software / Carlos Eduardo Carvalho. – Florianópolis :

SENAI/SC/DR, 2011.

59 p. : il. color ; 30 cm.

Inclui bibliografias.

1. Software. 2. Software - Controle de qualidade. 3. Software - Testes. 4.

Engenharia de software. I. SENAI. Departamento Regional de Santa

Catarina. II. Título.

CDU

004.415.53

SENAI/SC — Serviço Nacional de Aprendizagem IndustrialRodovia Admar Gonzaga, 2.765 – Itacorubi – Florianópolis/SCCEP: 88034-001Fone: (48) 0800 48 12 12

www.sc.senai.br


6/62

Prefácio

Você faz parte da maior instituição de educação prossional do estado.Uma rede de Educação e Tecnologia, formada por 35 unidades conecta-das e estrategicamente instaladas em todas as regiões de Santa Catarina.

No SENAI, o conhecimento a mais é realidade. A proximidade com asnecessidades da indústria, a infraestrutura de primeira linha e as aulasteóricas, e realmente práticas, são a essência de um modelo de Educaçãopor Competências que possibilita ao aluno adquirir conhecimentos, de-senvolver habilidade e garantir seu espaço no mercado de trabalho.

Com acesso livre a uma eciente estrutura laboratorial, com o que existe

de mais moderno no mundo da tecnologia, você está construindo o seufuturo prossional em uma instituição que, desde 1954, se preocupa emoferecer um modelo de educação atual e de qualidade.

Estruturado com o objetivo de atualizar constantemente os métodos deensino-aprendizagem da instituição, o Programa Educação em Movi-mento promove a discussão, a revisão e o aprimoramento dos processosde educação do SENAI. Buscando manter o alinhamento com as neces-sidades do mercado, ampliar as possibilidades do processo educacional,oferecer recursos didáticos de excelência e consolidar o modelo de Edu-cação por Competências, em todos os seus cursos.

É nesse contexto que este livro foi produzido e chega às suas mãos. Todos os materiais didáticos do SENAI Santa Catarina são produçõescolaborativas dos professores mais qualicados e experientes, e contamcom ambiente virtual, mini-aulas e apresentações, muitas com anima-ções, tornando a aula mais interativa e atraente.

Mais de 1,6 milhões de alunos já escolheram o SENAI. Você faz partedeste universo. Seja bem-vindo e aproveite por completo a Indústriado Conhecimento.


7/62


8/62

Sumário

Conteúdo Formavo 9

Apresentação 11

12 Unidade de estudo 1

O que é o teste desoware?

Seção 1 - Metodologiade desenvolvimento desoware

Seção 2 - Objevos do testede soware

Seção 3 - O que é teste desoware?

Seção 4 - E se não testar osoware?

Seção 5 - Casos de testes

Seção 6 - Tipos de testes


Técnicas de teste desoware

Seção 1 - O que é técnica deteste?

Seção 2 - Técnicas funcional,

estrutural e baseadas emerros

Seção 3 - Critérios para gera-ção de casos de teste

Seção 4 - Níveis de teste

13

13

14

15

16

16


Processo de teste desoware

Seção 1 - Ciclo de vida de de-senvolvimento de soware

Seção 2 - Conceito “V” deteste

Seção 3 - Ciclo de vida doprocesso de teste

Seção 4 - Preparação doambiente


Análise de riscos

Seção 1 - Denição de risco

Seção 2 - Riscos relavos aoteste de soware

Seção 3 - Determinação damagnitude dos riscos

Seção 4 - Controle dos riscos


Planejamento dostestes

Seção 1 - Plano de teste, oque é isso?

Seção 2 - Desenvolvimentodo plano de teste

Seção 3 - Documentação doteste


Execução dostestes

Seção 1 - Contexto dostestes

Seção 2 - Processo de execu-ção dos testes

Seção 3 - Relatório de testesegunda a IEEE 829

Seção 4 - Gerenciamento decomunicação do projeto deteste


Teste de aceitação

Seção 1 - Denição dos crité-

rios de aceitaçãoSeção 2 - Elaboração doplano de aceitação

Seção 3 - Execução do testede aceitação


Esmavas

Seção 1 - Análise do pontode teste

Seção 2 - Esmava baseadano tamanho e complexidadedo caso de uso

Finalizando 57

Referências 59

21

21

21

24

27

28

28

29

33

33

33

34

37

37

39

41

42

45

46

49

49

50

53

54


9/62

8 CURSOS TÉCNICOS SENAI


10/62

Conteúdo Formativo

9TESTES DE SOFTWARE

Carga horária da dedicação

Carga horária: 30 horas

Competências

Aplicar testes relacionados ao desenvolvimento de soware para validação dasolução computacional.

Analisar os resultados de testes realizados em sistemas computacionais.

Conhecimentos

▪ Diário de teste;

▪ Especicação de teste;

▪ Especicação e relato de teste;

▪ Especicações de caso de teste;

▪ Especicações de procedimento de teste;

▪ Especicações de projeto de teste;▪ Ferramenta de teste;

▪ Metodologia de desenvolvimento de programa de computador;

▪ Metodologia de teste;

▪ Normas técnicas vigentes;

▪ Procedimento de teste;

▪ Registro de teste;

▪ Relato de teste;

▪

Relatório de encaminhamento de item de teste;▪ Relatório de incidente de teste;

▪ Relatório-resumo de teste;

▪ Requisitos de ambiente;

▪ Técnicas de teste.

Habilidades

▪ Idencar os pos de teste a serem executados no procedimento;

▪ Ulizar o plano de testes;

▪ Interpretar as especicações de teste;


11/62

▪ Testar os programas;

▪ Elaborar registros de teste;

▪ Idencar defeitos e falhas em programas de computador;

▪ Ulizar artefatos de manutenção;

▪ Elaborar registros na documentação da manutenção de programas de computa-dor.

Atudes

▪ Organização e zelo na ulização de equipamentos;

▪ Foco no conteúdo trabalhado;

▪ Acesso a síos relacionados ao tema trabalhado;

▪ Organização e limpeza dos ambientes colevos;

▪ Dedicação e empenho nas avidades curriculares e extra-curriculares;

▪ Capacidade de abstração;

▪ Trabalho em equipe;

▪ Apresentação de novas soluções para situações problemas;

▪ Cumprimento de prazos;

▪ Análise críca da solução proposta.


12/62

Apresentação

TESTES DE SOFTWARE

Caro aluno,

imagine a seguinte situação...

É início do mês, você recebeu o seu merecido salário e agora vai fazer opagamento de uma conta por meio do site do banco. Você precisa trans-ferir R$ 100,00 para poder efetuar este pagamento. Mas, como muitaspessoas estão fazendo a mesma coisa que você, o sistema do banco dáaquela “travada”. Quinze segundos depois o sistema volta e a sua tran-sação foi efetuada. No dia seguinte, você vê o seu saldo e percebe queforam debitados R$ 200,00 da sua conta! E agora? O que aconteceu como sistema? Ele estava preparado para fazer todas aquelas transações aomesmo tempo? Ele foi testado para vericar se havia problemas caso osistema travasse?

Esse material didático foi elaborado pensando nestas questões, que de- verão ser reetidas por você, como um técnico em informática, respon-sável por sistemas de banco, de hospitais, de pequenos supermercados ede grandes empresas. Neste livro você vai encontrar os diversos tipos etécnicas para se testar um software de modo a garantir que ele funciona-rá corretamente nos momentos mais difíceis. Também verá que certossistemas não precisam ser testados nos mínimos detalhes. Eles serãotestados apenas até o ponto onde os custos do teste não são maiores doque a correção. Além de aprender que é mais barato testar no começodo desenvolvimento do que corrigir no nal.

O estudo e pesquisas realizadas para elaborar este material didático fo-ram demorados e detalhados, mas valeu a pena, pois certamente vocêencontrará ao longo da leitura deste livro respostas para muitas pergun-tas como as que você leu no início desta apresentação e muitas outrasque surgirão ao longo de sua carreira prossional. Então, espero que

você consiga aproveitar o material para se desenvolver prossionalmen-te e pessoalmente.

É importante considerar que sempre haverão coisas novas para aprendere você pode pesquisar muito mais e aprender a partir dos livros e blogs que foram utilizados para preparação deste material. Perceba que muitagente está estudando, discutindo, e aprendendo e inovando sobre teste

de software todos os dias. Por m, espero que, daqui a alguns anos, quan-do você estiver trabalhando em uma grande empresa de desenvolvimen-to e precisar elaborar um processo de teste, lembre-se desse materiale utilize,o como um ponto de partida para atingir o sucesso nos seustrabalhos.

Bons estudos!

Carlos Eduardo Carvalho

Formado em Engenharia Elé-trica pela Udesc – Joinville.Atuou em desenvolvimentode soware e hardware paraequipamentos eletrônicos, emusinas hidroelétricas. Lecionaas disciplinas de lógica de pro-gramação, microcontroladores,acionamentos elétricos e proje-tos elétricos nos cursos técnicosde automação, mecatrônica e

eletrotécnica. Atua em STT, de-senvolvendo programas paramicrocontroladores aplicadosem equipamentos eletrônicos.

11


13/62

Unidade deestudo 1

Seções de estudo

Seção 1 – Metodologia de desenvolvimen-

to de sofware

Seção 2 – Objevos do teste de sofware

Seção 3 – O que é teste de sofware?

Seção 4 – E se não testar o sofware?

Seção 5 – Casos de testes

Seção 6 – Tipos de testes


14/62

13TESTES DE SOFTWARE

O que é teste de software?

SEÇÃO 1Metodologia de desenvolvimento de soware

Você sabia que utilizar uma metodologia para desenvolver um software éo primeiro passo de uma prática prossional?

É isso mesmo! Conra a seguir um formato básico de metodologia paraelaboração de um software , de acordo com Bartié (2002, p. 25).

Figura 1: Ciclo de desenvolvimento de soware

Fonte: Baré (2002, p. 25)

Perceba que o item teste é apenas uma parte da metodologia e aparecesomente no nal do projeto.

Por isso, o objevo desta seção de estudo é mostrar à você que asprácas de teste devem iniciar juntamente com o início do projeto, nomomento em que as primeiras documentações são geradas. Assim,os erros e problemas não são transferidos para as próximas fases, ok?

Quando a cultura da aplicação da metodologia estiver bem entendida edifundida, você verá que os processos e métodos de teste permitirão aqualidade dos produtos. Neste momento é importante fazer referênciaao PMI ( Project Management Institute ) que fez o PMBOK ( Project Manage- ment Body of Knowledge ), no qual o processo de gerenciamento da qualida-de de software é subdividido em três partes complementares, acompanhe!

Processo de Garantia da Qualida-de do Software :

1. Planejamento da Qualidade.

2. Garantia da Qualidade.

3. Controle da Qualidade.

Neste momento você deve estar

se perguntando: mas porque devotestar um software ? Qual o objeti-

vo deste teste? Não seria perda detempo, já que na maioria das ve-zes o tempo de desenvolvimentode um software é curto?

É sobre este assunto que conver-saremos na próxima seção de es-

tudo. Vamos em frente!

SEÇÃO 2Objevos do teste desoware

De forma bem básica, o objevo do

teste de soware é simplesmente

garanr a qualidade do soware.

Para Bartié (2002) o processo dequalidade de software está decom-posto em fases e cada fase possui

uma numeração que indica a se-quência de execução dos testes aserem aplicados.

Assim, deve-se dividir os testesem duas categorias: testes de ve-ricação e testes de validação.

Os testes de vericação visamgarantir a correta elaboração do

software e os testes de validaçãoestão focados na garantia da qua-lidade do software .


15/62


Para que você possa vericar asatividades e avaliar os documen-tos gerados durante as fases doprocesso de engenharia de software , deve utilizar os testes de veri-

cação. As fases da metodologia que fa-zem parte dos testes de verica-ção são:

▪ Modelo de Negócios: veri-cação de negócios;

▪ Especicação de Requisi-

tos: vericação de requisitos;

▪ Análise e Modelagem: veri-cação, análise e modelagem;

▪ Implementação: vericaçãoda implementação.

Desta forma, deni-se testes de validação como:

[...] um processo formal de ava-liação de produtos tecnológicosque podem ser aplicados emcomponentes isolados, módulosexistentes ou mesmo nos siste-

mas como um todo. Seu obje-vo é avaliar a conformidade dosoware com os requisitos eespecicações analisadas e revi-sadas nas etapas iniciais do projeto (BARTIÉ, 2002, p. 38).

Ou seja, os testes de validação sãoaqueles feitos quando já existealguma parte do software pronta.São os testes feitos no software e

não na documentação. Nos testesde validação, temos as seguintesfases:

▪ Unidade Especicada ou

Modicada: validação da uni-dade;

▪ Integração Especicada

ou Modicada: validação daintegração;

▪ Sistema Especicado ou

Modicado: validação do siste-ma;

▪ Disponibilização de Solu-

ção: validação do aceite.Lembre--se de que o conhecimento seadquire por meio de uma cons-trução signicativa da aprendiza-

gem. Então, vamos juntos trilharnovos caminhos do conhecimen-to?

SEÇÃO 3O que é teste desoware?

Existem atualmente, duas deni-ções para teste.

Você sabe quais são? Vamos verjuntos.

A denição mais comum, que amaioria das equipes de desenvol-

vimento aplica está simplicadacomo:

▪ Teste é o processo de de-monstrar que algo funcionacorretamente.

▪ Teste é o processo de pro-var que determinadas coisasfazem o que deveriam fazer.

Ou seja, todo mundo vê os tes-tes como uma forma de mostrar

que está tudo bem. Na verdade, émais fácil mostrar que um software está funcionando do que mostrar

que ele não está funcionando.Mas, ao colocar uma pessoa quenão está envolvida no desenvolvi-mento do software e que não temnenhuma ligação com este, estapessoa criará diversas situações,possíveis no dia-a-dia do produto,e conseguirá demonstrar que emdeterminados cenários, o com-portamento deste produto pode

gerar um funcionamento inade-

quado.Neste ponto, é possível chegar àsegunda denição de teste:

▪ Teste é um processo siste-máco e planejado que tempor nalidade única a iden-cação de erros.

Esta é considerada a deniçãocorreta sobre os testes. Inde-pendentemente do teste ser apli-cado a um documento ou a um

software , o objetivo é criar situa-ções onde o produto pode nãofuncionar.

Porém, é preciso sempre lembrarque você não conseguirá mostrara ausência de erros. Ou seja, pormelhor que seja um processo dequalidade, nunca será possívelcobrir todas as innitas combina-ções existentes em um ambientede execução real. Pense semprenisso!

Vamos em frente? Na próximaseção você vericar o que podeacontecer quando um software nãoé testado.


16/62


SEÇÃO 4E se não testar osoware?

Erros, falhas, incidentes, não con-formidades e inconsistências são

palavras que representam nature-zas diferentes de defeitos. Apesarde ser um pensamento comum,esses defeitos não vêm apenas

no código – fonte do produto. Etambém não são apenas os pro-ssionais de desenvolvimento,qualidade e testes, os responsáveispor um software sem defeitos.

Os erros são resultados donão entendimento dos re-quisitos do cliente e especi-cações mal feitas. Portan-to, você deve trabalhar maistempo nas especicações emodelagem da solução. Issofará com que muitos erros sejam eliminados por meio deum levantamento bem feito.

A falta de testes em todas as etapasdo processo de desenvolvimentofará com que os erros passem deuma fase para a outra. Quandoo ciclo atingir a fase especíca detestes, muitos erros serão encon-trados e mesmo assim o produto

pode não atingir o esperado.

Você sabia que esse processo dequalidade de software , do qual ostestes fazem parte, traz diversas

vantagens para a organização?

Sim, isso mesmo! Ealgumas des-sas vantagens são:

▪ os testes tornam o ciclo dedesenvolvimento conável;

▪ garantem ações corretivasdurante o desenvolvimento

▪ ampliam as chances de sucesso do projeto de software e,

▪ evitam a propagação de erros.Interessante, não é mesmo? Bastos et al (2007) cita a regra 10 de Myers,que estabelece que o custo de correção de um erro aumenta muito como passar do tempo.

DICA

Quanto mais tempo demorar para se descobrir um erro, mais caroserá a solução deste erro. Defeitos encontrados na documentaçãode modelamento são muito mais baratos do que defeitos encontra-dos durante a produção. Portanto que atento!

Conra na imagem a seguir um gráco que apresenta um aumento do

custo durante as fases do projeto.

Figura 2: Custo da correção dos defeitos.

Finalizando esta seção, você pode ver que os testes são extremamenteimportantes no alcance da qualidade do software . Não testar ou fazertestes da forma errada pode trazer custos extremamente altos para aempresa.

DICA

E para alcançar a qualidade desejada pelo cliente, muitas vezes énecessário possuir uma equipe de testes, trabalhando em conjuntocom o desenvolvimento, desde a primeira reunião.

Apesar de gerar um custo inicial, após o treinamento e mudança de lo-soa da empresa, os ganhos serão muito maiores.

Que tal passar para a próxima seção e conhecer alguns casos de teste?Siga em frente!


17/62


SEÇÃO 5Casos de testes

De acordo com Bastos et al (2007,

p. 153) um caso de teste é a espe-cicação mais detalhada do teste,apresentando os campos de telas,formulários etc. O caso de testeestabelece as informações empre-gadas nos testes dos cenários equais são os resultados esperados.

Ou seja, é necessário fazer um de-talhamento do que será testado,como será feito o teste, quem éresponsável, quais são as entradas

necessárias e quais são as saídasesperadas.

Um bom caso de teste deve con-ter:

▪ identicação das condições deteste;

▪ o que testar (identicação doscasos);

▪ detalhamento da massa deentrada e de saída (dados);

▪ critérios especiais, quandonecessários, para gerar os dadosde entrada e saída do teste;

▪ especicação das congura-ções de ambiente no qual o testeserá executado: sistema operacio-nal, ferramentas necessárias, ori-gem dos dados etc (onde testar);

▪ como testar: automático/ma-nual (denir o tipo de implemen-

tação do teste); ▪ quando testar (cronograma,

em qual fase o teste será execu-tado);

▪ listar as interdependências,caso existam, entre os casos deteste.O quadro a seguir é um exemplode caso de teste aplicado a um sis-tema de uma imobiliária. Veja!

Caso de teste Portal de Administração de Sites – Imóveis Carvalho

Caso de testeCT 85 – Buscar para alteração. Botão visualizar ocalendário de locação.

Pré-condiçõesTer clicado em “Buscar para alteração” na páginade imóveis e estar com a opção de locação para atemporada.

Procedimentos

1. O ator clica em “Visualizar o calendário delocação do imóvel”representado pelo terceiroícone da esquerda para a direita na partesuperior da descrição do imóvel.

2. O sistema carrega um calendário destacandoos dias de locação do imóvel.

Resultado

esperadoCarregar o calendário de locação do imóvel.

Critériosespeciais

Não se aplica.

Implementação Manual.

Iteração 1ª iteração.

Quadro 1: Exemplo de caso de teste

Neste exemplo você pode ver que os casos de teste são bem detalhadose devem ser descritos de uma forma criteriosa. Todos os cenários e

casos de uso devem ser criados, vericando todas as funcionalidades dosoftware . Por isso eles dão bastante trabalho para a pessoa responsávelpela sua elaboração.

Preparado para seguir mais um percurso? Conheça na próxima seção ostipos de teste.

SEÇÃO 6Tipos de testes

No momento em que você começar a fazer os testes de validação, signi-ca que já tem um produto computacional, ou seja, um software que podeser executado.

Para fazer esta validação você pode utilizar duas abordagens:

▪ a estratégia da caixa branca ou,

▪ a estratégia da caixa preta.

Figura 3: Estratégias fundamentais dos testes.


18/62


Estas estratégias não excluem uma a outra. Na verdade, se você aplicaras duas, terá um produto com uma qualidade maior. Os testes de caixabranca são baseados na estrutura interna do software . Ou seja, é precisoempregar técnicas que trabalhem todas as estruturas utilizadas na codi-cação.

Os testes de caixa branca possuem alta eciência na detecção de erros,mas também costumam ser difíceis de implementar.

Para isso é necessário que o prossional de testes conheça a tecnolo-gia usada no soware. Assim como, tenha acesso a fontes, estruturasdos bancos de dados etc.

Conra a seguir a imagem que representa um teste de caixa branca.

Figura 4: Teste de caixa branca.

Você pôde observar na imagem anterior que o teste de caixa brancamostra um software que tem um processamento inicial, representado peloretângulo 1, uma tomada de decisão, representada pelo losango 2. Apartir desta decisão, o software pode passar por dois caminhos, o caminho

A ou o caminho B.

Importante: o soware nunca vai passar pelos dois caminhos ao mesmo

tempo.

Independente do caminho percorrido, o software chega ao processamen-to nal, retângulo 3. Após este processamento, o software é nalizado.

Perceba que para fazer este teste, é importante que o prossionalconheça o que cada processamento faz e que resultado cada tomadade decisão deverá dar.

Neste momento você deve estar se perguntando: mas e a caixa preta,qual a sua função?


19/62


O teste de caixa preta não tem o objetivo de vericar como ocorreminternamente os processamentos, mas se o algoritmo utilizado produzos resultados necessários. A vantagem desta estratégia é que não é ne-cessário conhecer os conceitos de implementação aplicados no software .Dessa forma é muito mais fácil encontrar um prossional capacitado a

modelar os testes de caixa preta da aplicação. Veja a seguir a imagem que representa um teste de caixa preta.

Figura 5: Teste de caixa preta.

Esta estratégia é muito encontrada nas organizações, em forma de testesmanuais executados por prossionais ou usuários.

Ao estudar os testes de software , é possível perceber que existem diversostipos de teste que devem ser feitos nos softwares . Muitas vezes, você nãoterá tempo para fazer todos os testes e criar todos os cenários. Assim,é importante conhecer os tipos e priorizar aqueles que podem encontrar

erros mais preocupantes.Bartié (2002) cita alguns testes que devem ser feitos:

1. Teste de funcionalidade: tem por objetivo simular os cenários denegócio e garantir que todos os requisitos funcionais sejam imple-mentados.

2. Teste de usabilidade: a ideia desse teste é medir o nível de facilida-de da aplicação, de modo a deixar o software mais simples e intuitivo.

Também é possível avaliar se o software avisa sobre ações que podemdanicar ou perder dados pertencentes ao usuário.

Por exemplo, botão “desfazer alteração” e “cancelar operação”, além damensagem “Esta operação excluirá seu histórico. Deseja connuar?”

3. Teste de volume: tem por objetivo determinar os limites de proces-samento do software e de toda a infra-estrutura da solução. Esse tiponão focaliza oscilações, mas o aumento contínuo dos parâmetros deexecução.


20/62


4. Teste de conguração (ambiente): o objetivo desta categoria éexecutar o software sobre diversas congurações de softwares e hardwares . Desta forma, é preciso garantir que a solução “rode” sobre osmais diversos ambientes. Para aplicá-los deve-se variar os sistemasoperacionais, browsers e hardwares .

5. Teste de compatibilidade: a ideia é garantir que as novas versõesestão suportando antigas interfaces, submetendo a aplicação trocarinformações com componentes que utilizam os protocolos de ver-sões anteriores.

6. Teste de segurança: esta categoria de teste tem por objetivo detec-tar falhas de segurança que podem comprometer o sigilo das infor-mações. Sendo assim, é importante que você simule situações queprovocam a quebra de protocolos de segurança, expondo os pontosfrágeis.

7. Teste de performance (desempenho): nesta categoria você devedeterminar se o desempenho do software está de acordo com os requi-sitos denidos, nas situações de pico máximo de acesso. Para estestestes deve-se especicar claramente o cenário que você deseja obter.Omitir informações signica a criação de um cenário irreal, que im-possibilita a avaliação do desempenho.

8. Teste de conabilidade e disponibilidade: nessa categoria, deve-semonitorar o software por um determinado tempo e coletar informa-ções para identicar se ocorrem falhas na infra-estrutura (conabili-dade), e quanto tempo é necessário para a resolução desse problema

(disponibilidade).

A próxima unidade vem cheia de novidades. Veja o que preparamos para você.


21/62

Unidade deestudo 2

Seções de estudo

Seção 1 – O que é técnica de teste?

Seção 2 – Técnicas funcional, estrutural e

baseada em erros.

Seção 3 – Critérios para geração de casos

de teste.

Seção 4 – Níveis de teste.


22/62


Técnicas de teste de software

SEÇÃO 1O que é técnica deteste?

De acordo com Bastos et al (2007,p. 86) a técnica de teste é um pro-cesso que assegura o funciona-mento adequado de alguns aspec-tos do sistema ou da unidade.

Já as ferramentas de teste são re-cursos para o testador. Utilizarapenas a ferramenta, sem a técni-ca adequada, não é suciente paraconduzir todo o teste.

DICA

Por exemplo, um serrote é

apenas uma ferramenta, quese não for usada com a técni-ca adequada, pode não cor-tar a madeira e sim a pessoa.

Enm, são poucas as técnicas emuitas as ferramentas existentes.

Na próxima seção você verá asprincipais técnicas de teste. Va-mos em frente!

SEÇÃO 2Técnicas funcional,estrutural e baseada emerros

Os testes funcionais são aquelesque vericam o funcionamento

do software e se ele atende os re-quisitos. Ou seja, se o código fazaquilo que foi pedido pelo clientee que está na documentação. Nor-malmente é necessária a criaçãode condições de teste que serãousadas na avaliação da correçãoda aplicação.

Já os testes estruturais vericamse o software possui uma estrutura

robusta, ou seja, se ele se mantém

funcionando quando ocorremcondições adversas. Nesses tiposde teste, não há preocupação como atendimento aos requisitos esim se a tecnologia foi usada demodo adequado e se os com-ponentes montados funcionam

como uma unidade.

Quando você usa uma técnica deteste baseada em erros, deverá in-serir erros no software e vericar o

seu funcionamento. Na verdade,esta é uma variação da técnica fun-cional, pois ele testa os requisitos.Mas serve para encontrar aquelesdefeitos que já são esperados.

Agora que você já conheça algu-mas técnicas de teste, veja os cri-térios utilizados para geração decasos de teste!

SEÇÃO 3Critérios para geraçãode casos de teste

Para que você possa garantir certaqualidade no software é necessárioque teste certa quantidade de pos-sibilidades, ou cenários.

Quanto maior a quandadede cenários testados, maiora qualidade do produto. Lem-bre-se que não será possívelchegar ao soware perfeito,sem defeitos. Portanto, vocêdeve determinar quais serãoos cenários necessários paraangir a qualidade desejada,ok?

A ênfase dos testes de validaçãoestá nos métodos que identicamtodos os possíveis cenários detestes, chamados casos de testes.Como você possuí duas técnicaspara lidar com os testes de software (testes estruturais e funcionais), aobtenção dos casos de teste estaráassociada a uma dessas técnicas.

Para Bartié (2002, p. 122),


23/62


“Um dos maiores desaos de um processo de garana da qualidade éconseguir medir o grau de qualidade alcançado nos testes de soware.Se em nosso entendimento os cenários esverem adequadamente simu-lados e garandos, então devemos buscar todas as alternavas possíveise inseri – las em nosso processo de teste de soware, de forma a renare ampliar o nível de cobertura alcançado.”

Assim, os casos de teste se tornam extremamente importantes no pro-cesso de teste de um software e, consequentemente, no processo de ga-rantia da qualidade.

A imagem a seguir considerou o método da caixa preta para a obtençãodos casos de testes, conra!

Figura 6: Método da caixa preta para geração dos casos de teste.

Se você utilizar o método da caixa preta para gerar os casos de teste,irá criar testes funcionais. Ou seja, testará cada requisito que aparece nadocumentação inicial do software .

Assim, você cria um caso de teste para o requisito A (Caso A1). Aplicaeste caso ao software e verica se o resultado apresentado pelo software atende aquele requisito. Depois, você criará o próximo caso (Caso A2) eassim por diante. Até que todos os casos de todos os requisitos tenhamsido testados.

Desta forma, quando você for fazer testes estruturais, deverá utilizar ométodo da caixa branca para gerar os casos de teste.

Lembre-se que os testes estruturais vericam o código do soware e devem

percorrer todos os caminhos possíveis, passando por cada parte do proces-

samento e das tomadas de decisão.


24/62


Figura 7: Obtenção dos casos teste através do método da caixa branca.

De acordo com a g. 7, você pode ver que o software em questão tem 2caminhos possíveis para chegar ao m do processamento: ABCDEF ou

AGHF. Seguindo o método da caixa branca, você deve criar casos deteste que obriguem o software a percorrer os dois caminhos.

Vendo estas duas abordagens, caixa preta e caixa branca, você pode pen-sar “Mas, qual das duas eu devo utilizar?”

Na verdade, em uma aplicação real, as duas abordagens devem ser uti-lizadas de modo a gerar os casos de testes necessários ao processo deteste.

Mas, lembre-se sempre: cmo você viu anteriormente, não serápossível eliminar todos os defeitos. Também não é economica-mente viável que se faça todos os testes possíveis e imagináveis nosoware.

É importante que o prossional de testes avalie quais são os testes ne-cessários para validar determinado produto.

DICAPor exemplo: um soware de um banco é testado de forma diferentede um soware para fazer pedido de pizza na internet, portantodevem possuir testes especícos para cada um deles.

As bibliograas especializadas apresentam diversos tipos de testes queestão dentro das técnicas estruturais (teste de carga, de execução, derecuperação, de conformidade etc) e das técnicas funcionais (teste derequisitos, de regressão, de interconexão, de controle etc).


25/62


Bartié (2002, p. 112) recomenda que os testes de cada software sejamorganizados em categorias e que em uma reunião com a equipe, cadacategoria receba um peso relativo a sua prioridade. Normalmente, todosquerem colocar alta prioridade para a sua área. Então deve ser denidoque apenas 3 categorias poderão ter alta prioridade. Assim, todos devem

entrar em acordo para determinar quais são as categorias mais importan-tes para testar determinado produto.

E por falar em peso, prioridade, que tal conhecer os níveis de teste? Ésobre este assunto que conversaremos a seguir, vamos lá!

SEÇÃO 4Níveis de teste

Como você estudou no início deste livro, de forma geral existem duasfases no processo de qualidade dos softwares . A fase de vericação (tes-tes estáticos - documentação) e a fase de validação (testes dinâmicos- software ).

Dentro da fase de vericação, você pode encontrar algumas das ativida-des que estão descritas no quadro a seguir, acompanhe!

Fase de

VericaçãoPrincipais Avidades

Modelo de

negócios

▪ Revisar contexto do mercado e necessidade docliente.

▪

Revisar riscos do projeto. ▪ Revisar estudo de viabilidade.

Especicação derequisitos

▪ Revisar especicação de requisitos funcionais enão – funcionais.

▪ Auditar rastreabilidade de requisitos.

▪ Revisar priorização de requisitos.

Análise emodelagem

▪ Revisar arquitetura da aplicação.

▪ Revisar nível de componenzação. Saiba mais so-bre componenzação de soware no argo escrito

pelo professor Antonio Mendes da Silva lho, dis-ponível em:

▪ Revisar nível de reulização.

Implementação

▪ Revisar código fonte.

▪ Avaliar complexidade do código fonte.

▪ Auditar rastreabilidade entre componentes.

▪ Revisar manual do usuário.

Quadro 2: Fases dos testes de vericação


26/62


Quando você chegar à fase de validação, encontrará 2 níveis de teste:baixo e alto nível. Os testes de baixo nível exigem um prossional combastante conhecimento da estrutura do produto. Já os testes de alto ní-

vel não exigem conhecimento da estrutura interna e possibilitam testescom maior nível de abstração.

No quadro a seguir você pode ver algumas características destes testes,conra!

Fase da Validação Caracteríscas

T e s t e d

e b

a i x o n

í v e l Teste de unidade

▪ Estratégia caixa branca e caixa preta.

▪ Testa partes do soware.

▪ Executada pelo desenvolvedor ou pros-sional de teste.

Teste de integração

▪ Estratégia caixa branca e caixa preta.

▪ Teste integrações entre as partes do sof-tware.

▪ Executada pelo desenvolvedor ou pros-sional de teste.

T e s t e d

e a

l t o n

í v e l

Teste de sistema

▪ Estratégia de caixa preta.

▪ São aplicados no soware como umtodo.

▪ Requer ambiente semelhante ao da pro-dução.

▪ Executado por um grupo de testes inde-pendente.


▪ Estratégia de caixa preta.

▪ São aplicados no soware como umtodo.

▪ Requer ambiente semelhante ao da pro-dução.

▪ Executado pelos usuários nais.

Quadro 3: Caracteríscas do testes de validação

Uma nova unidade lhe convida a explorar novos conceitos. Vamos lá?


27/62

Unidade deestudo 3

Seções de estudo

Seção 1 - Ciclo de vida de desenvolvimen-

to de sofware

Seção 2 – Conceito “V” de teste

Seção 3 – Ciclo de vida do processo de

teste

Seção 4 – Preparação do ambiente


28/62


Processo de teste de software

SEÇÃO 1Ciclo de vida de desen-volvimento de soware (CVDS)

De forma geral, os ciclos de vidade desenvolvimento de software (CVDS) são bastante diferentes,

pois em todos haverá atividadesespecícas dos testes aplicados. Aseguir você verá um ciclo de vidabásico que demonstrará as princi-pais atividades que acontecem du-rante o desenvolvimento de umsoftware . Acompanhe!

Segundo Bastos et al (2007, p. 33)as seguintes fases fazem parte deum CVDS.

▪ Fase 1 – Estudo preliminar:Essa fase começa com o reco-

nhecimento de um problema ouidenticação de uma necessida-de. Durante essa fase o projetoé justicado e aprovado no altonível da organização. As alterna-tivas de solução são exploradas eseleciona-se a solução mais viávele que atenda melhor às necessida-des identicadas. Muitas vezes,realiza-se um estudo de custo-

-benefício para apoiar o processode decisão.

▪ Fase 2 – Análise de requi-sitos:

Agora, os requisitos são denidos,coletados, validados e aprovados.

Também nesta fase são levantadasas informações necessárias pararealização dos testes.

Os requisitos geralmente sãomodicados nas fases seguintes,quando se adquire um melhor en-

tendimento do problema. Ainda nesta fase é preparado oPlano de Projeto, que inclui cro-nograma, recursos, orçamento,produtos intermediários, ativida-des de gestão, análise de riscos eos planos previstos no modelo doProject Management Institute (PMI).Deve-se incluir o plano de testes,com os recursos e prazo para rea-

lizar as atividades de teste.

Este plano do projeto não é xoe deve ser atualizado sempre quecertos eventos ocorram, comouma mudança no escopo do pro-

jeto.

▪ Fase 3 – Desenho do siste-

ma:

As atividades desta fase resultamno detalhamento da solução paraos aspectos que compõem umsistema: funcionalidade, dados etécnica. O Plano de Projeto deveser revisto para reetir as novasinformações.

▪ Fase 4 – Construção:

Nesta fase os modelos devemser transformados em realidade esuas atividades resultam em pro-gramas prontos e testados. Nes-ses programas devem ser aplica-dos os testes unitários conforme

os planos de teste e os casos deteste preparados.

Os manuais de treinamento, demanutenção e do usuário tambémsão preparados nesta fase, além

do Plano de Instalação. ▪ Fase 5 – Implantação:

Agora é o momento de efetuar ostestes de integração e de sistema.O sistema tem de receber certi-cação quanto a sua adequaçãoaos requisitos de segurança antesda instalação. E antes de ser cer-ticado, todos os resultados das

vericações e validações devemser documentados e comparados

com o antes e o depois. Por m,o sistema deve ser aceito pelousuário.

▪ Fase 6 – Operação:

Nesta fase o Modelo de Operaçãodo sistema deve ser implemen-tado, incluindo a expansão paraa instalação em outros locais. Osistema deve iniciar a operação

continuada e todas as mudanças

devem ser controladas de forma amanter e modicar o ciclo de vidadurante o restante de sua vida.Relatórios dos problemas e soli-citações de mudanças são usadospara facilitar a correção de formasistemática e a evolução do siste-ma.

Também devem ser executadasmedições de desempenho e ava-liação das atividades para garantir

que o sistema continuará atenden-do a seus requisitos.


29/62


Você já ouviu falar sobre o conceito “V” de teste? Caso ainda não tenhatido a oportunidade de conhecer este conceito, não se preocupe, pois napróxima seção você verá uma gura que ilustra exatamente o que seria ochamado conceito “V” de teste. Vamos!

SEÇÃO 2Conceito “V” de teste

Observe na imagem a seguir que os procedimentos de fazer e conferirconvergem do início ao m do projeto. Ou seja, os testes devem fazerparte de todo o processo de desenvolvimento.

Figura 8: Conceito “V” de teste de soware.

DICA

Lembre-se: testar o produto durante todo o desenvolvimento dimi-nui o custo da correção dos defeitos.

Na próxima seção você conhecerá o ciclo de vida do processo de teste.

Siga em frente!

SEÇÃO 3Ciclo de vida do processo de teste

De acordo com Rios (2003, p. 29) o ciclo de vida do processo de testeé composto por diversas etapas e é conhecido como Modelo 3Px3E.Conra na imagem a seguir um modelo de ciclo de vida do processo deteste.


30/62


Figura 9: Modelo de ciclo de vida do processo de teste.

Conheça agora cada uma das etapas do modelo.

Na etapa de procedimentos iniciais, os requisitos do negócio serãoaprofundados.Isso garantirá que o sistema de informação a ser desen-

volvido esteja completo. Claro que esta abordagem deve ser restrita aoprojeto de teste.

No planejamento serão elaborados a estratégia de teste e o plano deteste, os quais serão utilizados posteriormente.

DICA

Você estudará sobre a estratégia e o plano de teste mais para frente.

O ambiente de teste será organizado na etapa de preparação, de formaque os testes sejam executados corretamente. Esta etapa corre em pa-ralelo com as outras.O objetivo básico da etapa de especicação é elaborar/revisar os casosde teste e os roteiros de teste.

Na fase de execução os testes deverão ser executados de acordo com oscasos de testes e roteiros de teste. Devem ser usados scripts de teste,caso alguma ferramenta de automação seja empregada.

Na etapa de entrega oprojeto de teste é nalizado. Toda a documenta-ção será concluída e arquivada e todas as ocorrências importantes deve-rão ser relatadas.

Agora que você já conhece o ciclo de vida do processo de teste, quetal conhecer mais detalhadamente um ambiente de teste? Então, vamosjuntos!

SEÇÃO 4Ambiente de Teste

Nesta seção você estudará sobre ambiente de teste, o qual é preparadoem uma das etapas do ciclo de vida do processo de teste.

Script : está relacionadoà programas executados

dentro de outros programas deforma a estender a funcionali-dade deste programa ou con-trolá-lo.


31/62


O ambiente de teste é a estrutura onde o teste será executado.

Para este ambiente é preciso considerar a criação da massa de dados deteste, o modelo de dados e a conguração dos softwares usados.

É importante que você não confunda o ambiente com a conguração do

hardware, ok?

Veja na lista a seguir alguns itens que fazem parte de um ambiente deteste:

1. Pessoal: usuários, desenvolvedores, testadores.

2. Hardware : plataforma, impressora, scanners .

3. Software : software a ser testado, sistema operacional, software de teste,procedimentos de teste.

4. Suprimentos: papel, formulários.

5. Interface: interna, externa.

6. Rede: protocolos, conexões, gateways.

7. Ambiente físico: local, segurança, estrutura.

8. Documentação: requisitos, design , usuários.

Para preparar um ambiente de teste você pode usar o seguinte uxogra-ma:


32/62


Figura 10: Fluxograma de teste.

Perceba que a gura apresentada anteriormente é um ciclo, ou seja, deveser aplicada continuamente até que os testes estejam concluídos.

Mas, como toda ação geralmente possui um risco, a ação de testar um software não poderia ser diferente, não é mesmo? Por isso, na próxima uni-dade você estudará sobre a análise destes riscos, desde sua denição atécomo controlá-los. Gostou deste novo assunto? Então, siga em frente!


33/62

Unidade deestudo 4

Seções de estudo

Seção 1 – Denição de risco

Seção 2 – Riscos relavos ao teste de

sofware

Seção 3 – Determinação da magnitude

dos riscos

Seção 4 – Controle dos riscos


34/62


Análise de risco

SEÇÃO 1Denição de risco

Você sabe o que signica a palavra risco?

Segundo o dicionário da línguaportuguesa Michaelis, risco é a

possibilidade de perigo, incerto,mas previsível, que ameaça dedano a pessoa ou a coisa.

Quando falamos de software , es-tamos procurando aqueles fatoscujas ocorrências poderão acarre-tar perdas para a empresa. Noentanto, um risco presente nemsempre vai gerar uma perda.

Se uma empresa faz todo o seunegócio na internet, por exem-

plo, venda de produtos, existe umgrande risco de perda de dinheiro,se os computadores pararem de

funcionar. Mas se você pensar nomercadinho da esquina, não existenenhum problema se o computa-dor do caixa parar.

Mas, o que isso tem haver com oteste de software ? Encontre a res-posta para este questionamentona próxima seção.

SEÇÃO 2Riscos relavos ao teste de soware

A atividade de testar o software está bastante ligada ao risco. Você jáestudou como o custo dos testes inuencia no desenvolvimento de umsoftware . Também já viu que os defeitos encontrados tardiamente aumen-tam bastante o custo da correção.

Por isso, as equipes de teste devem procurar um nível de cobertura queminimize a possibilidade de defeitos graves, principalmente por causa daexistência de prazos. Ou seja, apesar de existirem riscos relativos a de-terminados defeitos, é necessário um tempo maior de teste com aquelesque podem gerar os maiores problemas.

DICA

Ao fazer a análise de riscos, leve em consideração a probabilidadede ocorrência do risco e o impacto e perda associados a esse risco.

Neste momento possivelmente você esteja se perguntando: mas, comoanalisar e avaliar os riscos que possam surgir? É sobre isso que conver-samos a seguir.

SEÇÃO 3Determinação da magnitude dos riscos

Você precisa lembrar que, quando se trata de riscos, é necessário avaliar

o custo da ocorrência do risco e o custo dos mecanismos de controlepara evitar que o risco ocorra.

Para fazer uma análise preliminar da qualicação do risco você pode usara tabela a seguir. Conra!


35/62


Impacto que o risco causaProbabilidade de ocorrência

Alta Média Baixa

Alto AA AM AB

Médio MA MM MB

Baixo BA BM BB

Quadro 4: Qualicação dos riscos (probabilidade x impacto).

Considerando o quadro apresentado anteriormente , perceba que vocêdeve dar prioridade àquele teste que vai causar o maior problema e quepode ocorrer com mais facilidade (AA).

E como controlar os riscos? Conra a seguir.

SEÇÃO 4Controle dos riscos

Considere uma loja que vende livros, CD’s e DVD’s pela internet e quemantém uma base de dados num ambiente de grande porte (legado).

Você pode encontrar alguns riscos associados a operação dessa loja.Imagine os seguintes riscos:

▪ Facilidade de uso do site , pois se a navegação não for bastante ami-gável, pode ser que o cliente desista de comprar.

▪ Tempo de resposta muito longo para as páginas abrirem, tambémpode fazer com que o cliente desista.

▪ A conectividade tem que ser conável, para que o sistema não caia e

interrompa o processo de compra.

O primeiro risco pode ser controlado fazendo um teste de usabilidadebem rigoroso. Uma das possibilidades é criar um protótipo para seravaliado por um público externo. O sistema só será liberado quando umgrupo de usuários concordar que o sistema está amigável.

Para contornar o segundo risco é preciso submeter o sistema a um testede carga e comparar os tempos de resposta com os requisitos do negó -cio. Por exemplo, os requisitos poderiam ser:


36/62


Deve ser prevista uma média de 6 mil acessos por dia, com pico de 8mil. O tempo de resposta não deve ser superior a 4 segundos e, nopico, a 8 segundos.

No controle desse risco é necessário utilizar uma ferramenta de auto-mação que faça o teste de carga, adicionando novos usuários pouco apouco até que o sistema comece a se degradar, ou seja, apresentar umtempo de resposta maior do que o requisitado.

Com este exemplo pode-se perceber que é preciso relacionar todos ospossíveis riscos que podem ocorrer com a implantação do software eposteriormente analisar cada um deles buscando uma resposta ou atémesmo solução prévia para que o risco não se torne realmente um “pro-blema”. Então que atento também aos riscos durante o processo deteste do software , ok?

Na próxima unidade você estudará sobre como fazer um plano de teste. Vamos em frente!


37/62

Unidade deestudo 5

Seções de estudo

Seção 1 – Plano de teste, o que é?

Seção 2 – Desenvolvimento do plano de

tese

Seção 3 – Documentação do teste


38/62


Planejamento dos testes

SEÇÃO 1Plano de teste, o que é?

Se você trata os testes como umprocesso contínuo, que faz partedo desenvolvimento do software ,torna-se necessário fazer um pla-no para estes testes, não é mesmo?

Da mesma forma que qualquercoisa que é executada em um am-biente industrial, é extremamenteimportante que haja um planeja-mento dos testes.

Imagine que você vai viajar deavião. Você sabe que o software de controle do avião foi testado.Mas e se não foi feito um plane-jamento e alguém se esqueceu detestar alguma coisa?

Segundo Bastos et al (2007, p.113) o plano de teste é uma ma-neira de documentar o projeto detestes e desse modo, permitir queos mesmos testes possam ser re-

petidos e controlados. Quando,posteriormente, o software passarpor algum tipo de manutenção eprecisar voltar para ser testado,esse documento será um ótimoguia para orientar a repetição ouservir de base para executar ostestes de regressão.

Conra a seguir as etapas que fa-zem parte de um plano de teste.

▪ Repetibilidade: uma coisa que torna qualquer sistema conávelé a repetibilidade, ou seja, se você executar o sistema com as mesmasentradas ele deverá apresentar as mesmas saídas. O plano de testespermite a repetibilidade da aplicação dos testes.

▪ Controle: como você saberá se os objetivos do teste foram atingi-

dos ou se todos os elementos críticos foram testados? A única formade fazer controle sobre os testes é possuir um plano que determinequais são os passos a serem seguidos na hora de testar.

▪ Cobertura: o plano de teste também determinará o nível de cober-tura dos testes. Essa cobertura deve atingir os elementos mais críticos,seja pelo risco que representa para o negócio, seja por sua importânciapara o projeto.

Em resumo, o plano de testes é extremamente importante para o pro-cesso de teste. Ele estabelece o que vai ser testado, durante quantotempo e quando os testes serão interrompidos.

O plano de teste descreve como o teste deverá ser executado e traça umalinha mestra a ser seguida.

Conra na seção seguinte como desenvolver um plano de teste. Sigaadiante!

SEÇÃO 2Desenvolvimento do plano de teste

Para que você possa desenvolver um plano de teste existe um padrãoque é mundialmente aceito. Este padrão foi denido pelo Institute of Electrical and Electronics Engineeres (IEEE). Nele está a lista com o conte-údo do plano de teste.

O Quality Assurance Institute (QAI) segue basicamente este mesmo pa-drão, apenas com algumas características próprias.


39/62


Para lembrar signica: PMI =Project Management Instu-

te, criadores do PMBOK.

Para relembrar signica: PM-BOK (Project ManagementBody of Knowledge).

Além desses dois formatos deplano, existe o Plano Global doProjeto, denido pelo PMBOK ,que foi citado na primeira unidadede estudos deste livro.

Este último trata o teste como umprojeto, por isso você irá estudálocom mais detalhes a seguir.

Os itens do PMBOK são os se-guintes:

▪ Escopo: o escopo deneexatamente a extensão do projetode teste, até suas interfaces comoutros softwares , componentes,elementos de rede ou demais ele-

mentos. Deve denir o que será eo que não será coberto pelo teste.

▪ Custo: para saber quantoo projeto de teste vai custar épreciso medir o seu tamanho,ouseja, é preciso fazer a métrica deteste. É possível adaptar algumasmétricas existentes, como análisede pontos de caso de teste. Masnormalmente isso leva tempo e amétrica deve ser ajustada gradati-

vamente. ▪ Tempo: a elaboração do cro-

nograma está ligada ao tamanhodo projeto, que servirá de basepara o cálculo dos custos. Vocêpode imaginar, por exemplo, umprojeto com 180 pontos de teste.Por meio de indicadores da em-presa é possível transformar estenúmero de pontos em horas (porexemplo, 220 horas). Depois,

transformar horas em custo ésimples. Como tempo é dinheiro, você deve também estabelecero momento de encerramento

dos testes. Ficar testando umaaplicação por muito tempo podeaumentar demais o custo do

projeto.

▪ Qualidade: você sempre

deve lembrar que o produto a serentregue deve estar de acordocom as necessidades de qualidadeestabelecidas pelo cliente. Então,

a medição da qualidade tem queser acompanhada por um progra-ma de indicadores, implementadono decorrer do projeto.

▪ Integração: a principal inte-gração do projeto de teste é como processo de desenvolvimento.

Além disso, como normalmenteo projeto de teste é segmentadoem etapas, por isso é precisomanter a integração entre elas.

▪ Recursos humanos: a quanti-dade de homens/hora imaginadapara o projeto é estabelecida apósa estimativa de seu tamanho.Porém, é necessário denir os re-cursos envolvidos em cada etapado projeto.

▪ Comunicação: a função dessa

etapa é garantir a maneira comoas partes envolvidas no projetoreceberão as informações de queprecisam para tomar decisões.

Todo material produzido deveráestar disponível para consulta demaneira clara em algum ambientecriado pelo projeto. As regrasde gerenciamento de projetosdeterminadas pelo PMI denema necessidade de um gerencia-mento de comunicação para dar

suporte aos projetos.

▪ Riscos: o projeto de testeimplica seus riscos especícos,como o uso de uma nova ferra-

menta de automação para a qualos testadores ainda não tenhamsido treinados. Se você é o líderdo projeto de teste, tome cuidadopara não confundir os riscos do

projeto de teste com os riscos donegócio.


40/62


▪ Suprimentos: é importanteque as necessidades de comprade bens ou serviços sejam aten-didas no momento certo. Talvezalgumas ferramentas precisem ser

compradas ou um ambiente deteste tenha de ser congurado.

▪ Conclusão: independen-

temente de qual modelo vocêseguirá na elaboração do planode teste, o importante é que esteplanejamento seja feito comcuidado e precisão.

Você sabe quais são os documen-tos necessários às atividades de

um projeto de software ? É sobreeste assunto que você estudará nasequência. Siga em frente!

SEÇÃO 3Documentação do teste

Segundo Bastos et al (2007, p.150), em torno de 50% a 60% dotempo do analista de teste é gas-to na documentação do teste. Anorma IEEE 829 descreve umconjunto de documentos neces-sários às atividades de um projetode software . Veja!

▪ Plano de teste: identica ositens e as funcionalidades a seremtestadas, os riscos associados aoteste, as tarefas a serem realizadase apresenta o planejamento para

a execução do teste. ▪ Especicação de projeto de

teste: trata-se de um detalhamen-to da abordagem apresentada noplano de teste que identica asfuncionalidades e as característi-cas a serem testadas pelo projeto.Este documento também apontaos casos e os procedimentos de

teste e apresenta os critérios deaprovação.

▪ Especicação de caso de teste: dene os casos de teste, comtodas as características que você estudou nas seções anteriores.

▪ Especicação do procedimento de teste: identica todos ospassos necessários para a operação do sistema e o exercício dos casosde teste especicados. Os procedimentos de teste devem ser seguidospasso a passo, sem imprevistos. Esta especicação forma um docu-mento separado.

Figura 11: Documentação IEEE 829.

Na próxima unidade você verá como deve ser executado o teste de umsoftware . Como já mencionado nas unidades anteriores todos os testesdevem ser executados buscando a qualidade do software . Mas, muitas ve-zes, os requisitos dos softwares não exigem essas características. E comoteste custa dinheiro, será preciso conversar com os usuários sobre a ne-cessidade de alguns tipos de teste.

Ficou curioso(a) para saber mais sobre o assunto? Vamos lá, siga emfrente nos estudos!


41/62

Unidade deestudo 6

Seções de estudo

Seção 1 – Contexto dos testes

Seção 2 – Processo de execução dos testes

Seção 3 – Relatório de teste segunda a

IEEE 829

Seção 4 – Gerenciamento de comunicação

do projeto de teste


42/62


Execução dos testes

SEÇÃO 1Contexto dos testes

De acordo com Bastos (2007, p. 169 apud CEM KANER, 1999), testeestático e teste dinâmico são denidos da seguinte forma:

▪ No teste estático, o código é examinado.

▪ No teste dinâmico, o código é testado.Para que os testes possam ser executados é necessário que exista o Plano

de Teste.

É muito importante que o plano de testes esteja atualizado e bemdetalhado, pois isso facilitará o trabalho dos testadores na hora deelaborar os casos de teste e de executar os testes.

A responsabilidade de cada pessoa durante a execução dos testes deveestar no plano de teste. No quadro a seguir você pode vericar o quecada agente da equipe de teste deve fazer. Conra!

Responsáveis pelos testes

Testes unitários Programadores

Testes de integração Analistas de sistemas

Testes de sistema Analistas de teste

Testes de aceitação Usuários com a ajuda dos analistas de teste

Quadro 5: Responsabilidade de cada pessoa da equipe de teste.

Você deve analisar os resultados dos testes a cada etapa de teste executa-da. Todo s os registros da execução dos testes devem ser guardados sobferramentas de gestão dos testes. Desse modo, o gestor de teste poderásaber o que ainda precisa ser corrigido pela equipe desenvolvimento, oque está em processo de teste e o que já foi dado como concluído, ouseja, já foi testado, corrigido, retestado e aprovado.

Que tal conhecer como acontece o processo de execução dos testes?Este é o nosso póximo assunto!


43/62


SEÇÃO 2Processo de execução dos testes

Nesta seção, você vai ver que o processo de teste que deve ser cumprido

na fase de execução. Esse processo está apresentado na gura a seguir.O Plano de Teste de teste é o documento mais importante deste uxo.

Figura 12: Fluxo de execução dos testes

DICA

Se ele não for elaborado, não é possível executar cada etapa correta-mente, ok? Lembre-se disso!

Você vai ver agora os diversos métodos para testar uma aplicação, se-gundo as características de qualidade dos softwares .

▪ Teste de autorização (funcionalidade): visa garantir que as regrasde autorização sejam cumpridas. Ninguém pode executar, por exem-plo, uma funcionalidade para a qual não está habilitado.

▪ Teste de integridade dos arquivos (funcionalidade): garante queas atualizações de arquivos foram feitas corretamente após a execuçãode um módulo do software .

▪ Teste de recuperação (continuidade): você deve testar os

procedimentos que permitem que o sistema seja reiniciado após umafalha. Todos os procedimentos que mostram como reiniciar o sistemadeverão passar por inspeção.

▪ Teste de estresse (performance): o teste deve colocar a aplicaçãosobre estresse para vericar se o software consegue funcionar correta-

mente sob grande carga de processamento.


44/62


Manutenibilidade é uma me-dida para mostrar se o sof-tware é fácil de consertar ouser melhorado.

▪ Teste manual (usabilidade):

os sistemas devem ser amigá- veis, fáceis de utilizar, para quepossam fazer sucesso com os

usuários nais. Normalmente,

é difícil avaliar se uma aplica-ção é amigável, apenas usandoum ambiente de teste. Então, émelhor fazer o teste manual numambiente mais próximo possíveldo ambiente de produção.

▪ Teste de segurança (segu-

rança): este tipo de teste deve

vericar se é possível que pessoasnão autorizadas violem as infor-mações. Em geral, o testador

não é especialista em segurança,então em alguns casos é necessá-rio contratar técnicos especialis-tas para a execução deste teste.

▪ Inspeções (manutenibilida-

de): é muito importante testar seserá fácil efetuar a manutençãoda aplicação no futuro. Para apessoa que desenvolveu o software , é fácil fazer alterações, pois elaconhece bem a aplicação. Mas

se esta aplicação for mantida poroutro técnico, é necessário queela seja simples de entender.

▪ Teste de conexão (conec-

tividade): estes testes devem

garantir que a aplicação está secomunicando corretamente com

outra.

▪ Teste de performance

(performance): muitas vezes, asaplicações apresentam alguns cri-térios de desempenho que preci-sam ser atendidos, como número

de clientes ativos ou transaçõesexecutadas por hora.

▪ Teste operacional (ope-

racionalidade): neste tipo de

teste, toda a documentação deoperação do software será avaliada.Ele deve ser feito pela equipe deprodução ou pela equipe que iráoperar a aplicação.O quadro a seguir é um exemplode checklist que pode ser utiliza-

do na execução dos testes. Esteexemplo foi retirado do livro Ga-rantia da Qualidade de Software doautor Alexandre Bartié. O quadromostra vários procedimentos deteste para integrações batch emum sistema de vendas, que cole-ta todas as entradas de pedidos

realizadas pelos vendedores, nasquais são informados os produtose suas quantidades, descontos e as

condições de pagamento negocia-das com o cliente.

Normalmente, nas integrações batch , se você deseja provocar umasituação no sistema, é necessáriointeragir com outros softwares deforma produzir o resultado dese-jado.

Batch: a tradução direta élote. No caso de soware,

essa palavra está relacionadacom um arquivo de lote (.bat)ulizado para automazar tare-fas.


45/62


Processo: importa resultado da análise de crédito

Cenário #1

Executar a importação sem a existência do arquivo

Pré - requisitos ▪ Garanr que não exista arquivo – texto de importação.

Ações ▪ Executar importação da análise de crédito.

Conferências ▪ Mensagem “Não foi encontrado o arquivo de Análise de Crédito”.

Cenário #2

Executar a importação com o arquivo disponível

Pré - requisitos ▪ Garanr que existam pedidos que aguardam análise de crédito.

▪

Garanr que exista arquivo de simulação Simula-01.TXT.


Conferências

▪ Mensagem “Importação da Análise de Crédito realizada com sucesso”.

▪ Conrmar se o arquivo foi excluído.

▪ Conrmar se as situações dos pedidos foram alteradas corretamente.

▪ Conrmar os movos para os pedidos com recusa de crédito.

Cenário #3

Executar a importação com arquivo já processado

Pré - requisitos ▪ Garanr que exista arquivo de simulação Simula-01.TXT.

▪ Garanr que o arquivo Simula-01.TXT já tenha sido processado.


Conferências

▪ Mensagem “Este arquivo já foi anteriormente processado!”.

▪ Conrmar se a operação foi cancelada.


Cenário #4

Executar a importação de pedidos com dois dias em pendência de análise de crédito

Pré - requisitos ▪ Garanr que existam pedidos aguardando análise de crédito há dois dias.

▪ Garanr que exista arquivo de simulação Simula-02.TXT.


Conferências

▪ Mensagem “Alguns pedidos estão em análise há dois dias ou mais!”.


▪ Conrmar exibição da lista de pedidos com dois dias em análise ao usuário.

▪ Conrmar e-mail para o Gerente de Vendas e de Crédito e Cobrança.

▪ Conrmar se e-mail possui lista de todos pedidos com dois dias em análise.

Quadro 6: Checklist para execução de testes


46/62


Na próxima seção você conhe-cerá modelos de relatório de tes-te segundo a IEEE 829. Siga emfrente!

SEÇÃO 3Relatório de teste se-gundo a IEEE 829

O líder do projeto deverá elaborarum relatório sobre os testes, ao -nal do projeto. Nesta seção vocêestudará alguns relatórios de testedenido pela norma IEEE 829.

Estes documentos são: ▪ relatório de Log de teste;

▪ relatório de Incidentes deteste;

▪ relatório de Sumário de teste.

DICA

Nas próximas páginas destaseção você estudará cada

um desses relatórios.

Relatório de log de tes-

te

O log pode ser considerado comoum diário de ocorrências da ativi-dade de execução dos testes. Opropósito básico é descrever tudode relevante que ocorre durante o

projeto de teste.Conra os itens que devem estarno log de teste:

▪ identicação;

▪ descrição;

▪ atividade e eventos;

▪ descrição da execução;

▪ resultados;

▪ informação sobre o ambiente

de teste; ▪ eventos imprevistos.

Exemplo:

▪ 28 de setembro de 2001.

▪ 10h: Nilton começou a testaro módulo M do sistema L.

▪ 10h15: Nilton usou os dadosde teste já existentes conforme odocumento AAA.

▪ 10h30: ocorreu um cancela-mento anormal que foi registradono documento correspondente

e encaminhado ao desenvolvi-mento.

▪ 10h40: Nilton interrompeu oteste, pois está aguardando o pa-recer da área de desenvolvimento.

Relatório de incidentes

de teste

Qualquer ocorrência no projetode teste que requeira algum tipode investigação deverá ser regis-trada no relatório de incidentes.O uso mais comum deste relató-rio é quando você encontra umdefeito ocorrido e tem que trans-mitir para a equipe de desenvolvi-mento, para que ela tome algumaprovidência.

O relatório de incidente de testedeve ter o seguinte conteúdo bá-sico:

▪ identicador do relatório -

deve ser único em todo o projetoou processo de teste;

▪ sumário da ocorrência - des-

crever em detalhes o que estavasendo feito quando ocorreu oincidente;

▪ descrição do incidente - o

IEEE sugere que você coloquena descrição os seguintes itens:entradas, resultados esperados,resultados encontrados, proble-mas, data e hora da ocorrência,sugestões de procedimentos aserem tomados, ambiente, tenta-

tivas de contornar o problema,testadores envolvidos e observa-dores.

Relatório de sumário

de teste

Neste relatório você deve apre-sentar as atividades de teste rea-

lizadas durante um determinadoprojeto e mostrar resumidamenteas ocorrências durante todas as

atividades. Este relatório costumafechar o projeto de teste.

A seguir conheça o conteúdo des-se relatório.

▪ Identicador: código queidentica o relatório. Deve teruma referência ao projeto de

teste em questão. ▪ Sumário: devem ser mos-

trados o escopo do trabalho eos documentos básicos usadosno projeto, descrevendo resu-midamente o trabalho de testeexecutado.

▪ Variações: se algum procedi-mento foi feito de forma diferen-

te do que está previsto no planode teste, deve ser listado neste

item. ▪ Avaliações do processo:

qualquer ocorrência que possacausar impacto na qualidade dosoftware liberado para a produçãodeve ser relatada. Por exemplo,se algum teste foi interrompidopor falta de prazo.

▪ Sumário dos resultados:

neste campo você deve colocartodos os parâmetros que possam

quanticar o projeto de teste.Por exemplo, número de casosde teste, número de execuçõesde cada caso, número de defeitosencontrados etc.

▪ Avaliação do teste: você deve

avaliar o projeto de teste e veri-car se alguns riscos ainda nãoresolvidos podem causar proble-mas no momento da produção.


47/62


▪ Sumário de atividades: neste sumário você deve listar as pessoasenvolvidas no projeto de teste, o número de horas consumidas noprojeto por atividade, tempo total consumido pelo projeto e outrasinformações relevantes.

▪ Aprovações: nome das pessoas responsáveis pela aprovação doprojeto de teste.

A partir do que você já estudou, percebeu a importância da sua dedi-cação para percorrer a trajetória de aprendizagem? Então, vamos emfrente.

SEÇÃO 4Gerenciamento de comunicação do projeto deteste

De acordo com o PMBOK, o gerenciamento de comunicação de umprojeto deve incluir os processos necessários para garantir a geração, acoleta, a disseminação, o armazenamento e o descarte de todas as infor-mações do projeto. Assim, o gerenciamento de comunicação se dividenas seguintes atividades:

▪ planejamento das comunicações;

▪ distribuição das informações;

▪ relatório de desempenho;

▪ encerramento.

E cada uma dessas atividades tem o seguinte conteúdo:

▪ entradas;

▪ ferramentas e técnicas;

▪ saídas.


48/62


Figura 13: Gerenciamento de comunicações

Em resumo, você pode entender que: ▪ as entradas são todos os artefatos necessários para realizar a ativida-

de;

▪ as ferramentas e técnicas correspondem a tudo o que é feito sobreas entradas;

▪ as saídas correspondem ao resultado nal da atividade.

Com este assunto você encerra os estudos desta unidade. Porém, a buscapor novos conhecimentos não acabou. Pesquise sobre os temas, conver-se com o professor, discuta com seus colegas, enm, explore todas as

oportunidades de aprendizagem. Agora prepare-se para uma nova jornada.


49/62

Unidade deestudo 7

Seções de estudo

Seção 1 – Denição dos critérios de aceitação

Seção 2 – Elaboração do plano de aceitação

Seção 3 – Execução do teste de aceitação


50/62



SEÇÃO 1Denição dos critériosde aceitação

O teste de aceitação é de respon-sabilidade do usuário do software (teste beta). Segundo Bartié(2000, p. 157)

“[...] é o úlmo estágio do pro-cesso de validação. Trata-se doúlmo processo formal de de-tecção de erros no sistema, an-tes de sua disponibilização noambiente de produção. Nessaetapa, o soware é disponibi-lizado para clientes e usuárioscom o objevo de estes valida-rem todas as funcionalidadesrequisitadas no início do proje-to. Os usuários terão a oportu-nidade de interagir com um sis-tema completo, exausvamentetestado pela equipe de testes.”

Esta validação não precisa ser fei-ta apenas no nal do processo.Ela pode acompanhar todo o de-senvolvimento do projeto.

Dessa forma é possível que o pró-prio usuário detecte problemas

mais cedo, podendo negociar novos prazos.

Para tanto, tá no início do projeto,quando são elaborados os requi-sitos, o usuário deve denir quaiscritérios serão utilizados para aaceitação do software . Ou seja, oque ele irá avaliar no momento doaceite.

Normalmente, os requisitos a queo software deve atender podem ser

divididos em três categorias:

▪ requisitos de funcionalida-

de: relatam as regras de negócioa que o software deverá obedecer;

▪ requisitos de performance:

retratam requisitos operacionais,como por exemplo, tempo deresposta, número de transaçõespor hora e outras restrições quedeverão ser cumpridas;

▪ requisitos de qualidade:

denem atributos de conança,testabilidade, correção e usabili-dade etc.

DICA

A testabilidade indica o quãofácil é escrever os casos deteste para o soware.

Você já ouviu falar em plano deaceitação? Vamos ver juntos oque a próxima seção reserva paraa contuidade dos seus estudos!

SEÇÃO 2Elaboração do plano deaceitação

O plano de aceitação é um do-cumento que dene os passosnecessários ao teste de aceitação,como estes testes devem ser feitos

e diversos requisitos e responsabi-

lidades.

O ideal é que o plano de aceita-ção seja escrito simultaneamenteao plano geral do projeto e à ela-boração dos requisitos. O teste de

aceitação vai depender da libera-ção do software pelos desenvolve-dores e testadores.

O plano do projeto deverá ter umcronograma de desenvolvimentoe teste, para indicar quando ostestes de aceitação terão início.

O plano de aceitação deve conteras informações seguintes.

▪ Descrição do projeto: devem

ser especicados o ambienteoperacional e as interligaçõescom outros software ou ambientes,além de incluir uma descriçãodetalhada do projeto, com suasfases e a metodologia utilizada nodesenvolvimento.

▪ Responsabilidades dos usu-

ários: denir as atividades que osusuários devem fazer durante ostestes. Deve incluir sua participa-ção nas etapas do projeto.

▪ Procedimentos administra-

tivos: incluir todos os relatóriosgerados durante o trabalho deteste. Identicar as áreas envolvi-das. Denir critérios de comuni-cação entre as partes envolvidas.

▪ Requisitos cobertos: iden-

ticar a lista dos requisitos queserão cobertos pelos testes deaceitação.

▪ Responsável pela elabora-ção: nomear o responsável pelaelaboração do plano.


51/62


Agora que você já sabe o que é um plano de aceitaçao, assim como asinformações que ele deve conter, que tal aprender a executá-lo? Siga emfrente!

SEÇÃO 3Execução do teste de aceitação

Os testes de aceitação são executados sobre os produtos entregues du-rante o ciclo de vida do processo de desenvolvimento. Esses testes se-rão as últimas oportunidades do usuário para vericar se o produto queencomendou à equipe de desenvolvimento é de fato o produto que lheestá sendo entregue. Assim, você pode empregar o aceite como umaestratégia para reduzir riscos de uma implantação maciça, na qual umerro vital não detectado pode comprometer a imagem da solução comoum todo.

Os testes de aceitação podem ser divididos em três partes: aceite formal,alpha – teste e o beta – teste. Conra!

Figura 14: Estágios do processo de aceite de umsoware.

▪ Aceite formal: nesta parte do teste de aceitação, os clientes plane-jam e realizam os testes. É muito utilizado em projetos desenvolvidospara atender a um grupo de empresas, possibilitando a criação de umcomitê que atestará a aderência do software às necessidades do grupo.

Assim, o processo de aceitação torna-se uma continuação natural dostestes funcionais do sistema.

▪ Alpha – teste: o objetivo deste teste é permitir que o usuário atuenaturalmente no software , de forma a encontrar defeitos em algunsprocedimentos implantados. Para isso, você deve convidar os clientesa operar o software em um ambiente localizado na empresa criadora dosoftware . Neste teste não há formalidades quanto à validação, mas é

importante criar um conjunto reduzido de procedimentos. Pode serque os clientes não sigam completamente estes procedimentos, maseles funcionarão como um checklist do aceite.

▪ Beta – teste: neste tipo de teste de aceitação é feita uma implan-tação em paralelo. Os clientes vão operar o produto utilizando suaspróprias instalações físicas para que o software seja utilizado no ambien-te real do dia-a-dia. Você não deve confundir o Beta – teste com aimplantação denitiva.


52/62


Este teste pode ocorrer até que o cliente se sinta seguro em realizar amudança de aplicativo e durante toda a sua execução, ele contará como apoio da empresa. Dessa forma a imagem do produto e da empresanão será prejudicada.

Agora, você já sabe por que alguns sistemas na internet possuem a pala-

vra “beta”, pequenininha, junto com o nome do sistema. A etapa que trata de “Todos os clientes” indica que o software será im-plantado denitivamente. Se todas as fases do processo de teste forambem planejadas e executadas, nesta etapa o software estará atendendocorretamente todos os requisitos funcionais e estruturais indicados pelocliente.

Conra o que preparamos para você na próxima unidade de estudos!


53/62

Unidade deestudo 8

Seções de estudo

Seção 1 – Análise do ponto de teste

Seção 2 – Esmava baseada no tamanho e

complexidade do caso de uso


54/62


Saiba mais sobre análise deponto de teste em:http://www.testexpert.com.br/?q=taxonomy/term/8http://qualidadebr.word-press.com/2009/11/22/esti-mava-de-testes-apt/.

Estimativas

SEÇÃO 1Análise do ponto deteste

Segundo Bastos et al (2007, p.243), a análise de ponto de teste(APT), é uma técnica de mediçãode projetos de teste de software .

DICA

Lembre - se que toda técni-ca de medição e esmavadeve levar em consideraçãoo ambiente onde está sendousada.

Você nunca deve esperar obterresultados exatos na primeira vezque empregar esta análise. Mascom o tempo e o ajuste do mode-lo, a tendência é que os resultadoscarão cada vez mais precisos.

O objetivo da APT é determinaro tempo necessário à etapa de tes-tes. Esta técnica leva em conside-ração o tamanho do sistema a sertestado a partir das informaçõescoletadas com as equipes de de-senvolvimento. Os testes tambémsão afetados pelos seguintes fato-res:

▪ o grau de complexidade doprocesso de teste;

▪ o nível de qualidade que sepretende alcançar com os testes;

▪ o grau de envolvimento dosusuários com os testes;

▪ as interfaces que são as

funções testadas têm com osarquivos;

▪ a qualidade do sistema testado(o ciclo de reincidência de defei-tos);

▪ o nível de cobertura esperadocom os testes;

▪ a experiência e a produtividadeda equipe de teste (medidos pormeio de indicadores históricos);

▪ o grau de automação dostestes;

▪ a qualidade do ambiente deteste, até mesmo a sua capaci-dade de simular o ambiente deprodução;

▪ a qualidade da documentação

do sistema e, especialmente dosrequisitos.

A gura a seguir mostra as etapasnecessárias para se chegar ao ta-manho do sistema em pontos deteste. Veja!

Figura 15: Visão geral da Análise de Pontos de Teste.


55/62


SEÇÃO 2Esmava baseada no tamanho e complexidadedo caso de uso

De acordo com Bastos et al (2007, p. 246) este tipo de estimativa ésimples e necessita de pouco conhecimento em cálculos. Ela utiliza asseguintes entradas:

▪ contagem do número de uxos de um determinado caso de uso;

▪ média de passos de cada uxo (passo do ator e reação do sistema);

▪ contagem do número de exceções;

▪ contagem das regras de negócios, classicadas como simples, médiase complexas.

Você deve calcular o esforço de teste combinando a complexidade e otamanho do caso de uso.

Por exemplo, quanto tempo é necessário para testar um caso de usopequeno e de complexidade simples?

Esse valor de tempo deve ser corrigido periodicamente (histórico asso-ciado à experiência e à maturidade da equipe de teste). Quando existempessoas com diferentes níveis de experiência, você pode atribuir um fa-tor de correção. Veja a tabela a seguir.

Tamanho Complexidade Horas

Pequeno Simples 6Pequeno Média 8

Pequeno Complexa 10

Médio Simples 8

Médio Média 12

Médio Complexa 16

Grande Simples 12

Grande Média 18

Grande Complexa 20

Muito grande Simples 16

Muito grande Média 20

Muito grande Complexa 28

Tabela 1: Esforço de teste em horas


56/62


A complexidade deve ser informada pela área de negócio, responsávelpela elaboração do caso de uso.

Esse valor em horas (complexidade/tamanho) deve ser dividido pela

Testes Software curso técnico em informatica

Documents

Transcript of Testes Software curso técnico em informatica