DOCSLIB.ORG

Differential Testing for Software

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Differential Testing for Software William M. McKeeman Differential Testing for Software Differential testing, a form of random testing, The Testing Problem is a component of a mature testing technology for large software systems. It complements Successful commercial computer systems contain tens of millions of lines of handwritten software, all of regression testing based on commercial test which is subject to change as competitive pressures suites and tests locally developed during prod- motivate the addition of new features in each release. uct development and deployment. Differential As a practical matter, quality is not a question of cor- testing requires that two or more comparable rectness, but rather of how many bugs are fixed and systems be available to the tester. These sys- how few are introduced in the ongoing development tems are presented with an exhaustive series process. If the bug count is increasing, the software is deteriorating. of mechanically generated test cases. If (we might say when) the results differ or one of Quality the systems loops indefinitely or crashes, the Testing is a major contributor to quality—it is the last tester has a candidate for a bug-exposing test. chance for the development organization to reduce Implementing differential testing is an interest- the number of bugs delivered to customers. Typically, ing technical problem. Getting it into use is an developers build a suite of tests that the software must pass to advance to a new release. Three major sources even more interesting social challenge. This of such tests are the development engineers, who paper is derived from experience in differential know where to probe the weak points; commercial test testing of compilers and run-time systems at suites, which are the arbiters of conformance; and cus- DIGITAL over the last few years and recently tomer complaints, which developers must address to at Compaq. A working prototype for testing win customer loyalty. All three types of test cases are C compilers is available on the web. relevant to customer satisfaction and therefore have value to the developers. The resultant test suite for the software under test becomes intellectual property, encapsulates the accumulated experience of problem fixes, and can contain more lines of code than the soft- ware itself. Testing is always incomplete. The simplest measure of completeness is statement coverage. Instrumentation can be added to the software before it is tested. When a test is run, the instrumentation generates a report detailing which statements are actually executed. Obviously, code that is not executed was not tested. Random testing is a way to make testing more com- plete. One value of random testing is introducing the unexpected test—1,000 monkeys on the keyboard can produce some surprising and even amusing input! The traditional approach to acquiring such input is to let university students use the software. Testing software is an active field of endeavor. Interesting starting points for gathering background 100 Digital Technical Journal Vol. 10 No. 1 1998 information and references are the web site main- rect. The very complexity of modern software that tained by Software Research, Inc.1 and the book drives us to construct tests makes it impractical to pro- Software Testing and Quality Assurance.2 vide a priori knowledge of the expected results. The problem is worse for randomly generated tests. There Developer Distaste is not likely to be a higher level of reasoning that can A development team with a substantial bug backlog be applied, which forces the tester to instead follow does not find it helpful to have an automatic bug the tedious steps that the computer will carry out dur- finder continually increasing the backlog. The team ing the test run. An oracle is needed. priority is to address customer complaints before deal- One class of results is easy to evaluate: program ing with bugs detected by a robot. Engineers argue crashes. A crash is never the right answer. In the triage that the randomly produced tests do not uncover that drives a maintenance effort, crashes are assigned to errors that are likely to bother customers. “Nobody the top priority category. Although this paper does not would do that,” “That error is not important,” and contain an in-depth discussion of crashes, all crashes “Don’t waste our time; we have plenty of real errors caused by differential testing are reported and consti- to fix” are typical developer retorts. tute a substantial portion of the discovered bugs. The complaints have a substantial basis. During a visit Differential testing, which is covered in the following to our development group, Professor C. A. R. Hoare of section, provides part of the solution to the problem of Oxford University succinctly summarized one class of needing an oracle. The remainder of the solution is dis- complaints: “You cannot fix an infinite number of bugs cussed in the section entitled Test Reduction. one at a time.” Some software needs a stronger remedy than a stream of bug reports. Moreover, a stream of bug Differential Testing reports may consume the energy that could be applied in more general and productive ways. Differential testing addresses a specific problem—the The developer pushback just described indicates that cost of evaluating test results. Every test yields some a differential testing effort must be based on a per- result. If a single test is fed to several comparable pro- ceived need for better testing from within the product grams (for example, several C compilers), and one pro- development team. Performing the testing is pointless gram gives a different result, a bug may have been if the developers cannot or will not use the results. exposed. For usable software, very few generated tests Differential testing is most easily applicable to soft- will result in differences. Because it is feasible to gener- ware whose quality is already under control, that is, ate millions of tests, even a few differences can result in software for which there are few known outstanding a substantial stream of detected bugs. The trade-off is errors. Running a very large number of tests and to use many computer cycles instead of human effort to expending team effort only when an error is found design and evaluate tests. Particle physicists use the becomes an attractive alternative. Team members’ same paradigm: they examine millions of mostly boring morale increases when the software passes millions of events to find a few high-interest particle interactions. hard tests and test coverage of their code expands. Several issues must be addressed to make differen- The technology should be important for applica- tial testing effective. The first issue concerns the qual- tions for which there is a high premium on correct- ity of the test. Any random string fed to a C compiler ness. In particular, product differentiation can be yields some result—most likely a diagnostic. Feeding achieved for software that has few failures in compari- random strings to the compiler soon becomes unpro- son to the competition. Differential testing is designed ductive, however, because these tests provide only to provide such comparisons. shallow coverage of the compiler logic. Developers The technology should also be important for appli- must devise tests that drive deep into the tested com- cations for which there is a high premium on indepen- piler. The second issue relates to false positives. The dently duplicating the behavior of some existing results of two tested programs may differ and yet application. Identical behavior is important when old still be correct, depending on the requirements. For software is being retired in favor of a new implementa- example, a C compiler may freely choose among alter- tion, or when the new software is challenging a domi- natives for unspecified, undefined, or implementation- nant competitor. defined constructs as detailed in the C Standard.3 Similarly, even for required diagnostics, the form of Seeking an Oracle the diagnostic is unspecified and therefore difficult to The ugliest problem in testing is evaluating the result compare across systems. The third issue deals with the of a test. A regression harness can automatically check amount of noise in the generated test case. Given a that a result has not changed, but this information successful random test, there is likely to be a much serves no purpose unless the result is known to be cor- shorter test that exposes the same bug. The developer Digital Technical Journal Vol. 10 No. 1 1998 101 who is seeking to fix the bug strongly prefers to use the level. One compiler could not handle 0x000001 if shorter test. The fourth issue concerns comparing pro- there were too many leading zeros in the hexadecimal grams that must run on different platforms. Differential number. Another compiler crashed when faced with testing is easily adapted to distributed testing. the floating-point constant 1E1000. Many compilers failed to properly process digraphs and trigraphs. Test Case Quality Stochastic Grammar Writing good tests requires a deep knowledge of the A vocabulary is a set of two kinds of symbols: terminal system under test. Writing a good test generator and nonterminal. The terminal symbols are what one requires embedding that same knowledge in the gen- can write down. The nonterminal symbols are names erator. This section presents the testing of C compilers for higher level language structures. For example, the as an example. symbol “+” is a terminal symbol, and the symbol “additive-expression” is a nonterminal symbol of the Testing C Compilers C programming language. A grammar is a set of rules For a C compiler, we constructed sample C source files for describing a language. A rule has a left side and a at several levels of increasing quality. right side.
Load more

