Что такое первичная ошибка в программе

Тема Основные направления протестантской богословской мысли в ХХ1. Курсовая. Принципы административного судопроизводства. .docxЗадание к теме №6_ Основные требования, оформлению и защите научЭссе по теме Введение, определение истории медицины, основные цеОсновные принципы стандартизации.docНазначение и основные функции ОС.docxПонятие государства основные подходы и определения — StudentLib.Л-5 — Основные достижения различных направлений институциональноРоссия в современном мире. Основные направления социально-экономОрганизационное изменение основные источники и механизмы.docx

поддержка поставок и жизненного цикла изделий

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

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

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

Основные принципы CALS-технологий базируются на контроле и организации этапов существования продукции. К ним относят:

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

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

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

Перспективы применения CALS на промышленных предприятиях

• Значительно увеличить уровень кооперации различных производств за счет однородных стандартов обработки информации;
• Снизить влияние территориального расположения предприятий и тем самым ограничить влияние расстояний на эффективность взаимодействия;
• Создать виртуальные элементы производств, позволяющих контролировать процессы проектирования, производства и эксплуатации изделий на уровне отдельных практических задач;
• Защитить результаты работы на основе преемственности результатов работы на всех этапах жизненного цикла продукции;
• Оптимизировать затраты за счет снижения бумажных составляющих документооборота;
• Использовать «прозрачность» процессов управления и контроля, благодаря разработке интегрированных моделей;
• Создать мощную информационную поддержку всех этапов цикла производства;
• Создать общую систему стандартизации информации об изделии;
• Обеспечить требуемый уровень качества продукции.

являются цифровые методы проектирования производств, поддерживающие контроль жизненного цикла продукции (Product LifecycleManagement) — так называемые PLM-системы. К ним относят следующие классы систем:

• CAD – (Computer Aided Design) – решение задач проектирования изделий и элементов; моделирование объектов на плоскости (2D-модель) и в пространстве (3D-модель); средства получения чертежей; архивы данных по элементам конструкций и создание шаблонов документов.
• CAE – (Computer Aided Engineering) – исследование свойств объектов (при изготовлении и эксплуатации); создание проверочных систем анализа объекта по разработанной модели; оптимизация параметров объекта по заданным условиям и ограничениям.
• CAM — (Computer Aided Manufacturing) – программирование контроллеров станков с ЧПУ; исследование вариантов траектории инструмента по алгоритмам обрабатываемой поверхности; анализ геометрических конфликтов; подгонка к оборудованию.
• PDM — (Product Data Management) — хранение данных и контроль документации; создание архива образцов; обеспечение доступа к информации и ее защита.

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

Еще одной важной функцией вычислительных методов является управление различными ресурсами и потоками предприятия в реальном времени — материально-техническими, финансовыми, процессами складирования, персоналом, планированием и сбытом продукции. Системы, реализующие выполнение перечисленных задач относятся к ERP-системам (Enterprise Resource Planning − управление ресурсами предприятия).

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

К типовым функциям данного класса программных продуктов относят:

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

2 Первичные ошибки, вторичные ошибки и их проявления

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

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

Распределение выявленных ошибок

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

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

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

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

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

• системные ошибки;
• ошибки в выборе алгоритма;
• алгоритмические ошибки;
• технологические ошибки;
• программные ошибки.

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

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

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

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

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

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

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

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

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

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

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

Технологические ошибки — это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором).

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

курс лекций.pdfЗачет по дисциплине просмотр попытки.pdfОчно-заочное ЗАДАНИЕ №2 К СЕМИНАРУ №1 по дисциплине Философия.doОпорный конспект разговора о ценности общественного согласия.pdfЗадание к семинару №2 по дисциплине Общая психология.docxРеферат по дисциплине Финансы на тему _Виды финансовых ресурсов,План конспект Презентация «Подросток и Закон» 12.01.2023.docПлан конспект Беседа «Один дома» 16.01.2023.docПлан конспект Беседа «Родники России» 05.02.2023.docЗадание к семинару №1 по дисциплине Психология общения.docx

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

результате интенсивность проявления ошибок при реальном функционировании программ зависит от среднего быстродействия ЭВМ и практически не зависит от конкретного распределения типов команд на маршрутах обработки данных между ошибками. Коллектив специалистов, их квалификация и загруженность предполагаются постоянными на интервале проектирования и исследования характеристик ошибок. Также постоянным считается доступное машинное время для проведения проверок программ. Вторая группа допущений при построении математических моделей ошибок является основной и проверена интегрально по обобщенным характеристикам частости обнаружения ошибок и дифференцирование путем анализа правомерности каждого допущения. Ниже рассмотрены допущения при построении экспоненциальной модели. Интервалы времени между обнаруживаемыми искажениями результатов предполагаются статистически независимыми. Время измеряется по фактической наработке длительностей исполнения программ  без учета дополнительных затрат календарного времени на локализацию, диагностику и исправление ошибок. Предполагается, что интенсивность проявления ошибок остается постоянной, пока не произведено исправление первичной ошибки или не изменена программа по другой причине. Если каждая обнаруженная ошибка исправляется, то значения интервалов времени между их проявлениями изменяются по экспоненциальному закону. Интегральная проверка распределения интервалов времени между обнаружениями ошибок показала, что оно достаточно хорошо аппроксимируется экспонентой. Логично предположить, что интенсивность обнаружения ошибок пропорциональна суммарному числу первичных ошибок, имеющихся в данный момент в комплексе программ. Это допущение подтверждено расчетом значений суммарного числа ошибок для хорошо отлаженных и переданных в эксплуатацию комплекса программ на ряд предыдущих моментов времени, когда проводилась отладка. Каждая обнаруженная ошибка подлежит исправлению, поэтому предполагается, что частота исправления ошибок пропорциональна частоте их обнаружения. Однако некоторые исправления, в свою очередь, содержат ошибки. Кроме того, некоторые ошибки являются связанными, и при обнаружении проявления одной ошибки следует исправление нескольких первичных ошибок. Из-за этого частота обнаружения ошибок и частота их исправления не равны, а должны быть связаны некоторым коэффициентом пропорциональности. Коэффициенты корреляции для исследованных комплексов программ довольно высокие — от 0,52 до 0,82 при среднем значении около 0,68, т. е. достаточно хорошо подтверждают гипотезу. группа допущений детализирует использование ресурсов на корректировку программ и повышение их качества. Приведенные предположения позволяют построить экспоненциальную математическую модель распределения моментов обнаружения ошибок в программах и установить связь между интенсивностью обнаружения ошибок при отладке dn/d, интенсивностью проявления ошибок при нормальном функционировании программ  и числом первичных ошибок п. Предположим, что в начале отладки комплекса программ при =0 в нем содержалось N0 первичных ошибок. После отладки в течение времени осталось п0 первичных ошибок и устранено п ошибок (n0 + n = N0). Время  соответствует длительности исполнения программы на ЭВМ для обнаружения ошибок и не учитывает время, необходимое для анализа результатов и проведения корректировок. Календарное время к отладочных и испытательных работ с реальным комплексом программ значительно больше, так как после тестирования программ, на которое затрачивается машинное время т, необходимо время на анализ результатов, на обнаружение и локализацию ошибок, а также на их устранение. При постоянных усилиях на отладку интенсивность обнаружения искажений вычислительного процесса, программ или данных вследствие еще не выявленных ошибок

