PONTIFCIA UNIVERSIDADE CATLICA DE GOIS DEPARTAMENTO DE COMPUTAO

TESTE FUNCIONAL

JOSIANE SOUSA E WASSILY BRASIL

Junho 2011

PONTIFCIA UNIVERSIDADE CATLICA DE GOIS - PUC-GOIS DEPARTAMENTO DE COMPUTAO

GRADUAO EM CINCIA DA COMPUTAO

TESTE FUNCIONAL:

Trabalho de Trabalho de Concluso de Curso apresentado por Josiane e Wassily Brasil PONTIFCIA UNIVERSIDADE CATLICA DE GOIS - PUCGOIS, como requisito parcial para obteno do ttulo de Bacharel em Cincia da Computao aprovado em x/06/2011 pela Banca Examinadora: Professor Andr Luiz, Dr. UCG Orientador Professor Nome, Ttulo de Nobreza. Instituio Professora Maria Auxiliadora do Bonfim, MBA. UCG

TESTE FUNCIONAL:

JOSIANE WASSILY BRASIL

Trabalho de Trabalho de Concluso de Curso apresentado por Josiane e Wassily Brasil PONTIFCIA UNIVERSIDADE CATLICA DE GOIS - PUCGOIS, como parte dos requisitos para obteno do ttulo de Bacharel em Cincia da Computao.

_____________________ ____ Professor Andr Luiz, Dr Orientador Curso

_________________________________ Professor Beltrano de Tal, MsC. Coordenador de Trabalho de Concluso de

No sei quantas almas tenho. Cada momento mudei. Continuamente me estranho Nunca me vi nem acabei. De tanto ser, s tenho alma. Quem tem alma no tem calma. Fernando Pessoa

AGRADECIMENTOS

Ao Professor Antnio de Jesus, orientador acadmico, pelo apoio e confiana depositada. Aos professores Carlos do Esprito Santo e Maria Auxiliadora do Bonfim, pela inestimvel colaborao. Coordenao do Departamento de Computao da PONTIFCIA UNIVERSIDADE CATLICA DE GOIS - PUCGOIS por ter ajudado de forma inestimvel execuo deste trabalho. Aos meus colegas Francisco Prego e Joo Bigorna pelas discusses tcnicas e inestimveis sugestes. Ao Conselho Nacional de Desenvolvimento Cientfico e Tecnolgico (CNPq), pela ajuda financeira no decurso de meu trabalho.

A Andr Luiz pela pacincia e tranquilidade com as quais conduziu esse documento

Aos nossos familiares Ao Deus de cada um de ns.

RESUMO

Apresenta-se um estudo sobre a influncia da relao Ferrita/Perlita nas caractersticas de usinabilidade dos aos ABNT 1020 e ABNT 8620. As diferentes relaes Ferrita/Perlita, foram obtidas atravs de diferentes velocidades de resfriamento nos tratamentos trmicos a que os dois tipos de ao foram submetidos. Os resultados foram analisados com auxlio da Equao de Taylor simples usando trs condies de corte distintas, garantindo-se dentro de um tempo razovel, um desgaste VB de Ferramenta de 0,3 mm. No ao ABNT 1020, a menor relao Ferrita/Perlita proporcionou maior usinabilidade. No ao ABNT 8620 ela ocorreu quando se tinha maior relao Ferrita/Perlita.

Palavras-Chave: Usinabilidade, Estrutura de Aos, Ao ABNT 1020, Ao ABNT 8620.

ABSTRACT

A study is presented on the influence of the ferrite/perlite ratio variation over the machinability of ABNT 1020 and ABNT 8620 steels. Different ferrite/perlite ratios were obtained through different cold rates on the thermal treatment to which the two steels were submitted. Results were analyzed via the simple Taylor equation, using three different machining situations, with the tool's VB wear being 0.3mm within a reasonable machining time. For ABNT 1020 steel a smaller ferrite/perlite ratio produced higher machinability. For the ABNT 8620 steel, a higher machinability was obtained when a higher ferrite/perlite ratio has been occurred.

Key Words: Machinability, Steel Structures, Steel ABNT 1020, Steel ABNT 8620.

TESTE FUNCIONAL:

SUMRIO

LISTA DE FIGURAS LISTAS DE TABELASxvi LISTA DE ABREVIATURA 1. 2. INTRODUO QUALIDADE DE SOFTWARE00 2.1. A busca pela qualidade

xiv xvii 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

3.

2.2. Adquirindo maturidade organizacional 2.3. Definindo Qualidade de Software 2.4. Entendendo o processo de qualidade de Software 2.5. Qualidade de Software incremental 2.6. Porque os modelos de qualidade de software fracassam 2.7. Benefcios de um processo de Qualidade de Software TESTES 3.1. 3.2. 3.3. 3.4. Viso Geral Fases da atividade de teste Princpios Tcnicas de Teste Viso Inicial Importncia dos Testes Funcionais Definio de tcnicas de criao de Testes Funcionais Escrevendo Requisitos e Casos de Teste 4.41. 4.42. Viso Inicial Levantar e escrever requisitos de teste

4.

TCNICAS DE TESTE FUNCIONAL 4.1. 4.2. 4.3. 4.4.

4.43. Testar com requisitos de Teste Fortes ou Maduros 4.44.Testar com requisitos de Teste Fracos 4.45. Testar sem requisitos de Teste 4.46.Levantar e escrever casos de teste 4.47. Casos de teste fortes versus casos de teste fracos 4.48. Como derivar casos de teste de casos de uso

4.5. 5. 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 6. 7. 8. 9.

Concluso Viso Inicial Teste de Equivalncia de Classe (EquivalenceClassTesting ) Teste de Valor Limite (BoundryValueTesting ) Teste por Tabela de Deciso ( DecisionTableTesting) Array Ortogonal (PairwiseTesting) Teste de Transio de Estados (StateTransitionTesting) Teste de Anlise de Domnio ( Domain AnalysisTesting )

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

TCNICAS DE TESTE FUNCIONAL

CONCLUSES REFERNCIAS BIBLIOGRFICAS GLOSSRIO APNDICE 10.1. Anexo A - Ensaios Pilotos 10.2. Anexo B - Resultados dos ensaios de usinabilidade

10. ANEXOS

LISTA DE FIGURAS

Figura 1 - Estrutura organizacional Figura 2 - Incio da informatizao Figura 3 Figura 4 -

00 00 00 00

LISTA DE ABREVIATURAS E SIGLAS

ABNT CMM VV&T UML UCG

Associao Brasileira de Normas Tcnicas CapabilityMaturityModel (Modelo evolutivo de maturidade) Verificao, validao e Testes UnifiedModelingLanguage (Linguagem Modelo Unificada) Universidade Catlica de Gois

APNDICE O MODELO DE APRESENTAO DE TABELAS

Tabela 1 Estrutura dos casos de teste segundo Myers

Seo Resumo Pr-condies Entradas do teste e o escopo. Para cada condio de execuo, descreve o estado obrigatrio do sistema antes do incio do teste. Para cada condio de execuo, enumera uma lista dos estmulos especficos a serem aplicados durante o teste. Em geral, eles so denominados entradas do teste e incluem os objetos ou os campos de interao e os valores de dados especficos inseridos durante a execuo deste caso de teste. Ao Resultados Esperados Ps-Condies Para a execuo do teste, so as aes que o usurio deve fazer para que o sistema possa cumprir com o que ser testado. o estado resultante ou as condies observveis esperadas como resultado da execuo do teste. Observe que isso pode incluir respostas positivas e negativas (como condies de erro e falhas). Para cada condio de execuo, descreve o estado ao qual o sistema dever retornar para permitir a execuo de testes subseqentes. Descrio Contm uma descrio do caso de teste, descrevendo a finalidade ou o objetivo

Fonte: Tabela 2 Tabela de transio de estados

Entrada/Sada 1 2 3 4 * Ignore empty-bf acc-bf acc-bf / ignore ignore acc-bf V * / V

Ignore 1 2 1 Ignore 3 2 1 acc-bf 4 3 3

deacc-bf;print acc-bf 4 1 3

Fonte:

Tabela 3 Tipos de teste de Caixa-Preta

Fonte: Tabela 4 Relao entre horrio e preo do evento

Horrio 18:00:00 at 19:59:59 20:00:00 at 21:59:59 22:00:00 at 23:59:59 Preo R$ 20,00 R$ 30,00 R$ 50,00

Fonte: Tabela 5 Relao entre idade e legalidade de contrato

Idade 0 a 15 anos 16 a 17 anos 18 a 49 anos 50 a 99 anos Contrato No realizado Meio-perodo Tempo Integral No realizado

Fonte:

Tabela 6 Exemplo 1 de tabela de deciso

Regra 1 Condies Condio-1 Condio-2 ... Condio-m Aes Ao-1 Ao-2 ... Ao-n Regra 2 ... Regra m

Fonte: Tabela 7 Exemplo 2 de tabela de deciso

Regra 1 Condies Honesta? Disposta? Bonita? Aes Salrio Guardar Fone R$ 440,00 No R$ 0 No R$ 520,00 Sim R$ 560,00 Sim Sim Sim No No Sim Sim Sim No Sim Sim Sim Sim Regra 2 Regra 3 Regra 4

Fonte: Tabela 8 Exemplo 3 de tabela de deciso

Caso de Teste 1 Condies Condio-1 Condio-2 Aes Ao-1 Ao-2 Faa A Faa X Faa B Faa X Faa A Faa Y Faa B Faa Y 0 10 <35 10-50 35 50 - 100 99 ou 100 100 1000 101 107 Caso de Teste 2 Caso de Teste 3 Caso de Teste 4

Fonte:

Tabela 9 Exemplo 4 de tabela de deciso

Caso de Teste 1 Condies Condio-1 Condio-2 Aes Ao-1 Ao-2 Faa A Faa X Faa B Faa X Faa A Faa Y Faa B Faa Y Sim Sim No Sim Sim No No No Caso de Teste 2 Caso de Teste 3 Caso de Teste 4

Fonte: Tabela 10 Exemplo 5 de tabela de deciso

Caso de Teste ID CT1 CT2 CT3 CT4 Condio 1 0 22 51 102 Condio 2 12 35 100 107 Resultado Esperado Faa A / Faa X Faa B / Faa X Faa A / Faa Y Faa B / Faa Y

Fonte:

APNDICE P MODELO DE APRESENTAO DE FIGURAS

Capacidade de correo de erros (t)

Comprimento da Mensagem (k)

Figura 4 -Capacidade de correo de erros(t) X comprimento da mensagem (k) de um cdigo linear de tamanho n.

APNDICE Q MODELO DE PRIMEIRA PGINA DE TEXTO

TESTE FUNCIONAL:
CAPTULO I INTRODUO

paragrafo 1 - apresentaao do assunto qs e testes

Essa documentose pauta na busca pela qualidade do produto final de software, definindo se prope a expor conceitos acerca de testes, visando a obteno da Qualidade de Software.

Buscando garantir um produto final de software que atenda necessidade do usurio final,as empresas ligadas rea de tecnologia tm buscado meios para imprimir maior qualidade ao software produzido . H muito o conhecimento deixou de partir de unidades e passou a caminhar em blocos, em velocidade e quantidade de informaes exponencialmente maiores. Buscando acompanhar as mudanas da tecnologia,

O mercado de trabalho ligado s reas tec nolgicas e computacionais, e em especfico da construo de software oferece boas oportunidades de emprego, as empresas de software necessitam de mo-de-obra especializada.

CAPTULO II 2 -QUALIDADE DE SOFTWARE 2.1 - A BUSCA PELA QUALIDADE No inicio do desenvolvimento de software, no existiam recursos dedicados garantia da qualidade, retardando assim os testes. Em 1970 esses processos passaram a ter maior ateno, o que coibiu com o aprofundamento no que diz respeito s funcionalidades do software, embora o retardo dos testes ainda fosse notrio. As organizaes esto sempre buscando atualizaes, visando atingir maior eficincia e sofisticando seus sistemas para sua sobrevivncia neste ambiente complexo, melhorando assim a eficincia de seus processos. Apesar do grande avano tecnolgico, muitas empresas ainda ficam presas a antigos paradigmas, impedindo assim seu amadurecimento no processo.

Embora as organizaes indiquem a tecnologia como instrumento de viabilizao, aprimoramento e inovao de seus produtos, as indstrias de softwares no esto preparadas para atender a todas as necessidades do mercado, no existindo garantia de solues em curto prazo e com custos combinados. Os americanos possuem uma carga muito maior de conhecimento, pois recebem uma carga de treinamento muito maior do que nossos profissionais. Por isso, as organizaes preferem contratar mo-de-obra estrangeira para o desenvolvimento de tecnologia.

2. 2 - ADQUIRINDO MATURIDADE ORGANIZACIONAL As empresas hoje j entendem que a fabricao de softwares no adequados, ou de baixa qualidade aumenta muito os custos de desenvolvimento, prejudicando a imagem da organizao. Em tempo, essas empresas especializam-se mais no aprimoramento do processo. O modelo CMM (CapabilityMaturityModel) um modelo evolutivo que se divide em cinco nveis de maturidade. Empresas podem partir de uma total falta de controle e gerenciamento de seus processos adotando este modelo em funo de se organizar em nveis de maturidade organizacional, ou mesmo evoluir a partir de um modelo qualquer j adotado. Cada nvel composto por reas-chave, que compe a diviso sistemtica dos nveis de maturidade de uma organizao. Uma organizao passa a outro nvel sempre que consegue atingir todas as reas chaves de um nvel em questo.

2.3 - DEFININDO QUALIDADE DE SOFTWARE Segundo Alexandre Barti, em seu livro Garantia da Qualidade de Software, Qualidade de Software um processo sistemtico que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeito.

Softwares que so mal testados causam muitos prejuzos s organizaes. Um simples erro pode solicitar processos importantes, podendo tambm influenciar em uma deciso qualquer a ser tomada pela gerencia ou diretoria dentro de uma organizao. No entanto, para garantir a qualidade de um software, devemos estabelecer um nvel determinado de tolerncia aos erros, alm de reestruturar os processos, fornecendo mecanismos de inibio e impedimento de falhas. Testes podem ser realizados para medir a qualidade dos processos. Visto que cada etapa produz documentos, possvel imprimir qualidade nas vrias fases do ciclo de desenvolvimento do software atravs da anlise dos documentos produz idos. Os testes so estticos, pois os alvos so documentos gerados durante o ciclo de desenvolvimento de software. A qualidade destes softwares garantida por meio da aplicao de testes conhecidos por testes de validao, os quais consistem em validar as interfaces de comunicao entre os componentes. Estes testes sero explicados adiante.

2.4 - ENTENDENDO O PROCESSO DE QUALIDADE DE SOFTWARE impossvel conceber um processo de garantia da qualidade de software sem integr-lo com o ciclo de desenvolvimento de software, ou seja, a qualidade do software precisa ser acompanhada e constatada durante o seu desenvolvimento. O processo de garantia composto por fases com um formato de um U (precisava no mnimo de um grfico para entender isso), numeradas para a indicao da seqncia de execuo dos testes a serem aplicados, visando garantir o processo de engenharia do software, enquanto os testes de validao esto focados na garantia da qualidade do produto de software. Figura 4.1 Viso do modelo do processo de qualidade de software em U Pag 36 do livro Garantia da qualidade de software (FIGURA 1) Os testes de validao so um processo de avaliao de produtos tecnolgicos, que podem ser aplicados em componentes isolados, mdulos existentes ou ate mesmo

no sistema como um todo, pois ele avalia a conformidade do software com os requisitos e especificaes analisadas e revisadas nas etapas iniciais do projeto. A caracterstica destes testes a presena fsica do software e de seu processamento em um ambient e bem preparado para essas as atividades. Durante o desenvolvimento do software os testes so aplicados por meio de ferramentas, tcnicas e abordagens diferenciadas. A validao ser aplicada respeitando-se os estgios de desenvolvimento.

2.5 - QUALIDADE DE SOFTWARE INCREMENTAL Tradicionalmente, os projetos so estruturados atravs de etapas bem de finidas que so completadas sequencialmente, ou seja, cada etapa depender da concluso da passada ser iniciada. Muitos profissionais dessa rea no lidam bem com coisas abstratas e as documentaes no sero suficientes para saciar tal necessidade. Quando no disponibilizado um produto para que ocorra uma avaliao concreta dos resultados alcanados, grandes riscos so gerados. Um dos aspectos mais importantes a ser definidos durante este processo determinar quais sero os indicadores que determinaro se o documento, atividade ou o software alcanou o nvel de qualidade desejado. Esses critrios servem como referncia aos grupos de qualidade, para que sejam aplicados os procedimentos para que uma atividade qualquer seja encerrada somente quando os critrios forem satisfatrios.

2.6 - POR QUE OS PROCESSOS DE QUALIDADE DE SOFTWARE FRACASSAM

Muitas implantaes de qualidade de software fracassam ou no so bem sucedidas, porque foram distorcidas e inadequadamente executadas. Quando estruturamos uma rea de qualidade de software, disponibiliza-se uma grande infraestrutura como recursos humanos, recursos fsicos e experincias acumuladas.

Um processo totalmente automatizado muito difcil de alcanar, pois necessrio investir alto na automao dos processos na fase de testes. Profissionais de qualidade de software devem possuir metodologia desenhada para atender seu maior objetivo: encontrar falhas no ciclo do desenvolvimento do projeto de software direcionando e aperfeioando essas metodologias, padronizando as documentaes e procedimentos de qualidade. Cabe a esta rea compreender as necessidades e as exigncias da rea a ser trabalhada. Com um bom planejamento, elaborada uma viso geral do projeto, tal como resolver um conjunto de situaes, antecipando passos de realizao de um trabalho. Todavia, com prazos nfimos para a entrega de um software, muitas etapas so deixadas de lado, provocando falhas que podem ficar ocultas e deixando o software vulnervel. O software no somente um objeto de testes como tambm uma importante fonte de informaes. Ele amplia a compreenso de negcio, auxilia no processo de refinamento e validao do planejamento dos testes.

2.7 - BENEFCIOS DE UM PROCESSO DE QUALIDADE DE SOFTWARE

Quando ocorre um erro, gerado um custo organizao. Os erros quando identificados, geram retrabalho, necessitando contabilizar os custos de identificao do problema, remodelagem, recodificao, teste e uma nova implantao. Com a importncia cada vez maior dos softwares, h maiores idealizao, planejamento e execuo, culminando com uma grande reduo de erros. Isso poupa a empresa de certos custos e facilita aes corretivas, minimizando problemas que so identificados durante o desenvolvimento. A perda de capacidade de gerenciar um projeto ocorre quando o gerente perde o controle do que esta sendo desenvolvido, isso ocorre por no existir um instrumento capaz de avaliar se o que est construdo tem a qualidade desejada, conforme o especificado.

