1. На каком этапе проектирования целесообразно начинать тестирование разрабатываемой системы?

На этапе анализа привлекаются группы тестирования. На данном этапе определяется план работ по обеспечению надежности информационной систем. Для любых проектов целесообразным является привлечение тестеров на ранних этапах разработки, в частности на этапе анализа и проектирования. Если проектное решение оказалось неудачным и это обнаружено слишком поздно - на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию, - то исправление ошибки проектирования может обойтись очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.

Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.

1. Различия этапов логического и физического проектирования бд

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

 Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.

1. Какие методологии тестирования ис Вы можете назвать?

Функциональное тестирование (functional testing)

• Нагрузочное тестирование

  • Тестирование производительности (perfomance/stress testing)

  • Тестирование стабильности (stability/load testing)

• Тестирование удобства использования (usability testing)

• Тестирование интерфейса пользователя (UI testing)

• Тестирование безопасности (security testing)

• Тестирование локализации (localization testing)

• Тестирование совместимости (compatibility testing)

По знанию системы:

• Тестирование чёрного ящика (black box)

• Тестирование белого ящика (white box)

• Тестирование серого ящика (gray box)

По степени автоматизированности:

• Ручное тестирование (manual testing)

• Автоматизированное тестирование (automated testing)

• Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

• Компонентное (модульное) тестирование (component/unit testing)

• Интеграционное тестирование (integration testing)

• Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

• Альфа тестирование (alpha testing)

  • Тестирование при приёмке (smoke testing)

  • Тестирование новой функциональности (new feature testing)

  • Регрессионное тестирование (regression testing)

  • Тестирование при сдаче (acceptance testing)

• Бета тестирование (beta testing)

По признаку позитивности сценариев:

• Позитивное тестирование (positive testing)

• Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

• Тестирование по документации (formal testing)

• Эд Хок (интуитивное) тестирование (ad hoc testing)

(либо мой вариант)

1)Стратегия «белого ящика» (проверяется логика программы)

• Нулевой метод покрытия операторов;

• Метод покрытия решений;

• Метод покрытия условий;

• Метод комбинаторного покрытия условий.

2)Стратегия «черного ящика» (проверяется соответствие программы внешним спецификациям)

• Метод эквивалентного разбиения;

• Метод анализа граничных значений;

• Метод тестирования таблицы решений.