В этой главе мы узнаем о тестировании потоковых приложений. Мы также узнаем о важности тестирования.
Зачем тестировать?
Прежде чем мы углубимся в дискуссию о важности тестирования, мы должны знать, что такое тестирование. В общем, тестирование — это метод определения того, насколько хорошо что-то работает. С другой стороны, особенно если мы говорим о компьютерных программах или программном обеспечении, то тестирование — это метод доступа к функциональности программ.
В этом разделе мы обсудим важность тестирования программного обеспечения. При разработке программного обеспечения должна быть двойная проверка перед выпуском программного обеспечения для клиента. Вот почему очень важно тестировать программное обеспечение опытной командой тестирования. Рассмотрим следующие моменты, чтобы понять важность тестирования программного обеспечения:
Улучшение качества программного обеспечения
Конечно, ни одна компания не хочет поставлять программное обеспечение низкого качества, и ни один клиент не хочет покупать программное обеспечение низкого качества. Тестирование улучшает качество программного обеспечения, обнаруживая и исправляя ошибки в нем.
Удовлетворенность клиентов
Самая важная часть любого бизнеса — это удовлетворение их клиентов. Предоставляя программное обеспечение без ошибок и хорошего качества, компании могут достичь удовлетворенности клиентов.
Уменьшить влияние новых функций
Предположим, что мы сделали программную систему из 10000 строк, и нам нужно добавить новую функцию, тогда команда разработчиков будет обеспокоена влиянием этой новой функции на все программное обеспечение. Здесь также тестирование играет жизненно важную роль, потому что если команда тестирования выполнила хороший набор тестов, то это может спасти нас от любых возможных катастрофических прорывов.
Пользовательский опыт
Другой наиболее важной частью любого бизнеса является опыт пользователей этого продукта. Только тестирование может гарантировать, что конечный пользователь найдет простой и легкий в использовании продукт.
Сокращение расходов
Тестирование может сократить общую стоимость программного обеспечения, обнаруживая и исправляя ошибки на этапе тестирования его разработки, а не исправляя его после поставки. Если после поставки программного обеспечения возникнет серьезная ошибка, это приведет к увеличению его материальных затрат, скажем, с точки зрения затрат и нематериальных затрат, с точки зрения неудовлетворенности клиентов, негативной репутации компании и т. Д.
Что проверить?
Всегда рекомендуется иметь соответствующие знания о том, что должно быть проверено. В этом разделе мы сначала поймем основной мотив тестера при тестировании любого программного обеспечения. Следует избегать покрытия кода, т. Е. Сколько строк кода попадет в наш набор тестов во время тестирования. Это связано с тем, что во время тестирования концентрация только на количестве строк кода не добавляет реальной ценности нашей системе. Могут остаться некоторые ошибки, которые отражаются позже на более позднем этапе даже после развертывания.
Рассмотрим следующие важные моменты, связанные с тем, что тестировать —
-
Нам нужно сосредоточиться на тестировании функциональности кода, а не покрытия кода.
-
Нам нужно сначала протестировать наиболее важные части кода, а затем перейти к менее важным частям кода. Это определенно сэкономит время.
-
Тестер должен иметь множество различных тестов, которые могут расширить программное обеспечение до его пределов.
Нам нужно сосредоточиться на тестировании функциональности кода, а не покрытия кода.
Нам нужно сначала протестировать наиболее важные части кода, а затем перейти к менее важным частям кода. Это определенно сэкономит время.
Тестер должен иметь множество различных тестов, которые могут расширить программное обеспечение до его пределов.
Подходы для тестирования параллельных программ
Из-за способности использовать истинную способность многоядерной архитектуры, параллельные программные системы заменяют последовательные системы. В последнее время параллельные системные программы используются во всем, от мобильных телефонов до стиральных машин, от автомобилей до самолетов и т. Д. Мы должны быть более осторожными при тестировании параллельных программ, потому что, если мы добавили несколько потоков в однопоточное приложение, имеющее уже ошибка, то мы бы в конечном итоге с несколькими ошибками.
Методы тестирования для параллельных программных программ в основном сосредоточены на выборе чередования, которое представляет потенциально вредные схемы, такие как условия гонки, взаимоблокировки и нарушение атомарности. Ниже приведены два подхода к тестированию параллельных программ:
Систематическое исследование
Этот подход направлен на то, чтобы исследовать пространство чередований как можно шире. Такие подходы могут использовать метод грубой силы, а другие применяют метод сокращения частичного порядка или эвристический метод для исследования пространства перемежений.
Недвижимость приводом
Подходы, основанные на свойствах, основаны на наблюдении, что сбои параллелизма более вероятны при чередованиях, которые раскрывают определенные свойства, такие как подозрительный шаблон доступа к памяти. Различные подходы, основанные на свойствах, нацелены на различные неисправности, такие как состояние гонки, взаимоблокировки и нарушение атомарности, что также зависит от тех или иных конкретных свойств.
Стратегии тестирования
Тестовая стратегия также известна как тестовый подход. Стратегия определяет, как будет проводиться тестирование. Тестовый подход имеет две методики —
Проактивная
Подход, при котором процесс разработки теста инициируется как можно раньше, чтобы найти и исправить дефекты до создания сборки.
реагирующий
Подход, при котором тестирование не начинается до завершения процесса разработки.
Прежде чем применять какую-либо стратегию тестирования или подход к программе на Python, мы должны иметь представление о типах ошибок, которые может иметь программа. Ошибки заключаются в следующем —
Синтаксические ошибки
Во время разработки программы может быть много мелких ошибок. Ошибки в основном из-за опечаток. Например, отсутствие двоеточия или неправильное написание ключевого слова и т. Д. Такие ошибки связаны с ошибкой в синтаксисе программы, а не в логике. Следовательно, эти ошибки называются синтаксическими ошибками.
Семантические ошибки
Семантические ошибки также называют логическими ошибками. Если в программном обеспечении есть логическая или семантическая ошибка, оператор будет скомпилирован и выполнен правильно, но не даст желаемого результата, поскольку логика неверна.
Модульное тестирование
Это одна из наиболее часто используемых стратегий тестирования для тестирования программ на Python. Эта стратегия используется для тестирования модулей или компонентов кода. Под единицами или компонентами мы подразумеваем классы или функции кода. Модульное тестирование упрощает тестирование больших систем программирования за счет тестирования «маленьких» модулей. С помощью вышеупомянутой концепции модульное тестирование может быть определено как метод, в котором отдельные блоки исходного кода проверяются, чтобы определить, возвращают ли они желаемый результат.
В наших последующих разделах мы узнаем о различных модулях Python для модульного тестирования.
модуль unittest
Самый первый модуль для модульного тестирования — это модуль unittest. Он вдохновлен JUnit и по умолчанию включен в Python3.6. Он поддерживает автоматизацию тестирования, совместное использование кода настройки и завершения для тестов, агрегирование тестов в коллекции и независимость тестов от среды отчетности.
Ниже приведены несколько важных концепций, поддерживаемых модулем unittest.
Текстовое крепление
Он используется для настройки теста таким образом, чтобы его можно было запустить перед началом теста и разорвать после окончания теста. Это может включать создание временной базы данных, каталогов и т. Д., Необходимых перед началом теста.
Прецедент
Тестовый пример проверяет, поступает ли требуемый ответ от определенного набора входов или нет. Модуль unittest включает базовый класс с именем TestCase, который можно использовать для создания новых тестовых случаев. Он включает два метода по умолчанию —
-
setUp () — метод подключения для настройки тестового прибора перед его применением. Это вызывается перед вызовом реализованных методов тестирования.
-
tearDown ( — метод ловушки для деконструкции объекта класса после запуска всех тестов в классе.
setUp () — метод подключения для настройки тестового прибора перед его применением. Это вызывается перед вызовом реализованных методов тестирования.
tearDown ( — метод ловушки для деконструкции объекта класса после запуска всех тестов в классе.
Тестирование
Это набор тестовых наборов, тестовых случаев или обоих.
Тест бегун
Он контролирует выполнение тестовых случаев или костюмов и предоставляет результат пользователю. Он может использовать графический интерфейс или простой текстовый интерфейс для обеспечения результата.
пример
Следующая программа на Python использует модуль unittest для тестирования модуля с именем Fibonacci . Программа помогает в расчете ряда Фибоначчи от числа. В этом примере мы создали класс с именем Fibo_test, чтобы определять тестовые случаи с использованием различных методов. Эти методы унаследованы от unittest.TestCase. Мы используем два метода по умолчанию — setUp () и tearDown (). Мы также определяем метод testfibocal. Название теста должно начинаться с буквенного теста. В последнем блоке unittest.main () предоставляет интерфейс командной строки для сценария тестирования.
import unittest def fibonacci(n): a, b = 0, 1 for i in range(n): a, b = b, a + b return a class Fibo_Test(unittest.TestCase): def setUp(self): print("This is run before our tests would be executed") def tearDown(self): print("This is run after the completion of execution of our tests") def testfibocal(self): self.assertEqual(fib(0), 0) self.assertEqual(fib(1), 1) self.assertEqual(fib(5), 5) self.assertEqual(fib(10), 55) self.assertEqual(fib(20), 6765) if __name__ == "__main__": unittest.main()
При запуске из командной строки приведенный выше сценарий создает вывод, который выглядит следующим образом:
Выход
This runs before our tests would be executed. This runs after the completion of execution of our tests. . ---------------------------------------------------------------------- Ran 1 test in 0.006s OK
Теперь, чтобы прояснить ситуацию, мы меняем наш код, который помог в определении модуля Фибоначчи.
Рассмотрим следующий блок кода в качестве примера —
def fibonacci(n): a, b = 0, 1 for i in range(n): a, b = b, a + b return a
Несколько изменений в блоке кода сделаны как показано ниже —
def fibonacci(n): a, b = 1, 1 for i in range(n): a, b = b, a + b return a
Теперь, после запуска скрипта с измененным кодом, мы получим следующий вывод:
This runs before our tests would be executed. This runs after the completion of execution of our tests. F ====================================================================== FAIL: testCalculation (__main__.Fibo_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "unitg.py", line 15, in testCalculation self.assertEqual(fib(0), 0) AssertionError: 1 != 0 ---------------------------------------------------------------------- Ran 1 test in 0.007s FAILED (failures = 1)
Приведенный выше вывод показывает, что модуль не смог выдать желаемый результат.
Docktest модуль
Модуль Docktest также помогает в модульном тестировании. Он также поставляется в комплекте с питоном. Это проще в использовании, чем модуль unittest. Модуль unittest больше подходит для сложных тестов. Для использования модуля doctest нам нужно его импортировать. Строка документации соответствующей функции должна иметь интерактивный сеанс Python вместе с их выходными данными.
Если в нашем коде все хорошо, то из модуля docktest не будет выходных данных; в противном случае он предоставит вывод.
пример
В следующем примере Python используется модуль docktest для тестирования модуля с именем Fibonacci, который помогает в вычислении ряда Фибоначчи от числа.
import doctest def fibonacci(n): """ Calculates the Fibonacci number >>> fibonacci(0) 0 >>> fibonacci(1) 1 >>> fibonacci(10) 55 >>> fibonacci(20) 6765 >>> """ a, b = 1, 1 for i in range(n): a, b = b, a + b return a if __name__ == "__main__": doctest.testmod()
Мы можем видеть, что строка документации соответствующей функции с именем fib имела интерактивный сеанс Python вместе с выходными данными. Если с нашим кодом все в порядке, то из модуля doctest не будет выходных данных. Но чтобы увидеть, как это работает, мы можем запустить его с опцией –v.
(base) D:\ProgramData>python dock_test.py -v Trying: fibonacci(0) Expecting: 0 ok Trying: fibonacci(1) Expecting: 1 ok Trying: fibonacci(10) Expecting: 55 ok Trying: fibonacci(20) Expecting: 6765 ok 1 items had no tests: __main__ 1 items passed all tests: 4 tests in __main__.fibonacci 4 tests in 2 items. 4 passed and 0 failed. Test passed.
Теперь мы изменим код, который помог в определении модуля Фибоначчи
Рассмотрим следующий блок кода в качестве примера —
def fibonacci(n): a, b = 0, 1 for i in range(n): a, b = b, a + b return a
Следующий блок кода помогает с изменениями —
def fibonacci(n): a, b = 1, 1 for i in range(n): a, b = b, a + b return a
После запуска сценария даже без опции –v с измененным кодом мы получим вывод, как показано ниже.
Выход
(base) D:\ProgramData>python dock_test.py ********************************************************************** File "unitg.py", line 6, in __main__.fibonacci Failed example: fibonacci(0) Expected: 0 Got: 1 ********************************************************************** File "unitg.py", line 10, in __main__.fibonacci Failed example: fibonacci(10) Expected: 55 Got: 89 ********************************************************************** File "unitg.py", line 12, in __main__.fibonacci Failed example: fibonacci(20) Expected: 6765 Got: 10946 ********************************************************************** 1 items had failures: 3 of 4 in __main__.fibonacci ***Test Failed*** 3 failures.
В приведенном выше выводе видно, что три теста не пройдены.