Обнаружение причины ошибки называется

To clean up transmission errors introduced by Earth’s atmosphere (left), Goddard scientists applied Reed–Solomon error correction (right), which is commonly used in CDs and DVDs. Typical errors include missing pixels (white) and false signals (black). The white stripe indicates a brief period when transmission was interrupted.

In information theory and coding theory with applications in computer science and telecommunication, error detection and correction (EDAC) or error control are techniques that enable reliable delivery of digital data over unreliable communication channels. Many communication channels are subject to channel noise, and thus errors may be introduced during transmission from the source to a receiver. Error detection techniques allow detecting such errors, while error correction enables reconstruction of the original data in many cases.

Definitions[edit]

Error detection is the detection of errors caused by noise or other impairments during transmission from the transmitter to the receiver.

Error correction is the detection of errors and reconstruction of the original, error-free data.

History[edit]

In classical antiquity, copyists of the Hebrew Bible were paid for their work according to the number of stichs (lines of verse). As the prose books of the Bible were hardly ever written in stichs, the copyists, in order to estimate the amount of work, had to count the letters.[1] This also helped ensure accuracy in the transmission of the text with the production of subsequent copies.[2][3] Between the 7th and 10th centuries CE a group of Jewish scribes formalized and expanded this to create the Numerical Masorah to ensure accurate reproduction of the sacred text. It included counts of the number of words in a line, section, book and groups of books, noting the middle stich of a book, word use statistics, and commentary.[1] Standards became such that a deviation in even a single letter in a Torah scroll was considered unacceptable.[4] The effectiveness of their error correction method was verified by the accuracy of copying through the centuries demonstrated by discovery of the Dead Sea Scrolls in 1947–1956, dating from c. 150 BCE-75 CE.[5]

The modern development of error correction codes is credited to Richard Hamming in 1947.[6] A description of Hamming’s code appeared in Claude Shannon’s A Mathematical Theory of Communication[7] and was quickly generalized by Marcel J. E. Golay.[8]

Principles[edit]

All error-detection and correction schemes add some redundancy (i.e., some extra data) to a message, which receivers can use to check consistency of the delivered message and to recover data that has been determined to be corrupted. Error detection and correction schemes can be either systematic or non-systematic. In a systematic scheme, the transmitter sends the original (error-free) data and attaches a fixed number of check bits (or parity data), which are derived from the data bits by some encoding algorithm. If error detection is required, a receiver can simply apply the same algorithm to the received data bits and compare its output with the received check bits; if the values do not match, an error has occurred at some point during the transmission. If error correction is required, a receiver can apply the decoding algorithm to the received data bits and the received check bits to recover the original error-free data. In a system that uses a non-systematic code, the original message is transformed into an encoded message carrying the same information and that has at least as many bits as the original message.

Good error control performance requires the scheme to be selected based on the characteristics of the communication channel. Common channel models include memoryless models where errors occur randomly and with a certain probability, and dynamic models where errors occur primarily in bursts. Consequently, error-detecting and correcting codes can be generally distinguished between random-error-detecting/correcting and burst-error-detecting/correcting. Some codes can also be suitable for a mixture of random errors and burst errors.

If the channel characteristics cannot be determined, or are highly variable, an error-detection scheme may be combined with a system for retransmissions of erroneous data. This is known as automatic repeat request (ARQ), and is most notably used in the Internet. An alternate approach for error control is hybrid automatic repeat request (HARQ), which is a combination of ARQ and error-correction coding.

Types of error correction[edit]

There are three major types of error correction:[9]

Automatic repeat request[edit]

Automatic repeat request (ARQ) is an error control method for data transmission that makes use of error-detection codes, acknowledgment and/or negative acknowledgment messages, and timeouts to achieve reliable data transmission. An acknowledgment is a message sent by the receiver to indicate that it has correctly received a data frame.

Usually, when the transmitter does not receive the acknowledgment before the timeout occurs (i.e., within a reasonable amount of time after sending the data frame), it retransmits the frame until it is either correctly received or the error persists beyond a predetermined number of retransmissions.

Three types of ARQ protocols are Stop-and-wait ARQ, Go-Back-N ARQ, and Selective Repeat ARQ.

ARQ is appropriate if the communication channel has varying or unknown capacity, such as is the case on the Internet. However, ARQ requires the availability of a back channel, results in possibly increased latency due to retransmissions, and requires the maintenance of buffers and timers for retransmissions, which in the case of network congestion can put a strain on the server and overall network capacity.[10]

For example, ARQ is used on shortwave radio data links in the form of ARQ-E, or combined with multiplexing as ARQ-M.

Forward error correction[edit]

Forward error correction (FEC) is a process of adding redundant data such as an error-correcting code (ECC) to a message so that it can be recovered by a receiver even when a number of errors (up to the capability of the code being used) are introduced, either during the process of transmission or on storage. Since the receiver does not have to ask the sender for retransmission of the data, a backchannel is not required in forward error correction. Error-correcting codes are used in lower-layer communication such as cellular network, high-speed fiber-optic communication and Wi-Fi,[11][12] as well as for reliable storage in media such as flash memory, hard disk and RAM.[13]

Error-correcting codes are usually distinguished between convolutional codes and block codes:

  • Convolutional codes are processed on a bit-by-bit basis. They are particularly suitable for implementation in hardware, and the Viterbi decoder allows optimal decoding.
  • Block codes are processed on a block-by-block basis. Early examples of block codes are repetition codes, Hamming codes and multidimensional parity-check codes. They were followed by a number of efficient codes, Reed–Solomon codes being the most notable due to their current widespread use. Turbo codes and low-density parity-check codes (LDPC) are relatively new constructions that can provide almost optimal efficiency.

Shannon’s theorem is an important theorem in forward error correction, and describes the maximum information rate at which reliable communication is possible over a channel that has a certain error probability or signal-to-noise ratio (SNR). This strict upper limit is expressed in terms of the channel capacity. More specifically, the theorem says that there exist codes such that with increasing encoding length the probability of error on a discrete memoryless channel can be made arbitrarily small, provided that the code rate is smaller than the channel capacity. The code rate is defined as the fraction k/n of k source symbols and n encoded symbols.

The actual maximum code rate allowed depends on the error-correcting code used, and may be lower. This is because Shannon’s proof was only of existential nature, and did not show how to construct codes that are both optimal and have efficient encoding and decoding algorithms.

Hybrid schemes[edit]

Hybrid ARQ is a combination of ARQ and forward error correction. There are two basic approaches:[10]

  • Messages are always transmitted with FEC parity data (and error-detection redundancy). A receiver decodes a message using the parity information and requests retransmission using ARQ only if the parity data was not sufficient for successful decoding (identified through a failed integrity check).
  • Messages are transmitted without parity data (only with error-detection information). If a receiver detects an error, it requests FEC information from the transmitter using ARQ and uses it to reconstruct the original message.

The latter approach is particularly attractive on an erasure channel when using a rateless erasure code.

Types of error detection[edit]

Error detection is most commonly realized using a suitable hash function (or specifically, a checksum, cyclic redundancy check or other algorithm). A hash function adds a fixed-length tag to a message, which enables receivers to verify the delivered message by recomputing the tag and comparing it with the one provided.

There exists a vast variety of different hash function designs. However, some are of particularly widespread use because of either their simplicity or their suitability for detecting certain kinds of errors (e.g., the cyclic redundancy check’s performance in detecting burst errors).

Minimum distance coding[edit]

A random-error-correcting code based on minimum distance coding can provide a strict guarantee on the number of detectable errors, but it may not protect against a preimage attack.

Repetition codes[edit]

A repetition code is a coding scheme that repeats the bits across a channel to achieve error-free communication. Given a stream of data to be transmitted, the data are divided into blocks of bits. Each block is transmitted some predetermined number of times. For example, to send the bit pattern 1011, the four-bit block can be repeated three times, thus producing 1011 1011 1011. If this twelve-bit pattern was received as 1010 1011 1011 – where the first block is unlike the other two – an error has occurred.

A repetition code is very inefficient and can be susceptible to problems if the error occurs in exactly the same place for each group (e.g., 1010 1010 1010 in the previous example would be detected as correct). The advantage of repetition codes is that they are extremely simple, and are in fact used in some transmissions of numbers stations.[14][15]

Parity bit[edit]

A parity bit is a bit that is added to a group of source bits to ensure that the number of set bits (i.e., bits with value 1) in the outcome is even or odd. It is a very simple scheme that can be used to detect single or any other odd number (i.e., three, five, etc.) of errors in the output. An even number of flipped bits will make the parity bit appear correct even though the data is erroneous.

Parity bits added to each word sent are called transverse redundancy checks, while those added at the end of a stream of words are called longitudinal redundancy checks. For example, if each of a series of m-bit words has a parity bit added, showing whether there were an odd or even number of ones in that word, any word with a single error in it will be detected. It will not be known where in the word the error is, however. If, in addition, after each stream of n words a parity sum is sent, each bit of which shows whether there were an odd or even number of ones at that bit-position sent in the most recent group, the exact position of the error can be determined and the error corrected. This method is only guaranteed to be effective, however, if there are no more than 1 error in every group of n words. With more error correction bits, more errors can be detected and in some cases corrected.

There are also other bit-grouping techniques.

Checksum[edit]

A checksum of a message is a modular arithmetic sum of message code words of a fixed word length (e.g., byte values). The sum may be negated by means of a ones’-complement operation prior to transmission to detect unintentional all-zero messages.

Checksum schemes include parity bits, check digits, and longitudinal redundancy checks. Some checksum schemes, such as the Damm algorithm, the Luhn algorithm, and the Verhoeff algorithm, are specifically designed to detect errors commonly introduced by humans in writing down or remembering identification numbers.

Cyclic redundancy check[edit]

A cyclic redundancy check (CRC) is a non-secure hash function designed to detect accidental changes to digital data in computer networks. It is not suitable for detecting maliciously introduced errors. It is characterized by specification of a generator polynomial, which is used as the divisor in a polynomial long division over a finite field, taking the input data as the dividend. The remainder becomes the result.

A CRC has properties that make it well suited for detecting burst errors. CRCs are particularly easy to implement in hardware and are therefore commonly used in computer networks and storage devices such as hard disk drives.

The parity bit can be seen as a special-case 1-bit CRC.

Cryptographic hash function[edit]

The output of a cryptographic hash function, also known as a message digest, can provide strong assurances about data integrity, whether changes of the data are accidental (e.g., due to transmission errors) or maliciously introduced. Any modification to the data will likely be detected through a mismatching hash value. Furthermore, given some hash value, it is typically infeasible to find some input data (other than the one given) that will yield the same hash value. If an attacker can change not only the message but also the hash value, then a keyed hash or message authentication code (MAC) can be used for additional security. Without knowing the key, it is not possible for the attacker to easily or conveniently calculate the correct keyed hash value for a modified message.

Error correction code[edit]

Any error-correcting code can be used for error detection. A code with minimum Hamming distance, d, can detect up to d − 1 errors in a code word. Using minimum-distance-based error-correcting codes for error detection can be suitable if a strict limit on the minimum number of errors to be detected is desired.

Codes with minimum Hamming distance d = 2 are degenerate cases of error-correcting codes and can be used to detect single errors. The parity bit is an example of a single-error-detecting code.

Applications[edit]

Applications that require low latency (such as telephone conversations) cannot use automatic repeat request (ARQ); they must use forward error correction (FEC). By the time an ARQ system discovers an error and re-transmits it, the re-sent data will arrive too late to be usable.

Applications where the transmitter immediately forgets the information as soon as it is sent (such as most television cameras) cannot use ARQ; they must use FEC because when an error occurs, the original data is no longer available.

Applications that use ARQ must have a return channel; applications having no return channel cannot use ARQ.

Applications that require extremely low error rates (such as digital money transfers) must use ARQ due to the possibility of uncorrectable errors with FEC.

Reliability and inspection engineering also make use of the theory of error-correcting codes.[16]

Internet[edit]

In a typical TCP/IP stack, error control is performed at multiple levels:

  • Each Ethernet frame uses CRC-32 error detection. Frames with detected errors are discarded by the receiver hardware.
  • The IPv4 header contains a checksum protecting the contents of the header. Packets with incorrect checksums are dropped within the network or at the receiver.
  • The checksum was omitted from the IPv6 header in order to minimize processing costs in network routing and because current link layer technology is assumed to provide sufficient error detection (see also RFC 3819).
  • UDP has an optional checksum covering the payload and addressing information in the UDP and IP headers. Packets with incorrect checksums are discarded by the network stack. The checksum is optional under IPv4, and required under IPv6. When omitted, it is assumed the data-link layer provides the desired level of error protection.
  • TCP provides a checksum for protecting the payload and addressing information in the TCP and IP headers. Packets with incorrect checksums are discarded by the network stack and eventually get retransmitted using ARQ, either explicitly (such as through three-way handshake) or implicitly due to a timeout.

Deep-space telecommunications[edit]

The development of error-correction codes was tightly coupled with the history of deep-space missions due to the extreme dilution of signal power over interplanetary distances, and the limited power availability aboard space probes. Whereas early missions sent their data uncoded, starting in 1968, digital error correction was implemented in the form of (sub-optimally decoded) convolutional codes and Reed–Muller codes.[17] The Reed–Muller code was well suited to the noise the spacecraft was subject to (approximately matching a bell curve), and was implemented for the Mariner spacecraft and used on missions between 1969 and 1977.

The Voyager 1 and Voyager 2 missions, which started in 1977, were designed to deliver color imaging and scientific information from Jupiter and Saturn.[18] This resulted in increased coding requirements, and thus, the spacecraft were supported by (optimally Viterbi-decoded) convolutional codes that could be concatenated with an outer Golay (24,12,8) code. The Voyager 2 craft additionally supported an implementation of a Reed–Solomon code. The concatenated Reed–Solomon–Viterbi (RSV) code allowed for very powerful error correction, and enabled the spacecraft’s extended journey to Uranus and Neptune. After ECC system upgrades in 1989, both crafts used V2 RSV coding.

The Consultative Committee for Space Data Systems currently recommends usage of error correction codes with performance similar to the Voyager 2 RSV code as a minimum. Concatenated codes are increasingly falling out of favor with space missions, and are replaced by more powerful codes such as Turbo codes or LDPC codes.

The different kinds of deep space and orbital missions that are conducted suggest that trying to find a one-size-fits-all error correction system will be an ongoing problem. For missions close to Earth, the nature of the noise in the communication channel is different from that which a spacecraft on an interplanetary mission experiences. Additionally, as a spacecraft increases its distance from Earth, the problem of correcting for noise becomes more difficult.

Satellite broadcasting[edit]

The demand for satellite transponder bandwidth continues to grow, fueled by the desire to deliver television (including new channels and high-definition television) and IP data. Transponder availability and bandwidth constraints have limited this growth. Transponder capacity is determined by the selected modulation scheme and the proportion of capacity consumed by FEC.

Data storage[edit]

Error detection and correction codes are often used to improve the reliability of data storage media.[19] A parity track capable of detecting single-bit errors was present on the first magnetic tape data storage in 1951. The optimal rectangular code used in group coded recording tapes not only detects but also corrects single-bit errors. Some file formats, particularly archive formats, include a checksum (most often CRC32) to detect corruption and truncation and can employ redundancy or parity files to recover portions of corrupted data. Reed-Solomon codes are used in compact discs to correct errors caused by scratches.

Modern hard drives use Reed–Solomon codes to detect and correct minor errors in sector reads, and to recover corrupted data from failing sectors and store that data in the spare sectors.[20] RAID systems use a variety of error correction techniques to recover data when a hard drive completely fails. Filesystems such as ZFS or Btrfs, as well as some RAID implementations, support data scrubbing and resilvering, which allows bad blocks to be detected and (hopefully) recovered before they are used.[21] The recovered data may be re-written to exactly the same physical location, to spare blocks elsewhere on the same piece of hardware, or the data may be rewritten onto replacement hardware.

Error-correcting memory[edit]

Dynamic random-access memory (DRAM) may provide stronger protection against soft errors by relying on error-correcting codes. Such error-correcting memory, known as ECC or EDAC-protected memory, is particularly desirable for mission-critical applications, such as scientific computing, financial, medical, etc. as well as extraterrestrial applications due to the increased radiation in space.

Error-correcting memory controllers traditionally use Hamming codes, although some use triple modular redundancy. Interleaving allows distributing the effect of a single cosmic ray potentially upsetting multiple physically neighboring bits across multiple words by associating neighboring bits to different words. As long as a single-event upset (SEU) does not exceed the error threshold (e.g., a single error) in any particular word between accesses, it can be corrected (e.g., by a single-bit error-correcting code), and the illusion of an error-free memory system may be maintained.[22]

In addition to hardware providing features required for ECC memory to operate, operating systems usually contain related reporting facilities that are used to provide notifications when soft errors are transparently recovered. One example is the Linux kernel’s EDAC subsystem (previously known as Bluesmoke), which collects the data from error-checking-enabled components inside a computer system; besides collecting and reporting back the events related to ECC memory, it also supports other checksumming errors, including those detected on the PCI bus.[23][24][25] A few systems[specify] also support memory scrubbing to catch and correct errors early before they become unrecoverable.

See also[edit]

  • Berger code
  • Burst error-correcting code
  • ECC memory, a type of computer data storage
  • Link adaptation
  • List of algorithms § Error detection and correction
  • List of hash functions

