একটি DBMS-এ ইউনিট পরীক্ষা - আমরা স্পোর্টমাস্টারে এটি কীভাবে করি, প্রথম অংশ

হে হাবর!

আমার নাম ম্যাক্সিম পোনোমারেনকো এবং আমি স্পোর্টমাস্টারের একজন বিকাশকারী। আইটি ক্ষেত্রে আমার 10 বছরের অভিজ্ঞতা আছে। তিনি ম্যানুয়াল টেস্টিংয়ে তার কর্মজীবন শুরু করেন, তারপর ডাটাবেস ডেভেলপমেন্টে স্যুইচ করেন। বিগত 4 বছর ধরে, পরীক্ষা এবং বিকাশে অর্জিত জ্ঞান সংগ্রহ করে, আমি ডিবিএমএস স্তরে স্বয়ংক্রিয় পরীক্ষা করছি।

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

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

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

আধুনিক আইটি এই বৈশিষ্ট্য দ্বারা চিহ্নিত করা হয় যে একজন বিকাশকারীকে শুধুমাত্র পণ্য কোড লেখার জন্যই নয়, এই কোডটি পরীক্ষা করে এমন ইউনিট পরীক্ষাও লিখতে হবে।

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

আনুগত্য পরীক্ষা করা

প্রথমে, আসুন সেই প্রজেক্টের কথা বলি যেখানে আমরা একটি স্বয়ংক্রিয় টেস্টিং সিস্টেম স্থাপন করেছি। আমাদের প্রকল্পটি হল স্পোর্টমাস্টার আনুগত্য ব্যবস্থা (যাইহোক, আমরা ইতিমধ্যে এটি সম্পর্কে লিখেছি এই পোস্ট).

যদি আপনার কোম্পানি যথেষ্ট বড় হয়, তাহলে আপনার আনুগত্য ব্যবস্থায় তিনটি মানসম্পন্ন বৈশিষ্ট্য থাকবে:

• আপনার সিস্টেম অত্যন্ত লোড হবে
• আপনার সিস্টেমে জটিল কম্পিউটিং প্রক্রিয়া থাকবে
• আপনার সিস্টেম সক্রিয়ভাবে উন্নত করা হবে.

চলুন ক্রমানুসারে যাই... মোট, আমরা যদি সমস্ত স্পোর্টমাস্টার ব্র্যান্ড বিবেচনা করি, তাহলে রাশিয়া, ইউক্রেন, চীন, কাজাখস্তান এবং বেলারুশে আমাদের 1000 টিরও বেশি স্টোর রয়েছে। এই দোকানে প্রতিদিন প্রায় 300 কেনাকাটা করা হয়। অর্থাৎ প্রতি সেকেন্ডে ৩-৪টি চেক আমাদের সিস্টেমে প্রবেশ করে। স্বাভাবিকভাবেই, আমাদের আনুগত্য সিস্টেম অত্যন্ত লোড হয়. এবং যেহেতু এটি সক্রিয়ভাবে ব্যবহৃত হয়, তাই আমাদের অবশ্যই এর মানের সর্বোচ্চ মান প্রদান করতে হবে, কারণ সফ্টওয়্যারটিতে যেকোন ত্রুটির অর্থ বড় আর্থিক, সুনামগত এবং অন্যান্য ক্ষতি।

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

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

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

বর্ণিত বৈশিষ্ট্যগুলি প্রায় কোনও আনুগত্য সিস্টেমের জন্য আদর্শ। আসুন আমাদের প্রকল্পের বৈশিষ্ট্য সম্পর্কে কথা বলি।

প্রযুক্তিগতভাবে, আমাদের লয়্যালটি সিস্টেমের 90% লজিক সার্ভার-ভিত্তিক এবং Oracle-এ প্রয়োগ করা হয়। ডেলফিতে একটি ক্লায়েন্ট উন্মুক্ত রয়েছে, যেটি একটি স্বয়ংক্রিয় কর্মক্ষেত্র প্রশাসকের কার্য সম্পাদন করে। বাহ্যিক অ্যাপ্লিকেশনগুলির জন্য উন্মুক্ত ওয়েব পরিষেবা রয়েছে (উদাহরণস্বরূপ একটি ওয়েবসাইট)। অতএব, এটা খুবই যৌক্তিক যে যদি আমরা একটি স্বয়ংক্রিয় পরীক্ষার ব্যবস্থা স্থাপন করি, তাহলে আমরা ওরাকল-এ তা করব।

স্পোর্টমাস্টারে লয়্যালটি সিস্টেমটি 7 বছরেরও বেশি সময় ধরে বিদ্যমান এবং এটি একক বিকাশকারীদের দ্বারা তৈরি করা হয়েছিল... এই 7 বছরে আমাদের প্রকল্পে বিকাশকারীদের গড় সংখ্যা ছিল 3-4 জন৷ কিন্তু গত এক বছরে, আমাদের দল উল্লেখযোগ্যভাবে বেড়েছে, এবং এখন 10 জন লোক প্রকল্পে কাজ করছে। অর্থাৎ, এমন লোকেরা প্রকল্পে আসে যারা সাধারণ কাজ, প্রক্রিয়া এবং আর্কিটেকচারের সাথে পরিচিত নয়। এবং একটি বর্ধিত ঝুঁকি আছে যে আমরা ভুল মিস করব।

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

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

utPLSQL উদ্ধারে আসে

আপনি কি স্টিফেন ফিউয়ারস্টেইন সম্পর্কে কিছু জানেন?

এটি একজন স্মার্ট ব্যক্তি যিনি তার ক্যারিয়ারের একটি দীর্ঘ অংশ ওরাকল এবং পিএল/এসকিউএল-এর সাথে কাজ করার জন্য উত্সর্গ করেছেন এবং এই বিষয়ে বেশ বড় সংখ্যক কাজ লিখেছেন। তার একটি বিখ্যাত বই বলা হয়: “Oracle PL/SQL. পেশাদারদের জন্য।" এটি ছিল স্টিফেন যিনি utPLSQL সমাধান তৈরি করেছিলেন, বা, এটির জন্য দাঁড়ায়, Oracle PL/SQL এর জন্য ইউনিট টেস্টিং ফ্রেমওয়ার্ক। utPLSQL সমাধানটি 2016 সালে তৈরি করা হয়েছিল, কিন্তু এটি সক্রিয়ভাবে কাজ করা অব্যাহত রয়েছে এবং নতুন সংস্করণ প্রকাশ করা হয়েছে। রিপোর্ট করার সময়, সর্বশেষ সংস্করণটি 24 মার্চ, 2019 তারিখে।
এটা কি. এটি একটি পৃথক ওপেন সোর্স প্রকল্প। উদাহরণ এবং ডকুমেন্টেশন সহ এটির ওজন কয়েক মেগাবাইট। দৈহিকভাবে, এটি ORACLE ডাটাবেসের একটি পৃথক স্কিমা যার সাথে ইউনিট পরীক্ষার আয়োজন করার জন্য প্যাকেজ এবং টেবিলের একটি সেট রয়েছে। ইনস্টলেশন কয়েক সেকেন্ড সময় নেয়। utPLSQL এর একটি স্বতন্ত্র বৈশিষ্ট্য হল এর ব্যবহারের সহজতা।
বিশ্বব্যাপী, utPLSQL হল ইউনিট পরীক্ষা চালানোর জন্য একটি প্রক্রিয়া, যেখানে একটি ইউনিট পরীক্ষাকে সাধারণ ওরাকল ব্যাচ পদ্ধতি হিসাবে বোঝানো হয়, যার সংস্থা নির্দিষ্ট নিয়ম অনুসরণ করে। লঞ্চ করার পাশাপাশি, utPLSQL আপনার সমস্ত টেস্ট রানের একটি লগ সঞ্চয় করে এবং একটি অভ্যন্তরীণ রিপোর্টিং সিস্টেমও রয়েছে৷

এই কৌশলটি ব্যবহার করে বাস্তবায়িত ইউনিট পরীক্ষার কোডটি কেমন দেখাচ্ছে তার একটি উদাহরণ দেখি।

সুতরাং, স্ক্রীন ইউনিট পরীক্ষার সাথে একটি সাধারণ প্যাকেজ স্পেসিফিকেশনের কোড দেখায়। বাধ্যতামূলক প্রয়োজনীয়তা কি? প্যাকেটটি অবশ্যই "utp_" দিয়ে উপসর্গযুক্ত হতে হবে। পরীক্ষার সাথে সমস্ত পদ্ধতির অবশ্যই একই উপসর্গ থাকতে হবে। প্যাকেজটিতে অবশ্যই দুটি আদর্শ পদ্ধতি থাকতে হবে: "utp_setup" এবং "utp_teardown"৷ প্রথম পদ্ধতিটি প্রতিটি ইউনিট পরীক্ষা পুনরায় চালু করে বলা হয়, দ্বিতীয়টি - লঞ্চের পরে।

"utp_setup", একটি নিয়ম হিসাবে, আমাদের সিস্টেমকে একটি ইউনিট পরীক্ষা চালানোর জন্য প্রস্তুত করে, উদাহরণস্বরূপ, পরীক্ষার ডেটা তৈরি করা। "utp_teardown" - বিপরীতভাবে, সবকিছু মূল সেটিংসে ফিরে আসে এবং লঞ্চের ফলাফলগুলি পুনরায় সেট করে৷

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

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

এবং যদি আমরা একটি নতুন ক্লায়েন্ট তৈরির পদ্ধতি ব্যবহার করে ইউনিট পরীক্ষা লিখি, তবে প্রতিটি পরীক্ষার পরে সিস্টেমে একটি নতুন ক্লায়েন্ট তৈরি করা হবে, যা পরীক্ষার পরবর্তী লঞ্চকে প্রভাবিত করতে পারে।

এইভাবে ইউনিট পরীক্ষা চালানো হয়। দুটি সম্ভাব্য লঞ্চ বিকল্প রয়েছে: একটি নির্দিষ্ট প্যাকেজ থেকে সমস্ত ইউনিট পরীক্ষা চালানো বা একটি নির্দিষ্ট প্যাকেজে একটি নির্দিষ্ট ইউনিট পরীক্ষা চালানো।

এটি একটি অভ্যন্তরীণ রিপোর্টিং সিস্টেমের উদাহরণের মত দেখায়। ইউনিট পরীক্ষার ফলাফলের উপর ভিত্তি করে, utPLSQL একটি ছোট রিপোর্ট তৈরি করে। এতে আমরা প্রতিটি নির্দিষ্ট চেকের ফলাফল এবং ইউনিট পরীক্ষার সামগ্রিক ফলাফল দেখতে পাই।

অটোটেস্টের 6টি নিয়ম

আনুগত্য সিস্টেমের স্বয়ংক্রিয় পরীক্ষার জন্য একটি নতুন সিস্টেম তৈরি করা শুরু করার আগে, ব্যবস্থাপনার সাথে একসাথে, আমরা সেই নীতিগুলি নির্ধারণ করেছি যা আমাদের ভবিষ্যতের স্বয়ংক্রিয় পরীক্ষাগুলি মেনে চলা উচিত৷

