Mohamed Mahmoud (El-Geish) : Testing

Test Patterns

mohamedg — Thu, 14 May 2009 08:53:46 GMT

Just like design patterns, the use of test patterns will make your life easier. A lot of the common testing methods can be reused. Along with the benefits of reuse, using patterns makes it easier to explain to others what you are going to do in a word...(read more)

Windbg

mohamedg — Fri, 27 Mar 2009 06:26:02 GMT

Using Windbg, aka Debugging Tools for Windows , is a great way for debugging, crash analysis, and reading dump files. If you’re not a keyboard person who likes to write commands and be in the driver’s seat, you might not like it at the first glance, but...(read more)

!exploitable

mohamedg — Mon, 23 Mar 2009 07:22:12 GMT

!exploitable is a crash analyzer plug-in for windows debugger (windbg) that does post-mortem analysis of a crash and assists its security risk, very cool! The project is licensed under Microsoft Public License (Ms-PL) and you can download it at codeplex. The analyzer rates the crash one of the following ratings: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown. Here are the usage instructions as listed on the project’s website:

!exploitable
Gives an analysis, including a proposed bug title

!exploitable -v
Gives a verbose analysis

!exploitable -m
Gives the same output as -v, but formatted for easy machine parsing

!exploitable -jit:address
Use the JIT Exception Record to determine the exception

!ror [-n <Rotation Count> [-c] <Value>
Get the API name for hash value <Value> using rotation count <Rotation Count>. Use -c to do a reverse lookup from an API name to a hash value. Run !ror without options for examples.

!xoru -b <addr> <length> <key>
Do the Xor transformation on the buffer from address <addr> to address <addr> + <length> using the key <key> and disassemble the buffer. Use -b to leave the transformed buffer in memory. Run !xoru without options for examples. You can do other types of transformation using xora, xorui, xorua, suba, subu, adda, addu, rola, or rolu.

For more info about the project please visit msec.

File System Limits

mohamedg — Sat, 15 Dec 2007 01:53:00 GMT

When you create a file or a folder, do you check that the full path is not too long?! Make sure that you handle the PathTooLongException:

Try to exceed the maximim lenght on Windows, and you'll get this error:

Here are some limits in Windows APIs that you should know about:

#define MAX_PATH 260 // Maximum length of full path
#define MAX_DIR 256 // Maximum length of path component
#define MAX_FNAME 256 // Maximum length of file name component
#define MAX_EXT 256 // Maximum length of extension component

And here are the limits of almost all file systems: http://en.wikipedia.org/wiki/Comparison_of_file_systems#limits

For more details and workarounds, please read: http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

Pseudo-localization

mohamedg — Fri, 07 Dec 2007 04:28:40 GMT

It's an economic need to develop international software as you need to reach as many customers as possible all over the world. Let's tackle a simple scenario, imagine that you will develop an application that has a bilingual UI: English and Arabic. It's very easy to develop everything in English, but what about Arabic? When you designed the UI, did you count for the length of the Arabic text? Did you forget to use resource files? If you fail to deliver the application in all supported languages, you will need to rewrite so much code, not to mention the hassle of explaining this wasted time to your team leader!

You'll need to test the application's UI in different languages before you ship it, and for that you need to hire a translator to translate each and every word into Arabic. What about the tests that you run during the development? Can you afford to pay the translator for text that might change in the next build? It's always an option that you buy a tool that generates inaccurate translation, but this might not be always available, especially for a complex language like Arabic with so many grammar rules. Another option is to use pseudo-localization. It means that you will use pseudo-translated text as if it were the real translation. The pseudo-localized text should mimic the behavior of the target locale, and it should cover scenarios like bidirectional (BiDi) text. For instance, in Arabic, the flow of words is from right to left (RTL), but when a number is written, it's written from left to right (LTR). Hence, you can have RTL text, followed by a number, then some other RTL text afterwards. The produced text will be gibberish for the tester, even if she knows the language, because it's not the real translation, that's why the tester might like to add the original text or the resource ID within the pseudo-localized code in order to recognize it. In order to be on the safe side, the pseudo-localized text should be longer than the original, to test whether it can fit in the UI or not. It may also be surrounded by markers, like brackets, to make sure that the text fits without cuts. Producing pseudo-localized resource files is an easy task and extremely economical at the same time. However, it's insufficient. You need to keep in mind other requirements needed for developing international software during design and development phases. This is just a sanity test; you will need to tackle more issues like mirroring, resource files, etc.

For more info, please read: Globalization Step-by-Step and Testing for World-Readiness