Тестирование
Целью процесса тестирования является выявление ошибок в программе. Чем больше ошибок нашли, тем лучше. О том, как интерпретировать количество ошибок, будет рассказано в параграфе "Надежность и качество". Мы будем различать три этапа тестирования на стадии проектирования, реализации и тестирование законченного продукта. Неплохо также тестировать сам процесс тестирования, но эта тема уже выходит за рамки данной книги.
Тестирование ни в коем случае не стоит делать непосредственному испольнителю, т.к. у него уже замыленный взгляд. Он знает, как спроектирована или работает программа, что ей подавать на вход. Человек так устроен, что всегда идет не самым простым и правильным путем, а тем, которым у него уже получалось дойти до цели. Другими словами, проектировщик или программист уже интуитивно представляет пути, по которым надо идти, чтобы получить результат. И он не знает и не представляет еще 1001 способ, которым можно воспользоваться программой.
Надо правильно понимать, что процесс тестирования не ставит своей задачей доказать правильность работы программы или информационной системы. Это просто невозможно сделать, т.к. невозможно протестировать абсолютно все варианты работы и использования программы. Однако, можно говорить, что были пройдены такие-то тесты и программа работоспособна. Результаты тестирования необходимо документировать и подшивать в отчет. В ходе тестирования тестерам должны быть доступны исходные коды программ. Но не путайте процесс тестирования с отладкой. Задачей тестера является зафиксировать ошибку и, по возможности, указать, как ее можно воспроизвести. Исправлять и отлаживать программу должен программист.
Поскольку, как уже было сказано, протестировать все возможные случаи работы программы нельзя, то необходимо протестировать ее работу в характерных точках.
Прежде, чем приступать к поиску ошибок необходимо определить, что такое ошибка и как ее идентифицировать. Для того чтобы можно было со стопроцентной уверенностью утверждать об обнаружение ошибки нужно иметь эталон, с которым можно было бы сравнивать объект тестирования.
В нашем случае мы не имеем точного эталона. При тестирование на стадии проектирования эталоном может служить логическая непротиворечивость и полнота функциональных требований. Необходиомо отметить, что поскольку мы имеем дело не с математикой, то полнота и непротиворечивость функциональных требований довольно субъективные характеристики и определяются здравым смыслом. На стадии реализации дело обстоит несколько проще, т.к. тестируются отдельные CGI-программы. Критерием обнаружения ошибки уже будет расхождение с проектной документацией. Казалось бы тот же критерий можно применить и на стадии тестирования конечного продукта. Но за время разработки, как правило, функциональные требования к системе немного меняются. Некоторые добавляются, некоторые оказываются невостребованными. В значительной степени функциональные требования могут быть уточнены и дополнены на стадии тестирования и внедрения. Иногда ошибки закрадываются и в ходе самого процесса тестирования. Например, у нас был такой случай, когда при тестировании программного продукта все гиперссылки на одной машине открывались в новом окне. Разработчиков на уши поставили, мол в чем дело? Оказалось, клавиша Shift на клавиатуре запала. Эта ошибка тестирования, конечно, была быстро выявлена. Но это пример из реальной жизни. Бывают и значительно более сложные ситуации. Вследствие всего вышесказанного, можно лишь говорить об обнаружении ошибки с определенной долей вероятности. Разделим выявленные ошибки по следующим типам:
