What is Security Testing?

Security testing is related to the security of data and the functionality of the application. You should be aware of the following concepts while performing security testing:
1. Confidentiality - The application should only provide the data to the relevant party e.g. one customer's transactional data should not be visible to another customer; the irrelevant personal details of the customer should not be visible to the administrator and so on.

2. Integrity - The data stored and displayed by the application should be correct e.g. after a withdrawal, the customer's account should be debited by the correct amount.

3. Authentication - It should be possible to attribute the data transmitted in the application to either the application or the customer. In other words, no one other than the customer or the bank should be able to create or modify any data.

4. Authorization - The application or a user should only be able to perform the tasks which they are respectively authorized to perform e.g. a customer should not be able to withdraw more than the balance in their account without having an overdraft facility, the application should not be able to levy charges on a customer account without prior customer approval.
5. Availability - The data and functionality should be available to the users throughout the working period e.g. if the bank's operating times are from 8 a.m. to 8 p.m. on all working days, it should be possible for a customer to access their account and make the necessary transactions on their account.

6. Non-repudiation - At a later date, it should not be possible for a party to deny that a particular transaction or data change took place e.g. if a customer withdraws an amount from their account, this should trigger the relevant actions (posting to their transaction records, debiting their account and sending them a notification etc.).

In your question, you mentioned that you wish to avoid any data breach by hackers. You should understand that hackers are not the only people from whom the application functionality and data need to be protected. There are other people that you need to consider as well:

1. Disgruntled customers
2. Unhappy or malicious employees of the bank
3. Unprofessional service providers e.g. an unprofessional hosting company that may have access to the application and the data
4. Unprofessional auditors

Further, since financial data is so important, banking applications in certain countries have to be compliant to the relevant financial standards. Research the relevant standards that your application needs to follow.
Creating a secure application involves a lot of work in designing a secure application and designing a secure data store. Even after deployment, the application should be closely monitored to ensure that the data is being accessed by only the authorized people. If any security breach is reported, it should be analyzed carefully and the loopholes plugged.
Now, let us discuss the actual security testing. You should design security tests based on at least the following:

1. Stated security requirements
2. Security-related standards that the application should follow Assuming that it is a web application,
3. Common vulnerabilities found in web applications
4. Different browser versions on different operating systems (here you should note that implementing security only on the client-side may not suffice)
In your initial tests, you may want to use automated testing tools e.g. web vulnerability scanners, password crackers, web proxy tools etc. Based on your learning, you may want to execute the more complex security tests by hand. Keep yourself updated about the latest hacks and test them on your application before every release.

As you might now appreciate, security testing is a vast area of knowledge and practice. In order to do justice to security testing, it is better to have a dedicated team for security testing

"Object reference not set to an instance of an object" analysis error in load runner

This error comes when the following files in (Analysis Install dir)\bin\dat\ are corrupted:

loader2.mdb, loader.mdf, loader.ldf
Solution:

You need to restore these files; take these files from another machine where you have installed the Analysis. Or Re-install the Analysis on your machine after a clean uninstall

Prerequisites for load Testing in load runner

Important Set up before load testing includes:

A suitable time to load-test the application, for instance when no development work is taking place on the server (load testing may cause the server to crash) and/or no other users are accessing the server (else the testing results would not yield the correct measures)
  1.  The performance metrics, accepted levels, or SLAs and goals
  2.  Objectives of the test
  3.  The Internet protocol(s) the application is(are) using (HTTPS, HTTP, FTP, etc.)
  4. If your application has a state, the method used to manage it (URL rewriting, cookies, etc.)
  5.  The workload at normal time and at peak time
  6. Before load or performance testing application should be stable at least tested at once through the manual method
  7. Before load testing, do not record any page, which has 404 or server errors
  8. During load test don’t do real transaction or any money ready work.
  9.  During load testing try to maintain the real scenario as user experience
  10.  Use meaningful test scenarios (use cases are helpful) to construct test plans with 'real-life' test cases.
  11.  Make sure that the machine running Load testing tool has sufficient network bandwidth, so the network connection has little to no impact on the results.
  12.  Let Load Test run for long time periods, hours or days, or for a large number of iterations. This may yield a smaller standard deviation, giving better average results. In addition, this practice may test system availability rate and may highlight any decay in server performance.
  13.  Ensure that the application is stable and optimized for one user before testing it for concurrent users.
  14.  Incorporate 'thinking time' or delays using Timers in your Load testing scenario Test Plan. 
  15.  Keep a close watch on the four main things: processor, memory, disk, and network.
  16.  Only run Load testing tool against servers that you are assigned to test, else you may be accused of causing DoS attacks.

How to check vuser status per script in Analysis in Load runner

To check vuser status (i.e. passed/failed/stopped) per script perform the following: 

1. Analyse the results in Analysis
2. Open the Vuser Summary graph.
3. Right-click on the graph, select "Set filter," then select the script name.
4. Select the Vuser End Status that you are interested in (Passed/Failed/Error/Stopped).

Enable remote desktop connection from remote registry

Machine A : PC which you are using to active remote desktop connection in another PC

Machine B : PC for which remote desktop connection has to be activated.

Step 1: From Machine A : Goto Start -> Run -> regedit. Open the Registry window of Machine A.

(Note: User ID logged in Machine A should have ADMIN rights in Machine B)

Step 2: Click “Connect Network Registry“

Step 3:Enter the computer name of Machine B, for which we have to change the settings and Click “OK”

Step4:The destination machine (Machine B) will be connected with our current logged in machine (Machine A).

Step 5:Goto the below mentioned path and change the fDenyTSConnections to “0” and click “OK”.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Step 6:After doing the following changes, right-click the remote machine (Machine B) name and click Disconnect.
NOTE: If suppose the above mentioned registry value is not found, then create a DWORD parameter with a value ’0′.

What is Little's law?

Little's Law:

Little's law is quite simple and intuitively appealing.

The law states that the average number of customers in a system (over some time interval), N, is equal to their average arrival rate, X, multiplied by their average time in the system, R.

N = X . R (or) for easy remembrance use L = A . W

This law is very important to check whether the load testing tool is not a bottleneck.
For Example, in a shop , if there are always 2 customers available at the counter queue , wherein the customers are entering the shop at the rate of 4 per second , then time taken for the customers to leave from the shop can be calculated as

N = X. R
R = 2/4 = 0.5 seconds

A Simple example of how to use this law to know how many virtual users licenses are required:

Web system that has peak user load per hour = 2000 users
Expected Response time per transaction = 4 seconds
The peak page hits/sec = 80 hits/sec

For carrying out Performance tests for the above web system, we need to calculate how many number of Virtual user licenses we need to purchase.

N = X . R
N = 80 . 4 = 320

Therefore 320 virtual user licenses are enough to carry out the Load Test.

How transaction response time is different from Hits Per Seconds in load runnner

Hits per Seconds is the number of hits made to the web server. These hits can be requests made to the web server for data or graphics. Hits per second measures the number of times the web server is being accessed. So, it does not represent well to users on how well their applications is performing.

Transaction Response Time helps us to find performance bottlenecks in the application. We can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the time of measurement. Other system related metrics like CPU Utilization etc. can be used to identify the root cause.

In LoadRuner, after running a performance test, various measurements can be correlated to find trends and bottlenecks. Correlation can be done between the response time, the amount of load that was generated and the payload of all the components of the application.

How transaction response time is different from Hits Per Seconds in load runnner

Hits per Seconds is the number of hits made to the web server. These hits can be requests made to the web server for data or graphics. Hits per second measures the number of times the web server is being accessed. So, it does not represent well to users on how well their applications is performing.

Transaction Response Time helps us to find performance bottlenecks in the application. We can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the time of measurement. Other system related metrics like CPU Utilization etc. can be used to identify the root cause.

In LoadRuner, after running a performance test, various measurements can be correlated to find trends and bottlenecks. Correlation can be done between the response time, the amount of load that was generated and the payload of all the components of the application

How transaction response time effects the performance of application?

How can we use Transaction Response Time to analyze performance issue?
Transaction Response Time allows us to identify abnormalities when performance issues surface. This will be represented as slow response of the transaction, which differs significantly (or slightly) from the average of the Transaction Response Time.

With this, we can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the point of time and the system-related metrics (e.g. CPU Utilization) to identify the root cause.

Bringing all the data that have been collected during the load test, we can correlate the measurements to find trends and bottlenecks between the response time, the amount of load that was generated and the payload of all the components of the application.

How is it beneficial to the Project Team?


Using Transaction Response Time, Project Team can better relate to their users using transactions as a form of language protocol that their users can comprehend. Users will be able to know that transactions (or business processes) are performing at an acceptable level in terms of time.

Users may be unable to understand the meaning of CPU utilization or Memory usage and thus using a common language of time is ideal to convey performance-related issues.

What is Transaction Response Time?How it is calculated by the tool Load runner

Transaction Response Time represents the time taken for the application to complete a defined transaction or business process.

Why is important to measure Transaction Response Time?
The objective of a performance test is to ensure that the application is working perfectly under load. However, the definition of “perfectly” under load may vary with different systems.
By defining an initial acceptable response time, we can benchmark the application if it is performing as anticipated.

The importance of Transaction Response Time is that it gives the project team/ application team an idea of how the application is performing in the measurement of time. With this information, they can relate to the users/customers on the expected time when processing request or understanding how their application performed.

What does Transaction Response Time encompass?

The Transaction Response Time encompasses the time taken for the request made to the web server, there after being process by the Web Server and sent to the Application Server. Which in most instances will make a request to the Database Server. All this will then be repeated again backward from the Database Server, Application Server, Web Server and back to the user. Take note that the time taken for the request or data in the network transmission is also factored in.

To simplify, the Transaction Response Time comprises of the following:
  • Processing time on Web Server
  • Processing time on Application Server
  • Processing time on Database Server
  • Network latency between the servers, and the client
The following diagram illustrates Transaction Response Time.

Figure 1

Transaction Response Time = (t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 + t9) X 2
Note:Factoring the time taken for the data to return to the client.

How do we measureransation Response Time?Measuring of the Transaction Response Time begins when the defined transaction makes a request to the application. From here, till the transaction completes before proceeding with the next subsequent request (in terms of transaction), the time is been measured and will stop when the transaction completes.

Differences with Hits Per Seconds and Transaction Response timesHits per Seconds measures the number of “hits” made to a web server. These “hits” could be a request made to the web server for data or graphics. However, this counter does not represent well to users on how well their applications is performing as it measures the number of times the web server is being accessed.

How can we use Transaction Response Time to analyze performance issue?
Transaction Response Time allows us to identify abnormalities when performance issues surface. This will be represented as slow response of the transaction, which differs significantly (or slightly) from the average of the Transaction Response Time.

With this, we can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the point of time and the system-related metrics (e.g. CPU Utilization) to identify the root cause.

Bringing all the data that have been collected during the load test, we can correlate the measurements to find trends and bottlenecks between the response time, the amount of load that was generated and the payload of all the components of the application.

How is it beneficial to the Project Team?

Using Transaction Response Time, Project Team can better relate to their users using transactions as a form of language protocol that their users can comprehend. Users will be able to know that transactions (or business processes) are performing at an acceptable level in terms of time.

Users may be unable to understand the meaning of CPU utilization or Memory usage and thus using a common language of time is ideal to convey performance-related issues.