References[edit]

  1. ^ a b «Masorah». Jewish Encyclopedia.
  2. ^ Pratico, Gary D.; Pelt, Miles V. Van (2009). Basics of Biblical Hebrew Grammar: Second Edition. Zondervan. ISBN 978-0-310-55882-8.
  3. ^ Mounce, William D. (2007). Greek for the Rest of Us: Using Greek Tools Without Mastering Biblical Languages. Zondervan. p. 289. ISBN 978-0-310-28289-1.
  4. ^ Mishneh Torah, Tefillin, Mezuzah, and Sefer Torah, 1:2. Example English translation: Eliyahu Touger. The Rambam’s Mishneh Torah. Moznaim Publishing Corporation.
  5. ^ Brian M. Fagan (5 December 1996). «Dead Sea Scrolls». The Oxford Companion to Archaeology. Oxford University Press. ISBN 0195076184.
  6. ^ Thompson, Thomas M. (1983), From Error-Correcting Codes through Sphere Packings to Simple Groups, The Carus Mathematical Monographs (#21), The Mathematical Association of America, p. vii, ISBN 0-88385-023-0
  7. ^ Shannon, C.E. (1948), «A Mathematical Theory of Communication», Bell System Technical Journal, 27 (3): 379–423, doi:10.1002/j.1538-7305.1948.tb01338.x, hdl:10338.dmlcz/101429, PMID 9230594
  8. ^ Golay, Marcel J. E. (1949), «Notes on Digital Coding», Proc.I.R.E. (I.E.E.E.), 37: 657
  9. ^ Gupta, Vikas; Verma, Chanderkant (November 2012). «Error Detection and Correction: An Introduction». International Journal of Advanced Research in Computer Science and Software Engineering. 2 (11). S2CID 17499858.
  10. ^ a b A. J. McAuley, Reliable Broadband Communication Using a Burst Erasure Correcting Code, ACM SIGCOMM, 1990.
  11. ^ Shah, Pradeep M.; Vyavahare, Prakash D.; Jain, Anjana (September 2015). «Modern error correcting codes for 4G and beyond: Turbo codes and LDPC codes». 2015 Radio and Antenna Days of the Indian Ocean (RADIO). pp. 1–2. doi:10.1109/RADIO.2015.7323369. ISBN 978-9-9903-7339-4. S2CID 28885076. Retrieved 22 May 2022.
  12. ^ «IEEE SA — IEEE 802.11ac-2013». IEEE Standards Association.
  13. ^ «Transition to Advanced Format 4K Sector Hard Drives | Seagate US». Seagate.com. Retrieved 22 May 2022.
  14. ^ Frank van Gerwen. «Numbers (and other mysterious) stations». Archived from the original on 12 July 2017. Retrieved 12 March 2012.
  15. ^ Gary Cutlack (25 August 2010). «Mysterious Russian ‘Numbers Station’ Changes Broadcast After 20 Years». Gizmodo. Archived from the original on 5 July 2017. Retrieved 12 March 2012.
  16. ^ Ben-Gal I.; Herer Y.; Raz T. (2003). «Self-correcting inspection procedure under inspection errors» (PDF). IIE Transactions. IIE Transactions on Quality and Reliability, 34(6), pp. 529-540. Archived from the original (PDF) on 2013-10-13. Retrieved 2014-01-10.
  17. ^ K. Andrews et al., The Development of Turbo and LDPC Codes for Deep-Space Applications, Proceedings of the IEEE, Vol. 95, No. 11, Nov. 2007.
  18. ^ Huffman, William Cary; Pless, Vera S. (2003). Fundamentals of Error-Correcting Codes. Cambridge University Press. ISBN 978-0-521-78280-7.
  19. ^ Kurtas, Erozan M.; Vasic, Bane (2018-10-03). Advanced Error Control Techniques for Data Storage Systems. CRC Press. ISBN 978-1-4200-3649-7.[permanent dead link]
  20. ^ Scott A. Moulton. «My Hard Drive Died». Archived from the original on 2008-02-02.
  21. ^ Qiao, Zhi; Fu, Song; Chen, Hsing-Bung; Settlemyer, Bradley (2019). «Building Reliable High-Performance Storage Systems: An Empirical and Analytical Study». 2019 IEEE International Conference on Cluster Computing (CLUSTER). pp. 1–10. doi:10.1109/CLUSTER.2019.8891006. ISBN 978-1-7281-4734-5. S2CID 207951690.
  22. ^ «Using StrongArm SA-1110 in the On-Board Computer of Nanosatellite». Tsinghua Space Center, Tsinghua University, Beijing. Archived from the original on 2011-10-02. Retrieved 2009-02-16.
  23. ^ Jeff Layton. «Error Detection and Correction». Linux Magazine. Retrieved 2014-08-12.
  24. ^ «EDAC Project». bluesmoke.sourceforge.net. Retrieved 2014-08-12.
  25. ^ «Documentation/edac.txt». Linux kernel documentation. kernel.org. 2014-06-16. Archived from the original on 2009-09-05. Retrieved 2014-08-12.

Further reading[edit]

  • Shu Lin; Daniel J. Costello, Jr. (1983). Error Control Coding: Fundamentals and Applications. Prentice Hall. ISBN 0-13-283796-X.
  • SoftECC: A System for Software Memory Integrity Checking
  • A Tunable, Software-based DRAM Error Detection and Correction Library for HPC
  • Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing

External links[edit]

  • The on-line textbook: Information Theory, Inference, and Learning Algorithms, by David J.C. MacKay, contains chapters on elementary error-correcting codes; on the theoretical limits of error-correction; and on the latest state-of-the-art error-correcting codes, including low-density parity-check codes, turbo codes, and fountain codes.
  • ECC Page — implementations of popular ECC encoding and decoding routines
  1. Программирование и отладка.

Отла́дка
— этап разработки компьютерной программы,
на котором обнаруживают, локализуют и
устраняют ошибки. Чтобы понять, где
возникла ошибка, приходится :

  • узнавать
    текущие значения переменных;

  • выяснять,
    по какому пути выполнялась программа.

Существуют
две взаимодополняющие технологии
отладки.

  • Использование
    отладчиков — программ, которые включают
    в себя пользовательский интерфейс для
    пошагового выполнения программы:
    оператор за оператором, функция за
    функцией, с остановками на некоторых
    строках исходного кода или при достижении
    определённого условия.

  • Вывод
    текущего состояния программы с помощью
    расположенных в критических точках
    программы операторов вывода — на экран,
    принтер, громкоговоритель или в файл.
    Вывод отладочных сведений в файл
    называется журналированием.

Место
отладки в цикле разработки программы

Типичный
цикл разработки, за время жизни программы
многократно повторяющийся, выглядит
примерно так:

Программирование
— внесение в программу новой
функциональности, исправление ошибок
в имеющейся.

Тестирование
(ручное или автоматизированное;
программистом, тестером или пользователем;
«дымовое», в режиме чёрного ящика или
модульное…) — обнаружение факта ошибки.

Воспроизведение
ошибки — выяснение условий, при которых
ошибка случается. Это может оказаться
непростой задачей при программировании
параллельных процессов и при некоторых
необычных ошибках, известных как
гейзенбаги.

Отладка
— обнаружение причины ошибки.

Инструменты
отладки

Отладчик
представляет из себя программный
инструмент, позволяющий программисту
наблюдать за выполнением исследуемой
программы, останавливать и перезапускать
её, прогонять в замедленном темпе,
изменять значения в памяти и даже, в
некоторых случаях, возвращать назад по
времени.

Также
полезными инструментами в руках
программиста могут оказаться:

  • Профилировщики.
    Они позволят определить сколько времени
    выполняется тот или иной участок кода,
    а анализ покрытия позволит выявить
    неисполняемые участки кода.

  • API
    логгеры позволяют программисту отследить
    взаимодействие программы и Windows API при
    помощи записи сообщений Windows в лог.

  • Дизассемблеры
    позволят программисту посмотреть
    ассемблерный код исполняемого файла

  • Сниферы
    помогут программисту проследить сетевой
    трафик генерируемой программой

  • Сниферы
    аппаратных интерфейсов позволят увидеть
    данные которыми обменивается система
    и устройство.

  • Логи
    системы.

Использование
языков программирования высокого
уровня, таких как Java, обычно упрощает
отладку, поскольку содержат такие
средства как обработка исключений,
сильно облегчающие поиск источника
проблемы. В некоторых низкоуровневых
языках, таких как ассемблер, ошибки
могут приводить к незаметным проблемам
— например, повреждениям памяти или
утечкам памяти, и бывает довольно трудно
определить что стало первоначальной
причиной ошибки. В этих случаях, могут
потребоваться изощрённые приёмы и
средства отладки.

Инструменты,
снижающие потребность в отладке

Другое
направление — сделать, чтобы отладка
нужна была как можно реже. Для этого
применяются:

  • Контрактное
    программирование — чтобы программист
    подтверждал другим путём, что ему на
    выходе нужно именно такое поведение
    программы. В языках, в которых контрактного
    программирования нет, используется
    самопроверка программы в ключевых
    точках.

  • Модульное
    тестирование — проверка поведения
    программы по частям.

  • Статический
    анализ кода — проверка кода на стандартные
    ошибки «по недосмотру».

  • Высокая
    культура программирования, в частности,
    паттерны проектирования, соглашения
    об именовании и прозрачное поведение
    отдельных блоков кода — чтобы объявить
    себе и другим, каким образом должна
    вести себя та или иная функция.

  • Широкое
    использование проверенных внешних
    библиотек.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #

    05.06.2015525.32 Кб244.docx

  • #
  • #
  • #
  • #

    05.06.2015321.73 Кб125.docx

  • #
  • #
  • #
  • #

Отладка программы — один их самых сложных этапов разработки программного обеспечения, требующий глубокого знания:

специфики управления используемыми техническими средствами,

операционной системы,

среды и языка программирования,

реализуемых процессов,

природы и специфики различных ошибок,

методик отладки и соответствующих программных средств. 

Отладка — это процесс локализации и исправления ошибок, обнаруженных при тестировании программного обеспечения. Локализацией называют процесс определения оператора программы, выполнение которого вызвало нарушение нормального вычислительного процесса. Доя исправления ошибки необходимо определить ее причину, т. е. определить оператор или фрагмент, содержащие ошибку. Причины ошибок могут быть как очевидны, так и очень глубоко скрыты.

Вцелом сложность отладки обусловлена следующими причинами:

требует от программиста глубоких знаний специфики управления используемыми техническими средствами, операционной системы, среды и языка программирования, реализуемых процессов, природы и специфики различных ошибок, методик отладки и соответствующих программных средств;

психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;

возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;

отсутствуют четко сформулированные методики отладки.

Всоответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):


    синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы; ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

    ошибки выполнения — ошибки, обнаруженные операционной системой, аппаратными средствами или пользователем при выполнении программы.

Синтаксические ошибки. Синтаксические ошибки относят к группе самых простых, так как синтаксис языка, как правило, строго формализован, и ошибки сопровождаются развернутым комментарием с указанием ее местоположения. Определение причин таких ошибок, как правило, труда не составляет, и даже при нечетком знании правил языка за несколько прогонов удается удалить все ошибки данного типа.

Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, имеющий очень простой и четко определенный синтаксис, хорошо проверяемый при компиляции программы, ко вторым — Си со всеми его модификациями. Чего стоит хотя бы возможность выполнения присваивания в условном операторе в Си, например:

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */ 

Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

обнаруженными при разрешении внешних ссылок. Например, предусмотрено обращение к подпрограмме другого модуля, а при объединении модулей данная подпрограмма не найдена или не стыкуются списки параметров. В большинстве случаев ошибки такого рода также удается быстро локализовать и устранить.

    Ошибки выполнения. К самой непредсказуемой группе относятся ошибки выполнения. Прежде всего они могут иметь разную природу, и соответственно по-разному проявляться. Часть ошибок обнаруживается и документируется операционной системой. Выделяют четыре способа проявления таких ошибок:

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т. п.;

«зависание» компьютера, как простое, когда удается завершить программу без перезагрузки операционной системы, так и «тяжелое», когда для продолжения работы необходима перезагрузка;

несовпадение полученных результатов с ожидаемыми.

Примечание. Отметим, что, если ошибки этапа выполнения обнаруживает пользователь, то в двух первых случаях, получив соответствующее сообщение, пользователь в зависимости от своего характера, степени необходимости и опыта работы за компьютером, либо попробует понять, что произошло, ища свою вину, либо обратится за помощью, либо постарается никогда больше не иметь дела с этим продуктом. При «зависании» компьютера пользователь может даже не сразу понять, что происходит что-то не то, хотя его печальный опыт и заставляет волноваться каждый раз, когда компьютер не выдает быстрой реакции на введенную команду, что также целесообразно иметь в виду. Также опасны могут быть ситуации, при которых пользователь получает неправильные результаты и использует их в своей работе.

Причины ошибок выполнения очень разнообразны, а потому и локализация может оказаться крайне сложной. Все возможные причины ошибок можно разделить на следующие группы:

неверное определение исходных данных,

логические ошибки,

накопление погрешностей результатов вычислений (рис. 10.2).

Н е в е р н о е о п р е д е л е н и е и с х о д н ы х д а н н ы х происходит, если возникают любые ошибки при выполнении операций ввода-вывода: ошибки передачи, ошибки преобразования, ошибки перезаписи и ошибки данных. Причем использование специальных технических средств и программирование с защитой от ошибок (см.§ 2.7) позволяет обнаружить и предотвратить только часть этих ошибок, о чем безусловно не следует забывать.

Л о г и ч е с к и е о ш и б к и имеют разную природу. Так они могут следовать из ошибок, допущенных при проектировании, например, при выборе методов, разработке алгоритмов или определении структуры классов, а могут быть непосредственно внесены при кодировании модуля.

Кпоследней группе относят:

ошибки некорректного использования переменных, например, неудачный выбор типов данных, использование переменных до их инициализации, использование индексов, выходящих за границы определения массивов, нарушения соответствия типов данных при использовании явного или неявного переопределения типа данных, расположенных в памяти при использовании нетипизированных переменных, открытых массивов, объединений, динамической памяти, адресной арифметики и т. п.;

ошибки вычислений, например, некорректные вычисления над неарифметическими переменными, некорректное использование целочисленной арифметики, некорректное преобразование типов данных в процессе вычислений, ошибки, связанные с незнанием приоритетов выполнения операций для арифметических и логических выражений, и т. п.;

ошибки межмодульного интерфейса, например, игнорирование системных соглашений, нарушение типов и последовательности при передачи параметров, несоблюдение единства единиц измерения формальных и фактических параметров, нарушение области действия локальных и глобальных переменных;

другие ошибки кодирования, например, неправильная реализация логики программы при кодировании, игнорирование особенностей или ограничений конкретного языка программирования.

На к о п л е н и е п о г р е ш н о с т е й результатов числовых вычислений возникает, например, при некорректном отбрасывании дробных цифр чисел, некорректном использовании приближенных методов вычислений, игнорировании ограничения разрядной сетки представления вещественных чисел в ЭВМ и т. п.

Все указанные выше причины возникновения ошибок следует иметь в виду в процессе отладки. Кроме того, сложность отладки увеличивается также вследствие влияния следующих факторов:

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску – так называемые стохастические ошибки;

возможности устранения внешних проявлений ошибок в исследуемой ситуации при внесении некоторых изменений в программу, например, при включении в программу диагностических фрагментов может аннулироваться или измениться внешнее проявление ошибок;

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

Отладка программы в любом случае предполагает обдумывание и логическое осмысление всей имеющейся информации об ошибке. Большинство ошибок можно обнаружить по косвенным признакам посредством тщательного анализа текстов программ и результатов тестирования без получения дополнительной информации. При этом используют различные методы:

ручного тестирования;

индукции;

дедукции;

обратного прослеживания.

Метод ручного тестирования. Это — самый простой и естественный способ данной группы. При обнаружении ошибки необходимо выполнить тестируемую программу вручную, используя тестовый набор, при работе с которым была обнаружена ошибка.

Метод очень эффективен, но не применим для больших программ, программ со сложными вычислениями и в тех случаях, когда ошибка связана с неверным представлением программиста о выполнении некоторых операций.

Данный метод часто используют как составную часть других методов отладки.

Метод индукции. Метод основан на тщательном анализе симптомов ошибки, которые могут проявляться как неверные результаты вычислений или как сообщение об ошибке. Если компьютер просто «зависает», то фрагмент проявления ошибки вычисляют, исходя из последних полученных результатов и действий пользователя. Полученную таким образом информацию организуют и тщательно изучают, просматривая соответствующий фрагмент программы. В результате этих действий выдвигают гипотезы об ошибках, каждую из которых проверяют. Если гипотеза верна, то детализируют информацию об ошибке, иначе — выдвигают другую гипотезу. Последовательность выполнения отладки методом индукции показана на рис. 10.3 в виде схемы алгоритма.

Самый ответственный этап — выявление симптомов ошибки. Организуя данные об ошибке, целесообразно записать все, что известно о ее проявлениях, причем фиксируют, как ситуации, в которых фрагмент с ошибкой выполняется нормально, так и ситуации, в которых ошибка проявляется. Если в результате изучения данных никаких гипотез не появляется, то необходима дополнительная информация об ошибке. Дополнительную информацию можно получить, например, в результате выполнения схожих тестов.

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

Метод дедукции. По методу дедукции вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину (рис. 10.4).

Метод обратного прослеживания. Для небольших программ эффективно применение метода обратного прослеживания. Начинают с точки вывода неправильного результата. Для этой точки строится гипотеза о значениях основных переменных, которые могли бы привести к получению имеющегося результата. Далее, исходя из этой гипотезы, делают предложения о значениях переменных в предыдущей точке. Процесс продолжают, пока не обнаружат причину ошибки.

A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and correcting bugs is termed «debugging» and often uses formal techniques or tools to pinpoint bugs. Since the 1950s, some computer systems have been designed to deter, detect or auto-correct various computer bugs during operations.

Bugs in software can arise from mistakes and errors made in interpreting and extracting users’ requirements, planning a program’s design, writing its source code, and from interaction with humans, hardware and programs, such as operating systems or libraries. A program with many, or serious, bugs is often described as buggy. Bugs can trigger errors that may have ripple effects. The effects of bugs may be subtle, such as unintended text formatting, through to more obvious effects such as causing a program to crash, freezing the computer, or causing damage to hardware. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges.[1]

Some software bugs have been linked to disasters. Bugs in code that controlled the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s. In 1996, the European Space Agency’s US$1 billion prototype Ariane 5 rocket was destroyed less than a minute after launch due to a bug in the on-board guidance computer program.[2] In 1994, an RAF Chinook helicopter crashed, killing 29; this was initially blamed on pilot error, but was later thought to have been caused by a software bug in the engine-control computer.[3] Buggy software caused the early 21st century British Post Office scandal, the most widespread miscarriage of justice in British legal history.[4]

In 2002, a study commissioned by the US Department of Commerce’s National Institute of Standards and Technology concluded that «software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product».[5]

History[edit]

The Middle English word bugge is the basis for the terms «bugbear» and «bugaboo» as terms used for a monster.[6]

The term «bug» to describe defects has been a part of engineering jargon since the 1870s[7] and predates electronics and computers; it may have originally been used in hardware engineering to describe mechanical malfunctions. For instance, Thomas Edison wrote in a letter to an associate in 1878:[8]

… difficulties arise—this thing gives out and [it is] then that «Bugs»—as such little faults and difficulties are called—show themselves[9]

Baffle Ball, the first mechanical pinball game, was advertised as being «free of bugs» in 1931.[10] Problems with military gear during World War II were referred to as bugs (or glitches).[11] In a book published in 1942, Louise Dickinson Rich, speaking of a powered ice cutting machine, said, «Ice sawing was suspended until the creator could be brought in to take the bugs out of his darling.»[12]

Isaac Asimov used the term «bug» to relate to issues with a robot in his short story «Catch That Rabbit», published in 1944.

A page from the Harvard Mark II electromechanical computer’s log, featuring a dead moth that was removed from the device.

The term «bug» was used in an account by computer pioneer Grace Hopper, who publicized the cause of a malfunction in an early electromechanical computer.[13] A typical version of the story is:

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.[14]

Hopper was not present when the bug was found, but it became one of her favorite stories.[15] The date in the log book was September 9, 1947.[16][17][18] The operators who found it, including William «Bill» Burke, later of the Naval Weapons Laboratory, Dahlgren, Virginia,[19] were familiar with the engineering term and amusedly kept the insect with the notation «First actual case of bug being found.» This log book, complete with attached moth, is part of the collection of the Smithsonian National Museum of American History.[17]

The related term «debug» also appears to predate its usage in computing: the Oxford English Dictionarys etymology of the word contains an attestation from 1945, in the context of aircraft engines.[20]

The concept that software might contain errors dates back to Ada Lovelace’s 1843 notes on the analytical engine, in which she speaks of the possibility of program «cards» for Charles Babbage’s analytical engine being erroneous:

… an analysing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders.

«Bugs in the System» report[edit]

The Open Technology Institute, run by the group, New America,[21] released a report «Bugs in the System» in August 2016 stating that U.S. policymakers should make reforms to help researchers identify and address software bugs. The report «highlights the need for reform in the field of software vulnerability discovery and disclosure.»[22] One of the report’s authors said that Congress has not done enough to address cyber software vulnerability, even though Congress has passed a number of bills to combat the larger issue of cyber security.[22]

Government researchers, companies, and cyber security experts are the people who typically discover software flaws. The report calls for reforming computer crime and copyright laws.[22]

The Computer Fraud and Abuse Act, the Digital Millennium Copyright Act and the Electronic Communications Privacy Act criminalize and create civil penalties for actions that security researchers routinely engage in while conducting legitimate security research, the report said.[22]

Terminology[edit]

While the use of the term «bug» to describe software errors is common, many have suggested that it should be abandoned. One argument is that the word «bug» is divorced from a sense that a human being caused the problem, and instead implies that the defect arose on its own, leading to a push to abandon the term «bug» in favor of terms such as «defect», with limited success.[23] Since the 1970s Gary Kildall somewhat humorously suggested to use the term «blunder».[24][25]

In software engineering, mistake metamorphism (from Greek meta = «change», morph = «form») refers to the evolution of a defect in the final stage of software deployment. Transformation of a «mistake» committed by an analyst in the early stages of the software development lifecycle, which leads to a «defect» in the final stage of the cycle has been called ‘mistake metamorphism’.[26]

Different stages of a «mistake» in the entire cycle may be described as «mistakes», «anomalies», «faults», «failures», «errors», «exceptions», «crashes», «glitches», «bugs», «defects», «incidents», or «side effects».[26]

Prevention[edit]

The software industry has put much effort into reducing bug counts.[27][28] These include:

Typographical errors[edit]

Bugs usually appear when the programmer makes a logic error. Various innovations in programming style and defensive programming are designed to make these bugs less likely, or easier to spot. Some typos, especially of symbols or logical/mathematical operators, allow the program to operate incorrectly, while others such as a missing symbol or misspelled name may prevent the program from operating. Compiled languages can reveal some typos when the source code is compiled.

Development methodologies[edit]

Several schemes assist managing programmer activity so that fewer bugs are produced. Software engineering (which addresses software design issues as well) applies many techniques to prevent defects. For example, formal program specifications state the exact behavior of programs so that design bugs may be eliminated. Unfortunately, formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.

Unit testing involves writing a test for every function (unit) that a program is to perform.

In test-driven development unit tests are written before the code and the code is not considered complete until all tests complete successfully.

Agile software development involves frequent software releases with relatively small changes. Defects are revealed by user feedback.

Open source development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus’s law says that popular open-source software has more chance of having few or no bugs than other software, because «given enough eyeballs, all bugs are shallow».[29] This assertion has been disputed, however: computer security specialist Elias Levy wrote that «it is easy to hide vulnerabilities in complex, little understood and undocumented source code,» because, «even if people are reviewing the code, that doesn’t mean they’re qualified to do so.»[30] An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian.

Programming language support[edit]

