еще раз о тестировании

[RXL]

Код:

int f(Mode m)
{
    int res;
    if (Mode1 == m)
    {
       res =f1();
    }
    if (Mode2 == m)
    {
        res = f2();
    }
return res;

Анализ исходного кода показал, что отсутствует обработка случая, когда режим работы не является ни режимом 1, ни режимом 2. Был создан набор модульных тестов для третьего случая - набор тестов 3. Спецификация обновлена, проблема устранена и обновленная версия передена заказчику.
но я в чем-то не прав, поэтому с удовольствием восполню пробелы в знаниях.

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

[Alf]

...приведенный пример, imho, пример неправильного подхода.
...
Кстати, с такое же ситуации начал тему Alf.

Да, ситуации похожи, как близнецы. Грабли практически одни и те же - не предусмотрены все возможные значения входных параметров или их комбинаций (мой пример чуточку сложнее, поскольку возможно бесчисленное множество размеров плат, но по сути число комбинаций тоже весьма ограничено - a>b, a<b, a=b).

Однако в описанном мной случае программа была написана на языке PL/I, который никоим образом не помогает программисту в подобных ситуациях. Компилятор PL/I подобен старательному и тупому исполнителю: готов усердно выполнять самое бестолковое поручение, не вдаваясь в смысл работы. Не зря в статьях Дейкстры этот язык подвергался уничтожающей критике. Впрочем, в те времена выбор был весьма невелик. (Конечно же, это не оправдание неряшливым программистам; корректную программу можно написать даже на ассемблере, правда, усилий придется затратить не в пример больше).

Сегодня мы располагаем несравнимо более мощными и выразительными языками, чем 10-15 лет назад. Поэтому при правильном использовании технологий допустить подобные ляпы практически невозможно - все равно как невозможно засунуть кассету в видеомагнитофон не той стороной или засунуть во флоппи-диск вторую дискету, не вынув первую, - не лезет она туда, и все. Конечно, при должном запасе дурной силы возможно и "уговорить" их, но это и есть грубое нарушение технологии.

В частности, если бы в процитированном примере архитектор не пошел по самому примитивному пути (облегчив работу себе и осложнив остальным участникам проекта), а провел более тщательный анализ задачи, он наверняка сделал бы Mode объектом, а не скаляром, и подобный ляп просто не прошел бы компиляцию (если даже его вообще можно было описать средствами объектно-ориентированного языка, в чем я лично сомневаюсь). Тогда и тест модуля выглядел бы иначе, и обработка ошибок претерпела бы изменения. (Опять же вспомнился разговор о дороговизне услуг хороших архитекторов... Ой не зря они свой хлеб едят, пусть даже со стороны он покажется до неприличия сдобным).

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

[Hooter]

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

Люди, люди, остановитесь! А то мы сейчас начнем обсуждать ошибки псевдокода в теме о тестировании

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

RXL, если ты не читал соседнюю тему, то поясняю - это и был пример неправлильного подхода. Здесь он был приведен для того, чтобы проиллюстрировать моё понимание терминов "функционального" и "модульного тестирования" и "тестирования белого ящика".

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

Alf, давай не будем обсуждать рефакторинг куска программы, вырванный из контекста и написанный на псевдокоде. Есть разные языки и разные подходы к архитектуре. Ведь это тема о тестировании, а не о разработке архитектуры?

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

[Alf]

Alf, давай не будем обсуждать рефакторинг куска программы, вырванный из контекста и написанный на псевдокоде.

А в чем проблема-то? Паттерны проектирования обсуждаются, как правило, на псевдокоде, чтобы не привязываться к особенностям отдельно взятого языка. Рефакторинг тоже предлагается в общем виде, причем подвергаются ему небольшие фрагменты, а не громадные проекты в целом. Ни псевдокод, ни малость фрагмента не мешают понять ошибочные идеи, относящиеся к сути проекта и не связанные с плохим владением языком программирования - проблемы лежат глубже.

Есть разные языки и разные подходы к архитектуре.

Именно поэтому и возникла дискуссия. Если бы был один язык и один подход, проблемы выбора просто не было бы. Я бы сделал ссылку на соотвествующий ГОСТ, ISO и т.д. и на этом бы все закончилось. Чтобы выбирать не по красоте названия или разрекламированности, а глубже вникнуть в суть, и затеяно обсуждение.

Ведь это тема о тестировании, а не о разработке архитектуры?

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

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

Тестирование - лишь малая часть общей картины. Я просто начал с него, как с наименее изученной большинством части общего процесса. Это только начало долгого разговора.

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

Это зависит от точки зрения. Мне не менее интересен другой вопрос: как не допустить подобных ошибок на стадии проектирования, чтобы реализовать их просто не удалось? Если вникнуть в причины ошибок, их и обнаруживать потом не придется.

[Hooter]

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

Это зависит от точки зрения. Мне не менее интересен другой вопрос: как не допустить подобных ошибок на стадии проектирования, чтобы реализовать их просто не удалось?

Автору безусловно лучше знать, для чего предназначена эта тема. Прошу прощения, что влез не в свое дело. Предложение: может быть тебе лучше организовать цикл статей в том порядке, в котором нужно, а не параллельные обсуждения? После выхода статей будет ясна общая картина.

[Dimka]

После выхода статей будет ясна общая картина.

А на каком языке эти статьи писать, чтобы всем было понятно? "70% времени люди тратят на взаимонепонимание" (Урсула Ле Гуин) Положим, напишет Alf своё видение, а потом кто-нибудь скажет, что "ко мне это не применимо"... Уж лучше в начале обсудить.

[Alf]

...Предложение: может быть тебе лучше организовать цикл статей в том порядке, в котором нужно, а не параллельные обсуждения? После выхода статей будет ясна общая картина.

По правде сказать, мне становится дурно при одной мысли о том, чтобы взяться за такой цикл... Для начала переписать Бадда, потом Буча с компанией. Затем взяться за нотации для функционального моделирования, документирования бизнес-процессов, потоков данных, а также - за инструменты их поддержки. Плавно перейти от бизнес-моделей через паттерны проектирования к объектным моделям, их реализующим. Затем через модели перейти к коду, затронув XP и рефакторинг. Затем добраться до инструментальных средств поддержки тестирования и отладки... Это только навскидку, наверняка забыл как минимум половину.

Не, ниасилю однозначно. Да и будут ли эти статьи лучше первоисточников?

[Ochkarik]

скину тут ссылочку...
набрел случайно на список книжек по тестированию ПО.
вдруг кому потребуется?
http://litera.by/books/11-93-97

ЗЫ и еще статейки по тестированию и не только. короче полезная ссылочка
http://software-testing.ru/lib/testing/