• Планування тестування:

  • Цільове налаштування на основі перспектив та очікувань клієнтів по якості

  • Загальна стратегія на онові характеристик продукту/оточення

• Підготовка тестування:

  • Підготовка тестових випадків та наборів– зазвичай на основі формальних моделей

  • Підготовка процедури випробувань

• Кто будет тестировать и на каких этапах?

• Какие компоненты надо тестировать?

• Когда надо тестировать?

• Как надо тестировать?

• В каком объеме тестировать?

• Кто будет тестировать?

• Какие компоненты надо тестировать?

• и т.д.

42. Створення тестів (test-cаse).

Тестовый случай (Test Case) - это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

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

Action > Expected Result > Test Result

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

Каждый тест кейс должен иметь 3 части:

PreConditions — Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.

Test Case Description — Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям

PostConditions — Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

43. Засоби (середовища) тестування.

На заміну аналізаторам коду та генераторам тестових даних для структурного та функціонального тестування, лише працюючих на деяких апаратних та програмних платформах, приходять кросплатформені інструменти підтримки різних методів тестування.

Лекція 14

QuickTest Professional, WinRunner, Rational Robot, Rational Functional Tester, SilkTest, TestComplete, Microsoft VS 2005, Selenium

______________________(дальше мб не в тему)

Як проводиться вибір інструментів тестування?

технические критерии

вопросы лицензирования

цена и стоимость

(качество, интеграция, удобность, надежность и т.д.)

44. Критерії вибору тестів.

1. Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы.

2. Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.

3. Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы

4. Критерий должен быть легко проверяемым, например вычисляемым на тестах

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

Поэтому мы стремимся к идеальному общему критерию через реальные частные.

Классы критериев

1. Структурные критерии используют информацию о структуре программы (критерии так называемого "белого ящика")

2. Функциональные критерии формулируются в описании требований к программному изделию ( критерии так называемого "черного ящика" )

3. Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.

4. Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.