понедельник, 25 марта 2013 г.

Чем полезен доступ к коду...

Еще раз обращаясь к Ron Pattorn, Software testing:

White-box testing, тестирование методом белого ящика - это когда тестировщик имеет доступ к исходному коду приложения и может исследовать его для получения подсказок, как следует тестировать, какие значения вводить. Он может заглянуть внутрь белого ящика и посмотреть, как происходит преобразование исходных значений в итоговые

Но, есть важное уточнение - перед тем, как смотреть в код и на основе полученных знаний строить некоторые решения, выводы, необходимо сначала протестировать приложение методом черного ящика. Почему? Да потому, что, читая код, вы ориентируетесь на то, как оно работает, а не на то, как оно должно работать. Поэтому - вначале ТЗ и black-box testing, а потом уже смотрим в код.

Но при это доступ к коду порой может значительно облегчить нам жизнь и помочь найти багу, а иногда даже исправить ее самим Smile :)

Вот, допустим, один из примеров.

Загружаем в систему файл. он сохраняется в БД и данные появляются в приложении, но только если они есть в списке допустимых значений (допустим, в этом списке есть слово "TEST").

И так как мы всегда должны начинать с позитивных тест-кейсов, я ввожу "TEST" и загружаю файл. В ответ - ничего. Хм... Редактирую файл, чтобы убедиться, что загружается именно он - да, загружается именно он, но значение не подтягивается.

Открываю БД, смотрю, а у меня там значение "TEST                 ".

Что-то я сходу сама не сообразила в чем дело, поэтому пишу разработчику:

- А почему у меня в БД ";TEST              ;" (; выступает в роли разделителя), если в файле загружаемом у меня ";TEST;", откуда берутся пробелы?

- Ну, откуда я знаю? Это ты так грузишь.

- о_О

Ну ладно, посидела, посидела, посмотрела в файл, прикидывая, как это я так могу грузить. Но  проверить же надо, что в системе появляется правильное значение, поэтому пока закостылим.

Изменяю значение прямо в БД на "TEST", коммичу, загружаю... Опять ничего о_О

Смотрю в базу - опять пробелы! И тут до меня начало доходить...
Открываю скрипт создания БД, ну конечно!

field_1 VARCHAR2(20 byte),
field_1 VARCHAR2(30 byte),
field_1 VARCHAR2(50 byte),
field_n CHAR(3 byte),
field_test CHAR(50 byte),
...

Ах это я так данные загружаю? А кто скрипт писал??

Переменные типа CHAR имеют фиксированную длину, поэтому при необходимости они заполняются до максимальной длины пробелами.

Так ведь разработчик мне еще и не поверил, пришел и встал над душой - "Ты откуда это определение взяла?". Оказалось, он просто сделал по аналогии с предыдущим полем (в котором была как раз четко установленная длина, потому и использовали CHAR), а не по аналогии с большинством других полей...

Вот так вот - всего то и надо было, скрипт поправить. А не будь у нас доступа к БД, к коду? Что тогда? Первый же позитивный тест проваливается! Мы загружаем правильное значение, а оно не появляется в системе. А почему - не знаем. Просто ставим блокер и сидим ждем, когда же его исправят...

Комментариев нет:

Отправить комментарий