Сообщений в теме: 29

[Jack]

Здравствуйте...
Возникла такая проблемка... Пишу диплом, в котором создаю некоторое веб-приложение под Оракл. Научный руководитель программой вполне доволен, однако научности в работе никакой, а очень надо... Поступило предложение применить некоторые средства тестирования пользовательского интерфейса (да и всего остальнго) дабы показать что приложение написано качествено и "оптимальным" образом :)

Веб-сервер Apache2, СУБД Oracle9, PHP, python...

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

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

[barancev]

Какая тема диплома?

(Неужели тот факт, что программа не только написана, но и протестирована добавит "научности"? Весьма странно...)

[Jack]

тема диплома еще не окончательно сформулирована :) от научной части и будет зависеть финальное название...
а по поводу того что тестирование - малонаучно... Честно говоря я сам не понял этот факт... но руководитель сказал что можно попробовать - я и пробую...
я так понял им важно факт того, что программа не просто написана, а написана как то качественно :) по методике какой-нить :)

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

[Case]

Не морочте себе голову тулами автоматизации :)
Спросите руководителя что конкретно он хочет видеть. Цитфры, графики (что от чего), что именно?

[Jack]

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

[Case]

То есть хочется нагрузить программу/систему и показать, что она работает под нагрузками? Исходя из описания вашей системы, это что-то веб-based. Возьмите к примеру opensta и попробуйте записать несколько скриптов, которые будут эмулировать проигрыш каких-то важных транзакций в вашей системе (если таковые есть). Если не подойдёт этот тул можно попробовать спросит у Гугла.

Про тул которому можно доверять я не понял - а как вы это оцениваете?

[barancev]

Как-то Вы, уважаемый, не с той стороны заходите. Вы пытаетесь сначала найти решение, а потом под него задачу подогнать. Так тоже можно делать, но при этом результаты не гарантировны. При свободном исследовательском поиске я бы понял такой подход. Но диплом-то, небось, нужно сдавать в мае, правильно? Так что на свободный поиск времени нет и нужно идти от задачи.

Я спрашивал не про название диплома, а про тему. Если Вы пытаетесь создать сверхнадёжное приложение -- нужно тестировать надёжность, если сверхпроизводительное -- нужно тестировать производительность, если сверхбезопасное -- нужно тестировать безопасность, если сверхудобное -- нужно тестировать юзабилити, и т.д.

Что в Вашем понимании значит "оптимальным образом"? Какой параметр (или параметры) оптимизируем? От этого зависит всё остальное.

[SALar]

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

Очень тежело найти черную кошку в темной комнате, если ее там нет.

Предположение. Программа написанная вами ненаучна.
Доказательство.
1. Будем считать ненаучным написание программы в условиях хаоса или, другими словами, будем считать ненаучным написание программы, если процесс разработки не соответствует не одной из принятых методологий
2. Процесс тестирования не следовал ни одной из известных методологий (вы не пишете по какой методологии вели разработку).
Другой вариант доказательства.
2. Процедуры направленные на контроль и улучшение качества являются неотемлемой частью многих методологий разработки.
* XP предполагает: написание модульных тестов до написания кода; формальные просмотры кода (code review); постоянное бета тестирование конечным пользователем в процессе разработки.
* RUP и MSF предпалагают наличие выделенных людей в команде разработки, занимающихся верификацией и валидацией в процессе создания ПО.
Вывод Программа написанная вами ненаучна.

Извините.
Уже само то, что тестирование будет проводиться постфактум, говорит о некачественном процессе разработки.

Помогите пожалуйста с выбором программного обеспечения для тестирования и помогите с вопросом "что вообще и как тестировать".

Определителсь, что вам нужно:
* "Потестить программу"? - Боюсь, что это вам не надо.
* Показать, что процесс разработки был качественный? - Увы , поздно.
* Показать, что программа хорошая? - Лучше всего получить отзывы от конечного пользователя. Удачное внедрение было бы идеальным вариантом
* Хоть что то написать в дипломе о средствам автоматизированного тестирования.? - Ну тут материал обширен.

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

