terça-feira, 9 de outubro de 2012

Teste de Software

E aí galera, tudo bem?!..
O primeiro post deve ser o mais difícil pelo tanto que estou sofrendo :') ....Enfim, decidi compartilhar aquilo que sei para que juntos possamos aprender cada vez mais! Esse primeiro post tem por objetivo fazer uma introdução praticamente acadêmica acerca do tema em geral e é um resumo de um dos capítulos do meu TCC.

Espero que gostem!


  \O/


Obs: Neste e nos próximos posts colocarei bonitinhas as referências assim que estruturar todas!


Enjoy!    




   Teste de Software




Com o passar do tempo a tecnologia da informação se fez cada vez mais presente em diversas atividades humanas, chegando a se  tornar crucial para o funcionamento de algumas áreas, o que levou se exigir cada vez mais qualidade dos softwares desenvolvidos [COSTA, 2004]. Sendo assim,a sociedade, atualmente, depende cada vez mais de sistemas computacionais de qualidade pois seu uso cresce de forma exponencial nos mais diversos setores desempenhando tarefas críticas. Se alguns sistemas de uso global deixarem de funcionar, aproximadamente 40% da população sofrerá as consequências deste problema [REED, 2000]. Entretanto, é possivel afirmar que apesar do quão significativos softwares são, uma grande parte dos projetos de software não possui uma estrutura sólida para implementação de métodos que venham a proporcionar a garantia da qualidade de seu produto final. Em uma pesquisa recente realizada pelo Ministério da Ciência e Tecnologia, cerca de 10% das empresas entrevistadas realizam algum teste de software no Brasil [MOLINARI, 2008].
“A qualidade é relativa. O que é qualidade para uma pessoa pode ser falta de qualidade para outra (G. Weinberg)”. Embora o conceito de qualidade aparente ser intuitivo, ao analisá-lo conclui-se que, na verdade, é complexo e defini-lo não é uma tarefa fácil. Segundo [CROSBY ,1992] a qualidade é a conformidade aos requisitos, um conjunto de características a serem satisfeitas em um determinado grau, de modo que o produto de software atenda às necessidades explícitas e implícitas de seus usuário  [ROCHA, 1994]. Conforme a ISO 9003-3-1991, qualidade é a totalidade de características e funções  de um produtos ou serviço que habilitem a satisfação de necessidades implícitas ou especificadas.Qualidade ainda, segundo a atual norma brasileira sobre o assunto (NBR ISO 8402), é a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas. Entretanto, para a obtenção da qualidade em um produto final é necessária a compreensão de que esta é intimamente ligada a todo os segmentos do ciclo de desenvolvimento de um software e não somente a uma fase específica.
[MOLINARI,2008] afirma que existem três elementos que compõe e sustentam a qualidade de software, sendo estes a gerência de configuração, a gerência de requisitos e os testes.  A gerência de configuração aborda a gerência, controle e registro dos artefatos que compõe o software, incluindo todo o histórico de mudança deste. Já a gerência de requisitos trata da gerência, controle e registro das necessidades do sistema e dos usuários em todos os níveis, resultando no acompanhamento dos requisitos e suas mudanças. Já o segmento de teste vai desde o gerenciamento de  todo o planejamento, controle e até a execução dos mesmos.
Somente a existência de testes no processo de desenvolvimento de um  software  não é capaz  de creditar a este a característica qualidade, entretanto pode auxiliar no processo de controlá-la e garanti-la, aumentando o grau de confiabilidade do sistema. Segundo [HAROLD, 2000]  o processo de teste é executado para dar a  garantia de qualidade ao produto de software e é a mais popular estratégia de gerenciamento de risco [MOLINARI,2008]. Este procedimento faz-se necessário pois o desenvolvimento de sistemas de software envolvem uma série de atividades de produção em que oportunidades para injetar a faliabilidade humana são enormes.  [DEUTSCH, 1979] afirma que erros podem vir a ocorrer até no início do processo de desenvolvimento  onde os objetivos podem ser erroneamente ou imperfeitamente especificados, bem como em  estágios posteriores de projeto e desenvolvimento por causa da inabilidade humana de realizar e comunicar com imperfeição.
“Se eu tivesse oito horas para derrubar uma árvore, passaria seis afiando o meu machado. " Abraham Lincoln, esta frase pode representar  uma analogia ao processo de testes, uma vez esta atividade é uma das mais onerosas do processo de produção de um software. Estudos indicam que testes podem vir a consumir mais de 50% do custo de desenvolvimento de um software [HAROLD, 2000]. A rigor o teste de software que envolve vidas (por exemplo, controle de tráfego aéreo, monitoramento de reatores nucleares) pode custar de três a cinco vezes mais do que todos os outros passos de engenharia de software combinados [PRESSMAN, 2002]. Segundo um estudo realizado pelo National Institute of Stanandarts and Tecnology (NIST) durante o ano de 2002, somente no Estados Unidos, perdas causadas por erros em sistemas somaram cerca de  U$ 59.5 bilhões de dólares,  este estudo aponta ainda  que o investimento na melhoria da infra-estrutura para a área de testes geraria uma economia de U$ 22 bilhões ao país.
A figura 1 representa um gráfico de custo médio de um erro por etapas do processo de desenvolvimento. Ela representa o ciclo de custo de um defeito, demonstrando que ele cresce em uma proporção média de 10 vezes a cada etapa de desenvolvimento. Sendo assim um erro encontrado na especificação tem seu custo em 10 centavos de dólar para ser corrigido. Já para o caso do mesmo erro ser esquecido e ser detectado na fase de implantação o custo seria de 100 dólares (BARTIÉ, 2002).


                                             Fonte: Bartie Alexandre (2002)
Figura 1. Custo médio de um erro em Dólar 

Atividades de teste devem ser cuidadosamente planejadas para fornecer um nível adequado de confiabilidade, atingir aos requisitos, dentro das condições especificadas, contribuindo para qualidade de software, já que testes bem planejados são capazes de remover 60% dos defeitos de um programa [BOEHM e BASILI, 2001], isto aplica-se também ao fato de que um bom teste não é redundante. Na prática não se pode garantir que um software é perfeito, devido principalmente a complexidade envolvida em sua construção, entretanto a  não ou má execução deste processo em alguns projetos além de custos altíssimos podem acarretar em graves acidentes pondo em risco vidas humanas. Em novembro de 2000 no Instituto Nacional do Cancro da Cidade do Panamá, ao menos oito pacientes morreram e outros 20 foram afetados devido a uma falha no software de controle da máquina de raios, havia um  erro no cálculo na dose de radiação que um paciente deveria receber durante uma terapia radiológica. Um exemplo de fracasso de um projeto de orçamento astronômico, avaliado em U$ 300 milhões, ocorreu em  3 de dezembro de 1999, quando a sonda da NASA Mars Polar Lander desapareceu na tentativa de um pouso em Marte. O motivo da falha foi um bit inesperado no conjunto de instruções do programa que ocasionou um problema na “cama de pouso” da sonda [MOLINARI, 2008].
Testes de software são elementos críticos da garantia de qualidade de software e representam uma revisão final da especificação, projeto e geração de código [PRESSMAN, 2002]. A definição clássica de teste de software foi dada por Myers em 1979 em um dos primeiros trabalhos a estudar a fundo esta atividade, caracterizando-se como o processo de executar o programa com a intenção de encontrar erros, partindo da premissa de que se o objetivo dos testes fossem somente provar a boa funcionalidade de um aplicativo seriam encontrados menos defeitos em relação a outra frente de pensamento, uma vez que toda a energia do processo de testes seria direcionada apenas  na comprovação deste fato [BARTIÉ, 2002].  Conforme [DIJKSTRA et al, 1972], os testes podem mostrar apenas a presença de erros e não a sua ausência. Logo, a atividade de teste demonstra que as funções do software estão sendo executadas de acordo com as especificações, que os requisitos de desempenho foram cumpridos e que, por conseqüência, as informações geradas por ele são confiáveis.
Afirma [NEVES, 1999] que os testes tem por objetivo no início de cada fase do ciclo de desenvolvimento de um software, verificar se aquela etapa corresponde exatamente aos requisitos e definições da fase imediatamente anterior, para assim garantir que o produto encomendado e o gerado pela atividade de desenvolvimento do software sejam os mesmos, através dos diversos níveis de refinamento. A finalidade dos testes é expor defeitos latentes em um software antes de este ser entregue [SOMMERVILLE, 2003], consistindo em atividades que devem verificar se não existem erros na lógica no código ou de projeto, no fluxo de dados, na compreensão dos requisitos, no desempenho do sistema, na integração do sistema com outros componentes de software e hardware, para posteriormente interferir na presença do erro.
Desta forma, segundo [KOSCIANSKI, 2006], quando a atividade  de testes é planejada de maneira sistemática e rigorosa, pode ser utilizada como um dos parâmetros para estimar a confiabilidade e qualidade do software construído, testes servem em si, para aumentar o grau de confiança de que se esta construindo um produto com o comportamento desejado.Um bom caso de teste é aquele que tem uma elevada probabilidade de descobrir um erro e um teste bem sucedido é aquele que revela um erro ainda não descoberto. Conforme [LEWIS, 2004],o teste  "É uma estratégia popular para o gerenciamento de risco". O teste de software é usado para verificar que requisitos funcionais e não-funcionais foram devidamente implementados. Pyhäjärvi e Rautiainen (2004) mencionam que Testes de Software  também representa uma importante ferramenta na busca pela satisfação do cliente – um dos principais objetivos das pesquisas em sistemas de informação e pela melhoria do processo de desenvolvimento.
 Um princípio adotado ao se testar um software é o de Pareto, este afirma que para muitos fenômenos, 80% das consequências advém de 20% das causas, mostrando assim que  há um grande desiquilíbrio entre causas e efeitos, entre a relação de esforços e resultados. Conforme [KOSCIANSKI, 2006], em programação, pode ser aplicado ao afirmar de uma forma genérica que 20% dos componentes de software concentram 80% dos defeitos. A grande aplicabilidade deste princípio encontra-se no fato de ajudar a identificar o reduzido número de causas que estão muitas vezes por trás de grande parte dos problemas que ocorrem, sugerindo assim que o foco dos testes deve ser concentrado nos pontos mais frágeis do sistema. No processo de desenvolvimento de software todos os erros são erros humanos e, apesar do uso dos melhores métodos de desenvolvimento, das melhores ferramentas de suporte e de pessoal treinado, os erros permanecem presentes nos diversos produtos de software produzidos e lançados no mercado [HOWDEN, 1987].
 Como em qualquer outra fase do ciclo de desenvolvimento de um software, a fase de testes requer certos cuidados em relação à compreensão de seus princípios básicos antes de sua aplicação de fato. Segundo [MYERS, 1979] a tarefa de testar um software é extremamente criativa e intelectualmente desafiadora, portanto sugeriu princípios para condicionar a acrescentar sustentabilidade ao projeto de teste e execução destes, são elas: o programador deve evitar de testar seu próprio programa, deve-se inspecionar completamente os resultados de cada teste. A probabilidade da existência de mais erros em uma seção de um programa é proporcional ao número de erros já encontrados naquela seção, não se deve planejar nenhum caso de teste sob a suposição de que nenhum erro será encontrado e que uma parte extremamente necessária de um caso de teste é a definição de uma saída ou resultado esperado. [PRESSMAN, 2002] acrescenta outros seis princípios, sendo estes: [1] todos os testes devem ser relacionados aos requisitos do cliente, [2] os testes devem ser planejados muito antes do início do teste, [3] o princípio de Pareto se aplica ao teste de software, [4] teste completo não é possível, [5] o teste começa em nível de componente e prossegue “para fora”, [6] o teste e a depuração são atividades diferentes entretanto a depuração deve ser acomodada em qualquer estratégia de teste.
                 Conforme Crespo et al as dificuldades em se testar um software pode ser descrito da  seguinte maneira:

                     
Devido a algumas características próprias do software como flexibilidade para mudanças, complexidade e intangibilidade, o teste não é uma tarefa trivial. A dificuldade em testar software é caracterizada por alguns pontos importantes como: o teste de software é um processo caro; existe uma falta de conhecimento sobre a relação custo/benefício do teste; há falta de profissionais especializados na área de teste; existem dificuldades em implantar um processo de teste; há o desconhecimento de um procedimento de teste adequado; há o desconhecimento de técnicas de teste adequadas; há o desconhecimento sobre como planejar a atividade de teste; e finalmente,  a preocupação com a atividade de teste somente na fase final do projeto.(2004).


            Entretanto, a medida que é reduzida a complexidade da atividade de teste seu custo tende a diminuir. Sendo assim, no momento em que componentes que agregam características que tornam um software mais facilmente testável são utilizados seu grau de testabilidade evolui. A testabilidade consiste na facilidade em que um programa tem de ser testado. Segundo a [IEE,1990], a testabilidade fornece o grau de dificuldade que será encontrado para detectar o defeito, refere-se a quanto esforço será necessário para cada teste e se o software apresenta suas falhas no momento em que são inseridas as entradas de teste, caracterizando-se como um programa com alta testabilidade. Do modo contrário ocorre um software com baixa testabilidade possuindo tendencia a ocultas as falhas que deveriam ser detectadas durante os testes.
          As seguintes características levam a um software testável e devem ser levadas em conta quando ele é construído [ZADROSNY,2006],[PRESSMAN,2002]:
● Operabilidade: o software deve ser projetado e implementado com qualidade. ”Quanto melhor funciona, mais eficientemente  pode ser usado e testado”.
● Observabilidade: variáveis devem ser visíveis ou consultáveis durante a execução. “O que você vê é o que você testa.”
● Controlabilidade: variáveis devem poder ser controladas diretamente pelo engenheiro de teste. ”Quanto mais você pode controlar o software, mais o teste pode ser automatizado e otimizado”.
Decomponibilidade: módulos independentes podem ser testados independentemente. ”Controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagem mais racionalmente”.
● Simplicidade: o conjunto de características deve ser o mínimo necessário para atender os requisitos. ”Quanto menos há a testar, mais rapidamente podemos testá-lo”.
● Estabilidade: o software se recupera bem de falhas. ”Quanto menos modificações, menos interrupções no teste”.
● Compreensibilidade: a documentação técnica é acessível instantaneamente, bem organizada, específica, detalhada e precisa.”Quanto mais documentação temos, mais racionalmente vamos testar”.

Conforme [ CRESPO et al,2004] e [KOSCIANSKI, 2006] existem, basicamente  duas técnicas de teste para qualquer produto que passa por engenharia. Sendo uma delas o  teste estrutural também conhecido como teste de caixa-branca, que caracteriza-se por ser uma técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de identificar defeitos nas estruturas internas do software, através de situações que exercitem adequadamente todas as estruturas utilizadas na codificação. Nesta técnica , o conhecimento interno de um produto oferece informações para testar se todas as operações internas estão sendo realizadas conforme as especificações e se todos os componentes internos estão sendo exercitados corretamente [PRESSMAN, 2002]. Já a segunda forma, chamada de  teste funcional  também conhecida como teste de caixa preta, é técnica de teste que adota critérios para a geração dos casos de teste com a finalidade de garantir que os requisitos do software que foi construído sejam plenamente atendidos. Desta maneira, o conhecimento da função para que o produto foi projetado para efetuar oferece informações para realização de testes que demonstrem que cada função está plenamente operacional, ao mesmo tempo em que erros são procurados em cada uma das funções, conforme critérios [PRESSMAN, 2002].
A visão do objeto a ser testado afeta no modo em que os testes serão realizados, [PFLEEGER, 2004] complementa que se o objeto for visto de uma  perspectiva externa, o teste consistirá em alimentar o objeto com entradas e observar se as saídas correspondem com o esperado, e ao se observar o objeto a ser testado sob uma perspectiva interna, para planejar os casos de testes será utilizada a  estrutura do objeto. Deve-se levar em consideração também a fase de desenvolvimento em que o teste será aplicado, já que a técnica de teste direciona a escolha de critérios para geração de casos de teste que, ao serem executados, vão exercitar os elementos requeridos pela abordagem do teste. Portanto, para realizar esta atividade de teste deve-se utilizar técnicas de testes de software bem estabelecidas e estas devem ser realizadas de forma sistemática. [MYERS, 1979] sugere que uma estratégia de testes onde sejam combinadas as técnicas de caixa-branca e caixa preta, sendo os casos de teste estruturais  realizados como complementares aos testes funcionais, já que um número razoável de técnicas deve ser aplicado a ao teste de software, mas nenhuma isoladamente.
Segundo [KOSCIANSKI, 2006] os testes de caixa-branca são projetados em função da estrutura do componente e podem permitir a verificação mais precisa de comportamento do produto, permitindo ao testador focar sua atenção nos pontos mais importantes ou delicados do código de uma maneira mais precisa. Consistindo em uma abordagem de testes em que estes são derivados do conhecimento da estrutura e da implementação do software, permitindo  uma verificação mais precisa do produto [SOMMERVILLE, 2003]. Desta forma,  os dados de teste são dirigidos para examinar a lógica do programa, sem interesse nas especificações  do mesmo [LEWIS, 2000]. Este teste objetiva verificar se a estrutura interna da unidade está correta e para isso são realizados para  os caso de teste que visam percorrer todos os caminhos internos possíveis da unidade, abrangendo também,  a manipulação dos valores dos atributos, verifica os resultados quando loops são executados até o seu limite visando identificar os caminhos críticos de cada procedimento, entretanto percorrer todos os caminhos acaba tornando esta atividade complexa. Os casos de teste do tipo estrutural devem garantir que todos os caminhos independentes de um módulo tenham sido exercitados pelo menos uma vez, exercitando todas as decisões lógicas em seus lados verdadeiro e falso,executando assim  todos os ciclos nos seus limites dentro de seus intervalos operacionais desta forma exercitando as estruturas de dados internas.
            Grafos de fluxo caracterizam-se como  uma ferramenta de representação baseada em em nodos e arestas que são importantes ferramentas conceituais. [MYERS, 1979] e [PRESSMAN, 2002] definem que cada círculo, chamado de nó do grafo de fluxo representa um bloco de comandos que são executados sequencialmente e cada seta, chamada aresta, arco ou ligação, indica a transferência de controle entre segmentos e sempre deve terminar em um nó. A figura 1 apresenta a notação de um grafo de fluxo.
           
                                                            Figura 2 -Notação Grafo de Fluxo

Através deste tipo de ferramenta é possível aplicar uma estratégia de teste estrutural, denominada teste de caminho. [SOMMERVILLE, 2003] afirma que este tipo de teste tem por objetivo exercitar todo caminho distinto ou independente ao longo do código, ao menos uma vez, em algum teste. Afirma ainda que se todo caminho independente for executado, logo todas as afirmações do código devem ter sido executadas, e todas as declarações condicionais testadas para os casos verdadeiros e falsos. Entretanto, a execução de testes de caminhos para todas as combinações possíveis torna-se um objetivo impossível, já que há uma quantidade infinita de possíveis combinações de caminhos em programas com loops, então este tipo de teste é aplicado somente em caminhos básicos [MYERS, 1979]. Este método permite definir um conjunto mínimo de caminhos de execução  que garante o exercício de cada comando do programa ao menos uma vez durante a atividade de teste [PRESSMAN, 2002].
Outro exemplo de teste estrutural seria o teste de unidade que foca os módulos e componentes de um software. [MYERS, 1979] define este tipo de teste como um processo para testar subprogramas, individuais ou subrotinas em um programa, com o objetivo testar o funcionamento deste grupo de funções [SOMMERVILLE, 2003]. Este teste é realizado para mostrar que a unidade não satisfaz a sua especificação funcional e/ou que sua estrutura implementada não corresponde com a planejada. Os dados de teste são derivados conforme uma analise do código de um componente e, depois são utilizados como entrada para os testes, que são executados e geram saídas conforme ilustra a figura 3.

                                                              Figura 3.Teste unitário. 

