Erken ve Sıkça Test Etme

Hataları olabildiğince erken yakalamak, yazılım kalitesi sağlamanın en ucuz yoludur.Kent Beck ve Cynthia Andres şöyle yazdı: "İşte yazılım geliştirmedeki ikilem: kusurlar pahalı, ama hataları ortadan kaldırmak da pahalı.Ancak, çoğu hata onları önleme maliyetinden daha çok maliyetle sonlanır." (Extreme Programming açıklanmıştır: Embrace Change) Takımınız önlenmesi ve onun ömrü boyunca projenizin kalitesini koruyarak kusurlarını düzeltme maliyeti en aza indirmek için en iyi yöntemler ve Araçlar yardımcı olabilir.

Hataları buluyorsanız, düzeltiyorsanız ve doğruluyorsanız ekibiniz herhangi bir anda projenizin kalitesini daha fazla kesinlikte ölçebilir.Ekibiniz ve paydaşlarınız sık sık test ederek kodun geçerli durumunun farkında olur ve proje boyunca bilinçli kararlar verebilirler.Sonuç olarak "Yayınlayabilir miyiz?" sorusunu yanıtlayabiliyor ve yazılımı kullanan kişiler için etkilerini anlayabiliyor olmanız gerekir.

Bu konu, aşağıdaki yöntemleri önermektedir:

• Her bir sınıf ve her bir ana bileşen API'si için bir dizi otomatikleştirilmiş birim testi oluşturun.Birim testlerinin yazılması ekip üyelerinin zamanının %40'ını alır.Daha fazla bilgi için bkz. Microsoft Test Yöneticisi'ni Kullanarak Otomatikleştirilmiş Testler Oluşturma.

• Her kullanıcı hikayesi için testler oluşturun.Bunlar tercihen otomatikleştirilmelidir.Daha fazla bilgi için bkz. Ürün Biriktirme Listesi Öğeleri, Kullanıcı Öyküleri veya Gereksinimler için Testler Oluşturma.

• Ekip üyelerine kodu iade etmeden önce birim testlerini çalıştırmalarını hatırlatan iade ilkeleri oluşturun.Daha fazla bilgi için bkz. Add Check-in Policies.

• Testlerin tam kümesini çalıştıran sürekli veya gecelik bir yapı ayarlayın.

• Tüm kodlarınızın test edildiğinden emin olmak için test kapsamını izleyin.En az % 70'lik kapsam amacı.Daha fazla bilgi için bkz. Boşluklar Excel raporu (hızlı) sınama.

• Her sprint sonuna yakın el ile testleri çalıştırın.

Ekibiniz Microsoft Test Yöneticisi, Visual Studio Uygulama Yaşam Döngüsü Yönetimi (ALM) ve Visual Studio Team Foundation Server arasındaki tümleştirmeyi kullanarak projenizdeki test faaliyetlerini önceden yönetebilir ve ölçekleyebilir.Daha fazla bilgi için bkz. Uygulamayı Sınama.

Bu konuda

• Test Stratejisi

• Test Planlama

• Kabul Testi

• Birim Testi

• Test-Kullanımlı Geliştirme ve Erken Test

• El ile ve Otomatik Test Karşılaştırması

• Test Sonuçlarını Raporlama

Test Stratejisi

Ekibinizin testlerdeki başarısı ekibinizin boyutu, kullandığı yöntemler ve yönetim araçlarını içeren çeşitli etkenlere bağlıdır.Test sonuçlarını sürekli iyileştirmek için çevik yöntemler kullanabilirsiniz.Bu yöntemi uygulayarak, yalnızca çok sınırlı kaynaklarla test etmeye başlamakla kalmaz, aynı zamanda uygulamanızı projenizin başından sonuna uygun şekilde ayarlayabilirsiniz.

Çevik testi devreye sokarken göz önünde bulundurulması gerekenler

Çevik test varolan bir uygulamaya uygulandığında, takımınız test stratejinizi hem sprint düzeyinde hem de proje düzeyinde düşünerek başlayabilir.Oturum düzeyinde, geçerli oturumla ilgili her kullanıcı hikayesini kapsayacak bir dizi kabul testi ekleyebilirsiniz.Proje düzeyinde, uçtan uca test gibi tüm projeyi kapsayan testleriniz olabilir.Bu yöntem, iki veya daha fazla yinelemeye yayılan işlevselliği doğrulamak istiyorsanız yararlıdır.Takımınız sprint sırasında kod oluştururken her türlü testi oluşturabilirsiniz.Bu testler birim testlerini, onay testlerini ve performans testleri, güvenlik testleri ve kullanılabilirlik testleri gibi işlevsiz testleri içerir

Çevik test yöntemleri uygulamak için öncelikle uygulamanızın tarihini ve takımınızın kullandığı sistemi düşünmeniz gerekir.Hem yeni hem de varolan uygulamalara çevik test yöntemleri uygulayabilirsiniz.Projenizin tamamı için bir test planı ve projenizdeki her aşama için bir test planı oluşturmak için Microsoft Test Yöneticisi kullanabilirsiniz.Bu test planları, takımınızın test durumlarını çalıştırılan testlere öncelik tanımaya ve test sonuçlarını anlamaya yardım eden test paketleri içine düzenlemesine izin verir.Daha fazla bilgi için bkz. Ürün Biriktirme Listesi Öğeleri, Kullanıcı Öyküleri veya Gereksinimler için Testler Oluşturma.Ekibiniz çeşitli yöntemleri kullanarak test çalışmalarını test paketleri içinde gruplandırmak için Visual Studio ALM kullanabilir:

• Testlerin sabit grubunu oluşturma ve düzenleme.

• Dinamik bir grup test çalışmasını oluşturmak ve yönetmek (yani test çalışmalarını öneme göre bulmak) için bir sorgu kullanmak.

• Test çalışmalarının gereksinime bir bağlantısının olduğu bir test planına kullanıcı hikayesi veya gereksinim ekleme.

• Diğer test planında bulunan bir test paketini kopyalar.

Daha fazla bilgi için bkz. Test Paketlerini Kullanarak Test Durumlarını Düzenleme.

İkinci olarak, kodunuzun test edilebilir olduğunu dikkate almanız gerekir.Bunu öğrenmek için uygulamanızın mimarisini ve düzenlerini anlamanız gerekir.Model Görünümü Denetleyici (MVC), Model Görünümü ViewModel (MVVM) ya da Model Görünümü Sunucu (MVP) modelleri kullanıyorsanız, kullanıcı arabirimi testinin kötü etkisi olmadan belirli işlevleri yalıtabilir ve işlevsel testleri çalıştırabilirsiniz.Ancak, bu her zaman gerçek durumu temsil etmez.Örneğin, uygulamanızın yeniden düzenleme bölümleri için işlevleri ayıramazsınız ve kodun belirli alanlarına yalnızca kullanıcı arabirimi veya ağ olay işleyicileri üzerinden erişebilirsiniz.Test kalitesini görünür derecede iyileştirmek istiyorsanız, test edilebilir kod yüzdesini arttırmalısınız.Bu desenleri hakkında daha fazla bilgi için bkz. ASP.NET Model View Controller (MVC).

Üçüncü olarak, çevik test uygulamadan önce takımınızın yeteneklerini dikkate almanız gerekir.Bazı ekip üyeleri siz işlevsellikleri uyguladığınızda birim testleri oluşturabilmelidir.Bazı ekip üyeleri uygulamanızın iş kurallarıyla ilgili bilgiye sahipse el ile kullanım durumları ve iş akışı testleri oluşturabilmeli ve tanımlayabilmelidir.Ayrıca, diğer ekip üyeleri gerekli teknik becerilere sahip olmak kaydıyla, el ile yapılan bu testlere dayalı otomatik ve daha ayrıntılı testleri oluşturabilmelidir.

Test yaşam döngüsü nasıl yönetilir

Test işlemi projeniz boyunca kullanacağınız, yinelemeli bir işlemdir.Aşağıdaki adımlara bakın:

1. Test hedeflerini netleştirin ve tüm ekibinizin bunları kabul ettiğinden emin olun.Bu hedeflere dayalı olarak, test stratejinizi belirleyin.Örneğin, stratejiniz "Testler her iadeden önce çalıştırılacak, birim testlerinde %70 kod kapsamı olacak ve her kullanıcı hikayesinde en az bir otomatik test olacak" şeklinde olabilir.

2. Geçerli sprint üzerinde kullanıcı hikayeleri, tasarım varsayımları ve işlevsel olmayan gereksinimlerine göre test planınızı tanımlayın.

   1. Kullanıcı hikayelerini biriktirme listesine ekleyebilir ve ilerideki sprint'ler için planlayabilirsiniz.Her test planı için en az bir sprint ile eşleştirmeniz ve bu nedenle sprinteki tüm kullanıcı öyküleri için test adımlarınızın olması gerekir.

3. Kabul testleri, birim testleri, işlevsel testler ve performans testleri gibi yapı testi çalışmaları tanımlayın.

4. Testleri, test paketleri içinde gruplandırın.Bu test paketlerini sınama çabanıza kılavuzluk etmeye yardımcı olan tanımlı test planlarına sığdırabilirsiniz.

5. Test paketlerini ve test çalışmalarını içerenleri sprint boyunca sürekli çalıştırın.Testleri bir sprint içinde erkenden çalıştırmaya başlayın ve test paketlerine test çalışmaları eklemeye devam edin.Önemli sınav koşulları ve durumları tanımlamak istiyorsanız, araştırmacı test uygulayabilir ve takımınız içerisinde sık görüşmeler yapabilirsiniz.

6. Durumunu tamamlanmış olarak ayarlamanızdan önce kullanıcı geçmişine yönelik kabul testlerinin denetiminizden geçtiğinden emin olun.

Her ne kadar, iş akışı yazılım dökümüne bağlı olarak çok daha karmaşık olabilse de, önceki şekil ana bileşenler arasındaki iş akışı özünü yakalar.

• Kod yapılar oluşturur.

• Kodu, tanımlanan iş, test planları ve yapı kalitesi etkiler.

• Test planlarını, test suit ve test durumlarında, planlanan hedeflere ve bu resimde görünmeyen projeyi diğer yönlerini tarafından etkilenmiştir.

• Kod üzerinde yapılan değişiklikler test çalışmalarını etkileyebilir.

Hataları Sabitleme

1. Hatalarla mümkün olduğunca erken ilgilenmeniz gerekir.Ciddi bir hata, etkilediği kullanıcı hikayelerinin tamamlanmamış olduğu anlamına gelir.

2. Test veya diğer eylemler üzerinde bulunan hatalar için hata iş öğeleri oluşturun.Kullanıcı hikayelerini ne derece etkilediğini belirtmek üzere hatanın önemini ayarlayın.0 Ya da 1 gibi yüksek bir önem derecesi önemli kullanıcı hikayelerinin uygulanmadığını veya kullanıcıların hikayeye ulaşmak için önemli geçici çözümler uygulaması gerektiğini gösterir.3 gibi düşük bir önem derecesi, kullanıcıların ekstra bir iş olmaksızın hala ana hedeflerine ulaşabileceklerini gösterir.

