Why Back-end is the most important part of the systemBugRaptors
BugRaptors is expertise in backend testing as checking tables, writing queries and procedures. We perform testing in web application or desktop and database can be used in the application like SQL or Oracle. We perform database testing on many projects like banking, finance, health insurance which requires extensive database testing. We are also expertise in “Data Migration” testing in which we migrates the client’s database into our local database and then compare both database by executing the sql queries.
The complete guide for software integration testing | David TzemachDavid Tzemach
What is integration testing?
The integration testing process
When should we start integration tests?
Why should we use integration tests?
Integration tests techniques
Entry and Exit criteria
Best Practices
JMeter Processors are utilized to transform the Samplers in their scope. There are two types of processors in JMeter as JMeter Post-processors and JMeter Pre-processors. In this presentation, we’ll go through post-processors.
Jmeter Post-processors are taking actions after the Sampler is done with its request. You can get the response or gather data into a variable for later use. It is up to your scenario. Read on to learn more.
Why Back-end is the most important part of the systemBugRaptors
BugRaptors is expertise in backend testing as checking tables, writing queries and procedures. We perform testing in web application or desktop and database can be used in the application like SQL or Oracle. We perform database testing on many projects like banking, finance, health insurance which requires extensive database testing. We are also expertise in “Data Migration” testing in which we migrates the client’s database into our local database and then compare both database by executing the sql queries.
The complete guide for software integration testing | David TzemachDavid Tzemach
What is integration testing?
The integration testing process
When should we start integration tests?
Why should we use integration tests?
Integration tests techniques
Entry and Exit criteria
Best Practices
JMeter Processors are utilized to transform the Samplers in their scope. There are two types of processors in JMeter as JMeter Post-processors and JMeter Pre-processors. In this presentation, we’ll go through post-processors.
Jmeter Post-processors are taking actions after the Sampler is done with its request. You can get the response or gather data into a variable for later use. It is up to your scenario. Read on to learn more.
YouTube Link: https://youtu.be/8UfQ8quw0Eg
(**Test Automation Masters Program: https://www.edureka.co/masters-program/automation-testing-engineer-training **)
This Edureka PPT on "What is Integration Testing?" will help you get in-depth knowledge on integration testing and why it is important to subject software builds to integration tests before moving on to next level of testing.
Levels of Software Testing
What is Integration Testing?
Different Approaches to Integration Testing
How to do Integration Testing?
Examples of Integration Testing
Integration Testing Challenges & Best Practices
Follow us to never miss an update in the future.
YouTube: https://www.youtube.com/user/edurekaIN
Instagram: https://www.instagram.com/edureka_learning/
Facebook: https://www.facebook.com/edurekaIN/
Twitter: https://twitter.com/edurekain
LinkedIn: https://www.linkedin.com/company/edureka
Castbox: https://castbox.fm/networks/505?country=in
Integration testing is a methodology where modules are created, and testing of modules consistently begins at the best degree of the programming hierarchy and proceeds towards the lower levels. It’s the augmentation of unit testing.
All software operates on data. High quality software needs to be thoroughly tested. This mandates to take the data into account and creates a need for easy and powerful solutions for data driven unit, functional and integration tests. Data driven tests are tests in which the test logic stays the same and the test data changes with each invocation of the test logic.
With TestNG implementing and executing data driven tests is easy as test data can be injected into test methods as method parameters. Unfortunately TestNG doesn't provide any standard for binding test data from external data sources, like XML, or CSV / Excel files, to the test method parameters. It rather leaves it up to each developer to implement her own solution for data binding. To minimize the effort this calls for the provision of a standardized solution.
This presentation shows how easy it is to implement data driven tests with TestNG. It then goes on to introduce the TestNG Data Binding framework. This framework fills the gap and provides a standardized solution for test data binding. It features an open, plug-in based architecture allowing for countless data formats to be bound to test method parameters. Currently it can bind data from CSV, Java .properties, text and XML files.
Increasing demand in technology is increasing in the number of people choosing software testing as their career path. While it requires a set of technical skills, there are a lot of other things to consider before getting into the field. Here are some that may help you.
Everyone says you should test your designs, but expects you to know what that testing should be. Here we briefly look at the kinds of tests (software) engineers might encounter and what the terms being used actually mean. Finally we settle on Unit Testing as a good place to begin the testing process.
Database development unit test with tSQLtSergio Govoni
When we talk about unit test, we are actually talking about a software testing level that aims to test a discrete piece of code. The word “unit” refers to the smallest piece of code that can be tested separately. In a database solution, the unit is typically a stored procedure, a trigger or a user-defined function. When you start to think about unit test, it is very important to define the System Under Test (SUT) first and isolate it! Unit testing frameworks, stubs, mock and fake objects are used to assist in unit testing. In this session we will explore the techniques and tSQLt framework to start unit testing in your database development.
Demo scripts are available here: https://github.com/segovoni/sql-server-demos/tree/master/datasaturday/2021/datasat0001/database-development-unit-test-with-tSQLt
Key Concepts:
This presentation covers the test aspects of the Continuous Integration process. In a CI implementation automated tests are necessary, but not sufficient. The CI test framework (CITF) allows immediate build verification on multiple test tools and multiple test environments in parallel. CITF provides an interface for incorporating new releases, applications, resources, test tools. It offers multi-purpose standardized reports and presents a flexible interface for presenting the test results, and for reviewing, updating, and summarizing the information.
Learning Objectives:
How to design test objects that mirror the build infrastructure.
How to design a test infrastructure that mirrors the architecture and requirements.
How to describe the test environments and build them dynamically; optimize the usage of limited resources.
How to combine a variety of test tools within the same framework, in order to standardize the test results presentation and the debugging.
YouTube Link: https://youtu.be/8UfQ8quw0Eg
(**Test Automation Masters Program: https://www.edureka.co/masters-program/automation-testing-engineer-training **)
This Edureka PPT on "What is Integration Testing?" will help you get in-depth knowledge on integration testing and why it is important to subject software builds to integration tests before moving on to next level of testing.
Levels of Software Testing
What is Integration Testing?
Different Approaches to Integration Testing
How to do Integration Testing?
Examples of Integration Testing
Integration Testing Challenges & Best Practices
Follow us to never miss an update in the future.
YouTube: https://www.youtube.com/user/edurekaIN
Instagram: https://www.instagram.com/edureka_learning/
Facebook: https://www.facebook.com/edurekaIN/
Twitter: https://twitter.com/edurekain
LinkedIn: https://www.linkedin.com/company/edureka
Castbox: https://castbox.fm/networks/505?country=in
Integration testing is a methodology where modules are created, and testing of modules consistently begins at the best degree of the programming hierarchy and proceeds towards the lower levels. It’s the augmentation of unit testing.
All software operates on data. High quality software needs to be thoroughly tested. This mandates to take the data into account and creates a need for easy and powerful solutions for data driven unit, functional and integration tests. Data driven tests are tests in which the test logic stays the same and the test data changes with each invocation of the test logic.
With TestNG implementing and executing data driven tests is easy as test data can be injected into test methods as method parameters. Unfortunately TestNG doesn't provide any standard for binding test data from external data sources, like XML, or CSV / Excel files, to the test method parameters. It rather leaves it up to each developer to implement her own solution for data binding. To minimize the effort this calls for the provision of a standardized solution.
This presentation shows how easy it is to implement data driven tests with TestNG. It then goes on to introduce the TestNG Data Binding framework. This framework fills the gap and provides a standardized solution for test data binding. It features an open, plug-in based architecture allowing for countless data formats to be bound to test method parameters. Currently it can bind data from CSV, Java .properties, text and XML files.
Increasing demand in technology is increasing in the number of people choosing software testing as their career path. While it requires a set of technical skills, there are a lot of other things to consider before getting into the field. Here are some that may help you.
Everyone says you should test your designs, but expects you to know what that testing should be. Here we briefly look at the kinds of tests (software) engineers might encounter and what the terms being used actually mean. Finally we settle on Unit Testing as a good place to begin the testing process.
Database development unit test with tSQLtSergio Govoni
When we talk about unit test, we are actually talking about a software testing level that aims to test a discrete piece of code. The word “unit” refers to the smallest piece of code that can be tested separately. In a database solution, the unit is typically a stored procedure, a trigger or a user-defined function. When you start to think about unit test, it is very important to define the System Under Test (SUT) first and isolate it! Unit testing frameworks, stubs, mock and fake objects are used to assist in unit testing. In this session we will explore the techniques and tSQLt framework to start unit testing in your database development.
Demo scripts are available here: https://github.com/segovoni/sql-server-demos/tree/master/datasaturday/2021/datasat0001/database-development-unit-test-with-tSQLt
Key Concepts:
This presentation covers the test aspects of the Continuous Integration process. In a CI implementation automated tests are necessary, but not sufficient. The CI test framework (CITF) allows immediate build verification on multiple test tools and multiple test environments in parallel. CITF provides an interface for incorporating new releases, applications, resources, test tools. It offers multi-purpose standardized reports and presents a flexible interface for presenting the test results, and for reviewing, updating, and summarizing the information.
Learning Objectives:
How to design test objects that mirror the build infrastructure.
How to design a test infrastructure that mirrors the architecture and requirements.
How to describe the test environments and build them dynamically; optimize the usage of limited resources.
How to combine a variety of test tools within the same framework, in order to standardize the test results presentation and the debugging.
As technology develops, software programs become more complex and more fragile. In addition to high functionality and seamless user interaction, aesthetics and presentation are increasingly significant in apps. Database testing is now crucial for assessing an application's databases effectively. Here are all the things you need to know about database testing.
Black-Box Testing, Model-Based Testing, Testing for Specialized Environments, Architecture, Object-Oriented Testing Strategies, Object-Oriented Testing Methods, Test Cases and the Class Hierarchy, Testing Concepts for WebApps, Testing Process – An Overview, User Interface Testing, Test Plan, Positive Testing Negative Testing
This is chapter 3 of ISTQB Advance Technical Test Analyst certification. This presentation helps aspirants understand and prepare the content of the certification.
As testers, we know that we can define many more test cases than we will ever have time to design, execute, and report. The key problem in testing is choosing a small, “smart” subset from the almost infinite number of tests available that will find a large percentage of the defects. Join Lee Copeland to discover how to design test cases using formal black-box techniques, including equivalence class testing, boundary value testing, decision tables, and state-transition diagrams. Explore examples of each of these techniques in action. Don’t just pick test cases at random. Rather, learn to selectively choose a set of test cases that maximizes your effectiveness and efficiency to find more defects in less time. Then, learn how to use the test results to evaluate the quality of both your products and your testing. Discover the test design techniques that will make your testing more productive.
COURSE IS NOW FULLY AVAILABLE AND LIVE HERE: https://goo.gl/gVukvc
What you will learn in this second section
Software Testing Methodologies. Waterfall, V-Model and Iterative
What is unity or component system testing
What is integration, system and acceptance means
Differences between functional and non-functional testing
What is a structural testing
Change-related testing
Maintenance testing
Access my blog for much more material and the mock exams.
www.rogeriodasilva.com
We investigate one of the most popular approaches to creating software: test driven development. From the basic understanding why tests are important to a new software development paradigm, where you start with tests and them do the implementation. We glance over different areas of testing and see how one should really do the software testing in different situation.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
A tale of scale & speed: How the US Navy is enabling software delivery from l...
Tutorial databasetestingusingsql
1. Page 1 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
Tutorial Database Testing using SQL
1. INTRODUCTION
1.1 Why back end testing is so important
1.2 Characteristics of back end testing
1.3 Back end testing phases
1.4 Back end test methods
2. STRUCTURAL BACK END TESTS
2.1 Database schema tests
2.1.1 Databases and devices
2.1.2 Tables, columns, column types, defaults, and rules
2.1.3 Keys and indexes
2.2 Stored procedure tests
2.2.1 Individual procedure tests
2.2.2 Integration tests of procedures
2.3 Trigger tests
2.3.1 Update triggers
2.3.2 Insert triggers
2.3.3 Delete triggers
2.4 Integration tests of SQL server
2.5 Server setup scripts
2.6 Common bugs
3. FUNCTIONAL BACK END TESTS
3.1 Dividing back end based on functionality
3.2 Checking data integrity and consistency
3.3 Login and user security
2. Page 2 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
3.4 Stress Testing
3.5 Test back end via front end
3.6 Benchmark testing
3.7 Common bugs
4. NIGHTLY DOWNLOADING AND DISTRIBUTION
4.1 Batch jobs
4.2 Data downloading
4.3 Data conversion
4.4 Data distribution
4.5 Nightly time window
4.6 Common bugs
5. INTERFACES TO TRANSACTION APIS
5.1 APIs' queries to back end
5.2 Outputs of back end to APIs
5.3 Common bugs
6. OTHER TEST ISSUES
6.1 Test tips
6.2 Test tools
6.2 Useful queries
1. INTRODUCTION
This document is to discuss general test specification issues for SQL server back end testing and
to provide testers a test design guide that includes test methodology.
Most systems, i.e. Forecast LRS, Delta, KENAI, KBATS and so on, that are developed by ITG
have client-server architectures. However, only a few projects have their back end completely tested.
1.1 Why back end testing is so important
A back end is the engine of any client/server system. If the back end malfunctions, it
may cause system deadlock, data corruption, data loss and bad performance. Many front ends
log on to a single SQL server. A bug in a back end may put serious impact on the whole
system. Too many bugs in a back end will cost tremendous resources to find and fix bugs and
3. Page 3 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
delay the system developments.
It is very likely that many tests in a front end only hit a small portion of a back end. Many bugs in
a back end cannot be easily discovered without direct testing.
Back end testing has several advantages: The back end is no longer a "black box" to testers.
We have full control of test coverage and depth. Many bugs can be effectively found and fixed in the
early development stage. Take Forecast LRS as an example; the number of bugs in a back end was
more than 30% of total number of bugs in the project. When back end bugs are fixed, the system quality
is dramatically increased.
1.2 Differences between back end testing and front end testing
It is not easier to understand and verify a back end than a front end because a front end usually
has friendly and intuitive user interfaces.
A back end has its own objects, such as, tables, stored procedures and triggers. Data integrity
and protection is critical. Performance and multi-user support are big issues. Slowness in operation can
be vital to the project’s future.
There are no sufficient tools for back end testing. SQL language is mainly a testing tool. MS
Access and MS Excel can be used to verify data but they are not perfect for testing. However, there are
a large number of test tools available for front end testing.
To be able to do back end testing, a tester must have strong background in SQL server and SQL
language. It is relatively difficult to find testers who understand both SQL server and SQL testing. This
causes a shortage of back end testers.
1.3 Back end testing phases
There are several phases in back end testing. The first step is to acquire design specifications
for an SQL server. The second step is test specification design. The next step is to implement the tests
in this design with SQL code. The test specification design should contain information concerning
component testing (individual pieces of the system), regression testing (previously known bugs),
integration testing (several pieces of the system put together), and then the entire system (which will
include both front and back ends).
Component testing will be done early in the development cycle. Integration and system tests
(including interfaces to front ends and nightly processes) are performed after the component tests pass.
Regression testing will be performed continuously throughout the project until it is finished. The back end
usually does not have an independent beta test, as it only exercised by the front end during the beta test
period. The last step is to deliver users a quality product.
1.4 Back end test methodology
Back end test methodology has many things in common with front end testing and API testing.
Many test methods can be used for back end testing. Structural testing and functional testing are more
effective approaches in back end testing. They are overlapped in some test cases. However, the two
methods may discover different bugs. We strongly recommend testers to do both types of testing.
There are many other test methods that can be applied to back end testing. We list a few below. For
other test methods, please check other test design references.
Structural testing:
4. Page 4 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
A back end can be broken down into a finite number of testable pieces based on a back end’s
structure. Tests will verify each and every object in a type of structure.
Functional testing:
A back end can be broken down into a finite number of testable pieces based on application’s
functionality. The test focus is on functionality of input and output but not on the implementation and
structure. Different projects may have different ways to break down.
Boundary testing:
Many columns have boundary conditions. For example, in a column for percentages, the value
cannot be less than zero and cannot be greater than 100%. We should find out these types of boundary
conditions and test them.
Stress testing:
It involves subjecting a database to heavy loads. For incidence, many users heavily access the
same table that has a large number of records. To simulate this situation, we need to start as many
machines as possible and run the tests over and over.
2. STRUCTURAL BACK END TESTS
Although not all databases are the same, there are a set of test areas that will be covered in all
test specifications.
Based on structure, a SQL database can be divided into three categories: database schema,
stored procedures, and triggers. Schema includes database design, tables, table columns, column types,
keys, indices, defaults, and rules. Stored procedures are constructed on the top of a SQL database.
The front end talks to APIs in DLL. The APIs communicate a SQL database through those stored
procedures. Triggers are a kind of stored procedures. They are the "last line of defense" to protect data
when data is about to be inserted, updated or deleted.
Figure 1. The structure of SQL back end
2.1 Database schema testing
Test Coverage Criterion: “EACH AND EVERY ITEM IN SCHEMA MUST BE TESTED AT LEAST ONCE”
2.1.1 Databases and devices
Verify the following things and find out the differences between specification and actual databases
• Database names
• Data device, log device and dump device
• Enough space allocated for each database
• Database option setting (i.e. trunc. option)
2.1.2 Tables, columns, column types, defaults, and rules
5. Page 5 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
Verify the following things and find out the differences between specification
and actual tables
• All table names
• Column names for each table
• Column types for each table (int, tinyint, varchar, char, text, datetime. specially
the number of characters for char and varchar)
• Whether a column allows NULL or not
• Default definitions
• Whether a default is bound to correct table columns
• Rule definitions
• Whether a rule is bound to correct table columns
• Whether access privileges are granted to correct groups
2.1.3 Keys and indexes,
Verify the following things and compare them with design specification
• Primary key for each table (every table should have a primary key)
• Foreign keys
• Column data types between a foreign key column and a column in other table
• Indices, clustered or nonclustered; unique or not unique
2.2 Stored procedure tests
Test Coverage Criterion: “EACH AND EVERY STORED PROCEDURE MUST BE TESTED AT LEAST
ONCE”
2.2.1 Individual procedure tests
Verify the following things and compare them with design specification
• Whether a stored procedure is installed in a database
6. Page 6 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• Stored procedure name
• Parameter names, parameter types and the number of parameters
Outputs:
• When output is zero (zero row affected)
• When some records are extracted
• Output contains many records
• What a stored procedure is supposed to do
• What a stored procedure is not supposed to do
• Write simple queries to see if a stored procedure populates right data
Parameters:
• Check parameters if they are required.
• Call stored procedures with valid data
• Call procedures with boundary data
• Make each parameter invalid a time and run a procedure
Return values:
• Whether a stored procedure returns values
• When a failure occurs, nonzero must be returned.
Error messages:
• Make stored procedure fail and cause every error message to occur at least once
• Find out any exception that doesn’t have a predefined error message
Others:
• Whether a stored procedure grants correct access privilege to a group/user
• See if a stored procedure hits any trigger error, index error, and rule error
• Look into a procedure code and make sure major branches are test covered.
7. Page 7 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
2.2.2 Integration tests of procedures
• Group related stored procedures together. Call them in particular order
• If there are many sequences to call a group of procedures, find out equivalent classes and
run tests to cover every class.
• Make invalid calling sequence and run a group of stored procedures.
• Design several test sequences in which end users are likely to do business and do stress
tests
2.3 Trigger tests
Test Coverage Criterion: “EACH AND EVERY TRIGGER AND TRIGGER ERROR MUST BE TESTED
AT LEAST ONCE”
2.3.1 Updating triggers
Verify the following things and compare them with design specification
• Make sure trigger name spelling is correct
• See if a trigger is generated for a specific table column
• Trigger’s update validation
• Update a record with a valid data
• Update a record, a trigger prevents, with invalid data and cover every trigger
error
• Update a record when it is still referenced by a row in other table
• Make sure rolling back transactions when a failure occurs
• Find out any case in which a trigger is not supposed to roll back transactions
2.3.2 Inserting triggers
Verify the following things and compare them with design specification
• Make sure trigger name spelling
8. Page 8 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• See if a trigger is generated for a specific table column
• Trigger’s insertion validation
• Insert a record with a valid data
• Insert a record, a trigger prevents, with invalid data and cover every trigger error
• Try to insert a record that already exists in a table
• Make sure rolling back transactions when an insertion failure occurs
• Find out any case in which a trigger should roll back transactions
• Find out any failure in which a trigger should not roll back transactions
• Conflicts between a trigger and a stored procedure/rules
(i.e. a column allows NULL while a trigger doesn’t)
2.3.3 Deleting triggers
Verify the following things and compare them with design specification
• Make sure trigger name spelling
• See if a trigger is generated for a specific table column
• Trigger’s deletion validation
• Delete a record
• Delete a record when it is still referenced by a row in other table
• Every trigger error
• Try to delete a record that does not exists in a table
• Make sure rolling back transactions when a deletion fails
• Find out any case in which a trigger should roll back transactions
• Find out any failure in which a trigger should not roll back transactions
• Conflicts between a trigger and a stored procedure/rules
(i.e. a column allows NULL while a trigger doesn’t)
9. Page 9 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
2.4 Integration tests of SQL server
Integration tests should be performed after the above component testing is done. It should call
stored procedures intensively to select, update, insert and delete records in different tables and different
sequences. The main purpose is to see any conflicts and incompatibility.
• Conflicts between schema and triggers
• Conflicts between stored procedures and schema
• Conflicts between stored procedures and triggers
2.5 Server setup scripts
Two cases must be tests: One is to set up databases from scratch and the other to set up
databases when they already exist. Below is the minimum list of areas:
• Is a setup batch job available to run without much operator’s assistance
(It is not acceptable if it requires an operator to run many batch jobs manually)
• Work environment the setup needs to run (DOS, NT)
• Environment variables (i.e. is %svr% defined?)
• Time it takes to set up
• Set up databases from scratch.
• Set up from existing databases
• Set up log and failure messages
• After setup, check for
Databases
Tables
Tables attachments (Keys, indexes, rules, defaults, column names and column types)
Triggers
Stored procedures
Look up data
User access privileges
10. Page 10 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
3. FUNCTIONAL BACK END TESTS
Functional tests more focus on functionality and features of a back end. Test cases can be
different from project to project. But many projects have things in common. The following section
discusses the common areas. We encourage testers to add project-specific test cases in the functional
test design.
3.1 How to divide back end on function basis
It is not a good idea to test a server database as a single entity at initial stage. We have to divide
it into functional modules. If we cannot do the partition, either we do not know that project deep enough
or the design is not modulized well. How to divide a server database is largely dependent on features of
a particular project.
METHOD 1: We may ask ourselves what the features of a project are. For each major feature,
pick up portion of schema, triggers and stored procedures that implement the function and make them
into a functional group. Each group can be tested together. For example, the Forecast LRS project had
four services: forecast, product lite, reporting, and system. This was the key for functional partitioning:
Figure 2. View a SQL server pertaining to the functionality
METHOD 2: If the border of functional groups in a back end is not obvious, we may watch data
flow and see where we can check the data: Start from the front end. When a service has a request or
saves data, some stored procedures will get called. The procedures will update some tables. Those
stored procedures will be the place to start testing and those tables will be the place to check test
results.
3.1 Test functions and features
Test Coverage Criterion: “EACH AND EVERY FUNCTION OR FEATURE MUST BE TESTED AT
LEAST ONCE”
The following areas should be tested:
• Every feature no matter major or minor
• For updating functions, make sure data is updated following application rules
• For insertion functions, make sure data is inserted following application rules
• For deletion functions, make sure data is deleted correctly
• Think about if those functions make any sense to us. Find out nonsense, invalid
logic, and any bugs.
• Check for malfunctioning
• Check for interoperations
• Error detection
• Error handling
11. Page 11 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• See if error messages are clear and right.
• Find out time-consuming features and provide suggestions to developers
3.2 Checking data integrity and consistency
This is a really important issue. If a project does not guarantee data integrity and consistency,
we have obligation to ask for redesign. We have to check the minimum things below:
• Find out data protection mechanisms for a project and evaluate them to see if they are
secure
• Data validation before insertion, updating and deletion.
• Triggers must be in place to validate reference table records
• Check major columns in each table and see if any weird data exist. (Nonprintable
characters in name field, negative percentage, and negative number of PSS phone calls
per month, empty product and so on)
• Generate inconsistent data and insert them into relevant tables and see if any failure
occurs
• Try to insert a child data before inserting its parent’s data.
• Try to delete a record that is still referenced by data in other table
• If a data in a table is updated, check whether other relevant data is updated as
well.
• Make sure replicated servers or databases are on sync and contain consistent
information
3.3 Login and user security
The following things need to be checked:
• Email validation
• SQL user login (user id, password, host name)
• NT server login
• Database access privilege (the sysusers table)
12. Page 12 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• Database security hierarchy
• Table access privilege (if ‘select’ is allowed.)
• Table data access control
• Training account (maybe no password is required)
There are more test cases here:
• Simulate front end login procedure and check if a user with correct login information can
login
• Simulate front end login procedure and check if a user with incorrect login
information fail to login
• Check concurrent logins (make many users login at the same time.)
• Try to login when a time-consuming query is running to see how long login will
take to succeed
• Check for any security-restrict functions and see they are working properly
• See any data view restriction in place, such as, a user can see his data and the
data of people who report to him.
3.4 Stress Testing
We should do stress tests on major functionality. Get a list of major back end functions/features
for a project. Find out corresponding stored procedures and do the following things:
Test Coverage Criterion: “EACH AND EVERY MAJOR FUNCTION OR FEATURE MUST BE
INCLUDED IN STRESS TESTING”
• Write test scripts to try those functions in random order but every function must be
addressed at least once in a full cycle.
• Run test scripts over and over for a reasonable period
• Make sure log execution results and errors.
• Analyze log files and look for any deadlock, failure out of memory, data
corruption, or nothing changed.
3.5 Test a back end via a front end
Sometimes back end bugs can be found by front end testing, specially data problem. The
13. Page 13 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
following are minimum test cases:
• Make queries from a front end and issue the searches (It hits SELECT statements or query
procedures in a back end)
• Pick up an existing record, change values in some fields and save the record.
(It involves UPDATE statement or update stored procedures, update triggers.)
• Push FILE - NEW menu item or the NEW button in a front end window. Fill in
information and save the record. (It involves INSERT statements or insertion
stored procedures, deletion triggers.)
• Pick up an existing record, click on the DELETE or REMOVE button, and
confirm the deletion. (It involves DELETE statement or deletion stored
procedures, deletion triggers.)
• Repeat the first three test cases with invalid data and see how the back end
handles them.
3.6 Benchmark testing
Test Coverage Criterion: “EACH AND EVERY FUNCTION OR FEATURE MUST BE INCLUDED IN
BENCHMARK TESTING”
When a system does not have data problems or user interface bugs, system performance will get
much attention. The bad system performance can be found in benchmark testing. Four issues must be
included:
• System level performance
• Major functionality (Pick up most-likely-used functions/features)
• Timing and statistics (Minimal time, maximal time and average time)
• Access volume (A large number of machines and sessions must be involved.)
3.7 Common bugs
(To be filled in)
4. NIGHTLY DOWNLOADING AND DISTRIBUTION
This part is usually developed by an operation team. It did not get enough attention a long time
14. Page 14 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
ago. However, after we deliver a product, end users must live with nightly process every daily. Bugs in
nightly job put serious impact on users’ daily work. Loss or corruption of customer data can be severe.
We strongly recommend testers to intensively test nightly downloading and distribution, particularly error
detection and reporting.
4.1 Batch jobs
By batch job, We mean batch jobs for Windows NT, DOS or OS/2. (The SQL scripts that are
called by a batch job will be discussed in next three sections. )
Test Coverage Criterion: “EACH AND EVERY BATCH JOB MUST BE TESTED AT LEAST ONCE”
Here are the minimum list of test cases:
File transfer batch job:
• Destination path and source path
• All variables in a batch job must be resolved
(i.e. if %log% is used, the “log” must be defined somewhere either in the same file or
in other system setup utility.)
• Make sure source files and their names are correct as specified.
• Make sure destination files and their names are correct as specified.
• Verify if any error level is checked after each file copy.
• Error messages must be logged. Fatal errors must be sent to operators or testers.
• Verify the database has the bulk copy option set to true before a batch job is
executed
• Get estimate of total batch execution time. Make sure it fits the time window
(specially the worst case)
BCP batch job:
• Make sure dbnmpipe.exe is automatically loaded and bcp.exe/isql.exe are on the
system path
• Check for pass-in parameters %1, %2, ... to a batch job
• Make sure a table truncation script must be run before bcp in to those tables
• Make sure database name, bcp in file name/bcp out file name, and options /S,
/U, /P, /c and /b
• Verify if any error level is checked after each bcp command.
15. Page 15 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• Failure should be logged. Fatal failure should be sent to operators or testers
immediately
Batch file jobs that launch SQL scripts:
• Make sure dbnmpipe.exe is automatically loaded and isql.exe are on the system
path
• Check for pass-in parameters %1, %2, ... to a batch job
• Make sure all required SQL files and their names, options /S, /U, /P
• Verify if any error level is checked after each launching
• Failure should be logged. Fatal failure should be sent to operators or testers
immediately
4.2 Data downloading
In most cases, downloading is not just bcp in to a database. Data format change and
calculations may happen.
Test Coverage Criterion: “EACH AND EVERY SCRIPT MUST BE TESTED AT LEAST ONCE”
We have to check the following areas:
• Network connection status. Failure handling.
• Input data must be validated before a batch job inserts/updates a database
(Invalid data must be filtered out, i.e. NULLs in critical fields, negative values, too big
numbers)
• Input data populated to right tables
• Calculations must follow business rules
• Check if data is really changed after data downloading
• See if two columns of data are mistakenly exchanged (i.e. product_id data and
productgroup_id data are reversed when inserted)
• Check if any data is unexpectedly changed or deleted
• See what happens if database objects do not exist when downloading starts
4.3 Data conversion
The goals of many ITG projects are moving end users from existing VAX systems into PC
platform systems. One of important steps is to convert old data into new systems. Data conversion is
16. Page 16 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
required.
Test Coverage Criterion: “EACH AND EVERY SCRIPT MUST BE TESTED AT LEAST ONCE”
We list several checking items here:
• For each script, check for syntax error (Running a script is an easiest way to find out)
• For each script, check for table mapping, column mapping, and data type
mapping
• Verify lookup data mapping
• Run each script when records do not exist in destination tables
• Run each script when records already exist in destination tables
• Make sure the execution sequence of scripts is correct
(i.e. Look up data must be converted first before conversions)
• Look for any scripts that encounter index error or trigger errors
(i.e. error attempt to insert unique index row.)
• Make sure a major transaction statement is followed by error checking “if
@@error != 0”
• Look for any script that causes error out of memory at run time
• Check for any scripts that take too long to run for reasonable size of records. If
it is the case, suggest developers to optimize scripts.
• Make sure “begin tran” and “commit tran” are in scripts
• If a failure occurs, transactions in a block after “begin tran” should be rolled
back
4.4 Data distribution
There are two kinds of data distribution: One kind is to send replicated data to other SQL servers
across LAN and WAN and keep them in sync. The other distribution is to pass information to other kinds
of systems. Header information and data need converting. For example, KBATS article editing system
nightly sends articles to Knowledge base server and to external system like CompuServe. Here is a
minimum checking list:
Test Coverage Criterion: “EACH AND EVERY FEATURE MUST BE TESTED AT LEAST ONCE”
For data replication:
17. Page 17 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• Make sure every job extracts right updates from a SQL server
• Look for any new records that are missing in distribution data set
• Make sure data overwriting works correct
• Make sure sequences of data updates in destination servers
• Run distribution utility when new updates need to be distributed
• Run distribution utility when many changes are made
• Verify data loss handling mechanism for LAN or WAN environment
• Verify distribution mechanism when a network is down
• Verify error handling when a destination server is down
• Verify error handling when a source server is down
• Check if failures can be automatically recovered or can be recovered from next
run
For data conversion distribution:
• Make sure every job extracts right data from a SQL server
• Look for any new records that are missing in distribution data set
• Make sure table mapping, column mapping, data type mapping, file format
changes, and header changes
• Make sure data is converted to fit other systems
• Make sure data overwriting works correct
• Make sure sequences of data updates in destination servers
• Run distribution utility when new updates need to be distributed
• Run distribution utility when many changes are made
• Verify data loss handling mechanism in LAN or WAN
• Verify distribution mechanism when a network is down
• Verify error handling when a destination server is down
18. Page 18 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• Verify error handling when a source server is down
• Check if failures can be automatically recovered or can be recovered from next run
4.6 Common bugs
(To be filled in soon)
5. INTERFACES TO TRANSACTION APIS
By Transaction API, we mean those APIs that are specially designed for our projects to handle
communications between a front end and a back end. Those APIs are not part of SQL DBLIB or
ODBC. Although they do not belong to a back end, we have to test their interfaces to back end.
Figure 3. Connections between a front end and a back end
5.1 Connections to a SQL server database
• Make sure transaction APIs can open connections to a SQL server
• Verify APIs are able to send queries to a SQL server and retrieve data
• Unplug net cable and see if APIs can detect it
• Stop a SQL server and call APIs to make connection
• Stop a SQL server in the middle of transaction
5.2 Send queries to a back end
• Call each API that sends queries to a back end
• Make sure APIs call right stored procedures
• Verify parameters in stored procedure calls
• Make sure APIs should call stored procedures to access a SQL server. It is not
recommended to send a simple query like “SELECT ... FROM ... WHERE...”
5.3 Receive output from a back end
• For every API, try a query with no row returned
• For every API, try more than one row returned
• For major API, try to have many rows returned
• Disconnect in the middle of transactions and check error detection
• Make sure an API always checks the return value of a stored procedure
19. Page 19 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
• When a failure occurs, an API should receives value nonzero
5.4 Common bugs
(To be filled in soon)
6. OTHER TEST ISSUES
6.1 Test tips
• No program is bug free. If you have been doing tests for several days and do not find any
bugs, our test methods or test data might be wrong. You should at least have some
suggestions for developers.
• The Break-Program attitude is highly recommended. If you don’t break it now,
end users will break it later.
• There are a huge number of test cases. Always ask yourselves if any test case
is missing and if our test specifications are complete.
• When you design test specification, think about valid cases, invalid cases and
boundary cases
• Effective test methodology is neither unique nor universal. Feel free to discuss
the test plan, test specifications and test data with other testers.
• When testing, you should pretend to be different levels of users. As “power”
users, you can test advanced features heavily. As novices, you can do “stupid”
things, i.e. turn off the machine in the middle of a transaction.
• If you suspect any result or message, go ahead and track it down. You may
have found a “big” bug.
• Before you log a bug into Raid, find out the minimal steps to reproduce it. If
you can not reproduce a bug, make a note and try it next time.
• If a developer resolves a major bug as “By-Design”, but you think it is crucial to
fix, try to convince the developer and your test lead.
• If you can track a bug down to a code level, do it. You will learn something
new from bug tracking
• If a test is likely to be repeated later, automate it.
• A good programmer may not be a good tester. Be proud of your ability to find
20. Page 20 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
bugs.
• You are an important part of product development. You help to ensure the high
quality of ITG products.
6.2 Test tools
As mentioned earlier in this document, there are not many good tools for back end
testing. But some utilities can be used.
• SQL language:
Write test scripts to call stored procedures, retrieve data, insert/update/delete
records. Most back end test work can be done with the SQL language
• NT SQL utilities:
DOS utilities like isql.exe, bcp.exe
Windows applications such as WinQuery, ISQL/w, SQL Administration, SQL Object
Manager, SQL Client Configuration Utility
• MSAccess:
We may take advantage of MSAccess’s tables, queries, forms, reports, macros and
modules.
• Excel:
MSQuery and Q+E are useful for data validation
• Our own test tools:
Several test tools have been developed. For example, stored procedures to log
passed/failed for each test and to present test statistics. Contact MinF for those tools.
6.2 Useful queries
To facilitate testing, we post some useful queries here. They are just something good to start
with.
• Check for data devices and log devices:
sp_helpdb <database_name>
• Check for space used:
sp_spaceused <database_name>
• Get information about an object in a database:
21. Page 21 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
sp_help <object_name>
where <object_name> can be a table name, trigger name, stored procedure name and so on.
• Get trigger code, procedure code, or view code, do:
sp_helptext <object_name>
• Find out who is on system, whose host name and other information:
sp_who
• Change database:
user <destination database_name>
• Find out existence of SQL objects by type:
select * from sysobjects where type = “<type>“
where <type> can be
U ------- User table
V ------- View
P ------- Stored procedure
TR ------ Trigger
• Count the numbers of records in individual user tables:
select "print '"+name+"'
select count(*) from "+name+"
go" from sysobjects where type = ‘U’
Note: this statement does do count(). It outputs a script that does count.
• Generate invalid test data:
declare @customer_id int
/* Generate an invalid customer company id. */
select @customer_id = MAX (customercompanyid) + 1 from customercompany
• Make a name unique and general using SUSER_NAME():
22. Page 22 of 22
Database Testing Tutorial using SQL – Provided by http://www.onestopsoftwaretesting.com
declare @companyname varchar(40)
select @ companyname = SUSER_NAME() + “‘S TEST COMPANY”
• The following code is to go through every record in a table and put a number after a
company name:
declare @number int, @companyname varchar(40)
select @number = 1
select @companyname = MIN(companyname) from customercompany
/* Change companyname */
while @companyname != “”
begin /* Update a companyname */
update customercompany
set companyname = companyname + convert(varchar, @number)
where companyname = @companyname
/* Pick up next companyname */
select @companyname = MIN(companyname)
from customercompany
where companyname > @companyname
end