Процесс поиска и исправления ошибок это

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

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

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

Тестирование программы – это выполнение программы на наборах исходных данных (тестах), для которых известны результаты, полученные другим методом. Система тестов подбирается таким образом, чтобы

а) проверить все возможные режимы работы программы;

б) по возможности, локализовать ошибку.

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

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

33. ВИДЫ ОШИБОК В ПРОГРАММАХ

Об ошибках в программе сигнализируют некорректная работоспособность программы либо ее полное невыполнение. В наше время для обозначения ошибки в программе используют термин «Баг» (с англ. Bug-жук).

Есть несколько типов ошибок:

1) Логическая ошибка. Это, пожалуй, наиболее серьезная из всех ошибок. Когда написанная программа на любом языке компилирует и работает правильно, но выдает неправильный вывод, недостаток заключается в логике основного программирования. Это ошибка, которая была унаследована от недостатка в базовом алгоритме. Сама логика, на которой базируется вся программа, является ущербной. Чтобы найти решение такой ошибки нужно фундаментальное изменение алгоритма. Вам нужно начать копать в алгоритмическом уровне, чтобы сузить область поиска такой ошибки. (пример: задача программы вывести сумму двух чисел а и b.

varc,a,b:integer;

Begin

readln(a,b);

c:=a-b; {нужнобылонаписатьc:=a+b;}

writeln(c);

readln;

end.

2) Синтаксическая ошибка.Каждый компьютерный язык, такой как C, Java, Perl и Python имеет специфический синтаксис, в котором будет написан код. Когда программист не придерживаться «грамматики» спецификациями компьютерного языка, возникнет ошибка синтаксиса. Такого рода ошибки легко устраняются на этапе компиляции.

begin

writln(‘helloworld!’); {вместоwritElnнаписаноwritln, чтоприведеткошибке}

readln;

end.

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

vara,b:real;

begin

b:=7.5;

с:=b*3; {ошибка компиляции, мы присваиваем значениие несуществующей переменой}

writeln(a);

readln;

end.

4) Ошибки среды выполнения (RunTime).Программный код успешно скомпилирован, и исполняемый файл был создан. Вы можете вздохнуть с облегчением и запустить программу, чтобы проверить ее работу. Ошибки при выполнении программы могут возникнуть в результате аварии или нехватки ресурсов носителя. Разработчик должен был предвидеть реальные условия развертывания программы. Это можно исправить, вернувшись к стадии кодирования.

vara:array[1..5] of integer;

begin

a[0]:=5; {ошибка в том, что мы вышли за предел массива}

writeln(a[0]);

readln;

end;

5) Арифметическая ошибка.Многие программы используют числовые переменные, и алгоритм может включать несколько математических вычислений. Арифметические ошибки возникают, когда компьютер не может справиться с проблемами, такими как «Деление на ноль», или ведущие к бесконечному результату. Это снова логическая ошибка, которая может быть исправлена только путем изменения алгоритма.

vara:real;

begin

a:=10/0; {ошибка, делениена 0}

writeln(a);

readln

end.

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

vara:integer;

begin

a:=32768; {ошибка, максимальное значение переменной типа integer равно 32767}

end.

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

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

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

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

…

Читайте также:

©2015-2022 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-04-03
Нарушение авторских прав и Нарушение персональных данных



Поиск по сайту:

Мы поможем в написании ваших работ!

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.

Error detection schemes[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]

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. Определите назначение вашего продукта: Будь то приложение, веб-сайт и т.д., важно определить назначение продукта, чтобы создавать эффективные тестовые примеры.
2. Определите целевую аудиторию: Понимание целевой аудитории вашего продукта поможет определить, какие тестовые примеры следует создать.
3. Определите объем тестирования: решите, какой тип тестов вы будете использовать, в каких средах будет тестироваться продукт и какие функциональные возможности будут тестироваться.
4. Проанализируйте продукт и определите, как лучше всего поступить: определите типы тестов, которые необходимо выполнить, и спланируйте порядок, в котором они должны выполняться.
5. Создайте тестовые наборы: Создайте тестовые наборы, которые будут охватывать все функции, сценарии и области продукта.
6. Запустите тестовые наборы: Выполните тестовые наборы и проверьте результаты на соответствие ожидаемым базовым показателям.
7. Исправьте любые ошибки: Если будут обнаружены какие-либо недочеты, исправьте их и повторите тестирование до тех пор, пока все неполадки не будут устранены.
8. Следите за результатами: Как только продукт будет выпущен, следите за производительностью и отслеживайте данные об использовании.

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

Автоматизированное тестирование и отладка

.

Автоматизированное тестирование и отладка

Автоматизированное тестирование и отладка стали неотъемлемой частью процесса разработки программного обеспечения. Этот метод используется для поиска ошибок в программе и более эффективного и точного тестирования ее функциональности. Он использовался многими командами разработчиков программного обеспечения для непрерывной интеграции и доставки.

Выгоды

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

Методы

• Модульное тестирование: Это включает в себя тестирование базовых блоков кода и гарантирует, что все отдельные блоки кода работают должным образом и в соответствии с ожиданиями.
• Функциональное/ интеграционное тестирование: С помощью этого метода проверяются различия между функциональностью, ожидаемой при разработке программного обеспечения, и фактическим написанным кодом. Это также включает в себя тестирование различных пользовательских взаимодействий.
• Тестирование процесса: Используется для проверки ошибок, которые могут возникнуть в процессе запуска программы. Он проверяет наличие условий, которые могут привести к ошибкам в приложении.
• Тестирование производительности: Это включает в себя тестирование различных сценариев применения в условиях стресса и нагрузки. Цель состоит в том, чтобы проверить, может ли приложение масштабироваться и быстро реагировать в определенной ситуации.
• Тестирование безопасности/проникновения: Это включает в себя проверку на наличие уязвимостей в коде и оценку безопасности приложения.

Вывод

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

Отладка с использованием различных методов

Регрессионное тестирование и отладка

.

Регрессионное тестирование и отладка

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

Регрессионное тестирование

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

Типы регрессионных тестов

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

Отладка

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

Вывод

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

Тестирование и отладка безопасности

.

Тестирование и отладка безопасности

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

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

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

Разница между тестированием безопасности и отладкой

Оба процесса тестирования и отладки безопасности включают в себя проверку программного обеспечения и систем на наличие любых уязвимостей и изъянов. Однако у них разные цели и задачки:

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

Преимущества тестирования и отладки безопасности

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

Вывод

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

Тестирование производительности и отладка

Завершение и сопровождение процесса тестирования и отладки

«Тестирование и отладка — это процесс изучения всех аспектов кода в надежде, что ничего не было упущено из виду». — Николай Шилов, российский разработчик программного обеспечения

Завершение и сопровождение процесса тестирования и отладки

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

Этапы завершения и сопровождения процесса тестирования и отладки:

1. Планирование:Первым шагом в завершении и поддержании процесса тестирования и отладки является создание плана.

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

2. устанавливать:Следующим шагом является настройка тестовой среды.

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

3. Выполнение теста:Как только тестовая среда настроена, следующим шагом является выполнение тестов.

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

4. Исправление ошибок:Как только тесты выполнены, следующим шагом является исправление выявленных ошибок в коде или системе.

Это потребует отладки кода для выявления основной причины дефекта или проблемы.

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

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

6. Поддержание среды отладки и тестирования:Наконец, следует поддерживать среду тестирования и отладки.

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

Основные вопросы по теме «Тестирование и отладка»

Неэффективное планирование тестирования

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

Недостаточные навыки

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

Проблемы с производительностью

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

Неадекватное тестирование

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

Тестирование и отладка приложений является неотъемлемой частью процесса разработки и ключевым элементом в создании надежного программного обеспечения, не допускающего ошибок. В последние годы процесс тестирования и отладки приложений претерпел быстрые изменения в связи с достижениями в области стека технологий и появлением новых методов и инструментов разработки. Сегодня процессы тестирования и отладки включают в себя тщательное тестирование, чтобы гарантировать, что приложения работают в соответствии с их требованиями. Автоматизированное тестирование и автоматизация тестирования становятся все более популярными благодаря их полезности при обнаружении ошибок. Кроме того, команды разработчиков используют инструменты на основе искусственного интеллекта для сравнительного анализа и прогнозной аналитики, чтобы оптимизировать свои конвейеры тестирования и отладки. В ближайшие годы мы можем ожидать, что тестирование и отладка программных приложений станут более эффективными и надежными благодаря использованию возможностей искусственного интеллекта (ИИ), машинного обучения (ML) и обработки естественного языка (NLP). Кроме того, облачные инструменты и приложения для тестирования и отладки, вероятно, станут еще более доступными для разработчиков. Наконец, ожидается, что тестирование безопасности станет еще более строгим, как с помощью законодательства, так и технологий, поскольку организации уделяют приоритетное внимание безопасности цифровых активов.

Список используемой литературы:

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

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 г.

Разгадываешь кроссворд и не знаешь что такое процесс исправления ошибок? Вот подсказка и ответ на данный вопрос:

Первая буква «п», вторая буква «р», третья буква «а», четвертая буква «в», пятая буква «к», шестая буква «а». Всего 6 букв.