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

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

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

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

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

Вот два примера, которые повлияли на меня в течение последних двух недель:

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

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

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

Хорошо, но "тестирование" в приведенной выше цитате - это ручное тестирование.

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

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

Здесь снова вопрос:

Как команда Ubuntu уверяет, что ошибки больше не появляются?

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

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

Источник

3 ответа

Решение

У 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 <robie.basak@ubuntu.com> Tue, 29 Apr 2014 15:33:07 +0000

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

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

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

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

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

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

Источник

Ряд способов.

  1. Много глаз.

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

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

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

    Эти глаза также включают компьютерные глаза:

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

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

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

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

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

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

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

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

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

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

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

  5. Управление версиями и запись программного обеспечения

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

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

Источник

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

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

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

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

Источник
Другие вопросы по тегам