Учет учебных материалов кафедры

• на экране не отображается ничего (сервер перегружен), или выдается системная ошибка с соответствующим кодом (ошибка авторизации, сбой);
• произошел внутренний сбой, при обращении к БД, при этом генерируется отчет об ошибке;
• ошибка в выборе языка либо различные языки выбраны для представления на экране различных разделов текста (ошибки системных кодировок);
• несоответствие конфигурации платформы и атрибутов отображения браузера.

Поскольку программа управления базой  данных учебных материалов является частью информационной системы кафедры  ИТ-4, построенной по модульному принципу, требуется проверить работоспособность всех модулей по завершении интеграции.

Для тестирования таких систем характерны два этапа. Во-первых, тестирование встраиваемого модуля  отдельно от всей системы в целом, и в случае отсутствия конфликтов переход ко второму этапу – тестированию всех модулей в совокупности – т.е. всей информационной системы в целом..

Тестирование на протяжении жизненного цикла PHP программ означает тестирование на наборе пользовательских транзакций. Эти транзакции должны быть выбраны таким образом, чтобы был использован полный набор серверных команд и запросов. Перспектива жизненного цикла обычно охватывает несколько различных платформ, в том числе и систему пользователя - браузер, СУБД и приложения сторонних разработчиков.

Завершенные системы, разрабатывавшиеся  различными коллективами программистов, должны взаимодействовать. Рассматриваемая система использует технологии PHP и SQL. При этом могут возникнуть проблемы совместимости типов данных, синхронизации событий, а также проблема необходимости ограничения их воздействия на работу системы. Например, когда на сервере, куда планируется установить программу, уже существует некоторое количество PHP программ и связанных с ними SQL баз.

Один из наиболее важных тестов предусматривает  построение тестовых случаев, которые  проверяют работу системы в условиях предельно допустимой нагрузки. Существуют инструментальные средства, упрощающие задачу увеличения количества запросов и вызова на сервере множества операций. Тест предельно допустимой нагрузки должен быть спроектирован так, чтобы в точности воспроизводить ожидаемый профиль использования. Должны быть запланированы тесты способности сервера ограничивать количество соединений в управляемом режиме (отображение на экране соответствующего сообщения), а не в катастрофическом режиме (полный отказ сервера).

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

• работа с PHP кодом программы;
• работа с базой данных (хранение, сортировка, выборка, поиск и анализ данных);
• формирование входных и выходных HTML страниц.

При программировании производился анализ БД, а после программирования – правильность отображения введенных данных.

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

К модулям программы, отвечающим за работу с базой данных, применялись все этапы и методы отладки ввиду того, что в них  была заложена наиболее трудоемкая часть  всей программы. А именно – осуществление анализа всех запросов пользователей и выявление нарушений в процессе обработки поступившей информации и других параметров. Для этого задавались различные исходные данные. Это позволило дополнительно протестировать предыдущие части программы, а также непосредственно отлаживать часть, отвечающую за работу с базой данных и анализ информации. Такая отладка проводилась путем сравнения ранее введенной информации и полученных данных с помощью программы.

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

3.2.1 Отладка кода с помощью Zend Debugger

Интеллектуальная интегрированная  среда разработки находит и помогает исправлять ошибки в интерактивном  режиме.

Специализированное приложение, называемое отладчиком, тестирует выполняющийся  код, позволяя остановить выполнение в произвольный момент времени, исследовать объекты, стек вызовов и даже изменить значение переменной "на лету".

Специализированное приложение, называемое отладчиком, помогает тестировать выполняющийся  код, позволяя останавливать его  выполнение в произвольных точках прерывания, исследовать объекты, стек вызовов и рабочую среду и даже изменять значение переменных "на лету".

При разработке использовался Zend Debugger - расширение системы Zend, тестирующее  выполняющееся PHP-приложение. Загрузить  и использовать Zend Debugger можно бесплатно. Однако для управления Zend Debugger и просмотра диагностической информации необходимо объединить его с клиентским приложением. Клиентское приложение может быть как элементарным, выполняющимся из командной строки, так и полнофункциональной интегрированной средой разработки (IDE), обладающей функциями редактора, завершения кода, визуальных браузеров классов и т.д.

С Zend Debugger могут взаимодействовать  несколько клиентских приложений с  открытыми исходными кодами, включая PHP-плагин для Eclipse. Однако я в качестве IDE для PHP предпочитаю использовать Zend Studio, предлагаемую компанией Zend Technologies, разрабатывающей как систему с открытыми исходными кодами. В отличие от самого PHP, Zend Studio является коммерческим продуктом. Продукт можно загрузить и использовать бесплатно на протяжении 30 суток (чего вполне достаточно для того, чтобы опробовать многочисленные возможности IDE), но затем необходимо купить лицензию, если вы захотите продолжать ее использование.

Комбинация Zend Studio и Zend Debugger позволяет удаленно управлять системой Zend. Zend Studio выступает в роли панели управления, отображающей информацию о внутренних деталях системы. Среди прочих данных можно просматривать выполняющийся исходный код, состояние переменных и состояние рабочей Web-среды.

Zend Debugger является своего рода  посредником - он передает информацию  из системы Zend в Zend Studio и команды  из Zend Studio в систему Zend. В число  его команд входят функции  отладки, например, continue (продолжение), которая продолжает выполнение, step (шаг), которая выполняет один оператор, и stop (останов), которая прерывает выполнение. При любых изменениях в системе Zend отладчик передает эти изменения в Zend Studio для отображения.

Таким образом, для отладки PHP-приложения мы настраиваем Zend Studio на подключение к отладчику и затем открываем приложение в браузере, как обычно. Когда приложение начинает выполняться, отладчик вмешивается в его работу и передает управление в Zend Studio. А там мы принимаем управление на себя.

Zend Studio содержит все необходимое  для написания PHP-кода: редактор  для изменения отдельных файлов, менеджер файлов, чтобы собирать  файлы в проект, браузер PHP-классов  и модулей, используемый в качестве  справки, окно вывода для просмотра  промежуточных результатов работы и браузер рабочей среды, отображающий переменные, стек вызовов и выходной буфер. Но еще лучше то, что редактор является контекстно-чувствительным и может автоматически завершать управляющие PHP-структуры, ключевые слова и разделители строк.

Основным методом работы с любым  отладчиком является расстановка т.н. «точек прерывания» (breakpoints), для выяснения возможных причин сбоя программы, получения логов или дополнительной информации. На рисунке 2.8 показано окно Zend Debugger во время работы с «точками прерывания».

 

 

Рисунок 2.8 – Установка точек прерывания в примере кода

3.2.2 Автоматизированное тестирование  программы – SimpleTest

Автоматизированные модульные  тесты разрабатывались с использованием бесплатной системы тестирования PHP SimpleTest [3.6]. Эти тесты использовались для регрессивного тестирования системы: при разработке новых функций, необходимо было убедиться, что ранее реализованные функции продолжают функционировать нормально. Тесты разрабатывались отдельно для каждой подсистемы: объектно-реляционного отображения, авторизации, модулей серверных компонентов, модулей каркаса пользовательского интерфейса.

Использование автоматизированных регрессивных модульных тестов позволило обнаружить ошибки, связанные с изменением корректности работы системы после внесения локальных изменений.

Основное назначение SimpleTest — проверка работоспособности классов и  функций, а также тестирование входных  и выходных данных для приложения.

В отличие от простейшего подхода  к организации тестирования путем самостоятельного написания методов проверки, классы SimpleTest позволяют кардинально расширить возможности тестируемого кода.

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

В первую очередь необходимо физически  связать вашу задачу и тестирующие  функции. Для этого следует включить в тестирующий код сами классы (как минимум файлы simpletest/unit_tester.php и simpletest/reporter.php) SimpleTest с помощью директив require_once. Сам тестирующий код по замыслу разработчиков должен выделяться в отдельный класс, который наследует свойства родительского объекта. Этим объектом является класс UnitTestCase, который содержит функции, необходимые для проверки разнообразных значений, которые могут возвращать методы наших классов.

Наиболее простыми методами этого  класса являются методы assertFalse и assertTrue, которые позволяют проверить  функции, возвращающие логические значения True или False. Таким образом, проверка может осуществляться путем вызова одного из методов, в качестве параметра которого передается тестируемая функция с необходимым для нее набором параметров.

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

assertTrue($x) — выдается ошибка, если  значение False;

assertFalse($x) — получаете ошибку  тестирования, если переданное значение True;

assertNull($x) — проверка, существует  ли переданное значение;

assertNotNull($x) — указанное в параметрах  метода значение не должно  существовать;

assertIsA($x, $t) — переменная $x не должна  иметь тип $t;

assertNotA($x, $t) — проверка на соответствие  типа переменной $x строке $t;

assertEqual($x, $y) — проверка на равенство $x и $y;

assertNotEqual($x, $y) — проверка на неравенство  $x и $y;

assertWithinMargin($x, $y, $m) — проверка того, что разница $x и $y меньше $m;

assertOutsideMargin($x, $y, $m) — разница $x и $y больше $m;

Для передачи сообщений в итоговый отчет и автоматизации некоторых функций, а также для тестирования собственной работоспособности SimpleTest предлагает набор специальных вспомогательных методов. Метод setUp (setDown) позволяет указать функцию, которая будет выполняться перед (после) каждым вызовом тестового метода класса. Функции pass() и fail() вызываются в качестве теста для самих классов SimpleTest. Метод sendMessage() передает пользовательское сообщение в итоговый отчет. Для очистки очереди ошибок можно применить метод swallowErrors.

Использование SimpleTest в качестве тестирующего класса позволило проверить стабильность его работы. Мы могли проконтролировать правильность написанного кода в любой момент разработки, что было особенно актуально, когда над одним и тем же классом работали несколько программистов. В функциональности SimpleTest есть множество других возможностей, которые помогли протестировать наше приложение. В случае если бы в качестве фреймворка был бы использован не CodeIgniter, а Eclipse, можно было бы использовать специальное расширение, которое позволило бы упростить процесс запуска тестирующего кода. В нашем же случае использовалась простейшая гиперссылка с всплывающим окном, которая показывала результаты тестирования функций в текущем коде.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 Безопасность жизнедеятельности

4.1 Анализ опасных и вредных  факторов, возникающих при работе  на ПЭВМ

Операторы ПЭВМ, программисты-операторы, работающие с компьютерным оборудованием, в течение рабочего дня должны воспринимать большие объемы информации, быстро и адекватно реагировать на ее изменение.

Для предупреждения от возможных заболеваний, утомления и повышения работоспособности оператора необходимо выделить опасные и вредные факторы, причины их возникновения и возможные пути устранения, которые позволят грамотно подойти к организации условий труда программистов и операторов ПЭВМ.

Опасными считаются такие факторы, которые могут привести к травмам  или летальному исходу.

Вредными называются такие факторы, которые имеют негативное воздействие на человека, и которые могут привести к ухудшению самочувствия и различным заболеваниям, связанными с их воздействием.