{'fraction_non_alphanumeric': 0.030233884768967486, 'fraction_numerical': 0.0031374786081003994, 'mean_word_length': 5.744230769230769, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Siddhartha 1 : A Technique for Developing Domain-Specific Testing Tools

Existing specification-based software testing tools are difficult to use in many real-world application domains. This occurs when a tool’s design is constrained along dimensions (which are often theoretically-oriented) which are incompatible with the constraints at work in the application domain (which are often business-oriented). When this problem occurs and the benefits to the software organization clearly outweigh the costs, test engineers develop custom, domain-specific, specification-based testing tools. When this problem occurs and the benefits do not clearly outweigh the costs, rigorous software testing may be forgone. This paper describes Siddhartha. Siddhartha is a technique for constructing domain-specific, specification-based software testing tools . Siddhartha provides essential automation support for specification-based testing in application domains that are “untestable” by existing tools. Siddhartha represents a defined, disciplined alternative to ad hoc development of domain-specific testing tools. Domain-specific testing tools constructed under Siddhartha take advantage of available software tool support and allow existing (legacy) development processes to remain intact. By characterizing the natural variation that exists within each domain, and building testing tools that operate within those constraints, Siddhartha supports “outlying” application domains, which cannot be supported by existing tools. Siddhartha is composed of a domain-independent library of software tool components, a reference architecture, and a process model. By following the process model, a test engineer extends the library to construct a domain-specific program synthesizer conforming to the reference architecture. The synthesizer is an essential, 1 1 Siddhartha Gautama /si-’dar-te-’gaut-e-me/ ca 563-ca 483 B.C. The Buddha /’bud-e, ‘bud-/ Indian philosopher; founder of Buddhism We chose the name Siddhartha as an extension of the acronym “SDRTA,” which stands for Signature Discovery, Reformulation, Translation, and Automation. SDRTA served as our early research paradigm. In Sanskrit, Siddhartha means “he who has attainted.” Because this research began while Reyes attainted his Ph.D., we thought Siddhartha was an exceptionally appropriate name for the technique. specification-based, software testing tool. The synthesizer transforms test specifications written in formal, domain-specific languages into corresponding test driver-oracle programs. Test driver-oracle programs automate test case execution and test case evaluation. This paper discusses the results of applying Siddhartha in two testing domains: requirements testing of Ada procedures against formal specifications written in SCR and regression testing of Ada procedures against earlier versions, assumed functionally equivalent. Ada procedures in these application domains are characterized by insufficiently defined interfaces and ubiquitous reference and assignment to global variables. We evaluate these domain-specific test synthesizers by replicating tests performed by the NASA Software Independent Verification and Validation Facility on the Operational Flight Program for the Production Support Flight Control Computer used on NASA Dryden Flight Research Center’s F/A-18B Hornet System Research Aircraft. This evaluation clarifies the prospective costs and benefits of applying Siddhartha within a software development organization.