Existem vrios fatores que contribuem para a qualidade final do produto, tais como: profissionais bem treinados com uma ampla experincia, ferramentas e metodologias adequadas, participao constante dos usurios finais que utilizaro o software. Todo projeto tecnolgico tem seus nveis de desordem, refletindo no aumento do numero de erros gerados e o quanto este propagou nas fases do projeto. Quanto maior for o nmero de erros, mais eles se propagaram, o que aumenta a desordem do projeto, refletindo na produtividade e nos retrabalhos do projeto tecnolgico. Uma equipe tem sua produtividade prejudicada quando o nvel de retrabalho muito alto, tirando o tempo que os profissionais teriam para desenvolver uma atividade nova para corrigir algo defeituoso. Um dos maiores benefcios que os testes agregam a um projeto de software a garantia que a manuteno ocorrida na aplicao no afetou o comportamento das outras funcionalidades. Sem um processo de testes regressivos, os testes se concentram nas partes do software que sofreram as mais recentes modificaes, descartando qualquer possibilidade de essas mudanas propagarem erros para outros mdulos. Automao de testes a utilizao de ferramentas de testes que simulem usurios ou atividades humanas de forma a no empregar procedimentos manuais no processo de execuo de testes. medida que reexecutamos os testes, os ganhos de tempo, controle e confiabilidade e as diversas possibilidades existentes com essa tecnologia, fica clara a vantagem inerente a esse processo.

CAPTULO III 3 - TESTE DE SOFTWARE 3.1 - Viso Geral Para que um software seja construdo, necessrio habilidade, interpretao e execuo.Construir um software no uma tarefa simples e mesmo utilizando mtodos e ferramentas, podem surgir erros. Isto pode resultar em um produto final de software diferente do que foi solicitado. Para que esses erros no continuem , existe uma srie de atividades chamadas de validao, verificao e teste (VV&T)

que buscam garantir que tanto a construo como o produto final esteja de acordo com o especificado. As atividades de VV&T so divididas em estticas e dinmicas. Segundo Delamaro, as estticas so aquelas que no requer a execuo ou mesmo a em existncia de um programa ou modelo executvel para serem conduzidas. As dinmicas so aquelas que se baseiam na execuo de um programa ou de um modelo. Atualmente tem ocorrido um crescimento acelerado por parte principalmente dos desenvolvedores de software em questes relacionadas qualidade. A indstria tambm tem despertado para a atividade de testes visto que com isso pode garantir a qualidade do produto, alm de reduzir os custos. Testes bem feitos nas primeiras fases de construo do software resultam na diminuio do retrabalho, alm de evitar que erros fceis de solucionar durante o incio se propaguem, causando transtornos bem maiores quando encontrados em fases avanadas da construo do software. necessrio que o processo de desenvolvimento conte com uma fase de testes que adotemtodos, tcnicas e ferramentas, visando aumentar a produtividade e a qualidade do produto final gerado, alm de diminuir os custos. Apesar dessa necessidade confirmada, esta rea de testes ainda tem grande carncia de profissionais com bom nvel de qualificao. O teste de software uma atividade dinmica, visto que o programa executado com algumas entradas e verificado se o resultado est de acordo com o esperado. Caso tal execuo apresente resultados que no foram especificados, dito que um defeito ou erro foi localizado. 3.2 Fases da atividade de teste A atividade de teste extremamente complexa, visto que diversos fatores podem colaborar para a ocorrncia de erros. Por este motivo, a atividade de teste dividida

em fases com objetivos distintos. Existem trs formas de selecionar elementos para executar testes, as quais sero descritas. A primeira chamada de teste de unidade. O teste de unidade tem como foco testar as menores unidades de um programa, seja uma funo, um procedimento, um mtodo ou uma classe. Esse tipo de teste busca encontrar erros nos algoritmos em partes separadas. Aps colocar em prtica este teste, aplicado o de integrao, pois este ir verificar se, ao juntar todas as partes do cdigo, no houve nenhum erro de compatibilidade. Executando esses dois testes, colocado em prtica o teste de sistema onde verificado se todas as funcionalidades que foram especificadas esto corretamente implementadas. Independente da fase de teste, algumas etapas devem ser seguidas de forma bem definida para a execuo de atividade de teste, segue: A) Planejamento B) Projeto de casos de teste C) Execuo D) Anlise

3.3 Princpios a)Casos de Teste Casos de Teste o conjunto de vrias condies que so usadas para testar determinado software. Os casos de teste podem ser elaborados para identificar defeitos na parte interna do produto, alm de garantir se todos os requisitos especificados esto sendo atendidos. Podem ser rastreados por ferramentas de casos de uso, facilitando assim a identificao de falhas.

 nos casos de teste que se identifica a sada esperada e quais sero os resultados esperados, para que a comparao possa ser efetuada. Segundo Myers, os casos de teste devem seguir a seguinte estrutura:
Seo Resumo Pr-condies Entradas do teste e o escopo. Para cada condio de execuo, descreve o estado obrigatrio do sistema antes do incio do teste. Para cada condio de execuo, enumera uma lista dos estmulos especficos a serem aplicados durante o teste. Em geral, eles so denominados entradas do teste e incluem os objetos ou os campos de interao e os valores de dados especficos inseridos durante a execuo deste caso de teste. Ao Resultados Esperados Ps-Condies Para a execuo do teste, so as aes que o usurio deve fazer para que o sistema possa cumprir com o que ser testado. o estado resultante ou as condies observveis esperadas como resultado da execuo do teste. Observe que isso pode incluir respostas positivas e negativas (como condies de erro e falhas). Para cada condio de execuo, descreve o estado ao qual o sistema dever retornar para permitir a execuo de testes subseqentes. Tabela 1 Estrutura dos casos de teste segundo Myers Descrio Contm uma descrio do caso de teste, descrevendo a finalidade ou o objetivo

b)Casos de Uso

3.4 Tcnicas de Teste

a) Estrutural ou Caixa-branca O teste estrutural tambm conhecido como teste caixa-branca.Seu foco principal testar a estrutura interna do programa, ou seja, o cdigo. Os requisitos so baseados na codificao do software. Com este teste, podemos calcular o percentual de cdigos exercitados em relao aos cdigos produzidos. Ele mais aplicado dentro do teste de unidade e de integrao. Nesse tipo de teste, analisada a implementao do software, ou seja, o cdigo. Aps esta anlise, so selecionados valores de entrada para execuo dos

caminhos escolhidos, so definidas as sadas esperadas, e feita a construo dos casos de teste. Finalmente, realizada a comparao entre as sadas esperadas e as sadas obtidas. Verificando o resultado desta comparao, descobre-se se o produto est gerando resultados corretos e se est de acordo com o que foi solicitado. A desvantagem deste teste que o nmero de casos de teste pode ser muito grande e estes casos podem no identificar defeitos sensveis ao dado, como por exemplo: A = b + 7 (nesta situao o resultado sair de acordo com o esperado) A = b + + 9 (nesta situao no haver resultado ou o mesmo ser calculado de forma incorreta pois o software iria identificar +9 como sendo um nico elemento. Neste teste tambm necessrio muita habilidade do profissional em relao a programao. b)Funcional ou Caixa-preta Ser tratado posteriormente. c) Caixa-cinza Esta tcnica de teste a unio da caixa-branca com a caixa-preta, isto , possvel ter acesso a estruturas de dados e a algoritmos para que os casos de teste possam ser desenvolvidos, sendo executados assim como na caixa-preta e feito a manipulao de dados na entrada e formatado o resultado na sada. d) Regresso Esta tcnica aplicada quando, ao produzir uma nova verso do software,queremos nos certificar de que as funcionalidades anteriores s quais o software atendia continuem corretas. executado um novo ciclo de teste no qual ser testado tudo aquilo que foi testado em verses ou ciclos de teste anteriores. Para aumentar a produtividade e a viabilidade dos testes, recomenda-se a utilizao de ferramentas de automao, visando que os testes j realizados possam ser executados de forma mais gil. e) Tcnicas no funcionais

As tcnicas no funcionais verificam a operao correta do software em relao a casos inesperados de entrada ou dados invlidos. Testa-se a tolerncia do software em relao ao inesperado. Nesta tcnica verificado se o sistema est preparado e se consegue fazer o processamento de grandes quantidades de dados. 3.5 Fases Aps cada funcionalidade ser desenvolvida, comum test-la separadamente, antes que o cliente tenha acesso ao software. Essa fase antecede a fase de testes, e deve ser realizada por profissionais diferentes dos que participaram da implementao. Tambm se pode testar o projeto desde o incio at o fim, tornando o processo contnuo. Sendo assim, o teste de unidade realizado primeiramente, e todo esse processo de testes feito paralelamente anlise dos cdigos, integrando assim o processo de construo do produto solicitado pelo cliente. a. Teste de Unidade

O teste unitrio tambm conhecido como teste de unidade. Neste, definido a menor unidade que poder ser testada. O objetivo encontrar defeitos na estrutura interna do mdulo. Este teste pode ser aplicado em paralelo com diversos outros testes. Porm indicado que seja o primeiro teste a ser realizado. Neste teste so encontrados alguns defeitos, os mais comuns so: a. Comparaes de dados diferentes b. Laos inadequados em variveis c. O final do ciclo inexistente

3.6 Teste de Integrao Aps efetuar a unio entre componentes do software, podem acontecer vrios tipos de incompatibilidade que gerem erros como, por exemplo, a perda de preciso nas mensagens. O objetivo principal do teste de integrao , portanto, verificar se as unidades funcionam completamente quando interligadas.

O teste de integrao pode ser executado antes da finalizao do software. As ligaes so realizadas por meio de interfaces de comunicao de unidades. feito logo aps o teste de unidade e antecede o teste de sistema onde testado em um ambiente que simula o ambiente de produo Este teste pode seguir uma abordagem incremental ou no. Na abordagem noincremental, o sistema agrupado por completo, enquanto na abordagem incremental ele agrupado em etapas, podendo assim isolar o erro para corrigi-lo com maior facilidade. 3.6 Teste de sistema

