Uyarlanabilir düzeni test etmek için bir araç. Duyarlı tasarım ücretsiz olarak nasıl test edilir. Google DevTools tarafından mobil emülatör

EastBanc Technologies'in QA departmanının karşı karşıya kaldığı en dikkate değer görevlerden biri, otomatikleştirilmiş bir site test sistemi oluşturmaktır. www.washingtonpost.com . Bu bir bilgi ve haber portalı olarak uygulanan bir elektronik gazetedir.

Otomatik bir test sistemi oluşturma ihtiyacının ana nedeni, uygulamanın, sitenin çeşitli bölümlerinde içerik yayınlamak için daha önce kullanılan diğer birçok CMS'nin yerini alması gereken yeni bir CMS'ye (sözde PageBuilder) geçmesinin planlanmasıydı. Bu tür bir geçişte, yeni CMS aracılığıyla çeşitli sayfalarda yayınlanan içeriğin düzgün görünmesi için hata yapmamak çok önemlidir.

Testlerimize uygunluk için tüm sayfaları kontrol etme görevi ile karşı karşıya değiliz. Görevimiz, PageBuilder hatalarını tespit etmek, yeni hazırlanmış PageBuilder tarafından oluşturulan sayfaların düzeninin güvenilirliğini kontrol etmek, Washingtonpost editörlerinin dikkatini, belirli bir sayfayı, sayfaların görüntülenmesinde olası sorunlara yol açabilecek içerikle doldurma nüanslarına çekmektir.
Bir test sisteminin oluşturulması aktif olarak geliştirilmektedir, ancak bize göre bazı ilginç noktalar şimdiden halka sunulabilir.

Bunu yapmadan önce, projenin bir özelliğini not etmek gerekir: tüm testler "dışarıda" yapılır. Onlar. diğer kullanıcılar gibi biz de test için sitenin savaş sürümünü kullanıyoruz.

Yerleşim testi araçlarının seçimi

İnternetin enginliğini keşfettikten sonra, aşağıdaki yaklaşımlar ve araçlar üzerinde karar kıldık. Sayfa iskeletini test etmek için çerçeveyi benimsedik galen , daha sonra testNG ile entegre edildi.

Doğal olarak, sayfa çerçevesi için başarılı Galen testi, henüz düzenin geçerliliği anlamına gelmez. Blokların konumuna ek olarak, blok içindeki çeşitli öğelerin görüntüsünü de kontrol etmeniz gerekir. Ekran görüntülerini karşılaştırarak blokların dahili içeriğini test etmeye karar verdik.
Ekran görüntüsü testlerinin insafına, çeşitli logolar, düğmeler, belirli bir ekrana sahip bazı bloklar düşüyor - Galen'in ulaşamadığı ve işlevsel testlerle kontrol edilmesi zor/imkansız olan her şey.

Azure - Galen tarafından test edildi, yeşille dolduruldu - ekran görüntüsü testleri:

Dikkatlice! büyük fotoğraf

gizli metin

Galen ve Ekran Görüntüsü testleri, bazı işlevsel testlerin yerini başarıyla alabilir, bazen görünürlükte, bazen hızda ve bazen her ikisinde birden kazanır. Belirli bir durum için bir test yönteminin seçimi, hız, destek kolaylığı, test kapsamının eksiksizliği ve görünürlük kriterlerine dayalı olarak her sayfa türü için bir test senaryosunun toplu olarak tartışılması yoluyla tarafımızca gerçekleştirilir.

Örneğin, başlangıçta işlevsel testler yazdığımız 2 blok vardır: En Çok Okunan ve Bilgi Bloğu. Şimdi ilkini ekran görüntüleri ile, ikincisini galen testi ile kontrol ediyoruz.

MostRead Block, ekran testi kontrolü:


İşlevsel testle ilgili olarak: önemli ölçüde daha az kod satırı var, test kapsamının eksiksizliği arttı ve test değiştiğinde güncelleniyor dış görünüş sayfadaki bu blok fazla zaman almayacaktır.

Bu bloğun test edilmesi, ekran görüntüsü yöntemiyle ilgili bölümde ele alınmıştır.

WaPo Bilgi Bloğu:


Galen, verilen bloğun metninin ve bağlantılarının uygunluğunu kolayca kontrol edebilir: bağlantıların kendileri yer bulucuda ayarlanır ve metnin uygunluğu dahili bir galen kontrolü ile kontrol edilir. İşlevsel test ile ilgili olarak, test kapsamının eksiksizliği değişmedi ancak kontrollerin tek bir test çerçevesinde yapılması nedeniyle önemli ölçüde zaman tasarrufu sağlıyoruz.

Galen test kodu.

Bizim otomatik sistem test kullanımları: Java, Maven, TestNG, Selenyum Web Sürücüsü, Selenyum Izgarası, Galen Çerçevesi.

Platformlar arası bir dizi yardımcı program, Ekran Görüntüsü tabanlı testler oluşturmamıza aktif olarak yardımcı olur ImageMagick.

Test kodunu Java'da PageObject modelini ve Yandex çerçevesini kullanarak yazdığımızı hemen not etmek isterim - HTML Öğeleri . Testleri çalıştırmak için Maven ve testNG kullanılır.

Testlerin başlatılmasını kolaylaştırmak, test başlatma geçmişini görüntülemek, yüksek nitelikli uzmanların katılımı olmadan raporları görüntülemek için geliştiriyoruz ayrı uygulama- Gösterge Paneli.

