Как уменьшить время, проведенное на тестировании?
Поздно, но я подумал, что это может быть полезно для тех, кто использует RxJava в своих приложениях.
RxJava поставляется с оператором под названием .timer(), который создаст Observable, который сработает onNext() только один раз через заданный промежуток времени, а затем вызовет onComplete(). Это очень полезно и позволяет избежать необходимости создавать Handler или Runnable.
Более подробную информацию об этом операторе можно найти в документации ReactiveX
// Wait afterDelay milliseconds before triggering call
Subscription subscription = Observable
.timer(5000, TimeUnit.MILLISECONDS) // 5000ms = 5s
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Action1() {
@Override
public void call(Long aLong) {
// Remove your AlertDialog here
}
});
. Вы можете отменить поведение, вызванное таймером, отменив подписку на наблюдаемое по нажатию кнопки. Поэтому, если пользователь вручную закрывает предупреждение, позвоните subscription.unsubscribe(), и это приведет к отмене таймера.
9 ответов
Дизайн, основанный на тестировании, - это не тестирование (обеспечение качества). С самого начала он был плохо назван.
Речь идет о предположениях и спецификациях поведения программы, которые можно запускать на компьютере, и делается программистами во время программирования, чтобы гарантировать, что предположения являются явными.
Поскольку эти задачи должны быть выполнены в какой-то момент в жизненном цикле продукта это просто смена работы. Будет ли это более или менее эффективным - это обсуждение в другой раз.
То, что вы имеете в виду, я бы не назвал тестированием. Наличие сильного TDD означает, что на фазу тестирования не нужно так сильно полагаться в отношении ошибок, которые будут обнаружены задолго до того, как они достигнут тестовой сборки (как у опытных программистов с хорошей спецификацией и отзывчивых заинтересованных сторон в не-TDD Окружающая среда).
Команда Subversion разработала несколько довольно хороших процедур тестирования , автоматизируя весь процесс.
Я сам начал использовать этот процесс, например, написав тесты до реализации новых функций. Он работает очень хорошо и обеспечивает последовательное тестирование на протяжении всего процесса программирования.
SQLite также имеет достойную систему тестирования с некоторой очень хорошей документацией о том, как это делается.
По моему опыту разработки через тестирование, экономия времени наступает значительно после того, как вы написали тесты или, по крайней мере, после того, как вы написали базовые тестовые примеры. Ключевым моментом здесь является то, что вам действительно нужно писать наши автоматизированные тесты. То, как вы сформулировали свой вопрос, заставляет меня думать, что вы на самом деле не писали автоматизированные тесты. После того, как вы напишете свои тесты, вы можете легко вернуться к ним позже и обновить тесты, чтобы охватить ошибки, которые они ранее не находили (для лучшего регрессионного тестирования), и вы можете легко и относительно быстро реорганизовать свой код, зная, что код будет по-прежнему работает должным образом после того, как вы его существенно изменили.
Нет ничего плохого в том, чтобы тратить много времени на тестирование, если вы тестируете продуктивно . Имейте в виду, что разработка через тестирование означает сначала написание (в основном автоматизированных) тестов (законно это может занять много времени, если вы напишете подробный набор тестов). Выполнение тестов не займет много времени.
Похоже, ваша проблема в том, что вы не выполняете автоматическое тестирование. Использование автоматических модульных и интеграционных тестов может значительно сократить время, затрачиваемое на тестирование.
Во-первых, хорошо, что вы осознаете, что вам нужна помощь - теперь пойдите и найдите ее :)
Идея состоит в том, чтобы использовать тесты, чтобы помочь вам подумать о том, что должен делать код , они являются частью вашего времени разработки.
Вам также следует подумать об общей стоимости владения кодом. Какова стоимость того, чтобы ошибка была доведена до производства, а не была исправлена в первую очередь? Если вы работаете в банке, есть ли серьезные последствия для неправильных чисел? Иногда для того, чтобы сделать правильный выбор, нужно время.
Одна из самых сложных вещей в любом проекте значительного размера - это проектирование базовой архитектуры и API. Все это раскрывается на уровне юнит-тестов. Если вы сначала пишете свои тесты, то этот аспект дизайна возникает при написании тестов, а не в логике программы. Это усугубляется дополнительными усилиями по тестированию кода. После того, как у вас есть тесты, логика программы обычно становится довольно очевидной.
При этом, похоже, на горизонте появятся несколько интересных автоматических построителей тестов.
Думаю, я понимаю. Выше уровня тестирования разработчика у вас есть уровень тестирования клиента, и похоже, что на этом уровне вы обнаруживаете много ошибок.
Для каждой обнаруженной ошибки вы должны останавливаться, снимать шляпу тестирования , наденьте шляпу воспроизведения и определите точную стратегию воспроизведения. Затем вы должны задокументировать ошибку, возможно, поместить ее в систему отслеживания ошибок. Тогда вы должны надеть шляпу тестирования. В то же время вы потеряли все настройки, над которыми работали, и потеряли из виду, где вы находились по плану тестирования, которому вы следовали.
Теперь - если этого не должно было случиться - если у вас было очень мало ошибок - вы могли бы быстро пройти через тестирование, верно?
Сомнительно, что автоматизация тестирования с помощью графического интерфейса пользователя поможет с этой проблемой. Вы' Я потрачу много времени на запись и поддержку тестов, и эти регрессионные тесты потребуют много времени, чтобы окупить вложения. Сначала вы будете работать намного медленнее с GUI-Driving-ориентированными на клиента тестами.
Итак (я утверждаю), что действительно может помочь более высокое / начальное / качество кода, получаемое в результате деятельности по разработке. В этом могут действительно помочь микротесты, также называемые тестами разработчика или разработкой, управляемой тестами. Еще одна вещь, которая может помочь, - это парное программирование.
Предполагая, что вы не можете найти кого-то еще для пары, я бы потратил час на изучение вашей системы отслеживания ошибок. Я бы посмотрел на последние 100 дефектов и попытался бы разделить их на основные причины. «Проблема с обучением» не является причиной, но может быть «отключена на одну ошибку».
После того, как вы их классифицировали и подсчитали, поместите их в электронную таблицу и отсортируйте. Какая бы основная причина ни возникала чаще всего, вы в первую очередь предотвращаете ее. Если вы действительно хотите пофантазировать, умножьте основную причину на какое-нибудь число, которое представляет собой причиняемую ею боль. (Пример: если в этих 100 ошибках у вас есть 30 опечаток в меню, которые так же легко исправить, и 10 трудно воспроизводимых ошибок javascript, вы можете сначала исправить проблему javascript.)
Это предполагает, что вы можете применить какое-то волшебное «исправление» каждой из этих первопричин, но попробовать стоит. Например: прозрачные значки в IE6 могут быть вызваны тем, что IE6 не может легко обрабатывать файлы .png. Поэтому используйте триггер управления версиями, который отклоняет .gif при регистрации, и проблема устранена.
Надеюсь, это поможет.
Если вы действительно хотите пофантазировать, умножьте основную причину на какое-нибудь число, которое представляет собой причиняемую ею боль. (Пример: если в этих 100 ошибках у вас есть 30 опечаток в меню, которые так же легко исправить, и 10 трудно воспроизводимых ошибок javascript, вы можете сначала исправить проблему javascript.)Это предполагает, что вы можете применить какое-то волшебное «исправление» каждой из этих первопричин, но попробовать стоит. Например: прозрачные значки в IE6 могут быть вызваны тем, что IE6 не может легко обрабатывать файлы .png. Поэтому используйте триггер управления версиями, который отклоняет .gif при регистрации, и проблема устранена.
Надеюсь, это поможет.
Если вы действительно хотите пофантазировать, умножьте основную причину на какое-нибудь число, которое представляет собой причиняемую ею боль. (Пример: если в этих 100 ошибках у вас есть 30 опечаток в меню, которые так же легко исправить, и 10 трудно воспроизводимых ошибок javascript, вы можете сначала исправить проблему javascript.)Это предполагает, что вы можете применить какое-то волшебное «исправление» каждой из этих первопричин, но попробовать стоит. Например: прозрачные значки в IE6 могут быть вызваны тем, что IE6 не может легко обрабатывать файлы .png. Поэтому используйте триггер управления версиями, который отклоняет .gif при регистрации, и проблема устранена.
Надеюсь, это поможет.
вы можете сначала решить проблему с javascript.)Предполагается, что вы можете применить какое-то волшебное «исправление» к каждой из этих основных причин, но попытаться стоит. Например: прозрачные значки в IE6 могут быть вызваны тем, что IE6 не может легко обрабатывать файлы .png. Поэтому используйте триггер управления версиями, который отклоняет .gif при регистрации, и проблема устранена.
Надеюсь, это поможет.
вы можете сначала решить проблему с javascript.)Предполагается, что вы можете применить какое-то волшебное «исправление» к каждой из этих основных причин, но попытаться стоит. Например: прозрачные значки в IE6 могут быть вызваны тем, что IE6 не может легко обрабатывать файлы .png. Поэтому используйте триггер управления версиями, который отклоняет .gif при регистрации, и проблема устранена.
Надеюсь, это поможет.
Вы написали:
«Спасибо за ответы, приведенные выше, изначально мой вопрос был как сократить время на общее тестирование, но теперь проблема в том, как напишите эффективный автоматический тест использовали комбинаторный генератор тестовых примеров для определения тестовых примеров для них. Команды, использующие комбинаторный генератор тестовых примеров, обнаружили в среднем более чем в два раза больше дефектов за час тестировщика. Это убедительное доказательство эффективности. Кроме того, комбинаторные тестеры обнаружили на 13% больше дефектов. Это убедительное доказательство качества / тщательности.
Эти результаты не являются чем-то необычным. Дополнительную информацию об этом подходе можно найти по адресу http://www.combinatorialtesting.com/clear-introductions-1 и с обзором нашего инструмента здесь . Он содержит снимки экрана и объяснение того, как наш инструмент делает тестирование более эффективным за счет определения подмножества тестов, которые максимизируют охват.
Также бесплатную версию нашего генератора тестовых случаев Hexawise можно найти на www.hexawise. com / users / new