Neste teste que acontece a entrega do software ao cliente. Ele feito em um ambiente prximo ao que ser utilizado e assim as chances de se encontrar erros so bem menores. Este teste sendo executado aps o teste de integrao no apresentar defeitos. O objetivo deste teste tentar burlar o sistema e simular o comportamento de diversos tipos de usurios. O teste de sistema est no escopo da tcnica de teste caixa-preta (que ser tratada posteriormente) e por este motivo no necessrio conhecimento da estrutura interna do sistema. Este teste mais limitado se comparado com o teste de unidade e de integrao, pois se preocupa apenas com aspectos gerais. Este teste aberto a testar requisitos funcionais e no funcionais.

b. - Teste de Aceitao O teste de aceitao realizado por pessoas que utilizaro o sistema, para assim simular e comprovar se o sistema est ou no de acordo com o esperado. Este teste utilizado para determinar se o sistema satisfaz ou no os critrios de aceitao e assim permitir ao cliente decidir se aceita ou no o mesmo. a validao do produto pelo comprador e pelo usurio final, utilizando base de dados reais. c. Teste de operao

Esta fase aplica-se somente a sistemas de informao prprio. Estes testes so aplicados por administradores do ambiente final, quando o sistema entrar em ambiente produtivo, podendo substituir um outro para garantir o suporte ao negcio. i. Teste Alfa e Beta Nos casos especiais do processo de desenvolvimento de software, h uma necessidade de fases tambm especiais antes do produto ser liberado aos usurios. A fase Alfa conhecida como o perodo do trmino do desenvolvimento E a entrega, sendo executados nesse perodo. Finalizada a etapa Alfa, so feitos testes do sistema, que so chamados verses Beta. Este um teste de aceitao sendo distribudo a um grande nmero de usurios de uma ou de vrias empresas compradoras. Neste teste o desenvolvedor no est presente, no sendo controlado por ele. O registro de todos os problemas que so encontrados durante o teste Beta so registrados pelo usurio, e informado aos criadores e solucionado, as modificaes so liberadas para toda a base de clientes. ii. Candidato a lanamento Na comunidade de software livre, utiliza-se o termo candidato a lanamento indicando uma verso que candidata a verso final, essas verses so um passo alm do teste Beta, sendo divulgadas para toda a comunidade.

3.8 Teste de recuperao No teste de recuperao, testada a capacidade de um software retornar ao seu estado operacional normal aps uma falha do sistema. Sendo assim o sistema dever tolerar falhas sem causar a interrupo da funo global do sistema. Em alguns casos, deve-se determinar um tempo para que esta falha seja corrigida. O objetivo forar diversos tipos de falhas para assim verificar se a recuperao est sendo adequadamente realizada. O tempo mdio de reparo definido para estabelecer limites aceitveis.

3.9 - Teste Baseado em Modelos No incio de um projeto de construo de um sistema, necessrio criar um documento especificando seus comportamentos e caractersticas. Existem vrias formas de definir esta especificao. Uma boa prtica elaborar um documento, com linguagem simples, que pode ser escrito no idioma ao qual o sistema pertencer. Devese evitar a ambiguidade, ou seja, no permitir que o texto do documento fornea ao leitor a chance de interpret-lo de mais de uma maneira. Tambm importante procurar evitar a complexidade, redigindo-o de forma clara. A modelagem permite que todo o conhecimento do sistema seja capturado e utilizado durante vrias fases do desenvolvimento. A maior parte da fase de testes utilizada tentando entender o que o sistema deve fazer. Para saber se o resultado obtido est correto, necessrio saber qual o resultado correto. Um modelo importante para comparar o resultado correto ao resultado gerado pelo programa, verificando se o sistema se comportou ou no de acordo com o que foi proposto. Depois de testado, o modelo servir de consulta para todo o desenvolvimento do sistema. Na fase de testes, um grande obstculo encontrado determinar os itens que podero ser testados e os itens que devero ser testados. Sendo assim uma clara especificao define todo o escopo do projeto, incluindo a fase de testes. Segundo Delamaro, a criao de modelos no uma habilidade nova a ser adquirida. Os testadores sempre constroem um modelo, mesmo que seja informal. Porm a preocupao qual o formato do modelo. O modelo estando apenas nos pensamentos do testador dificultar a automatizao dos testes. Para se entender o plano de teste, os passos bsicos para a utilizao do sistema devero ser entendidos pelo testador. As vrias aes que podem ocorrer durante o uso do sistema so definidas. Se o modelo de testes pode ser processado formalmente, os casos de teste podem ser derivados mecanicamente. Este modelo normalmente traduzido em uma mquina de estados finita que represente as possveis configuraes do sistema.
y

Mquinas de Estados Finitos -> uma mquina hipottica que composta por estados e transies. Cada uma dessas transies liga um estado aa um estado b, podendo ambos serem o mesmo estado. A cada instante a mquina pode estar

em apenas um estado, e a cada evento de entrada gerado um evento de sada, mudando assim de estado. O evento de sada e o novo estado so definidos somente em funo do estado atual e do evento de entrada. Esta mquina pode ser transmitida tanto por um diagrama de transio de estados quanto por uma tabela de transio. Exemplos:

Figura 2 Diagrama de transio de estados

Entrada/Sada 1 2 3 4

* ignore empty-bf acc-bf acc-bf

/ ignore ignore acc-bf

* / V

ignore 1 2 1 ignore 3 2 1 acc-bf 4 3 3

deacc-bf;print acc-bf 4 1 3

Tabela 2 Tabela de transio de estados Aps definir se o conjunto de estados atingveis de uma mquina de estados finito, possvel responder a quase todas as questes sobre o modelo, facilitando assim o processo de validao. Porm as classes de sistema que podem ser modeladas so consideravelmente limitadas, pois o modelo resultante pode ser extenso. Os mtodos para gerar casos de testes so baseados em algumas sequncias bsicas buscando obter um resultado significativo. IV - TESTE FUNCIONAL 4.1 - VISO INICIAL Por teste funcional, entendemos os testes cujo foco testar todos os componentes essenciais de um sistema sob o ponto de vista funcional. Ou seja, testar as funes de software de um componente. Os testes funcionais, sob a tica da anlise de

um sistema, dizem respeito aos testes realizados em funes do negcio e das funes e recursos do sistema. Todavia, preciso entender que os testes funcionais no dizem respeito nica e exclusivamente a testes de funes de uma interface, ou testes de funcionalidade de um sistema. Tambm chamado de teste funcional o teste que realizado em um nvel mais granular, ou seja, testes direcionados a funcionalidades de um componente qualquer de um software, como por exemplo, uma biblioteca DLL. Nesse caso, habitualmente prefere-se chamar o teste de teste unitrio, e s vezes esquece-se de que esse tipo de teste em potencial um teste funcional. Vrias definies podem ser dadas para que se entenda a que o teste funcional se prope. Podemos dizer que o tipo de teste com objetivo de medir a qualidade funcional de componentes de um sistema, ou que o teste funcional consiste em confrontar o que o sistema faz com o que ele se prope a fazer exatamente como ocorre na especificao de requisitos do sistema. Por fim, o teste funcional busca assegurar a funcionalidade do sistema, incluindo entrada de dados, processamento e resposta.

Tabela 3 Tipos de teste de caixa-preta

O teste funcional faz uso de testes de caixa preta, em termos comparativos. So usados o Teste de Valor Limite e o Teste de Equivalncia, entre outros, como mostra a figura 1.1, a seguir. A principal finalidade do teste funcional validar e testar os requisitos funcionais. A realizao dos testes, detalhadamente falando, consiste na seguinte frmula: sero executados cada caso ou funo e seus fluxos de uso, mediante a elaborao de casos e cenrios de teste, fazendo uso de dados vlidos e invlidos para verificar se os resultados esperados (comportamento e resposta da aplicao) ocorrem quando dados vlidos (e invlidos) so usados. Deve-se verificar se as mensagens de erro apropriadas so indicadas quando dados e aes invlidas so usadas. Portanto, deve-se verificar se cada regra do negcio corretamente aplicada. 4.2 - IMPORTNCIA DOS TESTES FUNCIONAIS

importante lembrar que todo e qualquer sistema projetado, desenvolvido e usado por algum que precisa e que financiou o nascimento desse sistema. Sendo assim, se o sistema no for testado de forma correta ou de forma completa, levando em conta que foi requerido, todos os envolvidos no negcio sero prejudicados. Tanto quem financiou o sistema como quem o desenvolveu ou testou. Em vista disso, importantssimo que se teste no mnimo as funes do sistema, ou seja, que os testes funcionais sejam bem feitos. A figura 1.2 abaixo ilustra alguns dos objetivos aos quais se pretende alcanar atravs do uso dos testes funcionais:

Fi

3 Objeti

do teste funcional

http://testar.me/pages/testar_me_teste_funcional_regressao.html A defi i de um processo cont com a defini o de fases, responsabilidades,

papis, aes permitidas e no permitidas, produtos de entrada e sada, etc. Definir um processo um trabal o de pura e simples l ica. A l ica ento al o importantssimo para a criao de casos de teste, j detal amento e entendimento. que para isso, trabal a-se com deduo,

4.3 - DEFINIO DE T NICAS DE CRIAO DE TESTES FUNCIONAIS Existem boas prticas recomendadas para que se descubra qual a mel or tcnica para construir bons casos de teste. Esta sesso discorrer sobre al umas dela e o modo como os testes indicados deve ser reali ado ser explicado posteriormente. y A criao de requisitos de teste facilita a definio da tcnica de teste a ser usada no projeto e na execuo do caso de teste; y Ler a documentao que se tem e caso ela no exista, definir em linhas gerais o que precisa ser testado; y Caso j tenham sido definidos Casos de Uso, use-os como base para a definio de seus Casos de Teste; y Se o sistema contiver estados que precisem ser testados (ex.: usurio ativo, inativo ou bloqueado), use o teste de transio de estado;

Se a tela-alvo de teste possuir campos, mas sem muitas situaes que se entrelacem (ex.: campo A depende do campo B que depende do campo C), basta usar combinaes. Pode-se usar neste caso, o teste de array ortogonal e inserir mais algumas combinaes que voc achar pertinentes; Se a tela-alvo possuir vrios campos com muitas situaes que se entrelaam, por exemplo, com muitas regras de negcio, necessrio fazer as combinaes pertinentes em funo das regras que seu teste pede. aconselhvel usar teste por tabela de decises, se o nvel de complexidade for alto ou mdio; Cada campo deve ser testado com situaes de teste que contemplem o teste do valor limite. Com isso, so testados e validados os valores de fronteira usados em cada campo; Se os casos de teste forem extrados de regras ou conjunto de regras, interessante usar o teste de equivalncia de classe; Caso seja necessrio testar e validar valores que trabalhem com domnios ou conjuntos e que tenham regras matemticas envolvidas, interessante usar o teste de anlise de domnio; Lembrar-se de testar o envolvimento do Banco de Dados, caso ele exista. Dados lidos, eliminados e gravados devero ser testados; Insira casos de teste que permitam verificar e comparar logs das aplicaes envolvidas. Isso pode ajudar muito na descoberta ou comprovao de erros; Combine os testes levantados a partir da tcnica adequada com os testes vitais levantados a partir de regras de negcio essenciais;

4.4 - ESCREVENDO REQUISITOS E CASOS DE TESTES 4.41 - VISO GERAL A elaborao dos requisitos consiste em colocar o que se quer testar no papel, definindo o que se deseja e at onde se quer ir, em termos de teste. um dos maiores problemas aps a elaborao do modelo de testes. Dependendo da qualidade do requisito, sero realizadas estratgias diferentes para os testes. Elaborar um caso de teste

a partir de requisitos de teste muito fracos ou at test-los sem que ningum tenha definido um requisito de teste uma tarefa bastante complexa. difcil conseguir essas informaes quando elas esto espalhadas em diversos documentos, ou quando est apenas na cabea das pessoas. Para ajudar, mais adiante sero descritas boas prticas para a escrita dos casos de teste. Mas antes de prosseguir, definiremos alguns conceitos bsicos em testes, visto que so facilmente confundidos:
y

Planejamento de teste: Processo de planejamento do teste em si, definido no modelo do teste. Depende da aplicao em questo, mas podemos citar como exemplo um plano de teste comum constitudo da definio do escopo do teste, definio de requisitos e definio dos casos de teste. Plano de teste: o fruto do planejamento do teste. Requisito de teste: Tudo aquilo o que se deseja testar, sendo o objetivo em si do teste. Pode ser desdobrado em mais de um objetivo ou em sub-objetivos. Caso de teste: Situaes de teste em nvel detalhado, podendo abranger um ou mais requisitos de teste. Procedimento de teste: Conjunto de aes ou passos para se realizar um teste Passo de teste: Ao singular para se realizar um teste. Normalmente compe um procedimento ou caso de teste. Script de teste: Procedimento de teste implementado atravs de uma ferramenta de automao de testes. uma linguagem que foi gravada em um arquivo com aes para repetio do teste pela ferramenta de automao. Ponto de verificao: um teste ou uma verificao definida em um procedimento de teste ou em um script de teste. Execuo de teste: Consiste na execuo manual ou automatizada de um teste. Resultado de um teste: o resultado de um teste, manual ou automatizado. O teste pode passar ou falhar.

y y

y y

y y

4.42 - LEVANTAR E ESCREVER REQUISITOS DE TESTE Existe uma fronteira tnue entre casos e requisitos de teste, que depende do grau de profundidade do plano de teste gerado. Isso um dos maiores problemas ao definir um requisito de teste e confunde muito os analistas de teste.

Os requisitos de teste sero levantados de documentos formais, especificaes de usurios, necessidades do sistema, casos de uso, etc. Um requisito de teste como um requisito qualquer, sendo apenas voltado para teste. A escrita dos requisitos de teste deve ser feita de forma clara, objetiva e simples. No pode haver ambiguidade, ou o requisito pode ser entendido de forma errada, gerando casos de teste errados. Deve ser de fcil entendimento, claro e deve conter as devidas explicaes. Quanto mais um requisito detalhado, mais se aproxima dos casos de teste. natural que os requisitos sejam dispostos em uma rvore hierrquica, onde teremos requisitos pais e filhos. Ser descrita a seguir, a composio da estrutura de requisito de teste:
y

Identificao do requisito de teste: Um nmero ou um identificador nico do requisito de teste; Descrio: Sumria e detalhada; Status: a posio atual no ciclo de vida de um requisito de teste. O status pode ser criado, atualizado, finalizado, aprovado, implementado, fechado, etc.; Relacionamentos e Dependncias: Relacionamentos e dependncias para com requisitos e casos de teste;

y y

4.43 TESTAR COM REQUISITOS DE TESTES FORTES OU MADUROS Existem fatores simples que devem ser avaliados a fim de constatar se um requisito ou no forte ou maduro. Esses fatores so:
y

O portugus do texto do requisito deve estar correto em termos ortogrficos, claro e o mais objetivo possvel; O texto deve estar adequado realidade a qual prope representar; O texto no deve estar ambguo. Caso o texto apresente mais de um significado, deve detalhar o que o termo significa de forma que no haja duplo sentido;

y y

O texto do requisito deve ser nico, ou seja, o que for representado no deve ser ambguo em relao a outros requisitos; O texto do requisito deve ser completo. Caso falte algo, com certeza ocorrero problemas de projeto, desenvolvimento ou implementao devido a informaes que faltam; O requisito deve ser verdadeiro, devendo ter os subitens confirmados;

Caso o requisito atenda a todos os fatores citados, ou no mnimo maioria deles, poderemos afirmar que o requisito ser tendenciosamente ou efetivamente forte. necessrio que o texto de um requisito forte seja lido com calma. Quanto maior o texto, mais complexa se torna a sua leitura e mais passvel de falhas e erros de entendimento. Uma boa sada dividi-lo em requisitos menores, porm claros. 2.4 - TESTAR COM REQUISITOS FRACOS

Figura 4 Lidando com requisitos fracos Um requisito ser considerado fraco caso sejam encontrados todos ou a maioria dos seguintes tpicos:

O portugus do texto do requisito est incorreto em termos ortogrficos ou no est claro e objetivo; O texto no est adequado realidade qual prope representar; O texto est ambguo; O texto do requisito no nico; O texto do requisito no est completo; O texto do requisito est ambguo; Requisito falso;

y y y y y y

Para testar um requisito fraco, necessrio explorar o mximo de possibilidades e situaes de testes de maneira a compensar a imaturidade dos requisitos. Assim sendo, h uma grande chance de criarmos vrios casos de testes que tero pouca importncia. Apesar da aparente perda de tempo, sem essa prtica, a quantidade de falhas do software crescer vultuosamente devido desateno para com os requisitos.

4.44 TESTAR SEM REQUISITOS DE TESTE Em algumas situaes, o mximo que se tem so telas ou funes que se quer testar. Assim sendo, o que podemos fazer criar requisitos de teste genricos, de maneira que se possa iniciar algum marco de referncia para os testes. Para que possamos minimizar a falta de requisitos, podemos procurar a documentao do programa a ser testado, mesmo que antiga ou desatualizada. Se possvel, podemos olhar o cdigo-fonte da aplicao para fazer uma engenharia reversa, mesmo que parcial, e ver comentrios. Alm disso, o melhor a se fazer conversar com algum que entenda da aplicao, sejam usurios, desenvolvedores ou at testadores experientes da aplicao. Em um primeiro momento, aps definir esses requisitos iniciais, o que se pode fazer criar os casos de teste de forma cada vez mais madura. Ao longo desse processo, sero criados requisitos novos e maduros, o que facilitar o processo de testes. 4.45 LEVANTAR E ESCREVER CASOS DE TESTE Abaixo, sero descritos trs grandes caminhos para lidar com a criao de casos de teste:

Primeiro caminho partindo dos requisitos:

Temos trs grupos de casos de testes

que precisam ser levantados. No precisamos preencher todos esses grupos 100% em amplitude e profundidade, mas todos devem ser vistos, porque na prtica, a quantidade e importncia dos testes podem variar entre cada grupo ou cenrio de testes. Assim, apresentamos os cenrios:
y

Cenrios de teste no caminho principal: composto pelo grupo de caso de testes envolvidos nas situaes mais comuns de uso do sistema-alvo de teste. feita uma referncia aos principais requisitos de teste ou caminho bsico de um caso de uso. Simplificadamente, os testes so realizados nas aplicaes que o usurio normalmente usa; Cenrios de teste no caminho alternativo: so os testes das variaes dos caminhos bsicos ou principais, sem fugir dos possveis fluxos de execuo da aplicao. Seriam tambm os fluxos alternativos ou testes de requisitos de menor importncia; Cenrios de teste de exceo: testes de situaes de possveis problemas ou excees, que atrapalham ou impedem o funcionamento da aplicao. Representam tambm testes de situaes que impedem ou atrapalham o fluxo normal de uso da aplicao;

