İşlevsel test nedir?
Bu bölümde Tailspin ekibine, işlem hattı için işlevsel testler tanımladıkları için katılırsınız. İşlevsel testler, yazılımın her işlevinin yapması gerekenleri yapıp yapmadığını doğrular.
Ekip ilk olarak işlevsel testin neleri kapsadığını tanımlar. Bazı işlevsel test türlerini keşfederler. Ardından işlem hattına eklenecek ilk teste karar verir.
Haftalık toplantı
Ekip haftalık toplantılarını yapıyor. Andy yayın işlem hattını gösterir. Ekip, işlem hattında başarılı bir derlemenin bir aşamadan diğerine taşınmasını izler. Son olarak, web uygulaması Hazırlama'ya yükseltilir.
İşlem hattından çok memnunum. Hayatımı çok daha kolay hale getiriyor. Bir kere, test ortamına otomatik olarak dağıtılan bir yayın alıyorum. Bu, derleme yapıtlarını test sunucularıma el ile indirip yüklememe gerek olmadığı anlamına gelir. Bu önemli bir zaman tasarrufu.
Ayrıca, Mara ve Andy'nin yazdığı birim testleri, sürüme geçmeden önce tüm regresyon hatalarını ortadan kaldırıyor. Bu, büyük bir hayal kırıklığı kaynağını ortadan kaldırır. Regresyon hatalarını bulmak ve belgelemek için zaman harcamıyorum.
Ama tüm testlerimin hala el ile olduğundan endişeleniyorum. İşlem yavaş ve ben bitirene kadar yönetime hiçbir şey gösteremiyoruz. Test önemli olduğundan zor. Test, kullanıcıların doğru deneyimi elde etmesini sağlar. Ama daha hızlı teslim etmek için baskı var.
Eminim sana yardım edebiliriz. Ne tür testler zamanınızı alır?
Kullanıcı arabirimi testlerinin olduğunu düşünüyorum. Doğru sonucu elde etmek için her adıma tıklamam gerekiyor ve bunu desteklediğimiz her tarayıcı için yapmam gerekiyor. Çok zaman alır. Web sitesinin karmaşıklığı arttıkça kullanıcı arabirimi testi uzun vadede pratik olmayacaktır.
Mara: Ui testleri işlevsel test olarak kabul edilir.
Neyin aksine, işlevsiz testler mi?
Tam olarak. Ve işlevsiz testler özellikle önemsediğiniz bir şeydir.
Tamam, kafam karıştı.
İşlevsel ve işlevsiz testler nelerdir?
Mara:İşlevsel testler , yazılımın her işlevinin yapması gerekenleri yaptığını doğrular. Yazılımın her işlevi nasıl uyguladığı bu testlerde önemli değildir. Önemli olan, yazılımın doğru şekilde davranmasıdır. Giriş sağlar ve çıkışın beklediğiniz gibi olup olmadığını denetlersiniz. Amita bu şekilde kullanıcı arabirimini test ediyor. Örneğin, puan tablosunda en üstteki oyuncuyu seçerse, o oyuncunun profilini görmeyi bekler.
İşlevsel olmayan testler performans ve güvenilirlik gibi özellikleri denetler. İşlevsel olmayan bir test örneği, kaç kişinin aynı anda uygulamada oturum açabileceğini denetlemektir. Yük testi, işlevsiz bir testin başka bir örneğidir. Bu performans ve güvenilirlik endişeleri senin önemsediğiniz şeyler Tim.
Gerçekten öyleler. Bunu bir süre düşünmem gerekiyor. İşlem hattına da otomasyon eklemek isteyebilirim, ancak ne yapmak istediğimden emin değilim. Ne tür otomatikleştirilmiş testler çalıştırabilirim?
Şimdilik işlevsel testlere odaklanalım. Amita'nın yaptığı türden bir test. Ve bu, geliştirmek istediğimiz bir alan gibi görünüyor.
Ne tür işlevsel testler çalıştırabilirim?
Birçok işlev testi türü vardır. Bunlar, test etmeniz gereken işlevlere ve normalde çalıştırmaları gereken zamana veya çabaya göre değişir.
Aşağıdaki bölümlerde yaygın olarak kullanılan bazı işlevsel testler yer almaktadır.
Duman testi
Duman testi , uygulamanızın veya hizmetinizin en temel işlevselliğini doğrular. Bu testler genellikle daha eksiksiz ve kapsamlı testlerden önce çalıştırılır. Duman testleri hızla çalıştırılmalıdır.
Örneğin, bir web sitesi geliştirdiğinizi varsayalım. Duman testiniz sitenin ulaşılabilir olduğunu ve giriş sayfasını getirmenin 200 (Tamam) HTTP durumu oluşturduğunu doğrulamak için kullanabilir curl . Giriş sayfası getirilirken 404 (Bulunamadı) veya 500 (İç Sunucu Hatası) gibi başka bir durum kodu oluşuyorsa, web sitesinin çalışmadığını biliyorsunuzdur. Ayrıca başka testler yapmak için bir neden olmadığını da biliyorsunuz. Bunun yerine hatayı tanılar, düzeltir ve testlerinizi yeniden başlatırsınız.
Birim testi
Azure Pipelines kullanarak derleme işlem hattınızda kalite testleri çalıştırma modülünde birim testleriyle çalıştınız.
Kısacası birim testi, programınızın veya kitaplığınızın tek bir işlev veya yöntem gibi en temel bileşenlerini doğrular. Beklenen sonuçlarla birlikte bir veya daha fazla giriş belirtirsiniz. Test çalıştırıcısı her testi gerçekleştirir ve gerçek sonuçların beklenen sonuçlarla eşleşip eşleşmediğini denetler.
Örneğin, bölme içeren bir aritmetik işlem gerçekleştiren bir işleviniz olduğunu varsayalım. Kullanıcılarınızın girmesini beklediğiniz birkaç değer belirtebilirsiniz. Ayrıca 0 ve -1 gibi kenar büyük/küçük harf değerlerini de belirtirsiniz. Belirli bir girişin hata veya özel durum oluşturmasını bekliyorsanız, işlevin bu hatayı ürettiğini doğrulayabilirsiniz.
Bu modülün ilerleyen bölümlerinde çalıştırılacak ui testleri birim testleridir.
Tümleştirme testi
Tümleştirme testi , tam bir sistem oluşturmak için birden çok yazılım bileşeninin birlikte çalıştığını doğrular. Örneğin, bir e-ticaret sistemi bir web sitesi, ürün veritabanı ve bir ödeme sistemi içerebilir. Alışveriş sepetine ürün ekleyen ve ardından ürünleri satın alan bir tümleştirme testi yazabilirsiniz. Test, web uygulamasının ürünler veritabanına bağlanıp siparişi karşılayabildiğini doğrular.
Katmanlı test stratejisi oluşturmak için birim testlerini ve tümleştirme testlerini birleştirebilirsiniz. Örneğin, tümleştirme testlerini çalıştırmadan önce bileşenlerinizin her birinde birim testleri çalıştırabilirsiniz. Tüm birim testleri başarılı olursa, tümleştirme testlerine daha güvenle geçebilirsiniz.
Gerileme testi
Bir özellik ekledikten veya değiştirdikten sonra mevcut davranış değiştiğinde veya bozulduğunda bir regresyon oluşur. Regresyon testi , kodun, yapılandırmanın veya diğer değişikliklerin yazılımın genel davranışını etkileyip etkilemediğini belirlemeye yardımcı olur.
Bir bileşendeki bir değişiklik başka bir bileşenin davranışını etkileyebileceğinden regresyon testi önemlidir. Örneğin, bir veritabanını yazma performansı için iyileştirdiğiniz varsayalım. Başka bir bileşen tarafından işlenen bu veritabanının okuma performansı beklenmedik şekilde düşebilir. Okuma performansındaki düşüş bir regresyondur.
Regresyon test etmek için çeşitli stratejiler kullanabilirsiniz. Bu stratejiler genellikle yeni bir özelliğin veya hata düzeltmesinin mevcut işlevselliği bozmadığını doğrulamak için çalıştırdığınız test sayısına göre değişir. Ancak testleri otomatikleştirdiğinizde regresyon testi, yazılım her değiştiğinde yalnızca tüm birim testlerinin ve tümleştirme testlerinin çalıştırılmasını içerebilir.
Sanity testi
Gizlilik testi , yazılımın çalışıyor gibi göründüğünü ve daha kapsamlı testlerden geçirilebileceğini doğrulamak için bir yazılım parçasının her bir ana bileşenini test etmeyi içerir. Akıl sağlığı testlerinin regresyon testlerinden veya birim testlerinden daha az kapsamlı olduğunu düşünebilirsiniz, ancak gizlilik testleri duman testlerinden daha geniştir.
Akıllılık testi otomatikleştirilebilir ancak genellikle bir özellik değişikliğine veya hata düzeltmesine yanıt olarak el ile yapılır. Örneğin, bir hata düzeltmesini doğrulayan bir yazılım sınayıcısı bazı tipik değerler girerek diğer özelliklerin çalıştığını da doğrulayabilir. Yazılım beklendiği gibi çalışıyor gibi görünüyorsa, daha kapsamlı bir test geçişi gerçekleştirebilir.
Kullanıcı arabirimi testi
Kullanıcı arabirimi (UI) testi , bir uygulamanın kullanıcı arabiriminin davranışını doğrular. Ui testleri, kullanıcı etkileşimlerinin sırasının veya sırasının beklenen sonuda yol açtığını doğrulamaya yardımcı olur. Bu testler, klavye veya fare gibi giriş cihazlarının kullanıcı arabirimini düzgün etkilediğini doğrulamaya da yardımcı olur. Yerel bir Windows, macOS veya Linux uygulamasının davranışını doğrulamak için UI testleri çalıştırabilirsiniz. Ya da kullanıcı arabiriminin web tarayıcılarında beklendiği gibi davrandığını doğrulamak için ui testlerini kullanabilirsiniz.
Birim testi veya tümleştirme testi, kullanıcı arabiriminin verileri doğru aldığını doğrulayabilir. Ancak kullanıcı arabirimi testi, kullanıcı arabiriminin doğru görüntülendiğini ve sonucun kullanıcı için beklendiği gibi çalıştığını doğrulamaya yardımcı olur.
Örneğin, kullanıcı arabirimi testi bir düğmeye tıklamaya yanıt olarak doğru animasyonnun göründüğünü doğrulayabilir. İkinci bir test, pencere yeniden boyutlandırıldığında aynı animasyonnun doğru göründüğünü doğrulayabilir.
Bu modülde, elle kodlanmış ui testleriyle çalışacaksınız. Ancak kullanıcı arabirimi testlerinizi otomatik olarak oluşturmak için yakalama ve yeniden yürütme sistemini de kullanabilirsiniz.
Kullanılabilirlik testi
Kullanılabilirlik testi , bir uygulamanın davranışını kullanıcı açısından doğrulayan bir el ile test biçimidir. Kullanılabilirlik testi genellikle yazılımı oluşturan ekip tarafından gerçekleştirilir.
Kullanıcı arabirimi testi bir özelliğin beklendiği gibi davranıp davranmadığına odaklanırken kullanılabilirlik testi, yazılımın sezgisel olduğunu ve kullanıcının gereksinimlerini karşıladığını doğrulamaya yardımcı olur. Başka bir deyişle kullanılabilirlik testi, yazılımın "kullanılabilir" olup olmadığını doğrulamaya yardımcı olur.
Örneğin, kullanıcının profiline bağlantı içeren bir web siteniz olduğunu varsayalım. Kullanıcı arabirimi testi, bağlantının mevcut olduğunu ve bağlantıya tıklandığında kullanıcının profilini ortaya çıkardığını doğrulayabilir. Ancak, insanlar bu bağlantıyı kolayca bulamıyorsa, profillerine erişmeye çalıştıklarında hayal kırıklığına uğrayabilirler.
Kullanıcı onay sınamaları
Kullanılabilirlik testi gibi kullanıcı kabul testi (UAT), kullanıcının perspektifinden bir uygulamanın davranışına odaklanır. Kullanılabilirlik testlerinden farklı olarak UAT genellikle gerçek son kullanıcılar tarafından gerçekleştirilir.
Yazılıma bağlı olarak, son kullanıcılardan belirli görevleri tamamlamaları istenebilir. Ya da belirli yönergeleri izlemeden yazılımı keşfetmelerine izin verilebileceğini de düşünebilirsiniz. Özel yazılımlarda UAT genellikle doğrudan istemciyle gerçekleşir. Daha genel amaçlı yazılımlar için ekipler beta testleri çalıştırabilir. Beta testlerde, farklı coğrafi bölgelerden veya belirli ilgi alanlarına sahip kullanıcılar yazılıma erken erişim elde edebilir.
Test edenlerden gelen geri bildirimler doğrudan veya dolaylı olabilir. Doğrudan geri bildirim sözlü yorumlar biçiminde gelebilir. Dolaylı geri bildirim, test edicilerin vücut dilini, göz hareketlerini veya belirli görevleri tamamlamak için gereken süreyi ölçme biçiminde gelebilir.
Test yazmanın önemini zaten ele aldık. Ancak, burada Microsoft Bulut Danışmanı Abel Wang'ın DevOps planınızda kaliteyi sağlamaya nasıl yardımcı olunacağı açıklandığı kısa bir video bulabilirsiniz.
Abel'a sorun
Takım neyi seçiyor?
Tüm bu testler önemli gibi geliyor. Önce hangisini ele almalıyız?
Andy: Zaten çalışma birimi testlerimiz var. Kullanıcı kabul testi gerçekleştirmeye henüz hazır değiliz. Duyduklarıma dayanarak, kullanıcı arabirimi testlerine odaklanmamız gerektiğini düşünüyorum. Şu anda sürecimizin en yavaş kısmı bu. Amita, katılıyor musun?
Evet, katılıyorum. Bu toplantıda hala biraz vaktimiz var. Andy veya Mara, otomatik kullanıcı arabirimi testi planlamama yardım etmek ister misin?
Kesinlikle. Ama birkaç ön hazırlık yapalım. Hangi aracı kullanmamız gerektiğini ve testleri nasıl çalıştıracağımızı tartışmak istiyorum.
Ui testleri yazmak için hangi araçları kullanabilirim?
Mara: Kullanıcı arabirimi testleri yazma konusunda seçeneklerimiz nelerdir? Bir sürü şey olduğunu biliyorum. Bazı araçlar açık kaynak. Diğerleri ücretli ticari destek sunar. Akla gelen birkaç seçenek şunlardır:
- Windows Uygulama Sürücüsü (WinAppDriver): WinAppDriver, Windows uygulamalarında kullanıcı arabirimi testlerini otomatikleştirmenize yardımcı olur. Bu uygulamalar Evrensel Windows Platformu (UWP) veya Windows Forms (WinForms) ile yazılabilir. Tarayıcıda çalışan bir çözüme ihtiyacımız var.
- Selenium: Selenium, web uygulamaları için taşınabilir bir açık kaynak yazılım testi çerçevesidir. Çoğu işletim sisteminde çalışır ve tüm modern tarayıcıları destekler. Selenium testlerini C# dahil olmak üzere çeşitli programlama dillerinde yazabilirsiniz. Aslında, Selenium'u NUnit testleri olarak çalıştırmayı kolaylaştıran NuGet paketlerini kullanabilirsiniz. Birim testlerimiz için zaten NUnit kullanıyoruz.
- SpecFlow: SpecFlow, .NET projelerine yöneliktir. Salatalık adında bir araç tarafından ilham alınmıştı. Hem SpecFlow hem de Salatalık davranış temelli geliştirmeyi (BDD) destekler. BDD, hem teknik ekiplerin hem de teknik olmayan ekiplerin iş kurallarını ve gereksinimlerini tanımlamasına yardımcı olmak için Gherkin adlı doğal dil ayrıştırıcısını kullanır. Ui testleri oluşturmak için SpecFlow veya Salatalık ile Selenium'ı birleştirebilirsiniz.
Andy Amita'ya bakar.
Bu seçeneklerin senin için yeni olduğunu biliyorum, selenium'ı seçmemizde bir sakınca var mı? Bu deneyime sahibim ve zaten bildiğim dilleri destekliyor. Selenium ayrıca bize birden çok tarayıcı için otomatik destek sağlayacaktır.
Amita: Tabii ki. Birimiz biraz deneyime sahip olsak daha iyi olur.
İşlem hattında işlevsel testler Nasıl yaparım? çalıştırılır?
Azure Pipelines'da, diğer tüm işlemleri veya testleri çalıştırdığınız gibi işlevsel testler de çalıştırırsınız. Kendinize sorun:
- Testler hangi aşamada çalıştırılacak?
- Testler hangi sistemde çalıştırılacak? Aracıda mı yoksa uygulamayı barındıran altyapıda mı çalışacaklar?
Bu soruları yanıtlayan ekibe katılalım.
Mara: Heyecanlandığım şeylerden biri, artık uygulamanın gerçekten çalıştığı üretim ortamı gibi bir ortamda test edebiliriz. Ui testleri gibi işlevsel testler bu bağlamda anlamlıdır. Bunları işlem hattımızın Test aşamasında çalıştırabiliriz.
Katılıyorum. El ile test çalıştırdığım aşamada otomatik ui testleri çalıştırırsak aynı iş akışını sürdürebiliriz. Otomatik testler bize zaman kazandıracak ve kullanılabilirliğe odaklanmamı sağlayacak.
Tim: Amita, Web sitesini Windows dizüstü bilgisayarından test ediyor çünkü kullanıcılarımızın çoğu siteyi bu şekilde ziyaret ediyor. Ancak Linux üzerinde derleyip Linux'ta Azure Uygulaması Hizmeti dağıtıyoruz. Bunu nasıl çözeceğiz?
Harika bir soru. Ayrıca testleri nerede çalıştıracağımız konusunda da bir seçeneğimiz var. Bunları çalıştırabiliriz:
- Aracıda: Bir Microsoft aracısı veya barındırdığımız bir aracı
- Test altyapısında: şirket içinde veya bulutta
Mevcut Test aşamamız tek bir iş içerir. Bu iş web sitesini Bir Linux aracısından App Service'e dağıtır. Windows aracısından kullanıcı arabirimi testlerini çalıştıran ikinci bir iş ekleyebiliriz. Microsoft tarafından barındırılan Windows aracısı Selenium testlerini çalıştırmak için zaten ayarlanmıştır.
Yine bildiklerimizle devam edelim. Microsoft tarafından barındırılan bir Windows aracısını kullanalım. Daha sonra, ek test kapsamına ihtiyacımız varsa macOS ve Linux çalıştıran aracılardan aynı testleri çalıştırabiliriz.
Plan
Mara: Tamam. Yapacaklarımız aşağıda verilmiştir:
- Microsoft tarafından barındırılan bir Windows aracısından Selenium UI testleri çalıştırma
- Test aşamasında, testlerin App Service'te çalışan uygulamadan web içeriğini getirmesini sağlayın
- Desteklediğimiz tüm tarayıcılarda testleri çalıştırma
Bu konuda Amita ile çalışacağım. Amita, yarın sabah buluşalım. Tanışmadan önce biraz araştırma yapmak istiyorum.
Amita: Harika! O zaman görüşürüz.
İşlevsel test planı oluşturma
Ekibin ilk işlevsel testlerini nasıl uygulayacaklarına karar verdiklerini gördük. Ekibiniz işlem hattına işlevsel testleri eklemeye yeni başlıyorsa (veya zaten bunu yapıyor olsanız bile), her zaman bir plana ihtiyacınız olduğunu unutmayın.
Çoğu zaman, bir kişi ekip üyelerine performans testi planını sorduğunda, kullanacağınız araçların bir listesiyle yanıt vermesi yaygın bir durum olur. Ancak araç listesi bir plan değildir. Ayrıca test ortamlarının nasıl yapılandırılacağını da çözmelisiniz. Kullanılacak işlemleri belirlemeniz ve başarının veya başarısızlığın nasıl göründüğünü belirlemeniz gerekir.
Planınızdan emin olun:
- İşletmenin beklentilerini dikkate alır.
- Hedef kullanıcıların beklentilerini dikkate alır.
- Kullanacağınız ölçümleri tanımlar.
- Kullanacağınız KPI'leri tanımlar.
Performans testinin en başından itibaren planlamanızın bir parçası olması gerekir. Bir hikaye veya Kanban panosu kullanıyorsanız, test stratejinizi planlayabileceğiniz bir alan kullanmayı düşünebilirsiniz. Yineleme planlaması kapsamında test stratejisindeki boşluklar vurgulanmalıdır. Ayrıca, uygulama dağıtıldıktan sonra performansı nasıl izleyeceğinizi ve yalnızca yayınlanmadan önce performansı ölçmeyi değil, nasıl izleyeceğinizi de öğrenmek önemlidir.