Стратегии Тестирования На Основе Моделей

[Есть несколько эссе, которые стоит прочитать на эту тему. Переполнение стека не позволит мне разместить более одного сообщения, поэтому я объединил их в блоге, связанном в конце этого ответа.]

Во-первых, короткая заметка об условиях. Я склонен использовать определение тестирования Джеймса Баха как “Questioning a product in order to evaluate it”. Все тесты основаны на моделях /mental/ тестируемого приложения. Однако термин тестирование на основе модели обычно используется для описания программирования модели, которую можно исследовать с помощью автоматизации. Например, можно указать ряд состояний, в которых может находиться приложение, различные пути между этими состояниями и определенные утверждения о том, что должно произойти при переходе между этими состояниями. Тогда можно заставить скрипты выполнять полуслучайные перестановки переходов внутри модели состояния, регистрируя потенциально интересные результаты.

Здесь есть реальные затраты: построение полезной модели, создание алгоритмов ее изучения, системы регистрации, позволяющие отсеивать интересные сбои и т.д. Разумны ли эти затраты или нет, во многом зависит от того, на какие вопросы вы хотите ответить? В общем, начните с “что я хочу знать? И как мне лучше всего узнать об этом?” вместо того, чтобы искать применение интересной технике.

Все это говорит о том, что некоторые отличные тестировщики получили большой пробег от автоматизированных тестов на основе моделей. Иногда у нас возникают важные вопросы о тестируемом приложении, которые лучше всего исследовать с помощью автоматизированных, объемных полу-рандомизированных тестов. Гарри Робинсон (один из ведущих теоретиков и сторонников модельного тестирования) описывает один очень красочный пример, когда он обнаружил много интересных ошибок в Google driving directions с помощью модельного теста (написанного с помощью библиотеки Watir ruby). Один

Робинсон успешно использовал MBT в таких компаниях, как Bell Labs, Microsoft и Google, и имеет ряд полезных essays.[2]

Бен Симо (еще один великий мыслитель и писатель в области тестирования) также написал довольно много достойных прочтения книг на основе моделей testing.[3]

Наконец, несколько предостережений: чтобы эффективно использовать стратегию, нужно изучить как ее сильные, так и слабые стороны. С этой целью Джеймс Бах провел отличную лекцию о границах и проблемах тестирования на основе моделей. Этот пост в блоге содержит ссылки Баха на его часовую беседу (и связанные с ней слайды).[4]

Я закончу заметкой о том, что Борис Бейзер называет Пестицидным парадоксом: "каждый метод, который вы используете для предотвращения или обнаружения ошибок, оставляет след более тонких ошибок, против которых эти методы неэффективны."Скриптовые тесты (независимо от того, выполняются ли они компьютером или человеком) особенно уязвимы для парадокса пестицидов, поскольку они имеют тенденцию находить все меньше и меньше полезной информации каждый раз, когда выполняется один и тот же сценарий. Люди иногда обращаются к тестированию на основе моделей, думая, что это позволяет обойти проблему пестицидов. В некоторых контекстах тестирование на основе моделей вполне может обнаружить гораздо больший набор ошибок, чем данный набор скриптовых тестов...но следует помнить, что он все еще принципиально ограничен парадоксом пестицида. Помня о его пределах — и начиная с вопросов, которые хорошо адресуются MBT-он может стать очень мощной стратегией тестирования.

Ссылки на все упомянутые выше эссе можно найти здесь: http://testingjeff.wordpress.com/2009/06/03/question-about-model-based-testing/

Гарри Робинсон, автор MBT-книг и много работавший с ним, например, в Google и Microsoft, имеет этот сайт с отличной информацией и белыми листами.

http://www.geocities.com/model_based_testing/

Мы не сделали ничего/много I&T и используем модульное тестирование почти исключительно, приправленное небольшим количеством системного тестирования. Но наше внимание явно сосредоточено на модульном тестировании. Я довольно строго отношусь к APIs we build/provide,, поэтому предположение заключается в том, что если он работает сам по себе, то он будет работать в сочетании, и в этом еще не было большой ошибки.

Наши модели ориентированы на одну цель/модуль с минимальным количеством зависимостей, насколько это возможно.

Фокус всегда заключается в том, чтобы начать как можно раньше (TDD-kinda), но, к сожалению, мы не всегда добираемся до этого. Проблема в том, что вы всегда должны продавать его руководству, а затем это трудно, потому что в то время как тестирование улучшает стабильность (в целом QA), люди со стороны (за пределами технологий) не могут по-настоящему понять, что это значит, пока не произойдет что-то плохое.

Поскольку мы используем PHP, мы используем PHPUnit для модульных тестов. В общем, мы делаем CI с различными различными инструментами. :)

Лучший способ-это попробовать самостоятельно инструмент тестирования на основе модели. Это лучший способ узнать, адаптировано ли тестирование на основе модели в вашем контексте. И какая стратегия является хорошей?

Я советую вам инструмент "MaTeLo" из All4Tec (www.all4tec.net)

"MaTeLo-это генератор тестовых случаев для функционального и системного тестирования черного ящика. В соответствии с подходом тестирования на основе модели, MaTeLo использует цепи Маркова для моделирования теста. Этот статистический аддин позволяет систематически проводить валидацию продуктов. Эффективность достигается за счет сокращения необходимых людских ресурсов, увеличения повторного использования модели и повышения релевантности тестовой стратегии (за счет целевого показателя надежности). MaTeLo является независимым и удобным для пользователя, предлагает к деятельности по проверке перейти от тестовых сценариев к реальной разработке тестов и сосредоточиться на реальной добавленной стоимости тестирования: планы тестирования"

Вы можете попросить лицензию на оценку и попробовать самостоятельно.

Вы можете найти некоторые исключения здесь: http://www.all4tec.net/wiki/index.php?название=учебники