Выбрать тему для диплома, связанную с QA/QC?
Изначально дипломный руководитель предложил тему, связанную с тестированием ПО. Предполагали с ним, что буду писать какой-то инструмент для тестирования. С тех пор я уже полгода проработал тестировщиком и понял, что никому это на. совсем не нужно, более того в сети лежат горы бесплатных утилит и frameworks для проведения различных видов тестирования, не говоря уже о платных развитых инструментах.
Не хотелось бы заниматься фигней, если честно. Не могли бы уважаемые коллеги помочь в генерации идей по поводу темы диплома (инженерного)? Что у нас сейчас "на острие"?
#2 Nadezhda- Город: Харьков
- ФИО: Алексей Баранцев
- Город: Россия, Москва
На острие всегда было, есть и будет решение задач. В тестировании масса технически сложных задач, именно инженерно-технических. И чаще всего не надо для их решения делать новые инструменты, можно предложить способ применить существующий инструмент так, как его еще никто не применял.
Лучше взять задачу из жизни, близкую той системе, с которой Вы работаете постоянно. Тогда решать её будет и интересно, и полезно. И не будет раздвоения личности. Например, я могу напридумывать кучу задач, связанных с тестированием втроенных систем, или с тестированием реализаций протоколов, или с тестированием компиляторов -- но они будут Вам чужие. Задачу нужно придумать самому, выстрадать её, тогда и решение её принесёт удовлетворение. Если диплом не для галочки, конечно.
Скажите хотя бы, с какого рода системами Вам приходится работать постоянно? Тогда можно будет методом последовательных приближений сформулировать задачу.
#4 sanches- Город: Волгоград
Скажите хотя бы, с какого рода системами Вам приходится работать постоянно? Тогда можно будет методом последовательных приближений сформулировать задачу.
#5 barancev- ФИО: Алексей Баранцев
- Город: Россия, Москва
Скажите хотя бы, с какого рода системами Вам приходится работать постоянно? Тогда можно будет методом последовательных приближений сформулировать задачу.
При таком подходе Вам никогда не удастся найти точку приложения. Думайте о том, ЧТО вы делаете, а не о том, КАК. Какая разница, на каком языке написано приложение? Важен тип приложения. На .Net можно написать почти все что угодно, и методы тестирования будут весьма сильно отличаться.
#6 sanches- Город: Волгоград
Думайте о том, ЧТО вы делаете, а не о том, КАК.
#7 barancev- ФИО: Алексей Баранцев
- Город: Россия, Москва
Задача стоит в тестировании распределенного приложения с множеством точек внедрения (порядка десятков тысяч), но проект находится в той стадии, когда полностью механизм взаимодействия частей приложения и централизации учета не разработан, поэтому тестируется пока stand alone приложение. Вот смысл, вкратце. Но меня все равно не покидает ощущение, что я не понял мысли и не ответил на Ваш вопрос.
Уже вполне достаточно ответили. Ну вот, навскидку:
"Способы переиспользования функциональных тестов для частей разпределенного приложения при тестировании приложения в целом""Нагрузочное тестирование распределенного приложения, состоящего из большого количества компонентов""Тестирование распределенного приложения с сильно разделенными частями" (особенности -- наличие файрволов и прочей подобной нечисти)"Тестирование механизма передачи данных между частями распределенного приложения" (наверняка у Вас найдутся специфические особенности, в этом месте почти всегда бывают особенности)"Тестирование безопасности и надежности протокола передачи данных между частями распределенного приложения" (тоже почти наверняка будут особенности)
Если знать более детально предметную область (что это за распределенное приложение -- банкоматы по всей стране, дилерская сеть, медицинская база знаний, система обработки метеорологических или сейсмических данных и т.п.) можно вытащить ещё кучу задач, более привязанных к специфике области.
#8 sanches- Город: Волгоград
[Уже вполне достаточно ответили. Ну вот, навскидку:
"Способы переиспользования функциональных тестов для частей разпределенного приложения при тестировании приложения в целом"
Слишком узкая тема, тем более что в нашем универе вообще нет ни предмета, касающегося качества ПО, ни специалистов в этом вопросе. Представляю какими глазами на меня будут смотреть, приди я с таким дипломом. Да и на инженерный диплом это не тянет никак.
"Нагрузочное тестирование распределенного приложения, состоящего из большого количества компонентов"
Не понимаю, чем отличается от нераспределенного приложения? Моделируем нагрузку частей, составляем для каждой сценарии, жмем батон "start test" и вперед. Грубо говоря. Приложение состоит из большого числа компонентов? Пожалуйста - пишем большое количество test cases. + интеграционное тестирование.
"Тестирование распределенного приложения с сильно разделенными частями" (особенности -- наличие файрволов и прочей подобной нечисти)
При тестировании создаем среду, заявленную в спецификациях продукта. Если не работает при коммерческой эксплуатации - пинаем админа чтобы открывал порты или еще чего. При этом потрясаем отчетом по тестированию.
"Тестирование механизма передачи данных между частями распределенного приложения" (наверняка у Вас найдутся специфические особенности, в этом месте почти всегда бывают особенности)
Специфика действительно есть, но в рамках системы она вся укладывается в специально придуманный для этого регламент документооборота. Тестирование его - дело техники. А тестировать механизмы придуманные сторонними разработчиками, типа как SOAP/SMTP/. вернее их реализации, конечно можно, но тут можно обойтись unit-тестированием и нагрузочным. Что я могу сказать в своем дипломе по этому поводу.
"Тестирование безопасности и надежности протокола передачи данных между частями распределенного приложения" (тоже почти наверняка будут особенности)
Вот это уже интереснее! Но я не специалист по тестированию безопасности и надежности. Необходимо будет почитать дополнительно литературу.
Если знать более детально предметную область (что это за распределенное приложение -- банкоматы по всей стране, дилерская сеть, медицинская база знаний, система обработки метеорологических или сейсмических данных и т.п.) можно вытащить ещё кучу задач, более привязанных к специфике области.
Приложение представляет собой большую БД о людях (Big Brother watching you. шутка) и содержащая некоторую другую информацию специфичную предметной области. Точки внедрения - клиентские приложения, взаимодействующие с центральной БД посредством регламента. А приложения автоматизируют внутренние бизнес-процессы организации. Бумажки туда-сюда и все такое.
Большое спасибо, Алексей, за поддержку обсуждения и предложенное. Буду рад еще ознакомиться с предложениями тем, если таковые возникнут.
To ALL (и в частности, Nadezhda): устроим мозговой штурм?
#9 barancev- ФИО: Алексей Баранцев
- Город: Россия, Москва
"Нагрузочное тестирование распределенного приложения, состоящего из большого количества компонентов"
Проблема в том, что воздействия на систему придется оказывать в многих разных местах. Во-первых, нужно их по этим местам как-то разнести, во-вторых -- как-то синхронизировать. Не создавать же просто тупую нагрузку, белый шум, надо же моделировать некоторые реальные ситуации, варианты использования системы. Типично инженерная задача.
"Тестирование распределенного приложения с сильно разделенными частями" (особенности -- наличие файрволов и прочей подобной нечисти)
То же самое -- как за эти файрволы запихать данные для воздействий, как воздействия синхронизировать, как собирать результаты измерений.
Специфика действительно есть, но в рамках системы она вся укладывается в специально придуманный для этого регламент документооборота. Тестирование его - дело техники. А тестировать механизмы придуманные сторонними разработчиками, типа как SOAP/SMTP/. вернее их реализации, конечно можно, но тут можно обойтись unit-тестированием и нагрузочным. Что я могу сказать в своем дипломе по этому поводу.
Ну, например -- тестирование соответствия реального поведения регламенту документоборота. Это же типа какое-то workflow? Вот и надо проверять, например, что система на разрешает недопустимых операций с документами (то есть тех, которые не допустипы в соответствии с регламентом) и разрешает допустимые. Даже привести систему в некоторые состояния workflow часто непростая задача, а если учесть, что от пути прохождения workflow может зависеть поведение, задача ещё усложняется. Готовых решений задачи тестирования на соответствие workflow нет, это совершенно точно. Есть для частных случаев. Сделайте ещё для одного частного случая.
А вообще-то я ушёл в отпуск. Это был мой последний пост. Перерыв на неделю-две :)
#10 Dmitry_NJ- ФИО: Дмитрий Шевченко
- Город: New Jersey, USA
4 sanches: так как дипломная работа должна содержать кроме практического применения еще и научно-исследовательскую часть я-бы предложил рассмотреть сначала более фундаментальные вещи, т.е. математические методы касаемые тестирования: комбинаторика, графы и т.д. Например, изложить модели: потока транзакций, меню с конечным числом состояний, потока данных, времени выполнения и другие. И на базе данной/ых модели/ей продемонстрировать эффективность их применения и оптимизации тестирования Вашего приложения.
В качестве оправной литературы рекомендую книгу Бориса Бейзера "Тестирования черного ящика".
#12 Case- ФИО: Панкратов Вячеслав
- Город: Украина, Киев.
В качестве оправной литературы рекомендую книгу Бориса Бейзера "Тестирования черного ящика".
#13 Chaos- ФИО: Родичев Артем
- Город: Москва
- ФИО: Sonya
В качестве оправной литературы рекомендую книгу Бориса Бейзера "Тестирования черного ящика".
ну спасибо - вы меня успокоили. Я то думала у меня просто серого вещества не хватает, поэтому так дико тянет в сон при прочтении сего труда
#15 sanches- Город: Волгоград
Чтож, пока вариант с автоматизацией тестирования нашего приложения пока мне нравится больше всех, осталось согласовать это с дип. руководителем и на работе.
А книжка Бейзера есть, процесс тестирования действительно там очень формализован, для диплома очень даже подойдет. :)
Всем большое спасибо!
#16 Сэм- ФИО: Сергей Минаев
- Город: Москва
Вообще, тестировщикам, а еще проще - QA, подобрать тему для защиты, чем программисту какой-нибудь стандартной системы, на JAVA, например. Поле для деятельности - колоссальное! Я в феврале защитился на тему "Моделирование и мониторинг корпоративной распределенной информационной системы". Задача была изначально вполне прикладная - автоматизировать процесс принятия решения о том, что производительность системы упала. Делать это - на основании собираемых данных о response time на клиенте в различных точках системы. Когда я пришел в ВУЗ с этой "задачкой", мне покрутили у виска и сказали, что это как минимум кандидатская, и то, если кучу всего упростить. В итоге, привели это к решению поставленной задачи не на реальной системе, а на модели, созданной в GNU Network Simulator. А к реальной системе применима в этом случае только экспертная система с "самообучением", когда оператор в течение N-го времени сообщает, нормальное ли поведение у системы при данных условиях (числе пользователей, их активности. ). Ну, это я так, просто поделился воспоминаниями, что бы представляли дипломники, что можно накрутить в нашей сфере. А вообще, главное заранее понять, решаема ли задача и подходит ли она под специфику ВУЗа и факультета/кафедры. Потому как в одних требуют чтоб все работало и было применимо, им на теорию и математику начхать. А в других - главное подогнать под это дело какую-нибудь теорию, красивое уравнение или что еще, а то, что там реально - одни скриншотики и до реализации красиво поставленной задачи еще 10 человеколет, это пустяки! Так что прежде чем взяться за дело - аккуратно все продумайте и обговорите с руководителями/консультантами.
ЗЫ: а вообще, главное в дипломе - КАК его приподнесешь. Я видел, как валили ТАКИЕ работы, где человек 1.5 года копал носом, но не смог вразумительно объяснить. А зато на красивые картинки, уверенный тон и солидность комиссия клюет безошибочно.