1. অটোটেস্ট অবশ্যই কার্যকর হতে হবে এবং অবশ্যই কার্যকর হতে হবে। আমাদের কাছে বিস্ময়কর বিকাশকারী রয়েছে, যাদের অবশ্যই উল্লেখ করা দরকার, কারণ তাদের মধ্যে কেউ কেউ সম্ভবত এই প্রতিবেদনটি দেখতে পাবে এবং তারা চমৎকার কোড লেখে। কিন্তু এমনকি তাদের বিস্ময়কর কোড নিখুঁত নয় এবং ত্রুটি রয়েছে, আছে এবং থাকবে। এই ত্রুটিগুলি খুঁজে পেতে অটোটেস্ট প্রয়োজন। যদি এটি না হয়, তাহলে হয় আমরা খারাপ অটোটেস্ট লিখছি, অথবা আমরা এমন একটি মৃত এলাকায় এসেছি যা, নীতিগতভাবে, বিকাশ করা হচ্ছে না। উভয় ক্ষেত্রেই, আমরা কিছু ভুল করছি, এবং আমাদের পদ্ধতির কোন অর্থ নেই।
2. অটোটেস্ট ব্যবহার করা উচিত। এটি একটি সফ্টওয়্যার পণ্য লেখার জন্য অনেক সময় এবং প্রচেষ্টা ব্যয় করার কোন অর্থ নেই, এটি একটি সংগ্রহস্থলে রাখুন এবং এটি ভুলে যান৷ পরীক্ষা চালানো উচিত, এবং যতটা সম্ভব নিয়মিত চালানো উচিত।
3. অটোটেস্টগুলি স্থিরভাবে কাজ করা উচিত। দিনের সময়, লঞ্চ স্ট্যান্ড এবং অন্যান্য সিস্টেম সেটিংস নির্বিশেষে, টেস্ট রান একই ফলাফলের দিকে পরিচালিত করবে। একটি নিয়ম হিসাবে, এটি নিশ্চিত করা হয় যে অটোটেস্টগুলি নির্দিষ্ট সিস্টেম সেটিংস সহ বিশেষ পরীক্ষার ডেটার সাথে কাজ করে।
4. অটোটেস্টগুলি আপনার প্রকল্পের জন্য গ্রহণযোগ্য গতিতে কাজ করা উচিত। এই সময় প্রতিটি সিস্টেমের জন্য পৃথকভাবে নির্ধারিত হয়। কিছু লোক সারাদিন কাজ করার সামর্থ্য রাখে, অন্যরা এটাকে কয়েক সেকেন্ডের মধ্যে করাকে গুরুত্বপূর্ণ বলে মনে করে। আমি আপনাকে একটু পরে বলব যে আমরা আমাদের প্রকল্পে কী গতির মান অর্জন করেছি।
5. অটোটেস্ট ডেভেলপমেন্ট নমনীয় হওয়া উচিত। কোনো কার্যকারিতা পরীক্ষা করতে অস্বীকার করা যুক্তিযুক্ত নয় কারণ আমরা এটি আগে বা অন্য কোনো কারণে করিনি। utPLSQL বিকাশের উপর কোন বিধিনিষেধ আরোপ করে না, এবং ওরাকল, নীতিগতভাবে, আপনাকে বিভিন্ন জিনিস বাস্তবায়নের অনুমতি দেয়। বেশিরভাগ সমস্যারই সমাধান আছে, এটা শুধু সময় এবং প্রচেষ্টার ব্যাপার।
6. স্থাপনযোগ্যতা। আমাদের বেশ কয়েকটি স্ট্যান্ড রয়েছে যেখানে আমাদের পরীক্ষা চালানো দরকার। প্রতিটি স্ট্যান্ডে, একটি ডেটা ডাম্প যেকোনো সময় আপডেট করা যেতে পারে। স্বয়ংক্রিয় পরীক্ষার সাথে একটি প্রকল্প পরিচালনা করা প্রয়োজন যাতে আপনি ব্যথাহীনভাবে এটির সম্পূর্ণ বা আংশিক ইনস্টলেশন চালাতে পারেন।

এবং কয়েক দিনের মধ্যে দ্বিতীয় পোস্টে আমি আপনাকে বলব আমরা কী করেছি এবং কী ফলাফল অর্জন করেছি।

উত্স: www.habr.com