Quando se faz uso do paradigma de teste caixa preta, que também pode ser chamado de teste comportamental ou teste de caixa fechada, se testa o programa sob a perspectiva do usuário, não levando em consideração sua estrutura interna ou meios de desenvolvimento. Segundo [SOMMERVILLE, 2003] seu comportamento do software ou parte dele só pode ser determinado através de estudos de suas entradas e suas respectivas saídas. A figura 4 é uma abstração desta técnica, e serve para elucidar demais conceituações sobre o assunto. Este tipo de teste  tem como objetivo medir a qualidade funcional de componentes de um sistema [MOLINARI, 2010], avaliando-os conforme seu comportamento externo. Quando se realiza um teste funcional está na verdade confrontando com o que se espera que o sistema vá fazer, ou seja, incluindo entrada de dados, processamento e resposta. [AGUIAR, 2007] afirma que este é o único tipo de teste possível para se aplicar no momento em que não se dispões do código-fonte, e ele é particularmente útil para encontrar problemas, como: funções incorretas ou omitidas, erros de interface, erros de comportamento ou desempenho e erros de iniciação [KOSCIANSKI, 2006].

Figura 4. Teste funcional
O teste de caixa-preta basea-se nos requisitos funcionais do software. Como não há conhecimento sobre a operação interna do programa, o avaliador se concentra nas funções que o software deve desempenhar [LOURENÇO, 2011]. A partir da especificação são determinadas as saídas esperadas para certos conjuntos de entrada de dados.[PEZZÈ, 2008] afirma que os testes funcionais tipicamente são usados como base para o projeto de casos de teste, já que estes devem começar como parte do processo de especificação de requisitos e continuar ao longo de cada nível de projeto e especificação de  interface sendo a  única técnica de projeto de teste com uma aplicabilidade tão ampla. Pode-se afirmar que testes de caixa preta podem ser aplicadados a qualquer descrição do comportamento de um software, sendo esta formal, parcial ou até mesmo informal, desde um módulo até abranger todo o sistema. Este tipo de caso de teste é mais barato para projetar e executar em relação ao modelo estrutural.
O teste de caixa preta exercita o programa sob diversas massas de dados preparadas anteriormente para provocar situações esperadas, validando aquela função ou estimulando a probabilidade de uma falha ocorrer através de situações mais propícias a esta condição. [HEINEBERG, 2008] afirma que o processo de teste funcional normalmente envolve a criação de cenários de testes para o uso na avaliação das funcionalidades da aplicação, validando se o que foi especificado foi implementado corretamente. Segundo [SOMMERVILLE, 2003] os testes funcionais são abordagens derivadas das especificações dos programas ou dos componentes, e possuem características de caixa-preta. [MYERS, 1979] define os testes funcionais com um processo na tentativa de encontrar divergências entre requisitos e programa. Conforme [PFLEEGER,2004] cita os testes relatados anteriormente concentravam-se nos componentes e integração dos mesmos, a abordagem dos testes funcionais ignora a estrutura interna do  programa e foca seu objetivo na funcionalidade do sistema, os testes funcionais tem como base os requisitos funcionais.
 Exemplo de um tipo de teste que aborda esta técnica chamada de particionamento por equivalência, também conhecido por classes de equivalência, é um método que divide o domínio de entrada  de um programa em classes de dados  a partir das quais  podem ser criados casos de teste. Segundo [PRESSMAN, 2011] um caso de teste ideal descobre sozinho uma classe de erros que poderia de outro modo, requerer que fossem executados muitos casos de teste até que o erro geral aparecesse. O projeto de casos de teste para particionamento de equivalência é baseado numa avaliação das classes de equivalência para uma certa condição de entrada, desta forma eliminando os casos de teste redundantes. Outro exemplo de técnica de teste de caixa preta é o teste baseado em modelo que faz uso de informações contidas no modelo de requisitos como base para a geração de casos de teste.Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste.

As atividades de Teste de Software ainda podem ser divididas de acordo com a fase do desenvolvimento e a abordagem empregada, seja procedimental ou orientada a objeto (OO), conforme Beizer (1990) e Maldonado e Fabbri (2001). As fases são:

 Teste de unidade – aplicado a sub-rotinas e funções (na abordagem procedimental) e a métodos (na abordagem OO);
 Teste de integração – aplicado à relação entre dois ou mais subsistemas (na abordagem procedimental) e à classe, cluster, componente e subclasse (na abordagem OO); e
 Teste de sistema – na abordagem procedimental e na OO, é aplicado para verificação de se o sistema está de acordo com as especificações.
  

Este texto apresentou uma visão geral sobre qualidade e testes de software, caracterizando os objetivos desta fase e as divisões que permeiam as técnicas de teste . Conclui-se que a  área de teste de software vive em constante transformação, que segue de perto o contínuo crescimento do mercado de desenvolvimento de software. Na mesma medida em que ocorrem mudanças tecnológicas na área de desenvolvimento, também se torna necessária uma adequação das praticas de teste.

Ética Hacker


