Software Architecture Design and Testing

Introduction

In software architecture and software engineering, Software testing is defined as an activity to check whether the actual results match the expected results and to ensure that the software system is Defect free. It involves execution of a software component or system component to evaluate one or more properties of interest.

Software testing also helps to identify errors, gaps or missing requirements in contrary to the actual requirements. It can be either done manually or using automated tools. Some prefer saying Software testing as a White Box and Black Box Testing.

In simple terms, Software Testing means Verification of Application Under Test (AUT). In software testing many of techniques that are used to identify the error and make the system match the purpose of it.

Using your own words, describe the difference between verification and validation. Do both make use of test-case design methods and testing strategies?

Software testing is mostly referred to as verification and validation. The differences is summarized below:

Validation

1. Verification is the set of tasks that ensures correct software implementation for a specific function Validation is the set of tasks that ensures that the software is built to be traceable for customer requirements
2. No code or implementation Contains code implementation
3. Performs before validation Performs after verification
4. Quality assurance team assures verification Testing team assures validation
5. It focuses on the process of the product It focuses on the product built.
   Get quality help now

   

   Doctor Jennifer

   Verified writer

   Proficient in: Engineering

   5 (893)

   “ Thank you so much for accepting my assignment the night before it was due. I look forward to working with you moving forward ”

   

   +84 relevant experts are online

   Hire writer

6. Activities included are reviews, inspection, meeting etc Activities included are black box testing, white box testing, non-functional testing etc
7. Focuses on the internal product specifications, for eg: if the system is well engineered and error free, etc Focuses on trying to uncover errors also at the requirement level of things that are apparent to the end-user.
   Get to Know The Price Estimate For Your Paper

   Topic

   Deadline: 10 days left

   Number of pages

   Email Invalid email

   By clicking “Check Writers’ Offers”, you agree to our terms of service and privacy policy. We’ll occasionally send you promo and account related email

   "You must agree to out terms of services and privacy policy"

   Write my paper

   You won’t be charged yet!

Testing strategy is based on the spiral model, A test plan requires the test to be conducted and the process of testing to reveal any error in the product. A test case consists of test data to be given along with the expected output. Both validation and verification make use of the test-case design methods and testing strategies.

Why is a highly coupled module difficult to unit test? How can project scheduling affect integration testing?

Errors can spread to different modules in a highly coupled module. The paths need to be tested will increase because of the shared data and other module invocation. Highly coupled components are tightly connected to each other.

A highly coupled module is where at least one part of its interface is closely tied to one of more modules, which mean the closely related modules are not completely tested independently (nominal unit testing) but has to be tested as a unit (more nearly sub-integrated testing). The larger (in terms of code size and complexity) the code, the more harder it is t test it.

Action appearing in different modules is difficult to trace, code, read, design realistic tests, etc.

Project scheduling can affect integration testing:

• Requirement list
• Design
• Construction
• Integration testing
• System testing
• Acceptance testing

Therefore, when the project scheduling is completed, each modules’ completion date will be created. Integration testing has to wait for all the modules to finish and tested. Any changes made in the project schedule will affect the integration testing. For example, if there is a delay in completing any of the previous phases e.g. design or construction and unit testing, this could delay the beginning of the integration testing phase.

Because integration testing is done after a certain point in the project lifetime any changes to the schedule before that point will affect the integration test schedule.

In your own words, describe why the class is the smallest reasonable unit for testing within an OO system.

Classes are the most important basic element in Object – Oriented system. A class is a template that consists of various attributes and functions of an object. It encapsulates data and operations. In OO system, an operation cannot be formed without being part of a class.

Classes frequently encapsulate data and operations to perform various functions. Since a class is the basic structure used to provide functions, it is considered as the smallest reasonable unit for testing in an OO system.

As the methods in the OO system are packaged as a unit of classes, testing the methods one by one error free and would not uncover errors.

Testing the whole class as a single unit would increase efficiency in testing and productivity.

Why do we have to retest subclasses that are instantiated from an existing class, if the existing class has already been thoroughly tested? Can we use the test-case design for the existing class?

Retesting subclasses that represent the existing class is a must because operations that are defined in the existing class can be used in different way when it’s in a subclass. It indicates that the same operation can be used in different ways depending on its subclass or an existing class when testing the subclass. Moreover, new set of tests must be designed if the subclass is used in different ways, the current class test will have little applicability.

Why should “testing” begin with object-oriented analysis and design?

Testing should begin with object-oriented analysis and design because it gives significant information about the structure and behaviour of the system. On every stage, the object-oriented models can be tested to uncover errors before their propagation to the next iteration.

What is the difference between thread-based and use-based strategies for integration testing? How does cluster testing fit in?

Thread-based testing

Use-based testing

1. Thread-based testing integrates the set of classes required to respond to one input or event for the system. Use-based testing integrates the set of classes required to respond to one use case.
2. Each thread is integrated and tested individually. It begins testing by from independent classes (the construction of the system by testing those classes).
3. Regression testing is applied to ensure that no side effects occur.

After independent classes are tested, dependent classes (the next layer of classes) which depend on independent classes are tested. This sequence of testing layers will be continued until the entire system is constructed.

Cluster testing

Cluster testing is one of the steps in the integration testing of object-oriented software. In this step, a cluster of collaborating classes is used by designing test cases that attempt to uncover errors in the collaborations.

Derive four additional tests using random testing and partitioning methods as well as multiple class testing and tests derived from the behavioural model for a banking application.

Considering a banking application in which an Account class has the following operations:

open(), setup(), deposit(), withdraw(), balance(), summarize(), creditLimit(), and close()

Each of these operations may be applied for Account:

Test 1:

Random test cases are generated to exercise a class and its functionality. Once such test case for a banking application is given below:

open.setup.deposit.deposit.summarize.deposit.summarize.withdraw.summarie.withdraw.close

This test case tests different operations which are randomly generated.

Test 2:

State operations and non-state operations can be exercised using partition testing. An example of state operations test case is given below which includes the deposit() operation as well as the withdraw() operation:

open.setup.deposit.withdraw.withdraw.deposit.withdraw.close

Another example of state which includes the balance()operation is given below to illustrate non-state operation:

open.setup.deposit.balance.withdraw.close

Test 3:

Tests should also be conducted to check the functioning between different classes. The following test case exercises several operations sequence for classes in a banking application:

verifyAcct.verifyPIN.withdrawReg.balancelnfoReq

The Bank class should collaborate with class ValidationInfo to be able to execute the operations verifyAcct() and verifyPIN(). The Bank class must be able to collabrote with the Account class also to execute the withdrawReq()and balancelnfoReq()operations. These collaborations can be exercised using the following new test case:

VerifyAcct[Bank:validAccValidationinfo].VerifyPIN[Bank:validPinValidationInfo].withdrawReq[Bank:wihrawaccount].balanceInfoReq[Bank:balanceEnquiryInfo]

Test 4:

The dynamic behaviour of a class is tested by a test -case that covers every state of the class from working to non-working state. Once such sequence of operations is given below:

open.setupAccnt.deposit(initial).withdraw.accntinfo.deposit.accntinfo.withdraw.accntinfo.withdraw(final).close

The concept of “antibugging” is an extremely effective way to provide built-in

debugging assistance when an error is uncovered.

Develop set of guidelines for antibugging.

Antibugging: A good design anticipates error conditions and establishes error-handling paths to reroute or cleanly terminate processing when an error does occur. A single rule covers a large number of situations.

The guidelines:

• The functions or methods must be able to turn over at least an error code or an exception.
• Any error code or possible exception must be tested and used.
• An “abnormal” error must stop the execution of the program and write the state of the variables and system in a disk file

Advantages of using this technique:

• Errors don't 'snowball'.
• The errors are immediately found.
• The errors cannot affect the remainder.
• The programmer finds and fixes the errors.

Disadvantages of using this technique:

• Requires extra processing time and memory.
• Many codes and tests might not be utilized.
• A program which doesn’t work will be a bad impression for the user.

Is unit testing possible or even desirable in all circumstances? Provide examples to justify your answer.

No, testing in all circumstances because if a module has 3 or 4 subordinates that supply data essential to a meaningful evaluation of the module, it may not be possible to conduct a unit test without 'clustering' all of the modules as a unit. A bug discovered as of these first tests will further save much time in the development.

Who should perform the validation test—the software developer or the software user? Justify your answer.

Validation testing is done in two phases:

Alpha testing: is done in a controlled environment in a company by the users before the release of the software

Beta testing: is done after the release of the software in the market in an uncontrolled environment by the software users.

Select a software component that you have designed and implemented recently.

Design a set of test cases that will ensure that all statements have been executed using basis path testing.

Software component: spell checker system

System description:

Collect words from the document and look up in the main directory. Display the words from the standard output and if they don’t appear in the directory or can’t be derived from those that do appear by applying certain inflections.

Design diagram for system:

Procedure for description:

Step 1: Get the document’s file name.

Step 2: Split the documents into words.

Step 3: Look up each word in the main dictionary and private dictionary

• a. If the word appears in either dictionary, or is derivable via various rules, it is deemed to be spelled correctly and ignored.
• b. Else the misspelled word is output

