Читаем Программирование. Принципы и практика использования C++ Исправленное издание полностью

Stone, Debbie, Caroline Jarrett, MarkWoodroffe, and Shailey Minocha. User Interface Design and Evaluation. Morgan Kaufmann, 2005. ISBN 0120884364.

Whittaker, James A. How to Break Software: A Practical Guide to Testing. Addison-Wesley, 2003. ISBN 0321194330.

Задание

Протестируйте функцию binary_search.

1. Реализуйте оператор ввода для класса Test из раздела 26.3.2.2.

2. Заполните файл тестов для последовательностей из раздела 26.3.

2.1. { 1 2 3 5 8 13 21 }        // "обычная последовательность"

2.2. { }

2.3. { 1 }

2.4. { 1 2 3 4 }                // нечетное количество элементов

2.5. { 1 2 3 4 5 }              // четное количество элементов

2.6. { 1 1 1 1 1 1 1 }               // все элементы равны

2.7. { 0 1 1 1 1 1 1 1 1 1 1 1 1 }   // другой элемент в начале

2.8. { 0 0 0 0 0 0 0 0 0 0 0 0 0 1 } // другой элемент в конце

3. Основываясь на разделе 26.3.1.3, выполните программу, генерирующую следующие варианты.

3.1. Очень большая последовательность (что считать большой последовательностью и почему?).

3.2. Десять последовательностей со случайным количеством элементов.

3.3. Десять последовательностей с 0, 1, 2 ... 9 со случайными элементами (но упорядоченные).

4. Повторите эти тесты для последовательностей строк, таких как { Bohr Darwin Einstein Lavoisier Newton Turing }.

Контрольные вопросы

1. Создайте список приложений, сопровождая их кратким описанием наихудшего события, которое может произойти из-за ошибки; например, управление самолетом — авиакатастрофа: гибель 231 человека; потеря оборудования на 500 млн. долл.

2. Почему мы не можем просто доказать, что программа работает правильно?

3. В чем заключается разница между модульным и системным тестированием?

4. Что такое регрессивное тестирование и почему оно является важным?

5. Какова цель тестирования?

6. Почему функция binary_search просто не проверяет свои требования?

7. Если мы не можем проверить все возможные ошибки, то какие ошибки следует искать в первую очередь?

8. В каких местах кода, манипулирующего последовательностью элементов, вероятнее обнаружить ошибки?

9. Почему целесообразно тестировать программу при больших значениях?

10. Почему часто тесты представляются в виде данных, а не в виде кода?

11. Почему и когда мы используем многочисленные тесты, основанные на случайных величинах?

12. Почему трудно тестировать программы, использующие графический пользовательский интерфейс?

13. Что необходимо тестировать при проверке отдельного модуля?

14. Как связаны между собой тестируемость и переносимость?

15. Почему классы тестировать труднее, чем функции?

16. Почему важно, чтобы тесты были воспроизводимыми?

17. Что может сделать тестировщик, обнаружив, что модуль основан на непроверяемых предположениях (предусловиях)?

18. Как проектировщик/конструктор может улучшить тестирование?

19. Чем тестирование отличается от отладки?

20. В чем заключается важность производительности?

21. Приведите два (и больше) примера того, как легко возникают проблемы с производительностью.

Ключевые слова

Упражнения

1. Выполните ваш алгоритм binary search из раздела 26.1 с тестами, представленными в разделе 26.3.1.

2. Настройте тестирование функции binary_search на обработку элементов произвольного типа. Затем протестируйте ее на последовательности элементов типа string и чисел с плавающей точкой.

3. Повторите упражнение 1 с вариантом функции binary_search, который получает в качестве аргумента критерий сравнения. Создайте список новых возможностей для появления ошибок, возникающих из-за дополнительного аргумента.

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

5. Добавьте новый тест в набор тестов для функции binary_search и попытайтесь перехватить (маловероятную) ошибку при модификации последовательности.

6. Слегка модифицируйте калькулятор из главы 7, предусмотрев ввод из файла и вывод в файл (или используя возможности операционной системы для перенаправления ввода-вывода). Затем изобретите для него исчерпывающий набор тестов.

7. Протестируйте простой текстовый редактор из раздела 20.6.

8. Добавьте текстовый интерфейс к библиотеке графического пользовательского интерфейса из глав 12–15. Например, строка Circle(Point(0,1),15) должна генерировать вызов Circle(Point(0,1),15). Используйте этот текстовый интерфейс для создания “детского рисунка”: плоский домик с крышей, два окна и дверь.

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT