একটি খুব বড় অ্যাপ্লিকেশন পরীক্ষার জন্য পদ্ধতি


10

আমার একটি পিএইচপি অ্যাপ রয়েছে যা খুব বড়। এটিতে সাধারণত 2-3 জন বিকাশকারী পুরো সময় কাজ করে এবং আমরা সেই স্থানে পৌঁছে যাচ্ছি যেখানে আমরা পরিবর্তন করছি এবং বাগ তৈরি করছি (কাশি বৈশিষ্ট্য!)! এই সফ্টওয়্যারটি বলতে প্রতিটি জটিল নয়, কেবল সেখানে প্রচুর চলছে (35% নিয়ামক, একই মডেলগুলি সম্পর্কে, ইত্যাদি)।

এমনকি এই দৃষ্টিভঙ্গির পরিবর্তনের জন্য (কোনও উপাদানকে একটি আইডি ট্যুইক করা) কিছু বিশেষ শর্তে (একটি পায়ে দাঁড়িয়ে থাকা অবস্থায় লগ আউট করা হয়েছে) নষ্ট হওয়া একটি এজাক্স কোয়েরি নষ্ট করার পক্ষেও সতর্কতা অবলম্বন করা।

ইউনিট টেস্ট হ'ল প্রথম জিনিস যা মনে রাখে তবে আমরা এটি অন্য অ্যাপ্লিকেশনটিতে চেষ্টা করেছি এবং এগুলি ভুলে যাওয়া / বা পরীক্ষাগুলি লেখার পরে আরও বেশি সময় ব্যয় করা এত সহজ। আমাদের একটি মঞ্চ পরিবেশ আছে যেখানে লাইভ পুশ করার আগে কোডটি চেক হয়ে যায়।

আমাদের কি পার্ট টাইম প্রশ্ন / একজন ব্যক্তির দরকার?

যে কোনও পরামর্শ / চিন্তা আছে।


"... তারপরে পরীক্ষা করা" মানে কি তার চেয়ে বেশি হওয়া উচিত ?
ajax333221

উত্তর:


25

হ্যাঁ, আপনার কিউ / এ স্টাফ দরকার। এর অনেকগুলি কারণের মধ্যে কয়েকটি রয়েছে

  • একটি উত্সর্গীকৃত পরীক্ষকটির জন্য অর্থ ব্যয় হয় তবে প্রায়শই বিকাশকারী থেকে কম অর্থ হয়, তাই আপনার সময় ব্যয় না করার সুবিধাটি অতিরিক্ত ব্যয়ের চেয়ে বেশি।
  • একটি উত্সর্গীকৃত পরীক্ষক কীভাবে জিনিসগুলি পরীক্ষা করতে জানেন, বিশেষত এমন জিনিস যা স্বয়ংক্রিয়ভাবে কীভাবে করা যায় তা স্পষ্ট নয়। ব্রাউজারের মাধ্যমে কোনও সিস্টেমের সাথে ইন্টারঅ্যাক্ট করার জন্য অটোমেটেড পরীক্ষা চালানো কিছুটা লোমযুক্ত তবে সু-প্রতিষ্ঠিত শৃঙ্খলা। যদি আপনি এমন কাউকে পেয়ে থাকেন যা ইতিমধ্যে এটি কীভাবে করতে হয় তা জানেন, আপনাকে ভাল সরঞ্জাম এবং সেট আপগুলি শিখতে আরও বেশি সময় ব্যয় করতে হবে না।
  • একজন পেশাদার পরীক্ষক জানেন কীভাবে আসলে ত্রুটিগুলি খুঁজে পাওয়া যায়। তারা অ্যাপ্লিকেশনটির একজন ব্যবহারকারী যেমন ভাববে তেমন ভাবতে পারে এবং তাই সিস্টেমের সেই সমস্ত রাজ্যগুলি ব্যবহার করে যা প্রকৃতপক্ষে উত্পাদনে আসবে, যার অর্থ যে যে বাগগুলি অত্যন্ত দৃশ্যমান হবে তা আগে খুঁজে পাওয়া যাবে , আপনাকে বিব্রত এবং অতি-জরুরি প্যাচগুলির জন্য ব্যয় সাশ্রয় করে।
  • এটি সাধারণকরণ করে একজন পরীক্ষক কোনও বিকাশকারীর মতো ভাবেন না । আপনি যদি এটি অভিজ্ঞতা না অর্জন করেন তবে এটি কতটা তফাত সৃষ্টি করে তা বোঝানো শক্ত। সচেতনভাবে বা না, একটি বিকাশকারী ত্রুটিগুলি খুঁজে পেতে চায় না । তারা জানে যে সিস্টেমটি কীভাবে কাজ করে এবং সাধারণত অযৌক্তিক (তাদের কাছে) ইনপুট বা ডেটা এড়ানোর ঝোঁক দেয় যা বাস্তব জীবনে সমস্যা সৃষ্টি করে। যদি কোনও কিছু অপ্রত্যাশিতভাবে কাজ করে তবে তারা কীভাবে এটি চারপাশে কাজ করতে হয় তা জানেন এবং এটিকে কোনও ত্রুটি হিসাবে দেখবেন না। তারা কখনও নাসিস্টেমের প্রতিক্রিয়াগুলির অর্থ কী তা বুঝতে অসুবিধা হয়, কারণ তারা এগুলি লিখেছিল, যদিও এটি প্রায় সমস্ত বাস্তব সিস্টেমে একটি বড় কারণ। সংক্ষেপে: প্রোগ্রামাররা সাধারণত যে সমস্যাগুলি ব্যবহার করেন তাদের সমস্যাগুলি খারাপ হতে থাকে, কারণ তারা উচ্চ প্রশিক্ষিত বিশেষজ্ঞ। একজন পরীক্ষকের সর্বাধিক প্রাসঙ্গিক পরীক্ষাগুলি সম্পাদন করতে অনেক সহজ সময় থাকে।

