Калі ваша арганізацыя рэгулярна апрацоўвае канфедэнцыйныя дадзеныя, вы павінны рэалізаваць стратэгіі захавання бяспекі дадзеных, каб абараніць не толькі асоб, якім дадзеныя належаць, але і вашу арганізацыю ад парушэння якіх -небудзь федэральных законаў (напрыклад, HIPPA, GDPR і г.д.). Гэта ўплывае на арганізацыі ў такіх галінах, як ахова здароўя, банкаўская справа, урад, юрыдычныя ... сапраўды любая арганізацыя, якая апрацоўвае канфедэнцыйныя дадзеныя.
Мы гаворым пра PII (персанальная інфармацыя) і PHI (ахоўная інфармацыя пра здароўе). Прыклады PII-
- Нумары сацыяльнага страхавання
- Банкаўскія рахункі
- Поўныя імёны
- Нумары пашпартоў і г.д.
Прыклады PHI-
- Запісы здароўя
- Вынікі лабараторыі
- Медыцынскія рахункі і таму падобнае, якія ўключаюць індывідуальныя ідэнтыфікатары
Метады абароны адчувальных дадзеных
Некаторыя кліенты апісваюць свае метады як сцэны, якія вы можаце сабе ўявіць у фільме, які вы паглядзелі ... уявіце сабе групу людзей, узброеных неабходнымі дазволамі бяспекі, якія туляцца ў зачыненым пакоі без вокнаў, каб уручную праверыць раздрукоўкі справаздач, каб пераканацца, што канфедэнцыйная інфармацыя не ўваходзіць. Нягледзячы на тое, што гэта стварае драматычную сцэну кіно, гэта не самы бяспечны і не самы эфектыўны спосаб праверкі справаздач на адчувальную інфармацыю. А з патрабаваннямі да аддаленай рабочай сілы Covid-19 на дадзены момант гэта проста немагчыма.
Мы дапамаглі некаторым нашым кліентам рэалізаваць магчымасці аўтаматызаванага тэсціравання для дынамічнага тэставання вынікаў справаздачы Cognos. Гэтая стратэгія тэсціравання ловіць справаздачы рана, як толькі яны перастаюць выконваць патрабаванні, і перш чым яны трапяць у вытворчасць, трапляюць у чужыя рукі. Заўсёды добра ведаць, дзе знаходзіцца бліжэйшы да вас аддзел сацыяльнага страхавання, напрыклад Аддзяленні сацыяльнага страхавання ў штаце Невадау выпадку найгоршага, бо каманда ў вашым мясцовым офісе будзе ведаць, як кіраваць сітуацыяй.
Значэнне ранняга тэсціравання ў цыклах развіцця
Выяўленне ўразлівых месцаў у галіне бяспекі дадзеных на ранніх этапах распрацоўкі можа дапамагчы пазбегнуць любых будучых накладзеных урадам штрафаў і санкцый. У адпаведнасці з Міністэрства аховы здароўя і сацыяльных службаў, на сённяшні дзень Бюро па грамадзянскіх правах (OCR) «урэгулявала або наклала грамадзянскі штраф у 75 выпадках, што прывяло да агульнай сумы ў даляры ў памеры 116,303,582.00 1.5 XNUMX даляры». Гэта больш за XNUMX мільёна долараў за выпадак! А згодна з Часопіс HIPAA "невыкананне агульнаарганізацыйнага аналізу рызык з'яўляецца адным з найбольш распаўсюджаных парушэнняў HIPAA, якое прыводзіць да фінансавага штрафу".
Акрамя пазбягання накладзеных урадам штрафаў, наогул важна выявіць памылкі на пачатку цыкла распрацоўкі, бо гэта той этап, калі выправіць праблемы значна прасцей і танней. У выніку асноўная мэта гэтага практыкаванні - выкарыстанне MotioCIМагчымасць рэгрэсійнага тэсціравання Расіі лёгка выявіць такія памылкі і, такім чынам, прадухіліць іх у самым пачатку цыкла распрацоўкі.
Давайце разбярэмся, як наладзіць тэставанне. Мы пачнем з налады асяроддзя Cognos, а потым растлумачым, як наладзіць аўтаматызаванае тэсціраванне дадзеных PHI і PII для нашага прыкладу. Мы таксама будзем выкарыстоўваць гэтыя ж тэставыя выпадкі ў вытворчым асяроддзі для дадатковага ўзроўню адпаведнасці і праверкі бяспекі.
Налада асяроддзя Cognos PHI і PII
Наша ўзорнае асяроддзе Cognos (малюнак 1) складаецца з некалькіх справаздач, кожны з якіх змяшчае сумесь канфедэнцыйных і асабістых дадзеных (напрыклад, код дыягназу, рэцэпт, нумар сацыяльнага страхавання, прозвішча пацыента і г.д.) і мінімальна адчувальныя дадзеныя (напрыклад, пацыент імя, дата наведвання і г.д.).
Малюнак 1: Наша ўзорнае асяроддзе Cognos.
Ёсць дзве ролі Cognos, ДазволіцьPII і Дазволіць PHI, якія вызначаюць, адлюстроўваюцца ці адчувальныя дадзеныя пры выкананні справаздач. (Табліца 1)
| Ролі Cognos | нататкі |
| ДазволіцьPII | Удзельнікі гэтай ролі могуць праглядаць усе дадзеныя PII (г.зн. нумар сацыяльнага страхавання і прозвішча пацыента) у справаздачах Cognos. |
| Дазволіць PHI | Удзельнікі гэтай ролі могуць праглядаць усе дадзеныя PHI (напрыклад, коды дыягностыкі ICD10, падрабязнае апісанне дыягназу і г.д.) у справаздачах Cognos. |
Табліца 1: Ролі Cognos, якія кантралююць перадачу канфедэнцыйных дадзеных.
Напрыклад, у карыстальніка, якому не хапае абедзвюх нашых роляў Cognos, іх справаздача "Штодзённае спажыванне пацыента" павінна выглядаць так (малюнак 2):
Малюнак 2: Вывад справаздачы ствараецца карыстальнікам, у якога адсутнічаюць ролі AllowPII і AllowPHI.
Як бачыце, усе дадзеныя PHI і PII цалкам зацямняюцца ў карыстальніка, які не мае сяброўства ў абедзвюх ролях "AllowPHI/PII".
Зараз давайце запусцім справаздачу з карыстальнікам, які ўваходзіць у ролю “AllowPII”, гэта значыць мы чакаем, што гэты карыстальнік зможа праглядаць толькі дадзеныя PII (малюнак 3):
Малюнак 3: Вывад справаздачы ствараецца карыстальнікам, які ўваходзіць у ролю AllowPII, а не ў ролю AllowPHI.
І тут вы можаце ўбачыць, што і слупкі "Код сацыяльнага страхавання" і "Прозвішча" адлюстроўваюцца належным чынам без рэдакцыі.
Да гэтага часу мы зазірнулі ў асяроддзе Cognos нашай міфічнай клінікі, і ўсё, што мы бачылі да гэтага часу,-гэта бяспека дадзеных на аснове роляў Cognos, якую многія з вас, магчыма, ужо рэалізавалі ў сваіх уласных асяроддзях Cognos. Гэта прывядзе нас да галоўнага пытання, з якім носьбіты канфедэнцыйных дадзеных спадзяюцца ніколі не сутыкацца:
Што рабіць, калі, скажам, пасля сур'ёзных намаганняў па распрацоўцы некаторыя адчувальныя дадзеныя праскокваюць і пачынаюць з'яўляцца для карыстальнікаў, якія не павінны іх бачыць?
Памылкі, безумоўна, непазбежныя, таму пазней у блогу мы будзем выкарыстоўваць MotioCIМагчымасць рэгрэсійнага тэсціравання, каб пільна сачыць за нашымі справаздачамі, каб пераканацца, што асабістыя дадзеныя ніколі не трапляюць у непажаданую аўдыторыю.
Разуменне тэставання адпаведнасці для Cognos
Як ужо згадвалася ў папярэднім раздзеле, простыя памылкі пры стварэнні або мадэляванні справаздач могуць выклікаць непажаданыя паводзіны пры вывадзе справаздач у вашым асяроддзі Cognos. І калі гэтыя змены не захапілі, яны могуць пракрасціся ў вашу вытворчую сераду. Што было б яшчэ больш катастрафічным, гэта тое, што калі гэтыя непажаданыя змены ўключаюць уздзеянне прыватных дадзеных на ненаўмысную аўдыторыю.
Напрыклад, карыстальнік, не ўваходзячы ні ў адзін, ні ў другі ДазволіцьPII or Дазволіць PHI Ролі Cognos не павінны бачыць асабістых дадзеных PII або PHI у нашым узоры асяроддзя Cognos. Аднак, як вы можаце бачыць ніжэй (малюнак 4), простае змяненне мадэлі FM выклікала такое апісанне дыягназу і нумар SSN пацыента, што з'яўляецца велізарным парушэннем федэральнага правіла бяспекі HIPAA.
Малюнак 4: Карыстальнік без членства ў ролях AllowPII і AllowPHI нейкім чынам падвяргаецца ўздзеянню адчувальных дадзеных HIPAA.
Перад тым, як перанесці рэчы ў MotioCI, мы спачатку створым трох тэставых карыстальнікаў у нашым асяроддзі Cognos і прызначым іх на дзве ролі наступным чынам (табліца 2):
| карыстальнікаў | Ролевае сяброўства | нататкі |
| TestUserA | ДазволіцьPII | Усе дадзеныя PHI павінны быць схаваныя ад гэтага карыстальніка |
| TestUserB | Дазволіць PHI | Усе дадзеныя PII павінны быць схаваныя ад гэтага карыстальніка |
| TestUserC | ні адзін | Чакаецца, што карыстальнік НЕ ўбачыць ні PHI, ні PII |
Табліца 2: Тэставанне уліковых запісаў карыстальнікаў Cognos з прызначанымі ролямі.
Гэтыя ўліковыя запісы карыстальнікаў пазней будуць выкарыстоўвацца ў MotioCI для рэгрэсійнага тэсціравання нашых справаздач, якія змяшчаюць канфедэнцыйную інфармацыю PII і PHI. Вынікі нашых тэстаў будуць залежаць ад бачнасці адчувальных дадзеных для кожнага карыстальніка ў залежнасці ад іх ролевай прыналежнасці.
Цяпер, калі мы наладзілі нашых тэставых карыстальнікаў, мы гатовыя наладзіць наша рэгрэсійнае тэставанне ў MotioCI.
MotioCI Environment Setup
Наша ўзорнае асяроддзе складаецца з асобнікаў Development, UAT і Production Cognos. Нягледзячы на тое, што MotioCI дазваляе адначасова ўваходзіць ва ўсе тры, мы пачнем наладжванне рэгрэсійнага тэсціравання ў асяроддзі распрацоўкі ў тры розныя фазы.
Малюнак 5: MotioCI Увайсці экран.
Малюнак 6: MotioCI хатні экран, які паказвае асобнікі Cognos.
Што тычыцца рэгрэсійнага тэсціравання ў MotioCI, сцвярджэнне гэта індывідуальная праверка або "тэст", які тэставы кейс выконвае на аб'екце ў вашым MotioCI напрыклад, напрыклад, справаздачу, тэчку або пакет. Выклікаецца зацвярджэнне, якое будзе выконваць працу па праверцы вынікаў справаздачы на адчувальныя дадзеныя Тэставанне на адпаведнасць адчувальным дадзеных (Малюнак 7). Гэта ўласнае сцвярджэнне, якое мы сабралі для гэтага практыкавання. Ніжэй вы можаце ўбачыць тып сцвярджэння які ў асноўным дзейнічае ў якасці асноўнага шаблону, які капіюецца для тэставання па ўсім нашым MotioCI навакольнага асяроддзя. Больш падрабязна пра гэта пазней.
Малюнак 7: Тып сцвярджэння "Тэставанне адпаведнасці адчувальным дадзеных". Копіі гэтага сцвярджэння разгортваюцца ў асяроддзі тэсціравання.
Некаторыя сцвярджэнні прадугледжваюць некаторыя функцыі, якія рэгулююцца карыстальнікам праз акно радка. Тут вы можаце змяніць, як вы хочаце, каб дадзенае сцвярджэнне правярала любы даклад Cognos. Малюнак 8 ніжэй паказвае акно радка нашага сцвярджэння, што мы будзем выкарыстоўваць для тэставання нашых справаздач Cognos, якія змяшчаюць канфедэнцыйныя дадзеныя.
Малюнак 8: Запытанае акно сцвярджэння "Тэставанне адпаведнасці адчувальным дадзеных", якое паказвае ўсе наладжвальныя карыстальнікам параметры тэсціравання.
Вылучаны зверху раздзел на малюнку 8 паказвае варыянты тэставання дадзеных, адчувальных да PII і PHI. Гэта дазваляе вам праверыць цверджанне, ці павінна справаздача паказваць або хаваць свае дадзеныя PII або PHI. Мы будзем уносіць змены ў гэтыя два варыянты, калі пачнем ствараць тэставыя прыклады для кожнага з трох нашых тэставых карыстальнікаў.
Сярэдні выдзелены раздзел на малюнку 8 паказвае назвы слупкоў, якія змяшчаюць у нашых справаздачах адчувальныя даныя PHI. Хоць наша ўзорнае асяроддзе складаецца з слупкоў з назвамі дыягнастычнага кода ICD10, апісання дыягназу, працэдуры і Rx, вы, безумоўна, можаце змяніць гэты спіс у адпаведнасці з вашымі патрэбамі.
Нарэшце, ніжні выдзелены раздзел на малюнку 8 паказвае параметры электроннай пошты. У выпадку збою гэта сцвярджэнне адправіць падрабязнае паведамленне электроннай пошты атрымальніку, настроенаму ў гэтым раздзеле.
Фаза I: справаздачы, у якіх адлюстроўваюцца толькі ідэнтыфікацыйныя дадзеныя
Давайце створым праект пад Распрацоўка асобнік у MotioCI і патэлефануйце Дазволіць толькі PII. Мы можам зрабіць гэта, пстрыкнуўшы правай кнопкай мышы на Распрацоўка вузел асобніка ў MotioCI дрэва навігацыі і выбар Дадаць праект варыянт (малюнак 9).
Малюнак 9: Стварэнне новага праекта. У MotioCI кожны праект выступае ў якасці палігона для зададзенага раздзела крамы кантэнту.
,en Дадаць майстра праекта правядзе вас праз некалькі крокаў, каб выбраць шляхі, неабходныя для вашага праекта. У нашым прыкладзе ўсе справаздачы, якія змяшчаюць канфідэнцыйныя дадзеныя PII і PHI, існуюць у фармаце Дадзеныя пацыентаў тэчку. Праверка гэтай бацькоўскай папкі аўтаматычна ўключае ўсе асноўныя справаздачы (малюнкі 10 і 11).
Малюнак 10: Вызначэнне аб'ёму праекта ў MotioCI шляхам выбару шляхоў з асяроддзя Cognos.
Малюнак 11: Паказ усіх аб'ектаў Cognos, выбраных для MotioCI праекта.
Паколькі ўсе справаздачы ў гэтым праекце, як чакаецца, дазваляюць адлюстроўваць усе дадзеныя PII і затуманьваць усе PHI, нам трэба будзе дадаць тып зацвярджэння з правільнымі наладамі перад даданнем якіх -небудзь тэставых прыкладаў (малюнак 12). Гэта азначае ўстаноўку двух варыянтаў тэсціравання на адно і тое ж сцвярджэнне акно радка што мы бачылі раней на малюнку 8.
Малюнак 12: Варыянты тэставання PII і PHI сцвярджэння "Тэставанне адпаведнасці адчувальных дадзеных".
Цяпер мы гатовыя дадаць нашы тэсты да нашых справаздач. Для гэтага пстрыкніце правай кнопкай мышы на вузле праекта (г.зн. Дазволіць толькі PII праект) у MotioCI і абярыце Стварэнне тэстаў варыянт (малюнак 13). Гэта запусціць майстар стварэння тэставых прыкладаў, які дазволіць нам стварыць вялікую колькасць тэставых выпадкаў для ўсіх справаздач у межах праекта.
Малюнак 13: MotioCI можа аўтаматычна генераваць усе неабходныя тэставыя выпадкі на любым узроўні ў межах праекта.
,en Стварыць тэст -кейс Майстар таксама дазволіць нам выбраць фарматы вываду для тэставага прыкладу, па якім мы хацелі б выканаць тэсты. Для нашага ўзору асяроддзя я выбраў вывад CSV. Майстар таксама дазволіць нам выбраць сцвярджэнні, якія будуць выкарыстоўвацца ў кожным тэставым выпадку для рэальнай задачы тэсціравання. І для нас гэта было б Тэставанне на адпаведнасць адчувальным дадзеных сцвярджэнне. Вы можаце ўбачыць абодва гэтыя варыянты, вылучаныя ніжэй (малюнак 14).
Малюнак 14: Параметры, выяўленыя падчас майстра "Стварыць тэставыя выпадкі".
Пасля націску «OK» вы вернецеся ў MotioCI галоўны экран, дзе вы зможаце ўбачыць усе нашы справаздачы, кожны з якіх змяшчае адзін тэставы выпадак, а кожны - наша адзінае сцвярджэнне (малюнак 15).
Малюнак 15: MotioCI дрэва навігацыі, якое паказвае ўсе аб'екты Cognos, кожны з якіх змяшчае тэставы выпадак і асноўнае сцвярджэнне.
Нарэшце, нам трэба наладзіць усе тэставыя выпадкі для выканання бацькоўскіх справаздач з выкарыстаннем правільнага карыстальніка Cognos (напрыклад, аднаго з трох тэставых карыстальнікаў, якіх мы наладзілі ў Cognos, перш чым наладжваць MotioCI). А паколькі для гэтага праекта мы праводзім тэставанне, каб пераканацца, што ўтрыманне PHI такое ня адлюстроўваецца карыстальнікам, якім дазволена толькі праглядаць дадзеныя PII, нам трэба будзе ўсталяваць усе тэставыя варыянты для запуску TestUserA (гл. табліцу 2).
Спачатку гэта можа здацца стомнай задачай, але нам пашанцавала, што мы можам усталяваць карыстальніка на ўзроўні праекта, які потым успадкоўваецца УСІМ асноўнымі тэстамі ў гэтым праекце. Для гэтага ў левым дрэве навігацыі мы збіраемся націснуць на вузел праекта ( Дазволіць толькі PII праект), а затым выберыце файл Налады праекта пасярэдзіне экрана. Затым, пад Тэставанне раздзел, мы ўбачым магчымасць змяніць уліковыя дадзеныя (малюнак 16):
Малюнак 16: Усталяванне ўліковых дадзеных карыстальніка ў праекце прывядзе да таго, што ўсе тэставыя выпадкі будуць выконваць бацькоўскі справаздачу Cognos у Cognos з гэтым карыстальнікам. Гэта можа быць перапісана кожным асобным тэстам.
Пасля націску на Рэдагаваць кнопка, размешчаная перад паўнамоцтвы варыянт, нам будзе прадстаўлены файл Рэдагаваць уліковыя дадзеныя акно. Мы працягнем і ўвядзем уліковыя дадзеныя для TestUserA (Малюнак 17).
Малюнак 17: Акно "Змяніць уліковыя дадзеныя" дазваляе ўсталяваць новыя ўліковыя дадзеныя карыстальніка або выкарыстоўваць бацькоўскія ўліковыя дадзеныя, устаноўленыя на ўзроўні экземпляра Cognos, таксама вядомы як сістэмныя ўліковыя дадзеныя.
Цяпер мы бачым, як новы карыстальнік адлюстроўваецца ў Тэставанне профіль Налады праекта укладку (малюнак 18).
Малюнак 18: Уліковыя дадзеныя новага карыстальніка ўсталяваны ў праекце.
Цяпер усё гатова і гатова выканаць усе тэсты.
Для гэтага мы націскаем на Дазволіць толькі PII праект, а пасярэдзіне нам будзе прадстаўлены файл Тэставыя выпадкі укладка, якая адлюстроўвае ўсе тэставыя выпадкі, размешчаныя ў межах праекта. Паколькі мы да гэтага часу нічога не выканалі, мы ўбачылі б Стан паказваючы як Вынікаў няма. Каб выканаць усе тэставыя прыклады, мы націснем на малюсенькую стрэлку прагон і абярыце Выканаць усе варыянт (малюнак 19).
Малюнак 19: Укладка "Выпрабавальныя выпадкі" змяшчае шэраг дзеянняў, якія можна было б выканаць ва ўсіх або ў частцы тэставых выпадкаў масава. Тут мы толькі выконваем усе тэсты.
MotioCI зараз выканае ўсе тэставыя прыклады і прадставіць нам вынікі, калі ўсе яны будуць выкананы (малюнак 20).
Малюнак 20: На ўкладцы «Выпрабавальныя выпадкі» адлюстроўваецца стан выканання кожнага тэставага выпадку, у тым ліку высновы, калі такія маюцца.
Як бачыце, усе нашы тэставыя прыклады ўдаліся, за выключэннем Стацыянарная справаздачу. Такім чынам, давайце паглядзім на вынікі. Для гэтага мы націскаем на сінюю пазнаку часу, размешчаную пад Вынік слупка і паглядзіце падрабязнасці на малюнку 21.
Малюнак 21: Панэль «Вынік тэставага выпадку» паказвае падрабязныя вынікі выканання тэставага прыкладу, уключаючы шлях тэставанага аб'екта, вынікі сцвярджэння і любыя вынікі, атрыманыя ў справаздачы.
пад Вынікі сцвярджэння раздзеле мы цяпер бачым, што наш даклад парушае патрабаванні адпаведнасці PHI. Мы можам загрузіць вывад справаздачы CSV з Высновы тэставага выпадку раздзел, націснуўшы на значок CSV (малюнак 21).
Малюнак 22: Вывад справаздачы CSV, які адлюстроўвае слупок «Працэдура», які павінен быў быць затуманены для тэставага карыстальніка.
Як вы можаце бачыць у нашым дакладзе (малюнак 22), у дадатак да дадзеных PII, да якіх TestUserA мае доступ, мы можам бачыць дадзеныя працэдуры PHI, якія ставяць справаздачу ў парушэнне федэральнага правіла бяспекі HIPAA.
Калі вы памятаеце з акна налад сцвярджэння, мы таксама павінны былі атрымаць паведамленне па электроннай пошце аб гэтай памылцы. Давайце паглядзім, як гэта выглядае (малюнак 23):
Малюнак 23: паведамленне электроннай пошты, адпраўленае сцвярджэннем аб няўдалым тэставанні, якое паказвае парушэнне захавання канфедэнцыйных дадзеных, верагодна, з -за нядаўніх змяненняў у справаздачы.
На гэтым этапе мы скончылі тэставанне, каб пераканацца, што дадзеныя PHI схаваныя ад карыстальнікаў без неабходнасці Дазволіць PHI Когнас ролю. Цяпер мы гатовыя пашырыць наша тэставанне на дадзеныя, якія ідэнтыфікуюць асобу, хаваючы ад карыстальнікаў, якім не патрабуецца ДазволіцьPII Когнас ролі.
Фаза II: Справаздачы, якія адлюстроўваюць толькі PHI
Перад тым, як ствараць новы праект, спачатку давайце адрэдагуем параметры нашага галоўнага зацвярджэння, каб пераканацца, што цяпер ён правярае, каб усе PII былі схаваныя, а ўсе PHI паказаны (малюнак 24).
Малюнак 24: Параметры тэставання PII і PHI сцвярджэння "Тэставанне адпаведнасці адчувальным дадзеных", якое ўсталёўваецца для TestUserB.
З нашым сцвярджэннем цяпер усё наладжана, мы гатовыя ствараць новы праект і нашы тэсты. Для гэтага мы проста зробім тыя ж крокі, што і ў «Фазе I», і створым праект пад назвай Дазволіць толькі PHI. Таксама не забудземся дадаць уліковыя дадзеныя TestUserB у якасці карыстальніка праекта.
Калі мы скончым з усімі крокамі канфігурацыі, мы выканаем усе тэсты, як мы рабілі на этапе I. У нашым узоры асяроддзя на гэты раз у нас ёсць іншы справаздачу, які, здаецца, парушае HIPAA (малюнак 25).
Малюнак 25: Укладка «Выпрабавальныя выпадкі», якая адлюстроўвае стан выканання кожнага тэставага выпадку, у тым ліку высновы, калі такія маюцца.
Далейшае расследаванне вынікаў тэставага выпадку Штодзённы прыём пацыента справаздача паказвае, што наша справаздача паказвае нумары сацыяльнага страхавання пацыентаў для ненаўмыснай аўдыторыі (малюнак 26).
Малюнак 26: Вынік тэставага прыкладу, які паказвае парушэнне патрабаванняў адпаведнасці SSN PII.
Загрузка і адкрыццё файла CSV дадаткова пацвердзяць вынікі нашага тэсту (малюнак 27):
Малюнак 27: Выснова CSV паказвае выяўлены SSN пацыента, дзе яго трэба было затуманіць.
Як вы можаце бачыць на малюнку 27, наш даклад належным чынам маскіруе слупок прозвішча пацыента (таксама PII), паказваючы толькі пачатковы.
| Дамашняя работа! |
| Паўтарыце тыя ж дзеянні для TestUserC якому не хапае абодвух ДазволіцьPII і Дазволіць PHI ролі, гэта значыць, што яны не павінны бачыць ні PII, ні PHI дадзеныя пры выкананні любога з нашых справаздач. |
Да гэтага моманту наша асяроддзе павінна было б дасягнуць поўнага рэгрэсійнага тэставання як адчувальных дадзеных PHI, так і PII, выкарыстоўваючы бяспеку дадзеных на аснове роляў Cognos. Кожны з нашых тэстаў будзе выконваць свой бацькоўскі справаздачу і аналізаваць высновы ў адпаведнасці з канфігурацыяй тэсціравання ў рамках іх асноўных сцвярджэнняў і паведаміць нам, калі які -небудзь з дакладаў выпадае з радка.
Безумоўна, адным з найбольш важных адрозненняў паміж нашым тэставым асяроддзем і тым, што вы маглі б мець у сваім асяроддзі, з'яўляецца памер. Звычайнае асяроддзе Cognos, хутчэй за ўсё, мае больш за сотні ці нават тысячы справаздач, і выкананне ўсіх іх адначасова, як мы рабілі ў нашым малюсенькім узоры, можа адбіцца на прадукцыйнасці Cognos. З MotioCIТэставыя сцэнары, аднак, вы можаце запланаваць, каб вашы тэставыя прыклады запускаліся меншымі партыямі ў непрацоўны час, што забяспечвае аптымальную прадукцыйнасць вашай асяроддзя Cognos у гадзіны з вялікай нагрузкай.
Добрая практыка тэставання падчас распрацоўкі
У прамежку паміж запланаванымі часамі выканання вы ўсё яшчэ можаце ўручную запусціць столькі асобных тэставых выпадкаў, колькі захочаце. Добрым прыкладам можа быць пры распрацоўцы справаздачы, вы можаце запусціць тэставы прыклад, каб пераканацца, што вашыя змены не прывялі да парушэнняў HIPAA.
Аўтаматызацыя тэстаў Cognos
назад да MotioCI, на дрэве навігацыі, мы пашыраем адзін з праектаў, якія мы стварылі, каб раскрыць яго змест. Гэта павінна паказаць вузел пад назвай Тэставыя сцэнары. Пры яго пашырэнні будзе паказаны набор тэставых сцэнарыяў, якія былі аўтаматычна створаны пры першым стварэнні праекта (малюнак 28).
Малюнак 28: Тэставыя сцэнары могуць быць створаны для адлюстравання толькі абмежаванай колькасці тэставых выпадкаў, якія адпавядаюць пэўным крытэрам, вызначаным карыстальнікам адміністратара.
Па вызначэнні, a тэставы сцэнар з'яўляецца кампанентам праекта, які адбірае тэставыя выпадкі, якія належаць праекту на аснове зададзеных крытэрыяў. Вы можаце запланаваць тэставыя сцэнары або запусціць іх уручную. Калі вы запускаеце тэставы сцэнар, MotioCI запускае ўсе тэставыя выпадкі, якія адпавядаюць крытэрам сцэнарыя.
У нашым выпадку мы хацелі б выставіць усе тэсты па раскладзе. Такім чынам, для гэтага мы націскаем на Усе тэставы сцэнар з дрэва навігацыі, а затым націсніце на Налады тэставага сцэнарыя у сярэдзіне экрана (малюнак 29).
Малюнак 29: Укладка "Налады сцэнарыя тэсту" дазваляе дадаць расклад для ўсіх тэставых выпадкаў.
Далей мы выбіраем Дадаць расклад варыянт. Тут мы можам усталяваць расклад для нашага тэставага сцэнара. Я буду працягваць, і нашы тэсты будуць праходзіць штодня з панядзелка па пятніцу ў 3:00 (малюнак 30).
Малюнак 30: У дадатак да штодзённага і штотыднёвага раскладу вы таксама можаце ўсталяваць хвілінную частату ў раскладзе.
Вось і ўсё! Цяпер мы можам кожную раніцу правяраць нашу паштовую скрыню, каб даведацца, ці не адпавядаюць якія -небудзь з нашых справаздач. Мы таксама можам убачыць усе няўдалыя справаздачы, проста націснуўшы на Зменена або не атрымалася тэставы сцэнар і ўсе няўдалыя тэсты будуць прадстаўлены нам у раздзеле Тэставыя выпадкі панэль (малюнак 31).
Малюнак 31: Уключаны скрыпт тэсту "Зменена або няўдала" паказвае адзіны тэст, які не атрымаўся ў апошнім пакетным запуску тэста.
заключэнне
Парушэнне патрабаванняў HIPPA, GDPR і іншых федэральных правілаў, якія тычацца канфідэнцыйнай інфармацыі і канфідэнцыяльнасці, можа каштаваць даволі дорага: каля 1.5 млн. Долараў ЗША ў выпадку выяўлення парушэння.
Укараняючы стратэгію аўтаматызаванага тэсціравання для праверкі адпаведнасці, вы атрымаеце дадатковы ўзровень бяспекі, а таксама спакой, якога вы прытрымліваецеся законаў. Акрамя мандатаў на даныя аб канфідэнцыйнасці, аўтаматызаванае тэсціраванне можа прынесці карысць усім галінам прамысловасці і любым відам патрабаванняў да тэставання, якія ваша арганізацыя хацела б прадставіць.
Як мы можам дапамагчы?
Калі вы хочаце паглядзець вебинар на гэтую тэму блога, атрымаць доступ да яго тут. Ці, звяжыцеся з намі для далейшага абмеркавання вашых пытанняў тэсціравання Cognos.
