Full Ebook of Handbook of Software Fault Localization Foundations and Advances 1St Edition W Eric Wong Editor Online PDF All Chapter

Handbook of Software Fault
Localization Foundations and

Advances 1st Edition W. Eric Wong
(Editor)
Visit to download the full and correct content document:
https://ebookmeta.com/product/handbook-of-software-fault-localization-foundations-a
nd-advances-1st-edition-w-eric-wong-editor/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Infanticide and Filicide Foundations in Maternal Mental

Health Forensics 1st Edition Gina Wong
https://ebookmeta.com/product/infanticide-and-filicide-
foundations-in-maternal-mental-health-forensics-1st-edition-gina-
wong/
ChatGPT for Beginners: Features, Foundations, and

Applications 1st Edition Eric Sarrion
https://ebookmeta.com/product/chatgpt-for-beginners-features-
foundations-and-applications-1st-edition-eric-sarrion/
Foundations of Game Engine Development Volume 1

Mathematics 1st Edition Eric Lengyel
https://ebookmeta.com/product/foundations-of-game-engine-
development-volume-1-mathematics-1st-edition-eric-lengyel/
Handbook of Hydraulic Geometry Theories and Advances

Vijay Singh
https://ebookmeta.com/product/handbook-of-hydraulic-geometry-
theories-and-advances-vijay-singh/
Partial Differential Equations - Topics in Fourier
Analysis 2nd Edition M. W. Wong
https://ebookmeta.com/product/partial-differential-equations-
topics-in-fourier-analysis-2nd-edition-m-w-wong/
Fundamentals of Software Engineering Engineering

Handbook 1st Edition Rajat Gupta
https://ebookmeta.com/product/fundamentals-of-software-
engineering-engineering-handbook-1st-edition-rajat-gupta/
Mathematical Foundations of Software Engineering: A

Practical Guide to Essentials 1st Edition Gerard
O'Regan
https://ebookmeta.com/product/mathematical-foundations-of-
software-engineering-a-practical-guide-to-essentials-1st-edition-
gerard-oregan/
Handbook of Artificial Intelligence Techniques in

Photovoltaic Systems: Modeling, Control, Optimization,
Forecasting and Fault Diagnosis 1st Edition Adel Mellit
https://ebookmeta.com/product/handbook-of-artificial-
intelligence-techniques-in-photovoltaic-systems-modeling-control-
optimization-forecasting-and-fault-diagnosis-1st-edition-adel-
mellit/
Integrating the Internet of Things Into Software

Engineering Practices Advances in Systems Analysis
Software Engineering and High Performance Computing
1st Edition D. Jeya Mala
https://ebookmeta.com/product/integrating-the-internet-of-things-
into-software-engineering-practices-advances-in-systems-analysis-
software-engineering-and-high-performance-computing-1st-edition-
Handbook of Software
Fault Localization
IEEE Press
445 Hoes Lane
Piscataway, NJ 08854
IEEE Press Editorial Board

Sarah Spurgeon, Editor in Chief
Jón Atli Benediktsson Andreas Molisch Diomidis Spinellis

Anjan Bose Saeid Nahavandi Ahmet Murat Tekalp
Adam Drobot Jeffrey Reed
Peter (Yong) Lian Thomas Robertazzi
About IEEE Computer Society

IEEE Computer Society is the world’s leading computing membership organization and the
trusted information and career-development source for a global workforce of technology
leaders including: professors, researchers, software engineers, IT professionals, employers,
and students. The unmatched source for technology information, inspiration, and
collaboration, the IEEE Computer Society is the source that computing professionals trust to
provide high-quality, state-of-the-art information on an on-demand basis. The Computer
Society provides a wide range of forums for top minds to come together, including technical
conferences, publications, and a comprehensive digital library, unique training webinars,
professional training, and the Tech Leader Training Partner Program to help organizations
increase their staff’s technical knowledge and expertise, as well as the personalized
information tool my Computer. To find out more about the community for technology
leaders, visit http://www.computer.org.
IEEE/Wiley Partnership
The IEEE Computer Society and Wiley partnership allows the CS Press authored book program
to produce a number of exciting new titles in areas of computer science, computing, and
networking with a special focus on software engineering. IEEE Computer Society members
receive a 35% discount on Wiley titles by using their member discount code. Please contact
IEEE Press for details.
To submit questions about the program or send proposals, please contact Mary Hatcher,
Editor, Wiley-IEEE Press: Email: mhatcher@wiley.com, John Wiley & Sons, Inc., 111 River
Street, Hoboken, NJ 07030-5774.
Handbook of Software Fault Localization
Foundations and Advances
Edited by
W. Eric Wong
Department of Computer Science, University of Texas at Dallas,
Richardson, TX, USA
T.H. Tse
Department of Computer Science, The University of Hong Kong,
Pokfulam, Hong Kong
This edition first published 2023
Copyright © 2023 by the IEEE Computer Society. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise,
except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without
either the prior written permission of the Publisher, or authorization through payment of the
appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers,
MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to
the Publisher for permission should be addressed to the Permissions Department, John Wiley
& Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at
http://www.wiley.com/go/permission.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley
& Sons, Inc. and/or its affiliates in the United States and other countries and may not be used
without written permission. All other trademarks are the property of their respective owners.
John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and authors have used their best
efforts in preparing this book, they make no representations or warranties with respect to the
accuracy or completeness of the contents of this book and specifically disclaim any implied
warranties of merchantability or fitness for a particular purpose. No warranty may be created or
extended by sales representatives or written sales materials. The advice and strategies contained
herein may not be suitable for your situation. You should consult with a professional where
appropriate. Neither the publisher nor authors shall be liable for any loss of profit or any other
commercial damages, including but not limited to special, incidental, consequential, or other
damages. Further, readers should be aware that websites listed in this work may have changed or
disappeared between when this work was written and when it is read. Neither the publisher nor
authors shall be liable for any loss of profit or any other commercial damages, including but not
limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact
our Customer Care Department within the United States at (800) 762-2974, outside the United
States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print
may not be available in electronic formats. For more information about Wiley products, visit our
web site at www.wiley.com
Library of Congress Cataloging-in-Publication Data
Names: Wong, W. Eric, editor. | Tse, T.H., editor. | John Wiley & Sons,
publisher.
Title: Handbook of software fault localization : foundations and advances /
edited by W. Eric Wong, T.H. Tse.
Description: Hoboken, New Jersey : Wiley, [2023] | Includes bibliographical
references and index.
Identifiers: LCCN 2022037789 (print) | LCCN 2022037790 (ebook) | ISBN
9781119291800 (paperback) | ISBN 9781119291817 (adobe pdf) | ISBN
9781119291824 (epub)
Subjects: LCSH: Software failures. | Software failures–Data processing. |
Debugging in computer science. | Computer software–Quality control.
Classification: LCC QA76.76.F34 H36 2023 (print) | LCC QA76.76.F34
(ebook) | DDC 005.1–dc23/eng/20220920
LC record available at https://lccn.loc.gov/2022037789
LC ebook record available at https://lccn.loc.gov/2022037790
Cover designed by T.H. Tse
Set in 9.5/12.5pt STIXTwoText by Straive, Pondicherry, India

v
Contents
Editor Biographies xv
List of Contributors xvii
1 Software Fault Localization: an Overview of Research, Techniques,

and Tools 1
W. Eric Wong, Ruizhi Gao, Yihao Li, Rui Abreu, Franz Wotawa,
and Dongcheng Li
1.1 Introduction 1
1.2 Traditional Fault Localization Techniques 14
1.2.1 Program Logging 14
1.2.2 Assertions 14
1.2.3 Breakpoints 14
1.2.4 Profiling 15
1.3 Advanced Fault Localization Techniques 15
1.3.1 Slicing-Based Techniques 15
1.3.2 Program Spectrum-Based Techniques 20
1.3.2.1 Notation 20
1.3.2.2 Techniques 21
1.3.2.3 Issues and Concerns 27
1.3.3 Statistics-Based Techniques 30
1.3.4 Program State-Based Techniques 32
1.3.5 Machine Learning-Based Techniques 34
1.3.6 Data Mining-Based Techniques 36
1.3.7 Model-Based Techniques 37
1.3.8 Additional Techniques 41
1.3.9 Distribution of Papers in Our Repository 45
1.4 Subject Programs 47
1.5 Evaluation Metrics 50
1.6 Software Fault Localization Tools 53
vi Contents
1.7 Critical Aspects 58

1.7.1 Fault Localization with Multiple Bugs 58
1.7.2 Inputs, Outputs, and Impact of Test Cases 60
1.7.3 Coincidental Correctness 63
1.7.4 Faults Introduced by Missing Code 64
1.7.5 Combination of Multiple Fault Localization Techniques 65
1.7.6 Ties Within Fault Localization Rankings 67
1.7.7 Fault Localization for Concurrency Bugs 67
1.7.8 Spreadsheet Fault Localization 68
1.7.9 Theoretical Studies 70
1.8 Conclusion 71
Notes 73
References 73
2 Traditional Techniques for Software Fault Localization 119

Yihao Li, Linghuan Hu, W. Eric Wong, Vidroha Debroy,
and Dongcheng Li
2.1 Program Logging 119
2.2 Assertions 121
2.3 Breakpoints 124
2.4 Profiling 125
2.5 Discussion 128
2.6 Conclusion 130
References 131
3 Slicing-Based Techniques for Software Fault Localization 135

W. Eric Wong, Hira Agrawal, and Xiangyu Zhang
3.1 Introduction 135
3.2 Static Slicing-Based Fault Localization 136
3.2.1 Introduction 136
3.2.2 Program Slicing Combined with Equivalence Analysis 137
3.2.3 Further Application 138
3.3 Dynamic Slicing-Based Fault Localization 138
3.3.1 Dynamic Slicing and Backtracking Techniques 144
3.3.2 Dynamic Slicing and Model-Based Techniques 145
3.3.3 Critical Slicing 148
3.3.3.1 Relationships Between Critical Slices (CS) and Exact Dynamic Program
Slices (DPS) 149
3.3.3.2 Relationship Between Critical Slices and Executed Static Program
Slices 150
3.3.3.3 Construction Cost 150
Contents vii
3.3.4 Multiple-Points Dynamic Slicing 151

3.3.4.1 BwS of an Erroneous Computed Value 152
3.3.4.2 FwS of Failure-Inducing Input Difference 152
3.3.4.3 BiS of a Critical Predicate 154
3.3.4.4 MPSs: Dynamic Chops 157
3.3.5 Execution Indexing 158
3.3.5.1 Concepts 159
3.3.5.2 Structural Indexing 161
3.3.6 Dual Slicing to Locate Concurrency Bugs 165
3.3.6.1 Trace Comparison 165
3.3.6.2 Dual Slicing 168
3.3.7 Comparative Causality: a Causal Inference Model Based on Dual
Slicing 173
3.3.7.1 Property One: Relevance 174
3.3.7.2 Property Two: Sufficiency 175
3.3.8 Implicit Dependences to Locate Execution Omission Errors 177
3.3.9 Other Dynamic Slicing-Based Techniques 179
3.4 Execution Slicing-Based Fault Localization 179
3.4.1 Fault Localization Using Execution Dice 179
3.4.2 A Family of Fault Localization Heuristics Based on Execution
Slicing 181
3.4.2.1 Heuristic I 182
3.4.2.2 Heuristic II 183
3.4.2.3 Heuristic III 185
3.4.3 Effective Fault Localization Based on Execution Slices and Inter-block
Data Dependence 188
3.4.3.1 Augmenting a Bad 1 189
3.4.3.2 Refining a Good (1) 190
3.4.3.3 An Incremental Debugging Strategy 191
3.4.4 Other Execution Slicing-Based Techniques in Software Fault
Localization 193
3.5 Discussions 193
3.6 Conclusion 194
Notes 195
References 195
4 Spectrum-Based Techniques for Software Fault Localization 201

W. Eric Wong, Hua Jie Lee, Ruizhi Gao, and Lee Naish
4.2 Background and Notation 203
4.2.1 Similarity Coefficient-Based Fault Localization 204
viii Contents
4.2.2 An Example of Using Similarity Coefficient to Compute

Suspiciousness 205
4.3 Insights of Some Spectra-Based Metrics 210
4.4 Equivalence Metrics 212
4.4.1 Applicability of the Equivalence Relation to Other Fault Localization
Techniques 217
4.4.2 Applicability Beyond Fault Localization 218
4.5 Selecting a Good Suspiciousness Function (Metric) 219
4.5.1 Cost of Using a Metric 219
4.5.2 Optimality for Programs with a Single Bug 220
4.5.3 Optimality for Programs with Deterministic Bugs 221
4.6 Using Spectrum-Based Metrics for Fault Localization 222
4.6.1 Spectrum-Based Metrics for Fault Localization 222
4.6.2 Refinement of Spectra-Based Metrics 227
4.7 Empirical Evaluation Studies of SBFL Metrics 232
4.7.1 The Construction of D∗ 234
4.7.2 An Illustrative Example 235
4.7.3 A Case Study Using D∗ 237
4.7.3.1 Subject Programs 237
4.7.3.2 Fault Localization Techniques Used in Comparisons 238
4.7.3.3 Evaluation Metrics and Criteria 239
4.7.3.4 Statement with Same Suspiciousness Values 240
4.7.3.5 Results 241
4.7.3.6 Effectiveness of D∗ with Different Values of ∗ 247
4.7.3.7 D∗ Versus Other Fault Localization Techniques 248
4.7.3.8 Programs with Multiple Bugs 251
4.7.3.9 Discussion 255
4.8 Conclusion 261
Notes 262
References 263
5 Statistics-Based Techniques for Software Fault Localization 271

Zhenyu Zhang and W. Eric Wong
5.1.1 Tarantula 272
5.1.2 How It Works 272
5.2 Working with Statements 274
5.2.1 Techniques Under the Same Problem Settings 275
5.2.2 Statistical Variances 275
5.3 Working with Non-statements 283
5.3.1 Predicate: a Popular Trend 283
Contents ix
5.3.2 BPEL: a Sample Application 285

5.4 Purifying the Input 286
5.4.1 Coincidental Correctness Issue 286
5.4.2 Class Balance Consideration 287
5.5 Reinterpreting the Output 288
5.5.1 Revealing Fault Number 288
5.5.2 Noise Reduction 291
Notes 292
References 293
6 Machine Learning-Based Techniques for Software Fault

Localization 297
W. Eric Wong
6.2 BP Neural Network-Based Fault Localization 298
6.2.1 Fault Localization with a BP Neural Network 298
6.2.2 Reduce the Number of Candidate Suspicious Statements 302
6.3 RBF Neural Network-Based Fault Localization 304
6.3.1 RBF Neural Networks 304
6.3.2 Methodology 305
6.3.2.1 Fault Localization Using an RBF Neural Network 306
6.3.2.2 Training of the RBF Neural Network 307
6.3.2.3 Definition of a Weighted Bit-Comparison-Based Dissimilarity 309
6.4 C4.5 Decision Tree-Based Fault Localization 309
6.4.1 Category-Partition for Rule Induction 309
6.4.2 Rule Induction Algorithms 310
6.4.3 Statement Ranking Strategies 310
6.4.3.1 Revisiting Tarantula 310
6.4.3.2 Ranking Statements Based on C4.5 Rules 312
6.5 Applying Simulated Annealing with Statement Pruning for an SBFL
Formula 314
6.6 Conclusion 317
Notes 317
References 317
7 Data Mining-Based Techniques for Software Fault Localization 321

Peggy Cellier, Mireille Ducassé, Sébastien Ferré, Olivier Ridoux,
and W. Eric Wong
7.2 Formal Concept Analysis and Association Rules 324
7.2.1 Formal Concept Analysis 325
x Contents
7.2.2 Association Rules 327

7.3 Data Mining for Fault Localization 329
7.3.1 Failure Rules 329
7.3.2 Failure Lattice 331
7.4 The Failure Lattice for Multiple Faults 336
7.4.1 Dependencies Between Faults 336
7.4.2 Example 341
7.5 Discussion 342
7.5.1 The Structure of the Execution Traces 342
7.5.2 Union Model 343
7.5.3 Intersection Model 343
7.5.4 Nearest Neighbor 343
7.5.5 Delta Debugging 344
7.5.6 From the Trace Context to the Failure Context 344
7.5.7 The Structure of Association Rules 345
7.5.8 Multiple Faults 345
7.6 Fault Localization Using N-gram Analysis 346
7.6.1 Background 347
7.6.1.1 Execution Sequence 347
7.6.1.2 N-gram Analysis 347
7.6.1.3 Linear Execution Blocks 349
7.6.1.4 Association Rule Mining 349
7.6.3 Conclusion 353
7.7 Fault Localization for GUI Software Using N-gram Analysis 353
7.7.1 Background 354
7.7.1.1 Representation of the GUI and Its Operations 354
7.7.1.2 Event Handler 356
7.7.1.3 N-gram 356
7.7.2 Association Rule Mining 357
7.7.3.1 General Approach 358
7.7.3.2 N-gram Fault Localization Algorithm 358
7.8 Conclusion 360
Notes 361
References 361
8 Information Retrieval-Based Techniques for Software Fault

Localization 365
Xin Xia and David Lo
Contents xi
8.2 General IR-Based Fault Localization Process 368

8.3 Fundamental Information Retrieval Techniques for Software Fault
Localization 369
8.3.1 Vector Space Model 369
8.3.2 Topic Modeling 370
8.3.3 Word Embedding 371
8.4 Evaluation Metrics 372
8.4.1 Top-k Prediction Accuracy 372
8.4.2 Mean Reciprocal Rank (MRR) 373
8.4.3 Mean Average Precision (MAP) 373
8.5 Techniques for Different Scenarios 374
8.5.1 Text of Current Bug Report Only 374
8.5.1.1 VSM Variants 374
8.5.1.2 Topic Modeling 375
8.5.2 Text and History 376
8.5.2.1 VSM Variants 376
8.5.2.2 Topic Modeling 378
8.5.2.3 Deep Learning 378
8.5.3 Text and Stack/Execution Traces 379
8.6 Empirical Studies 380
8.7 Miscellaneous 383
8.8 Conclusion 385
Notes 385
References 386
9 Model-Based Techniques for Software Fault Localization 393

Birgit Hofer, Franz Wotawa, Wolfgang Mayer, and Markus Stumptner
9.2 Basic Definitions and Algorithms 395
9.2.1 Algorithms for MBD 401
9.3 Modeling for MBD 404
9.3.1 The Value-Based Model 405
9.3.2 The Dependency-Based Model 409
9.3.3 Approximation Models for Debugging 413
9.3.4 Other Modeling Approaches 416
9.4 Application Areas 417
9.5 Hybrid Approaches 418
9.6 Conclusions 419
Notes 420
References 420
xii Contents
10 Software Fault Localization in Spreadsheets 425

Birgit Hofer and Franz Wotawa
10.1 Motivation 425
10.2 Definition of the Spreadsheet Language 427
10.3 Cones 430
10.4 Spectrum-Based Fault Localization 431
10.5 Model-Based Spreadsheet Debugging 435
10.6 Repair Approaches 440
10.7 Checking Approaches 443
10.8 Testing 445
10.9 Conclusion 446
Notes 446
References 447
11 Theoretical Aspects of Software Fault Localization 451

Xiaoyuan Xie and W. Eric Wong
11.2 A Model-Based Hybrid Analysis 452
11.2.1 The Model Program Segment 452
11.2.2 Important Findings 454
11.2.3 Discussion 454
11.3 A Set-Based Pure Theoretical Framework 455
11.3.1 Definitions and Theorems 455
11.3.2 Evaluation 457
11.3.3 The Maximality Among All Investigated Formulas 461
11.4 A Generalized Study 462
11.4.1 Spectral Coordinate for SBFL 462
11.4.2 Generalized Maximal and Greatest Formula in F 464
11.5 About the Assumptions 465
11.5.1 Omission Fault and 100% Coverage 465
11.5.2 Tie-Breaking Scheme 467
11.5.3 Multiple Faults 467
11.5.4 Some Plausible Causes for the Inconsistence Between Empirical and
Theoretical Analyses 468
Notes 469
References 470
12 Software Fault Localization for Programs with Multiple Bugs 473

Ruizhi Gao, W. Eric Wong, and Rui Abreu
12.2 One-Bug-at-a-Time 474
Contents xiii
12.3 Two Techniques Proposed by Jones et al. 475

12.3.1 J1: Clustering Based on Profiles and Fault Localization Results 476
12.3.1.1 Clustering Profile-Based Behavior Models 476
12.3.1.2 Using Fault Localization to Stop Clustering 478
12.3.1.3 Using Fault Localization Clustering to Refine Clusters 479
12.3.2 J2: Clustering Based on Fault Localization Results 480
12.4 Localization of Multiple Bugs Using Algorithms from Integer Linear
Programming 481
12.5 MSeer: an Advanced Fault Localization Technique for Locating Multiple
Bugs in Parallel 483
12.5.1 MSeer 485
12.5.1.1 Representation of Failed Test Cases 485
12.5.1.2 Revised Kendall tau Distance 486
12.5.1.3 Clustering 488
12.5.1.4 MSeer: a Technique for Locating Multiple Bugs in Parallel 494
12.5.2 A Running Example 496
12.5.3 Case Studies 499
12.5.3.1 Subject Programs and Data Collections 499
12.5.3.2 Evaluation of Effectiveness and Efficiency 501
12.5.3.3 Results 503
12.5.4 Discussions 510
12.5.4.1 Using Different Fault Localization Techniques 510
12.5.4.2 Apply MSeer to Programs with a Single Bug 510
12.5.4.3 Distance Metrics 512
12.5.4.4 The Importance of Estimating the Number of Clusters and Assigning
Initial Medoids 514
12.6 Spectrum-Based Reasoning for Fault Localization 514
12.6.1 Barinel 515
12.6.2 Results 517
12.7 Other Studies 518
12.8 Conclusion 520
Notes 521
References 522
13 Emerging Aspects of Software Fault Localization 529

T.H. Tse, David Lo, Alex Gorce, Michael Perscheid, Robert Hirschfeld,
and W. Eric Wong
13.2 Application of the Scientific Method to Fault Localization 530
13.2.1 Scientific Debugging 531
13.2.2 Identifying and Assigning Bug Reports to Developers 532
xiv Contents
13.2.3 Using Debuggers in Fault Localization 534

13.3 Fault Localization in the Absence of Test Oracles by Semi-proving of
Metamorphic Relations 538
13.3.1 Metamorphic Testing and Metamorphic Relations 539
13.3.2 The Semi-proving Methodology 541
13.3.2.1 Semi-proving by Symbolic Evaluation 541
13.3.2.2 Semi-proving as a Fault Localization Technique 542
13.3.3 The Need to Go Beyond Symbolic Evaluation 543
13.3.4 Initial Empirical Study 543
13.3.5 Detailed Illustrative Examples 544
13.3.5.1 Fault Localization Example Related to Predicate Statement 544
13.3.5.2 Fault Localization Example Related to Faulty Statement 548
13.3.5.3 Fault Localization Example Related to Missing Path 552
13.3.5.4 Fault Localization Example Related to Loop 556
13.3.6 Comparisons with Related Work 558
13.4 Automated Prediction of Fault Localization Effectiveness 560
13.4.1 Overview of PEFA 561
13.4.2 Model Learning 564
13.4.3 Effectiveness Prediction 564
13.5 Integrating Fault Localization into Automated Test Generation
Tools 565
13.5.1 Localization in the Context of Automated Test Generation 566
13.5.2 Automated Test Generation Tools Supporting Localization 567
13.5.3 Antifragile Tests and Localization 568
Notes 569
References 569
Index 581
xv
Editor Biographies
W. Eric Wong, PhD, is a Full Professor, Director of Software Engineering

Program, and the Founding Director of Advanced Research Center for Software
Testing and Quality Assurance in Computer Science at the University of Texas
at Dallas. He also has an appointment as a Guest Researcher with the National
Institute of Standards and Technology, an agency of the US Department of
Commerce.
Professor Wong’s research focuses on helping practitioners improve software
quality while reducing production cost. In particular, he is working on software
testing, program debugging, risk analysis, safety, and reliability. He was the recip-
ient of the ICST 2020 (The 13th IEEE International Conference on Software Test-
ing, Verification, and Validation) Most Influential Paper award for his paper titled
“Using Mutation to Automatically Suggest Fixes for Faulty Programs” published at
ICST 2010. He also received a JSS 2020 (Journal of Systems and Software) Most
Influential Paper award for his paper titled “A Family of Code Coverage-based
Heuristics for Effective Fault Localization” published in Volume 83, Issue 2,
2010. The conference version of this paper received the Best Paper Award at
the 31st IEEE International Computer Software and Applications Conference.
Professor Wong was the award recipient of the 2014 IEEE Reliability Society
Engineer of the Year. In addition, he was the Editor-in-Chief of the IEEE Transac-
tions on Reliability for six years ending on 31 May 2022. He has also been an Area
Editor of Elsevier’s Journal of Systems and Software since 2017. Dr. Wong received
his MS and PhD in Computer Science from Purdue University, West Lafayette,
IN, USA. More details can be found at Professor Wong’s homepage https://
personal.utdallas.edu/~ewong
T.H. Tse received his PhD in Information Systems from the London School
of Economics and was a Visiting Fellow at the University of Oxford. He is an
Honorary Professor in Computer Science with The University of Hong Kong after
retiring from the full professorship in 2014. His research interest is in program
testing and debugging. He has more than 270 publications, including a book in
xvi Editor Biographies
the Cambridge Tracts in Theoretical Computer Science series, Cambridge Univer-

sity Press. He is ranked internationally as no. 2 among experts in metamorphic
testing. The 2010 paper titled “Adaptive Random Testing: the ART of Test Case
Diversity” by Professor Tse and team has been selected as the Grand Champion
of the Most Influential Paper Award by the Journal of Systems and Software.
Professor Tse is a Steering Committee Chair of the IEEE International Confer-
ence on Software Quality, Reliability, and Security; and an Associate Editor of
IEEE Transactions on Reliability. He served on the Search Committee for the
Editor-in-Chief of IEEE Transactions on Software Engineering in 2013. He is a Life
Fellow of the British Computer Society and a Life Senior Member of the IEEE.
He was awarded an MBE by Queen Elizabeth II of the United Kingdom.
xvii
List of Contributors
Rui Abreu Alex Gorce

Department of Informatics School of Informatics, Computing,
Engineering, Faculty of Engineering and Cyber Systems, Northern
University of Porto, Porto, Portugal Arizona University, Flagstaff
AZ, USA
Hira Agrawal
Peraton Labs, Basking Ridge, NJ, USA Robert Hirschfeld
Department of Computer Science
Peggy Cellier Universität Potsdam, Brandenburg
INSA, CNRS, IRISA, Universite de Germany
Rennes, Rennes, France
Birgit Hofer
Vidroha Debroy Institute of Software Technology
Department of Computer Science Graz University of Technology, Graz
University of Texas at Dallas Austria
Richardson, TX, USA
and Linghuan Hu
Dottid Inc., Dallas, TX, USA Google Inc., Mountain View
CA, USA
Mireille Ducassé
INSA, CNRS, IRISA, Universite de Hua Jie Lee
Rennes, Rennes, France School of Computing, Macquarie
University, Sydney, NSW
Sébastien Ferré Australia
CNRS, IRISA, Universite de Rennes
Rennes, France Dongcheng Li
Ruizhi Gao University of Texas at Dallas
Sonos Inc., Boston, MA, USA Richardson, TX, USA
xviii List of Contributors
Yihao Li T.H. Tse

School of Information and Electrical Department of Computer Science, The
Engineering, Ludong University University of Hong Kong, Pokfulam
Yantai, China Hong Kong
David Lo W. Eric Wong

School of Computing and Information Department of Computer Science
Systems, Singapore Management University of Texas at Dallas
University, Singapore Richardson, TX, USA
Wolfgang Mayer
Advanced Computing Research Franz Wotawa
Centre, University of South Australia Institute of Software Technology, Graz
Adelaide, SA, Australia University of Technology, Graz
Austria
Lee Naish
School of Computing and Information Xin Xia
Systems, The University of Melbourne Software Engineering Application
Melbourne, Australia Technology Lab, Huawei, China
Michael Perscheid Xiaoyuan Xie

Department of Computer Science School of Computer Science, Wuhan
Universität Potsdam, Brandenburg University, Wuhan, China
Germany
Xiangyu Zhang
Olivier Ridoux
CNRS, IRISA, Universite de Rennes
Purdue University, West Lafayette
Rennes, France
IN, USA
Markus Stumptner
Advanced Computing Research Zhenyu Zhang
Centre, University of South Australia Institute of Software, Chinese
Adelaide, SA, Australia Academy of Sciences, Beijing, China
1
Software Fault Localization: an Overview of Research,

Techniques, and Tools
W. Eric Wong1, Ruizhi Gao2, Yihao Li3, Rui Abreu4, Franz Wotawa5,
and Dongcheng Li1
1
Department of Computer Science, University of Texas at Dallas, Richardson, TX, USA
2
Sonos Inc., Boston, MA, USA
3
School of Information and Electrical Engineering, Ludong University, Yantai, China
4
Department of Informatics Engineering, Faculty of Engineering, University of Porto, Porto, Portugal
5
Institute of Software Technology, Graz University of Technology, Graz, Austria
1.1 Introduction
Software fault localization, the act of identifying the locations of faults in a

program, is widely recognized to be one of the most tedious, time-consuming,
and expensive – yet equally critical – activities in program debugging. Due to
the increasing scale and complexity of software today, manually locating faults
when failures occur is rapidly becoming infeasible, and consequently, there is a
strong demand for techniques that can guide software developers to the locations
of faults in a program with minimal human intervention. This demand in turn has
fueled the proposal and development of a broad spectrum of fault localization tech-
niques, each of which aims to streamline the fault localization process and make it
more effective by attacking the problem in a unique way. In this book, we catego-
rize and provide a comprehensive overview of such techniques and discuss key
issues and concerns that are pertinent to software fault localization.
Software is fundamental to our lives today, and with its ever-increasing usage
and adoption, its influence is practically ubiquitous. At present, software is not
just employed in, but is critical to, many security and safety-critical systems in
industries such as medicine, aeronautics, and nuclear energy. Not surprisingly,
This chapter is an extension of Wong, W.E., Gao, R., Li, Y., Abreu, R., and Wotawa, F. (2016).
A survey on software fault localization. IEEE Transactions on Software Engineering 42 (8): 707–740.
Handbook of Software Fault Localization: Foundations and Advances, First Edition.

Edited by W. Eric Wong and T.H. Tse.
© 2023 The Institute of Electrical and Electronics Engineers, Inc.
Published 2023 by John Wiley & Sons, Inc.
2 1 Software Fault Localization: an Overview of Research, Techniques, and Tools
this trend has been accompanied by a drastic increase in the scale and complexity
of software. Unfortunately, this has also resulted in more software bugs, which
often lead to execution failures with huge losses [1–3]. On 15 January 1990, the
AT&T operation center in Bedminster, NJ, USA, had an increase of red warning
signals appearing across the 75 screens that indicated the status of parts of the
AT&T worldwide network. As a result, only about 50 percent of the calls made
through AT&T were connected. It took nine hours for the AT&T technicians to
identify and fix the issue caused by a misplaced break statement in the code.
AT&T lost $60 to $75 million in this accident [4].
Furthermore, software faults in safety-critical systems have significant ramifica-
tions not only limited to financial loss, but also to loss of life, which is alarming [5].
On 20 December 1995, a Boeing 757 departed from Miami, FL, USA. The aircraft
was heading to Cali, Colombia. However, it crashed into a 9800 feet mountain.
A total of 159 deaths resulted; leaving only five passengers alive. This event
marked the highest death toll of any accident in Colombia at the time. This acci-
dent was caused by the inconsistencies between the naming conventions of the
navigational charts and the flight management system. When the crew looked
up the waypoint “Rozo”, the chart indicated the letter “R” as its identifier. The
flight management system, however, had the city paired with the word “Rozo”.
As a result, when the pilot entered the letter “R”, the system did not know if
the desired city was Rozo or Romeo. It automatically picked Romeo, which is a
larger city than Rozo, as the next waypoint.
A 2006 report from the National Institute of Standards and Technology (NIST)
[6] indicated that software errors are estimated to cost the US economy $59.5 bil-
lion annually (0.6 percent of the GDP); the cost has undoubtedly grown since then.
Over half the cost of fixing or responding to these bugs is passed on to software
users, while software developers and vendors absorb the rest.
Even when faults in software are discovered due to erroneous behavior or some
other manifestation of the fault(s),1 finding and fixing them is an entirely different
matter. Fault localization, which focuses on the former, i.e. identifying the loca-
tions of faults, has historically been a manual task that has been recognized to
be time-consuming and tedious as well as prohibitively expensive [7], given the
size and complexity of large-scale software systems today. Furthermore, manual
fault localization relies heavily on the software developer’s experience, judgment,
and intuition to identify and prioritize code that is likely to be faulty. These limita-
tions have led to a surge of interest in developing techniques that can partially or
fully automate the localization of faults in software while reducing human input.
Though some techniques are similar and some very different (in terms of the type
of data consumed, the program components focused on, comparative effectiveness
and efficiency, etc.), they each try to attack the problem of fault localization from a
unique perspective, and typically offer both advantages and disadvantages relative
1.1 Introduction 3
to one another. With many techniques already in existence and others continually
being proposed, as well as with advances being made both from a theoretical and
practical perspective, it is important to catalog and overview current state-of-the-
art techniques in fault localization in order to offer a comprehensive resource for
those already in the area and those interested in making contributions to it.
In order to provide a complete survey covering most of the publications related
to software fault localization since the late 1970s, in this chapter, we created a pub-
lication repository that includes 587 papers published from 1977 to 2020. We also
searched for Masters’ and PhD theses closely related to software fault localization,
which are listed in Table 1.1.
Table 1.1 A list of recent PhD and Masters’ theses on software fault localization.
Author Title Degree University Year
Ehud Y. Shapiro [8] Algorithmic Program PhD Yale 1983

Debugging University
Hiralal Agrawal [9] Towards Automatic PhD Purdue 1991
Debugging of University
Computer Programs
Hsin Pan [10] Software debugging PhD Purdue 1993
with dynamic University
instrumentation and
test-based knowledge
W. Bond Gregory [11] Logic Programs for PhD Carleton 1994
Consistency-based University
Diagnosis
Benjamin Robert Liblit [12] Cooperative Bug PhD The 2004
Isolation University of
California,
Berkeley
Bernhard Peischl [13] Automated Source- PhD Graz 2004
Level Debugging of University of
Synthesizeable VHDL Technology
Designs
Haifeng He [14] Automated Master University of 2004
Debugging using Arizona
Path-based Weakest
Preconditions
Alex David Groce [15] Error Explanation PhD Carnegie 2005
and Fault Mellon
Localization with University
Distance Metrics
(Continued)
Table 1.1 (Continued)
Emmanuel Renieris [16] A Research PhD Brown 2005

Framework for University
Software-Fault
Localization Tools
Daniel Köb [17] Extended Modeling PhD Graz 2005
for Automatic Fault University of
Localization in Technology
Object-Oriented
Software
David Hovemeyer [18] Simple and Effective PhD University of 2005
Static Analysis to Find Maryland
Bugs
Peifeng Hu [19] Automated Fault PhD The 2006
Localization: University of
a Statistical Predicate Hong Kong
Analysis Approach
Xiangyu Zhang [20] Fault Localization via PhD The 2006
Precise Dynamic University of
Slicing Arizona
Rafi Vayani [21] Improving Automatic Master Delft 2007
Software Fault University of
Localization Technology
Ramana Rao Kompella [22] Fault Localization in PhD University of 2007
Backbone Networks California,
San Diego
Andreas Griesmayer [23] Debugging Software: PhD Graz 2007
from Verification to University of
Repair Technology
Tao Wang [24] Post-Mortem PhD Fudan 2007
Dynamic Analysis For University
Software Debugging
Sriraman Tallam [25] Fault Location and PhD The 2007
Avoidance in Long- University of
Running Arizona
Multithreaded
Applications
Ophelia C. Chesley [26] CRISP-A fault Master Rutgers, The 2007
localization Tool for State
Java Programs University of
New Jersey
Shan Lu [27] Understanding, PhD University of 2008
Detecting and Illinois at
Exposing Urbana-
Concurrency Bugs Champaign
1.1 Introduction 5
Naveed Riaz [28] Automated Source- PhD Graz 2008

Level Debugging of University of
Synthesizable Verilog Technology
Designs
James Arthur Jones [29] Semi-Automatic Fault PhD Georgia 2008
Localization Institute of
Technology
Zhenyu Zhang [30] Software Debugging PhD The 2009
through Dynamic University of
Analysis of Program Hong Kong
Structures
Rui Abreu [31] Spectrum-based Fault PhD Delft 2009
Localization in University of
Embedded Software Technology
Dennis Jefferey [32] Dynamic State PhD University of 2009
Alteration California
Techniques for Riverside
Automatically
Locating Software
Errors
Xinming Wang [33] Automatic PhD The Hong 2010
Localization of Code Kong
Omission Faults University of
Science and
Technology
Fabrizio Pastore [34] Automatic Diagnosis PhD University of 2010
of Software Milan
Functional Faults by Bicocca
Means of Inferred
Behavioral Models
Mihai Nica [35] On the Use of PhD Graz 2010
Constraints in University of
Automated Program Technology
Debugging – From
Foundations to
Empirical Results
Zachary P. Fry [36] Fault Localization Master The 2011
Using Textual University of
Similarities Virginia
Hua Jie Lee [37] Software Debugging PhD The 2011
Using Program University of
Spectra Melbourne
(Continued)
Vidroha Debroy [38] Towards the PhD The 2011

Automation of University of
Program Debugging Texas at
Dallas
Alberto Gonzalez Sanchez Cost Optimizations in PhD Delft 2011
[39] Runtime Testing and University of
Diagnosis Technology
Jared David DeMott [40] Enhancing PhD Michigan 2012
Automated Fault State
Discovery and University
Analysis
Xin Zhang [41] Secure and Efficient PhD Carnegie 2012
Network Fault Mellon
Localization University
Xiaoyuan Xie [42] On the Analysis of PhD Swinburne 2012
Spectrum-based Fault University of
Alexandre Perez [43] Dynamic Code Master University of 2012
Coverage with Porto
Progressive Detail
Levels
Raul Santelices [44] Change-effects PhD Georgia 2012
Analysis for Effective Institute of
Testing and Technology
Validation of Evolving
Software
George. K. Baah [45] Statistical Causal PhD Georgia 2012
Analysis for Fault Institute of
Swarup K. Sahoo [46] A Novel Invariants- PhD University of 2012
based Approach for Illinois at
Automated Software Urbana-
Fault Localization Champaign
Birgit Hofer [47] From Fault PhD Graz 2013
Localization of University of
Programs written in Technology
3rd level Language to
Spreadsheets
Aritra Bandyopadhyay [48] Mitigating the Effect PhD Colorado 2013
of Coincidental State
Correctness in University
Spectrum-based Fault
Localization
1.1 Introduction 7
Shounak Roychowdhury A Mixed Approach to PhD The 2013

