第一篇：導診--功能點分析

導診—功能點分析

在以下的描述中，暫不考慮醫(yī)生的身份（普診、專家）變化、登陸點變化、信息去向的多樣化等因素，僅從功能點的角度來描述，以期簡單明了地說明問題；若糅合多個因素，將會導致說明復雜化，不容易說明清楚。

? 模式一：護士排隊、醫(yī)生一次呼叫

這是最簡單的應用場景： 1.掛號不直接進入候診排隊隊列

2.患者到達護士臺后，由護士操作，將患者排進候診排隊隊列 3.醫(yī)生呼叫患者，患者直接進入對應診室（診臺）就診

在這個應用場景下，需要以下幾個功能點： 1.護士端排隊程序

患者信息：由患者提供，或從HIS獲取，或從非HIS掛號表（比如我們或第三方做的掛號程序對應的表）獲取

可能操作：在一個排隊隊列中增加、修改、刪除排隊者，將一個排隊者從一個隊列轉移到另一個隊列，清空隊列，信息同步等。具體說明如下：

? 增加：在隊首、隊尾或指定位置增加一個排隊者；結果：排隊表中增加一條信息，護士端界面的某個隊列的尾部、首部或指定位置增加一條信息，信息發(fā)布屏幕上某個隊列中的相應位置增加一條信息

? 修改：修改一個排隊者的信息；結果：排隊表中對應記錄的信息被修改，護士端界面的某個隊列的顯示信息被修改（可能只是一條信息改變、也可能排隊順序改變），信息發(fā)布屏幕上某個隊列的顯示信息被修改（可能只是一條信息改變、也可能排隊順序改變）

? 刪除：刪除一個排隊者的信息；結果：排隊表中對應記錄被刪除，護士端界面一個隊列的對應節(jié)點被刪除，信息發(fā)布屏幕上一個隊列的對應節(jié)點被刪除

? 轉移：將一個排隊者從一個隊列轉移到另一個隊列；結果：排隊表中對應記錄的信息被修改（排隊隊列ID被修改，排隊位置也可能修改）；護士端界面中將排隊者從原顯示隊列中刪除，添加到目標隊列中的合適位置；信息發(fā)布屏幕上也有與護士端界面上相應的變化

? 清空：清空一個排隊隊列；結果：排隊表中一個隊列的記錄被刪除，護士端界面中一個隊列的信息被清空，信息發(fā)布屏幕上一個隊列（或一部分信息，當多個排隊隊列在一個顯示隊列中顯示時）被清空

? 同步：指的是將信息發(fā)布屏幕內容與排隊表信息同步。通知TQServer將一個顯示隊列清空，再將該顯示隊列對應的多個排隊隊列的記錄逐條發(fā)給TQServer，由TQServer轉發(fā)給播放器；需要區(qū)分是同步首次排隊信息還是二次排隊信息（要利用患者的狀態(tài)）；結果：排隊表無變化，護士端界面顯示無變化，信息發(fā)布屏幕上顯示被更新、與排隊表信息一致

? 程序重啟：護士端程序重啟之后，需要重新讀取信息；對于兩次呼叫、且需要區(qū)別顯示首次等候隊列、二次等候隊列的（實際上是一個隊列的患者的兩種狀態(tài)），需要根據(jù)患者狀態(tài)自動為兩個隊列讀取信息并在自己的屏幕上顯示

操作分析：以上每個操作對于數(shù)據(jù)庫修改的預期結果，護士端程序是知道的；每個操作完成后護士端的預期顯示結果，護士端程序也是知道的。

鐘小明：此時的操作流程是：護士端程序將信息交給TQServer，TQServer操作數(shù)據(jù)庫，完成后會通知護士端程序重新讀取排隊表所有記錄、更新界面，并通知播放器、LED控制程序、TTS控制程序等進行后續(xù)操作。我認為：

? 在這種情況下，需要考慮重新讀取排隊表所有記錄這個思路是否妥當？若數(shù)據(jù)量不大，那么問題不大（讀取效率、顯示效率都可接受）；若數(shù)據(jù)量較大（比如一個隊列100人甚至更多），那么讀取效率、顯示效率如何？ ? 既然護士端程序對結果是完全知道的，可這樣設計：TQServer只是通知護士端程序，你所希望的操作是否已完成，若完成，則護士端就更新顯示（數(shù)據(jù)是什么、怎么更新，護士端是完全知道的）

在界面中增加一個排隊者時，關于其ViewID，有以下幾個問題：

? 何時確定：是在插入數(shù)據(jù)表之前就確定了，還是在插入排隊表之后才確定？從技術上來說都可以。應該要求在插入前確定，否則不管是什么程序執(zhí)行插入操作，它無法直接獲取ViewID。

? 多點執(zhí)行：插入數(shù)據(jù)表的操作是在一個地方執(zhí)行，還是可在多個地方執(zhí)行？若允許在多個地方執(zhí)行，那么存在ViewID沖突或不連續(xù)之可能。從單點執(zhí)行的角度考慮，不能由護士端程序確定ViewID，應該由TQS確定ViewID，之后回傳給護士端程序，護士端程序只需要根據(jù)隊列ID+ViewID讀取新增信息即可，無需讀取所有信息

關于排隊，一個隊列的信息在三個地方的體現(xiàn)： ? 排隊表中的信息

? 護士端排隊界面，一個隊列的排隊人的排隊順序（即顯示順序）? 信息發(fā)布屏幕：顯示順序應與護士端顯示順序一致

一個關鍵問題：護士端的顯示順序怎么決定？顯示順序與排隊表中的哪些信息有什么關系？舉例：

? 隊列中已有兩人：兩個平診A001、A002，此時顯示順序為A001、A002 ? 來個急診，號碼是A003，按照優(yōu)先級+編號排隊，此時顯示順序為A003、A001、A002 ? 來個平診，號碼是A004，排隊隊尾。此時顯示順序為A003、A001、A002、A004 ? 來個急診，號碼是A005，按照優(yōu)先級+編號排隊，此時顯示順序為A003、A005、A001、A002、A004 ? 直到此時，播放器端采取的策略是按照優(yōu)先級+編號排序

? 急診均已被呼叫，醫(yī)生再呼叫時A001剛好不在現(xiàn)場，A002進去就診，此時隊列中只剩A004了；過一會A001來了，若護士將其仍排在平診的首位，那么此時顯示順序為A001、A004，仍然符合按照優(yōu)先級+編號排序的規(guī)則；若護士將其排在平診的隊尾，那么顯示順序為A004、A001，不符合按照優(yōu)先級+編號排序的規(guī)則

? 若所有排隊者均未被呼叫，護士強行將A004排到A002的前邊（假設醫(yī)院的規(guī)則允許這樣做），此時顯示順序為A003、A005、A001、A004、A002，也不符合按照優(yōu)先級+編號排序的規(guī)則

? 還有其它很多情況會導致顯示順序不符合按照優(yōu)先級+編號排序的規(guī)則

是否絕對不會出現(xiàn)紅色文字描述的情況？

? 不會：可采取優(yōu)先級+編號排序的規(guī)則來處理護士端界面、信息發(fā)布屏幕的顯示；若需要刷新界面，只需要在讀取排隊信息時增加用優(yōu)先級+編號的order by字句即可

? 會：此時無法依賴優(yōu)先級+編號來確定顯示順序，只能用一個順序字段來確定顯示順序，這個字段的值需要有一個良好的策略來維護。

鐘小明：信息顯示是按照優(yōu)先級+順序號排序的。

根據(jù)這個規(guī)則，從排隊表中讀取信息時，增加用優(yōu)先級+順序號的oerder by子句即可。

關于順序號字段，應注意以下事項：

? 順序號應以2的n次方做間隔，比如32, 此時順序號為32、64、96、…；因為中間插入時可簡單用上下兩個節(jié)點的順序號之和除2所得的數(shù)總是偶數(shù)，不用考慮四舍五入問題；也因為是2的n次方的原因，不管出現(xiàn)何種插入情況，順序號均有良好的規(guī)則

? 第一個順序號不能為0，否則向第一個節(jié)點前邊插入節(jié)點時就變成不可能了

? 向尾部增加一條記錄時，應讀取表中該隊列的最大順序號，將該順序號+間隔數(shù)，即為新記錄的順序號 ? 順序號每天從頭開始，不累積

? 建議間隔不要小于32；當間隔為32時，在極端情況下，可在第一個節(jié)點之前用總是將節(jié)點插入在隊列最前端的規(guī)則增加5個節(jié)點，順序號分別為16、8、4、2、1，一般不會出現(xiàn)這種極端情況

在增加節(jié)點時，順序號也有跟ViewID類似的問題：何時確定、多點執(zhí)行

2.醫(yī)生端叫號程序（或硬件叫號器）

患者信息：已在排隊表中

可能操作：順呼、選呼、復呼。具體說明如下：

? 順呼：按照規(guī)則呼叫下一位；結果：排隊表中一條信息的狀態(tài)被改變，護士端界面的某個隊列的第一條信息被刪除，信息發(fā)布屏幕上某個隊列中第一條信息（多個專家的隊列在一個隊列中顯示的，是呼叫專家的第一條信息）被刪除，叫號信息被更新（LCD、LED，規(guī)則有多種），有彈出窗口顯示呼叫信息，有TTS發(fā)呼叫語音

? 選呼：選擇呼叫排隊隊列中的某一位（硬件叫號器無此功能）；結果：排隊表中一條信息的狀態(tài)被改變，護士端界面的某個隊列的一條信息被刪除，信息發(fā)布屏幕上某個隊列中一條信息被刪除，叫號信息被更新（LCD、LED，規(guī)則有多種），有彈出窗口顯示呼叫信息，有TTS發(fā)呼叫語音

? 復呼：再次呼叫剛才被呼叫的人；結果：排隊表中信息無變化，護士端界面無變化，信息發(fā)布屏幕上某個隊列中信息無變化，叫號信息無變化，有彈出窗口顯示呼叫信息，有TTS發(fā)呼叫語音

3.TQServer 患者信息：由護士端程序或叫號程序（硬件叫號器）提供

可能操作：其操作與護士端功能、醫(yī)生端功能均有對應關系。具體說明如下： ? 增加：護士端程序提供排隊者信息，TQS將其插入到排隊表；若成功，則發(fā)消息至護士端程序，并發(fā)消息至CS

? 修改：護士端程序提供排隊者信息，TQS將更新排隊表中對應記錄；若成功，則發(fā)消息至護士端程序，并發(fā)消息至CS

? 刪除：護士端程序提供排隊者信息，TQS將從排隊表中刪除對應記錄；若成功，則發(fā)消息至護士端程序，并發(fā)消息至CS

? 轉移：護士端程序提供排隊者信息及目標隊列信息，TQS修改排隊表中對應記錄的信息；若成功，則發(fā)消息至護士端程序，并發(fā)消息至CS（兩條消息）

? 清空：護士端提供隊列ID，TQS從排隊表中刪除該隊列的所有記錄；若成功，則發(fā)消息至護士端程序，并發(fā)消息至CS

? 同步：護士端程序提供命令（是否需要制定僅同步某個播放器？），TQS發(fā)消息給CS（一條清空，若干條插入消息）

? 順呼：醫(yī)生端提供設備號，TQS根據(jù)規(guī)則檢索被呼叫者信息，修改該記錄的狀態(tài)，發(fā)信息至CS（CS轉給播放器，從排隊信息中刪除對應節(jié)點、更新叫號信息、彈出窗口提示），發(fā)消息至LED控制程序（最終更新LED屏），發(fā)消息至TTS控制程序（最終播放呼叫語音）? 選呼：醫(yī)生端提供設備號及被呼叫者信息，TQS修改排隊表中對應記錄的狀態(tài)，發(fā)信息至CS（CS轉給播放器，從排隊信息中刪除對應節(jié)點、更新叫號信息、彈出窗口提示），發(fā)消息至LED控制程序（最終更新LED屏），發(fā)消息至TTS控制程序（最終播放呼叫語音）

? 復呼：醫(yī)生端提供設備號，TQS發(fā)信息至CS（CS轉給播放器，彈出窗口提示），發(fā)消息至LED控制程序（最終更新LED屏），發(fā)消息至TTS控制程序（最終播放呼叫語音）

4.CS（通訊服務）

接收TQServer發(fā)來的消息，轉發(fā)給對應的播放器

5.目標程序（播放器程序、LED控制程序、TTS控制程序等）

播放器程序：接收CS發(fā)來的信息，根據(jù)信息類型更新顯示

LED控制程序：接收TQS發(fā)來的消息，通過LED控制器更新LED屏的顯示 TTS控制程序：接收TQS發(fā)來的消息，通過TTS盒子+音箱播放呼叫語音

6.目標設備（播放器+LCD屏、LED控制器+屏、TTS盒子+音箱等）

播放器+LCD屏：由播放器程序控制，顯示多種內容 LED控制器+屏：由LED控制器控制，顯示叫號信息 TTS盒子+音箱：由TTS控制程序控制，播放呼叫語音

模式一中的要點：排隊順序機制。

? 模式二：掛號直接排隊、醫(yī)生一次呼叫

這個應用場景與模式1稍有不同：掛號直接進入候診排隊隊列。

此時可不需要護士端的排隊增加功能，但在某些情況下還是需要的（比如關系戶來了，不在掛號大廳掛號，護士直接排隊；或者70歲以上老人免掛號）。

此時最大的不同，在于掛號時自動進入排隊隊列，數(shù)據(jù)庫無法觸發(fā)護士端程序更新排隊信息，也無法觸發(fā)TQS發(fā)消息給CS（CS轉發(fā)給播放器、更新排隊顯示）。

我們可要求掛號程序給TQS序發(fā)消息（增加排隊節(jié)點），TQS收到消息后，發(fā)消息護士端程序（讀取新增排隊者信息、更新界面中排隊信息），發(fā)消息給CS（CS轉發(fā)給播放器、更新排隊顯示）。

如果這個要求沒法滿足（HIS廠家不愿意提供），那么在這個應用場景下，我們必須設計一個機制來感知通過掛號新增的排隊者信息。

不僅要感知新增信息，還要知道新增信息在排隊隊列中的順序。

模式二中的要點：排隊順序機制、如何感知通過掛號新增的排隊信息及順序。

鐘小明：掛號掃描程序

1.本質上掛號信息不是直接進入排隊表，而是保存在接口表（接口文件）中 2.導診這邊會編寫接口程序，掃描接口表（接口文件）中的信息，將掛號信息轉交TQS處理（寫入排隊表）

3.對于已被TQS成功處理（寫入排隊表）的掛號信息，會改變接口表中的標志或從接口文件中刪除，這樣再次掃描時不會讀取已經(jīng)處理的信息

那么有幾個問題需要考慮：

1.讀取數(shù)據(jù)表：數(shù)據(jù)表需要設置大科室、排隊隊列ID之類的列，并為每個點的掃描程序定義deptid=12 or deptid=16或queueid=16 or queueid=17之類的條件

2.讀取數(shù)據(jù)文件：如何確定文件名、文件格式

? 僅一個文件：文件名確定，但可能多個掃描程序掃描一個文件，存在讀寫效率、讀寫沖突等問題

? 多個文件：按照什么模式規(guī)劃文件及命名？若按照大科室，那么對于一個點的掃描程序掃描一個或多個科室的排隊隊列比較合適，但需要定義每個點的掃描程序對應的多個文件名（直接或間接）；按照排隊隊列，那么需要為每個點的掃描程序定義多個隊列文件名（直接或間接），一旦隊列個數(shù)發(fā)生變化，就需要維護這個定義 ? 文件格式：…

3.需要考慮是否可直接呼叫的配置

? 關于預約掛號

預約掛號可采用與掛號類似的方式：編寫預約掛號掃描程序，按照一定的規(guī)則將相應掛號信息轉入排隊隊列。

? 關于患者所處的階段（狀態(tài)）

這里所說的階段，主要是患者在排隊表中的狀態(tài)；狀態(tài)的改變，涉及屏幕顯示的變化。

以掛號、首次等候、二次等候、就診（從患者角度）為例；以下的步驟實際上是從導診系統(tǒng)的操作角度來說明的。

1.掛號：信息進入掛號表。

2.掛號掃描：掛號掃描程序進行掃描，將患者信息轉入排隊表，并設置其狀態(tài)為首次等候狀態(tài)。

患者進入首次等候狀態(tài)。

需要在首次等候區(qū)的屏幕上顯示該患者信息。

3.分流呼叫：此時患者退出首次等候狀態(tài)，進入二次等候狀態(tài)

退出首次等候狀態(tài)：需要在首次等候區(qū)的屏幕上刪除該患者的排隊信息、更新叫號列表信息、彈出呼叫提示、進行語音播報（藍色部分也可算到進入二次等候狀態(tài)的動作）

進入二次等候狀態(tài)：需要在二次等候區(qū)的屏幕上顯示該患者信息

4.就診呼叫（順呼）：此時上一位患者退出就診狀態(tài)，進入完成狀態(tài)；下一位患者退出二次等候狀態(tài)，進入就診狀態(tài) 退出就診狀態(tài)：患者信息從屏幕的就診去消失

退出二次等候狀態(tài)：需要在二次等候區(qū)的屏幕上刪除該患者的排隊信息、彈出呼叫提示、進行語音播報（藍色部分也可算到進入就診狀態(tài)的動作）進入就診狀態(tài)：顯示就診信息

從上述說明中可看出，從系統(tǒng)角度的一個事件的觸發(fā)，可能涉及對于患者的一個狀態(tài)的退出，另一狀態(tài)的進入。或者我們可以把一個狀態(tài)的退出、另一個狀態(tài)的進入看做是狀態(tài)的變更。

從程序設計的角度，我們可考慮兩種方式：

1.設計每個狀態(tài)的進入功能、退出功能，這些功能被合理的觸發(fā)

優(yōu)點：從狀態(tài)的角度看，很清晰；當狀態(tài)個數(shù)、狀態(tài)間的邏輯關系不可預知時，程序組織比較方便 缺點：編程難度大？

2.從操作事件角度出發(fā)，設計操作事件所涉及的所有功能

優(yōu)點：當狀態(tài)個數(shù)、狀態(tài)間的邏輯關系都已知時，可減少編程難度？ 缺點：若狀態(tài)個數(shù)、不可預知時，程序的重組很費勁

就目前的情況看來，即使考慮到分診模式（一次分診/二次分診）、是否允許直接呼叫、一次呼叫/兩次呼叫等模式，患者在各種模式下的狀態(tài)個數(shù)及順序是可知的，因此可采用第二種處理方式。

不過若第一種方式從程序角度來說并不難的話，應采用第一種方式。

不管如何，暫且為患者設置幾種狀態(tài)： 1.排隊（未指定隊列）

2.等候分流呼叫（排隊、已指定隊列、可直接呼叫）3.等候就診呼叫（排隊、已指定隊列、可直接呼叫）4.就診 5.結束

排隊、已指定隊列、不能直接呼叫

這個狀態(tài)不怎么需要

是用一個字段表示狀態(tài)，還是用多個字段組合表示狀態(tài)？需要仔細琢磨。

? 功能分布圖一：每個科室有獨立的掛號掃描程序、TQS

醫(yī)生端使用軟件時，會有直接讀寫數(shù)據(jù)庫的功能。

建議使用這種配置，其優(yōu)點是：

1.各科室掛號掃描程序、TQS獨立運行，一個科室程序故障不會影響其它科室的正常運行；對于業(yè)務較少的多個科室，可集中使用一套（掛號掃描程序、TQS、護士臺程序）；不建議一個科室使用兩套（此時可從邏輯上設計兩個科室）

2.每個掛號掃描程序、TQS工作量相對較小，不易導致響應延時 3.每個TQS處理不同的隊列，隊列的ViewID、順序號應不會沖突

在這種配置下，必須注意的事項如下： 1.每個掛號掃描程序必須設置屬性： ? 數(shù)據(jù)權限：讀取哪些隊列（或用其它方式）的掛號記錄 ? 目標TQS：讀取記錄后，發(fā)送給哪個TQS 2.每個TQS也必須設置屬性：

? 數(shù)據(jù)權限：讀寫哪些隊列（或用其它方式）的排隊記錄，與對應的掛號掃描程序類似

? 信息目標：包括護士端程序、CS、LED控制程序、TTS控制程序等；若TQS是被其它程序連接，只需要為其它程序設置好自己對應的TQS即可

3.護士端程序：

? 數(shù)據(jù)權限：讀寫哪些隊列（或用其它方式）的排隊記錄，與對應的TQS程序類似

? TQS：設置對應的TQS 4.醫(yī)生端程序：設置對應的TQS

? 功能分布圖二：整個醫(yī)院只有一個掛號掃描程序、一個TQS

醫(yī)生端使用軟件時，會有直接讀寫數(shù)據(jù)庫的功能。

不建議使用這種配置，缺點很多：

1.掛號掃描程序、TQS只有一套，一旦出現(xiàn)故障，所有科室的業(yè)務均無法正常運行

2.掛號掃描程序、TQS負擔較大，易導致響應延時

3.TQS邏輯復雜：必須能區(qū)分每個科室對應的隊列，能將不同科室的信息發(fā)送到對應科室的護士臺、CS、LED控制程序、TTS控制程序

第二篇：APP測試功能點總結

APP測試功能點總結

1.功能性測試：

——根據(jù)產(chǎn)品需求文檔編寫測試用例。

——軟件設計文檔編寫用例。

注意：就是根據(jù)產(chǎn)品需求文檔編寫測試用例而進行測試。

2.兼容性測試:

——android版本的兼容性

——手機分辨率兼容性

——網(wǎng)絡的兼容性：2G3G4GWIFI,弱網(wǎng)下、斷網(wǎng)時

——app跨版本的兼容性

1.適配性測試：

1>.手機不同分辨率支持：客戶端支持的分辨率等

2>.手機不同版本的支持：2.34.04.4等；在測試計劃中：需要安排單獨的時間用于android不同系統(tǒng)的兼容性測試，包括2.0以下版本和4.0以上等

3>.手機不同廠家系統(tǒng)的支持：不同廠家會有不同android系統(tǒng)，例如：小米，華為，錘子對市面上主流手機的支持

4>.手機不同尺寸的支持：3.5到5.0屏幕在UI顯示有區(qū)別，要支持最大到最小。

2.安裝、卸載測試：

1>.生成apk文件在真機上可以安裝及卸載；

2>.Android手機端通用安裝工具。如：豌豆莢

3.在線升級測試：

1>.驗證數(shù)字簽名

2>.升級后可以正常使用。

3>.在線跨版本升級。

3.性能測試：

——壓力測試：

——電量流量測試：

——cup、內存消耗：

——app啟動時長

——crash率

——內存泄漏

4.網(wǎng)絡測試：

1.外網(wǎng)測試主要現(xiàn)實模擬客戶使用網(wǎng)絡環(huán)境，檢驗客戶單程序在實際網(wǎng)若環(huán)境中使用情況及進行業(yè)務操作。

2.外網(wǎng)測試主要覆蓋到wifi2G3G4G,.netwap、電信移動聯(lián)通、所有可能的組合進行測試。

原則：

1.盡可能全面覆蓋用戶的使用場景，測試用例中需要包含不同網(wǎng)絡排列組合的各種可能。

2.還有模擬信號被屏蔽時候?？蛻舳说挠绊懙取＿€有做外包場景測試，在高山、丘陵、火車上等特殊環(huán)境下進行全面測試

5.接口性測試：

——client端和service端的交互

——client端的數(shù)據(jù)更新和service端的數(shù)據(jù)是否一致

——client端更新時斷開了。

——client端更新時service端掛了。

6.業(yè)務邏輯測試：

1.業(yè)務邏輯測試：主要測試客戶端業(yè)務能否正常完成。

2.功能點測試：主要測試客戶端功能點是否正常使用

3.關聯(lián)性測試：主要測試客戶端與pc端的交互，客戶端處理完后，pc端與客戶端數(shù)據(jù)一致

7.異常測試：

1.交互異常性測試：客戶端作為手機特性測試，包括被打擾的情況；如來電、來短信、低電量測試等，還要注意手機端硬件上，如：待機，插拔數(shù)據(jù)線、耳機等操作不會影響客戶端。

2.異常性測試：主要包含了斷網(wǎng)、斷電、服務器異常等情況下，客戶端能否正常處理，保證數(shù)據(jù)正確性。

客戶端側性能測試：

1.基準性能測試：主要通過壓服務器端接口及客戶端在不同網(wǎng)絡環(huán)境下響應速度。

2.大數(shù)量的測試：主要在特定環(huán)境下，客戶端一次性更新大量的數(shù)據(jù)及人員列表時，客戶端能否正常處理，分為三種情況：

——客戶端第一次使用，第一次就更新大量數(shù)據(jù)及人員列表。

——客戶端在平時更新中，更新大量的數(shù)據(jù)

——客戶端已經(jīng)在手機本地下載很多數(shù)據(jù)后，再次更新大量

如果想要在測試方面獲得進一步的提升，那么你就需要學會使用App測試工具。一方面，通過測試工具可以代替你做重復繁瑣的部分工作，你節(jié)省出的是更多的學習時間，另一方面，這些工具還會為你提供大量的游戲運行數(shù)據(jù)和日志，有了這些數(shù)據(jù)你就能更方便的判斷問題發(fā)生的原因，這寫數(shù)據(jù)的解讀能力將是你未來的最大競爭力。

第三篇：導診便民措施

鎮(zhèn)平縣人民醫(yī)院

導診就醫(yī)臺便民服務措施

1、免費輪椅服務。

2、免費測血壓、測體溫。

3、為老、弱、殘及危重患者提供全程導醫(yī)服務。