3. Ekibinizdeki diğer kişilerle her hata için uygulanacak eylem planına karar vermek için birlikte çalışın.

4. Hataları düzeltir düzeltmez çözümleyin.Hata, doğrulanması için başka bir kişiye atanmalıdır.Hataları olabildiğince çabuk doğrulayın ve kapatın.

5. Hataların durumunu izleyinHer yinelemenin sonundaki geriye dönük toplantıda Hata Eğilimleri raporuna bakın ve sıra dışı artışların sebebini bulmaya çalışın.Daha fazla bilgi için bkz. Hata Eğilimleri Raporu.

Test Planlama

Test planlama Ekibiniz proje büyük resmi anlamak için Yardım süreci ve ekibiniz için her türlü test hazırlama sürecindedir.Çevik test sprint düzeyinde başlar.Her sprint'te, takımınız bu sprint içinde oluşturulan kullanıcı öykülerini doğrulamak için testler oluşturur.Takım hem mevcut ve hem de önceki oturumlarda oluşturulan testleri çalıştırır.Projenin ilerlemesi boyunca, tüm işlevsellikleri kapsayan çok sayıda test oluşturulmuştur.Aşağıda şekil projenizdeki test planları için bir şablon gösterir.

Her bir sprint ve proje için test planı oluşturma

Ekibiniz Visual Studio ALM'un test özelliklerini kullanarak, testleri artımlı olarak planlayabilir, düzenleyebilir, yürütebilir ve raporlayabilir.Ekibiniz test planları için bir şablon oluşturabilir ve ekip üyeleri test paketlerini doldurabilir.Bir test planında, takımınız otomatikleştirilmiş veya el ile test durumlarını nerede kullanacağınızı belirleyebilir.

Projenizdeki her sprint için, test planı oluşturmaya başlayabilirsiniz.Bu planı kullanarak, ekibiniz geçerli oturumda işlevselliği doğrulamaya odaklanabilir.Her ne kadar, plan en başta boş olsa da, onu test çalışmalarında yer tutucu olarak kullanabilirsiniz.Test durumlarını uygun test paketleri içinde düzenleyebilirsiniz.Proje katılımcılarından zamanında geri bildirim almak isterseniz erkenden bu test adımlarını ve bir sprint oluşturmanız gerekir.

Ayrıca, projenizin tamamını kapsayan bir test planı oluşturabilirsiniz.Proje test planlarını, testleri önceki test sprintlerinden birleştirmek ve tüm proje için uygulanan test paketleri düzenlemek için kullanabilirsiniz.Ekibiniz daha büyük projeler oluştururken istikrar ve akış sağlamak önemli olduğundan regresyon testi paketlerini çalıştırmaya devam etmeniz gerekir.Özellikle, yakınlık bulunmayan daha geniş ve dağıtılmış ekiplerle çalışıyorsanız, gerileme test paketleri geçişli etkileri olan değişikliklere dayalı hataları yakalayabilir.Doğru ölçüler doğru yerde olmadığında bu hataların yakalanması çok zordur, döngü ilerledikten veya teslimden sonra yakalanabilirler.

Bazı ekipler tüm projeyi kapsayan bir test planı tanımlamak isteyebilir.Bu tür test planları, bir miktar sprint içindeki ilgili işlevselliği doğrulayabilir ve proje boyunca çalıştırılan test paketlerini içerebilir.Örneğin, bir özelliği özelliğin tamamı tamamlandığında kullanıcılar arasında yaygınlaşan bir özelliği test edebilirsiniz.

Sprint öncesinde kabul testleri tanımlama

Sprint öncesinde kabul testleri tanımlamanız gerekir.Bu kabul testleri bir kullanıcı hikayesinin tam olup olmadığını belirlemenize yardım edebilir.Kabul test durumlarını, bir test planında her sprint için Kabul Testleri adı verilen bir test paketi oluşturduysanız izleyebilirsiniz.Daha fazla bilgi için bu konuda Kabul Testi bölümüne bakın.

Bir oturum sırasında birim testleri oluşturun

Bir sprint sırasında ekibinizin birim testlerini oluşturması gerekir.Birim testleri kodu yürütmek için kullanılan zaman ve kaynak maliyeti gibi kod başarımını doğrulayabilir.İşlevsel olmayan testler (performans testleri ve güvenlik testleri) gibi diğer test türleri oluşturulabilir ve uygun test paketlerine eklenebilir.Maliyetleri kolayca tanımlayabilmeniz için bu test paketlerini düzenlemelisiniz.

Yüksek kullanım alanlarında odaklama testi

Yazılımınızda yüksek değişkenliğin nerede olduğunu anlamak sıcak noktaların da nerede olabileceğini belirler.Kullanıcı girişi, yazılımı çalıştıran ortam, ağ ve donanım yazılım içindeki etkin noktaların takımınızca keşfedilmesini sağlayan yapılandırma değişkenleri örnekleridir.Bir durum nadiren oluşuyorsa ya da bir test sırasında oluşan karışık sayıda durumlar varsa, bir hatanın olası etkileri çok yüksek değilse testin değeri azalır.Genel olarak, işlevsellik yalıtımı mümkün olduğunca tercih edilir.Yüksek etki bırakan durumların sınanması da büyük önem taşır.Microsoft Test Yöneticisi kullanarak yapılandırmaların yönetilmesi hakkında daha fazla bilgi için bkz. Test Yapılandırmaları - test platformlarını belirtme.

