shell-script-pt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recomendação de livro/apostila sobre Bourne Shell


From: carlos_jacon
Subject: Re: Recomendação de livro/apostila sobre Bourne Shell
Date: Wed, 22 Feb 2012 11:34:11 -0000
User-agent: eGroups-EW/0.82

Bom dia!

Gostaria de agradecer as dicas, principalmente a do Tiago... Serão muito úteis!
Estou reunindo o material para estudo... Quinta-feira continuarei a desenvolver 
os scripts de teste, se surgir alguma dúvida que não consiga resolver, irei 
pedir ajuda novamente a lista.

Obrigado novamente.



Abraço,
Carlos

--- Em address@hidden, Tiago Peczenyj <tiago.peczenyj@...> escreveu
>
> Ola
> 
> Veja se algum desses guias também pode ajuda-lo:
> 
> http://tldp.org/guides.html
> 
> Agora se vc tem alguma dificuldade especifica use a lista.
> 
> Minha dica sobre scripts de teste: não tenha scripts muito grandes. Eu ja
> dei manutenção em alguns scripts para korn shell que rodavam em HP UX e
> tinham mais de 5 mil linhas e é um inferno se pessoas com estilos
> diferentes ja passaram por este script ainda mais se ninguem documenta
> nada. Por isso a primeira coisa q eu faço é um "usage" ou "help".
> 
> Se for possivel divida os scripts da seguinte forma
> 
> 1- funções para executar os testes. ex: conectar_equipamento_xyz
> 2- funções para administrar os testes. ex: teste_passou. teste_falhou.
> total_testes.
> 3- os testes em si.
> 
> para o item 3 seria interessante vc separar em muitos scripts (que importam
> via "source" os itens 1 e 2) e coordenar a execução deles através de algo
> como o make. a vantagem é poder agrupar os testes de muitas formas.
> 
> para cada teste é muito importante que vc determine a causa da falha. uma
> forma "interessante" de testar é efetuar varios comandos e jogar a saida
> deles para um arquivo (ex: nome_do_teste.log) e comparar com um arquivo
> cuja saida é a esperada (ex: nome_do_teste.master) via diff, mas só faça se
> fizer sentido (a manutenção nesses testes é bem dificil).
> 
> porém o mais importante é ter o conceito de setup de teste. antes de cada
> teste garanta (setup) que o seu ambiente está num estado possivel de ser
> testado e volte a esse estado depois do teste (teardown). Afinal o teste
> falhou pq o equipamento tem um erro ou pq não esta ligado? Também faça os
> seus testes o mais independentes uns dos outros. E muito cuidado ao tentar
> paralelizar os testes.
> 
> também existem os pré-requisitos do ambiente de teste. faça uma rotina de
> checagem que roda antes dos testes para ver se vc tem tudo o que precisa
> (mount point nfs, se determinadas maquinas respondem a ping, etc). muito
> tempo ja perdi pq alguma maquina ou serviço estava fora.
> 
> pesquise sobre TAP - Test Anything Protocol - e veja se é util, pode ser
> que para gerar relatorios ou utilizar outras ferramentas possa ser mais
> adequado.
> 
> Seguindo estas dicas, seus scripts provavelmente serão muito simples e
> pouca dificuldade em coisas especificas de shell vcs terão. Agora se
> estiver muito lento, veja com o comando time (ou produza um log com tempo
> de inicio e fim) onde esta lento e confira se é algo de rede ou se é do
> proprio shell (de repente um loop onde muitos processos são criados). Se
> não conseguir fazer em shell provavelmente tcl, python ou perl podem
> resolver mas ai foge do esboço da lista.
> 
> Caso encontrem algum bug de outra forma (manualmente, por exemplo), tentem
> escrever um teste para encontrar o bug antes de resolver, descrevendo o
> motivo pelo qual aquele teste existe.
> 
> Uma ultima dica: veja o comando expect. As vezes precisamos interagir com
> um sistema externo que exige algum tipo de interação (como algum menu ascii
> ou responder perguntas).
> 
> Boa sorte.
> 
> 2012/2/19 carlos_jacon <carlosjacon@...>
> 
> > **
> >
> >
> > Bom dia!
> >
> > Por favor, gostaria de saber se alguém poderia recomendar um
> > livro/apostila sobre Bourne Shell.
> > Estamos gerando alguns scripts para teste de equipamentos de
> > telecomunicação, mas estamos com um pouco de dificuldade devido a
> > inexperiência de manuseio neste shell em específico.
> >
> > Obrigado,
> > Carlos Jacon
> >
> >  
> >
> 
> 
> 
> -- 
> Tiago B. Peczenyj
> Linux User #405772
> 
> http://pacman.blog.br
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]