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

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

Re: [shell-script] Recomendação de livro/apostila sobre Bourne Shell


From: Tiago Peczenyj
Subject: Re: [shell-script] Recomendação de livro/apostila sobre Bourne Shell
Date: Tue, 21 Feb 2012 10:35:40 -0200

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 <address@hidden>

> **
>
>
> 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]