[49] Spectrum-based Fault University of
Localization Using Texas at
Information Theoretic Austin
Foundations
Shaimaa Ali [50] Localizing State- PhD The 2013
Dependent Faults University of
Using Associated Western
Sequence Mining Ontario
Christian Kuhnert [51] Data-driven Methods PhD Karlsruhe 2013
for Fault Localization Institute of
in Process Technology Technology
Dawei Qi [52] Semantic Analyses to PhD Tsinghua 2013
Detect and Localize University
Software Regression
Errors
William N. Sumner [53] Automated Failure PhD Purdue 2013
Explanation Through University
Execution
Comparison
Mark A. Hays [54] A Fault-based Model PhD University of 2014
of Fault Localization Kentucky
Techniques
Sang Min Park [55] Effective Fault PhD Georgia 2014
Localization Institute of
Techniques for Technology
Concurrent Software
Gang Shu [56] Statistical Estimation PhD Case Western 2014
of Software Reliability Reserve
and Failure-causing University
Effect
Lucia [57] Ranking-based PhD Singapore 2014
Approaches for Management
Localizing Faults University
Seok-Hyeon Moon [58] Effective Software Master Korea 2014
Fault Localization Advanced
using Dynamic Institute of
Program Behaviors Science and
Technology
(Continued)
Yepang Liu [59] Automated Analysis PhD The Hong 2014

of Energy Efficiency Kong
and Performance for University of
Mobile Applications Science and
Technology
Cuiting Chen [60] Automated Fault PhD Delft 2015
Localization for University of
Service-Oriented Technology
Software Systems
Matthias Rohr [61] Workload-sensitive PhD Kiel 2015
Timing Behavior University
Analysis for Fault
Localization in
Software Systems
Ozkan Bayraktar [62] Ela: an Automated PhD The Middle 2015
Statistical Fault East
Localization Technical
Technique University
Azim Tonzirul [63] Fault Discovery, PhD University of 2016
Localization, and California
Recovery in Riverside
Smartphone Apps
Laleh Fault Localization PhD The 2016
Gholamosseinghandehari based on University of
[64] Combinatorial Texas at
Testing Arlington
Ruizhi Gao [65] Advanced Software PhD The 2017
Fault Localization for University of
Programs with Texas at
Multiple Bugs Dallas
Shih-Feng Sun [66] Statistical Fault PhD Case Western 2017
Localization and Reserve
Causal Interactions University
Rongxin Wu [67] Automated PhD The Hong 2017
Techniques for Kong
Diagnosing Crashing University of
Bugs Science and
Technology
Arjun Roy [68] Simplifying dataleft PhD University of 2018
fault detection and California
localization San Diego
1.1 Introduction 9
Yun Guo [69] Towards PhD George 2018

Automatically Mason
Localizing and University
Repairing SQL Faults
Nasir Safdari [70] Learning to Rank Master Rochester 2018
Relevant Files for Bug Institute of
Reports Using Technology
Domain knowledge,
Replication and
Extension of a
Learning-to-Rank
Approach
Dai Ting [71] A Hybrid Approach to PhD North 2019
Cloud System Carolina
Performance Bug State
Detection, Diagnosis University
and Fix
George Thompson [72] Towards Automated Master North 2020
Fault Localization for Carolina
Prolog A&T State
University
Xia Li [73] An Integrated PhD The 2020
Approach for University of
Automated Software Texas at
Debugging via Dallas
Machine Learning
and Big Code Mining
Muhammad Ali Gulzar Automated Testing PhD University of 2020
[74] and Debugging for Big California,
Data Analytics Los Angeles
Mihir Mathur [75] Leveraging Master University of 2020
Distributed Tracing California,
and Container Los Angeles
Cloning for Replay
Debugging of
Microservices
All papers in our repository2 are sorted by year, and the result is displayed in
Figure 1.1. As shown in the figure, the number of publications grew rapidly after
2001, indicating that more and more researchers began to devote themselves to the
area of software fault localization over the last two decades.
40
35
Number of publications
30
25
20
15
10
5
0
77–86
87
88
89
90
91
92
93
94
95
96
97
98
99
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
Year
Figure 1.1 Papers on software fault localization from 1977 to 2020.
12
10
Number of publications
0
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
Year
Figure 1.2 Publications on software fault localization in top venues from 2001 to 2020.
Also, as per our repository, Figure 1.2. gives the number of publications related
to software fault localization that have appeared in top quality and leading jour-
nals and conferences that focus on Software Engineering – IEEE Transactions
on Software Engineering, ACM Transactions on Software Engineering and
1.1 Introduction 11
Methodology, International Conference on Software Engineering, ACM Interna-

tional Symposium on Foundations of Software Engineering, and ACM Interna-
tional Conference on Automated Software Engineering – from 2001 to 2019.
This trend again supports the claim that software fault localization is not just
an important but also a popular research topic and has been discussed very heavily
in top quality software engineering journals and conferences over the last two
decades.
There is thus a rich collection of literature on various techniques that aim to
facilitate fault localization and make it more effective. Despite the fact that these
techniques share similar goals, they can be quite different from one another and
often stem from ideas that originate from several different disciplines. While we
aim to comprehensively cover as many fault localization techniques as possible,
no article, regardless of breadth or depth, can cover all of them. In this book,
our primary focus is on the techniques for locating Bohrbugs [76]. Those for diag-
nosing Mandelbugs [76] such as performance bugs, memory leaks, software bloats,
and security vulnerabilities are not included in the scope. Also, due to space lim-
itations, we group techniques into appropriate categories for collective discussion
with an emphasis on the most important features and leave other details of these
techniques to their respectively published papers. This is especially the case for
techniques targeting a specific application domain, such as fault localization for
concurrency bugs and spreadsheets. For these, we provide a review that helps
readers with general understanding.
The following terms appear repeatedly throughout this chapter, and thus
for convenience, we provide definitions for them here per the taxonomy
provided in [77]:
•• A failure is when a service deviates from its correct behavior.

An error is a condition in a system that may lead to a failure.
• A fault is the underlying cause of an error, also known as a bug.
In this book, we group fault localization techniques into appropriate categories

(including traditional, slicing-based, spectrum-based, statistics-based, machine
learning-based, data mining-based, information-retrieval-based, model-based,
spreadsheet-based, and emerging techniques) for collective discussion with an
emphasis on the most important features. We introduce the popular subject pro-
grams that have been used in different case studies and discuss how these programs
have evolved through the years. Different evaluation metrics to assess the effec-
tiveness of fault localization techniques are also described as well as a discus-
sion of fault localization tools and theoretical studies. Moreover, we explore
some critical aspects of software fault localization, including (i) fault
localization for programs with multiple bugs, (ii) inputs, outputs, and impact of
test cases, (iii) coincidental correctness, (iv) faults introduced by missing code,
(v) combination of multiple fault localization techniques, (vi) ties within fault
localization rankings, and (vii) fault localization for concurrency bugs. The gen-
eral information of each chapter is introduced as follows.
This book begins by introducing traditional software fault localization techni-
ques in Chapter 2, including program logging, assertions, and breakpoints. Exam-
ples will also be provided to clearly explain these techniques.
Program slicing is a technique to abstract a program into a reduced form by
deleting irrelevant parts such that the resulting slice will still behave in the same
way as the original program with respect to certain specifications. Chapter 3 intro-
duces slicing-based fault localization techniques, which can be classified into three
major categories: static slicing, dynamic slicing, and execution slicing-based tech-
niques. Examples will be given to illustrate the differences among these categories.
Techniques based on other slicing such as dual slicing, thin slicing, and relevant
slicing are also included.
Program spectrum-based techniques are presented in Chapter 4. A program
spectrum details the execution information of a program from certain perspec-
tives, such as execution information for conditional branches or loop-free intra-
procedural paths. It can be used to track program behavior. A list of different kinds
of program spectra will be provided. Also discussed are issues and concerns related
to program spectrum-based techniques.
Software fault localization techniques based on well-defined statistical analyses
(e.g. parametric and nonparametric hypothesis testing, causal-inference analysis,
and cross tabulation analysis) are described in Chapter 5.
Machine learning is the study of computer algorithms that improve through
experience. These techniques are adaptive and robust and can produce models
based on data, with limited human interaction. Such properties have led to their
employment in many disciplines including bioinformatics, natural language pro-
cessing, cryptography, computer vision, etc. In the context of software fault local-
ization, the problem at hand can be identified as trying to learn or deduce the
location of a fault based on input data such as statement coverage and the execu-
tion result (success or failure) of each test case. Chapter 6 covers fault localization
techniques based on machine learning techniques.
Along the lines of machine learning, data mining also seeks to produce a model
using pertinent information extracted from data. Data mining can uncover hidden
patterns in samples of data that may not be discovered by manual analysis alone,
especially due to the sheer volume of information. Efficient data mining techni-
ques transcend such problems and do so in reasonable amounts of time with high
1.1 Introduction 13
degrees of accuracy. The software fault localization problem can be abstracted to a

data mining problem – for example, we wish to identify the pattern of statement
execution that leads to a failure. Data mining-based techniques are reviewed and
analyzed in Chapter 7.
Chapter 8 introduces information retrieval (IR)-based fault localization techni-
ques. Fault localization is the problem of identifying buggy source code files given
a textual description of a bug. This problem is important since many bugs are
reported through bug tracking systems like Bugzilla and Jira, and the number
of bug reports is often too many for developers to handle. This necessitates an auto-
mated tool that can help developers identify relevant files given a bug report. Due
to the textual nature of bug reports, IR techniques are often employed to solve this
problem. Many IR-based fault localization techniques have been proposed in the
literature.
Program models can be used for software fault localization. The first part of
Chapter 9 discusses techniques based on different program models such as
dependency-based models, abstraction-based models, and value-based models.
The second part emphasizes model checking-based techniques.
Spreadsheets are one of the most popular types of end-user software and have
been used in many sectors, especially in business. Chapter 10 discusses how tech-
niques using value-based or dependency-based models can effectively locate bugs
in cells with erroneous formulae and avoid incorrect computation.
Instead of being evaluated empirically, the effectiveness of software fault local-
ization techniques can also be analyzed from theoretical perspectives. Chapter 11
discusses theoretical studies on software fault localization.
Many of the software fault localization techniques assume that there is only one
bug in the program under study. This assumption may not be realistic in practice.
Mixed failed test cases associated with different causative bugs may reduce the
fault localization effectiveness. In Chapter 12, we present fault localization tech-
niques for programs with multiple bugs.
Finally, Chapter 13 presents emerging aspects of software fault localization,
including how to apply the scientific method to fault localization, how to locate
faults when the oracle is not available, how to automatically predict fault locali-
zation effectiveness, and how to integrate fault localization into automatic test
generation tools.
The remaining part of this Chapter is organized in the following manner: we begin
by describing traditional and intuitive fault localization techniques in Section 1.2,
moving on to more advanced and complex techniques in Section 1.3. In
Section 1.4, we list some of the popular subject programs that have been used
in different case studies and discuss how these programs have evolved through the
years. Different evaluation metrics to assess the effectiveness of fault localization
techniques are described in Section 1.5, followed by a discussion of fault localiza-
tion tools in Section 1.6. Finally, critical aspects and conclusions are presented in
Section 1.7 and Section 1.8, respectively.
1.2 Traditional Fault Localization Techniques
This section describes traditional and intuitive fault localization techniques,

including program logging, assertions, breakpoints, and profiling.
1.2.1 Program Logging

Statements (such as print) used to produce program logging are commonly
inserted into the code in an ad-hoc fashion to monitor variable values and other
program state information [78]. When abnormal program behavior is detected,
developers examine the program log in terms of saved log files or printed run-time
information to diagnose the underlying cause of failure.
1.2.2 Assertions
Assertions are constraints added to a program that have to be true during the cor-
rect operation of a program. Developers specify these assertions in the program
code as conditional statements that terminate execution if they evaluate to false.
Thus, they can be used to detect erroneous program behavior at runtime. More
details of using assertions for program debugging can be found in [79, 80].
1.2.3 Breakpoints
Breakpoints are used to pause the program when execution reaches a specified
point and allow the user to examine the current state. After a breakpoint is trig-
gered, the user can modify the value of variables or continue the execution to
observe the progression of a bug. Data breakpoints can be configured to trigger
when the value changes for a specified expression, such as a combination of
variable values. Conditional breakpoints pause execution only upon the satisfac-
tion of a predicate specified by the user. Early studies (e.g. [81, 82]) use this
approach to help developers locate bugs while a program is executed under
the control of a symbolic debugger. The same approach is also adopted by more
advanced debugging tools such as GNU GDB [83] and Microsoft Visual Studio
Debugger [84].
1.2.4 Profiling
Profiling is the runtime analysis of metrics such as execution speed and memory
usage, which is typically aimed at program optimization. However, it can also be
leveraged for debugging activities, such as the following:
•• Detecting unexpected execution frequencies of different functions (e.g. [85]).

Identifying memory leaks or code that performs unexpectedly poorly (e.g. [86]).
• Examining the side effects of lazy evaluation (e.g. [87]).
Tools that use profiling for program debugging include GNU’s gprof [88] and the
Eclipse plugin TPTP [89].
1.3 Advanced Fault Localization Techniques
With the massive size and scale of software systems today, traditional fault local-
ization techniques are not effective in isolating the root causes of failures. As a
result, many advanced fault localization techniques have surfaced recently using
the idea of causality [90, 91], which is related to philosophical theories with an
objective to characterize the relationship between events/causes (program bugs
in our case) and a phenomenon/effect (execution failures in our case). There
are different causality models [91] such as counterfactual-based, probabilistic-
or statistical-based, and causal calculus models. Among these, probabilistic causal-
ity models are the most widely used in fault localization to identify suspicious code
that is responsible for execution failures.
In this chapter, we classify fault localization techniques into nine categories,
including slicing-based, spectrum-based, statistics-based, machine learning-based,
data mining-based, IR-based, model-based, spreadsheet-based techniques, and
additional emerging techniques. Many studies that evaluate the effectiveness of
specific fault localization techniques have been reported [92–124]. However, none
of them offer a comprehensive discussion on all these techniques.
1.3.1 Slicing-Based Techniques