Programming languages include features to help prevent bugs, such as static type systems, restricted namespaces and modular programming. For example, when a programmer writes (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", although this may be syntactically correct, the code fails a type check. Compiled languages catch this without having to run the program. Interpreted languages catch such errors at runtime. Some languages deliberately exclude features that easily lead to bugs, at the expense of slower performance: the general principle being that, it is almost always better to write simpler, slower code than inscrutable code that runs slightly faster, especially considering that maintenance cost is substantial. For example, the Java programming language does not support pointer arithmetic; implementations of some languages such as Pascal and scripting languages often have runtime bounds checking of arrays, at least in a debugging build.

Code analysis[edit]

Tools for code analysis help developers by inspecting the program text beyond the compiler’s capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes often when writing software.

Instrumentation[edit]

Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE"), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.

Testing[edit]

Software testers are people whose primary task is to find bugs, or write code to support testing. On some projects, more resources may be spent on testing than in developing the program.

Measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed.[citation needed]

Debugging[edit]

The typical bug history (GNU Classpath project data). A new bug submitted by the user is unconfirmed. Once it has been reproduced by a developer, it is a confirmed bug. The confirmed bugs are later fixed. Bugs belonging to other categories (unreproducible, will not be fixed, etc.) are usually in the minority

Finding and fixing bugs, or debugging, is a major part of computer programming. Maurice Wilkes, an early computing pioneer, described his realization in the late 1940s that much of the rest of his life would be spent finding mistakes in his own programs.[31]

Usually, the most difficult part of debugging is finding the bug. Once it is found, correcting it is usually relatively easy. Programs known as debuggers help programmers locate bugs by executing code line by line, watching variable values, and other features to observe program behavior. Without a debugger, code may be added so that messages or values may be written to a console or to a window or log file to trace program execution or show values.

However, even with the aid of a debugger, locating bugs is something of an art. It is not uncommon for a bug in one section of a program to cause failures in a completely different section,[citation needed] thus making it especially difficult to track (for example, an error in a graphics rendering routine causing a file I/O routine to fail), in an apparently unrelated part of the system.

Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmer. Such logic errors require a section of the program to be overhauled or rewritten. As a part of code review, stepping through the code and imagining or transcribing the execution process may often find errors without ever reproducing the bug as such.

More typically, the first step in locating a bug is to reproduce it reliably. Once the bug is reproducible, the programmer may use a debugger or other tool while reproducing the error to find the point at which the program went astray.

Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of the Therac-25 radiation machine deaths was a bug (specifically, a race condition) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called heisenbugs (humorously named after the Heisenberg uncertainty principle).

Since the 1990s, particularly following the Ariane 5 Flight 501 disaster, interest in automated aids to debugging rose, such as static code analysis by abstract interpretation.[32]

Some classes of bugs have nothing to do with the code. Faulty documentation or hardware may lead to problems in system use, even though the code matches the documentation. In some cases, changes to the code eliminate the problem even though the code then no longer matches the documentation. Embedded systems frequently work around hardware bugs, since to make a new version of a ROM is much cheaper than remanufacturing the hardware, especially if they are commodity items.

Benchmark of bugs[edit]

To facilitate reproducible research on testing and debugging, researchers use curated benchmarks of bugs:

  • the Siemens benchmark
  • ManyBugs[33] is a benchmark of 185 C bugs in nine open-source programs.
  • Defects4J[34] is a benchmark of 341 Java bugs from 5 open-source projects. It contains the corresponding patches, which cover a variety of patch type.

Bug management[edit]

Bug management includes the process of documenting, categorizing, assigning, reproducing, correcting and releasing the corrected code. Proposed changes to software – bugs as well as enhancement requests and even entire releases – are commonly tracked and managed using bug tracking systems or issue tracking systems.[35] The items added may be called defects, tickets, issues, or, following the agile development paradigm, stories and epics. Categories may be objective, subjective or a combination, such as version number, area of the software, severity and priority, as well as what type of issue it is, such as a feature request or a bug.

A bug triage reviews bugs and decides whether and when to fix them. The decision is based on the bug’s priority, and factors such as project schedules. The triage is not meant to investigate the cause of bugs, but rather the cost of fixing them. The triage happens regularly, and goes through bugs opened or reopened since the previous meeting. The attendees of the triage process typically are the project manager, development manager, test manager, build manager, and technical experts.[36][37]

Severity[edit]

Severity is the intensity of the impact the bug has on system operation.[38] This impact may be data loss, financial, loss of goodwill and wasted effort. Severity levels are not standardized. Impacts differ across industry. A crash in a video game has a totally different impact than a crash in a web browser, or real time monitoring system. For example, bug severity levels might be «crash or hang», «no workaround» (meaning there is no way the customer can accomplish a given task), «has workaround» (meaning the user can still accomplish the task), «visual defect» (for example, a missing image or displaced button or form element), or «documentation error». Some software publishers use more qualified severities such as «critical», «high», «low», «blocker» or «trivial».[39] The severity of a bug may be a separate category to its priority for fixing, and the two may be quantified and managed separately.

Priority[edit]

Priority controls where a bug falls on the list of planned changes. The priority is decided by each software producer. Priorities may be numerical, such as 1 through 5, or named, such as «critical», «high», «low», or «deferred». These rating scales may be similar or even identical to severity ratings, but are evaluated as a combination of the bug’s severity with its estimated effort to fix; a bug with low severity but easy to fix may get a higher priority than a bug with moderate severity that requires excessive effort to fix. Priority ratings may be aligned with product releases, such as «critical» priority indicating all the bugs that must be fixed before the next software release.

A bug severe enough to delay or halt the release of the product is called a «show stopper»[40] or «showstopper bug».[41] It is named so because it «stops the show» – causes unacceptable product failure.[41]

Software releases[edit]

It is common practice to release software with known, low-priority bugs. Bugs of sufficiently high priority may warrant a special release of part of the code containing only modules with those fixes. These are known as patches. Most releases include a mixture of behavior changes and multiple bug fixes. Releases that emphasize bug fixes are known as maintenance releases, to differentiate it from major releases that emphasize feature additions or changes.

Reasons that a software publisher opts not to patch or even fix a particular bug include:

  • A deadline must be met and resources are insufficient to fix all bugs by the deadline.[42]
  • The bug is already fixed in an upcoming release, and it is not of high priority.
  • The changes required to fix the bug are too costly or affect too many other components, requiring a major testing activity.
  • It may be suspected, or known, that some users are relying on the existing buggy behavior; a proposed fix may introduce a breaking change.
  • The problem is in an area that will be obsolete with an upcoming release; fixing it is unnecessary.
  • «It’s not a bug, it’s a feature».[43] A misunderstanding has arisen between expected and perceived behavior or undocumented feature.

Types[edit]

In software development projects, a mistake or error may be introduced at any stage. Bugs arise from oversight or misunderstanding by a software team during specification, design, coding, configuration, data entry or documentation. For example, a relatively simple program to alphabetize a list of words, the design might fail to consider what should happen when a word contains a hyphen. Or when converting an abstract design into code, the coder might inadvertently create an off-by-one error which can be a «<» where «<=» was intended, and fail to sort the last word in a list.

Another category of bug is called a race condition that may occur when programs have multiple components executing at the same time. If the components interact in a different order than the developer intended, they could interfere with each other and stop the program from completing its tasks. These bugs may be difficult to detect or anticipate, since they may not occur during every execution of a program.

Conceptual errors are a developer’s misunderstanding of what the software must do. The resulting software may perform according to the developer’s understanding, but not what is really needed. Other types:

Arithmetic[edit]

In operations on numerical values, problems can arise that result in unexpected output, slowing of a process, or crashing.[44] These can be from a lack of awareness of the qualities of the data storage such as a loss of precision due to rounding, numerically unstable algorithms, arithmetic overflow and underflow, or from lack of awareness of how calculations are handled by different software coding languages such as division by zero which in some languages may throw an exception, and in others may return a special value such as NaN or infinity.

Control flow[edit]

Control flow bugs are those found in processes with valid logic, but that lead to unintended results, such as infinite loops and infinite recursion, incorrect comparisons for conditional statements such as using the incorrect comparison operator, and off-by-one errors (counting one too many or one too few iterations when looping).

Interfacing[edit]

  • Incorrect API usage.
  • Incorrect protocol implementation.
  • Incorrect hardware handling.
  • Incorrect assumptions of a particular platform.
  • Incompatible systems. A new API or communications protocol may seem to work when two systems use different versions, but errors may occur when a function or feature implemented in one version is changed or missing in another. In production systems which must run continually, shutting down the entire system for a major update may not be possible, such as in the telecommunication industry[45] or the internet.[46][47][48] In this case, smaller segments of a large system are upgraded individually, to minimize disruption to a large network. However, some sections could be overlooked and not upgraded, and cause compatibility errors which may be difficult to find and repair.
  • Incorrect code annotations.

Concurrency[edit]

  • Deadlock, where task A cannot continue until task B finishes, but at the same time, task B cannot continue until task A finishes.
  • Race condition, where the computer does not perform tasks in the order the programmer intended.
  • Concurrency errors in critical sections, mutual exclusions and other features of concurrent processing. Time-of-check-to-time-of-use (TOCTOU) is a form of unprotected critical section.

Resourcing[edit]

  • Null pointer dereference.
  • Using an uninitialized variable.
  • Using an otherwise valid instruction on the wrong data type (see packed decimal/binary-coded decimal).
  • Access violations.
  • Resource leaks, where a finite system resource (such as memory or file handles) become exhausted by repeated allocation without release.
  • Buffer overflow, in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or storage violation. These are frequently security bugs.
  • Excessive recursion which—though logically valid—causes stack overflow.
  • Use-after-free error, where a pointer is used after the system has freed the memory it references.
  • Double free error.

Syntax[edit]

  • Use of the wrong token, such as performing assignment instead of equality test. For example, in some languages x=5 will set the value of x to 5 while x==5 will check whether x is currently 5 or some other number. Interpreted languages allow such code to fail. Compiled languages can catch such errors before testing begins.

Teamwork[edit]

  • Unpropagated updates; e.g. programmer changes «myAdd» but forgets to change «mySubtract», which uses the same algorithm. These errors are mitigated by the Don’t Repeat Yourself philosophy.
  • Comments out of date or incorrect: many programmers assume the comments accurately describe the code.
  • Differences between documentation and product.

Implications[edit]

The amount and type of damage a software bug may cause naturally affects decision-making, processes and policy regarding software quality. In applications such as human spaceflight, aviation, nuclear power, health care, public transport or automotive safety, since software flaws have the potential to cause human injury or even death, such software will have far more scrutiny and quality control than, for example, an online shopping website. In applications such as banking, where software flaws have the potential to cause serious financial damage to a bank or its customers, quality control is also more important than, say, a photo editing application.

Other than the damage caused by bugs, some of their cost is due to the effort invested in fixing them. In 1978, Lientz et al. showed that the median of projects invest 17 percent of the development effort in bug fixing.[49] In research in 2020 on GitHub repositories showed the median is 20%.[50]

Residual bugs in delivered product[edit]

In 1994, NASA’s Goddard Space Flight Center managed to reduce their average number of errors from 4.5 per 1000 lines of code (SLOC) down to 1 per 1000 SLOC.[51]

Another study in 1990 reported that exceptionally good software development processes can achieve deployment failure rates as low as 0.1 per 1000 SLOC.[52] This figure is iterated in literature such as Code Complete by Steve McConnell,[53] and the NASA study on Flight Software Complexity.[54] Some projects even attained zero defects: the firmware in the IBM Wheelwriter typewriter which consists of 63,000 SLOC, and the Space Shuttle software with 500,000 SLOC.[52]

Well-known bugs[edit]

A number of software bugs have become well-known, usually due to their severity: examples include various space and military aircraft crashes. Possibly the most famous bug is the Year 2000 problem or Y2K bug, which caused many programs written long before the transition from 19xx to 20xx dates to malfunction, for example treating a date such as «25 Dec 04» as being in 1904, displaying «19100» instead of «2000», and so on. A huge effort at the end of the 20th century resolved the most severe problems, and there were no major consequences.

The 2012 stock trading disruption involved one such incompatibility between the old API and a new API.

In popular culture[edit]

  • In both the 1968 novel 2001: A Space Odyssey and the corresponding 1968 film 2001: A Space Odyssey, a spaceship’s onboard computer, HAL 9000, attempts to kill all its crew members. In the follow-up 1982 novel, 2010: Odyssey Two, and the accompanying 1984 film, 2010, it is revealed that this action was caused by the computer having been programmed with two conflicting objectives: to fully disclose all its information, and to keep the true purpose of the flight secret from the crew; this conflict caused HAL to become paranoid and eventually homicidal.
  • In the English version of the Nena 1983 song 99 Luftballons (99 Red Balloons) as a result of «bugs in the software», a release of a group of 99 red balloons are mistaken for an enemy nuclear missile launch, requiring an equivalent launch response, resulting in catastrophe.
  • In the 1999 American comedy Office Space, three employees attempt (unsuccessfully) to exploit their company’s preoccupation with the Y2K computer bug using a computer virus that sends rounded-off fractions of a penny to their bank account—a long-known technique described as salami slicing.
  • The 2004 novel The Bug, by Ellen Ullman, is about a programmer’s attempt to find an elusive bug in a database application.[55]
  • The 2008 Canadian film Control Alt Delete is about a computer programmer at the end of 1999 struggling to fix bugs at his company related to the year 2000 problem.

See also[edit]

  • Anti-pattern
  • Bug bounty program
  • Glitch removal
  • Hardware bug
  • ISO/IEC 9126, which classifies a bug as either a defect or a nonconformity
  • Orthogonal Defect Classification
  • Racetrack problem
  • RISKS Digest
  • Software defect indicator
  • Software regression
  • Software rot
  • Automatic bug fixing

References[edit]

  1. ^ Mittal, Varun; Aditya, Shivam (January 1, 2015). «Recent Developments in the Field of Bug Fixing». Procedia Computer Science. International Conference on Computer, Communication and Convergence (ICCC 2015). 48: 288–297. doi:10.1016/j.procs.2015.04.184. ISSN 1877-0509.
  2. ^ «Ariane 501 — Presentation of Inquiry Board report». www.esa.int. Retrieved January 29, 2022.
  3. ^ Prof. Simon Rogerson. «The Chinook Helicopter Disaster». Ccsr.cse.dmu.ac.uk. Archived from the original on July 17, 2012. Retrieved September 24, 2012.
  4. ^ «Post Office scandal ruined lives, inquiry hears». BBC News. February 14, 2022.
  5. ^ «Software bugs cost US economy dear». June 10, 2009. Archived from the original on June 10, 2009. Retrieved September 24, 2012.{{cite web}}: CS1 maint: unfit URL (link)
  6. ^ Computerworld staff (September 3, 2011). «Moth in the machine: Debugging the origins of ‘bug’«. Computerworld. Archived from the original on August 25, 2015.
  7. ^ «bug». Oxford English Dictionary (Online ed.). Oxford University Press. (Subscription or participating institution membership required.) 5a
  8. ^ «Did You Know? Edison Coined the Term «Bug»«. August 1, 2013. Retrieved July 19, 2019.
  9. ^ Edison to Puskas, 13 November 1878, Edison papers, Edison National Laboratory, U.S. National Park Service, West Orange, N.J., cited in Hughes, Thomas Parke (1989). American Genesis: A Century of Invention and Technological Enthusiasm, 1870-1970. Penguin Books. p. 75. ISBN 978-0-14-009741-2.
  10. ^ «Baffle Ball». Internet Pinball Database. (See image of advertisement in reference entry)
  11. ^ «Modern Aircraft Carriers are Result of 20 Years of Smart Experimentation». Life. June 29, 1942. p. 25. Archived from the original on June 4, 2013. Retrieved November 17, 2011.
  12. ^ Dickinson Rich, Louise (1942), We Took to the Woods, JB Lippincott Co, p. 93, LCCN 42024308, OCLC 405243, archived from the original on March 16, 2017.
  13. ^ FCAT NRT Test, Harcourt, March 18, 2008
  14. ^ «Danis, Sharron Ann: «Rear Admiral Grace Murray Hopper»«. ei.cs.vt.edu. February 16, 1997. Retrieved January 31, 2010.
  15. ^ James S. Huggins. «First Computer Bug». Jamesshuggins.com. Archived from the original on August 16, 2000. Retrieved September 24, 2012.
  16. ^ «Bug Archived March 23, 2017, at the Wayback Machine», The Jargon File, ver. 4.4.7. Retrieved June 3, 2010.
  17. ^ a b «Log Book With Computer Bug Archived March 23, 2017, at the Wayback Machine», National Museum of American History, Smithsonian Institution.
  18. ^ «The First «Computer Bug», Naval Historical Center. But note the Harvard Mark II computer was not complete until the summer of 1947.
  19. ^ IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000
  20. ^ Journal of the Royal Aeronautical Society. 49, 183/2, 1945 «It ranged … through the stage of type test and flight test and ‘debugging’ …»
  21. ^ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. «Bugs in the System» (PDF). Open Policy Institute. Archived (PDF) from the original on September 21, 2016. Retrieved August 22, 2016.
  22. ^ a b c d Rozens, Tracy (August 12, 2016). «Cyber reforms needed to strengthen software bug discovery and disclosure: New America report – Homeland Preparedness News». Retrieved August 23, 2016.
  23. ^ «News at SEI 1999 Archive». cmu.edu. Archived from the original on May 26, 2013.
  24. ^ Shustek, Len (August 2, 2016). «In His Own Words: Gary Kildall». Remarkable People. Computer History Museum. Archived from the original on December 17, 2016.
  25. ^ Kildall, Gary Arlen (August 2, 2016) [1993]. Kildall, Scott; Kildall, Kristin (eds.). «Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry» (Manuscript, part 1). Kildall Family: 14–15. Archived from the original on November 17, 2016. Retrieved November 17, 2016.
  26. ^ a b «Testing experience : te : the magazine for professional testers». Testing Experience. Germany: testingexperience: 42. March 2012. ISSN 1866-5705. (subscription required)
  27. ^ Huizinga, Dorota; Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 426. ISBN 978-0-470-04212-0. Archived from the original on April 25, 2012.
  28. ^ McDonald, Marc; Musson, Robert; Smith, Ross (2007). The Practical Guide to Defect Prevention. Microsoft Press. p. 480. ISBN 978-0-7356-2253-1.
  29. ^ «Release Early, Release Often» Archived May 14, 2011, at the Wayback Machine, Eric S. Raymond, The Cathedral and the Bazaar
  30. ^ «Wide Open Source» Archived September 29, 2007, at the Wayback Machine, Elias Levy, SecurityFocus, April 17, 2000
  31. ^ Maurice Wilkes Quotes
  32. ^ «PolySpace Technologies history». christele.faure.pagesperso-orange.fr. Retrieved August 1, 2019.
  33. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). «The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs». IEEE Transactions on Software Engineering. 41 (12): 1236–1256. doi:10.1109/TSE.2015.2454513. ISSN 0098-5589.
  34. ^ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). «Defects4J: a database of existing faults to enable controlled testing studies for Java programs». Proceedings of the 2014 International Symposium on Software Testing and Analysis — ISSTA 2014. pp. 437–440. CiteSeerX 10.1.1.646.3086. doi:10.1145/2610384.2628055. ISBN 9781450326452. S2CID 12796895.
  35. ^ Allen, Mitch (May–June 2002). «Bug Tracking Basics: A beginner’s guide to reporting and tracking defects». Software Testing & Quality Engineering Magazine. Vol. 4, no. 3. pp. 20–24. Retrieved December 19, 2017.
  36. ^ Rex Black (2002). Managing The Testing Process (2Nd Ed.). Wiley India Pvt. Limited. p. 139. ISBN 9788126503131. Retrieved June 19, 2021.
  37. ^ Chris Vander Mey (August 24, 2012). Shipping Greatness — Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon. O’Reilly Media. pp. 79–81. ISBN 9781449336608.
  38. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (October 1, 2020). «Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems». Information and Software Technology. 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  39. ^ «5.3. Anatomy of a Bug». bugzilla.org. Archived from the original on May 23, 2013.
  40. ^ Jones, Wilbur D. Jr., ed. (1989). «Show stopper». Glossary: defense acquisition acronyms and terms (4 ed.). Fort Belvoir, Virginia, USA: Department of Defense, Defense Systems Management College. p. 123. hdl:2027/mdp.39015061290758 – via Hathitrust.
  41. ^ a b Zachary, G. Pascal (1994). Show-stopper!: the breakneck race to create Windows NT and the next generation at Microsoft. New York: The Free Press. p. 158. ISBN 0029356717 – via archive.org.
  42. ^ «The Next Generation 1996 Lexicon A to Z: Slipstream Release». Next Generation. No. 15. March 1996. p. 41.
  43. ^ Carr, Nicholas (2018). «‘It’s Not a Bug, It’s a Feature.’ Trite—or Just Right?». wired.com.
  44. ^ Di Franco, Anthony; Guo, Hui; Cindy, Rubio-González. «A Comprehensive Study of Real-World Numerical Bug Characteristics» (PDF). Archived (PDF) from the original on October 9, 2022.
  45. ^ Kimbler, K. (1998). Feature Interactions in Telecommunications and Software Systems V. IOS Press. p. 8. ISBN 978-90-5199-431-5.
  46. ^ Syed, Mahbubur Rahman (July 1, 2001). Multimedia Networking: Technology, Management and Applications: Technology, Management and Applications. Idea Group Inc (IGI). p. 398. ISBN 978-1-59140-005-9.
  47. ^ Wu, Chwan-Hwa (John); Irwin, J. David (April 19, 2016). Introduction to Computer Networks and Cybersecurity. CRC Press. p. 500. ISBN 978-1-4665-7214-0.
  48. ^ RFC 1263: «TCP Extensions Considered Harmful» quote: «the time to distribute the new version of the protocol to all hosts can be quite long (forever in fact). … If there is the slightest incompatibly between old and new versions, chaos can result.»
  49. ^ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (1978). «Characteristics of Application Software Maintenance». Communications of the ACM. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091.
  50. ^ Amit, Idan; Feitelson, Dror G. (2020). «The Corrective Commit Probability Code Quality Metric». arXiv:2007.10912 [cs.SE].
  51. ^ An overview of the Software Engineering Laboratory (PDF) (Report). Maryland, USA: Goddard Space Flight Center, NASA. December 1, 1994. pp41–42 Figure 18; pp43–44 Figure 21. CR-189410; SEL-94-005. Archived (PDF) from the original on November 22, 2022. Retrieved November 22, 2022. (bibliography: An overview of the Software Engineering Laboratory)
  52. ^ a b Cobb, Richard H.; Mills, Harlan D. (1990). «Engineering software under statistical quality control». IEEE Software. 7 (6): 46. doi:10.1109/52.60601. ISSN 1937-4194. S2CID 538311 – via University of Tennessee – Harlan D. Mills Collection.
  53. ^ McConnell, Steven C. (1993). Code Complete. Redmond, Washington, USA: Microsoft Press. p. 611. ISBN 9781556154843 – via archive.org. (Cobb and Mills 1990)
  54. ^ Holzmann, Gerard (March 6, 2009). «Appendix D – Software Complexity» (PDF). In Dvorak, Daniel L. (ed.). NASA Study on Flight Software Complexity (Report). NASA. pdf frame 109/264. Appendix D p.2. Archived (PDF) from the original on March 8, 2022. Retrieved November 22, 2022. (under NASA Office of the Chief Engineer Technical Excellence Initiative)
  55. ^ Ullman, Ellen (2004). The Bug. Picador. ISBN 978-1-250-00249-5.

External links[edit]

  • «Common Weakness Enumeration» – an expert webpage focus on bugs, at NIST.gov
  • BUG type of Jim Gray – another Bug type
  • Picture of the «first computer bug» at the Wayback Machine (archived January 12, 2015)
  • «The First Computer Bug!» – an email from 1981 about Adm. Hopper’s bug
  • «Toward Understanding Compiler Bugs in GCC and LLVM». A 2016 study of bugs in compilers

A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and correcting bugs is termed «debugging» and often uses formal techniques or tools to pinpoint bugs. Since the 1950s, some computer systems have been designed to deter, detect or auto-correct various computer bugs during operations.

Bugs in software can arise from mistakes and errors made in interpreting and extracting users’ requirements, planning a program’s design, writing its source code, and from interaction with humans, hardware and programs, such as operating systems or libraries. A program with many, or serious, bugs is often described as buggy. Bugs can trigger errors that may have ripple effects. The effects of bugs may be subtle, such as unintended text formatting, through to more obvious effects such as causing a program to crash, freezing the computer, or causing damage to hardware. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges.[1]

