Professional Documents
Culture Documents
590 Assignment 3 Final
590 Assignment 3 Final
LITERATURE REVIEW
The blockchain technology implements within the Fusion Engine is a form of data
structure where relevant information is collected and stored along with some additional
information of validation. Applications that are developed on the Fusion Engines
blockchain guarantee data integrity and uniqueness to ensure blockchain-based systems
are trustworthy. In the case of the Fusion Engine, security is a critical requirement for the
system.
There are requirements for a testing suite of the FUSION ENGINE to include the
following:
1) Smart Contract Testing (SCT), ensures that the smart contracts satisfy the contractor's
specifications, comply with the laws of the legal systems involved, and do not include
unfair contract terms.
2) Transaction Testing for the Fusion Engine include such tests as checking for double
expenditure and ensuring status integrity. There are various tools which provide
automated testing and verification of smart contracts which is critical in the testing
process, software hooks must exist, allowing external automated scripts to operate the
platform, and observe the outcome, and verifying that the outcome is as per expectation.
In government manufacturing systems if we do not have these software hooks, then smart
contracts functioning testing will be complicated. We will need scripted interactions to
kick the process off; the test logic developed as part of the contracts.
The Fusion Engine incorporates distributed blockchain methodology, testing is done in
isolation and requires the proper development of objects capable of effectively simulating
the blockchain. Blockchain methodology satisfies the requirement of reliable transactions
without a centralized management mechanism that protects the environment from
unreliable participants in the network.
A complete Software testing life cycle is proposed to test the Fusion Engine. This new
Software Testing Life Cycle will utilize a complete set of tests from all perspectives.
UNIT TESTING
Modern software development is not performed in one herculean serial effort but rather
in thousands of individual efforts or ‘units’. Today’s modern software applications are
coherent assemblies of tens of millions of lines of code, comparable in scale to one of the
Great Pyramids where each piece or unit is constructed, tested then joined with the
greater collection (Williams, 2018). Unit testing is a critical first step in developing
properly functioning software.
The key to successful unit testing is in its simplicity. Unit testing is conducted at the
lowest software assembly with each piece of code tested independently with self-
sufficiency (ESJ, 2012). Good unit testing is easy to write, readable, reliable, fast, fully
isolated and easily automatable (Kolodiy, 2018). Unit testing consist of three distinct
phases: code initialization, stimulus application and observation. These phases are also
known as Arrange, Act and Asses or ‘AAA’ (Feregrino, 2016).
The fusion engine has the functional requirements to prevent digital counterfeiting,
prevent manipulation, be secure and have low barriers to entry. Unit testing will be
conducted to ensure functional requirements are properly implemented.
FUNCTIONAL TESTING
The proposed solution includes creating a complete Software testing life cycle to test the
Fusion Engine, which focuses on testing all of the critical components from all critical
perspectives. There will be four phases as shown in Figure 1.
Figure 1. Block chain-oriented Software (BOS) Testing Lifecycle
Phase 1: System Overview
The first phase of our Fusion Engine testing cycle is the system overview phase. Early
adoption of testers in the SDLC so that they have an understanding of all components and
assignments of teams to specific components. A component map generated which
contains all the components and subcomponents of the completed system which will
include all system interfaces. The component map will give a general understanding of
the overall operational environment of the system.
From this complete component map, a system component map is generated, which
contains the shortlisting of all the components that pertain to blockchain technology. The
components shortlisted also mapped into a component diagram, and this defines the
scope of testing. Once the scope of testing is defined, the whole team will have a clear
idea of the required testing and which team is responsible for which component. The
output of phase 1 is the System component map determining the testing scope.
REGRESSION TESTING
Regression testing is a process for verifying that changes in software made by one
developer to one or more portions of the code does not affect other portions of the code.
An example of regression testing is: Consider a product which has functionality to trigger
confirmation, acceptance, and dispatched emails when Confirm, Accept, and Dispatch
buttons are clicked.
An issue occurs in the confirmation email and in order to fix it, some code changes have
to be done. When this occurs, not only the confirmation emails need to be tested, but the
Acceptance and Dispatched emails must also be tested after the code change to ensure the
change has not affected the related functionality.
For this software, we will implement regression testing by verifying that any
modification in the product does not affect the existing modules. A full functionality test
plan will be established, and after every code change or update to the software, regression
testers will follow the regression test plan to ensure all functionality is fully intact.
After functional testing occurs when a new build is available and is verified by the
functional testing process, regression testing will be used to ensure the functionality of
the previous modules still works as intended, and the new build or functionality has not
affected software processes, triggers, or workflows. Regression testing will be done using
the administration and user interfaces to test the user experience and functionality of the
software as a whole.
In the event a regression test finds a bug in the system, that will be submitted back to the
developers to address. When the fix has been put in place, functionality testing will verify
the fix and regression testing will be performed again to ensure the bug is fixed and no
further flaws have been introduced to affect any other functionality of the software. This
process will be repeated until the software passes regression testing.
VERIFICATION
In order to verify the software application, we must be sure that we are building the right
application for the individual needs. The verification process includes:
• Testing
• Inspection
• Design analysis
• Specification analysis
• Consistency checking
Our process involves the use of static analysis where we are ensuring the software
application works effectively without actually executing the program. We do this to
provide a program understanding so we all understand the code and ensure it follows all
regulations (Rouse, 2006, para 1).
The following diagram shows the taxonomy of satisfactory software specifications. It
shows all criteria for verification, which include completeness, consistency, feasibility,
and
testability.
The functional and regression test must be completed to verify the software application.
Once the software has been verified, it then goes to the validation process to ensure that
the way we are building/have built is correct.
Records of all testing is maintained in the applications repository in compliance with our
records matrix (Hart, 2014, p. 5). This ensures that if anyone needed to see how we
verified the software application, they can find all tests and the results of those tests.
I. Component/Unit Testing
Component and unit testing will focus on searching for defects in the software
components and verifying the functionality of the different software components
(modules, objects, classes, etc.) individually. These processes will primary focus on white
box testing perspectives with particular attention paid to the following elements:
• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object and function on an individual basis
Smart Contract Testing
The API’s for Smart Contract Testing will be validated individually during
Component/Unit Testing and in conjunction with other processes during Integration
testing. Particular attention will be paid to the method of applying the smart contract,
conditional statement verification, boundary value analysis, decision tables, and behavior
driven development techniques.
Node testing
Due to the fact that blockchain applications function in a peer-to-peer distributed
network, we must evaluate the network nodes that the blockchain passes through and the
specific protocol for authentication that they are using. The validity of a transaction is
based on a consensus from a majority of these nodes. These tests will independently
validate the consensus of the heterogeneous nodes in order to verify that new information
added to the distributed network is authenticated and valid.
II. Integration Testing
The interaction between the different interfaces of the components ensures that the
software will perform as a complete API. The areas addressed during Unit/Component
Testing must now be evaluated in concert with each other and with the computer
operating system, file system, hardware, and any other software system they interact
with. This process will cover some of the same territory covered during the previous
phase and, consequently, primary approaches testing from a white box perspective.
Alpha Testing
Alpha testing is an internal form of acceptance testing conducted by developers and
operational users in a dynamic testing environment. Each component of the system will
be tested for functionality in an operational state with the most current version of the API.
The Alpha test will be conducted in-house with buy-in from key stakeholders, developers
and representatives from potential end users. Problems encountered with the API will be
corrected on site and addressed during this iterative process. As a collaborative effort
between developers and end-users, Alpha Testing will be approached primarily from a
gray box perspective.
MITIGATION
Anticipating and mitigating security threats is critical during software development. To
assist in the software development process, it is crucial to investigate vulnerabilities and
explore mitigation strategies to help build secure applications. Failing to conduct
adequate testing to identify outstanding vulnerabilities affords a potential attacker the
opportunity to compromise the confidentiality, integrity, or availability of sensitive data
(Microsoft, 2011, pg. 2). Vulnerabilities that go unaddressed enable attackers to
potentially run malicious software on a victim’s machine and, in some situations, elevate
permissions to unrestricting levels. Vulnerabilities that are identified post-release can be
mitigated through software updates; however, in order to mitigate such vulnerabilities,
the software designers need to have knowledge of the vulnerability. Modifying the
program code to address the vulnerability request a whole new round of testing to ensure
no other vulnerabilities are introduced.
While updates are being developed for release, software designers can focus on breaking
the technique that the attackers would use to exploit the vulnerability. “Breaking or
destabilizing these techniques essentially removes a valuable tool from an attacker‘s
toolbox and can make exploitation impossible or increase the time and cost of developing
an exploit” (Microsoft, 2011, pg. 3). Several tactics have been employed Microsoft that
exploit mitigations.
CONCLUSIONS
The focus of this testing plan is on the most relevant issues in state-of-the-art blockchain
software development. We relied on the review of multiple books and articles
highlighting the issues present in Blockchain software testing. From the results of the
analysis, we have proposed a testing plan for blockchain software engineering,
suggesting a focus on collaboration of large teams, testing activities, and specialized tools
for the creation of smart contracts. The need for new professional roles by having a
dedicated software tester from the start of testing lifecycle and also recommended
enhanced security and reliability by testing critical features of blockchain as well as the
overall system.
REFERENCES
bcs.org. (n.d.). Testing of Blcokchain. Retrieved from bcs:
http://www.bcs.org/content/conWebDoc/56020
Boehm, B. W. (1979). Guidelines for verifying and validating software requirements and
design
specifications. Retrieved http://csse.usc.edu/TECHRPTS/1979/usccse79-501/usccse79-
501.pdf
Enterprise Systems Journal. (2012, September 24). 8 Principles of Better Unit Testing.
Retrieved from https://esj.com/Articles/2012/09/24/Better-Unit-Testing.aspx?Page=2
Feregrino, A. (2016, February 22). Unit testing. Retrieved from
https://thatcsharpguy.com/ post/
unit-testing/
Hart. (2014). Software verification and validation process. Retrieved from
https://www.sos.state.co.us/pubs/elections/VotingSystems/systemsDocumentation/HartIn
tercivic/FullEAC-TDP/2-12-QualityAssuranceProgram/QA-
Processes/SoftwareVerificationAndValidationProcess-1000560-D01-Redacted.pdf
Infosys. (n.d.). Blockchain Implementations Quality and Validatio. Retrieved from
https://www.infosys.com/IT-services/validation-solutions/white-
apers/Documents/blockchain-implementations-quality-validation.pdf
Microsoft (2011). Mitigating Software Vulnerabilities: How exploit mitigation
technologies can help reduce or eliminate risk, prevent attacks and minimize operational
disruption due to software vulnerabilities. Retrieved from
http://download.microsoft.com/download/5/0/5/505646ED-5EDF-4E23-8E84-
6119E4BF82E0/Mitigating_Software_Vulnerabilities.pdf
Kolodiy, S. Unit Tests, How to Write Testable Code and Why it Matters. Retrieved 16
October
2018 from https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
Rouse, M. (2006). Static analysis. Retrieved from the Search Win Development website
at:
https://searchwindevelopment.techtarget.com/definition/static-analysis
Steve. (2010, November 29). The difference between verification and validation.
Retrieved from
the Serendipity website at: https://www.easterbrook.ca/steve/2010/11/the-difference-
between-verification-and-validation/
usblogs.pwc.com. (n.d.). The blockchain challenge nobody is talking about. Retrieved
Oct 2018,
from usblogs: http://usblogs.pwc.com/emerging-technology/the-blockchain-challenge/
Williams, J. (2018, May 22). Hackers Are Targeting Your Software Supply Chain: A
Guide To
Securing It. Retrieved from https://www.forbes.com/sites/forbestechcouncil/2018/05/22/
hackers-are-targeting-your-software-supply-chain-a-guide-to-securing-it/#6dd767de3510