Uzak ofiste otomatik test ve Ar-Ge işbirliği nasıl tamamlanır?
Yazar | Tao Wang, Jushan Database'in Kurucu Ortağı ve CTO'su
Editör | Tang Xiaoyin
Mühür görüntüsü | CSDN indir VCG'den
Yeni geçen Bahar Şenliği sırasında, yeni koronavirüs birdenbire ülke çapında yayıldı. Fabrikalar kapandı, okullar kapandı. Ulusal çağrıya yanıt olarak, birçok yazılım şirketi ve İnternet şirketi de Önermek Çalışanlar uzaktan çalışma kullanıyor ve ayrıca önemli mühendislerin zamanında işe dönememeleri sorunu da var ki bu da üretkenliği büyük ölçüde etkiliyor.
Yazılım şirketleri için Ar-Ge ve test, iki temel can damarıdır. Ar-Ge ekibi, ürünün yeni işlevlerinin ve yeni özelliklerinin zamanında piyasaya sürülmesini garanti ederken, test ekibi Mustang'in dizginleri gibidir ve ürünün aşırı yineleme hızı ve kötü tasarım hususları nedeniyle yazılım hatalarına neden olmamasını sağlar. 9 yıllık kendi kendine araştırma ve teknolojik inovasyonun ardından Jushan Database, Ar-Ge sistemi yapımı, otomatik test, çevrimiçi ve çevrimdışı ekip konularında yer aldı. Birleştirmek Bu tür alanlarda çok fazla deneyim biriktirdi. Ekibimizin 2011 yılında kurulmasından bu yana, tüm teknoloji araştırma ve geliştirme sistemimiz süreç odaklı işbirlikçi bir şekilde inşa edilmiştir. Temel fikir, herhangi bir çalışanın herhangi bir yerde olabileceği, doğru süreci izledikleri sürece tüm takımla organik olarak bağlantı kurabilmeleridir. Şu anda, uzaktan çalışma döneminde yeni sürümün yinelemesini ve testini tamamlamaya yardımcı olmak için, kendi deneyimlerimizin bir kısmını da sizinle paylaşıyoruz, bu da bu makalenin içeriği: Gözetimsiz bir ortamda otomatik ürün testi ve Ar-Ge işbirliği nasıl tamamlanır.
Temel sistem
1. Ağ Altyapısı
Tüm geliştirme ortamımız iki ana ağa bölünmüştür, dahili ve harici ağlar Harici ağ WAN'a bağlanabilirken, dahili ağın WAN bağlantısı yoktur. Harici ağ, ofisteki her çalışanın masaüstünün yanı sıra çalışanların uzaktan bağlanması için VPN sunucularını ve güvenlik duvarlarını içerir. Mühendisler, ister ofis bilgisayarları kullansınlar, ister dağıtılmış bir dizüstü bilgisayar aracılığıyla VPN aracılığıyla uzaktan erişiyor olsunlar, şirketin harici ağ segmentine bağlanırlar.
Şirketin harici ağ bölümü ve dahili ağı yalnızca sanal masaüstleri aracılığıyla bağlanabilir. Herhangi bir çalışanın VPN aracılığıyla bağlanan ofis bilgisayarı veya dizüstü bilgisayarı, dahili ağ ortamındaki geliştirme ve test sunucusuna doğrudan erişemez. Uzak Masaüstü gibi uzak bağlantı yazılımı kullanılarak mühendisimizin bilgisayarı sanal masaüstü sunucusuna bağlandıktan sonra tüm belgeler, kodlar ve test durumları sanal masaüstü sunucusuna yazılır. Aynı zamanda sanal masaüstü, SSH üzerinden intranetin geliştirme ve test sunucusuna doğrudan bağlanabilir ve kod derleme, gönderme, test etme gibi tüm işlemleri gerçekleştirebilir.
Bu mekanizma sayesinde, herhangi bir mühendis, herhangi bir zamanda ve yerde sanal masaüstüne erişmek için herhangi bir dizüstü veya masaüstü bilgisayarı kullanabilir ve tüm belgeler, kodlar ve bilgiler kişisel sanal masaüstünde saklanır. Örneğin, uzun süreli bir derleme görevi için, çalışma ortamınızı derlemenin yarısında değiştirmeniz gerekse bile, sadece dizüstü bilgisayarı kapatmanız, evde açmanız ve VPN'e bağlanmanız yeterlidir ve derlemenin sonuçlarını uzaktaki masaüstünüzde görebilirsiniz. .
Dahili ağımızda, esas olarak üç ağ segmentine ayrılmıştır: yönetim kümesi, geliştirme kümesi ve test kümesi.
2. Kümeyi yönetin
Yönetim kümesi temel olarak Jira süreç yönetimi, Confluence içerik yönetimi, Gitlab kod yönetimi ve kendi geliştirdiğimiz dahili kaynak yönetimimiz gibi birkaç ana hizmeti içerir.
Jira süreç yönetimi, Ar-Ge ve testin ana işbirliğine dayalı sürecidir. Test ekibi tarafından keşfedilen herhangi bir potansiyel hata dahili Jira'ya fatura edilecek ve ilgili modülün geliştirme liderine atanacaktır. Ar-Ge mühendisi testin sunduğu sorun sayfasını aldıktan sonra, sorunu yeniden oluşturacak ve kodu düzeltecektir.
Jira süreç yönetimi şematiği
Herhangi bir kod değişikliği, Ar-Ge bünyesinde Kod Gözden Geçirme gerektirir.Aynı zamanda geliştiricinin yazdığı kod testi tamamen geçtiğinde Kod Birleştirme işlemi gerçekleştirilir. Kod İnceleme veya Birleştirme olsun, kod işlem kontrolü için GitLab'ı temel alıyoruz.
GitLab kod yönetimi
Tüm resmi tasarım belgelerimiz GitLab'da saklanır ve Ar-Ge ve test uzmanlarının deneyim paylaşımlarının bir kısmı Confluence içerik yönetim sistemine yüklenecektir.Ön Cephe uygulama mühendisleri ve tüm arka Ar-Ge test uzmanları Confluence sistemindeki belgelere erişebilir .
Confluence belge yönetimi
Şu anda intranetimiz, sanal makinelerimiz ve fiziksel makinelerimizdeki toplam sunucu sayısı yaklaşık bini bulmaktadır. Bu nedenle, bu bilgi işlem ve test kaynaklarının nasıl koordine edileceği, yönetileceği ve tahsis edileceği de çok karmaşık bir konudur. Bazı test senaryoları düzinelerce veya yüzlerce sunucu kaynağı gerektirebilir. Gerektiğinde bunları nasıl tahsis edeceğiniz ve gerekmediğinde bu kaynakları nasıl serbest bırakacağınız, kendi geliştirdiğimiz otomatik kaynak yönetimi çerçevemiz tarafından üstlenilen görevdir.
3. Ar-Ge ve test kümesi
Ar-Ge kümeleri için ana görevler kod derleme ve birim testidir. Geliştirme ortamımızda her mühendise en az üç sanal makine atanır. Derleme her tamamlandığında, sürekli entegrasyon testi resmi olarak sunulmadan önce, her mühendis kendi birim testini ve hızlı standart testini tamamen geçmelidir.
Hızlı standart teste şu anda yaklaşık 2800 test durumu dahil ediyoruz ve çalışmayı tamamlamak yaklaşık 20 dakika sürüyor. Tüm geliştiriciler, kodu sürekli entegrasyon testi çerçevesine göndermeden önce hızlı standart testi tamamlamalıdır. En temel kod garantilidir Sağlamlık.
Test kümesi üç bölüme ayrılmıştır: sürekli entegrasyon, performans testi ve işlev ve kaos testi.
Bunların arasında, sürekli entegrasyon CI, Jenkins araçlarını kullanır, Birleştirmek Kendi geliştirdiğimiz uzaktan programlama çerçevemiz yaklaşık olarak 30 0 sanal makinede yaklaşık 20.000 test vakası günde 24 saat tekrar tekrar çalıştırıldı.
Jenkins hareketi
Performans testi, birden çok yapılandırmaya sahip x86 sunucuları, OpenPower sunucuları ve yerelleştirilmiş ARM sunucuları dahil olmak üzere tamamen fiziksel makinelere dayanmaktadır. Şu anda benchmarkql, tpccrunner, sysbench ve bir dizi başka standartlaştırılmış test çerçevesi dahil olmak üzere ondan fazla farklı türde performans testi çerçevesi kullanıyoruz. Her önemli işlevin entegrasyonu ve değişikliği ve tüm sürümler yayınlanmadan önce performans testi tamamlanmalı ve önceki tüm sürümlerle performans karşılaştırma eğrisi çizilmeli ve performans regresyon testi uygulanmalıdır.
Fonksiyonel test ve kaos testi aynı kümeyi kullanır. Genel olarak, işlevsel test, esas olarak dışarıdan bildirilen bazı sorunları ve komut dosyalarıyla otomatikleştirilmesi zor olan bazı işlemleri simüle etmek için kullanılan belirli bir miktarda manuel işlem gerektirir. Ek olarak, yeni işlev geliştirildikten sonra, test ekibi önce test senaryolarını sıraladıktan sonra ilgili testi işlevsel test alanında tamamlayacak ve ardından otomatik test için sürekli bir entegrasyon komut dosyası halinde sağlamlaştıracaktır.
Her sürüm yayınlanmadan önce yaklaşık 2 haftalık bir kod dondurma penceremiz olacak. Kod dondurma penceresinde, yalnızca en yüksek öncelikli arıza onarımının ana kod tabanında birleşmesine izin verilecektir. Bu süre zarfında, test ekibi libfiu kullanarak en titiz yöntemleri kullanacaktır. Birleştirmek Kaos testi mekanizması, tüm küme ortamına hataları (ağ kesintisi, paket kaybı, disk veri hasarı, disk dolu, denetleyici hatası, sunucu askıda kalma, sunucu güç kesintisi, sunucu zaman bozukluğu vb.) Rastgele enjekte eder ve verilerin olmamasını sağlar Karışıklık veya kayıp olacak.
4. Uzaktan işbirliği
Gözetimsiz ekipler arasında etkili işbirliğini sağlamanın temeli ağ olanaklarıysa, uzaktan işbirliği araçları ve süreçleri verimli işbirliğinin özüdür.
Mevcut ekiplerimiz Pekin, Şangay, Guangzhou, Shenzhen ve Chengdu gibi birkaç büyük şehirde dağılmış durumdadır. Ekipler arasındaki iletişim çok sıktır. Bu nedenle, 2014 yılının başlarında, uzaktan işbirliğine dayalı bir iletişim mekanizması oluşturmaya başladık.
Şu anda iki farklı uzaktan kumanda kullanıyoruz toplantı Herhangi bir arızayı önlemek için Sistem (Xiaoyu Yilian ve Maxhub). Bunlar arasında Xiaoyu Yilian bir Sunum olarak paylaşılmalı ve birden fazla kişi tarafından paylaşılmalıdır. toplantı Sistem aynı anda 20'den fazla partiyi çevrimiçi olarak desteklemektedir; bu, her bir müşteri sahasında bulunan ön saf uygulama mühendisleri ve arka Ar-Ge test iletişimi için çok yararlıdır. Maxhub, uzaktan beyaz tahta çizimini destekleyen teknik bir tartışma sistemi olarak daha çok kullanılır. Mühendisler, bir ekran kalemi ile doğrudan TV terminalinde çizim yapabilirken, uzaktaki ekip karşılık gelen TV terminalindeki sesi duyabilir ve çizilen görüntüyü gerçek zamanlı olarak görebilir.
Uzaktan toplantı Ve işbirliği platformu
Resmi videoya ek olarak toplantı Paylaşıma ek olarak, Ar-Ge ekibinin dahili sanal masaüstü ağı doğrudan WAN'a bağlı olmadığından, IM aracı harici bir ağ bağlantısı gerektirmeyen Tencent RTX kullanır; ön saf uygulama ekibi ile iletişim kurmanız gerekiyorsa masaüstü bilgisayarı kullanın ve ekip olarak Skype kullanın Arasında gerçek zamanlı iletişim aracı.
5. Takım Organizasyonu
İyi bilinen , Geliştirme döngüsünü ve kod kalitesini etkin bir şekilde garanti altına almak için büyük bir proje mümkün olduğunca küçük modüllere bölünmelidir. Aynı anda bir işlev üzerinde çalışan düzinelerce insan, kaçınılmaz olarak feci sonuçlara yol açacaktır.
Ar-Ge sistemimiz Ar-Ge + testine göre bölünmüştür. Bir yandan, Ar-Ge personeli, ilgili uzmanlıklarına dayanarak, ilgili modül sorunlarını çözmek için alan uzmanları olarak SQL motoru, optimize edici, veri indeksi depolama, küme yönetimi ve işlem yönetimi modüllerini kullanır; aynı zamanda, yeni işlev geliştirme görevlerine göre bir bölüme ayrılacaktır. Sanal bir takım (veya "kabile"), her sanal takıma 2-5 kişi hakimdir.
Genel olarak konuşursak, tipik bir sanal ekip 2 geliştirici ve 1 test mühendisi içerir. Olağanüstü durumlarda 3 geliştirici ve 2 test mühendisi içerebilir. İşlevsel bir modülün tamamlanması için 3'ten fazla mühendise ihtiyaç varsa, bu modülün daha ayrıntılı alt görevlere ayrıştırılması gerektiği anlamına gelir.
Test uzmanının, işlev tasarımının ilk aşamasında tüm modülün tasarım tartışmasına katılması ve erken aşamada işlevsel gereksinimleri derinlemesine anlaması gerekir. Fonksiyonel tasarımla aynı zamanda, test mühendisi test senaryosu tasarımını mümkün olan en kısa sürede tamamlamalı ve geliştiriciler resmi olarak kodlamadan önce test senaryosu incelemesini geçmelidir.
Test senaryosu geliştirme ve kod geliştirme hemen hemen aynı anda başlar.İdeal olarak, veritabanı program kodunun geliştirilmesinden sonra, test senaryosu kodunun hazırlanması gerekir ve işlevsel doğrulama hemen başlayabilir. Fonksiyonel doğrulama gerçekleştirilirken, test senaryosu, sonraki tüm yeni yinelemelerin fonksiyonun normal çalışmasını etkilememesini sağlamak için yeni bir test birimi olarak entegrasyon testi çerçevesine dahil edilecektir.
Spesifik olarak, test süreci açısından, tüm test uzmanlarının ve geliştiricilerin katılması gereken düzenli toplantılar şunları içerir:
-
Planlama: Hedef ürün işlevinin kapsamını belirleyin, iş yükü tahminleri ve düzenlemeleri yapın, görevleri iyileştirin ve boyutlandırma yapın;
-
Uygulama: Mümkün olduğunca, tüm kullanım senaryoları testin başlamasından önce tamamlanır. Uygulamada, geliştiriciler geliştirme görevlerini aşamalı olarak tamamlar ve testler, sorunları olabildiğince erken bulmak ve mümkün olan en kısa sürede yeniden tasarlamak için senkronize edilebilir;
-
Retrospection: Ekip, projenin başarılı deneyimini, sorunlarını ve engellerini analiz eder.
Her bir işlev geliştirilip omurgada birleştirildikten sonra, sanal ekip dağıtılacak ve tüm üyeler diğer projelere ve modüllere atanacaktır. Acil bir durumda, bazı kilit mühendisler aynı anda birden fazla sanal ekibin geliştirilmesine veya test edilmesine katılabilir.
Ekip çalışması açısından, bölgeler arası ve departmanlar arası işbirliği sağladık Şu anda, ekibin altı lokasyonda işin verimliliğini sağlayabilecek bölgeler arası ve bölgeler arası ofisleri var.
Otomatik test mekanizması
1. Test senaryosu planlaması ve yönetimi
Test çalışmalarında, araçlar sadece bir yardımcı olarak kullanılabilir ve ürün kalitesini gerçekten garanti eden, test senaryolarının eksiksiz olmasıdır. Veritabanları gibi sıkı sıkıya bağlı temel yazılımlar için, çeşitli işlevlerin eşzamanlılığı ve sırasının farklı permütasyonlar ve kombinasyonlar altında astronomik senaryolar olduğu söylenebilir ve% 100 tam kapsama elde etmek imkansızdır. Bu nedenle, test ekibinin yapması gereken, program kodunu mümkün olduğunca sınırlı test senaryoları ve test süresi içinde kapsamalıdır.
Test ekibinin, kullanım senaryoları arasındaki eşzamanlılık ve kullanım senaryolarının kendilerinin eşzamanlılığı ve güvenilirlik otomasyonu kullanım durumlarını elektrik kesintisi, ağ arızası, kümedeki anormal düğümler ve tam disk alanı gibi çeşitli rastgele arızaları oluşturmak için her işlev için hikaye kullanım durumları tasarlaması ve uygulaması gerekir. Ürünlerin kalitesini farklı senaryolarda sağlamak. Tüm otomasyon kullanım durumlarına karşılık gelen metin kullanım senaryoları, TestLink kullanılarak birleşik bir şekilde yönetilir ve kullanım senaryoları, özelliklerine göre zamanında bakım ve izleme yapmak üzere belirlenir.
2. Sürekli Entegrasyon CI
Veritabanı sistemi gittikçe daha karmaşık hale geldikçe, daha fazla test senaryosunu ve kullanım durumlarını ele almamız gerekiyor. Şimdiye kadar toplamda yaklaşık 20.000 farklı test senaryosu ve 10.000'den fazla basit otomatik test senaryosu dahil ettik.Tüm otomatik test durumlarını tam olarak çalıştırmak 3-4 saat sürer ve tüm otomasyon ve manuel testleri kapsar. Test senaryoları (performans testi ve kaos testi dahil) yaklaşık 1 hafta sürer.
Pek çok test durumunda, kod her sunulduğunda tüm test durumlarını çalıştırmak imkansızdır, bu da yalnızca geliştirme verimliliğini verimsiz hale getirir. Bu nedenle, test ekibi çok seviyeli test güvencesinin özelliklerini kullandı ve tüm test durumlarını 5 seviyeye ayırdı:
(1) Derleme + temel testi gönderin
Bu seviye, hızlı standart test programı olarak da bilinen en düşük test seviyesidir. Tüm geliştiricilerin, en temel kararlılık gereksinimlerini elde etmek için kodu göndermeden önce manuel olarak çalıştırması ve testi geçmesi gerekir.
Test durumu paketi doğrudan programın kod ağacında bulunur ve geliştiriciler, test programını bu düzeyde çalıştırmak için derlemeden sonra doğrudan komut dosyasını arayabilir.
Hızlı standart test programı, temelde yaygın olarak kullanılan veritabanlarının temel işlevlerinin çoğunu kapsayabilen yaklaşık 2800 basit test senaryosu içerir. Bir geliştirici kodu her gönderdiğinde, test çerçevesi arka planda hızlı standart test programını da çalıştıracaktır.Herhangi bir istisna bulunursa, geliştiricinin ilgili test olaylarını gerektiği gibi çalıştırmadığı ve buna karşılık gelen bir ihlal uyarısıyla kaydedileceği anlamına gelir.
(2) Günlük derleme + entegrasyon testi
Bu seviye, sürekli entegrasyon çerçevemiz (CI) tarafından 24x7 tekrar tekrar çalıştırılan standart bir regresyon testi projesidir. Test çerçevesi, o gün her gece saat 2'de ve ardından yaklaşık olarak o gün gönderilen en son koda göre tam derlemeyi otomatik olarak tetikler. 30 Yaklaşık 20.000 test vakası, 0 sanal makinede 7x24 tekrar tekrar çalıştırıldı.
Bu test senaryoları, hızlı standart test durumlarından çok daha karmaşıktır.En temel işlevsel işlemlere ek olarak, gerçek müşteri sitelerinde kullanıcı işlemlerini mümkün olduğunca simüle etmek için çok sayıda eşzamanlı ve karışık işlem iş mantığı içerirler. Aslında, entegrasyon testi senaryo tasarımlarımızın çoğu müşterilerin gerçek çalışma ortamından gelmektedir.
Standart regresyon testimizin tamamen bir kez çalışması yaklaşık 4-5 saat sürer. Temel olarak, mühendisler sabah işe gittikten sonra ilk kez gece derlenen versiyonun sonuçlarını görebilirler.
(3) Yedi günlük stabilite stres testi
Regresyon testi sadece programın mevcut işlevlere zarar vermemesini sağlamak içindir, ancak genellikle belleği hedeflemek zordur. yol ver , Performans düşüşü, rastgele arızalar ve diğer algılama sorunları. Bazı rastgele sorunların program her çalıştırıldığında ortaya çıkmadığını, ancak belirli senaryo ve koşullarda belli bir süre çalıştırıldıktan sonra ortaya çıkabileceğini biliyoruz. Bu nedenle, üçüncü seviye testimiz yedi günlük bir stabilite stres testidir.
Bu test kapsamında, Jushan veritabanı kümesi TPCC, sysbench ve aynı anda birden fazla sunucuda bilinen bazı müşteri iş senaryolarını simüle eden stres testi programlarını çalıştıracak. Bu testin amacı, veri tabanını olabildiğince ekleme, silme, değişiklik ve kontrollerle dolu hale getirmektir.Aynı zamanda çalışan süreç sırasında performansta düşüş olup olmadığını ve işlemin hafıza tüketiminin artmaya devam edip etmediğini sürekli kontrol eder.Son 168 saat sonra özet rapor çıkarılır.
(4) Çok sahneli performans otomatik karşılaştırma testi
1-3 arasındaki test seviyeleri kıyaslama testleridir ve test sonuçları geçer veya başarısız olur. Ancak sonuçta kod, yazılımın farklı sürümleri arasında değiştirilmiştir ve dikkatli olunmazsa, genel performans düşüşüne neden olabilir. Bu nedenle, test seviyesi 4, birden fazla senaryo altında otomatik bir performans karşılaştırma testidir.
Test seviyesi 3'ün kararlılık stres testi çerçevesine dayanan bu testte, aynı donanım ortamında aynı mantığı çalıştırmak için en son sürümü ve önceki yeni sürümü kullanacağız ve ikisinin performansını karşılaştırmak için 6 saat çalışacağız.
Genel olarak, en son sürümün ve bir sonraki yeni sürümün performansının düştüğü tespit edilirse, başarısızlık olarak Ar-Ge analizine sunulacaktır.Performans% 5'ten fazla düşerse, büyük bir başarısızlık olacaktır.Aşırı durumlarda, sürümün yayınlanması sorun çözülene kadar kesintiye uğrayacaktır. .
(5) Hata enjeksiyonu ve güvenilirlik testi
1-4 arası test seviyeleri normal ortamlardaki testlerdir, yani tüm yazılım ve donanım ortamları doğru şekilde yapılandırılmıştır ve ani bir arıza yoktur. Ancak gerçek bir üretim ortamında herhangi bir donanım ve yazılım arızasının meydana gelebileceğini ve veritabanı yazılımı olarak herhangi bir arıza sonrasında verilerin kaybolmamasını sağlaması gerektiğini biliyoruz.
Kaos testi ve manuel test bu test seviyesinde tanıtılacaktır. Test mühendislerinin veritabanını herhangi bir "yaratıcı" şekilde "fırlatması" gerekir. Nihai verilerin kayba veya tutarsızlığa neden olduğu tespit edildiği sürece, bu bir ürün hatası olarak kabul edilecek ve Ar-Ge ekibine büyük bir arıza olarak bildirilecektir.
Kaos testi daha da aşırıdır. Kaotik test çerçevemiz, işletim sistemi ve ağ düzeylerindeki hataları, örneğin doğrudan boş bir veri sayfası veya hata kodu döndüren disk G / Ç veya veritabanını doğrulamak için ağda rastgele paket kaybı veya bayt atlamaları gibi hataları otomatik ve rastgele olarak enjekte edebilir. Yazılımın anormal durumlarla başa çıkma yeteneği.
Manuel testte olduğu gibi, kaotik testlerde oluşan veri kaybı veya tutarsızlık, Ar-Ge ekibine büyük bir başarısızlık olarak rapor edilecektir. Aşırı durumlarda, sürümün yayınlanması gecikebilir.
Sürekli entegrasyon sisteminin, kod gönderimi, sistem entegrasyonu, uzun vadeli operasyon, sürümler arası yükseltmeler ve üçüncü taraf yazılım ve donanım arızalarından senaryoları kapsadığı görülebilir. Bunların arasında, belirli bir derecede manuel işlem gerektiren test seviyesi 5 haricinde, diğer tüm test senaryoları otomatik olarak çalıştırılabilir, test sonuçları, raporlar oluşturabilir ve uyarı e-postaları gönderilebilir.
3. Ar-Ge ve test işbirliği
Bir sorun bulunduğunda, test ekibinin arızayı mümkün olan en kısa sürede Ar-Ge ekibinin ilgili modül liderine bildirmesi gerekir. Tüm test senaryolarımızda sorumlu bir kişi (ekip) kullanılır, herhangi bir test durumu başarısız olursa olsun, test senaryosu numarası ve ilgili günlük dahil olmak üzere test olayından sorumlu kişiye (takım) otomatik olarak bir uyarı e-postası gönderilir. indir yol. Aynı zamanda, herhangi bir test durumu başarısız olursa, sanal makinesi dondurulacak ve test ve Ar-Ge personeli sorunu ortamda yeniden oluşturana ve sanal makinenin kilidini açana kadar başka hiçbir test durumu çalışmaya devam etmeyecektir.
Test vakasından sorumlu kişi başarısız vakayı görecek veya e-postayı mümkün olan en kısa sürede alacaktır. indir Günlüğü analiz edin. Sorunun test senaryosunun yazım hatasından kaynaklanmadığı tespit edilirse, önceki normal işlemin günlüğünü karşılaştırır ve Birleştirmek Bu süre içinde gönderilen kod güncellemeleri basitçe sorunludur.
Arıza belirli bir blokla sınırlı olduğunda, test senaryosundan sorumlu kişi Jira aracılığıyla Ar-Ge ekibine bir bilet açacak ve test senaryosunun önemine göre ciddiyet seviyesini işaretleyecektir. Ar-Ge personeli, bileti aldıktan sonra ortamı ve günlükleri görüntülemek için donmuş sanal makinede doğrudan oturum açacak, gerekirse test komut dosyasını yeniden çalıştırabilir ve sorunu bulmak için noktayı kırabilir.
Ar-Ge personeli sorunu çözdükten ve kod incelemesini gerçekleştirdikten sonra, hızlı standart test programı geliştirme ortamında yerel olarak çalıştırılacaktır.Tamamlandıktan sonra, Ar-Ge personeli, düzeltmenin test senaryosu tarafından bildirilen sorunu gerçekten çözdüğünden emin olmak için sorundan etkilenen test durumları için ayrı ayrı çalışacaktır.
Yerel test süreci geçtikten sonra, geliştiriciler kodu işlemek ve ana iletişim hattına göndermek için git'i kullanabilir. Kod omurgaya girdikten sonra, derleme programının gönderimini otomatik olarak tetikler ve arka plandaki sanal makine, kodun en temel kararlılığını sağlamak için hızlı standart test programını burada derler ve çalıştırır.
Her akşam saat 2'de, CI sistemi en son ana hat kodunun tam derlemesini otomatik olarak tetikleyecektir. Yaklaşık 1 saatlik derleme süresinden sonra, 30 0 test sanal makinesinde 4-5 saat çalıştırın.Tüm test senaryoları çalıştırılacak ve sabah 8'den önce bir sonuç raporu oluşturulacaktır.
Araç listesi
Son olarak, otomatik testte kullanılan araçları kısaca listeliyoruz:
-
Kod Yönetimi GitLab
-
Süreç Yönetimi Jira
-
Belge Yönetimi Confluence
-
Sunucu kaynak yönetimi kendi kendine oluşturulmuş sistem
-
Ar-Ge iç iletişim IMRTX
-
Harici iletişim IMSkype
-
Sürekli entegrasyon yönetimi çerçevesi Jenkins
-
Sanal masaüstü Windows sanal makine + Uzak Masaüstü
-
Sanal makine yönetimi OpenStack + VMWare
-
Performans testi LoadRunner + JMeter + bağımsız test aracı
-
Test senaryosu yönetimi Testlink
-
Libfiu'ya istisna enjeksiyonu
sonuç olarak
Bu makale esas olarak otomatik testlerdeki uygulamamızı paylaşmaktadır. Kendi kendini geliştiren bir teknoloji şirketi olarak, şirketin kuruluşundan bu yana, kendi mükemmel sistemimizi kurduk ve Ar-Ge sistemi, otomatik test, çok alanlı çalışmanın koordinasyonu ve yönetimi ve kullanıcı destek hizmetlerinde zengin deneyim biriktirdik. Bu nedenle, teknolojik araştırma ve geliştirme ilerlememizin etkilenmemesini sağlamak için kullanıcılara olağanüstü dönemde aynı hizmet ve desteği sunmayı garanti edeceğiz.
Yeni koronavirüsün neden olduğu akciğer iltihaplanması Günümüzün şiddetli salgın durumunda, tüm çalışanların kendilerini olabildiğince korumak için evden çalışmalarını zorunlu kılıyoruz.Aynı zamanda, epideminin Ar-Ge testlerinin ilerlemesi üzerindeki etkisini en aza indiren, nispeten eksiksiz bir uzaktan işbirliği ve otomatik test mekanizması kurduk. .
Makalede paylaşılan Ar-Ge ve test mekanizmamız, umarız yazılım şirketleri için bir referans olarak da kullanılabilir ve nihayetinde herkesin uzak ofis işbirliği ve Ar-Ge test yönetimi sorunlarını çözmesine yardımcı olabilir.
Yazar hakkında:
Jushan Database'in kurucu ortağı ve CTO'su Wang Tao, Kuzey Amerika'daki IBM DB2 Lab'ın çekirdek bir Ar-Ge üyesi, temel DB2 motorunun geliştirilmesinden sorumlu ve dünyanın ilk dağıtılmış veri tabanı DPF'nin geliştirilmesine katıldı. Veritabanı çekirdek mimarisi tasarımı, araştırma ve geliştirme ve inovasyon konularında 15 yıldan fazla deneyime sahiptir. Jusen Veritabanının baş mimarı ve teknik ürünlerinin başkanı olarak, 2011 yılından bu yana, Wang Tao liderliğinde, SequoiaDB'nin teknik ekibi sıfırdan dağıtılmış bir veritabanı geliştirdi ve şu anda finans endüstrisi işlem işinde, veri merkezinde vb. Sahne yaygın olarak kullanılmaktadır.
