INF 1413 Teste de Software

(1)

2016/2

3WA Segundas e quartas 17-19h sala L522

Prof. Arndt von Staa

e-mail: arndt /at/ inf.puc-rio.br

Página da disciplina: HTTP://www.inf.puc-rio.br/~INF1413 Horários de atendimento:

Não tenho horário de atendimento específico. Prefiro que o atendimento seja feito através de e-mail. Entre-tanto, sempre que necessário, podem me procurar na sala RDC420.

1. Ementa, no catálogo

Inspeção de software. Princípios e técnicas de teste de software. Teste de unidade. Teste de integração. Tes-te de regressão. Desenvolvimento dirigido por Tes-tesTes-tes. Automação dos Tes-tesTes-tes. Geração de casos de Tes-tesTes-te. Teste de interfaces com humanos. Teste de aplicações para Web. Teste alfa, beta e de aceitação. Ferramen-tas de teste. Planos de teste. Gerenciamento do processo de teste. Registro e acompanhamento de proble-mas.

2. Objetivos

● Habilitar o aluno a aplicar com eficácia os principais conceitos e métodos de controle da qualidade de software, visando as atividades: verificação, validação e aceitação; e envolvendo as técnicas: inspe-ção, teste convencional, teste automatizado e técnicas formais leves.

● Habilitar o aluno a organizar e gerenciar o processo de controle e garantia da qualidade de software.

3. Descrição

Precisamos poder depender de sistemas intensivos em software sem incorrer em demasiados riscos. Gran-de é a importância da qualidaGran-de do serviço prestado pelo sistema, e pequenos Gran-devem ser os custos tanto do seu desenvolvimento, como os decorrentes da sua adoção. Além de prestar um serviço de qualidade satisfa-tória, o software deve também poder ser evoluído e corrigido com facilidade e sem perda da qualidade. En-tre as muitas práticas e técnicas que visam atingir estes objetivos, encontra-se a garantia da qualidade do software que se baseia, entre outros, em boas práticas para desenvolvê-lo, evitando por construção que contenha defeitos, e no sistemático controle da qualidade do software.

O controle da qualidade possui diversas facetas, entre elas a de verificar se o software está em con-formidade com as suas especificações de requisitos funcionais e não funcionais, e, mais ainda, se está em conformidade com as reais necessidades e anseios explícitos e implícitos dos seus usuários. Para podermos verificar essas conformidades precisamos saber como inspecioná-lo e como realizar experimentos controla-dos, isto é testes, e precisamos saber como observar o comportamento do software em uso, prevenindo da-nos em caso de falhas observadas durante o uso produtivo.

Almeja-se que a qualidade seja atingida por construção, ou seja, como consequência da adoção de bons processos, boas práticas, boas ferramentas e eficazes padrões que, em conjunto, propiciem o desenvolvimen-to de software de qualidade satisfatória. Além de definir as práticas de desenvolvimendesenvolvimen-to e as da gerência do desenvolvimento, é necessário definir as práticas de controle da qualidade que deverão ocorrer junto com as diversas etapas do desenvolvimento.

(2)

espe-© Arndt von Staa INF1413_2016-2_Apresentacao.docx 24-ago-2016 A segunda parte da disciplina abordará testes de componentes e módulos software. De maneira ge-ral, testes são caros e demorados, e deixam remanescer defeitos. Testes são necessários, embora sejam inca-pazes de assegurar que todos os defeitos foram identificados e devidamente eliminados. Várias técnicas fo-ram desenvolvidas para melhorar a eficácia e a eficiência dos testes, tais como: desenvolver iterativamente o software; utilizar técnicas formais leves para especificar, verificar e testar; automatizar os testes; desenvol-ver software que se auto desenvol-verifica durante o uso; estabelecer a estratégia de teste e redigir os módulos de teste automatizado antes de desenvolver o software; gerar automaticamente os testes diretamente a partir da especificação; e utilizar melhores técnicas e critérios de seleção de casos de teste. Um grande desafio ho-je é desenvolver técnicas de teste eficazes, eficientes, e automatizáveis.

A terceira parte abordará técnicas e práticas que visam organizar o processo de teste, tanto como uma atividade integrada ao desenvolvimento, como uma atividade independente do desenvolvimento. Es-ta parte é difusa sobre o andamento da disciplina.

Entremeado a estes assuntos serão abordadas diversas propostas de práticas de desenvolvimento que têm por objetivo assegurar ou aumentar a fidedignidade por construção do software quando compa-rado com o estado da arte atual.

3.1. Bibliografia

Livro texto

PEZZÈ, M.; YOUNG, M.; Teste e Análise de Software. Porto Alegre: Bookman, 2008; ISBN 978-85-7780-262-3

Bibliografia básica:

PEZZÈ, M.; YOUNG, M.; Teste e Análise de Software. Porto Alegre: Bookman, 2008; ISBN 978-85-7780-262-3 COCKBURN, A.; Escrevendo Casos de Uso Eficazes - Um Guia para Desenvolvedores de Software. São Paulo: Bo-okman; 2005

DELAMARO. M.E.; MALDONADO, J. C.; JINO, M.; Introdução ao Teste de Software. Rio de Janeiro: Cam-pus, 2007.

Bibliografia complementar:

Adzic, G.; Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing; London, UK: Neuri; Kindle edition; 2009

Beck, K.; Test-driven development by example. Addison Wesley, 2002.

Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcock, J.; eds.; Testing Techniques in Software Engineering; LNCS 6153; Berlin: Springer, Lecture Notes in Computer Science; 2010

Huizinga, D.; Kolawa, A.; Automated Defect Prevention: Best Practices in Software Management; Hoboken, New Jersey: John Wiley & Sons; 2007

Hunt, A.; Thomas, D.; eds.; Pragmatic Unit Test: in Java with JUnit; Sebastopol, CA: O'Reilly; 2003 Myers, G.J.; The Art of Software Testing, 2nd edition; Hoboken, New Jersey: John Wiley & Sons; 2004 Staa, A.v.; Programação Modular; Rio de Janeiro: Campus; 2000

4. Critério de aprovação

A disciplina INF 1413 Teste de Software adota o critério da categoria III da resolução 1/2005, copiada a se-guir:

Categoria III - A avaliação do aproveitamento feita pelo professor será expressa por meio de dois graus de qua-lificação, apresentados numericamente, em escala de zero (0) a dez (10), do seguinte modo:

(3)

b) o segundo grau de qualificação, resultante de testes, relatórios, trabalho, prova ou projeto, cobrindo um pro-grama parcialmente lecionado ou toda a matéria lecionada no período letivo. Neste grau podem ser incluídos testes e relatórios relativos a programa parcialmente lecionado;

c) o Grau Final será calculado conforme um dos dois casos a seguir:

1. Se o segundo grau for maior ou igual a três (3,0), o Grau Final será a média aritmética das duas

avalia-ções (mesmo peso).

2. Se o segundo grau for menor que três (3,0), o Grau Final será calculado tendo o primeiro grau peso um

(1) e o segundo grau peso três (3). Para o cálculo desses graus serão realizados:

2 provas (todas as provas são com consulta) Cabe salientar que não comparecer a uma prova resulta

na nota 0. 1. P1: 19/10 – quarta-feira 2. P2: 14/12 – quarta-feira 4 trabalhos, prazos 1. T1: 26/09 – segunda-feira 2. T2: 19/10 – quarta-feira 3. T3: 28/11 – segunda-feira 4. T4: 14/12 – quarta-feira

4.1. Cálculo do grau final

A seguir é apresentada a forma de cálculo dos dois graus e do grau final: G1 = ( P1 * 2. + T1 + T2 ) / 4.

G2 = ( P2 * 2. + T3 + T4 ) / 4.

GrauFinal = if ( G2 >= 3. ) then ( G1 + G2 ) / 2. else ( G1 + 3. * G2 ) / 4. fi 1

Para ser aprovado o aluno deverá alcançar um Grau Final igual ou maior do que 5. OBS. 1- O grau G1 estará disponível antes da data de cancelamento de disciplinas.

OBS. 2- O grau G2 menor do que 3 implica reprovação, mesmo que a nota do G1 tenha sido 10. Por-tanto, não abandone o estudo na segunda parte da disciplina, mesmo que a nota do G1 tenha sido muito boa!

4.2. Trabalhos

Os trabalhos serão feitos

● em grupos de 2 ou 3 alunos

● procurem logo os seus parceiros de trabalho. Os trabalhos devem ser entregues via e-mail.

● caso a mensagem contenha vírus, a nota será 0 (zero). São utilizados diversos controladores de vírus. ● será descontado 1 ponto por dia útil de atraso (domingos e feriados não são dias úteis, sábados e

di-as enforcados são considerados “didi-as úteis”). O término de um “dia” é às 8 hordi-as da manhã do dia a

seguir do prazo. Por exemplo, se o trabalho for devido no dia 3 e for enviado no dia 4 antes das 8 ho-ras, não perde ponto, após as 8 horas perde.

(4)

5. Plano de aulas tentativo

Datas

Assunto

1 24/08 Apresentação da disciplina 2 29/08 Qualidade de software

3 31/08 Técnicas de controle da qualidade

4 05/09 Especificações, historietas, casos de uso, padrões de redação

5 12/09 Revisão e inspeção 1; caracterização de revisões e inspeções; técnicas de leitura 6 14/09 Revisão e inspeção 2; ferramentas, práticas e critérios de inspeção

7 19/09 Princípios de teste 1; Tipos de teste; Oráculo; Projeto de teste 8 21/09 Princípios de teste 2; Processos de teste, depuração, e manutenção 9 26/09 Critérios seleção de casos de teste; Requisitos; Critério de valoração

10 28/09 Teste funcional 1; Conceitos; Cobertura de elementos GUI; tabelas de decisão 11 03/10 Teste funcional 2; Grafos causa e efeito; classes de equivalência; listas de quesitos;

exemplos de quesitos Web

12 05/10 Teste funcional 3; Geração de casos de teste a partir de casos de uso

13 10/10 Máquinas de estados; Conversão de máquinas de estados para casos de teste; Conversão de casos de uso para máquinas de estado e, a seguir, para tabelas de decisão

14 17/10 Teste baseado em riscos 19/10 1ª. prova

15 24/10 Assertivas; Sintaxe e exemplos de assertivas

16 26/10 Aspectos Formais de Apoio aos Testes 1; Desenvolvimento dirigido por contratos 17 31/10 Aspectos Formais de Apoio aos Testes 2; Teste metamórfico; Argumentação da

corretude

18 07/11 Teste estrutural 1: O que é; Grafo da estrutura do código; critérios de cobertura instruções; arestas e condições

19 09/11 Teste estrutural 2: Funções encapsuladas; Cobertura de caminhos; Fluxo de dados 20 16/11 Teste estrutural 3: Teste de exceções; planejamento da integração; módulos dublê 21 21/11 Teste estrutural 4; Teste com mutantes; Adição de redundância

22 23/11 Teste automatizado 1; JUnit, Talisman C++ test framework 23 28/11 Teste automatizado 2; Desenvolvimento dirigido por testes 24 30/11 Teste automatizado 3; Manutenção dirigida por testes 25 05/12 Geração automática de casos de teste

26 07/12 Teste de programas OO 27 12/12 Plano de testes

14/12 2ª. prova

(5)

Critérios de avaliação dos trabalhos

Objetivos dos trabalhos

O objetivo básico da disciplina é habilitar o aluno a controlar de forma sistemática a qualidade dos artefatos produzidos ao desenvolver e manter software. Para isso é necessário

• aprender a ler e avaliar criteriosamente uma variedade de artefatos (documentos, especifica-ções, código);

• aprender a projetar e realizar testes sistemáticos utilizando uma variedade de técnicas; • aprender a utilizar técnicas formais “leves” em apoio aos testes;

• aprender a planejar e organizar o trabalho relacionado com controle da qualidade.

O aprendizado evidentemente requer a prática das técnicas abordadas. Independentemente da difi-culdade, do esforço e do tempo gasto pelo aluno, o que vai ser examinado ao corrigir os trabalhos é a quali-dade dos resultados apresentados. Ou seja, o número de horas que o aluno possivelmente tenha levado para desenvolver os trabalhos não têm influência sobre as notas.

Sugere-se que a realização dos trabalhos seja iniciada imediatamente ao receber o enunciado. Os enunciados possivelmente deixarão margens a dúvidas. Sempre consulte o instrutor para tirá-las, não utili-ze “achologia” nem opiniões de colegas para resolver dúvidas.

O que será corrigido é o que foi entregue. Ou seja, caso sejam entregues artefatos obsoletos ou erra-dos, o aluno poderá perder muitos pontos devido à falta de atenção. O objetivo deste critério é induzir os alunos a tomarem cuidado ao compor a versão final a ser entregue.

Entrega do trabalho

• Os trabalhos deverão ser entregues via e-mail. Caso a mensagem não satisfaça qualquer um dos itens a seguir: -2 pontos

• O assunto da mensagem (subject) deve ser: INF1413 Trabalho nn idGrupo em que: • nn é o número do trabalho,

• idGrupo é formado por n conjuntos de duas ou três letras, cada conjunto identificando um dos n membros do grupo.

• Exemplo: INF1413-Trab1-JBOGESP

• OBS.: Num espaço de 48 horas será enviada uma resposta ao grupo ou à pessoa que enviou o trabalho, confirmando o recebimento correto do trabalho. Caso o corra algum erro no re-cebimento, o grupo poderá reenviar o trabalho sem perda de pontos.

