simple approach xml database testing
Bu makale, XML'in anlaşılmasına yardımcı olacaktır. Veritabanı test konsepti zorlayıcı olan test tipi .
Veri karşılaştırması, kalite ile başarılması gereken kritik bir görevdir. Herhangi bir kusur, bir uygulamada bir veya daha fazla başarısızlıkla sonuçlanacaktır.
XML, verileri içeren bir elektronik iletişim mesajı formatıdır ve Veritabanı, veri içeren tablolar / sütunlar içeren fiziksel bir depolamadır.
Çoğu uygulama birbiriyle veri alışverişi yapar. Bu iletişimler, veri içeren XML mesajları biçiminde olabilir. Ayrıca bu veriler bir veritabanı sisteminde saklanmakta ve gerektiğinde veriler uygulamalar tarafından alınmaktadır.
Ayrıca oku => XML Teknolojilerini Kullanarak Mükemmel Bir Veri Testi Yolu
Finans, pazarlama, satış, e-ticaret, otomobil, lojistik ve üretim gibi alanların çoğu, uygulamalarla veri iletişimi için bu tekniği kullanır.
XML'den Veritabanına testini başarılı kılmak için en önemli girdi, eşleme belgesi veritabanındaki sütunlara karşı XML'deki her bir öğeyi tanımlar.
Eşleştirme belgesi, öğelerin (XML) sütun (DB) ilişkisine tam bir temsilini sağlayacaktır. XML öğe değerleri, DB tablolarına bir girdi olabilir veya bunun tersi de olabilir.
php mülakat soruları ve cevapları pdf
Bu makale ile, veri doğruluğu için XML mesaj verilerinin Veritabanı verilerine nasıl test edileceğini iyi anlayacaksınız.
Ne öğreneceksin:
- XML ve Veritabanı hakkında konuşalım:
- Uygulama Mimarisi:
- Misal:
- Nasıl test edilir:
- Gerçek hayat örneği:
- Başarısızlık senaryoları:
- Sonuç:
- Önerilen Kaynaklar
XML ve Veritabanı hakkında konuşalım:
Uygulamalar birbirleriyle iletişim kurmak için farklı teknikler kullanır. XML kullanarak mesaj iletişimi bunlardan biridir. XML, iki uygulama arasında mesajları (Veri) iletmek için güvenilir bir tekniktir. XML, belirli değerlere sahip bir dizi öğe içerir. Bazen değerler NULL veya boş olabilir.
Veritabanı, verileri tablolar şeklinde depolar. Bir veritabanı birkaç tablo içerir. Bir uygulama bir veritabanındaki tabloya veri besleyebilir ve ayrıca tablo verileri gerektiğinde uygulamalar tarafından alınabilir.
Artık uygulamalar, veritabanı tablolarından verileri XML biçiminde depolayabilir / alabilir ve bunu yapmak oldukça güvenilir / esnek bir tekniktir.
Uygulama Mimarisi:
Bir test uzmanı olarak aşağıdakiler önemlidir:
- Uygulamaların modüller / veritabanları arasında mesajları nasıl ilettiğini anlamak için Ürün Mimarisini gözden geçirin / Bu bilgileri gözden geçirip herhangi bir tutarsızlık / soru olduğunu bulduğunuzda, açıklamalar için BA / SA'ya ulaşabilirsiniz.
- Yukarı ve aşağı uygulama veri akışlarını anlayın.
- Bir uygulamaya gelen ve giden veri akışı.
Bazı durumlarda, yukarı akış ve aşağı akış uygulamaları, farklı uygulamaların veritabanları olabilir ve Depolanan Prosedürleri, Web hizmetlerini, API'leri vb. Kullanarak XML biçiminde veri iletir / iletir. birbirleriyle.
Misal:
Bu XML'den Veritabanına test makalesi için, verileri depolamak üzere bir veritabanıyla iletişim kuran bir uygulamayı ele alalım.
Aşağı yönde bir uygulamamız var IBAPX , mesajları XML biçiminde bir veritabanı uygulamasına ileten MYDBX . Yukarı yönde bir uygulamamız var OBAPX , verileri alan MYDBX raporlama uygulaması için RPTX ve yukarı akış uygulamasıdır OBAPX .
Not: Başlamadan önce, ara katman yazılımı iletişimi için kullanılan teknolojiyi (Depolanan Prosedür, Web Hizmeti, API, vb.) Öğrenin ve mimariyi net bir şekilde öğrenin. Bu bilgiler genellikle tasarım belgesinde veya SA / BA / Dev ekipleriyle birlikte bulunur.
Şimdi uygulama IBAPX, veri tabanı uygulaması MYDBX'te veri depoluyor. Tablonun sütununa hangi xml elemanının eşlendiğini bilmek için, eşleme belgesi . Bazen XML öğeleri ve sütun adları aynı olabilir veya olmayabilir. Fark, bir iş ihtiyacından kaynaklanmaktadır.
Örneğin . Diyelim ki IBAPX şu adla öğe gönderiyor: satış sipariş numarası , ancak MYDBX bir tabloda aynı öğe değerini depoladığında, p_orderid sütun adı. Bu, XML öğesine satışla ilgili varlık olarak atıfta bulunulmasından kaynaklanıyor olabilir, aynı değer tabloda saklandığında sütun adı üretim kullanımına atıfta bulunmak için değiştirilmiş olabilir. Bu, iş ihtiyacına göre diğer uygulamalarda değişebilir.
Nasıl test edilir:
Şimdi bir test uzmanı tüm senaryoları etkili ve verimli bir şekilde nasıl test edebilir? Hadi tartışalım.
Öncelikle giriş XML dosyasını alırsınız ve XML yapısını doğrulayın yani öğeler. Bu, ilgili XML'in yapısını tanımlayan XSD yardımıyla yapılabilir.
XSD dosyası XML gibi görünür ve öğe adı, öğe türü, minOccurs, maxOccurs, vb. Gibi XML'nin yapısını tanımlar. XML doğrulaması tamamlandıktan sonra, onu excel'e dışa aktarın. Xml dosyasını yeni bir excel sayfasına sürüklemeniz yeterlidir. Dosyayı nasıl açmak istediğinizi soran bir açılır pencere verecektir, sadece 'XML tablosu olarak' seçeneğini seçin. Veriler excel dosyasına tablo olarak kaydedilir.
Tabloya doldurulmuş verileri görebilir, belirli verilerle tabloyu sorgulayabilir ve kaydı getirebilirsiniz. Verileri aynı excel dosyasına başka bir sayfaya kopyalayın. Şimdi excel'de EXACT işlevini kullanarak XML verileri ile DB verilerini kolayca karşılaştırabilirsiniz. Sütun adlarını değil, yalnızca verileri karşılaştırdığınızdan emin olun.
Bu şekilde birden fazla kayıt verisini karşılaştırabilir ve çok fazla manuel çaba tasarrufu sağlayabilir XML öğesi veri değerlerini DB sütun veri değerleriyle karşılaştırmak için.
Referans için aşağıdaki eki bulun:
Not: Yukarıdaki görselde, sütun adlarının daha önce tartıştığımız gibi eşleşmediğini görebilirsiniz.
İpucu: Bazen büyük boyutlu XML ile DB'yi karşılaştırırken bir sorunla karşılaşabilirsiniz. Bu durumda, yönetmeniz gereken tek şey, Excel sayfasındaki sütun değerlerini düzenlemektir. Bir şeyi unutma: Excel dosyası karşılaştırması, 100MB dosya boyutuyla sınırlandırılmalıdır . Bunun ötesine geçerseniz performans sorunlarıyla karşılaşırsınız.
Daha önce tartıştığımız gibi, XML öğe değerleri DB tablolarına bir girdi olabilir veya bunun tersi de olabilir. Dolayısıyla, XML mesajını bir DB uygulamasından bir uygulamaya gelen dosya olarak aldığınızda, XML ile DB'nin veri değerlerini karşılaştırmak için yukarıdaki test tekniğini uygulamanız gerekir. Bazen birden fazla uygulamanın verileri işlediği E2E testi yapmamız gerekir.
Gerçek hayat örneği:
Bir kullanıcı, bir e-ticaret sitesi olan Flipkart'tan bir kitap sipariş etti. Başlangıç noktası, kullanıcının bir ürün siparişi vermesidir ve bitiş noktası, e-ticaret merkezinde Fatura kopyasını alır. Daha sonra sipariş iadesi veya sipariş değişimi, ödeme iadesi vb. Gibi bazı senaryolar ortaya çıkabilir.
Burada, ürün müşteriye ulaşana kadar bir siparişi işlemek için satış, envanter, ürün işleme, lojistik, ödeme, iadeler, teklifler vb. E2E akışı, siparişi yerine getirmek için mesajlar iletiyor.
E2E testine katılacağınız zaman bir test uzmanı olarak, Uygulama ile DB veya DB'den DB'ye veya Uygulamadan Uygulamaya verilerini doğrulayacağınız senaryolarla karşılaşmanız gerekebilir. Burada, E2E veri akışı hakkında tam bir netliğe sahip olmalısınız, yani bir uygulama tarafından alınan veya uygulama tarafından gönderilen verilerin ne olması gerektiği ve DB'de depolanan veya DB'den getirilen verilerin ne olduğu.
Başarısızlık senaryoları:
Bazı olası başarısızlık senaryolarını tartışalım.
- Basit bir hata senaryosu yanlış eşleme . XML öğeleri ile DB sütunları arasındaki eşleştirme, analiz veya planlama aşamasında bir test uzmanı tarafından analiz edilmelidir. Şüpheleri açıklığa kavuşturmak için tüm haritalama endişelerini BA / SA ile tartışın. Eşleme dondurulduktan sonra, XML öğeleriyle DB sütun değerlerinin eşleşmesini sağlayabilirsiniz.
- Değerleri karşılaştırın ve eşleşmezse, sorunu çözmek için bir kusur kaydedin. Veri kusuru gibi ortaya çıkan kusur için bir dizi olasılık vardır - test verisi sorunu ; Kod hatası - Eşlenmemesi için veri değerlerini ayrıştıran koddaki hata olabilir; Artefakt kusuru - BA / SA tarafından sağlanan yanlış eşleme olabilir.
- XML biçim sorunu - XML başlığı veya meta verileri veya bazı yanlış xml etiketleri. Bu durumda XML'in kendisi veri değerlerini veritabanı tablosunda saklayamadı.
- Veri türü uyumsuzluğu - XML'deki öğe değeri, DB sütununun kabul edebileceğinden daha fazla karakter uzunluğuna sahip. Bu bir kod sorunu olacaktır ve geliştirici ekibin o sütun için veri türü uzunluğunda gerekli değişiklikleri yapması gerekir.
- Çevre hatası - Ortam çalışmıyor veya DB uygulaması çalışmıyor, veri akışı eksik kalıyor.
- Performans sorunu - İletiyi oluşturan kayıtların miktarı çok fazla olabilir veya DB üzerindeki yük, kayıt oluşması ile başlamak için yüksek olabilir.
- Ara yazılım hatası uygulamadan veritabanına veri akışının azalmasına neden olur.
- Veritabanı erişim sorunu gelen uygulamanın verileri ilgili tabloya gönderememesi nedeniyle.
Sonuç:
XML'den Veritabanına testi, tek bir XML mesajı verileri birden çok sistemde depoladığında daha karmaşık olacaktır. Ayrıca, büyük hacimli verilerin depolanması / geri alınması için veri tabanının performansı, bir test uzmanının bu tür senaryoları test etmesi için bir zorluk olacaktır.
Yukarıdaki örnek, bir uygulamada gerçekleştirilen test faaliyetlerinin küçük bir bölümüdür. Bir test uzmanının benzer bir yaklaşımla büyük miktarda veri testi yapması gerekebilir.
Lütfen yorumlarınızı, sorularınızı ve deneyimlerinizi aşağıdan bize bildirin.
Önerilen Kaynaklar
- JMeter ile Veritabanı Testi
- En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
- XML Teknolojilerini Kullanarak Mükemmel Bir Veri Test Etme Yolu (Teknik Rapor)
- 40'tan Fazla En İyi Veritabanı Test Aracı - Popüler Veri Test Çözümleri
- Mutasyon Testi Nedir: Örneklerle Eğitim
- Primer e-Kitap İndirmeyi Test Etme
- 2021'de En İyi 10 ETL Test Aracı
- Veritabanı Testi Eksiksiz Kılavuzu (Veriler Neden, Ne ve Nasıl Test Edilir)