Otomatik test donanım aracı (Otomatik test olarak adlandırılır), farklı programlar ve yazılım birimleri üzerindeki bir dizi test durumunu kontrol eder. Her test, girdi verileri, testin nasıl çalıştırılacağına ilişkin talimatlar ve beklenen çıktı verileri tarafından tanımlanır. Araç, test edilecek programların yalnızca dosyalarda tutulan verilerden çalıştırılabilmesini gerektirir. Neyse ki, programlarımızın çoğu bu yeteneğe sahipti. Test süreci tasvir edilmiştir.

Karşılaştırma işlemi, karşılaştırılacak verilerin formatına bağlı olarak farklı programlar tarafından gerçekleştirilir. Bazı biçimler, iki dosya arasındaki her farkın raporlanması için yalnızca basit bir karşılaştırma gerektirir. Meşru farklılıklar içeren dosyalar için daha karmaşık karşılaştırma programları gerekir.

Beklenen çıktı verileri manuel olarak önceden belirtilmemiştir. Bunun yerine, ilk test çıktısının manuel olarak doğrulandığı ve daha sonra diğer tüm çalışmaların otomatik olarak karşılaştırılması için bir referans noktası olarak hizmet ettiği bir referans test yaklaşımı kullanılır.

Her test çalışmasının durumunu veren bir test raporu oluşturulur. Bu aynı zamanda yazılım sürümlerinin, kullanılan makinenin, geçen sürelerin vb. ayrıntılarını da içerir.

Geliştirme Çabası

Test koşum takımı ve birkaç ‘standart’ karşılaştırma aracı, yaklaşık 4 kişi-yıllık bir çabayla bir yıldan biraz daha kısa bir sürede geliştirildi. Ayrıntılı gereksinimler onaylanmadan önce prototiplerden çok yararlanıldı. Bu geliştirme sürecinin sonlarına doğru Ürün Güvence Grubu entegrasyon testlerinin otomasyonunu üstlendi.

Bu, yaklaşık 9 kişi-ay emeği kullanılarak tamamlandı. Gerekli testlerin tümü otomatikleştirilememiştir. Test edilen programlar dahili veri yapılarına erişimi kolaylaştırmadığı için bazılarını manuel olarak gerçekleştirmek hala gerekliydi. Çoğu zaman, nihai sonuç verileri, testin işe yaradığını göstermek için yetersizdi.

Autotest’in İlk Kullanımı

Otomatik entegrasyon testleri, ilk kez, Visual 5.0 sürümünün eksiksiz bir entegrasyon testini gerçekleştirmek için kullanıldı. Manuel testler 2 kişi-hafta ve otomatik testler 1 kişi-hafta sürmüştür. Otomatikleştirilmiş testler aslında yaklaşık 10 saat içinde çalıştırılabilir, ancak karşılaştırma araçlarının olmaması, bazı sonuçların doğrulanması için manuel çabanın gerekli olduğu anlamına geliyordu.

Otomasyon olmadan, entegrasyon testi her platformda 10 kişi-hafta sürdü. Otomasyon ile bu 3 kişi-haftaya düşürüldü. Daha otomatik karşılaştırmalarla daha fazla azalma mümkün oldu.

Bilgisayar donanım test programı
Bilgisayar donanım testi
Online bilgisayar donanım Testi
Bilgisayar donanım SORULARI pdf
Telefon donanım testi
Bilgisayar donanım Test Soruları ve Cevapları pdf
PC benchmark test Programı
Donanım test programı

Sistem Testi Otomasyonu

Entegrasyon testi üzerinde önemli bir etki yaratan sonraki adım, sistem testini otomatikleştirmekti. Ancak bu çok daha büyük bir girişimdi: 28 kişi-haftalık manuel testlerin, otomatik olarak çalıştırılabilecek testlere yoğunlaştırılması gerekiyordu.

Ne yazık ki, manuel testlerin tümü ayrıntılı test spesifikasyonları tarafından desteklenmiyordu. Sistem test edildiğinde bazı işlevsellik alanları, uygulama mühendisleri tarafından uygun gördükleri şekilde ‘uygulanır’. Ayrıca çok az resmi test verisi vardı. Manuel test, her uygulama mühendisinin ya uygun bir Veri Kümesinin nerede bulunabileceğini bilmesine ya da onu yerinde oluşturmasına dayanıyordu. Ek olarak, platformlar arasında belirli veri türlerinin aktarımı için bir mekanizma olmadığından, verilerin çoğu platforma özeldi.

Bu durum göründüğü kadar kötü değildi, çünkü mühendislerin çoğu bir süredir testlerle uğraşıyordu ve daha önce kullanılmış olan test verilerini nerede bulacaklarını biliyorlardı. Ancak bu, yalnızca testleri otomatikleştirmenin değil, aynı zamanda neyin otomatikleştirilmesi gerektiğini tanımlamanın da gerekli olduğu anlamına geliyordu. Bu karmaşıklık, uygulama mühendislerinin test otomasyonuna dahil edilmesini zorunlu hale getirdi.

Biraz temkinli bir yaklaşımla, sistem test eforunu %80 oranında azaltmak için yaklaşık 3 kişi-yıl efor gerektiren bir proje önerisi ortaya atıldı. Ancak, Genel Müdürü testin %20’sini manuel olarak gerçekleştirmenin hala gerekli olduğuna ikna etmek çok zor oldu. %100 test otomasyonu istedi.

Test verisi geliştirme, genişlik testi ve derinlik testi geliştirme aşamaları olarak adlandırılan iki aşamaya ayrıldı. İlk aşama veya ‘genişlik testi’, tüm programların bir şekilde uygulanmasını sağlamayı amaçlıyordu.

Amaç, kusurları bulmaktan çok, her programın en azından bazı şeyleri doğru yaptığını göstermekti. Yazılımdaki daha kritik alanların test kapsamını (yani işlevsel kapsamı) iyileştirmeyi amaçlayan ikinci aşama veya ‘derinlik testi’; temel olarak programların bir alt kümesi için test derinliğini artırmak.

Genişlik testi için, uygulama mühendisleri ağırlıklı olarak manuel testlerin bir alt kümesini uyguladılar: iş için en iyi olduğuna inandıkları testler. Hiçbir test planı veya test spesifikasyonu yazılmamıştır. Yazılımdaki en kritik alanlar için daha titiz bir test yaklaşımının kullanılabilmesi için bu ilk Test Setinin mümkün olan en kısa sürede tamamlanması gerekiyordu.

Derinlik testi için test spesifikasyonları üretildi. Bunlar, mühendislerin eğitilmiş olduğu denklik bölümleme ve sınır değer analizi gibi test senaryosu tasarım metodolojilerinin iyi bir şekilde kullanılmasını sağladı.

Otomatik entegrasyon testlerini sistem testi için geliştirilenlerle birleştirmeye karar verdik. Manuel testte, entegrasyon testlerini geçmek aslında sistem testine başlamak için giriş kriteriydi.

Otomatik test için, iki seti ayrı ayrı tutmanın çok az değeri var gibi görünüyordu, çünkü her ikisi de haftalar yerine birkaç saat içinde çalıştırılabilirdi. En son kullanıldıktan birkaç ay sonra entegrasyon testi verilerinin bulunmasındaki sorunlar, resmi kontrol ihtiyacını vurguladı. Kontrol standartlarının ve prosedürlerinin getirilmesi gerektiği açıktı. Neyse ki, gerekenlerin çoğunu makineleştirmek için kaynak kodu kontrol sistemimizi kullanabildik.

Dikkate değer başka bir sorun da, entegrasyon testinin sonuçlarını doğrulama görevinin çoğunun manuel olarak yapılmış olmasıydı, bu nedenle testlerin kendileri için daha fazla çalışma gerekiyordu. (O zamana kadar, test sonucu doğrulamasının otomasyonunu kolaylaştıran daha zengin bir karşılaştırıcı seti mevcuttu.)

Test Edilebilirlik İçin Tasarlanmamış Programlar

Test otomasyon programının en başından beri, birçok programın zayıf test edilebilirliği sürekli bir sorun kaynağıydı. Geliştirme grupları, uygulamalarının daha iyi test edilmesini sağlayacak değişiklikleri yapmak konusunda genellikle isteksiz veya yetersiz olduklarını kanıtladılar. Neyse ki, test araçlarını şirket içinde geliştirme kararı pek çok sıkıntıyı önledi.

Bazen, test edilecek programla ilgili bazı bilgileri test aracına ekleyerek geçici bir geçici çözüm uygulamak mümkündü. Bu, araçların genel olmasını talep eden araç geliştirme politikamıza geçici olarak aykırıydı.

Programların çok azı otomatik testler düşünülerek tasarlanmıştı. Bu hikayenin iki buçuk yılı boyunca pek çok iyileştirme yapıldı, ancak hala yapılabilecek daha çok şey vardı. Bu deneyim sayesinde öğrendiklerimiz, tesisleri, önemli yönlerinin çoğunu otomatik olarak test etmeyi mümkün kılan yeni programlara göre tasarlayabileceğimiz anlamına geliyordu.

The post Test Donanım Aracı first appeared on Akademi Delisi (Tez Yaptırma).