Основы стандартизации ПОИТ ч4. Руководство для студентов специальности i40 01 01 Программное обеспечение информационных технологий
 Скачать 460 Kb.
|
1.4 Виды тестирования программного обеспечения1.4.1 Функциональные виды тестированияВсе виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы: 1) функциональные; 2) нефункциональные; 3) связанные с изменениями. Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены самые распространенные виды функциональных тестов: функциональное тестирование (Functional testing); тестирование безопасности (Security and Access Control Testing); тестирование взаимодействия (Interoperability Testing). Функциональное тестирование. Этот вид тестирования проверяет соответствие реализованных функций требованиям, техническому заданию, спецификациям, различным другим проектным документам и просто ожиданиям пользователя. Проверяется каждая из функций приложения и все они в комплексе. Исследуются все сценарии использования. Проверяется адекватность хранимых и выходных данных, методы их обработки, обработка вводимых данных, методы хранения данных, методы импорта и экспорта данных и т.д. в зависимости от специфики приложения. Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases). Тестирование функциональности может проводиться в двух аспектах: «требования»; «бизнес-процессы». Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал. Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases). Преимущества функционального тестирования: имитирует фактическое использование системы. Недостатки функционального тестирования: возможность упущения логических ошибок в программном обеспечении; вероятность избыточного тестирования. Достаточно распространенной является автоматизация функционального тестирования. Тестирование безопасности. Стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Тестирование безопасности может выполняться как автоматизированно так и в ручную, включая проверку как позитивных, так и негативных тестовых случаев. Основывается на трех основных принципах – это конфиденциальность, целостность и доступность (confidentiality, integrity, availability) Конфиденциальность – это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей, или другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу. Существует два основных критерия при определении понятия целостности: 1. Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей. 2. Повреждение и восстановление. В случае, когда данные повреждаются или неправильно меняются авторизованным или не авторизованным пользователем, необходимо определить на сколько важной является процедура восстановления данных. Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть. Тестирование взаимодействия. С развитием сетевых технологий и интернета взаимодействие разных систем, сервисов и приложений друг с другом приобрело значительную актуальность, так как любые связанные с этим проблемы могут привести к падению авторитета компании, что как следствие повлечет за собой финансовые потери. Поэтому к тестированию взаимодействия стоит подходить со всей серьезностью. Тестирование взаимодействия – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing). Программное обеспечение с хорошими характеристиками взаимодействия может быть легко интегрировано с другими системами, не требуя каких–либо серьезных модификаций. В этом случае, количество изменений и время, требуемое на их выполнение, могут быть использованы для измерения возможности взаимодействия. 1.4.2 Нефункциональные виды тестирования. Тестирование производительностиНефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, «Как» система работает. Далее перечислены основные виды нефункциональных тестов: тестирование производительности: (a) нагрузочное тестирование (Performance and Load Testing); (b) стрессовое тестирование (Stress Testing); (c) тестирование стабильности или надежности (Stability / Reliability Testing); (d) объемное тестирование (Volume Testing); тестирование установки (Installation testing); тестирование удобства пользования (Usability Testing); тестирование на отказ и восстановление (Failover and Recovery Testing); конфигурационное тестирование (Configuration Testing). Нагрузочное тестирование или тестирование производительности. Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций; определение количества пользователей, одновременно работающих с приложением; определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций); исследование производительности на высоких, предельных, стрессовых нагрузках. Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности. Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит: измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций; может производиться определение количества пользователей, одновременно работающих с приложением. Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты, влияющие именно на стабильность работы. 1.4.3 Связанные с изменениями виды тестированияПосле проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть перетестировано для потверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта: дымовое тестирование (Smoke Testing) регрессионное тестирование (Regression Testing) тестирование сборки (Build Verification Test) санитарное тестирование или проверка согласованности/исправности (Sanity Testing) Понятие дымовое тестирование пошло из инженерной среды. При вводе в эксплуатацию нового оборудования («железа») считалось, что тестирование прошло удачно, если из установки не пошел дым. В области же тестирования программного обеспечения, оно направлено на поверхностную проверку всех модулей приложения на предмет работоспособности и наличие быстро находимых критических и блокирующих дефектов. По результатам дымового тестирования делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику. Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования. Регрессионное тестирование – это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде (см. также Санитарное тестирование или проверка согласованности/исправности). Регрессионными могут быть как функциональные, так и нефункциональные тесты. Как правило, для регрессионного тестирования используются тест кейсы, написанные на ранних стадиях разработки и тестирования. Это дает гарантию того, что изменения в новой версии приложения не повредили уже существующую функциональность. Рекомендуется делать автоматизацию регрессионных тестов, для ускорения последующего процесса тестирования и обнаружения дефектов на ранних стадиях разработки программного обеспечения. Сам по себе термин «Регрессионное тестирование», в зависимости от контекста использования может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования: Регрессия багов (Bug regression) – попытка доказать, что исправленная ошибка на самом деле не исправлена. Регрессия старых багов (Old bugs regression) – попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться. Регрессия побочного эффекта (Side effect regression) – попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) – это узконаправленное тестирование, достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную. Отличие санитарного тестирования от дымового. В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование – это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки. Тестирование сборки (Build Verification Test) – это тестирование, направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии. Тестирование Установки (Installation Testing) – направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения. В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования). В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки. В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll–back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя – это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения. Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing. 1.4.4 Тестирование удобства пользованияТестирование удобства пользования (Usability Testing). Иногда мы сталкиваемся с непонятными, нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. А значит они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее является неотъемлемой частью тестирования любых массовых продуктов. Тестирование удобства пользования – это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126] Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам: производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше – лучше); правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением? (меньше – лучше); активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя); эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция – лучше). Уровни проведения. Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке – тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом. Отсюда становится, очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки программного обеспечения: модульном, интеграционном, системном и приемочном. При этом оно целиком и полностью будет зависит от того, кто будет использовать приложение на выделенном конкретном уровне – разработчик, бизнес пользователь системы и т.д. Советы по улучшению удобства пользования. Для дизайна удобных приложений полезно следовать принципам «пока–йока» или fail–safe. У нас это более известно как «защита от дурака». Простой пример, если поле требует цифровое значение, логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок. Для повышения юзабилити существующих приложений можно использовать цикл Демминга Plan–Do–Check–Act, собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения. Заблуждения о тестировании удобства пользования 1. Тестирование пользовательского интерфейса = Тестирование удобства пользования. Тестирование удобства пользования не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе равно как и на многих других возможных компонентах продукта. При этом тип тестирования и тесткейсы будут совсем другие, так как речь может идти об удобстве использования не визуальных компонентов (если таковые имеются) или процессе администрирования, например, распределенного клиент-серверного продукта и т.д. 2. Тестирование удобства пользования можно провести без участия эксперта. Не всегда человек, не разбирающийся в предметной области, способен провести его самостоятельно. Представьте, что тестировщику нужно протестировать удобство пользования стратегического бомбардировщика. Ему придется проверить основные функции: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки и т.д. Очевидно, что без привлечения эксперта это будет весьма проблематично, и можно даже сказать, что невозможно. 1.4.5 Тестирование на отказ и восстановлениеТестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта. Тестирование на отказ и восстановление очень важно для систем, работающих по принципу «24x7». Если Вы создаете продукт, который будет работать, например, в интернете, то без проведения данного вида тестирования Вам просто не обойтись. Так как каждая минута простоя или потеря данных в случае отказа оборудования, может стоить вам денег, потери клиентов и репутации на рынке. Методика подобного тестирования заключается в симулировании различных условий сбоя и последующем изучении и оценке реакции защитных систем. В процессе подобных проверок выясняется, была ли достигнута требуемая степень восстановления системы после возникновения сбоя. Для наглядности рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как: отказ электричества на компьютере-сервере; отказ электричества на компьютере–клиенте; незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации); объявление или внесение в массивы данных невозможных или ошибочных элементов; отказ носителей данных1). При достижении соответствующих условий сбоя и по результатам работы систем восстановления, можно оценить продукт с точки зрения тестирования на отказ. Во всех выше перечисленных случаях, по завершении процедур восстановления, должно быть достигнуто определенное требуемое состояние данных продукта: потеря или порча данных в допустимых пределах; отчет или система отчетов с указанием процессов или транзакций, которые не были завершены в результате сбоя. Стоит заметить, что тестирование на отказ и восстановление – это весьма продукт-специфичное тестирование. Разработка тестовых сценариев должна производиться с учетом всех особенностей тестируемой системы. Принимая во внимание довольно жесткие методы воздействия, стоит также оценить целесообразность проведения данного вида тестирования для конкретного программного продукта. 1.4.6 Конфигурационное тестированиеКонфигурационное тестирование (Configuration Testing) – специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.) В зависимости от типа проекта конфигурационное тестирование может иметь разные цели: 1. Проект по профилированию работы системы. Цель Тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы. 2. Проект по миграции системы с одной платформы на другую. Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм. Уровни проведения тестирования. Для клиент-серверных приложений конфигурационное тестирование можно условно разделить на два уровня (для некоторых типов приложений может быть актуален только один): серверный или клиентский. На первом (серверном) уровне, тестируется взаимодействие выпускаемого программного обеспечения с окружением, в которое оно будет установлено: 1. Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.) 2. Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.) Основной упор здесь делается на тестирование с целью определения оптимальной конфигурации оборудования, удовлетворяющего требуемым характеристикам качества (эффективность, портативность, удобство сопровождения, надежность). На следующем (клиентском) уровне, программное обеспечение тестируется с позиции его конечного пользователя и конфигурации его рабочей станции. На этом этапе будут протестированы следующие характеристики: удобство использования, функциональность. Для этого необходимо будет провести ряд тестов с различными конфигурациями рабочих станций: 1 Тип, версия и битность операционной системы (подобный вид тестирования называется кросс–платформенное тестирование) 2 Тип и версия Web браузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс-браузерное тестирование) 3 Тип и модель видео адаптера (при тестировании игр это очень важно) 4 Работа приложения при различных разрешениях экрана 5 Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки) и т.д. Порядок проведения конфигурационного тестирования. Перед началом проведения конфигурационного тестирования рекомендуется: создавать матрицу покрытия (матрица покрытия – это таблица, в которую заносят все возможные конфигурации); проводить приоритезацию конфигураций (на практике, скорее всего, все желаемые конфигурации проверить не получится); шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию. Уже на начальном этапе становится очевидно, что чем больше требований к работе приложения при различных конфигурациях рабочих станций, тем больше тестов необходимо будет провести. В связи с этим, рекомендуется автоматизировать этот процесс. Конечно же автоматизированное тестирование не является панацеей, но в данном случае оно окажется очень эффективным помощником. 1.4.7. Вопросы для самоконтроля1) Как можно измерить сложность программы? 2) Группа видов тестирования в зависимости от цели 2) На чем базируются функциональные тесты? 3) На каких уровнях тестирования могут быть представлены функциональные тесты? 4) Виды функциональных тестов 5) В каких аспектах может проводиться тестирование функциональности? 6) Плюсы и минусы тестирования функциональности 7) Что такое тестирование безопасности. Его принципы. 8) Критерии определения целостности 9) Что такое тестирование взаимодействия. 10) Какой из видов тестирования функциональности чаще всего автоматизируется? 11) Виды тестирования производительности. Их характеристика. 12) Структура систематизации тестирования производительности. Изобразите схематично. 13) Задача тестирования производительности. Как его еще называют? 14) Задача стрессового тестирование. 15) Задача объемного тестирования. 16) Задача тестирования стабильности. 17) Задача дымового тестирования. 18) Типы регрессионного тестирования. 19) Задача санитарного тестирования. 20) Отличие санитарного тестирования от дымового. Являются ли они синонимами? 21) Аналогом какого тестирования является тестирование сборки? 22) Что такое Тестирование Установки и зачем оно необходимо? 23) Тестирование удобства пользования. Его критерии. Можно ли его измерить? 24) Тестирование пользовательского интерфейса = Тестирование удобства пользования? 25) Тестирование на отказ и восстановление. 26) Опишите сценарий (методику) тестирования на отказ. 27) Цели конфигурационного тестирования 28) Уровни проведения тестирования. На что делается в них акцент? Изобразите схематично. 29) Схема проведения конфигурационного тестирования ЛитератураБейзер, Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем / Б. Бейзер.– СПб.: Питер, 2004. –292с. Благодатских, В.А. Стандартизация разработки программных средств : учебное пособие [Текст] / В.А. Благодатских, В.А. Волнин, К.Ф. Поскакалов; под ред. О.С. Разумова. - М.: Финансы и статистика, 2005. –284с. Крылова, Г.Д. Основы стандартизации, сертификации, метрологии : учебник для вузов / Г.Д. Крылова. – 2-е изд.. – М.: ЮНИ- ТИ-ДАНА, 2001. –356с. Майерс, Г. Надежность программного обеспечения / Г. Майерс: — М.: Мир, 1980. –274с. Осипенко, Н.Б. Основы стандартизации и сертификации программного обеспечения: тексты лекций для студентов математических специальностей [Текст] / Н. Б. Осипенко; М-во образ. РБ, Гомельский государственный университет им. Ф. Скорины. - Гомель: ГГУ им. Ф. Скорины, 2007. – 137с. Тейер, Т. Надежность программного обеспечения / Т. Тейер, М. Липов, Э. Нельсон / Пер. с англ. — М.: Мир, 1981. –342с. Производственно-практическое издание Осипенко Наталья Борисовна ОСНОВЫ СТАНДАРТИЗАЦИИ И СЕРТИФИКАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Практическое руководство для студентов специальности I–40 01 01 «Программное обеспечение информационных технологий» В авторской редакции Подписано в печать 00.00.2014 (26). Формат 60х80 1/16. Бумага писчая №1. Гарнитура Таймс. Усл.печ.л. 4,1. Уч.-изд.л. 3,2. Тираж 25 экз. Издатель и полиграфическое исполнение: учреждение образования «Гомельский государственный университет имени Франциска Скорины». ЛИ № 02330/0549481 от14.05.2009 ул. Советская, 104, 2  46019, г. Гомель.1) Вот простой пример в 1979 г. Майерс (Myers) описал некоторый простой алгоритм. В нем был всего один цикл и несколько операторов условного перехода. В большинстве языков программирования для кодирования такого алгоритма потребуется не более 20 строк кода. Но такая программа имеет более 100 триллионов путей выполнения! Самому быстрому тестировщику для полного тестирования потребовался бы как минимум миллион лет. Аналогичная программа из 100 строк имеет 1018 триллионов путей выполнения, если на проверку выполнения одного пути тратить 1 секунду, то на полное ее завершение не хватит времени существования всей нашей вселенной, время жизни которой меньше 4 • 1017 секунд! 1) Данные ситуации могут быть воспроизведены, как только достигнута некоторая точка в разработке, когда все системы восстановления или дублирования готовы выполнять свои функции. Технически реализовать тесты можно следующими путями: симулировать внезапный отказ электричества на компьютере (обесточить компьютер); симулировать потерю связи с сетью (выключить сетевой кабель, обесточить сетевое устройство); симулировать отказ носителей (обесточить внешний носитель данных); имулировать ситуацию наличия в системе неверных данных (специальный тестовый набор или база данных). |