Modern web uygulamalarının işlevsel testi. Web Uygulama Testi

  • 18.06.2019

Bu yazıda, bakacağız site testi(web uygulamaları) test takımlarını kullanarak. Oldukça uzun, bu yüzden rahatça oturun.

Ana site testi türleri (web uygulamaları)

  1. İşlevsellik testi;
  2. Kullanılabilirlik testi;
  3. Arayüz testi;
  4. Uyumluluk testi;
  5. Web sitesi performansı ve yükleme hızı testi;
  6. Güvenlik testi.

1. İşlevsellik testi

Tüm bağlantıları kontrol et

  • Tüm sayfalardan belirli bir alana gelen bağlantıları kontrol edin.
  • Dahili bağlantılar.
  • Sayfalarda bulunan diğer öğelere bağlantılar.
  • Web sayfalarının yöneticisine veya diğer kullanıcılarına e-posta göndermek için bağlantılar.
  • İzole sayfalara bağlantı olup olmadığını kontrol edin.

Formları Kontrol Et

Formlar, kullanıcılardan bilgi almak ve onlarla etkileşim kurmak için kullanılır.

Formlarda kontrol edilmesi gerekenler:

  • Formun her alanındaki doğrulamanın doğruluğu.
  • Varsayılan alan değerleri.
  • Form oluşturma, silme, formları görüntüleme ve düzenleme seçenekleri ( varsa).

Şu anda üzerinde çalıştığım örnek bir arama motoru projesini düşünün. Proje, reklamverenlerin ve ortakların kayıt aşamalarına sahiptir. Her kayıt adımı diğerlerinden farklıdır, ancak diğer adımlara bağlıdır. Bu nedenle, tüm kayıt işlemi doğru bir şekilde ilerlemelidir.

E-posta kontrolü, kullanıcı finansal bilgileri vb. gibi çeşitli doğrulama türleri vardır. Doğrulamalı tüm alanlar manuel veya otomatik olarak test edilmelidir.

Çerezleri test etme

Çerezler, kullanıcının bilgisayarında saklanan küçük dosyalardır. En yaygın olarak kimliği doğrulanmış oturumları desteklemek için kullanılırlar. Tarayıcı seçeneklerinizden çerezleri kapatıp açarak uygulamayı test edin.

Bilgisayara yazılmadan önce Çerezlerin şifrelenip şifrelenmediğini kontrol edin. Site ziyareti oturumu sona erdiğinde kayıt oturumlarını ve kullanıcı istatistiklerini test edin. Çerezleri silmenin uygulamanın güvenliğini etkileyip etkilemediğini kontrol edin.

HTML/CSS'yi kontrol edin

Sitenizi arama motorları için optimize ediyorsanız, HTML/CSS doğrulaması özellikle önemlidir. Her şeyden önce, HTML kodunda sözdizimi hataları için siteyi kontrol edin. Sitenin çeşitli arama motorları için uygun olup olmadığını kontrol edin.

Veritabanı testi

Bir web uygulamasının bir veritabanı ile etkileşimi çok önemlidir. Veri bütünlüğünü kontrol edin ve çalıştırın siteyi hatalar için test etme veri tabanıyla ilgili formları düzenlerken, silerken, değiştirirken veya diğer eylemlerde.

Tüm veritabanı sorgularının doğru çalıştığını ve verilerin beklendiği gibi alındığını ve güncellendiğini doğrulayın.

Sitelerin işlevselliğini test ederken şunları kontrol etmeniz gerekir:

Bağlantılar

  1. Dahili bağlantılar;
  2. Dış bağlantılar;
  3. E-posta bağlantıları;
  4. Bozuk bağlantılar.

Formlar

  1. Alan doğrulama;
  2. Geçersiz giriş için hata mesajları;
  3. Zorunlu ve isteğe bağlı alanlar.

Veri tabanı

Veritabanının bütünlüğü kontrol edilmelidir.

2. Kullanılabilirlik testi (web sitesi kullanılabilirliği)

Kullanılabilirlik testi, kullanıcı ve site arasındaki etkileşimin analizi, hataların aranması ve ortadan kaldırılmasıdır.

Bu şunları kontrol eder:

  • Öğrenme kolaylığı;
  • Navigasyon;
  • Öznel kullanıcı memnuniyeti;
  • Genel form.

Navigasyon kontrolü

Gezinme, kullanıcının sayfalarda gezindiği araçları ifade eder. Bunlar düğmeler, bloklar. Site ziyaretçisinin diğer sayfalara bağlantıları nasıl kullandığının yanı sıra.

Kullanılabilirlik kontrolü:

  • Sitenin kullanımı kolay olmalıdır;
  • Talimatlar çok açık olmalıdır;
  • Sağlanan talimatların amaçlanan amaca ulaşıp ulaşmadığını kontrol edin;
  • Ana menü her sayfada mevcut olmalıdır;
  • Ana menü mantıksal bir sırayla oluşturulmalıdır.

İçerik kontrolü

İçerik mantıklı ve anlaşılması kolay olmalıdır. Metinde hatalar olup olmadığını kontrol edin. Koyu renklerin kullanılması kullanıcıları rahatsız eder, tema içerisinde kullanmayınız.

Sayfanın içeriği ve arka planı için genel kabul görmüş standartları kullanmak daha iyidir, böylece yazı tipinin rengi, kenarlıklar vb. kullanıcıları rahatsız etmedi.

İçerik anlamlı olmalı, bağlantılar düzgün çalışmalı, görseller doğru boyutta olmalıdır. Bunlar, web geliştirmede izlenen ana standartlardır. İşiniz, kullanıcı arayüzü testinin bir parçası olarak her şeyi test etmektir.

Kullanıcılar için diğer bilgiler

Arama seçenekleri, site haritası, referans malzemeleri vb. Site haritasındaki tüm bağlantıların çalışmasını kontrol edin. Site Arama işlevi, ihtiyacınız olan içeriği kolayca bulmanıza yardımcı olmalıdır.

3. Arayüz testi

Sunucuyla bağlantının doğru olup olmadığını kontrol etmeniz gerekir. Sunucunun kullanılan yazılım, donanım, ağ ve veritabanı ile uyumluluğu kontrol edilmelidir.

Ana arayüzler:

  • Web sunucusu ve uygulama arayüzleri.
  • Veritabanı sunucusu ve uygulama sunucusu arayüzleri.

Veritabanı veya web sunucusu, uygulama sunucusundan gelen herhangi bir istek için bir hata mesajı döndürürse, uygulama sunucusu bunu yakalamalı ve kullanıcıya göstermelidir.

Kullanıcı bazı etkinlikleri kestiğinde ne olduğunu kontrol edin. Ayrıca bir işlem sırasında sunucuya yeniden bağlandığınızda ne olur.

4. Uyumluluk kontrolü

Kontrol etmeniz gerekiyor:

  • Tarayıcı Uyumluluğu;
  • İşletim sistemleriyle uyumlu;
  • Mobil cihazlarda görüntüleme;
  • Yazdırma seçenekleri.

Tarayıcı Uyumluluğu

Bazı web uygulamaları, tarayıcının türüne bağlı olarak çalışır. Site, farklı tarayıcıların farklı konfigürasyonları ve ayarları ile uyumlu olmalıdır.

Sitenin düzeni çapraz tarayıcı olmalıdır. UI işlevselliği sağlamak için Java komut dosyaları ve AJAX kullanıldığında, güvenlik kontrolleri veya doğrulamalar sisteme çok fazla yük bindirir.

Web uygulamasını Internet Explorer , Firefox , Netscape Navigator , AOL , Safari , Opera tarayıcılarının farklı versiyonlarında kontrol edin.

İşletim sistemi uyumluluğu

Web uygulamasının bazı özellikleri, belirli işletim sistemleriyle uyumlu olmayabilir. Hepsi web geliştirmede kullanılan yeni teknolojileri desteklemez. Bu yüzden uygulamayı Windows , Unix , MAC , Linux , Solaris ve bunların çeşitli versiyonlarında test edin.

Mobil cihazlarda görüntüleme

Harcamak mobil cihazlarda site testi ve mobil tarayıcılar kullanılarak web sayfalarının nasıl görüntülendiğini kontrol edin. Uyumluluk sorunları mobil cihazlardan da kaynaklanabilir. Ayrıca şunu da unutmayın siteyi farklı çözünürlüklerde test etme.

Yazdırma Seçenekleri

Sayfayı yazdırmayı düşünüyorsanız, yazı tiplerinin, hizalamanın, grafiklerin vb. kağıt üzerinde düzgün görüntülendiğinden emin olun. Sayfalar, yazdırma seçeneklerinde ayarlanan boyutlara sığmalıdır.

5. Web Sitesi Performans Testi

Web sitesi veya web uygulaması performans testi şunları içermelidir:

  • Stres testi.
  • stres testi.

Uygulamanın performansını farklı internet hızlarında test edin.

Site yükü testi(web uygulamaları), çok sayıda kullanıcının aynı anda aynı sayfaya istekte bulunduğu testtir. Sistem pik yüklere dayanabilir mi?

Stres testi, sistemin belirlenen sınırların ötesine geçen yüküdür. Yükü artırarak bir sitenin veya web uygulamasının işleyişinde bir arıza elde etmek için stres testi yapılır. Ayrıca sistemin strese nasıl tepki verdiğini ve arızalardan nasıl kurtulduğunu da kontrol edin. Bilgi girişi, giriş ve kayıt alanları strese tabidir.

ab işlevsellik testi ayrıca RAM ile ilgili hataların kontrol edilmesini de içerir.

Karşılaştırma, bir sitenin ölçeklenebilirliğini test etmek veya üçüncü taraf yazılımı kullanırken performansı değerlendirmek için kullanılabilir.

Bağlantı hızı

Bölünmüş site testiçeşitli İnternet bağlantı seçeneklerini kullanırken: modem, ISDN vb. aracılığıyla.

Yük

  1. Siteyi aynı anda ziyaret eden kullanıcı sayısı;
  2. Pik yüklerde sistem performansını kontrol edin;
  3. Kullanıcı büyük miktarda veriye erişir.

