Test verilerine ihtiyacımız var mı yoksa birim testlere ve manuel testlere güvenebilir miyiz?


10

Şu anda orta / büyük bir PHP / MySQL projesi üzerinde çalışıyoruz. PHPUnit & QUnit ile birim testi yapıyoruz ve uygulamayı manuel olarak test eden iki tam zamanlı testçimiz var. Test (sahte) verilerimiz şu anda SQL komut dosyalarıyla oluşturulmaktadır.

Test verileri için komut dosyalarını koruma konusunda sorun yaşıyoruz. İş mantığı oldukça karmaşıktır ve test verilerindeki bir "basit" değişiklik genellikle uygulamada birkaç hata üretir (bunlar gerçek hatalar değildir, sadece geçersiz verilerin ürünüdür). Bu, tüm takım için büyük bir yük haline geldi, çünkü sürekli olarak tablolar oluşturuyor ve değiştiriyoruz.

Komut dosyalarında test verilerini koruma noktasını gerçekten görmüyorum, çünkü her şey kullanıcı arayüzüyle yaklaşık 5 dakika içinde uygulamaya manuel olarak eklenebilir. Başbakanımız buna katılmıyor ve test verileriyle dağıtamayacağımız bir projeye sahip olmanın kötü bir uygulama olduğunu söylüyor.

Komut dosyalarının test verileriyle bakımından vazgeçmeli ve sadece test kullanıcılarının uygulamayı veri olmadan test etmesine izin vermeli miyiz? En iyi uygulama nedir?

Yanıtlar:


4

İki farklı kavramı karıştırıyorsunuz. Bunlardan biri Birim Testi ve Hakem İncelemelerine dayanan doğrulamadır . Bu, test verileri olmadan geliştiricilerin kendileri tarafından yapılabilir ve amacı bir dizi gereksinimin karşılandığını doğrulamaktır.

İkincisi doğrulamadır ve bu QA (test kullanıcılarınız) tarafından yapılır. Bu adım için test verisine ihtiyacınız vardır, çünkü test cihazı uygulamadaki programlama hakkında herhangi bir bilgiye sahip olmak zorunda değildir, sadece amaçlanan kullanım durumlarıdır. Amacı, uygulamanın bir üretim ortamında tasarlandığı gibi davrandığını doğrulamaktır.

Her iki süreç de müşteriye kaliteli bir ürün sunmak için önemlidir ve gereklidir. Sadece birim testlere güvenemezsiniz. Anlamanız gereken, test verilerinizin geçerli olduğundan emin olmak için güvenilir bir yöntemdir.

EDIT: Tamam, istediğini alıyorum. Cevap evet, çünkü Test Cihazının işi test verilerini üretmek değil, sadece uygulamayı test etmek. Komut dosyalarınızı daha kolay bakım sağlayacak ve geçerli verilerin eklenmesini sağlayacak şekilde oluşturmanız gerekir. Test verileri olmadan, test cihazının test edecek hiçbir şeyi olmayacaktır. Bununla birlikte, test ortamına erişiminiz varsa , komut dosyalarını kullanmak yerine test verilerini neden manuel olarak ekleyemediğinizi anlamıyorum.


Belki de birim test ve test verilerinden bahsederek sorumu yanlış ifade ettim. Doğrulamanın birim test ile aynı olmadığını anlıyorum. Buradaki sorunum, komut dosyalarıyla oluşturduğumuz test verilerinin 5 dakika içinde kullanıcı arayüzü üzerinden oluşturulabilmesidir. Bu verileri uygulamaya eklemek için programlamayı bilmenize gerek yoktur, sadece test senaryolarını takip etmeniz gerekir.
Christian P

@ christian.p soruyu açıklığa kavuşturmak için güncellememi kontrol et.
AJC

Yani çözümünüz komut dosyalarını terk etmek ve sadece kullanıcı arayüzünden manuel olarak test verileri eklemek mi? P.Brian.Mackey'nin verdiği cevap ve verilerin UI ile eşleştirilmesine verdiği cevaplar ne olacak?
Christian P

@ christian.p Peki, script kullanmanız gerektiğine katılıyorum. AMA GERÇEK olduğunu söyleyen hiçbir formalite veya kural yoktur. Sahte veriler oluşturmak için komut dosyalarını kullanmanın ana nedeni hız (otomasyon) ve erişimdir (test ortamına). Erişiminiz varsa ve manuel olarak yapmak daha hızlı ve daha kolaysa, bunu yapamamanızın bir nedeni yoktur. (AMA test ettiğiniz verilerin kaydını tutun).
AJC

her test cihazının kendi test ortamı vardır ve test cihazları db'yi günde birkaç kez tamamen düşürmektedir, bu nedenle test verilerini manuel olarak eklemek pratik değildir, ancak test için kibarca veri eklemelerini isteyebiliriz.
Christian P

6

Evet, birim testlere ve veri maketlerine sahip olmak en iyi uygulamadır. Proje yöneticisi doğrudur. Test verilerinde "basit" bir değişiklik yapmak genellikle hatalar ürettiğinden, sorunun özü budur.

