@cheden2008

Мне дали задание протестировать Приложение на C++(Не я его писал). Все требования разработчиком выполнены. Всё работает хорошо. Но нужно найти ошибки (Проблемы) в коде программы. Если кто занимался тестированием готовых приложений, подскажите с чего лучше начать, какие средства Microsoft Visual Studio использовать, может другие программы для проверки кода посоветуете или литературу. Или самому весь код просматривать и искать ошибки. В общем помогите чем можете.

0

@IT_Exp

cheden2008,

CppUnit - старейший и известный фреймфорк для тестирования приложений на C++, порт JUnit
Несколько тяжеловат для создания тестов, но есть возможность визуального представления.

GoogleTest - фреймворк от лучшего поисковика в мире очень богатые возможности для тестирования + поддержка mock-объектов. субьективно - лучший из open sourced.
хотя GUI-части не имеет.

тестирование качества готового кода - PC Lint
тестирование в процессе выполнения - AQTime, Purify ...

1

@Nick Alte

CppUnit - не просто для тестирования, а для модульного тестирования, TDD. В данном случае не подходит. Остальное тоже в общем лишнее.

Начать надо с выявления ошибок в программе. Подсовывать ей различные стрёмные данные, пытаться заставить совершить ошибку. После чего уже выявлять место в коде, за эту ошибку отвечающее, при помощи трассировки, просмотра содержимого переменных и при помощи точек останова, в том числе "стукачей". Это всё встроено в Visual Studio, возможности там богатые.

0

@CheshireCat

Вот тут я усматриваю некоторые противоречия.
Противоречие 1. "Все требования разработчиком выполнены. Всё работает хорошо." - на каком основании сделан этот вывод? Означает ли этот вывод, что приложение уже тестировалось? Кем, как, когда? Если приложение уже прошло тестирование (а, возможно, и испытания и приемку заказчиком) - то нафига его еще раз перетестировать?? Зачем тратить время и деньги на повторное выполнение уже сделанной работы?
А если (это возможно, такое бывает) уже на этапе испытаний или в ходе эксплуатации выявлены недоделки по функционалу или некорректная работа приложения, и тебе дали задание его перетестировать, - то на каком основании ты утверждаешь "Все требования разработчиком выполнены. Всё работает хорошо.", ведь при такой ситуации это явная чушь?
Противоречие 2. "Но нужно найти ошибки (Проблемы) в коде программы." - это не есть тестирование, это называется code inspection. Так что же именно тебе поручили? Тестирование программы или инспекцию кода? Это - разные виды деятельности, и организуются по-разному, и выполняются различными инструментами, и имеют различные выходные (результирующие) документы.

0

@cheden2008

Вместе с приложением есть ещё постановка задачи разработчику. Все требования из этой постановки разработчиком выполнены(вот что я имею в виду). Это интерфейс(Необходимо реализовать простую электронную таблицу в виде оконного Windows, Каждая ячейка характеризуется порядковым номером, как в MS Excel (A1, A2 и.т.д)), занесение и обработка данных, предусмотрен вывод ошибок вычисления формул. Всё это я проверял на некоректных, граничных случаях. При некоректном занесение формул , вычисляемая ячейка содержит словосообщение об ошибке(как и нужно в постановке).
Дословно мне написали задание: "Приложение нужно протестировать. И предоставить список обнаруженных проблем. Формат предоставления отчета: свободный. Единственное требование - отчет должен быть воспринимаемым и из описания была понятна суть проблемы (ошибки)."
Из этого я сделал вывод что ошибке могут быть где то в программе(Н-р некоректное использование памяти, ненужный заход в функцию(время) и т.п.).

0

@CheshireCat

