What kinds of tests are there?

I've always worked alone and my method of testing is usually compiling very often and making sure the changes I made work well and fix them 开发者_JS百科if they don't. However, I'm starting to feel that that is not enough and I'm curious about the standard kinds of tests there are.

Can someone please tell me about the basic tests, a simple example of each, and why it is used/what it tests?

Thanks.

---

Different people have slightly different ideas about what constitutes what kind of test, but here are a few ideas of what I happen to think each term means. Note that this is heavily biased towards server-side coding, as that's what I tend to do :)

Unit test

A unit test should only test one logical unit of code - typically one class for the whole test case, and a small number of methods within each test. Unit tests are (ideally) small and cheap to run. Interactions with dependencies are usually isolated with a test double such as a mock, fake or stub.

Integration test

An integration test will test how different components work together. External services (ones not part of the project scope) may still be faked out to give more control, but all the components within the project itself should be the real thing. An integration test may test the whole system or some subset.

System test

A system test is like an integration test but with real external services as well. If this is automated, typically the system is set up into a known state, and then the test client runs independently, making requests (or whatever) like a real client would, and observing the effects. The external services may be production ones, or ones set up in just a test environment.

Probing test

This is like a system test, but using the production services for everything. These run periodically to keep track of the health of your system.

Acceptance test

This is probably the least well-defined term - at least in my mind; it can vary significantly. It will typically be fairly high level, like a system test or an integration test. Acceptance tests may be specified by an external entity (a standard specification or a customer).

---

Black box or white box?

Tests can also be "black box" tests, which only ever touch the public API, or "white box" tests which take advantage of some extra knowledge to make testing easier. For example, in a white box test you may know that a particular internal method is used by all the public API methods, but is easier to test. You can test lots of corner cases by calling that method directly, and then do fewer tests with the public API. Of course, if you're designing the public API you should probably design it to be easily testable to start with - but it doesn't always work out that way. Often it's nice to be able to test one small aspect in isolation of the rest of the class.

On the other hand, black box testing is generally less brittle than white box testing: by definition, if you're only testing what the API guarantees in its contracts, then the implementation can change as much as it wants without the tests changing. White box tests, on the other hand, are sensitive to implementation changes: if the internal method changes subtly - or gains an extra parameter, for example - then you'll need to change the tests to reflect that.

It all boils down to balance, in the end - the higher the level of the test, the more likely it is to be black box. Unit tests, on the other hand, may well include an element of white box testing... at least in my experience. There are plenty of people who would refuse to use white box testing at all, only ever testing the public API. That feels more dogmatic than pragmatic to me, but I can see the benefits too.

---

Starting out

Now, as for where you should go next - unit testing is probably the best thing to start with. You may choose to write the tests before you've designed your class (test-driven development) or at roughly the same time, or even months afterwards (not ideal, but there's a lot of code which doesn't have tests but should). You'll find that some of your code is more amenable to testing than others... the two crucial concepts which make testing feasible (IMO) are dependency injection (coding to interfaces and providing dependencies to your class rather than letting them instantiate those dependencies themselves) and test doubles (e.g. mocking frameworks which let you test interaction, or fake implementations which do everything a simple way in memory).

---

I would suggest reading at least book about this, since the domain is quite huge, and books tend to synthesize better such concepts. E.g. A very good basis might be: Software Testing Testing Across the Entire Software Development Life Cycle (2007)

I think such a book might explain better everything than some out of context examples we could post here.

---

Hi… I would like to add on to what Jon Skeet Sir’s answer.. Based on white box testing( or structural testing) and black box testing( or functional testing) the following are the other testing techniques under each respective category:

• STRUCTURAL TESTING Techniques

Stress Testing

This is used to test bulk volumes of data on the system. More than what a system normally takes. If a system can stand these volumes, it can surely take normal values well.

E.g.

May be you can take system overflow conditions like trying to withdraw more than available in your bank balance shouldn’t work and withdrawing up to a maximum threshold should work.

Used When

This can be mainly used we your unsure about the volumes up to your system can handle.

Execution Testing

Done in order to check how proficient is a system.

E.g.

To calculate turnaround time for transactions.

Used when: Early in the development process to see if performance criteria is met or not.

Recovery Testing

To see if a system can recover to original form after a failure.

E.g.

A very common e.g. in everyday life is the System Restore present in Windows OS.. They have restore points used for recovery as one would well know.

Used when:

When a user feels an application critical to him/her at that point of time has stopped working and should continue to work, for which he performs recovery.

Other types of testing which you could find use of include:-

Operations Testing

Compliance Testing

Security Testing

• FUNCTIONAL TESTING Techniques include:

Requirements Testing

Regression Testing

Error-Handling Testing

Manual-Support Testing

Intersystem testing

Control Testing

Parallel Testing

There is a very good book titled “Effective methods for Software Testing” by William Perry of Quality Assurance Institute(QAI) which I would suggest is a must read if you want to go in depth w.r.t. Software Testing.

More on the above mentioned testing types would surely be available in this book.

There are also two other very broad categories of Testing namely

Manual Testing: This is done for user interfaces.

Automated Testing: Testing which basically involves white box testing or testing done through Software Testing tools like Load Runner, QTP etc.

Lastly I would like to mention a particular type of testing called

Exhaustive Testing

Here you try to test for every possible condition, hence the name. This is as one would note pretty much infeasible as the number of test conditions could be infinite.

---

Firstly there are various tests one can perform. The Question is how does one organize it. Testing is a Vast & enjoying process.

Start Testing with 1.Smoke Testing. Once passed , go ahead with Functionality Testing. This is the Backbone of Testing. If Functionality works fine then 80% of Testing is profitable.

2.Now go with User Interface testing. AS at times User Interface is something that attracts the Client more than functionality. It is the look & feel that a client gets more attracted to it.

3.Now its time to have a look on Cosmetics bugs. Generally these bugs are ignored because of time constraint. But these play a major role depending on the page it is found. A spelling mistake turns to be Major when found on Splash Screen Or Your landing page or the App name itself. Hence these can not be overlooked as well.

4.Do Conduct Compatibility Testing. i,e Testing on Various Browsers & browser Versions. May be devices & OS for Responsive applications.

Happy testing :)