Еще раз обращаясь к Ron Pattorn, Software testing:
White-box testing, тестирование методом белого ящика - это когда тестировщик имеет доступ к исходному коду приложения и может исследовать его для получения подсказок, как следует тестировать, какие значения вводить. Он может заглянуть внутрь белого ящика и посмотреть, как происходит преобразование исходных значений в итоговые
Но, есть важное уточнение - перед тем, как смотреть в код и на основе полученных знаний строить некоторые решения, выводы, необходимо сначала протестировать приложение методом черного ящика. Почему? Да потому, что, читая код, вы ориентируетесь на то, как оно работает, а не на то, как оно должно работать. Поэтому - вначале ТЗ и black-box testing, а потом уже смотрим в код.
Но при это доступ к коду порой может значительно облегчить нам жизнь и помочь найти багу, а иногда даже исправить ее самим
Вот, допустим, один из примеров.
Загружаем в систему файл. он сохраняется в БД и данные появляются в приложении, но только если они есть в списке допустимых значений (допустим, в этом списке есть слово "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), а не по аналогии с большинством других полей...
Вот так вот - всего то и надо было, скрипт поправить. А не будь у нас доступа к БД, к коду? Что тогда? Первый же позитивный тест проваливается! Мы загружаем правильное значение, а оно не появляется в системе. А почему - не знаем. Просто ставим блокер и сидим ждем, когда же его исправят...
White-box testing, тестирование методом белого ящика - это когда тестировщик имеет доступ к исходному коду приложения и может исследовать его для получения подсказок, как следует тестировать, какие значения вводить. Он может заглянуть внутрь белого ящика и посмотреть, как происходит преобразование исходных значений в итоговые
Но, есть важное уточнение - перед тем, как смотреть в код и на основе полученных знаний строить некоторые решения, выводы, необходимо сначала протестировать приложение методом черного ящика. Почему? Да потому, что, читая код, вы ориентируетесь на то, как оно работает, а не на то, как оно должно работать. Поэтому - вначале ТЗ и black-box testing, а потом уже смотрим в код.
Но при это доступ к коду порой может значительно облегчить нам жизнь и помочь найти багу, а иногда даже исправить ее самим
Вот, допустим, один из примеров.
Загружаем в систему файл. он сохраняется в БД и данные появляются в приложении, но только если они есть в списке допустимых значений (допустим, в этом списке есть слово "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), а не по аналогии с большинством других полей...
Вот так вот - всего то и надо было, скрипт поправить. А не будь у нас доступа к БД, к коду? Что тогда? Первый же позитивный тест проваливается! Мы загружаем правильное значение, а оно не появляется в системе. А почему - не знаем. Просто ставим блокер и сидим ждем, когда же его исправят...
программист и должен это исправить, кто писал, загружал код
ОтветитьУдалить