Сообщений в теме: 4

[baranceva]

Практический тренинг с домашними заданиями, 6 занятий

Вы наверняка читали о том, что гарантированно найти все ошибки в сколь-нибудь сложной программе средствами тестирования невозможно. Равно как невозможно доказать, что ошибок в программе нет.
Это в теории. А на практике некоторые тестировщики находят дефектов в программе больше, чем другие, в том числе они умеют находить весьма нетривиальные дефекты. Почему? Как им это удаётся? Что за секретные техники они применяют?
Увы, никаких особых приёмов проектирования тестов, о которых не было бы написано в любой книжке, не существует. Эффективные тестировщики применяют те же самые техники, что и все остальные. Разница лишь в том, КАК они их применяют.
На этом тренинге я не буду ничего говорить о том, как и в каком формате записывать тесты, я буду рассказывать только о том, как их придумывать.
Мы постоянно будем держать в уме два противоборствующих фактора:

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

Подробная программа и условия участия

Посмотреть отзывы участников онлайн-тренинга "Практикум по тест-дизайну"



Читать дальше

[Фрося]

))) почту посмотрела -приглашают на тренинг. ОК1
Только вот скажите мне пожалуйста, что есть "Физическое устройство" как аспект (т.е. точка зрения, если полагаться на Яндекс-словарь) по отношению к программному продукту?
Вот из этой цитатки:
"При рассмотрении программного продукта можно выделить различные аспекты:

Structure: физическое устройство продукта, из чего он состоит;"

(..... даже не могу вообразить...)

[Keiga]

))) почту посмотрела -приглашают на тренинг. ОК1
Только вот скажите мне пожалуйста, что есть "Физическое устройство" как аспект (т.е. точка зрения, если полагаться на Яндекс-словарь) по отношению к программному продукту?
Вот из этой цитатки:
"При рассмотрении программного продукта можно выделить различные аспекты:

Structure: физическое устройство продукта, из чего он состоит;"

(..... даже не могу вообразить...)

Я думаю это просто структура продукта. Из чего состоит на уровне компонентов и модулей. Клиент-сервер, приложение + внешняя база данных и т.п.

[barancev]

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

[Фрося]

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

хм.
Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. [IEEE 1471].

Т.е. речь идет об архитектуре программного обеспечения.

А интерфейсы....

Ну.... физический интерфейс - это провода, оптоволокно, в конце концов какие-то волны (или как там мобильники общаются?) ну и т.п. Т.е. физические объекты, характеризующиеся конкретными физическими параметрами.

)) Ну как хотите.
Скомпилированный код и прочее - никак не физические объекты.
Это как роман Л.Н.Толстого "Война и мир" - ведь роман не есть физический объект?