I've read some of the topics on stress testing but what options are there for testing a site that uses membership to simulate many concurrent users logging/logged in? I guess one could use/create custom scripts but that would also proliferate the database.
How do some of the 'big boys' do it? BTW maybe stress testing isn't exactly what I'm referring too but like a test suite or anything that would be beneficial..
I can think:
Profiling
Application Suite testing. Does this exist for web? It seems difficult to do.
Stress testing.
Performance
Hardening/security
It has a steep(ish) learning curve but I use the free web stress tool from Microsoft called WCat.
I recall reading that this is used by the IIS Team to stress test new features - I guess you could call them 'big boys'? You need IIS to be able to run this of course.
Related
i am currently doing my functional specification document for my project. the only thing still missing is a testing concept. my project is all about an web app with which i can record and manage employee attendance in my ojt company. i am doing the app in asp.net web forms with c# as programming language. the ide i am using is vs for web 2012.
now i need to write a testing concept. i have already read a little literature about system and module tests. i have designed my app with a few model classes whose only methods are get() and set() methods. it may be that i will write a FEW methods where parameters are expected, for how much that matters.
i am little unsure about what tests i will be planning. could you maybe help me out here? a few crude examples would also be very helpful...
thanks
Here if u know about testing then there is no required of Test case & Test Plan.Its for only reference for Ur client.
First of all
U just do Functional testing, it will help to status of your project.
If every function is work properly then application will have no major problem.
Then just go through regression & Smoke testing
You should be doing following based on your requirements:
Unit Testing
Integration Testing
Regression Testing
Functional Testing
End to End Testing
Load Testing
Stress Testing
Performance Testing
Beta Testing
Security Testing
Usability Testing
Functional testing has many examples.
Like Login ,Add,Edit,Delete etc
Here u Just check these are functions working properly or not.
This is the basic thing in your Application
platform: ASP.NET 4.5, MVC 4, C#
I'm currently designing a website that's available on the public domain. However, there is a meaningful % of my target market that would be uncomfortable putting some information on a public site, even if it's https etc.
What I'd like to be able to do is allow corporate users use my site, and one way to do that is to allow them to host my website on their intranet. The usual disadvantages are, of course, that they don't get their site updated as fast as the public one would, and it's also a headache for me in terms of support.
My questions are
What are some strategies to make "corporate friendly" deployments easy and hassle-free?
Are there ways I could keep the site public with just the database inside the intranet (can't see how... but then I'm no techno-know-all)
If I have no choice but to make it locally hosted - then what's the best way to do it to keep my development/support overheads at a minimum?
I hope the mods don't lock this. I'm asking for specific methods and technical approaches to a very real problem.
Thank you,
For #1, there's a many facets to the question. A couple thoughts that might help you think it out:
Deploying your app: Make it simple to deploy, and to upgrade, between versions of your application. Try to make it happen as a single operation, not upgrading different parts by hand manually. As Darin Dimitrov mentioned, you could look into a technology like Web Deployment Packages, especially with Visual Studio 2012 which will have incremental database publishing (in VS2010, the database was non-incremental so there wasn't really an "update" story). Keep the cost of deployment down so that they can afford to upgrade more frequently (not the cost of your product, but the overhead of who's getting paid to keep the system updated and running).
Consider differences between running on the Internet and on an Intranet: For example, authentication on the Internet is usually done with forms based authentication. On an intranet, you may want to consider supporting Windows authentication for a seamless login experience for corporate users. This should impact your designs to allow authentication to be modular between your deployments.
Corporate adoption of newer technologies might be slower than you want: You're using the latest and greatest (ASP.NET 4.5/MVC4). Some companies might not be prepared to deploy this now, or for a couple years. Consider if you could use an older, established technology, such as .NET 4 - having been out for a few years, it's already somewhat proven and has adoption.
For your 2nd question, it comes down to what their IT is willing to accommodate. Many corporate sites have the database within a secured LAN, but the web server is accessible from the public Internet. It's certainly a well-understood network design, but depending on the assets involved in your application, your customers may or may not agree to it. This one's a business decision.
For #3 the answer is common to any long term software project. It has to be high quality and maintainable if you want to minimize the hassle.
If you're only going to support the last N versions, make that very clear. Avoid supporting code that you're already fixed long in the past. Consider providing extra support or affordable upgrades to keep your customers on newer (and hopefully better) releases.
Keep in mind what components need to be upgraded between versions. Your web app (obviously), but also your database schema and any dependencies or libraries you're using. This is mostly the same considerations as #1. Make sure you have a good plan for upgrades and rollbacks.
Most importantly, test, test, test. Have functional regression tests and install/upgrade tests, and try out as many possibilities as you can think of.
Answer to only 1) above.
I would recommend a continuous integration tool. We use TeamCity and deploy mvc3 and mvc4 applications to our public as well as privately hosted sites with a click of a button. Previously, we used cruise control, but now we are more satisfied with TeamCity. Read up on them. Might lead you in the right direction.
You may checkout Visual Studio's Web Deployment Packages. They allow you to prepare a package that could directly be installed on your client's web servers.
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).
We are looking to build a cube in Microsft SQL server analysis services but would like to be able to use some of the automated testing infrastructure we have.
such as Cruise control for automated build, deployments and test.
I am looking for anyone that can give me any pointers on building tests against analysis services, and also any experience with adding these to a build pipeline.
Also if automation is not possible some manual test methods.
Recently I came upon BI.Quality project on codeplex and from what I can tell it's very easy to learn and to integrate into existing deployment process.
There is another framework named NBi. You've additional features compared to BI.Quality as to check the existence of a measure, dimension, attributes, the order of members, the count of members. Also when comparing two result sets it's often easier to spot the difference between them with NBi. The edition of the test-suites is also done in one single xml file validated by an XSD (better user-experience).
We recently had a web app that went out to site acceptance testing where they found severe performance problems related to request size (massive viewstate ASP.net).
We need to ammend our testing strategy to include performance testing, can anyone give us guidance on best practices please?
This is a very broad case to cover, but here are a few of the highlights of things that we do on a regular basis.
DO NOT just test on your network, get remote testing in. LAN connections are very fast, large pages and large load times can go by un-noticed. Ideally get to a place where it mimics the production location in regards to hardware and proximity/connection to the end user.
Use ANTS Profiler or similar tool to profile for expensive methods, and high memory usage.
Test with multiple users, to simulate load. Depending on the nature of the application also load test, either with multiple physical testers or with testing tools that allow you to simulate and script a load scenario.
Review the code to see if objects are retaining viewstate when they shouldn't need to.
I don't know a hard and fast set of "rules" but I find these are good starting points.
In addition to Mitchel's comments above I would recommend conducting load testing as part of your Continuos Integration (CI) process. Visual Studio Team Suite (Test Edition) contains a good load/stress test tool.