Varolan projeler için, en yüksek sayıda hata bulunan alanları izleyin ve hataların neden var olduğunu saptayın.Bu alan temel varsayımları gözden kaçırabileceğinden kod karmaşasını da izleyin.Kod hataları nedenlerinden bazıları yalnızca durumları değil (örneğin, ağ ve kullanıcı birimi) kodu yönetme zorluklarını içerir.

Kabul Testi

Kabul testleri, kullanıcı hikayelerini doğrular.Bu testler, sadece projenin yaşam döngüsü boyunca müşterilerin ihtiyaçlarını başarıyla derlemeyi sağlamaz, aynı zamanda müşterilere karşı güven oluşturur ve onaylanan sorumlulukları gösterir.Daha fazla bilgi için Microsoft Web sitesindeki şu sayfaya bakın: Onay Testi Mühendisliği Kılavuzu.

Kabul testine nasıl başlanır

Microsoft Test Yöneticisi öğesini açın ve ardından test planınızda Kabul Testleri olarak adlandırılan bir test paketi oluşturun.Ekibiniz her sprint için kabul testlerini gruplandıran en az bir test paketine sahip olması gerekir. Daha fazla bilgi için bkz. Test Planı Tanımlama.

El ile testlerden otomatik testlere geçme

El ile yapılan testlerin tanımlanması otomatik testlerden daha kolay olmasına rağmen daha pahalıdır.Bu nedenle, el ile testler ile başlayıp, daha önemli olanları yavaş yavaş otomatikleştirilmiş testlerle değiştirmek iyi bir stratejidir.

Önce, sprint için tanımlanmış olan her bir kullanıcı hikayesini doğrulamak için el ile test çalışmaları kümesi oluşturmaya başlayın.Bir sprintin başında kod olmadığı için, bir test çalışması bir kullanıcı hikayesinin parçalarıyla eşleşen yüksek seviyeli eylemleri anahatlarıyla belirtmelidir.Örneğin, bir test çalışmasının bir adımı "Kimliği doğrulanmış bir kullanıcı olarak, ...yapın" olabilir. El ile bir test çalışmasıyla başlamak ekibinizin sprint başlamadan önce ideal kabul testlerini hızlı bir şekilde tanımlamasına olanak sağlar.

İkinci olarak, ekibiniz kullanıcı hikayelerini sprint içine uygulayan bir koda sahip olduğunda, belirli kullanıcı deneyimlerini yansıtmak için kabul testlerini gözden geçirin ve güncelleştirin.Ancak, takımınız varolan kabul testleri kümesini değiştirmek istemezse, testleri yeni bir sınav paketine içeri aktarabilir ve daha ayrıntılı testler için bir başlangıç noktasına sahip olabilirsiniz.Örneğin, daha ayrıntılı bir test çalışmasının bir adımı "Kullanıcı adı metin kutusuna adı yazın ve banka hesabına giriş yapmak için Giriş düğmesini seçin" olabilir.

Üçüncü olarak, kabul testlerine dayanarak, eylem kaydı kullanma yoluyla kodlanmış kullanıcı arabirimi (UI) testleri oluşturur.Daha fazla bilgi için bkz. Varolan Eylem Kaydından Kodlanmış UI Testi Oluşturma.İşlevselliği izole eden adımlar oluşturursanız kodlanmış Kullanıcı Arabirimi testleri daha temiz bir kod oluşturabilir.El ile test çalışmalarına kodlu UI testi iliştirirseniz test planınızdan otomatikleştirilmiş testler çalıştırabilirsiniz (Daha fazla bilgi için bkz. Nasıl yapılır: Otomatikleştirilmiş Testi, Test Çalışmasıyla İlişkilendirme.)

Bir sprint başlangıcında tanımlanan el ile testler otomatikleştirilmiş testler oluşturmanıza yardımcı olabilir.Kod veya kullanıcı değişikliklerle karşılaşırsa, otomatik testlerin güncellenmesi gerekeceğinden ve el ile testlerin bir kişi tarafından çalıştırılması gerektiğinden, otomatik ve el ile testlerin bir bedeli var.Daha fazla bilgi için, bu konuda El ile ve Otomatik Test Karşılaştırması bölümüne bakın.

Kabul testi olgularını kim çalıştırıyor?

Ekibiniz, ürün sahibiniz ve müşterileriniz kabul testi çalışmalarını çalıştırabilirler.Ekibinizin bir sprintte geçmesi gereken testlerin bir kümesindeki taban çizgisini sağlamak için onları mümkün olduğunca sık çalıştırması gerekir.Müşteri de ürün sahibi de kabul testlerini çalıştırabilir ve sprint'i başarıyla tamamlamak doğrulama gerektirebilir.

Ekibiniz her kabul testi çalışmasını çalıştırmak ve test sonuçlarının ekran görüntüsünün bir videosunu kaydetmek için Microsoft Test Yöneticisi kullanabilir.Bu şekilde test sonuçlarının görsel kaydını alabilir ve sonuçları müşterileriniz ile de paylaşabilirsiniz.Bu, gerekli yapılandırmaların oluşturulmasının zor olduğu durumlarda (örneğin, çoklu sunucu yapılandırmaları) faydalıdır.

Kullanıcı öyküleri ile birlikte kabul test çalışmaları tanımlama

