☰

Как команда Ubuntu проводит автоматизированное тестирование?

tag-icon • tag-icon canonical quality
Как команда Ubuntu проводит автоматизированное тестирование?

Каким образом команда Ubuntu гарантирует, что ошибки больше не возникнут?

Я видел это несколько раз. Пакет не может быть использован после установки.

Да, иногда ошибки исправляются очень быстро.

Но я не вижу никаких усилий по улучшению автоматизированного тестирования, чтобы ошибка не появлялась снова.

Вот два примера, которые повлияли на меня за последние две недели:

Есть и другие примеры, но их перечисление не входит в задачу.

Один комментарий со vsftpстраницы ошибки:

Пожалуйста, помогите нам, протестировав этот новый пакет. Смотретьhttps://wiki.ubuntu.com/Testing/EnableProposedдля документации о том, как включить и использовать -proposed. Ваш отзыв поможет нам распространить это обновление среди других пользователей Ubuntu.

Хорошо, но «тестирование» в приведенной выше цитате — эторуководствотестирование.

Для обеспечения качестваавтоматизированныйнеобходимо тестирование.

Для меня ручное тестирование — пустая трата времени. С другой стороны, создание автоматизированных тестов гарантирует качество.

И снова вопрос:

Каким образом команда Ubuntu гарантирует, что ошибки не возникнут снова?

История этого вопроса

Сначала заголовок был «Как команда Ubuntu гарантирует, что ошибки не появятся снова?». Теперь он стал «Как команда Ubuntu проводит автоматизированное тестирование?». Это было сделано, потому что я считаю, что ручное тестирование не является решением. Пожалуйста, не голосуйте против ответов, которые только объясняют, как выполняется ручное тестирование.

решение1

В Ubuntu есть автоматизированное тестирование. Например, автоматизированное тестирование используется для предотвращения повторения вашего первого примера ошибки. Я был тем, кто исправил первую ошибку vsftpd, о которой вы упомянули, и при этом я также добавил автоматизированный тест, чтобы предотвратить повторение той же самой ошибки. Вы можете увидеть это в записи журнала изменений, которая была опубликована для самой ошибки:

vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium

  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
    calls (LP: #1219857).
  * Add dep8 smoke test.
 -- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000

Я не знаю, почему вы считаете ошибку примером отсутствия автоматизированного тестирования, так как я несколько раз упоминаю об этом в ошибке. Например, я сказал "тест dep8 добавлен для обнаружения этого в будущем" и "Включенный тест dep8 автоматически проверяет исправление этой ошибки" в резюме.

Помните, что Ubuntu — это дистрибутив: это интегрированная совокупность многих внешних проектов, которые мы называем апстримами. Ubuntu не был бы возможен без работы других в более широкой экосистеме свободного ПО, и мы также часто зависим от авторов апстрима в предоставлении тестов, поскольку они являются экспертами в своем программном обеспечении.

Кроме того, поскольку мы являемся совокупностью различных проектов, единая инфраструктура автоматического тестирования не имеет смысла. Разные области имеют разные потребности. Поэтому наша стратегия тестирования достаточно широко распространена, чтобы соответствовать этим потребностям, охватывая как ручное, так и автоматизированное тестирование с помощью ряда различных инфраструктур.

Там, где проекты upstream предоставляют автоматизированные тесты, мы запускаем их как часть сборки пакета. Сборка пакета завершается неудачей, если тесты не пройдены. Обеспечение того, чтобы любое доступное автоматизированное тестирование было включено таким образом, является частью нашейтребования к основному включению:Если пакет содержит набор тестов и нет очевидной причины, по которой он не может работать во время сборки (например, для этого требуются права root или сетевой доступ), его следует запустить во время сборки пакета, а не прошедший набор тестов должен привести к сбою сборки.

Кроме того, мы проводим «автоматическое тестирование установленного пакета» на основе спецификации, называемойdep8, который предназначен для проверки того, что интеграция между пакетами работает правильно. Обновления пакетов, которые регрессируют тесты dep8, не попадают в выпуск разработки, пока они не будут исправлены.

Я менее знаком с автоматизированным тестированием, проводимым командами настольных компьютеров и телефонов, но я знаю, что существует больше механизмов, поскольку я видел ссылки на них на протяжении многих лет, и это включает автоматизированное тестирование GUI, которое, по моему мнению, весьма впечатляет. Я приветствую еще один ответ, который охватывает автоматизированное тестирование настольных компьютеров и телефонов.

решение2

Несколькими способами.

  1. Множество глаз.

    Ubuntu — это Open Source, то есть любой может посмотреть на код и увидеть, в чем проблема. Люди, которым интересно посмотреть на код, часто находят в нем ошибки или в процессе его использования, исообщите о них на launchpadиобщественность может даже исправить их.

    Когда вы протестировали его и предложили исправление, вы запрашиваете слияние с основным пакетом Ubuntu. Другие разработчики рассматривают это изменение и, если оно одобрено, добавляют его.

    Поскольку любой может их исправить, их быстро замечают, и они рассматриваются, они менее склонны задерживаться на некоторое время. Это приводит к следующему пункту.

    К таким глазам относятся также компьютерные глаза:

    Процесс QA вверх по течению должен быть задокументирован/продемонстрирован и связан с ошибкой отслеживания SRU. В других случаях, когда такое автоматическое тестирование вверх по течению недоступно...

    Что показывает, что обычно автоматическое тестирование проводится.

  2. Бета-релизы

    До того, как Ubuntu будет выпущена для широкой публики, существуют бета-версии. В настоящее время это 15.10 Beta, которая будетвыпущено 22 октября 2015 г.. Множество людей будут использовать, просматривать и исправлять ошибки до того, как он будет выпущен (например,5 месяцев 22 дняв этом случае).

    Это означает, что любые ошибки устраняются оперативно (благодаря Many Eyes), а обычные пользователи не страдают, поскольку они исправляются до официального релиза.

  3. Эксперты по написанию кода

    Люди, которые умеют писать качественный код, — это те, кто пишет код. Не один человек сидит и пишет Ubuntu вот так:

    Есть люди со всего мира, и люди, работающие в Canonical, компании, стоящей за Ubuntu. Все эти люди вносят немного нового кода. Если я напишу 2000 строк кода, будет много ошибок. Если 200 человек напишут всего 10, их будет намного меньше.

  4. Стабильные основы

    Насколько мне известно, Ubuntu не переписывается с нуля каждый раз, когда выходит новый релиз. Вместо этого следующая версия начинается как текущая версия (т. е. 30.04.2015 и 15.10, и 15.04 были одинаковыми), и оттуда добавляются новые функции.

    Если у вас есть хорошая база для работы, то вам придется писать меньше кода, и вы можете доверять тому, что уже существует. Если вы можете положиться на то, что есть, то будет меньше ошибок.

  5. Программное обеспечение для управления версиями и записи

    Если одна и та же ошибка возникает более одного раза (в разных версиях, или исправление не сработало, или ошибка вернулась из-за другого патча), то у них есть документация, объясняющая, как она была исправлена, и они могут исправить ее снова.

Насколько я могу судить, автоматизированных тестов нет. Но что такое автоматизированный тест? Если он компилируется, то это он? Нельзя просто сказать "автоматизированные тесты", не объяснив, что это такое

решение3

Не пишите код с ошибками. lol ok. Я потерял желание писать подробный ответ на это. Вот приличная статья: https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf

и вот хорошая книга о том, как делатьошибки в C++

Лучшим ответом может быть просто взяться за некоторые задачи по разработке ПО и посмотреть, откуда берутся проблемы. Обработка неожиданных входных данных/результатов является довольно большой проблемой по моему опыту. Затем идут ошибки в нисходящем потоке. Например, кто-то находит уязвимость в iostream.h, и каждая часть ПО, которая вызывает эту библиотеку, затем может также иметь эту ошибку, нужно как минимум проверить.

Что касается автоматизированного тестирования, оно существует, но у него также есть ограничения. Я не знаю ни одного решения, которое работало бы на всех языках. Если вам действительно интересно, напишите нам генетический отладчик кода с некоторым ИИ. Насколько мне известно, все это пока находится в зачаточном состоянии. Вот некоторые работы аспирантов: https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf

Связанный контент