Еще раз о тестировании для ВЕБ
#1
Отправлено 18 апреля 2005 - 13:39
Возникла такая проблемка... Пишу диплом, в котором создаю некоторое веб-приложение под Оракл. Научный руководитель программой вполне доволен, однако научности в работе никакой, а очень надо... Поступило предложение применить некоторые средства тестирования пользовательского интерфейса (да и всего остальнго) дабы показать что приложение написано качествено и "оптимальным" образом :)
Веб-сервер Apache2, СУБД Oracle9, PHP, python...
Помогите пожалуйста с выбором программного обеспечения для тестирования и помогите с вопросом "что вообще и как тестировать". Сроки поджимают, а я только приблизительно представляю себе сам процесс тестирования... Конечно особое внимание хотелось бы уделить средствам автоматизированного тестирования.
Полазил по сайту, форуму... Очень много различных программных продуктов... Даже и не знаю что выбрать и где бесплатно скачать...
#2
Отправлено 18 апреля 2005 - 14:13
(Неужели тот факт, что программа не только написана, но и протестирована добавит "научности"? Весьма странно...)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#3
Отправлено 18 апреля 2005 - 15:11
а по поводу того что тестирование - малонаучно... Честно говоря я сам не понял этот факт... но руководитель сказал что можно попробовать - я и пробую...
я так понял им важно факт того, что программа не просто написана, а написана как то качественно :) по методике какой-нить :)
одним словом, я щас экстренно изучаю применимость автоматизированного тестирования к диплому...
ну и очень нада помощь по выбору программного обеспечения для этого процесса... а то их что-то уж очень много...
#4
Отправлено 18 апреля 2005 - 16:13
Спросите руководителя что конкретно он хочет видеть. Цитфры, графики (что от чего), что именно?
Редактор портала www.it4business.ru
#5
Отправлено 18 апреля 2005 - 17:44
Грубо говоря, результат работы какой нибудь автоматизированной тестирующей проги, которой можно доверять (в том смысле что ее можно найти в продаже или скачать нахаляву и результаты ее работы можно обосновать умными словами) То есть сказать что тестировалось, каким образом чему это эквивалентно (в случае стресс-тестов) ну и прочее...
#6
Отправлено 19 апреля 2005 - 06:49
Про тул которому можно доверять я не понял - а как вы это оцениваете?
Редактор портала www.it4business.ru
#7
Отправлено 19 апреля 2005 - 07:09
Я спрашивал не про название диплома, а про тему. Если Вы пытаетесь создать сверхнадёжное приложение -- нужно тестировать надёжность, если сверхпроизводительное -- нужно тестировать производительность, если сверхбезопасное -- нужно тестировать безопасность, если сверхудобное -- нужно тестировать юзабилити, и т.д.
Что в Вашем понимании значит "оптимальным образом"? Какой параметр (или параметры) оптимизируем? От этого зависит всё остальное.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#8
Отправлено 19 апреля 2005 - 07:35
Очень тежело найти черную кошку в темной комнате, если ее там нет.Пишу диплом, в котором создаю некоторое веб-приложение под Оракл. Научный руководитель программой вполне доволен, однако научности в работе никакой, а очень надо... Поступило предложение применить некоторые средства тестирования пользовательского интерфейса (да и всего остальнго) дабы показать что приложение написано качествено и "оптимальным" образом :)
Предположение. Программа написанная вами ненаучна.
Доказательство.
1. Будем считать ненаучным написание программы в условиях хаоса или, другими словами, будем считать ненаучным написание программы, если процесс разработки не соответствует не одной из принятых методологий
2. Процесс тестирования не следовал ни одной из известных методологий (вы не пишете по какой методологии вели разработку).
Другой вариант доказательства.
2. Процедуры направленные на контроль и улучшение качества являются неотемлемой частью многих методологий разработки.
* XP предполагает: написание модульных тестов до написания кода; формальные просмотры кода (code review); постоянное бета тестирование конечным пользователем в процессе разработки.
* RUP и MSF предпалагают наличие выделенных людей в команде разработки, занимающихся верификацией и валидацией в процессе создания ПО.
Вывод Программа написанная вами ненаучна.
Извините.
Уже само то, что тестирование будет проводиться постфактум, говорит о некачественном процессе разработки.
Определителсь, что вам нужно:Помогите пожалуйста с выбором программного обеспечения для тестирования и помогите с вопросом "что вообще и как тестировать".
* "Потестить программу"? - Боюсь, что это вам не надо.
* Показать, что процесс разработки был качественный? - Увы , поздно.
* Показать, что программа хорошая? - Лучше всего получить отзывы от конечного пользователя. Удачное внедрение было бы идеальным вариантом
* Хоть что то написать в дипломе о средствам автоматизированного тестирования.? - Ну тут материал обширен.
Не советую вообще трогать тулы "автоматизированного тестирования." Если вы не знаете тестирования, то вам понадобится с полгода, чтобы просто понять зачем они нужны и почему в вашем случае их применения совершенно неоправдано.Сроки поджимают, а я только приблизительно представляю себе сам процесс тестирования... Конечно особое внимание хотелось бы уделить средствам автоматизированного тестирования.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#9
Отправлено 19 апреля 2005 - 07:47
Скажем, JUnit -- тоже инструмент автоматизированного тестирования, а для освоения достаточно недели-двух.
Проблема не в том, что инструменты сложны, а в том, что задачи автоматизированного тестирования весьма многочисленны и разнообразны. И для того, чтобы научиться их все (ну или хотя бы значительную часть) решать, действительно времени нужно немало. Но инструменты в этом не виноваты :) А учиться можно и нужно постепенно.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#10
Отправлено 19 апреля 2005 - 09:20
я думаю тебе не стоит забивать себе голову изучением тулов автоматизации и тем более всего тестирования.
Лучше всего ограничится объемом информации, достаточным для написания диплома.
Например.
Нужны графики показывающие, что система стабильно работает при определнных нагрузках. Берешь ЛЮБОЙ тул, позволяющий сделать график, читаешь в мануале как это сделать, и делаешь график. Выводы из графика, почему был выбран именно этот тул и тому подобную галиматью ты, как студент-старшекурсник, уже просто обязан уметь писать. :) В крайнем случае, вообще рисуешь график сам. :)
Да. еще неплохо узнать у шефа, откуда у него такие странные пожелания. Может он хочет тебя или твой автотест потом как использовать. Тогда никуда не деться - придется учить.
А так... Забивать себе перед дипломом голову ненужной ерундой - зачем?
#11
Отправлено 19 апреля 2005 - 13:19
Для освоения достаточно. Но для того, чтобы понять, выгодно или невыгодно их использовать нужно времени побольше.Скажем, JUnit -- тоже инструмент автоматизированного тестирования, а для освоения достаточно недели-двух.
2Kaluga. Аплодирую стоя. Точь в точь мои мысли. Нужно график - нарисуй график. Нужно сказать, что приложение качественное - скажи, что оно качественное. А учиться "автоматизации отдельных аспектов тестирования" за месяц до диплома? Зачем?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#12
Отправлено 19 апреля 2005 - 17:31
Спасибо.
Теперь по порядку.
Диплом пишется в одной конторе, которая выступает в качестве заказчика, но защищается на кафедре.
Заказчику пофигу на мою защиту - ему важна система и ее работоспособность. Кафедре пофиг на контору - ей важно чтобы мой диплом содержал некоторую научность, математику, математическое моделирование, решал оптимизационные задачи и т.п. Сами понимаете тот факт что я просто написал информационную систему, которая удовлетворяет заказчика для основной темы диплома не катит. Получается у меня два научрука: из конторы - ему надо система и пофик на диплом как таковой и с кафедры - которому пофик на программы а важна научность и математика. Ввиду того, что их требования противоречивы,а защищаюсь я на кафедре - то приходится ВЫДУМЫВАТЬ научность и высасывать ее из пальца. Заказчик системой впринципе доволен. Так что решаю проблему с кафедрой. Научрук от кафедры предложил покопать тестирование - чем я и успешно занялся :)
Теперь о сути системы. В конторе есть информационная система на базе оракла, для которой я пишу некоторое веб-приложение. Основная задача этого веб-приложение - управление данными существующей информационной системы. Не буду вдаваться в подробности. Однако работа с веб-приложением будет сводиться к выполнению различных операций по извлечению, вставке, обновлению различных таблиц в БД. Написана она с учетом пожеланий заказчика. То есть в собственную базу системы вносятся скрипты и SQL запросы (типа создавая некоторую операцию), а пользователю нужно лишь выбрать нужную операцию и ввести необходимые параметры. Например, операция выборки из базы некоторых значений, где в качестве параметра указывается какой-нить ID. Пользователь выбирает нужную операцию, вводит ID и веб-приложение возвращает ему результат этого SQL запроса.
Задача получилась чисто программисткая, с разработкой базы данных, ER диаграммы и т.п. Вот научрук с кафедры и предложил потестировать созданное веб-приложение автоматическими тестами. Ввиду того что в этой области ни я, ни (как оказалось) он не спецы - то я к в ас и обратился :) Еще раз спасибо что прояснили ситуацию.
Теперь о моем представлении тестирования моей системы.
Основная задача тестирования - удобство пользовательского интерфейса и функциональности. Дополнительные - все остальные.
Подобные системы уже писались, но основной их недостаток - они по сути создавали средство для ввода SQL. Т.е. вместо написания insert into пользователь должен был нажать кнопку "добавить строку" и заполнить необходимые поля. Принципиально эти разработки ничем не лучше (а даже хуже) стандартных SQL-навигаторов (PL/SQL-Developer например).
Вопросы безопасности и защиты от взлома веб-приложения не рассматриваются. Т.е. считает что пользователь не хочет сломать или испортить работу системы. Поэтому защита может быть только "от дурака".
Case, попробую скачать openSTA и сделать то, что Вы рекомендовали. Одна важнейшая и основная транзация в системе есть и как оказалось припараллельном ее вызове система не работает :) Но это я уже обнаружил и исправил вручную.
тул, которому можно доверять... Ммм... Не знаю, это я так выразился. Имел в виду тул, который написан не мной и не конторой, а сторонними разработчиками, т.е. независимо и непредвзято оценивающий работоспособность моей системы.
barancev, основные параметры для оптимизации - удобство и интуитивная понятность интерфейса, а также функциональность. Т.е. система должна решать те задачи, которые на нее возложены. Задачи не описаны при ее создании, ввиду того что система - просто хранилище операций. Каждая операция должна выполнять корректно то действие для которого она написана. Задача системы - обеспечить эту функциональность.
Также наверное интересно ответить на вопросы:
какое максимальное количество человек может пользоваться системой одновременно?
Производительность, среднее время работы системы, время загрузки страниц, выполнения операций.
ну и пр.
SALar, если Вы не против, то я буду Вас цитировать при разговоре с научруком от кафедры :) Почитав за это время кучу дитературы по тестированию - пришел к выводу, что тестирование - отдельная тема для диплома :) Однако диплом надо сдавать именно мой и именно в мае :)
Kaluga, завтра еду разговаривать с научруком от кафедры. Попытаюсь ему объяснить про нереальность тестирования моей проги в качестве научной части работы...
Спасибо всем за отклик и советы. Они действительно для меня оказались бесценны...
Ну и если не затруднит проясните пожалуйста вопрос о тестировании пользовательского интерфейса и так сказать его удобстве для пользователя...
А может кто предложит какую научность сюда можно приписать... :)
Еще раз всем спасибо огромное.
P.S. За это время понял, что в список интересующих меня тем добавлен новый элемент - тестирование :)
#13
Отправлено 20 апреля 2005 - 07:26
http://www.usethics.ru/Ну и если не затруднит проясните пожалуйста вопрос о тестировании пользовательского интерфейса и так сказать его удобстве для пользователя...
А может кто предложит какую научность сюда можно приписать... :)
http://software-test...nctional_ui.htm
#14
Отправлено 20 апреля 2005 - 07:35
Ну что вы. Это ведь реклама. Добавьте еще, что согласно MSF роли тестера и программиста совмещать нельзя. Это обязательно два разных человека.SALar, если Вы не против, то я буду Вас цитировать при разговоре с научруком от кафедры :)
Легко. Очень неплохо и "научно" будет смотреться расчет времени выполнения бизнес операций по методу GOMS. Прочитать можно в книге "Дизайн пользовательского интерфейса" Влад. В. Головач (http://www.uibook1.ru/), стр 120.Ну и если не затруднит проясните пожалуйста вопрос о тестировании пользовательского интерфейса и так сказать его удобстве для пользователя...
А может кто предложит какую научность сюда можно приписать... :)
Пример мой, при цитировании ссылка обязательна.
Обработка попытки удаления объекта, на который есть ссылки.
С точки зрения программиста все просто. Навешиваем констрейны на базу данных. При попытке удаления перехватываем эксепшен и делаем ролбек транзакции.
А пользователь вместо элементарной последовательности:
Вызов меню / попытка нажатия на кнопку удаления. Все приехали, вижу что невозможно.
вынужден идти по длинному пути:
Вызов меню -> отдание команды на удаление -> подтверждение команды.
Расчет времени по GOMS дает 2.4 - 3.6 секунды в первом случае и 8.4 во втором. В случае же Web приложения во втором варианте добавляются еще две задержки приложения 2-6 секунд. А это уже очень серьезно. Одно дело за 2.5 секунды понять, что удаление невозможно и совсем другое в течение 10 - 15 секунд заниматься нудной работой, забыть, что же делать дальше и выяснить, что все это напрасно.
Выдача пользователю информации о блокирующих объектах легко решается. Раз приложение знает, почему нельзя удалять, то этот список уже есть. Значит можно показывать его во всплывающей подсказке.
Пожалуй, можно найти довод в пользу плохого интерфейса - это разгрузка сервера. Необходимость считать возможность удаления для всех элементов, даже если пользователь ничего удалять не собирается накладно. Но это обходится введением дополнительного свойства объекта «Есть ли ссылки?». Пропадает информативность? Хорошо, добавим команду «показать список блокирующих элементов»
Итак, все сводится к некоему усложнению кодирования. Что перевесит: удобство программирования или удобство использования? Пока в подавляющем большинстве случаев программисты одерживают верх над конечными пользователями.
И это еще одна истина из длинного списка неприятных, поскольку «утаить их - нечестно, сказать же правду - значить, вызвать огонь на себя».
А вот о том, что существуют средства для тестирования GUI я не слышал. Нет, есть конечно средста позволяющие сравнить скриншот с эталоном, но это "две большие разницы".
Слава (CASE) дал очень правильную ссылку. Можно еще взять триал какого нибудь платного софта. Astra Load Stress Tool - легок в изучении, дает хорошие графики. Load Runner - монстр, может все, только бублики не печет, но как все это охватить?Также наверное интересно ответить на вопросы:
1) какое максимальное количество человек может пользоваться системой одновременно?
2) Производительность,
3) среднее время работы системы,
4) время загрузки страниц,
5) выполнения операций.
ну и пр.
От себя добавлю, что на 3-5 вопросы вы ответите легко. А вот первый вопрос сложнее. Научиться правильно писать пользовательские сценарии сложнее, чем изучить тул для нагрузочного тестирования.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#15
Отправлено 20 апреля 2005 - 07:57
Когда я писал диплом, у нас в группе каждый второй сталкивался с подобной проблемой (я столкнулся с обратной проблемой - как к математике и статистике, которыми просто захлебывался мой диплом, притянуть Информационное Технологии). Все решали ее по - разному, но через тестирование никто не решал. Ни у кого даже мыслей подобных не возникало :)
На мой взгляд решать проблему так, как обсуждается в данном топике, очень даже не тривиально и не очень корректно.
Решать данную проблему, на мой взгляд, необходимо исходя из целей и задач, которые планировалось решить при написании диплома.
#16
Отправлено 20 апреля 2005 - 16:27
Проблема в том, что Astra LoadTest нельзя скачать самому. LoadRunner можно, но он гораздо сложнее и потребует времени на изучение, коего, наверняка, не будет перед защитой диплома. Кроме того, на вопрос #1 trial версия ответить не поможет (ну если, конечно, автор топика написал что-то приличное, что не упадет от нагрузки в 10 пользователей).Можно еще взять триал какого нибудь платного софта. Astra Load Stress Tool - легок в изучении, дает хорошие графики. Load Runner - монстр, может все, только бублики не печет, но как все это охватить?
От себя добавлю, что на 3-5 вопросы вы ответите легко. А вот первый вопрос сложнее. Научиться правильно писать пользовательские сценарии сложнее, чем изучить тул для нагрузочного тестирования.
#17
Отправлено 28 апреля 2005 - 17:23
Как я понимаю средств автоматизированного тестирования пользовательского интерфейса не существует?
И вообще может кого-то был опыт тестирования именно интерфейса - подскажите основные ошибки новичков и прочие тонкости, на что обратить внимание...
Потому что я пока знаю только то, что прочитал и за плечами у меня ни одного протестированного интерфейса... :(
#18
Отправлено 28 апреля 2005 - 19:54
Редактор портала www.it4business.ru
#19
Отправлено 29 апреля 2005 - 04:36
Я так понимаю, средств АВТОМАТИЗИРОВАННОГО тестирования пользовательских интерфейсов нет? Не надо полностью автоматический программ. Есть ли удобные инструменты для тестирования ПИ? Просто если таковые есть, то мне ОБЯЗАТЕЛЬНО надо с ними поработать... :( А потом скажу что я все инструменты для тестирования ПИ просмотрел :)
P.S. По поводу того что я понимаю под тестированием ПИ. Качество ПИ определяется некоторыми показателями, каждые из которых разбиваются на подпоказатели. Вплоть до того, что их можно замерить или оценить (экспертами или еще как-нибудь) Основной набор показателей эффективности я нашел в книге http://www.uibook1.ru/. Часть - в разных статьях. Среди методов измерения есть несколько цифровые GOMS. Плюс насколько я знаю этим на кафедре никто не занимался - что тоже плюс. Никто не шарит, да и тема актуальная для России, как я понимаю :)
вопщем вот :)
#20
Отправлено 29 апреля 2005 - 08:10
Средства автоматизированного тестирования через интерфейс много, их называют record/playback - смотрите раздел Инструменты.
А вот для тестирования пользовательского интерфейса с точки зрения юзабилити и эргономики наверное и нет. Что-то встречал, но с трудом представляю что именно они могу проверять, кроме разве что расстояние между кнопками и порядка обхода по табу, к примеру.
Редактор портала www.it4business.ru
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных