কেন্দ্রীয় ধারণা
একটি পণ্য বিভাগ একটি স্থাপত্য নির্দেশ করে না। একটি সিস্টেমকে পরিষেবাগুলিতে বিভক্ত করার আগে অ্যাকাউন্ট, অর্ডার, ডেটা এবং ইন্টিগ্রেশনগুলি বুঝুন।
বাণিজ্য একটি পেমেন্ট বোতামের চেয়ে বেশি
আপনার স্পষ্ট ইভেন্ট অর্থ সহ পণ্য, মূল্য, অর্ডার, অর্থপ্রদান এবং ফেরতের সংজ্ঞা প্রয়োজন। একটি অর্থপ্রদান পৃষ্ঠা খোলা অর্থ পাওয়ার প্রমাণ নয়। প্রোভাইডার বিজ্ঞপ্তি এবং ডুপ্লিকেট-ইভেন্ট পরিচালনার সার্ভার-সাইড যাচাইকরণের পরিকল্পনা করুন। একটি হোস্ট করা কমার্স প্ল্যাটফর্ম স্ট্যান্ডার্ড অপারেশনগুলিকে আরও ভালভাবে ফিট করতে পারে, যখন অস্বাভাবিক প্রয়োজনীয়তাগুলি একটি পৃথক পরীক্ষার প্রাপ্য।
SaaS গ্রাহকদের মধ্যে সীমানা যোগ করে
যখন বেশ কয়েকটি কোম্পানি একটি সিস্টেম ব্যবহার করে, তখন ডেটা, অনুমতি এবং রিপোর্ট বিচ্ছেদ একটি ইন্টারফেস ফিল্টারে ছেড়ে দেওয়া যাবে না। ভাগ করা এবং প্রতিটি গ্রাহক প্রতিষ্ঠানের নিজস্ব রিসোর্স এবং প্রশাসন, বিলিং ও ডেটা এক্সপোর্টের দায়িত্ব সংজ্ঞায়িত করুন। অ্যাকাউন্ট গণনা সমকালীন অনুরোধ গণনা নয়: একটি কাজের চাপ বর্ণনা করে যে লোকেরা কী করে, কখন তারা এটি করে এবং প্রতিটি অ্যাকশন কতটা ডেটা পরিচালনা করে।
ড্যাশবোর্ডের সামঞ্জস্যপূর্ণ সংজ্ঞা প্রয়োজন
একটি চার্ট আঁকার আগে, "সম্পূর্ণ", "দেরী" এবং "পর্যালোচনার অধীনে" এর অর্থ কী তা সম্মত হন। গণনা কি সব রেকর্ড কভার করে নাকি শুধুমাত্র বর্তমান পৃষ্ঠা? একটি তারিখ কি সৃষ্টি বা সর্বশেষ আপডেটের প্রতিনিধিত্ব করে? একটি মেট্রিকের উত্স এবং সীমা পরিষ্কার করুন এবং হিসাব না করা শতাংশ বা সংখ্যা প্রদর্শন করবেন না। এগুলি চার্ট-লাইব্রেরি পছন্দ হওয়ার আগে পণ্য এবং ডেটার সিদ্ধান্ত।
উদাহরণ: একটি অনুরোধ একটি বহিরাগত পরিষেবা অতিক্রম করে৷
ধরুন একজন ব্যবহারকারী একটি অনুরোধ জমা দেন এবং প্রদানকারীর প্রতিক্রিয়া বাধাপ্রাপ্ত হয়। সাফল্য আবিষ্কার করবেন না বা অন্ধভাবে পুনরায় চেষ্টা করবেন না। একটি বোধগম্য অবস্থা, একটি অপারেশন শনাক্তকারী এবং একটি নিরাপদ যাচাইকরণ বা সার্ভারে পুনরায় চেষ্টা করার পথ ডিজাইন করুন৷ স্পষ্ট সীমানার পিছনে ইন্টিগ্রেশনকে আলাদা করুন যাতে একটি প্রদানকারী পরিবর্তন প্রতিটি ইন্টারফেসে সম্পাদনা করতে বাধ্য না করে। এই উদাহরণটি কোন প্রকৃত প্রদানকারীর অনুমোদন বা লাইভ ইন্টিগ্রেশন বোঝায় না।
প্রমাণে যৌক্তিক মনে হলেই পরিধি বাড়ান
সুস্পষ্ট যৌক্তিক সীমানা দিয়ে শুরু করুন যা পরীক্ষা এবং বজায় রাখা যেতে পারে। নির্দিষ্ট সমস্যা সমাধানের জন্য ক্যাশিং এবং ব্যাকগ্রাউন্ড কাজ যোগ করুন, একটি প্রযুক্তি চেকলিস্ট সম্পূর্ণ করতে নয়। গুরুত্বপূর্ণ পরিস্থিতি এবং ব্যর্থতা পরিমাপ করুন এবং কোথায় অনুমোদিত লোড পরীক্ষার প্রয়োজন তা চিহ্নিত করুন। একটি ভাষা বা ক্লাউড ব্র্যান্ডের উপর ভিত্তি করে এক মিলিয়ন ব্যবহারকারীর গ্যারান্টি দেবেন না এবং অনুমতি ছাড়া তৃতীয় পক্ষের সিস্টেমে লোড টেস্ট করবেন না।
শিক্ষাগত উদাহরণ / পর্যালোচনাযোগ্য পদক্ষেপ
সিস্টেমের অবস্থা পরীক্ষা: সাবস্ক্রিপশন, অর্থপ্রদান ও গ্রাহকের ডেটার সীমানা
একটি শিক্ষামূলক দৃশ্য যেখানে দুটি পরীক্ষা প্রতিষ্ঠান একটি পণ্যের সদস্যতা নিচ্ছে এবং অর্থপ্রদানের বিজ্ঞপ্তি গ্রহণ করছে। হিসাব এবং ঘটনা সিন্থেটিক; এটি একটি সক্রিয় পেমেন্ট গেটওয়ে বা এই ওয়েবসাইটে বিদ্যমান ইন্টিগ্রেশন বোঝায় না।
- গ্রাহক বিচ্ছেদ: একটি সংস্থা A রেকর্ড তৈরি করুন এবং ইন্টারফেস, API এবং রপ্তানির মাধ্যমে সংগঠন B হিসাবে অনুরোধ করুন। এমনকি পরিচিত রেকর্ড আইডি দিয়েও কোনো পথের মাধ্যমে কোনো প্রকাশ স্বীকার করবেন না।
- অর্থপ্রদান নিশ্চিতকরণ: প্রকৃত অর্থপ্রদান ছাড়াই একটি ব্রাউজার সাফল্য পৃষ্ঠা খুলুন। অপরিবর্তিত এনটাইটেলমেন্ট গ্রহণ করুন যতক্ষণ না সার্ভার সঠিক অ্যাকাউন্ট এবং অর্ডারের জন্য একটি প্রামাণিক অবস্থা যাচাই করে।
- বিজ্ঞপ্তির উৎস: সেবাদাতার ডকুমেন্টেশন অনুযায়ী একটি ভুল স্বাক্ষরযুক্ত ও একটি সঠিক স্বাক্ষরযুক্ত পরীক্ষামূলক ইভেন্ট পাঠান। প্রথমটি প্রত্যাখ্যাত হলে, দ্বিতীয়টি নথিভুক্তভাবে প্রক্রিয়াকৃত হলে এবং লগে গোপন তথ্য না থাকলে পরীক্ষা সফল।
- ডুপ্লিকেট হ্যান্ডলিং: একই ইভেন্ট দুবার ডেলিভার করুন, তারপর প্রদানকারীর দ্বারা সমর্থিত একটি অপারেশনের জন্য দুটি ইভেন্ট পরীক্ষা করুন। ট্রেসযোগ্য প্রক্রিয়াকরণ সহ কোনও সদৃশ এনটাইটেলমেন্ট বা আর্থিক রেকর্ড গ্রহণ করবেন না।
- বিলম্ব ও ক্রম: ভুল ক্রমে বা বিভ্রাটের পরে পরীক্ষার আপডেট পাঠান। সাবস্ক্রিপশনকে অপ্রচলিত অবস্থায় ফিরিয়ে আনার পরিবর্তে প্রামাণিক কারেন্ট-স্টেট চেক এবং অনুমোদিত ট্রানজিশন গ্রহণ করুন।
- বাতিলকরণ এবং রপ্তানি: সংগঠন A বাতিল করুন এবং নীতির গ্রেস পিরিয়ড এবং রপ্তানি পরীক্ষা করুন। শুধুমাত্র A-এর অ্যাক্সেসে পরিবর্তনগুলিকে গ্রহণ করুন, B সংগঠনকে প্রভাবিত না করে এবং এর ডেটা অপ্রকাশিত।
জনপ্রিয়তা নয়, প্রয়োজনের সঙ্গে কতটা মানানসই তা তুলনা করুন।
বিদ্যমান বাণিজ্য প্ল্যাটফর্ম
মানানসই: স্ট্যান্ডার্ড সেলিং ওয়ার্কফ্লো এবং অনুমোদিত উপলব্ধ ইন্টিগ্রেশন।
বিবেচনা করুন: কাস্টমাইজেশন, এক্সপোর্ট, পেমেন্ট স্টেট এবং ফি পরীক্ষা করুন।
কাস্টম ওয়েব অ্যাপ্লিকেশন
মানানসই: ব্যবসায়িক নিয়ম বা ভিন্ন গ্রাহক প্রতিষ্ঠানের ডেটা পৃথক রাখার সীমা, যা বিদ্যমান সফ্টওয়্যারে সমর্থিত নয়।
বিবেচনা করুন: ডেটা, অনুমতি, ইন্টিগ্রেশন এবং অপারেশন টেস্টিং প্রয়োজন।
বিদ্যমান সিস্টেম উন্নত করুন
মানানসই: একটি শনাক্তযোগ্য, বিচ্ছিন্ন সমস্যা সহ একটি উপযুক্ত ভিত্তি।
বিবেচনা করুন: উত্স বোঝার এবং একটি যাচাইকরণ/রোলব্যাক পরিকল্পনা প্রয়োজন৷
এটি সিদ্ধান্ত নিতে সহায়তার জন্য, কোনো পরিষেবার প্রস্তাব বা কর্মক্ষমতার নিশ্চয়তা নয়। চূড়ান্ত পছন্দ আপনার প্রয়োজন এবং বাস্তবায়নের সময় নির্বাচিত সংস্করণগুলোর ওপর নির্ভর করবে।
আরও পড়ার জন্য অফিসিয়াল সূত্র
OWASP — অ্যাপ্লিকেশন নিরাপত্তা যাচাইকরণ স্ট্যান্ডার্ডএকটি নতুন উইন্ডোতে খোলেPostgreSQL — ডকুমেন্টেশনএকটি নতুন উইন্ডোতে খোলেweb.dev — Web Vitalsএকটি নতুন উইন্ডোতে খোলেStripe — ওয়েবহুক যাচাই, পুনরাবৃত্ত ইভেন্ট ও ইভেন্টের ক্রমএকটি নতুন উইন্ডোতে খোলেউৎসগুলো প্রযুক্তির বৈশিষ্ট্য ব্যাখ্যা করে। বিভিন্ন পরিস্থিতি ও সুবিধা-সীমাবদ্ধতার আলোচনা প্রেক্ষাপটভিত্তিক নির্দেশনা, বেঞ্চমার্ক পরীক্ষার ফলাফল নয়।