Виды контроля ПС:

• 
  Визуальный,
  
• 
  Статический
  
• 
  динамический
  

Визуальный контроль - это проверка программ “ за столом “, без использования компьютера.

1. 
   сначала осуществляется чтение программы
   
2. 
   затем осуществляется сквозной контроль программы (ее ручная прокрутка на нескольких заранее подобранных простых тестах).
   

Статический контроль - это проверка программы по ее тексту (без выполнения) с помощью инструментальных средств. Формы статического контроля:

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

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

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

Отладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ.

Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом.

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

Отладка = Тестирование + Поиск ошибок + Редактирование.

---

Каждому программисту известно, сколько времени и сил уходит на отладку программ. На этот этап приходится около 50% общей стоимости разработки программного обеспечения. Тестирование - это процесс выполнения программы с целью обнаружения в ней ошибок. Но Нельзя гарантировать, что тестированием ПС можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи:

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

Заповеди отладки.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

Заповедь 4. Избегайте невоспроизводимых тестов, документируйте их пропуск через компьютер; детально изучайте результаты каждого теста.

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Советы по организации тестирования

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

---

Основные принципы организации тестирования ПС

Существует 4 этапа тестирования многомодульных ПС:

1. 
   Тестирование отдельных модулей;
   
2. 
   Совместное тестирование модулей;
   
3. 
   Тестирование функций программного комплекса;
   
4. 
   Тестирование всего комплекса в целом.
   

На первых двух этапах используются прежде всего методы структурного программирования. При структурном тестировании программа рассматривается как “белый ящик” (т.е. ее текст открыт для пользования). Происходит проверка логики программы.

Совместное тестирование модулей

Два подхода к совместному тестированию модулей:

1. 
   Пошаговое. Каждый модуль для своего тестирования подключается к набору уже проверенных модулей. Здесь модули проверяются не изолированно друг от друга, поэтому требуются либо только ведущие модули, либо только заглушки.
   
2. 
   Монолитное. Сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования. Для каждого модуля требуется модуль, имитирующий вызов тестируемого модуля, и один или несколько модулей, имитирующих работу модулей, вызываемых из тестируемого. При пошаговом тестировании
   

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

Наиболее важные для программы в целом модули должны тестироваться в первую очередь.

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

Тестирование функций ПС

Используются методы функционального тестирования. При функциональном тестировании программа рассматривается как “черный ящик” (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее

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

---

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестированием. Точность, устойчивость, защищенность, временная эффективность, в какой-то мере - эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств могут тестироваться. Легкость применения ПС оценивается при тестировании документации по применению ПС.

Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также неудобств применения ПС. Этот этап непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию требований к ПС и аттестации ПС), поэтому весьма важно разработчикам сначала самим воспользоваться ПС так, как это будет делать пользователь. Все тесты на этом этапе готовятся исключительно на основании только документации по применению ПС. Должны быть протестированы все неясные места в документации, а также все примеры, использованные в документации.

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

Виды программных документов.

---

Документация, создаваемая в процессе разработки программных средств.

При разработке ПС создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы:

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

---

Смотрите также файлы

• Влияние налогов и налогового планирования на ценовую политику.docx

• Актуальность выбранной темы.docx

• Методика организации ситуационноролевой игры.docx

• Отчет по практике на базе прохождения омвд россии по Надеждинскому району в период времени с.docx

• Маманды лемі курсы бойынша Жмыс дптері (89шы сынып оушыларына арналан).docx