Тестирование инф.систем. Ответы на вопросы к лекциям Понятие тестирования программного обеспечения
 Скачать 0.52 Mb.
|
|
Ответы на вопросы к лекциям Понятие тестирования программного обеспечения 1. Какие исторические примеры серьезных программных ошибок, которые привели к финансовым потерям и/или человеческим жертвам, вам известны? Therac-25 представлял собой компьютеризированную машину для радиационной терапии, построенную компанией Atomic Energy of Canada Limited (AECL). Therac-25 был усовершенствованием Therac-20. Он был способен испускать фотоны или электроны с энергией 25 МэВ с возможностью переключения уровней. Он был меньше, имел больше возможностей и был легче в использовании. Также он был сконструирован так, чтобы компьютерное управление было более полным, чем в его предшественниках. Программное обеспечение, разработанное для Therac-25, было способно осуществлять контроль состояния и управление оборудованием. Поэтому решено было удалить аппаратные средства безопасности и полагаться в этом вопросе на программное обеспечение. Therac-25 поступил в продажу в конце 1982 года, и 11 таких машин были установлены в Северной Америке, 5 - в США и 6 - в Канаде. Шесть несчастных случаев с большими передозировками произошли между 1985 и 1987 годами. В июне 1985 года в г. Кенстоун, округ Мариетта, штат Джорджия женщина в возрасте 61 года была направлена в онкологический центр для дополнительного лечения аппаратом Therac-25 после хирургического удаления молочной железы. Как считается, пациентка получила одну или две дозы радиации от 15 000 до 20 000 рад (поглощенная доза радиации). Для сравнения, типичная разовая терапевтическая доза радиации составляет до 200 рад. Кенстоунская клиника использовала Therac-25 с 1983 года без происшествий. Техники и фирма AECL не поверили, что эта проблема может быть вызвана Therac-25. В конечном итоге пациентка потеряла грудь, а также возможность пользоваться руками и плечами из-за радиационного поражения. Клиника в Хэмилтоне использовала Therac-25 в течение шести месяцев до инцидента с передозировкой. Сорокалетняя женщина поступила в клинику на 24-й сеанс лечения аппаратом Therac-25. Аппарат отключился через пять секунд после того, как оператор запустил его. Операторы были знакомы с частыми неполадками машины. Эти неполадки, вероятно, не имели серьезных последствий для пациента. Поскольку машина показывала, что облучение не было произведено, оператор попытался повторить его. Были произведены пять попыток. После пятой попытки был вызван техник, не обнаруживший проблем в аппарате. Об инциденте сообщили в AECL, но воспроизвести неполадку и сделать заключение о причинах такого поведения Therac-25 не удалось. Однако благодаря этому сообщению фирма AECL обнаружила некоторые слабости конструкции и потенциальные механические проблемы в позиционировании поворотной платформы Therac-25 и были сделаны исправления. Пациентка умерла через пять месяцев. Результаты вскрытия показали, что смерть наступила от рака, а не от передозировки радиации. Однако вскрытие также выявило серьезные поражения бедра, вызванные радиационным воздействием. Как было позже определено, пациентка получила дозу порядка 13 000 - 17 000 рад. За короткую жизнь Therac-25 было обнаружено два программных дефекта: логическая ошибка в обновлении параметров, когда оператор менял состояние машины; проверка безопасности не срабатывала, когда 8-битный счетчик переполнялся и достигал нуля каждые 256 итераций. Однако с точки зрения безопасности систем самое уязвимое место - это доверие к программному обеспечению. Очевидно, что тот же дефект, который вызвал передозировки в Therac-25, присутствовал и в Therac-20. Та же ошибка в Therac-20 приводила к отключению машины без передозировки, поскольку в Therac-20 применялись независимые аппаратные устройства безопасности, которые предотвращали ее. Ошибки, связанные с зависимостью от скорости, очень трудно обнаружить и воспроизвести. В первом случае две причины точно должны были присутствовать, чтобы активировать ошибку: 1) оператор должен сделать изменения в параметрах режима и уровня энергии; 2) оператор должен сделать изменения в течение восьми секунд. В случае второго дефекта все зависит от случайности. Ошибка активируется, если клавиша нажимается в тот момент, когда счетчик достигает нуля. Вот почему, несмотря на врожденный дефект в продукте, было отмечено только шесть несчастных случаев. Если бы ошибка была более явной и ее было бы легче запустить, несомненно, она была бы выявлена на AECL в ходе обычных процедур тестирования и проверки качества, и тогда о ней никогда не узнало бы общество. Если ошибку трудно активировать, ее также трудно будет выявить в ходе обычного процесса тестирования. Трудно найти ошибки, если не можешь их воспроизвести. Ракета-носитель Ariane 5 была ответом попыткам Европейского космического агентства (European Space Agency) стать лидером в запусках ракет на коммерческом космическом рынке. Стоившая 7 миллиардов долларов и строившаяся в течение 10 лет, Arian 5 могла вывести на орбиту два трехтонных спутника.При своем первом полете ракета Ariane 5 взорвалась через 40 секунд послестарта утром 4 июня 1996 года. Анализ данных полета быстро показал, что ракета вела себя нормально до того момента, когда она вдруг отклонилась от курса и самоуничтожилась. Погода в то утро была приемлемой, так что она не могла оказать влияние. Полетные данные также показывали, что активная система и первичная Инерционная система ориентировки (Inertial Reference System), которые влияли на управление соплами твердотопливного ускорителя, более или менее одновременно отказали прямо перед разрушением ракеты. После инцидента была сформирована комиссия по его расследованию. Комиссия для решения своей задачи располагала телеметрическими данными ракеты, данными о траектории с радиолокационных станций, оптическими наблюдениями ракеты и упавших обломков и восстановленной Инерционной системой ориентировки. Кроме того, комиссия располагала отдельными компонентами ракеты и системами программ, использованных в ней, для тестирований и осмотра. Получив эту информацию, комиссия смогла реконструировать последовательность событий 4 июня 1996 года. 1. Программный модуль, в котором в итоге возникла ошибка, был унаследован от ракеты-носителя Arian 4. Этот модуль производил выравнивание инерционной платформы для того, чтобы оценить точность измерений, проведенных Инерционной системой ориентировки. После старта данный модуль более не служил в Ariane 5 никаким целям. Однако в Ariane 4 этот модуль работал в течение еще полных 50 секунд. Начальная часть траектории полета Ariane 5 существенно отличалась от траектории Ariane 4, и этот программный модуль никогда соответствующим образом не тестировался. 2. Вскоре после старта ошибочный программный модуль попытался посчитать значение, основанное на горизонтальной скорости ракеты. Поскольку для Ariane 5 это значение было существенно больше, чем то, которое ожидалось для Ariane 4, возникла ошибка и на активной, и на запасной Инерционной системе ориентировки. Допустимость такого преобразования не была проверена, поскольку ожидалось, что такого никогда не случится. 3. Спецификация обработки ошибок в системе указывала, что контекст ошибок должен быть сохранен в постоянной памяти (ПЗУ) до отключения процессора. После ошибки операнда Инерционная система ориентировки сохранила контекст ошибки, как было установлено. Эти данные были прочитаны бортовым компьютером. На основе этих данных компьютер отдал команду соплам твердотопливного ускорителя и главному двигателю. Команда требовала полного отклонения сопел, что вызвало то, что ракета вышла на запредельную траекторию. 4. На новой траектории ракета подверглась запредельной аэродинамической нагрузке и начала разрушаться. Стартовые двигатели отделились от ракеты, что запустило ее самоуничтожение. Несомненно, глупая ошибка, но интересен такой вопрос: как эта ошибка миновала стадию тестирования? В аэрокосмической индустрии обычно строгие стандарты и скрупулезные процессы и процедуры, направленные на проверку безопасности из-за высокой цены ошибок. Комиссия по расследованию задала тот же вопрос, и команда обслуживания Ariane 5 представила следующие объяснения: команда Ariane 5 решила не защищать некоторые переменные от возможной ошибки операнда, поскольку они считали, что значения этих переменных либо ограничены физическими факторами, либо имеют существенный запас по максимальной величине; команда Ariane 5 решила не включать данные о траектории в функциональные требования для Инерционной системы ориентировки. Следовательно, данные о траектории Ariane 5 не использовались при тестировании; из-за физических законов трудно осуществить реалистичный полетный тест Инерционной системы ориентировки. При функциональном имитационном тестировании полетных программ было решено не включать в тест эту систему главным образом по той причине, что она должна быть проверена при тестировании аппаратного уровня, а также потому, что было бы трудно достигнуть необходимой точности при имитационном тестировании, если бы была использована реальная Инерционная система ориентировки. 2. В каком случае труднее всего найти ошибки? Ошибки, связанные с зависимостью от скорости, очень трудно обнаружить и воспроизвести. В первом случае две причины точно должны были присутствовать, чтобы активировать ошибку: 1) оператор должен сделать изменения в параметрах режима и уровня энергии; 2) оператор должен сделать изменения в течение восьми секунд. В случае второго дефекта все зависит от случайности. Ошибка активируется, если клавиша нажимается в тот момент, когда счетчик достигает нуля. Вот почему, несмотря на врожденный дефект в продукте, было отмечено только шесть несчастных случаев. Если бы ошибка была более явной и ее было бы легче запустить, несомненно, она была бы выявлена на AECL в ходе обычных процедур тестирования и проверки качества, и тогда о ней никогда не узнало бы общество. Если ошибку трудно активировать, ее также трудно будет выявить в ходе обычного процесса тестирования. Трудно найти ошибки, если не можешь их воспроизвести. 3. Что может служить показателем качества программного обеспечения? Тестирование программного обеспечения представляет собой один из возможных способов оценки его качества. Показателями качества могут служить количество найденных дефектов, их критичность, распределение дефектов по модулям и компонентам тестируемой системы и т.д. Если найденные в процессе тестирования дефекты исправляются, то качество программного обеспечения повышается. Однако исправление одного дефекта может порождать новые дефекты, еще более критичные, трудновоспроизводимые. В таком случае динамика изменения показателей качества в общем итоге может дать отрицательную картину. 4. Что может свидетельствовать о повышении качества программного обеспечения? Согласно стандартному глоссарию терминов, используемых в тестировании программного обеспечения, тестирование – это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. 5. К каким последствиям может привести исправление дефектов? Если найденные в процессе тестирования дефекты исправляются, то качество программного обеспечения повышается. Однако исправление одного дефекта может порождать новые дефекты, еще более критичные, трудновоспроизводимые. В таком случае динамика изменения показателей качества в общем итоге может дать отрицательную картину. 6. Какие активности включает в себя тестирование? • планирование, • управление, • подготовку тестовых данных и выбор условий, • разработку и выполнение тестовых сценариев, • проверку результатов, • оценку критериев выхода, • создание отчетов о процессе тестирования. Существуют различные принципы тестирования, но, в качестве основных можно назвать следующие семь: 1) тестирование показывает наличие дефектов, но не доказывает, что их нет. Вероятность наличия дефектов снижается, но отсутствие дефектов не доказывает абсолютную корректность программного обеспечения; 2) тестирование необходимо начинать как можно раньше в жизненном цикле разработки системы. Тестирование не может быть бесцельным. У каждой активности необходимо определить четкую цель; 3) полное или исчерпывающее тестирование невозможно, т.к. существует огромное количество комбинаций, предусловий, постусловий и т.д. Чтобы наиболее четко определить, как и что необходимо тестировать, применяется анализ рисков, расстановка приоритетов, оценка критичности функционала; 4) парадокс пестицида – один из самых известных принципов, который означает, что многократный прогон одних и тех же тестов при соблюдении одинаковых условий неэффективен. Такие тесты перестают находить дефекты, но это не означает, что их нет. Тесты должны наиболее полно охватывать систему, а для этого они должны быть разноплановыми, разносторонними. Написание тестов – творческая задача. Каждый тест может найти большое количество дефектов, если написан грамотно и продуманно; 5) дефекты скапливаются в небольшом количестве модулей, на которых, в конечном счете, необходимо сосредоточить основные усилия по тестированию; 6) тестирование напрямую зависит от объекта, который подвергается испытаниям. Прежде чем начать тестирование, нужно изучить систему и понять наиболее критичные и уязвимые места, важность тех или иных функций для пользователей; 7) заблуждение об отсутствии ошибок в системе. Данный принцип состоит в том, что, если система не подходит пользователю и изначально была спроектирована неверно, то она не сможет удовлетворить потребности, даже если масса дефектов были обнаружены и устранены. 7. Для чего может использоваться содержащаяся в дефектах информация? Обнаруживая и исправляя дефекты мы, тем самым, повышаем уровень качества программного продукта. Кроме того, информация, содержащаяся в дефектах, является базой для формирования представления об уровне качества программы, а, следовательно, на основании такой информации можно принимать управленческие решения. 8. Какие цели преследует тестирование? Первая и самая очевидная цель данного процесса – это выявление дефектов. Т.к. дефекты в процессе тестирования могут обнаруживаться не только в программе, но и в документации, которая также подвергается проверке, то следующей целью тестирования является предотвращение дефектов. Чем раньше обнаруживается дефект, тем дешевле его исправление и тем меньше последствий он несет как для компании-разработчика, так и для непосредственного пользователя продукта. 9. Возможно ли исчерпывающее тестирование? Почему? Исчерпывающие тестирование невозможно. ПО можно проверить на 100% только в двух случаях: есть неограниченные ресурсы, тривиальный функционал. Главный ресурс, которого часто не хватает - это время. Далее следует нехватка тестировщиков. А потом начинается нехватка тестовых девайсов, отсутствие или проблемы с коммуникациями и т.п. В условиях нехватки ресурсов важно грамотно расставлять приоритеты и планировать тестирование. 10. В чем состоит парадокс пестицида? тестирование зависит от контекста (Testing is context dependent) Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Тестирование демонстрирует наличие дефектов. О чём принцип: Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. На этот принцип довольно часто плюют с высоты бизнеса и проджект менеджмента. 11. Как в большинстве случаев распределены дефекты внутри программной В первом случае две причины точно должны были присутствовать, чтобы активировать ошибку: 1) оператор должен сделать изменения в параметрах режима и уровня энергии; 2) оператор должен сделать изменения в течение восьми секунд. В случае второго дефекта все зависит от случайности. Ошибка активируется, если клавиша нажимается в тот момент, когда счетчик достигает нуля. Вот почему, несмотря на врожденный дефект в продукте, было отмечено только шесть несчастных случаев. системы? 12. Для чего необходим анализ рисков? При тестировании программного обеспечения анализ рисков - это процесс выявления рисков в приложениях или программном обеспечении, которые вы создали, и определения их приоритетности для тестирования. После этого завершается процесс присвоения уровня риска. Происходит категоризация рисков, следовательно, рассчитывается влияние риска. 13. От чего в большей степени зависит тестирование? Перечислим классические программные ошибки: Пользователь вбивает в поле ответ на вопрос и жмет клавишу Далее программа завершает работу, а информация не сохраняется. То же самое происходит и при следующей попытке. Пользователь играет в шутер. Вдруг персонажи начинают странно двигаться, подергиваться и т.д. Сначала программа попросту не реагирует на нажатие клавиш, а потом и вовсе выдаёт «Game over». Пользователь заходит в личный кабинет интернет-магазина и нажимает «Оплатить». Однако его перебрасывает на главную страницу. Кроме того, в аккаунт приходится заново входить. При этом не существует безошибочных программ, которые всегда выдают лишь нужные результаты. Разработчики, как правило, допускают некоторые ошибки в коде, что впоследствии усложняет пользователю процесс взаимодействия с приложением. В некоторых случаях дефекты несущественны и малозаметны, но встречаются и такие недочёты, из-за которых программа вообще не может работать. 14. Что не может доказать тестирование? Тестирование доказывает наличие багов, а не их отсутствие Задача тестирования доказать, что софт не работает. Хотя многие участники разработки ошибочно считают, что задача тестирования доказать, что ПО работает. Всегда старайся доказать точку зрения "не работает"! Для тестировщика важно не путать эти точки зрения. Как только тестировщик занимает позицию "доказать, что ПО работает", так сразу пропускает критичные баги. Тестировщик - это деструктор, т.е. разрушитель. Как только получаешь софт на тестирование сразу же попробуй его сломать. Например, у тебя сайт конвертер картинок. Сразу же загрузи большой файл, файл не поддерживаемого формата и т.п. (почитай Чек-лист тестирования: изображения). Главное помни, сначала надо начинать с позитивных кейсов, а уже потом вдоволь пройтись по негативным. 15. В каком случае тестирование оказывается бессильным заблуждение об отсутствии ошибок в системе. Данный принцип состоит в том, что, если система не подходит пользователю и изначально была спроектирована неверно, то она не сможет удовлетворить потребности, даже если масса дефектов были обнаружены и устранены. Виды тестирования Назовите основные признаки классификации видов тестирования?
В чем разница между функциональным и структурным тестированием? Функциональное тестирование (тестирование методом черного ящика, black-box testing). Функции, которые выполняет система, подсистема или компонент, могут быть описаны в таких артефактах процесса разработки как спецификация требований, сценарии использования системы или функциональная спецификация, либо могут быть недокументированны. Эти функции описывают, «что» данная система делает. Функциональные тесты разрабатываются на основе функций и возможностей системы (описанных в документах или понятных тестировщикам) и их взаимодействия со специфичными системами и могут быть выполнены на всех уровнях тестирования (например, тесты для компонентов могут основываться на спецификациях компонентов). Структурное тестирование (тестирование методом белого ящика, white-box testing) может выполняться на всех уровнях тестирования. Структурные методы тестирования лучше всего использовать после методов разработки тестов на основе спецификации, чтобы измерить тщательность тестирования, используя измерения покрытия структуры программы. Тестирование методом белого ящика еще называют «тестированием по маршрутам». Под маршрутом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных. Программный код системы в случае структурного тестирования открыт и доступен для анализа и проведения испытаний. В чем суть компонентного тестирования и каковы его основные особенности? Компонентное тестирование наиболее часто производится с доступом к программному коду, поддержкой рабочего окружения и инструментов отладки. Для реальных проектов компонентное тестирование – это уровень тестирования, который более относится к стадии разработки. Разработчик, отлаживая код, находит в нем дефекты, которые исправляются сразу без необходимости занесения их в систему отслеживания дефектов. Важно отметить, что отладка (локализация и исправление дефекта) относится к процессу разработки, а не тестирования. Таким образом, разработчик – непосредственный участник процесса тестирования, и от того, насколько качественно будет проведено модульное тестирование, во многом зависит дальнейшие стадии тестирования системы. Для чего главным образом необходимо интеграционное тестирование? Интеграционное тестирование проверяет интерфейсы между компонентами, взаимодействие различных частей системы, таких как операционная системы, файловая система, аппаратное обеспечение, и интерфейсы между системами. Разработчики рыночного, или коробочного, ПО часто хотят получить отзывы от потенциальных или существующих заказчиков до того, как начнется продажа продукта. Альфа-тестирование выполняется организацией, разрабатывающей продукт, но не группой разработчиков. Бета- тестирование, или тестирование в условиях эксплуатации, выполняется покупателями или потенциальными заказчиками на их собственных мощностях. Какой вид тестирования наиболее часто автоматизируется и почему? Регрессионное тестирование может выполняться на всех уровнях тестирования и включает функциональное, нефункциональное и структурное тестирование. Регрессионные наборы тестов запускаются множество раз и меняются медленно, поэтому регрессионное тестирование чаще все автоматизируют. В чем разница между альфа- и бета-тестированием? Альфа-тестирование выполняется организацией, разрабатывающей продукт, но не группой разработчиков. Бета- тестирование, или тестирование в условиях эксплуатации, выполняется покупателями или потенциальными заказчиками на их собственных мощностях Что призвано оценить тестирование совместимости? тестирование возможности взаимодействия (тестирование совместимости), оценивает способность программного продукта взаимодействовать с одним или более указанными компонентами или системами. Что такое usability testing? Тестирование удобства использования (usability testing) – согласно ISO 9126, это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий В чем состоят особенности тестирования «на опыте»? Системное тестирование может осуществляться на базе сценариев использования и на базе требований к системе. Зная, как будет использоваться система, и имея конкретный набор вариантов использования (use cases), тестировщик разрабатывает набор тестовых сценариев для прохождения (test cases). Если набор вариантов использования отсутствует, но имеются требования к системе и ее поведению, то на основании этих требований тестировщик также может написать тестовые сценарии, проверяющие, выполняется ли конкретное требование или нет. Зачастую при написании и прохождении тестовых сценариев тестировщик прибегает не только к изучению предоставленных требований, но и к собственному опыту и здравому смыслу. Такой подход – одна из главных составляющих процесса тестирования. Данный метод носит название «тестирование, основанное на опыте». Но важно помнить, что в этом случае качество продукта будет во многом зависеть от опыта тестировщика. Что подразумевает под собой «атака на недочёты»? На основе ранее полученного опыта тестировщик может предположить, как поведет себя система в той или иной ситуации, и где стоит ожидать наибольшего количества дефектов. На основании таких знаний разрабатываются тестовые сценарии, способные выявить наиболее ожидаемые дефекты. Такой подход называют «атакой на недочеты». Какие активности включает в себя исследовательское тестирование? В такой ситуации часто прибегают к исследовательскому тестированию, которое представляет собой параллельную разработку тестов, их выполнение и изучение системы по разрабатываемым тестовым сценариям и на основе ее использования в процессе тестирования. Исследовательское тестирование может иметь место в условиях нехватки времени или применяться для проверки процесса тестирования в целом. После установки система программного обеспечения обычно находится в эксплуатации в течение многих лет. В это время сама система, ее конфигурация или среда исполнения часто изменяются или расширяются. Ранее планирование релизов крайне важно для успешного тестирования в период сопровождения. При этом необходимо отличать запланированные выпуски и срочные исправления. Когда исследовательское тестирование может быть эффективным? Исследовательское тестирование может иметь место в условиях нехватки времени или применяться для проверки процесса тестирования в целом. В чем особенности тестирования в период сопровождения? Тестирование в период сопровождения выполняется на текущей ОС и может быть вызвано модификацией, переносом или прекращением эксплуатации данной системы. Что такое системное тестирование? Системное тестирование сконцентрировано на поведении тестового объекта как целостной системы или продукта. Системное тестирование способно выявить несовместимость с окружением, некорректные комбинации данных, заведомо непредусмотренные сценарии использования, неудобство для пользователя, отсутствие необходимого пользователям функционала и т.д. Во время системного тестирования тестовое окружение должно быть как можно ближе к предполагаемому эксплуатационному окружению системы для минимизации риска пропуска отказов, связанных с эксплуатационным окружением системы. В чем разница между системным тестированием на базе сценариев использования и на базе требований? Системное тестирование – это тестирование фазы, в то время как тестирование использования методом состоит в разработке тестовых примеров на основе вариантов использования, которые могут использоваться на многих уровнях тестирования. Например: 1) В тестовом примере использования вы создаете тестовые примеры на основе случаев использования. Необходимо разработать, построить и интегрировать систему или, по крайней мере, компоненты, участвующие в данном случае использования. Можно проверить, работают ли два модуля, задействованные в данном примере использования, правильно. Таким образом, в вашем Интеграционном тесте вы готовите тестовый пример на основе варианта использования, который раскрывает сотрудничество этих двух модулей. 2) Когда вы выполняете Системные тесты, как часть их, вы можете использовать Use Case Testing – для подтверждения того, что поведение, указанное в Use Case, работает так, как должно. Но, как отметил Роберт Харви, тестирование системы – это проверка соответствия требованиям, поэтому она обеспечивает как положительное тестирование, так и отрицательное тестирование. Поэтому тестирование системы не только охватывает ожидаемое поведение, описанное в разделе “Служебные случаи”, но также пытается “разбить” систему с точки зрения специфической потребности. 3) Кроме того, следует упомянуть, что, поскольку Случаи использования содержат некоторые ожидаемые действия пользователя, они делают хорошую отправную точку для Тестирования приёма пользователей. С другой стороны, поскольку пользователь не хочет проверять использование в режиме входа в систему, а скорее является входом в систему и делает некоторые вещи и замечает некоторые эффекты, входящие в их бизнес-процесс, так что просто проверять Use Cases недостаточно. Случаи использования. Некоторая отправная точка, но UAT обычно требует, чтобы тесты шли глубже в процесс buisness, который должен поддерживать программное обеспечение. |