пропорциональна количеству оставшихся первичных ошибок в комплексе программ. Предположение о сильной корреляции между значениями по и dn/d проверено анализом реальных характеристик процесса обнаружения ошибок. Тогда (11.1)_ где коэффициенты К и К’ учитывают масштаб времени, используемый для описания процесса обнаружения ошибок, быстродействие ЭВМ и другие параметры. Значение коэффициента К’ можно определить как изменение темпа проявления искажений при переходе от функционирования программ на специальных тестах к функционированию на типовых исходных данных. В начале отладки это различие может быть значительным, однако при завершении отладки и при испытаниях тестовые данные практически совпадают с исходными данными при нормальной эксплуатации. Поэтому ниже К’ полагается равным единице (К’=1). Таким образом, интенсивность обнаружения ошибок в программе и абсолютное число устраненных первичных ошибок связываются уравнением Так как выше предполагалось, что в начале отладки при = 0 отсутствуют обнаруженные ошибки, то решение уравнения (11.2) имеет вид (11.3) пропорционально интенсивности их обнаружения dn/d с точностью до коэффициента К. Наработка между проявлениями ошибок, которые, рассматриваются как обнаруживаемые искажения программ, данных или вычислительного процесса, равны величине, обратной интенсивности обнаружения ошибок: Если учесть, что до начала отладки в комплексе программ содержалось N0первичных ошибок и этому соответствовала наработка T0 , то функцию наработки между проявлениями ошибок от длительно- Если известны все моменты обнаружения ошибок ti и каждый раз в эти моменты обнаруживается и достоверно устраняется одна первичная ошибка, то, используя метод максимального правдоподобия, получим уравнение для определения значения начального количества первичных ошибок N0(11.6) и выражение для расчета коэффициента пропорциональности (11.7) Необходимые для расчетов К и N0 экспериментальные значения ti определяются в процессе отладки данного или аналогичных комплексов программ, созданных тем же коллективом разработчиков и при такой же технологии. В результате можно рассчитать

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

— использование таблиц переходов; — выполнение данных (вместо команд). Ситуация возможна из-за ошибок работы с указателями, отсутствия проверок границ массивов, ошибок перехода, вызванных, например, ошибкой в таблице адресов перехода, ошибок сегментирования памяти. 4. Ошибки обработки или интерпретации данных. Выделяются подпункты: — проблемы при передаче данных между подпрограммами (сюда включены несколько видов ошибок: параметры указаны не в том порядке или пропущены, несоответствие типов данных, псевдонимы и различная интерпретация содержимого одной и той же области памяти, неправильная интерпретация данных, неадекватная информация об ошибке, перед аварийным выходом из подпрограммы не восстановлено правильное состояние данных, устаревшие копии данных, связанные переменные не синхронизированы, локальная установка глобальных данных (имеется в виду путаница локальных и глобальных переменных), глобальное использование локальных переменных, неверная маска битового поля, неверное значение из таблицы); — границы расположения данных (сюда включены несколько видов ошибок: не обозначен конец нуль-терминированной строки, неожиданный конец строки, запись/чтение за границами структуры данных или ее элемента, чтение за пределами буфера сообщения, чтение за пределами буфера сообщения, дополнение переменных до полного слова, переполнение и выход за нижнюю границу стека данных, затирание кода или данных другого процесса); — проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных). 5. Повышенные нагрузки. При повышенных нагрузках или нехватке ресурсов могут возникнуть дополнительные ошибки. Выделяются подпункты: требуемый ресурс недоступен; не освобожден ресурс; нет сигнала об освобождении устройства; старый файл не удален с накопителя; системе не возвращена неиспользуемая память; лишние затраты компьютерного времени; нет свободного блока памяти достаточного размера; недостаточный размер буфера ввода или очереди; не очищен элемент очереди, буфера или стека; потерянные сообщения; снижение производительности; повышение вероятности ситуационных гонок; при повышенной нагрузке объем необязательных данных не сокращается; не распознается сокращенный вывод другого процесса при повышенной загрузке; не приостанавливаются задания с низким приоритетом. В этом разделе хотелось бы обратить внимание на следующее: 1) Часть ошибок из этого раздела могут проявляться и при не очень высоких нагрузках, но, возможно, они будут проявляться реже и через более длительные интервалы времени; 2) Многие ошибки из 2-х предыдущих разделов уже в своей формулировке носят вероятностный характер, поэтому следует предположить возможность использования вероятностных моделей и методов для их выявления. 6. Контроль версий и идентификаторов. Выделяются подпункты: таинственным образом появляются старые ошибки; обновление не всех копий данных или программных файлов; отсутствие заголовка; отсутствие номера версии; неверный номер версии в заголовке экрана; отсутствующая или неверная информация об авторских правах; программа, скомпилированная из архивной копии, не соответствует проданному варианту; готовые диски содержат неверный код или данные.

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