stres yükü

  • Bellek, işlemci, dosya işleme vb. performansı
  • 6. Güvenlik testi

    Aşağıda bazı web güvenliği test paketleri bulunmaktadır:

    • Dahili URL'yi izinsiz olarak tarayıcının adres çubuğuna yapıştırarak doğrulama. İç sayfalar açılmamalıdır.
    • Bir kullanıcı adı ve şifre ile giriş yaptıktan ve dahili sayfalara göz attıktan sonra URL'yi değiştirmeyi deneyin. Örneğin, ID= 123 altında bazı web sitesi istatistiklerini kontrol ediyorsunuz. URL kimliğini, oturum açmış kullanıcıyla ilgili olmayan başka bir site kimliğiyle değiştirmeyi deneyin. Her durumda, bu kullanıcının diğer göstergeleri görüntüleme erişimi yasaklanmalıdır.
    • Yetkilendirme formu alanlarına yanlış veri girmeye çalışın. Sistemin geçersiz girişe nasıl tepki verdiğini öğrenin.
    • Dizinler veya dosyalar, indirilebilir olmadıkça doğrudan erişilebilir olmamalıdır.
    • Program kodunu kullanarak otomatik oturum açmaya karşı koruma sağlamak için captcha'yı kontrol edin.
    • Güvenlik amacıyla SSL kullanılıp kullanılmadığını kontrol edin. Evet ise, kullanıcı güvenli olmayan HTTP sayfalarından güvenli sayfalara geçtiğinde ve bunun tersi olduğunda bir mesaj görüntülenmelidir.
    • Tüm işlemler, hata mesajları, güvenlik ihlalleri web sunucusunda bir günlük dosyasına kaydedilmelidir.

    Site güvenlik testinin ana nedeni, olası güvenlik açıklarını bulmak ve ardından bunları ortadan kaldırmaktır.

    • Ağ taraması;
    • Güvenlik açığı taraması;
    • Potansiyel şifre kırma olasılığı;
    • Dergi incelemesi;
    • Bütünlüğü kontrol etmek için araçlar;
    • Virüs algılama.

    Bir siteyi test ederken dikkat edilmesi gereken noktalar

    HTML sayfalarının etkileşimine, internet bağlantısına, güvenlik duvarlarına, web sayfalarında çalışan uygulamalara dikkat etmelisiniz ( uygulamalar, JavaScript, modüler uygulamalar), sunucu tarafında çalışan uygulamaların yanı sıra (komut dosyaları CGI, veritabanı arayüzleri, dinamik web sayfası oluşturucuları).

    Çeşitli sürümlerde birçok sunucu ve tarayıcı türü vardır. Aralarında küçük ama önemli farklılıklar vardır.

    Site testi komut dosyası örneği

    Bir siteyi test ederken dikkate alınması gereken ek faktörler:

    • Sunucuda beklenen yük nedir ( örneğin, zaman birimi başına istek sayısı)?
    • Farklı yük türleri için hangi performans gereklidir ( web sunucusu yanıt süresi, istek başına veritabanı yanıt süresi)?
    • Performans testi için hangi araçlara ihtiyacınız var?
    • Hedef kitle kim? Kullanıcılar hangi tarayıcıları kullanacak? Bağlantı hızı nedir? Sitenin kuruluş içinde kullanılması amaçlanıyor mu yoksa İnternet'te geniş bir kullanıcı kitlesine sunulacak mı?
    • Müşterinin beklediği performans ( sayfalar ne kadar hızlı yüklenmeli, animasyonlar, uygulamalar, yükleme ve başlatma nasıl davranmalı)?
    • İçerik güncellemelerinin yanı sıra sunucu kesinti süresi ve bakımına izin verilecek mi? Evet ise, ne miktarda?
    • Hangi güvenlik önlemleri gerekli güvenlik duvarları, şifreleme, şifreler vb.) ve ne tür işler yapacaklar? Nasıl kontrol edilebilirler?
    • İnternet bağlantısı ne kadar güvenilir olmalıdır? Sistem yedeklemesini nasıl etkiler?
    • Site içeriği güncellemeleri nasıl yönetilecek?
    • Web sayfası içeriğinin, grafiklerin, bağlantıların vb. bakımı, izlenmesi ve kontrolü için gereksinimler.
    • Hangi HTML spesifikasyonu izlenecek? Ne kadar isabetli?
    • İç ve dış bağlantılar nasıl kontrol edilecek ve güncellenecek? Ne sıklıkla?
    • CGI uygulamaları, JavaScript komut dosyaları, ActiveX bileşenleri vb. nasıl yönetilecek ve doğrulanacak?
    • İçerik tek bir konuya odaklanmadıkça, bir web sayfasının maksimum boyutu 3-5 ekranı geçmemelidir. Web sayfası daha büyükse, gezinmek için dahili bağlantılar sağlayın.
    • Web sayfası düzeni ve tasarım öğeleri tutarlı ve mantıksal olarak ilişkili olmalıdır.
    • Web sayfalarının görüntülenmesi, tarayıcı türünden bağımsız olmalıdır.
    • Her sayfada iletişim için bir bağlantı bulunmalıdır.

    Yazının tercümesi “ Web Testi Komple Kılavuzu (Web Uygulaması Testi İpuçları ve Senaryolar) Güleryüzlü bir proje ekibi tarafından hazırlandı

    WEB Uygulama Testi*
    Web uygulaması nedir?
    Web uygulaması, bir istemci-sunucu uygulamasıdır.
    tarayıcının istemci ve web sunucusunun sunucu olduğu yerde. Sunucu genelinde dağıtılan web uygulaması mantığı
    ve müşteri, veri depolama gerçekleştirilir,
    ağırlıklı olarak, sunucuda bilgi alışverişi gerçekleşir
    ağ üzerinden. Bu yaklaşımın avantajlarından biri,
    istemcilerin belirli bir işletim sisteminden bağımsız olması
    kullanıcının sistemi, bu nedenle web uygulamaları
    çapraz platform hizmetleri.

    WEB Uygulama Testi

    *
    Web Uygulamaları Nelerdir?
    1. "Basit" siteler ve web uygulamaları:
    -
    bilgi siteleri
    Elektronik mağazaları
    Basit web uygulamaları

    WEB Uygulama Testi

    *
    2. Karmaşık uygulamalar ve portallar
    -
    Gelişmiş Çözümler
    Yatay portallar ve sosyal ağlar
    Akış Çözümleri
    İnternet açık artırmaları ve pazar yerleri

    WEB Uygulama Testi

    *
    3. Gelişmiş web ürünleri ve bulut çözümleri
    - Yenilikçi ürünler
    - SaaS çözümleri
    -Arama motorları
    - Ticaret sistemleri
    -Online ödeme sistemleri

    İstemci-sunucu mimarisi

    *

    İstemci-sunucu mimarisi

    *
    2 katmanlı istemci-sunucu mimarisi

    WEB Uygulama Testi

    *
    Web uygulaması testi nedir?

    10. WEB Uygulamalarının Test Edilmesi

    *
    1. Hazırlık çalışması
    testçi alınan belgeleri inceler (analiz eder)
    bunlar için işlevsellik görev, sitenin son düzenlerini inceler ve
    daha fazla test için bir test planı hazırlar)
    2. Fonksiyonel test - en uzun aşama
    kaynak kontrolleri. Bu sürecin özü, her şeyi kontrol etmektir.
    açıklanan işlevsellik:
    Sitenin gerekli tüm işlevlerinin çalışmasını kontrol etmek;
    Sitedeki kullanıcı formlarının performansını test etme
    (örneğin, geri bildirim, bir bloga yorum ekleme);
    Arama performansının kontrol edilmesi (sonuçların alaka düzeyi dahil);
    Köprüleri kontrol etme, kırık linkleri arama;
    Dosyaların sunucuya yüklenmesinin kontrol edilmesi;
    Sayfalara kurulan sayaçların performansının kontrol edilmesi
    alan;
    Site sayfalarının içeriğinin orijinaline uygunluk açısından görüntülenmesi
    müşteri tarafından sağlanan içerik.

    11.

    3. Düzeni Test Etme - düzeni kontrol ederken ilk şey
    test cihazı elemanların yerini, yazışmalarını kontrol eder
    sağlanan düzenlere konumlandırır ve ayrıca optimizasyonu kontrol eder
    görüntüler ve grafikler. Bir sonraki adım geçerliliğini kontrol etmektir.
    kod.
    Yerleşim sürecinde nesnelerin doğru hiyerarşisini gözlemlemek önemlidir,
    ve çalışma tamamlandıktan sonra geçerliliğini doğrulamak önemlidir.
    Tarayıcılar, görünüşe göre kötü koda rağmen, her durumda
    web sayfasını görüntülemeye çalışacaktır. Ama var olmadığından
    “eğrinin” nasıl gösterilmesi gerektiğine dair tek düzenleme
    belgede, her tarayıcı bunu farklı şekilde yapmaya çalışır. Ve bu içinde
    sırayla aynı belgenin olabileceği gerçeğine yol açar.
    farklı tarayıcılarda farklı görünüyor.
    Belirgin gafları düzeltmek ve kod müşteri adaylarını sistematize etmek,
    bir kural olarak, istikrarlı bir sonuç için. Kontrol işlemini tamamladıktan sonra
    geçerlilik, uzman tarayıcılar arası uyumluluğu kontrol etmeye devam eder,
    şunlar. sitenin performansını çeşitli tarayıcılarda kontrol eder, ayrıca
    farklı ekran ayarlarıyla aynı.

    12.

    Neden bir siteyi tarayıcılar arası uyumluluk açısından kontrol etmelisiniz? Bugüne kadar
    Google gibi en popüler web tarayıcılarından bazıları var
    Chrome, Safari, Mozilla Firefox, Internet Explorer ve Opera. Her biri
    biçimlendirme görselleştirmesi için genel yönergelere uyar
    sayfalar, ancak aynı zamanda herkes kodu işler
    kendi motorunun özelliklerine uygun olarak. Her şey karmaşıklaşıyor
    tarayıcıların yeni sürümlerinin oldukça sık görünmesi ve
    örneğin IE9'da harika görünen bir kaynak, mutlaka
    IE7 veya IE8'de doğru görünecektir. Bu nedenle süreçte
    test, destekleyen tarayıcıların listesini dikkate alır.
    proje tartışmasının ilk aşamalarında müşteri ile müzakere edilir.
    Siteyi çeşitli tarayıcılar arası uyumluluk açısından kontrol etme aşaması
    izinler zaman açısından oldukça uzundur, ancak sonuç buna değer -
    hedefin herhangi bir temsilcisi sitenizi görebilecek
    kitle.

    13.

    Kullanılabilirlik testi - kullanılabilirliği değerlendirmek için yapılır
    çekiciliğe dayalı kullanımda ürün
    test kullanıcıları olarak kullanıcılar ve alınanların analizi
    Sonuçlar.
    Kullanılabilirliğin gelişmesine rağmen
    kaynak teknik bir çizim sürecinde gerçekleştirilir
    görevler, düzenlerin geliştirilmesi, ne zaman durumlar vardır
    elde edilen sonuç optimal değildir. Böyle olmasına rağmen
    oldukça nadiren meydana gelir, bu konuda en uygun çözüm
    durum - uygulanan üründe değişiklik yapmak.
    Test, birkaç kişinin katılımıyla gerçekleştirilir.
    hedef kitle, sözde yanıtlayıcılar. İçin
    4-6 kişi için test yeterlidir. var
    kullanıcıların %20'sinin %80 verdiğini söyleyen 80/20 kuralı
    sonuç. Dolayısıyla bu cevaplayıcı sayısı
    zamandan tasarruf açısından en verimli ve
    maliyetler.

    14.

    Güvenlik testi - Testin bu aşamasında
    uzman, kullanıcıların erişime sahip olup olmadığını kontrol eder
    hizmet / kapalı sayfalar ve ayrıca kontroller
    tüm kritik sayfaların korunması (örneğin, bölüm
    site yönetimi) dış etkilerden.

    15.

    Site performans testi - amacı ile yürütülür
    sitenin veya bir bölümünün performansının belirli bir çerçevede belirlenmesi
    yük. Performans testi aşağıdaki türleri içerir
    test yapmak:
    Yük testi - en basit test şekli
    verim. Yük testi genellikle
    bir sitenin (veya uygulamanın) davranışını belirli bir koşul altında değerlendirmek için
    beklenen yük Bu yük, örneğin beklenen yük olabilir.
    sitedeki eşzamanlı kullanıcı sayısı,
    zaman aralığı başına belirli sayıda işlem gerçekleştirme. Bu tip
    test genellikle en çok yanıt süresini elde etmenizi sağlar
    önemli iş fonksiyonları.
    Performans Testi - Web sitesi yükleme hızının kontrol edilmesi
    komut dosyası işleme hızının belirlenmesi, görüntü yükleme ve
    içerik. Bu test, önyükleme işlemini optimize etmek için yapılır.
    sitenin yanı sıra en uygun sunucu ayarlarını belirleme.

    16. Web uygulamalarını test etmenin özellikleri:

    *
    Teknolojik farklılıklar.
    Klasik uygulama bir tane kullanarak çalışır
    veya ilgili teknolojilerin bir ailesi.
    Web uygulaması temelde kullanarak çalışır
    çeşitli teknolojiler.
    Yapısal farklılıklar.
    Klasik "monolitik" uygulama. Birinden oluşur veya
    az sayıda modül. Veritabanı sunucuları kullanmaz,
    web sunucuları vb.
    Web uygulaması - "çok bileşenli". büyük oluşur
    modül sayısı. Veritabanı sunucuları, web sunucuları, uygulama sunucuları kullandığınızdan emin olun.

    17.

    Çalışma modlarındaki farklılıklar.
    Klasik uygulama gerçek zamanlı olarak çalışır
    zaman, yani olarak, kullanıcının eylemlerinden anında haberdar
    sadece yapılır.
    Web uygulaması, istek-yanıt modunda çalışır, yani.
    bazı eylemler hakkında ancak bir talepten sonra bilinir.
    sunucu.

    18.

    Arayüzün oluşumundaki farklılıklar.
    Klasik uygulama oluşturmak için kullanır
    kullanıcı arayüzü nispeten iyi kurulmuş ve
    standartlaştırılmış teknolojiler.
    Web uygulaması oluşturmak için kullanır
    kullanıcı arayüzü hızla gelişen
    çoğu birbiriyle rekabet eden teknolojiler.
    Ağ farklılıkları.
    Klasik uygulama neredeyse hiç ağ kullanmaz
    veri kanalları.
    Web uygulaması ağ iletim kanallarını aktif olarak kullanır
    veri.

    19.

    Başlatma ve durdurma arasındaki fark.
    Klasik uygulama başlar ve durur
    seyrek.
    Web uygulaması olaydan sonra başlar ve durur
    her talebin alınması, yani Sıklıkla.
    Fark, kullanıcı sayısındadır.
    Klasik uygulama: kullanıcı sayısı,
    uygulamayı aynı anda kullanmak tabidir
    kontrollü, sınırlı ve kolay tahmin edilebilir.
    Web uygulaması: aynı anda kullanıcı sayısı
    uygulamayı kullanarak tahmin etmek zordur ve
    geniş bir aralıkta aniden değişir.

    20.

    Başarısızlıkların ve başarısızlıkların özellikleri.
    Klasik uygulama: belirli bileşenlerin arızası
    hemen belli olur.
    Web uygulaması: bazı bileşenlerin arızası
    bir bütün olarak uygulamanın performansı üzerinde öngörülemeyen etki.
    Kurulum farklılıkları.
    Klasik uygulama - kurulum süreci standartlaştırılmış ve
    geniş bir kullanıcı kitlesine odaklanmıştır. Değil
    özel bilgi gerektirir. Uygulama Bileşenleri Ekleme
    aynı kullanılarak standart bir şekilde gerçekleştirilir
    aynı yükleyici.
    Web uygulaması - yükleme işlemi genellikle son kullanıcı için mevcut değildir
    kullanıcı. Kurulum özel bilgi gerektirir. İşlem
    uygulama bileşenlerindeki değişiklikler sağlanmaz veya
    kullanıcı nitelikleri. yükleyici eksik.

    21.

    Kaldırmadaki farklılıklar.
    Masaüstü uygulaması: kaldırma işlemi
    standartlaştırılmış ve otomatik olarak gerçekleştirilen veya
    yarı otomatik.
    Web Uygulaması: Kaldırma işlemi şunları gerektirir:
    yönetici müdahalesi için özel bilgi ve
    genellikle işletim ortamının kodundaki bir değişiklikle ilişkilendirilir
    uygulamalar, veritabanı, sistem işletim sistemi ayarları.
    Çalışma ortamının özellikleri.
    Klasik Uygulama: Çalışma Zamanı Ortamı
    standartlaştırılmıştır ve işleyişi büyük ölçüde etkilemez
    uygulamalar.
    Web uygulaması: işletim ortamı çok çeşitlidir
    performans üzerinde önemli bir etkisi olabilir ve
    sunucu ve istemci tarafı.

    22. Pratik görev:

    *
    Kaynağı test edin.
    Bulunan hatalar için hata raporları oluşturun.
    http://mines.pp.ua/

    Web uygulaması testi, genellikle birbirine bağlı birçok öğe için destek içeren, bir ağ üzerinden kullanılabilen istemci/sunucu ürünlerini test etme sürecidir. Bilgi sistemlerinin verimliliği, maliyet etkinliği ve genel olarak kullanıcı değerlendirmesi, büyük ölçüde gelişimlerinin kalitesine bağlıdır. Bir yazılım hatası şirket için mali kayıplara yol açabileceği gibi, genel kabul görmüş standartların, uygun fonksiyonel ve tasarım gereksinimlerinin ve çözümlerin kullanılması, aktif kullanıcı sayısında artışa neden olabilir.

    Test, uygulama ile etkileşime giren çok çeşitli dağıtılmış sistem bileşenlerini hesaba katar. Ağ ortamında bir hata oluştuğunda, istemci-sunucu uygulamasının herhangi bir bölümünde meydana gelebileceğinden, nitelikli bir teknisyenin yardımı olmadan hatanın nerede oluştuğunu belirlemek genellikle imkansızdır. Web uygulamalarını test etme sürecinde QA mühendisleri, proje mimarisinin özelliklerini ve veritabanı, uygulamanın arka ucu, web hizmetleri, üçüncü taraf bileşenleri ve kullanıcı arayüzü arasındaki etkileşim mekaniğini dikkate alır.

    Web Uygulama Testine Webmart QA Yaklaşımı


    Web uygulamalarını test etmenin bir parçası olarak ekibimiz şunları gerçekleştirir:

    • İşlevsellik Testi(uygulamanın işlevsel içeriğinin gerekliliklere ve genel kabul görmüş standartlara uygunluğunun kontrol edilmesi).
    • Çapraz tarayıcı ve platformlar arası test(kullanıcı farklı işletim sistemlerinde, tarayıcılarda ve farklı cihazlarda ürünle etkileşime girdiğinde sistem davranışındaki kusurların ve farklılıkların tespiti).
    • Web Servis Testi (doğru veri işleme için web uygulaması tarafından çağrılan servislerin doğruluğunu kontrol etme, nesnelerin durumunu değiştirme, veri tabanından bilgi döndürme vb.).
    • Entegrasyon testi, E2E (bağlantıların ve bağlanabilirliğin doğrulanması, belirli bileşenlerde test verilerinin hazırlanması ve bir bütün olarak tüm sistemin adım adım iş süreçlerinin yürütülmesinin sonuçlarının doğrulanması dahil olmak üzere, etkileşimli alt sistemler kompleksi için uçtan uca senaryoların test edilmesi) .
    • Kullanılabilirlik testi(kullanılabilirliği kontrol etme, navigasyon ve arayüzdeki kusurları ve ayrıca aşırı veya yetersiz bilgi içeriğini tespit etme).
    • Yük ve stres testi ( normal çalışma koşulları ve uzun bir süre boyunca tepe yükleri altında sistemin kararlılığını ve hata toleransını kontrol etme).

    Test için gönderilen bir web uygulamasıyla çalışmak için tipik bir süreç aşağıdaki gibidir. Uzmanlarımız, mevcut sorunları belirlemek için sistemin tam bir işlevsel testini ve analizini gerçekleştirir. Gelecekte, sonraki geliştirme aşamalarında düzeltmelerinin eksiksizliğini kontrol ederler. Her proje için ayrı bir çalışma programı ve test dokümantasyon formatı geliştirilir.

    Ancak, Webmart QA uzmanları, uygulama düzeltmelerinin yeni kusurlara yol açmadığından emin olmak ister. Bu nedenle, kural olarak, işimiz biter gerileme testi– iyileştirilmiş sistemin olması gerektiği gibi çalıştığının kontrol edilmesi: uygulanan iyileştirmeler ilgili işlevsellikte hatalara yol açmadı ve düzeltilen kusurlar yenilerinin ortaya çıkmasına neden olmadı.

    Sadece uygun kombinasyonlar


    Ekibimiz hiçbir zaman her şeyi sunmaz: Yalnızca her özel durumda gerçekten uygun ve uygulanabilir olan yaklaşımları uygularız:

    • En basit uygulamalar, istenen kaliteyi ekstra ücret ödemeden elde edecek standart prosedürler önerilecektir.
    • Daha ciddi işlevselliğe sahip uygulamalar için genişletilmiş bir test stratejisi geliştirilecek, yinelemeli ve takvimli bir çalışma planı hazırlanacak. Bu tür projeler için analitik departmanın çalışanları dahil edilecektir.
    • Buna karşılık, uzman ekiplerin temsilcileri ve geliştirme departmanı çalışanları, işin dağılımı ile benzersiz bir test stratejisi ve proje yaşam döngüsünün oluşturulacağı derinlemesine araştırma sonuçları üzerinde karmaşık projeler üzerinde çalışmaya dahil olacak ve belirlenen zaman çerçevesinde belirlenen hedeflere ulaşmak için test türleri.

    Hangi yaklaşımın sizin için en uygun olduğunu düşündüğümüzü öğrenmek için herhangi bir uygun şekilde bizimle iletişime geçin veya önerilen formlardan birinde bir istek bırakın.


    Web uygulamalarını test etmenin, masaüstü işletim sistemlerini test etmeyle pek çok ortak noktası vardır. Standart işlevselliği, yapılandırmayı ve uyumluluğu test etmeniz ve diğer tüm standart test türlerini gerçekleştirmeniz gerekir. Ancak, web uygulamalarını test etmek daha karmaşık bir süreçtir, çünkü zorluklar, sistemin uygulama ile etkileşime giren tüm dağıtılmış bileşenleri tarafından çarpılır. Bir ağ ortamında bir hata gördüğümüzde, tam olarak nerede meydana geldiğini belirlemek genellikle zordur ve bu nedenle çalışma modu veya aldığımız hata mesajı, ağın farklı bölümlerinde meydana gelen hataların sonucu olabilir. sistem. Bu durumda, hatayı düzeltmek sorunlu olacaktır. Peki web tabanlı bir sistemde hataları nasıl analiz ederiz ve bu tür hataları düzeltmek için ne gibi araştırmalar yapılmalıdır?

    Altta yatan teknolojinin tasarımını anladığımızda, yeniden üretilmesi daha kolay olan kilitlenme ve hata bildirimleri yazarak test verimliliğini çok daha fazla artırabiliyoruz. Bu da arızaları daha hızlı tespit etmemizi sağlar. Ancak ilan etmek, uygulamaktan çok daha kolaydır. Özellikle internet ortamında. Oldukça hataya açık olan teknolojik değişkenlerle dolu. İşte Web uygulamalarını test etmeyle ilgili 5 temel, temel yargı:

    • İstemci tarafında bir hata gördüğümüzde, hatanın kendisini değil, hatanın belirtisini görürüz.
    • Hatalar ortama bağlıdır ve farklı ortamlarda oluşmayabilir.
    • Hatalar kodda veya konfigürasyonda olabilir.
    • Hatalar birkaç düzeyden herhangi birinde bulunabilir.
    • 2 sınıf çalışma ortamının - statik ve dinamik - dikkate alınması farklı yaklaşımlar gerektirir.

    Bu 5 ifadeye daha ayrıntılı olarak bakalım:

    1. Aslında ne görüyoruz, bir böcek mi yoksa bir semptom mu?

    Çevresel bir teşhis yapmadan, semptomun nedeninin tam olarak ne olduğunu tam olarak söyleyemeyiz. İstemci veya sunucu tarafındaki belirli ortam değişkenlerinden herhangi biri taşınır veya değiştirilirse, sorunu yeniden oluşturamama olasılığımız vardır.

    İşte bir örnek. Bir hata izleme web uygulamasını test ediyorum ve yeni bir hata raporu oluşturma sürecindeyim. YENİ 'yi tıkladığınızda, şuna benzeyen bir hata mesajı görünür:

    ODBC Sürücüleri için Microsoft OLE DB Sağlayıcısı hatası "8004014".

    Tarayıcı cihazını araştırmak için biraz zaman harcadıktan sonra, tarayıcı ayarları iletişim kutusunda JavaScript'in etkin olmadığını görüyorum. JavaScript'i etkinleştirmek hatayı düzeltir. Ana fikir, hata mesajıyla ilgili ek JavaScript yapılandırma bilgileri eklememdir. Ayrıca, "JavaScript'i devre dışı bırak" öğesi ileriye dönük olarak test takımımda bulunuyor, potansiyel olarak ilgili tüm hataların yakalanabilmesi için uygulamanın tüm bölümlerine eklenecek.

    2. Hata çevreye bağlı mı?

    Oynamak çevreye bağlı hata, hem eylemlerin tam sırasını hem de uygulamanın çalışacağı ortamın koşullarını (işletim sistemi, tarayıcı sürümü, ek bileşenler, veritabanı sunucusu, web sunucusu, üçüncü taraf bileşenler, sunucu/istemci kaynakları) mükemmel bir şekilde çoğaltmamız gerekir. , bant genişliği ağı, trafik vb.). Örneğin 28,8 kbps hızında çevirmeli bağlantı kullanarak web uygulamanıza giriş yapmaya çalışıyorsanız, bu amaç için ayrılan sürenin dolması nedeniyle yetkilendirme işlemi kesintiye uğrayana kadar giriş hataları yaşarsınız. Ancak, aynı şekilde gerçekleştirilen, ancak 1.54 Mbps hızında bir T-1 bağlantısı kullanılarak ağda kayıt başarılı olacaktır. Bu durumda, bağımlılığın ağ bant genişliği ile ilgili olduğu, ortama bağlı bir hatanız olur.

    Öte yandan, çevreden bağımsız hataların yeniden üretilmesi nispeten daha kolaydır. İşletim ortamını çoğaltmaya gerek yoktur. Ortamdan bağımsız hatalar için gereken tek şey, hatayı yeniden oluşturacak adımları çoğaltmaktır. Örneğin, ürünleriyle birlikte tüm sitelerde şirketin adı yanlış yazılmışsa ve şöyle görünüyorsa - WebTesti.Con, o zaman sen Her zaman işletim ortamınızdaki donanım, yazılım veya kaynak değişkenlerinden bağımsız olarak bu hatayı göreceksiniz. Başka bir deyişle, çevreden bağımsız hataları işlevsel olarak özel olarak algılarız.

    3. Bir kodlama hatası mı yoksa bir yapılandırma sorunu mu?

    Hatalar (veya şüpheli hataların belirtileri), programdaki konumlarının koordinatları kullanılarak (hataların gerçekten var olduğu varsayılarak) veya sistemi (istemci, sunucu veya ağ) yeniden yapılandırarak düzeltilebilir. Bunun bir hata olduğuna inanarak sonuçlara atlamayın.

    ODBC Sürücüleri için Microsoft OLE DB Sağlayıcısı hatası "80004005"

    İşte tanımlamadaki zorlukları gösteren bir örnek mümkün yapılandırma sorunlarının aksine gerçek yazılım sorunları. Kaydolma yetersizliğinden ("başarısız oturum açma") kaynaklanan bir hata mesajı görüyoruz. Bu mesaj bir web uygulaması tarafından oluşturuldu. Ancak, yalnızca bu hata bildirimine bakarak, bunun gerçekten bir hata olup olmadığını veya bir yazılım hatası mı, sunucu tarafı yapılandırma sorunu, uyumsuzluk sorunu, tarayıcı yapılandırma sorunu veya sonucu olup olmadığını belirlemek mümkün değildir. bunların hepsinden az ya da çok.

    Arızanın daha ayrıntılı analizinden sonra, bu hata bildirimini oluşturabilecek birkaç olası neden buldum:

    Web sunucusu (IIS) sanal dizini düzgün ayarlanmamış.

    Sanal dizin doğru yapılandırılmadığında, istenen dosyalar, komut dosyaları veya veriler bulunmayacaktır. Genellikle bu bir sunucu yapılandırma sorunudur. Kurulum programı web sunucusunu spesifikasyona göre otomatik olarak yapılandıramadıysa da, bu yazılım hatası. Sistem yöneticisi, web sunucusunu spesifikasyona göre düzgün bir şekilde yapılandıramazsa, hata şuna dönüşür: özel hata.

    Uygulama dizini, komut dosyalarını doğru şekilde çalıştırmak için doğru şekilde yapılandırılmamış.

    Standart uygulama sunucusu dizini c, istemcinin isteği üzerine web sunucusu tarafından çağrıldıklarında yürütülen komut dosyalarını içerir. Güvenlik nedenleriyle, web sunucusu, ayrı dizinler içindeki komut dosyalarının yürütülmesine izin verecek veya engelleyecek şekilde yapılandırılabilir. Bu nedenle, uygulama sunucunuz yürütülecek komut dosyalarını içerecek şekilde tasarlanmışsa ve web sunucusu bu dizinde yürütülmesini engelleyecek şekilde yapılandırılmışsa, uygulama çalışmayacaktır. Öyleyse nedir yazılım hatası veya yapılandırma sorunu?

    Varsayılan web sayfası düzgün yüklenmedi.

    Sorun, yukarıda açıklanan soruna benzer.

    SQL Server etkin değil.

    Uygulama sunucusu, sorguları yürütmek, prosedürleri depolamak ve verilere erişmek için SQL sunucusunda bulunan bir veritabanı düğümüne bağlantı gerektirir. SQL arka ucu çalışmıyorsa, uygulama kesinlikle çalışmayacaktır.

    DLL/COM nesneleri eksik veya başarıyla kaydedilmedi.

    Kurulum programı, kurulum sırasında uygulama sunucusu tarafından kullanılan tüm DLL dosyalarını kopyalayamamış olabilir. Uygulama sunucusunun çalışması için gerekli herhangi bir DLL dosyası eksikse, uygulama çalışmayacaktır.

    Kurulum programı gerekli tüm modülleri doğru şekilde kopyalamış, ancak bir veya daha fazlasını kaydedememiş olabilir. Örneğin, COM veya DCOM gibi OLE tabanlı nesnelerin, kullanılmadan önce kayıt defteri veritabanında kayıtlı sınıf kimliklerinin (CLSID) olması gerekir. Bir uygulama başarıyla kaydedilmemiş bir COM nesnesine erişmeye çalışırsa çalışmayacaktır.

    Bu sorun genellikle kurulum sırasındaki hataların bir sonucu olarak ortaya çıkar. Öte yandan, bileşenlerin manuel olarak kaydedilmesi gerekiyorsa, bu yapılandırma sorunu.

    Tarayıcı tarafı JavaScript ayarları devre dışı bırakıldı.

    Bu, bir uygulama tarayıcıdan JavaScript engellemesini kaldırmasını istediğinde ortaya çıkan, tarayıcıya özgü bir yapılandırma sorunudur. Bu bir yazılım hatası mı, yapılandırma sorunu mu yoksa teknik destek sorunu mu?

    4. Soruna gerçekten hangi seviye neden oluyor?

    Çok sayıda değişken, istemci/sunucu sistem yapısının dağıtılmış doğası tarafından temsil edildiğinden, web sistemlerinde hataları tutarlı bir şekilde yeniden oluşturmak genellikle zordur. Web ortamında en az 3 adet "olağan şüpheli" bulunmaktadır. BT müşteri, sunucu ve ağ.

    Hem istemci hem de sunucu, tüm bileşenlerin "aynı kutuda" olduğu PC ortamlarına benzer yapılandırma ve uyumluluk uyumsuzluklarına tabidir. Ancak, birçok istemci ve sunucu bir ağa bağlanabileceğinden, bu tutarsızlıklar istemci/sunucu sistemlerinde çoğalır. Tipik yapılandırma ve uyumluluk uyumsuzlukları, donanım ve işletim sistemi (örneğin UNIX tabanlı ve Windows tabanlı bloklar) ve sunucu tarafı yazılım karışıklığı (web sunucusu paketleri, veritabanı sunucusu paketleri, güvenlik duvarları, COM nesneleri, CORBA nesneleri vb.) arasında karışıklığa neden olur. .). Tutarsızlıklar, istemci tarafında da yazılım karışıklığına yol açabilir (TCP/IP kuyrukları, çevirici yazılımı, yardım bileşenleri, tarayıcı markaları ve sürümleri). Ayrıca genel ayarlar, bağlantı ayarları, güvenlik ayarları (ActiveX denetleyicileri, ek program modülleri (eklentiler), Java , komut dosyaları, indirmeler, kullanıcı yetkilendirme vb. dahil), içerik ayarları, program ayarları ve diğer gelişmiş ayarlar gibi tarayıcı ayarları (görüntüleme seçenekleri, multimedya seçenekleri, Java VM seçenekleri, yazdırma seçenekleri ve HTTP seçenekleri dahil) test edilmesi ve çalışmalara dahil edilmesi gereken birçok değişken sağlar.

    Ağlar farklı bir değişken kümesi sunar. Bant genişliği ve gecikme nedeniyle borçlu olduğumuz zamanla ilgili sorunlar (bağlantı sağlığı, performans, kapalı kalma süresi vb.), olası yapılandırma ve ağ geçitleri ve yönlendiriciler gibi donanım uyumluluğu sorunları ve bunlarla ilişkili yan etkiler dahil olmak üzere web uygulamalarını çeşitli şekillerde etkilerler. güvenlik servisinin çalışmasıyla.

    5. Statik ve dinamik çalışma ortamları farklıdır.

    Her biri kendine özgü test senaryolarına sahip 2 çalışma ortamı sınıfı vardır:

    Statik ortamlar (Statik Ortamlar), işleme hızı ve kullanılabilir bellek gibi değişken koşullardan bağımsız olarak uyumsuzluk sorunlarının ortaya çıkabileceği yerler.

    Dinamik Ortamlar. Onlarda bunun tersi doğrudur - uyumlu bileşenler, belleğe bağlı hatalara ve gizli koşullara göre hataları algılayabilir. (Dinamik ortamları bu bölümün ilerleyen kısımlarında daha ayrıntılı olarak tartışacağız).

    Statik İşletim Ortamı: konfigürasyon ve uyumluluk değişkenleri.

    Yapılandırma ve uyumluluk sorunları Web sistemi içinde herhangi bir yerde ortaya çıkabilir: bunlar istemci tarafından, sunucu tarafından veya ağ tarafından gelebilir.

    Yapılandırma sorunları, çeşitli sunucu yazılım ve donanım ayarlarını, tarayıcı ayarlarını, ağ bağlantılarını ve TCP/IP kuyruk ayarlarını etkiler. Daha önce tartışılan Tarayıcı Ayarları ve JavaScript örneği, bir tür yapılandırma sorununu gösteriyordu. Başka bir tür gösterilir şema 1 ve Şema 2 . İki olası fiziksel sunucu yapılandırmasında sunulurlar: bir ve iki birim.

    Senaryo 1: Aynı platformda web sunucusu, uygulama sunucusu ve veritabanı sunucusu

    Şema 2: Bir platformda WEB sunucusu ve uygulama sunucusu, diğerinde veritabanı sunucusu

    Test edilen örnek uygulamamız, kullanıcının çubuk ve çizgi grafikler gibi metrik raporlar oluşturmasına olanak tanıyan bazı grafik eşlemelerine sahiptir. Bir kullanıcı bir ölçüm raporu istediğinde, uygulama sunucusu sözde kodu aşağıdaki sırayla çalışır:

    1. Veritabanı sunucusuna bağlanma ve istekte bulunma.

    2. Sorgu sonucunun isimle bir dosya olarak yazılması c:\temp\chart.val

    3. Chart Java Uygulamasının Yürütülmesi. Bir dosyadan veri okuma ve kullanma c:\temp\chart.val grafik çizebilmek.

    4. Java Applet'i tarayıcıya gönderme.

    Uygulamayı test etme sürecinde, çizimdeki bir özelliğin yukarıdaki konfigürasyonlardan yalnızca biriyle çalıştığını gördüm. Daha fazla incelemenin bir sonucu olarak, sorunun sadece iki üniteli konfigürasyonla ilgili olduğu anlaşıldı. Kodu kontrol ettikten sonra sorunun 2. ve 3. noktalarda olduğu ortaya çıktı. İkinci noktada sorgunun sonucu c:\temp\chart.val veritabanı sunucusunun yerel sürücüsüne yazılmıştır. Chart Java Applet'in üçüncü paragrafında, veritabanı sunucusundan farklı bloklarda bulunan uygulama sunucusunda başlatıldı. Bir dosyayı açmaya çalışırken c:\temp\chart.val uygulama sunucusunun yerel disk sürücüsünde, bu dosyanın orada olmadığı ortaya çıktı.

    Bu durumda her hatayla karşılaştığınızda kodu okumanızı önermiyorum. Geliştiricilerin sorunları çözme işini yapmasına izin verin. Sadece hangi sunucunun yapılandırma sorunları yaşadığını belirleme ihtiyacına dikkat çekmek ve bu bilgileri sorun raporlarına dahil etmek istiyorum. Ayrıca, test edilen uygulama sunucusu tarafından desteklenen tüm dağıtılmış konfigürasyonlarda sığ bir test takımı çalıştırırdım.

    Statik çalışma ortamlarında uygunluk sorunları da önemlidir. Örnek olarak, düşünün Şema 3 , burada Netscape Navigator ve Internet Explorer arasındaki uyumluluk farkını görüyoruz.

    Şema 3: Tarayıcı Uyumluluğu Sorunu

    Bu hiçbir şekilde Internet Explorer'ın Netscape Navigator'dan daha iyi olduğu anlamına gelmez. Bu, tarayıcılar arasında tutarsızlık sorunları olduğu ve kodun tüm tarayıcılar için göreli yolların (dosyaya giden) çalışmasını beklemeyebileceği anlamına gelir. Daha da önemlisi, bu, bir ortamda bir hatayla karşılaşırsanız, ortaya çıkmamak ortama bağlı bir hata olması şartıyla.

    Dinamik İşletim Ortamı: Her şey aynı kalmaz.

    Her ardışık test prosedürü sırasında belirli bir ortamın özniteliğinin değeri sabit kalmadığında, bu, işletim ortamının dinamik.Öznitelik, kaynağa özgü (kullanılabilir RAM, disk alanı vb.) ile seçime özgü (ağ zaman aşımı, gerçekleştirilen kullanıcı işlemlerinin sırası vb.)

    Test durumu bağlı olduğunda kesin olarak oynatma eylem seti, ve çalışma ortamı ve ortam yeniden üretilemez (dinamik doğasına uygun olarak), o zaman hata yeniden üretilemez veya yeniden üretilmesi zor hale gelir.

    Bu arada, bellekle ilgili hataların yeniden üretilmesinin genellikle zor olmasının nedeni budur. Örneğin, kodda bir bellek üzerine yazma hatası olduğunda, bu her zaman ilgili bir sorun yaratacaktır. Ancak, kara kutu testi açısından, üzerine yazılan belirli kod bayt(lar)ı veya veriler çalıştırılana veya okunana kadar bu hatanın belirtisini göremeyeceğiz. Bu örnekte, eylem kümesi, kara kutu işlevlerinin tam kümesini temsil eder. Bellek üzerine yazma hatası, koddaki gerçek bir hatayı temsil eder. Üzerine yazılan baytın yürütüldüğü veya okunduğu koşul, dinamik bir çalışma ortamını veya hatayı yeniden oluşturmak için gerekli bir koşulu belirtir.

    Burada, zamanla ilgili bir hataya bakacağımız dinamik ortama bağlı bir web uygulaması hatası örneği verilmiştir.

    Şartname gereksinimleri:

    1. Sistem içindeki proje adları benzersiz olmalıdır.
    2. Potansiyel istemci tarafı kopyası için hata algılama ve işleme, JavaScript kullanılarak sağlanmalıdır.
    3. Kullanıcılar bir sayfa isteyerek proje adlarını ekleyebilir veya kaldırabilir AyarYukarıProjeler.
    4. Kullanıcı yeni bir proje başlığı oluşturduğunda, tarayıcı tarafı JavaScript, giriş adını HTML sayfasında bulunan bir seçim listesine göre kontrol eder (şekilde gösterildiği gibi). Şema 4 )

    Gösterilen zamanla ilgili hataya bakın Şema 5 . Bu sayfa ekran görüntüleri Projeleri Ayarlama yaptı önceki ve sonrasında, uygulamanın "Doomed" yinelenen adını belirleyemediğini görmemize izin verin. AT Şema 4 Her iki kullanıcının da aynı veritabanına yeni proje başlıkları eklemesine neden olan bu zamanla ilgili hata için bir açıklama yapılmıştır.

    Şema 4: Tarayıcı tarafındaki Java betiği girilen değerleri kontrol eder

    Diyagram 5: Zamanlama Hatası

    Da gösterildiği gibi tablo 1 , kullanıcı A ve kullanıcı B, aynı anda, ancak birbirlerinin eylemlerinden haberdar olmadan yeni projeler oluşturur. 3. paragrafa uygun olarak, A kullanıcısı adlı bir proje ekler: Bir diğer. Ancak ad zaten mevcut olduğundan, tarayıcısının JavaScript'i ona farklı bir ad kullanmasını söyleyen bir mesaj görüntüler.

    Tablo 1: A ve B Kullanıcılarının Faaliyetleri
    [daha büyük aç]

    Kullanıcı B proje başlığı ekler mahkum. Tarayıcısının JavaScript'i onu önceden var olarak tanımıyor ve bu nedenle adı hem veritabanına hem de iade listesine ekliyor. Güncellenmiş proje adları listesi B kullanıcısına geri gönderilir.

    Daha sonra, A kullanıcısı aynı adı ekler mahkum proje listesi. Tarayıcısının JavaScript'i onu HTML listesinde tanımlamıyor, bu yüzden adı yeniden ekliyor mahkum veritabanına ve geri dönüş listesine. Güncellenmiş proje adları listesi, dahil edilen iki öğeyle birlikte A kullanıcısına geri gönderilir. mahkum.

    Elde edilen sonuç ürün özelliklerini karşılamıyor. Ve bu durum iyi örneklenmiş bir test durumu olmasına rağmen, yanlışlıkla bu hatayı bulup yeniden oluşturmaya çalışmak kolay bir iş değildir. Bu örnekte, hatanın kendisi, uygulamanın yinelenen adları sunucu tarafından kontrol edip düzeltememesidir (istemci tarafından kontrol etmenin yanı sıra). Adımlar, A kullanıcısının eylemlerini içerir.Dinamik işletim sistemi, B kullanıcısının A kullanıcısından gizlenen ya da onun tarafından bilinmeyen eylemleri tarafından oluşturulur.

    Çözüm

    Bir web ortamındaki hataları analiz etmede ve yeniden üretmede etkili olmak için, işletim ortamından daha fazla yararlanmanız gerekir. Ayrıca ortama özgü değişkenlerin hataları yeniden oluşturma yeteneğinizi nasıl etkileyebileceğini de anlamanız gerekir. Umarım bu makaleden öğrenebileceğiniz bazı beceriler, web testi deneyiminizi daha az sinir bozucu ve daha eğlenceli hale getirir.

    Hiçbir şeyin test etme becerilerinizin ve iyi test senaryoları oluşturma becerinizin yerini tutamayacağını unutmayın. "Ya eğer...?" diye sormaktan, ayrıntılı notlar almaktan ve yeniden üretilmesi zor hataları metodik olarak araştırmaktan korkmayın. Bunlar sadece hataları incelemede değil, aynı zamanda bunlarla ilişkili diğer sorunları bulmada da yardımcınız olacak becerilerdir.

    Bir web uygulamasını test etmek, genellikle işlevsel olduğundan ve kullanıcılar görmeden önce düzgün çalıştığından emin olmak için birkaç adım içerir.

    Her gün daha fazla web uygulaması geliştirilmekte ve her yeni kod satırında yeni hatalar ortaya çıkabilmektedir. Ancak, bu hatalar ne kadar geç bulunursa, bunların düzeltilmesi için parasal maliyetler o kadar yüksek olur.

    Sistem Bilimleri Enstitüsü IBM'de, piyasaya sürüldükten sonra bulunan bir hatayı düzeltme maliyetinin, geliştirme sırasında bir hatayı bulma ve düzeltme maliyetinden 4-5 kat daha yüksek olduğunu buldu.Bu nedenle, bir web uygulamasını yayınlamadan önce kapsamlı bir şekilde test etmek önemlidir.

    Aşağıda bu konuda yardımcı olacak 6 adıma genel bir bakış verilmiştir.

    Adım 1Fonksiyonel Test

    Bir web uygulamasını test etmenin ilk adımı, sistemin işlevselliğini test etmektir.

    İşlevsel testler (Wikipedia'ya göre) -Bu, işlevsel gereksinimlerin fizibilitesini, yani yazılımın belirli koşullar altında kullanıcıların ihtiyaç duyduğu sorunları çözme yeteneğini doğrulamak için yazılım testidir. İşlevsel gereksinimler, yazılımın tam olarak ne yaptığını, hangi görevleri çözdüğünü belirler.

    Fonksiyonel testler genellikle şunları içerir:

    • Uygulamanın gerçekleştirmesi gereken işlevselliği belirleme,
    • veri girişi ve çıkışı,
    • test senaryolarının yürütülmesi,
    • gerçek sonuçların analizi.

    Fonksiyonel testler sırasında sistemin gerçek kullanımı simüle edilir. Bu tür testlerin amacı, uygulamanın gerçek kullanımına mümkün olduğunca yaklaşmak ve kullanıcının gereksinimlerine yakın koşullar yaratmaktır.

    2. Adım: Kullanılabilirlik Testi

    Kullanılabilirlik, işlevsellik testinin ötesine geçer ve işlevsellik testinin yanı sıra genel kullanıcı deneyimini birleştirir. Kullanılabilirlik testi, Kullanıcı Kabul Testi ile karıştırılmamalıdır. Her ikisi de bir web uygulamasının başarısı için gerekli olmakla birlikte, her birinin farklı bir amacı vardır ve yazılım yaşam döngüsünün farklı aşamalarında yürütülür.

    Kullanılabilirlik testi aşağıdaki adımları içerir:

    • Bir web uygulamasının tüm işlevlerinin test edilmesini düzenleyen bir test stratejisinin geliştirilmesi,
    • hem şirket içinden hem de dışarıdan test katılımcılarının seçimi,
    • uzmanların gözetiminde test yapılması,
    • sonuçların analizi ve web uygulamasının iyileştirilmesi.

    Adım 3Arayüz Testi

    Arayüz testi, web sunucusu ve kullanıcı arayüzü arasındaki tüm etkileşimlerin gerektiği gibi tekrarlanabilir olmasını sağlar. Ayrıca hata mesajlarının görüntülenmesinin doğruluğunu kontrol eder.

    4. Adım Uyumluluk Testi

    Web uygulaması testinde önemli bir adım, uygulamanın tüm web tarayıcıları ve cihazlarıyla uyumlu olduğundan emin olmaktır.

    Web tarayıcı uyumluluğu.

    Uygulamanın farklı web tarayıcılarında düzgün çalıştığına dair güvence sağlar. JavaScript, AJAX, WebSockets, tarayıcı bildirimleri ve kimlik doğrulama isteklerinin gereksinimlerde belirtildiği gibi çalıştığını doğrular.

    Uygulamayı farklı tarayıcılarda (hatta Internet Explorer'da! :)) test etmenin yanı sıra, aynı tarayıcının diğer sürümlerinin uygulamanın doğru çalışmasını sağladığından emin olmalısınız.

    Mobil cihazlarla uyumludur.

    Web uygulaması testinin önemli bir parçası da uygulamayı Android, iOS ve diğer mobil işletim sistemlerinde çalışan farklı mobil cihazlarda test etmektir.

    Adım 5. Performans testi.

    Web uygulamasını çeşitli tarayıcılarda ve cihazlarda test ettikten sonra, yüksek yük sırasında performansını test etmelisiniz. Bu tür testleri kullanarak, uygulamanın farklı İnternet hızlarında nasıl çalıştığını ve uygulamanın normal ve pik yükler altında nasıl davrandığını (yük testi) görebilirsiniz.

    Uygulamanın limitini belirlemek için işlevselliği bozulana kadar yüksek (stres) bir yüke maruz bırakılır (stres testi). Ayrıca, uygulamanın çökmelerden nasıl kurtulduğunu kontrol etmeye yardımcı olur.

    Adım 6. Güvenlik testi.

    Web uygulaması testinde son adım. Uygulamanın yetkisiz erişime ve virüsler veya diğer kötü amaçlı yazılımlar kullanılarak yapılan kötü amaçlı eylemlere karşı korunmasını sağlamaya yardımcı olur.

    Güvenlik testi aşağıdaki adımları içerir:

    • korumalı sayfalara yetkisiz erişim olasılığının kontrol edilmesi,
    • kullanıcı etkinliğinin sona ermesinden sonra tüm oturumların işlerini bitirdiğini kontrol etme (uygulamayı kapatma),
    • uygulamanın SSL protokolünün doğrulanması,
    • kısıtlı dosyaların önceden izin alınmadan indirilemeyeceğini kontrol etmek.

    Güvenlik testi kontrol listesi, test çalışmasını düzenlemeye ve yapılandırmaya yardımcı olduğu için çok kullanışlıdır. Kontrol listesi aşağıdaki alanlardaki görevleri içermelidir:

    • Güvenli veri aktarımı;
    • kimlik doğrulama;
    • Oturum yönetimi;
    • Yetki;
    • kriptografi;
    • Veri doğrulama;
    • Hizmet Reddi;
    • Spesifik fonksiyonel testler;
    • Hata işleme.

    Çözüm.

    Web uygulaması testinde 6 adımı inceledik. Bu adımları uygulamanızın geliştirilmesi sırasında gerçekleştirirseniz, çok geç olmadan mümkün olduğunca çok hatayı bulup düzeltmenize yardımcı olurlar.