Program slicing is a technique to abstract a program into a reduced form by delet-
ing irrelevant parts such that the resulting slice will still behave the same as the
original program with respect to certain specifications. Hundreds of papers on this
topic have been published [125–127] since Weiser first proposed static slicing in
1979 [128].
One of the important applications of static slicing [129] is to reduce the search
domain while programmers locate bugs in their programs. This is based on the
idea that if a test case fails due to an incorrect variable value at a statement, then
the defect should be found in the static slice associated with that variable-
statement pair, allowing us to confine our search to the slice rather than looking
at the entire program. Lyle and Weiser extend the above approach by constructing
a program dice (as the set difference of two groups of static slices) to further reduce
the search domain for possible locations of a fault [130]. Although static slice-
based techniques have been experimentally evaluated and confirmed to be useful
in fault localization [109], one problem is that handling pointer variables can make
data-flow analysis inefficient because large sets of data facts that are introduced by
dereferences of pointer variables need to be stored. Equivalence analysis, which
identifies equivalence relationships among the various memory locations accessed
by a procedure, is used to improve the efficiency of data-flow analyses in the pres-
ence of pointer variables [131]. Two equivalent memory locations share identical
sets of data facts in a procedure. As a result, data-flow analysis only needs to com-
pute information for a representative memory location, and data-flow for other
equivalent locations can be garnered from the representative location. Static sli-
cing is also applied for fault localization in binary executables [132], and type-
checkers [133].
A disadvantage of static slicing is that the slice for a given variable at a given
statement contains all the executable statements that could possibly affect the
value of this variable at the statement. As a result, it might generate a dice with
certain statements that should not be included. This is because we cannot predict
some run-time values via a static analysis. To deal with the imprecision of static
slicing, Zhang and Santelices [134] propose PRIOSLICE to refine the results
reported by static slicing.
A good approach to exclude such extra statements from a dice (as well as a
slice) is to use dynamic slicing [135, 136] instead of static slicing, as the former
can identify the statements that do affect a particular value observed at a partic-
ular location, rather than possibly affecting such a value as with the latter. Stud-
ies such as [121, 122, 132, 134, 137–159], which use the dynamic slicing concept
in program debugging, have been reported. In [156], Wotawa combines dynamic
slicing with model-based diagnosis to achieve more effective fault localization.
Using a given test suite against a program, dynamic slices for erroneous variables
discovered are collected. Hitting-sets are constructed, which contain at least one
statement from each dynamic slice. The probability that a statement is faulty is
calculated based on the number of hitting-sets that cover that statement [160].
Zhang et al. [157] propose the multiple-points dynamic slicing technique, which
intersects slices of three techniques: backward dynamic slice (BwS), forward
dynamic slice (FwS), and bidirectional dynamic slice (BiS). The BwS captures
any executed statements that affect the output value of a faulty variable, while
the FwS is computed based on the minimal input difference between a failed
and a successful test case, isolating the parts of the input that trigger a failure.
The BiS flips the values of certain predicates in the execution of a failed test case
so that the program generates a correct output. Qian and Xu [152] propose a sce-
nario-oriented program slicing technique. A user-specified scenario is identified
as the extra slicing parameter, and all program parts related to a special compu-
tation are located under the given execution scenario. There are three key steps to
implementing the scenario-oriented slicing technique: scenario input, identifica-
tion of scenario relevant codes, and, finally, gathering of scenario-oriented slices.
Ocariza et al. [150] propose an automated technique based on dynamic backward
slicing of the web application to localize DOM-related JavaScript faults. The pro-
posed fault localization approach is implemented in a tool called AUTOFLOX.
Ishii and Kutsuna [143] propose an effective fault localization method for Simulink
model. They use the satisfiability modulo theories (SMT) solver to generate distinct
dynamic slicing result for each failed test case. Guo et al. [161] apply dynamic sli-
cing and delta debugging to localize faults in SQL predicates. First, in order to iden-
tify any suspicious clause, row-based dynamic slicing execute the query for each
row in the provided test data, and record the predicate and the Boolean result
for each clause. Second, delta debugging is employed to mutate the column values
of the failed rows and replace them with the corresponding values from the suc-
cessful rows. If the mutated row passes, then the clause containing this column is
faulty.
One limitation of dynamic slicing-based techniques is that they cannot capture
execution omission errors, which may cause the execution of certain critical
statements in a program to be omitted and thus result in failures [162]. Gyimothy
et al. [163] propose the use of relevant slicing to locate faulty statements respon-
sible for execution omission errors. Given a failed execution, the relevant slicing
first constructs a dynamic dependence graph in the same way that classic
dynamic slicing does. It then augments the dynamic dependence graph with
potential dependence edges, and a relevant slice is computed by taking the tran-
sitive closure of the incorrect output on the augmented dynamic dependence
graph. However, incorrect dependencies between program statements may be
included to produce oversized relevant slices. To address this problem, Zhang
et al. [162] introduce the concept of implicit dependencies, in which dependencies
can be obtained by predicate switching. A similar idea has been used by Weer-
atunge et al. [164] to identify root causes of omission errors in concurrent pro-
grams, in which dual slicing, a combination of dynamic slicing and trace
differencing, is used. Wang and Liu [165] propose a hierarchical multiple
predicate switching technique (HMPS). It reduces the search scope of critical

predicates to highly suspicious functions identified by spectrum-based fault
localization (SBFL) techniques, and then assigns the functions into combina-
tions following the call dependency graph.
An alternative approach to static and dynamic slicing is the use of execution
slicing based on data-flow tests to locate program bugs [166] in which an execu-
tion slice with respect to a given test case contains the set of statements executed
by this test. The reason for choosing execution slicing over static slicing is that a
static slice focuses on finding statements that could possibly have an impact on
the variables of interest for any inputs, versus statements that are executed by a
specific input. This implies that a static slice does not make any use of the input
values that reveal the fault and violates a very important concept in debugging
that suggests programmers analyze the program behavior under the test case that
fails and not under a generic test case. Collecting dynamic slices may consume
excessive time and file space, even though different algorithms [167–170] have
been proposed to address these issues. Conversely, it is relatively easy to con-
struct the execution slice for a given test case if we collect code coverage data
from the execution of the test. Different execution slice-based debugging tools
have been developed and used in practice such as χSuds at Telcordia (formerly
Bellcore) [171, 172] and eXVantage at Avaya [173]. Agrawal et al. [166] apply the
execution slice to fault localization by examining the execution dice of one failed
and one successful test to locate program bugs. Jones et al. [174, 175] and Wong
et al. [176] extend that study by using multiple successful and failed tests based
on the following observations:
• The more successful tests that execute a piece of code, the less likely it is for the
code to contain a bug.
• The more failed tests with respect to a given bug that execute a piece of code, the
more likely that it contains this bug.
We use the following example to demonstrate the differences among static,

dynamic, and execution slicing. Use the code in column 2 of Table 1.2 as the ref-
erence. Assume it has one bug at s7. The static slice for the output variable, prod-
uct, contains all statements that could possibly affect the value of product, s1, s2,
s4, s5, s7, s8, s10, and s13, as shown in the third column. The dynamic slicing for
product only contains the statements that do affect the value of product with
respect to a given test case, which includes s1, s2, s5, s7, and s13 (as shown in
the fourth column) when a = 2. The execution slice with respect to a given test
case contains all statements executed by this test. Therefore, the execution slice
for a test case, a = 2, consists of s1, s2, s3, s4, s5, s6, s7, s12, s13 as shown in the fifth
column of Table 1.2.
Table 1.2 An example showing the differences among static, dynamic, and execution slicing.
Dynamic slice for product Execution slice for product

Code with a bug at s7 Static slice for product with respect to a test case a = 2 with respect to a test case a = 2
s1 input(a) input(a) input(a) input(a)

s2 i = 1; i = 1; i = 1; i = 1;
s3 sum = 0; sum = 0;
s4 product = 1; product = 1; product = 1;
s5 if (i < a) { if (i < a) { if (i < a) { if (i < a) {
s6 sum = sum + i; sum = sum + i;
s7 product = product ∗ i; product = product ∗ i; product = product ∗ i; product = product ∗ i;
// bug: product = product ∗ 2 ∗ i
s8 } else { } else { } }
s9 sum = sum – i;
s10 product = product / i; product = product / i;
s11 } }
s12 print (sum); print (sum);
s13 print (product); print (product); print (product); print (product);
Source: Wong et al. [177]/IEEE.
One problem with the aforementioned slice-based techniques is that the bug
may not be in the dice. Even if a bug is in the dice, there may still be too much
code that needs to be examined. To overcome this problem, an inter-block data
dependency-based augmentation and a refining method is proposed in [178].
The former includes additional code in the search domain for inspection based
on its inter-block data dependency with the code currently being examined,
whereas the latter excludes less suspicious code from the search domain using
the execution slices of additional successful tests. Additionally, slices are problem-
atic because they are always lengthy and hard to understand. In [179], the notion
of using barriers is proposed to provide a filtering approach for smaller program
slices and better comprehensibility. Stridharan et al. [180] propose thin slicing
in order to find only producer statements that help compute and copy a value to
a particular variable. Statements that explain why producer statements affect
the value of a particular variable are excluded from a thin slice.
1.3.2 Program Spectrum-Based Techniques

Following the discussion in the beginning of Section 1.3, we would like to empha-
size that many spectrum-based techniques are inspired by the probabilistic- and
statistical-based causality models. With this understanding, we now explain the
details of these techniques.
A program spectrum details the execution information of a program from cer-
tain perspectives, such as execution information for conditional branches or loop-
free intra-procedural paths [181]. It can be used to track program behavior [182].
An early study by Collofello and Cousins [183] suggests that such spectra can be
used for software fault localization. When the execution fails, such information
can be used to identify suspicious code that is responsible for the failure. Code
coverage, or executable statement hit spectrum (ESHS), indicates which parts of
the program under testing have been covered during an execution. With this infor-
mation, it is possible to identify which components were involved in a failure, nar-
rowing the search for the faulty component that made the execution fail. Masri
[184] presents a comprehensive survey of state-of-the-art SBFL techniques pro-
posed from 2005 to February 2016, describing the most recent advances and
challenges.
1.3.2.1 Notation
p a program
aef Number of failed test cases that cover a statement
anf Number of failed test cases that do not cover a
statement
aes Number of successful test cases that cover a statement

ans Number of successful test cases that do not cover a
statement
ae Total number of test cases that cover a statement
an Total number of test cases that do not cover a statement
aS Total number of successful test cases
af Total number of failed test cases
ti The ith test case
1.3.2.2 Techniques
Early studies [145, 185–187] only use failed test cases for SBFL, though this
approach has subsequently been deemed ineffective [107, 117, 166]. Later studies
achieve better results using both the successful and failed test cases and emphasiz-
ing the contrast between them. Set union and set intersection are proposed in
[188]. The set union focuses on the source code that is executed by the failed test
but not by any of the successful tests. Such code is more suspicious than others.
The set intersection excludes the code that is executed by all the successful tests
but not by the failed test. Renieris and Reiss [188] propose another ESHS-based
technique, nearest neighbor, which contrasts a failed test with a successful test that
is most similar to the failed one in terms of the distance between them. If a bug is in
the difference set, it is located. For a bug that is not contained in the difference set,
the process continues by first constructing a program dependence graph (PDG)
and then including and checking adjacent unchecked nodes in the graph step
by step until all the nodes in the graph are examined. The idea of nearest neighbor
is similar to Lewis’ counterfactual reasoning [189], which claims that, for two
events A and B, A causes B (in world w) if and only if, in all possible worlds that
are maximally similar to w, A does not take place and B also does not happen. The
theory of counterfactual reasoning is also found in other studies such as [190–192].
Intuitively, the closer the execution pattern of a statement is to the failure pattern
of all test cases, the more likely the statement is to be faulty, and consequently the
more suspicious the statement seems. By the same token, the farther the execution
pattern of a statement is to the failure pattern, the less suspicious the statement
appears to be. Similarity coefficient-based measures can be used to quantify this
closeness, and the degree of closeness can be interpreted as the suspiciousness
of the statements.
A popular ESHS-based similarity coefficient-based technique is Tarantula [174],
which uses the coverage and execution result (success or failure) to compute the
suspiciousness of each statement as aef af aef af + aes as A study on the
Siemens suite [107] shows that Tarantula inspects less code before the first faulty
statement is identified, making it a more effective fault localization technique

when compared to others such as set union, set intersection, nearest neighbor,
and cause transition [193]. Based on the suspiciousness computed by Tarantula,
studies like [174, 175] use different colors (from red to yellow to green) to provide
a visual mapping of the participation of each program statement in the execution
of a test suite. The more failed test cases that execute a statement, the brighter (red-
der) the color assigned to the statement will be. In [103], Debroy et al. further
revise the Tarantula technique. Statements executed by the same number of failed
test cases are grouped together, and then groups are ranked in descending order by
the number of failed test cases. Using Tarantula, statements are ranked by suspi-
ciousness within each group.
For discussion purposes, let us use the code in Table 1.2 again. Assume that we
have two successful test cases (a = 0 and a = 1) and one failed test case (a = 2). The
suspiciousness value of each statement can be computed, for example, using the
Tarantula technique discussed above. The results are as shown in Table 1.3.
The third to fifth columns in Table 1.3 represent the statement coverage of the
three test cases. An entry with a “●” means the statement is covered by the corre-
sponding test case, while an empty entry means the statement is not. The values of
aef and aes for each statement are given in the sixth and seventh columns. Based on
the definition of Tarantula, the suspiciousness value of each statement is com-
puted and displayed in the eighth column. The ranking of each statement is given
in the rightmost column. As we can observe, the faulty statement s7 has the highest
ranking.
In recent years, other techniques have also been proposed that perform at the
same level with, or even surpass, Tarantula in terms of their effectiveness at fault
localization. The Ochiai similarity coefficient-based technique [94] is generally
considered more effective than Tarantula, and its formula is as follows:
aef
Suspiciousness Ochiai =
af × aef + aes
There are two major differences between Ochiai and the nearest neighbor
model: (i) the nearest neighbor model utilizes a single failed test case, while Ochiai
uses multiple failed test cases and (ii) the nearest neighbor model only selects the
successful test case that most closely resembles the failed test case, while Ochiai
includes all successful test cases. Ochiai2 [113] is an extension of Ochiai, and
its formula is as follows:
aef ×ans
Suspiciousness Ochiai2 =
aef +aes × ans +anf × aef +anf × aep +ans
Table 1.3 An example showing the suspiciousness values computed by Tarantula.
Code with a bug at s7 a=0 a=1 a=2 aef aes Suspiciousness Ranking
s1 input(a) ● ● ● 1 2 0.5 3
s2 i = 1; ● ● ● 1 2 0.5 3
s3 sum = 0; ● ● ● 1 2 0.5 3
● ● ● 1 2 0.5 3
s4 product = 1;
● ● ● 1 2 0.5 3
s5 if (i < a){
● 1 0 1 1
s6 sum = sum + i;
● 1 0 1 1
s7 product = product ∗ i;
// bug: product = product ∗ 2 ∗ i ● ● 0 2 0 10
s8 } else { ● ● 0 2 0 10
s9 sum = sum – i; ● ● 0 2 0 10
s10 product = product / i; ● ● 0 2 0 10
● ● ● 1 2 0.5 3
s11 }
● ● ● 1 2 0.5 3
s13 print (product);
Execution result Successful Successful Failed
Source: Wong et al. [177]/IEEE.

In [113], Naish et al. propose two techniques, O and OP. The technique O is
designed for programs with a single bug, while OP is better applied to programs
with multiple bugs. Data from their experiments suggest that O and OP are more
effective than Tarantula, Ochiai, and Ochiai2 for single-bug programs. On the
other hand, Le et al. [194] present a different view by showing that Ochiai can
be more effective than O and OP for programs with single bugs.
− 1 if anf > 0
Suspiciousness O =
ans otherwise
Table 1.4 lists 31 similarity coefficient-based techniques, along with their alge-
braic forms, which have been used in different studies such as [195–197]. A few
additional techniques using similar approaches can be found in [198]. Tools like
Zoltar [199] and DEPUTO [200] are available to compute the suspiciousness with
respect to selected techniques. Empirical studies have also shown that techniques
proposed in [117, 197, 201–203] are, in general, more effective than Tarantula.
Comparisons among different SBFL techniques are frequently discussed in
recent studies [95, 113, 194, 197, 204, 205]. However, there is no technique claim-
ing that it can outperform all others under every scenario. In other words, an opti-
mum spectrum-based technique does not exist, which is supported by Yoo et al.’s
study [206].
A few additional examples of program SBFL techniques are listed below.
• Program Invariants Hit Spectrum (PIHS)-Based: This spectrum records the

coverage of program invariants [207], which are the program properties that
remain unchanged across program executions. PIHS-based techniques try to
find violations of program properties in failed program executions to locate bugs.
Potential invariants [208], also called likely invariants [209], are program proper-
ties that are observed to hold in some sets of successful executions but, unlike
invariants, may not necessarily hold for all possible executions. The major obsta-
cle in applying such techniques is how to automatically identify the necessary
program properties required for the fault localization. To address this problem,
existing PIHS-based techniques often take the invariant spectrum of successful
executions as the program properties. In study [210], Alipour and Groce propose
extended invariants by adding execution features such as the execution count of
blocks to the invariants. They claim that extended invariants are helpful in fault
localization. Shu et al. [211] propose FLSF technique based on Tarantula. They
use statement frequency, instead of coverage information, to evaluate the sus-
piciousness of each statement. FLSF first counts the statement frequency of each
program statement in each test case execution so as to construct a statement fre-
quency matrix. Second, each weighted element of the constructed matrix is nor-
malized to a value between 0 and 1. Finally, the suspiciousness of each statement
Table 1.4 Some similarity coefficients used for fault localization.
Coefficient Algebraic form Coefficient Algebraic form
1 Braun- aef 17 Harmonic aef × ans − anf × aes × aef + aes × ans + anf + aef + anf × aes + ans
Banquet max aef + aes , aef + anf Mean aef + aes × ans + anf × aef + anf × aes + ans
2 Dennis aef × ans − aes × anf 18 Rogot2 1 aef aef ans ans
+ + +
4 aef + aes aef + anf ans + aes ans + anf
n × aef + aes × aef + anf
3 Mountford aef 19 Simple aef + ans
05× aef × aes + aef × anf + aes × anf Matching aef + aes + ans + anf
4 Fossum n × aef − 0 5
2 20 Rogers and aef + ans
Tanimoto aef + ans + 2 anf + aes
aef + aes × aef + anf
5 Pearson 2 21 Hamming aef + ans
n× aef × ans − aes × anf
Φe × Φn × ΦS × ΦF
6 Gower aef × ans 22 Hamann aef + ans − anf − aes
ΦF × Φe × Φn × ΦS aef + anf + aes + ans
7 Michael 4× aef × ans − aes × anf 23 Sokal 2 aef + ans
2 2
aef × ans + aes × anf 2 aef + ans + anf + aes
8 Pierce 24 Scott 2
aef × anf + anf × aes 4 aef × ans − anf × aes − anf − aes
aef × anf + 2 × anf × ans + aes × ans 2aef + anf + aes 2ans + anf + aes
9 Baroni- aef × ans + aef 25 Rogot1 1 aef ans
Urbani and +
2 2aef + anf + aes 2ans + anf + aes
Buser aef × ans + aef + aes + anf
10 Tarwid n × aef − ΦF × Φe 26 Kulczynski aef
n × aef + ΦF × Φe anf + aes
(Continued)
Another random document with
no related content on Scribd:
“It will be all right, Tante; don’t be downcast. Only at present
everybody is homesick and tired as you are. Can’t we have tea? You
are not sorry we have come?”
“Certainly not,” and Polly smiled at her own childishness while she
rejoiced over Peggy’s sweetness and good sense.
Of course, she had known there would be difficulties in so original
a Camp Fire club experiment. But when did anything worth while
ever arrange itself without difficulties?
Ten minutes later two colored stewards in white uniforms had
arranged the tables and brought in tea.
In entire good humor Mrs. Burton presided while the men were
kept busy passing back and forth innumerable cups of tea and plates
of sandwiches.
The girls were fifty per cent more cheerful and consequently more
agreeable. At the table nearest Mrs. Burton were Peggy, Sally Ashton
and Gerry Williams.
All at once Mrs. Burton turned to her niece.
“What in the world has become of Bettina, dear?” she demanded.
“I had not missed her until this moment. I am not a very successful
old woman who lived in a shoe with so many children she couldn’t
tell what to do, for I don’t even know when one of mine is lost.”
Peggy got up.
“Bettina is out on the back platform dreaming, I suppose. I told
her to come in with me a quarter of an hour ago. I’ll go get her.”
However, after a little time, Peggy returned alone looking a little
cross.
“Bettina has disappeared. I can’t find her,” she announced. “As I
did not want to miss tea, I asked our porter to look.”
And no one thought of being worried about Bettina until the porter
came to say that no young woman answering Bettina’s description
could be found.
CHAPTER VI
Experience
But Bettina was not conscious of how long a time had passed, or that
she was causing anxiety.
An unusual experience had come to her, and a most
unconventional one.
Standing there at the back of the observation car, she had
forgotten Peggy’s suggestion that she return to the rest of the girls.
But perhaps she would not have gone in any case, because Bettina
was not enjoying their society. She was shy, or perhaps cold. It was
difficult to tell which was the influence at work. Nevertheless, she
was finding it as much of a trial to be friendly and at ease with her
fellow-travelers as she had with her mother’s older and more
conventional guests in Washington. But it is possible that Bettina
had inherited some of her father’s reserve—the reserve which had
made Anthony Graham work and study alone during those many
hard years before reaching manhood.
However, to make up for her lack of interest and her
uncongeniality with people—as is true with nearly all such persons—
Bettina had an unusual fondness for nature.
Now, the landscape of Kansas had not appealed strongly to any
one of the other girls. Usually the country was flat and covered with
great fields of young corn or wheat, with prosperous farm-houses
standing in the background. Yet Bettina saw color and grace in
everything.
As the car rushed along, with its rattling and banging, she was
trying to recall a line of Kipling’s poetry which described the sound
the wind made through the corn.
After Peggy left her, Bettina had caught hold of the wide railing at
the end of the car for safety. She was now occupying the entire rear
platform of the observation train alone. She was swaying slightly
with the movement, with her eyes wide open and her lips slightly
parted. Having taken off her hat, the afternoon sunshine made
amber lights in her hair as it flickered amid the brown and gold.
Then, suddenly, Bettina became conscious that some one else had
come out on the same end of the car with her and was standing near.
It was stupid and self-conscious to flush as she always did in the
presence of strangers.
“I hope I do not disturb you,” she then heard a voice say
courteously. And, turning her head to reply, Bettina beheld a young
man of about twenty. He looked very dark—a Spaniard she believed
him for the moment. His eyes were fine and clear, with a faraway
look in them; his nose, aquiline; and he held his head back and his
chin uplifted.
“You don’t trouble me in the least,” Bettina replied, feeling her
shyness vanish. “Besides, I was just going back to my friends.”
Yet she did not go at once.
She was interested in the unusual appearance of her companion.
He had folded his arms and was looking gravely back at the
constantly receding landscape.
“And east is east and west is west,
And never the twain shall meet.”
He spoke apparently without regarding Bettina and softly under

his breath.
Therefore it was Bettina who really began their conversation, their
other speeches to each other having expressed only the ordinary
conventionalities between fellow-travelers.
“It is curious—your repeating those lines,” Bettina returned, her
eyes changing from gray to blue, as they often did in moments of
friendliness. “I have just been standing here trying to recall another
line of Kipling’s poetry. And it has come to me since you spoke: ‘The
wind whimpers through the fields.’ Do you care for Kipling’s poetry?”
The young man turned more directly toward Bettina.
“I am an Indian,” he explained simply. “It is natural that I should
think of those lines, for I have been for several years at a college in
your eastern country and am now returning to my own people and
my own land. I am a Hopi. My home is in the province of Tusayan,
Arizona, in the town of Oraibi. We are Indians of the Pueblo.”
“But you—” Bettina hesitated.
The young fellow threw back his head and, then realizing that
custom demanded it, lifted his hat. He was dressed as any other
young college man might be, except that his clothes were simple and
a little shabby.
“I am not entirely Indian,” he continued, still so serious that
Bettina was unconscious of there being anything out of the way in his
confidence. “My mother was a Spanish woman, I have been told; but
she died at my birth and now my father is again married and has
children by a woman of his own race. Yet I am glad to return to my
own people, to wear again the moccasin of brown deer-skin and the
head-band of scarlet.”
Instinctively the young man’s pose changed. Bettina could see that
his shoulders lifted and that he breathed more deeply. He stood
there on the platform of the most civilized and civilizing monster in
the world—a great express train—gazing out on the fields as if he had
been an Indian chief at the door of his own tepee, surveying his own
domains.
Naturally Bettina was fascinated. What young girl could have
failed to have been interested? And Bettina had lived more in books
and dreams than in realities.
“We are also going to Arizona,” Bettina added quickly. “I have
never been West before, though I have longed to always. We are to
camp somewhere on a ranch not far from the Painted Desert. Do
Indians live near there and would you mind telling me something of
them? Are they still warlike? Sometimes I feel a little nervous, for we
are to be only a party of girls and our Camp Fire guardian, except
that we are to have a man and his wife for our cook and guide.”
For an instant the young fellow laughed as any other boy would
have done, and showing white, fine teeth. Afterwards he relapsed
into the conventional Indian gravity.
“My own people are peaceful and always have been, except when
we have been attacked by other Indians. Hopi means ‘peaceful
people,’ and we have lived in Arizona, the land of ‘few springs,’ since
before the days when your written history begins. The Apaches have
always been our bitterest enemies. But they will not harm you—the
great hand of your United States Government is over us all,” he
concluded.
And Bettina could not tell whether he spoke in admiration or in
bitterness.
It was growing cooler and she shivered—not in reality from the
cold half so much as from her interest in the conversation.
Nevertheless the Indian saw her slight movement.
“You are cold; you must be careful in the desert, as often the night
turns suddenly cool after a scorching day. May I take you to your
friends?”
Bettina was accustomed to having her own way. She was enjoying
the talk with her unusual acquaintance far more than anything that
had taken place since their journey began. Therefore it did not occur
to her to consider that her absence might create uneasiness.
“Are you going to do anything else? If you are not I wonder if you
would mind our finding a place somewhere and talking?” she
suggested. “I know it is asking a great deal of you, but there are so
many things I wish to know about the West.”
Bettina was like an eager child. But, then, ordinary
conventionalities never troubled her, unless they were forced upon
her consideration.
And what could the young man do except assent.
He found Bettina a camp chair at the rear end of the adjoining car
and himself a small one beside it.
But the chairs were not outside; they stood in an enclosed space
just inside the train and beside a great window.
When her companion sat down beside her, one could not get a full
view of Bettina.
However, Peggy did not pass her by, for she did not go into this car
to search. But the colored porter did. Yet he had been told to discover
a young woman who was alone, dressed in a blue suit and wearing a
blue hat.
And Bettina was not alone. She was deeply engaged in
conversation, and without a hat, so, although the porter did hesitate
beside her, he did not interrupt, deciding that she was not the young
woman he sought.
But here Mrs. Burton and two of the girls found her a few
moments later.
As soon as the man returned and declaring that Bettina had
vanished, Polly had become instantly terrified. For a woman who was
to be chaperon to half a dozen or more girls, she had far too much
imagination. At once she conceived the idea that Bettina had fallen
off the train—and—what could she say to the child’s mother and
father? It was too dreadful!
Indeed, Mrs. Burton would have had the train stopped
immediately, except that Peggy and Ellen Deal, who at once rose to
the occasion, insisted that Bettina be reconnoitered for again.
But when Bettina was finally traced and discovered in agreeable
conversation with a strange young man, her chaperon was angry.
Indeed, the natural Polly wished to assert herself and give the girl
just such a scolding as she would have bestowed upon her mother in
their younger days. Only, of course, the present, more elderly Polly
was convinced that Betty would never have been so inconsiderate as
her daughter.
However, remembering her own dignity as a newly-chosen Camp
Fire guardian, after a few moments of reproach, she did manage to
control her temper.
And Bettina, although making no defense, was sorry. She had not
been intentionally selfish, only she did not see but one side of a
situation until usually it was too late. She lived—as so many other
people do—in her own visions and her own desires. Yet, at present,
she deeply wished her mother’s old friend to care for her and
exaggerated the failure she was making with her. Without
appreciating it, Polly walked in a kind of halo of achievement and
charm before Bettina’s eyes. Therefore, it was unfortunate Bettina
did not realize that everything and everybody in the world Mrs. Polly
Burton took more seriously than she did her own fame, and that the
dearest desire of her heart at the present time was that her new
Camp Fire girls should regard her as their friend.
CHAPTER VII
Sunset Pass
Two days later, however, a few hours after breakfast, Mrs. Polly
Burton was also interested in Bettina’s new acquaintance, and was
making the young man useful.
The afternoon of their meeting Bettina had endeavored to
introduce him, but had found this difficult because she did not know
his name.
At the time, the Indian had met the situation with no more
awkwardness than any other young fellow in the same position
would have shown. He had at once given his name to Mrs. Burton as
John Mase. However, both she and the girls, who were her
companions, understood this was not the young man’s Indian name,
but probably the one which had been bestowed upon him at a
government school and which he evidently preferred using at college
and among strangers of the white race.
The following day none of the Camp Fire party saw anything of
him, though frankly all the girls were curious, after learning of
Bettina’s escapade. It was on the second morning that, going back to
his own coach from the dining car, the young man chanced to pass
Bettina and Mrs. Burton. At the moment they were seated side by
side in one compartment. But it was Mrs. Polly Burton—the official
guardian of the new group of Camp Fire girls en route to their desert
camp—who this time accosted him. For the young Indian had only
bowed and continued to walk gravely on.
But the train was now entering the Arizona plateau country. By
nightfall the Camp Fire party expected to arrive at a tiny village not
far from Winslow and the next day begin the trek to their own camp.
Already the air was clear and brilliant. Away to the west were the
outlines of high mountains and the peaks of giant canyons. Here and
there were bits of dreary, olive-gray desert and then an unexpected
green oasis.
In the night it appeared as if the face of the world had changed,
and with it the Camp Fire girls had changed also. If there were
further coldness or friction between them, it had disappeared in their
great common interest in the things before them and in the dream of
their new life together in the desert. And, though they were too
absorbed at the time for reflection, this is the way in which all
friction between human beings may be destroyed; unconsciously the
girls were acquiring one of the big lessons of the Camp Fire work—to
live and think outside themselves.
At every station there were dozens of Indians offering their wares
for sale. To eastern girls it seemed scarcely possible that they were
still in the United States, so unlike was this new land. Yet the Camp
Fire girls nobly refrained from making purchases, having solemnly
promised to add nothing to their luggage until they reached camp.
Yet, in reality, it was the sight of so many Indian treasures which
inspired Mrs. Burton to speak to Bettina’s Indian acquaintance. She
appreciated that he must know more of the requirements of camp life
in Arizona than she could learn from any number of books or from
the conversation of a dozen acquaintances.
Yet possibly this was just a “Pollyesque” excuse. She may have
been attracted by the young Indian’s appearance, as Bettina had
previously been, and simply wished to be entertained by him.
He was so grave and yet so courteous; and his voice had the gentle,
caressing sound which afterwards the campers learned was a
peculiarity of Hopi Indians.
“My father is a kiva chief,” he explained good-naturedly. “We have
many chiefs among the Hopis, but the kiva is the underground
chamber for our religious ceremonies, and the kiva chief has charge
of them.”
He seemed to be as willing to talk to Polly as he had to Bettina on
their first meeting. But then Bettina was beside them, listening with
the soft color coming in her cheeks from her deep interest, and the
blue in her sometimes gray eyes.
She had been sitting with Mrs. Burton and separated from the
others when the young Indian joined them. It was extraordinary how
soon they were surrounded.
First Peggy came and took a seat across from her aunt and then
Alice Ashton, intending to make a special study of Indian custom,
therefore felt it her duty to make the young man’s acquaintance.
Ellen Deal frankly leaned over from her place on the opposite side of
the aisle and Gerry came and stood beside Bettina. Only Vera and
Sallie Ashton appeared uninterested. Vera, because she was too shut
up inside herself to be natural; and Sallie, because she was too much
entertained by a light novel and a five-pound box of chocolates, into
which she had been dipping steadily for several days without the
least injury to her disposition or her complexion.
When the young Indian sat down she had simply given him a
glance from over the pages of her book and then glanced at Bettina.
Afterwards she had smiled and gone on reading. Sally and Bettina
knew each other, of course, though not intimately, considering the
fact that their mothers were sisters. But then they only met now and
then and there was no congeniality between them. Alice and Bettina
were better friends.
“Gerry Williams and Bettina looked a little alike,” Mrs. Burton
reflected, even while she was listening with interest to the
conversation of their new acquaintance. But then it had become
second nature to study the girls traveling with her ever since their
departure.
“Gerry was perhaps prettier than Bettina, or at least some people
might think so,” Polly decided, feeling that in some way the idea was
a disloyalty to her own friendship with Bettina’s mother. And
certainly Gerry was easier to understand!
She was standing now beside Bettina, her eyes a lighter blue, her
hair a paler gold, but she was about the same in height and
slenderness. And she was talking to the young Indian as if they had
known each other a long time, while Bettina, now that other people
were present, remained silent.
“Do you mean to be a chief yourself some day?” Gerry asked, her
blue eyes widening like a child’s from curiosity.
Gerry was a pretty contrast to the young Indian; so delicately fair
in comparison with his bronze vigor.
She looked almost poorly dressed as she stood by Bettina, but girls
do not realize that handsome clothes are not necessary when one is
pretty and young. Gerry’s traveling dress was also blue, a brighter
color, and equally becoming. Just for half an instant, and before the
young man answered, it flashed through Polly Burton’s mind that the
young Indian might become interested in Gerry if they should chance
to meet often. And Gerry had not the social training to make her
realize how wrong it might be to cultivate such a friendship. The next
instant, however, Mrs. Burton had forgotten the absurdity of her own
idea. Besides, in all probability they would not see the young man
again.
“I am studying law at Yale,” he answered, surveying Gerry with a
peculiar long stare he had given no one else. “It is my plan to work
among my own people, but in the white man’s way.”
Before the morning had passed he had confessed to Mrs. Burton
his own name. At least he made his confession looking directly at her
as the official chaperon. But really he seemed less conscious of the
group of girls about him than any American college fellow could have
managed to be.
“Se-kyal-ets-tewa (Dawn Light). The name was a beautiful one, but
small wonder the young man preferred being called by his adopted
name! He smiled when he explained that it was against the better
judgment of a Hopi Indian to confess his own title. A friend might
tell it for him, but to speak one’s own name was to invite disaster.
Indeed, during the long morning’s talk together, Mrs. Burton was
puzzled to discover how far the young man had been converted to
American ideas and ideals, and how far he still believed in and
preferred his own. He made no criticism of either. He merely
answered a hundred inquiries from half a dozen young women for
the distance of a hundred miles or more, and never lost his temper or
suggested that some of the questions were absurd. Only once did he
smile with slight sarcasm. In her best Boston manner Alice Ashton
had asked a question not complimentary to Indian women.
“The Hopi women have always had the privilege of voting,” he
replied. “I believe you will find them the original American
suffragettes, since we came to this country a good many years before
the Pilgrim fathers. You do not vote in Boston, I think.” And then all
the party laughed except Alice, who had not a sense of humor.
Although Sallie, her younger sister, was not supposed to hear, she
flashed a pleased smile above the pages of her book. For Alice was
the learned member of the family and Sally the frivolous, so now and
then it was fun to score.
When lunch time arrived the Indian would not remain longer with
the Camp Fire party, although Mrs. Burton felt it her duty to issue an
invitation. She was pleased with his good sense in declining.
However, on leaving, he did say: “You may some day wish to come
to my village in Oraibi, and then I would like to show you both
beautiful and curious things.”
For an instant, just as he was making this remark, his glance
rested on Bettina. She could not have defined it to herself, but in
some way his invitation appeared to have been addressed to her. And
Bettina determined to accept. The young Indian had interested her in
the account he gave of his life and people. Bettina was not fond of a
conventional existence and had often wished to see a simpler and
freer life. The Hopi Indians appeared to have arrived at a curious
combination of civilization and what we call savagery. For instance,
the old and infirm in a Hopi community are never allowed to want.
The “Law of Mutual Help” suggests a better way of life than Lloyd
George’s far-famed “old-age pensions” in the British Isles.
So Bettina sat dreaming and reflecting the greater part of the
afternoon, while the other girls packed and unpacked, laughed and
talked, excited over the prospect of arrival.
By an accident it was just before sunset when they reached a small
wayside station known as Sunset Pass, because the Sunset trail led
away from it. The party expected to spend the night at a big ranch
house some miles away and, if possible, make camp the next
morning.
But, as they left the train, suddenly the day had changed from heat
to coldness. The girls and Mrs. Burton, as well, felt an uncomfortable
sense of chill at their surroundings.
The little western station looked so bare and dreary. There were
scarcely a dozen frame houses in view and these were all built alike
and had no flowers or shrubbery to relieve their dullness.
Near the station was an extraordinary structure, which covered
more than a half acre of ground. It was built of wooden planks so
crossed and recrossed as to form small rooms or pens. It might have
been an enormous open-air prison and was in fact. Weird and lonely
noises issued from it—the bleating of hundreds of sheep waiting for a
cattle train to ship them to the eastern market.
Had she been alone, Mrs. Burton felt she would have given way to
homesickness. However, as Camp Fire guardian and the oldest
member of what was after all her own expedition, she must appear
cheerful.
Then Marie unexpectedly relieved the situation.
Descending from the train to the wooden platform, Marie gave a
long look at the surroundings and burst into tears. And her tears
were not of the silent variety.
Sally Ashton and Peggy giggled irresistibly, but everybody smiled.
Marie looked so incongruous. Her costume was the perfectly
correct one she wore when following her famous mistress through a
sometimes curious crowd at the Grand Central Station in New York
City, or through another almost equally large.
But it was Gerry Williams, after all, who went to Marie and patted
her sympathetically on the shoulder. Mrs. Burton was pleased. And it
was true that, in spite of other weaknesses, Gerry did things like this
naturally, although she may not have been entirely unconscious,
even at this moment, of their Camp Fire guardian’s presence.
Gerry knew that the celebrated Mrs. Burton had taken a fancy to
her and intended making the most of it.
Then Gerry’s prettiness also appealed strongly to Polly Burton. It
was of the fair ethereal kind—an entire contrast to her own
appearance. Moreover, one must remember how Polly O’Neill had
always admired beauty and how great a point she had made of her
friend Betty Ashton’s in their old Camp Fire days.
Although Gerry’s sympathy was not effective, Mrs. Burton knew
how to check her maid’s tears.
“I am cold; will you please put my fur coat on me, Marie,” she
suggested, whispering something consoling as Marie slipped her into
it.
Then Mrs. Burton became nervous.
She and her Camp Fire party were standing alone on a deserted
platform in a place which appeared to be a thousand miles from
nowhere. For there was no one in sight except a little bent-over
station master inside a kind of wooden box, who looked like a clay
model of a man molded by an amateur artist.
As he did not emerge from his shack, Mrs. Burton started toward
him.
Certainly she had expected that every arrangement for meeting
them had been made beforehand, her husband having spent a small
fortune on telegrams for this purpose.
However, she had gone but a few steps when the tallest man she
ever remembered seeing came striding toward her.
“I guess this is the party looked for,” he remarked with an
agreeable smile. “Arizona hasn’t seen such a bunch of pretty girls in a
long spell. Come this way; my wife is expecting you at the ranch
house, but I got tired waiting for you and have been loafing about in
the neighborhood.”
Then he led the way, the Sunrise Camp Fire party of course
following.
Waiting for them a little out of sight was an old-fashioned stage-
coach drawn by a pair of fine horses.
The driver, who was Mr. Gardener, the wealthy owner of Sunset
Ranch, assisted by the dwarf station master piled all the girls’
luggage on top the stage; the heavier trunks were to be sent for later.
Then the coach started down a long, straight road facing the west.
The sky was a mass of color far more vivid and brilliant than an
eastern sunset. Beyond, almost pressing up into the clouds, were the
distant peaks of extinct volcanoes. It was as if they had once flung
their molten flames up into the sky and there they had been caught
and held in the evening clouds.
It does not seem credible that eight women can remain silent for
three-quarters of an hour, and yet the Camp Fire party was nearly so.
Then they drew up in front of a big one-story house with a grove of
cottonwood trees before it.
On the porch waiting to receive them stood Mrs. Gardener, the
wife of their driver and the owner of the ranch house and the great
ranch itself, near whose border the Camp Fire party expected to pitch
their tents.
CHAPTER VIII
At The Desert’s Edge
Soon after sunrise the next day the Camp Fire party planned to leave
the big ranch house.
Mr. and Mrs. Gardener had already assured them that their
camping outfit had been sent on ahead the day before to the borders
of Cottonwood Creek, so there need be no delay when the campers
arrived. One of Mr. Gardener’s own men had it in charge and, as
soon as the expedition joined him, would aid in the choice of a
camping site. Water, one must remember, was the great problem in
Arizona and they must, therefore, select a place near a clear creek.
It was not yet daylight when Bettina Graham first opened her eyes
the morning after their arrival, and yet she felt completely rested.
She was sleeping beside Peggy, while on the opposite side of the
room were Gerry Williams and the Russian girl, Vera Lageloff.
“Camping also makes strange bedfellows,” Bettina thought with
the quiet sense of humor so few people realized she possessed. She
was not homesick—life at present held too many fascinating
possibilities—but it was natural that she should begin thinking of her
own home in Washington, and more especially of her own suite of
rooms. They had been recently refurnished—as a birthday gift from
her father—in pale grey and rose color, with the furniture of French
oak.
Bettina appreciated that she had known nothing but the fair side of
life—that it was almost a weakness of her father’s to do more for her
than she even desired. Senator Graham was not ashamed of his own
humble past and the hard struggle of his boyhood; but, like many
another self-made man, for this reason he wished his family to have
every indulgence. Yet, although the close bond of sympathy was
between Bettina and her father and Tony and his mother, Senator
Graham did not wish his daughter to know only the life of luxury and
self-indulgence.
Therefore, it was he who had been most in favor of the western
camping experiment. Bettina was to long remember his saying that
he wished her “to find herself” and that this one must do away from
one’s own family.
In camping with so wealthy and famous a woman as Polly Burton
there would be scarcely any great hardships to be endured. The new
Sunrise Camp Fire girls were in more danger of having life made too
easy for them rather than too difficult. Yet there might be
circumstances now and then which would require good sense and
courage to overcome. And, most of all, Bettina needed to see the
practical side of every-day life.
“It was so like Polly O’Neill to get together such an extraordinarily
unlike group of girls, but I had hoped Polly O’Neill Burton might
have better judgment,” Betty Graham had lamented to her husband
and daughter, half in earnest and half amused.
But when her husband assured her that this was one of the
particular reasons why he wished Bettina to form one of the group,
Mrs. Graham, suddenly remembering his humble origin, had been
wisely silent.
Therefore, before setting out on their western trip, Bettina had
firmly made up her mind to do her best to be friendly with the entire
group of Camp Fire girls. And, on waking this first morning of their
arrival, she was in a measure reproaching herself for her lack of
effort on the journey.
Then unexpectedly Bettina sat upright in bed, feeling that she
must get out of doors at once. She needed to breathe the fresh air in
order to get rid of a stupid impression which had just taken hold of
her.
All her life Bettina had been given to odd fancies—impressions
which annoyed her mother deeply, and which she herself considered
strange and uncomfortable. Just at this moment, for instance, and in
the midst of her good resolution, Bettina had been assailed by a kind
of presentiment. She had a feeling, which was part mental and part
physical, that among the four girls in the room—for Vera and Gerry
Williams were sleeping opposite herself and Peggy—one of the four
of them, either consciously or unconsciously would bring misfortune
upon the others.
Yet, even as she thought this, Bettina was embarrassed and
ashamed and, in the gray light of the early morning, she felt her
cheeks flushing.
But deny or be ashamed of the fact as she would, nevertheless it
was true that Bettina Graham, ever since she was a little girl, had a
curious fashion of knowing certain events were to take place before
they occurred.
She moved over now to the edge of the bed. Then a faint noise
disturbed her.
Turning, she saw that Gerry Williams had also awakened and was
half way out of her bed. She could just faintly see her delicate outline
—the pretty tumbled light hair and smiling blue eyes.
Bettina made a slight sign to her and began quietly to dress. A few
moments later the two girls slipped out and went downstairs and out
of doors.
It was not dark now, for daylight was breaking. Guided by a sound
they heard, the girls went to the left of the big ranch house. And
there, tied to hitching posts, were half a dozen burros with women’s
saddles on them; also a pair of little gray mules packed like camels of
the desert with great loads hanging from their backs and extending
out on either side.
A young man was bending over arranging one of these packs.
He looked up surprised as the two girls came toward him. He was
dressed like the usual western cowboy, with the big hat and flannel
shirt and his trousers ending inside his riding boots. He must have
been about twenty-one.
Gerry smiled at him.
“This must be our caravan. I wonder if I can manage to ride? I
never have in my life.”
The young man lifted his hat.
“This is the Sunrise Camp Fire outfit. I am glad to meet some of its
members at such an hour.”
He pointed toward the east where the sun was now rising above
the horizon.
“Perhaps I may be able to show you how to ride, as I am to be your
guide.”
In reply, Gerry laughed and Bettina shook her head.
“No, I think not,” Gerry returned. “Mrs. Burton told us that she
had engaged an elderly man and his wife to be our guide and cook.
She wrote to secure them weeks ago.”
The young man did not reply.
But an hour afterwards Mrs. Burton, who never remembered
having gotten up so early since the long-ago Sunrise Camp Fire days,
was engaged in argument on this same subject.
“But, my dear Mr. and Mrs. Gardener, surely you can see this
young man is impossible, no matter how trustworthy he may be or
how excellent a knowledge of the country he may have!” She gave a
semi-tragic shrug of her shoulders. “You may not have considered
that I am to have six young girls in my camp and one only a little
older, besides myself and my maid. And now to hear we are to have
an ex-college youth to look after us when I wished a man of fifty at
least! You know yourself, Mrs. Gardener, that anything may
happen.”
Mrs. Burton was standing beside her host and hostess at one side
of the big ranch house veranda at six o’clock that same morning. She
looked very fragile and young herself in comparison. For, although
Mrs. Gardener was not tall, she made up in breadth what she lacked
in height.
She now patted Mrs. Burton’s shoulder, as if she had been a child
needing encouragement.
“Nonsense, my dear; the young man will do you no harm.
Husband and I are sorry that the man and wife we engaged for you
disappointed us. But getting help of any kind out here is a problem.
Besides, it’s better that those Camp Fire girls of yours should do their
own cooking. This one young man cannot do any mischief when
there are so many of you. His tent will be far enough away not to
make him a nuisance, and yet you can get hold of him when you need
him. But you must remember that husband and I are near and ready
to be of whatever service we can.”
The fact that the new Sunrise camp would be anywhere from ten to
twenty miles away did not suggest itself to Mrs. Gardener as
representing distance, so little do people in the western states
consider space. Then she broke into cheerful little good-natured
chuckles.
“Were you planning, Mrs. Burton, to be a kind of Mother Superior,
and run a nunnery in our Arizona wilderness? You’ll find it pretty
hard work to hide those girls out here where girls are scarce. If they
had not been, how do you suppose I would have gotten my good-
looking husband?”
Then Polly turned in despair to Mr. Gardener.
“Your wife is an incorrigible woman. But at least tell me who this
young man is, his name, and why you think he can be trusted as a
safe protector for eight lone women? Really, you must find me a
proper person, Mr. Gardener. Your young man will have to guide us
today, since there is no one else, but in a few days—say, in a week—
you’ll get somebody else?”
Mrs. Burton looked so young and so alarmed at the responsibilities
she had assumed that Mr. Gardener nodded his head reassuringly.
“Certainly, I’ll find some one else for you in time, if you prefer. But
Terry Benton is all right. He got tired of school and came out here to
work for me and has been with me on the ranch for a year. He is a
pretty nervy fellow to undertake this job, I think, and he wouldn’t
except to accommodate me.” Mr. Gardener deliberately winked a
very large, childlike blue eye. “I had to produce some one to keep my
word. But I tell you I am nervous about Terry. There are enough girls
to take care of themselves.”
Polly was uncertain whether she wanted to laugh or cry. Being a
Camp Fire guardian under the present circumstances was not an
easy position. Really, she had not anticipated the things that could
happen.
“And you actually called our new guide, Terry, Mr. Gardener. You
know that means he is an Irishman. Don’t contradict me. Being Irish
myself, I shall know when I see him, anyhow. I expect to have a good
many problems with my Camp Fire girls, but the Irish problem I
won’t have.”

