frei_by

Очень удобно для наглядности пользоватся схемами базы данных, на которых указаны первичные ключи и связи таблиц по ключам.

Из бесплатных - нашёл MySQL Workbench (собственно для MySQL).

можно выгрузить дамп структуры таблиц командой вроде
mysqldump -u user -p --no-data bd tbls > /home/user/tables.sql

и по sql дампу получаются отличные ER диаграммы.

посоветуете ещё какие-нибудь?

Вот например, нужно протестировать, насколько корректно заносятся записи в БД. У тестировщика из требований по ней есть общая схема с описанием таблиц и типов полей, и ТЗ (как это принято называть в той конторе, где работает тестировщик — тех задание) на модуль, в котором в идеале есть инфа о том, какие таблицы должны обновляться при добавлений записи.

Получается так что при добавлении одной записи апдейтятся пять таблиц. Это написано в первом абзаце ТЗ. А во втором абзаце Главнокомандующий отдела разработки в ТЗ расписал только для одной таблицы какие должны вносится данные. А про остальные 4 таблицы в ТЗ он решил сэкономить время и не писать.

Естественно что для той таблицы про которую он расписал, как должны заносится данные, программисты сделали всё как положено. А для остальных — посчитали что раз нет в ТЗ можно не делать, или сделать так как они сами поняли.

Складывается интересная ситуация. Во время тестирования приходится выяснять полную картину перечня полей которые должны апдейтиться, и фактически дописывать ТЗ но в виде багов о том, что программа должна была сделать то-то то-то но не сделала.

Например, если написано что программа должна апдейтить таблицу StateLog, но не написано какие конкретно поля и как — тестировщик смотрит таблицу и видит, что там поле date заполняется null. Странно. Тестировщик идёт к проектировщику БД и спрашивает, почему date апдейтится нулём? Проектировщик БД говорит, что не нулём а датой, это баг. Тестировщик пишет баг, отправлет программистам. Программисты читают и говорят, что не волнует, этого не было в ТЗ. Бага редиректится разработчику ТЗ который писал ТЗ в самом начале и не внёс данной информации. Разработчик ТЗ в данном случае пишет в комментарий к багу что всё-таки нужно апдейтить дату лога, только после этого баг исправляется.

В исходное ТЗ при этом исправления не вносятся, и через несколько дней первоначальное ТЗ полностью устаревает, так как в процессе выясняются всё новые подробности работы. Остаются неизменными только высокоуровневые бизнес требования, вроде «программа должна предоставить возможность пользователю управлять счётом», нефункциональные требования / описание реализации меняется / уточняется постоянно.

Такая картина повторяется многократно в течении нескольких месяцев.

Неточности и недопонимания в исходном ТЗ порождают баги и бесконечные допиливания программы. Бесконечные допиливания программы приводят к тому, что даже то, что было написано изначально в описании реализации — устаревает. Автор ТЗ наблюдая такую картину оправдывается, что он специально не вносит многую информацию в исходное ТЗ потому что всё равно как будет работать программа мы не знаем пока не напишем, всё равно её потом сто раз допиливать, а бесконечно вносить правки в ТЗ с каждой правкой программы слишком утомительно. Но с другой стороны бесконечные правки порождает изначальная неточность.

Получается какой-то заколдованный круг.

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

Что делать? Это нормально?

Может быть кто-то с подобным встречался?

Я думаю многие сталкивались с классической задачей "протестировать форму регистрации" логин + email + проль.

В данном случае инетерес предаставляет именно поле email.
Какие для такого теста можно придумать тестовые данные? есть собачка, нет собачки, есть точка для доменной зоны (.com) нет точки...

Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.

Особо инетресны случаи, когда email вроде...
first.last@[IPv6:::12.34.56.78] - корректный email ))
first.(")middle.last(")@iana.org - корректный email ))
test@example - снова, согласно RFC, корректный email ))

Проблема такая. Занимаюсь написанием тестов для RC на php.
Есть конструкция из тестов:

class Example extends PHPUnit_Extensions_SeleniumTestCase
{
protected $arr_all; //property for script exchange

public function test_one()
	{...
	$this->arr_all = array (); //full array
	...
	var_dump ($this->arr_all);//array present
	}
public function test_second()
	{
	var_dump ($this->arr_all);//empty!!!!
	}
}

По моей задумке в первом тесте записывается $arr_all а во втором тесте считывается. ООП в php знаю очень приблизительно поэтому прошу снисхождения.

Для всего класса я объявляю свойство $arr_all;
далее в первом тесте test_one() присваиваю ему массив, и для проверки делаю var_dump - всё ок, свойство присвоилось.

Но когда во втором тесте test_second() я вновь пытаюсь обратится к данному свойству - то возвращает var_dump ($this->arr_all);//empty!!!! - NULL.

тесты исполняются один за другим. Пробовал сделать $arr_all; privaty либо public - не помогает. Можно конечно записать в сериализованный файл результаты работы одного теста а потом в другом тесте прочитать этот файл, но не вариант. Хотелось-бы именно в скрипте через переменные / поля класса.

Подскажите пожалуйста способ обмена информацией межуд тестами в пределах одного класса class Example ну или альтернативное решение. Спасибо...

Предлагаю поделится героями-тестировщиками в различных видах изобразительных жанров (кино, телевидение и т.п.)
На создание данной темы меня сподвиг образ
Captain Hindsight


(из 14 сезона South Park серии про BP и Coon)

Думаю что деятельность Капитана Баяна достаточно близко отражает особенности работы тестировщиков.

http://ru.wikipedia....2:_Послевидение

Капитан Послевидение (англ. Captain Hindsight; в других переводах — Капитан Баян и Капитан Очевидность), который «помогает» тем, что объясняет людям, как надо было себя вести и что делать, чтобы не случилось катастрофы, хотя это не приносит никакой пользы делу. Как ни странно, люди с радостью принимают его помощь.

С той разницей что хотелось-бы надеятся что работа тестировщиков делу пользу приносит. ))