 |
Тестирование в конструировании
|
|
|
|
Цели и задачи. Основные определения
Тестирование – процесс выполнения программы с намерением найти ошибки. (Майерс)
«Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» (Дейкстра, 1970 г)
Существующие на сегодняшний день методы тестирования программного обеспечения не позволяют полностью устранить все дефекты и ошибки и установить корректность функционирования программного продукта. Процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учетом человеческого фактора, присутствующего на всех этапах жизненного цикла программного обеспечения).
Существует множество подходов к решению задачи тестирования и верификации программного обеспечения. Конечной целью любого процесса тестирования является обеспечение качества ПО. Задача тестирования – снизить стоимость разработки путем раннего обнаружения дефектов.
Методологии тестирования
Существует две основные методологии тестирования:
a) «белого ящика» и
b) «чёрного ящика».
При тестировании методом белого ящика (white-box testing, также говорят — прозрачного ящика, оно же структурное тестирование – рис. 27), разработчик теста имеет доступ к исходному коду программы. Тесты создаются на основе знаний о структуре самой системы и о том, как она работает. Критерии полноты основаны на проценте элементов кода, которые отработали в ходе выполнения тестов.
Рис. 27. Метод белого ящика
При тестировании методом чёрного ящика тестировщик имеет доступ к программному обеспечению только через те же интерфейсы, что и пользователь, или через внешние интерфейсы (см. рис. 28).
|
|
|
Рис. 28. Метод черного ящика
Тестирование черного ящика нацелено на проверку требований, зафиксированных в спецификациях, стандартах и внутренних нормативных документах. Часто его называют тестированием на соответствие (conformance testing). Частным случаем является функциональное тестирование.
Существует также смешанный вариант тестирования - методом «серого ящика» (см.рис.29). При этом используется некоторая информация о внутренней структуре приложения или о деталях реализации. Метод применяется в последнее время все чаще.
Рис. 29. Метод серого ящика
В данном случае у человека, который разрабатывает тест кейсы, есть
Уровни тестирования
Еще одна классификация видов тестирования основана на уровне детализации работ проекта, т.е с фазой жизненного цикла, на которой они выполняются. Она иллюстрируется рис. 30.
| Unit Testing |
| Integration Testing |
| System Testing |
| Acceptance Testing |
Рис. 30. Уровни тестирования
Модульное тестирование (Unit-testing) — уровень тестирования, на котором тестируется минимально возможный компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика». В современных проектах такое тестирование («юнит-тестинг») осуществляется разработчиками.
Модульное тестирование предназначено для проверки правильности отдельных модулей, вне зависимости от их окружения. При этом счтитается, что если модуль получает на вход корректные данные, то и результаты его корректны. Для описания критериев корректности входных и выходных данных часто используют программные контракты:
a) предусловия, описывающие для каждой операции, на каких входных данных она работает,
b) постусловия, описывающие для каждой операции, как должны соотноситься входные данные с возвращаемыми результатами.
|
|
|
Основной недостаток модульного тестирования состоит в том, что проводить его можно, только когда проверяемый элемент программы уже разработан. Снизить влияние этого ограничения можно, подготавливая тесты (а это — наиболее трудоемкая часть тестирования) на основе требований заранее, когда исходного кода еще нет. Подход опережающей разработки тестов с успехом используется, например, в рамках XP.
Модульное тестирование является важной составной частью отладочного тестирования, выполняемого разработчиками для отладки написанного ими кода.
Интеграционное тестирование (Integration testing) – уровень тестирования, на котором отдельные программные модули объединяются и тестируются в группе. Обычно оно проводится после модульного тестирования.
Интеграционное тестирование в качестве входных данных использует оттестированные модули, группирует их в более крупные множества, выполняет тесты для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования. При этом проверяется, что в ходе совместной работы модули обмениваются данными и вызовами операций, не нарушая взаимных ограничений на такое взаимодействие, например, предусловий вызываемых операций.
Интеграционное тестирование выполняется разработчиками при отладке, но на более позднем этапе разработки.
Системное тестирование (System testing) - это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки ее соответствия исходным требованиям. Оно относится к методам «чёрного ящика» и не требует знаний о внутреннем устройстве системы.
Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса, проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями такого тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI). Системное тестирование выполняется инженерами по тестированию.
Приемочное тестирование (Acceptance testing)- это тестирование готового продукта конечными пользователями на реальном окружении, в котором будет функционировать система. Приемочные тесты разрабатываются пользователями, обычно в виде сценариев.
|
|
|
Статическое тестирование (Static testing) – тестирование, в ходе которого тестируемая программа не выполняется. При этом выполняется анализ программы на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. Этот метод уже рассмотрен.
Примеры статического тестирования:
a) Обзоры (Reviews)
b) Инспекции (Inspections)
c) Сквозные просмотры (Walkthroughs)
d) Аудиты (Audits)
К статическому тестированию относят также тестирование требований, спецификаций, документации.
Динамическое тестирование (Dynamic testing)– тестирование в ходе выполнения программы. Различают два вида такого тестирования:
a) Альфа-тестирование — тестирование в процессе разработки
b) Бета-тестирование — тестирование выполняется пользователями (end-users)
Перед тем, как выпускается программное обеспечение, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты, проводимые специалистами группы разработки. Этот вид тестирования не может быть заранее спланирован.
Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения.
После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Такое тестирование может выполняться как вручную, так и средствами автоматизации.
Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов.
«Смок-тест» (Smoke Testing, «дымовое тестирование») в тестировании означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом. Не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.
|
|
|
Виды тестирования
Функциональное (functional testing)
– каждое функциональное требование транслируется в тест-кейсы (используя техники «черного ящика») для того, чтобы проверить, что система функционирует в точности, как и описано в спецификации
– проверяется, все ли функциональные требования действительно закодированы.
Тестирование производительности (perfomance testing). Существует особый вид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения:
–продемонстрировать, что система удовлетворяет критериям производительности при заданных условиях;
–измерить, какая часть системы является причиной «плохой» производительности;
–измерить время реакции на действие пользователя, время отклика на запрос, и т.д.
Стрессовое тестирование (stress testing)
– тестирование в условиях ограниченных ресурсов (например, скорость, память, место на диске и т.д.)
– проверка, что система в стрессовых условиях не прекращает свою работу или прекращает некорректным образом (без сохранения копии базы данных, вывода сообщения пользователям и т.п.)
Нагрузочное тестирование (load testing) применяется для анализа работы информационных систем на различных уровнях нагрузки. Его основным понятием является «виртуальный пользователь». Управляя числом таких пользователей, тестировщик управляет нагрузкой на систему. При этом определяют, при какой максимальной нагрузке (максимальном количестве пользователей) система способна функционировать в соответствии с требованиями к производительности
Тестирование удобства использования (usability testing)
- эксперимент, выполняемый с целью определения, насколько хорошо можно использовать некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство). Юзабилити-тестирование измеряет юзабилити объекта.
- метод оценки удобства в использовании продукта, основанный на привлечении пользователей в качестве тестировщиков - испытателей.
При испытании многих продуктов пользователю предлагают в «лабораторных» условиях решить основные задачи, для выполнения которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания. Процесс тестирования фиксируется в протоколе или на аудио- и видеоустройстве — с целью последующего более детального анализа.
|
|
|
Если юзабилити-тестирование выявляет какие-либо трудности (например, сложности в понимании инструкций, выполнении действий или интерпретации ответов системы), то разработчики должны доработать продукт и повторить тестирование.
Наблюдение за тем, как люди взаимодействуют с продуктом, нередко позволяет найти для него более оптимальные решения. Основную трудность после проведения процедуры юзабилити-тестирования нередко представляют большие объёмы и беспорядочность полученных данных.
Существует еще один подход к usability-тестированию: Для решения задачи, предложенной пользователю, разрабатывается «идеальный» сценарий. Как правило, это сценарий, на который ориентировался разработчик. При выполнении задачи пользователями регистрируются их отклонения от задуманного сценария для последующего анализа. После нескольких итераций доработки программы и последующего тестирования можно получить удовлетворительный результат с точки зрения пользователя.
Тестирование интерфейса пользователя (UI testing)
– тестирование графического интерфейса для того, чтобы убедиться, что он соответствует принятым стандартам и их требованиям;
– проверка того, как приложение обрабатывает ввод с клавиатуры и «мышки» и как отображаются элементы графического интерфейса (текст, кнопки, меню, списки и прочие элементы).
Тестирование безопасности (security testing)
- оценка уязвимости программного обеспечения к различным атакам. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:
· попытки узнать пароль с помощью внешних средств;
· атака системы с помощью специальных утилит, анализирующих защиты;
· подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);
· целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;
· просмотр несекретных данных в надежде найти ключ для входа в систему.
Тестирование локализации (localization testing) – проверка, функционирует ли система как ожидается под разными языковыми локализациями операционных систем
Тестирование совместимости (compatibility testing) - проверка, что приложение совместимо с определенными конфигурациями оборудования, операционными системами, базами данных, браузерами, и т.д.
Процесс тестирования.
Этапы и задачи
Тестирование — это проверка соответствия программного обеспечения требованиям, осуществляемая с помощью наблюдения за его работой в специальных, искусственно построенных ситуациях. Такого рода ситуации называют тестовыми или просто тестами.
Тестирование — конечная процедура. Набор ситуаций, в которых будет проверяться тестируемое программное обеспечение, всегда конечен. Более того, он должен быть настолько мал, чтобы тестирование можно было провести в рамках проекта разработки программного обеспечения, не слишком увеличивая его бюджет и сроки. Это означает, что при тестировании всегда проверяется очень небольшая доля всех возможных ситуаций. По этому поводу Дейкстра (Dijkstra) заметил, что тестирование позволяет точно определить, что в программе есть ошибка, но не позволяет утверждать, что там нет ошибок.
Тем не менее, тестирование может использоваться для достаточно уверенной вынесения оценки качества программного обеспечения. Для этого необходимо иметь критерии полноты тестирования, описывающие важность различных ситуаций для оценки качества, а также эквивалентности и зависимости между ними. Этот критерий может утверждать, что все равно в какой из ситуаций, A или B, проверять правильность работы программного обеспечения, или, если программа правильно работает в ситуации A, то, скорее всего, в ситуации B все тоже будет правильно. Часто критерий полноты тестирования задается при помощи определения эквивалентности ситуаций, дающей конечный набор классов ситуаций. В этом случае считают, что все равно, какую из ситуаций одного класса использовать в качестве теста. Такой критерий называют критерием тестового покрытия, а процент классов эквивалентности ситуаций, случившихся вовремя тестирования, — достигнутым тестовым покрытием.
Таким образом, основные задачи тестирования - построить такой набор ситуаций, который был бы достаточно представителен и позволял бы завершить тестирование с достаточной степенью уверенности в правильности программного обеспечения вообще, и убедиться, что в конкретной ситуации программное обеспечение работает правильно, в соответствии с требованиями.
Процесс тестирования иллюстрируется схемой рис. 31.
Рис. 31. Схема процесса тестирования
Тестирование — наиболее широко применяемый метод контроля качества. Для оценки многих атрибутов качества не существует других эффективных способов, кроме тестирования.
Организация тестирования программного обеспечения регулируется следующими стандартами:
· IEEE 829-1998 Standard for Software Test Documentation. Описывает виды документов, служащих для подготовки тестов.
· IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing. Описывает организацию модульного тестирования (см. ниже).
· ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 и ГОСТ Р-2000, также принят IEEE под номером IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing. Описывает требования к процедурам тестирования программных систем.
Принципы организации тестирования
Основными принципами организации тестирования являются следующие:
1) Программирующая организация не должна сама тестировать разработанные ею программы
2) Необходимо досконально изучать результаты применения каждого теста.
3) Тесты для неправильных и непредусмотренных входных данных
4) следует разрабатывать так же тщательно, как для правильных и предусмотренных
5) Необходимо проверять не только, делает ли программа то, для
6) чего она предназначена, но и не делает ли она то, что не должна делать
7) Не следует выбрасывать тесты, даже если программа уже не нужна
8) Нельзя планировать тестирование в предположении, что ошибки
9) не будут обнаружены
10) Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части
11) Тестирование — процесс творческий.
Программирующая организация не должна сама тестировать разработанные ею программы.
Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости. Одна из причин такой системы оценок состоит в том, что временные и стоимостные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы. Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, поскольку тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшения вероятности соответствия программы заданным временным и стоимостным параметрам.
Программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно. Экономически более целесообразно выполнение тестирования объективным, независимым подразделением. В некоторых организациях подобная практика существует, но только на этапах комплексной отладки. Подобный способ тестирования чрезвычайно сложно реализовать из-за организационных трудностей.
Необходимо досконально изучать результаты применения каждого теста.
Большая часть всех обнаруженных в конечном итоге ошибок могла быть пропущена вследствие недостаточно тщательного анализа результатов первого тестового прогона.
Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных.
При тестировании программ имеется естественная тенденция концентрировать внимание на правильных и предусмотренных входных условиях, а неправильным и непредусмотренным входным данным не придавать значения. Например, при тестировании задачи о треугольниках, лишь немногие смогут привести в качестве теста длины сторон 1, 2 и 5, чтобы убедиться в том, что треугольник не будет ошибочно интерпретирован как неравносторонний. Множество ошибок можно также обнаружить, если использовать программу новым, не предусмотренным ранее способом. Вполне вероятно, что тесты, представляющие неверные и неправильные входные данные, обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным.
Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.
Это логически просто вытекает из предыдущего принципа. Необходимо проверить программу на нежелательные побочные эффекты. На пример, программа расчета зарплаты, которая производит правильные платежные чеки, окажется неверной, если она произведет лишние чеки для работающих или дважды запишет первую запись в список личного состава.
Не следует выбрасывать тесты, даже если программа уже не нужна.
Эта проблема наиболее часто возникает при использовании интерактивных систем отладки. Обычно тестирующий сидит за терминалом, на лету придумывает тесты и запускает программу на выполнение. При такой практике работы после применения тесты пропадают. После внесения изменений или исправления ошибок необходимо повторять тестирование, тогда приходится заново изобретать тесты. Как правило, этого стараются избегать, поскольку повторное создание тестов требует значительной работы. В результате повторное тестирование бывает менее тщательным, чем первоначальное, т. е. если модификация затронула функциональную часть программы и при этом была допущена ошибка, то она зачастую может остаться необнаруженной.
Эту проблему почти полностью решают современные инструментальные средства тестирования, однако, она перешла в область организации труда разработчика.
Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены.
Такую ошибку обычно допускают руководители проекта, использующие неверное определение тестирования как процесса демонстрации отсутствия ошибок в программе, корректного функционирования программы.
Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части.
Этот принцип не согласуются с интуитивным представлением. На первый взгляд он лишен смысла, но, тем не менее, подтверждается многими программами. Например, допустим, что некоторая программа состоит из модулей или подпрограмм A и B. К определенному сроку в модуле A обнаружено пять ошибок, а в модуле B –только одна, причем модуль A не подвергался более тщательному тестированию. Тогда из рассматриваемого принципа следует, что вероятность необнаруженных ошибок в модуле A больше, чем в модуле В. Справедливость этого принципа подтверждается еще и тем, что для ошибок свойственно располагаться в программе в виде неких скоплений. В качестве примера можно рассмотреть операционные системы IBM S/370. В одной из версий операционной системы 47 % ошибок, обнаруженных пользователями, приходилось на 4 % модулей системы.
Интуитивно понятно, что ошибки могут группироваться в частях программы (модулях), разрабатываемых программистами низкой квалификации, или в модулях, в которых слабо проработана общая идея. Раннее выявление таких модулей – залог эффективного процесса тестирования. Преимущество рассматриваемого принципа заключается в том, что он позволяет ввести обратную связь в процесс тестирования. Если в какой-нибудь части программы обнаружено больше ошибок, чем в других, то на ее тестирование должны быть направлены дополнительные усилия.
Тестирование — процесс творческий.
Вполне вероятно, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования. Выше было показано, что нельзя дать гарантию построения теста, обнаруживающего все ошибки.
Планирование тестирования
Основным документом является Тест план.
Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Он содержит
1. Перечень тестовых ресурсов.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию:
o Анализ функций и подсистем с целью определения слабых мест, требующих исчерпывающего тестирования (участков функциональности, где появление дефектов наиболее вероятно).
o Определение стратегии выбора входных данных для тестирования. Поскольку в реальных применениях множество входных данных программного продукта практически бесконечно, выбор конечного подмножества для проведения тестирования является сложной задачей. Для ее решения могут быть применены методы покрытия классов входных и выходных данных, анализ крайних значений, покрытие случаев использования и тому подобное. Выбранная стратегия должна быть обоснована и задокументирована.
o Определение возможности автоматизации процесса тестирования. При этом решение об использовании существующей, либо о создании новой автоматизированной системы тестирования должно быть обосновано, а также продемонстрирована оценка затрат на создание новой системы или на внедрение уже существующей.
4. График (расписание) тестовых циклов.
5. Указание конкретных параметров аппаратуры и программного окружения.
6. Определение тестовых метрик, которые необходимо собирать и анализировать (например, покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п.).
Тест план должен определять:
· Критерии начала тестирования:
o готовность окружения
o готовность тест кейсов
o законченность разработки требуемого функционала
o выполнение юнит-тестов
o билд построен и удовлетворяет определенным критериям
o и т.п.
· Критерии окончания тестирования:
o результаты тестирования удовлетворяют определенным критериям
o требовния к количеству открытых багов выполнены (определяются заранее)
o и т.п....
· Критерии передачи системы для приемочного тестирования:
o Приемочные тесты – где хранятся и когда выполняются
o Процедура приемки
· Риски и их разрешение
· Метрики и отчеты:
o Продуктовые метрики – кто собирает, с какой периодичностью…
o Отчеты - кто создает, кому отправляет, и т.п.
В тестировании используется понятие тестового случая.
Тестовый случай (Test Case) – это
– минимальный элемент тестирования (всего одна верификация\проверка)
– совокупность шагов, конкретных условий и параметров, необходимых для проверки тестируемой функции или ее части
– описание определенных действий и условий, которые необходимы для того, чтобы выявить ту или иную ошибку (баг, дефект).
Описание Тестового случая (Test Case) приведено на рис. 32.
Рис. 32. Структура тестового случая
Хороший тест обладает следующими свойствами:
– Существует большая вероятность выявления тестом ошибки;
– Не является избыточным в наборе тестов;
– Наилучший в своей категории;
– Не слишком сложный и не слишком простой;
– Условия, шаги и ожидаемый результат описаны однозначно и понятно
– Объемы входных данных не должны быть очень большими.
Оценка качества тестов
Тесты нуждаются в контроле качества так же, как и тестируемый продукт. Для оценки качества тестов используются различные методы, наиболее популярные из которых следующие.
1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит или о неэффективности тестов (когда большое количество тестов находит мало дефектов), или о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, отнесенное к времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.
|
|
|
