Verdiğim örnekler bu yüzden yaptığım her şeyin SQL Server olduğunu söyleyerek başlamak istiyorum. Ancak genel olarak bu sistemden bağımsız olarak her türlü kod için geçerlidir.
Bunu biraz parçalayarak başlayalım.
Yükseltmeler
Bir sisteminiz var ve bir kısmını veya tamamını yükseltmek üzeresiniz. Örneğin, bir örneği SQL Server 2012'den 2014'e yükseltme. Bu noktada test yapılması önemlidir. Ne yazık ki küçük bir uygulamanın bile her parçasını test etmek muhtemelen mümkün olmayacaktır. Bu noktada "çalışma" testi dediğim şeyi yaparım. Temel sistem çalışıyor mu? Ortak görevlerinizin üzerinden geçmeye başlayın. Her seçeneği test etmeyin, sadece ana yol.
Bir SQL Server yükseltmesi yaparken de gerekli bazı okumalar vardır . Temel olarak Backward Compatibilityyeni sürümün girişini okumak istiyorsunuz ( işte 2014 sürümü ) ve listelerin hiçbirinde hiçbir değişiklik olmadığından (değişiklikleri kırma, davranış değişiklikleri vb.) Emin olun.
Başvuru Kodu
Burada yeni / değişen uygulama koduna bakıyoruz (elbette var olan herhangi bir şey zaten test edildi mi?). Bu durumda her şey test edilmelidir. Test senaryolarını önceden ayarlamanız ve etkilenen özelliklerinizin en azından çoğundan geçmeniz gerekir. Tercihen bu noktada başka birine de benzer bir kontrol yaptırmalısınız. Bu kod, muhtemelen oldukça uzun bir süre için geçerli olacak ve çok sayıda insan tarafından kullanılacak. İyi çalıştığından ve iyi çalıştığından emin olmak istiyorsunuz.
Bununla gerçekten yardımcı olabilecek şeylerden biri unit tests, kolayca tekrarlanabilir bir dizi oluşturmaktır . Steve Jones , TSQL kodunuzu test etmek için tSQLt kullanmanızı önerir (sadece SQL Server korkarım). Ancak bunu yaparak sabit bir dizi testten hızlı bir şekilde geçebilirsiniz ve regresyon testine gerçekten yardımcı olacaktır (bir yükseltme yapmadan önce her şeyi test edin).
Özellikler / Yapılandırmaları
Uygulama kodu değişikliklerinden bile daha fazla, yeni özellikleri ve yapılandırma değişikliklerini iyice test etmek istiyorsunuz. Örneğin, sütun deposu dizinleriyle çalışmaya başlamaya karar verirsenizilk defa etkilenen tablolara dokunan her kod parçasını test etmeniz gerekecektir. Uygulamanızı test etmek için oluşturduğunuz birim testlerini kullanın. Bu özellikler muhtemelen sizin için yenidir (ve muhtemelen platformda yenidir) ve muhtemelen beklemediğiniz bazı eşyalar olacaktır. Yapılandırma değişikliklerine gelince, muhtemelen tüm sisteminizi etkileyebilecek bir şeyden bahsediyorsunuz. Temel kural test etmek ve dikkatle test etmektir. Aktif bir sisteme (muhtemelen sadece üretim sisteminize) girene kadar gerçekten göremeyeceğiniz bazı değişiklikler var, ancak bu onları ilk önce bir test ortamında denememek için bir bahane değil.
Kullanıcı verilerini referans alan / etkileyen geçici sorgular
Kullanıcı verilerinizi etkileyen bir kodunuz olduğunda, genellikle, hatta belki de özellikle test etmeniz gerekir Ad Hoc. Şimdi, aynı kod parçasını, farklı parametrelerle tekrar tekrar çalıştırıyorsanız, muhtemelen her seferinde test etme konusunda endişelenmenize gerek yoktur.
Örneğin, her üç ayda bir AdList tablosundan bir veya daha fazla Reklamı silmeniz gerekir.
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')
Bu noktada kodu zaten test ettiniz (sadece sabit dizeleri değiştiriyorsunuz) ve muhtemelen sadece kodu çalıştırmanız oldukça güvenlidir (her ihtimale karşı iyi yedeklere sahip olduğunuzu varsayarak).
Bir kolay yolu bir test etmek DELETE, UPDATEya da INSERTbeklediğiniz satır sayısı ve tipi döndürülür ki, o zaman onaylamak SELECT'in bunları değiştirmek ve onları çalıştırmaktır.
SELECTHerhangi bir veriyi değiştirmedikleri için s test etmeniz gerekmediğini düşünebilirsiniz . Ancak kodu bir nedenle çalıştırıyorsunuz değil mi? Diyelim ki yöneticiniz için araştırma yapıyorsunuz, bu verileri yöneticilerine iletecek vb. Yanlış verileri almadığınızdan (veya başkalarının verilerini toplamasını engellediğinizden) emin olmak için test yaparsınız.
Sistem verilerini referans alan / etkileyen geçici sorgular
Bu muhtemelen "her şeyi test et" kuralının tek istisnasıdır. Sistem verileri hakkında bilgi sorguları çalıştırıyorsunuz. Burada önemli olan, beklediğiniz verileri geri almaktır. Sorgu basit bir şeyse (sistem görünümünü sorgulama), görünümün / sütunların gerçekten ne anlama geldiğini kontrol ettiğiniz sürece muhtemelen tamamsınız demektir. Sorgu karmaşıksa (örneğin, döndürülen sütunlardaki hesaplamalar ile 3 veya 4 sistem görünümüne vurma), beklediğiniz verileri geri alacağınızdan emin olmak için birkaç test yapmak isteyebilirsiniz.
özet
Özetle, evet, her şeyi test etmek istiyorsunuz. Yazmanız ve çalıştırmanız için yeterince önemliyse, test etmeniz için yeterince önemlidir. Bu, her kod satırının her dalını test etmek için çok fazla zaman harcamanız gerektiği anlamına gelmez. Ancak bir miktar test yapılması gerekiyor.
Otomatik birim testi burada arkadaşınızdır. Gelişiyle birlikte DevOpsve Continuous Integrationgiderek daha fazla uygulama ve hızlı ve kolay bir kod sınama yöntemleri göreceksiniz. Tabii ki bu, iyi bir test ortamı ve onunla birlikte verilere sahip olmayı gerektiriyor, ancak bu tamamen farklı bir tartışma.