Some software bugs have been linked to disasters. Bugs in code that controlled the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s. In 1996, the European Space Agency’s US$1 billion prototype Ariane 5 rocket was destroyed less than a minute after launch due to a bug in the on-board guidance computer program.[2] In 1994, an RAF Chinook helicopter crashed, killing 29; this was initially blamed on pilot error, but was later thought to have been caused by a software bug in the engine-control computer.[3] Buggy software caused the early 21st century British Post Office scandal, the most widespread miscarriage of justice in British legal history.[4]

In 2002, a study commissioned by the US Department of Commerce’s National Institute of Standards and Technology concluded that «software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product».[5]

History[edit]

The Middle English word bugge is the basis for the terms «bugbear» and «bugaboo» as terms used for a monster.[6]

The term «bug» to describe defects has been a part of engineering jargon since the 1870s[7] and predates electronics and computers; it may have originally been used in hardware engineering to describe mechanical malfunctions. For instance, Thomas Edison wrote in a letter to an associate in 1878:[8]

… difficulties arise—this thing gives out and [it is] then that «Bugs»—as such little faults and difficulties are called—show themselves[9]

Baffle Ball, the first mechanical pinball game, was advertised as being «free of bugs» in 1931.[10] Problems with military gear during World War II were referred to as bugs (or glitches).[11] In a book published in 1942, Louise Dickinson Rich, speaking of a powered ice cutting machine, said, «Ice sawing was suspended until the creator could be brought in to take the bugs out of his darling.»[12]

Isaac Asimov used the term «bug» to relate to issues with a robot in his short story «Catch That Rabbit», published in 1944.

A page from the Harvard Mark II electromechanical computer’s log, featuring a dead moth that was removed from the device.

The term «bug» was used in an account by computer pioneer Grace Hopper, who publicized the cause of a malfunction in an early electromechanical computer.[13] A typical version of the story is:

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug.[14]

Hopper was not present when the bug was found, but it became one of her favorite stories.[15] The date in the log book was September 9, 1947.[16][17][18] The operators who found it, including William «Bill» Burke, later of the Naval Weapons Laboratory, Dahlgren, Virginia,[19] were familiar with the engineering term and amusedly kept the insect with the notation «First actual case of bug being found.» This log book, complete with attached moth, is part of the collection of the Smithsonian National Museum of American History.[17]

The related term «debug» also appears to predate its usage in computing: the Oxford English Dictionarys etymology of the word contains an attestation from 1945, in the context of aircraft engines.[20]

The concept that software might contain errors dates back to Ada Lovelace’s 1843 notes on the analytical engine, in which she speaks of the possibility of program «cards» for Charles Babbage’s analytical engine being erroneous:

… an analysing process must equally have been performed in order to furnish the Analytical Engine with the necessary operative data; and that herein may also lie a possible source of error. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders.

«Bugs in the System» report[edit]

The Open Technology Institute, run by the group, New America,[21] released a report «Bugs in the System» in August 2016 stating that U.S. policymakers should make reforms to help researchers identify and address software bugs. The report «highlights the need for reform in the field of software vulnerability discovery and disclosure.»[22] One of the report’s authors said that Congress has not done enough to address cyber software vulnerability, even though Congress has passed a number of bills to combat the larger issue of cyber security.[22]

Government researchers, companies, and cyber security experts are the people who typically discover software flaws. The report calls for reforming computer crime and copyright laws.[22]

The Computer Fraud and Abuse Act, the Digital Millennium Copyright Act and the Electronic Communications Privacy Act criminalize and create civil penalties for actions that security researchers routinely engage in while conducting legitimate security research, the report said.[22]

Terminology[edit]

While the use of the term «bug» to describe software errors is common, many have suggested that it should be abandoned. One argument is that the word «bug» is divorced from a sense that a human being caused the problem, and instead implies that the defect arose on its own, leading to a push to abandon the term «bug» in favor of terms such as «defect», with limited success.[23] Since the 1970s Gary Kildall somewhat humorously suggested to use the term «blunder».[24][25]

In software engineering, mistake metamorphism (from Greek meta = «change», morph = «form») refers to the evolution of a defect in the final stage of software deployment. Transformation of a «mistake» committed by an analyst in the early stages of the software development lifecycle, which leads to a «defect» in the final stage of the cycle has been called ‘mistake metamorphism’.[26]

Different stages of a «mistake» in the entire cycle may be described as «mistakes», «anomalies», «faults», «failures», «errors», «exceptions», «crashes», «glitches», «bugs», «defects», «incidents», or «side effects».[26]

Prevention[edit]

The software industry has put much effort into reducing bug counts.[27][28] These include:

Typographical errors[edit]

Bugs usually appear when the programmer makes a logic error. Various innovations in programming style and defensive programming are designed to make these bugs less likely, or easier to spot. Some typos, especially of symbols or logical/mathematical operators, allow the program to operate incorrectly, while others such as a missing symbol or misspelled name may prevent the program from operating. Compiled languages can reveal some typos when the source code is compiled.

Development methodologies[edit]

Several schemes assist managing programmer activity so that fewer bugs are produced. Software engineering (which addresses software design issues as well) applies many techniques to prevent defects. For example, formal program specifications state the exact behavior of programs so that design bugs may be eliminated. Unfortunately, formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.

Unit testing involves writing a test for every function (unit) that a program is to perform.

In test-driven development unit tests are written before the code and the code is not considered complete until all tests complete successfully.

Agile software development involves frequent software releases with relatively small changes. Defects are revealed by user feedback.

Open source development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus’s law says that popular open-source software has more chance of having few or no bugs than other software, because «given enough eyeballs, all bugs are shallow».[29] This assertion has been disputed, however: computer security specialist Elias Levy wrote that «it is easy to hide vulnerabilities in complex, little understood and undocumented source code,» because, «even if people are reviewing the code, that doesn’t mean they’re qualified to do so.»[30] An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian.

Programming language support[edit]

Programming languages include features to help prevent bugs, such as static type systems, restricted namespaces and modular programming. For example, when a programmer writes (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", although this may be syntactically correct, the code fails a type check. Compiled languages catch this without having to run the program. Interpreted languages catch such errors at runtime. Some languages deliberately exclude features that easily lead to bugs, at the expense of slower performance: the general principle being that, it is almost always better to write simpler, slower code than inscrutable code that runs slightly faster, especially considering that maintenance cost is substantial. For example, the Java programming language does not support pointer arithmetic; implementations of some languages such as Pascal and scripting languages often have runtime bounds checking of arrays, at least in a debugging build.

Code analysis[edit]

Tools for code analysis help developers by inspecting the program text beyond the compiler’s capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes often when writing software.

Instrumentation[edit]

Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE"), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.

Testing[edit]

Software testers are people whose primary task is to find bugs, or write code to support testing. On some projects, more resources may be spent on testing than in developing the program.

Measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed.[citation needed]

Debugging[edit]

The typical bug history (GNU Classpath project data). A new bug submitted by the user is unconfirmed. Once it has been reproduced by a developer, it is a confirmed bug. The confirmed bugs are later fixed. Bugs belonging to other categories (unreproducible, will not be fixed, etc.) are usually in the minority

Finding and fixing bugs, or debugging, is a major part of computer programming. Maurice Wilkes, an early computing pioneer, described his realization in the late 1940s that much of the rest of his life would be spent finding mistakes in his own programs.[31]

Usually, the most difficult part of debugging is finding the bug. Once it is found, correcting it is usually relatively easy. Programs known as debuggers help programmers locate bugs by executing code line by line, watching variable values, and other features to observe program behavior. Without a debugger, code may be added so that messages or values may be written to a console or to a window or log file to trace program execution or show values.

However, even with the aid of a debugger, locating bugs is something of an art. It is not uncommon for a bug in one section of a program to cause failures in a completely different section,[citation needed] thus making it especially difficult to track (for example, an error in a graphics rendering routine causing a file I/O routine to fail), in an apparently unrelated part of the system.

Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmer. Such logic errors require a section of the program to be overhauled or rewritten. As a part of code review, stepping through the code and imagining or transcribing the execution process may often find errors without ever reproducing the bug as such.

More typically, the first step in locating a bug is to reproduce it reliably. Once the bug is reproducible, the programmer may use a debugger or other tool while reproducing the error to find the point at which the program went astray.

Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of the Therac-25 radiation machine deaths was a bug (specifically, a race condition) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called heisenbugs (humorously named after the Heisenberg uncertainty principle).

Since the 1990s, particularly following the Ariane 5 Flight 501 disaster, interest in automated aids to debugging rose, such as static code analysis by abstract interpretation.[32]

Some classes of bugs have nothing to do with the code. Faulty documentation or hardware may lead to problems in system use, even though the code matches the documentation. In some cases, changes to the code eliminate the problem even though the code then no longer matches the documentation. Embedded systems frequently work around hardware bugs, since to make a new version of a ROM is much cheaper than remanufacturing the hardware, especially if they are commodity items.

Benchmark of bugs[edit]

To facilitate reproducible research on testing and debugging, researchers use curated benchmarks of bugs:

  • the Siemens benchmark
  • ManyBugs[33] is a benchmark of 185 C bugs in nine open-source programs.
  • Defects4J[34] is a benchmark of 341 Java bugs from 5 open-source projects. It contains the corresponding patches, which cover a variety of patch type.

Bug management[edit]

Bug management includes the process of documenting, categorizing, assigning, reproducing, correcting and releasing the corrected code. Proposed changes to software – bugs as well as enhancement requests and even entire releases – are commonly tracked and managed using bug tracking systems or issue tracking systems.[35] The items added may be called defects, tickets, issues, or, following the agile development paradigm, stories and epics. Categories may be objective, subjective or a combination, such as version number, area of the software, severity and priority, as well as what type of issue it is, such as a feature request or a bug.

A bug triage reviews bugs and decides whether and when to fix them. The decision is based on the bug’s priority, and factors such as project schedules. The triage is not meant to investigate the cause of bugs, but rather the cost of fixing them. The triage happens regularly, and goes through bugs opened or reopened since the previous meeting. The attendees of the triage process typically are the project manager, development manager, test manager, build manager, and technical experts.[36][37]

Severity[edit]

Severity is the intensity of the impact the bug has on system operation.[38] This impact may be data loss, financial, loss of goodwill and wasted effort. Severity levels are not standardized. Impacts differ across industry. A crash in a video game has a totally different impact than a crash in a web browser, or real time monitoring system. For example, bug severity levels might be «crash or hang», «no workaround» (meaning there is no way the customer can accomplish a given task), «has workaround» (meaning the user can still accomplish the task), «visual defect» (for example, a missing image or displaced button or form element), or «documentation error». Some software publishers use more qualified severities such as «critical», «high», «low», «blocker» or «trivial».[39] The severity of a bug may be a separate category to its priority for fixing, and the two may be quantified and managed separately.

Priority[edit]

Priority controls where a bug falls on the list of planned changes. The priority is decided by each software producer. Priorities may be numerical, such as 1 through 5, or named, such as «critical», «high», «low», or «deferred». These rating scales may be similar or even identical to severity ratings, but are evaluated as a combination of the bug’s severity with its estimated effort to fix; a bug with low severity but easy to fix may get a higher priority than a bug with moderate severity that requires excessive effort to fix. Priority ratings may be aligned with product releases, such as «critical» priority indicating all the bugs that must be fixed before the next software release.

A bug severe enough to delay or halt the release of the product is called a «show stopper»[40] or «showstopper bug».[41] It is named so because it «stops the show» – causes unacceptable product failure.[41]

Software releases[edit]

It is common practice to release software with known, low-priority bugs. Bugs of sufficiently high priority may warrant a special release of part of the code containing only modules with those fixes. These are known as patches. Most releases include a mixture of behavior changes and multiple bug fixes. Releases that emphasize bug fixes are known as maintenance releases, to differentiate it from major releases that emphasize feature additions or changes.

Reasons that a software publisher opts not to patch or even fix a particular bug include:

  • A deadline must be met and resources are insufficient to fix all bugs by the deadline.[42]
  • The bug is already fixed in an upcoming release, and it is not of high priority.
  • The changes required to fix the bug are too costly or affect too many other components, requiring a major testing activity.
  • It may be suspected, or known, that some users are relying on the existing buggy behavior; a proposed fix may introduce a breaking change.
  • The problem is in an area that will be obsolete with an upcoming release; fixing it is unnecessary.
  • «It’s not a bug, it’s a feature».[43] A misunderstanding has arisen between expected and perceived behavior or undocumented feature.

Types[edit]

In software development projects, a mistake or error may be introduced at any stage. Bugs arise from oversight or misunderstanding by a software team during specification, design, coding, configuration, data entry or documentation. For example, a relatively simple program to alphabetize a list of words, the design might fail to consider what should happen when a word contains a hyphen. Or when converting an abstract design into code, the coder might inadvertently create an off-by-one error which can be a «<» where «<=» was intended, and fail to sort the last word in a list.

Another category of bug is called a race condition that may occur when programs have multiple components executing at the same time. If the components interact in a different order than the developer intended, they could interfere with each other and stop the program from completing its tasks. These bugs may be difficult to detect or anticipate, since they may not occur during every execution of a program.

Conceptual errors are a developer’s misunderstanding of what the software must do. The resulting software may perform according to the developer’s understanding, but not what is really needed. Other types:

Arithmetic[edit]

In operations on numerical values, problems can arise that result in unexpected output, slowing of a process, or crashing.[44] These can be from a lack of awareness of the qualities of the data storage such as a loss of precision due to rounding, numerically unstable algorithms, arithmetic overflow and underflow, or from lack of awareness of how calculations are handled by different software coding languages such as division by zero which in some languages may throw an exception, and in others may return a special value such as NaN or infinity.

Control flow[edit]

Control flow bugs are those found in processes with valid logic, but that lead to unintended results, such as infinite loops and infinite recursion, incorrect comparisons for conditional statements such as using the incorrect comparison operator, and off-by-one errors (counting one too many or one too few iterations when looping).

Interfacing[edit]

  • Incorrect API usage.
  • Incorrect protocol implementation.
  • Incorrect hardware handling.
  • Incorrect assumptions of a particular platform.
  • Incompatible systems. A new API or communications protocol may seem to work when two systems use different versions, but errors may occur when a function or feature implemented in one version is changed or missing in another. In production systems which must run continually, shutting down the entire system for a major update may not be possible, such as in the telecommunication industry[45] or the internet.[46][47][48] In this case, smaller segments of a large system are upgraded individually, to minimize disruption to a large network. However, some sections could be overlooked and not upgraded, and cause compatibility errors which may be difficult to find and repair.
  • Incorrect code annotations.

Concurrency[edit]

  • Deadlock, where task A cannot continue until task B finishes, but at the same time, task B cannot continue until task A finishes.
  • Race condition, where the computer does not perform tasks in the order the programmer intended.
  • Concurrency errors in critical sections, mutual exclusions and other features of concurrent processing. Time-of-check-to-time-of-use (TOCTOU) is a form of unprotected critical section.

Resourcing[edit]

  • Null pointer dereference.
  • Using an uninitialized variable.
  • Using an otherwise valid instruction on the wrong data type (see packed decimal/binary-coded decimal).
  • Access violations.
  • Resource leaks, where a finite system resource (such as memory or file handles) become exhausted by repeated allocation without release.
  • Buffer overflow, in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or storage violation. These are frequently security bugs.
  • Excessive recursion which—though logically valid—causes stack overflow.
  • Use-after-free error, where a pointer is used after the system has freed the memory it references.
  • Double free error.

Syntax[edit]

  • Use of the wrong token, such as performing assignment instead of equality test. For example, in some languages x=5 will set the value of x to 5 while x==5 will check whether x is currently 5 or some other number. Interpreted languages allow such code to fail. Compiled languages can catch such errors before testing begins.

Teamwork[edit]

  • Unpropagated updates; e.g. programmer changes «myAdd» but forgets to change «mySubtract», which uses the same algorithm. These errors are mitigated by the Don’t Repeat Yourself philosophy.
  • Comments out of date or incorrect: many programmers assume the comments accurately describe the code.
  • Differences between documentation and product.

Implications[edit]

The amount and type of damage a software bug may cause naturally affects decision-making, processes and policy regarding software quality. In applications such as human spaceflight, aviation, nuclear power, health care, public transport or automotive safety, since software flaws have the potential to cause human injury or even death, such software will have far more scrutiny and quality control than, for example, an online shopping website. In applications such as banking, where software flaws have the potential to cause serious financial damage to a bank or its customers, quality control is also more important than, say, a photo editing application.

Other than the damage caused by bugs, some of their cost is due to the effort invested in fixing them. In 1978, Lientz et al. showed that the median of projects invest 17 percent of the development effort in bug fixing.[49] In research in 2020 on GitHub repositories showed the median is 20%.[50]

Residual bugs in delivered product[edit]

In 1994, NASA’s Goddard Space Flight Center managed to reduce their average number of errors from 4.5 per 1000 lines of code (SLOC) down to 1 per 1000 SLOC.[51]

Another study in 1990 reported that exceptionally good software development processes can achieve deployment failure rates as low as 0.1 per 1000 SLOC.[52] This figure is iterated in literature such as Code Complete by Steve McConnell,[53] and the NASA study on Flight Software Complexity.[54] Some projects even attained zero defects: the firmware in the IBM Wheelwriter typewriter which consists of 63,000 SLOC, and the Space Shuttle software with 500,000 SLOC.[52]

Well-known bugs[edit]

A number of software bugs have become well-known, usually due to their severity: examples include various space and military aircraft crashes. Possibly the most famous bug is the Year 2000 problem or Y2K bug, which caused many programs written long before the transition from 19xx to 20xx dates to malfunction, for example treating a date such as «25 Dec 04» as being in 1904, displaying «19100» instead of «2000», and so on. A huge effort at the end of the 20th century resolved the most severe problems, and there were no major consequences.

The 2012 stock trading disruption involved one such incompatibility between the old API and a new API.

In popular culture[edit]

  • In both the 1968 novel 2001: A Space Odyssey and the corresponding 1968 film 2001: A Space Odyssey, a spaceship’s onboard computer, HAL 9000, attempts to kill all its crew members. In the follow-up 1982 novel, 2010: Odyssey Two, and the accompanying 1984 film, 2010, it is revealed that this action was caused by the computer having been programmed with two conflicting objectives: to fully disclose all its information, and to keep the true purpose of the flight secret from the crew; this conflict caused HAL to become paranoid and eventually homicidal.
  • In the English version of the Nena 1983 song 99 Luftballons (99 Red Balloons) as a result of «bugs in the software», a release of a group of 99 red balloons are mistaken for an enemy nuclear missile launch, requiring an equivalent launch response, resulting in catastrophe.
  • In the 1999 American comedy Office Space, three employees attempt (unsuccessfully) to exploit their company’s preoccupation with the Y2K computer bug using a computer virus that sends rounded-off fractions of a penny to their bank account—a long-known technique described as salami slicing.
  • The 2004 novel The Bug, by Ellen Ullman, is about a programmer’s attempt to find an elusive bug in a database application.[55]
  • The 2008 Canadian film Control Alt Delete is about a computer programmer at the end of 1999 struggling to fix bugs at his company related to the year 2000 problem.

See also[edit]

  • Anti-pattern
  • Bug bounty program
  • Glitch removal
  • Hardware bug
  • ISO/IEC 9126, which classifies a bug as either a defect or a nonconformity
  • Orthogonal Defect Classification
  • Racetrack problem
  • RISKS Digest
  • Software defect indicator
  • Software regression
  • Software rot
  • Automatic bug fixing

References[edit]

  1. ^ Mittal, Varun; Aditya, Shivam (January 1, 2015). «Recent Developments in the Field of Bug Fixing». Procedia Computer Science. International Conference on Computer, Communication and Convergence (ICCC 2015). 48: 288–297. doi:10.1016/j.procs.2015.04.184. ISSN 1877-0509.
  2. ^ «Ariane 501 — Presentation of Inquiry Board report». www.esa.int. Retrieved January 29, 2022.
  3. ^ Prof. Simon Rogerson. «The Chinook Helicopter Disaster». Ccsr.cse.dmu.ac.uk. Archived from the original on July 17, 2012. Retrieved September 24, 2012.
  4. ^ «Post Office scandal ruined lives, inquiry hears». BBC News. February 14, 2022.
  5. ^ «Software bugs cost US economy dear». June 10, 2009. Archived from the original on June 10, 2009. Retrieved September 24, 2012.{{cite web}}: CS1 maint: unfit URL (link)
  6. ^ Computerworld staff (September 3, 2011). «Moth in the machine: Debugging the origins of ‘bug’«. Computerworld. Archived from the original on August 25, 2015.
  7. ^ «bug». Oxford English Dictionary (Online ed.). Oxford University Press. (Subscription or participating institution membership required.) 5a
  8. ^ «Did You Know? Edison Coined the Term «Bug»«. August 1, 2013. Retrieved July 19, 2019.
  9. ^ Edison to Puskas, 13 November 1878, Edison papers, Edison National Laboratory, U.S. National Park Service, West Orange, N.J., cited in Hughes, Thomas Parke (1989). American Genesis: A Century of Invention and Technological Enthusiasm, 1870-1970. Penguin Books. p. 75. ISBN 978-0-14-009741-2.
  10. ^ «Baffle Ball». Internet Pinball Database. (See image of advertisement in reference entry)
  11. ^ «Modern Aircraft Carriers are Result of 20 Years of Smart Experimentation». Life. June 29, 1942. p. 25. Archived from the original on June 4, 2013. Retrieved November 17, 2011.
  12. ^ Dickinson Rich, Louise (1942), We Took to the Woods, JB Lippincott Co, p. 93, LCCN 42024308, OCLC 405243, archived from the original on March 16, 2017.
  13. ^ FCAT NRT Test, Harcourt, March 18, 2008
  14. ^ «Danis, Sharron Ann: «Rear Admiral Grace Murray Hopper»«. ei.cs.vt.edu. February 16, 1997. Retrieved January 31, 2010.
  15. ^ James S. Huggins. «First Computer Bug». Jamesshuggins.com. Archived from the original on August 16, 2000. Retrieved September 24, 2012.
  16. ^ «Bug Archived March 23, 2017, at the Wayback Machine», The Jargon File, ver. 4.4.7. Retrieved June 3, 2010.
  17. ^ a b «Log Book With Computer Bug Archived March 23, 2017, at the Wayback Machine», National Museum of American History, Smithsonian Institution.
  18. ^ «The First «Computer Bug», Naval Historical Center. But note the Harvard Mark II computer was not complete until the summer of 1947.
  19. ^ IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000
  20. ^ Journal of the Royal Aeronautical Society. 49, 183/2, 1945 «It ranged … through the stage of type test and flight test and ‘debugging’ …»
  21. ^ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. «Bugs in the System» (PDF). Open Policy Institute. Archived (PDF) from the original on September 21, 2016. Retrieved August 22, 2016.
  22. ^ a b c d Rozens, Tracy (August 12, 2016). «Cyber reforms needed to strengthen software bug discovery and disclosure: New America report – Homeland Preparedness News». Retrieved August 23, 2016.
  23. ^ «News at SEI 1999 Archive». cmu.edu. Archived from the original on May 26, 2013.
  24. ^ Shustek, Len (August 2, 2016). «In His Own Words: Gary Kildall». Remarkable People. Computer History Museum. Archived from the original on December 17, 2016.
  25. ^ Kildall, Gary Arlen (August 2, 2016) [1993]. Kildall, Scott; Kildall, Kristin (eds.). «Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry» (Manuscript, part 1). Kildall Family: 14–15. Archived from the original on November 17, 2016. Retrieved November 17, 2016.
  26. ^ a b «Testing experience : te : the magazine for professional testers». Testing Experience. Germany: testingexperience: 42. March 2012. ISSN 1866-5705. (subscription required)
  27. ^ Huizinga, Dorota; Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 426. ISBN 978-0-470-04212-0. Archived from the original on April 25, 2012.
  28. ^ McDonald, Marc; Musson, Robert; Smith, Ross (2007). The Practical Guide to Defect Prevention. Microsoft Press. p. 480. ISBN 978-0-7356-2253-1.
  29. ^ «Release Early, Release Often» Archived May 14, 2011, at the Wayback Machine, Eric S. Raymond, The Cathedral and the Bazaar
  30. ^ «Wide Open Source» Archived September 29, 2007, at the Wayback Machine, Elias Levy, SecurityFocus, April 17, 2000
  31. ^ Maurice Wilkes Quotes
  32. ^ «PolySpace Technologies history». christele.faure.pagesperso-orange.fr. Retrieved August 1, 2019.
  33. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). «The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs». IEEE Transactions on Software Engineering. 41 (12): 1236–1256. doi:10.1109/TSE.2015.2454513. ISSN 0098-5589.
  34. ^ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). «Defects4J: a database of existing faults to enable controlled testing studies for Java programs». Proceedings of the 2014 International Symposium on Software Testing and Analysis — ISSTA 2014. pp. 437–440. CiteSeerX 10.1.1.646.3086. doi:10.1145/2610384.2628055. ISBN 9781450326452. S2CID 12796895.
  35. ^ Allen, Mitch (May–June 2002). «Bug Tracking Basics: A beginner’s guide to reporting and tracking defects». Software Testing & Quality Engineering Magazine. Vol. 4, no. 3. pp. 20–24. Retrieved December 19, 2017.
  36. ^ Rex Black (2002). Managing The Testing Process (2Nd Ed.). Wiley India Pvt. Limited. p. 139. ISBN 9788126503131. Retrieved June 19, 2021.
  37. ^ Chris Vander Mey (August 24, 2012). Shipping Greatness — Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon. O’Reilly Media. pp. 79–81. ISBN 9781449336608.
  38. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (October 1, 2020). «Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems». Information and Software Technology. 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  39. ^ «5.3. Anatomy of a Bug». bugzilla.org. Archived from the original on May 23, 2013.
  40. ^ Jones, Wilbur D. Jr., ed. (1989). «Show stopper». Glossary: defense acquisition acronyms and terms (4 ed.). Fort Belvoir, Virginia, USA: Department of Defense, Defense Systems Management College. p. 123. hdl:2027/mdp.39015061290758 – via Hathitrust.
  41. ^ a b Zachary, G. Pascal (1994). Show-stopper!: the breakneck race to create Windows NT and the next generation at Microsoft. New York: The Free Press. p. 158. ISBN 0029356717 – via archive.org.
  42. ^ «The Next Generation 1996 Lexicon A to Z: Slipstream Release». Next Generation. No. 15. March 1996. p. 41.
  43. ^ Carr, Nicholas (2018). «‘It’s Not a Bug, It’s a Feature.’ Trite—or Just Right?». wired.com.
  44. ^ Di Franco, Anthony; Guo, Hui; Cindy, Rubio-González. «A Comprehensive Study of Real-World Numerical Bug Characteristics» (PDF). Archived (PDF) from the original on October 9, 2022.
  45. ^ Kimbler, K. (1998). Feature Interactions in Telecommunications and Software Systems V. IOS Press. p. 8. ISBN 978-90-5199-431-5.
  46. ^ Syed, Mahbubur Rahman (July 1, 2001). Multimedia Networking: Technology, Management and Applications: Technology, Management and Applications. Idea Group Inc (IGI). p. 398. ISBN 978-1-59140-005-9.
  47. ^ Wu, Chwan-Hwa (John); Irwin, J. David (April 19, 2016). Introduction to Computer Networks and Cybersecurity. CRC Press. p. 500. ISBN 978-1-4665-7214-0.
  48. ^ RFC 1263: «TCP Extensions Considered Harmful» quote: «the time to distribute the new version of the protocol to all hosts can be quite long (forever in fact). … If there is the slightest incompatibly between old and new versions, chaos can result.»
  49. ^ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (1978). «Characteristics of Application Software Maintenance». Communications of the ACM. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091.
  50. ^ Amit, Idan; Feitelson, Dror G. (2020). «The Corrective Commit Probability Code Quality Metric». arXiv:2007.10912 [cs.SE].
  51. ^ An overview of the Software Engineering Laboratory (PDF) (Report). Maryland, USA: Goddard Space Flight Center, NASA. December 1, 1994. pp41–42 Figure 18; pp43–44 Figure 21. CR-189410; SEL-94-005. Archived (PDF) from the original on November 22, 2022. Retrieved November 22, 2022. (bibliography: An overview of the Software Engineering Laboratory)
  52. ^ a b Cobb, Richard H.; Mills, Harlan D. (1990). «Engineering software under statistical quality control». IEEE Software. 7 (6): 46. doi:10.1109/52.60601. ISSN 1937-4194. S2CID 538311 – via University of Tennessee – Harlan D. Mills Collection.
  53. ^ McConnell, Steven C. (1993). Code Complete. Redmond, Washington, USA: Microsoft Press. p. 611. ISBN 9781556154843 – via archive.org. (Cobb and Mills 1990)
  54. ^ Holzmann, Gerard (March 6, 2009). «Appendix D – Software Complexity» (PDF). In Dvorak, Daniel L. (ed.). NASA Study on Flight Software Complexity (Report). NASA. pdf frame 109/264. Appendix D p.2. Archived (PDF) from the original on March 8, 2022. Retrieved November 22, 2022. (under NASA Office of the Chief Engineer Technical Excellence Initiative)
  55. ^ Ullman, Ellen (2004). The Bug. Picador. ISBN 978-1-250-00249-5.

External links[edit]

  • «Common Weakness Enumeration» – an expert webpage focus on bugs, at NIST.gov
  • BUG type of Jim Gray – another Bug type
  • Picture of the «first computer bug» at the Wayback Machine (archived January 12, 2015)
  • «The First Computer Bug!» – an email from 1981 about Adm. Hopper’s bug
  • «Toward Understanding Compiler Bugs in GCC and LLVM». A 2016 study of bugs in compilers

Библиографическое описание:


Пивоваров, Д. О. Отладка и тестирование программного обеспечения / Д. О. Пивоваров. — Текст : непосредственный // Молодой ученый. — 2022. — № 25 (420). — С. 14-15. — URL: https://moluch.ru/archive/420/93470/ (дата обращения: 29.01.2023).




В статье описываются способы отладки и тестирования программного обеспечения.



Ключевые слова:



программное обеспечение, тестирование, функциональное тестирование, тип тестирования.

Отладка — это процесс поиска ошибок, т. е. ошибок в программном обеспечении или приложении, и их исправления. Любое программное обеспечение или продукт, который разрабатывается, проходит через различные этапы — тестирование, устранение неполадок, обслуживание в другой среде. Эти программные продукты содержат некоторые ошибки. Эти ошибки должны быть устранены из программного обеспечения. Отладка — это не что иное, как процесс, который многие тестировщики программного обеспечения использовали для поиска и устранения этих ошибок. Отладка — это поиск ошибок, их анализ и исправление. Этот процесс происходит, когда программное обеспечение дает сбой из-за некоторых ошибок или программное обеспечение выполняет нежелательные действия. Отладка выглядит просто, но это сложная задача, поскольку необходимо исправлять все ошибки на каждом этапе отладки [2].

Процесс отладки состоит из нескольких этапов:

– определение ошибки;

– определение местонахождения ошибки;

– анализ ошибки;

– автоматизация тестирования;

– покрытие ущерба.

Выявление ошибок на ранней стадии может сэкономить много времени. Если допускается ошибка при выявлении ошибки, это приведет к большим потерям времени. Определение правильной ошибки — это импорт, чтобы сэкономить время и избежать ошибок на стороне пользователя.

После выявления ошибки необходимо определить точное местоположение в коде, где происходит ошибка. Определение точного местоположения, которое приводит к ошибке, может помочь решить проблему быстрее.

На следующем этапе отладки нужно использовать соответствующий подход для анализа ошибки. Это поможет понять проблему. Этот этап очень важен, так как решение одной ошибки может привести к другой ошибке.

После того, как выявленная ошибка была проанализирована, необходимо сосредоточиться на других ошибках программного обеспечения. Этот процесс включает в себя автоматизацию тестирования, когда требуется написать тестовые примеры через тестовую среду.

На последнем этапе необходимо выполнить модульное тестирование всего кода, в котором вносятся изменения. Если не все тестовые примеры проходят тестирование, следует решить тестовый пример, который не прошел тест.

Ниже приведен список преимуществ отладки:

– экономия времени;

– создание отчетов об ошибках;

– простая интерпретация.

Для выявления и исправления ошибок использовались различные инструменты, отладочные средства — это программное обеспечение, которое используется для тестирования и отладки других программ. На рынке доступно множество инструментов отладки с открытым исходным кодом.

Существуют различные стратегии отладки:

– стратегия обучения;

– опыт;

– форвардный анализ;

– обратный анализ.

Перед обнаружением ошибки в программном обеспечении или продукте очень важно изучить его очень тщательно. Потому что без каких-либо знаний сложно найти ошибки. В этом заключается стратегия обучения.

Предыдущий опыт может помочь найти похожие типы ошибок, а также решение для устранения ошибок.

Прямой анализ программ включает в себя отслеживание программ вперед с использованием операторов печати или точек останова в разных точках. Это больше касается места, где получены неправильные результаты.

Обратный анализ программы включает в себя отслеживание программы назад от места, где происходят ошибки, чтобы идентифицировать область неисправного кода.

Тестирование — немаловажная часть разработки ПО, так как от него зависит, будут ли возникать ошибки в работе программы. Поэтому необходимо рассмотреть доступные варианты средств тестирования и выбрать подходящие.

Типы тестирования, зависящие от объекта тестирования:

– модульное/unit-тестирование — проверка корректной работы отдельных модулей;

– интеграционное тестирование — проверка взаимодействия между несколькими модулями;

– системное — проверка работы программного обеспечения целиком;

– приемное — оценка соответствия требованиям, указанным в техническом задании.

Все эти типы необходимы и используются в тестировании ПМ ОО.

В зависимости от цели тестирование делится на два типа: функциональное и нефункциональное. Функциональное тестирование направлено на проверку реализуемости функциональных требований. Такие тесты могут проводиться на всех уровнях тестирования. Преимуществом этого типа тестирования является имитация фактического пользования программой.

Нефункциональное тестирование — это тип тестирования программного обеспечения для проверки нефункциональных аспектов программного приложения: производительность, удобство использования, надежность и т. д. Он предназначен для проверки готовности системы по нефункциональным параметрам, которые никогда не учитываются при функциональном тестировании. Нефункциональное тестирование включает в себя:

– тестирование производительности — работа ПОпод сильной нагрузкой;

– тестирование пользовательского интерфейса — удобство пользователя при взаимодействии с разными параметрами интерфейса;

– тестирование UX — правильность логики использования;

– тестирование защищенности — определение безопасности ПО;

– инсталляционное тестирование — поиск возникновения проблем при установке;

– тестирование совместимости — тестирование работы ПО в определенном окружении;

– тестирование надежности — работа программы при длительной нагрузке;

– тестирование локализации — оценка правильности версии.

В зависимости от доступа к коду программы при тестировании различают:

– тестирование белого ящика;

– тестирование черного ящика;

– тестирование серого ящика.

Главная цель тестирования белого ящика — проверка кода, тестирование внутренней структуры и дизайна. Эта стратегия предполагает поиск и улучшение таких случаев как:

– нерабочие и неоптимизированные участки кода;

– безопасность;

– ввод данных;

– условные процессы;

– неправильная работа объектов;

– некорректное отображение информации.

Основным подходом в этой стратегии является анализ кода программы.

Во время тестирования черного ящика тестировщик не знает, что за программу он тестирует. Как правило, этот метод используется для функционального тестирования по техническому заданию.

Стратегия серого ящика — это комбинация подходов белого и черного ящиков. Суть этого подхода — найти все проблемы функционирования и ошибки в коде.

Литература:

  1. Гленфорд Майерс. Тестирование программного обеспечения. Базовый курс / Майерс Гленфорд, Баджетт Том, Сандлер Кори. — 3-е изд., 2022. — 298 c. — Текст: непосредственный.
  2. Отладка (debugging): что это. — Текст: электронный // Skillfactory: [сайт]. — URL: https://blog.skillfactory.ru/glossary/otladka-debugging/ (дата обращения: 22.06.2022).

Основные термины (генерируются автоматически): программное обеспечение, ошибка, тестирование, тип тестирования, функциональное тестирование, черный ящик, белый ящик, нефункциональное тестирование, серый ящик, техническое задание.

  1. Программирование и отладка.

Отла́дка
— этап разработки компьютерной программы,
на котором обнаруживают, локализуют и
устраняют ошибки. Чтобы понять, где
возникла ошибка, приходится :

  • узнавать
    текущие значения переменных;

  • выяснять,
    по какому пути выполнялась программа.

Существуют
две взаимодополняющие технологии
отладки.

  • Использование
    отладчиков — программ, которые включают
    в себя пользовательский интерфейс для
    пошагового выполнения программы:
    оператор за оператором, функция за
    функцией, с остановками на некоторых
    строках исходного кода или при достижении
    определённого условия.

  • Вывод
    текущего состояния программы с помощью
    расположенных в критических точках
    программы операторов вывода — на экран,
    принтер, громкоговоритель или в файл.
    Вывод отладочных сведений в файл
    называется журналированием.

Место
отладки в цикле разработки программы

Типичный
цикл разработки, за время жизни программы
многократно повторяющийся, выглядит
примерно так:

Программирование
— внесение в программу новой
функциональности, исправление ошибок
в имеющейся.

Тестирование
(ручное или автоматизированное;
программистом, тестером или пользователем;
«дымовое», в режиме чёрного ящика или
модульное…) — обнаружение факта ошибки.

Воспроизведение
ошибки — выяснение условий, при которых
ошибка случается. Это может оказаться
непростой задачей при программировании
параллельных процессов и при некоторых
необычных ошибках, известных как
гейзенбаги.

Отладка
— обнаружение причины ошибки.

Инструменты
отладки

Отладчик
представляет из себя программный
инструмент, позволяющий программисту
наблюдать за выполнением исследуемой
программы, останавливать и перезапускать
её, прогонять в замедленном темпе,
изменять значения в памяти и даже, в
некоторых случаях, возвращать назад по
времени.

Также
полезными инструментами в руках
программиста могут оказаться:

  • Профилировщики.
    Они позволят определить сколько времени
    выполняется тот или иной участок кода,
    а анализ покрытия позволит выявить
    неисполняемые участки кода.

  • API
    логгеры позволяют программисту отследить
    взаимодействие программы и Windows API при
    помощи записи сообщений Windows в лог.

  • Дизассемблеры
    позволят программисту посмотреть
    ассемблерный код исполняемого файла

  • Сниферы
    помогут программисту проследить сетевой
    трафик генерируемой программой

  • Сниферы
    аппаратных интерфейсов позволят увидеть
    данные которыми обменивается система
    и устройство.

  • Логи
    системы.

Использование
языков программирования высокого
уровня, таких как Java, обычно упрощает
отладку, поскольку содержат такие
средства как обработка исключений,
сильно облегчающие поиск источника
проблемы. В некоторых низкоуровневых
языках, таких как ассемблер, ошибки
могут приводить к незаметным проблемам
— например, повреждениям памяти или
утечкам памяти, и бывает довольно трудно
определить что стало первоначальной
причиной ошибки. В этих случаях, могут
потребоваться изощрённые приёмы и
средства отладки.

Инструменты,
снижающие потребность в отладке

Другое
направление — сделать, чтобы отладка
нужна была как можно реже. Для этого
применяются:

  • Контрактное
    программирование — чтобы программист
    подтверждал другим путём, что ему на
    выходе нужно именно такое поведение
    программы. В языках, в которых контрактного
    программирования нет, используется
    самопроверка программы в ключевых
    точках.

  • Модульное
    тестирование — проверка поведения
    программы по частям.

  • Статический
    анализ кода — проверка кода на стандартные
    ошибки «по недосмотру».

  • Высокая
    культура программирования, в частности,
    паттерны проектирования, соглашения
    об именовании и прозрачное поведение
    отдельных блоков кода — чтобы объявить
    себе и другим, каким образом должна
    вести себя та или иная функция.

  • Широкое
    использование проверенных внешних
    библиотек.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #

    05.06.2015525.32 Кб254.docx

  • #
  • #
  • #
  • #

    05.06.2015321.73 Кб125.docx

  • #
  • #
  • #
  • #

Ошибка, недостаток, сбой или сбой в компьютерной программе или системе

A Ошибка программного обеспечения — это ошибка, недостаток или сбой в компьютерной программе или системе, из-за которой она дает неверный или неожиданный результат или ведет себя непредусмотренным образом. Процесс поиска и исправления ошибок называется «отладка » и часто использует формальные методы или инструменты для выявления ошибок, а с 1950-х годов некоторые компьютерные системы были разработаны также для обнаружения, обнаружения или автоматического исправления различных компьютерные ошибки во время работы.

Большинство ошибок возникает из-за ошибок и ошибок, допущенных либо в проекте программы, либо в ее исходном коде, либо в компонентах и ​​операционных системах, используемых такие программы. Некоторые из них вызваны тем, что компиляторы создают неправильный код. Программа, содержащая множество ошибок и / или ошибок, серьезно мешающих ее функциональности, называется ошибочной (дефектной). Ошибки могут вызывать ошибки, которые могут иметь волновой эффект. Ошибки могут иметь незначительные последствия или привести к аварийному завершению работы или зависанию компьютера. Другие ошибки квалифицируются как ошибки безопасности и могут, например, позволить злоумышленнику обойти контроль доступа, чтобы получить неавторизованные привилегии.

Некоторые программные ошибки связаны с катастрофами. Ошибки в коде, который управлял аппаратом Therac-25 лучевой терапии, были непосредственными причинами смерти пациентов в 1980-х годах. В 1996 г. ракета Европейского космического агентства стоимостью 1 миллиард долларов прототип Ariane 5 должна была быть уничтожена менее чем через минуту после запуска из-за ошибки в системе. бортовая компьютерная программа наведения. В июне 1994 года вертолет Royal Air Force Chinook врезался в Mull of Kintyre, в результате чего погибло 29 человек. Первоначально это было отклонено как ошибка пилота, но расследование Computer Weekly убедил запрос Палаты лордов в том, что это могло быть вызвано ошибкой программного обеспечения в компьютере управления двигателем.

самолета. В 2002 году исследование, проведенное по заказу Национальный институт стандартов и технологий Министерства торговли США пришел к выводу, что «программные ошибки или ошибки настолько распространены и настолько пагубны, что обходятся экономике США примерно в 59 миллиардов долларов. ежегодно, или около 0,6 процента валового внутреннего продукта ».

Содержание

  • 1 История
    • 1.1 Отчет« Ошибки в системе »
  • 2 Терминология
  • 3 Профилактика
    • 3.1 Типографические ошибки
    • 3.2 Методологии разработки
    • 3.3 Поддержка языков программирования
    • 3.4 Анализ кода
    • 3.5 Инструментарий
  • 4 Тестирование
  • 5 Отладка
  • 6 Тест ошибок
  • 7 Управление ошибками nt
    • 7.1 Уровень серьезности
    • 7.2 Приоритет
    • 7.3 Версии программного обеспечения
  • 8 Типы
    • 8.1 Арифметика
    • 8.2 Логика
    • 8.3 Синтаксис
    • 8.4 Ресурс
    • 8.5 Многопоточность
    • 8.6 Взаимодействие
    • 8.7 Работа в команде
  • 9 Последствия
  • 10 Хорошо известные ошибки
  • 11 В популярной культуре
  • 12 См. Также
  • 13 Ссылки
  • 14 Внешние ссылки

История

