Форум: "Прочее";
Текущий архив: 2016.03.20;
Скачать: [xml.tar.bz2];
ВнизТестирование Найти похожие ветки
← →
Pavia © (2015-07-06 11:32) [0]Хочу увидеть практические советы по тестированию. Есть программа 3 000 строк кода с ростом до 10 000 строк. Сейчас около 100 функций.
Есть документация того что должно быть. Сейчас по ней написано 13 тестов. Ещё добавится максимум 7. И того будет 20 тестов.
20/100 или 20/3000 это капля в море.
А вот писать юнит тесты для тестирования каждой функции это простите под 500 тестов и уйма кода.
Хочется что-то среднее. И довести число тестов до 100. Но вот на что обратить внимание? Что тестировать в первую очередь?
Код сложный. Одни функции цепляются за вторые. Вторые за третьи и так далее.
Уже сейчас с 10 тестов видно что много ошибок вернее не дописок из-за того что просто некоторые моменты выпали из поля зрения.
← →
Ega23 © (2015-07-06 11:42) [1]
> Есть документация того что должно быть.
Вот это всё что документировано и должно быть обложено тестами.
← →
Игорь Шевченко © (2015-07-06 13:40) [2]http://www.ozon.ru/context/detail/id/1501671/
Читать и проникаться. После прочтения вопросы, подобные заданным, должны отпасть сами собой.
← →
brother © (2015-07-06 16:48) [3]наймите программиста и ТЕСТЕРА... они все уладят
← →
Pavia © (2015-07-06 16:58) [4]
> Игорь Шевченко © (06.07.15 13:40) [2]
Как обычно всё не-то. Хотя интересные мысли есть. Но как говорят с чего начнёшь тем и закончишь. Начнёшь с тестов тестами и закончишь. Безусловно покрыть тестами надо все методы. Но разработку такую хочется вести постепенно. На этом этапе 100 тестов на следующим 100, а там глядишь и не нужно будет дополнительные. Или напротив ещё 100.
Суть в том что не могу распылятся на всё. Поэтому и хочется сосредоточить силы. Но предложенный метод в книге предлагает тестировать ошибки в коде, а не поиск пропущенного кода.
да и организация кода достаточно специфична, тестировать код по входу затруднительно.
Но в ToDO уже вижу что можно поставить. Правда всё второстепенное.
← →
Игорь Шевченко © (2015-07-06 17:02) [5]Pavia © (06.07.15 16:58) [4]
> Но предложенный метод в книге предлагает тестировать ошибки
> в коде, а не поиск пропущенного кода.
Еще раз надо прочитать, медленно.
← →
brother © (2015-07-06 17:08) [6][3] не дешевле будет?
← →
Ega23 © (2015-07-06 17:20) [7]
> Безусловно покрыть тестами надо все методы.
Совершенно не "безусловно".
← →
Kilkennycat © (2015-07-06 17:22) [8]
> все методы
начать с апи виндов, потом делфю проверить, сторонние компоненты...
← →
Pavia © (2015-07-06 20:16) [9]
> Совершенно не "безусловно".
А как по вашему?
← →
Pavia © (2015-07-06 20:18) [10]
> > Но предложенный метод в книге предлагает тестировать ошибки
> > в коде, а не поиск пропущенного кода. Еще раз надо прочитать,
> медленно.
Прочитал. И своего мнения я не изменил. Разве что автор предлагает перечитывать и переписывать свой код 20 раз минимум.
← →
Ega23 © (2015-07-06 20:25) [11]
> А как по вашему?
Есть "чёрный ящик". Получив на входе А, должен выдать B. Получив на входе С дожен выдать D. Вот это и обкладывается тестами (собственно, вот тебе два готовых). А что там у него внутри - это дело десятое. Возможно что-то тоже обложено тестами, возможно - нет. Возможно, в "чёрном ящике" три строчки кода, возможно - миллион.
← →
brother © (2015-07-06 20:57) [12]Удалено модератором
Примечание: Создание пустых сообщений
← →
Игорь Шевченко © (2015-07-06 22:01) [13]Pavia © (06.07.15 20:18) [10]
Тесты нужны ровно для одной цели - проверки того, что написанное выдает результат, соответствующий ожидаемому. А сколько раз при этом код переписывать - это совершенно несущественно.
Мне очень жаль, но жизнь слишком коротка, чтобы тратить время на переубеждение несогласных.
← →
Pavia © (2015-07-06 23:38) [14]Вы как-то узко смотрите. Есть ведь приемосдаточное тестирование, тестирование сопряжения интерфейсов, есть юнит-тесты, есть стресс-тесты и др.
Понятно что если у нас функция, то протестировать её легко есть параметр и есть результат.
Но программирование одними функциями не ограниченно! Ошибки гораздо разнообразнее. И тестирование должно покрывать всё многообразие хотя бы в разной степени. Не даром ведь придумано статический анализ кода, а ведь это тоже тестирование.
Помимо функциональной парадигмы программирования есть и другие:
- Объектно ориентированное программирование.
- Машины состояний конечные автоматы.
- Иерархическое.
- Алгоритмы.
- параллельная.
- Процессы.
И к каждому надо свой подход.
В одном интерфейсе может скрываться разные алгоритмы. И одно дело проверять пузырьковую сортировку и другое дело проверять поразрядную сортировку. Помните поговорку что сортировку делением по полам безошибочно могут написать единицы.
Тестирование можно вести не только по методике черного ящика, но и по методике белого ящика. У нас есть функция и мы должны проверить правильность её устройства. Легко разбить функцию на участки создаваемые ветвлением и проверить по отдельности каждый блок.
Но оператор ветвления есть почти в каждой второй функции. Что не есть то что мне нужно.
А вот с процессами пока не понятно как построить тестирование. Понятно что процесс сам состоит из блоков, но тестировать все блоки это запредельно. Думаю надо думать в сторону генератора перестановок, который должен облегчить труд.
За дискуссию спасибо. Я уже понял что надо написать задание на тестирования. И он будет состоять из: приемосдаточного тестирования, тестирование сопряжения интерфейсов, частично стресс-тесты, частично юнит-тестов. Юнит тесты будут делиться на тесты по методике чёрного ящика и по методики белого ящика.
И далее идти по заданию на тестирование. Этот порядок тестов идёт с возрастанием трудозатрат. Что мне и нужно было.
Думаю в задание сделаю разбивку по юнитам, чтобы видить какой тип теста к какому юниту прилагается.
← →
картман © (2015-07-07 20:30) [15]
> Ega23 © (06.07.15 20:25) [11]
>
>
> > А как по вашему?
>
>
> Есть "чёрный ящик". Получив на входе А, должен выдать B.
> Получив на входе С дожен выдать D.
а как быть, если получив на входе А, правильным может быть В или С? А может и D, причем, D правильнее предыдущих двух? Где В, С и D - массивы с (возможно)пересекающимися элементами? Для подобного есть готовые инструменты?
← →
Дмитрий С © (2015-07-07 20:46) [16]Или вообще не знаешь какой ответ правильный. Боюсь предположить, что и такое бывает.
Интересно, а как тестируются функции, которые обрабатывают данные в базе. Помимо работы каждой под-функции, необходимо проверить и работу всех функции в целом.
Для этого создается множество подопытных баз и входящих данных?
Вот пример: функция, которая запрашивает список резервирований отеля из какой-либо системы бронирования и должна разместить их в карте брони (грубо говоря, это таблица соответствий дней, номеров и резервирований). Причем, требований по размещению много.
Как ее принято тестировать?
Ни разу не встречал, чтобы кто-то использовал тесты в практике.
← →
Kerk © (2015-07-07 20:53) [17]
> Дмитрий С © (07.07.15 20:46) [16]
> Интересно, а как тестируются функции, которые обрабатывают
> данные в базе.
Почти что как обычные. Подготавливаешь окружение, вызываешь, смотришь результат.
Есть инструменты, позволяющие автоматизировать рутину. Например для Оракла http://software.dell.com/products/toad-development-suite-for-oracle/code-tester-for-oracle.aspx . Заполняешь в GUI все что нужно, жмешь кнопку - на выходе код юнит-теста. [Это была минутка пиара, я эту штуку почти 3 года пилил когда-то]
> Вот пример: функция, которая запрашивает список резервирований
> отеля из какой-либо системы бронирования и должна разместить
> их в карте брони (грубо говоря, это таблица соответствий
> дней, номеров и резервирований). Причем, требований по размещению
> много.
> Как ее принято тестировать?
Аналогично. Подсовываешь этой функции заранее подготовленные тестовые данные, сравниваешь результат с эталоном.
← →
Дмитрий С © (2015-07-07 21:20) [18]
> Аналогично. Подсовываешь этой функции заранее подготовленные
> тестовые данные, сравниваешь результат с эталоном.
Берем ту же задачу про размещение броней (они же резервирования).
И всего одно требование: положить бронь в таблицу таким образом, чтобы она не пересекалась с другими бронями. Т.е. не должно быть другой брони на этот же номер, пересекающейся периодом проживания с новой.
В этом случае эталона быть не может. Можно только проверить, выполнилось ли условие. Получается что функция тестирования по сложности сопоставима с тестируемой функцией.
Пример достаточно прост, в жизни условий больше и ошибиться в функции тестирования так же легко как и в тестируемой. Как в этом случае решается задача тестирования?
← →
Kerk © (2015-07-07 21:26) [19]Дмитрий С © (07.07.15 21:20) [18]
> И всего одно требование: положить бронь в таблицу таким
> образом, чтобы она не пересекалась с другими бронями. Т.
> е. не должно быть другой брони на этот же номер, пересекающейся
> периодом проживания с новой.
>
> В этом случае эталона быть не может.
Почему не может? Берешь пустую таблицу броней, добавляешь туда десяток заранее известных тебе записей. Потом вызываешь свою функцию для нескольких крайних случаев и смотришь чего она туда записала. В такой ситуации проверять результат можно элементарно.
← →
Дмитрий С © (2015-07-07 21:30) [20]
> Почему не может? Берешь пустую таблицу броней, добавляешь
> туда десяток заранее известных тебе записей. Потом вызываешь
> свою функцию для нескольких крайних случаев и смотришь чего
> она туда записала. В такой ситуации проверять результат
> можно элементарно.
Так задача найти свободное место в таблице (для тестируемой) и проверить есть ли пересечения в таблице (для тестирующей) почти одинаковая.
Вот еще пример, где на мой взгляд протестировать функцию сложнее чем написать: это тестировать функцию тестирования. :)
← →
Игорь Шевченко © (2015-07-07 21:39) [21]Дмитрий С © (07.07.15 20:46) [16]
> Ни разу не встречал, чтобы кто-то использовал тесты в практике.
Я использую. Меня ты на форуме уже встретил.
> Берем ту же задачу про размещение броней (они же резервирования).
>
> И всего одно требование: положить бронь в таблицу таким
> образом, чтобы она не пересекалась с другими бронями. Т.
> е. не должно быть другой брони на этот же номер, пересекающейся
> периодом проживания с новой.
>
> В этом случае эталона быть не может.
Не вижу проблемы.
Как ты понимаешь у базы данных нет атомарной операции "положить бронь", это бизнес-условие, значит для "положить бронь" есть набор элементарных операций, после которых необходимое бизнес-условие будет выполнено.
Вот этот набор и тестируется.
И протестировать такое простое бизнес-условие совсем не трудно.
← →
ухты © (2015-07-07 22:53) [22]
> Ни разу не встречал, чтобы кто-то использовал тесты в практике.
аналогично, на собеседовании спрашивают вовсю, приходишь на работу и тишина :)
← →
Kerk © (2015-07-07 23:06) [23]Юнит-тестирование как подростковый секс: все об этом говорят, никто этого не умеет, все думают, что остальные это делают, и поэтому все утверждают, что сами это делают.
← →
Дмитрий С © (2015-07-07 23:20) [24]
> Игорь Шевченко © (07.07.15 21:39) [21]
Тебя на форуме видел, а вот твою практику нет.
← →
Сергей Суровцев © (2015-07-08 20:09) [25]ТЗ надо правильно составлять. И порядок создания ПО. тогда создание ф-и и ее тестирование происходит во время отладки. При написании тестов на все случаи жизни бабла не хватит, это удорожит систему на порядок. И времени, ибо часто основной код надо написать и запустить еще вчера. Главное обозначить отлаженное и бдить и сурово карать тех кто в него лезет. А если влезть надо, то только с пониманием того что меняем и зачем, и как это повлияет.
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2016.03.20;
Скачать: [xml.tar.bz2];
Память: 0.53 MB
Время: 0.002 c