SYSTEM TESTING

1 SYSTEM TESTING 1.1 Introduction to SYSTEM TESTING For most organizations, software and system testing represents a significant element of a project's cost in terms of money and management time. Making this function more effective can deliver a range of benefits including reductions in risk, development costs and improved 'time to market' for new systems. Systems with software components and software-intensive systems are more and more complex everyday. Industry sectors such as telecom, automotive, railway, and aeronautical and space, are good examples. It is often agreed that testing is essential to manufacture reliable products. However, the validation process does not often receive the required attention. Moreover, the validation process is close to other activities such as conformance, acceptance and qualification testing. The difference between function testing and system testing is that now the focus is on the whole application and its environment . Therefore the program has to be given completely. This does not mean that now single functions of the whole program are tested, because this would be too redundant. The main goal is rather to demonstrate the discrepancies of the product from its requirements and its documentation. In other words, this again includes the question, ``Did we build the right product?'' and not just, ``Did we build the product right?'' However, system testing does not only deal with this more economical problem, it also contains some aspects that are orientated on the word ``system'' . This means that those tests should be done in the environment for which the program was designed, like a mulituser network or whetever. Even security guide lines have to be included. Once again, it is beyond doubt that this test cannot be done completely, and nevertheless, while this is one of the most incomplete test methods, it is one of the most important. A number of time-domain software reliability models attempt to predict the growth of a system's reliability during the system test phase of the development life cycle. In this paper we examine the results of applying several types of Poisson-process models to the development of a large system for which system test was performed in two parallel tracks, using different strategies for test data selection. we will test that the functionality of your systems meets with your specifications, integrating with which- ever type of development methodology you are applying. We test for errors that users are likely to make as they interact with the application as well as your application’s ability to trap errors gracefully. These techniques can be applied flexibly, whether testing a financial system, e-commerce, an online casino or games testing. System Testing is more than just functional testing, however, and can, when appropriate, also encompass many other types of testing, such as: o security o load/stress o performance o browser compatibility o localisation 1.2 Need for System Testing Effective software testing, as a part of software engineering, has been proven over the last 3 decades to deliver real business benefits including: reduction of costs Reduce rework and support overheads increased productivity More effort spent on developing new functionality and less on "bug fixing" as quality increases reduce commercial risks If it goes wrong, what is the potential impact on your commercial goals? Knowledge is power, so why take a leap of faith while your competition step forward with confidence? These benefits are achieved as a result of some fundamental principles of testing, for example, increased independence naturally increases objectivity. Your test strategy must take into consideration the risks to your organisation, commercial and technical. You will have a personal interest in its success in which case it is only human for your objectivity to be compromised. 1.3 System Testing Techniques Goal is to evaluate the system as a whole, not its parts Techniques can be structural or functional Techniques can be used in any stage that tests the system as a whole (acceptance, installation, etc.) Techniques not mutually exclusive Structural techniques stress testing - test larger-than-normal capacity in terms of transactions, data, users, speed, etc. execution testing- test performance in terms of speed, precision, etc. recovery testing - test how the system recovers from a disaster, how it handles corrupted data, etc. operations testing - test how the system fits in with existing operations and procedures in the user organization compliance testing - test adherence to standards security testing - test security requirements Functional techniques requirements testing - fundamental form of testing - makes sure the system does what it’s required to do regression testing - make sure unchanged functionality remains unchanged error-handling testing - test required error-handling functions (usually user error) manual-support testing - test that the system can be used properly - includes user documentation intersystem handling testing - test that the system is compatible with other systems in the environment control testing - test required control mechanisms parallel testing - feed same input into two versions of the system to make sure they produce the same output Unit Testing Goal is to evaluate some piece (file, program, module, component, etc.) in isolation Techniques can be structural or functional In practice, it’s usually ad-hoc and looks a lot like debugging More structured approaches exist 1.4 Functional techniques input domain testing - pick test cases representative of the range of allowable input, including high, low, and average values equivalence partitioning - partition the range of allowable input so that the program is expected to behave similarly for all inputs in a given partition, then pick a test case from each partition boundary value - choose test cases with input values at the boundary (both inside and outside) of the allowable range syntax checking - choose test cases that violate the format rules for input special values - design test cases that use input values that represent special situations output domain testing - pick test cases that will produce output at the extremes of the output domain Structural techniques statement testing - ensure the set of test cases exercises every statement at least once branch testing - each branch of an if/then statement is exercised conditional testing - each truth statement is exercised both true and false expression testing - every part of every expression is exercised path testing - every path is exercised (impossible in practice) Error-based techniques basic idea is that if you know something about the nature of the defects in the code, you can estimate whether or not you’ve found all of them or not fault seeding - put a certain number of known faults into the code, then test until they are all found mutation testing - create mutants of the program by making single changes, then run test cases until all mutants have been killed historical test data - an organization keeps records of the average numbers of defects in the products it produces, then tests a new product until the number of defects found approaches the expected number 1.5 Conclusion: Hence the system Test phase should begin once modules are integrated enough to perform tests in a whole system environment. System testing can occur in parallel with integration test, especially with the top-down method. . 1 SYSTEM TESTING 1.1 Introduction to SYSTEM TESTING For most organizations, software and system testing represents a significant. flexibly, whether testing a financial system, e-commerce, an online casino or games testing. System Testing is more than just functional testing, however,