Не советую вообще трогать тулы "автоматизированного тестирования." Если вы не знаете тестирования, то вам понадобится с полгода, чтобы просто понять зачем они нужны и почему в вашем случае их применения совершенно неоправдано.

[barancev]

Сергей, ну зачем уж так-то? Люди после этого инструментов пугаться будут :)

Скажем, JUnit -- тоже инструмент автоматизированного тестирования, а для освоения достаточно недели-двух.

Проблема не в том, что инструменты сложны, а в том, что задачи автоматизированного тестирования весьма многочисленны и разнообразны. И для того, чтобы научиться их все (ну или хотя бы значительную часть) решать, действительно времени нужно немало. Но инструменты в этом не виноваты :) А учиться можно и нужно постепенно.

[Kaluga]

Jack,
я думаю тебе не стоит забивать себе голову изучением тулов автоматизации и тем более всего тестирования.
Лучше всего ограничится объемом информации, достаточным для написания диплома.
Например.
Нужны графики показывающие, что система стабильно работает при определнных нагрузках. Берешь ЛЮБОЙ тул, позволяющий сделать график, читаешь в мануале как это сделать, и делаешь график. Выводы из графика, почему был выбран именно этот тул и тому подобную галиматью ты, как студент-старшекурсник, уже просто обязан уметь писать. :) В крайнем случае, вообще рисуешь график сам. :)
Да. еще неплохо узнать у шефа, откуда у него такие странные пожелания. Может он хочет тебя или твой автотест потом как использовать. Тогда никуда не деться - придется учить.
А так... Забивать себе перед дипломом голову ненужной ерундой - зачем?

[SALar]

Скажем, JUnit -- тоже инструмент автоматизированного тестирования, а для освоения достаточно недели-двух.

Для освоения достаточно. Но для того, чтобы понять, выгодно или невыгодно их использовать нужно времени побольше.
2Kaluga. Аплодирую стоя. Точь в точь мои мысли. Нужно график - нарисуй график. Нужно сказать, что приложение качественное - скажи, что оно качественное. А учиться "автоматизации отдельных аспектов тестирования" за месяц до диплома? Зачем?

[Jack]

Прежде всего хочу сказать всем огромное спасибо. Не думал что меня удостоят ответом, причем в такие короткие сроки :)
Спасибо.
Теперь по порядку.
Диплом пишется в одной конторе, которая выступает в качестве заказчика, но защищается на кафедре.
Заказчику пофигу на мою защиту - ему важна система и ее работоспособность. Кафедре пофиг на контору - ей важно чтобы мой диплом содержал некоторую научность, математику, математическое моделирование, решал оптимизационные задачи и т.п. Сами понимаете тот факт что я просто написал информационную систему, которая удовлетворяет заказчика для основной темы диплома не катит. Получается у меня два научрука: из конторы - ему надо система и пофик на диплом как таковой и с кафедры - которому пофик на программы а важна научность и математика. Ввиду того, что их требования противоречивы,а защищаюсь я на кафедре - то приходится ВЫДУМЫВАТЬ научность и высасывать ее из пальца. Заказчик системой впринципе доволен. Так что решаю проблему с кафедрой. Научрук от кафедры предложил покопать тестирование - чем я и успешно занялся :)

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

Задача получилась чисто программисткая, с разработкой базы данных, ER диаграммы и т.п. Вот научрук с кафедры и предложил потестировать созданное веб-приложение автоматическими тестами. Ввиду того что в этой области ни я, ни (как оказалось) он не спецы - то я к в ас и обратился :) Еще раз спасибо что прояснили ситуацию.

Теперь о моем представлении тестирования моей системы.
Основная задача тестирования - удобство пользовательского интерфейса и функциональности. Дополнительные - все остальные.
Подобные системы уже писались, но основной их недостаток - они по сути создавали средство для ввода SQL. Т.е. вместо написания insert into пользователь должен был нажать кнопку "добавить строку" и заполнить необходимые поля. Принципиально эти разработки ничем не лучше (а даже хуже) стандартных SQL-навигаторов (PL/SQL-Developer например).

Вопросы безопасности и защиты от взлома веб-приложения не рассматриваются. Т.е. считает что пользователь не хочет сломать или испортить работу системы. Поэтому защита может быть только "от дурака".

Case, попробую скачать openSTA и сделать то, что Вы рекомендовали. Одна важнейшая и основная транзация в системе есть и как оказалось припараллельном ее вызове система не работает :) Но это я уже обнаружил и исправил вручную.
тул, которому можно доверять... Ммм... Не знаю, это я так выразился. Имел в виду тул, который написан не мной и не конторой, а сторонними разработчиками, т.е. независимо и непредвзято оценивающий работоспособность моей системы.

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

SALar, если Вы не против, то я буду Вас цитировать при разговоре с научруком от кафедры :) Почитав за это время кучу дитературы по тестированию - пришел к выводу, что тестирование - отдельная тема для диплома :) Однако диплом надо сдавать именно мой и именно в мае :)

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

Спасибо всем за отклик и советы. Они действительно для меня оказались бесценны...

Ну и если не затруднит проясните пожалуйста вопрос о тестировании пользовательского интерфейса и так сказать его удобстве для пользователя...
А может кто предложит какую научность сюда можно приписать... :)

Еще раз всем спасибо огромное.

P.S. За это время понял, что в список интересующих меня тем добавлен новый элемент - тестирование :)

[Scorp-13]

Ну и если не затруднит проясните пожалуйста вопрос о тестировании пользовательского интерфейса и так сказать его удобстве для пользователя...
А может кто предложит какую научность сюда можно приписать... :)

http://www.usethics.ru/
http://software-test...nctional_ui.htm

[SALar]

Развернутый вопрос - правильный вопрос.

SALar, если Вы не против, то я буду Вас цитировать при разговоре с научруком от кафедры :) 

Ну что вы. Это ведь реклама. Добавьте еще, что согласно MSF роли тестера и программиста совмещать нельзя. Это обязательно два разных человека.

Ну и если не затруднит проясните пожалуйста вопрос о тестировании пользовательского интерфейса и так сказать его удобстве для пользователя...
А может кто предложит какую научность сюда можно приписать... :)

Легко. Очень неплохо и "научно" будет смотреться расчет времени выполнения бизнес операций по методу GOMS. Прочитать можно в книге "Дизайн пользовательского интерфейса" Влад. В. Головач (http://www.uibook1.ru/), стр 120.

Пример мой, при цитировании ссылка обязательна.
Обработка попытки удаления объекта, на который есть ссылки.
С точки зрения программиста все просто. Навешиваем констрейны на базу данных. При попытке удаления перехватываем эксепшен и делаем ролбек транзакции.
А пользователь вместо элементарной последовательности:
Вызов меню / попытка нажатия на кнопку удаления. Все приехали, вижу что невозможно.
вынужден идти по длинному пути:
Вызов меню -> отдание команды на удаление -> подтверждение команды.
Расчет времени по GOMS дает 2.4 - 3.6 секунды в первом случае и 8.4 во втором. В случае же Web приложения во втором варианте добавляются еще две задержки приложения 2-6 секунд. А это уже очень серьезно. Одно дело за 2.5 секунды понять, что удаление невозможно и совсем другое в течение 10 - 15 секунд заниматься нудной работой, забыть, что же делать дальше и выяснить, что все это напрасно.
Выдача пользователю информации о блокирующих объектах легко решается. Раз приложение знает, почему нельзя удалять, то этот список уже есть. Значит можно показывать его во всплывающей подсказке.
Пожалуй, можно найти довод в пользу плохого интерфейса - это разгрузка сервера. Необходимость считать возможность удаления для всех элементов, даже если пользователь ничего удалять не собирается накладно. Но это обходится введением дополнительного свойства объекта «Есть ли ссылки?». Пропадает информативность? Хорошо, добавим команду «показать список блокирующих элементов»
Итак, все сводится к некоему усложнению кодирования. Что перевесит: удобство программирования или удобство использования? Пока в подавляющем большинстве случаев программисты одерживают верх над конечными пользователями.
И это еще одна истина из длинного списка неприятных, поскольку «утаить их - нечестно, сказать же правду - значить, вызвать огонь на себя».


А вот о том, что существуют средства для тестирования GUI я не слышал. Нет, есть конечно средста позволяющие сравнить скриншот с эталоном, но это "две большие разницы".

Также наверное интересно ответить на вопросы:
1) какое максимальное количество человек может пользоваться системой одновременно?
2) Производительность,
3) среднее время работы системы,
4) время загрузки страниц,
5) выполнения операций.
ну и пр.