Recommended publications
  • Master's Project at ICT, KTH Examensarbete Vid ICT, KTH
    Master's Project at ICT, KTH Examensarbete vid ICT, KTH Automated source-to-source translation from Java to C++ Automatisk källkodsöversättning från Java till C++ JACEK SIEKA [email protected] Master's Thesis in Software Engineering Examensarbete inom programvaruteknik Supervisor and examiner: Thomas Sjöland Handledare och examinator: Thomas Sjöland Abstract Reuse of Java libraries and interoperability with platform native components has traditionally been limited to the application programming interface offered by the reference implementation of Java, the Java Native Interface. In this thesis the feasibility of another approach, automated source-to-source translation from Java to C++, is examined starting with a survey of the current research. Using the Java Language Specification as guide, translations for the constructs of the Java language are proposed, focusing on and taking advantage of the syntactic and semantic similarities between the two languages. Based on these translations, a tool for automatically translating Java source code to C++ has been developed and is presented in the text. Experimentation shows that a simple application and the core Java libraries it depends on can automatically be translated, producing equal output when built and run. The resulting source code is readable and maintainable, and therefore suitable as a starting point for further development in C++. With the fully automated process described, source-to-source translation becomes a viable alternative when facing a need for functionality already implemented in a Java library or application, saving considerable resources that would otherwise have to be spent rewriting the code manually. Sammanfattning Återanvändning av Java-bibliotek och interoperabilitet med plattformspecifika komponenter har traditionellt varit begränsat till det programmeringsgränssnitt som erbjuds av referensimplementationen av Java, Java Native Interface.
    [Show full text]
  • Concept Programming in XL the Art of Turning Ideas Into Programs
    Concept Programming in XL The Art of Turning Ideas into Programs TM Concept Programming 1 2 Concept Programming Chapter 1— Introduction . 13 1.1. Why another language? . 14 1.2. Who should read this book?. 16 1.3. A quick tour of XL . 16 1.4. Contents Overview. 17 Chapter 2— Simple Examples . 19 2.1. Hello World . 20 2.2. Factorial Function . 21 2.3. Computing a Maximum . 24 2.4. Symbolic Differentiation . 26 Part I — Concept Programming . 31 Chapter 3— Concepts? . 33 3.1. Programming Philosophy. 34 3.2. Translating concepts. 37 3.3. Pseudo-Metrics. 45 3.4. Concept Mismatch . 48 3.5. In Conclusion . 51 Chapter 4— The Trouble with Programming . 53 4.1. Scale Complexity and Moore s Law . 54 4.2. Domain Complexity . 57 4.3. Artificial complexity . 58 4.4. Business Complexity . 64 4.5. The Grim State of Software Quality . 68 Chapter 5— From Concepts to Code . 71 5.1. Turning Ideas into Code. 72 Concept Programming 3 5.2. Abstractions . 77 5.3. Abstractions in Programs . 84 Part II —Core Language . .93 Chapter 6— Compiling XL . 95 6.1. Representing Programs . 96 6.2. Understanding Programs . 98 6.3. Compiling XL . 102 Chapter 7— Syntax . 105 7.1. Source Text. 106 7.2. Tokens . 107 7.3. Parse Tree . 112 7.4. Practical Considerations. 121 7.5. Beyond the Syntax . 126 Chapter 8— Declarations . 127 8.1. Variables. 128 8.2. Subroutines. 134 8.3. Types . 143 8.4. Constants . 143 Chapter 9— Control Flow . 145 9.1. Tests . 145 9.2.
    [Show full text]
  • The Opengl ES Shading Language
    The OpenGL ES® Shading Language Language Version: 3.00 Document Revision: 6 29 January 2016 Editor: Robert J. Simpson, Qualcomm OpenGL GLSL editor: John Kessenich, LunarG GLSL version 1.1 Authors: John Kessenich, Dave Baldwin, Randi Rost Copyright © 2008-2016 The Khronos Group Inc. All Rights Reserved. This specification is protected by copyright laws and contains material proprietary to the Khronos Group, Inc. It or any components may not be reproduced, republished, distributed, transmitted, displayed, broadcast, or otherwise exploited in any manner without the express prior written permission of Khronos Group. You may use this specification for implementing the functionality therein, without altering or removing any trademark, copyright or other notice from the specification, but the receipt or possession of this specification does not convey any rights to reproduce, disclose, or distribute its contents, or to manufacture, use, or sell anything that it may describe, in whole or in part. Khronos Group grants express permission to any current Promoter, Contributor or Adopter member of Khronos to copy and redistribute UNMODIFIED versions of this specification in any fashion, provided that NO CHARGE is made for the specification and the latest available update of the specification for any version of the API is used whenever possible. Such distributed specification may be reformatted AS LONG AS the contents of the specification are not changed in any way. The specification may be incorporated into a product that is sold as long as such product includes significant independent work developed by the seller. A link to the current version of this specification on the Khronos Group website should be included whenever possible with specification distributions.
    [Show full text]
  • A Typesetter's Toolkit
    A Typesetter's Toolht Pierre A. MacKay Department of Classics DH-10, Department of Near Eastern Languages and Civilization (DH-20) University of Washington, Seattle, WA 98195 U.S.A. Internet: mackayecs .washi ngton .edu Abstract Over the past ten years, a variety of publications in the humanities has required the development of special capabilities, particularly in fonts for non-English text. A number of these are of general interest, since they involve strategies for remapping fonts and for generating composite glyphs from an existing repertory of simple characters. Techniques for selective compilation and remapping of METAFONTs are described here, together with a program for generating Postscript-style Adobe Font Metrics from Computer Modern Fonts. Introduction usually start out in a technology that was out of date in the first place. In the past year we have History. For the past ten years I have served as had to work with one text made up of extensive the technical department of a typesetting effort quotations from Greek inscriptions, composed in which produces scholarly publications for the fields a version of RUNOFF dating from about 1965 and of Classics and Near Eastern Languages, with occa- modified by an unknown hand to produce Greek sional forays into the related social sciences. Right on an unknown printer. The final version of the from the beginning these texts have presented the manuscript was submitted to the editorial board in challenge of special characters, both simplex and 1991. I have no idea when the unique adaptation for composite. We have used several different roman- epigraphical Greek was first written.
    [Show full text]
  • Orthographies in Early Modern Europe
    Orthographies in Early Modern Europe Orthographies in Early Modern Europe Edited by Susan Baddeley Anja Voeste De Gruyter Mouton An electronic version of this book is freely available, thanks to the support of libra- ries working with Knowledge Unlatched. KU is a collaborative initiative designed to make high quality books Open Access. More information about the initiative can be found at www.knowledgeunlatched.org An electronic version of this book is freely available, thanks to the support of libra- ries working with Knowledge Unlatched. KU is a collaborative initiative designed to make high quality books Open Access. More information about the initiative can be found at www.knowledgeunlatched.org ISBN 978-3-11-021808-4 e-ISBN (PDF) 978-3-11-021809-1 e-ISBN (EPUB) 978-3-11-021806-2 ISSN 0179-0986 e-ISSN 0179-3256 ThisISBN work 978-3-11-021808-4 is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License, ase-ISBN of February (PDF) 978-3-11-021809-1 23, 2017. For details go to http://creativecommons.org/licenses/by-nc-nd/3.0/. e-ISBN (EPUB) 978-3-11-021806-2 LibraryISSN 0179-0986 of Congress Cataloging-in-Publication Data Ae-ISSN CIP catalog 0179-3256 record for this book has been applied for at the Library of Congress. ISBN 978-3-11-028812-4 e-ISBNBibliografische 978-3-11-028817-9 Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliogra- fie;This detaillierte work is licensed bibliografische under the DatenCreative sind Commons im Internet Attribution-NonCommercial-NoDerivs über 3.0 License, Libraryhttp://dnb.dnb.deas of February of Congress 23, 2017.abrufbar.
    [Show full text]
  • Programming Languages & Tools
    I PROGRAMMING LANGUAGES & TOOLS Volume 10 Number 1 1998 Editorial The Digital Technicaljoumalis a refereed AlphaServer, Compaq, tl1e Compaq logo, jane C. Blake, Managing Editor journal published quarterly by Compaq DEC, DIGITAL, tl1e DIGITAL logo, 550 ULTIUX, Kathleen M. Stetson, Editor Computer Corporation, King Street, VAX,and VMS are registered 01460-1289. Hden L. Patterson, Editor LKGI-2jW7, Littleton, MA in the U.S. Patent and Trademark Office. Hard-copy subscriptions can be ordered by DIGITAL UNIX, FX132, and OpenVMS Circulation sending a check in U.S. funds (made payable arc trademarks of Compaq Computer Kristine M. Lowe, Administrator to Compaq Computer Corporation) to the Corporation. published-by address. General subscription Production rates arc $40.00 (non-U.S. $60) for four issues Intel and Pentium are registered u·ademarks $75.00 $115) Christa W. Jessica, Production Editor and (non-U.S. for eight issues. of Intel Corporation. University and college professors and Ph.D. Elizabeth McGrail, Typographer I lUX is a registered trademark of Silicon students in the elecu·icaJ engineering and com­ Peter R. Woodbury, Illustrator Graphics, Inc. puter science fields receive complimentary sub­ scriptions upon request. Compaq customers Microsoft, Visual C++, Windows, and Advisory Board may qualify tor giftsubscriptions and arc encour­ Windows NT are registered trademarks Thomas F. Gannon, Chairman (Acting) aged to contact tl1eir sales representatives. of Microsoft Corporation. Scott E. Cutler Donald Z. Harbert Electronic subscriptions are available at MIPS is a registered trademark of MIPS William A. Laing no charge by accessing URL Technologies, Inc. Richard F. Lary http:jjwww.digital.com/subscription.
    [Show full text]
  • On the Creation of a Pronunciation Dictionary for Hungarian
    On the creation of a pronunciation dictionary for Hungarian Stephen M. Grimes [email protected] August 2007 Abstract This report describes the process of creating a pronunciation dictionary and phonological lexicon for Hungarian for the purpose of aiding in linguistic research on Hungarian phonology and phonotactics. The pronunciation dictionary was created by transforming orthographic forms to pronunciation representations by taking advantage of systematic deviations between Hungarian orthography and pronunciation. It is argued that the “automated” creation of such a dictionary is reasonably expected to be accurate due to the relative similarity of Hungarian orthography to actual pronunciation. This document includes discussion of goals and standards for creating a Hungarian pronunciation dictionary, and each phonological change creating a mismatch between orthography and pronunciation is highlighted. Future developments and additions to the current dictionary are also suggested as well as strategies for evaluating the quality of the dictionary. Finally, potential applications to linguistic research are discussed. 1 Introduction While students of the English language quickly learn that English spelling is by no means consistent, many Hungarians believe that the Hungarian alphabet is completely phonetic. Here, a phonetic alphabet refers to the existence of a one-to-one mapping between symbol and sound. It can quite easily be demonstrated by counter-example that 1 Hungarian orthography is not phonetic, and in fact several types of orthographic- pronunciation discrepancies exist. Consider as an example the word /szabadság/ 1 [sabatʃ:a:g] ‘freedom, liberty’ , in which no fewer than four orthographic-pronunciation discrepancies can be identified with the written form of this word: (1) a.
    [Show full text]
  • Simple Ciphers
    Swenson c02.tex V3 - 01/29/2008 1:07pm Page 1 CHAPTER 1 Simple Ciphers As long as there has been communication, there has been an interest in keeping some of this information confidential. As written messages became more widespread, especially over distances, people learned how susceptible this particular medium is to being somehow compromised: The messages can be easily intercepted, read, destroyed, or modified. Some protective methods were employed, such as sealing a message with a wax seal, which serves to show the communicating parties that the message is genuine and had not been intercepted. This, however, did nothing to actually conceal the contents. This chapter explores some of the simplest methods for obfuscating the contents of communications. Any piece of written communication has some set of symbols that constitute allowed constructs, typically, words, syllables, or other meaningful ideas. Some of the simple methods first used involved simply manipulating this symbol set, which the cryptologic community often calls an alphabet regardless of the origin of the language. Other older tricks involved jumbling up the ordering of the presentation of these symbols. Many of these techniques were in regular use up until a little more than a century ago; it is interesting to note that even though these techniques aren’t sophisticated,COPYRIGHTED newspapers often publish MATERIAL puzzles called cryptograms or cryptoquips employing these cryptographic techniques for readers to solve. Many books have been published that cover the use, history, and cryptanal- ysis of simple substitution and transposition ciphers, which we discuss in this chapter. (For example, some of the resources for this chapter are References [2] and [4].) This chapter is not meant to replace a rigorous study of these techniques, such as is contained in many of these books, but merely to expose the reader to the contrast between older methods of cryptanalysis and newer methods.
    [Show full text]
  • PDF Hosted at the Radboud Repository of the Radboud University Nijmegen
    PDF hosted at the Radboud Repository of the Radboud University Nijmegen The following full text is a publisher's version. For additional information about this publication click this link. http://hdl.handle.net/2066/150793 Please be advised that this information was generated on 2021-10-02 and may be subject to change. THE DIGITAL LITERACY INSTRUCTOR: DEVELOPING AUTOMATIC SPEECH RECOGNITION AND SELECTING LEARNING MATERIAL FOR OPAQUE AND TRANSPARENT ORTHOGRAPHIES Catia Cucchiarini, Radboud University Nijmegen Marta Dawidowicz, University of Vienna Enas Filimban, Newcastle University Taina Tammelin-Laine, University of Jyväskylä Ineke van de Craats and Helmer Strik, R adboud University Nijmegen Abstract While learning a new language can now be a lot of fun because attractive interactive games and multimedia materials have become widely available, many of these products generally do not cater for non-literates and low-literates. In addition, their limited reading capabilities make it difficult for these learners to access language learning materials that are nowadays available for free on the web. More advanced course materials that can make learning to read and spell in a second language (L2) more enjoyable would therefore be very welcome. This article reports on such an initiative, the DigLin project, which aims at developing and testing online basic course material for non-literate L2 adult learners who learn to read and spell either in Finnish, Dutch, German or English, while interacting with the computer, which continuously provides feedback like the most determined instructor. The most innovative feature of DigLin is that in production exercises learners can read aloud and get feedback on their speech production.
    [Show full text]
  • An Introduction to Modern Cryptology Within an Algebraic Framework John Szwast Eastern Washington University
    Eastern Washington University EWU Digital Commons EWU Masters Thesis Collection Student Research and Creative Works 2012 An introduction to modern cryptology within an algebraic framework John Szwast Eastern Washington University Follow this and additional works at: http://dc.ewu.edu/theses Part of the Physical Sciences and Mathematics Commons Recommended Citation Szwast, John, "An introduction to modern cryptology within an algebraic framework" (2012). EWU Masters Thesis Collection. 13. http://dc.ewu.edu/theses/13 This Thesis is brought to you for free and open access by the Student Research and Creative Works at EWU Digital Commons. It has been accepted for inclusion in EWU Masters Thesis Collection by an authorized administrator of EWU Digital Commons. For more information, please contact [email protected]. AN INTRODUCTION TO MODERN CRYPTOLOGY WITHIN AN ALGEBRAIC FRAMEWORK A Thesis Presented To Eastern Washington University Cheney, Washington In Partial Fulfillment of the Requirements for the Degree Master of Science By John Szwast Fall 2012 THESIS OF JOHN SZWAST APPROVED BY DATE: DR. RON GENTLE, GRADUATE STUDY COMMITTEE DATE: DR. DALE GARRAWAY, GRADUATE STUDY COMMITTEE DATE: DR. PAUL SCHIMPF, GRADUATE STUDY COMMITTEE Contents List of Figures vii List of Tables viii 1 Introduction 1 1.1 Scope . .1 1.2 Background . .2 1.3 Conventions and Notations . .2 1.4 Overview . .3 1.5 General Definitions . .4 1.6 Bit Operations and Big-O Notation . .5 1.6.1 Overview . .5 1.6.2 Time Estimates for Integer Arithmetic . .8 1.6.3 Time estimates for modular arithmetic . 12 1.7 Probability . 15 iii CONTENTS CONTENTS 1.7.1 Discrete distributions .
    [Show full text]
  • UNITED NATIONS Working Paper No
    UNITED NATIONS Working - Paper- No. 112 GROUP OF EXPERTS ON GEOGRAPHICAL NAMES Twenty-second Session New York, 20-29 Anril2004 Item 17 of the Provisional Agenda TOPONYMIC GUIDELINES FOR MAP EDITORS AND OTHER EDITORS Toponymic guidelines for map editors and other editors ITALY (Third draft edition)* * Submitted by Italy Stato Ma&ore della Difesa Istituto Geogl-atico Miiitare First edition prepared in 1987, by prof. Sandro Toniolo, on account of the Italian Association of Cartograpl~y. Second edition updated in 1997, by COI. tee. (geo) Maurizio Pampaloni. Italian Military Geographic Institute. Third edition, updated in 2004. by D.r Andrea Cantile, Italian Military Geographic Institute: translation Ldt. Col. Giovanni Orril, Italian Military Geographic Institute: supervision D.r Salvatore Arca, Italian Military Geographic institute. TABLE OF CONTENTS 1 LAA’GUAGES pag. 5 1.1 General remarks S 1.2 Official hgLlages s 1.2.1 General remarks 5 1.2.2 The Italian alphabet 6 1.2.3 Pronunciation of Italian words 6 1.2.4 Characteristic of the Italian language and orthogl-aphy necessary for the understanding of maps 8 1.2.4.1 Diphthongs and triphthongs s 1.2.4.2 Digraphs and trigraplx 8 I .2.4.3 Spaced-out lettering and division into syllables ‘3 1.2.4.4 Capitalization 9 1.2.4.5 Stress and accents 10 1.2.4.6 Gender 10 1.2.4.7 Formation of the plural II 1.2.4.8 Articles 11 1.2.4.9 Adjectives 11 1.2.4.10 Prepositions 12 1.2.4.11 Elision 12 1.2.4.12 The apocope of ~IOLUIS 12 1.2.4.13 Compound geographical names 12 1.2.5 Italian dialects 14 1.2.6 Linguistic
    [Show full text]
  • Oklahoma Academic Standards ENGLISH LANGUAGE ARTS
    Oklahoma Academic Standards ENGLISH LANGUAGE ARTS Education Oklahoma Academic Standards for English Language Arts Introduction ​ ​ Table of Contents Guiding Principles 3 Grade 5 62 Eight Overarching Standards 6 Grade 6 72 Navigating the Standards 9 Grade 7 80 Pre-Kindergarten 10 Grade 8 88 Kindergarten 16 Grade 9 96 Grade 1 24 Grade 10 104 Grade 2 34 Grade 11 112 Grade 3 44 Grade 12 120 Grade 4 53 2 Oklahoma Academic Standards for English Language Arts Introduction ​ ​ Guiding Principles Teachers use standards as guides for developing curriculum and instruction that is engaging, challenging, and sequenced for the students in their care. By nature, acquiring language arts knowledge and skills is a recursive learning endeavor: students revisit concepts again and again as they use language at increasingly sophisticated levels. Because of this recursive learning process, language arts learning will not progress for students in the strictly linear way it may in other content areas. Nonetheless, it is important for any set of standards to provide “concise, written descriptions of what students are expected to know and be able to do at a specific stage of their education” (Great Schools Partnership, 2014). In order to make this document a clear, coherent description of what students are expected to know and be able to do at specific stages, the writers have adopted some guiding principles for design and organization: clarity, coherence, and purpose. Clarity ● Standard statements are written with verbs that indicate specifically what learning students must demonstrate and at what depth. When students compare, paraphrase, predict, or summarize, they are able to show a broader range of mastery of a concept than when they are ​ ​ ​ ​ expected to identify or recognize.
    [Show full text]