Full Ebook of Handbook of Software Fault Localization Foundations and Advances 1St Edition W Eric Wong Editor Online PDF All Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Ebook of Handbook of Software Fault Localization Foundations and Advances 1St Edition W Eric Wong Editor Online PDF All Chapter

Uploaded by

Copyright:

Available Formats

Handbook of Software Fault

Localization Foundations and

Infanticide and Filicide Foundations in Maternal Mental

ChatGPT for Beginners: Features, Foundations, and

Foundations of Game Engine Development Volume 1

Handbook of Hydraulic Geometry Theories and Advances

Fundamentals of Software Engineering Engineering

Mathematical Foundations of Software Engineering: A

Handbook of Artificial Intelligence Techniques in

Integrating the Internet of Things Into Software

IEEE Press Editorial Board

Jón Atli Benediktsson Andreas Molisch Diomidis Spinellis

About IEEE Computer Society

Foundations and Advances

Set in 9.5/12.5pt STIXTwoText by Straive, Pondicherry, India

1 Software Fault Localization: an Overview of Research, Techniques,

1.7 Critical Aspects 58

2 Traditional Techniques for Software Fault Localization 119

3 Slicing-Based Techniques for Software Fault Localization 135

3.3.4 Multiple-Points Dynamic Slicing 151

4 Spectrum-Based Techniques for Software Fault Localization 201

4.2.2 An Example of Using Similarity Coefficient to Compute

5 Statistics-Based Techniques for Software Fault Localization 271

5.3.2 BPEL: a Sample Application 285

6 Machine Learning-Based Techniques for Software Fault

7 Data Mining-Based Techniques for Software Fault Localization 321

7.2.2 Association Rules 327

8 Information Retrieval-Based Techniques for Software Fault

8.2 General IR-Based Fault Localization Process 368

9 Model-Based Techniques for Software Fault Localization 393

10 Software Fault Localization in Spreadsheets 425

11 Theoretical Aspects of Software Fault Localization 451

12 Software Fault Localization for Programs with Multiple Bugs 473

12.3 Two Techniques Proposed by Jones et al. 475

13 Emerging Aspects of Software Fault Localization 529

13.2.3 Using Debuggers in Fault Localization 534

W. Eric Wong, PhD, is a Full Professor, Director of Software Engineering

the Cambridge Tracts in Theoretical Computer Science series, Cambridge Univer-

Rui Abreu Alex Gorce

Yihao Li T.H. Tse

David Lo W. Eric Wong

Michael Perscheid Xiaoyuan Xie

Software Fault Localization: an Overview of Research,

Software fault localization, the act of identifying the locations of faults in a

Handbook of Software Fault Localization: Foundations and Advances, First Edition.

Author Title Degree University Year

Ehud Y. Shapiro [8] Algorithmic Program PhD Yale 1983

Table 1.1 (Continued)

Author Title Degree University Year

Emmanuel Renieris [16] A Research PhD Brown 2005

Table 1.1 (Continued)

Author Title Degree University Year

Naveed Riaz [28] Automated Source- PhD Graz 2008

Table 1.1 (Continued)

Author Title Degree University Year

Vidroha Debroy [38] Towards the PhD The 2011

Table 1.1 (Continued)

Author Title Degree University Year

Shounak Roychowdhury A Mixed Approach to PhD The 2013

Table 1.1 (Continued)

Author Title Degree University Year

Yepang Liu [59] Automated Analysis PhD The Hong 2014

Table 1.1 (Continued)