Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тестирование программного обеспечения. Фундамен...docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
935.81 Кб
Скачать

Глава 12: Планирование и документация 305

1.

Наиболее вероятные ошибки

1'ИСУНОК 12.4.

Ги к тика

2.

Наиболее заметные ошибки

3.

Наиболее часто используемые области программы

кш )юционного

4.

Отличительные особенности программы

тестирования (2)

5.

Сложнейшие для тестирования аспекты

6.

Самые понятные для вас функциональные области

• Наиболее вероятные ошибки. Если известно, что в определенной части программы очень много ошибок, поработайте прежде всего с ней. Внутри программы ошибки обитают колониями. В ходе иссле­дований, проведенных Майерсом (Myers) в 1979 году, 47% ошибок было найдено в 4% всех модулей системы. Это пример, иллюстри­рующий совершенно реальную тенденцию — чем больше ошибок обнаружено в определенной области программы, тем больше их еще предстоит там найти. И даже вносимые исправления с большей чем обычно вероятностью влекут за собой новые ошибки. Те области, которые в ходе первоначального тестирования показали себя наибо­лее слабыми, останутся такими и в дальнейшем. Поэтому лучше всего начать с ними работать как можно раньше и как можно обсто­ятельнее.

• Наиболее заметные ошибки. Можно поступить и иначе — прежде всего сконцентрироваться на тех ошибках, которые более всего за­метны пользователю или наиболее негативно скажутся на его работе и на его впечатлении о продукте. Подумайте, какие части програм­мы будут использоваться чаще других, какие ее возможности выгод­но отличают ее от конкурентов и какие функции наиболее важны для пользователя. Те из функций, которые сами по себе хороши, но не являются жизненно важными компонентами продукта, можно протестировать во вторую очередь. Если они не работают, это, ко­нечно, плохо. Но гораздо хуже, если не функционируют базовые элементы продукта, ведь тогда это вообще не продукт.

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

• Отличительные особенности программы. Если вы продаете базу данных и утверждаете, что она сортирует таблицы в 48 раз быстрее, чем продукты конкурентов, функцию сортировки следует протести­ровать особенно тщательно. Если сортировка и в самом деле выпол­няется быстро, но неправильно, вряд ли это понравится пользователям. Высоко оптимизированные фрагменты кода являют­

306 Часть II: Приемы и технологии тестирования

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

• Сложнейшие для тестирования аспекты. Поговорите с программи­стом и спросите у него, есть ли в программе особенно сложные области, об ошибках в которых ему не хочется даже думать. Впол­не возможно, что он расскажет вам о таких областях. В этом случае возьмитесь за их тестирование как можно раньше, как минимум за несколько месяцев до окончательного выпуска продукта, чтобы у программиста было достаточно времени на исправление найденных там ошибок. Иначе, если вы найдете в такой области ошибку за неделю до выпуска, у программиста будет инфаркт или он уволит­ся и ошибка так и не будет исправлена.

• Самые понятные для вас функциональные области. Возможно, вы читали программный код или хорошо знакомы с продуктами подоб­ного типа. Это значит, что отдельные области программы вам на­столько хорошо знакомы, что вы готовы немедленно приступить к их тестированию. Так и поступайте. С остальными составляющими программы вы познакомитесь по ходу тестирования. Работая с наи­более понятной частью программы, постарайтесь разобраться, как она взаимодействует с остальными частями. В результате, даже если выбранная область не является критической, вы приобретете хоро­ший опыт, выявите ряд ошибок и в дальнейшем быстрее разберетесь с остальными составляющими продукта.

Углубление тестового плана

Тестовый план можно углубить путем добавления к нему разнообразных компонентов: списков функций, других рабочих списков, деревьев приня­тия решений, диаграмм граничных условий, тестовых матриц и т.д. Все это

— ваши средства анализа программы и выделения необходимых тестов.

• В следующем разделе, “Компоненты плана тестирования”, расска­зывается о назначении всех этих компонентов и о том, как их раз­рабатывать. Вы узнаете о том, какую роль в их создании играет эволюционный подход.

• После описания отдельных компонентов речь пойдет об их объеди­нении в различных типах плановых документов.

• Затем предмет дискуссии расширяется, охватывая организацию те­стового проекта и назначение приоритетов отдельным задачам. Эти вопросы освещаются в главе 13. В этой же главе, в нескольких разделах, посвященных проведению тестирования после выпуска альфа-версии продукта, продолжается дальнейшее рассмотрение процесса разработки тестового плана.