Step 4 To test API : Call Sequencing, Step 5 To Test API : Observe the output

Step 4: Call Sequencing
When combinations of possible arguments to each individual call are unmanageable, the number of possible call sequences is infinite. Parameter selection and combination issues further complicate the problem call-sequencing problem. Faults caused by improper call sequences tend to give rise to some of the most dangerous problems in software. Most security vulnerabilities are caused by the execution of some such seemingly improbable sequences.

Step 5: Observe the output
The outcome of an execution of an API depends upon the behavior of that API, the test condition and the environment. The outcome of an API can be at different ways i.e. some could generally return certain data or status but for some of the APIs. It might not return or shall be just waiting for a period of time, triggering another event, modifying certain resource and so on.

The tester should be aware of the output that needs to be expected for the API under test. The outputs returned for various input values like valid/invalid, boundary values etc needs to be observed and analyzed to validate if they are as per the functionality. All the error codes returned and exceptions returned for all the input combinations should be evaluated.

What is the strategy that is needed to test an API?

By analyzing the problems faced by the testers, a strategy needs to be formulated for testing the application programming interface.
- The API to be tested would require some environment for it to work. Hence, it is required that all the conditions and prerequisites understood by the tester.
- The next step would be to identify and study its points of entry. The graphical user interfaces would have items like menus, buttons, check boxes, and combo lists that would trigger the event or action to be taken.
- Similarly, for APIs, the input parameters, the events that trigger the API would act as the point of entry. Subsequently, a chief task is to analyse the points of entry as well as significant output items. The input parameters should be tested with the valid and invalid values using strategies like the boundary value analysis and equivalence partitioning.
- The fourth step is to understand the purpose of the routines, the contexts in which they are to be used. Once all this parameter selections and combinations are designed, different call sequences need to be explored.

The steps can be summarized as follows:
- Identify the initial conditions required for testing.
- Identify the parameters i.e. choosing the values of individual parameters.
- Identify the combination of parameters i.e. pick out the possible and applicable parameter combination with multiple parameters.
- Identify the order to make the calls i.e. deciding the order in which to make the calls to force the API to exhibit its functionality.
- Observe the output.

Understanding Application Programming Interfaces(APIs)

Application Programmable Interfaces (APIs) are collections of software functions or procedures that can be used by other applications to fulfill their functionality. APIs provide an interface to the software component.These form the critical elements for the developing the applications and are used in varied applications from graph drawing packages, to speech engines, to web-based airline reservations systems, to computer security components.

Each API is supposed to behave the way it is coded i.e. it is functionality specific. These APIs may offer different results for different type of the input provided. The errors or the exceptions returned may also vary. However, once integrated within a product, the common functionality testing/integration testing may cover only those paths. By considering each API as a black box, a generalized approach of testing can be applied. But, there may be some paths which are not tested and lead to bugs in the application. Applications can be viewed and treated as APIs from a testing perspective.

The distinctive attributes that make testing of APIs slightly different from testing other common software interfaces like GUI testing.
- Testing APIs requires a thorough knowledge of its inner workings: Some APIs may interact with the operating system kernel, other APIs, with other software to offer their functionality. Thus, an understanding of the inner workings of the interface would help in analyzing the call sequences and detecting the failures caused.
- Adequate programming skills: API tests are in form of sequences of calls, namely, programs.Each tester must possess expertise in the programming language that are targeted by the API.
- Lack of domain knowledge: Involve the testers from the initial stage of development. This would help the testers to have some understanding on the interface and avoid exploring while testing.
- No documentation: Without the documentation, it is difficult for the test designer to understand the purpose of calls, the parameter types and possible valid/invalid values, their return values, the calls it makes to other functions and usage scenarios. Hence, proper documentation would help test designer design the tests faster.
- Access to source code: The availability of the source code would help tester to understand and analyze the implementation mechanism used; and can identify the loops or vulnerabilities that may cause errors.
- Time constraints: Thorough testing of APIs is time consuming, requires a learning overhead and resources to develop tools and design tests.

How does the operating system does its job when the storage media are removable ?

Major OS jobs are to manage physical devices and to present a virtual machine abstraction to applications.Most operating system handles removable disks almost exactly as they do the fixed disks.A new cartridge is formatted and an empty file system is generated on the disk.

Tapes are often handled differently. Tapes are presented as a raw storage medium, i.e., an application does not not open a file on the tape, it opens the whole tape drive as a raw device.Usually the tape drive is reserved for the exclusive use of that application. The operating system does not provide file-system services when tape drive is presented as a raw device.Since the OS does not provide file system services, the application must decide how to use the array of blocks. Since every application makes up its own rules for how to organize a tape, a tape full of data can generally only be used by the program that created it.

The basic operations of tape drives differ from the operations of disk drive.
* locate positions the tape to a specific logical block, not an entire track (corresponds to seek).
* read position operation returns the logical block number where the tape head is.
* The space operation enables relative motion.

Tape drives are “append-only” devices; updating a block in the middle of the tape also effectively erases everything beyond that block. An EOT (End of tape) mark is placed after a block that is written.

The issue of naming files on removable media is especially difficult when we want to write data on a removable cartridge on one computer, and then use the cartridge in another computer. Contemporary OS generally leave the name space problem
unsolved for removable media, and depend on applications and users to figure out how to access and interpret the data. Some kinds of removable media (e.g., CDs) are so well standardized that all computers use them the same way.