"1C: تست سناریو. ابزارهای تست برای کسانی که از اتلاف وقت خود برای کارهای معمول متنفرند

این مقاله یک مکانیسم تست خودکار جدید را مورد بحث قرار می دهد که برای اولین بار در نسخه 8.3 در پلتفرم ظاهر شد. پس از مطالعه مقاله یاد خواهید گرفت:

• تست خودکار در پلتفرم چیست؟
• چگونه و چه زمانی از آن استفاده کنیم؟
• برای اجرا به چه چیزی و کجا نیاز دارید؟
• چگونه یک اسکریپت تست خودکار بنویسیم؟

قابلیت کاربرد

این مقاله در مورد پلتفرم 1C: Enterprise نسخه 8.3.4.465 بحث می کند. در نسخه فعلی پلت فرم، قابلیت های مکانیزم تست خودکار به طور قابل توجهی گسترش یافته است، اما این موضوع بر ارتباط مقاله تأثیری نداشت. هنوز هم مرتبط است.

تست خودکار در 1C: Enterprise 8.3

پلت فرم 1C:Enterprise 8.3 دارای مکانیزم جدیدی است که برای شبیه سازی اقدامات تعاملی کاربران سیستم طراحی شده است - تست خودکار.

تست خودکار از کار با یک رابط معمولی پشتیبانی نمی کند، بلکه فقط با یک رابط مدیریت شده پشتیبانی می کند.

هنگام آزمایش، از دو نوع برنامه مشتری استفاده می شود - مدیر آزمون و مشتری آزمایش. مدیر تست با مشتری تست ارتباط برقرار می کند و اسکریپت تست را اجرا می کند.

یک اسکریپت آزمایشی کدی است در یک زبان تعبیه شده که توالی اقدامات تعاملی را که باید انجام شود، توصیف می کند.

برای این منظور، اشیاء جدیدی به زبان داخلی اضافه شده است که در سطح انتزاعی رابط برنامه (از نظر پنجره، فرم، کنترل ها و غیره) را توصیف می کند و همچنین اقدامات کاربر (پیمایش از طریق پیکربندی) را توصیف می کند. ، ورود داده ها و غیره) .

مدیر آزمون می تواند یک مشتری ضخیم یا نازک باشد. مشتری آزمایشی – کلاینت ضخیم، نازک یا وب کلاینت.

یک مدیر تست می تواند به چندین مشتری آزمایشی متصل شود، اما یک سرویس گیرنده آزمایشی فقط می تواند به یک مدیر متصل شود.

برای مدیریت مشتری، مدیر یک اتصال TCP با آن برقرار می کند. مهم است که تست خودکار نیازی به تغییر در ساختار پیکربندی نداشته باشد.

اساساً مشتری و مدیر تست پیکربندی‌هایی هستند که با پارامترهای خط فرمان خاصی اجرا می‌شوند، با مدیری که مشتریان را با «ساختن» پنجره‌ها و کنترل‌ها مدیریت می‌کند که گویی کاربر با آنها در تعامل است.

تست خودکار محدودیت هایی دارد. به عنوان مثال، کار با یک رابط معمولی پشتیبانی نمی شود، اما فقط با یک رابط مدیریت شده پشتیبانی می شود.

برای انجام تست خودکار، مدیر آزمون و کلاینت تست باید در حال اجرا باشند.

مدیر را می توان از خط فرمان با کلید /TESTMANAGER راه اندازی کرد:

"c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F "X:\test" /N Administrator /TESTMANAGER

همچنین می توانید مدیر تست را از پیکربندی راه اندازی کنید.

برای انجام این کار، از طریق منوی Tools - Options، گفتگوی "Options" را باز کنید، که در آن، در برگه Launch 1C: Enterprise - Advanced، مورد "Run as testing manager" را انتخاب کنید:

راه دیگری برای راه اندازی مدیر تست از زبان داخلی است، با استفاده از متد StartSystem() که در آن باید خط فرمان را مشخص کنید:

RunSystem("c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F X:\test /N Administrator /TESTMANAGER")

کلاینت تست را می توان از خط فرمان نیز راه اندازی کرد. برای انجام این کار، از سوئیچ گزینه خط فرمان /TESTCLIENT استفاده کنید.

با استفاده از پارامتر TPort، شماره پورتی را مشخص می‌کنید که از طریق آن مدیر و کلاینت آزمایشی با هم تعامل خواهند داشت. اگر این پارامتر در خط فرمان مشخص نشده باشد، از پورت 1538 استفاده می شود.

"c:\Program Files (x86)\1cv8\8.3.4.437\bin\1cv8c.exe" ENTERPRISE /F "X:\Platform8Demo" /N Administrator /TESTCLIENT -TPort 1539

مشتری آزمایشی را می توان از پیکربندی راه اندازی کرد. برای انجام این کار، از طریق منوی Tools - Options، گفتگوی "Options" را باز کنید، که در آن، در برگه Launch 1C: Enterprise - Advanced، مورد "Run as testing client" را علامت بزنید. در این صورت باید شماره پورت استفاده شده را مشخص کنید.

لطفاً توجه داشته باشید که برای اتصال به سرویس گیرنده آزمایشی، باید دو پارامتر را بدانید: آدرس IP (یا نام) رایانه ای که کلاینت آزمایشی روی آن اجرا می شود و شماره پورت TCP که تعامل از طریق آن انجام می شود.

هر دو پایگاه اطلاعاتی مختلف می توانند به عنوان مدیر آزمایش و سرویس گیرنده آزمایشی استفاده شوند (پیکربندی پایگاه داده مدیر آزمایش ممکن است با پیکربندی مشتری آزمایشی مطابقت نداشته باشد) یا همان پایگاه اطلاعاتی.

برای انجام تست خودکار، باید مراحل زیر را انجام دهید:

1. یک اسکریپت آزمایشی ایجاد کنید - یک پردازش خارجی یا داخلی بنویسید که در آن مراحلی که باید انجام شوند به ترتیب شرح داده می شوند.
2. Test Manager را راه اندازی کنید.
3. یک کلاینت آزمایشی (یک یا چند) راه اندازی کنید.
4. در مدیر تست، پردازش ایجاد شده را اجرا کنید و مطمئن شوید که اقدامات برنامه ریزی شده روی مشتری انجام می شود.

برنامه تحت آزمایش با مجموعه ای از اشیاء زبان داخلی که برای نوشتن اسکریپت استفاده می شود، توصیف می شود:

• برنامه تست شده؛
• ClientApplicationWindow در حال آزمایش است.
• TestedWindowCommandInterface.
• TestGroupCommandInterface.
• TestCommandInterfaceButton؛
• TestForm;
• TestFormField;
• TestFormGroup;
• TestFormButton;
• TestFormTable;
• TestedDecorationForm.

ما از پیکربندی نمایشی «برنامه مدیریت شده» به عنوان پیکربندی مورد آزمایش استفاده خواهیم کرد.

بیایید یک پردازش خارجی ایجاد کنیم، یک فرم جدید اضافه کنیم که در آن یک کنترل کننده برای دستور جدید RunTesting تعریف می کنیم.

در آزمایش، اقدامات زیر را انجام می دهیم: یک عنصر دایرکتوری جدید "Warehouses" ایجاد کنید، در قسمت Name خط "Warehouse test" را وارد کنید، سپس روی دکمه "Record and close" کلیک کنید.

کد این تست به شکل زیر خواهد بود:

&OnClient
روش اجرای تست(تیم)
// به برنامه تحت آزمایش متصل شوید
درخواست در حال آزمایش= جدید درخواست در حال آزمایش("localhost")؛
// سعی می کنیم بیشتر از یک دقیقه وصل شویم
پایان زمان انتظار= تاریخ فعلی () + 60 ;
متصل = نادرست ;
هنوز نه CurrentDate() >= پایان زمان انتظارتلاش چرخه ای
برنامه تحت آزمایش. EstablishConnection();
متصل = درست ;
سقط
استثنا
پایان تلاش ; چرخه پایان ; اگر متصل نیست پس
// آزمون را تمام کنید
درخواست در حال آزمایش= تعریف نشده
گزارش دادن ( "ارتباط ناموفق بود!");
برگشت ؛
EndIf
// پنجره اصلی را پیدا کنید
MainWindowTested
= (Type());
MainWindowTested.Activate();
// دستور ایجاد یک آیتم فهرست محصول را اجرا کنید
پنجره اصلی Test Subject.Execute Command("e1cib/command/Directory.Warehouses.Create");
برنامه تحت Test.ExpectDisplayObject(نوع ( "TestForm")، "موجودی*" )؛
TestForm= برنامه تحت Test.FindObject(نوع ( "TestForm"),
"موجودی*" )؛
TestForm.Activate();
// یک نام برای محصول جدید تعیین کنید
FormElement = TestForm.FindObject(نوع ( "FormField در حال آزمایش"),
"نام");
Form Element.Activate();
Form Element.EnterText("آزمون انبار")؛
// عنصر را بنویسید
FormElement = TestForm.FindObject(نوع ( "FormButton در حال آزمایش است"),
"ضبط و بستن");
عنصر فرم. کلیک کنید();
پایان رویه

در گفتگوی گزینه های راه اندازی، ابتدا مقدار «اجرا به عنوان مدیر آزمایش» انتخاب شد و جلسه کاربر با استفاده از کلید ترکیبی Ctrl+F5 راه اندازی شد.

سپس در محاوره مقدار "Run as testing client" انتخاب شد و با استفاده از کلید ترکیبی Ctrl+F5 دومین جلسه کاربر راه اندازی شد.

به این ترتیب از نیاز به تعیین دستی پارامترهای خط فرمان مورد نیاز اجتناب کردیم.

کد بالا کار نسبتاً ساده‌ای را انجام می‌دهد، اما با پیچیده‌تر شدن سناریو، اندازه کد با توجه به نیاز به توضیح هر تعامل کاربر افزایش می‌یابد.

اینجاست که یکی دیگر از ویژگی‌های جدید این پلتفرم کمک می‌کند – ثبت گزارشی از اقدامات کاربر.

برای انجام این کار، باید برنامه را در یک حالت خاص اجرا کنید:

برای بزرگنمایی روی تصویر کلیک کنید.

چندین دکمه در هدر برنامه ظاهر می شود:

دکمه ها برای:

• شروع/مکث ضبط؛
• خاتمه ضبط؛
• اتمام ضبط

پس از اتمام ضبط، یک سند متنی روی صفحه باز می شود که دنباله ای از اقدامات کاربر ذخیره شده در یک فایل XML است.

برای بزرگنمایی روی تصویر کلیک کنید.

گزارش ثبت شده را می توان به کد برنامه تبدیل کرد، که سپس می تواند در یک اسکریپت آزمایشی استفاده شود.

برای این منظور پردازش “User Action Log Conversion” (UIlogToScript.epf) در نظر گرفته شده است که می توانید آن را از وب سایت ITS دریافت کنید.

برای بزرگنمایی روی تصویر کلیک کنید.

در نتیجه کار پردازش، کد تولید شده را به زبان داخلی دریافت می کنیم. این کد باید در ماژول فرم پردازش تست چسبانده شود.

توجه داشته باشید که در کد تولید شده، اعداد بزرگتر از 999 یا کمتر از 999- با استفاده از یک فضای بدون شکست به عنوان جداکننده گروه (به عنوان مثال، "1234" به جای "1234") خروجی خواهند شد.

این کاراکتر باید به صورت دستی از کد دریافتی حذف شود.

بخش کد با اتصال به مشتری به طور خودکار با پردازش تولید شد.

در مثال ما کد زیر را دریافت کردیم:

