Skip to main content Accessibility help

We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings.

Close cookie message
×
  1. Home
  2. Browse subjects
  3. Computer Science
  4. Software Engineering and Development
  5. Content listing

Refine search

Refine search

Access:
Content type:
Publication date:
Apply   From and To filters
Subject: Show more
Journals Show more
Publishers: Show more
Societies Show more
Series: Show more
Collections: Show more

Actions for selected content:

Select all | Deselect all
  • View selected items
  • Export citations
  • Download PDF (zip)
  • Save to Kindle
  • Save to Dropbox
  • Save to Google Drive

Save Search

You can save your searches here and later view and run them again in "My saved searches".

Please provide a title, maximum of 40 characters.
Cancel
×

1763 results in Software Engineering and Development

Page 13 of 89

Introduction to Software Testing
  • 2nd edition
  • Paul Ammann, Jeff Offutt
  • Published online:
    28 May 2018
    Print publication:
    13 December 2016
  • This extensively classroom-tested text takes an innovative approach to explaining software testing that defines it as the process of applying a few precise, general-purpose criteria to a structure or model of the software. The book incorporates cutting-edge developments, including techniques to test modern types of software such as OO, web applications, and embedded software. This revised second edition significantly expands coverage of the basics, thoroughly discussing test automaton frameworks, and it adds new, improved examples and numerous exercises. The theory of coverage criteria is carefully and cleanly explained to help students understand concepts before delving into practical applications, while extensive use of the JUnit test framework gives students practical experience in a test framework popular in the industry. Exercises, meanwhile, feature specifically tailored tools that allow students to check their own work. The book's website also offers an instructor's manual, PowerPoint slides, testing tools for students, and example software programs in Java.

  • 12 - Test Implementation

  • from Part 3 - Testing in Practice
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 296-303

  • Summary

    Theory is usually further from practice than we wish.

    Like other software, tests can be designed in an abstract way. However, as discussed at length in Chapter 4, developers want tests to become “real” as soon as possible so that they can benefit from the immediate feedback of any failed tests. To do so, all the code must compile, tests must not cause collateral damage, the process must be repeatable, and it must complete in a timely manner. Unit testing normally doesn't pose a serious challenge with respect to these constraints, but other test phases certainly do. This section discusses technical problems that arise during the implementation of test cases. We do not catalog the problems from a process point of view. Instead, we focus on the technical strategies used to solve these problems. Many of the problems arise naturally during software integration, but integration is not the only source of difficulty; the testing of fully integrated systems also requires the techniques discussed here.

    Software programs are composed of many pieces of software of varying sizes. Individual programmers are often responsible for testing the lowest level components (classes, modules, and methods). After that, testing must be carried out in collaboration with software integration. Software can be integrated in many ways.

    Integration testing is the testing of incompatibilities and interfaces between otherwise correctly working components. That is, it is the testing needed to assure correct integration of subcomponents into a bigger working component. This is emphatically not the same as testing an already integrated component.

    Integration testing is often done with an incomplete system. The tester may be evaluating how only two of many components in the system work together, may be testing integration aspects before the full system is complete, or may be putting the system together piece by piece and evaluating how each new component fits with the previously integrated components.

    This chapter uses the term software “component” in a very broad sense: A component is a piece of a program that can be tested independently of the complete program or system. Thus, classes, modules, methods, packages, and even code fragments can be considered to be components. Also, non-executable software artifacts such as XML files, XML schemas, and databases can be considered to be components.

  • 2 - Model-Driven Test Design

  • from Part 1 - Foundations
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 19-34

  • Summary

    Designers are more efficient and effective if they can raise their level of abstraction.

    This chapter introduces one of the major innovations in the second edition of Introduction to Software Testing. Software testing is inherently complicated and our ultimate goal, completely correct software, is unreachable. The reasons are formal (as discussed below in section 2.1) and philosophical. As discussed in Chapter 1, it's not even clear that the term “correctness” means anything when applied to a piece of engineering as complicated as a large computer program. Do we expect correctness out of a building? A car? A transportation system? Intuitively, we know that all large physical engineering systems have problems, and moreover, there is no way to say what correct means. This is even more true for software, which can quickly get orders of magnitude more complicated than physical structures such as office buildings or airplanes.

    Instead of looking for “correctness,” wise software engineers try to evaluate software's “behavior” to decide if the behavior is acceptable within consideration of a large number of factors including (but not limited to) reliability, safety, maintainability, security, and efficiency. Obviously this is more complex than the naive desire to show the software is correct.

    So what do software engineers do in the face of such overwhelming complexity? The same thing that physical engineers do–we use mathematics to “raise our level of abstraction.” The Model-Driven Test Design (MDTD) process breaks testing into a series of small tasks that simplify test generation. Then test designers isolate their task, and work at a higher level of abstraction by using mathematical engineering structures to design test values independently of the details of software or design artifacts, test automation, and test execution.

    A key intellectual step in MDTD is test case design. Test case design can be the primary determining factor in whether tests successfully find failures in software. Tests can be designed with a “human-based” approach, where a test engineer uses domain knowledge of the software's purpose and his or her experience to design tests that will be effective at finding faults. Alternatively, tests can be designed to satisfy well-defined engineering goals such as coverage criteria. This chapter describes the task activities and then introduces criteria-based test design.

  • 10 - Managing the Test Process

  • from Part 3 - Testing in Practice
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 285-291

  • Summary

    If you ignore quality, everything else is easy.

    Part I of this book laid down the foundations for modern software testing, and part II went into great detail about technical methods to design effective test case values from criteria. Eventually, of course, the concepts must be put into practice. This brings in many additional pragmatic concerns. Part III of this book provides a summary overview of the major aspects of putting the Model-Driven Test Design process into practice. The most obvious audience for these chapters are test team managers. We start with overall process concerns in this chapter, then discuss aspects of practical testing such as test plans, integration testing, regression testing, and the design and implementation of test oracles.

    OVERVIEW

    Many organizations postpone all software testing activities to the end of development, after the implementation has started, or even after implementation has ended. By waiting until late in the process, testing ends up compromised. Not enough resources (time or budget) remain, problems with previous stages have been solved by taking time and dollars from testing, and we do not have enough time to plan for testing. Instead of planning and designing tests, the developers have time only to run tests, usually in an ad hoc manner. The key point is that the goal is to create high-quality software, and the old adage that “quality cannot be tested in” is still very relevant. A tester cannot show up at the last minute and make a bad product good; high quality has to be part of the process from the beginning.

    This section discusses how to integrate testing with development, where testing activities begin as soon as development activities begin, and are carried out in parallel with the development stages. Specific activities, including planning, active testing, and development-influencing activities, can be associated with each of the traditional lifecycle phases. These activities can be carried out by the developers or by separate test engineers, and can be associated with development stages within the confines of any specific development process. These testing activities allow the tester to detect and prevent faults throughout the software development process.

  • 4 - Putting Testing First

  • from Part 1 - Foundations
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 54-63

  • Summary

    What's past is prologue.

    The role of testing in software development has undergone radical changes in recent years. Testing has evolved from afterthought to a central activity in certain development methods—particularly agile methods. This chapter explains the evolving role of testing in software development and highlights the key theoretical and practical enablers for that evolution. The message of this chapter is as follows: If high-quality testing is not centrally and deeply embedded in your development process, your project is at high risk for failure. Your project might fail in the technical sense, in that you simply lose control of what the code actually does. Or it might fail in the business sense, in that your competitors roll out better functionality faster. It does not really matter which way you fail; sadly, the consequences are the same.

    TAMING THE COST-OF-CHANGE CURVE

    Traditional software engineering, as described in standard texts on software engineering, came into being as a field precisely because the development of large software projects was proving to be increasingly difficult—even impossible—using ad hoc development methods. Traditional software engineering focuses primarily on extensive modeling and upfront analysis. The goal is to reveal potential problems and changes as early as possible. The economic rationale is that effort spent on revealing failures early delivers an enormous return on investment. Every software engineering text shows the traditional “cost-of-change” curve, where the key variable is the lag between when a change should ideally be made and when the need for that change is recognized. Figure 1.1 in Chapter 1 illustrates this concept, by showing that the cost of finding and fixing faults balloons as we move from unit testing to integration testing to system testing to deployment.

    A more general description is shown in Figure 4.1. The way to read this figure is to identify the time at which a decision (or the mistake) is originally made and the time at which that decision is revised (or mistake is repaired). The time interval between these events is shown on the horizontal axis. Cost, shown on the vertical axis, is a function of the length of time between the original and the revision. The “delta” cost starts at a small value for revisions made shortly after the original and climbs ever more steeply as the interval between the two events grows longer.

  • 3 - Test Automation

  • from Part 1 - Foundations
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 35-53

  • Summary

    Test automation is a prerequisite for unit testing and criteria-based testing.

    One of the most widespread changes in software testing during the last decade has been the increased use of test automation. We introduced test automation in Chapter 2 as implementing tests into executable test scripts. This chapter expands on that concept, starting with a complete definition.

    Definition 3.9 Test automation: The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.

    Software testing can be expensive and labor intensive, so an important goal of software testing is to automate as much as possible. Test automation not only reduces the cost of testing, it also reduces human error and makes regression testing easier by allowing a test to be run repeatedly with the push of a button.

    Software engineers sometimes distinguish revenue tasks, which contribute directly to the solution of a problem, from excise tasks, which do not. For example, compiling a Java class is a classic excise task because, although necessary for the class to be executable, compilation contributes nothing to the behavior of that class. In contrast, determining which methods are appropriate to define a data abstraction in a Java class is a revenue task. Excise tasks are candidates for automation; revenue tasks usually are not. Software testing probably has more excise tasks than any other aspect of software development. Maintaining test scripts, rerunning tests, and comparing expected results with actual results are all common excise tasks that routinely use large amounts of test engineers’ time. Automating excise tasks serves the test engineer in many ways. First, eliminating excise tasks eliminates drudgery, thereby making the test engineer's job more satisfying. Second, automation frees up time to focus on the fun and challenging parts of testing, such as test design, a revenue task. Third, automation allows the same test to be run thousands of times without extra effort in environments where tests are run daily or even hourly. Fourth, automation can help eliminate errors of omission, such as failing to update all the relevant files with the new set of expected results. Fifth, automation eliminates some of the variance in test quality caused by differences in individual's abilities.

  • 5 - Criteria-Based Test Design

  • from Part 1 - Foundations
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 64-72

  • Summary

    Abstraction should be used to handle complexity, not to ignore it.

    Previous chapters introduced coverage criteria and gave some simple examples. Now we are ready to define this important concept formally. This chapter presents the ideas behind criteria in an abstract way, applicable to all structures. The four chapters in Part II instantiate these ideas with specific criteria or specific structures and show how they are used in practice.

    COVERAGE CRITERIA DEFINED

    It is common to hear testers talk about “complete testing,” “exhaustive testing,” and “full coverage.” These terms are poorly defined because of a fundamental theoretical limitation of software. Specifically, the number of potential inputs for most programs is so large as to be effectively infinite. Consider a Java compiler—the number of potential inputs to the compiler is not just all Java programs, or even all almost-correct Java programs, but all strings. The only limitation is the size of the file that can be read by the parser. Therefore, the number of inputs is effectively infinite and cannot be explicitly enumerated.

    This is where formal coverage criteria come in. Since we cannot test with all inputs, coverage criteria are used to decide which test inputs to use. The rationale behind coverage criteria is that they divide up the input space to maximize the number of faults found per test case. From a practical perspective, coverage criteria also provide useful rules for when to stop testing.

    This book defines coverage criteria in terms of test requirements as introduced in Chapter 2. The basic idea is that we want our tests to have certain properties, each of which is provided (or not) by at least one test case.

    Definition 5.23 Test Requirement: A test requirement is a specific element of a software artifact that a test case must satisfy or cover.

    This definition is fairly abstract, and more specific versions for individual structures and criteria will be given in later chapters. Test requirements usually come in sets, and we use the abbreviation TR to denote a set of test requirements.

    Test requirements can be described with respect to a variety of software artifacts, including the source code, design components, specification modeling elements, or even descriptions of the input space. Later in this book, test requirements will be generated from all of these.

  • 7 - Graph Coverage

  • from Part 2 - Coverage Criteria
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 106-176

  • Summary

    In engineering, as in baseball, you don't have to be strong to hit a home run. You just have to hit it dead center.

    This chapter introduces some of the most widely known test coverage criteria. This chapter uses graphs to define criteria and design tests. This starts our progression into the RIPR model by ensuring that tests “reach” certain locations in a graph model of the artifact being tested. The chapter starts with basic theory as a way to make the practical and applied portions of the chapter easier to follow. We first emphasize a generic view of a graph without regard to the graph's source. After this model is established, the rest of the chapter turns to practical applications by demonstrating how graphs can be obtained from various software artifacts and how the generic versions of the criteria are adapted to those graphs.

    OVERVIEW

    Directed graphs form the foundation for many coverage criteria. They come from many sources and types of software artifacts, including control flow graphs from source, design structures, finite state machines, statecharts, and use cases, among others. We use the term artifact in the most general way, to be anything associated with the software, including the requirements, design documents, implementation, tests, user manuals, and many others. Graph criteria usually require the tester to “cover” the graph in some way, usually by traversing specific portions of the graph. This overview presents graphs in general terms, and overlaps standard texts on discrete math, algorithms, and graph theory. Unlike those theoretical treatments, we focus only on the ideas needed for testing and introduce some new terminology that enable test design.

    Given an artifact under test, the idea is to extract a graph from that artifact. For example, the most common graph abstraction for source code maps executable statements and branches to a control flow graph. It is important to recognize that the graph is not the same as the artifact, and usually omits certain details. It is also possible for the same artifact to have several useful, but different, graph abstractions. The same abstraction that produces the graph from the artifact also maps test cases for the artifact to paths in the graph. Accordingly, a graph-based coverage criterion evaluates a test set for an artifact in terms of how the paths corresponding to the test cases “cover” the artifact's graph abstraction.

  • 11 - Writing Test Plans

  • from Part 3 - Testing in Practice
  • Paul Ammann, George Mason University, Virginia, Jeff Offutt, George Mason University, Virginia
  • Book:
    Introduction to Software Testing
    Published online:
    28 May 2018
    Print publication:
    13 December 2016, pp 292-295

  • Summary

    Young people think quick thoughts. Old people think deep thoughts. Leaders think long thoughts.

    Amajor emphasis formany organizations is documentation, including test plans and test plan reporting. Unfortunately, putting too much of a focus on documentation can lead to an environment where lots of meaningless reports are produced but nothing useful is done. That is why this book largely focuses on content, not form. The contents of a test plan include how the tests were created, why the tests were created, and how they will be run.

    Producing test plans, however, is an essential requirement for many organizations. Companies and customers often impose templates or outlines. Rather than surveying many different types of test plans, we look at the IEEE standard definition. The original version was defined in 1983 (829-1983), with updates in 1990 and 1998, with the most recent being 829-2008, the “IEEE Standard for Software and System TestDocumentation.” Aquick search on theWeb will supply you with more test plans and test plan outlines than you could ever use. The 829-2008 standard defines a test plan as:

    “(A) A document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. (B) A document that describes the technical and management approach to be followed for testing a system or component. Typical contents identify the items to be tested, tasks to be performed, responsibilities, schedules, and required resources for the testing activity.”

    The two major types of test plans in the current standard are:

  • 1. A Master Test Plan (MTP) provides an overall test planning and test management document for multiple levels of test. An MTP can either apply to one project, or apply to multiple projects within the same organization.

  • 2. A Level Test Plan (LTP) describes testing at a particular level, where the levels are as described in Chapter 1. Each LTP must describe the scope, approach, resources, and schedule of the testing activities for its level of testing. The LTP then defines the items being tested, the features to be tested, the testing tasks to be performed, who is responsible for each task, and any risks associated with that testing.

  • 23 - Highway Toll Control System Case Study

  • from Part IV - Real-Time Software Design Case Studies for Embedded Systems
  • Hassan Gomaa, George Mason University, Virginia
  • Book:
    Real-Time Software Design for Embedded Systems
    Published online:
    05 March 2016
    Print publication:
    26 May 2016, pp 513-524

  • Summary

    This chapter describes a concise case study of a Highway Toll Control System in which there are several entry and exit toll booths. Each toll booth is controlled by a real-time embedded subsystem that communicates with a Highway Toll Service subsystem, which receives entry and exit transactions from the toll booths and charges customer accounts. At each toll booth there are multiple sensors and actuators, requiring state dependent entry and exit control. Because entry and exit toll booths are similarly configured and behave in a similar way, this shorter case study concentrates on the design of the entry toll booth. There is less emphasis on the structural modeling in this case study, which has been covered in detail in other case studies.

    The problem description is given in Section 23.1. Section 23.2 describes the use case model, and Section 23.3 describes the software system context modeling. Section 23.4 describes the object and class structuring. Section 23.5 describes the state machine model, and Section 23.6 describes the dynamic interaction modeling. Section 23.7 describes the design modeling, which consists of the distributed software design and distributed software deployment, followed by the design of the concurrent task architecture and detailed software design.

    PROBLEM DESCRIPTION

    A highway toll road has several entry and exit points, at each of which, there is a toll plaza with one or more tollbooths. To use the system, a customer purchases a RFID (radio frequency ID) transponder, which holds the encoded customer account number, from the Highway Toll Service and mounts the transponder on the windshield of the vehicle. The Highway Toll Service maintains customer accounts in a database including owner and vehicle information, and account balance. Customers purchasing a transponder must pay in advance for toll fees by credit card. Accounts are reduced by the toll charge incurred at the end of each trip. The toll charge to be paid depends on the length of the trip and category of the vehicle.

    All tollbooths consist of a vehicle arrival sensor (placed fifty feet in front of the tollbooth), a vehicle departure sensor, a traffic light to indicate whether the vehicle has been authorized to pass through the tollbooth, a transponder detector, and a camera.

  • 14 - Detailed Real-Time Software Design

  • from Part II - Real-Time Software Design Method
  • Hassan Gomaa, George Mason University, Virginia
  • Book:
    Real-Time Software Design for Embedded Systems
    Published online:
    05 March 2016
    Print publication:
    26 May 2016, pp 266-296

  • Summary

    After structuring the system into tasks (in Chapter 13), this chapter describes the detailed software design. In this step, the internals of composite tasks that contain nested objects are designed, detailed synchronization issues of tasks accessing passive classes are addressed, connector classes are designed that encapsulate the details of inter-task communication, and each task's internal event sequencing logic is defined. Several examples are given in Pseudocode of the detailed design of task synchronization mechanisms, connector classes for inter-task communication, and task event sequencing logic.

    The detailed software design is depicted on a detailed concurrent communication diagram, which adds more detail to the concurrent communication diagram developed during task structuring. It depicts the internal design of clustered tasks and the design of connector objects.

    Section 14.1 describes the design of composite tasks, including the internal design of temporal and control clustering tasks. Section 14.2 describes the synchronization of access to classes using different synchronization mechanisms, including the mutual exclusion algorithm and the multiple readers and writers algorithm. Section 14.3 describes the synchronization of access to passive objects using the monitor concept. Section 14.4 describes the design of connectors for inter-task communication, in particular for synchronous and asynchronous message communication. Section 14.5 describes the detailed software design of tasks using task behavior specifications and event sequencing logic. Section 14.6 provides detailed software design examples of task communication and synchronization in real-time robot and vision systems. Finally, Section 14.7 briefly describes implementing concurrent tasks in Java using threads.

    DESIGN OF COMPOSITE TASKS

    A composite task is a task that encapsulates one or more nested objects. This section describes the detailed design of composite tasks, which includes tasks that were structured using the task clustering criteria. Such tasks are designed as composite active classes that contain nested passive classes. In a real-time design, typical nested classes are entity classes, input/output classes, and state machine classes.

    After considering the relationship between tasks and classes, this section describes situations where it is useful to divide the responsibility between tasks and classes. Next, the design of two composite tasks is described in detail: a temporal clustering task and a control clustering task.

  • Appendix A - Conventions Used in This Textbook

  • Hassan Gomaa, George Mason University, Virginia
  • Book:
    Real-Time Software Design for Embedded Systems
    Published online:
    05 March 2016
    Print publication:
    26 May 2016, pp 525-529

  • Summary

    For improved readability, certain conventions are used in this book. These are the naming conventions used in this book and the conventions for message sequence numbering on interaction diagrams.

    NAMING CONVENTIONS USED IN THIS BOOK

    For improved readability, the conventions used for depicting names of classes, objects, and so on in the figures are sometimes different from the conventions used for the same names in the text. In the figures, examples are shown in Times New Roman font. In the body of the text, however, examples are shown in a different font to distinguish them from the regular Cambria Math font. Some specific additional conventions used in the book vary depending on the phase of the project. For example, the conventions for capitalization are different in the analysis model (which is less formal) than in the design model (which is more formal).

    REQUIREMENTS MODELING

    In both figures and text, use cases are shown with initial uppercase and spaces in multiword names – for example, Cook Food.

    ANALYSIS MODELING

    The naming conventions for the analysis model are as follows.

    CLASSES

    Classes are shown with an uppercase initial letter. In the figures, there are no spaces in multiword names – for example, HeatingElement. In the text, however, spacing is introduced to improve the readability – for example, Heating Element.

    Attributes are shown with a lowercase initial letter – for example, weight. For multiword attributes, there are no spaces between the words in figures, but spaces are introduced in the text. The first word of the multiword name has an initial lowercase letter; subsequent words have an initial uppercase letter – for example, sensorValue in figures and sensor Value in text.

    The type of the attribute has an initial uppercase letter – for example, Boolean, Integer, or Real.

    OBJECTS

    An object may be depicted in various ways, in particular as:

    1. • An individual named object. In this case, the first letter of the first word is lowercase, and subsequent words have an uppercase first letter. In figures, the objects appear as, for example, aWarningAlarm and anotherWarningAlarm. In the text, these objects appear as a Warning Alarm and another Warning Alarm.

Page 13 of 89