Журнал фильтра правок

Фильтры правок (обсуждение) — это автоматизированный механизм проверок правок участников.
(Список | Последние изменения фильтров | Изучение правок | Журнал срабатываний)
Перейти к навигации Перейти к поиску
Подробности записи журнала 600 008

07:21, 26 июля 2011: 103 «Ссылка» 193.28.234.161 (обсуждение) на странице Регрессионное тестирование, меры: Метка (просмотреть)

Изменения, сделанные в правке



== Ссылки ==
== Ссылки ==
* [http://fixber.com/ Площадка услуг по тестированию сайтов и ПО]{{ref-ru}}
* [http://automated-testing.info/knowledgebase/article/chto-mozhet-predlozhit-avtomatizacija-testirovanija-ili-vygody-avtomatizacii-t Автоматизация регрессионного тестирования] {{ref-ru}}
* [http://automated-testing.info/knowledgebase/article/chto-mozhet-predlozhit-avtomatizacija-testirovanija-ili-vygody-avtomatizacii-t Автоматизация регрессионного тестирования] {{ref-ru}}
* [http://www.javenue.info/post/24 Регрессионное тестирование (regression testing)] {{ref-ru}}
* [http://www.javenue.info/post/24 Регрессионное тестирование (regression testing)] {{ref-ru}}

Параметры действия

ПеременнаяЗначение
Имя учётной записи (user_name)
'193.28.234.161'
ID страницы (page_id)
101219
Пространство имён страницы (page_namespace)
0
Название страницы (без пространства имён) (page_title)
'Регрессионное тестирование'
Полное название страницы (page_prefixedtitle)
'Регрессионное тестирование'
Действие (action)
'edit'
Описание правки/причина (summary)
'/* Ссылки */ '
Была ли правка отмечена как «малое изменение» (больше не используется) (minor_edit)
false
Вики-текст старой страницы до правки (old_wikitext)
'{{викифицировать}} '''Регрессио́нное тести́рование''' ({{lang-en|regression testing}}, от {{lang-la|regressio}} — движение назад) — собирательное название для всех видов [[тестирование программного обеспечения|тестирования программного обеспечения]], направленных на обнаружение ошибок в уже протестированных участках [[исходный код|исходного кода]]. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют ''регрессионными ошибками'' ({{lang-en|regression bugs}}). Регрессионное тестирование (по некоторым источникам) включает new bug-fix - проверка исправления найденного ранее дефекта, old bug-fix - проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect - проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода. Из опыта разработки ПО известно, что повторное появление одних и тех же ошибок — случай достаточно частый. Иногда это происходит из-за слабой техники управления версиями или по причине человеческой ошибки при работе с [[система управления версиями|системой управления версиями]]. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации. Поэтому считается хорошей практикой при исправлении ошибки создать тест на неё и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты [[Автоматическое_тестирование|автоматически]]. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через заданный интервал времени. Обычно это выполняется после каждой удачной компиляции (в небольших проектах) либо каждую ночь или каждую неделю. Регрессионное тестирование является неотъемлемой частью [[экстремальное программирование|экстремального программирования]]. В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное тестирование всего программного пакета на каждой стадии [[цикл разработки программного обеспечения|цикла разработки программного обеспечения]]. Регрессионное тестирование может быть использовано не только для проверки корректности программы, часто оно также используется для оценки [[качество программного обеспечения|качества]] полученного результата. Так, при разработке [[компилятор]]а, при прогоне регрессионных тестов рассматривается размер получаемого кода, скорость его выполнения и время компиляции каждого из тестовых примеров. == Цитаты == * «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс идет по принципу "два шага вперед, шаг назад".<br>Почему не удается устранять ошибки более аккуратно? Во-первых, даже скрытый дефект проявляет себя как отказ в каком-то одном месте. В действительности же он часто имеет разветвления по всей системе, обычно неочевидные. Всякая попытка исправить его минимальными усилиями приведет к исправлению локального и очевидного, но если только структура не является очень ясной или документация очень хорошей, отдаленные последствия этого исправления останутся незамеченными. Во-вторых, ошибки обычно исправляет не автор программы, а зачастую младший программист или стажер.<br>Вследствие внесения новых ошибок сопровождение программы требует значительно больше системной отладки на каждый оператор, чем при любом другом виде программирования. Теоретически, после каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась. На практике такое ''возвратное (регрессионное) тестирование'' действительно должно приближаться к этому теоретическому идеалу, и оно очень дорого стоит.» — [[Брукс, Фредерик|Брукс Ф.]] ''[[Мифический человеко-месяц|Мифический человеко-месяц или как создаются программные системы]]''. — Пер. с англ. — СПб.: Символ-Плюс, 2001. — 304 стр.: ил. (стр.113–114) == См. также == * [[Автоматическое тестирование]] * [[Бета-тестирование]] * [[Интеграционное тестирование]] * [[Модульное тестирование]] * [[Непрерывная интеграция]] * [[Разработка через тестирование]] * [[Система отслеживания ошибок]] * [[Системное тестирование]] * [[Тестирование программного обеспечения]] * [[Экстремальное программирование]] * [[Юзабилити-тестирование]] == Ссылки == * [http://automated-testing.info/knowledgebase/article/chto-mozhet-predlozhit-avtomatizacija-testirovanija-ili-vygody-avtomatizacii-t Автоматизация регрессионного тестирования] {{ref-ru}} * [http://www.javenue.info/post/24 Регрессионное тестирование (regression testing)] {{ref-ru}} [[Категория:Тестирование программного обеспечения]] [[ca:Proves de regressió]] [[de:Regressionstest]] [[en:Regression testing]] [[es:Pruebas de regresión]] [[et:Regressioonitestimine]] [[fr:Non-régression]] [[he:בדיקות נסיגה]] [[it:Collaudo del software#Il collaudo di regressione]] [[ko:회귀 테스트]] [[lt:Regresija (klaida)]] [[nl:Regressietest]] [[pl:Regresja (informatyka)]] [[pt:Teste de regressão]] [[zh:回归测试]]'
Вики-текст новой страницы после правки (new_wikitext)
'{{викифицировать}} '''Регрессио́нное тести́рование''' ({{lang-en|regression testing}}, от {{lang-la|regressio}} — движение назад) — собирательное название для всех видов [[тестирование программного обеспечения|тестирования программного обеспечения]], направленных на обнаружение ошибок в уже протестированных участках [[исходный код|исходного кода]]. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют ''регрессионными ошибками'' ({{lang-en|regression bugs}}). Регрессионное тестирование (по некоторым источникам) включает new bug-fix - проверка исправления найденного ранее дефекта, old bug-fix - проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect - проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода. Из опыта разработки ПО известно, что повторное появление одних и тех же ошибок — случай достаточно частый. Иногда это происходит из-за слабой техники управления версиями или по причине человеческой ошибки при работе с [[система управления версиями|системой управления версиями]]. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации. Поэтому считается хорошей практикой при исправлении ошибки создать тест на неё и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты [[Автоматическое_тестирование|автоматически]]. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через заданный интервал времени. Обычно это выполняется после каждой удачной компиляции (в небольших проектах) либо каждую ночь или каждую неделю. Регрессионное тестирование является неотъемлемой частью [[экстремальное программирование|экстремального программирования]]. В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное тестирование всего программного пакета на каждой стадии [[цикл разработки программного обеспечения|цикла разработки программного обеспечения]]. Регрессионное тестирование может быть использовано не только для проверки корректности программы, часто оно также используется для оценки [[качество программного обеспечения|качества]] полученного результата. Так, при разработке [[компилятор]]а, при прогоне регрессионных тестов рассматривается размер получаемого кода, скорость его выполнения и время компиляции каждого из тестовых примеров. == Цитаты == * «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс идет по принципу "два шага вперед, шаг назад".<br>Почему не удается устранять ошибки более аккуратно? Во-первых, даже скрытый дефект проявляет себя как отказ в каком-то одном месте. В действительности же он часто имеет разветвления по всей системе, обычно неочевидные. Всякая попытка исправить его минимальными усилиями приведет к исправлению локального и очевидного, но если только структура не является очень ясной или документация очень хорошей, отдаленные последствия этого исправления останутся незамеченными. Во-вторых, ошибки обычно исправляет не автор программы, а зачастую младший программист или стажер.<br>Вследствие внесения новых ошибок сопровождение программы требует значительно больше системной отладки на каждый оператор, чем при любом другом виде программирования. Теоретически, после каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась. На практике такое ''возвратное (регрессионное) тестирование'' действительно должно приближаться к этому теоретическому идеалу, и оно очень дорого стоит.» — [[Брукс, Фредерик|Брукс Ф.]] ''[[Мифический человеко-месяц|Мифический человеко-месяц или как создаются программные системы]]''. — Пер. с англ. — СПб.: Символ-Плюс, 2001. — 304 стр.: ил. (стр.113–114) == См. также == * [[Автоматическое тестирование]] * [[Бета-тестирование]] * [[Интеграционное тестирование]] * [[Модульное тестирование]] * [[Непрерывная интеграция]] * [[Разработка через тестирование]] * [[Система отслеживания ошибок]] * [[Системное тестирование]] * [[Тестирование программного обеспечения]] * [[Экстремальное программирование]] * [[Юзабилити-тестирование]] == Ссылки == * [http://fixber.com/ Площадка услуг по тестированию сайтов и ПО]{{ref-ru}} * [http://automated-testing.info/knowledgebase/article/chto-mozhet-predlozhit-avtomatizacija-testirovanija-ili-vygody-avtomatizacii-t Автоматизация регрессионного тестирования] {{ref-ru}} * [http://www.javenue.info/post/24 Регрессионное тестирование (regression testing)] {{ref-ru}} [[Категория:Тестирование программного обеспечения]] [[ca:Proves de regressió]] [[de:Regressionstest]] [[en:Regression testing]] [[es:Pruebas de regresión]] [[et:Regressioonitestimine]] [[fr:Non-régression]] [[he:בדיקות נסיגה]] [[it:Collaudo del software#Il collaudo di regressione]] [[ko:회귀 테스트]] [[lt:Regresija (klaida)]] [[nl:Regressietest]] [[pl:Regresja (informatyka)]] [[pt:Teste de regressão]] [[zh:回归测试]]'
Была ли правка сделана через выходной узел сети Tor (tor_exit_node)
0
Unix-время изменения (timestamp)
1311664915