Kullanıcı hikayelerini tanımladıktan hemen sonra kabul kriterlerini tanımlayabilirsiniz.Kabul testlerini tanımlayarak, ekibinizin geçerli oturumla ilgili olarak ürün sahibi ve müşterilerden gelen kabul kriterlerini anlamasına yardımcı olabilirsiniz.Müşterinin kabul testlerini kabul etmesi gerektiği için, sprint başlamadan önce kabul testi olgularını oluşturmak iyi bir fikirdir.

Birim Testi

Birim testleri bileşen, sınıf, yöntem veya özellik seviyesindeki işlevselliği doğrulayan otomatik testlerdir.Birim testleri projenin uzun dönem dengesini ve gelecekte devamlılığını sağlayan otomatik ve gerileme testlerinin temelidir.

Birim testleri uygulamamın tasarımının gelişmesine nasıl yardım eder?

Sınanan kodu oluştururken birim testlerini oluşturma işlemi kodun şeklini tanımlamaya yardımcı olur.Birim testleri kullanılarak test edilebilen kodlar oluşturabilirsiniz.Kod için birim testleri oluşturmada zorluk kodun yeniden işlenmesi gerektiğini belirtir.

Birim testlerimi nasıl düzenleyebilirim?

Kod yazan her ekip üyesi yapılandırdıkları bileşenler için birim testleri oluşturmalı ve birim testi kodunu Visual Studio proje içindeki sürüm denetimine iade etmelidir.Test çalışması iş öğelerini her yapı boyunca sürekli tümleştirme ile çalışacak bir yapı doğrulaması içinde ve ayrıca ilgili kullanıcı hikayesini doğrulayan test paketi içinde dosyalayın.

Test kodunu değiştirmek zorunda kalmadan, birim testlerin değişkenini nasıl yönetirim?

Test girişlerindeki sapma proje kodundaki işlevselliği doğrularken testler arasındaki benzerlikleri veya farklılıkları tanımlar.Örneğin, Web uygulaması için oturum açma bileşenleri test edilirken, kullanıcı hesabı oluşturmak için çeşitli parola türleri sağlayabilirsiniz.Sistem, kullanılan karakter türlerinin birleşimi ve sırası için kurallar içerebilir.

Visual Studio Test Professional verilere bağlı birim testleri yazmak için yeteneği sağlar ve kodlanmış UI testleri.Daha fazla bilgi için, bkz. Nasıl Yapılır: Veri Temelli Birim Testi Oluşturma ve Nasıl yapılır: Verilerle Çalışan Kodlanmış UI Testi Oluşturma.

Test-Kullanımlı Geliştirme ve Erken Test

Test-kullanımlı geliştirme (TDD), her bir kod satırının programcının kodlama yapmadan önce yazdığı bir teste karşılık yazıldığı bir tasarım ve programlama disiplinidir.Uygulamak istediğiniz kodun tüketicisi olma fikri oldukça güçlüdür ve kodun nasıl kullanılması ve tasarlanması gerektiği konusunda gerçekçi bir beklenti içerir.

TDD'de geliştirici pek çok küçük artımla çalışır.Her küçük artışın geliştirilmesi, birkaç dakika ile birkaç saat arasında sürer.Genellikle böyle bir çok artış kullanıcı hikayesini oluşturur.Geliştirici, kullanıcı hikayesi çalışırken testleri ve kodu iade edebilir.Geliştirici aşağıdaki döngüde çalışır:

1. Artış yazıldığında geçmesi beklenen otomatik bir test yazın.

2. Testin çalıştığından emin olmanıza yardımcı olması için yeni testin başarısız olduğunu doğrulayın.

3. Testin geçmesini sağlayacak bir kod yazın.

4. Başarılı olduğunu doğrulamak için testi çalıştırın.

5. Ayrıca, hiçbir hatanın meydana gelmediğinden emin olmak için aynı bölge üzerinde diğer tüm testleri yürütün.

6. Gerekiyorsa, kodu yeniden düzenleyerek davranış eklemeden yapısını geliştirin.Kodun çalışmaya devam ettiğinden emin olmak için testleri yeniden çalıştırın.

7. Tam kullanıcı hikayesi uygulanana kadar tüm bu adımları yineleyin.Yukarıdaki adımlar tam bir hikayeye entegre edildikçe, tam hikayeyi doğrulayan testler ekleyin.

8. Uygulama kodu ve birim testlerini iade edin.

Erken test yöntemlerine ilgi duyuyorsanız el ile testleri (veya el ile kabul testleri) oluşturarak başlayabilirsiniz.Bu elle testler, kodlu bir UI testi oluşturarak otomatikleştirilebilir.(Daha fazla bilgi için bkz. Nasıl yapılır: Test Altındaki Uygulama Kaydı Tarafından Kodlanmış UI Testi Oluşturma.) Visual Studio ALM öğesindeki birim testi çerçevesini kullanan tümleştirme testleri, uygulanan işlevselliği doğrulamak için oluşturulabilir.Yinelemenin başında oluşturulan test durumları hem işlevselliğini doğrulamaları ve hem de hataları bulmaları için yinelemede erken çalıştırılır.Bu test paketleri ve test durumları proje süresince gerileme testi olarak aralıksız çalıştırılabilir.Bu testleri çalıştırmaya devam ederek, yinelemede daha önce bulunan hataların ve doğrulanmış işlevselliğin, projede sonradan yapılan değişikliklerden etkilenmemesini sağlarsınız.

Sürekli tümleştirme için ünite testlerini kullanın.

Erken test uygulaması sırasında oluşturulan birim testleri geçerli sprint ve kullanıcı hikayesi için test paketi içinde düzenlenmelidir.Bu birim testleri, proje çapındaki test planlarına yükseltilebilir ve takım tarafından sürekli tümleştirme döngüsü içinde düzenli aralıklarla çalıştırılabilir.Ünite testleri aynı zamanda tümleştirme, yükleme ve başarım testleri için de temel görevi görür.