Matrix é uma trilogia cujo primeiro filme foi lançado em 1999, sucesso de bilheteria e crítica, arrecadou cerca de 456 milhões de dólares sendo que seu custo de produção foi estimado em 65 milhões de dólares. Este filme conta a história de Neo interpretado por Keanu Reeves. Neo é um programador que vive em um cubículo escuro e sente fortes dores de cabeça e sensações de que há algo de estranho no mundo em que vive. E suas sensações são corretas, pois esta história conta em um tempo muito afrente, um mundo dominado pelas máquinas, no qual os homens são aprisionados em casulos para gerar bioenergia, já que é esta a forma que as máquinas encontraram para garantir sua sobrevivência.
A Matrix seria uma espécie de computador central que gera na mente dos homens aprisionados sensações e experiências que os fazem crer que realmente vivem uma vida normal, as máquinas obrigam-se a fazer uso disto pela afirmação feita no filme de que um corpo não poderia viver sem uma mente. Após esta compreensão da temática, destaca-se a questão chave abordada no filme, a questão da escolha. O livre arbítrio neste contexto é tratado como um diferencial dado somente àqueles que aguentariam saber da verdade. Desta forma, acaba-se evidenciando através desta analogia umas das maiores qualidades do homem: a capacidade de ação por meio da razão.
Neo acaba tendo que tomar a difícil decisão de escolher entre a pílula vermelha ou azul, conhecer a verdade ou continuar na ignorância carcerária respectivamente. Ao escolher a vermelha ele buscou conhecer a verdade, porém dolorosa. A história conta também, que outros que passaram por esta situação preferiram permanecer na ignorância e disto conclui-se que a resistência a qualquer método de opressão só é possível através do conhecimento e que este exige no mínimo a valorização da liberdade. Através da reflexão acerca desta obra fictícia é possível abordar uma série das mais importantes questões filosóficas trazendo á tona motivos que tornam a ética indispensável para a vida das pessoas, sendo no âmbito social ou profissional independente dos diversos segmentos aos quais estas possam vir a pertencer.
Obviamente, este filme não trouxe novas questões para a filosofia. Para aqueles que conhecem é perceptível que este filme foi baseado em um diálogo travado pelo filósofo Sócrates com Glauco e que encontra-se descrito no livro “A República” de Platão, sob o título de “A Alegoria” ou “Mito da Caverna”, o qual narra a tentativa de Sócrates mostrar a Glauco através de uma analogia o caminho percorrido por um indivíduo na tentativa de se ver livre do mundo da ilusão e atingir a esfera da verdade, tentando demonstrar que a verdade não se encontra meramente através das aparências.
Esta explanação de Sócrates conta a história de pessoas que desde seu o nascimento são acorrentados no interior de uma caverna de modo que olhem somente para uma parede iluminada por uma fogueira, que ilumina um palco onde estátuas dos seres como homem, planta, animais etc. são manipuladas e vistas pelos prisioneiros apenas como sombras projetadas na parede, sendo a única imagem que aqueles prisioneiros conseguem enxergar. Acabam vendo estas encenações corriqueiramente e com passar do tempo tomam estas por referência e dão nomes a estas sombras e associam também sua regularidade fazendo competições entre eles para comparar o número de acertos em relação ao nome daquela sombra e sua respectiva aparição.
A história conta que em um determinado dia, um daqueles prisioneiros é forçado a sair da caverna. No momento em que é atirado para fora da caverna o sol cega seus olhos forjados praticamente pela escuridão, relutantes e demorados a entender a verdadeira realidade. Em um primeiro momento pensa em retornar para a caverna, entretanto ao passo que percebe que passou a vida toda julgando e crendo apenas em sombras e ilusões o homem se compadece de seus companheiros que ainda estavam a caverna e decide resgatá-los. Esta é uma parte sensível da história, já que como os prisioneiros não nunca tiveram contato com outra esfera a não ser a da realidade que presenciam, debocham de seu colega liberto e afirmam que este está louco e que se o mesmo não parasse com aquelas ideias acabariam por matá-lo, não aceitando a possibilidade de existência de outro cenário diferente daquele que conhecem.
Esta alegoria afirma que os prisioneiros são equivalentes as pessoas que segundo diferentes culturas, acostumam-se com mesmas noção por vezes insubjetivas que geram um juízo de fato sem que ao menos o indivíduo reflita sobre aquilo que acredita ideologicamente da mesma forma que aquilo o foi transmitido. Nesta linha de raciocínio conclui-se que o indivíduo pode vir a ser prisioneiro de uma caverna que ele próprio ignora. Atualmente, por muitas vezes o sentimento individualista toma o ser humano fazendo com que esqueça ou não queira ver os inúmeros problemas sociais existentes e por vezes com pouco conhecimento da verdade, as pessoas acabam não sendo racionais e críticas a respeito do que pode e deve ser feito para mudar o que está errado.
O indivíduo ciente torna-se refém de suas próprias escolhas e se este possui um bom nível de criticidade e sensatez compreende que as consequências de seus atos se realizados para o bem comum serão produtivos no presente e futuro. Para tanto, o requisito é estar ciente, consciente e desta forma o mais necessário é a busca constante da razão, que não é de difícil acesso e só depende da vontade de cada um. Após esta reflexão introdutória que conclui que a ética é intrínseca ao ser que deve querer possuí-la o texto segue com a óbvia informação de que a cultura hacker, como qualquer outra, também possui sua ética.
Os hackers são conhecidos pela maioria das pessoas como pessoas que criam e disseminam vírus, atacam computadores e espalham dados pessoais pela internet. O que pouca gente sabe, no entanto, é que a cultura hacker surgida na década de 1960 é responsável por uma série de soluções que são utilizadas no cotidiano. Para entender um pouco melhor, é necessário saber o que cada um dos nomes significa. Hackers, na verdade, são indivíduos que elaboram e modificam softwares e hardwares de computadores, seja desenvolvendo funcionalidades novas ou adaptando as antigas. Já cracker é o termo usado para designar quem pratica a quebra (ou cracking) de um sistema de segurança. Na prática, os dois termos servem para conotar pessoas que têm habilidades com computadores, porém, cada um dos "grupos" usa essas habilidades de formas bem diferentes. Os hackers utilizam todo o seu conhecimento para melhorar softwares de forma legal e nunca invadem um sistema com o intuito de causar danos. No entanto, os crackers têm como prática a quebra da segurança de um software e usam seu conhecimento de forma ilegal, portanto, são vistos como criminosos.
Definindo melhor, conforme a enciclopédia livre, hacker é um indivíduo que se dedica, com uma intensidade incomum, a conhecer e modificar os aspectos mais internos de dispositivos,  programas e redes de computadores. Graças a esses conhecimentos, um hacker frequentemente consegue obter soluções e efeitos extraordinários, que extrapolam os limites do funcionamento "normal" dos sistemas como previstos pelos seus criadores; incluindo, por exemplo, contornar as barreiras que supostamente deveriam impedir o controle de certos sistemas e acesso a certos dados. Abstraindo-se conceitos encontrados no site Hackerteen, postados pelo professor e sociólogo Sergio Amadeu o termo compartilhar era a regra e o esperado dentro da cultura hacker. O princípio do compartilhamento foi resultado da atmosfera informal e do acesso não burocrático aos recursos no MIT (Massachusetts Institute of Technology). No início da era dos computadores e da programação, os hackers do MIT desenvolviam os programas e os compartilhavam com outros usuários. Se o hack (termo utilizado para expressar o código do programa) fosse particularmente bom, então o programa poderia ser postado em um quadro em algum lugar perto dos computadores para que assim pudesse ser melhorado ou adaptado colaborativamente, e os programas que fossem construídos em cima deste, eram arquivados em fitas e guardados em uma gaveta de programas, de fácil acesso a outros hackers.
Segundo Pekka Himanen, escritor e estudioso deste movimento, um hacker adora encontrar desafios em que possa usar livremente sua inteligência para assim superá-los e no momento da obtenção do resultado compartilhá-lo. Pode-se afirmar que os valores mais importantes para um hacker são o conhecimento a liberdade e a colaboração (compartilhamento). Neste contexto, a crença no poder de uma máquina, como o computador, na capacidade da melhoria de vida da população é um estimulo a mais para os valores éticos deste grupo que trabalham de forma coletiva e aberta. Uma das mais revolucionárias tecnologias da atualidade, a internet, foi fomentada por este segmento. Sobre essa ética hacker, Pekka Himanen, em seu livro A Ética Hacker (2001), descreve os métodos de trabalho daqueles que atuam mais diretamente no desenvolvimento de softwares para computadores e, expandindo esse conceito, pensa que essa postura hacker pode ser, em última instância, uma postura para todos os campos das atividades humanas.
Ainda segundo este autor, são sete as características da chamada ética dos hackers: paixão, liberdade, valor social (abertura), nética (ética da rede), atividade, participação responsável e criatividade, todas elas devendo estar presentes nos três principais aspectos da vida: trabalho, dinheiro e ética da rede (HIMANEN, 2001, p. 125-127). Paixão também pode ser entendida como a palavra que descreve o que Linus Torvalds chamou de “entretenimento”, essa é o entusiasmo e o prazer de fazer o trabalho. Liberdade é descrita como a liberdade no estilo de vida. Usualmente, hackers não trabalham com horário fixo para produzir software, eles gostam da liberdade de serem capaz de trabalhar a hora que melhor os convêm. Valor social é referente ao trabalho feito “pela” comunidade “para” a comunidade e a apreciação de tal trabalho. A abertura é o conceito do trabalho ser aberto para ser cobrado, melhorado, copiado... Atividade é o conceito de fazer algo com suas crenças, é sobre colocar em prática os princípios de cada um. Consideração está relacionado com respeito, quando em comunidade todos podem participar e é importante ter consideração pelo outro para gerar um ambiente harmonioso. O último é criatividade, é o valor de criar algo novo, surpreendente, autêntico. É a inovação das características do software que o faz mais fácil, prático e completo.
Conforme publicação de Brunet, em seu artigo “Software livre e ética hacker como propulsores de projetos artísticos e culturais” inúmeros projetos de grande porte foram desenvolvidos com base nos valores da ética hacker:


“[...] são comumente encontrados nos projetos colaborativos artísticos e culturais na internet. Projetos como Wikipedia (http://pt.wikipedia.org), Freesound (http://freesound.iua.upf.edu), Slashdot (http://slashdot.org/), Metafilter (www.metafilter.com), Yellow Arrow Project (http://yellowarrow.net), Converse (http://converse.org.br), Our Media (http://www.ourmedia.org), Wikimedia Commons (http://commons.wikimedia.org) e Sito (http://www.sito.org) são trabalhos feitos por voluntários que realmente tem paixão uma paixão pelo que fazem.” (2010).

 Nelson Pretto, doutor em Ciências da Comunicação pela Universidade de São Paulo afirma que esses princípios dos hackers possibilitaram a construção do ciberespaço e que este com os aparatos tecnológicos digitais, possibilitou intrinsecamente a emergência de novas linguagens e de novas práticas de produção de conhecimentos e de culturas. Nestes preceitos, pode-se afirmar que diversas personalidades tiveram uma conduta hacker durante sua trajetória e a simples frase da poetisa brasileira, Cora Coralina além de transmitir bem o sentimento deste grupo é uma prova disto: “Feliz aquele que transfere o que sabe e aprende o que ensina”. Sendo assim, conclui-se que no momento em que sejam incentivados valores semelhantes aos cultivados por este segmento, muitas novas ideias e projetos surgirão já que a criatividade que é a base da inovação sustenta-se sobre os pilares do conhecimento.
 


REFERÊNCIA

PLATÃO. A República. Lisboa: Fundação Calouste Gulbenkian, 1996. RIBEIRO, Renato Janine. Ser Ético, Ser Herói. Disponível no site: <http://www.renatojanine.pro.br/Etica/heroi.html>. Acesso em: 11/09/2012.
WIKIPEDIA, The Free Encyclopedia: Hacker. Disponível em: <http://pt.wikipedia.org/wiki/Hacker >. Acesso em: 11/09/2012.

WIKIPEDIA, The Free Encyclopedia: Ética Hacker. Disponível em: <http://pt.wikipedia.org/wiki/%C3%89tica_hacker>. Acesso em: 11/09/2012.

WIKIPEDIA, The Free Encyclopedia: Matrix. Disponível em: <http://pt.wikipedia.org/wiki/Matrix>. Acesso em: 11/09/2012.

AMADEU, Sergio.  Hackerteen : O juízo de fato da ética hacker. Disponível em: <http://www.hackerteen.com/pt-br/link/etica-hacker-faixa-preta.html>. Acesso em: 11/09/2012.
BORGES, Jamile. Pirataria e ética hacker. Disponível em: <http://www.novae.inf.br/site/modules.php?name=Conteudo&pid=1428 >. Acesso em: 11/09/2012.

PRETTO, Nelson. Redes colaborativas, ética hacker e educação. Educação em Revista, Belo Horizonte, n.3, dez 2010.

HIMANEN, Pekka. The hacker ethic: a radical approach to philosophy of business. New York: Random House Trade Paperbacks, 2001.
BRUNET, Karla Schuch. Software livre e ética hacker como propulsores de projetos artísticos e culturais na Internet. Revista Digital do LAV, v. 2, p. 1, 2009. [Pdf]

Métricas de Software


    As métricas de software são os sistemas métricos utilizados para medir software, com o objetivo de obter informações que sejam úteis aos desenvolvedores, podendo assim, auxilia-los na administração do projeto bem como, em todo o ciclo de vida da engenharia de software. “Uma métrica de software é qualquer tipo de medição que se refira a um sistema de software, processo ou documentação relacionada” (SOMMERVILLE, 2003, p. 468). Sommerville ainda define assim o papel das métricas de software: A medição de software se ocupa em obter um valor numérico para alguns atributos de um produto ou de um processo de software. Comparando esses valores um com os outros e com os padrões que se aplicam em uma organização, é possível tirar conclusões sobre a qualidade do software ou dos processos de software.(SOMMERVILLE, 2003, p. 468). 

  Segundo esta visão percebe-se que as métricas de software baseiam-se na aplicação de padrões bem definidos dentro da organização. Por outra perspectiva a importância de se usar dados numéricos, obtidos através da aplicação de métricas de software, segundo Koscianski e Soares (2006, p. 57) se justifica pelo fato de que os números permitem análises, comparações e combinações que são impossíveis de fazer com outros tipos de informações. Para Pressman (2002, p. 506) as métricas de software ajudam na avaliação dos modelos de análise e projeto, fornecem uma indicação da complexidade do projeto procedimental e do código-fonte além de facilitar o processo de teste de software tornando-o mais efetivo. As métricas de software abrangendo todo o ciclo de vida do software possuem um vasto campo de pesquisa: 

    O assunto ‘métricas de software’ é bastante extenso. Exemplificando, Xenos [2000] cita um relatório com mais de 200 métricas diferentes, um indício de que caracterizar o funcionamento de um software não é uma tarefa simples. (XENOS apud KOSCIANSK; SOARES, 2006, p. 224).  Dessa maneira existem diferentes classificações na literatura a respeito das métricas de software. Essas classificações servem como guias para a escolha de métricas de software que se encaixe em um determinado contexto. A respeito das medições é necessário ainda explanar as diferentes fontes de ruídos que podem afetar o resultado da aplicação das métricas. Essa explanação é feita a seguir.



 Fontes de Ruído nas Métricas de Software 


   Ao se realizar uma medição espera-se obter dados legítimos sobre o objeto em questão. Segundo Koscianski e Soares (2006, p. 57) no domínio das ciências exatas e da engenharia os valores das medições necessitam de precisão, pois um pequeno erro de medida pode ter conseqüências bastante significativas. Porém, nem sempre o resultado da aplicação de uma métrica representa o valor real que seria obtido em condições ideais.  O motivo dessa distorção no resultado de uma medição são as fontes de ruídos. Exemplificando na engenharia civil as fontes de ruídos que poderiam influenciar nas medições de um projeto de um prédio seriam: a umidade relativa do ar da região que poderia modificar as propriedades de certos materiais utilizados na obra, o clima e o tipo de terreno onde o prédio será construído. Essas fontes de ruídos, portanto são devidamente tratadas pelos engenheiros e dessa maneira os prédios são construídos. 

    As aplicações de métricas em software também estão sujeitas a interferência de ruídos que segundo Koscianski e Soares (2006, p. 58) basicamente estão divididos  em duas categorias: os ruídos provenientes dos usuários e os ruídos provenientes do hardware. Os ruídos que são influenciados pelos usuários podem ser vistos em testes práticos realizados em software para obter informações relativas a sua usabilidade: Exemplos de medidas que se enquadram aqui são aquelas envolvendo a habilidade ou a opinião dos usuários, como medir o tempo para  cumprir uma determinada tarefa; ou julgar em uma escala de zero a dez a qualidade de uma interface. Embora os números obtidos possam refletir alguma informação sobre a qualidade do software, carregam consigo uma grande margem de incerteza. (KOSCIANSKI; SOARES, 2006, p. 59). Uma possível alternativa para amenizar essa margem de incerteza seria utilizar técnicas estatísticas tais como Média e Desvio-Padrão possibilitando uma maior exatidão a respeito dos dados coletados.

   Há também os ruídos provenientes do hardware, ao se avaliar o desempenho de um software, por exemplo, deve-se levar em conta fatores como: CPU utilizada, quantidade de memória, periféricos conectados ao computador e ainda a presença de outros softwares rodando na máquina. Ou seja, fatores técnicos do hardware como, quantidade de  cache do processador e dos discos rígidos e a disposição dos dados em memória tudo isso influencia em um resultado da aplicação de uma métrica de software que dependa da execução do mesmo sobre determinado hardware. Percebe-se, portanto que a utilização de métricas de software está sujeita a variações e influências nos seus resultados e dessa maneira deve-se minimizar estas influências para que os dados representem com mais fidelidade  o objetivo da medição.

Como instalar o Cucumber no Windows e Linux


Depois de sofrer um pouco, resolvi compartilhar um passo a passo para instalação desta ferramenta. Espero que seja útil!!!


Primeiro no Windows (aqui era o 7):



1 - fazer download do ruby para windows: http://rubyinstaller.org/, instalar a versão mais recente, e certificar-se de marcar a opcão "Add ruby executables to your Path"
2 - Instalar o kit de desenvolvimento Ruby segundo instruçoes: https://github.com/oneclick/rubyinstaller/wiki/Development-Kit que é a seguinte
 1 - baixar http://rubyinstaller.org/downloads/
 2 - duplo clique e instalar em c:/devkit
 3 - abrir o diretório por linha de comando (cd)
 4 - executar "ruby dk.rb init" para gerar o config.yml
 5 - executar "ruby dk.rb install" isso instala arquivos necessários para implementar um rubygem
 6 - teste executando "gem install rdiscount --platform=ruby
3 - executar em linha de comando "gem -v" para ver se a instalaçao deu certo
4 - executar "gem install cucumber" para baixar e instalar o cucumber
5 - baixar http://adoxa.3eeweb.com/ansicon/ extrair e colocar em C:utils, na janela de comando dar cd até abrir o diretório e depois o diretorio x64 ou x86 dependendo do windows usado, e executar ansicon -i
6 - sair dessa e ir para principal, executar "gem install capybara" 
7 - executar "gem install rspec"
8 - baixar http://www.richardlawrence.info/wp-content/uploads/2012/08/ruby-capybara.zip, descompacte e abra por linha de comando o diretorio onde foi extraido e execute "cucumber" para testar.



Agora no Ubuntu 11.04 (Prefiro e Recomendo!!!)



1- sudo apt-get install build-essential curl zliblg-dev libreadline5-dev
2 -sudo apt-get install libreadline-gplv2-dev
3- sudo apt-get install lib64readline-gplv2-dev
4- sudo apt-get install libssl-dev libxml2-dev libxslt-dev sqlite3 libsqlite3-dev
5- sudo apt-get install git-core
6- sudo apt-get install gitk
7- sudo apt-get install curl
8- curl -L https://get.rvm.io | bash -s stable --ruby
9- exit
10- curl -L https://get.rvm.io | bash -s stable --rails
11- exit
12- source /home/caminho/.rvm/scripts/rvm
13- type rvm | head -n 1
14- rvm requirements
15- sudo apt-get install build-essential openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion pkg-config
16- exit
17- type rvm | head -n 1
18- source /home/caminho/.rvm/scripts/rvm
19- type rvm | head -n 1
20- rvm requirements
21- type rvm | head -n 1
22- rvm install ruby-1.9.3-p0
23- rvm --default ruby-1.9.3-p0
24- gem install bundler
25- sudo apt-get install vim
26- mkdir ~/projects
27- cd projects/
28- mkdir cucumber-exercises
29- cd cucumber-exercises/
30- touch Gemfile
31- vim Gemfile
32- bundle install
33- cucumber --help
34- cucumber
35- mkdir features
36- cd features/
37- mkdir step_definitions
38- mkdir support
39- cd support/
40- touch env.rb
41- vim env.rb
42- cucumber




Conteudo Gemfile

source 'http://rubygems.org'
gem 'cucumber'
gem 'capybara'
gem 'rspec-expectations'
gem 'pry' #debug
gem 'pry-nav'



Conteudo env.rb (aqui configura conforme a necessidade/preferência)

require 'cucumber/formatter/unicode'
require 'capybara/cucumber'
require "selenium-webdriver"
Capybara.run_server = false
Capybara.default_selector = :css
Capybara.default_driver = :selenium
Capybara.app_host = 'link'
Capybara.default_wait_time = 60



Concordion




      O Concordion foi desenvolvido no Reino Unido em 2006 por David Peterson, e se encontra sobre a licença Apache v2.0. Dentre as principais vantagens buscadas com a construção      do   framework      estão, a   melhora     da   legibilidade,   a  facilidade    de   uso  e diminuição do uso de scripts (Peterson, 2011). Dentro dos roteiros de testes (test scripts) está o comportamento que um teste está tentando demonstrar, mas por vezes, o requisito testado, por não ser explícito, é difícil de ser reconhecido aquilo que está sendo testado.  Concordion,   é   um   framework   de   auxílio   na   escrita   de   testes   de   aceitação   tanto   para linguagem Java quanto para outras como Python, .NET e Ruby. A utilização de testes de    aceitação    tem   como    principal   propósito     efetuar   uma   validação     daquilo   que   foi  implementado,       onde     são   verificados    se  todos     os requisitos     estão   implementados corretamente       e  se  o  software     está  pronto    para   uso   do   usuário   final  (Pressma  & Pressman, 2004). 
         Os testes de aceitação são o foco principal do framework escolhido, sendo que, através     da   criação   de   testes   para   as   funcionalidades      e  uso    de  páginas     web,    é proporcionado a seu utilizador uma boa forma de execução e armazenamento de testes realizados, contendo   informações   pertinentes   ao   caso   juntamente   com   seus   resultados (Peterson,     2011).    Para   execução     dos  testes,   o  Concordion      utiliza-se  do   JUnit,   um framework para testes de unidade da linguagem Java. 
 Com a integração direta do Concordion com o JUnit, métodos de testes podem ser escritos em uma classe Java, criadas em um pacote de testes, e chamados em uma página   HTML,   já   que   a   utilização   de   páginas   HTML   é  à base   do   funcionamento   do Concordion.   Um   de   seus   principais   objetivos   é   permitir   que   os   testes   de   aceitação escritos   possuam     alta    legibilidade,   podendo      ser  escritos   de maneira     simples,     com  pontuações, parágrafos e tabelas de forma livre, sem estar preso a um tipo de estrutura obrigatória (Peterson, 2011). 
        Para que os testes sejam  mostrados na página HTML, na qual se escrevem os testes   de   aceitação   desejados,   são   utilizadas  tags.   As   tags   são   utilizadas  para   que   a comunicação        com    a  classe    de  testes   do   JUnit    seja  feita,  podendo      ser  passados parâmetros  a  serem avaliados. Depois de executados os testes da classe do JUnit, um arquivo   HTML       é   gerado  contendo   os      resultados  produzidos,  podendo   indicar   se   o resultado foi positivo, negativo ou de exceção.      

         Por se tratar de um framework que permite a utilização de diversas linguagens, o Concordion       possui    uma    boa    portabilidade     entre   sistemas.    O   framework      possui compatibilidade   com   as     seguintes   linguagens   de   programação:   Java,   .NET,   Ruby   e Phyton. Para o código Java, que é portável entre sistemas Linux e Windows, somente é necessário uma máquina virtual para execução do código. As linguagens Ruby e Phyton geralmente       já   possuem      seus   compiladores       instalados    na    grande    maioria     das distribuições Linux, caso não estando, é necessário um curto tempo para sua instalação e configuração. 
         A linguagem .NET, que é proprietária da Microsoft, possui uma implementação própria da linguagem para funcionamento em ambiente Linux, o Mono. O Mono é uma implementação open source de C# e de uma máquina virtual compatível com o .NET, permitindo que seja utilizado o framework de desenvolvimento .NET tanto em Linux quanto em Mac. 
      Tutoriais   de   instalação    para   os ambientes de desenvolvimento JAVA mais utilizados, o NetBeans IDE e o Eclipse IDE:

         1.  Download do Concordion: para efetuar o download do framework basta acessar sua página de downloads: http://www.concordion.org/Download.html 

         2.  O   arquivo   baixado   possuirá   as   bibliotecas   tanto   do   JUnit   quanto   do   Concordion,         sendo necessário extraí-las para um pasta no computador. Recomenda-se que seja  na pasta lib do JRE ou JDK instalado, a fim de manter um padrão. 

         3.  Extrair todos os arquivos .jar encontrados na pasta lib e dist do arquivo baixado para  a biblioteca do JDK/JRE.  



  • NetBeans (Versão utilizada: 7.1.2) 



         1.  Criar um novo projeto Java Web -> Aplicação Web. 

         2.  Depois de criado, clicar como botão direito no projeto e selecionar Propriedades. 

         3.  Na aba Bibliotecas, clique em adicionar JAR/Pasta e navegue até o local onde foram              extraídos os arquivos .jar. 

         4.  Selecione o .jar do Concordion, o do JUnit e mais dois auxiliares: xom e ognl sendo estes 4 os arquivos necessários para o funcionamento. 

         5.  Confirme e feche as janelas. Instalação concluída 

  •       Eclipse (Versão utilizada: Indigo


         1.  Acesse    o  menu   File  e  escolha  criar  um  novo  Dynamic    Web    Project  (Projeto              dinâmico web); 

         2.  Clicar com o botão direito no projeto e selecionar Proprieties; 

         3.  Na aba Java Build Path clique em Add External JARs e navegue até o local onde foram extraídos os arquivos .jar; 

         4.  Selecione o .jar do Concordion, o do JUnit e mais dois auxiliares: xom e ognl sendo  estes 4 os arquivos necessários para o funcionamento 

         5.  Confirmar a adição e fechar as janelas. Instalação concluída.