Среднеанглийское слово bugge лежит в основе терминов «bugbear » и «bugaboo » как терминов, используемых для обозначения монстра.

Термин «ошибка» для описания дефектов был частью инженерного жаргона с 1870-х годов и предшествовал электронным компьютерам и компьютерному программному обеспечению; возможно, изначально он использовался в аппаратной инженерии для описания механических неисправностей. Например, Томас Эдисон написал следующие слова в письме своему сотруднику в 1878 году:

Так было во всех моих изобретениях. Первым шагом является интуиция, и она приходит с порывом, затем возникают трудности — эта штука выдает, и [это] затем, что «жуки» — как называются такие маленькие ошибки и трудности — проявляют себя и месяцы интенсивного наблюдения, изучения прежде чем будет достигнут коммерческий успех или провал, необходимы и труд.

Baffle Ball, первая механическая игра в пинбол, в 1931 году рекламировалась как «свободная от ошибок». Проблемы с военным снаряжением во время Второй мировой войны упоминались как ошибки (или сбои ). В фильме 1940 года Flight Command дефект в части радиопеленгатора называется «ошибкой». В книге, опубликованной в 1942 году, Луиза Дикинсон Рич, говоря о механизированной машине для резки льда, сказала: «Распиловка льда была приостановлена ​​до тех пор, пока не будет привлечен создатель, чтобы устранить жучков. своего любимого ».

Исаак Азимов использовал термин« ошибка »для обозначения проблем с роботом в своем рассказе« Поймай этого кролика », опубликованном в 1944 году.

A страница из журнала электромеханического компьютера Harvard Mark II с изображением мертвой мотылька, удаленной с устройства.

Термин «ошибка» использовался в описании компьютерного первопроходца Грейс Хоппер, который объявил причину неисправности в одном из первых электромеханических компьютеров. Типичная версия этой истории такова:

В 1946 году, когда Хоппер освободили от действительной службы, она поступила на Гарвардский факультет в вычислительную лабораторию, где продолжила свою работу над Mark II и Марк III. Операторы связали ошибку в Mark II с мотыльком, застрявшим в реле, придумав термин «ошибка». Этот баг был аккуратно удален и записан в журнал. Исходя из первой ошибки, сегодня мы называем ошибки или сбои в программе ошибкой.

Хоппер не нашла ошибку, что она с готовностью признала. В бортовом журнале была дата 9 сентября 1947 года. Операторы, которые его нашли, включая Уильяма «Билла» Берка, позже работавшего в Лаборатории военно-морского оружия, Дальгрен, Вирджиния, были знакомы с техническим термином и забавно сохранил насекомое с пометкой «Первый реальный случай обнаружения ошибки». Хоппер любил пересказывать эту историю. Этот журнал, вместе с прикрепленным к нему мотыльком, является частью коллекции Смитсоновского Национального музея американской истории.

Связанный термин «отладка » также появился раньше, чем его использовали в вычислительной технике: Оксфордский словарь английского языка этимология этого слова содержит свидетельство 1945 года в контексте авиационных двигателей.

Идея, что программное обеспечение может содержать ошибки, восходит к 1843 году Ады Лавлейс. примечания к аналитической машине, в которых она говорит о возможности того, что программные «карты» для аналитической машины Чарльза Бэббиджа ошибочны:

… процесс анализа также должен быть выполнен, чтобы предоставить Аналитической машине необходимые оперативные данные; и в этом также может заключаться возможный источник ошибки. При условии, что реальный механизм работает без ошибок, карты могут давать ему неправильные команды.

Отчет «Ошибки в системе»

Институт открытых технологий, управляемый группой New America, выпустил доклад «Ошибки в системе» в августе 2016 года, в котором говорится, что политики США должны провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». Один из авторов отчета сказал, что Конгресс сделал недостаточно для устранения уязвимости киберпрограмм, хотя Конгресс принял ряд законопроектов по борьбе с более серьезной проблемой кибербезопасности.

Государственные исследователи, компании и кибербезопасность эксперты — это люди, которые обычно обнаруживают недостатки программного обеспечения. В докладе содержится призыв к реформированию законов о компьютерных преступлениях и авторских правах.

Закон о компьютерном мошенничестве и злоупотреблениях, Закон об авторском праве в цифровую эпоху и Закон о конфиденциальности электронных коммуникаций криминализируют и вводят гражданские санкции за действия, которые исследователи в области безопасности обычно совершают при проведении законных исследований в области безопасности. — говорится в отчете.

Терминология

Хотя использование термина «ошибка» для описания ошибок программного обеспечения является обычным явлением, многие предложили отказаться от него. Один из аргументов состоит в том, что слово «ошибка» не связано с тем, что проблема была вызвана человеком, и вместо этого подразумевает, что дефект возник сам по себе, что привело к необходимости отказаться от термина «ошибка» в пользу таких терминов, как «дефект» с ограниченным успехом. Начиная с 1970-х годов Гэри Килдалл несколько юмористически предложил использовать термин «грубая ошибка».

В разработке программного обеспечения термин «метаморфизм ошибки» (от греческого meta = «изменение», morph = «форма») означает эволюции дефекта на заключительном этапе развертывания программного обеспечения. Преобразование «ошибки», совершенной аналитиком на ранних этапах жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительной стадии цикла, было названо «метаморфизмом ошибки».

Различные этапы «ошибки» во всем цикле могут быть описаны как «ошибки», «аномалии», «сбои», «сбои», «ошибки», «исключения», «сбои», «сбои», «ошибки», » дефекты »,« инциденты »или« побочные эффекты ».

Предотвращение

Отрасль программного обеспечения приложила много усилий для сокращения количества ошибок. К ним относятся:

Типографические ошибки

Ошибки обычно появляются, когда программист делает логическую ошибку. Различные нововведения в стиле программирования и защитном программировании призваны сделать эти ошибки менее вероятными или более простыми для обнаружения. Некоторые опечатки, особенно в символах или логических / математических операторах, позволяют программе работать некорректно, в то время как другие, такие как отсутствие символа или неправильное имя, могут препятствовать работе программы. Скомпилированные языки могут обнаруживать некоторые опечатки при компиляции исходного кода.

Методологии разработки

Несколько схем помогают управлять деятельностью программиста, чтобы генерировать меньше ошибок. Программная инженерия (которая также решает проблемы проектирования программного обеспечения) применяет множество методов для предотвращения дефектов. Например, формальные спецификации программ устанавливают точное поведение программ, так что ошибки проектирования могут быть устранены. К сожалению, формальные спецификации нецелесообразны ни для чего, кроме самых коротких программ, из-за проблем комбинаторного взрыва и неопределенности.

Модульное тестирование включает в себя написание теста для каждой функции (модуля), которая программа для исполнения.

В разработке, управляемой тестированием, модульные тесты пишутся до кода, и код не считается завершенным, пока все тесты не завершатся успешно.

Гибкая разработка программного обеспечения включает частые выпуски программного обеспечения с относительно небольшими изменениями. Дефекты выявляются по отзывам пользователей.

Разработка с открытым исходным кодом позволяет любому исследовать исходный код. Школа мысли, популяризированная Эриком С. Реймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало ошибок или совсем не иметь ошибок, чем другое программное обеспечение., потому что «при достаточном внимании к нему все ошибки мелкие». Однако это утверждение оспаривается: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малоизученном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не означает, что они обладают достаточной квалификацией для этого «. Примером того, что это произошло случайно, была уязвимость 2008 OpenSSL в Debian.

Поддержка языков программирования

Языки программирования включают функции, помогающие предотвратить ошибки, такие как системы статических типов , ограниченное пространства имен и модульное программирование. Например, когда программист записывает (псевдокод) LET REAL_VALUE PI = "THREE AND A BIT", хотя это может быть синтаксически правильным, код не проходит проверку типа . Скомпилированные языки улавливают это без необходимости запускать программу. Интерпретируемые языки выявляют такие ошибки во время выполнения. Некоторые языки намеренно исключают функции, которые легко приводят к ошибкам, за счет более низкой производительности: общий принцип заключается в том, что почти всегда лучше писать более простой и медленный код, чем непостижимый код, который выполняется немного быстрее, особенно с учетом того, что обслуживание стоимость существенная. Например, язык программирования Java не поддерживает арифметику с указателем ; реализации некоторых языков, таких как Pascal и языков сценариев, часто имеют границы среды выполнения , проверяющие массивов, по крайней мере, в отладочной сборке.

Анализ кода

Инструменты для анализа кода помогают разработчикам, проверяя текст программы за пределами возможностей компилятора, чтобы выявить потенциальные проблемы. Хотя в целом проблема поиска всех программных ошибок в данной спецификации не разрешима (см. проблема остановки ), эти инструменты используют тот факт, что люди-программисты часто допускают определенные виды простых ошибок при написании программного обеспечения.

Инструментарий

Инструменты для мониторинга производительности программного обеспечения во время его работы, специально для поиска таких проблем, как узкие места, или для обеспечения уверенности в правильной работе, могут быть встроенными в код явным образом (возможно, так просто, как выражение PRINT «I AM HERE») или предоставлено в виде инструментов. Часто бывает неожиданностью обнаружить, где большую часть времени занимает фрагмент кода, и это удаление предположений может привести к переписыванию кода.

Тестирование

Тестировщики программного обеспечения — это люди, основной задачей которых является обнаружение ошибок или написание кода для поддержки тестирования. В некоторых проектах на тестирование может быть потрачено больше ресурсов, чем на разработку программы.

Измерения во время тестирования могут дать оценку количества оставшихся вероятных ошибок; это становится более надежным, чем дольше тестируется и разрабатывается продукт.

Отладка

Типичная история ошибок (GNU Classpath данные проекта). Новая ошибка, отправленная пользователем, не подтверждена. Как только он был воспроизведен разработчиком, это подтвержденная ошибка. Подтвержденные ошибки позже исправлены. Ошибки, относящиеся к другим категориям (невоспроизводимые, не будут исправлены и т. Д.), Обычно составляют меньшинство.

Поиск и исправление ошибок или отладка — основная часть компьютерного программирования. Морис Уилкс, один из первых пионеров вычислительной техники, описал свое осознание в конце 1940-х годов, что большую часть оставшейся жизни он потратит на поиск ошибок в собственных программах.

Обычно самые сложные Часть отладки — это поиск ошибки. Как только она обнаружена, исправить ее обычно относительно легко. Программы, известные как отладчики, помогают программистам обнаруживать ошибки, выполняя код построчно, наблюдая за значениями переменных и другими функциями для наблюдения за поведением программы. Без отладчика код может быть добавлен так, что сообщения или значения могут быть записаны в консоль или в окно или файл журнала для отслеживания выполнения программы или отображения значений.

Однако даже с помощью отладчика обнаружение ошибок — это своего рода искусство. Нередко ошибка в одном разделе программы вызывает сбои в совершенно другом разделе, что особенно затрудняет отслеживание (например, ошибка в подпрограмме рендеринга графики , вызывающая файл I / O ошибка подпрограммы) в явно несвязанной части системы.

Иногда ошибка не является изолированным недостатком, а представляет собой ошибку мышления или планирования со стороны программиста. Такие логические ошибки требуют капитального ремонта или перезаписи части программы. Как часть обзора кода, пошаговое выполнение кода и воображение или расшифровка процесса выполнения часто может обнаруживать ошибки без воспроизведения ошибки как таковой.

Как правило, первым шагом при обнаружении ошибки является ее надежное воспроизведение. Как только ошибка будет воспроизведена, программист может использовать отладчик или другой инструмент при воспроизведении ошибки, чтобы найти точку, в которой программа сбилась с пути.

Некоторые ошибки обнаруживаются при вводе данных, которые программисту может быть трудно воссоздать. Одной из причин смерти радиационной машины Therac-25 была ошибка (в частности, состояние гонки ), которая возникала только тогда, когда оператор машины очень быстро вводил план лечения; На то, чтобы это сделать, потребовались дни практики, поэтому ошибка не проявлялась ни при тестировании, ни при попытке производителя воспроизвести ее. Другие ошибки могут перестать возникать всякий раз, когда установка расширяется, чтобы помочь найти ошибку, например, запуск программы с отладчиком; они называются хайзенбагами (шутливо названы в честь принципа неопределенности Гейзенберга ).

С 1990-х годов, особенно после катастрофы Ariane 5 Flight 501, возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода посредством абстрактной интерпретации.

Некоторые классы ошибок не имеют ничего общего с кодом. Неправильная документация или оборудование могут привести к проблемам при использовании системы, даже если код соответствует документации. В некоторых случаях изменения в коде устраняют проблему, даже если код больше не соответствует документации. Встроенные системы часто обходят аппаратные ошибки, поскольку создание новой версии ПЗУ намного дешевле, чем восстановление оборудования, особенно если они товарные позиции.

Тест ошибок

Чтобы облегчить воспроизводимые исследования по тестированию и отладке, исследователи используют специально подобранные тесты тестов:

  • тест Siemens
  • ManyBugs — тест на 185 ошибок C. в девяти программах с открытым исходным кодом.
  • Defects4J — это тест на 341 ошибку Java из 5 проектов с открытым исходным кодом. Он содержит соответствующие исправления, которые охватывают множество типов исправлений.
  • BEARS — это эталонный тест на ошибки сборки с непрерывной интеграцией с упором на ошибки тестирования. Он был создан путем мониторинга сборок из проектов с открытым исходным кодом на Travis CI.

Управление ошибками

Управление ошибками включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении — ошибки, запросы на улучшения и даже целые выпуски — обычно отслеживаются и управляются с помощью систем отслеживания ошибок или систем отслеживания проблем. Добавленные элементы могут называться дефектами, заявками, проблемами или, следуя парадигме гибкой разработки, рассказами и эпосами. Категории могут быть объективными, субъективными или комбинированными, например номер версии, область программного обеспечения, серьезность и приоритет, а также тип проблемы, такой как запрос функции или ошибка.

Уровень серьезности

Уровень серьезности — это влияние ошибки на работу системы. Это может быть потеря данных, финансовая потеря, потеря репутации и потраченные впустую усилия. Уровни серьезности не стандартизированы. Воздействие различается в зависимости от отрасли. Сбой в видеоигре оказывает совершенно иное влияние, чем сбой в веб-браузере или системе мониторинга в реальном времени. Например, уровни серьезности ошибки могут быть такими: «сбой или зависание», «нет обходного пути» (что означает, что клиент не может выполнить данную задачу), «имеет обходной путь» (что означает, что пользователь все еще может выполнить задачу), «визуальный дефект »(например, отсутствующее изображение или смещенная кнопка или элемент формы) или« ошибка документации ». Некоторые издатели программного обеспечения используют более квалифицированные уровни серьезности, такие как «критический», «высокий», «низкий», «блокирующий» или «простой». Серьезность ошибки может быть отдельной категорией по отношению к ее приоритету для исправления, и эти две категории могут быть количественно определены и обработаны отдельно.

Priority

Приоритет определяет, где ошибка попадает в список запланированных изменений. Приоритет определяется каждым производителем программного обеспечения. Приоритеты могут быть числовыми, например от 1 до 5, или именованными, например, «критические», «высокие», «низкие» или «отложенные». Эти рейтинговые шкалы могут быть похожи или даже идентичны рейтингам серьезности, но оцениваются как комбинация серьезности ошибки с предполагаемыми усилиями по исправлению; ошибка с низким уровнем серьезности, которую легко исправить, может получить более высокий приоритет, чем ошибка средней степени серьезности, для исправления которой требуются чрезмерные усилия. Рейтинги приоритета могут быть согласованы с выпусками продукта, например «критический» приоритет, указывающий на все ошибки, которые необходимо исправить до следующего выпуска программного обеспечения.

Выпуски программного обеспечения

Распространенной практикой является выпуск программного обеспечения с известными низкоприоритетными ошибками. Большинство крупных программных проектов поддерживают два списка «известных ошибок» — тех, которые известны команде разработчиков программного обеспечения, и тех, о которых нужно сообщить пользователям. Второй список информирует пользователей об ошибках, которые не исправлены в конкретном выпуске, и могут быть предложены обходные пути. Релизы бывают разных видов. Ошибки с достаточно высоким приоритетом могут потребовать специального выпуска части кода, содержащей только модули с этими исправлениями. Они известны как патчи. Большинство выпусков включают в себя как изменение поведения, так и несколько исправлений ошибок. Релизы, в которых упор делается на исправления ошибок, называются отладочными. Релизы, в которых особое внимание уделяется добавлению / изменению функций, известны как основные релизы и часто имеют названия, позволяющие отличать новые функции от старых.

Причины, по которым издатель программного обеспечения предпочитает не исправлять или даже не исправлять конкретную ошибку, включают:

  • Срок должен быть соблюден, а ресурсов недостаточно для исправления всех ошибок к указанному сроку.
  • ошибка уже исправлена ​​в следующем выпуске, и она не имеет высокого приоритета.
  • Изменения, необходимые для исправления ошибки, слишком дороги или затрагивают слишком много других компонентов, что требует серьезного тестирования.
  • Можно подозревать или знать, что некоторые пользователи полагаются на существующее поведение с ошибками; предлагаемое исправление может ввести критическое изменение.
  • Проблема находится в области, которая будет устаревшей в следующем выпуске; исправлять это не нужно.
  • Это «не ошибка». Возникло недопонимание между ожидаемым и предполагаемым поведением, когда такое недопонимание не связано с путаницей, возникшей из-за недостатков дизайна или ошибочной документации.

Типы

В проектах разработки программного обеспечения — «ошибка» или «сбой» может быть введен на любом этапе. Ошибки возникают из-за упущений или недоразумений, допущенных командой разработчиков программного обеспечения во время спецификации, проектирования, кодирования, ввода данных или документации. Например, относительно простая программа для построения списка слов по алфавиту может не учитывать, что должно произойти, если слово содержит дефис. Или при преобразовании абстрактного дизайна в код кодировщик может непреднамеренно создать единичную ошибку и не отсортировать последнее слово в списке. Ошибки могут быть такими же простыми, как опечатка: имелось в виду «<» where a «>».

Другая категория ошибок называется состоянием состязания, которое может возникнуть, когда в программах одновременно выполняется несколько компонентов. Если компоненты взаимодействуют в порядке, отличном от предполагаемого разработчиком, они могут мешать друг другу и мешать программе выполнять свои задачи. Эти ошибки может быть трудно обнаружить или предвидеть, поскольку они могут не возникать при каждом выполнении программы.

Концептуальные ошибки — это неправильное понимание разработчиком того, что должно делать программное обеспечение. Полученное программное обеспечение может работать в соответствии с пониманием разработчика, но не в соответствии с тем, что действительно необходимо. Другие типы:

Арифметика

Логика

  • Бесконечные циклы и бесконечная рекурсия.
  • Поочередная ошибка, считая слишком много или слишком мало при зацикливании.

Синтаксис

  • Использование неправильного оператора, например выполнение присваивания вместо проверки равенства. Например, в некоторых языках x = 5 установит значение x равным 5, а x == 5 будет проверять, является ли x в настоящее время 5 или каким-либо другим числом. Интерпретируемые языки допускают сбой такого кода. Скомпилированные языки могут обнаруживать такие ошибки до начала тестирования.

Ресурс

  • Нулевой указатель разыменование.
  • Использование неинициализированной переменной.
  • Использование в противном случае действительной инструкции для неправильного тип данных (см. упакованный десятичный / двоичный десятичный код ).
  • Нарушения доступа.
  • Утечка ресурсов, когда конечный системный ресурс (например, память или дескрипторы файлов ) исчерпываются из-за повторного выделения без освобождения.
  • Переполнение буфера, при котором программа пытается сохранить данные за пределами выделенного хранилища. Это может привести или не привести к доступу нарушение или нарушение хранилища. Они известны как ошибки безопасности.
  • Чрезмерная рекурсия, которая, хотя и логически допустима, вызывает переполнение стека.
  • Ошибка использования после освобождения, где указатель используется после того, как система освободила память, на которую он ссылается.
  • Ошибка двойного освобождения.

Многопоточность

  • Тупик, когда задача A не может продолжаться до выполнения задачи B. заканчивается, но в в то же время задача B не может продолжаться до завершения задачи A.
  • Состояние гонки, когда компьютер не выполняет задачи в порядке, заданном программистом.
  • Ошибки параллелизма в критических секциях, взаимные исключения и другие особенности параллельной обработки. Время проверки — время использования (TOCTOU) — это форма незащищенной критической секции.

Взаимодействие

  • Неправильное использование API.
  • Неправильная реализация протокола.
  • Неправильная обработка оборудования.
  • Неправильные предположения о конкретной платформе.
  • Несовместимые системы. Новый API или протокол связи может показаться работоспособным, когда две системы используют разные версии, но могут возникать ошибки, когда функция или функция, реализованная в одной версии, изменяется или отсутствует в другой. В производственных системах, которые должны работать постоянно, отключение всей системы для крупного обновления может оказаться невозможным, например, в телекоммуникационной отрасли или в Интернете. В этом случае меньшие сегменты большой системы обновляются индивидуально, чтобы свести к минимуму перебои в работе большой сети. Однако некоторые разделы могут быть пропущены и не обновлены, что может вызвать ошибки совместимости, которые трудно найти и исправить.
  • Неправильные аннотации кода

Коллективная работа

  • Нераспространяемые обновления; например программист изменяет myAdd, но забывает изменить mySubtract, который использует тот же алгоритм. Эти ошибки смягчаются философией Не повторяйся.
  • Комментарии устарели или неверны: многие программисты считают, что комментарии точно описывают код.
  • Различия между документации и продукта.

Последствия

Объем и тип ущерба, который может вызвать программная ошибка, естественным образом влияют на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемые космические путешествия или автомобильная безопасность, поскольку недостатки программного обеспечения могут привести к травмам или даже смерти людей, такое программное обеспечение будет подвергаться гораздо более тщательной проверке и контролю качества, чем для Например, веб-сайт интернет-магазина. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, приложение для редактирования фотографий. Технологическому центру Software Assurance НАСА удалось снизить количество ошибок до менее 0,1 на 1000 строк кода (SLOC ), но это не было сочтено возможным для проектов в мире бизнеса..

Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, вложенными в их исправление. В 1978 году Линц и др. показал, что в среднем по проектам 17% усилий по разработке вкладывается в исправление ошибок. Исследование, проведенное в 2020 году в репозиториях GitHub, показало, что медиана составляет 20 процентов.

Хорошо известные ошибки

Ряд программных ошибок стал широко известным, обычно из-за по степени серьезности: примеры включают крушения различных космических и военных самолетов. Возможно, самая известная ошибка — это проблема 2000 года, также известная как ошибка 2000 года, в которой опасались, что мировой экономический коллапс произойдет в начале 2000 года в результате того, что компьютеры думали, что это был 1900. (В конце концов, серьезных проблем не возникло.) Срыв в 2012 году на бирже был связан с одной такой несовместимостью между старым API и новым API.

В массовой культуре

  • В романе 1968 года 2001: Космическая одиссея и соответствующем фильме 1968 года 2001: Космическая одиссея, бортовой компьютер космического корабля, HAL 9000, пытается убить всех членов экипажа. В последующем романе 1982 года 2010: Одиссея 2 и сопутствующем фильме 1984 года 2010 выясняется, что это действие было вызвано тем, что компьютер был запрограммирован двумя конфликтующими цели: полностью раскрыть всю свою информацию и сохранить в секрете истинную цель полета от экипажа; этот конфликт привел к тому, что HAL стал параноиком и, в конечном итоге, стал смертоносным.
  • В американской комедии 1999 года Офисное пространство трое сотрудников пытаются использовать озабоченность своей компании исправлением компьютерной ошибки Y2K, заразив компьютер компании система с вирусом, который отправляет округленные пенни на отдельный банковский счет. Этот план имеет неприятные последствия, поскольку у самого вируса есть собственная ошибка, которая преждевременно отправляет большие суммы денег на счет.
  • Роман 2004 года «Ошибка» Эллен Ульман описывает попытку программиста найти неуловимую ошибку в приложении базы данных.
  • Канадский фильм 2008 года Control Alt Delete рассказывает о программисте в конце 1999 года, который пытается исправить ошибки в своей компании, связанные с годом Проблема 2000.

См. Также

Ссылки

Внешние ссылки

  • «Перечисление общих слабых мест »- экспертная веб-страница, посвященная ошибкам, на NIST.gov
  • тип ОШИБКИ Джима Грея — другое er Тип ошибки
  • Изображение «первой компьютерной ошибки» на Wayback Machine (архивировано 12 января 2015 г.)
  • «Первая компьютерная ошибка! »- письмо от 1981 об ошибке Адмирала Хоппера
  • «на пути к пониманию ошибок компилятора в GCC и LLVM «. Исследование ошибок в компиляторах 2016 г.

Отладка программы — один их самых сложных этапов разработки программного обеспечения, требующий глубокого знания:

специфики управления используемыми техническими средствами,

операционной системы,

среды и языка программирования,

реализуемых процессов,

природы и специфики различных ошибок,

методик отладки и соответствующих программных средств. 

Отладка — это процесс локализации и исправления ошибок, обнаруженных при тестировании программного обеспечения. Локализацией называют процесс определения оператора программы, выполнение которого вызвало нарушение нормального вычислительного процесса. Доя исправления ошибки необходимо определить ее причину, т. е. определить оператор или фрагмент, содержащие ошибку. Причины ошибок могут быть как очевидны, так и очень глубоко скрыты.

Вцелом сложность отладки обусловлена следующими причинами:

требует от программиста глубоких знаний специфики управления используемыми техническими средствами, операционной системы, среды и языка программирования, реализуемых процессов, природы и специфики различных ошибок, методик отладки и соответствующих программных средств;

психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;

возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;

отсутствуют четко сформулированные методики отладки.

Всоответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):


    синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы; ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

    ошибки выполнения — ошибки, обнаруженные операционной системой, аппаратными средствами или пользователем при выполнении программы.

Синтаксические ошибки. Синтаксические ошибки относят к группе самых простых, так как синтаксис языка, как правило, строго формализован, и ошибки сопровождаются развернутым комментарием с указанием ее местоположения. Определение причин таких ошибок, как правило, труда не составляет, и даже при нечетком знании правил языка за несколько прогонов удается удалить все ошибки данного типа.

Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, имеющий очень простой и четко определенный синтаксис, хорошо проверяемый при компиляции программы, ко вторым — Си со всеми его модификациями. Чего стоит хотя бы возможность выполнения присваивания в условном операторе в Си, например:

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */ 

Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

обнаруженными при разрешении внешних ссылок. Например, предусмотрено обращение к подпрограмме другого модуля, а при объединении модулей данная подпрограмма не найдена или не стыкуются списки параметров. В большинстве случаев ошибки такого рода также удается быстро локализовать и устранить.

    Ошибки выполнения. К самой непредсказуемой группе относятся ошибки выполнения. Прежде всего они могут иметь разную природу, и соответственно по-разному проявляться. Часть ошибок обнаруживается и документируется операционной системой. Выделяют четыре способа проявления таких ошибок:

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т. п.;

«зависание» компьютера, как простое, когда удается завершить программу без перезагрузки операционной системы, так и «тяжелое», когда для продолжения работы необходима перезагрузка;

несовпадение полученных результатов с ожидаемыми.

Примечание. Отметим, что, если ошибки этапа выполнения обнаруживает пользователь, то в двух первых случаях, получив соответствующее сообщение, пользователь в зависимости от своего характера, степени необходимости и опыта работы за компьютером, либо попробует понять, что произошло, ища свою вину, либо обратится за помощью, либо постарается никогда больше не иметь дела с этим продуктом. При «зависании» компьютера пользователь может даже не сразу понять, что происходит что-то не то, хотя его печальный опыт и заставляет волноваться каждый раз, когда компьютер не выдает быстрой реакции на введенную команду, что также целесообразно иметь в виду. Также опасны могут быть ситуации, при которых пользователь получает неправильные результаты и использует их в своей работе.

Причины ошибок выполнения очень разнообразны, а потому и локализация может оказаться крайне сложной. Все возможные причины ошибок можно разделить на следующие группы:

неверное определение исходных данных,

логические ошибки,

накопление погрешностей результатов вычислений (рис. 10.2).

Н е в е р н о е о п р е д е л е н и е и с х о д н ы х д а н н ы х происходит, если возникают любые ошибки при выполнении операций ввода-вывода: ошибки передачи, ошибки преобразования, ошибки перезаписи и ошибки данных. Причем использование специальных технических средств и программирование с защитой от ошибок (см.§ 2.7) позволяет обнаружить и предотвратить только часть этих ошибок, о чем безусловно не следует забывать.

Л о г и ч е с к и е о ш и б к и имеют разную природу. Так они могут следовать из ошибок, допущенных при проектировании, например, при выборе методов, разработке алгоритмов или определении структуры классов, а могут быть непосредственно внесены при кодировании модуля.

Кпоследней группе относят:

ошибки некорректного использования переменных, например, неудачный выбор типов данных, использование переменных до их инициализации, использование индексов, выходящих за границы определения массивов, нарушения соответствия типов данных при использовании явного или неявного переопределения типа данных, расположенных в памяти при использовании нетипизированных переменных, открытых массивов, объединений, динамической памяти, адресной арифметики и т. п.;

ошибки вычислений, например, некорректные вычисления над неарифметическими переменными, некорректное использование целочисленной арифметики, некорректное преобразование типов данных в процессе вычислений, ошибки, связанные с незнанием приоритетов выполнения операций для арифметических и логических выражений, и т. п.;

ошибки межмодульного интерфейса, например, игнорирование системных соглашений, нарушение типов и последовательности при передачи параметров, несоблюдение единства единиц измерения формальных и фактических параметров, нарушение области действия локальных и глобальных переменных;

другие ошибки кодирования, например, неправильная реализация логики программы при кодировании, игнорирование особенностей или ограничений конкретного языка программирования.

На к о п л е н и е п о г р е ш н о с т е й результатов числовых вычислений возникает, например, при некорректном отбрасывании дробных цифр чисел, некорректном использовании приближенных методов вычислений, игнорировании ограничения разрядной сетки представления вещественных чисел в ЭВМ и т. п.

Все указанные выше причины возникновения ошибок следует иметь в виду в процессе отладки. Кроме того, сложность отладки увеличивается также вследствие влияния следующих факторов:

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску – так называемые стохастические ошибки;

возможности устранения внешних проявлений ошибок в исследуемой ситуации при внесении некоторых изменений в программу, например, при включении в программу диагностических фрагментов может аннулироваться или измениться внешнее проявление ошибок;

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

Отладка программы в любом случае предполагает обдумывание и логическое осмысление всей имеющейся информации об ошибке. Большинство ошибок можно обнаружить по косвенным признакам посредством тщательного анализа текстов программ и результатов тестирования без получения дополнительной информации. При этом используют различные методы:

ручного тестирования;

индукции;

дедукции;

обратного прослеживания.

Метод ручного тестирования. Это — самый простой и естественный способ данной группы. При обнаружении ошибки необходимо выполнить тестируемую программу вручную, используя тестовый набор, при работе с которым была обнаружена ошибка.

Метод очень эффективен, но не применим для больших программ, программ со сложными вычислениями и в тех случаях, когда ошибка связана с неверным представлением программиста о выполнении некоторых операций.

Данный метод часто используют как составную часть других методов отладки.

Метод индукции. Метод основан на тщательном анализе симптомов ошибки, которые могут проявляться как неверные результаты вычислений или как сообщение об ошибке. Если компьютер просто «зависает», то фрагмент проявления ошибки вычисляют, исходя из последних полученных результатов и действий пользователя. Полученную таким образом информацию организуют и тщательно изучают, просматривая соответствующий фрагмент программы. В результате этих действий выдвигают гипотезы об ошибках, каждую из которых проверяют. Если гипотеза верна, то детализируют информацию об ошибке, иначе — выдвигают другую гипотезу. Последовательность выполнения отладки методом индукции показана на рис. 10.3 в виде схемы алгоритма.

Самый ответственный этап — выявление симптомов ошибки. Организуя данные об ошибке, целесообразно записать все, что известно о ее проявлениях, причем фиксируют, как ситуации, в которых фрагмент с ошибкой выполняется нормально, так и ситуации, в которых ошибка проявляется. Если в результате изучения данных никаких гипотез не появляется, то необходима дополнительная информация об ошибке. Дополнительную информацию можно получить, например, в результате выполнения схожих тестов.

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

Метод дедукции. По методу дедукции вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину (рис. 10.4).

Метод обратного прослеживания. Для небольших программ эффективно применение метода обратного прослеживания. Начинают с точки вывода неправильного результата. Для этой точки строится гипотеза о значениях основных переменных, которые могли бы привести к получению имеющегося результата. Далее, исходя из этой гипотезы, делают предложения о значениях переменных в предыдущей точке. Процесс продолжают, пока не обнаружат причину ошибки.

    1. Отладка и тестирование программы

Отладка
программы является итеративным процессом
обнаружения и исправления ошибок и
обычно требует последовательного
выполнения четырех этапов:

  • выявления
    ошибки;

  • локализации
    ошибки в тексте программы;

  • установления
    причины ошибки;

  • исправления
    ошибки.

Некоторые
ошибки проявляются после первого же
запуска программы на выполнение, и для
их обнаружения не надо прибегать ни к
каким специальным средствам. Некоторые
ошибки проявляются в случайные моменты
работы программы. С такими ошибками
справиться труднее всего – зафиксировать
условия возникновения ошибки, понять
причину ошибки и устранить ее. С целью
обнаружения подобных ошибок осуществляется
тестирование
программы

ее выполнение для специально подобранных
представительных контрольных примеров
– тестов. Тест
это такой
набор исходных данных, для которого
вручную или другим способом просчитаны
промежуточные и конечные результаты и
который может быть использован для
получения информации о надежности
проверяемой программы.

Тестирование
программы должно включать в себя прогон
трех видов контрольных примеров:
нормальных ситуаций, граничных ситуаций
и случаев неправильных данных.
Нормальные
случаи

это примеры с правильными входными
данными. Если программа не работает в
подобных случаях, она требует серьезных
переделок. Граничные контрольные примеры
помогают установить, способна ли
программа нормально реагировать на
особые случаи во входных данных. Граничные
примеры

представляют собой данные, которые,
будучи математически корректными,
приводят программу к необходимости
работать особым образом. Неправильными
являются
такие данные,
которые расположены вне допустимого
диапазона. Примеры с неправильными
данными должны быть обработаны
соответствующим образом, поскольку в
повседневной эксплуатации программе
придется иметь дело и с неверными
входными данными.

После того как
ошибка обнаружена, необходимо найти в
исходном тексте программы то место, в
котором она возникала, – локализовать
ошибку.
Можно
использовать ряд различных методов
отладки, позволяющих обнаружить
расположение ошибки; выбор существенно
зависит от особенностей ситуации.
Большинство программистов начинают с
неформального метода, известного под
названием проверка
за столом.
Используя
контрольный пример, который привел к
ошибке в программе, программист
аналитически трассирует листинг
программы в надежде локализовать ошибку.
Проверка за столом – это хороший метод,
поскольку он заставляет программиста
детально понять работу программы. Если
применение метода проверки за столом
оказалось бесплодным, нужно использовать
специальные методы и способы отладки,
позволяющие наблюдать за передачей
управления в программе и за изменением
значений наиболее важных переменных.
Полученная отладочная информация
позволит локализовать подозрительные
ситуации, провести анализ и выявить
причину ошибки, устранить ее, а затем
продолжить поиск других ошибок.

      1. Причины и типы ошибок

В общем случае
ошибки могут возникать на любом этапе
разработки программы, причина ошибок
может быть связана с недопониманием
сути задачи, недостатками проектирования
алгоритма, неправильным использованием
языковых средств. При выполнении
программы ошибки разного типа проявляют
себя различным образом, и их принято
подразделять на следующие группы:

  • синтаксические
    ошибки;

  • семантические
    ошибки;

  • логические
    ошибки.

Синтаксические
ошибки

это ошибки, проявляющиеся на этапе
компиляции программы и возникающие в
связи с нарушением синтаксических
правил написания предложений используемого
языка программирования (к таким ошибкам
относятся
пропущенные точки с запятой, ссылки на
неописанные переменные, присваивание
переменной значений неверного типа и
т. д.). Если компилятор встречает в
тексте программы оператор или описание,
которые
он не может интерпретировать, то он
позиционирует курсор на место обнаруженной
ошибки и
в строку статуса выводит сообщение,
содержащее номер ошибки и ее краткое
описание.

Семантические
ошибки –
это
ошибки, проявляющиеся на этапе
выполнения программы при ее попытке
вычислить недопустимые значения
параметров или выполнить недопустимые
действия. Причина возникновения ошибок
данного типа связана с нарушением
семантических правил написания программ
(примером являются ситуации
попытки
открыть несуществующий файл или выполнить
деление на нуль). Если программа
обнаруживает ошибку такого типа, то она
завершает свое выполнение
и
выводит
соответствующее сообщение в окне Build,
содержащее номер строки с ошибкой и ее
возможный характер. Список сообщений
можно просмотреть с помощью команды
меню View/Debug
Windows/Event
Log.
При выполнении программы из среды Delphi
автоматически выбирается соответствующий
исходный файл и в нем находится
местоположение ошибки. Если же программа
выполнялась вне среды и в ней появилась
ошибка данного типа, то необходимо
запустить
среду и найти вызвавший ошибку оператор.

Логические
(смысловые) ошибки –
самые
сложные и трудноуловимые, связанные с
неправильным применением тех или иных
алгоритмических конструкций. Эти ошибки
при выполнении программы могут проявиться
явно (выдано сообщение об ошибке, нет
результата или выдан неверный результат,
программа «зацикливается»), но чаще
они проявляют себя только при определенных
сочетаниях параметров или вообще не
вызывают нарушения работы программы,
которая в этом случае выдает правдоподобные,
но неверные результаты.

Ошибки первого
типа легко выявляются самим компилятором.
Обычно устранение синтаксических ошибок
не вызывает особых трудностей. Более
сложно выявить ошибки второго и особенно
третьего типа. Для обнаружения и
устранения ошибок второго и третьего
типа обычно применяют специальные
способы и средства отладки программ.
Выявлению ошибок второго типа часто
помогает использование контролирующих
режимов компиляции с проверкой допустимых
значений тех или иных параметров (границ
индексов элементов массивов, значений
переменных типа диапазона, ситуаций
переполнения, ошибок ввода-вывода).
Устанавливаются эти режимы с помощью
ключей
компилятора
,
задаваемых либо в программе, либо в меню
Project/Options/Compiler
среды
Delphi, либо
в
меню
Options/Compiler Турбо-среды.

Соседние файлы в папке крутые билеты по инфе

  • #
  • #
  • #
  • #

Обнаружение ошибок в технике связи — действие, направленное на контроль целостности данных при записи/воспроизведении информации или при её передаче по линиям связи. Исправление ошибок (коррекция ошибок) — процедура восстановления информации после чтения её из устройства хранения или канала связи.

Для обнаружения ошибок используют коды обнаружения ошибок, для исправления — корректирующие коды (коды, исправляющие ошибки, коды с коррекцией ошибок, помехоустойчивые коды).

Содержание

  • 1 Способы борьбы с ошибками
  • 2 Коды обнаружения и исправления ошибок
    • 2.1 Блоковые коды
      • 2.1.1 Линейные коды общего вида
        • 2.1.1.1 Минимальное расстояние и корректирующая способность
        • 2.1.1.2 Коды Хемминга
        • 2.1.1.3 Общий метод декодирования линейных кодов
      • 2.1.2 Линейные циклические коды
        • 2.1.2.1 Порождающий (генераторный) полином
        • 2.1.2.2 Коды CRC
        • 2.1.2.3 Коды БЧХ
        • 2.1.2.4 Коды коррекции ошибок Рида — Соломона
      • 2.1.3 Преимущества и недостатки блоковых кодов
    • 2.2 Свёрточные коды
      • 2.2.1 Преимущества и недостатки свёрточных кодов
    • 2.3 Каскадное кодирование. Итеративное декодирование
    • 2.4 Сетевое кодирование
    • 2.5 Оценка эффективности кодов
      • 2.5.1 Граница Хемминга и совершенные коды
      • 2.5.2 Энергетический выигрыш
    • 2.6 Применение кодов, исправляющих ошибки
  • 3 Автоматический запрос повторной передачи
    • 3.1 Запрос ARQ с остановками (stop-and-wait ARQ)
    • 3.2 Непрерывный запрос ARQ с возвратом (continuous ARQ with pullback)
    • 3.3 Непрерывный запрос ARQ с выборочным повторением (continuous ARQ with selective repeat)
  • 4 См. также
  • 5 Литература
  • 6 Ссылки

[править] Способы борьбы с ошибками

В процессе хранения данных и передачи информации по сетям связи неизбежно возникают ошибки. Контроль целостности данных и исправление ошибок — важные задачи на многих уровнях работы с информацией (в частности, физическом, канальном, транспортном уровнях сетевой модели OSI).

В системах связи возможны несколько стратегий борьбы с ошибками:

  • обнаружение ошибок в блоках данных и автоматический запрос повторной передачи повреждённых блоков — этот подход применяется, в основном, на канальном и транспортном уровнях;
  • обнаружение ошибок в блоках данных и отбрасывание повреждённых блоков — такой подход иногда применяется в системах потокового мультимедиа, где важна задержка передачи и нет времени на повторную передачу;
  • исправление ошибок (англ. forward error correction) применяется на физическом уровне.

[править] Коды обнаружения и исправления ошибок

Корректирующие коды — коды, служащие для обнаружения или исправления ошибок, возникающих при передаче информации под влиянием помех, а также при её хранении.

Для этого при записи (передаче) в полезные данные добавляют специальным образом структурированную избыточную информацию (контрольное число), а при чтении (приёме) её используют для того, чтобы обнаружить или исправить ошибки. Естественно, что число ошибок, которое можно исправить, ограничено и зависит от конкретного применяемого кода.

С кодами, исправляющими ошибки, тесно связаны коды обнаружения ошибок. В отличие от первых, последние могут только установить факт наличия ошибки в переданных данных, но не исправить её.

В действительности, используемые коды обнаружения ошибок принадлежат к тем же классам кодов, что и коды, исправляющие ошибки. Фактически любой код, исправляющий ошибки, может быть также использован для обнаружения ошибок (при этом он будет способен обнаружить большее число ошибок, чем был способен исправить).

По способу работы с данными коды, исправляющие ошибки, делятся на блоковые, делящие информацию на фрагменты постоянной длины и обрабатывающие каждый из них в отдельности, и свёрточные, работающие с данными как с непрерывным потоком.

[править] Блоковые коды

Пусть кодируемая информация делится на фрагменты длиной k бит, которые преобразуются в кодовые слова длиной n бит. Тогда соответствующий блоковый код обычно обозначают (n,\;k). При этом число R=\frac{k}{n} называется скоростью кода.

Если исходные k бит код оставляет неизменными, и добавляет n-k проверочных, такой код называется систематическим, иначе несистематическим.

Задать блоковый код можно по-разному, в том числе таблицей, где каждой совокупности из k информационных бит сопоставляется n бит кодового слова. Однако хороший код должен удовлетворять как минимум следующим критериям:

  • способность исправлять как можно большее число ошибок,
  • как можно меньшая избыточность,
  • простота кодирования и декодирования.

Нетрудно видеть, что приведённые требования противоречат друг другу. Именно поэтому существует большое количество кодов, каждый из которых пригоден для своего круга задач.

Практически все используемые коды являются линейными. Это связано с тем, что нелинейные коды значительно сложнее исследовать, и для них трудно обеспечить приемлемую лёгкость кодирования и декодирования.

[править] Линейные коды общего вида

Линейный блоковый код — такой код, что множество его кодовых слов образует k-мерное линейное подпространство (назовём его C) в n-мерном линейном пространстве, изоморфное пространству k-битных векторов.

Это значит, что операция кодирования соответствует умножению исходного k-битного вектора на невырожденную матрицу G, называемую порождающей матрицей.

Пусть C^{\perp} — ортогональное подпространство по отношению к C, а H — матрица, задающая базис этого подпространства. Тогда для любого вектора \overrightarrow{v}\in C справедливо:

\overrightarrow{v}H^T=\overrightarrow{0}.
[править] Минимальное расстояние и корректирующая способность

Расстоянием Хемминга (метрикой Хемминга) между двумя кодовыми словами \overrightarrow{u} и \overrightarrow{v} называется количество отличных бит на соответствующих позициях:

d_H(\overrightarrow{u},\;\overrightarrow{v})=\sum_s{|u^{(s)}-v^{(s)}|}.

Минимальное расстояние Хемминга d_\min=\min_{u\ne v}d_H(\overrightarrow{u},\;\overrightarrow{v}) является важной характеристикой линейного блокового кода. Она показывает, насколько «далеко» расположены коды друг от друга. Она определяет другую, не менее важную характеристику — корректирующую способность:

t=\left\lfloor\frac{d_\min-1}{2}\right\rfloor.

Корректирующая способность определяет, сколько ошибок передачи кода (типа 1\leftrightarrow 0) можно гарантированно исправить. То есть вокруг каждого кодового слова A имеем t-окрестность A_t, которая состоит из всех возможных вариантов передачи кодового слова A с числом ошибок (1\leftrightarrow 0) не более t. Никакие две окрестности двух любых кодовых слов не пересекаются друг с другом, так как расстояние между кодовыми словами (то есть центрами этих окрестностей) всегда больше двух их радиусов d_H(A,\;B)\geqslant d_\min>2t.

Таким образом, получив искажённую кодовую комбинацию из A_t, декодер принимает решение, что исходной была кодовая комбинация A, исправляя тем самым не более t ошибок.

Поясним на примере. Предположим, что есть два кодовых слова A и B, расстояние Хемминга между ними равно 3. Если было передано слово A, и канал внёс ошибку в одном бите, она может быть исправлена, так как даже в этом случае принятое слово ближе к кодовому слову A, чем к любому другому, и, в частности, к B. Но если каналом были внесены ошибки в двух битах (в которых A отличалось от B), то результат ошибочной передачи A окажется ближе к B, чем A, и декодер примет решение, что передавалось слово B.

[править] Коды Хемминга

Коды Хемминга — простейшие линейные коды с минимальным расстоянием 3, то есть способные исправить одну ошибку. Код Хемминга может быть представлен в таком виде, что синдром

\overrightarrow{s}=\overrightarrow{r}H^T, где \overrightarrow{r} — принятый вектор, будет равен номеру позиции, в которой произошла ошибка. Это свойство позволяет сделать декодирование очень простым.
[править] Общий метод декодирования линейных кодов

Любой код (в том числе нелинейный) можно декодировать с помощью обычной таблицы, где каждому значению принятого слова \overrightarrow{r}_i соответствует наиболее вероятное переданное слово \overrightarrow{u}_i. Однако данный метод требует применения огромных таблиц уже для кодовых слов сравнительно небольшой длины.

Для линейных кодов этот метод можно существенно упростить. При этом для каждого принятого вектора \overrightarrow{r}_i вычисляется синдром \overrightarrow{s}_i=\overrightarrow{r}_i H^T. Поскольку \overrightarrow{r}_i=\overrightarrow{v}_i+\overrightarrow{e}_i, где \overrightarrow{v}_i — кодовое слово, а \overrightarrow{e}_i — вектор ошибки, то \overrightarrow{s}_i=\overrightarrow{e}_i H^T. Затем с помощью таблицы по синдрому определяется вектор ошибки, с помощью которого определяется переданное кодовое слово. При этом таблица получается гораздо меньше, чем при использовании предыдущего метода.

[править] Линейные циклические коды

Несмотря на то, что декодирование линейных кодов значительно проще декодирования большинства нелинейных, для большинства кодов этот процесс всё ещё достаточно сложен. Циклические коды, кроме более простого декодирования, обладают и другими важными свойствами.

Циклическим кодом является линейный код, обладающий следующим свойством: если \overrightarrow{v} является кодовым словом, то его циклическая перестановка также является кодовым словом.

Слова циклического кода удобно представлять в виде многочленов. Например, кодовое слово \overrightarrow{v}=(v_0,\;v_1,\;\ldots,\;v_{n-1}) представляется в виде полинома v(x)=v_0+v_1 x+\ldots+v_{n-1}x^{n-1}. При этом циклический сдвиг кодового слова эквивалентен умножению многочлена на x по модулю x^n-1.

В дальнейшем, если не указано иное, мы будем считать, что циклический код является двоичным, то есть v_0,\;v_1,\;\ldots могут принимать значения 0 или 1.

[править] Порождающий (генераторный) полином

Можно показать, что все кодовые слова конкретного циклического кода кратны определённому порождающему полиному g(x). Порождающий полином является делителем x^n-1.

С помощью порождающего полинома осуществляется кодирование циклическим кодом. В частности:

[править] Коды CRC

Коды CRC (англ. cyclic redundancy check — циклическая избыточная проверка) являются систематическими кодами, предназначенными не для исправления ошибок, а для их обнаружения. Они используют способ систематического кодирования, изложенный выше: «контрольная сумма» вычисляется путем деления x^{n-k}u(x) на g(x). Ввиду того, что исправление ошибок не требуется, проверка правильности передачи может производиться точно так же.

Таким образом, вид полинома g(x) задаёт конкретный код CRC. Примеры наиболее популярных полиномов:

название кода степень полином
CRC-12 12 x^{12}+x^{11}+x^{3}+x^{2}+x+1
CRC-16 16 x^{16}+x^{15}+x^{2}+1
CRC-CCITT 16 x^{16}+x^{12}+x^{5}+1
CRC-32 32 x^{32}+x^{26}+x^{23}+x^{22}+x^{16}+x^{12}+x^{11}+x^{10}+x^{8}+x^{7}+x^{5}+x^{4}+x^{2}+x+1
[править] Коды БЧХ

Коды Боуза — Чоудхури — Хоквингема (БЧХ) являются подклассом циклических кодов. Их отличительное свойство — возможность построения кода БЧХ с минимальным расстоянием не меньше заданного. Это важно, потому что, вообще говоря, определение минимального расстояния кода есть очень сложная задача.

Математически полинома g(x) на множители в поле Галуа.

[править] Коды коррекции ошибок Рида — Соломона

Коды Рида — Соломона — недвоичные циклические коды, позволяющие исправлять ошибки в блоках данных. Элементами кодового вектора являются не биты, а группы битов (блоки). Очень распространены коды Рида-Соломона, работающие с байтами (октетами).

Математически коды Рида — Соломона являются кодами БЧХ.

[править] Преимущества и недостатки блоковых кодов

Хотя блоковые коды, как правило, хорошо справляются с редкими, но большими пачками ошибок, их эффективность при частых, но небольших ошибках (например, в канале с АБГШ), менее высока.

[править] Свёрточные коды

Свёрточные коды, в отличие от блоковых, не делят информацию на фрагменты и работают с ней как со сплошным потоком данных.

Свёрточные коды, как правило, порождаются дискретной линейной инвариантной во времени системой. Поэтому, в отличие от большинства блоковых кодов, свёрточное кодирование — очень простая операция, чего нельзя сказать о декодировании.

Кодирование свёрточным кодом производится с помощью регистра сдвига, отводы от которого суммируются по модулю два. Таких сумм может быть две (чаще всего) или больше.

Декодирование свёрточных кодов, как правило, производится по алгоритму Витерби, который пытается восстановить переданную последовательность согласно критерию максимального правдоподобия.

[править] Преимущества и недостатки свёрточных кодов

Свёрточные коды эффективно работают в канале с белым шумом, но плохо справляются с пакетами ошибок. Более того, если декодер ошибается, на его выходе всегда возникает пакет ошибок.

[править] Каскадное кодирование. Итеративное декодирование

Преимущества разных способов кодирования можно объединить, применив каскадное кодирование. При этом информация сначала кодируется одним кодом, а затем другим, в результате получается код-произведение.

Например, популярной является следующая конструкция: данные кодируются кодом Рида-Соломона, затем перемежаются (при этом символы, расположенные близко, помещаются далеко друг от друга) и кодируются свёрточным кодом. На приёмнике сначала декодируется свёрточный код, затем осуществляется обратное перемежение (при этом пачки ошибок на выходе свёрточного декодера попадают в разные кодовые слова кода Рида — Соломона), и затем осуществляется декодирование кода Рида — Соломона.

Некоторые коды-произведения специально сконструированы для итеративного декодирования, при котором декодирование осуществляется в несколько проходов, каждый из которых использует информацию от предыдущего. Это позволяет добиться большой эффективности, однако декодирование требует больших ресурсов. К таким кодам относят турбо-коды и LDPC-коды (коды Галлагера).

[править] Сетевое кодирование

[править] Оценка эффективности кодов

Эффективность кодов определяется количеством ошибок, которые тот может исправить, количеством избыточной информации, добавление которой требуется, а также сложностью реализации кодирования и декодирования (как аппаратной, так и в виде программы для ЭВМ).

[править] Граница Хемминга и совершенные коды

Пусть имеется двоичный блоковый (n,k) код с корректирующей способностью t. Тогда справедливо неравенство (называемое границей Хемминга):

\sum_{i=0}^t {n\choose i}\leqslant 2^{n-k}.

Коды, удовлетворяющие этой границе с равенством, называются совершенными. К совершенным кодам относятся, например, коды Хемминга. Часто применяемые на практике коды с большой корректирующей способностью (такие, как коды Рида — Соломона) не являются совершенными.

[править] Энергетический выигрыш

При передаче информации по каналу связи вероятность ошибки зависит от отношения сигнал/шум на входе демодулятора, таким образом, при постоянном уровне шума решающее значение имеет мощность передатчика. В системах спутниковой и мобильной, а также других типов связи остро стоит вопрос экономии энергии. Кроме того, в определённых системах связи (например, телефонной) неограниченно повышать мощность сигнала не дают технические ограничения.

Поскольку помехоустойчивое кодирование позволяет исправлять ошибки, при его применении мощность передатчика можно снизить, оставляя скорость передачи информации неизменной. Энергетический выигрыш определяется как разница отношений с/ш при наличии и отсутствии кодирования.

[править] Применение кодов, исправляющих ошибки

Коды, исправляющие ошибки, применяются:

  • в системах цифровой связи, в том числе: спутниковой, радиорелейной, сотовой, передаче данных по телефонным каналам.
  • в системах хранения информации, в том числе магнитных и оптических.

Коды, обнаруживающие ошибки, применяются в сетевых протоколах различных уровней.

[править] Автоматический запрос повторной передачи

Системы с автоматическим запросом повторной передачи (ARQ — Automatic Repeat reQuest) основаны на технологии обнаружения ошибок. Распространены следующие методы автоматического запроса:

[править] Запрос ARQ с остановками (stop-and-wait ARQ)

Идея этого метода заключается в том, что передатчик ожидает от приемника подтверждения успешного приема предыдущего блока данных перед тем, как начать передачу следующего. В случае, если блок данных был принят с ошибкой, приемник передает отрицательное подтверждение (negative acknowledgement, NAK), и передатчик повторяет передачу блока. Данный метод подходит для полудуплексного канала связи. Его недостатком является низкая скорость из-за высоких накладных расходов на ожидание.

[править] Непрерывный запрос ARQ с возвратом (continuous ARQ with pullback)

Для этого метода необходим полнодуплексный канал. Передача данных от передатчика к приемнику производится одновременно. В случае ошибки передача возобновляется, начиная с ошибочного блока (то есть передается ошибочный блок и все последующие).

[править] Непрерывный запрос ARQ с выборочным повторением (continuous ARQ with selective repeat)

При этом подходе осуществляется передача только ошибочно принятых блоков данных.

[править] См. также

  • Цифровая связь
  • Код ответа (Код причины завершения)
  • Линейный код
  • Циклический код
  • Код Боуза — Чоудхури — Хоквингема
  • Код Рида — Соломона
  • LDPC
  • Свёрточный код
  • Турбо-код

[править] Литература

  • Блейхут Р. Теория и практика кодов, контролирующих ошибки = Theory and Practice of Error Control Codes. — М.: Мир, 1986. — 576 с.
  • Мак-Вильямс Ф. Дж., Слоэн Н. Дж. А. Теория кодов, исправляющих ошибки. М.: Радио и связь, 1979.
  • Морелос-Сарагоса Р. Искусство помехоустойчивого кодирования. Методы, алгоритмы, применение / пер. с англ. В. Б. Афанасьева. — М.: Техносфера, 2006. — 320 с. — (Мир связи). — 2000 экз. — ISBN 5-94836-035-0

[править] Ссылки

  • Помехоустойчивое кодирование (11 ноября 2001). — реферат по проблеме кодирования сообщений с исправлением ошибок. Архивировано из первоисточника 25 августа 2011. Проверено 25 декабря 2006.

Отладка программы — один их самых сложных этапов разработки программного обеспечения, требующий глубокого знания:

специфики управления используемыми техническими средствами,

операционной системы,

среды и языка программирования,

реализуемых процессов,

природы и специфики различных ошибок,

методик отладки и соответствующих программных средств. 

Отладка — это процесс локализации и исправления ошибок, обнаруженных при тестировании программного обеспечения. Локализацией называют процесс определения оператора программы, выполнение которого вызвало нарушение нормального вычислительного процесса. Доя исправления ошибки необходимо определить ее причину, т. е. определить оператор или фрагмент, содержащие ошибку. Причины ошибок могут быть как очевидны, так и очень глубоко скрыты.

Вцелом сложность отладки обусловлена следующими причинами:

требует от программиста глубоких знаний специфики управления используемыми техническими средствами, операционной системы, среды и языка программирования, реализуемых процессов, природы и специфики различных ошибок, методик отладки и соответствующих программных средств;

психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;

возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;

отсутствуют четко сформулированные методики отладки.

Всоответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):


    синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы; ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

    ошибки выполнения — ошибки, обнаруженные операционной системой, аппаратными средствами или пользователем при выполнении программы.

Синтаксические ошибки. Синтаксические ошибки относят к группе самых простых, так как синтаксис языка, как правило, строго формализован, и ошибки сопровождаются развернутым комментарием с указанием ее местоположения. Определение причин таких ошибок, как правило, труда не составляет, и даже при нечетком знании правил языка за несколько прогонов удается удалить все ошибки данного типа.

Следует иметь в виду, что чем лучше формализованы правила синтаксиса языка, тем больше ошибок из общего количества может обнаружить компилятор и, соответственно, меньше ошибок будет обнаруживаться на следующих этапах. В связи с этим говорят о языках программирования с защищенным синтаксисом и с незащищенным синтаксисом. К первым, безусловно, можно отнести Pascal, имеющий очень простой и четко определенный синтаксис, хорошо проверяемый при компиляции программы, ко вторым — Си со всеми его модификациями. Чего стоит хотя бы возможность выполнения присваивания в условном операторе в Си, например:

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */ 

Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

обнаруженными при разрешении внешних ссылок. Например, предусмотрено обращение к подпрограмме другого модуля, а при объединении модулей данная подпрограмма не найдена или не стыкуются списки параметров. В большинстве случаев ошибки такого рода также удается быстро локализовать и устранить.

    Ошибки выполнения. К самой непредсказуемой группе относятся ошибки выполнения. Прежде всего они могут иметь разную природу, и соответственно по-разному проявляться. Часть ошибок обнаруживается и документируется операционной системой. Выделяют четыре способа проявления таких ошибок:

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т. п.;

«зависание» компьютера, как простое, когда удается завершить программу без перезагрузки операционной системы, так и «тяжелое», когда для продолжения работы необходима перезагрузка;

несовпадение полученных результатов с ожидаемыми.

Примечание. Отметим, что, если ошибки этапа выполнения обнаруживает пользователь, то в двух первых случаях, получив соответствующее сообщение, пользователь в зависимости от своего характера, степени необходимости и опыта работы за компьютером, либо попробует понять, что произошло, ища свою вину, либо обратится за помощью, либо постарается никогда больше не иметь дела с этим продуктом. При «зависании» компьютера пользователь может даже не сразу понять, что происходит что-то не то, хотя его печальный опыт и заставляет волноваться каждый раз, когда компьютер не выдает быстрой реакции на введенную команду, что также целесообразно иметь в виду. Также опасны могут быть ситуации, при которых пользователь получает неправильные результаты и использует их в своей работе.

Причины ошибок выполнения очень разнообразны, а потому и локализация может оказаться крайне сложной. Все возможные причины ошибок можно разделить на следующие группы:

неверное определение исходных данных,

логические ошибки,

накопление погрешностей результатов вычислений (рис. 10.2).

Н е в е р н о е о п р е д е л е н и е и с х о д н ы х д а н н ы х происходит, если возникают любые ошибки при выполнении операций ввода-вывода: ошибки передачи, ошибки преобразования, ошибки перезаписи и ошибки данных. Причем использование специальных технических средств и программирование с защитой от ошибок (см.§ 2.7) позволяет обнаружить и предотвратить только часть этих ошибок, о чем безусловно не следует забывать.

Л о г и ч е с к и е о ш и б к и имеют разную природу. Так они могут следовать из ошибок, допущенных при проектировании, например, при выборе методов, разработке алгоритмов или определении структуры классов, а могут быть непосредственно внесены при кодировании модуля.

Кпоследней группе относят:

ошибки некорректного использования переменных, например, неудачный выбор типов данных, использование переменных до их инициализации, использование индексов, выходящих за границы определения массивов, нарушения соответствия типов данных при использовании явного или неявного переопределения типа данных, расположенных в памяти при использовании нетипизированных переменных, открытых массивов, объединений, динамической памяти, адресной арифметики и т. п.;

ошибки вычислений, например, некорректные вычисления над неарифметическими переменными, некорректное использование целочисленной арифметики, некорректное преобразование типов данных в процессе вычислений, ошибки, связанные с незнанием приоритетов выполнения операций для арифметических и логических выражений, и т. п.;

ошибки межмодульного интерфейса, например, игнорирование системных соглашений, нарушение типов и последовательности при передачи параметров, несоблюдение единства единиц измерения формальных и фактических параметров, нарушение области действия локальных и глобальных переменных;

другие ошибки кодирования, например, неправильная реализация логики программы при кодировании, игнорирование особенностей или ограничений конкретного языка программирования.

На к о п л е н и е п о г р е ш н о с т е й результатов числовых вычислений возникает, например, при некорректном отбрасывании дробных цифр чисел, некорректном использовании приближенных методов вычислений, игнорировании ограничения разрядной сетки представления вещественных чисел в ЭВМ и т. п.

Все указанные выше причины возникновения ошибок следует иметь в виду в процессе отладки. Кроме того, сложность отладки увеличивается также вследствие влияния следующих факторов:

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску – так называемые стохастические ошибки;

возможности устранения внешних проявлений ошибок в исследуемой ситуации при внесении некоторых изменений в программу, например, при включении в программу диагностических фрагментов может аннулироваться или измениться внешнее проявление ошибок;

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

Отладка программы в любом случае предполагает обдумывание и логическое осмысление всей имеющейся информации об ошибке. Большинство ошибок можно обнаружить по косвенным признакам посредством тщательного анализа текстов программ и результатов тестирования без получения дополнительной информации. При этом используют различные методы:

ручного тестирования;

индукции;

дедукции;

обратного прослеживания.

Метод ручного тестирования. Это — самый простой и естественный способ данной группы. При обнаружении ошибки необходимо выполнить тестируемую программу вручную, используя тестовый набор, при работе с которым была обнаружена ошибка.

Метод очень эффективен, но не применим для больших программ, программ со сложными вычислениями и в тех случаях, когда ошибка связана с неверным представлением программиста о выполнении некоторых операций.

Данный метод часто используют как составную часть других методов отладки.

Метод индукции. Метод основан на тщательном анализе симптомов ошибки, которые могут проявляться как неверные результаты вычислений или как сообщение об ошибке. Если компьютер просто «зависает», то фрагмент проявления ошибки вычисляют, исходя из последних полученных результатов и действий пользователя. Полученную таким образом информацию организуют и тщательно изучают, просматривая соответствующий фрагмент программы. В результате этих действий выдвигают гипотезы об ошибках, каждую из которых проверяют. Если гипотеза верна, то детализируют информацию об ошибке, иначе — выдвигают другую гипотезу. Последовательность выполнения отладки методом индукции показана на рис. 10.3 в виде схемы алгоритма.

Самый ответственный этап — выявление симптомов ошибки. Организуя данные об ошибке, целесообразно записать все, что известно о ее проявлениях, причем фиксируют, как ситуации, в которых фрагмент с ошибкой выполняется нормально, так и ситуации, в которых ошибка проявляется. Если в результате изучения данных никаких гипотез не появляется, то необходима дополнительная информация об ошибке. Дополнительную информацию можно получить, например, в результате выполнения схожих тестов.

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

Метод дедукции. По методу дедукции вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину (рис. 10.4).

Метод обратного прослеживания. Для небольших программ эффективно применение метода обратного прослеживания. Начинают с точки вывода неправильного результата. Для этой точки строится гипотеза о значениях основных переменных, которые могли бы привести к получению имеющегося результата. Далее, исходя из этой гипотезы, делают предложения о значениях переменных в предыдущей точке. Процесс продолжают, пока не обнаружат причину ошибки.

Понравилась статья? Поделить с друзьями:
  • Обнаружение ошибок спецификации
  • Обнаружены следующие проблемы adobe код ошибки 72
  • Обнаружены ошибки при сохранении файла excel
  • Обнаружение ошибок при передаче информации
  • Обнаружены ошибки при сохранении excel возможно