Başlangıçta oluşturulan birim testleri sürekli tümleştirmenin bir parçası olarak kullanılabilir.Bir yapı sırasında testleri çalıştırma hakkında daha fazla bilgi için bkz. TestToolsTask Task.

Test yapılandırmalarını yönetmek için sanallaştırma kullanın

Birim testleri çalıştırmak için Hyper-v resimleri yönetilen ortamlar kümesi oluşturabilirsiniz Microsoft Test Yöneticisi. Kullanarak bir test planından otomatikleştirilmiş testleri çalıştırma hakkında daha fazla bilgi için Microsoft Test Yöneticisi, bkz: Nasıl yapılır: çalışma otomatik Microsoft sınama Yöneticisi'ni kullanarak laboratuar ortamında sınama.

El ile ve Otomatik Test Karşılaştırması

Otomatik ve el ile test çalışmaları tamamlayıcıdır.Çevik ekipler, sık ya da sürekli test çalıştırmasını desteklediğinden daha fazla otomatik test çalışması edinmeyi hedefler.Testleri sürekli çalıştırmak için hızlı ve sıkça bir biçimde yürütülmeleri gerekir ki bunu yapmak elle testle zordur.

Elle ve otomatik test durumlarına ilişkin bir dağıtım hakkında karar verirken, üzerinde düşünülmesi gereken birçok husus vardır.

Kuruluşunuzun becerileri test türleri dağıtımınızı nasıl etkiler?

Ürün sahibi kullanıcının projeye ilişkin öykülerini tanımlamasına yardımcı olur ve kabul testlerinin oluşturulmasına da katkıda bulunmalıdır.Ürün sahibi, büyük olasılıkla kodlanmış testleri üretmeyecek ancak iş etki alanına ilişkin önemli bilgi sahibi olacaktır.Bu nedenle, ürün sahibi tarafından tanımlanan test durumları, iş kuralları ve iş sözlüğü düzeyinde olacak.Örneğin, bir nakliye şirketindeki ürün sahibi işi tarafından desteklenen farklı taşımacılık yollarını belirtir (örneğin, kamyon, tren, hava yolu, deniz yolu veya bunların birleşimi).Ürün sahibi, daha sonra farklı olasılıkları deneyeceği çeşitli test çalışmalarını tanımlayabilir.Bu el ile testler için, farklı seçenekleri (bu durumda nakliye araçlarının) çalıştıran en az sayıda testi belirtmek önemlidir.

Manüel testlere dayanabilen veya herhangi bir diğer testten bağımsız olabilen UI testlerinin kodunu belirleyen ekip üyeleri.Daha fazla bilgi için bkz. How to: Generate a Coded UI Test by Recording the Application Under Test.Kodlanmış UI testleri yönetmek ve proje kodu geliştirme yeteneğine sahip ekip üyeleri tarafından desteklenmelidir.

Ne zaman el ile yapılan testleri otomatik testlere dönüştürmeli veya baştan otomatik testler oluşturmalısınız?

Kodunuzun istikrarını korumak için testleri tekrarlı bir şekilde çalıştırmayı düşündüğünüzde otomatikleştirilmiş testler oluşturabilirsiniz.Otomatikleştirme yatırımı takımınızın kaynaklarını etkilediğinden, otomatikleştirilmiş testlerin oluşturulmasındaki çabayı göz önüne almak önemlidir.Yatırımda (ROI) daha düşük düzeyde test karmaşası nedeniyle daha yüksek düzeyde geri dönüş olduğu halde kodda düşük düzeyde karmaşıklık sonucu bulunduğunda otomatik testler oluşturma.Ancak, otomasyonu erken oluşturmak değerlidir çünkü hem tasarım hem de mantık sorunlarını keşfetmeye yardımcı olacaktır.Her iki durumda da, otomatik test kodu desteklemek için gerekli olan kaynakların dikkate alınması gerekir.

Test kümesinin otomatikleştirilmesine karar verdikten sonra, otomatikleştirme yararları arasında kod istikrarının yönetilmesi de olduğundan, otomatikleştirme işlemini mümkün olan en kısa sürede tamamlamaya çalışın.Kararlılık ve otomasyon yazılırken bulunan hataların sayısı, otomasyonu tamamlamak için gerekli olan çabayı etkiler.Sonuç olarak el ile yapılan testler ve otomatik testler arasındaki denge, projenin yaşamı sırasında oluşturulmasına ve çalıştırılmasına ihtiyacınız olan test türlerine öncelik verilmesiyle ilgilidir.

Hangi tür testler otomatiktir?

Birim Testleri

Birim testleri işlevselliği kodda veya TDD adı verilen bir yordam yoluyla doğrular.Birim testleri önemlidir. Çünkü kodun içindeki dengenin ve bağımlılıkların korunmasını sağlarlar.TDD, ayrıca tasarım kod tüketicisinin bakış açısından anlamanıza yardımcı olacağından, bağımlılıkları ve iyi katman tanımı ile daha iyi tasarım üretme eğilimindedir.

Yükleme Testleri

Varolan otomatikleştirilmiş test durumlarını temel alan yük testleri oluşturabilir veya uygulamalarda ya da hizmetlerde belirli yük türleri oluşturan testler oluşturabilirsiniz.Benzetilen test yüklemeleri oluşturmak için test yardımcı denetleyicilerini ve test denetleyicilerini kullanma hakkında daha fazla bilgi için bkz. Nasıl yapılır: Test Denetleyicileri ve Test Aracıları Kullanarak Test Çalıştırma.

Visual Studio ALM ile yük testi hakkında daha fazla bilgi için, Microsoft Web sitesindeki şu sayfaya bakın: Yükleme Testlerini Anlama.

Sürekli Tümleştirme Testleri

Visual Studio ALM ile sürekli tümleştirmeyi, kod her geliştirildiğinde ve iade edildiğinde, varolan kodla düzgün çalıştığından emin olmak için kullanabilirsiniz.Ekibiniz ve kod tabanınız genişlediği için sürekli tümleştirme önemlidir.Test parametrelerini içeren bir yapı türü tanımlayabilir ve yapıyı tamamlandıktan sonra hangi testlerin çalıştırılacağını belirleyebilirsiniz.Test adımları oluşturma hakkında daha fazla bilgi için bkz. Varsayılan şablonu temel yapı işlemi tanımla.

Hangi tür testler otomatik olabilir?

Yapılandırmayı Test

Birden fazla kurulu ortam üzerinde sınama işlemi zahmetli bir görev haline gelebilir.Microsoft Test Yöneticisi, sanal makineleri ya da fiziksel makineler kullanarak farklı yapılandırmalarda test takımları çalıştırma yetenekleri sağlar.Çoklu ortamlarda veri toplama ve testleri çalıştırmayla ilgili daha fazla bilgi için bkz. Testleri Çalıştırmak veya Veri Toplamak için Test Makinelerini Ayarlama.

Kullanıcı Arabirim Testleri

Visual Studio ALM doğrudan kullanıcı arabirimi için otomatik testler oluşturma yeteneğine sahiptir.Kodlanmış kullanıcı arabirimi oluşturma hakkında ayrıntılı bilgi için bkz. Kodlanmış UI Testi Nasıl Oluşturulur.

Yükleme Testleri

Yükleme programlarının beklendiği gibi çalışıp çalışmadığını doğrulamak için kullanabileceğiniz bir grup yapılandırma ayarı yapmak üzere Microsoft Test Yöneticisi laboratuvar özelliklerini kullanabilirsiniz.

Otomasyona engeller nelerdir?

Ekibin yetenekleri

Otomasyonun oluşturulması test ekibinin alt kümesinin kodun nasıl yazılacağını öğrenmesini gerektirir.Otomasyon oluşturmanın öğrenim eğrisini ve test kodunun tasarımını uygulamayı planlayın.Devamlılık, birleştirme kolaylığı ve dayanıklılık gibi istediğiniz hedefler için otomasyon kodunuzu üretim koduna benzer şekilde tasarlayın.

Visual Studio Test Professional kullanarak otomatik testler oluşturma hakkında daha fazla bilgi için bkz: Microsoft Test Yöneticisi'ni Kullanarak Otomatikleştirilmiş Testler Oluşturma.

Kod karmaşası

Sık değişen kod hareketli bir hedeftir ve aynı zamanda değiştirilmesi de gerekeceği için test otomasyon kodu içerisinde geçişli etkilere sahip olacaktır.Değişme ihtimalleri daha az olan bileşenler ve arabirimler için test otomatikleştirme kodu oluşturarak peş peşe gelen bu etkilerden kaçının.

Kod tasarımı

Kodun farklı kısımlarını doğrulamak için gerekli olan izolasyona sahip kodu yazmaya yönelik ASP.NET MVC ve MVVM kılavuz ekip üyeleri gibi kod çerçeveleri.Kullanıcı arabirimine sıkı bir şekilde bağlı olan kodun test edilmesi zordur çünkü kullanıcının kullanıcı arabirimi denetimleri ile etkileşime girmesini gerektirebilir.

El ile test çalışmalarının yaraları nelerdir?

El ile test çalışmaları aşağıdaki faydaları sağlar:

• El ile yapılan testler, ekibinizin keşif sürecinde hataları bulmasına yardımcı olur.

• Herhangi bir soyutlamadan adım grupları tanımlayıp, başarı ve başarısızlığı istediğiniz şekilde belirleyebileceğiniz için el ile test çalışmalarının tanımlanması kolaydır.

• Proje başlangıcında, hiç bir kod yazılmadan önce el ile test durumlarını yazmaya başlamak çok daha kolaydır.Bu, kabul testlerini tanımlama işlemi sırasında önemlidir.

• Visual Studio Test Professional kullanıyorsanız, test çalışmaları yardımcı benzer testleri tanımlarken zaman Paylaşılan adımlardan oluşur ve takımınızın testin alt tek bir sürümünü sağlar.Paylaşılan adımları kullanmak aynı zamanda test çalışmalarını değiştirirken de yardımcı olur. Çünkü paylaşılan adımlara yapılan bir değişiklik otomatik olarak paylaşılan adımları kullanan tüm test çalışmalarını değiştirir.Paylaşılan adımların oluşturulması ve kullanımı hakkında daha fazla bilgi için bkz. How to: Share Common Test Case Steps Using Shared Steps.

• El ile test çalışmaları, proje veya sprint'te erken iletişimin bir yolu olabilir.

• El ile test çalışmaları, kodun hiç kimse tarafından incelenmediği otomatik test çalışmasını belgelemenin bir yolu olabilir.

• Visual Studio ALM öğesini kullanıyorsanız, el ile testleri çalıştırma kod kapsamı ölçümleri toplayabilir.

El ile test çalışmalarının açıkları nelerdir?

El ile test çalışmaları aşağıdaki eksikliklere sahiptir:

• Başarı kriterlerinin tanımlanması zor olabilir çünkü testin açıklamasında kullanılan perspektif ve dile dayalıdır.Bazı diller farklı bir şekilde yorumlandırılabilir ve bu hata oluşmasına fırsat verebilir.

• El ile test çalışmaları içeren test takımlarını çalıştırmak, test adımlarını ve rapor sonuçlarını fiziksel olarak takip etmek için bir kişi gerektirir.Bu işlem çok zaman alabilir ve ya testleri uygulamak için daha fazla takım üyesi ya da test grubunu çalıştırmak için daha fazla zaman gerektirir.Visual Studio Test Professional kullanarak takım "sarma el ile test," hangi eylemleri sınaması sırasında kaydedildiği, ardından gelecek test çalıştırmalarını çalıştırılabilmesi için kullanabilirsiniz.

• Kodun istikrarına bağlı olarak, testleri çalıştırmak için gerekli çaba ve süre değişiklik gösterir.Bunun sonucunda, el ile testlerin yürütülmesi ekipteki akışı etkileyebilir.

• En büyük eksiklik, elle yapılan testlerin bir yanlışı saptarken insan hatasına yatkın olmasıdır.Sınayıcılar açıkça göz önünde olmasına rağmen hatayı tanıyamayabilir.

Otomatik test çalışmalarının yararları nelerdir?

Otomatikleştirilmiş test çalışmaları aşağıdaki faydaları sağlar:

• Otomatikleştirilmiş testler, istikrarı korumaya ve kod değişikliği nedeniyle oluşabilecek gerilemeleri bulmaya yardımcı olur.

• Otomatikleştirilmiş testler katılımsız çalıştırılabilir.

• Otomatikleştirilmiş testler yazılımdır ve yeniden kullanılabilir kodlardan tasarlanıp oluşturulabilir.Bu, otomatikleştirilmiş testleri esnek ve sürdürülebilir kılar.

• Otomatikleştirme, Microsoft Test Yöneticisi kullanılarak birden çok yapılandırmada çalıştırılabilir.

• Otomatik testler çalıştırıldığında kod kapsama ölçümleri toplanabilir.

Otomatik test çalışmalarının açıkları nelerdir?

Otomatikleştirilmiş test çalışmalarının aşağıdaki eksiklikleri vardır:

• Özel durumlar göz önünde bulundurulmalı ve kod kullanarak uygulanmalıdır.Otomasyon oluşturulur ve çalıştırılırken, ek koşullar keşfedildikçe uygulanacaktır.

• Kod değiştirildiğinde veya yeniden düzenlendiğinde, etkilenmiş otomatik testleri değiştirmek için eş değerde çaba gerektirecek peş peşe gelen etkiler olabilir.

• Kod değişiklikleri birçok testin başarısız olmasına neden olursa, takımınızda psikolojik etkiye sebep olabilir.Bu testler bayrak olarak kullanılırsa, takım herhangi bir bayrağı yükseltmek istemeyebilir.

• Test durumları doğru şartlar için sınanmıyorsa, tüm testler başarılı olduğunda yanlış bir güvenlik hissine kapılabilirsiniz.Test paketlerini korumak ve doğru durum ve sonuçları doğruladıklarından emin olmak önemlidir.

Test Sonuçlarını Raporlama

Kıvrak bir bakış açısından, hata veya toplama ölçümlerine dayanan Team Foundation Server geçerli kalite durumu raporlaması, takımın yinelemesine ve kodda, proje planında ve test planında değişiklik yapmasına izin veren geri bildirim döngüsünün parçasıdır.Daha fazla bilgi için bkz. Test planı ilerleme raporu.

Microsoft Test Yöneticisi'nde test planı sonuçlar özelliğini kullanarak, test planınızın ilerlemesini de izleyebilirsiniz.Test planı sonuçları sayısal İstatistikler ve grafikler üzerinde geçti, başarısız ve etkin testleri içerir.Ayrıca, test planı sonuçlarını ayrıntılı hata türleri ve çözünürlük verileri gösteren grafikler içerir.Eklenecek veya belirli test paketleri, test planınızda test planı sonuçları filtre uygulanabilir.Ayrıca, test takımınız tek tek test edenler için sonuçları görüntüleyebilirsiniz.Daha fazla bilgi için bkz. Nasıl yapılır: Görünüm sınama planı Microsoft Test Yöneticisi ' nde sonuçları.

Takımınıza hangi seviyelerdeki testler raporlanmalıdır?

Visual Studio Test Professional kullanarak ve Team Foundation Server, ekibiniz testlerin planlama ve yürütme durumunu anlayabilir.Team Foundation Server test planlarınızı, test programlarınızı, test çalışmalarınızı, test sonuçlarınızı ve test etme süreciniz süresince oluşturulan ilişkili tüm diğer verileri depolar.Birleştirirseniz, test ve kalite kontrol işlemi görselleştirmek Microsoft Test Yöneticisi ile raporlama ve iş öğesi sorguları Team Foundation Server. Kullanabileceğiniz Microsoft Test Yöneticisi farklı durumlardaki çeşitli hataları sorgulamak için.Diğer ekip üyeleri tarafından çözüldü şeklinde işaretlenen hatalar, giderilmiş durumda olmalıdır.Düzeltilmiş hataları doğrulamak için sonraki yapıları kullanabilirsiniz.Bir hatanın giderildiğinin nasıl doğrulanacağı hakkında bilgi için bkz. Nasıl yapılır: Microsoft Test Yöneticisi Kullanarak Hatanın Düzeltildiğini Doğrulama.