Слава (CASE) дал очень правильную ссылку. Можно еще взять триал какого нибудь платного софта. Astra Load Stress Tool - легок в изучении, дает хорошие графики. Load Runner - монстр, может все, только бублики не печет, но как все это охватить?
От себя добавлю, что на 3-5 вопросы вы ответите легко. А вот первый вопрос сложнее. Научиться правильно писать пользовательские сценарии сложнее, чем изучить тул для нагрузочного тестирования.

[van]

Интересное решение проблемы притягивание математики к программированию :) Я имею в виду через тестирование ПО :)

Когда я писал диплом, у нас в группе каждый второй сталкивался с подобной проблемой (я столкнулся с обратной проблемой - как к математике и статистике, которыми просто захлебывался мой диплом, притянуть Информационное Технологии). Все решали ее по - разному, но через тестирование никто не решал. Ни у кого даже мыслей подобных не возникало :)

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

[Dmitry_NJ]

Можно еще взять триал какого нибудь платного софта. Astra Load Stress Tool - легок в изучении, дает хорошие графики. Load Runner - монстр, может все, только бублики не печет, но как все это охватить?
От себя добавлю, что на 3-5 вопросы вы ответите легко. А вот первый вопрос сложнее. Научиться правильно писать пользовательские сценарии сложнее, чем изучить тул для нагрузочного тестирования.

Проблема в том, что Astra LoadTest нельзя скачать самому. LoadRunner можно, но он гораздо сложнее и потребует времени на изучение, коего, наверняка, не будет перед защитой диплома. Кроме того, на вопрос #1 trial версия ответить не поможет (ну если, конечно, автор топика написал что-то приличное, что не упадет от нагрузки в 10 пользователей).

[Jack]

Как сложно с моими научруками... сами не знают чего хотят... Поэтому скорее всего я буду тестировать интерфейс пользователя. На это смелое решение повлияла книга "Дизайн Пользовательского Интерфейса". Прочитал и очень понравилось.

Как я понимаю средств автоматизированного тестирования пользовательского интерфейса не существует?

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

[Case]

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

[Jack]

Согласен, что формализация и создание автоматизированнного средства тестирования пользовательского интерфейса - совершенно другая задача. Однако в книге (http://www.uibook1.ru/) впринципе приведены основные критерии эффективности пользовательского интерфейса. Пусть даже не совсем математические, а больше психологические. Попробую позаниматься именно ими, максимально их формализуя :)

Я так понимаю, средств АВТОМАТИЗИРОВАННОГО тестирования пользовательских интерфейсов нет? Не надо полностью автоматический программ. Есть ли удобные инструменты для тестирования ПИ? Просто если таковые есть, то мне ОБЯЗАТЕЛЬНО надо с ними поработать... :( А потом скажу что я все инструменты для тестирования ПИ просмотрел :)

P.S. По поводу того что я понимаю под тестированием ПИ. Качество ПИ определяется некоторыми показателями, каждые из которых разбиваются на подпоказатели. Вплоть до того, что их можно замерить или оценить (экспертами или еще как-нибудь) Основной набор показателей эффективности я нашел в книге http://www.uibook1.ru/. Часть - в разных статьях. Среди методов измерения есть несколько цифровые GOMS. Плюс насколько я знаю этим на кафедре никто не занимался - что тоже плюс. Никто не шарит, да и тема актуальная для России, как я понимаю :)
вопщем вот :)

[Case]

Давайте чуток разберёмся в названиях?
Средства автоматизированного тестирования через интерфейс много, их называют record/playback - смотрите раздел Инструменты.

А вот для тестирования пользовательского интерфейса с точки зрения юзабилити и эргономики наверное и нет. Что-то встречал, но с трудом представляю что именно они могу проверять, кроме разве что расстояние между кнопками и порядка обхода по табу, к примеру.