Как тестировать программу ?

Всем привет !
Вопрос у меня такой:

Как тестировать программу ?

Методом "черного ящика":
Это понятно. Создал пару тестовых заданий и протестировал выходный/входные данные программы.

Методом "белого ящика":
Запустил трассировщик и протестировал входные/выходные параметры функций.

А какие метрики нужно посчитать ?

Чидамбера и Кемерера или Метрики Лоренца и Кидда?

Проект большое, какие методы тестирования обычно используют ?

И еще как проверить ресурсопотребляемость программы (CPU, MEM) ?

Память можно узнать в 2k/XP - она по CAD всё показывает...

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

Цитата Shiru_Otaku, 05.06.03, 06:24:53

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

Самый лучьший метод - это дать эту программу в руки юзвера - поюзать...

Всплывают ситуации о которых и подумать не мог ;D
А если юзьверов 10-50....

Я когда говорил про 10-50 компов, имел в виду, что тестировать будут их владельцы, а не я:)

При чем, чем дубовей юзер - тем лучше. А вообще, у Rational есть специальные тестирующие пакеты, в которых ты описываешь сенарий тестирования и оставляешь прогу на n-ное время, после чего смотришь на результат.
Есть методика автотестов - это ты сам пишешь тестовый модуль, который проверяет какие-то (или все) аспекты работы программы.
Есть вариант тестирование программы под нагрузкой. В этом режиме всплывают узкие "по памяти" и "по производительности" места.
Если тестируешь на производительности - имеет смысл погонять под TrueTime'ом иои Intel VTune'ом (при средней нагрузке). Получишь некоторую карту узких мест.
Но, как говорится "Тестирование может доказать наличие ошибок в программе, но не может доказать их отсутствие".

Цитата Flex Ferrum, 06.06.03, 12:50:34

Но, как говорится "Тестирование может доказать наличие ошибок в программе, но не может доказать их отсутствие".

Это как? Ошибки будут всегда? т.е. отрицательного результата тестов не бывает?

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

никто не читал "Рефакторинг" мартина фаулера

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

1. Самотестирование

File1:
function1,
function2,
.....
test_function1 {
for function1
}
test_function2 {
for function1
}
test_function3 {
for function1 and function2
}
.......
Количество тестовых ф-ций (или/и их параметров) определяется количеством тестируемых ф-ций и количеством всех возможных взаимодействий между ними.

То же, если мы будем рассматривать модули программы любого другого уровня.

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

2. Белый Ящик - практически - тоже самое что и самотестирование, только тестовый код пишет другой человек (это не просто - трассировщик запустил, это его КТО-ТО ДРУГОЙ запустил). Обычно на этапе белого ящика предполагается, что ф-ность только-только прошла самотестирование, но ещё не готова к чёрному ящику. Это стоит больше, но и эффекта от этого - на много больше.

3. Чёрный ящик - это подготовка к Бетта тестированию. Проводится проффесиональными тестерами, которые должны приготовить почву для сопровождения Бета тестинга. Так же проверяется готовность к Бета тестингу, основываясь на спецификации продукта. Обязательно нужно иметь список ф-ности!!! Предполагается, что вещи, прошедшие Белый ящик (например - правильность метода сортировки, работоспособность элементов управления) детально не тестируется, проверяются результаты работы: стабильность системы в целом, правильность рапорта о результатах сортировки, взаимодействие элементов управления. Тест план сследует составлять так, чтобы он покрывал всё основную ф-ность, и проверял чистоту ВСЕГО Белого ящика. Если в Белом ящике находятся пятнышки, возвращаемся (частично или полностью, всё зависит от бюджета и требований к разработке) к пункту 2. Самый дорогостоящий метод. При неправильном подходе, комманда из N тестеров может изо дня в день топтаться на одном месте и просматривать "чистые" участки программы, в то время, как рядышком будет улей багов.

4. Упомянутое Бета-тестирование (отдать программу юзерам на растерзание), обязательно когда-нить произойдёт. Только вот стыдно, как по мне отдавать недоделаную (читай - недотестированную) программу. Хотя всё, как уже было сказано, зависит от бюджета и требований к разработке.

На самом деле, подходов ооочень много. Есть ещё маленькие тонкости, которые многократно расширяют этот список. Например тестирование многими группами, ввод искуственных багов. Эти подходы позволяет определить уровень баговости.

Сообщение отредактировано: Shaman - 14.07.03, 17:37

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

Сообщение отредактировано: bin - 15.07.03, 16:54

Всё зависит от МАССЫ проекта. Screensaver так тестировать можно (ИМХО при этом в любом случае хош-нехош пройдёшь по крайней мере самотестирование). А вот SPSS, или Mathcad... врядли пользователи а) поймут правильно б) захотят тестировать бесплаьно