स्टेटिक परीक्षण या निजी रयान को बचाने के लिए

एक रिलीज अक्सर किसी का ध्यान नहीं जाता है। और कोई भी गलती जो अचानक उसके सामने आई थी, वह हमें डेडलाइन, हॉटफ़िक्स में बदलाव के लिए धमकी देती है, सुबह तक काम करती है और नसों को खर्च करती है। जब इस तरह की भीड़ व्यवस्थित रूप से होने लगी, तो हमने महसूस किया कि आप अब उस तरह नहीं रह सकते। साधारण रयान डेवलपर एर्टोम को बचाने के लिए एक व्यापक सत्यापन प्रणाली विकसित करने का निर्णय लिया गया था, जो 9 बजे, या 10 बजे या 11 बजे रिलीज होने से पहले घर चला गया था। ठीक है, आप समझते हैं। डेवलपर को त्रुटि के बारे में पता लगाने के लिए विचार किया गया था, जबकि परिवर्तन अभी तक रिपॉजिटरी तक नहीं पहुंचे थे, और वह स्वयं कार्य के संदर्भ में नहीं खोया था।


आज, किए गए परिवर्तनों को स्थानीय स्तर पर पहले ध्यान से जांचा जाता है, और फिर विधानसभा खेत पर एकीकरण परीक्षणों की एक श्रृंखला के साथ। इस लेख में, हम सत्यापन के पहले चरण के बारे में बात करेंगे - स्थैतिक परीक्षण, जो संसाधनों की शुद्धता की निगरानी करता है और कोड का विश्लेषण करता है। यह श्रृंखला का पहला सबसिस्टम है और इसमें पाई जाने वाली त्रुटियों का बड़ा हिस्सा है।

यह सब कैसे शुरू हुआ

रिलीज से पहले खेल की जांच की मैनुअल प्रक्रिया QA में रिलीज से एक हफ्ते पहले शुरू हुई। स्वाभाविक रूप से, कीड़े जो इस स्तर पर हैं उन्हें जल्द से जल्द ठीक करने की आवश्यकता है।

एक अच्छे समाधान के लिए समय की कमी के कारण, एक अस्थायी "बैसाखी" जोड़ा जाता है, जो फिर लंबे समय तक जड़ लेता है और अन्य बहुत लोकप्रिय समाधानों से घिरा होता है।

सबसे पहले, हमने ओवरट गलतियों की खोज को स्वचालित करने का फैसला किया: क्रैश, खेल के लिए कार्यों के मुख्य सेट को पूरा करने में असमर्थता (एक स्टोर खोलें, खरीदारी करें, एक स्तर खेलें)। ऐसा करने के लिए, खेल एक विशेष ऑटोगेम मोड में शुरू होता है और अगर कुछ गलत हुआ, तो हम अपने खेत पर परीक्षण पास करने के तुरंत बाद इसके बारे में जानेंगे।

लेकिन अधिकांश त्रुटियां जो परीक्षक और हमारे स्वचालित धुएं परीक्षण दोनों में पाई गईं, वे विभिन्न प्रणालियों के संसाधन या गलत सेटिंग्स की कमी थीं। इसलिए, अगला चरण स्थैतिक परीक्षण था - आवेदन को लॉन्च किए बिना संसाधनों की उपलब्धता, उनके संबंधों और सेटिंग्स की जांच करना। इस प्रणाली को असेंबली फ़ार्म पर एक अतिरिक्त कदम द्वारा लॉन्च किया गया था और त्रुटियों की खोज और निर्धारण को बहुत सरल किया गया था। लेकिन विधानसभा खेत के संसाधनों को बर्बाद क्यों करें यदि आप समस्या को कम करने और भंडार में रखने से पहले भी एक त्रुटि का पता लगा सकते हैं? यह प्रीकोमाइट हुक के साथ किया जा सकता है , जो कि कमिट बनाने से पहले और रिपॉजिटरी को भेजे जाने से पहले शुरू किया जाता है।

और हाँ, हम इतने शांत हैं कि कमिटमेंट से पहले और असेंबली फ़ार्म पर एक-एक कोड का परीक्षण किया जाता है, जो इसके समर्थन को बहुत सरल करता है।

हमारे प्रयासों को तीन क्षेत्रों में विभाजित किया जा सकता है:

• एक विधानसभा फार्म का निर्माण - बहुत जगह जहां सब कुछ एकत्र किया गया है और जांच की जाएगी;
• स्थैतिक परीक्षणों का विकास - संसाधनों की शुद्धता, उनके संबंधों की जाँच करना, कोड एनालाइज़र लॉन्च करना;
• रनटाइम टेस्ट का विकास - एप्लिकेशन को ऑटो-प्ले मोड में लॉन्च करना।

एक अलग कार्य डेवलपर द्वारा मशीन पर परीक्षणों के प्रक्षेपण को व्यवस्थित करना था। निष्पादन समय को स्थानीय रूप से कम करना आवश्यक था (डेवलपर को एक पंक्ति बनाने के लिए 10 मिनट इंतजार करने की आवश्यकता नहीं है) और सुनिश्चित करें कि परिवर्तन करने वाले प्रत्येक सिस्टम में हमारी प्रणाली स्थापित है।

कई आवश्यकताएँ - एक प्रणाली

विकास के दौरान, असेंबली का एक पूरा सेट है जो काम में आ सकता है: धोखा या बीटा या अल्फा, आईओएस या एंड्रॉइड के बिना। प्रत्येक मामले में, विभिन्न संसाधनों, सेटिंग्स, या यहां तक ​​कि अलग कोड की आवश्यकता हो सकती है। कई मापदंडों के साथ जटिल प्रणाली में प्रत्येक संभावित विधानसभा परिणामों के लिए स्थैतिक परीक्षणों के लिए स्क्रिप्ट लिखना। बनाए रखने और संशोधित करने में मुश्किल होने के अलावा, प्रत्येक परियोजना में बैसाखी बाइक का अपना सेट भी होता है।

परीक्षण और त्रुटि के माध्यम से, हम एक प्रणाली में आए, प्रत्येक परीक्षण जिसमें लॉन्च संदर्भ को ध्यान में रखा जा सकता है और यह तय कर सकता है कि इसे चलाना है या नहीं, क्या जांचना है। परीक्षण रन में, हमने तीन मुख्य गुणों की पहचान की:

• विधानसभा का प्रकार: संसाधनों की रिहाई और डिबगिंग के लिए, जाँच कठोरता, कवरेज की पूर्णता, साथ ही पहचानकर्ताओं के लिए सेटिंग्स और उपलब्ध कार्यक्षमता के सत्यापन के मामले में भिन्न होगी;
• प्लेटफ़ॉर्म: जो Android के लिए मान्य है वह iOS के लिए गलत हो सकता है, संसाधनों को भी अलग तरह से एकत्र किया जाता है और एंड्रॉइड संस्करण में सभी संसाधन आईओएस में नहीं होंगे और इसके विपरीत;
• लॉन्च स्थान: जहां हम बिल्कुल लॉन्च कर रहे हैं - बिल्ड एजेंट पर जहां सभी उपलब्ध परीक्षण आवश्यक हैं या उपयोगकर्ता के कंप्यूटर पर जहां स्टार्टअप की सूची को कम से कम करने की आवश्यकता है।

स्थैतिक परीक्षण प्रणाली

सिस्टम का मूल और स्थैतिक परीक्षणों का मूल सेट अजगर में लागू किया गया है। आधार केवल कुछ संस्थाएँ हैं:


परीक्षण संदर्भ एक व्यापक अवधारणा है। यह बिल्ड और लॉन्च दोनों मापदंडों को संग्रहीत करता है, जिसके बारे में हमने ऊपर बात की थी, साथ ही मेटा-जानकारी भी दी थी कि परीक्षण भरते हैं और उपयोग करते हैं।

पहले आपको यह समझने की आवश्यकता है कि कौन से परीक्षण चलाने हैं। इसके लिए, मेटा-सूचना में उन संसाधनों के प्रकार होते हैं जिनकी हम विशेष रूप से इस लॉन्च में रुचि रखते हैं। संसाधन प्रकार सिस्टम में पंजीकृत परीक्षणों द्वारा निर्धारित किए जाते हैं। एक परीक्षण एक प्रकार या कई के साथ "संबद्ध" हो सकता है, और यदि, प्रतिबद्ध होने के समय, यह पता चलता है कि इस परीक्षण की जाँच करने वाली फाइलें बदल गई हैं, तो संबंधित संसाधन बदल गया है। यह सुविधाजनक रूप से हमारी विचारधारा में फिट बैठता है - स्थानीय रूप से संभव के रूप में कुछ जांचें चलाने के लिए: यदि वे फ़ाइलें जिनके लिए परीक्षण जिम्मेदार है, वे नहीं बदले गए हैं, तो आपको इसे चलाने की आवश्यकता नहीं है।

उदाहरण के लिए, मछली का विवरण है, जिसमें 3 डी मॉडल और बनावट का संकेत दिया गया है। यदि विवरण फ़ाइल बदल गई है, तो यह जांच की जाती है कि मॉडल और बनावट का संकेत मौजूद है। अन्य मामलों में, मछली की जांच चलाने की आवश्यकता नहीं है।

दूसरी ओर, एक संसाधन को बदलने के लिए इसके आधार पर परिवर्तन और संस्थाओं की आवश्यकता हो सकती है: यदि बनावट का सेट जिसे हम xml फ़ाइलों में संग्रहीत करते हैं, बदल गया है, तो अतिरिक्त 3 डी मॉडल की जांच करना आवश्यक है, क्योंकि यह पता लगा सकता है कि आपके द्वारा आवश्यक बनावट हटा दी गई है। ऊपर वर्णित अनुकूलन को केवल उस समय उपयोगकर्ता की मशीन पर स्थानीय रूप से लागू किया जाता है, और जब विधानसभा खेत में लॉन्च किया जाता है, तो यह माना जाता है कि सभी फाइलें बदल गई हैं और हम सभी परीक्षण चलाते हैं।

अगली समस्या दूसरों पर कुछ परीक्षणों की निर्भरता है: सभी बनावट और मॉडल खोजने से पहले मछली की जांच करना असंभव है। इसलिए, हमने सभी निष्पादन को दो चरणों में विभाजित किया:

• संदर्भ तैयारी
• निरीक्षण प्रदर्शन

पहले चरण में, संदर्भ संसाधनों (मछली के मामले में, पैटर्न और बनावट के पहचानकर्ताओं के साथ) के बारे में जानकारी से भरा हुआ है। दूसरे चरण में, संग्रहीत जानकारी का उपयोग करके, बस यह जांचें कि वांछित संसाधन मौजूद है या नहीं। एक सरलीकृत संदर्भ नीचे प्रस्तुत किया गया है।

class VerificationContext(object):   def __init__(self, app_path, build_type, platform, changed_files=None):       self.__app_path = app_path       self.__build_type = build_type       self.__platform = platform       #          self.__modified_resources = set()       self.__expected_resources = set()       #      ,              self.__changed_files = changed_files       # -  ,          self.__resources = {} def expect_resources(self, resources):   self.__expected_resources.update(resources) def is_resource_expected(self, resource):   return resource in self.__expected_resources def register_resource(self, resource_type, resource_id, resource_data=None):   self.__resources.setdefault(resource_type, {})[resource_id] = resource_data def get_resource(self, resource_type, resource_id):   if resource_type not in self.__resources or resource_id not in self.__resources[resource_type]:       return None, None   return resource_id, self.__resources[resource_type][resource_id] 

परीक्षण के लॉन्च को प्रभावित करने वाले सभी मापदंडों को निर्धारित करने के बाद, हम बेस क्लास के अंदर सभी तर्क को छिपाने में कामयाब रहे। एक विशिष्ट परीक्षण में, यह केवल परीक्षण ही लिखने के लिए रहता है और मापदंडों के लिए आवश्यक मान।

 class TestCase(object):  def __init__(self, name, context, build_types=None, platforms=None, predicate=None,               expected_resources=None, modified_resources=None):      self.__name = name      self.__context = context      self.__build_types = build_types      self.__platforms = platforms      self.__predicate = predicate      self.__expected_resources = expected_resources      self.__modified_resources = modified_resources      #               #   ,          self.__need_run = self.__check_run()      self.__need_resource_run = False  @property  def context(self):      return self.__context  def fail(self, message):      print('Fail: {}'.format(message))  def __check_run(self):      build_success = self.__build_types is None or self.__context.build_type in self.__build_types      platform_success = self.__platforms is None or self.__context.platform in self.__platforms      hook_success = build_success      if build_success and self.__context.is_build('hook') and self.__predicate:          hook_success = any(self.__predicate(changed_file) for changed_file in self.__context.changed_files)      return build_success and platform_success and hook_success  def __set_context_resources(self):      if not self.__need_run:          return      if self.__modified_resources:          self.__context.modify_resources(self.__modified_resources)      if self.__expected_resources:          self.__context.expect_resources(self.__expected_resources)   def init(self):      """        ,                    ,          """      self.__need_resource_run = self.__modified_resources and any(self.__context.is_resource_expected(resource) for resource in self.__modified_resources)  def _prepare_impl(self):      pass  def prepare(self):      if not self.__need_run and not self.__need_resource_run:          return      self._prepare_impl()  def _run_impl(self):      pass  def run(self):      if self.__need_run:          self._run_impl() 

मछली के उदाहरण पर लौटते हुए, हमें दो परीक्षणों की आवश्यकता होती है, जिनमें से एक बनावट को ढूंढता है और उन्हें संदर्भ में पंजीकृत करता है, अन्य पाया गया मॉडल के लिए बनावट की खोज करता है।

 class VerifyTexture(TestCase):  def __init__(self, context):      super(VerifyTexture, self).__init__('VerifyTexture', context,                                          build_types=['production', 'hook'],                                          platforms=['windows', 'ios'],                                          expected_resources=None,                                          modified_resources=['Texture'],                                          predicate=lambda file_path: os.path.splitext(file_path)[1] == '.png')  def _prepare_impl(self):      texture_dir = os.path.join(self.context.app_path, 'resources', 'textures')      for root, dirs, files in os.walk(texture_dir):          for tex_file in files:              self.context.register_resource('Texture', tex_file) class VerifyModels(TestCase):  def __init__(self, context):      super(VerifyModels, self).__init__('VerifyModels', context,                                         expected_resources=['Texture'],                                         predicate=lambda file_path: os.path.splitext(file_path)[1] == '.obj')  def _run_impl(self):      models_descriptions = etree.parse(os.path.join(self.context.app_path, 'resources', 'models.xml'))      for model_xml in models_descriptions.findall('.//Model'):          texture_id = model_xml.get('texture')          texture = self.context.get_resource('Texture', texture_id)          if texture is None:              self.fail('Texture for model {} was not found: {}'.format(model_xml.get('id'), texture_id)) 

प्रोजेक्ट स्प्रेड

Playrix में गेम का विकास अपने स्वयं के इंजन पर होता है और, तदनुसार, सभी परियोजनाओं में समान नियमों का उपयोग करके एक समान फ़ाइल संरचना और कोड होता है। इसलिए, कई सामान्य परीक्षण हैं जो एक बार लिखे गए हैं और सामान्य कोड में हैं। यह परीक्षण प्रणाली के संस्करण को अद्यतन करने और खुद को एक नया परीक्षण जोड़ने के लिए परियोजनाओं के लिए पर्याप्त है।

एकीकरण को आसान बनाने के लिए, हमने एक धावक लिखा है जो कॉन्फ़िगरेशन फ़ाइल और डिज़ाइन परीक्षण (उनके बारे में बाद में) प्राप्त करता है। कॉन्फ़िगरेशन फ़ाइल में बुनियादी जानकारी होती है जिसके बारे में हमने ऊपर लिखा था: विधानसभा का प्रकार, प्लेटफ़ॉर्म, परियोजना का पथ।

 class Runner(object):  def __init__(self, config_str, setup_function):      self.__tests = []      config_parser = RawConfigParser()      config_parser.read_string(config_str)      app_path = config_parser.get('main', 'app_path')      build_type = config_parser.get('main', 'build_type')      platform = config_parser.get('main', 'platform')      '''      get_changed_files         CVS      '''      changed_files = None if build_type != 'hook' else get_changed_files()      self.__context = VerificationContext(app_path, build_type, platform, changed_files)      setup_function(self)  @property  def context(self):      return self.__context  def add_test(self, test):      self.__tests.append(test)  def run(self):      for test in self.__tests:          test.init()      for test in self.__tests:          test.prepare()      for test in self.__tests:          test.run() 

कॉन्फिग फाइल की खूबी यह है कि इसे असेंबली फार्म पर अलग-अलग असेंबली में ऑटोमैटिक मोड में जेनरेट किया जा सकता है। लेकिन इस फ़ाइल के माध्यम से सभी परीक्षणों के लिए पासिंग सेटिंग्स बहुत सुविधाजनक नहीं हो सकती हैं। ऐसा करने के लिए, एक विशेष कॉन्फ़िगरेशन xml है जिसे प्रोजेक्ट रिपॉजिटरी में संग्रहीत किया जाता है और अनदेखा फ़ाइलों की सूची, कोड में खोज के लिए मास्क, और इसी तरह इसमें लिखा जाता है।



सामान्य भाग के अलावा, परियोजनाओं की अपनी ख़ासियतें और अंतर हैं; इसलिए, परियोजना परीक्षणों के सेट हैं जो धावक के कॉन्फ़िगरेशन के माध्यम से सिस्टम से जुड़े हैं। उदाहरणों में कोड के लिए, कुछ पंक्तियाँ चलाने के लिए पर्याप्त होंगी:

 def setup(runner):  runner.add_test(VerifyTexture(runner.context))  runner.add_test(VerifyModels(runner.context)) def run():  raw_config = '''  [main]  app_path = {app_path}  build_type = production  platform = ios  '''  runner = Runner(raw_config, setup)  runner.run() 

एकत्रित रेक

हालाँकि अजगर अपने आप में क्रॉस-प्लेटफ़ॉर्म है, लेकिन हमें नियमित रूप से इस बात की समस्या थी कि उपयोगकर्ताओं के पास अपना विशिष्ट वातावरण हो, जिसमें उनके पास वह संस्करण न हो जिसकी हम अपेक्षा करते हैं, कई संस्करण, या कोई दुभाषिया बिल्कुल नहीं। नतीजतन, यह काम नहीं करता है जैसा कि हम उम्मीद करते हैं या बिल्कुल भी काम नहीं करते हैं। इस समस्या को हल करने के लिए कई पुनरावृत्तियों थे:

1. पायथन और सभी पैकेज उपयोगकर्ता द्वारा स्थापित किए जाते हैं। लेकिन दो "बट्स" हैं: सभी उपयोगकर्ता प्रोग्रामर नहीं हैं और डिजाइनरों के लिए पाइप इंस्टॉल के माध्यम से स्थापित कर रहे हैं, और प्रोग्रामर के लिए भी, एक समस्या हो सकती है।
2. एक स्क्रिप्ट है जो सभी आवश्यक पैकेजों को स्थापित करती है। यह पहले से बेहतर है, लेकिन यदि उपयोगकर्ता के पास गलत अजगर स्थापित है, तो काम में संघर्ष हो सकता है।
3. आर्टिफिशियल स्टोरेज (नेक्सस) से दुभाषिया और निर्भरता के सही संस्करण को वितरित करना और एक आभासी वातावरण में परीक्षण चलाना।

एक और मुद्दा प्रदर्शन है। जितने अधिक परीक्षण, उपयोगकर्ता के कंप्यूटर पर परिवर्तन की जाँच की जाती है। हर कुछ महीनों में अड़चनों की रूपरेखा और अनुकूलन होता है। इसलिए संदर्भ में सुधार किया गया था, पाठ फ़ाइलों के लिए एक कैश दिखाई दिया, विधेय तंत्र में सुधार हुआ (यह निर्धारित करना कि यह फ़ाइल परीक्षण के लिए दिलचस्प है)।

और फिर यह केवल इस समस्या को हल करने के लिए बनी हुई है कि सभी परियोजनाओं पर सिस्टम को कैसे लागू किया जाए और सभी डेवलपर्स को पूर्व स्वामित्व वाले हुक को शामिल करने के लिए मजबूर किया जाए, लेकिन यह पूरी तरह से अलग कहानी है ...

निष्कर्ष

विकास प्रक्रिया के दौरान, हमने रेक पर नृत्य किया, कड़ा संघर्ष किया, लेकिन फिर भी एक प्रणाली मिली जिसने हमें प्रतिबद्धताओं के दौरान त्रुटियों को खोजने की अनुमति दी, परीक्षकों के काम को कम कर दिया, और बनावट के लापता होने के बारे में रिलीज से पहले के कार्य अतीत की बात थे। संपूर्ण खुशी के लिए, पर्यावरण का एक सरल सेटअप और व्यक्तिगत परीक्षणों का अनुकूलन पर्याप्त नहीं है, लेकिन सीआई विभाग के golems इस पर कड़ी मेहनत करते हैं।

लेख में उदाहरण के रूप में उपयोग किए गए कोड का एक पूरा उदाहरण हमारे भंडार में पाया जा सकता है ।