DOCSLIB.ORG

Fuzzing Radio Resource Control Messages in 5G and LTE Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fuzzing Radio Resource Control Messages in 5G and LTE Systems DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2021 Fuzzing Radio Resource Control messages in 5G and LTE systems To test telecommunication systems with ASN.1 grammar rules based adaptive fuzzer SRINATH POTNURU KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Fuzzing Radio Resource Control messages in 5G and LTE systems To test telecommunication systems with ASN.1 grammar rules based adaptive fuzzer SRINATH POTNURU Master’s in Computer Science and Engineering with specialization in ICT Innovation, 120 credits Date: February 15, 2021 Host Supervisor: Prajwol Kumar Nakarmi KTH Supervisor: Ezzeldin Zaki Examiner: György Dán School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Fuzzing Radio Resource Control-meddelanden i 5G- och LTE-system Fuzzing Radio Resource Control messages in 5G and LTE systems / Fuzzing Radio Resource Control-meddelanden i 5G- och LTE-system © 2021 Srinath Potnuru iii Abstract 5G telecommunication systems must be ultra-reliable to meet the needs of the next evolution in communication. The systems deployed must be thoroughly tested and must conform to their standards. Software and network protocols are commonly tested with techniques like fuzzing, penetration testing, code review, conformance testing. With fuzzing, testers can send crafted inputs to monitor the System Under Test (SUT) for a response. 3GPP, the standardiza- tion body for the telecom system, produces new versions of specifications as part of continuously evolving features and enhancements. This leads to many versions of specifications for a network protocol like Radio Resource Control (RRC), and testers need to constantly update the testing tools and the testing environment. In this work, it is shown that by using the generic nature of RRC specifications, which are given in Abstract Syntax Notation One (ASN.1) de- scription language, one can design a testing tool to adapt to all versions of 3GPP specifications. This thesis work introduces an ASN.1 based adaptive fuzzer that can be used for testing RRC and other network protocols based on ASN.1 description language. The fuzzer extracts knowledge about ongoing RRC messages using protocol description files of RRC, i.e., RRC ASN.1 schema from 3GPP, and uses the knowledge to fuzz RRC messages. The adaptive fuzzer identifies indi- vidual fields, sub-messages, and custom data types according to specifications when mutating the content of existing messages. Furthermore, the adaptive fuzzer has identified a previously unidentified vulnerability in Evolved Packet Core (EPC) of srsLTE and openLTE, two open-source LTE implementations, confirming the applicability to robustness testing of RRC and other network protocols. Keywords: RRC, 5G NR, robustness testing, fuzzing, ASN.1, network pro- tocol testing, vulnerability detection, software security iv Sammanfattning 5G-telekommunikationssystem måste vara extremt tillförlitliga för att möta be- hoven för den kommande utvecklingen inom kommunikation. Systemen som används måste testas noggrant och måste överensstämma med deras standar- der. Programvara och nätverksprotokoll testas ofta med tekniker som fuzzing, penetrationstest, kodgranskning, testning av överensstämmelse. Med fuzzing kan testare skicka utformade input för att övervaka System Under Test (SUT) för ett svar. 3GPP, standardiseringsorganet för telekomsystemet, producerar ofta nya versioner av specifikationer för att möta kraven och bristerna från tidigare utgåvor. Detta leder till många versioner av specifikationer för ett nät- verksprotokoll som Radio Resource Control (RRC) och testare behöver stän- digt uppdatera testverktygen och testmiljön. I detta arbete visar vi att genom att använda den generiska karaktären av RRC-specifikationer, som ges i be- skrivningsspråket Abstract Syntax Notation One (ASN.1), kan man designa ett testverktyg för att anpassa sig till alla versioner av 3GPP-specifikationer. Detta uppsatsarbete introducerar en ASN.1-baserad adaptiv fuzzer som kan användas för att testa RRC och andra nätverksprotokoll baserat på ASN.1- beskrivningsspråk. Fuzzer extraherar kunskap om pågående RRC meddelan- den med användning av protokollbeskrivningsfiler för RRC, dvs RRC ASN.1 schema från 3GPP, och använder kunskapen för att fuzz RRC meddelanden. Den adaptiva fuzzer identifierar enskilda fält, delmeddelanden och anpassade datatyper enligt specifikationer när innehållet i befintliga meddelanden mu- teras. Dessutom har den adaptiva fuzzer identifierat en tidigare oidentifierad sårbarhet i Evolved Packet Core (EPC) för srsLTE och openLTE, två open- source LTE-implementeringar, vilket bekräftar tillämpligheten för robusthets- provning av RRC och andra nätverksprotokoll. Nyckelord: RRC, 5G NR, robusthetstest, fuzzing, ASN.1, nätverksproto- kolltestning, sårbarhetsdetektering, mjukvarusäkerhet Acknowledgments v Acknowledgments I am grateful for the opportunity provided by the host company Ericsson AB, my manager Hans Eriksson, and my supervisor Prajwol Kumar Nakarmi for trusting me to carry out this project. The guidance and support provided by Prajwol helped me identify many challenges and solutions along the way. His immense knowledge in security and radio access solutions made it easy for me to carry out the thesis work. I would also like to thank my KTH supervisor Ezzeldin Zaki and my exam- iner Dr. György Dán who helped me frame the research question and provided valuable inputs throughout my thesis. I thank all the open-source communi- ties and forums which gave enough support for many of my questions. Lastly, I would like to extend my gratitude towards my closest friends and family who stood by me throughout the period of this thesis. Stockholm, February 2021 Srinath Potnuru Contents List of Figures . .x List of Tables . xi List of Acronyms and Abbreviations . xvi 1 Introduction 1 1.1 Background . .1 1.2 Problem description . .3 1.3 Contribution . .4 1.4 Goals . .4 1.5 Ethical and Sustainability Aspects . .4 1.6 Method . .5 1.7 Stakeholders . .5 1.8 Delimitations . .6 1.9 Outline . .6 2 Background 7 2.1 Introduction to 5G . .7 2.1.1 5G Architecture . .9 2.2 5G New Radio . 10 2.3 Radio Resource Control (RRC) . 16 2.3.1 RRC State Machine . 17 2.3.2 Messages in RRC . 18 2.4 ASN.1 . 19 2.5 Fuzzing . 21 2.6 Related Work . 23 2.7 RRC and Fuzzing . 25 2.8 Similarities between 5G and LTE . 26 2.9 Summary . 28 vii viii CONTENTS 3 Design and Methodology 29 3.1 Design Requirements . 29 3.2 The adaptive fuzzer . 29 3.2.1 Fuzzer . 31 3.2.2 Observer . 32 3.3 Summary . 33 4 Implementation 34 4.1 Fuzzer . 34 4.1.1 Fuzzing Strategies . 36 4.2 Observer . 40 4.3 Summary . 43 5 Evaluation 44 5.1 Evaluation tools . 44 5.2 Integrating adaptive fuzzer with srsLTE . 45 5.3 Identifying testing strategies . 46 5.4 Collecting Results . 48 5.5 Filtering out false positives . 51 5.6 Summary . 52 6 Results and Analysis 53 6.1 Results . 53 6.2 Crash in EPC . 56 6.3 Impact on performance of srsLTE due to fuzzing . 57 6.4 Summary . 58 7 Conclusions and Future Work 59 7.1 Conclusions . 59 7.2 Future Work . 60 References 62 List of Figures 1.1 Minimalistic view of 5G system. .2 2.1 Use case categorization triangle in 5G by ITU-T. .8 2.2 Overview of 5G communication system. .9 2.3 Service Based Architecture with different network functions in 5G system. 10 2.4 Networking layers involved in 5G control plane messages. 11 2.5 Networking layers involved in 5G user plane messages. 12 2.6 Mapping between logical, transport and physical channels in the downlink [19]. 13 2.7 Mapping between logical, transport and physical channels in the uplink [19]. 14 2.8 RRC State Machine in 5G NR [25]. 17 2.9 ASN.1 language structure for RRCConnectionRequest in EU- TRA TS 36.331 v15.4. 19 2.10 Example tree fashion ASN.1 structure of an RRC Message. 20 2.11 General fuzzing framework. 22 2.12 Networking layers involved in 5G and LTE control plane mes- sages. 26 2.13 srsLTE nodes no RF front-end. 28 3.1 Adaptive fuzzing framework for an ASN.1 based network pro- tocol. 30 3.2 RRC State Machine in EUTRA [49]. 33 4.1 Components of the mutation based adaptive fuzzer. 36 4.2 ASN.1 description of DedicatedInfoNAS in 3GPP TS [49]. 36 4.3 Wireshark packet capture of UECapabilityInformation gener- ated by srsUE (UE implementation in srsLTE). 39 ix x LIST OF FIGURES 4.4 Wireshark packet capture of UECapabilityInformation with fuzz_append_string set to true.................. 40 5.1 Integrating the adaptive fuzzer with srsLTE. 46 5.2 RRC messages sent between UE and network during initial activation in 5G and LTE system. 47 5.3 Automated toolchain for continuous testing (dashed lines in- dicate fuzzing during initial AS activation). 50 5.4 Flowchart for replaying RRC messages to verify a TRUE crash (dashed lines indicate fuzzing in initial AS activation). 51 6.1 Boxplot distribution of measured latency for 44,383 fuzzed uplink RRC messages. 57 List of Tables 2.1 Names and Abbreviations of Physical Channels in 5G NR [18] 13 2.2 Names and Abbreviations of Transport Channels in 5G NR [18] 15 2.3 Names and Abbreviations of Logical Channels in 5G NR [18] 15 5.1 Different fuzzing strategies identified for RRC messages in srsLTE . 49 6.1 Number of RRC messages from srsLTE fuzzed by the adaptive fuzzer and the range of seed values used . 56 xi xii List of Acronyms and Abbreviations List of Acronyms and Abbreviations 3G Third Generation Telecommunication System 3GPP 3rd Generation Partnership Project 5G Fifth Generation Telecommunication System 5G NR Fifth
Load more

