Lesson 51

Что-то уроки у Сэма пошли немаленькие, быстренько перевести уже не получается, эх.


Слово Канеру:

Техники тестирования, основанные на проблемах сфокусированы на причинах тестирования (каких рисков мы хотим избежать)

Тестирование основанное на рисках имеет по крайней мере два основных значения.

Amland (1999) предоставил замечательное описание менеджмента тестирования основанного на рисках. Согласно его точке зрения, анализ рисков необходим для определения следующих шагов тестирования. Тесты приоритезируются с точки зрения вероятности того, что фича сломается и с точки зрения вероятной цены поломки фичи. И чем больше вероятность поломки, тем важнее тест и тем раньше его нужно проводить.

По другомум мнению, анализ рисков можно делать собственно для поиска ошибок. Когда мы изучаем особенности продукта, мы спрашиваем себя, как он может ломаться. Этот вопрос распадается на на множество дополнительных вопросов, таких как: Как будет выглядеть бага? Почему эта фича сломалась? (Мы опишем наш подход к тестированию основанному на рисках в дополнении к книге)

Оба этих подхода обсуждались в James Bach on Risk-Based Testing (1999c).

Whittaker и Jorgensen (1999 and 2000) предоставили отличное обсуждение и примеры широких классов ошибок, включающих нарушения ограничений:

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

Ограничения вывода Ввод был корректным, но он привел к выходным значениям, которые не могли быть обработаны. Программа может упасть при попытке отобразить, распечатать или сохранить эти данные.

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

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

Whittaker (2002) дал детальные рекомендации по тестированию этих ограничений.

Вот несколько полезных советов для проектирования тестов с учетом риска:

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


Настроение дня:


Готовая тема попутчика Декстера.