&OnClient
روش اجرای تست(تیم)
سناریوی آزمایشی_23_03_2014();
پایان رویه و روی مشتری
روش سناریوی آزمایشی_23_03_2014() نرم افزار تست= جدید درخواست در حال آزمایش();
پایان زمان انتظار= تاریخ فعلی () + 60 ;
متصل = نادرست ;
توضیحات ErrorsConnections= “” ;
هنوز نه CurrentDate() >= پایان زمان انتظارچرخه
تلاش
تست Application.SetConnection();
متصل = درست ;
سقط
استثنا
توضیحات ErrorsConnections= ErrorDescription();
پایان تلاش ;
چرخه پایان ;
اگر متصل نیست پس
نرم افزار تست= تعریف نشده
گزارش (+ Symbols.PS + توضیحات ErrorsConnections);
برگشت ؛
EndIf ( نرم افزار تست);
(نرم افزار تست) پایان رویه و روی مشتری
روش WindowApplicationsCounterpartiesButtonCreatePress(نرم افزار تست)
WindowApplicationsCounterparties= (نوع (
"پنجره تست برنامه مشتری"), “Counterparties” , , 30 );
WindowApplicationsContractorsFormContractors= Window Applications Contractors Find Object(نوع (
"TestForm")، "طرفدارهای متقابل")؛
ButtonCreate = Window Applications Contractors Form Contractors(نوع (
"FormButton در حال آزمایش است")، "ايجاد كردن" )؛
ButtonCreate.کلیک کنید()؛ پایان رویه و روی مشتری
روش WindowApplicationsCounterpartyCreateButtonRecordAndClosePress(نرم افزار تست) WindowApplicationsCounterpartyCreation= TestApplication.FindObject(نوع (
"پنجره تست برنامه مشتری"), "طرف مقابل (آفرینش)", , 30 );
WindowApplicationsAccountCreationFormAccountCreation=
برنامه های کاربردی پنجره CounterpartyCreation.FindObject(نوع ( "TestForm"),
"طرف مقابل (آفرینش)");
نام زمینه=
(نوع (
"FormField در حال آزمایش"), "نام");
FieldName.EnterText("جدید" )؛ FieldViewPrice = WindowApplicationsAccountCreationFormAccountCreation.FindObject(نوع (
"FormField در حال آزمایش")، "نوع قیمت ها")؛
FieldTypePrice.Activate(); FieldTypePrice.Select(); FieldTypePrice.ExpectFormationDropdownList(); FieldTypePrice.ExecuteSelectionFromSelectionList("خرید")؛ ButtonRecordIClose=
WindowApplicationsAccountCreationFormAccountCreation.FindObject(نوع (
"FormButton در حال آزمایش است"), "ضبط و بستن");
ButtonRecordIClose. فشار دهید()؛ پایان رویه

در اسکریپت به دست آمده، اتصال به مشتری آزمایشی برقرار می شود، دکمه ایجاد یک آیتم دایرکتوری جدید "Counterparties" در فیلد فشار داده می شود. ناممتن "جدید" را وارد کنید و در لیست کشویی "نوع قیمت"، مقدار "خرید" را انتخاب کنید، سپس روی دکمه "ضبط و بستن" کلیک کنید.

اگر یک سناریو نیاز به استفاده از چندین مشتری آزمایشی داشته باشد، اتصال به هر یک از آنها و اقدامات انجام شده باید به طور جداگانه شرح داده شود.

یک مدیر تست استفاده خواهد شد و دو کلاینت در پورت های مختلف به آن متصل خواهند شد.

از آنجایی که یک اسکریپت آزمایشی پردازشی است که خطوط کد آن به صورت متوالی اجرا می شوند، توسعه دهنده باید دنباله ای از اقدامات را برای هر مشتری توصیف کند.

بیایید نگاهی دقیق تر به نحوه نمایش کد هنگام استفاده از دو مشتری آزمایشی بیندازیم:

روش سناریوی آزمایشی_23_03_2014_دو مشتری() //اولین مشتری
برنامه آزمایشی 1= جدید درخواست در حال آزمایش();
پایان زمان انتظار= تاریخ فعلی () + 60 ;
متصل = نادرست ;
توضیحات ErrorsConnections= “” ;
هنوز نه CurrentDate() >= پایان زمان انتظارچرخه
تلاش
برنامه آزمایشی 1. اتصال را برقرار کنید();
متصل = درست ;
سقط
استثنا
توضیحات ErrorsConnections= ErrorDescription();
پایان تلاش ;
چرخه پایان ; //دوم مشتری
برنامه تست 2= جدید درخواست در حال آزمایش();
پایان زمان انتظار= تاریخ فعلی () + 60 ;
توضیحات ErrorsConnections= “” ;
هنوز نه CurrentDate() >= پایان زمان انتظارچرخه
تلاش
برنامه آزمایشی 2. اتصال را برقرار کنید();
متصل = درست ;
سقط
استثنا
توضیحات ErrorsConnections= ErrorDescription();
پایان تلاش ;
چرخه پایان ;
اگر متصل نیست پس
برنامه آزمایشی 1= تعریف نشده
برنامه تست 2= تعریف نشده
گزارش دادن ( "ما نتوانستیم ارتباط برقرار کنیم!"+ نمادها.PS + توضیحات ErrorsConnections);
برگشت ؛
EndIf //روش های جداگانه برای هر مشتری آزمایشی
WindowApplicationsCounterpartiesButtonCreatePress1(برنامه آزمایشی 1);
WindowApplicationsCounterpartiesButtonCreatePress2(برنامه تست 2);
WindowApplicationsCounterpartyCreateButtonRecordAndClosePress1(برنامه آزمایشی 1);
WindowApplicationsCounterpartyCreateButtonRecordAndClosePress2(برنامه تست 2) پایان رویه

مکث بین اقدامات انجام شده نیز باید به طور جداگانه برنامه ریزی شود. خواندن متن برای تعداد زیادی از مشتریان دشوار می شود.

علاوه بر این، آزمایش خودکار فقط برای فرم های مدیریت شده در دسترس است.

با این حال، مزیت تست خودکار، سادگی و وضوح توسعه تست است. از آنجایی که تست فقط بر روی اقدامات تعاملی کاربر عمل می کند، توسعه دهنده نیازی به دانستن ساختارهای پیکربندی در سطح جزئیات شی ندارد.