• O texto da mensagem deve somente identificar cada um dos os autores fornecendo os respecti-vos: número de matrícula, nome e endereço e-mail.

• Todos os arquivos que compõem o trabalho devem estar "zipados" em um único arquivo ane-xado à mensagem enviada.

• O nome do arquivo .ZIP deve ser INF1413-Trabnn-idGrupo.zip conforme descrito e exemplifi-cado acima. Alguns provedores de acesso impedem a transmissão de arquivos contendo execu-táveis (.exe, .bat) e similares. Neste caso rebatizem o arquivo .zip para .zipx, (ou .rar para .rarx para quem utilizar esse tipo de compressor de arquivos).

● Para cada dia útil de atraso (domingos e feriados não são dias úteis, porém sábados e dias enforcados são dias úteis) é descontado: -1 ponto. Obs. O “término” de um dia é às 8 horas do dia a seguir. Por exemplo, se o trabalho era devido no dia 10 e for enviado no dia 11 antes das 8 horas, não perde pon-to, após as 8 horas perde.

Composição do trabalho

• “Grupos” formados por um único ou por quatro ou mais alunos: -1 ponto.

• Procure formar o seu grupo já na primeira aula. Leve em conta a afinidade e a disponibilidade de tempo de cada participante. O objetivo é aprender a organizar e realizar trabalho em grupo. • Conteúdo da mensagem com vírus resulta em nota zero

• Cuidado com as máquinas dos laboratórios, pois, por mais controle que se exerça, colegas in-gênuos ou pouco éticos frequentemente infectam estas máquinas.

(6)

pelos alunos. Para cada uma das tarefas deve(m) estar relacionado(s) o(s) aluno(s) que a re-alizaram(realizou).

• Caso o trabalho exija programação, devem ser entregues: • Programa executável

• Módulos de código fonte

• Arquivo .make capaz de coordenar a recompilação do programa • Arquivos contendo as diretivas (scripts) de teste

Critérios básicos

• Se algum dos arquivos não identificar os autores: -1 ponto

• Se os artefatos entregues não estiverem relacionados com o enunciado: -9 pontos

• Se um ou mais artefatos entregues forem plágio de algum outro trabalho, a nota do trabalho será

Zero.

• Caso tenha havido colaboração entre os grupos, cada um dos grupos envolvidos deve docu-mentar isso em um documento “observacoes.doc” ou “observacoes.txt”. Caso parte da solução tenha sido baixado da rede, deve ser dado o respectivo crédito (citar a referência de onde foi obtida a parte da solução). Não sendo dado crédito será considerado plágio.

• Cópias de trabalhos anteriores ou de colegas (p.ex. contidos em um dropbox) são considerados plágio. Também são considerados plágio reescritas mecânicas de trabalhos anteriores ou de co-legas (p.ex. trocas de nomes de variáveis em programas, traduções, paráfrases).

No caso trabalhos envolvendo programação, execução básica

• Se o programa executável .exe não existe: -8 pontos • Se o programa .exe não dá partida: -8 pontos

• Recomenda-se especial cuidado com o teste final. Assegure que o programa opera corretamente em uma máquina sem a infra-estrutura necessária para o ambiente de desenvolvimento. • Se o programa não completa a execução (entra em loop, trava, cancela a execução, voa, etc.) em

to-dos os testes usato-dos: -8 pontos

• Se o programa não completa a execução em um ou mais dos casos de teste usados: -6 pontos. • O teste será repetido para que se tenha certeza de não se tratar de uma falha fortuita do

instru-tor e na ficha de avaliação será descrito, em linhas gerais, como proceder para gerar a falha. • Não foram incluídos os scripts de teste solicitados: -4 pontos.

• Os scripts de teste não estão em conformidade com o solicitado: -4 pontos. • Outros problemas encontrados: -1 ponto por problema

No caso de programas, código fonte e documentação

* Se o código fonte não existe: a nota do trabalho: -8 pontos

* Se o código fonte não for compilável ou não corresponde ao programa executável entregue: -8

pon-tos

* Se o código fonte for mal organizado ou comentado (INF1301 é pré-requisito): -3 pontos.

* São examinados: comentários inexistentes ou fora dos padrões, nomes mal escolhidos, constan-tes fora dos padrões, estilo ruim, organização do código ruim, código duplicado.

* Especificações não existem, incompletas ou mal organizadas: -2 pontos

* Usualmente o enunciado do trabalho contém critérios complementares. Cada um deles identificará o número de pontos perdidos caso não seja satisfeito.

Observação