System Testing in a Simulated Environment

Total Page:16

File Type:pdf, Size:1020Kb

System Testing in a Simulated Environment School of Innovation, Design and Engineering CDT504 – Computer Science, Advanced Level for 2years Master Degree (30 hp) System Testing in a Simulated Environment By Manuel Palmieri [email protected] CrossControl Advisor: Anders Öberg Mälardalen University Advisor: Antonio Cicchetti Mälardalen University Examinator: Paul Pettersson University of L’Aquila Advisor: Henry Muccini April 2013 I dedicate this thesis to my parents Elio and Rossana, and my sister Ilaria for their love, endless support and encouragement. ii Abstract System Testing in a Simulated Environment is becoming one of the bigger challenges moved by companies with the purpose to improve the quality and increase the dependability of artefacts. Moreover, another big challenge faced by them is the achievement of the independent development of software and hardware systems, with the purpose to speed up and reduce costs of development. Besides, software testing remains today a tricky activity that attracts the interest of many researchers and companies with the purpose to refine or invent new techniques and methods to perform the optimal testing on different case studies and conditions. Nowadays, the execution of testing on some real environments is not adequate because of the impossibility to perform particular kinds of tests that could be destructive for hardware and dangerous for testers. One of the areas that are affected by this issue is certainly the one regarding the production of vehicles that work in critical environments. In this respect, companies in such applicative domain trying to move towards the revolutionary approach to replace real environments with simulated environments. This thesis presents a survey of existing state–of–the–art and state–of–the–practice testing techniques and methods, a simulated environment derived from a vehicle, and how and in what way it is possible to perform testing on a simulated environment. Furthermore, with the purpose to provide a better understanding of how a real environment could be represented with a simulated environment, an overview of replacement is presented. Besides, according to CrossControl and customers’ environments, limits and needs, a case study has been realized to demonstrate how is possible to design, implement and test a simulated environment. iii Acknowledgements I would like to thank my advisors Antonio Cicchetti from Mälardalen University and Anders Öberg from CrossControl AB for their continuous help and huge support in enhancing my capability in system testing area and for making this thesis. Furthermore, sincere thanks go to Rikard Land and Daniel Boström from CrossControl AB for their contribution in achieving the desired goal of the proposal thesis. Besides, I would like to acknowledge Henry Muccini from University of L’Aquila and for giving me the opportunity to achieve my goals by taking part in Global Software Engineering European Master (GSEEM) and Magnus Nolen from CrossControl AB for giving me the possibility to carry out the thesis in CrossControl. Finally, I wish to express my gratitude to my colleagues and friends for their moral support during the entire academic experience. iv Nomenclature The Nomenclature includes abbreviations and terms found in the thesis that are common in Software Testing, and are often used or are not defined. NAME DESCRIPTION 3G 3rd Generation 3GPP 3rd Generation Partnership Program ASN.1 Abstract Syntax Notation One ATM Automated Teller Machine AUTOSAR AUTomotive Open System ARchitecture AWD All-Wheel Drive BSD Berkeley Software Distribution BTT BroadBit Test Tool CAN Controller Area Network CCM CORBA Component Model CD Codec or Coding and Decoding CH Component Handling CORBA Common Object Request Broker Architecture CPL Common Public License CPU Central Processing Unit DSL Digital Subscriber Line ECU Electrical Control Unit EJB Enterprise JavaBeans ETSI European Telecommunications Standards Institute FIT Framework for Integrated Test GUI Graphical User Interface GSM Global System for Mobile Communications HIL Hardware–In–The–Loop HW Hardware I/O or IO Input/output ID Identifier IDE Integrated Development Environment IDL Interface Definition Language IMS Internet Protocol Multimedia Subsystem IPv6 Internet Protocol version 6 KMH Kilometres per Hour LIN Local Interconnect Network LTE Long Term Evolution MC/DC Modified Condition/Decision Coverage v MOST Media Oriented Systems Transport MS Microsoft NGN Next Generation Network OMA Open Mobile Alliance OSI Open Systems Interconnection PA Platform Adapter PC Personal Computer PDP Product Development Process PTO Power Take–Off RAM Random Access Memory ROI Return Of Investment RPDE Runtime Plugin Development Environment RPM Revolution Per Minutes SA System Adapter SAP Systems, Applications and Products SEP System Engineering Process SIP Session Initiation Protocol SIGTRAN Signaling Transport SUT System Under Test SWT Standard Widget Toolkit TC Test Case TCI TTCN–3 Control Interfaces TDD Test–Driven Development TE Text Executable TEM Text Executor Manager TETRA Terrestrial Trunked Radio TL Test Logging TM Test Management TRI TTCN–3 Runtime Interface TS Test System TSE Test Script Editor TSU Test System User TTCN Testing and Test Control Notation TTCN–3 Testing and Test Control Notation – version 3 UI User Interface UML Unified Modelling Language VNC Virtual Network Computing WiMAX Worldwide Interoperability for Microwave Access XML Extensible Markup Language vi Table of Contents Abstract .............................................................................................. iii Acknowledgements ............................................................................ iv Nomenclature ..................................................................................... v Table of Contents .............................................................................. vii 1 Introduction .................................................................................. 1 2 Survey of Testing–Related Literature ............................................. 3 2.1 System Engineering Process ............................................................ 4 2.1.1 Process Input.......................................................................................... 5 2.1.2 Process Development ............................................................................ 6 2.1.3 Process Output....................................................................................... 9 2.2 System Development Model ........................................................... 9 2.3 Product Development Process ...................................................... 11 2.3.1 Phases .................................................................................................. 12 2.3.2 Tollgates ............................................................................................... 13 2.3.3 Disciplines ............................................................................................ 13 2.3.4 Artefacts ............................................................................................... 15 2.4 Testing Techniques ....................................................................... 15 2.4.1 Black–Box Testing ................................................................................ 17 2.4.2 White–Box Testing ............................................................................... 18 2.5 Testing Methods ........................................................................... 19 2.5.1 Unit Testing .......................................................................................... 21 2.5.2 Integration Testing ............................................................................... 24 2.5.3 System Testing ..................................................................................... 25 2.5.4 Hardware–In–the–Loop Testing .......................................................... 27 2.5.5 Fault Injection Testing .......................................................................... 30 2.6 Automated Software Testing ........................................................ 34 2.6.1 Code–Driven Testing ............................................................................ 35 2.6.2 Graphical User Interface Testing ......................................................... 35 2.7 Test Coverage ............................................................................... 36 2.7.1 Code Coverage ..................................................................................... 37 3 Survey of Existing Test Notations and Tools ................................. 41 vii 3.1 General Notations ......................................................................... 41 3.1.1 Testing Tools ........................................................................................ 42 3.2 TTCN–3 Notation........................................................................... 44 3.2.1 Application Fields ................................................................................. 45 3.2.2 Architecture ......................................................................................... 46 3.2.3 Core Language ..................................................................................... 51 3.2.4 Testing Tools ........................................................................................ 54 4 CCSimTech Simulated Environment ............................................. 58 4.1 Basic Concepts and Architecture ..................................................
Recommended publications
  • Codeigniter-Testing-Guide-Sample.Pdf
    CodeIgniter Testing Guide Beginners’ Guide to Automated Testing in PHP. Kenji Suzuki and Mat Whitney This book is for sale at http://leanpub.com/codeigniter-testing-guide This version was published on 2016-01-23 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2015 - 2016 Kenji Suzuki and Mat Whitney Tweet This Book! Please help Kenji Suzuki and Mat Whitney by spreading the word about this book on Twitter! The suggested hashtag for this book is #CITestGuide. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: https://twitter.com/search?q=#CITestGuide Contents Preface ............................................... i The Book at a Glance ..................................... i What You Need for This Book ................................. iii Who should read This Book? ................................. iii Why PHPUnit? ........................................ iv Is This a CodeIgniter Book? .................................. iv Is Testing PHP Applications Difficult? ............................ iv Is Testing CodeIgniter Applications Difficult? .................... v Testing is Fun and Easy ................................ v Conventions Used in This Book ................................ v Errata .............................................
    [Show full text]
  • EVALUATING and SELECTING SOFTWARE TEST AUTOMATION TOOLS Synthesizing Empirical Evidence from Practitioners
    A 752 OULU 2020 A 752 UNIVERSITY OF OULU P.O. Box 8000 FI-90014 UNIVERSITY OF OULU FINLAND ACTA UNIVERSITATISUNIVERSITATIS OULUENSISOULUENSIS ACTA UNIVERSITATIS OULUENSIS ACTAACTA SCIENTIAESCIENTIAEA A RERUMRERUM Päivi Raulamo-Jurvanen NATURALIUMNATURALIUM Päivi Raulamo-Jurvanen University Lecturer Tuomo Glumoff EVALUATING AND University Lecturer Santeri Palviainen SELECTING SOFTWARE TEST Postdoctoral researcher Jani Peräntie AUTOMATION TOOLS SYNTHESIZING EMPIRICAL EVIDENCE FROM University Lecturer Anne Tuomisto PRACTITIONERS University Lecturer Veli-Matti Ulvinen Planning Director Pertti Tikkanen Professor Jari Juga University Lecturer Anu Soikkeli University Lecturer Santeri Palviainen UNIVERSITY OF OULU GRADUATE SCHOOL; UNIVERSITY OF OULU, FACULTY OF INFORMATION TECHNOLOGY AND ELECTRICAL ENGINEERING Publications Editor Kirsti Nurkkala ISBN 978-952-62-2765-8 (Paperback) ISBN 978-952-62-2766-5 (PDF) ISSN 0355-3191 (Print) ISSN 1796-220X (Online) ACTA UNIVERSITATIS OULUENSIS A Scientiae Rerum Naturalium 752 PÄIVI RAULAMO-JURVANEN EVALUATING AND SELECTING SOFTWARE TEST AUTOMATION TOOLS Synthesizing Empirical Evidence from Practitioners Academic dissertation to be presented with the assent of the Doctoral Training Committee of Information Technology and Electrical Engineering of the University of Oulu for public defence in the OP auditorium (L10), Linnanmaa, on 13 November 2020, at 12 noon UNIVERSITY OF OULU, OULU 2020 Copyright © 2020 Acta Univ. Oul. A 752, 2020 Supervised by Professor Mika Mäntylä Professor Burak Turhan Associate Professor Vahid Garousi Reviewed by Associate Professor Filippo Ricca Associate Professor Viktoria Stray Opponent Professor Kari Smolander ISBN 978-952-62-2765-8 (Paperback) ISBN 978-952-62-2766-5 (PDF) ISSN 0355-3191 (Printed) ISSN 1796-220X (Online) Cover Design Raimo Ahonen PUNAMUSTA TAMPERE 2020 Raulamo-Jurvanen, Päivi, Evaluating and Selecting Software Test Automation Tools.
    [Show full text]
  • Practical Example of Tcl Command Design in a Qt/C++ Graphical Application Tony Johnson October 18Th, 2017 Tony [email protected]
    Practical Example of Tcl Command Design in a Qt/C++ Graphical Application Tony Johnson October 18th, 2017 [email protected] Abstract Tcl provides excellent support for creating complicated user commands in applications that have correct-by-construction built-in help, support for hidden commands, support for position- independent switches, and more. This paper discusses the technical details for how we created one such command in our Qt-based application. Summary In this paper I will discuss the technical details around the design for the Tcl “wave” command in our Qt-based [1] application. Visualizer is a GUI for displaying and analyzing simulation waveforms. It is driven by the user either via standard GUI operations such as menu selections, button clicks, drag and drop, key accelerators, etc or via commands passed in through a command prompt which is a Tcl shell. Because GUI operations are inherently difficult to automate among other reasons, there was a strong need to have a command for our waveform window that could do everything that could be done via the GUI. Since we already had a Tcl shell in our application, the obvious answer was to create a Tcl command to provide this capability. Luckily Tcl is well suited for implementing such a complex command. Background and Motivation Command-based control of graphical user interface interactions is important for many different reasons. The four key reasons that motivated this work were: Testing; User Control; 3rd Party Access; Save/Restore; and Expandability. Testing Unless you want to retest the GUI operations in your application by hand with every major release, minor release, feature addition and bug fix (trust me, you don’t), then you will want to have some way to create automated tests for GUI interactions.
    [Show full text]
  • Types of Software Testing
    Types of Software Testing We would be glad to have feedback from you. Drop us a line, whether it is a comment, a question, a work proposition or just a hello. You can use either the form below or the contact details on the rightt. Contact details [email protected] +91 811 386 5000 1 Software testing is the way of assessing a software product to distinguish contrasts between given information and expected result. Additionally, to evaluate the characteristic of a product. The testing process evaluates the quality of the software. You know what testing does. No need to explain further. But, are you aware of types of testing. It’s indeed a sea. But before we get to the types, let’s have a look at the standards that needs to be maintained. Standards of Testing The entire test should meet the user prerequisites. Exhaustive testing isn’t conceivable. As we require the ideal quantity of testing in view of the risk evaluation of the application. The entire test to be directed ought to be arranged before executing it. It follows 80/20 rule which expresses that 80% of defects originates from 20% of program parts. Start testing with little parts and extend it to broad components. Software testers know about the different sorts of Software Testing. In this article, we have incorporated majorly all types of software testing which testers, developers, and QA reams more often use in their everyday testing life. Let’s understand them!!! Black box Testing The black box testing is a category of strategy that disregards the interior component of the framework and spotlights on the output created against any input and performance of the system.
    [Show full text]
  • Software License Agreement
    ESSENTIAL STUDIO SOFTWARE LICENSE AGREEMENT This Software License Agreement (the “Agreement”) is a legal agreement between you (“You”, “Your”, or “Customer”) and Syncfusion, Inc., a Delaware corporation with its principal place of business located at 2501 Aerial Center Parkway, Suite 200, Morrisville, NC 27560 (“Syncfusion”). This license is for Essential Studio Enterprise Edition, Essential Studio WPF Edition, Essential Studio PDF Edition, Essential Studio Xamarin Edition, and Essential Studio Win Forms Edition. Syncfusion licenses its products on a per-copy basis (referred to below as Retail Licenses) or under a project license, a corporate division license, or an enterprise license. Your right to use any given copy of a Syncfusion Essential Studio software product is generally set forth in this Agreement. In the event that your copy of this software product is licensed under a project license, a division license, or global license, additional terms and conditions shall also apply which will be set forth in a separate written and signed agreement. Carefully read all of the terms and conditions of this Agreement prior to downloading and/or installing or using the Licensed Product (as that term is defined below). This Agreement between you and Syncfusion sets forth the terms and conditions of your use of the Licensed Product. For the purposes of this Agreement, the effective date of this Agreement shall be the date upon which you click the “YES” button below. BY CLICKING THE “YES” BUTTON, YOU ARE ACCEPTING ALL OF THE TERMS OF THIS AGREEMENT AND AGREE TO BE BOUND BY THE TERMS OF THIS AGREEMENT. THIS AGREEMENT CONSTITUTES A BINDING CONTRACT.
    [Show full text]
  • Towards a Taxonomy of Sunit Tests *
    Towards a Taxonomy of SUnit Tests ? Markus G¨alli a Michele Lanza b Oscar Nierstrasz a aSoftware Composition Group Institut f¨urInformatik und angewandte Mathematik Universit¨atBern, Switzerland bFaculty of Informatics University of Lugano, Switzerland Abstract Although unit testing has gained popularity in recent years, the style and granularity of individual unit tests may vary wildly. This can make it difficult for a developer to understand which methods are tested by which tests, to what degree they are tested, what to take into account while refactoring code and tests, and to assess the value of an existing test. We have manually categorized the test base of an existing object-oriented system in order to derive a first taxonomy of unit tests. We have then developed some simple tools to semi-automatically categorize tests according to this taxonomy, and applied these tools to two case studies. As it turns out, the vast majority of unit tests focus on a single method, which should make it easier to associate tests more tightly to the methods under test. In this paper we motivate and present our taxonomy, we describe the results of our case studies, and we present our approach to semi-automatic unit test categorization. 1 Key words: unit testing, taxonomy, reverse engineering 1 13th International European Smalltalk Conference (ESUG 2005) http://www.esug.org/conferences/thirteenthinternationalconference2005 ? We thank St´ephane Ducasse for his helpful comments and gratefully acknowledge the financial support of the Swiss National Science Foundation for the project “Tools and Techniques for Decomposing and Composing Software” (SNF Project No.
    [Show full text]
  • Smoke Testing What Is Smoke Testing?
    Smoke Testing What is Smoke Testing? Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing. The term ‘Smoke Testing’ is came from the hardware testing, in the hardware testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on.Prior to start Smoke testing few test cases need to created once to use for smoke testing. These test cases are executed prior to start actual testing to checkcritical functionalities of the program is working fine. This set of test cases written such a way that all functionality is verified but not in deep. The objective is not to perform exhaustive testing, the tester need check the navigation’s & adding simple things, tester needs to ask simple questions “Can tester able to access software application?”, “Does user navigates from one window to other?”, “Check that the GUI is responsive” etc. Here are graphical representation of Smoke testing & Sanity testing in software testing: Smoke Sanity Testing Diagram The test cases can be executed manually or automated; this depends upon the project requirements. In this types of testing mainly focus on the important functionality of application, tester do not care about detailed testing of each software component, this can be cover in the further testing of application. The Smoke testing is typically executed by testers after every build is received for checking the build is in testable condition. This type of testing is applicable in the Integration Testing, System Testing and Acceptance Testing levels.
    [Show full text]
  • YOSSEF BENHAROSH RESUME 972 (0) 544-308209 | [email protected] | Kiryat Gat, Israel
    YOSSEF BENHAROSH RESUME 972 (0) 544-308209 | [email protected] | Kiryat Gat, Israel PHP & Drupal developer, June 2011 – present Freelance web developer for 4 years who works with the following technologies: PHP, MySQL, Javascript, jQuery, Drupal, HTML/HTML5, CSS/CSS3. Specializes in PHP development. Including: Object-Oriented Programming, mySQL as a data base, and Laravel as a framework. Drupal developer, specializing in developing new modules and themes, and in taming existing modules. Good working knowledge of organic SEO. Chosen works freefax.co.il – PHP site that provides fax services. I worked as a PHP and mySQL programmer, as well as on the front end with jQuery, Ajax, html and CSS. I wrote the cart and invoice modules and the user class. puzzlemedia.co.il – Bilingual Drupal website for film producers. www.yaronlivne.co.il – Drupal based app that I wrote most of its modules and developed its’ theme. ZEZBRA – A startup that I themed its Drupal site, as well as developed its PHP based cellular version. reshetech.co.il – Hebrew tutorials website based on PHP. phpenthusiast.com – English tutorials website devoted to Object Oriented PHP. Github projects myAPI – I think it is the simplest way to provide API services for small businesses that want to provide data based services to their customers. csvtax – Drupal 7 module that transforms a CSV file into hierarchical taxonomy. cornerslider – A jQuery popup that slides the content in and out when the user scrolls down and up the page. Technologies Back end programming languages: PHP, mySQL. Front end programming languages: CSS/3, HTML/5, javascript.
    [Show full text]
  • 2.5 the Unit Test Framework (UTF)
    Masaryk University Faculty of Informatics C++ Unit Testing Frameworks Diploma Thesis Brno, January 2010 Miroslav Sedlák i Statement I declare that this thesis is my original work of authorship which I developed individually. I quote properly full reference to all sources I used while developing. ...…………..……… Miroslav Sedlák Acknowledgements I am grateful to RNDr. Jan Bouda, Ph.D. for his inspiration and productive discussion. I would like to thank my family and girlfriend for the encouragement they provided. Last, but not least, I would like to thank my friends Ing.Michal Bella who was very supportive in verifying the architecture of the extension of Unit Test Framework and Mgr. Irena Zigmanová who helped me with proofreading of this thesis. ii Abstract The aim of this work is to gather, clearly present and test the use of existing UTFs (CppUnit, CppUnitLite, CppUTest, CxxTest and other) and supporting tools for software project development in the programming language C++. We will compare the advantages and disadvantages of UTFs and theirs tools. Another challenge is to design effective solutions for testing by using one of the UTFs in dependence on the result of analysis. Keywords C++, Unit Test (UT), Test Framework (TF), Unit Test Framework (UTF), Test Driven Development (TDD), Refactoring, xUnit, Standard Template Library (STL), CppUnit, CppUnitLite, CppUTest Run-Time Type Information (RTTI), Graphical User Interface (GNU). iii Contents 1 Introduction ....................................................................................................................................
    [Show full text]
  • Studio Fundamentals Userguide Table of Contents Ranorex Studio Fundamentals
    RANOREX STUDIO FUNDAMENTALS USERGUIDE TABLE OF CONTENTS RANOREX STUDIO FUNDAMENTALS ....................................................................................... 4 RANORIZE YOURSELF IN 20 MINUTES .................................................................................................... 5 Download and install Ranorex Studio ..................................................................................... 5 Plan your first test ................................................................................................................... 8 Create a new solution ........................................................................................................... 10 Record your first test ............................................................................................................. 13 Analyze your recording ......................................................................................................... 18 Run a test and check the report ............................................................................................ 20 RANOREX STUDIO .......................................................................................................................... 23 Ranorex Studio start page .................................................................................................... 29 Sample solutions ................................................................................................................... 33 Create a new solution ..........................................................................................................
    [Show full text]
  • Squish Coco 3.3.2 - Copyright ©2015 Froglogic Gmbh CONTENTS
    Squish Coco 3.3.2 - Copyright ©2015 froglogic GmbH CONTENTS Contents 1 Introduction 1 1.1 Squish Coco - Code Coverage Tool for Tcl, C# and C/C++ . .1 1.2 CoverageScanner—Instrumentation during the Generation . .2 1.3 CoverageBrowser—View, Analyse, and Manage, Code Coverage Results . .2 I Quick Start and Tutorials 4 2 Synopsis 5 3 Using Squish Coco 6 4 Creating an instrumented project 7 4.1 Installing Squish Coco ..............................................7 4.2 C++ on Microsoft Visual Studio using the Microsoft Visual Studio Add-in . .7 4.3 C# on Microsoft Visual Studio . .8 4.4 Tcl.........................................................9 4.4.1 Using more than one Tcl version on one system . 10 4.5 Command Line Tools . 10 5 Generating Instrumentations Without Modifying Projects 12 5.1 GNU Make . 12 5.2 Microsoft NMake . 12 5.3 Microsoft Visual Studio . 13 5.4 Microsoft MSBuild . 13 5.5 Mono C# XBuild . 13 6 Instrumenting a simple project 14 6.1 UNIX and Apple Mac OS X setup . 14 6.1.1 Setup . 14 6.1.2 Structure of the parser directories . 15 6.1.3 Compiling and testing . 15 6.1.4 Instrumentation . 15 - i - froglogic GmbH CONTENTS 6.1.5 How the project is instrumented . 16 6.1.6 Additional changes . 17 6.2 Microsoft Windows setup . 17 6.2.1 Setup . 17 6.2.2 Structure of the parser directories . 17 6.2.3 Compiling and testing . 18 6.2.4 Instrumentation . 18 6.2.5 How the project is instrumented . 19 6.2.6 Additional changes .
    [Show full text]
  • Visual Foxpro
    PRE201 Introduction to Visual FoxPro Ted Roche Ted Roche & Associates, LLC Visual FoxPro DevCon 2001 Ground Rules Pagers and cell phones silent, please. Rest breaks as appropriate How to ask questions Administrivia Conference Binder Schedule – Some sessions only given once Trade Show – T-shirt Tuesday, Drawing Wed. Evaluations - help the community Closing session questions – Wednesday noon Drink Tickets! Visual FoxPro DevCon 2001 Goals for this morning Learn the terminology used in VFP Understand the tools of VFP has Understand how VFP stores and retrieves data Know what applications VFP can create Know resources to learn more Visual FoxPro DevCon 2001 Who is Ted Roche? President of TR&A, LLC Consulting Microsoft Certified Solution Developer, Microsoft Certified Systems Engineer Co-Author of Hacker’s Guide to VFP 6 Author of Essential SourceSafe Microsoft Support MVP Visual FoxPro DevCon 2001 Outline Ground Rules & Pop Quiz Episode I: It’s the Data Part B: It’s the Coding Act III: Advanced Topics Part 4: Putting it all together Epilogue: So, Now What? Visual FoxPro DevCon 2001 What is Visual FoxPro? Visual FoxPro is… … a standalone tool for data manipulation. … a development tool for standalone, LAN, client-server, COM and Web applications. … a database engine. … a programming language. … part of Visual Studio. … an integral part of Microsoft Windows. … a religionVisual. FoxPro DevCon 2001 What is Visual FoxPro? Visual FoxPro is… … a standalone tool for data manipulation. … a development tool for standalone, LAN, client-server, COM and Web applications. … a database engine. … a programming language. … part of Visual Studio. … an integral part of Microsoft Windows.
    [Show full text]