Ошибка в программном обеспечении определение

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.

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 Dictionary‘s 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 efforts, 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]

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 development 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, 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 2020, research 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]

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

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

Определение

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

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

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

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

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

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

Как классифицируют

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

1. Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
2. Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
3. Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

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

Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.

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

Виды

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

Разработчики выделяют следующие типы ошибок по уровню сложности:

1. «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
2. «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
3. «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
4. «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.

Типы багов

Ошибки в программах бывают:

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

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

Ошибки синтаксиса

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

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

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

Выше – пример логической ошибки в программе. Тут:

1. Происходит сравнение значения i с 15.
2. На экран выводится сообщение, если I = 15.
3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

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

Время выполнения

Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

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

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

Ресурсные

Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

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

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

Исключения и как избежать багов

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

Исключения бывают:

1. Программными. Они генерируются приложением или ОС.
2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

Готовая программа не всегда работает как надо. Бывает, возникают баги, предупреждения, исключения. В итоге программа зависает, дает сбой или вылетает. Но это не конец света. Любую ошибку в коде можно исправить, если знать, почему она возникла.

Программная ошибка: что это и почему возникает

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

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

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

Ошибки часто называют багами, но подразумевают под ними разное, например:

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

❗ Исключения. Это не ошибки, а особые ситуации, которые нужно обработать.

❗ Синтаксические ошибки. Это ошибка в программе, связанная с написанием кода. Пример: программист забыл поставить точку или неверно написал название оператора. Если не исправить, код программы не запустится, а останется просто текстом.

Классификация багов

У багов есть два атрибута — серьезности (Severity) и приоритета (Priority). Серьезность касается технической стороны, а приоритет — организационной.

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

По серьезности баги классифицируют так:

• Blocker — блокирующий баг. Программа запускается, но спустя время баг останавливает ее выполнение. Чтобы снова пользоваться программой, блокирующую ошибку в коде устраняют.
• Critical — критический баг. Нарушает функциональность программы. Появляется в разных частях кода, из-за этого основные функции не выполняются.
• Major — существенный баг. Не нарушает, но затрудняет работу основного функционала программы либо не дает функциям выполняться так, как задумано.
• Minor — незначительный баг. Слабо влияет на функционал программы, но может нарушать работу некоторых дополнительных функций.
• Trivial — тривиальный баг. На работу программы не влияет, но ухудшает общее впечатление. Например, на экране появляются посторонние символы или всё рябит.

🚦 По приоритету. Атрибут показывает, как быстро баг необходимо исправить, пока он не нанес программе приличный ущерб. Бывает таким:

• Top — наивысший. Такой баг — суперсерьезный, потому что может обвалить всю программу. Его устраняют в первую очередь.
• High — высокий. Может затруднить работу программы или ее функций, устраняют как можно скорее.
• Normal — обычный. Баг программу не ломает, просто где-то что-то будет работать не совсем верно. Устраняют в штатном порядке.
• Low — низкий. Баг не влияет на программу. Исправляют, только если у команды есть на это время.

Типы ошибок в программе

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

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

🧨 Взаимодействия. Это ошибка в участке кода, который отвечает за взаимодействие с аппаратным или программным окружением. Такая ошибка возникает, например, если неправильно использовать веб-протоколы. Исправляется элементарно: разработчик переписывает нужный кусок кода.

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

Компиляционные баги появляются, если что-то не так с компилятором или в коде есть синтаксические ошибки. Компилятор будто ругается: «Не понимаю, что тут написано. Не знаю, как обработать».

🧨 Ошибки среды выполнения. Возникают, когда программа скомпилирована и уже выглядит как файл — жми и работай. Юзер запускает файл, а программа тормозит и виснет. Причина — нехватка ресурсов, например памяти или буфера.

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

🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг. Надо лезть в код и проверять математику.

Что такое исключения в программах

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

Как это происходит:

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

Исключения бывают программными и аппаратными:

• Аппаратные создает процессор. К ним относят деление на ноль, выход за границы массива, обращение к невыделенной памяти.

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

Как контролировать баги в программе

🔧 Следите за компилятором. Когда компилятор преобразует текст программы в машинный код, то подсвечивает в нём сомнительные участки, которые способны вызывать баги. Некоторые предупреждения не обозначают баг как таковой, а только говорят: «Тут что-то подозрительное». Всё подозрительное надо изучать и прорабатывать, чтобы не было проблемы в будущем.

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

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

Ключевое: что такое ошибки в программировании

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

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

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

К вопросу о классификации программных ошибок

Березкин
Д.В.

Определение
понятия «ошибка в программе» 1

Классификация
ошибок по месту их возникновения 2

Классификация
ошибок с точки зрения тестировщика 12

Классификация
ошибок по степени их критичности 13

Классификация
ошибок в зависимости от их места в
жизненном цикле программного изделия 14

Классификация
программных ошибок (багов) с точки
зрения субъективного восприятия их
программистами 15

Некоторые
выводы 16

Литература 16

В качестве введения рассмотрим определения
понятия «ошибка». Начнем с наиболее
общего трактования этого понятия
применительно к некоторым техническим
системам.

По определению стандарта ISO
9241-13 [1] ошибка это – несоответствие
между целями пользователя и ответом
системы.

Определение, приведенное в работе [2],
предполагает, что ошибка вызвана не
сложностью задачи, а сложностью орудия
(напр., компьютерной системы), поэтому
она является не ошибкой пользователя,
а ошибкой разработчиков этого орудия.

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

Определение понятия «ошибка в программе»

В самом общем случае под ошибкой
понимается какой-то сбой в программе
на этапе ее выполнения.

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

Майерс дает такое нестрогое определение:
«Если программа не делает того, чего
пользователь от нее вполне обосновано
ожидает, значит налицо программная
ошибка» [3].

Автор работы [4] настаивает на субъективном
характере программных ошибок: «Не
существует ни абсолютного определения
ошибок, ни точного критерия наличия их
в программе. Можно лишь сказать, насколько
программа не справляется со своей
задачей, — это исключительно субъективная
характеристика».

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

В книге [6] приводится такое определение
программных ошибок: «Говоря простыми
словами, программная ошибка — не что
иное, как изъян в разработке программного
продукта, который вызывает несоответствие
ожидаемых результатов выполнения
программного продукта и фактически
полученных результатов. Дефект может
возникнуть на стадии кодирования, на
стадии формулирования требований или
на стадии проектирования, либо же его
причина может крыться в некорректной
конфигурации или данных. Дефектом может
быть также что-то другое, что не
соответствует ожиданиям заказчика и
что может быть, а может и не быть определено
в спецификации программного продукта».

Классификация ошибок по месту их возникновения

Классификация ошибок в книге [5] дается
по месту их возникновения. В главе 4
приводится краткая классификация ошибок
и в Приложении – более полная, которая,
на мой взгляд, не имеет строгих принципов
и является скорее перечнем возможных
ошибок, чем их классификацией. Авторы
исходят из того, что главным критерием
программы должно быть ее качество,
которое трактуется как отсутствие в
ней недостатков, а также сбоев и явных
ошибок. Недостатки программы зависят
от субъективной оценкой ее качества
потенциальным пользователем. При этом
авторы скептически относятся к
спецификации и утверждают, что даже при
ее наличии, выявленные на конечном этапе
недостатки говорят о ее низком качестве.
При таком подходе преодоление недостатков
программы, особенно на заключительном
этапе проектирования, может приводить
к снижению надежности. Очевидно, что
для разработки ответственного и
безопасного программного обеспечения
(ПО) такой подход не годится, однако
проблемы наличия ошибок в спецификациях,
субъективного оценивания пользователем
качества программы существуют и не
могут быть проигнорированы. Должна быть
разработана система некоторых ограничений,
которая бы учитывала эти факторы при
разработке и сертификации такого рода
ПО. Для обычных программ все проблемы,
связанные с субъективным оцениванием
их качества и наличием ошибок, скорее
всего неизбежны.

В краткой классификации выделяются
следующие ошибки.

Ошибки пользовательского интерфейса.

Функциональность.

Взаимодействие программы с пользователем.

Организация программы.

Пропущенные команды.

Производительность.

Выходные данные.

Обработка ошибок.

Ошибки, связанные с обработкой граничных
условий.

Ошибки
вычислений.

Начальное и последующие состояния.

Ошибки управления потоком.

Ошибки передачи или интерпретации
данных.

Ситуация гонок.

Перегрузки.

Аппаратное обеспечение.

Контроль версий.

Документация.

Ошибки тестирования.

Подробная классификация с небольшой
правкой и моими комментариями приведена
ниже.

Ошибки пользовательского интерфейса.

