Comments 12
В рассчете процента покрытия тестов хорошо бы добавить еще одни скобки?:
Процент_покрытия = 100 — (((количество_todocase-тестов + количество_manual-тестов) / общее_количество_тестов_в_проекте) * 100).
Процент_покрытия = 100 — (((количество_todocase-тестов + количество_manual-тестов) / общее_количество_тестов_в_проекте) * 100).
dimkss Спасибо за совет! Переписал формулу, сделал её в целом более читаемой.
Интересная статья, спасибо.
Несколько вопросов по поводу показателя покрытия UI тестов:
1) Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?
2) Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.
3) Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружновыбрасывается в окно начинает работать по ночам?
Несколько вопросов по поводу показателя покрытия UI тестов:
1) Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?
2) Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.
3) Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно
nizkopal, спасибо!
1. «Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?»
Доверяем мы ему настолько, что на данный момент это наш единственный способ подсчета метрики покрытия UI-тестами. Про понимание того, что все кейсы описаны в тестах: Понимание основано на том, что тесты и описание к ним хранятся в одном месте, т.е у нас просто нет дублирующей системы хранения тест-кейсов, если QA-специалисту нужно добавить в систему регрессионный тест, то он так или иначе идет в код и в нем может сразу создать тест или написать описание с минимальной «заготовкой» под тест. И замечу, что у нас нет цели добавить в систему все кейсы, мы очень гибко подходим к каждому проекту и формируем для проектов именно то покрытие, которое им необходимо, не тратя лишние ресурсы.
2. «Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.»
При постановке задач на расширение покрытия приоритет todocase, конечно, играет роль, QA-специалист в большинстве случаев сам может принять решение по приоритетам, поэтому чаще всего приоритеты мы в описание не пишем, но делать это можно.
3. «Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно начинает работать по ночам?»
Начну с того, что желаемый процент покрытия проекта изначально согласовывается с менеджером продукта и на этот процесс выделяются необходимые ресурсы. Если процент покрытия в проекте падает, то чаще всего это означает то, что новые функциональные возможности в команде создаются без процесса актуализации тестового покрытия, что является нарушением производственного процесса. Поэтому QA-специалисты в первую очередь разбираются с этой проблемой, а затем планомерно (без авралов и работы по ночам) увеличивают процент покрытия до необходимого значения.
1. «Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?»
Доверяем мы ему настолько, что на данный момент это наш единственный способ подсчета метрики покрытия UI-тестами. Про понимание того, что все кейсы описаны в тестах: Понимание основано на том, что тесты и описание к ним хранятся в одном месте, т.е у нас просто нет дублирующей системы хранения тест-кейсов, если QA-специалисту нужно добавить в систему регрессионный тест, то он так или иначе идет в код и в нем может сразу создать тест или написать описание с минимальной «заготовкой» под тест. И замечу, что у нас нет цели добавить в систему все кейсы, мы очень гибко подходим к каждому проекту и формируем для проектов именно то покрытие, которое им необходимо, не тратя лишние ресурсы.
2. «Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.»
При постановке задач на расширение покрытия приоритет todocase, конечно, играет роль, QA-специалист в большинстве случаев сам может принять решение по приоритетам, поэтому чаще всего приоритеты мы в описание не пишем, но делать это можно.
3. «Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно начинает работать по ночам?»
Начну с того, что желаемый процент покрытия проекта изначально согласовывается с менеджером продукта и на этот процесс выделяются необходимые ресурсы. Если процент покрытия в проекте падает, то чаще всего это означает то, что новые функциональные возможности в команде создаются без процесса актуализации тестового покрытия, что является нарушением производственного процесса. Поэтому QA-специалисты в первую очередь разбираются с этой проблемой, а затем планомерно (без авралов и работы по ночам) увеличивают процент покрытия до необходимого значения.
Спасибо за обстоятельную публикацию. Есть два вопроса.
Время прохождения тестов по проектам на Production
Вы тесты на проде выполняете? Зачем?
И второй: Насколько я понял вы написали собственную реализацию приёмочных UI-тестов поверх webdriver для phpunit? И не совсем понятно тогда, что за отчёт генерится, о каком покрытии здесь речь...
samizdam, спасибо!
1. «Вы тесты на проде выполняете? Зачем?»
Да, мы выполняем специальный комплект тестов на Production. В первую очередь это нужно для того, чтобы гарантированно предоставлять нашим клиентам высокий уровень сервиса. Production-окружение имеет ряд отличий от наших stage-систем, как на «железном» уровне, так и на уровне контента, поэтому выполнение тестов полностью оправдано и нас отдельно радует то, что тесты на Production практически всегда так, как мы и ожидаем — это результат большой работы.
2. «Насколько я понял вы написали собственную реализацию приёмочных UI-тестов поверх webdriver для phpunit? И не совсем понятно тогда, что за отчёт генерится, о каком покрытии здесь речь…»
В основе нашей системы лежит PHPUnit, при помощи него осуществляется непосредственный запуск каждого теста. В статье не идет речь про компонент PHP_CodeCoverage, мы формируем отчет о покрытии проекта UI-тестами и строим его на основе тех данных, которые несут сами тесты в своем описании при помощи специальных лейблов.
1. «Вы тесты на проде выполняете? Зачем?»
Да, мы выполняем специальный комплект тестов на Production. В первую очередь это нужно для того, чтобы гарантированно предоставлять нашим клиентам высокий уровень сервиса. Production-окружение имеет ряд отличий от наших stage-систем, как на «железном» уровне, так и на уровне контента, поэтому выполнение тестов полностью оправдано и нас отдельно радует то, что тесты на Production практически всегда так, как мы и ожидаем — это результат большой работы.
2. «Насколько я понял вы написали собственную реализацию приёмочных UI-тестов поверх webdriver для phpunit? И не совсем понятно тогда, что за отчёт генерится, о каком покрытии здесь речь…»
В основе нашей системы лежит PHPUnit, при помощи него осуществляется непосредственный запуск каждого теста. В статье не идет речь про компонент PHP_CodeCoverage, мы формируем отчет о покрытии проекта UI-тестами и строим его на основе тех данных, которые несут сами тесты в своем описании при помощи специальных лейблов.
Прошу прощения, пропустил слово при ответе на первый вопрос: Тесты на Production проходят практически всегда так, как мы и ожидаем — это результат большой работы.
Спасибо за ответ. Вкупе с вашим ответом на предыдущий комментарий от другого автора, кажется теперь чуть понятней. Но не до конца.
Если для метрики покрытия используется кол-во описанных, но не реализованных тест кейсов, то как избежать следующей ситуации: Функциональность добавилась, тесты нет => покрытие осталось прежним…
Или я опять недопонял алгоритм рассчёта…
Если для метрики покрытия используется кол-во описанных, но не реализованных тест кейсов, то как избежать следующей ситуации: Функциональность добавилась, тесты нет => покрытие осталось прежним…
Тут вы абсолютно правы, если функциональность добавилась и QA-специалист не добавил в систему todocase или не написал тест, то покрытие останется прежним, по-другому можно сказать, что данная функциональность не была добавлена в регрессионные проверки.
Во первых хочу отметить, что действительно не каждая функциональность должна добавляться в регрессию, это зависит от многих факторов, а во вторых, в этом вопросе мы доверяем тестировщикам, они лучше всех знают когда в систему UI-тестирования нужно добавить тест или «заявку на покрытие» — todocase. Наша система, как и любая другая требует работы по актуализации :)
Понятно, спасибо.
Вы смотрели в сторону Codeception / Gherkin? Чем эти инструменты не угодили?
Первый, кстати, позволяет связать приёмочные тесты с покрытием исходного кода.
А второй позволяет использовать наиболее высокий из возможных уровней абстракций в приёмочном тестировании, наилучшим образом покрывая требование ваше первого и самого важного пункта.
Вы смотрели в сторону Codeception / Gherkin? Чем эти инструменты не угодили?
Первый, кстати, позволяет связать приёмочные тесты с покрытием исходного кода.
А второй позволяет использовать наиболее высокий из возможных уровней абстракций в приёмочном тестировании, наилучшим образом покрывая требование ваше первого и самого важного пункта.
Codeception пробовали/использовали — отказались по причине внутреннего для него meta-языка (например, $I->see('Home')), который нам совсем не подходит. Из-за этого пришлось писать обвязку над Codeception, которая дает возможность писать на «чистом» PHP, что в совокупности, архитектурно не очень хорошее решение.
Gherkin — не про нас, тоже навязывает свой мета-язык, который нам не близок.
Gherkin — не про нас, тоже навязывает свой мета-язык, который нам не близок.
Sign up to leave a comment.
Как мы в Tutu.ru добиваемся эффективности каждого из 9000+ UI-тестов