Borsasında işlem gören 550’den fazla şirketin Üye Kayıtlarını tutmaktadır. Bu, kote edilen toplam şirket sayısının %50’sinden fazladır ve günlük işlem hacminin %50’sinden fazlasını oluşturur. LBR tarafından üstlenilen iş, adına hareket ettiğimiz şirketler (müşteriler olarak bilinir) için tüm hissedarların adlarını, adreslerini ve varlıklarını korumayı ve temettüler, devralmalar, hak sorunları, analizler ve diğer toplu işleri yürütmeyi gerektirir.

1980’lerin ortalarında LBR, BT’yi daha önce kendileri için yapmış olan merkezi Lloyds Bank BT departmanından kendi bünyesine aldı. Bu, hızla değişen ve büyüyen hisse senedi piyasasıyla başa çıkamayacak kadar yavaş ve hantal hale gelen IBM toplu sistemlerini değiştirmeyi planladıkları zamandı.

Test Uygulaması

LBR’nin BT kurulumunun bir parçası olarak, daha önce IBM sisteminin son kullanıcıları olan ve çok az resmi BT eğitimi almış veya hiç almamış personelden bir Sistem Testi ekibi oluşturuldu. Sonuç olarak, test başlangıçta neredeyse bir kullanıcı kabul alıştırması olarak gerçekleştirildi; burada her testçi, ortak bir test ortamında test edilen programı çalıştırdıkları sürekli gelişen kendi test veritabanına sahipti.

Regresyon testini daha tutarlı hale getirmek için geliştirilen test planları ve testin tekrarlanabilir olması için statik bir başlangıç konumuna sahip olmak için test veritabanlarının yedekleri alınmasıyla, zaman içinde testler daha disiplinli hale geldi.

Yerleşik bu temel ve birikmiş büyük bir test yığınıyla birlikte, test ekibinin üretkenliğini artırmanın bir yolu gerekiyordu ve testlerin bir kısmının otomatikleştirilmesi bunu başarmanın bir yolu gibi görünüyordu. 1989 yılında eğitimli bir BT yöneticisi olarak LBR’ye katıldığımda, bana test ekibini yönetme ve otomatikleştirilmiş testi başlatma görevi verildi.

Test Edilecek Yazılımlar

Otomatik testi başlattığımız sırada LBR’de sürmekte olan geliştirme projesi, hisse kayıt sisteminin VAX Basic dilinde yeniden yazılmasıydı; bu, sistemi bir gecelik toplu iş yerine çevrimiçi ve gerçek zamanlı hale getiriyor ve donanımı bir IBM ana bilgisayar platformundan taşıyordu. 

İki ana program türü, kayıt memuru olarak hareket ettiğimiz şirketlerin üyelerinin kayıtlarını tutmak için iki aşamalı (giriş ve kontrol) veri yakalama programları ve toplu değişiklikler yapmak için arka plan (bir gecede olması gerekmese de) toplu programlar idi. 

Tüm işler, VAX kümesine bağlı aptal terminallerden çalıştırıldı. PC kullanımı yoktu. Temel sistem, 1989’da sistemin hayata geçmesini sağlamak için başlangıçta 500 ila 1000 program modülü gerektiriyordu. Ancak, yeni gereksinimler bunu çok hızlı bir şekilde 1991’de yaklaşık 3000 modüle çıkardı.

1989’da yayın tarihi elde edildikten sonra, yazılacak ekstra programların ölçeği belirginleşti ve üretkenliği artırma çabası ciddi bir şekilde başlatıldı. Bunun ana itici gücü, mümkün olduğu kadar çok testi otomatikleştirme planıydı.

Test otomasyonu görevinin amacı, aynı sayıda personelle daha fazla program üzerinde daha fazla test yapabilmek ve böylece daha fazla hatayı daha hızlı bulabilmekti. Bu, yalnızca manuel testle mümkün olandan daha hızlı bir şekilde canlı ortamda daha kaliteli kod uygulamamızı sağlamalıdır. Bu vaka çalışması, bu amaca ulaşma girişimindeki deneyimlerimi detaylandırıyor.

İlk Otomasyon Denemesi

Tüm geliştirmemiz Dijital bir platform üzerinde olduğundan, önce Dijital Test Yöneticisi (DTM) olarak bilinen Dijital sistem yazılımıyla ücretsiz olarak sağlanan test aracına bakmak mantıklıydı.

Benim için ilk adım, DTM’de bulunan tüm olanakları araştırmak için küçük örnek programlar kullanarak bir alışma alıştırmasından geçmekti. Ürünü uygulanabilir buldum ve dili, sınırlı teknik geçmişe sahip test ekibi tarafından kullanılacak kadar basit buldum. Kriterlerle karşılaştırmalar yapmadan önce test ortamının kurulmasına ve sonuçların önceden düzenlenmesine izin veren ön ve son süreçler vardı.

PC sistem Testi
Sistem testi Nedir
Online bilgisayar performans testi
Performans testi PC
Sistem Testi Valorant
Sistem testi nasıl yapılır
Kabul Testi Nedir
Bilgisayar Performans Testi programsız

Etkileşimli Programlarla İlgili Sorunlar

Ürünü anladıktan sonra, test edilen gerçek bir ekran tabanlı etkileşimli program seçtik ve test planından testleri yürüten testçiyi kaydetmeye devam ettik. Her test için komut dosyası ayrı ayrı saklandı.

Program düzeltme için geliştiricilere iade edildi ve geri döndüğünde kaydedilen testleri oynatmaya çalıştık. Her tuş vuruşundan doğru sonuç döndürüldüğü sürece bu iyiydi.

Beklenmedik bir sonuç meydana gelir gelmez, betiğin geri kalanı programa ayak uyduramadı ve bazı çok istenmeyen sonuçlar doğurdu. Komut dosyası dili, bu sorunun üstesinden gelmemize izin verecek kadar yeterli zekaya sahip görünmüyordu, bu nedenle temiz çalışmayan tüm testler terk edilmek zorundaydı.

Komut dosyasını ekran formatındaki değişikliklere izin verecek şekilde güncellemek (ek alanlar en yaygın değişikliktir) zor değildi, ancak her test ayrı olarak saklandığından, hepsinin çok dikkatli bir şekilde güncellenmesi gerekiyordu; o ekran değişti. Bu, kaçınılmaz olarak, programı o noktaya geldiğinde tekrar kontrolden çıkaran bazı hatalara yol açtı.

Toplu Programlar

Raporlar üreten toplu programları çalıştırırken, ekran arabirimi nispeten basitti. Buradaki zorluk, rapor içeriklerini kontrol etmekti. DTM son işlemcisinin, çalıştırmadan çalıştırmaya değişen başlıklardan, sayfa numaralarından ve diğer öğelerden tarihleri filtrelemesi amaçlandı. Bununla birlikte, programlar hala geliştirme aşamasında olduğundan, sonuçlarda çalıştırmadan çalıştırmaya kaçınılmaz olarak farklılıklar vardı.

Testlerin her yeniden çalışmasından her zaman çok sayıda fark rapor edildi ve hangi farkların düzeltilen sorunlardan hangilerinin sorunlardan kaynaklandığını bulmak için muazzam çıktılar arasında ilerlemek çok zor ve zaman alıcıydı. 

Zamanla bu sorunlardan bazıları azaldı, ancak hiçbir zaman tutarlı tasarruflar sağlayacak kadar azaldı ve çoğu zaman DTM’yi kullanmak, manuel testten daha uzun sürdü. Bu, test ekibi arasında yalnızca DTM ile değil, otomatik test konseptiyle ilgili de tam bir hayal kırıklığına yol açtı. Komut dosyaları ve sonuç dosyaları da çok büyük miktarda disk alanı tüketmeye başlıyordu ve bu, programın yeni bir sürümü için bu testleri geri yüklememiz gerektiğinde tüm ilgili gecikmelerle birlikte bazı verileri teybe arşivlememize neden oluyordu.

DTM’i istediğimiz gibi çalıştıramadığımız için kullanımını bıraktık. Bununla birlikte, deneyimlerimiz, gelecekte satın almayı düşüneceğimiz herhangi bir otomatik test aracında nelere bakmamız gerektiği konusunda bize iyi bir fikir verdi.

The post Sistem Testi Oluşturma first appeared on Akademi Delisi (Tez Yaptırma).