Ага. Ну, тогда все более-менее упрощается.
1. "Вместе с приложением есть ещё постановка задачи разработчику." - отлично! Пишешь такой документ - Программу и методику испытаний (ПиМИ), он, собственно, ГОСТированный. На каждый пункт постановки задачи разработчику пишешь подробную методику проверки - как проверить выполнение этого пункта требований при нормальных, некорректных и граничных данных, и - по каждому пункту однозначный вывод: "Результат испытания по п.XXX считается удовлетворительным, если....." Эту ПиМИ согласуешь с тем, кто поставил тебе задачу по тестированию (условно, заказчиком). И выполняешь все по ПиМИ с соответствующими выводами. Проверяешь именно выполнение всех оговоренных требований, не более и не менее - т.е. разработчик обязан выполнить все, что оговорено, но он не обязан был делать что-либо сверх оговоренных требований или прямо вытекающих из них. Собственно, спецификация требований (SRS) есть?
2. "Приложение нужно протестировать. И предоставить список обнаруженных проблем. Формат предоставления отчета: свободный. Единственное требование - отчет должен быть воспринимаемым и из описания была понятна суть проблемы (ошибки)." - при такой постановке задачи внутреннее устройство программы тебя вообще не должно интересовать, ты тестируешь только выполнение требований к ней (ее внешнее наблюдаемое поведение) методом "черного ящика". По той самой ПиМИ, согласованной с твоим руководством или заказчиком.
Тебе нет смысла добровольно взваливать на себя функцию инспекции кода - ведь, насколько я понимаю, при такой постановке задачи тебе за это не заплатят....... Вообще же, при нормальной постановке процесса разработки инспекция кода должна была быть уже проведена на более ранних стадиях разработки. У тебя же - скорее приемочное тестирование.

0

@cheden2008

Это задание мне дали при приеме на работу(специалистом по тестированию ПО). Врт что ещё написали: "Внимание будет обращаться на общие технические навыки, умение выполнять задачи, структурировать мысли и искать необходимую информацию".

0

@CheshireCat

Ага. Так вот с этого и надо было начинать!
0. Перед началом тестирования не забудь прочесть документацию к программе - Руководство пользователя или User Guide - как она работает, дабы случайно не принять за ошибку что-то, являющееся просто следствием твоего неумения с ней работать и получить ожидаемый результат. Все тестирование ведешь по методу "черного ящика".
Пишешь ПиМИ и выполняешь ее с подробным описанием нехороших результатов (какая точно последовательность шагов позволяет гарантированно воспроизвести ошибку, либо если ошибка "плавающая" - то указать, что не воспроизводится), буде таковые будут получены; либо с заключением о положительном результате тестирования.
В ПиМИ обрати внимание на:
1. Functional Testing + Boundary conditions check - проверяешь выполнение всех требуемых функций программы по методу "черного ящика" - тестируешь только наблюдаемое внешнее поведение программы при различных входных данных.
2. Далее, ЕСЛИ такое требование было указано разработчику, тестируешь локализацию программы в разных локализованных версиях ОС. Здесь же проверяешь ошибки в User Interface.
3. Протестируй нарушения работы программы при намеренно некорректном вводе - типа попыток buffer overrun и вообще security.
4. Performance Testing — проверяешь выполнение требований к временн`ым характеристиками программы (ЕСЛИ таковые были четко указаны в постановке задачи разработчику).
6. Load Testing — проверяешь работу программы при ОЧЕНЬ БОЛЬШИХ! объемах входных данных. Максимальный объем входных данных, вероятно, был указан в требованиях.
7. Stress Testing — проверяешь работу при сильно ограниченных аппаратных ресурсах (на самой минимальной указанной в постановке задачи конфигурации ПК. Можно еще запустить другие требовательные к памяти/процессору программы, дабы "застрессить" тестируемую программу окончательно).
8. Stability Test — проверяешь на утечки памяти, ресурсов и т.п. при очень долговременной работе программы (эти гадости имеют нехорошее свойство проявляться очень не сразу!), в простейшем случае - с помощью Process Explorer или Диспетчера Процессов Винды, либо с помощью специализированных инструментов типа Compuware BoundsChecker, Rational Purify и т.п.
Результаты по каждому пункту, если они нехорошие - тщательно описываешь! (Если хорошие - то пишешь просто "результат испытания удовлетворительный".) Самое главное для тестировщика - точно описать ожидаемое поведение программы, реальное поведение (в чем отличается?) и точную последовательность шагов, ведущих к воспроизведению зафиксированной ошибки, дабы разработчики могли ее воспроизвести и исправить.

1

Бэль

Всем привет! мне очень нужен специалист, который разбирается в тестировании приложений с Visual Studio 2010!!! Напишите пожалуйста мне на почту кто может помочь!!!!!!!!!!!ebodnar@spe******t.ru