Попытка найти ошибки выполняя программу в тестовой или моделируемой среде
Программа состоит из модулей, что сильно облегчает тестирование, так как каждый модуль может быть отдельно проверен для всех возможных комбинаций, поскольку их число меньше. Если программа хорошо структурирована, необходимо проверять только интерфейс между проверенными ранее модулями. Даже если проверяются все варианты интерфейса, это является посильной ношей как для программиста, так и для вычислительной системы.
К сожалению, объектно-ориентированное программирование ускоряет создание сложных программ, но зато увеличивает число ошибок, которые к тому же очень тяжело искать.
Автономное тестирование модуля должно как минимум обеспечивать прохождение всех путей вычислений. Проектная процедура тестирования модуля состоит из следующих действий:
1) по внешним спецификациям модуля готовятся тесты для каждой ситуации и каждого недопустимого условия;
2) просматривается текст модуля с целью убедиться, что все условные переходы будут выполняться в каждом направлении. При необходимости добавляются соответствующие тесты;
3) изучается текст модуля с целью убедиться, что тесты охватывают достаточно много путей. Для циклов должны быть тесты без повторения, с одним повторением и с несколькими повторениями;
4) проверяется текст модуля, чтобы определить его чувствительность к особым значениям данных. Наиболее опасные числа это ноль и единица. В случае необходимости нужно добавить тесты.
МЕТОДЫ ТЕСТИРОВАНИЯ
Существует два крайних подхода к проектированию тестов. Сторонники первого подхода создают тесты, исследуя внешние спецификации сопряжения программы или модуля, который необходимо протестировать. В этом случае программа является как бы «черным ящиком». Необходимо проверить все возможные комбинации и значения на входе. Обычно их слишком много даже для простейших алгоритмов. Для программы расчета среднего арифметического четырех чисел надо готовить 10 7 тестовых данных.
Сторонники второго подхода связывают тесты только с логикой программы. При этом стремятся, чтобы каждая команда была бы выполнена хотя бы один раз. Цикл должен выполняться один раз, ни разу, максимальное число раз. Такое тестирование всех путей извне также недостижимо. В программе из двух последовательных циклов, внутри каждого из которых включено ветвление на десять путей имеется 10 18 путей расчета.
Чтобы построить разумную стратегию тестирования надо разумно сочетать оба этих подхода и пользоваться математическими доказательствами.
Восходящее тестирование. Сначала автономно тестируются модули нижних уровней, которые не вызывают других модулей. При этом достигается такая же их высокая надежность, как и у встроенных в компилятор функций. Затем тестируются модули более высоких уровней вместе с уже проверенными модулями и так далее по схеме иерархии.
Нисходящее тестирование. При этом подходе изолированно тестируется головной модуль или группа модулей головного ядра. Программа собирается и тестируется сверху вниз. Недостающие модули заменяются заглушками. Достоинством этого подхода является то, что тестирование модуля совмещается с тестированием сопряжений.
Модифицированный нисходящий метод. Согласно этому методу каждый модуль автономно тестируется перед включением в программу, собираемую сверху вниз.
Метод большого скачка. Каждый модуль тестируется автономно. По окончании автономного тестирования все модули интегрируются в готовую программную систему. Этот метод применяется, если программа мала и хорошо спроектирована по сопряжениям.
Метод сэндвича. Представляет собой компромисс между нисходящим и восходящим подходами. По этому методу реализация и тестирование ведется одновременно сверху и снизу, и два этих процесса встречаются в заранее намеченной точке.
Модифицированный метод сэндвича. Нижние модули тестируются снизу вверх, а модули верхних модулей сначала тестируются автономно, а затем собираются нисходящим методом.
АКСИОМЫ ТЕСТИРОВАНИЯ
Тестирование программных систем в настоящее время остается в большей мере искусством, чем наукой. При проведении тестов рекомендуется придерживаться так называемых аксиом тестирования, представляющих собой эвристические приемы. Вот некоторые из них:
1) хорошим считается тот тест, в котором высока вероятность обнаружения ошибок;
2)тестирование собственной программы существенно осложняется психологическими причинами;
3) необходимой частью тестов считается описание выходных результатов;
4)нужно готовить тесты как для правильных, так, и для неправильных данных; ,
5) нельзя тестировать «с лету», наскоком;
6) необходимо тщательно изучать результаты каждого теста;
7) по мере обнаружения все большего числа ошибок в программе, возрастает вероятность обнаружения в ней еще большего числа ошибок;
8) тестирование программ должны осуществлять самые лучшие и опытные программисты;
9)одной из главных задач разработчиков программы является возможность осуществления ее тестирования;
10)нельзя изменять программу только с целью облегчить процесс ее тестирования;
11)чем раньше спроектирован тест, тем выше вероятность выявления ошибок. Лучше всего готовить тесты еще на этапе проектирования системы;
12)процесс тестирования должен быть документирован и полностью управляем, хаотичность недопустима;
13)необходимы повторяемость и завершенность тестов;
14)следует избегать добавления новых тестов уже в процессе тестирования.
КЛАССИФИКАЦИЯ ТЕСТОВ
По условиям их поведения тесты могут быть классифицированы следующим образом:
Доказательство (proof) - попытки найти ошибки в программе путем доказательств на основе математических теорем о правильности программы, безотносительно к внешней программной среде.
Верификация программы (program verification) - попытка найти ошибки, выполняя программу в тестовой или моделируемой среде.
Испытание (validation) - попытка найти ошибки, выполняя программу в заданной программной среде.
Приемо-сдаточные испытания - проверка пригодности программы для эксплуатации; такие испытания обычно проводят под контролем поставщика системы.
По назначению тесты классифицируются:
тестирование модуля (автономное тестирование) (module testing) — контроль, отдельного модуля в изолированной среде (например, с помощью ведущей программы), инспекция текста модуля на сессии программистов, которая иногда дополняется математическим доказательством правильности модуля;
тестирование сопряжений (integration testing) - контроль сопряжений между частями программной системы, как между компонентами в комплексе, так и между модулями отдельного компонента (например, у заглушки);
комплексное тестирование (system testing) — контроль и испытание системы по отношению к исходным целям. Осуществляется с целью проверки правильной совместной работы составных частей программы. При комплексном тестировании особое внимание обычно уделяется взаимодействию компонентов. Комплексное тестирование является процессом контроля, если оно выполняется в условиях моделируемой среды, и процессом испытания при выполнении в реальной среде;
системное тестирование - при системном тестировании вся система в целом обычно рассматривается как некоторый «черный ящик»; поведение этой системы исследуют, не вникая в подробности отдельных ее компонентов и взаимодействий между ними;
тестирование приемлемости (acceptance testing) - проверка соответствия программы требованиям пользователя.
ОТЛАДКА
Процесс тестирования нельзя путать с процессом отладки (debugging). Первый служит лишь для обнаружения факта существования ошибок, а не для их локализации и устранения.
Отладка программ обычно осуществляется с использованием специальных программных средств. Последние используются для исследования внутреннего поведения программы. Типичный отладчик позволяет вводить в программу точки останова для оценки промежуточных результатов и производить проверку и модификацию значений переменных в этих точках.
Существуют несколько способов отладки программы.
Распечатка текущего состоя н и я . Используется с целью фиксации фактических значений переменных для проверки хода вычислений. Для этого во время отладки программы в места, которые программист считает критическими, помещают процедуры распечатки текущего состояния переменных. После окончания теста вызовы этих процедур удаляются, и программа снова перекомпилируется.
Метод деления п о п о л а м . Этот метод используют связисты, когда ищут обрыв в кабеле, закопанном в землю. Например, если приблизительно известно до какого момента программа успешно выполняется, то в этом месте программы ставят точку останова. Затем ставят точку в конце «подозреваемой» процедуры и посредине - между первой и последней точками. Снова компилируют и выполняют программу. Если программа дошла до второй точки, то зацикливание произошло где-то между второй и третьей точками, если не дошла - между первой и второй. После этого вставляется новая точка останова в локализованный участок и программа снова компилируется. Таким образом, постоянно сжимая район поисков, можно найти ошибочный участок.
Трассировка. Является последним средством обнаружения ошибки. Она может оказаться очень эффективной, но значительно замедляет выполнение программы и, не будучи тщательно спланированной, приводит к колоссальным объемам выдаваемой информации. При трассировке происходит пошаговое выполнение программы с возможностью просмотра состояния всех переменных.
ОПТИМИЗАЦИЯ
Обычно программа создается в достаточно жестком временном режиме, что заставляет программиста искать, скорее, более правильные решения, чем более эффективные. Под эффективностью программы понимают, прежде всего, скорость ее выполнения, а также ее объем. Сегодня, когда уделяется особое внимание пользовательскому интерфейсу, в список влияющих на эффективность программы факторов можно, пожалуй, также занести и удобство интерфейса. Таким образом, под оптимизацией понимается процесс улучшения программы.
Оптимизация не является обязательным условием разработки программы. Однако существует целый класс программ, критичных как к скорости выполнения, так и к размеру. Таковыми являются программы графического вывода в силу большого объема вычислений, связанных с графическими преобразованиями.
При проектировании больших систем оптимизация производится в два этапа, Сначала оптимизируют текст программы на языке высокого уровня, а затем наиболее критичные ко времени выполнения процедуры переписывают на язык ассемблера. Существуют следующие способы оптимизации программных кодов.
Разгрузка участков повторяемости. Является способом оптимизации, который чаще всего подразумевает разгрузку циклов путем вынесения из них выражений, которые могут быть вычислены вне циклов.
К этому виду преобразований относятся также «чистки» тел рекурсивных процедур, когда выражения в соответствующем цикле (или теле многократно вызываемой процедуры) выносятся и размещаются перед входом в участок повторяемости — это так называемая чистка вверх.
Иногда применяют чистку вниз, когда соответствующие фрагменты кода помещаются после цикла. При этом нужно обратить внимание на то, что выносить можно только такие выражения, которые обязательно исполняются при каждом прохождении разгружаемого цикла.
Замена сложных операций на более простые. Очень часто одна операция предпочтительнее другой на том основании, что выполняется быстрее, но знание таких нюансов приходит к программисту лишь с опытом.
Например, операция сложения выполняется быстрее операции умножения, а умножение быстрее операции деления. Поэтому один оператор умножения переменной на некоторое небольшое целое число (обычно не более трех) лучше заменить на эквивалентное количество сложений. Выражение:
Total := Summa + Summa + Summa;
эффективнее выражения: Total := 3 * Summa;
а операцию деления Summa := Summa/2; лучше заменить на более быстрое умножение, которое приведет к тому же самому результату Summa := Summa * 0.5;
Чистка программы. Данный способ повышает качество программы за счет удаления из нее ненужных объектов и конструкций. Набор преобразований этого типа включает в себя следующие варианты оптимизации:
удаление несущественных операторов, то есть операторов, не влияющих на результат программы;
удаление бесполезных операторов, вычисляющих вспомогательные переменные, используемые только для подстановки в другие выражения;
удаление объявленных, но неиспользуемых переменных и типов;
удаление идентичных операторов;
удаление процедур, к которым нет обращений.
Необходимость в такого рода чистках возникает потому, что очень часто программист «захлебывается» в общем количестве переменных и процедур одного слишком большого модуля. Подчас он объявляет переменные, которые потом нигде в программе не использует.
Например, программист может объявить целочисленную переменную для организации цикла, а затем, спустя какое-то время, для организации другого цикла объявляет еще одну переменную, забыв о существовании предыдущей и возможности ее повторного использования.
Экономия памяти. Одним из главных ресурсов после процессорного времени, который использует программа, является объем оперативной памяти. Объем памяти зависит как от размера кода самой программы, так и от количества статических и динамических переменных.
Программист должен учиться как можно экономнее использовать память. Каждую структуру следует тщательно продумывать и не требовать, скажем, для переменной, в которой будут храниться координаты текстового экрана, двухбайтового типа.
Это так называемая экономия на типе переменной. Существует и еще ряд способов более экономного расходования памяти:
1) Глобальная экономия памяти подразумевает совмещение по памяти не существующих одновременно статических переменных. Модульное программирование также подразумевает разнесение объявлений несвязанных переменных в различные модули.
2) Изменение области существования переменной.
3) Перемещение оператора объявления переменной (резервирования памяти) ближе к тому участку программы, в котором содержатся операторы, использующие эту переменную, то есть переменную следует объявлять в границах того блока, где она используется.
4) Экономия стека: при передаче массива в качестве параметра подпрограммы, следует использовать ссылку на массив. Помимо экономии памяти это приводит также и к экономии времени за счет того, что система не создает копии передаваемого массива в стеке.
Тестирование программного средства (ПС) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Тестирование программ является одной из составных частей более общего понятия - «отладка программ». Под отладкой понимается процесс, позволяющий получить программу, функционирующую с требующимися характеристиками в заданной области изменения входных данных.
Процесс отладки включает:
действия, направленные на выявление ошибок (тестирование);
диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);
внесение исправлений в программу с целью устранения ошибок.
Из трех перечисленных видов работ самым трудоемким и дорогим является тестирование, затраты на которое приближаются к 45 % общих затрат на разработку ПС.
Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности - с самого начала не допускать ошибок в программе.
Роль тестирования состоит в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе.
Тестирование оказывается довольно необычным процессом (поэтому и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего (тестовика) - заставить программу сбиться.
Программы, как объекты тестирования, имеют ряд особенностей, которые отличают процесс их тестирования от общепринятого, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПС являются:
отсутствие эталона (программы), которому должна соответствовать тестируемая программа;
высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;
практическая невозможность создания единой методики тестирования (формализация процесса тестирования) в силу большого разнообразия программных изделий (ПИ) по их сложности, функциональному назначению, области использования и т.д.
Тестирование - это процесс многократного выполнения программы с целью выявления ошибок. Целью тестирования является обнаружение максимального числа ошибок. Поэтому тестовый прогон, в результате которого не выявлено ошибок, считается неудачным (неэффективным).
Существуют несколько эмпирических правил проведения тестирования программ, обобщающих опыт тестировщиков.
1. Процесс тестирования более эффективен, если проводится не автором программы.
2. Необходимой частью тестового набора данных должно быть описание предполагаемых значений результатов тестовых прогонов. Тестирование как процесс многократного выполнения программы проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных в результате очередного тестового прогона данных, необходимо знать ожидаемый результат. Таким образом, тестовый набор данных должен включать в себя два компонента: описание входных данных, описание точного и корректного результата, соответствующего набору входных данных.
3.Необходимо изучить результаты каждого теста. Из практики следует, что значительная часть обнаруженных ошибок могла быть выявлена в результате первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа их результатов.
5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она того, чего не должна делать. Это утверждение логически вытекает из предыдущего. Необходимо любую программу проверить на нежелательные побочные эффекты.
6. Следует тщательнее проверять те участки программ, где обнаруживается больше ошибок. Утверждается, что вероятность наличия необнаруженных ошибок в какой-либо части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Возможно, что те части программы, где при тестировании обнаружено большее число ошибок, либо были слабо проработаны с точки зрения системного анализа, либо разрабатывались программистами более низкой квалификации.
Тестирование (testing) - процесс выполнения программы или ее части с целью найти ошибки.
Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы.
Контроль (verification) - попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде.
Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.
Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, но под ними подразумеваются разные виды деятельности.
Тестирование - это деятельность, направленная на обнаружение ошибок.
Отладка направлена на установление точной природы известной ошибки, а затем на исправление этой ошибки. Эти два вида деятельности связаны, т.к. результаты тестирования являются исходными данными для отладки.
Тестирование модуля, или автономное тестирование (module testing, unit testing) - контроль отдельного программного модуля, обычно в изолированной среде (изолированно от всех остальных модулей).
Тестирование модуля иногда включает математическое доказательство.
Тестирование сопряжений (integration testing) - контроль сопряжений между частями системы (модулями, компонентами, подсистемами).
Тестирование внешних функций (external function testing) - контроль внешнего поведения, определенного внешними спецификациями.
Комплексное тестирование (system testing) - контроль и/или испытание системы по отношению к исходным целям.
Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.
Тестирование приемлемости (acceptance testing) - проверка соответствия программы требованиям пользователя.
Тестирование настройки (installation testing) - проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
Хотя в тестировании можно выделить несколько различных процессов, такие термины, как «тестирование», «отладка», «доказательство», «контроль» и «испытание», часто используются как синонимы и, к сожалению, для разных людей имеют разный смысл. Нашу классификацию различных форм тестирования мы начнем с того, что дадим эти определения, слегка их дополнив и расширив их список.
Тестирование (testing) – процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.
Доказательство (proof) – попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию – взгляд во многом ошибочный.
Контроль (verification) – попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
Испытание (validation) – попытка найти ошибки, выполняя программу в заданной реальной среде.
Аттестация (certification) – авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.
Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем – на исправление этой ошибки. Эти два вида деятельности связаны – результаты тестирования являются исходными данными для отладки.
Эти определения представляют один взгляд на тестирование – со стороны среды, на которую оно опирается. Другой ряд определений, приведенный ниже, охватывает вторую сторону тестирования: типы ошибок, которые предполагается обнаружить, и стандарты, с которыми сопоставляются тестируемые программы.
Тестирование модуля, или автономное тестирование (module testing, unit testing), – контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.
Тестирование сопряжений (integration testing) – контроль сопряжений между частями системы (модулями, компонентами, подсистемами).
Тестирование внешних функций (external function testing) – контроль внешнего поведения системы, определенного внешними спецификациями.
Комплексное тестирование (system testing) – контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
Тестирование приемлемости (acceptance testing) – проверка соответствия программы требованиям пользователя.
Тестирование настройки (installation testing) – проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
Отладка программы – это процесс поиска и устранения ошибок. Часть ошибок формального характера, связанных с нарушением правил записи конструкций языка или отсутствием необходимых описаний, обнаруживает транслятор, производя синтаксический анализ текста программы. Транслятор выявляет ошибки и сообщает о них, указывая их тип и место в программе. Такие ошибки называются ошибками времени трансляции или синтаксическими ошибками.
Ошибочные ситуации могут возникнуть и при выполнении программы, например, деление на нуль или извлечение корня квадратного из отрицательного числа. Такие ошибки называются ошибками времени выполнения.
Программа, не имеющая ошибок трансляции и выполнения, может и не дать верных результатов из-за логических ошибок в алгоритме, т. е. алгоритмических или семантических ошибок. Ошибки подобного рода могут возникнуть на любом этапе разработки программы: постановки задачи, разработке математической модели или алгоритма. Необходим действенный контроль над процессом вычислений, позволяющий предотвращать или своевременно обнаруживать ошибки подобного рода. Для этого используются как качественный анализ задачи, основанный на различного рода интуитивных соображениях и правдоподобных рассуждениях, так и контрольный просчет или тестирование программы.
Тестирование программы – это выполнение программы на наборах исходных данных (тестах), для которых известны результаты, полученные другим методом. Система тестов подбирается таким образом, чтобы
а) проверить все возможные режимы работы программы;
б) по возможности, локализовать ошибку.
При тестировании программы простой и действенный метод дополнительного контроля над ходом её выполнения – получение контрольных точек, т. е. контрольный вывод промежуточных результатов.
Для проверки правильности работы программы иногда полезно также выполнить проверку выполнения условий задачи (например, для алгебраического уравнения найденные корни подставляются в исходное уравнение и проверяются расхождения левой и правой частей).
33. ВИДЫ ОШИБОК В ПРОГРАММАХ
Об ошибках в программе сигнализируют некорректная работоспособность программы либо ее полное невыполнение. В наше время для обозначения ошибки в программе используют термин «Баг» (с англ. Bug-жук).
Есть несколько типов ошибок:
1) Логическая ошибка. Это, пожалуй, наиболее серьезная из всех ошибок. Когда написанная программа на любом языке компилирует и работает правильно, но выдает неправильный вывод, недостаток заключается в логике основного программирования. Это ошибка, которая была унаследована от недостатка в базовом алгоритме. Сама логика, на которой базируется вся программа, является ущербной. Чтобы найти решение такой ошибки нужно фундаментальное изменение алгоритма. Вам нужно начать копать в алгоритмическом уровне, чтобы сузить область поиска такой ошибки. (пример: задача программы вывести сумму двух чисел а и b.
varc,a,b:integer;
2) Синтаксическая ошибка.Каждый компьютерный язык, такой как C, Java, Perl и Python имеет специфический синтаксис, в котором будет написан код. Когда программист не придерживаться "грамматики" спецификациями компьютерного языка, возникнет ошибка синтаксиса. Такого рода ошибки легко устраняются на этапе компиляции.
3) Ошибка компиляции.Компиляция это процесс, в котором программа, написанная на языке высокого уровня, преобразуется в машиночитаемую форму. Многие виды ошибок могут происходить на этом этапе, в том числе и синтаксические ошибки. Иногда, синтаксис исходного кода может быть безупречным, но ошибка компиляции все же может произойти. Это может быть связано с проблемами в самом компиляторе. Эти ошибки исправляются на стадии разработки.
vara:array[1..5] of integer;
6) Ошибки ресурса. Ошибка ресурса возникает, когда значение переменной переполняет максимально допустимое значение. Переполнение буфера, использование неинициализированной переменной, нарушение прав доступа и переполнение стека - примеры некоторых распространенных ошибок.
vara:integer;
7) Ошибка взаимодействия. Они могут возникнуть в связи с несоответствием программного обеспечения с аппаратным интерфейсом или интерфейсом прикладного программирования. В случае веб-приложений, ошибка интерфейса может быть результатом неправильного использования веб-протоколов
Синтаксические ошибки – это ошибки в записи конструкций языка программирования (чисел, переменных, функций, выражений, операторов, меток, подпрограмм).
Семантические ошибки – это ошибки, связанные с неправильным содержанием действий и использованием недопустимых значений величин.
Внимание! Все тесты в этом разделе разработаны пользователями сайта для собственного использования. Администрация сайта не проверяет возможные ошибки, которые могут встретиться в тестах.
Список вопросов теста
Вопрос 1
Проверка соответствия программного обеспечения требованиям, осуществляемая с помощью наблюдения за его работой в специальных, искусственно построенных ситуациях.
- Тестирование
- Отладка
- Верификация
Вопрос 2
Основные цели тестирования программного обеспечения
- продемонстрировать заказчикам, а также разработчикам, что программный продукт соответствует требованиям
- выявить ситуации, в которых поведение программного обеспечения является неправильным, нежелательным или несоответствующим спецификации.
- устранить ошибки, допущенные на всех предыдущих этапах подготовки задач для решения на ЦВМ и получить программу, дающую правильные результаты
Вопрос 3
Основные задачи тестировщика
- поиск вероятных ошибок и сбоев
- моделирует различные ситуации, которые могут возникнуть в процессе использования ПП
- осуществление отладки ПП
Вопрос 4
Система методов отбора и создания тестов для тестового набора
Вопрос 5
- Отладка
- Испытание
- Контроль
- Настройка
Вопрос 6
- тестирование программного кода на этапе разработки программного обеспечения
- поиск ошибок при выполнении программ в тестовой или моделируемой среде
- попытка найти ошибки при выполнении программы в реальной среде
Вопрос 7
- тестирование программного кода на этапе разработки программного обеспечения
- поиск ошибок при выполнении программ в тестовой или моделируемой среде
- попытка найти ошибки при выполнении программы в реальной среде
Вопрос 8
- тестирование программного кода на этапе разработки программного обеспечения
- поиск ошибок при выполнении программ в тестовой или моделируемой среде
- попытка найти ошибки при выполнении программы в реальной среде
Вопрос 9
документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
- План тестирования
- Тест-дизайн
- Тест-кейс
- Баг-репорт
Вопрос 10
процесс тестирования ПО, на котором проектируются и создаются тест-кейсы в соответствии с определенными ранее критериями качества и целями тестирования.
- Тест-дизайн
- План тестирования
- Тест-кейс
- Баг-репорт
Вопрос 11
документ, описывающий последовательность действий, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части.
- Тест-кейс
- Тест-дизайн
- План тестирования
- Баг-репорт
Вопрос 12
Тест-кейсы подразделяют по ожидаемому результату на:
- позитивные и негативные
- правильные и неправильные
- первичные и вторичные
- положительные и отрицательные
Вопрос 13
Каждый кейс-комплект содержит общую информацию о тестировании:
- название проекта
- номер версии
- имя тестера
- даты тестирования
- номер тестирования
- название теста
- количество тестов
Вопрос 14
План работы над тест-дизайном включает в себя:
- анализ документации (спецификации, требования, планы), модели, исполняемого кода и т.д.
- написание спецификации по тест-дизайну
- проектирование и создание
- критерии окончания тестирования (результаты тестирования удовлетворяют критериям качества продукта);
- необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
Вопрос 15
В соответствии с этапом обработки, на котором появляются ошибки, различают:
- синтаксические ошибки
- ошибки компоновки
- ошибки выполнения
- глобальная ошибка
Вопрос 16
ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы
Читайте также: