|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 7
This is, in fact, the situation for all testing. Except in the most trivial cases, we can never prove the absence of bugs by software testing. The point of testing is to increase our confidence that most of the bugs in a program have been caught and that the intended functionality has been demonstrated under a controlled set of states. In this light, runnability testing is like any other testing -- it employs standard testing techniques, only with a different emphasis.
When running Java programs, an important consideration is the Java security model. One of the advantages of the Java platform
is that it gives the user very good safety; a security-restricted Java program runs inside a sandbox and therefore cannot
damage the user's computer or violate the user's privacy. Any Java program, especially downloadable code like an applet, must
expect to run inside a sandbox and must be prepared to be denied access to various system resources, as controlled by the
SecurityManager interface.
This security model is another dimension of runnability for Java programs. Developers must understand the assumptions their program makes about the security policy, and how it will cope if the user has chosen to set a different security policy. This, again, is not a consideration exclusive to Java programs; most operating systems have some access control mechanisms, and so any program may be denied access to protected resources. Java technology differs from operating systems only in that it has a stronger and more detailed security model, so that a program is more often exposed to the denial of access.
Another issue for runnable Java programs is the use of various extensions, or class libraries. There is not a clear distinction in form between an extension (intended as an expansion of the capabilities of the Java platform) and a class library (intended as code to be incorporated into the user's program). Indeed, every class library can be regarded as an extension of the platform capabilities. Extensions may be categorized as standard -- as specified by the Java Software Division of Sun Microsystems through an industry consensus process -- or as proprietary. The standard and proprietary extensions have different runnability implications. In addition, there is an important class of external software that a program may depend on that isn't used directly by the program. We'll describe such software as driver software, because it's most often used indirectly, via a service request of some kind.
A standard extension is an interface published by Sun that conforms to certain criteria for industry acceptance and platform independence. Standard extensions are published as public documentation, and typically are provided with a reference implementation and a compatibility test. These publication standards give the developer a certain level of confidence that a standard extension, if available, will be consistent from platform to platform. This reduces the load on the runnability test -- a standard extension can be treated as an optional part of the Core APIs, and can (if present) be trusted to the same degree. Of course, it's wise to specify what a program should do if a standard extension it uses isn't available, and to test for that specified behavior. Once it has been determined that the extension is available, however, variations in behavior shouldn't be a major consideration.