Segundo caminho utilizando tcnicas de caixa-preta: Aqui entraro as tcnicas especficas de testes funcionais, sendo usadas as tcnicas de caixa-preta, para que sejam elaborados mais casos de teste. Sero utilizados testes de valor limite e outras tcnicas, as quais no sero abordadas nesse tpico j que o captulo seguinte as explicar detalhadamente. Terceiro caminho tcnicas gerais: Aqui sero levantados os casos de testes focando na execuo de objetivos especficos, como a forma de manipulao de situaes criadas no primeiro e segundo caminhos. As mais usadas so:
y

Teste de regresso: So executados testes de verso anterior na nova verso de um aplicativo, de modo a certificar que o que est na aplicao continua correto; Errorhandling: Sero introduzidos erros de forma intencional no teste, para avaliar assim o comportamento da aplicao. Similar aos testes em cenrios de exceo, com a diferena de serem mais detalhados e menos ligados s funcionalidades da aplicao;

Paralelismo: Existe quando a aplicao antiga e a nova esto presentes ao mesmo tempo, sendo feita a comparao dos resultados dos testes de ambas; Recuperao: Esse teste analisa se o que est no backup do banco de dados pode ser recuperado e utilizado corretamente. A recuperao pode ser parcial ou total;

Quanto validao dos acessos da aplicao ao banco de dados, importante que seja criado um caso de teste, ou que se coloque um passo dentro dos respectivos casos de testes com essa funo. Assim, se pode verificar se o dado de trabalho est correto, ou seja, se foi lido, inserido e atualizado no banco de dados. Isso realizado em funo de garantir a integridade da informao, visto que muitas vezes a aplicao faz a operao correta, mas deixa errado no banco de dados. Citaremos agora, a estrutura dos casos de teste para que os mesmos sejam escritos formalmente. Um caso de teste formal deve conter os seguintes itens:
y y y y y y y y y y

Identificao do caso de teste: Nmero ou identificador nico do caso de teste; Dados: Informaes utilizadas no caso de teste; Pr-condies: Condies indispensveis para que o caso de teste seja escrito; Ps-condies: Condies indispensveis derivadas do caso de teste j escrito; Resultado da execuo: Indica se o teste passou ou no, e por qu; Ambiente: Informaes e configuraes de ambiente necessrias ao teste; Tipo de implementao: Se o caso de teste automatizado ou no; Prazo de execuo esperado: Cronograma, datas, etc.; Execuo realizada: Quem realizou a execuo, em que data, etc.; Status: Posio no ciclo de vida de um caso de teste (ex.: criado, atualizado, finalizado, aprovado, executado, fechado, etc.); Relacionamentos e dependncias: Relacionamentos e dependncias para com os requisitos e casos de testes;

4.46 CASOS DE TESTES FORTES VERSUS CASOS DE TESTES FRACOS Devemos encontrar um meio de distinguir se determinado caso de teste forte ou fraco. Para isso, podemos fazer uso da mesma estratgia usada em requisitos de teste. Um caso de

Teste ser considerado fraco tomando como base as seguintes premissas:

y

O portugus do texto do caso de teste est incorreto em termos ortogrficos e/ou no est claro e objetivo; O texto no est adequado realidade qual se prope representar; Caso de teste falso; No contm especificamente todos os passos para se realizar um teste No contm especificamente os dados de teste necessrios para se realizar um teste.

y y y y

No sendo identificado como fraco, notoriamente ser maduro ou forte. Um caso de teste forte ajudar muito na execuo do teste. Erros de portugus ou um texto que no claro dificulta para quem testa, e tambm a documentao e qualidade do projeto. 4.47 COMO DERIVAR CASOS DE TESTES DE CASOS DE USO Os requisitos de um sistema, no que se refere ao desenvolvimento de software, so definidos pelos casos de uso. De acordo com a metodologia RUP (RationalUnefiedProcess da IBM/Rational), pode-se dizer que um caso de uso descreve inteiramente uma sequncia de aes executadas por um sistema para fornecer um resultado observvel do valor a uma pessoa ou a um outro sistema usando o produto em desenvolvimento. Para os clientes e usurios, os casos de uso mostram o que esperar do sistema. Para o colaborador, o que desenvolver e transformar em cdigo. Ao responsvel pela documentao, o que documentar e ao analista de qualidade ou de testes, o que testar. A metodologia UnifiedModelingLanguage UML (Linguagem Modelo Unificada) o que d base aos casos de uso. Essa metodologia ilustrada na figura 1.3 abaixo: Figura 5 Viso geral do caso de uso usando UML Pgina 139 Mollinari As elipses representam os casos de uso e as figuras de bonecos representam os atores que podem ser seres humanos ou sistemas. As linhas representam a comunicao entre um ator e um caso de uso. Esse diagrama foi idealizado atravs da figura acima, sendo que cada caso de uso representa uma grande parte da funcionalidade

que est sendo executada e cada ator representa algum ou algo fora de nosso sistema, que interage com o mesmo. importantssimo salientar que cada caso de uso requer uma quantidade significativa de texto para descrev-lo. Esse texto pode ser formatado em sees, como mostrado a seguir:
y y y

Nome: Nome adequado ao caso de uso Descrio breve: Descrio sucinta da funo e da finalidade do caso de uso Fluxo de eventos: Consiste em uma descrio textual do que o sistema faz em relao ao caso de uso. Deve ser compreensvel por todos, principalmente pelo usurio ou cliente. Normalmente divide-se em trs fluxos bsicos:
y y

Fluxo bsico dos eventos: fluxo normal de execuo dos eventos; Fluxos alternativos: fluxos alternativos de execuo dos eventos, tomando como referncia o fluxo bsico Fluxo de exceo: fluxos de exceo de eventos onde erros ou falhas possam vir a interromper os fluxos normais ou de exceo Exigncias especiais: descrio textual que colete todas as exigncias, tais como as exigncias no funcionais que precisem de qualquer cuidado ao longo do projeto; Pr-condies: descrio textual que define todas as exigncias para que o caso de uso possa se iniciar Ps-condies: descrio textual que define todas as exigncias para que o caso de uso possa ser finalizado com sucesso.

Para a gerao de um caso de teste atravs de um caso de uso, a parte mais importante a ser analisada o fluxo de eventos. deles que extrairemos casos de teste que cubram o caminho normal do fluxo de execues. Os caminhos alternativos de fluxo e de erro na aplicao sero mostrados pelos fluxos alternativos e de exceo. Um caso de uso precisa ter as seguintes caractersticas para que possa ser bem testado: poder ser lido, estar correto, estar atualizado, ser especfico, ser compreensvel, estar completo, ser estvel e ser documentvel. Apresentando essas caractersticas, detectamos duas formas de derivar casos de teste a partir de casos de uso, as quais sero descritas a seguir:

Descrio textual: acontece com o mapeamento de cada caminho, sendo que cada caminho identificado ser traduzido em um requisito de teste. As variaes que ocorrerem em cada caminho definir um conjunto de casos de teste. Descrio visual: importante que faamos uma representao visual de todos os fluxos de desenho juntos. A partir desse desenho, rascunharemos todos os caminhos existentes. Cada caminho encontrado representar uma situao qualquer que pode acontecer. Assim sendo, cada caminho resulta em um requisito de teste. Para uma boa derivao visual, teremos ento que definir quantos caminhos existem, se esses caminhos satisfazem aos casos de uso, se os testes so viveis, justificados e significantes, e definir novos casos de teste, caso necessrio. 4.5 Concluso Um projeto de requisitos e casos de testes mal feito gera uma imensa chance de produzirmos um software com defeitos. Um defeito em um software de um banco, por exemplo, pode ser no apenas desconfortvel para o usurio como pode causar erros de propores calamitosas. Este captulo apresentou boa descrio acerca de requisitos e casos de teste, sendo descritas boas prticas para melhor escrev -los, em funo de realizar os testes em conformidade com aquilo que o software se prope a fazer, evitando muita dor de cabea tanto para a equipe de desenvolvimento quanto para o usurio final.

V - TCNICAS DE TESTE FUNCIONAL 5.1 - VISO INICIAL Trataremos no referido captulo, de tcnicas de testes funcionais do tipo caixapreta, testando o objeto alvo - que pode ser uma biblioteca DLL, um componente,

uma parte da aplicao, ou a aplicao em si, entre outros - sob o ponto de vista de suas entradas e sadas. Esses testes podem ser criados e aplicados em nvel de teste de unidade, teste de integrao, teste de sistema e teste de aceitao do usurio. De incio, ficam claras uma desvantagem e uma vantagem dos testes de caixa-preta. Como desvantagem, podemos citar que o teste no consegue garantir que todas as linhas do cdigo tenham sido testadas, j que no se tem viso sobre as linhas de cdigo que sero executadas. Por mais que testemos entradas e sadas, a execuo completa no ser garantida. O que o teste funcional faz se direcionar aos conjuntos de problemas mais significativos. Ele garante dessa forma, maior eficincia e eficcia ao conjunto de testes, encontrando mais defeitos e maximizando o retorno de investimento de tempo e alocao de pessoal.

5.2 TESTE DE EQUIVALNCIA DE CLASSE (EquivalenceClassTesting) Essa uma tcnica simples e que deve ser usada de forma intuitiva, trabalhando por deduo lgica. Apresenta como principal objetivo diminuir o nmero de casos de teste. Segundo Leonardo Molinari, em seu livro Teste Funcional, podemos definir o teste de Equivalncia de Classe da seguinte maneira: O Teste de Equivalncia de classe uma tcnica de reduo da quantidade de casos de testes (ou de dados de testes) que se baseia em descobrir em termos lgicos, conjuntos de situaes (ou classes) que produzam ou gerem o mesmo comportamento na aplicao. Ao descobrir essas classes, para efeito de teste, basta ter um (ou pouco mais de um) caso de teste (ou dado de teste) que represente essa situao. Exemplificando, imagine que hoje ocorrer um show de rock da banda Pearl Jam em Goinia, no estdio Serra Dourada. Nossa equipe de desenvolvimento foi chamada para fazer um software para o evento. Algumas das regras do negcio so as seguintes: O preo do ingresso ser de R$ 20,00 para quem chegar das 18:00:00

