Posts filed under ‘Debugging’

71-660 Exam: Windows Internals

http://weblogs.asp.net/andrenobre/archive/2008/08/01/71-660-exam-windows-internals.aspx

Abraços.
— André

Agosto 1, 2008 at 1:20 pm Deixe um comentário

Testes de Qualidade (SQC)

Eu sempre tive uma opinião um pouco divergente da maioria em relação a testes de qualidade. Para mim, a equipe de testes deve saber tanto quanto ou até mais que a equipe de desenvolvimento. Saber procurar um bug, investigar e dar a solução não é tarefa para qualquer um. E ao investigar aplicações .NET, é possível utilizar alguns recursos extras, que podem auxiliar e facilitar a vida dos testers.

Antes de tudo, é importante esclarecer do que exatamente estou falando. Qual é o tipo de teste a que estou me referindo e quando ele acontece.

Software Quality Control (SQC) consiste em verificar e validar a qualidade dos softwares envolvidos. Tecnicamente, este controle é efetuado através de testes (unit, integration ou system). Normalmente, este tipo de testes de software é realizado ao final do processo de desenvolvimento (ou de suas iterações), antes do produto entrar em homologação. O objetivo é garantir que o software desenvolvido está de acordo com os requisitos de negócio, funcionais e de qualidade de serviço (Quality of Service Requirement).

E aqui começa a dificuldade: como validar e garantir todas essas questões, e quais recursos podem auxiliar neste árduo trabalho?

Voltando ao processo, o teste de qualidade começa quando o desenvolvimento acaba (claro, não vamos entrar em detalhes de testes de desenvolvedor, etc). Portanto, a única “coisa” que o responsável pelo teste tem em mãos é um build (ASP.NET, Windows Formas, Smart Client, …), simples e direto. Muito provavelmente não terá em mãos os códigos-fonte, estrutura do projeto e detalhes da implementação. Por esse motivo, este build deve fornecer o máximo de informações para investigação técnica, através de arquivos PDB (Program Database) e versões em Debug.

Através destas informações, é possível localizar algum erro mais a fundo, onde ocorreu, o stack do CLR, o que estava na memória, onde as threads estavam paradas, entre outras informações importantes.

SQC não é uma tarefa fácil. Ao achar um erro, é necessário saber o que estava acontecendo em todo o ambiente. Se o erro é de OutOfMemory, por exemplo, o que ocasionou este erro, como o GC estava se comportando, como estava a aplicação neste momento. Por isso, equipe de testes tem que tem um conhecimento muito grande sobre todo o funcionamento do CLR, desde declarações de variáveis a threads, GC e concorrência.

Efetuar testes sem saber o que acontece por baixo dos panos não tem valor algum.
Reportar erros qualquer pessoa pode fazer. Descrever o porquê é o segredo de bons profissionais.

Abraços e até a próxima!

Abril 9, 2008 at 6:20 pm Deixe um comentário

Blog Chat sobre Debugging

Nesta quarta-feira aconteceu no blog da Tess e do Tom, um chat blog sobre Debugging.
O papo correu muito bem e muito interessante, com muitas dúvidas solucionadas, sugestões e coisas engraçadas.

É muito legal ver estas iniciativas partirem de profissionais do nível destes dois. A oportunidade de participar de uma conversa, como velhos amigos ou colegas de trabalho, é realmente incomparável.

Acompanhem agora os posts que irão detalhar as nossas conversas 🙂

http://blogs.msdn.com/tess/archive/2008/04/02/live-blog-chat-about-asp-net-and-debugging-with-windbg-and-sos-10-am-est-4-pm-cet.aspx

http://blogs.msdn.com/tom/archive/2008/04/02/recap-asp-net-blog-chat.aspx

Abraços!

Abril 3, 2008 at 2:55 am Deixe um comentário

.NET Debugging Demos Lab

Tess Ferrandez, uma das minhas referências em Debugging, está escrevendo alguns labs sobre Debugging avançado. Com certeza vale a pena!

.NET Debugging Demos Lab 1: Hang

Abraços!

Fevereiro 8, 2008 at 1:40 am Deixe um comentário

Coisas que aprendi e gostei sobre Debugging – Parte 1

Algumas dicas que podem ajudar seu dia-a-dia na eterna luta contra os bugs J

1.     O erro de produção não acontece na minha máquina de desenvolvimento!
Não é a toa que coloquei este item em primeiro. É o item que mais gosto e que acho mais útil. Uma das coisas mais difíceis em debugging é reproduzir um erro. E um dos maiores erros é tentar reproduzir este erro em um ambiente totalmente diferente de onde este erro aconteceu. Portanto, tenha instalado em sua máquina de desenvolvimento uma máquina virtual, com a configuração idêntica (ou praticamente) da configuração do servidor de produção. Utilize Remote Debugging com Visual Studio e já era! 

2.     Administrador não desenvolve!
Eu vou abrir o jogo com vocês: sempre achei esta observação meio inútil. Por quais motivos eu nunca deveria desenvolver utilizando um usuário com privilégios de administrador? Que besteira…Agora acredite em mim: não faça isso. Um usuário com privilégios de administrador tem permissões para tudo, e com certeza seu servidor de produção não permite que este tipo de usuário execute sua aplicação. Portanto, antecipe-se aos erros e programe com um usuário comum, com as mesmas permissões do servidor de produção. Com isso, você conseguirá garantir que todas as permissões necessárias estão sendo tratadas. 

3.     Desenvolvimento Pró-Ativo
Como Edsger Dijkstra, se debug é o processo para remover os bugs, programar é o processo para criá-los. Partindo deste pensamento, por que não evitar os bugs? Por que não programamos pensando em evitar bugs, além de resolver os problemas? Muitos destes bugs ocorrem por falta de um simples if (obj != null), por incrível que pareça!
 

Novembro 5, 2007 at 4:50 pm 1 comentário

Debug or Release: Como identificar um assembly?

Quando uma compilação é executada, várias informações são inseridas no assembly, informando o runtime sobre o código gerado, otimizações, etc.

Para identificarmos se um assembly foi gerado ou não em modo Debug, basta verificarmos se uma destas informações está presente, armazenada em um attribute class do assembly, System.Diagnostics.DebuggableAttribute.

Depois de recuperar o objeto DebuggableAttribute do assembly, precisamos saber se o JIT está gerando informações para o debug durante a geração de código, através da propriedade IsJITTrackingEnabled. Se este valor estiver como true, seu assembly foi compilado como Debug.

Update 1: Vou acertar a formatação do código, já coloco novamente.

Abraços!

Março 5, 2007 at 3:08 pm Deixe um comentário


Calendário

Agosto 2017
S T Q Q S S D
« Ago    
 123456
78910111213
14151617181920
21222324252627
28293031  

Posts by Month

Posts by Category