Kuruluşunuz hassas verileri düzenli olarak işliyorsa, yalnızca verilerin ait olduğu kişileri değil, kuruluşunuzu da herhangi bir federal yasayı (örneğin HIPPA, GDPR, vb.) ihlal etmekten korumak için veri güvenliği uyumluluğu stratejileri uygulamalısınız. Bu, sağlık, bankacılık, devlet, hukuk gibi sektörlerdeki kuruluşları… gerçekten hassas verileri işleyen herhangi bir kuruluşu etkiler.
Hakkında konuşuyoruz PII (Kişisel Olarak Tanımlanabilir Bilgiler) ve PHI (Korumalı Sağlık Bilgileri). PII örnekleri-
- Sosyal güvenlik numaraları
- banka hesabı
- Tam isimler
- Pasaport numaraları vb.
PHI örnekleri-
- Sağlık kayıtları
- Laboratuar sonuçları
- Bireysel tanımlayıcıları içeren tıbbi faturalar ve benzerleri
Hassas Verileri Koruma Yöntemleri
Bazı müşteriler yöntemlerini izlediğiniz bir filmde hayal edebileceğiniz sahneler olarak tanımladılar…Gerekli güvenlik izinleriyle donanmış bir grup insanı penceresiz, kilitli bir odada toplanmış olarak görselleştirin, hassas bilgilerin doğru olduğundan emin olmak için rapor çıktılarını manuel olarak kontrol edin. içermiyor. Bu, dramatik bir film sahnesi oluştursa da, raporları hassas bilgiler için test etmenin en kusursuz veya en etkili yolu değildir. Ve uzak Covid-19 iş gücü gereksinimleriyle, bu şu anda mümkün değil.
Müşterilerimizin birçoğunun, Cognos rapor çıktılarını dinamik olarak test etmek için otomatik testin gücünü uygulamasına yardımcı olduk. Bu test stratejisi, raporları erkenden, uygunluktan düşer düşmez ve yanlış ellere geçmek üzere üretime geçmeden önce yakalar. Size en yakın sosyal güvenlik ofisinin nerede olduğunu bilmek her zaman iyi bir fikirdir. Nevada'daki Sosyal Güvenlik ofisleri, en kötüsü olursa, yerel ofisinizdeki ekip durumu nasıl yöneteceğini bilecek.
Geliştirme Döngülerinde Erken Test Etmenin Değeri
Veri güvenliği açıklarını geliştirme aşamasında erken tespit etmek, gelecekte hükümet tarafından uygulanacak para cezalarından ve yaptırımlardan kaçınmaya yardımcı olabilir. Göre ABD Sağlık ve İnsani Hizmetler DepartmanıBugüne kadar, Medeni Haklar Ofisi (OCR) “75 davada toplam 116,303,582.00 ABD Doları tutarında bir para cezası ödedi veya verdi.” Bu, vaka başına 1.5 milyon doların üzerinde! Ve göre HIPAA Dergisi "kuruluş çapında bir risk analizi yapmamak, mali cezaya neden olan en yaygın HIPAA ihlallerinden biridir."
Devletin uyguladığı cezalardan kaçınmanın yanı sıra, sorunları düzeltmenin çok daha kolay ve daha ucuz olduğu aşama olduğundan, geliştirme döngüsünün başlarında hataları tespit etmek genellikle önemlidir. Sonuç olarak, bu alıştırmanın temel amacı, MotioCIregresyon testinin gücü, bu tür hataları kolayca tespit eder ve bu nedenle geliştirme döngüsünün başlarında bunları önler.
Testin nasıl kurulacağına bir göz atalım. Cognos ortamımızı kurmaya başlayacağız ve ardından örneğimiz için PHI ve PII verileri için otomatik testin nasıl kurulacağını açıklayacağız. Ek bir uyumluluk ve güvenlik kontrolü düzeyi için üretim ortamında da aynı test senaryolarını kullanacağız.
PHI ve PII Cognos Ortamı Kurulumu
Örnek Cognos ortamımız (Şekil 1), her biri PII ve PHI'ye duyarlı verilerin (ör. tanı kodu, reçete, sosyal güvenlik numarası, hasta soyadı vb.) ve minimum düzeyde hassas verilerin (ör. hasta) bir karışımını içeren birkaç rapordan oluşur. adı, ziyaret tarihi vb.).
Şekil 1: Örnek Cognos ortamımız.
İki Cognos rolü vardır, İzin verPII ve İzin verPHI, raporlar yürütülürken hassas verilerden herhangi birinin oluşturulup oluşturulmayacağını belirleyen. (Tablo 1)
| Cognos Rolleri | notlar |
| İzin verPII | Bu rolün üyeleri, Cognos raporlarındaki tüm PII (yani sosyal güvenlik numarası ve hasta soyadı) verilerini görüntüleyebilir. |
| İzin verPHI | Bu rolün üyeleri, Cognos raporlarındaki tüm PHI (ör. ICD10 tanı kodları, ayrıntılı tanı açıklaması vb.) verilerini görüntüleyebilir. |
Tablo 1: Hassas verilerin yorumlanmasını kontrol eden Cognos rolleri.
Örneğin, her iki Cognos rolümüzden yoksun bir kullanıcının "Hasta Günlük Alımı" raporu şöyle görünmelidir (Şekil 2):
Şekil 2: Hem AllowPII hem de AllowPHI rollerine sahip olmayan bir kullanıcı tarafından üretilen rapor çıktısı.
Gördüğünüz gibi, tüm PHI ve PII verileri, her iki "AllowPHI/PII" rolünde üyeliği olmayan kullanıcıdan tamamen gizlenmiştir.
Şimdi raporu “AllowPII” rolünün üyesi olan bir kullanıcıyla çalıştıralım, yani bu kullanıcının yalnızca PII verilerini görebilmesini bekliyoruz (Şekil 3):
Şekil 3: AllowPII rolünün DEĞİL, AllowPII rolünün üyesi olan bir kullanıcı tarafından üretilen rapor çıktısı.
Ve burada hem Sosyal Güvenlik Numarası hem de Soyadı sütunlarının herhangi bir düzeltme yapılmadan uygun şekilde göründüğünü görebilirsiniz.
Şimdiye kadar efsanevi kliniğimizin Cognos ortamına bir göz attık ve şu ana kadar gördüğümüz tek şey, birçoğunuzun kendi Cognos ortamlarınızda zaten uygulamış olabileceği Cognos rol tabanlı veri güvenliği. Bu da bizi hassas veri sahiplerinin asla yüzleşmek zorunda kalmayacağı ana soruya getirecektir:
Diyelim ki, yoğun bir geliştirme çabasından sonra, bazı hassas veriler kayıp ve bunu görmemesi gereken kullanıcılar için görünmeye başlarsa?
Hatalar kesinlikle kaçınılmazdır, bu yüzden daha sonra kullanacağımız blogda MotioCIÖzel verilerin asla istenmeyen hedef kitleye maruz kalmamasını sağlamak için raporlarımızı dikkatli bir şekilde takip etmek için regresyon testinin gücü.
Cognos için Uyumluluk Testini Anlama
Önceki bölümde bahsedildiği gibi, rapor yazma veya modellemedeki basit hatalar, Cognos ortamınızdaki raporların çıktısında istenmeyen davranışlara neden olabilir. Ve bu değişiklikler yakalanmazsa, Üretim ortamınıza gizlice girme potansiyeline sahiptirler. Daha da feci olan şey ise, bu istenmeyen değişiklikler, özel verilerin istenmeyen bir kitleye ifşa edilmesini içeriyorsa.
Örneğin, herhangi birine üye olmayan bir kullanıcı İzin verPII or İzin verPHI Cognos rollerinin, örnek Cognos ortamımızda PII veya PHI özel verilerini görmemesi gerekir. Ancak aşağıda görebileceğiniz gibi (Şekil 4), FM modelinde yapılan basit bir değişiklik, teşhis tanımının ve hasta SSN numarasının böyle bir kullanıcıya maruz kalmasına neden olmuştur ki bu, federal HIPAA Güvenlik Kuralı'nın BÜYÜK bir ihlalidir.
Şekil 4: AllowPII ve AllowPHI rol üyeliği olmayan bir kullanıcı bir şekilde HIPAA'ya duyarlı verilere maruz kalır.
Eşyaları taşımadan önce MotioCI, önce Cognos ortamımızda üç test kullanıcısı oluşturacağız ve bunları aşağıdaki şekilde iki rolümüze atayacağız (Tablo 2):
| Kullanıcılar | Rol Üyeliği | notlar |
| TestKullanıcıA | İzin verPII | Tüm PHI verileri bu kullanıcıdan gizlenmelidir |
| TestKullanıcıB | İzin verPHI | Tüm PII verileri bu kullanıcıdan gizlenmelidir |
| TestKullanıcıC | Hayır | Kullanıcının PHI veya PII GÖRMEMESİ bekleniyor |
Tablo 2: Cognos kullanıcı hesaplarını atanan rollerle test etme.
Bu test kullanıcı hesapları daha sonra MotioCI hassas PII ve PHI verileri içeren raporlarımızın regresyon testi için. Test sonuçlarımız, rol üyeliklerine göre her kullanıcı için hassas verilerin görünürlüğüne bağlı olacaktır.
Artık test kullanıcılarımızı ayarladığımıza göre, regresyon testimizi şu şekilde yapılandırmaya hazırız: MotioCI.
MotioCI Ortam Kurulumu
Örnek ortamımız Geliştirme, UAT ve Production Cognos örneklerinden oluşur. Rağmen MotioCI Üçüne de aynı anda giriş yapmamıza izin veriyorsa, Geliştirme ortamındaki regresyon testi kurulumumuza üç farklı aşamada başlayacağız.
Şekil 5: MotioCI giriş ekranı.
Şekil 6: MotioCI Cognos örneklerini gösteren ana ekran.
Regresyon testi ile ilgili olarak MotioCI, Bir iddia bir test senaryosunun bilgisayarınızdaki bir nesne üzerinde gerçekleştirdiği bireysel bir kontrol veya "test"tir. MotioCI örneğin bir rapor, klasör veya paket gibi. Hassas veriler için rapor çıktılarını test etme işini yapacak olan iddiaya denir. Hassas Veri Uyumluluk Testi (Şekil 7). Bu, bu alıştırma için bir araya getirdiğimiz özel bir iddiadır. Aşağıda görebilirsiniz iddia türü temel olarak, uygulamamız boyunca test senaryolarına kopyalanan ana şablon olarak işlev görür. MotioCI Çevre. Bu konuda daha sonra.
Şekil 7: “Hassas Veri Uyumluluk Testi” onay türü. Bu onayın kopyaları test ortamına dağıtılır.
Bazı iddialar, bazı kullanıcı tarafından ayarlanabilen işlevsellik sağlar. istem penceresi. Burada, verilen herhangi bir Cognos raporunu test etmek için belirli bir iddianın nasıl olmasını istediğinizi değiştirebilirsiniz. Aşağıdaki Şekil 8, istem penceresi hassas veriler içeren Cognos raporlarımızı test etmek için kullanacağımız iddiamızın özeti.
Şekil 8: Kullanıcı tarafından ayarlanabilen tüm test seçeneklerini gösteren "Hassas Veri Uyumluluk Testi" iddiasının bilgi istemi penceresi.
Şekil 8'de en üstte vurgulanan bölüm, PII ve PHI'ye duyarlı veriler için test seçeneklerini gösterir. Bu, raporun PII veya PHI verilerini göstermesi veya gizlemesi gerekip gerekmediğini onaylama testine sahip olmanızı sağlar. Üç test kullanıcımızın her biri için test senaryoları oluşturmaya başladığımızda bu iki seçenekte değişiklikler yapacağız.
Şekil 8'de ortadaki vurgulanan bölüm, raporlarımızda PHI'ye duyarlı verileri içeren sütunların adlarını gösterir. Örnek ortamımız ICD10 Teşhis Kodu, Teşhis Açıklaması, Prosedür ve Rx adlarına sahip sütunlardan oluşsa da, bu listeyi kesinlikle ihtiyaçlarınıza göre değiştirebilirsiniz.
Son olarak, Şekil 8'de vurgulanan alt kısım e-posta seçeneklerini gösterir. Bir arıza durumunda, bu onay, bu bölümde yapılandırılan alıcıya ayrıntılı bir e-posta mesajı gönderir.
Aşama I: Yalnızca Kişisel Bilgilerin Görüntülendiği Raporlar
altında bir proje oluşturalım. gelişme örnek MotioCI ve onu çağır Yalnızca PII'ye İzin Ver. Bunu ilk önce sağ tıklayarak yapabiliriz. gelişme içindeki örnek düğüm MotioCI gezinme ağacını seçin ve Proje Ekle seçeneği (Şekil 9).
Şekil 9: Yeni bir proje oluşturma. İçinde MotioCI her proje, içerik deposunun önceden tanımlanmış bir bölümü için bir test alanı görevi görür.
The Proje Sihirbazı Ekle projeniz için gerekli yolları seçmeniz için sizi bazı adımlardan geçirecektir. Örneğimizde, PII ve PHI'ye duyarlı verileri içeren tüm raporlar, Hasta Verileri dosya. Bu üst klasörün kontrol edilmesi, tüm temel raporları otomatik olarak içerecektir (Şekil 10 ve 11).
Şekil 10: Proje kapsamının belirlenmesi MotioCI Cognos ortamından yolları seçerek.
Şekil 11: Seçilen tüm Cognos nesnelerini gösterme MotioCI projesi.
Bu projedeki tüm raporların, tüm PII verilerinin görüntülenmesine ve tüm PHI'lerin karartılmasına izin vermesi beklendiğinden, herhangi bir test senaryosu eklemeden önce onaylama türümüzü doğru ayarlarla yapılandırmamız gerekecek (Şekil 12). Bu, aynı iddiada iki test seçeneğinin ayarlanması anlamına gelir. istem penceresi Daha önce Şekil 8'de gördüğümüz
Şekil 12: “Hassas Veri Uyumluluk Testi” iddiasının PII ve PHI test seçenekleri.
Artık test senaryolarımızı raporlarımıza eklemeye hazırız. Bunu yapmak için proje düğümüne sağ tıklayın (örn. Yalnızca PII'ye İzin Ver proje) içinde MotioCI Seçin ve Test Durumları Oluştur seçeneği (Şekil 13). Bu, proje içindeki tüm raporlar için çok sayıda test senaryosu oluşturmamıza izin verecek olan test senaryosu oluşturma sihirbazını başlatacaktır.
Şekil 13: MotioCI proje içinden herhangi bir seviyede gerekli tüm test senaryolarını otomatik olarak üretebilir.
The Test Senaryosu Oluştur sihirbaz ayrıca, üzerinde test yapmak istediğimiz test senaryosu için çıktı biçimlerini seçmemize de izin verecektir. Örnek ortamımız için CSV çıktısını seçtim. Sihirbaz ayrıca, her bir test senaryosunun gerçek test işi için kullanacağı iddiaları seçmemize izin verecektir. Ve bizim için bu olurdu Hassas Veri Uyumluluk Testi iddia. Aşağıda vurgulanan bu seçeneklerin her ikisini de görebilirsiniz (Şekil 14).
Şekil 14: “Test Senaryoları Oluştur” sihirbazı sırasında ortaya çıkan seçenekler.
"Tamam" ı tıkladıktan sonra, geri yönlendirileceksiniz. MotioCI Her biri tek bir test senaryosu içeren ve her biri tek bir iddiamızı içeren tüm raporlarımızı görebileceğiniz ana ekran (Şekil 15).
Şekil 15: MotioCI artık her biri bir test senaryosu ve temeldeki onaylamayı içeren tüm Cognos nesnelerini gösteren gezinme ağacı.
Son olarak, doğru Cognos kullanıcısını kullanarak üst raporlarını yürütmek için tüm test senaryolarını yapılandırmamız gerekir (örn. MotioCI). Ve bu proje için PHI içeriğinin doğru olduğundan emin olmak için test yapıyoruz. değil yalnızca PII verilerini görüntüleme izni olan kullanıcılara gösterilirse, birlikte çalışacak tüm test senaryolarını ayarlamamız gerekecek. TestKullanıcıA (bkz. tablo 2).
İlk başta bu sıkıcı bir görev gibi görünebilir, ancak şanslıyız ki kullanıcıyı proje düzeyinde ayarlayabiliriz, bu daha sonra o projedeki TÜM temel test senaryoları tarafından miras alınır. Bunu yapmak için, sol gezinme ağacında proje düğümüne ( Yalnızca PII'ye İzin Ver proje) ve ardından Proje ayarları ekranın ortasında. Ardından, altında Test yapmak bölümünde, kimlik bilgilerini değiştirme seçeneği göreceğiz (Şekil 16):
Şekil 16: Bir projede kullanıcı kimlik bilgilerinin ayarlanması, tüm test senaryolarının o kullanıcıyla Cognos'ta üst Cognos raporunu yürütmesine neden olur. Bunun üzerine her bir test senaryosu yazılabilir.
Üzerine tıkladıktan sonra Düzenle önünde bulunan düğme Tanıtım seçeneği ile karşı karşıya kalacağız. Kimlik Bilgilerini Düzenle pencere. Devam edeceğiz ve kimlik bilgilerini gireceğiz TestKullanıcıA (Şekil 17).
Şekil 17: "Kimlik Bilgilerini Düzenle" penceresi, yeni bir kullanıcı kimlik bilgileri ayarlamanıza veya sistem kimlik bilgileri olarak da bilinen Cognos örneği düzeyinde ayarlanan üst kimlik bilgilerini kullanmanıza olanak tanır.
Artık yeni kullanıcıya yansıdığını görüyoruz. Test yapmak bölümünde Proje ayarları sekmesi (Şekil 18).
Şekil 18: Yeni kullanıcı kimlik bilgileri artık projede ayarlanmıştır.
Artık hepimiz hazırız ve tüm test senaryolarımızı yürütmeye hazırız.
Bunu yapmak için, üzerine tıklayacağız Yalnızca PII'ye İzin Ver proje ve ortada bize sunulacak Test Durumları proje içinde yer alan tüm test durumlarını gösteren sekme. Hâlâ hiçbir şey yürütmediğimize göre, Durum olarak gösteriliyor Sonuçlar yok. Tüm test senaryolarını yürütmek için, yanındaki küçük oka tıklayacağız. koşmak tuşuna basın ve Tümünü Çalıştır seçeneği (Şekil 19).
Şekil 19: “Test Durumları” sekmesi, test senaryolarının tamamında veya bir kısmında toplu olarak gerçekleştirilebilecek bir dizi eylem sağlar. Burada sadece tüm test durumlarını yürütüyoruz.
MotioCI şimdi tüm test senaryolarını yürütecek ve hepsi bittiğinde sonuçları bize sunacak (Şekil 20).
Şekil 20: “Test Durumları” sekmesi, varsa çıktılar dahil olmak üzere her bir test senaryosunun yürütme durumunu görüntüler.
Gördüğünüz gibi, tüm test senaryolarımız, aşağıdakiler dışında başarılı oldu: Yatarak rapor. Öyleyse sonuçlara bir göz atalım. Bunu yapmak için, altında bulunan mavi zaman damgasını tıklayacağız. Sonuç sütunu ve Şekil 21'deki ayrıntılara bakın.
Şekil 21: “Test Vakası Sonucu” paneli, test edilen nesnenin yolu, onaylama sonuçları ve rapor tarafından üretilen tüm çıktılar dahil olmak üzere test senaryosunun yürütülmesinin ayrıntılı sonuçlarını gösterir.
Altında Onay Sonuçları bölümünde artık raporumuzun PHI uyum gerekliliklerini ihlal ettiğini görebiliyoruz. CSV rapor çıktısını şu adresten indirebiliriz: Test Durumu Çıktıları bölümüne CSV simgesine tıklayarak (Şekil 21) tıklayın.
Şekil 22: Test kullanıcısı için gizlenmiş olması gereken görüntülenen bir “Prosedür” sütununu gösteren CSV rapor çıktısı.
Raporumuzda da görebileceğiniz gibi (Şekil 22), TestUserA'nın erişmesine izin verilen PII verilerine ek olarak, raporu federal HIPAA Güvenlik Kuralını ihlal eden PHI prosedür verilerini görebiliyoruz.
İddia ayarları penceresinden hatırlarsanız, bu hata için de bir e-posta bildirimi almamız gerekiyordu. Bakalım neye benziyor (Şekil 23):
Şekil 23: Başarısız test senaryosunun iddiasıyla gönderilen ve muhtemelen rapordaki son değişiklik nedeniyle hassas veri uyumluluğunun ihlalini gösteren e-posta mesajı.
Bu noktada, PHI verilerinin gerekli bilgiler olmadan kullanıcılardan gizlendiğinden emin olmak için testleri bitirdik. İzin verPHI Cognos rol. Artık testimizi, gerekli bilgilere sahip olmayan kullanıcılardan gizlenen PII verilerini kapsayacak şekilde genişletmeye hazırız. İzin verPII Cognos rolü.
Aşama II: Yalnızca PHI Görüntüleyen Raporlar
Yeni projeyi oluşturmadan önce, şimdi tüm PII'lerin gizlenmesini ve tüm PHI'ların gösterilmesini test etmesini sağlamak için ana onaylamamızın seçeneklerini düzenleyelim (Şekil 24).
Şekil 24: TestUserB için ayarlanan “Hassas Veri Uyumluluk Testi” onayının PII ve PHI test seçenekleri.
İddiamızın tamamı yapılandırıldığında, artık yeni projeyi ve test senaryolarımızı oluşturmaya hazırız. Bunun için “Aşama I”deki adımların aynısını izleyeceğiz ve adında bir proje oluşturacağız. Yalnızca PHI'ya İzin Ver. Ayrıca, kimlik bilgilerini eklemeyi de unutmayalım. TestKullanıcıB proje kullanıcısı olarak.
Tüm yapılandırma adımlarını tamamladığımızda, Aşama I'de yaptığımız gibi tüm test senaryolarını çalıştıracağız. Örnek ortamımızda bu sefer HIPAA ihlalinde gibi görünen farklı bir raporumuz var (Şekil 25).
Şekil 25: Varsa çıktılar dahil her bir test senaryosunun yürütme durumunu gösteren “Test Durumları” sekmesi.
Test vakası sonuçlarına ilişkin daha fazla araştırma Hasta Günlük Alımı rapor, raporumuzun hasta sosyal güvenlik numaralarını istenmeyen izleyicilere gösterdiğini gösteriyor (Şekil 26).
Şekil 26: SSN PII uyumluluk gereksiniminin ihlal edildiğini gösteren test senaryosu sonucu.
CSV dosyasını indirip açmak, testimizin sonuçlarını daha da doğrulayacaktır (Şekil 27):
Şekil 27: CSV çıktısı, gizlenmesi gereken yerde ortaya çıkan hasta SSN'sini gösterir.
Bununla birlikte, Şekil 27'de görebileceğiniz gibi, raporumuz sadece baş harfini görüntüleyerek hasta soyadı sütununu (ayrıca bir PII) düzgün bir şekilde maskeliyor.
| Ödev! |
| için aynı adımları tekrarlayın. TestKullanıcıC ikisinden de yoksun olan İzin verPII ve İzin verPHI bu, raporlarımızdan herhangi birini yürütürken PII veya PHI verilerini görmemeleri gerektiği anlamına gelir. |
Bu noktada ortamımız, Cognos'un rol tabanlı veri güvenliğini kullanarak hem PHI hem de PII'ye duyarlı verilerin tam regresyon testini başarmış olmalıdır. Test senaryolarımızın her biri kendi ana raporunu yürütecek ve çıktıyı, temel iddiaları içinde ayarlanan test yapılandırmasına göre analiz edecek ve raporlardan herhangi birinin çizginin dışına çıkıp çıkmadığını bize bildirecektir.
Test ortamımız ile ortamınızda olabilecekler arasındaki en önemli farklardan biri kesinlikle boyuttur. Tipik bir Cognos ortamında büyük olasılıkla yüzlerce hatta binlerce rapor vardır ve bunların hepsini aynı anda yürütmek, bizim küçük örnek ortamımızda yaptığımız gibi, Cognos'un performansını olumsuz etkileyebilir. İle birlikte MotioCI'nin test komut dosyaları, ancak, test senaryolarınızı kapalı saatlerde daha küçük gruplar halinde çalışacak şekilde programlayabilir, böylece yoğun trafik saatlerinde Cognos ortamınızın en iyi performansını garantileyebilirsiniz.
Geliştirme sırasında iyi bir test uygulaması
Bununla birlikte, planlanan çalıştırma süreleri arasında, yine de istediğiniz kadar ayrı test senaryosunu manuel olarak çalıştırabilirsiniz. Bir rapor geliştirirken buna iyi bir örnek olabilir, değişikliklerinizin herhangi bir HIPAA ihlali oluşturmadığından emin olmak için test senaryosunu çalıştırabilirsiniz.
Cognos Test Durumlarını Otomatikleştirme
Için Geri MotioCI, navigasyon ağacında, içeriğini ortaya çıkarmak için oluşturduğumuz projelerden birini genişletiyoruz. Bu, adlı bir düğümü ortaya çıkarmalıdır. Test Komut Dosyaları. Bunu genişletmek, projenizi ilk oluşturduğunuzda otomatik olarak oluşturulmuş bir dizi test komut dosyasını gösterecektir (Şekil 28).
Şekil 28: Yönetici kullanıcı tarafından belirlenen belirli bir kriterle eşleşen sınırlı sayıda test senaryosunu görüntülemek için test komut dosyaları oluşturulabilir.
Tanım olarak, bir test komut dosyası belirli kriterlere göre bir projeye ait test senaryolarını seçen bir projenin bir bileşenidir. Test komut dosyalarını programlayabilir veya manuel olarak çalıştırabilirsiniz. Bir test komut dosyası çalıştırdığınızda, MotioCI komut dosyası kriterlerine uyan tüm test senaryolarını çalıştırır.
Bizim durumumuzda, tüm test senaryolarını bir programa göre ayarlamak istiyoruz. Yani bunu yapmak için üzerine tıklıyoruz Türkiye gezinme ağacından komut dosyasını test edin ve ardından Komut Dosyası Ayarlarını Test Et ekranın ortasında bulunan sekme (Şekil 29).
Şekil 29: “Test Komut Dosyası Ayarları” sekmesi, tüm test senaryoları için bir program eklemenize olanak tanır.
Sonra, Program Ekle seçenek. Burada artık test komut dosyamız için bir program ayarlayabiliriz. Devam edeceğim ve test vakalarımızın Pazartesi'den Cuma'ya her gün saat 3:00'te çalıştırılmasını sağlayacağım (Şekil 30).
Şekil 30: Günlük ve haftalık programa ek olarak, bir programda dakika frekansı da ayarlayabilirsiniz.
Bu kadar! Artık raporlarımızdan herhangi birinin uyumluluk dışına çıkıp çıkmadığını öğrenmek için her sabah e-posta gelen kutumuzu kontrol edebiliriz. Ayrıca, sadece üzerine tıklayarak tüm başarısız raporları görebiliriz. Değiştirildi veya Başarısız test komut dosyası ve tüm başarısız test senaryoları altında bize sunulacaktır. Test Durumları paneli (Şekil 31).
Şekil 31: En son test senaryosu toplu çalıştırmasında başarısız olan tek test senaryosunu gösteren dahil edilen “Değiştirildi veya Başarısız” test komut dosyası.
Sonuç
HIPPA, GDPR ve hassas bilgi ve mahremiyetle ilgili diğer federal düzenlemelere uyumsuzluk oldukça maliyetli olabilir, aslında ihlalde bulunan vaka başına yaklaşık 1.5 milyon dolar.
Uyumluluk testinin üstesinden gelmek için otomatik bir test stratejisi uygulayarak, bu ekstra güvenlik katmanına ve ayrıca yasalara uyduğunuza dair gönül rahatlığına sahip olacaksınız. Gizlilik verisi zorunluluklarının ötesinde, otomatikleştirilmiş testler, kuruluşunuzun yerine getirmek istediği her tür sektöre ve her türlü test gereksinimine fayda sağlayabilir.
Nasıl yardımcı olabiliriz?
Bu blog konusuyla ilgili web seminerini izlemek isterseniz, buradan erişin. altın, İletişim Cognos test sorularınızı daha fazla tartışmak için.
