Тестирование

← →
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 года пилил когда-то]

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

Аналогично. Подсовываешь этой функции заранее подготовленные тестовые данные, сравниваешь результат с эталоном.

> Аналогично. Подсовываешь этой функции заранее подготовленные
> тестовые данные, сравниваешь результат с эталоном.

Берем ту же задачу про размещение броней (они же резервирования).
И всего одно требование: положить бронь в таблицу таким образом, чтобы она не пересекалась с другими бронями. Т.е. не должно быть другой брони на этот же номер, пересекающейся периодом проживания с новой.

В этом случае эталона быть не может. Можно только проверить, выполнилось ли условие. Получается что функция тестирования по сложности сопоставима с тестируемой функцией.

Пример достаточно прост, в жизни условий больше и ошибиться в функции тестирования так же легко как и в тестируемой. Как в этом случае решается задача тестирования?

Дмитрий С © (07.07.15 21:20) [18]

> И всего одно требование: положить бронь в таблицу таким
> образом, чтобы она не пересекалась с другими бронями. Т.
> е. не должно быть другой брони на этот же номер, пересекающейся
> периодом проживания с новой.
>
> В этом случае эталона быть не может.

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

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

Так задача найти свободное место в таблице (для тестируемой) и проверить есть ли пересечения в таблице (для тестирующей) почти одинаковая.

Вот еще пример, где на мой взгляд протестировать функцию сложнее чем написать: это тестировать функцию тестирования. :)

Дмитрий С © (07.07.15 20:46) [16]

> Ни разу не встречал, чтобы кто-то использовал тесты в практике.

Я использую. Меня ты на форуме уже встретил.

> Берем ту же задачу про размещение броней (они же резервирования).
>
> И всего одно требование: положить бронь в таблицу таким
> образом, чтобы она не пересекалась с другими бронями. Т.
> е. не должно быть другой брони на этот же номер, пересекающейся
> периодом проживания с новой.
>
> В этом случае эталона быть не может.

Не вижу проблемы.

Как ты понимаешь у базы данных нет атомарной операции "положить бронь", это бизнес-условие, значит для "положить бронь" есть набор элементарных операций, после которых необходимое бизнес-условие будет выполнено.
Вот этот набор и тестируется.

И протестировать такое простое бизнес-условие совсем не трудно.

> Ни разу не встречал, чтобы кто-то использовал тесты в практике.
аналогично, на собеседовании спрашивают вовсю, приходишь на работу и тишина :)

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

ТЗ надо правильно составлять. И порядок создания ПО. тогда создание ф-и и ее тестирование происходит во время отладки. При написании тестов на все случаи жизни бабла не хватит, это удорожит систему на порядок. И времени, ибо часто основной код надо написать и запустить еще вчера. Главное обозначить отлаженное и бдить и сурово карать тех кто в него лезет. А если влезть надо, то только с пониманием того что меняем и зачем, и как это повлияет.

Тестирование Найти похожие ветки