О требованиях к средствам автоматизации приемочных тестов при использовании подхода «разработка, управляемая описанием поведения» — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) (Batch edit: replace PCRE (\n\n)+(\n) with \2) |
||
(не показано 60 промежуточных версий этого же участника) | |||
== Аннотация == ;Докладчик: {{Speaker|Евгений Пышкин}} <blockquote> Задачей предлагаемого доклада мы видим обсуждение трудностей, возникающих при использовании подхода «разработка, управляемая описанием поведения» (Behavior Driven Development, BDD), который является одной из развивающихся практик гибкой методологии. В BDD преобразование пользовательских сценариев (которые, по сути, являются вариантами требований), написанных в повествовательной форме на языке, близком к естественному, к модульным тестам осуществляется за счет построения своего рода коммуникационной инфраструктуры, призванной лучше донести до разработчиков пользовательский контекст. Фактически, термин «тестирование» обозначает здесь совместную работу заказчика и разработчика по настройке этой инфраструктуры, в отличие от разработки через тестирование, которая скорее нацелена на улучшение взаимодействия разработчиков друг с другом, а не разработчиков с внешними заинтересованными лицами. Мы проанализировали различные инструментальные средства, реализующие концепции поведенческого тестирования. Установлено, что даже для тех реализаций, где правила преобразования пользовательских сценариев к модульным тестам строго определены, задачи автоматизированного преобразования далеки от полного решения. Многие из рассмотренных средств представлены как «поддерживающие запись приемочных тестов на естественном языке», хотя обычно речь идет о наличии существенных ограничений записи пользовательских сценариев. Наличие этих ограничений позволяет рассчитывать на получение автоматизированных средств преобразования, использующих современные решения в области обработки естественного языка, процедуры, основанные на эвристических правилах. По результатам исследования мы предлагаем контрольный список требований к средствам автоматизации определения и преобразования пользовательских сценариев, генерации соответствующих тестовых классов и обеспечения взаимодействия между этими компонентами в процессе запуска тестов и отладки разрабатываемого программного обеспечения.</blockquote> == Видео == {{vimeoembed|53064352|800|450}} <!-- pollholder --> <poll> ALTERNATIVE REVOTE UNIQUE Оцените доклад «{{PAGENAME}}»: Отлично! Хорошо. Нормально… Не очень :( Просто хочу узнать результаты. </poll> == Слайды == [[File:О требованиях к средствам автоматизации приемочных тестов при «разработке, управляемая описанием поведения».pdf|left|page=-|256px]] {{----}} == Примечания и отзывы == <!-- <blockquote>[©]</blockquote> --> * [http://2012.secrus.ruorg/talks/requirements-for-acceptance-testing-automation-tools-in-bdd Страница доклада на сайте конференции] * [http://www.secrus.ruorg/2012/presentations/pyshkin-mozgovoy-glukhikh_80_article.pdf Статья авторов] <references/> [[Category:SECR-2012]] [[Category:ToPublish]] [[Category:BDD]] [[Category:Автоматизированное тестирование]] <!-- topub --> {{stats|disqus_comments=0|refresh_time=2021-08-31T17:36:51.723741|vimeo_comments=0|vimeo_plays=76|youtube_plays=0}} |
Текущая версия на 12:22, 4 сентября 2021
Содержание
Аннотация
- Докладчик
- Евгений Пышкин
Задачей предлагаемого доклада мы видим обсуждение трудностей, возникающих при использовании подхода «разработка, управляемая описанием поведения» (Behavior Driven Development, BDD), который является одной из развивающихся практик гибкой методологии.
В BDD преобразование пользовательских сценариев (которые, по сути, являются вариантами требований), написанных в повествовательной форме на языке, близком к естественному, к модульным тестам осуществляется за счет построения своего рода коммуникационной инфраструктуры, призванной лучше донести до разработчиков пользовательский контекст. Фактически, термин «тестирование» обозначает здесь совместную работу заказчика и разработчика по настройке этой инфраструктуры, в отличие от разработки через тестирование, которая скорее нацелена на улучшение взаимодействия разработчиков друг с другом, а не разработчиков с внешними заинтересованными лицами.
Мы проанализировали различные инструментальные средства, реализующие концепции поведенческого тестирования. Установлено, что даже для тех реализаций, где правила преобразования пользовательских сценариев к модульным тестам строго определены, задачи автоматизированного преобразования далеки от полного решения.
Многие из рассмотренных средств представлены как «поддерживающие запись приемочных тестов на естественном языке», хотя обычно речь идет о наличии существенных ограничений записи пользовательских сценариев. Наличие этих ограничений позволяет рассчитывать на получение автоматизированных средств преобразования, использующих современные решения в области обработки естественного языка, процедуры, основанные на эвристических правилах.
По результатам исследования мы предлагаем контрольный список требований к средствам автоматизации определения и преобразования пользовательских сценариев, генерации соответствующих тестовых классов и обеспечения взаимодействия между этими компонентами в процессе запуска тестов и отладки разрабатываемого программного обеспечения.
Видео
Слайды
Примечания и отзывы
Plays:76
Comments:0