Showing posts with label Performance Testing. Show all posts
Showing posts with label Performance Testing. Show all posts

Thursday, August 26, 2010

Some Opposing goals for WEB - SECURITY Vs Reliability Performance Usability.txt

There are many opposing goals in software creation but none is more important than security...

Most important goals among these are security versus reliability.Reliability often requires developers to write more code (for example, error-handlers) and more code means more opportunity to write bugs. Most of the times these error handlers are under-exercised in testing and chances that it has security bugs is greater.
Error code needs to be carefully checked for security flaws....

Another important opposing factor is performance. The more code that is pushed to the client the faster the server will run.But more code on the client means more opportunity for security breaches because the user has access to the code running on the client...

Usability may be next an opposing target to security. Usability means giving information to users to make the system as easy to use as possible.Easy to use often means easy to hack :-) ..Specifically, when error messages reveal information that is helpful to an attacker.

Thursday, August 27, 2009

What is BoudsChecker : Memory Leak Testing Tool

BoundsChecker is a memory checking tool used for C++ software development with Microsoft Visual C++. It is part of the DevPartner for Visual C++ BoundsChecker Suite. Comparable tools are Purify, Insure++ and Valgrind.

BoundsChecker can be run in two modes: ActiveCheck, which does not instrument the application, and FinalCheck, which does.

ActiveCheck performs a less intrusive analysis and monitors all calls by the application to the C Runtime Library, Windows API and calls to COM objects. By monitoring memory allocations and releases, it can detect memory leaks and overruns. Monitoring API and COM calls enables ActiveCheck to check parameters, returns and exceptions and report exceptions when they occur. Thread deadlocks can also be detected by monitoring of the synchronization objects and calls giving actual and potential deadlock detection.

FinalCheck requires an instrumented build and gives a much deeper but more intrusive analysis. It provides all of the detection features of ActiveCheck plus the ability to detect buffer overflows (read and write) and uninitialized memory accesses. It monitors every scope change, pointer and memory usage.

Saturday, June 27, 2009

How to create a low-memory conditions for Testing your Software Application

All this was shared by one of my team-mate for performance testing where we want to test our software performance at different memory levels. Here are the exact details:

*********************
Using the boocfg command, you can restrict the amount of physical memory available to windows. So typing the following command will reduce the memory available to Windows by 768 MB. After this, on a machine with 1GB RAM only 256 MB will be available to Windows, 768 MB
will not be available:

bootcfg /raw "/burnmemory=768" /A /ID 1

After this reboot the system and Windows will reboot with only 256 MB
of memory available to it.

*********************

To remove this entry, the following steps should be performed:

1. Go to Control Panel
2. Open System dialog
3. Open Advanced Tab on System Dialog
4. In Startup and Recovery Section, click Settings button
5. the Edit button in System Startup section
6. Boot.ini opens in notepad, delete the "/burnmemory=768" entry
7. Reboot the system

*********************