Test cases for the spell check system using the basis path testing:

Basic path testing is the white box testing technique. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one-time during testing. Input of the basis path test case scenario:

No.	Test case name	Test case description	Actual value	Obtained values
1.	Spell check	Login page	Open/close members	Classes: - Find word - Insert word - Remove word - Next word iterator - Abstract Classes - Alphabetic words Excepted & limited
2.	Private dictionary	Cardinality	Super class member	Expected
3.	Main dictionary	Static dictionary	Unlimited

Specify, design, and implement a software tool that will compute the cyclomatic complexity for the programming language of your choice. Use the graph matrix as the operative data structure in your design.

Cyclomatic complexity is a software metric that offers a quantitative measure of the logical complexity of a program. When used in the context of basis path testing method, the value computed for Cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed once. An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.

When mentioned as a flow graph, an independent path must move along at least one edge that has not been crossed before the path is defined. For example, a set of independent paths for the flow graph given below:

Path 1: 1-11

Path 2: 1-2-3-4-5-10-1-11

Path 3: 1-2-3-6-8-9-10-1-11

Path 4: 1-2-3-6-7-9-10-1-11

Each new path introduces a new edge. The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 is not considered to be an independent path because it is simply a combination of already specified paths and does not traverse any new edges. Paths 1 through 4 constitute a basis set for the above flow graph. That is, if tests can be designed to force execution of these paths (a basis set), every statement in the program will have been guaranteed to be executed at least one time and every condition will have been executed on its true and false sides.

Cyclomatic complexity has a foundation in graph theory and offers an extremely useful software metric. Complexity is computed in one of the three ways:

1. The number of regions of the flow graph corresponds to the Cyclomatic complexity.
2. Cyclomatic complexity, V(G), for a flow graph, G is defined as V(G)=E-N+2 Where E is the number of flow graph edges, N is the number of flow graph nodes.
3. Cyclomatic complexity V(G) for a flow graph G is also defined as V(G)=P +1

Where P is the number of predicate nodes contained in the flow graph G.

Referring to the above figure, the Cyclomatic complexity can be computed using each of the algorithms:

1. The flow graph has four regions.
2. V(G) = 11 edges - 9 nodes + 2 = 4
3. V(G) = 3 predicate nodes + 1=4

Therefore, the Cyclomatic complexity of the flow graph is 4.

The value of V(G) provides us with an upper bound for the number of independent paths that form the basis set and by implication, an upper bound on the number of tests that must be designed and executed to guarantee coverage of all program statements.

Give at least three examples in which black-box testing might give the impression that “everything’s OK,” while white-box tests might uncover an error.

It is easy to achieve, branch coverage, with cases that do not test boundary values. Black box tests expose these problems. Some examples in block box testing are:

Caught by Black-Box likely missed by White-Box:

1. Division by Zero: white box is unlikely to hit the exact number; black box may find this as a boundary value.
2. Possible off by one error: likely boundary case in black-box testing.
3. All performance issues: white box is not concerned with.
4. Memory errors (very large input): likely a block box testing boundary value, but is not needed for white box testing coverage.
5. Rounding errors and overflow errors: block box testing boundary cases, but is not needed to test to achieve any white box testing coverage.
6. Requirements not implemented (missing path problem): block box testing would easily catch (missing function), white-box testing would not since we would not be aware that the code is missing.

Caught by White-Box, missed by Black-Box:

1. Unexpected and flawed branches to optimize the code: if some incorrect optimization is used for some cases, black-box is unlikely to catch it, but white-box testing would force coverage of this code and we might find the problem.
2. Missing requirements
3. Code and requirements are out of date
4. Test a user manual (or help facility) for an application that you use frequently. Find at least one error in the documentation.

The testing must also extend to the third element of the software configuration - documentation. Errors in documentation can be as upsetting for the program as the errors in data source code. We must follow a user guide or an on-line help facility and getting results or behaviours that do not coincide with those predicted by the documentation. Which is why documentation testing is mandatory for every software test plan. Documentation testing can be approached in two phases.

The first phase, review and inspection (examines the document for editorial clarity). The second phase live test uses the documentation with the use of the actual program.

References

1. Roger S. Pressman, Bruce R. Maxim (2015). Software Engineering A Practitioner’s Approach eighth edition, available at : https://dishantrathi.keybase.pub/Semester%206%20Material/Software%20Engineering%20A%20Practitioner%E2%80%99s%20Approach%20eighth%20edition-(www.downloadnema.com).pdf
2. Patton, Ron (2005). Software Testing, available at: https://archive.org/details/softwaretesting0000patt