Content deleted Content added
→Scope: [ { "data": { "card": { "network": "American Express", "number": "3777 658805 43528", "cvv": 4765, "pin": 2514, "balance": "$37573", "expiration-month": 8, "expiration-year": 2030 }, "customer": { "name": "Kim Fox", "address": "Dunbar Place 5464", "country": "Maldives" } } } ] Tags: Mobile edit Mobile web edit |
rv COI / citespam |
||
Line 74:
* ''[[Delta Debugging]]''{{snd}} a technique of automating test case simplification.<ref>{{cite book |last=Zeller |first=Andreas |date=2005 |title=Why Programs Fail: A Guide to Systematic Debugging |publisher=Morgan Kaufmann |isbn=1-55860-866-4}}</ref>{{rp|p.123}}<!-- for redirect from 'Saff Squeeze' -->
* ''Saff Squeeze''{{snd}} a technique of isolating failure within the test using progressive inlining of parts of the failing test.<ref>{{cite web|url=http://www.threeriversinstitute.org/HitEmHighHitEmLow.html|archive-url=https://web.archive.org/web/20120311131729/http://www.threeriversinstitute.org/HitEmHighHitEmLow.html|url-status=dead|archive-date=2012-03-11|title=Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze}}</ref><ref>{{cite web |last1=Rainsberger |first1=J.B. |title=The Saff Squeeze |url=https://blog.thecodewhisperer.com/permalink/the-saff-squeeze |website=The Code Whisperer |access-date=28 March 2022}}</ref>
* ''Causality tracking'': There are techniques to track the cause effect chains in the computation.<ref>{{cite journal|last=Zeller|first=Andreas|date=2002-11-01|title=Isolating cause-effect chains from computer programs|journal=ACM SIGSOFT Software Engineering Notes|volume=27|issue=6|pages=1–10|doi=10.1145/605466.605468|s2cid=12098165|issn=0163-5948}}</ref> Those techniques can be tailored for specific bugs, such as null pointer dereferences.<ref name="BondNethercote2007">{{cite book |last1=Bond|first1=Michael D.|title=Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07|last2=Nethercote|first2=Nicholas|last3=Kent|first3=Stephen W.|last4=Guyer|first4=Samuel Z.|last5=McKinley|first5=Kathryn S.|chapter=Tracking bad apples|year=2007|pages=405|doi=10.1145/1297027.1297057|isbn=9781595937865|s2cid=2832749
==Debugging for embedded systems==
In contrast to the general purpose computer software design environment, a primary characteristic of embedded environments is the sheer number of different platforms available to the developers (CPU architectures, vendors, operating systems, and their variants). Embedded systems are, by definition, not general-purpose designs: they are typically developed for a single task (or small range of tasks), and the platform is chosen specifically to optimize that application. Not only does this fact make life tough for embedded system developers, it also makes debugging and testing of these systems harder as well, since different debugging tools are needed for different platforms.
| |||