Şu anda tüm test sürecinin nasıl düzgün bir şekilde organize edileceğine dair araştırma aşamasında olduğumuzu ve tüm yaklaşımlara henüz tam olarak hakim olunmadığını ve incelenmediğini vurgulamakta fayda var.

Galen Çerçevesi ile Test Etme

Galen Framework'ün pek çok şüphesiz avantajı vardır: geniş bir duyarlı tasarım test etme yetenekleri yelpazesine sahip, esnek, kullanımı kolay bir araçtır. Ek olarak, şu anda iyi bir şekilde belgelenmiştir ve aktif olarak geliştirilmektedir.

Galen Çerçevesi zaten birinde yeterince ayrıntılı olarak açıklanmıştır. nesne . Galen ile çalışma prensibini kısaca tanımlarsanız, şuna benzer: özel, iyi belgelenmiş ve sezgisel bir sözdizimi kullanarak bir sayfa belirtimi (sözde özellik dosyası) yazarsınız. Spec dosyası, sayfa öğelerinin göreli konumunu, boyutunu, girintilerini, iç içe geçmesini ve sayfa düzeninin uyması gereken diğer bazı parametreleri ve koşulları açıklar, hatta öğenin içindeki metnin uygunluğunu kontrol edebilirsiniz. Ve tüm bu kontroller belirlediğimiz etiketlere bağlı olarak uygulanacaktır.

Spec dosyasındaki etiketler aşağıdaki şekilde belirtilebilir:






Galen tüm kontrolleri gerçekleştirir ve ardından bir html dosyası biçiminde görsel bir rapor oluşturur. Rapor, belirli bir test için hangi belirli kontrollerin başarısız olduğunu gösterir ve başarısız olan kontrollerin her biri için, belirli bir kontrolde başarısız olan öğelerin vurgulanacağı, test edilmekte olan sayfanın tam ekran görüntüsünü görebilirsiniz.
Örneğin, bitişik öğeler arasındaki mesafe için başarısız bir kontrol, raporda şöyle görünür:




Kırmızı ile vurgulanan bir onaya tıkladığınızda, aşağıdaki vurgulanan öğelerle birlikte tüm kontrol edilen sayfanın ekran görüntüsü görüntülenir:




Galen Framework aşağıdaki parametreleri girdi olarak kabul eder:

• kontrol etmek için tarayıcı
• testin çalıştırılacağı çözünürlük
• test edilen sayfanın url'si
• .spec dosyasına karşı kontroller başlamadan önce başlatılan sayfada (gerekirse) uygulanması gereken Javascript dosyası (örneğin, sitede oturum açmış bir kullanıcıya sayfanın görüntülenmesini kontrol etmeniz gerekiyorsa)
• çalıştırılacak .spec dosyasının adı
• .spec dosyasının kontrollerine uygulanması gereken etiketler (örneğin: masaüstü için düzeni test ediyorsak masaüstü, tümü).

Gördüğünüz gibi, Galen'e verilen parametreleri değiştirerek sitemizin çerçevesinin neredeyse eksiksiz test kapsamını elde etmek mümkündür.

Site çerçevesi test aracına karar verdikten sonraki görev, Galen testleri ile sayfanın maksimum kapsamını sağlamamıza izin verecek bir şema seçmekti.

Aynı türdeki sayfaların bir alt kümesinden test edilecek bir sayfa seçme

Test aynı türden birçok sayfayı test etmek için tasarlanmışsa, düzeni test etmek için hangi sayfaları seçmelisiniz?

Özellikle uğraşmadan, test paketi her başlatıldığında bir alt kümeden rastgele bir sayfa seçmeye karar verdik (yani, tarif sayfalarının bir alt kümesini test etmek için tariflerden birini seçtik ve URL'sini düzenlere göre tüm testlere ilettik). Görevin tüm sayfalarını kontrol etmeye değmeyeceğinden, rastgele bir sayfa seçme seçeneği en uygun görünüyordu. Kontrol edilen bir sayfa alt kümesindeki rastgele bir sayfanın URL'si, otomatik site test sistemimiz içindeki tüm testlerde ortak olan bir yöntemle Galen'e iletilir (düzen testi testlerine ek olarak, işlevsellik ve ekran görüntüsü testlerimiz de vardır).

Örneğin, aynı türde sayfaları görüntülemek için 2 seçenek vardır - yemek tarifleri sayfaları, bunlardan birinde düzen bir hata içerir:




Örnek, sayfanın sağ sütununda yer alması gereken “En Çok Okunan” bloğunun sağda değil, ana bölümde sol sayfada yer aldığını göstermektedir. Böyle bir sorun olmadığını kontrol etmek için kontrol etmeniz gerekir. Büyük sayı sayfalar ve birçok faktörü dikkate alın.

Testleri çalıştırmak için hangi izinler?

İlk başta, en yaygın cihazları seçme ve testleri çalıştırmak için izinlerini kullanma fikri geldi. Bununla birlikte, gezegenin açıkça izlenebilir olan hızlandırılmış seferberlik eğilimi, bu alanda tartışmasız herhangi bir lideri ayırmamıza (ve dahası, tahmin etmemize) izin vermiyor. Web uygulamalarını görüntülemenize izin veren birçok cihaz var ve bu tür cihazlar için izinlerin birleştirilmesi bugün hiç de moda değil. Duyarlı tasarımın duyarlı olması, herhangi bir geçerli çözünürlükte doğru şekilde görüntülenmesi gerektiği şeklindeki ani ima, aklımızı kurtardı ve bu alanda daha fazla araştırmayı durdurdu. Karar verildi: düzeni tüm geçerli izinler üzerinde test ediyoruz.

Geçerli izinler, minimum Görüntü Alanı genişliği = 241 piksel (tarayıcının küçülmediğinden daha az) ile maksimum Görüntü Alanı genişliği = 1920 piksel (üst sınır - basit bir irade ile) arasındaki tüm izinlere atanmıştır. Henüz, otomatik test amacıyla görünümün yüksekliğinin tanımlayıcı parametre olduğu sayfalarımız olmadı, bu nedenle henüz yüksekliğe dikkat etmiyoruz.

Düzen tüm çözünürlüklerde nasıl test edilir?

Başlangıç ​​olarak, tüm geçerli izinler aralığı farklı düzen aralıklarına bölünmüştür. Yerleşimlerin kendisi "kauçuk", ancak blokların farklı yerleşimi bir ayrım yapmanızı sağlıyor. Düzenlerin sınırlarını belirlemek kolaydır - tarayıcının köşesini sürükleriz ve sayfa bloklarının hangi sınır noktasında değiştiğine bakarız: göreceli konumları, sayıları ve / veya davranışları. Basitleştirmek için, yalnızca görünümün genişliğini dikkate alıyoruz. Sonuç aşağıdaki tablodur:

MASAÜSTÜ: maks. 1920 piksel, min. 1018 piksel;
DİZÜSTÜ BİLGİSAYAR: maks. 1017 piksel, min. 769 piksel;
TABLET: maks. 768 piksel, min. 481 piksel;
MOBİL: maks. 480 piksel, min. 361 piksel;
SMALL_MOBILE: maks. 360 piksel, min. 280 piksel.

Bu arada, SMALL_MOBILE düzenini henüz test etmemeye karar verdik, çünkü böyle bir çözünürlüğe sahip cihazlarda Washingtonpost'u görüntüleyen kullanıcı sayısı feci derecede düşük (spekülatif bir sonuç ve gelecekte test sırasında bunu eklemek sorun değil). Farklı düzenlerle 4 aralığı test etmeye devam ediyor.

Masaüstü çözünürlükleri için Galen testini çalıştırma kodu aşağıdadır:

gizli metin

Her testi çalıştırırken, Galen'e verilen düzen için aralıktan rastgele bir çözünürlük verilir (getRandomResolution(DESKTOP)):

Ve aslında, izin aralığı şu şekilde belirlenir:

Geçerli bir aralıktan rastgele bir çözünürlük ve benzer sayfalardan oluşan bir alt kümeden bir test sayfası seçerek test etme, böylece olasılıksal bir sürece dönüşür. Ne kadar sık ​​lansman yaparsak o kadar farklı hatalar buluruz. Testin tek bir başarılı geçişiyle, yalnızca bu belirli sayfanın bu belirli çözünürlükte geçerli olduğunu söyleyebiliriz. Ancak 500 başarılı çalıştırmadan sonra, düzenin çoğunlukla uygulanabilir olduğunu söyleyebiliriz. Hemen bir rezervasyon yapalım ki “500 başarılı çalıştırma” spekülatif bir tahmin ve burada içerik ve eşdeğer sayfa sayısına bakmanız gerekiyor.

Rastgele çözünürlükte çalıştırmak çok hızlı bir şekilde karşılığını verdi ve testleri sabit çözünürlükte çalıştırırken büyük olasılıkla gözden kaçırmış olacağımız ilginç bir hatayı anında ortaya çıkardı.

Bir tarif sayfasını test etme örneğini kullanarak bu yaklaşımın bize nasıl yardımcı olduğunu görelim.

Tarif sayfası tel kafes testi, 768 piksel ila 1017 piksellik bir Görüntü Alanı genişlik aralığı için çalışır. Örnek olarak bu sayfayı ele alalım: www.washingtonpost.com/pb/recipes/maple-banana-frozen-yogurt/14143/

Dizüstü bilgisayar düzeninin (1017px ve 768px) kenar noktalarında yapılan test herhangi bir hata vermedi.

Ancak, testi rastgele bir çözünürlükte çalıştırmaya başladıktan sonra, vakaların yaklaşık yarısında testler çöktü ve ekran görüntüleri, sağ sütundaki blokların ana içeriğin altına kaydığını gösterdi.

Doğru görünüm:

Dikkatlice! büyük fotoğraf

gizli metin

Düzen bozuldu:

Dikkatlice! büyük fotoğraf

gizli metin

Ekran görüntüsü tabanlı test yöntemi

Makaleden ilham alındı , ekran görüntüsüne dayalı test yöntemini kullanmaya karar verdik. Bu arada, düzeni test etmek için başlangıçta bu yönteme güvendik. Onlar. sayfanın tam boyutlu ekran görüntülerini önceden hazırlanmış bir modelle karşılaştırma, potansiyel olarak değişen tüm öğeleri taslaklarla değiştirme fikri vardı (önceden seçilmiş rastgele bir görüntü taslak olarak alınır). Bu öğeler arasında resimler, flash reklamlar ve metin yer alır. Fikir, temel olarak, sayfaların dinamik olarak yüklenen birçok blok içermesi ve bunun sonucunda alınan ekran görüntülerinin fiziksel boyutlarının ve blokların konumlarının test çalıştırmasından çalıştırmaya değişmesi nedeniyle başarısız oldu. Ek olarak, Chrome bir süredir tam boyutlu ekran görüntüleri alma yeteneğini kaybetti ve bu da bir dizi sorun yarattı.

Ekran görüntüsüne dayalı testler artık sayfadaki görüntülemenin önemli olduğu ve/veya işlevsel veya galenik testlerle hangi doğrulamanın zor veya imkansız olduğu tek tek öğeleri ve blokları kontrol ediyor.

Örneğin:

MostRead bloğu böyle görünüyor ana sayfa washingtonpost.com (solda) ve bu bloğun ekran görüntüsünü karşılaştıracağımız model (sağda):



Test kodu şöyle görünür:

Ekran görüntülerini depolamak için aşağıdaki dizin yapısı kullanılır: /models/HomePage/firefox/HomePage_thePostMost.png

Buradan da görüleceği üzere, farklı tarayıcılar gerekli bloğun model ekran görüntüsü alınır.

shootAndVerify() yöntemi, geçirilen sayfanın sınıfına ve testin çalıştırıldığı tarayıcının adına göre modelin yolunu bulur.

İleriye baktığımızda, oldukça iyi çalıştığını varsayalım ve ardından, henüz her şeyin tam olarak ayıklanmaması şartıyla, sürecin bazı ayrıntılarını açıklayacağız.

Görünüşe göre, gerekli bloğun anlık görüntüsü aşağıdakiler gibi birçok faktöre bağlı olabilir:

• işletim sistemi versiyonu
• işletim sistemi teması
• tarayıcı ve sürüm
• çeşitli yazı tipi yumuşatma seçenekleri ve donanım hızlandırma.

İlk sorun, alınan ekran görüntülerinin boyutlarının işletim sistemine ve tarayıcı ayarlarına bağlı olarak değişmesiydi. Blokların boyutlarını ve dolayısıyla ekran görüntülerini aynı yapmak için tarayıcıyı sabit boyutlarda çalıştırmanız gerekir. Uygun web sürücüsü yöntemini kullanarak tarayıcı penceresinin boyutunu değiştirebilirsiniz: driver.manage().window().setSize(requiredSize). Ancak bu şekilde, ihtiyacımız olan görünür alanın boyutunu değil, pencerenin boyutunu ayarlıyoruz - görünüm. Bu arada dikey kaydırma çubuğu, görünümün boyutunu da etkiler ve kalınlığı da pencere temaları, yani bu dikkate alınmalıdır. Sorunun çözümü, görünümün boyutunu sığacak şekilde ayarlayan bir kalibrasyon yöntemiydi. verilen boyutlar. İlk testi çalıştırdıktan sonra, pencere boyutunun genişliği ile görünümün genişliği arasındaki fark özel bir parametrede saklanır ve sonraki çalıştırmalarda yeniden kullanılır.

Karşılaştığımız ikinci sorun, kenar yumuşatma ayarları nedeniyle tarayıcılarda yazı tiplerinin farklı oluşturulmasıydı. Yükleyerek sorunu çözmeye çalıştım çeşitli ayarlar tarayıcı gibi:

katmanlar. hızlanma. devre dışı
gfx.font_rendering.cleartype_params.rendering_mode
gfx.direct2d.devre dışı

Ama maalesef yardımcı olmadı.

Ayrıca ImageMagick, ekran görüntülerini karşılaştırmak için fuzz gibi bir parametre kullanır ve bu, ekran görüntüleri arasındaki olası maksimum tutarsızlığı ayarlar.

karar vermeye çalıştım bu sorun bu ayarı deneyerek. Küçük bir tüylenme katsayısı sorunu çözmedi, çünkü çok fazla metin olması nedeniyle farklı piksellerin sayısı çok büyüktü ve büyük bir tüylenme katsayısı, bloklarda bazı öğelerin bulunmamasına neden oldu. test geçişini etkilemedi ve potansiyel olarak gözden kaçan hatalara yol açtı.

Çıkış yolu, çeşitli tarayıcıların tüm ayarlarını herkes için kopyalamaktı. Sanal makineler, üzerinde testlerin yapıldığı ve işletim sistemi ayarlarının kendilerinin kopyalanması.

Örneğin, resimlerden birinin yüklenmediği bir sosyal düğmeler bloğunu kontrol eden bir test.

Rapordaki bağlantılar mevcuttur:

resim modeli


test edilen ünitenin ekran görüntüsü:


bu iki resmi karşılaştırmanın sonucu:


CommandException, karşılaştırılan görüntülerin 251 piksel farklı olduğunu söyler:



Ekran görüntülerinin boyutlarının eşleşmediği durumlar da vardır. Bu durumda, aşağıdaki raporu alacağız:




Bazen, bilinmeyen nedenlerle, test edilen bloğun içindeki öğeler biraz yanlış hizalanır. Bu gibi durumlarda, tek bir modelle değil, maskeyle eşleşen bir grup modelle karşılaştırırız, örn. PostMost bloğunun HomePage_thePostMost.png, HomePage_thePostMost (1).png gibi adlara sahip birkaç modeline sahip olabiliriz ve tüm modeller geçerli kabul edilir. Neyse ki, bu tür seçeneklerin sayısı sınırlıdır, genellikle 2'den fazla değildir.

Teknik yönler

Yukarıda bahsedildiği gibi, testler yazmak ve çalıştırmak için bir yığın teknoloji kullanılır: Java, Maven, TestNG, Selenium, Galen Framework. Ayrıca test sonuçları grafite gönderilir. Testler doğrudan Jenkins CIS kullanılarak gerçekleştirilir. Neden böyle bir setin seçildiği üzerinde durmayacağız. Tüm bunların birbiriyle nasıl bağlantılı olduğunu kısaca açıklayalım.

Selenium Grid artık dörtte yerel olarak dağıtılıyor Sanal makinelerızgara düğümlerini çalıştıran Windows 7'de ve hub'ı çalıştıran bir Linux makinesinde. Her düğümde 3 adet firefox ve chrome tarayıcı örneği bulunur. Ek olarak, Jenkins ve grafit de Linux makinesinde konuşlandırılmıştır. Galen testleri, TestNG ile entegrasyon sayesinde genel test çalışmasında yürütülür. Bunun için java Galen API'sini kullanmanıza izin veren uygun bir sınıf yazılmıştır. TestNG etkileşimini galen ile uygularken, galen geliştiricisi ile etkileşim yoluyla hızla çözülen bazı sorunlarla karşılaştık. Galena geliştiricisinin kendisi işbirliği yapmaya isteklidir ve bu araç için yeteneklerini genişleten ve onu daha da kullanışlı hale getiren güncellemeleri düzenli olarak yayınlar. Kendisi, Galen'in TestNG ile entegrasyonu hakkında belgeler yazmayı planlıyor.

Fonksiyonel, galen ve ekran görüntüsü tabanlı testler, Test ek açıklamasına atanan ilgili grup parametresi kullanılarak ayrılır ve bunları ayrı ayrı çalıştırmak mümkündür.

Sonuçlarımız

Her iki yaklaşım da - ekran görüntüsü karşılaştırma yöntemi ve Galen Çerçevesi ile test etme - sayfa düzeni testine uygulanabilir. Birbirlerini başarıyla tamamlarlar. Bazı ekran görüntülerini test etmeniz gerektiğinde ekran görüntüsü karşılaştırma yöntemi daha uygundur. bireysel eleman veya bir blok, örneğin "paylaşım" paneli sosyal ağlar veya başlıktaki ana menü. Bir blok, kendi içinde, diğer simgelerin ve öğelerin içinde olabilen veya onlarla göreli konumlandırmaya sahip olabilen birçok simge içerebilir.

Tüm bu küçük anları açıklamak için Galen'i kullanmak oldukça zaman alıcıdır, ancak tarayıcı başına bir ekran görüntüsü bu sorunu çözer ve ekran görüntülerini karşılaştırmak, özellikleri açıklarken bir şeyi gözden kaçırabileceğimiz seçeneği ortadan kaldırır. Öte yandan Galen, blokların göreli konumlandırılması ve içlerindeki başlıkların ve sabit metnin kontrol edilmesiyle harika bir iş çıkarıyor. O sahip iyi kullanım, mizanpajı işlevsel mantıkla yüklenmemiş aynı türde şablonlu sayfalarda test etmeniz gerektiğinde, örneğin herhangi bir bilgi portalı, bizim durumumuzda olduğu gibi, sitenin hemen hemen her sayfası yetkilendirme veya diğer herhangi bir kullanıcı eylemi olmadan kullanılabilir olduğunda. Ek olarak, Galen, uyarlanabilir uygulama düzeni koşullarında tarayıcılar arası test görevlerini iyi çözer.

Merhaba sevgili blog okuyucuları. Uyarlanabilir tasarımın Rus İnternetinde giderek daha popüler hale gelmesi şaşırtıcı değil. Ve elbette, yerleşim tasarımcılarının bunu incelemesi gerekir. Duyarlı tasarım yakında neredeyse tüm sitelerde olacağından, çünkü giderek daha fazla insan mobil cihaz kullanıyor.

Ve bu tür cihazlarda okumanın onsuz olduğundan çok daha uygun olduğunu söylemek istiyorum.

Bugün size sitenin uyarlanabilirliğini kontrol edebileceğiniz çok kullanışlı ve harika 5 hizmet sunmak istiyorum.

Öyleyse gidelim.

Siteyi uyarlanabilirlik açısından kontrol edebileceğiniz 5 hizmet.

www.responsivedesigntest.net

Siteleri kontrol etmek için iyi bir hizmet. Hem tabletler hem de telefonlar için birçok ekran çözünürlüğü bulunmaktadır.

mattkersley.com

Matt Kersley'den bir web sitesini kontrol etmek için basit bir hizmet. Mobil cihazların tüm popüler çözünürlükleri de mevcuttur.

ekran sorguları

Herhangi bir siteyi kontrol edecek çok harika bir hizmet. Tasarımını ve işlevselliğini çok beğendim.

quirktools.com

Çok güzel ve işlevsel bir hizmet. Hatta sitenin televizyonda nasıl görüneceğini kontrol etmek bile mümkün :-)

Teknoloji sürekli gelişiyor, akıllı telefonlar ve tabletler daha da soğuyor ve kullanıcılar mobil. Şu anda, mobil cihazlardan gelen izleyici sayısı, kişisel bilgisayarlar. Bunun altında tüm sitelerin yönüne yol açması boşuna değildir. mobil cihazlar.

Örneğin, bir akıllı telefon aracılığıyla normal bir siteyi (uyarlanabilir düzen ve mobil sürüm olmadan) açarsanız, büyük olasılıkla kullanıcı için uygun olmayan bir biçimde açılacaktır. Onlar. içerik tam olarak görüntülenecek, ancak yatay kaydırma olacak ki bu kötü bir durum.

1. Uyarlanabilir web sitesi düzeni - nedir bu

Duyarlı site düzeni- o gibi html düzeni, tarayıcı penceresinin boyutuna bağlı olarak sitenin kullanıcı dostu bir görünüme "dönüştürüldüğü"

kafan karışmasın mobil versiyon site ve sitenin uyarlanabilir düzeni. Mobil sürüm, ayrı bir alt alan adında bulunur ve sitenin içeriğini tamamen kopyalar. Duyarlı site, aynı sayfa URL'lerini içeriyor ancak cihaza bağlı olarak yükleniyor farklı stiller Siteyi daha rahat bir şekilde görüntülemenizi sağlayan CSS.

2. SEO optimizasyonu ve uyarlanabilir düzen

Arama motorlarının şu anda iki farklı sonucu var (çok benzerler). Biri PC kullanıcıları için, diğeri mobil cihazlar için. Site mobil cihazlar için optimize edilmemişse, bu olumsuz bir faktör olarak kabul edilir ve sitenin konumu 2-3 (bazen daha fazla) düşürülür. Aynı zamanda, yalnızca mobil versiyonun konumlarının hafife alınması mantıklı olacaktır, ancak uygulama aynı zamanda sitenin ana sürümünün konumlarının da kötüleştiğini göstermektedir.

Bu adaletsizlik, arama motorlarının PC'lerden ve mobil cihazlardan davranışsal faktörleri toplama olasılığının daha yüksek olmasıyla açıklanabilir. Sonuç olarak tabii ki site uyarlanmazsa PF'si daha kötü olur ve bu da sitenin ana sürümünü aşağı çeker.

3. Sitenin uyumluluk açısından nasıl kontrol edileceği

Siteyi uyarlanabilirlik açısından yalnızca içinde açarak kontrol edebilirsiniz. farklı tarayıcılar ve ekranın genişliğini değiştirerek. Ama setten yap çeşitli cihazlarİle farklı izinler- çok zaman alacak. Elinizde düzinelerce akıllı telefon ve tablet olması da olası değildir.

İnternette çok daha hızlı ve kolay bir çözüm var. Örneğin, tarayıcıya yükleyebilirsiniz. Google Chromeözel bir Windows Resizer eklentisi ve siteyi en popüler çözünürlüklerde açmak için kullanın.

Tarayıcı penceresini genişlik olarak manuel olarak yeniden boyutlandırabilir ve sonucu görebilirsiniz. Firefox veya Google Chrome, Ctrl+Shift+M tuşlarına basarak yanıt veren bir tarayıcı tasarımına sahiptir.

En önemli koşul, sayfada yatay kaydırma olmamasını ve flash eklentilerin olmamasını sağlamaktır.

Google, uyarlanabilirlik faktörünü arama algoritmasına sokan ilk kişi oldu. onun özel bir yeri var ücretsiz servis, mobil cihazlar için optimizasyon için herhangi bir siteyi analiz eder. Yandex bu işlevselliğe biraz sonra sahipti.

Kontrol ettikten sonra iki seçenek vardır. Site optimize edilmiş veya edilmemiş:

Örneğin, Google'ın duyarlı kontrolü:

Yandex'de uyarlanabilirliği kontrol etme:

4. Uyarlanabilir bir web sitesi düzeni nasıl yapılır?

Yalnızca CSS ve html'den anlayan bir kişi sitenin uyarlanabilir bir düzenini yapabilir. Tek bir tarif olmadığı için ana noktaları ele alacağız.

Duyarlı bir düzen oluşturmak için üçüncü sürümde CSS stil sayfaları oluşturmanız gerekir. 2 ile 3 arasında fark var ama tarzlarda mutlak değerlerin olmaması bu konuda çok önemli. Kısacası, tüm blok boyutu değerleri - uzunluk, genişlik, boyutlar - hepsi yüzde olarak verilmiştir.

@Medya CSS Sözdizimi

@medya device_type ve|sadece|değil (media_features){ ... Stillerin açıklaması... }

Örneğin ekran genişliği 800 pikselden küçük olan cihazlarda stillerin hangi koşullarda çalışacağını yazalım.

@media ekranı ve (maksimum genişlik: 800 piksel) ( ... stiller ... )

Stiller sırayla yazılmalıdır yüksek çözünürlük küçüğe, yani önce genel stiller ve ardından "kesilmiş" boyutlar için, örneğin:

@yalnızca ortam ekranı ve (maks-genişlik: 1280 piksel) ( ... ) @yalnızca ortam ekranı ve (maks-genişlik : 1024 piksel ) ( ... ) @yalnızca ortam ekranı ve (maks-genişlik : 800 piksel ) ( ... )

Başlık etiketlerinde şu satırı yazdığınızdan emin olun:

Viewport meta etiketi, ekran genişliğinin tarayıcı genişliğine eşit olduğunu ve cihazdaki her pikselin bir piksele karşılık geldiğini söyler. Bu belirtilmezse, uyarlanabilirlik uygulanamaz.

5. Uyarlanabilir web sitesi düzeninin pratik örnekleri

5.1. Çok uzun kelimeleri uyarlama

Örneğin, sayfada çok uzun bir kelime görünecek ve ardından taşma özelliği ayarlanmamışsa, bu, yatay kaydırma görünümüne yol açabilir. Bundan kaçınmak için aşağıdaki içeriği yazmanız gerekir. CSS özellikleri

.hphns ( taşma sarma : kelime kırma ; kelime sarma : kelime kırma ; -webkit-tireler : otomatik ; -ms-tireler : otomatik ; -moz-tireler : otomatik ; tireler : otomatik ; )

5.2. Duyarlı web sitesi menüsü

Bir web sitesinin kenar çubuğu genellikle 200-300 piksel genişliğindedir ve bu, mobil cihazlarda tarayıcının neredeyse tüm genişliğini kaplar. Bu nedenle, açılır menüler çoğunlukla üç vuruş şeklinde standart bir düğme kullanılarak yapılır (bu zaten bir klasik haline geldi).

Bunu sitede uygulayabilirsiniz, ancak stilleri biraz kurcalamanız gerekir. Her şeye adım adım bakalım.

Bir menümüz olduğu ve ana içeriğe sahip olduğumuz durum (Üstbilgi ve altbilgiyi çizmedim):

Böyle bir yapı için html kodu şöyle görünebilir:

Меню

• Ссылка в меню 1
• Ссылка в меню 2
• Ссылка в меню 3
• Ссылка в меню 4

Название страницы

Контент страницы

Контент страницы

Контент страницы

Контент страницы

Преобразуется на странице в

Минусом этого способа является то, что на маленьких разрешениях меню будет занимать почти всю область по ширине, а значит появится горизонтальная прокрутка или еще хуже - все блоки могут поплыть.

Модифицируем наш пример следующим образом. Если разрешение экрана меньше 800 пикселей, то меню исчезнет и появится специальная кнопка открыть меню.

Приведем html-код адаптивной верстки с комментариями:

Раскрыть меню ↓

Меню

• Ссылка в меню 1
• Ссылка в меню 2
• Ссылка в меню 3
• Ссылка в меню 4

Название страницы

Контент страницы

Контент страницы

Контент страницы

Контент страницы

Уменьшим ширину экрана до 700 пикселей (к примеру). Вот как это выглядит на странице

Тест показывает, как выглядит адаптивный сайт на различных мобильных устройствах. Для проверки ваш сайт должен поддерживать загрузку и работу во фреймах. Для удобства просмотра переведите браузер в полноэкранный режим.

Проверить

Что такое адаптивный сайт?

Адаптивный сайт автоматически подстраивается под ширину устройства. При этом блоки сайта могут скрываться или видоизменяться. Например, на компьютере логотип и меню сайта располагаются слева направо, а на телефоне — сверху вниз.

Чем отличается адаптивный сайт от мобильной версии?

Если у сайта есть мобильная версия, то при загрузке такого сайта с мобильного телефона, вас перенаправят на другой адрес: site.ru → m.site.ru. Мобильная версия — это отдельный сайт с другим адресом.

Если же у сайта нет мобильной версии, адрес сайта не изменится при загрузке с телефона. На телефон будут загружаться те же самые данные, что и на компьютер. Чаще всего это неудобно для пользователя, потому что экран телефона меньше в несколько раз.

Данная проблема решается двумя способами: добавить мобильную версию m.site.ru или НЕ делать отдельный сайт, но добавить вашему основному сайту адаптивности. Это специальные стили и скрипты, которые включаются, если ширина экрана слишком мала: например, спрятать меню, увеличить шрифт, вместо крупных изображений показать маленькие и т.п.

Строго говоря, нельзя сравнивать адаптивный сайт и мобильную версию сайта. По сути адаптивный сайт = полная версия + версия для планшетов + версия для телефонов (мобильная), и всё это в одном флаконе. То есть, одно понятие заключено в другом.

Адаптивный сайт совмещает в себе и обычный (для PC), и мобильный (для телефонов), и несколько промежуточных вариантов (крупные телефоны, планшеты, телевизоры и т.д.). Главное преимущество адаптивного сайта — он хорошо выглядит на любой ширине экрана.

Почему ширина телефона в данном сервисе такая маленькая?

Реальное количество пикселей на современных гаджетах, как правило, очень велико, а сайты не рассчитаны на такую огромную ширину. Поэтому мобильные устройства с экранами повышенной чёткости открывают сайты, приведя их к некоему виртуальному стандарту. Чтобы узнать эти цифры у себя, нажмите кнопку, открыв эту страницу с телефона или планшета:

Какой у меня размер окна браузера?

На устройствах с ретино-подобными дисплеями показанные размеры будут отличаться от реального разрешения в пикселях, которое указано в спецификации устройства. Смартфоны покажут 320×480 или 480×800 пикселей, планшеты — 1280×800.

От автора: у вас в руках файлы с версткой. Но как проверить ее качество? Какие инструменты существуют для тех, кто не разбирается в HTML и CSS? Какими полезными вещами стоит пользоваться самому верстальщику? Эта статья попробует ответить на эти вопросы.

Почему важно проверять качество верстки

Вопрос, который волнует как заказчиков, так и самых верстальщиков. Первые так могут убедиться в том, что исполнитель выполнил свою работу качественно. Верстальщику же полезно будет проверить верстку сайта перед тем, как посылать ее на одобрение клиента. Это позволит экономить время, иначе может возникнуть ситуация, когда правки придется вносить уже после сдачи проекта. Если вы сами создаете свой сайт, инструменты проверки тоже вам пригодятся.

Инструменты для проверки

Отладчик . Один из самых простых способов, как можно проверить верстку сайта – включить отладчик. Он запускается при нажатии в браузере F12. Этот инструмент помогает увидеть, как изменится вид страницы, если из нее убрать какие-то элементы или стили. Например, вы прописали какое-то новое CSS-свойство, потом прописали еще несколько. Решили посмотреть, как все это будет выглядеть в браузере.

Оказалось, что элементы отображаются не так, как планировалось. Из-за какого свойства произошла такая ошибка? Вручную это определять долго. В отладчике же вы можете быстро отключить любые стили и быстро обнаружить ошибки. Также в нем хорошо видно опечатки. Большинство опытных верстальщиков ищут ошибки именно с помощью отладчика, а не самостоятельно просматривая код.

Рис. 1. С отладчиком находить ошибки проще