Kodun iyileştirilmesi gerekiyor. Bunu yapmamak (hey, testlere ihtiyacımız yok demek) bir düzeltme değildir, bu sadece teknik borç eklemek demektir . Kodu daha küçük, test edilebilir daha küçük birimlere ayırın, çünkü birimleri kırılmadan tanımlayamamak bir sorundur.

Refactor yapmaya başlayın. Geliştirmeleri yönetilebilir olması için küçük tutun. KURU, tek sorumluluk vb. Olmayan Tanrı sınıfları / yöntemleri gibi anti-kalıpları arayın ...

Son olarak, ekip için işe yarayıp yaramadığını görmek için TDD'ye bakın. TDD, tüm kodunuzun test edilebilir olmasını sağlamak için iyi çalışır (çünkü önce testleri yazıyorsunuz ) ve ayrıca testleri geçmek için yeterli kod yazarak (mühendislik üzerinde en aza indirgeyin) yalın kalmanızı sağlar .

Genel olarak, bir dizi karmaşık iş mantığı işlemi bir veri kümesi üretirse, bunu bir rapor olarak görüyorum. Raporu kapsülleyin. Raporu çalıştırın ve sonuçtaki nesneyi bir sonraki sınama için girdi olarak kullanın.


Biraz şeyleri açıklığa kavuşturmak gerekiyor: "Test verilerinde basit bir değişiklik hata üretir" - burada sorun uygulamada değil - veri geçerli olduğunda uygulama iyi çalışıyor (ve manuel olarak geçersiz veri ekleyemezsiniz) . Buradaki sorun, geçersiz test verilerinin bu veriler üzerinde çalışmaya çalışırken hatalar üretebilmesidir. Test verilerini de test etmemiz gerekiyor mu?
Christian P

Kırmızı bir ringa balığı yanılgısına kapılmayın. Test verilerinin bir hata oluşturması hep birlikte farklı bir konudur. Testlerin kaldırılması bir sorun değildir, "hükümeti yönetmek" de başka bir şeydir. Sorun kod. Test edilemez çünkü bize bir şeyleri kırmayan testler yazamayacağınızı söylüyorsunuz. Bu yüzden kodu geliştirmeniz gerekiyor.
P.Brian.Mackey

Belki sorumu yanlış anladın. Çalışma birimi testlerimiz var ve yazdığımız her yeni işlevsellikte birim testleri var. Geçmeyen testleri kaldırmamızı veya hiç test yazmamamızı önermiyorum. Sadece manuel test kullanıcıları aynı şeyi yapıyor çünkü veritabanında sahte veri oluşturmak için komut dosyaları kullanmamanızı öneririz.
Christian P

"Komut dosyalarında test verilerini koruma noktasını gerçekten göremiyorum" <- Söylediğim test desteğini bırakmak. Eski testlerin silinmesi değil. Bu kötü bir fikir. Tekrarlanabilirliği azaltır ve kendinizi test etmeye çalıştığınız ve değişime uyum sağlayabileceğiniz şeyin bir parçası olan bir kullanıcı arayüzüne bağlarsınız. Kullanıcı arayüzünden kendinizi ayırın. Veri otomasyonunu koruyun.
P.Brian.Mackey

Ancak geçersiz sahte veri sorununu nasıl çözeceğiz? Veritabanı için sahte veriler oluşturmaya devam edersek, sahte verilerin iyi olup olmadığını nasıl kontrol ederiz? İş kuralı X = 2 değerini gerektiriyorsa ve veritabanı X = 100 kabul ediyorsa - iş kuralı karmaşık olduğunda test verilerinin bütünlüğünü nasıl kontrol edebiliriz?
Christian P

1

Bu çok yaygın ve çok zor bir sorundur. Bir veritabanına ( HSQLDB gibi bir bellek içi veritabanı bile) çalışan otomatik testler genellikle yavaş, belirleyici değildir ve bir test hatası yalnızca kodunuzda veya verilerinizde bir yerde bir sorun olduğunu gösterir. fazla bilgilendirici değil.

Deneyimlerime göre, en iyi strateji iş mantığı için birim testlere odaklanmaktır. Temel alan kodunuzu mümkün olduğunca kapsamaya çalışın. Bu bölümü doğru bulursanız, ki bu oldukça zor bir iştir, otomatik testler için en iyi maliyet-fayda ilişkisini elde edeceksiniz. Kalıcılık katmanına gelince, normalde otomatik testlere çok daha az çaba harcıyorum ve bunu özel manuel test kullanıcılarına bırakıyorum.

Ancak, kalıcılık testlerini otomatikleştirmek istiyorsanız (veya ihtiyacınız varsa) , Testler tarafından yönlendirilen Büyüyen Nesne Tabanlı Yazılımları okumanızı tavsiye ederim . Bu kitapta kalıcılık testlerine ayrılmış bir bölüm vardır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.