-
продукт достиг необходимого уровня качества;
-
заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.
Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения. 1.2.5 ВИДЫ ТЕСТИРОВАНИЯ ПО ДОСТУПУ К КОДУ (МЕТОДЫ ТЕСТИРОВАНИЯ)Метод белого ящика[5]Для тестирования программного кода без его запуска применяется метод белого ящика. Тестировщик имеет доступ к исходному коду программного средства и может писать код, который связан с библиотеками тестируемого программного средства. Чаще используют для компонентного тестирования, при котором тестируются только отдельные части системы. Такие тесты основаны на знании кода и внутренних механизмах приложения. Метод белого ящика используется на стадии, когда приложение не собрано в одно целое, но необходимо проверить его компоненты, модули, процедуры и подпрограммы. Тестированием данным методом занимаются: программист, или тестировщик со знанием языка программирования.Метод черного ящика[5]При использовании метода черного ящика тестировщик имеет доступ к ПО только через те интерфейсы, что и заказчик, конечный пользователь. Тестировщику предоставляются спецификации или иные документы, в которых описаны требования. Тестировщик запускает приложение на выполнение и тестирует его функциональность, работает с программой как конечный пользователь и ничего не знает о внутренних механизмах и алгоритмах, по которым работает программа. Цель метода – проверить работу всех функций ПС на соответствие функциональным требованиям.Метод серого ящика используется при тестировании веб-приложений, когда тестировщик знает принципы функционирования технологий, но может не видеть кода. 1.2.6 ВИДЫ ТЕСТИРОВАНИЯ ПО ПОЗИТИВНОСТИ СЦЕНАРИЯПозитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана. Например, умножение на калькуляторе цифр 3 и 5.Негативным называют тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть, например, исключительные ситуации или неверные данные. На примере калькулятора, это умножения числа 3 на грушу. Значение “груша” не является валидным для калькулятора.
Прежде всего негативное тестирование направлено на проверку устойчивости системы к различным воздействиям, валидации неверных данных, обработки исключительных ситуаций. Сценарии позитивного тестирования, в свою очередь, направлены на проверку работы системы с теми типами данных, для которых она разрабатывалась.Создание позитивных сценариев (тест-кейсов), как правило, предшествует созданию негативных тест-кейсов. Сначала мы проверяем работу системы, когда наш условный пользователь работает с системой “правильно”, а потом приступаем к проверке отклика системы на пользователя, который допускает различные ошибки (ввод неверных данных, например). И наша система должна быть готова ответить на неверный запрос. Это и есть цель негативного тестирования. 1.2.7 КРИТЕРИИ ВЫБОРА ТЕСТОВ И ОЦЕНКИ КАЧЕСТВА ПОТребования к идеальному критерию тестирования[19] -
Критерий должен быть достаточным.
-
Критерий должен быть полным.
-
Критерий должен быть надежным.
-
Критерий должен быть легко проверяемым
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.Поэтому мы стремимся к идеальному общему критерию через реальные частные.Классы критериев[19] -
Структурные.
-
Функциональные.
-
Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
-
Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
Структурные критерии- используют модель программы в виде "белого ящика", что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing)Структурные критерии базируются на основных элементах УГП (управляющий граф программы), операторах, ветвях и путях. -
Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
-
Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
-
Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей).
Функциональные критерии- важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Отражают взаимодействие тестируемого приложения с окружением. Используется модель "черного ящика". Проблема:трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), достаточно объемны. -
Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
-
Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
-
Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
-
Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
-
Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели "полупрозрачного ящика", где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
-
Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
Стохастические критерии- применяется при тестировании сложных программных комплексов - когда набор детерминированных тестов имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на фазе тестированияНеобходимо разработать программы - имитаторы случайных последовательностей входных сигналов{x}. Вычислить независимым способом значения {y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y). Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов: -
Детерминированный контроль - проверка соответствия вычисленного значения y значению y, полученному в результате прогона теста на наборе {x} - случайной последовательности входных сигналов, сгенерированной имитатором.
-
Стохастический контроль - проверка соответствия множества значений {y}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества.Критерии стохастического тестирования -
Cтатистические методы окончания тестирования - стохастические методы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат широко известные: метод Стьюдента, метод Хи-квадрат.
-
1 2 3 4 5 6 7 8 9 10
Метод оценки скорости выявления ошибок - основан на модели скорости выявления ошибок, согласно которой тестирование прекращается, если оцененный интервал времени между текущей ошибкой и следующей слишком велик для фазы тестирования приложения.
Мутационный критерий
- постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Мутации - мелкие ошибки в программе[19].
Мутанты - программы, отличающиеся друг от друга мутациями.
Метод мутационного тестирования - в разрабатываемую программу P вносят мутации, т.е. искусственно создают программы-мутанты P1, P2... Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной.
1.3 ТИПЫ И УРОВНИ ТРЕБОВАНИЙ. ВЫЯВЛЕНИЕ ТРЕБОВАНИЙ
Требование (requirement) — описание функции и/или условия, которое должно соблюдаться приложением в процессе решения пользовательской задачи[19].
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как.
Требования нужны в частности для того, чтобы разработчик мог определить и согласовать с заказчиком временные и финансовые перспективы проекта автоматизации. Поэтому значительная часть требований должна быть собрана и обработана на ранних этапах создания ПС. Однако собрать на ранних стадиях все данные, необходимые для реализации ПС, удается только в исключительных случаях. На практике процесс сбора, анализа и обработки растянут во времени на протяжении всего жизненного цикла ПС, зачастую нетривиален и содержит множество подводных камней.
Источники требований[19]
Все требования приходят от заказчиков, или людей связанных с ними (сотрудников, пользователей и тп.)