Testing and Quality Assurance for Component-Based Software for a Listing of Recent Titles in the Artech House Computing Library, Turn to the Back of This Book

Total Page:16

File Type:pdf, Size:1020Kb

Testing and Quality Assurance for Component-Based Software for a Listing of Recent Titles in the Artech House Computing Library, Turn to the Back of This Book Testing and Quality Assurance for Component-Based Software For a listing of recent titles in the Artech House Computing Library, turn to the back of this book. Testing and Quality Assurance for Component-Based Software Jerry Zeyu Gao H.-S. Jacob Tsao Ye Wu Artech House Boston • London www.artechhouse.com Library of Congress Cataloging-in-Publication Data Gao, Jerry. Testing and quality assurance for component-based software / Jerry Zeyu Gao, H. -S. Jacob Tsao, Ye Wu. p. cm. — (Artech House computing library) Includes bibliographical references and index. ISBN 1-58053-480-5 (alk. paper) 1. Computer software—Quality control. 2. Computer software—Testing. I. Tsao, H.-S. J. II. Wu, Ye. III. Title. IV. Artech House computer library. QA76.76.Q35G38 2033 005.1’4—dc22 2003057725 British Library Cataloguing in Publication Data Gao, Jerry. Testing and quality assurance for component-based software. — (Artech House computing library) 1. Component software—Testing 2. Computer software industry—Quality control I. Title II. Tsao, H.-S. J. (H.-S. Jacob) III. Wu, Ye 005.3’0287 ISBN 1-58053-480-5 Cover design by Igor Veldman © 2003 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 The following are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University: Capability Maturity Model and CMM. Testing Maturity ModelSM and TMMSM are service marks of the Illinois Institute of Technology. All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any infor- mation storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capi- talized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 1-58053-480-5 Library of Congress Catalog Card Number: 2003057725 10987654321 To my wife Tracey and my lovely son Kevin To my parents Ming Gao and YeFang Qin —Jerry Zeyu Gao To my mother Shu-Wen Pao, my brother Hsiao-Tzu Tsao, my wife Hueylian, and my children Allison and Jason —H.-S. Jacob Tsao To my wife Wanjie and to my lovely daughter Ya Ya —Ye Wu . Contents Preface ..............................xvii What is this book about? xvii Why has reuse of third-party software components become popular recently? xviii Why is testing software components and component-based software important? xviii Book organization xix Is this book for you? xx Acknowledgments .......................xxi I Introduction ............................1 1 Introduction to software components ..............3 1.1 The evolution of software components 3 1.2 Why is software component reuse important? 5 1.3 What is a software component? 6 1.4 Properties of software components in CBSE 8 1.5 Basic elements of software components 11 1.6 Software modules versus software components in CBSE 13 1.7 An engineering process for software components 17 vii viii Contents 1.8 Questions, concerns, and needs in component validation and quality control 19 1.9 Summary 21 References 22 2 Software component testing ..................25 2.1 Component testing background 26 2.2 Component testing in CBSE 28 2.2.1 Vendor-oriented component testing 29 2.2.2 User-oriented component testing 30 2.3 Issues and challenges of component testing in CBSE 34 2.3.1 Issues and challenges in user-oriented component validation 35 2.3.2 Issues and challenges in vendor-oriented component testing 38 2.4 Component testing myths and other needs 41 2.5 Summary 44 References 44 3 Introduction to component-based software ..........47 3.1 Introduction 47 3.2 Component-based software versus traditional programs 49 3.2.1 Properties of component-based software 49 3.2.2 Component-based software versus traditional programs 53 3.3 Component-based software infrastructure: component model 55 3.4 Engineering process for component-based software 58 3.4.1 Process models for traditional software 58 3.4.2 A process model for component-based software 60 References 65 4 Testing component-based software ..............67 4.1 Introduction 68 4.2 Issues and challenges of testing and maintaining component-based software 69 4.2.1 Why is adequate testing for component-based software necessary? 69 Contents ix 4.2.2 Difficulties in adequate testing and maintenance for component-based software 71 4.3 Testing model for component-based software 75 4.3.1 Interaction model 75 4.3.2 Behavior model 77 4.4 Testing and maintenance methodologies 79 4.5 Enterprise-based test process for component-based software 80 4.6 Summary 81 References 82 5 Testability of software components ..............85 5.1 Basic concepts of software testability 86 5.2 Understanding component testability 90 5.2.1 Component understandability 91 5.2.2 Component observability 91 5.2.3 Component traceability 92 5.2.4 Component controllability 95 5.2.5 Test support capability 96 5.3 Design for testability of software components 98 5.3.1 Understanding of testable software components 98 5.3.2 Methods to increase component testability 100 5.3.3 Current research efforts on building testable components 102 5.4 Verification and evaluation of component testability 105 5.4.1 Static verification approach 107 5.4.2 Statistic verification approach 107 5.5 Software testability measurement 109 5.5.1 What is software testability measurement? 109 5.5.2 How to measure software testability 110 5.6 Summary 113 References 114 II Validation methods for software components ........117 6 Black-box testing methods for software components ....119 6.1 Introduction 119 6.2 Black-box testing foundations 122 x Contents 6.2.1 Component specification 122 6.2.2 Component verification history 123 6.2.3 Component customization 125 6.3 Black box–based testing techniques 126 6.3.1 Random testing 126 6.3.2 Partition testing 127 6.3.3 Boundary value testing 130 6.3.4 Decision tables–based testing 133 6.3.5 Mutation testing 134 6.4 Summary 137 References 138 7 White-box testing methods for software components ...141 7.1 Flow graph notation 142 7.2 Path testing 142 7.2.1 Statement coverage 143 7.2.2 Branch coverage 144 7.2.3 Multiple-condition coverage 144 7.2.4 Path coverage 145 7.2.5 Loop coverage 146 7.3 Data-flow testing 147 7.4 Object-oriented testing 149 7.4.1 Inheritance 149 7.4.2 Polymorphism 150 7.4.3 GUI 151 7.4.4 Binding coverage 151 7.4.5 State-based testing 152 7.5 Issues in testing software components 153 7.6 Conclusion 154 References 154 8 Test automation and tools for software components ....157 8.1 Software test automation 158 8.1.1 Basics of software test automation 160 8.1.2 Software test automation process 164 8.1.3 Different types of test automation tools 166 8.2 Component-oriented software test tools 170 Contents xi 8.2.1 ADLscope: a specification-based test tool for components 170 8.2.2 The Java Compatibility Test Tools and technology compatibility kit 171 8.3 Component test automation in CBSE 174 8.3.1 Systematic management of component testing information 174 8.3.2 Automatic test execution for software components 176 8.3.3 Automatic test generation for co1mponents 179 8.3.4 Systematic performance testing for components 181 8.3.5 Systematic regression testing for software components 183 8.4 Summary 185 References 186 III Validation methods for component-based software ....189 9 Integration testing for component-based software .....191 9.1 Introduction 191 9.1.1 Type I: Intercomponent faults 192 9.1.2 Type II: Interoperability faults 192 9.1.3 Type III: Traditional faults and other faults 193 9.2 Traditional integration-testing methodologies 193 9.2.1 Function decomposition–based integration testing 193 9.2.2 Call graph–based integration testing 195 9.3 A test model for integration testing of component-based software 196 9.3.1 Test elements 197 9.3.2 Component interaction graph 198 9.3.3 Test-adequacy criteria 199 9.4 Black box–based integration-testing approaches 200 9.4.1 Interface nodes 201 9.4.2 Event nodes 201 9.4.3 Context-dependence and content-dependence relationships 202 9.5 UML-based integration-testing approaches 202 9.5.1 Context-dependence relationships 203 9.5.2 Content-dependence relationships 207 9.6 Summary 208 References 209 xii Contents 10 Regression testing for component-based software .....211 10.1 Introduction 212 10.2 Regression testing for corrective-maintenance activities 215 10.2.1 Representing modifications with UML diagrams 216 10.2.2 Regression testing for corrective maintenance 218 10.3 Regression testing for perfective and adaptive maintenance 221 10.3.1 Control similarity evaluation 221 10.3.2 Data dependence similarity evaluation 224 10.4 Summary 225 References 225 11 Performance testing and measurement ...........229 11.1 Basics of software performance testing and measurement 230 11.1.1 Major focuses in software performance testing and evaluation 231 11.1.2 Performance test process 234 11.1.3 Performance testing and evaluation challenges and needs in CBSE 236 11.2 Performance evaluation metrics 238 11.2.1 Utilization metrics 238 11.2.2 Speed-related metrics 239 11.2.3 Availability metrics 240 11.2.4 Reliability metrics 243 11.2.5 Throughput metrics 245 11.2.6 Scalability metrics 246 11.3 Performance evaluation approaches 248 11.3.1 Classification of performance evalution approaches 248 11.3.2 Component-based performance evaluation
Recommended publications
  • Java™ Technology Test Suite Development Guide
    Java™ Technology Test Suite Development Guide 1.2 For Java Compatibility Test Suite Developers Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 U.S.A. 650-960-1300 November 2003 Copyright © 2003 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. THIS SOFTWARE CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF SUN MICROSYSTEMS, INC. USE, DISCLOSURE OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF SUN MICROSYSTEMS, INC. U.S. Government Rights - Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements. Sun, the Sun logo, Sun Microsystems, Java, the Java Coffee Cup logo, JavaTest, Java Community Process, JCP,J2SE, Solaris and Javadoc are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. The Adobe®logo is a registered trademark of Adobe Systems, Incorporated. This distribution may include materials developed by third parties. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. The Adobe® logo is a registered trademark of Adobe Systems, Incorporated. Products covered by and information contained in this service manual are controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries. Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S.
    [Show full text]
  • Software Tools: a Building Block Approach
    SOFTWARE TOOLS: A BUILDING BLOCK APPROACH NBS Special Publication 500-14 U.S. DEPARTMENT OF COMMERCE National Bureau of Standards ] NATIONAL BUREAU OF STANDARDS The National Bureau of Standards^ was established by an act of Congress March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to pro- mote public safety. The Bureau consists of the Institute for Basic Standards, the Institute for Materials Research, the Institute for Applied Technology, the Institute for Computer Sciences and Technology, the Office for Information Programs, and the ! Office of Experimental Technology Incentives Program. THE INSTITUTE FOR BASIC STANDARDS provides the central basis within the United States of a complete and consist- ent system of physical measurement; coordinates that system with measurement systems of other nations; and furnishes essen- tial services leading to accurate and uniform physical measurements throughout the Nation's scientific community, industry, and commerce. The Institute consists of the Office of Measurement Services, and the following center and divisions: Applied Mathematics — Electricity — Mechanics — Heat — Optical Physics — Center for Radiation Research — Lab- oratory Astrophysics^ — Cryogenics^ — Electromagnetics^ — Time and Frequency*. THE INSTITUTE FOR MATERIALS RESEARCH conducts materials research leading to improved methods of measure- ment, standards, and data on the properties of well-characterized materials needed by industry, commerce, educational insti- tutions, and Government; provides advisory and research services to other Government agencies; and develops, produces, and distributes standard reference materials.
    [Show full text]
  • Software Error Analysis Technology
    NIST Special Publication 500-209 Computer Systems Software Error Analysis Technology U.S. DEPARTMENT OF COMMERCE Wendy W. Peng Technology Administration Dolores R. Wallace National Institute of Standards and Technology NAT L INST. OF ST4ND & TECH R I.C. NISI PUBLICATIONS A111D3 TTSTll ^QC ' 100 .U57 //500-209 1993 7he National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in the development of technology . needed to improve product quality, to modernize processes, to reliability . manufacturing ensure product and to facilitate rapid commercialization . , of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's competitiveness; advance science and engineering; and improve public health, safety, and the environment. One of the agency's basic functions is to develop, maintain, and retain custody of the national standards of measurement, and provide the means and methods for comparing standards used in science, engineering, manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal Government. As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and applied research in the physical sciences and engineering and performs related services. The Institute does generic and precompetitive work on new and advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303.
    [Show full text]
  • Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants
    SIMPLIFIED SOFTWARE LIFE-CYCLE DIAGRAM FEASIBILITY STUDY PROJECT TIME I SOFTWARE P FUNCTIONAL I SPECIFICATION! SOFTWARE SYSTEM DESIGN DETAILED MODULES CECIFICATION MODULES DESIGN SOFTWARE INTEGRATION AND TESTING SYSTEM TESTING ••COMMISSIONING I AND HANDOVER | DECOMMISSION DESIGN DESIGN SPECIFICATION VERIFICATION OPERATION AND MAINTENANCE SOFTWARE LIFE-CYCLE PHASES TECHNICAL REPORTS SERIES No. 282 Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants f INTERNATIONAL ATOMIC ENERGY AGENCY, VIENNA, 1988 MANUAL ON QUALITY ASSURANCE FOR COMPUTER SOFTWARE RELATED TO THE SAFETY OF NUCLEAR POWER PLANTS The following States are Members of the International Atomic Energy Agency: AFGHANISTAN GUATEMALA PARAGUAY ALBANIA HAITI PERU ALGERIA HOLY SEE PHILIPPINES ARGENTINA HUNGARY POLAND AUSTRALIA ICELAND PORTUGAL AUSTRIA INDIA QATAR BANGLADESH INDONESIA ROMANIA BELGIUM IRAN, ISLAMIC REPUBLIC OF SAUDI ARABIA BOLIVIA IRAQ SENEGAL BRAZIL IRELAND SIERRA LEONE BULGARIA ISRAEL SINGAPORE BURMA ITALY SOUTH AFRICA BYELORUSSIAN SOVIET JAMAICA SPAIN SOCIALIST REPUBLIC JAPAN SRI LANKA CAMEROON JORDAN SUDAN CANADA KENYA SWEDEN CHILE KOREA, REPUBLIC OF SWITZERLAND CHINA KUWAIT SYRIAN ARAB REPUBLIC COLOMBIA LEBANON THAILAND COSTA RICA LIBERIA TUNISIA COTE D'lVOIRE LIBYAN ARAB JAMAHIRIYA TURKEY CUBA LIECHTENSTEIN UGANDA CYPRUS LUXEMBOURG UKRAINIAN SOVIET SOCIALIST CZECHOSLOVAKIA MADAGASCAR REPUBLIC DEMOCRATIC KAMPUCHEA MALAYSIA UNION OF SOVIET SOCIALIST DEMOCRATIC PEOPLE'S MALI REPUBLICS REPUBLIC OF KOREA MAURITIUS UNITED ARAB
    [Show full text]
  • Efficient Dependency Detection for Safe Java Test Acceleration
    Efficient Dependency Detection for Safe Java Test Acceleration Jonathan Bell, Gail Kaiser Eric Melski, Mohan Dattatreya Columbia University Electric Cloud, Inc 500 West 120th St 35 S Market Street New York, NY USA San Jose, CA USA {jbell,kaiser}@cs.columbia.edu {ericm,mohan}@electric-cloud.com ABSTRACT Our study of popular open source Java programs echoes Slow builds remain a plague for software developers. The fre- these results, finding projects that take hours to build, with quency with which code can be built (compiled, tested and most of that time spent testing. Even in cases of projects packaged) directly impacts the productivity of developers: that build in a more manageable amount of time | for ex- longer build times mean a longer wait before determining if ample, five to ten minutes | faster builds can result in a a change to the application being built was successful. We significant increase in productivity due to less lag-time for have discovered that in the case of some languages, such as test results. Java, the majority of build time is spent running tests, where To make testing faster, developers may turn to techniques dependencies between individual tests are complicated to such as Test Suite Minimization (which reduce the size of discover, making many existing test acceleration techniques a test suite, for instance by removing tests that duplicate unsound to deploy in practice. Without knowledge of which others) [11, 12,23,24,27,28,37,39], Test Suite Prioritization tests are dependent on others, we cannot safely parallelize (which reorders tests to run those most relevant to recent the execution of the tests, nor can we perform incremen- changes first) [14, 15, 35, 36, 38], or Test Selection [17, 25, 32] tal testing (i.e., execute only a subset of an application's (which selects tests to execute that are impacted by recent tests for each build).
    [Show full text]
  • Software Quality Assurance Activities in Software Testing
    Software Quality Assurance Activities In Software Testing Tony never synopsizing any recidivist gazetting thus, is Brooke oncogenic and insolvable enough? Monogenous Chadd externalises, his disciplinarians denudes spring-clean Germanically. Spindliest Antoni never humors so edgewise or attain any shells lyingly. Each module performs one or two tasks, and thenpasses control to another module. Perform test automation for web application using Cucumber. Identify and describe safety software procurement methods, including supplier evaluation and source inspection processes. He previously worked at IBM SWS Toronto Lab. The information maintained in status accounting should enable the rebuild of any previous baseline. Beta Breakers supports all industry sectors. Thank you save time for all the lack of that includes test software assurance and must often. Focus on demonstrating pos next column containing algorithms, activities in software quality assurance testing activities of testing programs for their findings from his piece of skills, validate features to refresh teh page object. XML data sets to simulate production, using LLdap and ALTOVA. Schedule information should be expressed as absolute dates, as dates relative to either SCM or project milestones, or as a simple sequence of events. Its scope of software quality assurance and the correct email list all testshave been completely correct, in software quality assurance activities to be precisely known about its process on a familiarity level. These exercises are performed at every step along the way in the workshop. However, you have to balance driving out quality with production value. The second step is the validation of the computer system implementation against the computer system requirements. Software development tools, whose output becomes part of the program implementation and which can therefore introduce errors.
    [Show full text]
  • Software Quality Assurance Report
    Software Quality Assurance Report Elmore demobilizing onerously if halftone Filmore reboils or discounts. Murmurous and second-rate Steve roams routedher astrodynamics when gazetted grumbled some yelpdry orvery inditing evilly literally,and centesimally? is Fonzie well-entered? Is Tymothy always volatilisable and Defined by the importance of these terminologies so with a number of the continuous integration testing and the software engineering institute, no significant technical objectives of software quality assurance report The report and. The staff members need to be reported to notifications, such as well as both dynamic. Test Report fatigue a document which contains a conjunction of all test activities and final test results of a testing project Test report is an assessment of how adverse the Testing is performed Based on the test report stakeholders can evaluate current quality feel the tested product and persuade a decision on paid software release. Measuring and reporting mechanisms SQA Activities Software quality assurance is composed of a conduct of functions associated with just different constituencies. Senior software Quality Assurance Engineer Arizona City. It is not understand and federal regulations. Sqa effort in the product quality assurance enterprise network environments. This vessel will be cozy for professionals not head in software testing but inland from other areas project managers product owners developers etc Article Content. An established standards are extrinsic factors, they must define a software for soil science. Document or the product for the data are not. Quality Assurance is defined as the auditing and reporting procedures used to. Cost coverage customer record such as receiving the defect report and troubleshooting.
    [Show full text]
  • Software Quality Assurance and Quality Management
    12. Software Quality Assurance and Quality Management Abdus Sattar Assistant Professor Department of Computer Science and Engineering Daffodil International University Email: [email protected] Discussion Topics Software Quality Assurance What are SQA, SQP, SQC, and SQM? Elements of Software Quality Assurance SQA Tasks, Goals, And Metrics Quality Management and Software Development QA Vs QC Reviews and Inspections An Inspection Checklist Software Quality Assurance Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering processes. It ensures that developed software meets and complies with the defined or standardized quality specifications. SQA is an ongoing process within the Software Development Life Cycle (SDLC) that routinely checks the developed software to ensure it meets the desired quality measures. The implication for software is that many different constituencies he implication for software is that many different constituencies What are SQA, SQP, SQC, and SQM? Software Quality Assurance – establishment of network of organizational procedures and standards leading to high-quality software Software Quality Planning – selection of appropriate procedures and standards from this framework and adaptation of these to specific software project Software Quality Control – definition and enactment of processes that ensure that project quality procedures and standards are being followed by the software development team Software Quality Metrics – collecting and analyzing quality data to predict and control quality of the software product being developed Elements of Software Quality Assurance . Standards. The IEEE, ISO, and other standards organizations have produced a broad array of software engineering standards and related documents. Reviews and audits. Technical reviews are a quality control activity performed by software engineers for software engineers.
    [Show full text]
  • Software Quality Management for Improving Quality of Software Product
    Journal of Network Communications and Emerging Technologies (JNCET) www.jncet.org Volume 8, Issue 5, May (2018) Software Quality Management for Improving Quality of Software Product Shubham Srivastava 1, Prabha singh 2, Chayanika Srivastava 3 1, 2, 3 Department of Computer Science and Engineering, ITM, GIDA, Gorakhpur (India) Abstract – Software quality management (SQM) is a process that ensures that developed software meets and complies with defined or standardized quality specifications. SQM is an ongoing process within the software development life cycle (SDLC) that routinely checks the developed software to ensure it meets desired quality measures. In this article, it is highlighted that how to combine software quality management life cycle with software development life cycle to generate better quality and outcomes. This article takes a different approach by examining how software quality management practices can impact project outcomes. Software quality management (SQM) plays a critical role in the software development lifecycle (SDLC) and can impact a project’s overall success. Index Terms – SQM, SQA, SQP, SQC and SDLC. 1. INTRODUCTION Today’s scenario, it is really difficult to implement successful IT projects which is a critical strategic method for entire Fig:-1 SQM ACTIVITIES industrial sectors. This is even more important in times of scarce resources needed for other competing strategic 2. PROJECT MANAGEMENT FAILURES initiatives important to a firm. A lot of software projects still Some Basic Reasons for Failure:- fail to deliver on time and within target costs and other necessary specifications. Software quality management (SQM) Planning: Insufficient planning is a management process the goal of which is to develop and manage the quality of a software to make sure the product Scope: Poorly defined and requirement and scope satisfies the user.
    [Show full text]
  • Corner Cases and Possible Improvements of Automated Testing
    MASARYK UNIVERSITY FACULTY OF INFORMATICS Corner cases and possible improvements of automated testing MASTER'S THESIS Petra Mikova Brno, Spring 2020 MASARYK UNIVERSITY FACULTY OF INFORMATICS Corner cases and possible improvements of automated testing MASTER'S THESIS Petra Mikova Brno, Spring 2020 This is where a copy of the official signed thesis assignment and a copy of the Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Petra Mikova Advisor: RNDr. Adam Rambousek, Ph.D. i Acknowledgements I would like to thank my advisors Mgr. Jiri Vanek and RNDr. Adam Rambousek, Ph.D. for their help, valuable advice and support, and the members of OpenJDK QE team in Red Hat for their expertise and input. ii Abstract The aim of this thesis is analysis of current state of OpenJDK QE in Red Hat, identification of biggest issues and their resolution. That is achieved both by outlining new and reusing existing tools and software. Most of the problematic corner cases mentioned in this thesis are not product specific, making the solutions applicable for other QE teams. The last part of the thesis is dedicated to improving automated results processing and reporting. iii Keywords OpenJDK, Jenkins, quality engineering, test automation, Java iv Contents Introduction 1
    [Show full text]
  • Javatest Harness Architect’S Guide, Javatest Harness 4.4.1 for the Java Platform E20663-02
    JavaTest Harness Architect’s Guide, JavaTest Harness 4.4.1 for the Java Platform E20663-02 December 2012 This Architect’s Guide is intended for those who design JavaTest harness test suites. You should be familiar with the JavaTest harness. JavaTest Architect's Guide, JavaTest Harness 4.4.1 for the Java Platform E20663-02 Copyright © 2002, 2011, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).
    [Show full text]
  • Java™ Technology Compatibility Kit User's Guide Template
    Java™ Technology Compatibility Kit User’s Guide Template For Technology Licensees Release [VersionNumber] Sun Microsystems, Inc. 4150 Network Circle Santa Clara, California 95054 U.S.A. 1-800-555-9SUN or 1-650-960-1300 May, 2003 Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 U.S.A. 1-800-555-9SUN or 1-650-960-1300 Sun Microsystems, Inc. 4150 Network Circle Santa Clara, California 95054 U.S.A. 1-800-555-9SUN or 1-650-960-1300 <NOTE this copyright page states Sun’s copyrights regarding this TCK User’s Guide Template. It is not intended for use as a template or model for TCK User’s Guide copyright statements.> COPYRIGHT © 2003 SUN MICROSYSTEMS, INC. ALL RIGHTS RESERVED. SUN MICROSYSTEMS, INC. HEREBY GRANTS A NON-EXCLUSIVE, NON-TRANSFERABLE, WORLDWIDE LICENSE TO JAVA COMMUNITY PROCESS (JCP) MEMBERS TO USE, REPRODUCE, AND CREATE DERIVATIVE WORKS FROM THIS DOCUMENT, SOLELY FOR THE PURPOSE OF CREATING THEIR OWN JAVA TECHNOLOGY COMPATIBILITY KIT USER GUIDES, AND TO DISTRIBUTE, PUBLICLY PERFORM, OR PUBLICLY DISPLAY SUCH USER GUIDES, IN WHOLE OR IN PART, AND IN ANY MEDIA OR FORMAT. LICENSEE AGREES THAT IT MAY NOT MODIFY OR CLAIM ANY LEGAL RIGHTS IN ANY SUN TRADEMARK OR LOGO. LICENSEE MAY NOT USE ANY SUN TRADEMARK OR LOGO EXCEPT IN CONFORMANCE WITH SUN’S TRADEMARK AND LOGO USAGE REQUIREMENTS (WWW.SUN.COM/POLICIES/TRADEMARKS/). THIS LICENSE IS SUBJECT TO AND CONDITIONED UPON LICENSEE’S COMPLIANCE WITH THE TERMS AND CONDITIONS OF THIS LICENSE, AND LICENSEE’S RETENTION, ON ALL REDISTRIBUTIONS, IN WHOLE OR IN PART, OF THE ABOVE COPYRIGHT NOTICE, THIS PERMISSION NOTICE, AND ALL DISCLAIMERS.
    [Show full text]