Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Structural (non-functional) testing
Transcript of Structural (non-functional) testing
Uy, Dexie Eunice Interface testing Security Testing Structural (Non-functional) Testing Focuses on data transferred between the application under test and different software platform components.
Application program interfaces (APIs)
Network data transfers
One helpful way to develop interface testing is to
consider a four-step approach. First, write tests that cause the application to produce data for transfer but have the transfer itself inhibited. Second, remove the data transfer inhibitors and observe if the receiving software platform component deals with the incoming data from the application correctly. Fourth, connect the application to the software platform components and rerun
the data requests with “live” data feeds. This will allow the tester to validate that
the software platform is producing data per its data specifications. If the problems
are found with these data, you have isolated the problem to the vendor’s interface
component (does not work as advertised) or its data specifications. Here is a pictorial view of these four steps
1st: Application under test Data (validate)
2nd: Application under test Data Support platform (validate)
3rd: Application under test (validate) Data Manual substitution
4th: Application under test Data (validate) Support platform Third, write tests that cause the application to request data from other software platform components, but manually substitute the requested data in lieu of a “live” data feed from the involved software platform. This technique is referred to as “stubbing” the inputs. 1st: Application under test → Data (validate)
2nd: Application under test → Data → Support platform (validate)
3rd: Application under test (validate) ← Data ← Manual substitution Structural testing is white box testing, not black box testing, since black boxes are considered opaque and do not permit visibility into the code.
Is a way to test software with knowledge of the internal workings of the code being tested.
The objective of structural testing is to validate the behavior of software that supports the software the user touches. Structural (Non-functional) Testing Why non-functional? Doesn’t that mean we already know it does not work??!” This group of testing types is related to the general characteristics and attributes of the application. These attributes include Security, Accessibility and Performance. Chapter 8: Structural testing techniques The software platform purpose is basically different from the application
software. The software platform is not written for one specific business application.
Conversely, a software platform is written as a generic capability that can support
many different kinds of business applications at the same time. This collective support software is often called the software
platform. interface testing security testing installation testing the smoke test administration testing backup and recovering testing It is a process used to determine whether an information system protects data and maintain its functionality as intended. Most security systems have different types or levels of security relating to end user processing restrictions based on job roles. A typical three-level security system would define... (1) clerks and other employees who just need to view data at security level 1 (2) clerk managers who need to view and update at security level 2 (3) security administrators at security level 3 to grant and deny permissions to clerks at security level 1 and clerk managers at security
level 2. A Brute force approach to testing these security behaviors would be to collect all of the user ID/password pairs in the company and test each user ID/password pair to verify that the user ID under test is authorized and has the appropriate security access. Installation testing Installation testing focuses on the way the new application or system is placed into its production environment. The installation process itself can vary from a simple startup.exe that copies all application files to their proper place to a complex set of files and an instruction manual for an experienced system installer. copies copies copies copies copies copies copies copies copies The smoke test is used to verify that a successfully installed software application can be subsequently configured properly.
After the software installation and the system prompt a successful installation, it is not sufficient to allow the end user to start using the software for routine business. The smoke test The term “smoke test” comes from the hardware engineering practice of plugging
a new piece of equipment into an electrical outlet and looking for smoke.
IF there is no sign of smoke, the engineer starts using the equipment. t Configuration and administration. A typical configuration tasks include setting startup parameters and choosing process rules.
Examples of startup parameters are
• the location of data files
• maximum number of user sessions
• maximum user session duration before automatic timeout
• ID/password of the system administrator,
• Default date formats
• geography-specific settings for language and culture. Examples of process rules are
• definitions of security classes
• startup/shutdown schedules
• backup schedules
• destination files
• accounting rules and travel reservation rules. Administration Testing • Administration testing is an extension of functional testing of business activities to functional testing of business support activities.
• Include such technically complex activities as applying updates and fixes to the software
• Can also include organization-specific activities such as adding users to the system, adding user security to the system, and building master files. and so forth. Customer lists sales history Backup and Recovery Testing Sooner or later, all business software applications fail. The extent of financial damage that occurs with this failure is directly proportional to the software developer’s effort to minimize that financial damage. A surprising number of commercial software packages simply instruct you to “start over” when a failure occurs. Start Over??? The accepted approach is that you start your failure defense by periodically making backup copies of critical business files such as master files, transaction files, and before/after update images. Then, when (not if) the software fails, the backup files are used to restore the software close to its pre-failure state. The recovery pre-failure state can range from last weekend’s backups (fairly inexpensive)... To last night’s backups (more expensive)... To all backed up transactions except the one that caused the failure (very expensive but guarantees minimum loss of business) product lists The term “smoke test” comes from the hardware engineering practice of plugging
a new piece of equipment into an electrical outlet and looking for smoke. If there is no sign of smoke, the engineer starts using the equipment. Testing developed application against business requirements.
Functional testing is done using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team. Testing the application based on the clients and performance requirement
Non-Functioning testing is done based on the requirements and test scenarios defined by the client. VS Non-Functional Testing Functional Testing END