QA personeli önbellekleme mantığını göremediklerini nasıl test edebilir?

Web uygulamamda sadece bir önbellek katmanı kullandım ve şimdi önbelleğe alma işlemi kullanıcı için şeffaf olduğundan, KG'nin bunu nasıl test etmesi gerektiğini merak ediyorum.

Benim bir fikrim, önbelleği dolduran kodu çağıran yöntemlere giriş yapmak ve bir nesne önbellekten çekildiğinde ve veritabanından yeniden oluşturma gerektirdiğinde kayıt yapmak ve ardından test ediciler, aşağıdakileri görmek için günlükleri görüntüleyebilmektir. örneğin, her sayfa görünümü yerine, her 10 dakikada bir belirli bir nesne db'den yeniden yüklenir.

Ancak herhangi biri bu durum için daha iyi uygulamalar önerebilir mi?

Bir soru, önbelleğin gerçekten QA tarafından test edilmesi gereken bir gereksinim olup olmadığıdır. Önbellekleme performansı artırır, böylece performansın bir gereksinimi karşıladığından emin olmak için performans farkını test edebilir.

Ancak, önbelleğe alma konusunda bazı testler yapmak iyi bir fikirdir, kim sorumluysa. Performans sayaçlarını kullandık. Önbellek sisteminiz bunlardan yararlanıyorsa, basittir. Önbellekten bir sayı almanın bir yolu varsa, bu başka bir seçenektir.

Yaklaşımınızı kullanmak da güzel. Bunlardan herhangi biri sonuçları kontrol eden otomatik testlere tabi tutulursa, o zaman kimse cevapları bulmak için kayıtlara bakmak zorunda kalmaz.

Sistem yeterince iyi performans göstermediğinden önbellek uyguladınız (sanırım). Bu kullanıcı için önemli bir şey. QA'nın kontrol edebileceği şeyler:

• Önbellek tanıtıldıktan sonra sistemin hala doğru olduğunu. Bu, önbelleği kandırmak için QA'nın doğrulayabileceği ve başka hiçbir şeyin kırılmadığından emin olmak için eski veriler sağlamaları için kandırmaları gerektiği anlamına gelir.
• Sistemin artık performansı karşılaması, performansı iyileştirmeye karar verdiğinizde yerine gelmediğini gösteriyor. Eski ölçüleri karşılaştırabilir ve yenilerini karşılaştırabilirler.

Unutmayın, kullanıcılar (ve buna ek olarak, KG) bir sorunu nasıl çözdüğünüzü önemsemez . Sadece sorunun çözülmesini ve yeni sorunlar yaratmamasını önemsiyorlar . Bu, önbellekleme, geliştirilmiş Dize ayrıştırma, donanım yükseltme veya sunucuda sihirli peri tozu serpme durumunuz için geçerlidir.

Önemli iş mantığını veya sistem durumunu kara kutuya gömmek doğru sistem davranışını doğrulamayı zorlaştırır. Sistemdeki tek bir bileşenin davranışını tüm sistemden daha ayrıntılı bir şekilde test etmek daha kolaydır. Bu tür şeyleri açıkça bazı mekanizmalarla açığa vurmayı tercih ederim, böylece birim / regresyon / entegrasyon / KG üzerinde anlamlı bir şekilde test edilebilir.

Önbellek içeren bir seçenek, önbellekle ilgili bazı detaylar (içerik, durum vb.) Sunan özel bir sayfa açmak olacaktır. Bu gelişme ve potansiyel olarak üretimde hata ayıklamaya yardımcı olabilir. KG, önbelleğin beklenen davranışının ne olduğu konusunda ayrıntılı bilgi verilirse önbellek için test senaryoları oluşturmak için de bu sayfayı kullanabilir. Önbellek davranışını açıkça belgelemek için performans sayaçlarını ve / veya günlük dosyalarını kullanmak, daha az görülebilir ancak uygulanabilir bir yaklaşımdır.

Bu yaklaşımın baştan sona performans testinin yerine geçmediğini unutmayın. Bu, önbelleğin kendisinin doğru davranmasını sağlayan bir mekanizmadır. Önbelleğe almanın performans üzerinde amaçlanan etkiye sahip olup olmadığını belirlemek için performans testi kullanılmalıdır.

Ayrıca, sistemin bileşenlerinin, önbellek takma gibi aynı arayüzü uygulayan yenileriyle değiştirilmesinin kararsızlaştırıcı ve aldatıcı bir şekilde karmaşık bir değişiklik olabileceğine dikkat edin. Önbellek örneğiyle, daha önce vatansız olan, bulması ya da çoğaltması daha zor olan böcekler yaratabilen durumu tanıtıyorsunuz. Beklenen sistem davranışını doğrulamak için böyle bir değişikliğe her zaman tam regresyon testi eşlik etmelidir.

Andy'nin cevabında belirtildiği gibi performansı test edin.

