Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: еще раз о тестировании  (Прочитано 57090 раз)
0 Пользователей и 1 Гость смотрят эту тему.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #30 : 17-04-2006 17:41 » 

Код:
int f(Mode m)
{
    int res;
    if (Mode1 == m)
    {
       res =f1();
    }
    if (Mode2 == m)
    {
        res = f2();
    }
return res;
Анализ исходного кода показал, что отсутствует обработка случая, когда режим работы не является ни режимом 1, ни режимом 2. Был создан набор модульных тестов для третьего случая - набор тестов 3. Спецификация обновлена, проблема устранена и обновленная версия передена заказчику.
но я в чем-то не прав, поэтому с удовольствием восполню пробелы в знаниях.
Я к тестированию не имею никакого отношения, за исключением проверок собственных же программ, но приведенный пример, imho, пример неправильного подхода. Я стараюсь либо приравнивать "прочие" варианты входных данных к одной из штатных реакций (вину - на потребителя, если конечно не критическая задача), либо инициировать ошибку.
Кстати, с такое же ситуации начал тему Alf.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Alf
Гость
« Ответ #31 : 17-04-2006 21:11 » new

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

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

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #32 : 18-04-2006 05:42 » 

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

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

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

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

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

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

Разработчики (или архитекторы, как угодно) допускают такие ошибки - это факт. Причины здесь не важны. Важен вопрос: как обнаружить такие ошибки на стадиях реализации, а не в процессе эксплуатации. Ответ: тестированием. Давайте же это и будем обсуждать Улыбаюсь
Записан
Alf
Гость
« Ответ #33 : 18-04-2006 06:29 » 

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

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

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

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

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

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

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #34 : 18-04-2006 06:51 » 

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #35 : 18-04-2006 06:58 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #36 : 18-04-2006 07:23 » 

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #37 : 06-09-2008 10:52 » 

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

ЗЫ и еще статейки по тестированию и не только. короче полезная ссылочка
http://software-testing.ru/lib/testing/
« Последнее редактирование: 06-09-2008 11:09 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines