Overview: Functional Requirements are the business requirements that the business define for the application being built. Non-functional testing is concerned with performance, reliability, scalability, recovery, load, security and usability testing. For SharePoint it is a good idea to test this at a platform level and then verify the individual application non functional testing is appropriate.
SharePoint Non Functional Testing:
All of these test should be performed against your various SharePoint platforms and will dictate the SLA's offered to the business using SharePoint as a service. Baseline testing is a good idea as the differences can be used to determine the efficiency of the individual application being created.
Proxies:
Fiddler is my favourite (other tools for capturing web traffic Charles, BurpSuite, WireShark and you can use the developer tools shipped with the browsers). tcpdump, goPacket are awesome for network monitoring.
SharePoint Non Functional Testing:
All of these test should be performed against your various SharePoint platforms and will dictate the SLA's offered to the business using SharePoint as a service. Baseline testing is a good idea as the differences can be used to determine the efficiency of the individual application being created.
Proxies:
Fiddler is my favourite (other tools for capturing web traffic Charles, BurpSuite, WireShark and you can use the developer tools shipped with the browsers). tcpdump, goPacket are awesome for network monitoring.
Use Fiddler to:
- Observe traffic (http/https requests, headers,..)
- Replay sessions,
- Evaluate performance,
- Set break point
Performance is primarily concerns with looking at typical user usage scenarios and see how long each page takes to load. So a recorded script with wait time between recorded calls is useful It's also worth looking at the same page with minimal data and also with large amounts of data.
Load Test involves recording the standard users interaction (ensure some users query heavy and some light amounts of data), there are no wait times. The norm is to multiple this concurrent number of users by 100 to know the amount of users the farm business application can support. e.g. a concurrent user load of 100 users where the performance is acceptable means the farm should handle 10,000 users (100 users times 100). You run the 100 users in a steady state for a few hours.
Stress testing is similar to load testing but you keep stepping up the number of concurrent users until the SharePoint farm starts running out of resources and throttling requests. Once the system degrades and performance is not acceptable is pretty much how many users the application on the SharePoint farm are supported. So if the performance throttles at 170 users, the farm can handle 17, 000 normal usage users.
References:
http://www.guru99.com/non-functional-testing.html
Load Test involves recording the standard users interaction (ensure some users query heavy and some light amounts of data), there are no wait times. The norm is to multiple this concurrent number of users by 100 to know the amount of users the farm business application can support. e.g. a concurrent user load of 100 users where the performance is acceptable means the farm should handle 10,000 users (100 users times 100). You run the 100 users in a steady state for a few hours.
Stress testing is similar to load testing but you keep stepping up the number of concurrent users until the SharePoint farm starts running out of resources and throttling requests. Once the system degrades and performance is not acceptable is pretty much how many users the application on the SharePoint farm are supported. So if the performance throttles at 170 users, the farm can handle 17, 000 normal usage users.
References:
http://www.guru99.com/non-functional-testing.html
