Tuesday, May 24, 2011

Performance & Security Testing Checklist

Creating checklists for performance & security is extremely important. This checklist helps in better definition of performance and security requirement. In the absence of properly defined performance & security testing requirements, teams can spend great deal time in things which probably does not matter much.

LOAD

  • Many users requesting a certain page at the same time or using the site simultaneously.
  • Increase the number of users and keep the data constant.
  • Does the home page load quickly? within 8 seconds.
  • Is load time appropriate to content, even on a slow dial-in connection?
  • Can the site sustain long periods of usage by multiple users?
  • Can the site sustain long periods of continuous usage by 1 user?
  • Is page loading performance acceptable over modems of different speeds?
  • Does the system meet its goals for response time, throughput, and availability?
  • Have you defined standards for response time (i.e. all screens should paint within 10 seconds)?
  • Does the system operate in the same way across different computer and network configurations, platforms and environments, with different mixes of other applications?
VOLUME
  • Increase the data by having constant users.
  • Will the site allow for large orders without locking out inventory if the transaction is invalid?
  • Can the site sustain large transactions without crashing?
STRESS
  • Increase both number of users and the data.
  • Performance of memory, CPU, file handling etc.
  • Error in software, hardware, memory errors (leakage, overwrite or pointers).
  • Is the application or certain features going to be used only during certain periods of time or will it be used continuously 24 hours a day 7 days a week? Test that the application is able to perform during those conditions. Will downtime be allowed or is that out of the question?
  • Verify that the application is able to meet the requirements and does not run out of memory or disk space.
SECURITY
  • Is confidentiality/user privacy protected?
  • Does the site prompt for user name and password?
  • Are there Digital Certificates, both at server and client?
  • Have you verified where encryption begins and ends?
  • Are concurrent log-ons permitted?
  • Does the application include time-outs due to inactivity?
  • Is bookmarking disabled on secure pages?
  • Does the key/lock display on status bar for insecure/secure pages?
  • Is Right Click, View, Source disabled?
  • Are you prevented from doing direct searches by editing content in the URL?
  • If using Digital Certificates, test the browser Cache by enrolling for the Certificate and completing all of the required security information. After completing the application and installation of the certificate, try using the <-- Backspace key to see if that security information is still residing in Cache. If it is, then any user could walk up to the PC and access highly sensitive Digital Certificate security information.
  • Is there an alternative way to access secure pages for browsers under version 3.0, since SSL is not compatible with those browsers?
  • Do your users know when they are entering or leaving secure portions of your site?
  • Does your server lock out an individual who has tried to access your site multiple times with invalid login/password information?
  • Test both valid and invalid login names and passwords. Are they case sensitive? Is there a limit to how many tries that are allowed? Can it be bypassed by typing the URL to a page inside directly in the browser?
  • What happens when timeout is exceeded? Are users still able to navigate through the site?
  • Relevant information is written to the log files and that the information is traceable.
  • In SSL verify that the encryption is done correctly and check the integrity of the information.
  • Scripting on the server is not possible to plan or edit scripts without authorization.
  • Have you tested the impact of Secure Proxy Server?
  • Test should be done to ensure that the Load Balancing Server is taking the session information of Server A and pooling it to Server B when A goes down.
  • Have you verified the use of 128-bit Encryption?

Reference - http://www.testinggeek.com/performance-security-testing-checklist

2 comments:

  1. Very nice and interesting post. I have even framed few points about Security Testing Check List. Hope you would like it - http://bit.ly/1RaHeDx

    ReplyDelete

^ Go to Top