- •Минск 2016
- •Цель работы
- •Общие сведения
- •Теоретические сведения
- •1. Различные подходы к тестированию (черный ящик, белый ящик)
- •2. Смежные вопросы тестирования
- •3. Требования к программному продукту и тестирование
- •4. Модульное тестирование
- •4.2. Обзоры
- •4.3. Принципы тестирования структуры программных модулей
- •При планировании тестирования структуры программных модулей решаются 2 задачи:
- •4.4. Способы тестирования взаимодействия модулей
- •4.5. Стратегии выполнения пошагового тестирования
- •4.6. Объектно-ориентированное тестирование
- •Литература
- •Дополнительная литература
- •Приложение а образец требований
- •Содержание
- •Введение
- •1. Общее описание
- •1.1. Функции продукта
- •1.1.1. Работа в роли администратора
- •1.1.2. Работа в роли клиента
- •1.2. Пользовательские характеристики
- •1.3. Общие ограничения
- •2.1.4. Регистрация пользователя
- •2.1.5. Просмотр информации о пользователях. Изменение статуса пользователя
- •2.1.6. Добавление нового пользователя
- •2.1.7. Удаление пользователя
- •2.1.8. Редактирование данных пользователя
- •2.1.9. Просмотр тем тестов
- •2.1.10. Добавление нового теста
- •2.1.11. Удаление теста
- •2.1.12. Просмотр вопросов теста и редактирование теста
- •2.1.13. Добавление вопроса к тесту
- •2.1.14. Удаление вопроса из теста
- •2.1.15. Редактирование вопроса
- •2.1.16. Добавление варианта ответа к вопросу
- •2.1.17. Удаление варианта ответа
- •2.1.18. Прохождение теста
- •Содержание расчетно-пояснительной записки
- •Содержание
2. Смежные вопросы тестирования
Об экономической стороне тестирования. Тестирование само по себе является затратной деятельностью, отнимающей у нас время и деньги. Поэтому в большинстве случаев разработчики программного обеспечения (ПО) заранее формулируют какой-либо критерий качества создаваемых программ (определяют так называемую планку качества), добиваются выполнения этого критерия и после этого прекращают тестирование и выпускают продукт на рынок. Такая концепция получила название Good Enough Quality (достаточно хорошое ПО), в противовес более очевидной концепции Best Possible Quality (максимально качественное ПО).
К сожалению, принцип Good Enough Quality зачастую понимают неправильно, ближе к формулировке Quality - If Time Permits (качество - если будет время). Конечно, выпуск плохо протестированного продукта из-за недостатка времени - это плохая практика. Практика показывает, что пользователи склонны со временем забывать даже значительные задержки с выпуском продукта, но плохое качество выпущенного продукта запоминается на всю жизнь.
На самом деле, Good Enough Quality - это просто поиск разумного компромисса между затратами на тестирование, длительностью разработки продукта и его качеством. Ничего умнее пока не придумали.
Психологические аспекты тестирования. Тестирование принципиально отличается от программирования по своим психологическим характеристикам. Дело в том, что программирование носит конструктивный характер, а тестирование ПО - деструктивно по своей природе. Можно сказать, что программист строит что-то, создает из ничего нечто, а тестировщик отыскивает недостатки этих построений. Поэтому программисты так часто не замечают очевидных ошибок в своих программах: к своему творчеству трудно относиться критично - как к своим детям.
Все это не значит, что тестирование "хуже", чем программирование, или что в процессе тестирования нет места творчеству - просто эти виды деятельности отличаются коренным образом, и для тестирования требуется иной склад характера, чем для программирования. Следовательно, программист не должен тестировать свои собственные программы; для этого необходим другой человек. Более того, программист не должен тестировать даже чужие программы! Дело в том, что программист потратит какое-то время просто на "раскачку", перенастраиваясь на новую задачу. Даже переключение с одной программистской задачи на другую требует обычно от 10 минут до получаса. Понятно, что переключение с одного образа мышления на другой отнимет существенно больше времени - возможно даже день или два.
Кстати, именно поэтому с точки зрения разработчика e-mail значительно выгоднее телефона (есть возможность ответить на вопросы после достижения некоторой логической точки в работе). Более того, программистам рекомендуют проверять почту не постоянно, а два-три раза в день - чтобы увеличить среднее время работы без отвлечений.
Итак, будем считать, что команда разработчиков не должна совпадать с командой инженеров тестирования, но при этом разработчики и тестировщики должны постоянно взаимодействовать друг с другом для достижения приемлемого качества окончательного продукта.