4、免費小件物品寄存。

5、健康指導服務，免費發(fā)放健康教育處方。

6、失物招領，并負責電話聯(lián)系。

7、提供針線包、老花鏡、筆、紙。

8、免費為患者提供咨詢，幫助患者選擇醫(yī)生。

9、免費提供開水。

第四篇：導診工作制度

導診工作制度

1、面帶微笑，規(guī)范站姿，熱情禮貌，耐心回答患者詢問，正確引患者各科就診。

2、隨時觀察門診大廳及門口的人流動態(tài)，主動攙扶年老體弱的患者，為行動不便的患者提供輪椅、協(xié)助掛號、必要時協(xié)助就診、取藥、檢查等。

3、勤動口勤動手，維持大廳門診的良好秩序。

4、導醫(yī)每日提前10分鐘到崗，統(tǒng)一著導醫(yī)服裝，保持衣帽整齊，佩帶胸卡。

5、病人進入大廳后：一張笑臉，一聲問候，一份熱情，引導病人掛號。

6、掛號分診：站立式服務，詢問病人掛號情況，做好初、復診病人的登記工作，患者無特殊要求，根據(jù)病情按科室及相關規(guī)定分診。

7、流動班：走動式服務，負責將病人帶到醫(yī)生診室，詢問病情介紹醫(yī)生特長，協(xié)助病人交費，輔助病人做檢查，取藥，等全程優(yōu)質服務。

8、遵守醫(yī)院規(guī)章制度，按時上下班，不遲到，不早退。

9、導醫(yī)的：“九不準”

不準吃零食、干私事。

不準閑聊、打鬧、高聲喧嘩。

不準看書、看報、看電視、玩手機、玩游戲。

不準約會私人客人。

不準對病人不理不睬。

不準索取病人取禮物。

不準與病人頂撞吵架。

不準擅自離崗串崗。

不準遲到早退。

10、分診導醫(yī)每日負責所轄區(qū)域內一切物品的清潔衛(wèi)生

11、對危重搶救患者及特殊情況病員，導醫(yī)盡快送到相關科室就診，協(xié)助醫(yī)生護士做好搶救工作，對行走不方便病人上前攙扶。

12、科室要有團隊精神，團結之心，相互幫助每日必需完成自己的工作，交接班要清楚?？剖曳峙淙蝿詹坏猛妻o，服從領導安排。

科左中旗人民醫(yī)院護理部

第五篇：導診工作制度

導醫(yī)工作職責

1、面帶微笑，規(guī)范站姿，熱情禮貌，耐心回答患者詢問，正確引患者各科就診。

2、隨時觀察門診大廳及門口的人流動態(tài)，主動攙扶年老體弱的患者，為行動不便的患者提供輪椅、協(xié)助掛號、必要時協(xié)助就診、取藥、檢查等。

3、勤動口勤動手，維持大廳門診的良好秩序。

4、導醫(yī)每日7：20到崗，統(tǒng)一著導醫(yī)服裝，保持衣帽整齊，佩帶胸卡。

5、病人進入大廳后：一張笑臉，一聲問候，一份熱情，引導病人掛號。

6、掛號分診：站立式服務，詢問病人掛號情況，做好初、復診病人的登記憶工作，患者無特殊要求，根據(jù)病情按科室及相關規(guī)定分診。

7、流動班：走動式服務，負責將病人帶到醫(yī)生診室，詢問病情介紹醫(yī)生特長，協(xié)助病人交費，輔助病人做檢查，取藥，等全程優(yōu)質服務。

8、遵守醫(yī)院規(guī)章制度，按時上下班，不遲到，不早退。

9、導醫(yī)的：“十不準” 不準吃零食、干私事； 不準閑聊、打鬧、高聲喧嘩；

不準看書、看報、看電視、玩手機、玩游戲。不準約會私人客人； 不準對病人不理不睬； 不準索取病人取禮物； 不準與病人頂撞吵架； 不準擅自離崗串崗； 不準遲到早退；

10、分診導醫(yī)每日負責所轄區(qū)域內一切物品的清潔衛(wèi)生

11、對危重搶救患者及特殊情況病員，導醫(yī)盡快送到相關科室就診，協(xié)助醫(yī)生護士做好搶救工作，對行走不方便病人上前攙扶。

12、科室要有團隊精神，團結之心，相互幫助每日必需完成自己的工作，交接班要清楚。科室分配任務不得推辭，服從領導安排。