О тестировании web-приложений

    Тестирование софта это процесс, участвующий во всех жизненных циклах его разработки, который занимается проверкой и планированием требований продукта, подготовкой и проведением изменений в разрабатываемой системе. Как следствие — находятся несоответсвия требованиям и ошибки, оцениваются инструменты которые были использованы.
    А если отвлечься и рассматривать системно, то роль тестера на самом деле лежит в каждом человеке. Если смотреть на проект как на человека, то роли
    • управляющего проектом это позвоночник и вегетативная нервная система
    • программисты это скелет и моторика
    • аналитики это органы чувств
    • тестеры это совесть

    Quality Assurance часто считается синонимом тестирования, но на самом деле это методика предотвращения ошибок, а не их поиска и исправления. Качество в этом смысле — характеристика сделанного продукта.

    Формально говоря, тестер должен проверять даже техническое задание, план проекта и анализ на логичность и понятность, а не только код и интерфейс программы. Тестирование как независимая дисциплина в общем потоке разработки ПО появилась в начале девяностых, когда стали более важны аудитория (клиенты), качество и время разработки.
    Важность тестирования ПО особенно важна в критических системах. К примеру аппарат по лучевой терапии Therac (1985) облучил смертельной дозой радиации 6 человек из-за отсутсвия проверки состояния агрегата в коде и валидации. Или марсоход в 1999 году принёс убыток в 125 млн долларов из-за непродуманности единой системы измерения между коммандами разработчиков. И даже в Эстонии при электронных выборах были проблемы из-за плохого нагрузочного тестирования.
    Основные принципы тестирования воплощены в небольшом документе ISTQB и в книге «Foundations of software testing».
    Вся «прелесть» специальности тестера в том что как правило для этого не нужны большие познания в программировании и люди далёкие от web-строительства могут себя попробовать в этой роли.

    Организационный процесс


    Тестирование как часть работы компании над проектом может проходить либо в waterfall-подходе, где под тестер подтягивается лишь под конец проекта, либо по agile-методологии, где с каждой итерацией выкатывается готовая версия.




    Итерация тестирования состоит из следующих пунктов
    1. Планирования. Определяются цели, инструменты, время, порядок. Самая психологически сложная часть — понять и запомнить как система должна работать, особенно когда нет технического задания, документации и вменяемого управляющего проектом (см. exploratory testing ниже)

      Посему у тестера хотя-бы внутренний, но анализ состоит из…
      • Условий (conditions)
      • Истории взаимодействий (cases)
      • Воплощение в виде документа (basis) со ссылками на спецификацию, архитектуру и прочие документы (коли они есть)

    2. Проверки. В случае недоступностей и непонятностей — когда и с кем связаться что-бы задание не забылось.
      • Приоритезация тест-case'ов (обычно 1 case = 1 требование = 1 web-страница). Какие сценарии самые критичные? Какие в разработке и наиболее рискованные?
      • Группировка тестов в комплекты (suite) по общим модулям
      • Проверка и сравнение с требованиями (собственно поиск ошибок)
      • Написание рапорта (как багов, так и общей картины — процент покрытия)
      • Перепроверка изменнённой части (confirmation, retesting) или влияние на неизменённые части (regression testing)

    3. Завершение. Архивация тестов, сохранение полученных уроков.


    Уровни тестов


    У тестов есть свои уровни, иерархия и классы (привет игроки RPG!). Проверять можно как разные части приложения (то есть по площади, по страницам), так и разные свойства этого участка (то есть в глубину, степени качества). Вот по размерам площадок можно тесты разбить на категории...
    • Модульные (unit-testing). Полуавтоматическое тестирование, в том плане что тесты приходится писать программисту в очень тесном контакте с кодом классов которые unit-тест должен проверить. Не обязательно следовать TDD, можно написать хотя-бы для самых критичных частей (финансовые операции и тп.)
    • Интеграционные (integration testing) проверяют связи между разными модулями. Можно делать как до общей интеграции системы (модуль за модулем), так и после (пишем, пишем, сложим — протестим до финального acceptance-теста). Тут опять тесная работа с кодом и программистами.
    • Системные — пройтись по всей системе и найти несоответсвие общим стандартам и спецификации в целом. Как правило под конец, когда система в основном готова.
    • Acceptance-тест проходит как правило уже с клиентом при передаче проекта и показывает готовность работы с клиентами. Именно на этой стадии появляются альфа версии (всё лежит ещё вероятно у разработчика на машине, привлекаются сторонние тестеры) и бета версии (всё уже лежит у клиента, привлекаются потенциальные клиенты)

    Типы тестов


    Теперь собственно по сути тестирования..
    • Функциональные отвечают на вопрос «что» должно делать приложение
    • Нефункциональные требования/тесты отвечают на вопрос «как». Нефункциональные включают в себя свойства удобства интерфейса, надёжности, безопасности данных, масштабируемости, кроссплатформенности и даже экономической целесообразности (см. ISO/IEC 9126)
    • Внешние (black box) / Внутренние (структурные, white box). Структурное тестирование проверяет внутреннюю структуру приложения как оно реализовано, но нуждается в понимании кода. Подход «чёрного ящика» исходит из того что ПО ещё не реализовано либо мы не знаем его точной работы, зато есть спецификация как должно всё работать. Структурные (white box) подходы тестируют приложение снизу вверх, концентрируясь на максимальном покрытии кода (а не комбинаций входа-выхода в интерфейсе). Обычно white box подходы используются в дополнение к чёрному ящику (как должно работать).
    • Регрессионное тестирование — а не поломалось ли что-то из-за этого изменения? Как правило именно это надо связывать с unit-тестированием для большей автоматизации
    • Тест-поддержка (maintenance testing) — система уже работает и мы просто её обновляем (deploy & migration). Миграции в последнее время тоже как правило автоматизируются.
    • Динамическое / статическое тестирование. Динамическое подразуемевает интерактив, работу с готовой системой или кодом. Это не всегда обязательно и возможно. Теоретически можно тестировать документацию или проверять логичность анализа, находить ошибки из логов и тп.

    Тестеры как и «писатели тех-задания» для самоконтроля всегда должны помнить аббревиатуру SMART, что-бы их правильно поняли более практичные люди.
    • Specific — точное описание требования, без копи-пастов переписки с клиентом, чатом, дампом данных и односложными предложениями
    • Measureable — измеряемое значение чисел, времени, вероятности, пользователей, местоположения.
    • Attainable — технически-достижимые требования. Не всё ещё возможно технически, вперёд прогресса не угонишься
    • Realizeable — человечески-достижимые людские требования по времени, качеству, знанию, цене
    • Traceable — соответсвие изначальной идее и цели, логичность соответсвия нескольких требований.






    Black box техники


    Ad-hoc (monkey) — случайное тестирование без определённой стратегии
    Исследовательское тестирование (exploratory testing) — изучение продукта если документация во многом отсутствует
    Группировка ошибок по эквивалентным классам (equivalence partitioning). Самый популярная методика. Каждый вход проверяется на требования (по длине символов, возможных значениях). В тестах для минизации их количества классы разных входов комбинируются что-бы сделать максимальное покрытие ошибок.
    Ещё одна техника существует преимущественно для целочисленных значений. Ошибки как правило возникают в пограничных значениях, поэтому методика так и называется (boundary value analysis). Выбираются два или три значения возле границы. Например если максимальная длина заголовка 250 символов, то как будет выдаваться ошибка при 249, 250 и 251 значении?
    Более приближенная к динамическим системам есть методика проверки перехода состояний (state transition testing). Состояние зависит от входа и от предыдущего состояния. Состояния и переходы описываются графами (finite state machine).
    Таблица решений (decision table testing) сама собой приходит в голову когда бизнес-правила в приложении очень сложные и нуждаются в больших математических вычислениях. С помощью таблиц можно минимизировать число уникальных комбинаций
    Тестирование сценариев (use-case based) проходит согласно созданных в анализе сценариях, с учётом разных ролей, альтернативных потоков.
    Интуитивно-опытное тестирование (experience-based) как уже понятно приходит у человека со временем и позволяет находить систематические ошибки дизайна, программистов, потока данных с учётом изменения кода.

    White box (структурные) техники


    Цель структурных техник — максимально покрыть тестами код (code coverage), а поскольку white box используется как дополнение к сценарным техникам, то логично, что есть и максимальное покрытие сценариев или, точнее, их разветвлений (statement & decision coverage).
    Математически процент покрытия = 100% * число покрытых единиц / число всех единиц. Это не значит, что будет всё протестировано, только выбранные единицы тестирования (coverage item). Единицы тестирования для каждой роли по разному выглядят — для разработчиков это таблицы БД, функции в коде, запрос к внешнему компоненту, тогда как для тестера и аналитика это действия в сценарии, классы эквивалентности.
    Поднимаясь выше над единицами тестирования можно увидеть предложения и соответственно покрывать их (statement coverage). Хорошее тестирование с методиками чёрного ящика могут покрыть до 60-75% предложений. В плане кода это конкретная строка
    Покрытие разветвлений (decision coverage) уже более высокий уровень, включает все типы иерархии (if-else, switch, вызовы методов и тп.). Методами чёрного ящика можно покрыть 40-60%. Циклическая сложность (cyclomatic complexity) — проверка алгоритма известная всем информатикам на квадратичную, экспоненциальную и логарифмическую сложность.
    Следующая степень покрытия включает возможные пути по которым можно пройти по разветвлениям. Теоретически этих путей бесконечно много если учитывать ещё и все циклы.

    Инструменты



    Наиболее знакомые инструменты программистом это конечно системы отслеживания ошибок (bug/issue tracking) — Mantis, Bugzilla и Trac. Некоторые IDE могут интегрироваться с ними так, что commit-действии в репозиторий версионной системы (SVN/CVS/Git/Mercurial) можно обновить баг без работы в браузере.


    Есть и более общие, индустриальные продукты включающие в себя и составление требований, группировку сценариев — HP (Mercury) Quality Center и IBM Rational Quality Manager


    Автоматизированное тестирование интерфейсов сейчас наиболее популярно с помощью Selenium, SilkTest, HP QuickTest Pro, QF-Test, Rational Robot, TestComplete, Watir, TestPartner. Есть и более экзотические тесты типа soapUI.








    Нагрузочное тестирование чуть более сложное, потому что нужны дополнительные машины (скажем одна машина симулирует 300 пользователей-соединений) — на одной машине запускать 3000 соединений как правило невозможно. Инструменты:




    Оригинал статьи

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 6

      0
      че то перевод не осилил комикса, напишешь?
        0
        Жаль что народу оказалась не особо интересна эта тема. Было интересно почитать и рассусоливания на тему…
          0
          Народу может и нет, а отдельным персонажам даже очень.
          Вот только тема, кажется, широковата для одного поста. И текст содержит в основном определения, вроде нету особого материала для обсуждения. Что хорошо, про то не скажешь плохо. Мало кто возьмет на себя смелость заявить, что тестирование — не нужно и вредно (вот на такое комментов, наверно, было бы много).
            0
            Было бы интересно почитать рассусоливания, например, на такие темы. Может, некоторые скользкие, но зато интересно. Тестирование сложных отчетов. Генерация тестовых данных. Практика модульного тестирования при разработке приложений над большой БД (а вы перегенерируете базу после каждого теста?) Насколько полны и полезны автоматизированные тесты веб-интерфейсов. Требует ли работа тестировщика интеллекта и квалификации? Правда ли, что тестировщик произошел от обезьяны? Почему многие думают, что тестирование — это первое, чем надо пожертвовать при сокращении бюджета?
            И вообще, почему опять в релизе полно багов? :)
            0
            Хорошая статья.

            Кстати там есть одна ошибка:
            «Самый популярная методика.» -> «Самая»
              0
              Спасибо за статью! Привёл в порядок свои знания. (сорри за запоздалый коммент! Как говоиртся, лучше поздно, чем...)

              Only users with full accounts can post comments. Log in, please.