Многие
из них субъективны, т.к. часто они
являются скорее неудобствами, чем
«чистыми» логическими ошибками. Однако
они могут провоцировать ошибки
пользователя программы или же замедлять
время его работы до неприемлемой
величины. В результате чего мы будем
иметь ошибки информационной системы
(ИС) в целом. Основным источником таких
ошибок является сложный компромисс
между функциональностью программы и
простотой обучения и работы пользователя
с этой программой. Проблему надо начинать
решать при проектировании системы на
уровне ее декомпозиции на отдельные
модули, исходя из того, что вряд ли
удастся спроектировать простой и удобный
пользовательский интерфейс для модуля,
перегруженного различными функциями.
Кроме того, необходимо учитывать
рекомендации по проектированию
пользовательских интерфейсов, например
[7]. В этой книге приводятся простые
модели проверки качества интерфейса,
которые можно использовать на стадии
его проектирования. На этапе тестирования
ПО полезно предусмотреть встроенные
средства тестирования, которые бы
запоминали последовательности действий
пользователя, время совершения отдельных
операций, расстояния перемещения курсора
мыши. Кроме этого возможно применение
гораздо более сложных средств
психо-физического тестирования на этапе
тестирования интерфейса пользователя,
которые позволят оценить скорость
реакции пользователя, частоту этих
реакций, утомляемость и т.п. Необходимо
отметить, что такие ошибки очень критичны
с точки зрения коммерческого успеха
разрабатываемого ПО, т.к. они будут в
первую очередь оцениваться потенциальным
заказчиком.

Ошибки функциональности.

«Если с помощью программы трудно,
неудобно или невозможно выполнить
что-то, чего может обоснованно ожидать
от нее пользователь, значит, в ней имеется
функциональная ошибка». Очень расплывчатое
определение, хотя возможно, что и верное.
Как уже отмечалось, авторы книги [5]
предполагают наличие ошибок в спецификации
программы. Авторы подразделяют ошибки
функциональности, однако трудно провести
грань между функциональными и другими
видами ошибок.

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

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

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

Пропущенная функция. В программе
не реализована функция, предусмотренная
спецификацией.

Неверно работающая функция. Функция
работает не так, как предусмотрено
спецификацией.

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

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

Взаимодействия программы и пользователя.
Их появление возможно как в интерактивном,
так и в пакетном режимах.

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

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

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

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

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

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

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

Потери времени. Имеются в виду потери
времени из-за неудачного интерфейса
программы.

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

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

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

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

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

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

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

Кто здесь главный? В этом пункте
авторы работы [5] опять возвращаются к
ошибкам в сообщениях программ и
недостаткам команд. Получился как бы
еще один раздел «Разное», который
включает следующие ошибки: навязывание
ненужных ограничений, дружественность
к новичкам, создающая неудобства для
опытных пользователей, навязчивая
предупредительность и неудачная попытка
сделать программу интеллектуальной,
запрос информации без необходимости,
ненужное повторение действий, ненужные
ограничения.

Производительность. Авторы отмечают
существование нескольких трактовок
этого понятия: 1) скорость программы, 2)
производительность работы пользователя,
3) субъективное восприятие пользователем
характеристик производительности
программы. В связи с этим возможна
ситуация, когда высокоскоростная
программа с неудачным пользовательским
интерфейсом кажется медленнее, чем на
самом деле. Какая-то логика в этом
безусловно есть, но представляется
более правильным разделить производительность
программы при решении ее основных
функциональных задач, которая в
большинстве случаев не зависит от
пользователей и может быть точно
замерена, и производительность
непосредственно интерфейса. При всей
субъективности этой характеристики
она может быть оценена на стадии
разработки интерфейса, а затем и измерена
специальными средствами.

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

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

Обработка ошибок.

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

Выделяются подпункты:

неверное начальное состояние;

неадекватная проверка пользовательского
ввода;

неадекватная защита от испорченных
данных;

не выполнена проверка переданных
параметров;

недостаточная защита от ошибок
операционной системы;

не выполняется проверка версии;

недостаточная защита от неправильного
использования («защита от дурака»).

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

Выделяются подпункты:

переполнение;

невозможные значения;

непроверенные данные;

флаги ошибок;

аппаратные сбои;

сравнение данных;

восстановление после ошибок;

автоматическое исправление ошибок;

отсутствие сообщения об ошибке;

не установлен флаг ошибки;

куда возвращается управление? (Ошибки
передачи управления после сбоя);

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

обработка аппаратных отказов;

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

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

Выделяют следующие типы таких ошибок:

неправильная обработка граничного
значения;

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

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

Выделяются следующие подпункты:

числовые ограничения;

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

количественные ограничения;

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

ограничения времени (имеются в виду
вопросы, связанные с поведением системы
на границах заданных в программе
временных интервалов);

условия циклов;

ограничения объема памяти;

ограничения, связанные со структурой
данных;

ограничения, связанные с аппаратным
обеспечением;

невидимые границы.

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

Ошибки вычислений.

Авторы работы [5] выделяют следующие
причины возникновения таких ошибок:

неверная логика (может быть следствием,
как ошибок проектирования, так и
кодирования);

неправильно выполняются арифметические
операции (как правило – это ошибки
кодирования);

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

Выделяются подпункты:

устаревшие константы;

ошибки вычислений;

неверно расставленные скобки;

неправильный порядок операторов;

неверно работает базовая функция;

переполнение и потеря значащих разрядов;

ошибки отсечения и округления;

путаница с представлением данных;

неправильное преобразование данных из
одного формата в другой;

неверная формула;

неправильное приближение.

Начальное и последующие состояния
(Ошибки инициализации).

Представляется не очень обоснованным
их выделение в самостоятельный раздел,
хотя они важны.

Выделяются подпункты:

не присвоены начальные значения;

не инициализирована переменная,
управляющая циклом;

не инициализирован указатель;

не очищена строка;

не инициализированы регистры;

не сброшен флаг;

данные должны были инициализироваться
в другом месте;

не выполнена повторная инициализация;

предположение (не верное), что данные
не были инициализированы;

путаница со статическими и динамическими
переменными;

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

ошибочная инициализация;

зависимость от инструментальных средств,
которых может не быть.

Ошибки управления потоком.

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

Выделяются подпункты:

очевидно неверное поведение программы;

переход по GOTO;

логика, основанная на определении
вызывающей подпрограммы;

использование таблиц переходов;

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

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

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

путаница имен переменных и команд;

неверное предположение о состоянии
программы или данных после вызова;

обработка ошибок выполнения процедур
(имеются в виду ошибки, когда программист
не предусмотрел такую обработку);

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

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

завершение работы программы;

«зависание» компьютера;

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

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

неверный приоритет пользователя или
процесса;

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

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

Ошибки обработки или интерпретации
данных.

Выделяются подпункты:

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

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

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

Ситуация гонок.

Выделяются подпункты:

гонки при обновлении данных;

предположение, что одно задание завершится
до начала другого;

предположение, что в течение определенного
короткого интервала времени не будет
ввода данных;

предположение, что в течение определенного
короткого интервала времени не будет
прерываний;

ресурс только что стал недоступен;

предположение, что человек, устройство
или процесс ответят быстро;

реальный набор опций в процессе
перерисовки экрана;

задание начинается до того, как выполнены
подготовительные действия;

сообщения приходят одновременно или
не в том порядке, в котором они были
отправлены.

Повышенные нагрузки.

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

требуемый ресурс недоступен;

не освобожден ресурс;

нет сигнала об освобождении устройства;

старый файл не удален с накопителя;

системе не возвращена неиспользуемая
память;

лишние затраты компьютерного времени;

нет свободного блока памяти достаточного
размера;

недостаточный размер буфера ввода или
очереди;

не очищен элемент очереди, буфера или
стека;

потерянные сообщения;

снижение производительности;

повышение вероятности ситуационных
гонок;

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

не распознается сокращенный вывод
другого процесса при повышенной загрузке;

не приостанавливаются задания с низким
приоритетом;

задания с низким приоритетом вообще не
выполняются.

В этом разделе хотелось бы обратить
внимание на следующее:

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

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

Аппаратное обеспечение.

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

неверное устройство;

неверный адрес устройства;

устройство недоступно;

устройство возвращено не в тот пул;

данному пользователю или программе
использование устройства запрещено;

данный уровень привилегий не позволяет
получить доступ к устройству;

шумы;

прерывание связи;

проблемы тайм-аута;

неверный накопитель;

не проверяется содержимое текущего
диска;

не закрыт файл;

неожиданный конец файла;

ошибки, связанные с длиной файлов и
дисковыми секторами;

неверный код операции или команды;

неверно интерпретирован код состояния
или возврата;

ошибка протокола обмена с устройством;

неполное использование возможностей
устройства;

игнорирование или неправильно используется
механизм страничного управления памятью;

игнорирование ограничений канала;

предположения о наличии или отсутствии
устройства или его инициализации;

программируемые функциональные клавиши.

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

Контроль версий и идентификаторов.

Выделяются подпункты:

таинственным образом появляются старые
ошибки;

обновление не всех копий данных или
программных файлов;

отсутствие заголовка;

отсутствие номера версии;

неверный номер версии в заголовке
экрана;

отсутствующая или неверная информация
об авторских правах;

программа, скомпилированная из архивной
копии, не соответствует проданному
варианту;

готовые диски содержат неверный код
или данные.

Ошибки тестирования.

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

пропущенные ошибки в программе;

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

пропуск ошибок на экране;

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

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

не описаны временные зависимости
появления ошибок;

слишком сложный тест (не позволяет
ошибку и добиться ее воспроизведения);

преувеличения;

личные выпады.

Ошибка выявлена и забыта.

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

не составлен итоговый отчет;

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

не проверено исправление;

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

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