W3C Валидатор . Сервис проверки кода на мелкие ошибки. W3C – это организация, которая занимается разработкой и официальной поддержкой веб-стандартов. Поскольку она устанавливает эти стандарты, на ее сайте есть специальный сервис, который может проверить любую страницу в сети на валидность (то есть на ошибки). Нужно сказать, что это достаточно строгий валидатор.

Часто им пользуются заказчики, пытающиеся так определить качество верстки. Даже в хорошо сверстанной страничке валидатор может найти более тридцати ошибок. Однако в этом нет ничего страшного. Сервис считает за ошибку даже то, что вы не поставили пробел перед значением html-атрибута. А теперь представьте, что в таком стиле вы написали весь код. У вас будут сотни ошибок, но на самом деле верстка будет выполнена правильно, просто вы нарушите стандарты, которые W3C установили на счет правильного написания кода.

Подробнее с этими правилами можно ознакомиться на сайте W3C. По сути, единственный сайт, который валидатор проверяет без ошибок, это сайт самой W3C. Поэтому не стоит исправлять все ошибки. И все-таки валидатор может указать на какие-то серьезные проблемы, поэтому проверка верстки сайта в нем желательна. validator.w3.org — валидатор.

IE Tester . Существует такая программа, которая позволяет протестировать сайт в старых версиях Internet Explorer. Многие заказчики сегодня все еще требуют поддержку этого браузера, чтобы сайт в нем отображался так же, как и в других. Возможно, сейчас уже есть онлайн-сервисы, в которых можно выполнить аналогичную проверку. В любом случае, вам достаточно вставить нужный код и программа покажет, как все это отображалось бы в IE 6, 7 и 8.

Обычно поддержка шестой версии уже никому не нужна, а восьмая может вести себя вполне адекватно если, конечно, в вашей верстке не присутствуют новые CSS-свойства. У старых версий IE есть интересная особенность – они читают закомментированный код. Поэтому в одном из комментариев можно подключить таблицу стилей, которая будет создана специально для старых версий этого браузера.

Остальные браузеры просто пропустят этот фрагмент. Такой способ можно использовать, если вам действительно очень сильно нужна поддержка IE.

Другие сервисы . В последнее время сервисов для проверки верстки становится все больше и больше. Нет смысла останавливаться на каком-то отдельном. Большинство этих сервисов работают неплохо, но все равно не проверяют все досконально.

Как проверить адаптивную верстку

Отдельно стоит разговор об адаптивной верстке. Наилучшим вашим инструментом в этом деле будет обычное окно браузера. Просто уменьшайте ширину окна и наблюдайте, как меняется дизайн. Если вы видите, что появляется горизонтальный скролл или какие-то элементы не влазят на страничку, значит, ваша верстка далека до идеала и ее нужно дорабатывать. Если вы хотите увидеть, как будет себя вести сайт на большом экране – уменьшите масштаб. Конечно, если у вас есть планшет и телефон, то можно загрузить вашу верстку на какой-нибудь бесплатный хостинг и зайти на сайт с этих устройств.

Рис. 2. Изменение ширины окна браузера – самый простой способ проверить адаптивность.

Кроссбраузерность

Чем еще проверить верстку сайта? Обязательно должна быть проверка на кроссбраузерность. Нужны открыть сайты в различных браузерах и посмотреть, как они там выглядят. Можно изменять масштаб и размер шрифта. Вы должны убедиться, что хотя бы у большинства пользователей все будет нормально. Если вы проверяете вручную, то можете также попросить знакомых проверить верстку в их браузерах, если их версии отличаются от ваших. Здесь можно дать еще один совет – не используйте слишком специфических свойств, которые поддерживаются только в каком-то одном браузере. А если уже используйте, придумывайте для них какую-то альтернативу в других браузерах. Для некоторых свойств все еще нужно использовать вендорные префиксы. Это связано с тем, что веб-стандарты постоянно развиваются и все браузеры не могут поддерживать всего. Но если уже делать проверку на кроссбраузерность, то делать ее как минимум для таких браузеров: Chrome, Mozilla, Opera, Safari, IE.

Есть очень хорошие зарубежные сервисы продвинутой кроссбраузерной проверки. Например, browserstack.com. Такая проверка может стоить вам денег. Если у вас действительно очень крупный проект и вы хотите досконально проверить его, в таком случае есть смысл пользоваться подобными сервисами.

Проверка на соответствие с макетом

Проверить верстку можно еще так: скриншот сверстанного сайта необходимо добавить к макету в фотошопе в качестве нового слоя. Установить этому слою прозрачность и посмотреть, насколько отображение элементов совпадает с макетом. Для этого можно использовать специальный плагин. Например, Pixel Perfect для Mozilla.

Дополнительные требования

Естественно, в любой нормальной верстке должна быть прописана кодировка и doctype. Также страничку можно проверить на работоспособность при выключенных картинках или при блокировании javascript-кода. Дело в том, что в настройках любого браузера пользователь может отключить эти параметры. Особенно полезно будет прописать атрибуты alt для картинок, чтобы при их исчезновении пользователь хоть как-то мог ориентироваться. На самом деле требований к верстке может быть очень много. Даже в рунете есть достаточно строгий перечень необходимых проверок. Например, с появлением HTML5 верстку можно проверять на правильную семантическую разметку. Однако все это не является критичным. Вышеописанных проверок вполне хватит, чтобы смело запустить нормальный работоспособный сайт.

В этой статье мы описали основные способы проверки верстки с помощью различных программ, сервисов и инструментов. Это поможет вам адаптировать сайт под любые условия.