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