Birçok kuruluşta önbelleğe alma (ve performans) uygulamasının önündeki en büyük engelin aslında iyi performans testi yapabileceğiniz ve çeşitli gerçek dünya yük ve performans testleri için testler yapabileceğiniz bir ortama sahip olduğunu buldum.

Buna sahip olmak için, mümkün olduğu kadar yakından ve maliyetlere olanak tanıyan üretimi yansıtan bir performans test ortamı oluşturmalısınız. Bu, muhtemelen hızlı uygulama geliştirmeye olanak sağlamak için daha küçük ve daha fazla bağımsız olması gereken mevcut geliştirme ortamınız DEĞİLDİR. Geliştirme ortamları ayrıca daha az önbellekleme eğilimindedir ve bu nedenle performans testi için üretimi iyi temsil etmemektedir.

Performans test ortamında, uygulamanın üretim 'modunda' çalışıyor olması gerekir. Üretim yapıyorsa birden fazla sunucuya ihtiyacınız olmalı, üretim ortamı için veritabanı bağlantı havuzu ve önbellekleme ayarlanmalıdır.

Ayrıca, yük testinde yardımcı olacak bir araç düşünebilirsiniz.
jmeter, oldukça düşmanca ve kullanımı ilkel bulduğum halde çok popüler.
Kullandığım başka bir rota da sadece curlbir yakut betiği ile url yapmaktır.

Açık olmak gerekirse

• Temel hat performans testi, ONE isteğinin yapacağı süreyi test etmek içindir.
• Yük testi, performans testine benzer, ancak sistem diğer taleplerden yük altındayken de cevaba bakar.

Aşağıdaki linkleri faydalı bulabilirsiniz:

• Önbelleği yoğun kullanan birim sınama yöntemleri için en iyi yöntemler?
• Önbellek için Test Metodolojisi
• Sitenin yük altında nasıl bir performans göstereceğini test etmenin bir yolu var mı
• http://www.procata.com/cachetest/

Testçilerin sunucuları yeniden başlatmasını ve girdikleri verilerin hala orada olup olmadığını kontrol etmelerini unutmayın. Aylarca test yapan, yapıldığında başarısız olan bir sistem gördüm!

Testine zor kısmı veri güncellenir ancak olmasıdır asla önbellekten döndürülen herhangi dışı tarihten sonuçları.

Bu, kullanıcının bir değişiklik yaptıktan sonra gördüğü onay sayfasını doldurmak için her zaman önbellekteki verileri kullanarak yardımcı olabilir. Örneğin, veritabanını güncellemek için kullandığınız nesneyi kullanmayın, ancak önbellekten veri isteyin, ardından veritabanından isteyin. Biraz daha yavaş, ancak böcekleri daha hızlı göstermesi daha muhtemel.

Bu sorunun çok basit bir cevabı var ve önbellekleme seviyesiyle ilgili. Önbellekleme doğru olduğunda gözlemleyeceğiniz şey, isteklerin hedefindeki isteklerin olmamasıdır. Yani, "beklenen sonuçlar" hackneyed QA ifade aşağı gelir.

Web katmanında bir önbellek kullanılıyorsa, önbelleğe tabi öğelerin yalnızca bir kez test edilen her kullanıcı oturumu için (istemci önbellek kullanılıyorsa) veya birden çok kullanıcı için bir kez (bir CDN stili önbellek uyguluyorsa) görünmesini beklerim. Ortak sonuçlar için veri katmanında bir önbellek uyguluyorsanız, veri katmanı için profil günlüğünde sorguların olmamasıyla birlikte, önbellek katmanınızda yüksek bir önbellek isabet oranı görmeyi beklerim.

vb...

Bazı şeyler bir programcı tarafından, belki de kodu yazan kişi tarafından birim sınamaları kullanılarak daha iyi test edilir. Önbelleğe alma kodunuzun doğruluğunu test etmek bunlardan biridir. (Bu soruyu sorma şeklinden, QA çalışanlarınızın uygulamaya "kara kutu" olarak baktıklarını ve harici arayüzü aracılığıyla test ettiklerini farz ediyorum.)

Önbelleğe alma mantığı, geliştirici tarafından QA'nın esas olarak kara kutu testini gerçekleştirmesi nedeniyle test edilmesi gereken bir şeydir.

KG, yalnızca performans yönlerini veya uyguladığınız düzeltmeleri önemser, KG'ye önbelleğe almayı etkinleştirmek / devre dışı bırakmak için bir mekanizma veya performansı iyileştirmek için kullandığınız mekanizmaları sağlayabilir ve ardından performans farkını doğrulayabilir. Elbette, KG aynı zamanda performansınızı arttırmış olana karşı eski bir sürümü doğrulayabiliyordu.

Önbellek çözümünü test ederken, temelde performansı test ettikten sonra uyguladık. XML sonuçları için bu önbellek çözümünü yaptık ve önbellekten sonra yanıt vermek çok az zaman alıyor. Ayrıca log girişlerini kontrol ederek sunucu loguyla kontrol ettik.