এটি বলেছিল, কোনও বিকাশকারী এবং ছাদের মাধ্যমে ড্রাইভিং সিস্টেমের গুণমানের জন্য একটি পরীক্ষকের মধ্যে উত্পাদনশীল সহযোগিতা হারাবে না। একজন বিকাশকারী প্রায়শই লক্ষণগুলি লক্ষ্য করেন যে পরীক্ষক হওয়ার আগে কিছু ভুল উপায়। একজন বিকাশকারী প্রায়শই একজন পরীক্ষককে পরামর্শ দিতে পারেন যে কীভাবে সমস্যাটিকে আরও দক্ষতার সাথে পুনরায় উত্পাদন করা যায় এবং কীভাবে একটি সঠিক সমস্যা প্রতিবেদন লিখতে হয়, অর্থাত্ সমস্যাটি সনাক্ত করার জন্য প্রয়োজনীয় বিবরণ অন্তর্ভুক্ত করুন। তবে এগুলির জন্য কমপক্ষে একটি পরীক্ষক প্রয়োজন যা আপনি একসাথে কাজ করতে পারেন।


3
+1 টি। সাধারণ ব্যবহারকারীরা যে সমস্যাগুলি
দেখছেন

3

আপনার সম্ভবত আরও বা আরও ভাল রিগ্রেশন টেস্টের প্রয়োজন (নির্দিষ্ট ইউনিট পরীক্ষা নয়)। আপনার নিজের বিশ্লেষণ করতে হবে এমন কোন ধরণের পরীক্ষাগুলি হওয়া উচিত তবে তাদের যে বাগগুলি আপনি বলছেন তা সনাক্ত করা উচিত। আমি আপনাকে একটি পরীক্ষা পরিকল্পনা তৈরি করা এবং সেই পরীক্ষাগুলিকে অগ্রাধিকার দেওয়ার পরামর্শ দিই - এবং আপনি যখন এটি করেন, প্রাথমিকভাবে পরীক্ষা অটোমেশন সম্পর্কে খুব বেশি চিন্তা করবেন না think

এরপরে, নিজেকে জিজ্ঞাসা করুন যে আপনি যুক্তিসঙ্গত প্রচেষ্টার সাথে কয়েকটি বা বেশিরভাগ পরীক্ষা স্বয়ংক্রিয় করতে পারেন। উত্তরটি যদি হ্যাঁ হয় তবে আপনার সেগুলি করা উচিত। যদি উত্তরটি "না" হয় এবং আপনি মনে করেন "খণ্ডকালীন প্রশ্নোত্তর / একজন ব্যক্তি" সস্তা, তবে আপনার যা প্রয়োজন তা অবলম্বন করা উচিত। বেশিরভাগ ক্ষেত্রে, উভয়ই রাখা ভাল ধারণা - ম্যানুয়াল টেস্টিং এবং নতুন পরীক্ষাগুলি উদ্ভাবনের জন্য একজন প্রশ্ন / একজন ব্যক্তি এবং অনেকগুলি স্বয়ংক্রিয় প্রতিরোধ পরীক্ষাও।


রিগ্রেশন পরীক্ষাগুলির উল্লেখ করার জন্য +1 এবং ইউনিট পরীক্ষাগুলি কেবল কার্যকর সমাধান নয় poin
জর্জিও

হাই, আপনি কি রিগ্রেশন পরীক্ষাগুলিতে আরও কিছু বিশদ বর্ণনা করতে পারেন। আমি বিশ্বাস করি এগুলি আবার পুরানো বাগগুলি পুনরায় ঘটতে বাধা দিতে পারে - তবে কী পদ্ধতিগুলি দিয়ে আপনি এটি সম্পন্ন করার প্রস্তাব দিচ্ছেন? ইউনিট পরীক্ষা? জিনিসগুলির একটি 'চেকলিস্ট'? ধন্যবাদ :)
উইজার্ড

@ উইজার্ড: শব্দটি রিগ্রেশন টেস্টগুলি ইতিমধ্যে বিদ্যমান, কার্যকরী কার্যকারিতা (আপনার অ্যাপ্লিকেশনটি পরিবর্তন করার সময় তা ভঙ্গ করা থেকে বিরত রাখতে) যে কোনও ধরণের পরীক্ষার জন্য কেবল সাধারণ শব্দ। এটিতে একটি চেক তালিকা থেকে পরীক্ষাগুলি, আপনার ফ্রন্টএন্ডের মাধ্যমে স্বয়ংক্রিয় পরীক্ষা (এটি সম্ভবত আপনার ব্রাউজারটি) এবং ইউনিট পরীক্ষাগুলিও কভার করে। আমার পরামর্শটি হ'ল প্রথমে আপনাকে কী পরীক্ষা করতে হবে সে সম্পর্কে চিন্তা করা উচিত , স্বাধীনভাবে আপনি কীভাবে এটি পরীক্ষা করতে যাচ্ছেন (যদি আপনি "আমরা ইউনিট পরীক্ষার চেষ্টা করেছি" বলে, উদাহরণস্বরূপ, আপনি ইতিমধ্যে "কী" এ আছেন, "কী" নয়) ।
ডক ব্রাউন

2

একটি পেশাদার QA ভাড়া

আপনি যদি কোনও বাণিজ্যিক প্রকল্প বিকাশ করছেন তবে এটি করা উচিত। শক্তিশালী পরীক্ষার কৌশল ছাড়াই পণ্য প্রস্তুত করা আপনার বাগ ফিক্স সহ আরও বেশি ব্যয় করতে পারে। এছাড়াও, নতুন গ্রাহক অর্জন বা তাদের ধরে রাখা আপনার অ্যাপ্লিকেশনটি কতটা ভাল পরীক্ষা করা হয়েছে তার উপরও নির্ভর করবে।

সাধারণত কোডিং ইউনিট টেস্টিং আপনার কোড বেসে প্রয়োগ করা উচিত, তবে ইন্টিগ্রেশন টেস্টিং এবং ম্যানুয়াল টেস্টিং বাতিল করা উচিত নয়।


1

ইউনিট পরীক্ষা করা সত্যিই ভাল ধারণা, বিশেষত যদি আপনার প্রকল্পটি বাড়ছে। যদি ইউনিট পরীক্ষা লেখার অভ্যাস হয়ে যায় তবে এটি আপনার কাজকে অনেক সহজ করবে। সেখানে একটিইউটিউবে ক্লিন কোড লেখার বিষয়ে ভিডিও রয়েছে, যা বজায় রাখা এবং পরীক্ষা করা সহজ।

কিউএ ইঞ্জিনিয়ারও খুব জরুরি। একটি ভাল কিউএ পরীক্ষক কেবল কার্যকারিতাতে বাগগুলি খুঁজে পাবেন না, তবে অ্যাপটি ব্যবহারকারী-বান্ধব কিনা তা পরীক্ষা করতে পারবেন (যা নিজের দ্বারা পরীক্ষা করা প্রায় অসম্ভব)। কিউএ দল কীভাবে আপনার সময় এবং অর্থ সাশ্রয় করবে এবং আরও ভাল সফ্টওয়্যার সরবরাহ করতে সহায়তা করবে সে সম্পর্কে এখানে একটি সুন্দর নিবন্ধটি বর্ণনা করা হচ্ছে।


1

15 টি নিয়ামক এবং মডেল খুব বড় নয়। লেখাকে পরীক্ষা করার অভ্যাস করতে কিছুটা সময় লাগে, একে অপরকে এর দিকে লাথি মারতে (প্রথমে বন্ধুত্বপূর্ণ উপায়ে) অনেক সহায়তা করে।

এমন কিছু সরঞ্জাম রয়েছে যা পরীক্ষার কভারেজটি কিছুটা প্রসারিত করতে পারে। পিএইচপি জন্য কোড কভারেজ সরঞ্জাম


1
দুঃখিত, 35 টি নিয়ন্ত্রক এবং প্রায় সমান সংখ্যক মডেল। এমএমএমএম মনে হচ্ছে ইউনিট পরীক্ষার কিছু ফর্ম একটি সহায়তা হতে চলেছে।
উইজার্ড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.