اگر مثلاً کد پیکربندی را تغییر دهید، نیازی به انجام مجدد تست نیست زیرا همان اقدامات با کنترل های یکسان همچنان روی سرویس گیرنده آزمایشی انجام می شود.

یک مکانیسم تست خودکار می تواند توسط آزمایش کنندگان برای ثبت توالی اقداماتی که منجر به خطا می شود استفاده شود. داده های ضبط شده را می توان برای توسعه دهندگان ارسال کرد تا خطای شناسایی شده را تصحیح کنند.

تست خودکار همچنین می تواند برای شناسایی قفل ها و بن بست های اضافی در یک پیکربندی استفاده شود.

برای انجام این کار، باید اسکریپتی را پیاده سازی کنید که مشکل را بازتولید کند و شروع به یافتن و حذف علت کنید.

بسیاری از متخصصان و کاربران ساده محصولات مبتنی بر 1C Enterprise 8 باید قبلاً در مورد انتشار یک محصول نرم افزاری جدید برای آزمایش هر گونه پیکربندی (طبق اظهارات رسمی) شنیده باشند و نام آن 1C سناریو تست 8 است. اجازه دهید بلافاصله توضیح دهم که این ابزار مستقیماً توسط شرکت 1C و نه فعالان شخص ثالث توسعه یافته است. من نتوانستم اطلاعاتی در مورد این محصول پیدا کنم (به غیر از چاپ مجدد بی پایان از وب سایت 1C)، که از آن می توانم نتیجه بگیرم که به سادگی وجود ندارد. و یافتن محصول بررسی خود آسان نیست، حداقل برای کسانی که نمی خواهند 30 هزار دلار برای مجوز بپردازند یا از قبل آن را همراه با عرضه ابزار دقیق ندارند. به هر حال، پس از مدتی سختی ها، توانستم این ساز را به دست بیاورم. و از این لحظه با جزئیات بیشتر شروع خواهم کرد.

نصب و راه اندازی.

در حال حاضر، من از راه های رسمی زیر برای دریافت این ابزار اطلاع دارم:

الف) در تحویل "1C: مجموعه ابزار شرکتی 8" گنجانده شده است.

ب) از وب سایت پشتیبانی کاربران 1C قابل دانلود است.

ج) یک نسخه اولیه روی دیسک ITS وجود داشت، به نظر می رسد از اکتبر.

خود برنامه حدود 2 مگابایت وزن دارد، اما برای خوشحالی خیلی زود است - برای نصب آن، باید مسیر پوشه را با الگوها مشخص کنید. همانطور که متوجه شدم، این دایرکتوری در تنظیمات اولیه یا در پیکربندی آزمایشی موجود در برنامه موجود است. ابتدا باید نصب شود (~90 مگابایت)، سپس با خیال راحت برنامه را نصب کرده و پیکربندی غیرضروری را حذف می کنیم.

پس از این دستکاری های ساده، کاتالوگی با ابزار مورد نظرمان دریافت خواهیم کرد. خود برنامه از دو پردازش خارجی *.epf تشکیل شده است، علاوه بر این یک توضیح کوتاه و یک آزمایش آزمایشی برای پیکربندی مشخصی که حذف کردیم، پیوست شده است.

اجازه دهید روشن کنم که باید با چه چیزی کار کنم. من نسخه 1.2.2.1 را گرفتم، واضح است که نسخه اولیه نیست. به عنوان یک پیکربندی آزمایشی، من از پیکربندی مبتنی بر 1C Enterprise 8.1 استفاده کردم.

تشریح.

بنابراین، همانطور که قبلاً اشاره کردم، آزمایش سناریو 1C شامل دو پردازش خارجی است: RecordTests و RunTests.

بیشتر اطلاعات را می توان در راهنمای داخلی پیدا کرد. با این حال، من امید زیادی به آن ندارم. اما، با این وجود، می توانید آن را برای توسعه کلی بخوانید.

برای شروع، من به زبان خودم عملکرد اصلی این ابزار را شرح خواهم داد و سپس سعی خواهم کرد به اجرای عملکردهای فردی بپردازم.

با استفاده از تست سناریو 1C، می توانید به راحتی اسناد، دایرکتوری ها، ثبت ها را طبق یک اسکریپت از پیش نوشته شده ایجاد کنید، آنها را با اشیاء مرجع و غیره مقایسه کنید، هم در حالت بصری و هم به صورت پنهان از چشم آزمایشگر. نمونه ای از یک سناریوی معمولی را می توان در تصویر اول مشاهده کرد.

هر نقطه در فیلمنامه یک مرحله نامیده می شود. به طور کلی، همه چیز در نگاه اول واضح و ساده است و افسوس که تا حدی فریبنده است. با این حال، در بخش بعدی در مورد مشکلات صحبت خواهیم کرد، اما در حال حاضر روی قابلیت های اساسی تمرکز خواهیم کرد.

برنج. 1 پردازش رکوردهای تست.

ایدئولوژی این ابزار مبتنی بر مقایسه اشیاء در پایگاه داده مرجع با اشیاء در پایگاه داده آزمایش شده است. این به وضوح در پنجره اصلی برای پردازش RecordTests قابل مشاهده است، در سمت چپ داده هایی از پایگاه داده مرجع وجود دارد، در سمت راست تست هایی بر اساس داده های سمت چپ وجود دارد. پایگاه داده مرجع پایگاهی است که آزمون در آن ایجاد شده است.

علاوه بر عملکرد اصلی ابزاری که در بالا توضیح داده شد، تعدادی دیگر وجود دارد که ابتدایی تر هستند، اما گاهی اوقات کمتر مفید نیستند. به عنوان مثال، این ابزار فقط می تواند برای تکمیل خودکار فرم ها، کلیک کردن بر روی دکمه ها، پر کردن بخش های جدولی و غیره استفاده شود. و از آنجایی که نقش کاربر توسط تستر بازی می شود، معلوم می شود که نوعی تست موقت در حالت خودکار است.

الگویی از مراحل معمولی وجود دارد که بسته به شی مورد آزمایش به طور خودکار تولید می شوند. در اینجا یک مثال معمولی وجود دارد: در سمت چپ، یک سند خاص (دایرکتوری و غیره) را انتخاب کنید و آن را به سمت راست بکشید، پس از آن یک الگوی مراحل معمولی به طور خودکار ایجاد می شود. سپس می توانید آنها را به دلخواه ویرایش کنید.

هر مرحله را می توان به طور مستقیم در این پردازش با فشار دادن F12 انجام داد. این عملکرد نیاز به پردازش دوم RunTests را زیر سوال می برد.

برنج. 2 پردازش RunTests.

تست تمام شده در یک سند xml نوشته شده است، که ما آن را در پایگاه داده تحت آزمایش از طریق پردازش RunTest باز می کنیم و مشاهده می کنیم که چگونه همه چیز برای ما عالی کار می کند.

با توجه به اینکه اجرا با پردازش اول نیز قابل انجام است، عملکرد پردازش دوم تفاوتی ندارد. برخی از ویژگی های مفید شامل نگه داشتن گزارشی از اجرا و علامت گذاری مراحل تکمیل شده است.

با نگاهی به آینده، برای اینکه دوباره به این پردازش برنگردم، می گویم که درجا شگفت زده شدم. با همه گزینه های ضروری و نه چندان ضروری، جایی برای حالت اجرای آزمایشی که خطاها را نادیده می گرفت، وجود نداشت. که انجام تست های منفی و به طور کلی آزمایش را بسیار ناخوشایند می کند. هنگامی که کوچکترین اختلاف ظاهر می شود، پردازش "اتوماتیک" ما دچار سردرگمی می شود.

حال بیایید مزایا و معایب استفاده از این سیستم را در این زمینه بررسی کنیم.

ویژگی های استفاده.

طبق بیانیه های رسمی، آزمایش سناریو 1C باید از نظر سازگاری با پیکربندی های مختلف یک ابزار جهانی باشد. من فکر می کنم پیکربندی من یک بستر آزمایشی عالی برای این بیانیه است.

فوراً می گویم که روند کار با این ابزار را نمی توان ساده و آرام نامید. تقریباً در هر مرحله (به تمام معنا) باید چیزهای به ظاهر بدیهی را آزمایش کنید.

در اینجا برخی از مواردی است که باید با آنها سر و کار داشتم:

1. بنا به دلایلی، با همه گزینه های مختلف برای مراحل تست، هیچ مرحله ای برای حذف شی پردازش شده وجود ندارد. در ابتدا مجبور شدم از مرحله "Process" استفاده کنم و به صورت دستی کد بنویسم تا اشیا را حذف کنم. در پایان تصمیم گرفتم فعلا بدون آن کار کنم و با داده های موجود کار کنم.
2. یکی از مفیدترین آنها، به نظر من، مرحله "مقایسه حرکت با یک استاندارد" است. این چیزی است که گم شده بود. اکنون امکان ردیابی تمام تغییرات در تراکنش هایی که برنامه ریزی نشده بودند وجود دارد.
   این مرحله نیاز به تنظیم بسیار دقیق دارد. برای مثال، ما باید حرکت یک سند را در چهار رجیستر ردیابی کنیم و هر کدام از آنها مجموعه فیلدها و تجزیه و تحلیل خاص خود را دارند. مقادیری هستند که با تغییر شی تغییر می کنند و این یک خطا نخواهد بود. به عنوان مثال، فیلدی مانند TimeStamp که زمان پردازش سند را ثبت می کند، یا اگر به طور خودکار به آن اختصاص داده شود، شماره سند را ثبت می کند. تمام چنین لحظاتی هنگام اجرای تست باعث خطا می شود. خوب است که توسعه دهندگان این را در نظر گرفتند و امکان غیرفعال کردن بررسی یک فیلد غیر ثابت را فراهم کردند. تنها کاری که باید انجام دهیم این است که چنین زمینه هایی را پیدا کنیم.
   با این حال، حتی در اینجا نیز برخی از دام ها وجود دارد. به عنوان مثال، به دلایلی در فرم راه اندازی مرحله من، اگر بیش از یک ثبات نمایش داده می شود، سپس حرکات مربوط به آنها نشان داده نمی شود، من باید موارد اضافی را خاموش کنم و هر ثبات را به صورت جداگانه پیکربندی کنم.
   و چیزی که اصلا دوست نداشتم همانطور که من متوجه شدم، فقط حرکاتی که در استاندارد هستند توسط رجیسترها بررسی می شوند. به عنوان مثال، اگر یک تراکنش در استاندارد و سه تراکنش در پایگاه داده آزمایش شده وجود داشته باشد، در طول مقایسه هیچ خطایی وجود نخواهد داشت. زیرا کل رجیستر برای ورودی هایی با پارامترهای مرجع جستجو می شود، اگر همه چیز درست باشد، حضور سایرین مربوط به همان شی ردیابی نمی شود.
3. مراحل تکمیل خودکار فرم ها بر اساس یک اسکریپت همیشه به درستی کار نمی کند. خطاها اغلب در فیلدهای مرجع و تاریخ رخ می دهد. به احتمال زیاد این یک خطای ابزار نیست، بلکه یکی از ویژگی های فیلدها است، اما با این وجود باید تنظیمات آنها را تغییر دهید.
4. گزینه های مرحله ممکن با اشیاء پیکربندی خاص مرتبط هستند. آنچه برای دایرکتوری ها در دسترس است ممکن است برای رجیسترها و غیره در دسترس نباشد. دقیق‌تر است که بگوییم صحافی نه به اشیاء، بلکه به ویژگی‌های آنها است، مثلاً اگر ثبت فرمی نداشته باشد، مرحله‌ای برای پر کردن آن وجود نخواهد داشت.
   اما اشکالاتی نیز وجود دارد، به عنوان مثال، مرحله "دکمه فشار دهید" اغلب برای من در دسترس نیست، یا بهتر است بگوییم، خود انتخاب می تواند انجام شود، اما هیچ اتفاقی نمی افتد.
5. سوالات زیادی در مورد اتوماسیون تست در برخی موارد بخصوص پیچیده باقی مانده است. این امر به ویژه در مورد اسنادی که با باقیمانده‌ها کار می‌کنند صادق است، جایی که تقریباً همه جنبه‌ها نقش مهمی دارند، که اجرای برخی از آنها در اجرای فعلی ابزار بسیار مشکل‌ساز است. تعدادی محدودیت در پیکربندی برای ایجاد اسناد در همان تاریخ، با همان تعداد و غیره وجود دارد. تا کنون من به استفاده از اشیاء موجود بدون ایجاد موارد جدید رضایت داده ام.

این لیست می تواند ادامه پیدا کند، اما اجازه دهید آزمایش کنندگان این محصول این کار را انجام دهند. اصلی‌ترین چیزی که من فهمیدم و سعی می‌کنم آن را منتقل کنم این است که "هیچ رایگانی وجود نخواهد داشت." برای اجرای تست اتوماسیون با این محصول در نقش اصلی، باید بیش از یک روز سخت کار کنید. البته تحلیل من کاملاً ذهنی است و عدم تجربه در استفاده از محصول و ویژگی های پیکربندی نیز ممکن است روی آن تأثیر بگذارد، اما همانطور که می گویند ما آنچه را داریم داریم و راه گریزی از آن نیست.

گزینه های برنامه

من در حال حاضر مفهوم زیر را برای معرفی ابزار مورد نظر در فرآیند تست انتخاب کرده ام.

بر اساس تجربه عملیاتی فعلی، من متقاعد شده‌ام که پایگاه مرجع و پایگاه آزمایشی باید از نظر داده‌ها یکسان باشند. به طور طبیعی، اگر ما در مورد اسکریپت هایی صحبت می کنیم که از اشیاء موجود بدون تغییر استفاده می کنند و موارد جدیدی ایجاد نمی کنند. اولاً، این تعادل یکنواخت را در هر دو پایه به ما می دهد و این برای آزمایش گردش مالی بسیار مهم است. ثانیاً، این یک قابلیت اطمینان خاص و محافظت در برابر خطاهای غیر ضروری را فراهم می کند، زیرا من هنوز به طور کامل ارتباط بین داده های مرجع و پایگاه های داده، پیوندهای مختلف و غیره را درک نکرده ام. من از سوء ظن مبهمی رنج می برم که ممکن است نوعی پیوند وجود داشته باشد که روزی به انبوهی از پیوندهای مرده تبدیل شود که دیگر نمی تواند وجود داشته باشد. گره گشایی

بنابراین، ما یک پایگاه مرجع داریم که بر اساس آن سناریوهایی را برای همه مناسبت ها ایجاد کرده ایم. در برخی از اسناد در پیکربندی توسعه، اصلاحاتی انجام شده است که نیاز به آزمایش دارد. به عنوان یک قاعده - به صورت دستی. پس از آن، پیکربندی با تغییرات در پایگاه داده آزمایشی بارگذاری می‌شود و اسکریپت‌ها برای همه یا فقط اشیاء مجاور اجرا می‌شوند تا بفهمند آیا تغییر در سند روی اشیاء دیگر تأثیر داشته است یا خیر. پس از آن پیکربندی قابل اجرا در نظر گرفته می شود و در پایگاه داده کار نصب می شود. پس از این، اسکریپت تست برای سند اصلاح شده به یک استاندارد جدید از پایگاه داده کار تغییر می کند.

به عبارت دیگر با این سناریوها تست رگرسیون را انجام می دهیم. و این یکی از مهم ترین و دشوارترین روش های اجرای دستی انواع تست در 1C Enterprise است. از این گذشته، اغلب اوقات نه تنها سند تغییر می کند، بلکه، مثلاً، عملکرد ارسال اسناد، که به تمام اسناد سیستم متصل است، و اینجاست که اسکریپت های ما نقش شبکه ای را ایفا می کنند که تمام اسنادی که در آن از کار می افتند خواهد افتاد.

یکی دیگر از کاربردهای خوب می تواند بررسی پایگاه داده کار برای اشکالات تصادفی باشد. برای انجام این کار، یک نسخه پشتیبان از آن گرفته می شود، در پایگاه داده آزمایشی بارگذاری می شود و یک چرخه کامل از تست ها اجرا می شود. خوب است که این روش به صورت خودکار انجام شود، اما تست سناریو 1C امکان اجرای تست ها را بر اساس یک برنامه زمان بندی فراهم نمی کند، حداقل هنوز.

طبیعتاً دامنه کاربرد این ابزار به همین جا ختم نمی شود.

نتیجه.

این ابزار بدون شک آینده ای دارد. به نظر من هنوز قسمت اعظم پتانسیل آن در نسخه های بعدی فاش نشده است و بدون شک این محصول کاربر خود را پیدا خواهد کرد که به نظر من که ظاهراً با نظر سازنده مطابقت ندارد به احتمال زیاد یک کاربر معمولی و بدون دانش خاص در زمینه IT نباشید و فرد از بخش توسعه باشد. زیرا استفاده موثر از این ابزار، به خصوص در پیکربندی های پیچیده، ساده ترین کار نیست.

سلام دوستان!

من پیکربندی کوچکی را برای آزمایش سناریو راه حل های مبتنی بر فرم های مدیریت شده 1C: Enterprise 8.3 به شما جلب می کنم.

پیکربندی تستر نام دارد. تستر محیطی برای توسعه و اجرای تست های سناریو است. تستر یک محصول BDD خالص نیست و برای توصیف رفتار یک سیستم قبل از توسعه آن در نظر گرفته نشده است.

اهداف اصلی تستر:

1. سازماندهی کار جمعی با تست ها در یک محیط واحد با پشتیبانی از نسخه سازی، ضبط برای ویرایش و سایر عملکردهای آشنا برای کار با کد
2. روشی آسان برای ایجاد، پشتیبانی و گسترش تست های سناریو واقعی، در زمان معقول، با حداقل آستانه برای ورود به فرآیند، و زیرساخت قابل اعتماد در اختیار کاربر قرار دهید.

با استفاده از تستر، می توانید روی حل مشکلات زیر حساب کنید:

1. درجه بالایی از پوشش عملکردی. تستر به خوبی روی فرآیند توسعه آزمایش متمرکز است که تأثیر مثبتی بر کمیت و کیفیت تست های ایجاد شده دارد.
2. تست ها به زبان برنامه نویسی 1C نوشته شده اند، که نه تنها یک ابزار آشنا است، بلکه به شما امکان می دهد از کل مجموعه توابع پلتفرم در تست استفاده کنید و مهمتر از همه، به شما امکان می دهد پیشرفت تست را به صورت برنامه نویسی کنترل کنید، بدون اتکا به مدل داخلی در ابزار تست
3. می‌توانید از آزمایش‌ها کتابخانه‌هایی بسازید، به عنوان مثال، می‌توانید آزمایش‌هایی ایجاد کنید که بر اساس پارامترهای پاس شده، پنجره جستجو را در یک لیست پویا باز کنند یا گزارشی تولید کنند. اگر برای آزمون خود نیاز به موجودی در انبار دارید، می توانید یک آزمون کتابخانه ای اجرا کنید که ترکیب موجودی مورد نیاز را به آن منتقل می کنید و این موجودی با حروف بزرگ نوشته می شود.
4. یک آزمون ساده از منطق کسب و کار، بدون مقایسه با داده‌های سایر پایگاه‌های داده، بدون درخواست مستقیم به برنامه تحت آزمایش، بدون طرح‌بندی با داده‌های سریالی «در جای دیگر». تمام اطلاعات را می توان در خود آزمون، در طرح بندی ذخیره کرد و در صورت لزوم اصلاح کرد.
5. علاوه بر این که تمام تست ها در پایگاه داده ذخیره می شوند و هر کاربر تستر می تواند از تستی که توسط برنامه نویس دیگری نوشته شده است استفاده کند، تستر قابلیت آپلود/دانلود تدریجی تست ها را در سیستم فایل دارد. این می تواند برای همگام سازی بیشتر تست ها با سیستم های کنترل نسخه، مانند Git مفید باشد.

پایگاه آزمایشی زیرساخت کوچکی از تست‌های به هم پیوسته را توسعه داده است که می‌تواند هنگام توسعه آزمایش‌های خود مورد استفاده قرار گیرد. همچنین در پایگاه داده نمونه ای از ایجاد سفارش به سند تامین کننده برای ERP2 (دمو) وجود دارد.

برای پیکربندی ERP2 (دمو)، یک مخزن ایجاد شد https://github.com/grumagargler/ERP2
تست های دمو را آنجا آپلود کردم. امیدوارم این ابتکار مورد توجه علاقه مندان قرار نگیرد و تست های بیشتری اضافه شود.

جامع ترین اطلاعات مربوط به تستر را در راهنما پیدا خواهید کرد، هنگامی که سیستم شروع به کار کرد روی دسکتاپ قرار خواهد گرفت. یک بخش شروع سریع در راهنما وجود دارد، توصیه می کنم با آن آشنا شوید.

تستر رایگان است. بدون هیچ انگیزه تجاری برای نیازهای خودمان توسعه و پشتیبانی می شود.

با تشکر از توجه شما به سیستم و موفق باشید در آزمون های شما دوستان!

به روز رسانی 1.3.2.7

رویه LogError اضافه شد، برای افزودن پیام‌ها به گزارش خطا از کد اسکریپت بدون توقف اجرای اسکریپت به‌صورت برنامه‌نویسی استفاده می‌شود.

همه توابع برای کار با فیلدها اکنون می توانند در قسمت جدولی حرکت کنند، به عنوان مثال، به این ترتیب می توانید مقدار تعهدی را در خط پنجم بررسی کنید: بررسی کنید ("#Accruals / Result [ 5 ]", 1000);

تابع Check سعی می کند مقادیر عددی را بدون در نظر گرفتن جداکننده سه گانه و قسمت اعشاری بررسی کند.

گزارش راه اندازی اضافه شد، جایی که رویدادهای اجرای اسکریپت ثبت می شوند

انتقال از اسکریپت به گزارش راه اندازی و ثبت خطا اضافه شد

دستیار به درخت انتخاب فیلد اضافه شد

راهنمای آنلاین در مورد روش های آزمایش کننده داخلی به دستیار اضافه شده است.

نسخه های برنامه اضافه شد. نسخه ها را می توان هم برای برنامه به طور کلی و هم به طور جداگانه برای هر کاربر تنظیم کرد

گزارش‌های اضافه شده: پروتکل، خلاصه (گزارش‌ها فقط برای اسکریپت‌های تازه راه‌اندازی شده در این نسخه کار می‌کنند). امکان پیکربندی یک برنامه زمانبندی برای ارسال گزارش از طریق پست وجود دارد (RLS کاربران هنگام تولید گزارش در نظر گرفته می شود)

گزارش‌ها به‌عنوان حقوق جداگانه پیاده‌سازی می‌شوند تا آن‌ها را به کاربران غیر سرپرست اضافه کنید، باید تنظیمات مناسب را در نمایه‌های آن‌ها انجام دهید

بهینه سازی آپلود اسکریپت ها در فایل ها. فایل های آپلود شده با فرمت bsl تولید می شوند

ترتیب انتقال:

پس از به روز رسانی پیکربندی، قبل از اجرای اسکریپت ها، توصیه می شود نسخه های آنها را برای راه حل های خود مشخص کنید. این کار در دایرکتوری Application انجام می شود.

توجه! پیکربندی بر اساس نسخه 8.3.10 است، اما نسخه های قبلی نیز پشتیبانی می شوند. برای انجام این کار، باید حالت سازگاری مورد نیاز برای پیکربندی را در نسخه 8.3.10 تنظیم کنید، پیکربندی را در یک فایل ذخیره کنید و از آن به عنوان به روز رسانی استفاده کنید.

کارت راه حل 1C: تست سناریو 8

این یک جعبه ابزار برای بررسی عملکرد هر پیکربندی سیستم 1C: Enterprise 8 است. این محصول به شما این امکان را می دهد که تست های لازم را تهیه کرده و به صورت دستی یا خودکار انجام دهید. برای توسعه آزمایشات با استفاده از 1C: تست سناریو 8، درک عملکرد پیکربندی در حال آزمایش در سطح کاربر کافی نیست.

خرید 1C: تست سناریو 8

4601546061393

42 000

صدور مجوز 1C: تست سناریو 8

محصول "1C: تست سناریو 8" برای استفاده در نظر گرفته شده است مجوزهای مشتری "1C: Enterprise 8"، افزایش تعداد مشاغل بسته تحویل محصول شامل یک کیت توزیع، کتاب "1C: تست سناریو 8. راهنمای کاربر" و یک قرارداد مجوز است.

برای استفاده از محصول، باید هرگونه تحویل اولیه (نسخه PROF) سیستم 1C:Enterprise 8 را داشته باشید. از شبکه محلی سازمان، ارائه شده با مجوز مشتری 1C: Enterprises 8. 1C: تست سناریو 8 شامل تحویل 1C: جعبه ابزار شرکتی 8

پشتیبانی و به روز رسانی 1C: تست سناریو 8

پشتیبانی و خدمات برای کاربران ثبت نام شده در چارچوب پشتیبانی فناوری اطلاعات (1C:ITS) - 1C:ITS Techno یا 1C:ITS Prof. مدت زمان اشتراک رایگان هنگام خرید برنامه 3 ماه است. پس از انقضای اشتراک رایگان، برای دریافت خدمات پشتیبانی محصول، باید برای اشتراک پولی در هر تحویل اولیه سیستم 1C:Enterprise 8 ثبت نام کنید.

کاربران ثبت نام شده می توانند به روز رسانی ها را از وب سایت users.v8.1c.ru و از دیسک ITS دانلود کنند.

عملکرد 1C: تست سناریو 8

تست مجموعه ای از اقداماتی است که کاربر باید در یک برنامه انجام دهد. اینها می تواند اقداماتی باشد، برای مثال، ایجاد عناصر جدید دایرکتوری ها، اسناد، پر کردن داده ها در یک فرم، یا فشار دادن دکمه ها. هنگامی که چنین آزمایشی به طور خودکار انجام می شود، ورودی کاربر شبیه سازی می شود. مهم است که اجرای دستورات آزمایشی برای ایجاد تعاملی اشیا و پر کردن فرم ها توسط پلت فرم 1C:Enterprise 8 به همان روشی پردازش شود که کاربر این داده ها را از صفحه کلید وارد کرده است.

یک اصل آزمایش مشابه در برنامه های دیگر وجود دارد، اما، بر خلاف آنها، 1C: Scenario Testing 8 قابلیت های توسعه آزمایشی را پیاده سازی می کند که منعکس کننده ویژگی های آزمایش 1C: این قابلیت ها هستند:

• ایجاد قالب هایی برای پر کردن فرم ها برای اشیاء پیکربندی مختلف (می توان آنها را سفارشی کرد و برای آزمایش های مختلف از همان پیکربندی استفاده کرد).
• تجزیه و تحلیل ارتباط بین اشیاء پایه پیکربندی مرجع و مراحل آزمایش؛
• تجزیه و تحلیل صحت آزمون ثبت شده قبل از اجرای آن؛
• امکان دور زدن دستی یک خطای شناسایی شده هنگام اجرای آزمایش خودکار و ادامه اجرای آزمایش در حالت خودکار.
• مقایسه خودکار حرکات سند با داده های پایگاه داده مرجع.
• مقایسه ضروری اشیاء ایجاد شده توسط آزمون با داده های پایگاه داده مرجع.
• امکان اشکال زدایی مراحل هنگام ضبط تست؛
• تجزیه و تحلیل پوشش آزمایشی اشیاء پیکربندی

برای انجام آزمایش، هیچ آماده سازی خاصی برای پیکربندی مورد آزمایش لازم نیست.

در همان تست، می توانید مراحلی را برای آزمایش تراکنش های مختلف تجاری ایجاد کنید. منطق آزمون با قوانین انعکاس معاملات تجاری در برنامه مطابق با مستندات کاربر توضیح داده شده است. بنابراین، ابزار را می توان برای سناریو یا تست عملکردی تنظیمات استفاده کرد.

نیاز به چنین آزمایشی زمانی ایجاد می شود که لازم است مطمئن شویم که هنگام اصلاح عملکرد پیکربندی یا تصحیح خطاها، عملکرد عملکرد پیکربندی که بدون تغییر باقی می ماند حفظ می شود. این در سازمان هایی که توسعه نسخه های پیکربندی جدید، آزمایش و انتشار آنها تکراری است بیشتر مورد تقاضا است. در این حالت، هزینه‌های نوشتن تست‌ها و اجرای خودکار بیشتر آن‌ها کمتر از آزمایش رگرسیون دستی هر نسخه پیکربندی جدید خواهد بود.

به عنوان یک قاعده، آزمایش‌ها برای پرکاربردترین سناریوهای کار واقعی با یک راه‌حل کاربردی نوشته می‌شوند و در هر نسخه جدید از یک پیکربندی یا پلتفرم اصلاح‌شده اجرا می‌شوند. بسته به بحرانی بودن خطاها در یک عملکرد خاص راه حل کاربردی و بسته به مدت زمانی که سازمان مایل است برای آزمایش صرف کند، آزمایش ها را می توان کم و بیش پیچیده کرد.

جعبه ابزار 1C:Scenario testing 8 شامل دو پردازش خارجی است (یک پردازش برای ضبط تست در نظر گرفته شده است، دومی برای اجرای آن) و همچنین مجموعه ای از تست ها (فایل ها با فرمت xml) برای پیکربندی های معمولی 1C:Enterprise 8.

می تواند به کار رود:

• شرکا - توسعه دهندگان راه حل های گردش خون،
• شرکا یا کاربرانی که وظیفه آزمایش پیکربندی قبل از به روز رسانی پایگاه داده کار را دارند.