horas s 19:59:59 horas, aumentando para 30 reais para quem chegar das 20:00:00 s 21:59:59 horas, e para 50 reais das 22:00 horas at as 23:59:59 horas. Temos ento que, se horrio >= 18:00:00 e horrio <= 19:59:59, o preo = 20,00. Se horrio >=20:00:00 e horrio <= 21:59:59, preo = 30,00. Se horrio >=22:00:00 e Horrio <= 23:59:59, o preo = 50,00.
Horrio 18:00:00 at 19:59:59 20:00:00 at 21:59:59 22:00:00 at 23:59:59 Preo R$ 20,00 R$ 30,00 R$ 50,00

Tabela 4: Relao entre horrio e preo do evento

Dados esses valores, conseguimos enxergar que ser feita a anlise de uma classe que contm um conjunto de valores contnuos, ou seja, valores racionais Q. Assim sendo, deve-se fazer uso do teste de equivalncia de classe contnuo. Para testar essa funo do software, a priori teramos que testar todos os valores de tempo contidos no domnio, ou seja, para descobrir se o valor pago ser igual a R$ 20, obteremos todos os horrios possveis nos quais o valor do ingresso seria de R$ 20 reais, ou seja, {18:00:00, 18:00, 18:02, ..., 19:59:59}. Isso faz sentido, mas extremamente desgastante, e pode aumentar exponencialmente o tempo do teste. O que o teste de Equivalncia de Classe prope nesse caso, que testemos apenas um valor de cada domnio existente. Ou seja, para o preo de 20 reais, testaramos uma nica entrada entre as 18:00:00 horas e as 19:59:59 horas, como por exemplo 19:28:37 horas, analisando se a sada conta com o valor de 20 reais, e realizaramos o mesmo procedimento, usando com um s valor de teste com um horrio dentro do domnio (intervalo de tempo) para cada um dos valores do ingresso, verificando a obteno do valor correto. A classe de equivalncia, nesse caso, pode ser contnua ou discreta. Quando contnua, a classe possui um conjunto de valores contnuos(todo aquele que pode ser representado por uma frao) , assim como foi mostrado no exemplo anterior,. Pode tambm ser discreta, ou seja, os valores so discretos e nicos, como no caso de

nmeros inteiros (1, 2, 3...). Segue agora um exemplo de teste de classe de equivalncia discreto. Suponhamos que para esse show, o estado fornea capital para o evento de acordo com algumas exigncias prescritas pela Lei de Incentivo cultura. Dentre essas exigncias, existe a de que o pblico presente deve ser superior a 1.000 pagantes. Temos ento, que, se pagantes>=0 e pagantes <=999, a Lei de Incentivo Cultura nega o capital do evento, e o capital liberado se pagantes >= 1.000 pessoas Isso significa que faremos uma anlise de uma classe que possui um conjunto de valores discretos e nicos, ou seja, nmeros inteiros. Quando isso acontece, fazemos uso do teste de equivalncia de classe discreto. Para tal, testaremos apenas um valor compreendido entre os limites do domnio. Se pagantes >=0 e pagantes <= 999, podemos testar qualquer valor nesse intervalo, como por exemplo, 11. Se pagantes >= 1.000, tambm podemos testar qualquer valor deste domnio, como 1.500. Essa tcnica pode ser aplicada a testes em nvel unitrio, de integrao, sistmico ou em nvel de teste de aceitao de usurio. Basta ter entradas e sadas obtidas atravs dos requisitos do sistema, para que o teste seja realizado. 5.3 TESTE DO VALOR LIMITE (BoundryValueTesting) Para definir o teste do valor limite, tomaremos como base a seguinte definio de Roger S. Pressman no livro Engenharia de Software (6 edio): A anlise do valor-limite uma tcnica de projeto de casos de teste que completa o particionamento de equivalncia. Em vez de selecionar qualquer elemento de uma classe de equivalncia, o Teste do Valor Limite leva seleo de casos de teste nas bordas da classe. Em vez de focalizar somente as condies de entrada, ela deriva casos de teste tambm para o domnio de sada.

Essa tcnica muito importante, levando em considerao a existncia de um grande nmero de erros nas fronteiras do domnio de entrada. Isso ocorre muito em funo de como os requisitos so definidos. Tomemos como exemplo a seguinte especificao: uma empresa no contrata funcionrios menores de 16 anos, contrata funcionrios de 16 a 18 anos para trabalhar at meio-perodo, de 18 a 50 anos para trabalhar integralmente, e no contrata funcionrios de 50 a 99 anos. Essa especificao pode gerar problemas para o programador, visto que no se sabe exatamente se o trabalhador com 18 anos trabalha apenas meio -perodo ou integralmente, e tambm no se sabe se com 50 anos a pessoa pode trabalhar integralmente ou se no aceita pela empresa. Aqui fica evidente a importncia do teste de anlise de valor limite, para saber como o sistema lida com esses valores, e se o faz da forma que deveria. Para verificar os limites dessa aplicao, se idade >=0 e idade <= 15, o funcionrio no deve ser contratado. Se idade >= 16 e idade <=17, o funcionrio pode ser contratado para trabalhar meio perodo. Se idade >= 18 e idade <= 54, o funcionrio pode trabalhar em tempo integral. Se idade >= 50 e idade <= 99, o funcionrio no pode trabalhar.
Idade 0 a 15 anos 16 a 17 anos 18 a 49 anos 50 a 99 anos Contrato No realizado Meio-perodo Tempo Integral No realizado

Tabela 5 Relao entre idade e legalidade de contrato

Isso significa que faremos uma anlise de uma classe que possui um conjunto de valores discretos e nicos, ou seja, nmeros inteiros. Quando isso acontece, fazemos uso do teste de valor limite discreto. Assim sendo, testaremos os valores para a fronteira inferior {-1, 0}, {15,16}, {17,18} e {49,50}. Na fronteira superior, testaremos os valores {15,16}, {17, 18}, {49,50} e {99,100}.

Observamos que alguns dos valores se repetiram. Os valores repetidos podem ser eliminados. Ficaremos ento com os seguintes valores para teste de valor limite: { 1,0}, {15,16}, {17,18}, {49,50} e {99,100}. Em um novo exemplo, podem-se analisar o salrio de um empregado qualquer da empresa de produo de petrleo Tupzinho. Dependendo do cargo e do nmero de horas-extra de trabalho de um empregado, ele pode receber entre R$ 1.600,00/ms a R$ 9.600,00/ms. Isso significa, que salrio >= 1.600,00 e salrio <=9.600,00. Dados esses valores, conseguimos enxergar que ser feita a anlise de uma classe que contm um conjunto de valores contnuos, ou seja, valores racionais Q limitados pela quantidade de casas decimais. Quando isso acontece, fazemos uso do teste de valor limite contnuo. Nesse caso, testaramos na fronteira inferior, os valores {R$ 1.599,99; R$ 1.600,00; RS 1.600,01} e para a fronteira superior, {R$ 9.599,99; R$ 9.600,00; R$ 9.600,01}. O teste de valor limite pode ser aplicado quando lidamos com testes de nvel unitrio, de integrao, sistmico ou em nvel de teste de aceitao de usurio. A aplicao do teste necessita apenas das entradas e sadas que podem ser obti as d atravs dos requisitos do sistema. 5.4 TESTE POR TABELA DE DECISO (DecisionTableTesting) uma tcnica de testes aplicvel e recomendada quando, no produto de teste, se tem muitas regras e conjuntos de aes que se interligam. Essa tcnica busca, atravs do uso de tabelas, formar um conjunto de casos de testes em para deixar claro um conjunto de regras e aes envolvidas na referida tabela. Essa tabela, chamada tabela de deciso, consiste basicamente na seguinte estrutura:
Regra 1 Condies Regra 2 ... Regra m

Condio-1 Condio-2 ... Condio-m Aes Ao-1 Ao-2 ... Ao-n

Tabela 6 Exemplo 1 de tabela de deciso Esquecendo a aplicabilidade da tabela em situaes que envolvem muitas regras interligadas, citaremos um exemplo simples apenas para entendimento. Suponhamos que o senhor Mrio queira contratar uma diarista. Constri ento a seguinte tabela:

Regra 1 Condies Honesta? Disposta? Bonita? Aes Salrio Guardar Fone R$ 440,00 No Sim Sim No

Regra 2 No Sim Sim R$ 0 No

Regra 3 Sim No Sim R$ 520,00 Sim

Regra 4 Sim Sim Sim R$ 560,00 Sim

Tabela 7 Exemplo 2 de Tabela de Deciso

A tabela em questo um simples exemplo de tabela de deciso de testes que conta com duas aes (Salrio e Guardar Fone). Informaes mais relevantes ainda podem ser inseridas na tabela, aumentando sua complexidade, por exemplo da seguinte maneira:

Caso de Teste 1

Caso de Teste 2

Caso de Teste 3

Caso de Teste 4

Condies Condio-1 Condio-2 Aes Ao-1 Ao-2 Faa A Faa X Faa B Faa X Faa A Faa Y Faa B Faa Y 0 10 <35 10-50 35 50 - 100 99 ou 100 100 1000 101 107

Tabela 8 Exemplo 3 de tabela de deciso

Se considerarmos que essas regras so casos de teste, podemos pensar em uma tabela de deciso convertida em uma tabela de caso de testes. Os ttulos das colunas se tornam casos de teste, como no exemplo abaixo:
Caso de Teste 1 Condies Condio-1 Condio-2 Aes Ao-1 Ao-2 Faa A Faa X Faa B Faa X Faa A Faa Y Faa B Faa Y Sim Sim No Sim Sim No No No Caso de Teste 2 Caso de Teste 3 Caso de Teste 4

Tabela 9 Exemplo 4 de tabela de deciso

Atravs dessa tabela, observamos trs condies que interagem de modo a produzir duas aes, ou dois conjuntos de aes quaisquer. Finalmente, atravs da tabela acima, podemos pensar numa forma mais direta de reproduzir os casos de testes.
Caso de Teste ID CT1 CT2 CT3 CT4 Condio 1 0 22 51 102 Condio 2 12 35 100 107 Resultado Esperado Faa A / Faa X Faa B / Faa X Faa A / Faa Y Faa B / Faa Y

Tabela 10 Exemplo 5 de tabela de deciso

A tcnica de teste por tabela de deciso deve ser aplicada quando existirem muitas regras de negcio, complexas, onde existam muitas regras dependentes umas das outras. A tabela ajuda a organizar os testes. importante observar, no entanto,

que se a quantidade de regras e aes envolvidas for muito grande, ser gerada uma quantidade de casos de teste muito grande, podendo tornar o teste invivel. Para tal situao, indicado o uso da tcnica seguinte chamada PairwiseTesting. 5.5 PAIRWISE TESTING (Array Ortogonal) Existem aplicaes nas quais existe um domnio relativamente pequeno a ser testado, embora seja grande demais para acomodar um teste exaustivo. Para esses casos, podemos usar o teste de ArrayOrtogonal. Segundo Leonardo Molinari em seu livro Testes Funcionais de Software, obtemos a seguinte definio:
O teste de ArrayOrtogonal tem o objetivo de agregar um conjunto de casos de teste significativo dentro de um conjunto invivel de combinaes de citaes que, na prtica, tomaria muito tempo para se testar.

Esse teste consiste em identificar as variveis de teste, determinando o nmero de possibilidades de cada varivel, localizar no array ortogonal qual coluna corresponde a qual varivel, mapear o problema no array ortogonal, e finalmente construir os casos de teste. A tcnica deve ser aplicada principalmente quando existirem muitas regras de negcio, em especial com muitas variveis, e a quantidade de combinaes for invivel para teste. Para melhor entendimento deste teste, vejamos a tabela a seguir:

Fator Teste 1 2 3 4 1 0 0 1 1 2 0 1 0 1

Tabela 11 Tipos de teste considerando fatores (Matriz Ortogonal)

Cada coluna significa um item de configurao, e cada linha so os casos de teste, ou seja, a combinao de valores. Por exemplo: deve-se testar um sistema fator 1 seria o Sistema Operacional (onde os dois itens existentes so: Windows XP e Linux) e o fator 2 o Navegador (onde os dois itens so: Firefox e Internet Explorer). A tabela ficaria assim:

Fator Teste 1 2 3 4 Sistema Operacional Windows XP Windows XP Linux Linux Navegador Firefox Internet Explorer Firefox Internet Explorer

Tabela 12 Definindo testes para Sistema Operacional e Navegador

Figura 3.2 Matriz Ortogonal Passo 2

Todos os fatores da coluna um devem ser combinados com todos os fatores da coluna dois que devem ser combinados com a coluna trs e assim por diante. A ilustrao da tabela a seguir mostra a eficincia dessa tcnica Se fssemos fazer um mximo de combinaes, trs fatores com dois itens cada, resultariam em seis casos de teste. Portanto, utilizando a tcnica, esses valores diminuem para quatro. Veja como:
Fator Teste 1 2 3 4 1 0 0 1 1 2 0 1 0 1 3 0 1 1 0

Tabela 13 Adicionando um fator de teste

Matriz Ortogonal Passo 3 Adaptando o exemplo anterior, supe-se que o terceiro fator seria o tipo de conexo (banda larga e wireless), ento, a tabela ficaria assim:
Fator Teste 1 2 3 4 SO Windows XP Windows XP Linux Linux Navegador Firefox Internet Explorer Firefox Internet Explorer Conexo Banda Larga Wireless Wireless Banda Larga

Tabela 14 Definindo o que testar com o novo fator

Matriz Ortogonal Passo 4

Perceba que todos os valores da tabela combinam, em pares, com todos os valores da tabela: - Windows XP combina com Firefox e Internet Explorer (coluna dois) e com Banda larga e Wireless (coluna trs). A mesma relao ocorre para o Linux. - Firefox combina com Windows XP e Linux (coluna um) e com Banda larga e Wireless (coluna trs). A mesma relao ocorre para o Internet Explorer. - Banda larga combina com Windows XP e Linux (coluna um) e com Firefox e Internet Explorer (coluna dois). A mesma relao ocorre para o Wireless.

5.6 - TESTE DE TRANSIO DE ESTADO S(State-TransitionTesting) O teste de Transio de Estados realizado quando um aspecto qualquer do sistema pode ser descrito fazendo uso de uma mquina de estados, ou seja, um autmato. Um autmato pode ter um nmero finito de estados diferentes, e as transies de um estado para outro so determinadas por regras da mquina. Os testes com autmatos podem ser construdos para cobrir uma sequncia tpica de estados, cobrir todos os estados, exercitar todas as transies/aes, exercitar uma sequncia especfica de transies/aes ou testar transies/aes invlidas. Para tal, criado um Diagrama de Transio de Estados. Esses diagramas documentam os eventos que ocorrem em um sistema ou parte de um sistema. Em geral, quando existe um evento (ordem, comando ou ao) que leva o sistema a uma ao, atravs do diagrama, pode-se identificar se a sequencia executada est de acordo com a regra pretendida. Abaixo poderemos ver um diagrama de estados. No importante que expliquemos o diagrama em si, mas que os caminhos possveis sejam entendidos. Figura 7 Figura pgina 162 livro Mollinari A partir do referido grfico, podemos extrair uma tabela de transio de estados. Assim, podemos combinar aleatoriamente todos os estados, onde cada estado tem seu evento e aes correspondentes. A tabela mostrada na figura x.y.

Figura 8pgina 162 livro Mollinari

A partir da figura, uma propriedade interessante que cada linha inteira selecionada representa um caminho. Esse caminho compreende um fluxo de dados qualquer que iniciou seu percurso no estado inicial do autmato e foi processado terminando num estado final, sendo aceito ou negado. Se desses caminhos forem selecionados apenas aqueles que no possuem linhas invlidas - ou seja, aqueles que atendem regra do autmato sero encontrados poucos estados. Esses estados so exatamente os casos de teste. Nesse caso, as linhas selecionadas constituem os seguintes casos de teste: Figura 9 pgina 163 livro Mollinari O teste de transio de estado costuma ser muito utilizado em softwares industriais embarcados e automaes tcnicas em geral. Tambm adequado para modelar um objeto de negcio tendo estado especfico ou para testar fluxos de telas de dilogos. A aplicao dessa tcnica principalmente recomendada quando existirem vrias regras de negcios associadas a estados de objetos e suas transies. A tcnica deixa de ser recomendada quando os sistemas envolvidos no possuem, no trabalham ou no precisam de respostas em funo de eventos acionados em tempo real.

5.7 - TESTE DE ANLISE DE DOMNIO (Domain AnalysisTesting)

Imagine que tenhamos que testar variveis acompanhadas de vrias regras associativas, as quais estejam sujeitas a operadores relacionais. Se precisarmos obter um conjunto de casos de teste vlidos a partir dessas variveis, podemos fazer uso do teste de Anlise de Domnio. A tcnica de teste de anlise de domnio, segundo Molinari, uma tcnica que levanta casos de teste considerando valores exatos e de fronteira. Para melhor entendimento, analisemos a sentena {a >= 500}. Iremos ento, entender o

comportamento das preposies on, off e in, aplicando-as expresso em funo de entender seu domnio. Quando dissermos que um valor qualquer est on, estaremos dizendo que esse valor pertence exatamente fronteira. Isso significa que ele o primeiro valor vlido pertencente ao domnio da aplicao. No referido exemplo {a >= 500}, o nmero 500 satisfaz ao domnio da aplicao, encontrando-se exatamente no limite da fronteira. Ele pertence ao domnio, e considerado um valor on. Quando dissermos que um valor est off, estaremos dizendo que esse valor no pertence ao domnio da aplicao. Isso significa que o dado invlido em relao ao domnio escolhido. No referido exemplo {a >= 500}, todos os nmeros inferiores a 500 no satisfazem ao domnio da aplicao, ou seja, 499, 498, 497 e assim por diante. Esses valores inferiores a 500 ento, sero considerados como valores off. Finalmente, quando dissermos que um valor est in, estaremos dizendo que esse valor pertence ao domnio da aplicao, e no se localiza na fronteira. No dado exemplo, todos os valores maiores que 500, tais quais 501, 502, 503 e assim por diante, que pertencem ao domnio da aplicao sem estarem no limite da mesma, esto in. Aplicando ento essas combinaes a uma varivel qualquer, sujeita a determinada regra, cria-se uma matriz chamada matriz de teste de domnio. Um exemplo desse tipo de matriz pode ser visto abaixo: Tabela 15 Exemplos de uma matriz de teste de domnio Pgina 165 Molinari Pode ser aplicada em especial quando temos um teste com mltiplas variveis (como, por exemplo, input fields) que precisam ser testadas juntas por interagirem. Esta tcnica mais prpria para valores numricos, podendo ser generalizada para booleans, strings, etc.

Iterao e Persistncia.