Recommended publications
  • Core Elements of Continuous Testing
    WHITE PAPER CORE ELEMENTS OF CONTINUOUS TESTING Today’s modern development disciplines -- whether Agile, Continuous Integration (CI) or Continuous Delivery (CD) -- have completely transformed how teams develop and deliver applications. Companies that need to compete in today’s fast-paced digital economy must also transform how they test. Successful teams know the secret sauce to delivering high quality digital experiences fast is continuous testing. This paper will define continuous testing, explain what it is, why it’s important, and the core elements and tactical changes development and QA teams need to make in order to succeed at this emerging practice. TABLE OF CONTENTS 3 What is Continuous Testing? 6 Tactical Engineering Considerations 3 Why Continuous Testing? 7 Benefits of Continuous Testing 4 Core Elements of Continuous Testing WHAT IS CONTINUOUS TESTING? Continuous testing is the practice of executing automated tests throughout the software development cycle. It’s more than just automated testing; it’s applying the right level of automation at each stage in the development process. Unlike legacy testing methods that occur at the end of the development cycle, continuous testing occurs at multiple stages, including development, integration, pre-release, and in production. Continuous testing ensures that bugs are caught and fixed far earlier in the development process, improving overall quality while saving significant time and money. WHY CONTINUOUS TESTING? Continuous testing is a critical requirement for organizations that are shifting left towards CI or CD, both modern development practices that ensure faster time to market. When automated testing is coupled with a CI server, tests can instantly be kicked off with every build, and alerts with passing or failing test results can be delivered directly to the development team in real time.
    [Show full text]
  • Small Data Transmission (SDT): Protocol Aspects
    Small Data Transmission (SDT): Protocol Aspects Taehun Kim Ofinno • ofinno.com • May 2021 Small Data Transmission (SDT): Protocol Aspects Signals for transitioning to a radio resource control • a radio resource control (RRC) connection (RRC) connected state and maintaining the RRC establishment procedure to establish an RRC connected state could cause overheads (e.g., power connection [3][4]; and consumption and delay) to a wireless device having • an initial access stratum (AS) security activation small amount of data to transmit when in an RRC idle procedure for secured data transmission [3][4]. state or an RRC inactive state. When the procedures is successfully completed, the 3rd Generation Partnership Project (3GPP) has wireless device in an RRC connected state transmits introduced technologies to reduce the overheads. the UL data. After the transmission of the UL data, This article gives a brief introduction of the the wireless device stays in the RRC connected technologies and investigates a protocol aspects of state until receiving an RRC release message from the technologies. a base station. While staying in the RRC connected state, the wireless device should perform additional 1. Introduction procedures (e.g., radio link monitoring (RLM), Before technologies to reduce overheads for small measurement & measurement reporting, etc.). The data transmission (SDT) is introduced for long-term wireless device transitions back to the RRC idle state evolution (LTE) or new radio (NR), uplink (UL) data when receiving an RRC release message from the generated in an RRC idle state can be transmitted base station. only after transitioning to an RRC connected state according to 3GPP specifications.
    [Show full text]
  • Drive Continuous Delivery with Continuous Testing
    I Don’t Believe Your Company Is Agile! Alex Martins CTO Continuous Testing CA Technologies October 2017 1 Why Many Companies Think They’re Agile… They moved some Dev projects from waterfall to agile They’re having daily standups They have a scrum master Product owner is part of the team They are all talking and walking agile… And are talking about Continuous Delivery BUT… QA is STILL a Bottleneck… Even in DevOps Shops A 2017 survey of self- …of delays were occurring at proclaimed DevOps 63% the Test/QA stage of the practitioners found that … cycle. “Where are the main hold-ups in the software production process?” 63% 32% 30% 16% 22% 21% 23% http://www.computing.co.uk/digital_assets/634fe325-aa28-41d5-8676-855b06567fe2/CTG-DevOps-Review-2017.pdf 3 Challenges to Achieving Continuous Delivery & Testing IDEA Requirements 64% of total defect cost originate in the requirements analysis and design phase1. ? ? of developers time is spent 80% of teams experience delays in development and QA Development 50% 3 finding and fixing defects2 due to unavailable dependencies X X Security 70x required manual pen 30% of teams only security scan 50% more time spent on security test scan cost vs. automation10 once per year9 defects in lower-performing teams8 X X X 70% of all 63% of testers admit they 50% of time 79% of teams face prohibitive QA / Testing testing is still can’t test across all the different spent looking for restrictions, time limits or access manual4 devices and OS versions5 test data6 fees on needed 3rd party services3 ! Release 57% are dissatisfied with the time it takes to deploy new features7 ! ! Ave.
    [Show full text]
  • Your Continuous Testing with Spirent's Automation Platforms
    STREAMLINE Your Continuous Testing With Spirent’s Automation Platforms DE RELE VE AS LO E P E T A ING T R G ES E T T S N U I O U IN T N E CO STAG Table of Contents Agile 3 What is Continuous Test (CT)? 4 What Hinders CT Implementation? 5 The Chasm 6 The Bridge 7 Spirent Velocity Framework 8 Lab as a Service (LaaS) 9 Test as a Service (TaaS) 10 CT Implementation Best Practices 11 Summary 12 2 of 12 Agile software development practices gained momentum in the late 90s. Agile emphasizes close collaboration between business stakeholders, the development team, and QA. This enabled faster software delivery, better quality and improved customer satisfaction. By employing DevOps practices, the pace and benefits are amplified. 3 of 12 What is Continuous Test (CT)? Continuous Test (CT) enables CT haed Cotuous terato ad Deery ee network testing to be more effectively performed by DEVELOP ITEATE STAGE ELEASE development teams by enabling them to take advantage of the QA team’s knowledge of real world customer use cases and environments. This is known as “shift left” because testing is moved earlier in the development cycle. With “shift left” tests are run as early as possible to accelerate understanding of AUTOMATE TESTS ORCHESTRATE TEST ENVIRONMENTSEXECUTE TESTS EARLIER problem areas in the code and where development attention is required. Why Do You Need CT? The combination of earlier and faster testing shortens time to release while improving quality and customer satisfaction. 4 of 12 What Hinders CT Implementation? Deficient or non existent Insufficient test Lack of test results Inadequate understanding of tools for creating resources for timely analysis tools hinder customer environments and automated tests test execution assessment of test results use cases by developers EW SOFTWAE DEVELOP ITEATE STAGE ELEASE SOFTWAE BILD ELEASE The promise of DevOps can’t be fully realized until Continuous Testing (CT) is factored in.
    [Show full text]
  • IEC 61850: Role of Conformance Testing in Successful Integration
    1 IEC 61850: Role of Conformance Testing in Successful Integration Eric A. Udren, KEMA T&D Consulting Dave Dolezilek, Schweitzer Engineering Laboratories, Inc. Abstract—The IEC 61850 Standard, Communications Net- a single standard solution for communications integration hav- works and Systems in Substations, provides an internationally ing high-level capabilities not available from protocols in prior recognized method of local and wide area data communications use. The most important technical objectives were: for substation and system-wide protective relaying, integration, control, monitoring, metering, and testing. It has built-in capabil- 1. Use self-description and object modeling technol- ity for high-speed control and data sharing over the communica- ogy to simplify the integration and configuration tions network, eliminating most dedicated control wiring as well process for the user. as dedicated communications channels among substations. IEC 2. Dramatically increase the functional capabilities, 61850 facilitates systems built from multiple vendors’ IEDs. Many vendors have supported the standard throughout its crea- sophistication and complexity of the integration to tion, and they are developing products to handle all the needed meet users’ ultimate relaying, control, and enterprise functions. data integration needs. This paper is the third in a series on the evolution of IEC 3. Incorporate robust, very high-speed control commu- 61850. It focuses on the purpose and value of conformance test- nications messaging that can operate among relays ing and certification. IEC 61850 is aimed at making it easy for and other IEDs to eliminate panel wiring and con- utilities to install and integrate single-vendor or multivendor trols. control and protection systems in substations and to integrate existing communications.
    [Show full text]
  • An Overview of 5G System Accessibility Differentiation and Control
    1 An Overview of 5G System Accessibility Differentiation and Control Jingya Li, Demia Della Penda, Henrik Sahlin, Paul Schliwa-Bertling, Mats Folke, Magnus Stattin Ericsson Contact: [email protected]; [email protected] component to provide the desired accessibility prioritization for Abstract—5G system is characterized by its capability to different types of devices, users and services, when supporting support a wide range of use cases and services. Supporting multiple verticals in a shared 5G Stand Alone (SA) network, as accessibility differentiation becomes therefore essential to illustrated in Figure 1. preserve a stable network condition during high traffic load, while This article provides first an overview of the motivations for ensuring connection and service quality to prioritized devices and accessibility differentiation in 5G system. Then, it describes the services. In this article, we describe some use cases and requirements that impact the 3GPP design of the 5G accessibility mechanisms introduced by 3GPP to maintain the service quality differentiation framework. We then provide an overview of the of ongoing high priority communications during high load supported mechanisms for accessibility differentiation and control situations, while assuring that incoming prioritized connection in 5G Stand Alone (SA) system, including cell barring and requests receive the desired access treatment. To the best of our reservation, unified access control, paging control, random access knowledge, this is the first article presenting a comprehensive control and admission control. We discuss how these summary of main use cases and technology opportunities for functionalities can be used to maintain the service quality and accessibility differentiation and control in 5G networks.
    [Show full text]
  • TS 5G.300 V1.1 (2016-06) Technical Specification
    TS 5G.300 v1.1 (2016-06) Technical Specification KT PyeongChang 5G Special Interest Group (KT 5G-SIG); KT 5th Generation Radio Access; Overall Description; (Release 1) Ericsson, Intel Corp., Nokia, Qualcomm Technologies Inc., Samsung Electronics & KT Disclaimer: This document provides information related to 5G technology. All information provided herein is subject to change without notice. The members of the KT PyeongChang 5G Special Interest Group (“KT 5G- SIG”) disclaim and make no guaranty or warranty, express or implied, as to the accuracy or completeness of any information contained or referenced herein. THE KT 5G-SIG AND ITS MEMBERS DISCLAIM ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE, AND ALL INFORMATION IS PROVIDED ON AN “AS-IS” BASIS. No licenses under any intellectual property of any kind are provided by any person (whether a member of the KT 5G-SIG or not) that may be necessary to access or utilize any of the information contained herein, including, but not limited to, any source materials referenced herein, and any patents required to implement or develop any technology described herein. It shall be the responsibility of anyone attempting to use the information contained or referenced herein to obtain any such licenses, if necessary. The KT 5G-SIG and its members disclaim liability for any damages or losses of any nature whatsoever whether direct, indirect, incidental, special or consequential resulting from the use of or reliance on any information contained or referenced herein. © 2016 KT corp. All rights reserved 2 TS 5G.300 v1.1 (2016-06) Document History Version Date Change 0.1 2016-02-17 First Draft Version 1.1 2016-07-13 Final Version 1.2 2016-08-31 Correction in Appendix A4 KT 5G-SIG 3 TS 5G.300 v1.1 (2016-06) Contents Foreword............................................................................................................................................................
    [Show full text]
  • Continuous Testing Report 2019
    Continuous Testing Report In association with 2 Continuous Testing Report Contents Introduction 4 Executive summary 6 Current trends in continuous testing Test design 9 Functional and performance testing 13 Test data management 17 Test environment management 21 Test orchestration in the agile enterprise 24 Continuous testing: the road ahead 27 About the study 31 About the sponsors 37 3 Introduction Welcome dear readers. dependency on IT solutions today, with the integration of front-office and consumer-facing apps with back- Quality and testing approaches, methods, and office core systems, the leveraging of cloud and expertise have undergone radical changes over the microservices and the integration and use of IoT. And, last few years. Every organization today aspires on top of that, AI is emerging to make these solutions to deliver faster and more valuable IT solutions to autonomous and self learning. business and customers. To do this, they have been leveraging agile and DevOps methodologies and All this technology is delivered by different teams, using smarter automation technologies and as-a- many of which may not even be part of a single Service solutions to deliver IT faster and with greater company. flexibility. As we scramble to deliver innovative solutions for the At the same time, the IT landscape has also been newer, more complex IT landscape, there is, of course, growing in complexity. There is an increased a risk of failure. While some failures are inevitable and often provide a valuable learning opportunity (given a quick feedback loop), there are others that we must prevent from happening. Failures in core systems that seriously disrupt the business operations of an enterprise, failures that seriously impact a large number of clients and therefore jeopardize an organization’s reliability and brand perception, or failures in systems that cannot easily be rolled back all demand good testing of these systems before being deployed.
    [Show full text]
  • Construction Quality Assurance Plan Craighead County Solid
    CONSTRUCTION QUALITY ASSURANCE PLAN CRAIGHEAD COUNTY SOLID WASTE DISPOSAL AUTHORITY LEGACY CLASS 1 LANDFILL AFIN: 16-00199 ADEQ PERMIT NO. 0254-S1-R3 PREPARED FOR: Craighead County Solid Waste Disposal Authority 328 CR 476 PO Box 16777 Jonesboro, AR 72403-6712 (870) 972-6353 PREPARED BY: Terracon Consultants, Inc. 25809 Interstate 30 South Bryant, Arkansas 72022 (501) 847-9292 NOVEMBER 2008 CCSWDA Legacy Landfill Construction Quality Assurance Plan November 2008 TABLE OF CONTENTS SECTION 1 ..................................................................................................................................................................1 GENERAL ....................................................................................................................................................................1 1.0 INTRODUCTION .............................................................................................................................................1 2.0 DEFINITIONS RELATED TO CQA ................................................................................................................2 2.1 Construction Quality Assurance and Construction Quality Control ...........................................................2 2.2 Use of the Terms in This Plan ......................................................................................................................2 3.0 CQA AND CQC PARTIES .................................................................................................................................3
    [Show full text]
  • Continuous Quality and Testing to Accelerate Application Development
    Continuous Quality and Testing to Accelerate Application Development How to assess your current testing maturity level and practice continuous testing for DevOps Continuous Quality and Testing to Accelerate Application Development // 1 Table of Contents 03 Introduction 04 Why Is Continuous Quality and Testing Maturity Important to DevOps? 05 Continuous Testing Engineers Quality into DevOps 07 Best Practices for Well- Engineered Continuous Testing 08 Continuous Testing Maturity Levels Level 1: Chaos Level 2: Continuous Integration Level 3: Continuous Flow Level 4: Continuous Feedback Level 5: Continuous Improvement 12 Continuous Testing Maturity Assessment 13 How to Get Started with DevOps Testing? 14 Continuous Testing in the Cloud Choosing the right tools for Continuous Testing On-demand Development and Testing Environments with Infrastructure as Code The Right Tests at the Right Time 20 Get Started 20 Conclusion 21 About AWS Marketplace and DevOps Institute 21 Contributors Introduction A successful DevOps implementation reduces the bottlenecks related to testing. These bottlenecks include finding and setting up test environments, test configurations, and test results implementation. These issues are not industry specific. They can be experienced in manufacturing, service businesses, and governments alike. They can be reduced by having a thorough understanding and a disciplined, mature implementation of Continuous Testing and related recommended engineering practices. The best place to start addressing these challenges is having a good understanding of what Continuous Testing is. Marc Hornbeek, the author of Engineering DevOps, describes it as: “A quality assessment strategy in which most tests are automated and integrated as a core and essential part of DevOps. Continuous Testing is much more than simply ‘automating tests.’” In this whitepaper, we’ll address the best practices you can adopt for implementing Continuous Quality and Testing on the AWS Cloud environment in the context of the DevOps model.
    [Show full text]
  • Continuous Testing for Devops Evolving Beyond Simple Automation
    Technical Whitepaper 1 Continuous Testing for DevOps Evolving Beyond Simple Automation INTRODUCTION DevOps represents a cultural shift that stresses collaboration be- on acceleration. Moreover, adopting a bona fide Continuous Testing tween the business, developers, and IT professionals. Software test process (more than just automated tests running regularly) helps automation can enhance these connections and help organizations promote all of the core pillars of DevOps: Culture, Automation, Lean, achieve desired SDLC acceleration, but it’s important to recognize Metrics, and Sharing. that automation is just one piece of the DevOps puzzle. In this paper, we’ll explore why and how Continuous Testing’s real- Since testing is often one of the greatest constraints in the SDLC, time objective assessment of an application’s business risks is a optimizing quality processes to allow testing to begin earlier, as well critical component of DevOps. as shrink the amount of testing required, can have a marked impact DEVOPS PRINCIPLES There are several key pieces to understanding DevOps revolutions and they are often brought about by a compelling event at an organization, such as a shift to agile. As organizations start to move into an agile development methodology, they start to uncover other processes that can be accelerated, such as delivery by DevOps and testing by Continuous Testing. The acceleration that is set in motion via agile makes it necessary to accelerate the release schedule. In order to ensure a successful release, an organization must adopt continuous testing to make sure the conveyer belt does not break down. The modernization maturity model has these three distinct phases: AGILE Agile software development is a different way of thinking about approaching the challenge of development time.
    [Show full text]
  • UMTS); Radio Interface Protocol Architecture (3GPP TS 25.301 Version 3.8.0 Release 1999)
    ETSI TS 125 301 V3.8.0 (2001-06) Technical Specification Universal Mobile Telecommunications System (UMTS); Radio Interface Protocol Architecture (3GPP TS 25.301 version 3.8.0 Release 1999) 3GPP TS 25.301 version 3.8.0 Release 1999 1 ETSI TS 125 301 V3.8.0 (2001-06) Reference RTS/TSGR-0225301UR5 Keywords UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.:+33492944200 Fax:+33493654716 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/ If you find errors in the present document, send your comment to: [email protected] Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2001.
    [Show full text]