The Development and Evaluation of a Unit Testing Methodology

Total Page:16

File Type:pdf, Size:1020Kb

The Development and Evaluation of a Unit Testing Methodology Computer Science Stefan Lindberg and Fredrik Strandberg The Development and Evaluation of a Unit Testing Methodology Master’s thesis 2006:3 The Development and Evaluation of a Unit Testing Methodology Stefan Lindberg and Fredrik Strandberg ii This report is submitted in partial fulfillment of the requirements for the Master of Science degree in Information technology. All material in this report which is not my own work has been identified and no material is included for which a degree has previously been conferred. Stefan Lindberg Fredrik Strandberg Approved, 2006-03-07 Opponent: Per Hurtig Advisor: Donald Ross Examiner: Tim Heyer iii iv Abstract Westinghouse Fuel Manufacturing in Västerås, Sweden, manufactures fuel rods for nuclear plants. Manufacturing-IT is a software development section at Westinghouse Fuel Manufacturing. This thesis involves the development of a unit testing methodology (UTM) for the Manufacturing-IT section, which currently does not follow a well-defined software test process. By evaluating different unit testing best practices and UTM design issues collected from literature, articles, papers and the Internet, a UTM document was developed. The UTM document was developed according to requirements from Manufacturing-IT and as an extension to existing documents within the Westinghouse organization. The UTM was evaluated by applying the methodology in a case study. A single unit within a production control system in the rod manufacturing workshop at the Westinghouse fuel factory in Västerås was tested. Asides from evaluating the UTM, the case study was intended to find software tools that could simplify the unit testing process, and to test the production control system unit thoroughly. The 182 test cases designed and implemented revealed 28 faults in the tested unit. NUnit was chosen to be the tool for automated unit testing in the UTM. The results from the case study indicate that the methods and other unit testing process related activities included in the UTM document developed are applicable to unit testing. However, adjustments and further evaluation will be needed in order to enhance the UTM. The UTM developed in this thesis is a first step towards a structured testing process for the Manufacturing-IT section and the UTM document will be used at the Manufacturing-IT section. By using the methods and other unit testing process related activities in the UTM developed in this thesis, any company or individual with similar requirements for a UTM as Manufacturing-IT, and that performs unit testing in an unstructured way, may benefit in that a more structured unit testing process is achieved. v vi Contents 1 Introduction...................................................................................................................1 1.1 What is a unit testing methodology?.......................................................................1 1.2 Thesis summary.....................................................................................................1 1.3 Reading guidelines.................................................................................................2 2 Background...................................................................................................................5 2.1 Introduction............................................................................................................5 2.2 Software engineering..............................................................................................6 2.2.1 What is software engineering?.............................................................................................6 2.2.2 Principles of software engineering.......................................................................................7 2.3 Verification and validation.....................................................................................8 2.4 Software Testing....................................................................................................9 2.5 Unit testing...........................................................................................................11 2.6 Unit testing at ManIT...........................................................................................11 2.6.1 Existing standards and documents.....................................................................................12 2.7 Summary..............................................................................................................15 3 Unit testing methodology development.......................................................................17 3.1 Introduction..........................................................................................................17 3.2 Methodology design issues...................................................................................20 3.3 ManIT requirements.............................................................................................23 3.4 Unit testing best practices.....................................................................................25 3.4.1 Definition of a unit............................................................................................................25 3.4.2 When to design and execute unit test cases........................................................................26 3.4.3 Unit testing roles...............................................................................................................27 3.4.4 Traditional unit testing methods.........................................................................................29 3.4.5 Formal specification and verification.................................................................................29 3.4.6 Black-box unit testing.......................................................................................................30 3.4.7 Equivalence partitioning and boundary value analysis........................................................30 3.4.8 The all-pairs method.........................................................................................................32 3.4.9 White-box unit testing.......................................................................................................34 3.4.10 Path testing.......................................................................................................................34 3.4.11 Data flow testing...............................................................................................................36 3.4.12 Multiple condition testing..................................................................................................37 3.4.13 Loop testing......................................................................................................................37 3.4.14 Testing exceptions............................................................................................................38 3.4.15 Unit test methods for object-oriented code.........................................................................39 vii 3.4.16 State-based unit testing......................................................................................................39 3.4.17 Selecting test cases for state-based unit testing...................................................................40 3.4.18 Inheritance........................................................................................................................42 3.4.19 Polymorphism...................................................................................................................46 3.4.20 Information hiding............................................................................................................46 3.4.21 Order of testing within a unit.............................................................................................48 3.4.22 Documentation of unit test cases........................................................................................48 3.4.23 Unit test drivers.................................................................................................................49 3.4.24 Stubs.................................................................................................................................50 3.4.25 Prioritizing unit tests.........................................................................................................52 3.4.26 Criteria for ending unit testing...........................................................................................52 3.4.27 Redundant test cases.........................................................................................................57 3.4.28 Reporting unit test results..................................................................................................57 3.5 Summary..............................................................................................................61 4 Case study....................................................................................................................63 4.1 Introduction..........................................................................................................63 4.2 Case study expectations........................................................................................64 4.3 Case study setup...................................................................................................64 4.3.1 Tool research....................................................................................................................64
Recommended publications
  • Getting Started with Testcomplete 7
    * Windows and the Windows logo are trademarks of the Microsoft group of companies. 2 Table of Contents Table of Contents INTRODUCING AUTOMATED TESTING AND TESTCOMPLETE .....................................................3 Automated Testing......................................................................................................................................3 Test Types ...................................................................................................................................................3 TestComplete Projects and Project Items...................................................................................................4 TestComplete User Interface......................................................................................................................5 TestComplete Test Object Model................................................................................................................6 Checkpoints and Stores ..............................................................................................................................8 CREATING YOUR FIRST TEST..................................................................................................................9 1. Creating a Test Project.........................................................................................................................10 2. Defining Applications to Test ...............................................................................................................11 3. Planning
    [Show full text]
  • Buyers Guide Product Listings
    BUYERS GUIDE PRODUCT LISTINGS Visual Studio Magazine Buyers’ Guide Product Listings The 2009 Visual Studio Magazine Buyers’ Guide listings comprise more than 700 individual products and services, ranging from developer tooling and UI components to Web hosting and instructor-led training. Included for each product is contact and pricing information. Keep in mind that many products come in multiple SKUs and with varied license options, so it’s always a good idea to contact vendors directly for specific pricing. The developer tools arena is a vast and growing space. As such, we’re always on the prowl for new tools and vendors. Know of a product our readers might want to learn more about? E-mail us at [email protected]. BUG & FEATURE TRACKING Gemini—CounterSoft Starts at $1189 • countersoft.com • +44 (0)1753 824000 Rational ClearQuest—IBM Rational Software $1,810 • ibm.com/rational • 888-426-3774 IssueNet Intercept—Elsinore Technologies Call for price • elsitech.com • 866-866-0034 FogBugz 7.0—Fog Creek Software $199 • fogcreek.com • 888-364-2849; 212-279-2076 SilkPerformer—Borland Call for price • borland.com • 800-632-2864; 512-340-2200 OnTime 2009 Professional—Axosoft Starts at $795 for five users • axosoft.com • 800-653-0024; SourceOffSite 4.2—SourceGear 480-362-1900 $239 • sourcegear.com • 217-356-0105 Alexsys Team 2.10—Alexsys Surround SCM 2009—Seapine Software Starts at $145 • alexcorp.com • 888-880-2539; 781-279-0170 Call for price • seapine.com • 888-683-6456; 513-754-1655 AppLife DNA—Kinetic Jump Software TeamInspector—Borland
    [Show full text]
  • Anatomy of an Automated Testing Framework
    MONTHLY NEWSLETTER July 2009 - Pragmatic Software Newsletters Anatomy of an Automated Testing Framework Last month we discussed why companies embark on automated testing, why some companies fail in this effort, and how using a keyword driven automated testing framework can increase your chance of success. To view that newsletter, visit http://www.pragmaticsw.com/newsletters/Newsletter_2009_06_SP.htm. This month we discuss the key ingredients of an automated testing framework that can lead to automation success. Why Automate Your Test Cases? Many companies run their regression test cases manually, so when does it make sense to begin automating your regression test cases? It makes sense to automate your test cases when you can no longer run the regression test cases on each build created. For example, if you are doing daily or weekly builds of your code to quality assurance and you cannot quickly run your regression test cases with each build, it is time to consider automating them. Automating your test cases provide these benefits: Quicker Releases – By having your regression test cases run automatically, your software quality team can concentrate on testing new features of your software and less time regressing existing features. Higher quality releases – Your software releases will have fewer bugs and require less customer support because they will be of higher quality. Happier Customers – Your customers will be happier and more willing to serve as testimonials for future prospects. What is an Automated Testing Framework? Most automated tools require the test engineer to understand a scripting language (VB Script, Java Script, etc.) to write their automated test cases.
    [Show full text]
  • Comparison of Unit-Level Automated Test Generation Tools
    Comparison of Unit-Level Automated Test Generation Tools Shuang Wang and Jeff Offutt Software Engineering George Mason University Fairfax, VA 22030, USA {swangb,offutt}@gmu.edu Abstract effort will be worthwhile [2]. Another possible reason is that unit tests must be maintained, and maintenance for unit Data from projects worldwide show that many software tests is often not budgeted. A third possibility is that de- projects fail and most are completed late or over budget. velopers may not know how to design and implement high Unit testing is a simple but effective technique to improve quality unit tests; they are certainly not taught this crucial software in terms of quality, flexibility, and time-to-market. knowledge in most undergraduate computer science pro- A key idea of unit testing is that each piece of code needs grams. its own tests and the best person to design those tests is Using automated unit test tools instead of manual testing the developer who wrote the software. However, generating can help with all three problems. Automated unit test tools tests for each unit by hand is very expensive, possibly pro- can reduce the time and effort needed to design and imple- hibitively so. Automatic test data generation is essential to ment unit tests, they can make it easier to maintain tests as support unit testing and as unit testing is achieving more at- the program changes, and they can encapsulate knowledge tention, developers are using automated unit test data gen- of how to design and implement high quality tests so that eration tools more often.
    [Show full text]
  • Bsquare Annual Report 2018
    ANNUAL REPORT 2018 April 30, 2019 Dear shareholder, I would like to start by thanking the board for giving me the opportunity to serve you as President & CEO of Bsquare. I look forward to delivering on our commitments to our customers and business partners, creating an environment that can attract and retain the brightest minds in the industry, and most importantly building value and restoring the confidence of our shareholders. 2018 was a year of transition for Bsquare Corporation. In May of 2018 president & CEO Jerry Chase stepped down, and the board appointed Kevin Walsh as acting CEO while they initiated a search for a permanent chief executive officer. At that time Andrew Harries became executive chairman, increasing his involvement in day-to-day management. The changes were a recognition by the board of directors that the DataV IoT software-as-a-service (SaaS) business was not progressing as quickly as the prior leadership had projected. 2018 also saw changes to the board of directors of Bsquare: in June Ryan Vardeman, principal and co-founder of Palogic Value Management, LP, was appointed; in August Robert Peters, also of Palogic, joined following the resignation of Robert DeSantis; and finally, in November, Davin Cushman, CEO of Ignite Technologies, was appointed, replacing long-time board member Kendra VanderMeulen. In an interim capacity Kevin Walsh was tasked with reducing spending on DataV software development and exploring options for transitioning the DataV SaaS-only model to combination of software and professional services. The board of directors also directed Kevin to further explore partnering opportunities with Amazon and Microsoft as their cloud and Internet of Things (IoT) strategies seemed synergistic with Bsquare’s DataV Industrial Internet of Things (IIoT) strategy.
    [Show full text]
  • Testing Strategies for Complex Environments: Agile, SOA
    May/June 2009 Volume 2 SOFTWARE TESTING Testing strategies for complex environments: Agile, SOA • CHAPTER 1 A SOA VIEW OF TESTING • CHAPTER 2 AGILE TESTING STRATEGIES: EVOLVING WITH THE PRODUCT EDITOR’S LETTER 1 Testing in the new worlds of SOA and agile p UNLESS YOU LIVE in a sci-fi novel, Karen N. Johnson in “Agile testing a there’s one rule of thumb for any new strategies: Evolving with the product.” EDITOR’S LETTER place you go: some things are differ- Agile is a more collaborative process ent; some are the same. Usually, suc- and calls for seizing “iterations as a cess, fun or survival in that new place chance to evolve test ideas,” Johnson a depends upon how well you handle writes. Fundamental testing tasks, like CHAPTER 1 A SOA VIEW the differences. In this issue of exploratory and investigative testing, OF TESTING SearchSoftwareQuality.com’s Soft- stay the same, but the productivity of ware Testing E-Zine, the new “places” completing those jobs can increase. are a service-oriented architecture Johnson and Kelly discuss the finer a (SOA) and an agile software develop- points of testing in agile and SOA, CHAPTER 2 AGILE TESTING ment environment. respectively, in this issue’s articles. STRATEGIES: EVOLVING Examining the ins and outs of soft- They also describe revelations they’ve WITH THE ware testing in SOA environments in had while working in those environ- PRODUCT “An SOA view of testing,” consultant ments and best practices they’ve Mike Kelly focuses on the “subtle dif- learned and continue to use.
    [Show full text]
  • Load and Performance Test Tools Pylot
    Load and Performance Test Tools Pylot - Open source tool by Corey Goldberg for generating concurrent http loads. Define test cases in an XML file - specify requests - url, method, body/payload, etc - and verifications. Verification is by matching content to regular expressions and with HTTP status codes. HTTP and HTTPS (SSL) support. Monitor and execute test suites from GUI (wxPython), and adjust load, number of agents, request intervals, rampup time, test duration. Real-time stats and error reporting are displayed. JCrawler - An open-source stress-testing tool for web apps; includes crawling/exploratory features. User can give JCrawler a set of starting URLs and it will begin crawling from that point onwards, going through any URLs it can find on its way and generating load on the web application. Load parameters (hits/sec) are configurable via central XML file; fires up as many threads as needed to keep load constant; includes self-testing unit tests. Handles http redirects and cookies; platform independent. vPerformer - Performance and load testing tool from Verisium Inc. to assess the performance and scalability of web apps. Use recorded scripts or customized scripts using Javascript. Targeted platforms: Windows Curl-Loader - Open-source tool written in 'C', simulating application load and behavior of tens of thousand HTTP/HTTPS and FTP/FTPS clients, each with its own source IP- address. In contrast to other tools curl-loader is using real C-written client protocol stacks, namely, HTTP and FTP stacks of libcurl and TLS/SSL of openssl. Activities of each virtual client are logged and collected statistics include information about: resolving, connection establishment, sending of requests, receiving responses, headers and data received/sent, errors from network, TLS/SSL and application (HTTP, FTP) level events and errors.
    [Show full text]
  • The Art of Unit Testing
    the art of with Examples in .NET MANNING ROY OSHEROVE Early Praise for The Art of Unit Testing “Th e Art of Unit Testing provides a thorough, incremental introduction to writing tests as part of the programming process. Programmers looking to write their fi rst test will fi nd easy-to-follow instructions, while those who have been testing for a while will fi nd ideas for refi ning their technique” —Kent Beck, Th ree Rivers Institute “Beautifully craft ed, detailed unit testing masterpiece. Bravo, Bravo, Bravo!” —Mohammad Azam, Microsoft MVP, HighOnCoding “Th is book tells all the truth about unit testing, even the unpleasant side of it.” —Franco Lombardo, Molteni Informatica “Roy knows testing.” —Wendy Friedlander, Agile Solutions “Unit testing, directly from theory to practice.” —Francesco Goggi, Soft ware Engineer Licensed to Abraham Rosner <[email protected]> The Art of Unit Testing with Examples in .NET Licensed to Abraham Rosner <[email protected]> Licensed to Abraham Rosner <[email protected]> The Art of Unit Testing with Examples in .NET Roy Osherove MANNING Greenwich (74° w. long.) Licensed to Abraham Rosner <[email protected]> For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. Sound View Court 3B fax: (609) 877-8256 Greenwich, CT 06830 email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.
    [Show full text]
  • Load Testing, Performance Testing, Volume Testing, and Stress Testing
    STRESS, LOAD, VOLUME, PERFORMANCE, BENCHMARK AND BASE LINE TESTING TOOL EVALUATION AND COMPARISON Cordell Vail Copyright 2005 by Cordell Vail - All rights reserved www.vcaa.com NOTE: The information contained in this document or on the handout CD at the seminars is for use only by the participants who attend one of our seminars. Distribution of this information to anyone other than those attending one of the seminars is not authorized by the authors. It is for educational purposes of the seminar attendees only. It is our intention that by putting this information here from the vendor web pages and from other testers evaluations, that you will have a tool that will let you do your own evaluation of the different tool features. Hopefully this will let you find tools that will best meet your needs. The authors are not recommending any of these tools as one being better than another. All the information has been taken from reviews we have found on the Internet, from their own web pages, or from correspondence with the vendor. They have been grouped here according to our presentation outline. For some of the tools, we were not able to determine the cost or type (ie open source) from their web page or correspondence with the vendor. Users are cautioned that they will be installing any downloaded tools at their own risk. TABLE OF CONTENTS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Table Of Contents Key: EVALUATION SECTION Page VENDOR (and foreign country if known) Tool Name [type and price if known]
    [Show full text]
  • Best Practices for Planning Your Automated Test Effort
    MONTHLY NEWSLETTER June 2010 - Monthly Newsletters Best Practices for Planning your Automated Test Effort This month's newsletter is delivered as an On-Demand webinar. It is the 1st in a 5 part series entitled "Uniting your Automated and Manual Test Efforts" and focuses on best practices for planning your automated test effort. Best Practices for Planning your Automated Test Effort Click on the movie below (http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=UnitingPart01) to begin the presentation. You will learn: 1. How to identify what test cases should be automated 2. How to best organize your automated test cases 3. How to version and protect your automated test cases 4. How to schedule your automated test cases to run periodically What's Coming Next Month Look for our next On-Demand video next month, “Best Practices for Planning your Manual Test Effort”. Thank you and we hope you enjoy this On-Demand Webinar. Happy testing! Sign Up Today Start improving your project efficiency and success by signing up for our monthly newsletters today. Helpful Software Testing Tools and Templates Below are some helpful software testing resources and templates to aid you in developing software solutions: Software Planner AutomatedQA TestComplete (Automated Testing Tool) Code Collaborator (Peer Code Review Tool) Software Development and QA Templates Test Case Training Pragmatic Agile Development Other Webinars About the Author Steve Miller is the Vice President of ALM Solutions for AutomatedQA. With over 25 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software.
    [Show full text]
  • Significance of Testing Through Testing Tools: Cost Analysis
    e-Περιοδικό Επιστήμης & Τεχνολογίας e-Journal of Science & Technology (e-JST) SIGNIFICANCE OF TESTING THROUGH TESTING TOOLS: COST ANALYSIS Jigna B Prajapati Research scholar , Shri JJT University, Jhunjhunu, Rajasthan. Abstract Software testing is decisive factor for achieving reliability and more correctness in any program, application or in whole system. The system would become more adaptable by proper testing. In this process testing tools play an important role to help the developers. The first objective of this paper is to focus of significance of testing and its categories as per the testing performed by the particular entities. Secondly it represents the different vendors and their associated software testing tools with their key features. It also analyzes testing tools which work differently to check different types of application. Further the cost effectiveness for various testing tools has been shown by different charts. The ten high cost, ten low cost, open source and various free testing tools are shown to focus the effectiveness of cost factor. Keywords : Testing , Testing Tools, Automation, Cost. 1. Introduction Software Testing : It is the route of executing a program, application or system with the purpose of finding errors [1]. This process also involves any activity intended at evaluating competence of a program, application or system and seminal that it meets its required objectivity or not [2]. Software testing is the process of checking whole program, application or system by various way. The prime goal of testing is to find bugs, failure in software but testing is not focus only to the errors occurred at system but also focus the objective derived from the system.
    [Show full text]
  • Software Testing Tools
    SOFTWARETESTINGTOOLS PenttiPohjolainen DepartmentofComputer ScienceandApplied Mathematics UniversityofKuopio March2002 2 CONTENTS 1Introduction ............................................................................................. 5 2References............................................................................................... 10 3DivisionoftheTools .............................................................................. 11 3.1TestDesignTools.........................................................................................................11 3.1.1TestCaseTools ...........................................................................................................11 3.1.2DatabaseTools.............................................................................................................12 3.1.3DataGenerators...........................................................................................................13 3.1.4GeneralTestDesign ...................................................................................................14 3.2GUITestDrivers...........................................................................................................16 3.3LoadandPerformanceTestingTools.................................................................25 3.4TestManagementTools ............................................................................................32 3.4.1CORBA .........................................................................................................................32
    [Show full text]