第一篇：考勤系統(tǒng)月測試報(bào)告

XX月電子考勤系統(tǒng)月報(bào)表測試報(bào)告

一、系統(tǒng)部分

1、月報(bào)表中顯示有公差的人員，月報(bào)表中的出勤天數(shù)和計(jì)薪天數(shù)都有減出，應(yīng)該不用減。例0108XXXX、940304XXXX在XX月份月考勤。(ok)

2、在職人員和離職人員例0108XXXX、940304XXXX；計(jì)薪天數(shù)比實(shí)際的出勤天數(shù)少一天。(原因：XX月9日和12調(diào)休，當(dāng)時(shí)的在系統(tǒng)中的處理為12日停工、9日正常上班，計(jì)算出的計(jì)薪天數(shù)有減出12日的，應(yīng)處理成調(diào)休)

3、0108XXXX、940304XXXX在11月份的月報(bào)表中缺勤時(shí)間(請假和曠工)的累加的不正確導(dǎo)致計(jì)薪天數(shù)不正確(實(shí)際計(jì)薪天數(shù)=21.75-月累計(jì)的缺勤時(shí)間)

4、XXX組夜班人員的加班時(shí)間計(jì)算。

二、數(shù)據(jù)部分：

1、出勤天數(shù)正確，員工實(shí)際出勤數(shù)與計(jì)算出的出勤天數(shù)一致。

2、計(jì)薪天數(shù)：計(jì)薪天數(shù)應(yīng)受到缺勤天數(shù)(請假、曠工、停工等)的影響，計(jì)薪天數(shù)數(shù)據(jù)與實(shí)際不一致。

3、晚加班時(shí)間：

計(jì)時(shí)部分：

A、XX課：申報(bào)的晚加班時(shí)間=以刷卡計(jì)算出的加班時(shí)間(大部分人)，少數(shù)不一致的相差在0.5或1批準(zhǔn)：審核：編制：王小二 小時(shí)。

B、XX課：申報(bào)晚加班時(shí)間與以刷卡計(jì)算出的加班時(shí)間相差在0.5-2小時(shí)之間。大部分人申報(bào)時(shí)間>刷卡計(jì)算出的加班時(shí)間。

C、XX課后勤：申報(bào)晚加班時(shí)與以刷卡計(jì)算出的加班時(shí)間相差在0.5-4小時(shí)之間。兩者交錯相差。D、XX后勤：面后勤與刷卡計(jì)算出的加班時(shí)間相差少0.5-2小時(shí)之間，底部后勤相差在0.5-5之間多數(shù)為申報(bào)時(shí)間多。

計(jì)件部份： a、b、XX組：申報(bào)晚加班小于以刷卡計(jì)算出的加班時(shí)間，在1.5-3之間。

XX課：上白班人員工時(shí)相差在0.5-1.5之間，多數(shù)為以刷卡時(shí)間計(jì)算的晚加班比申報(bào)時(shí)間多。

上夜班人員工時(shí)相差在12-30小時(shí)之間，申報(bào)時(shí)間比晚加班時(shí)間多。

C、XX組：上白班人員數(shù)據(jù)ok，上夜班人員工時(shí)相差3-4小時(shí)，------此問題系統(tǒng)存在一部分。D、XX課：以刷卡時(shí)間計(jì)算出的加班時(shí)間差異很大，與申報(bào)時(shí)間相差在4-30小時(shí)之間不等。申報(bào)時(shí)間大于以刷卡時(shí)間計(jì)算出的加班時(shí)間。

E、XX組：兩者相差0.5-1小時(shí)，申報(bào)時(shí)間>刷卡計(jì)算的晚加班時(shí)間。F、XX組：兩者相差在0.5-3小時(shí)，申報(bào)時(shí)間>刷卡計(jì)算的晚加班時(shí)間。

G、XX部、XX部生產(chǎn)線大部分線是申報(bào)時(shí)間<刷卡計(jì)算的晚加班時(shí)間。(相差在0.5-1之間,)

三、數(shù)據(jù)出現(xiàn)差異的原因：

批準(zhǔn)：審核：編制：王小二

1、工號開頭為0301XX的人員在月初無廠卡，晚加班時(shí)間未用刷卡時(shí)間計(jì)算。

備注：針對此種情況即：不能刷卡計(jì)算晚加班時(shí)，用設(shè)置的”晚加班時(shí)間登記表”作登記(見附頁)，人事再作系統(tǒng)的手工考勤。2、3、4、5、累計(jì)8小時(shí)后計(jì)加班時(shí)間。晚加班下班后半小時(shí)有效刷卡時(shí)間。XX組定產(chǎn)量下班

XX組夜班下班提前且半小時(shí)內(nèi)刷卡規(guī)則。

總結(jié)：

1、上夜班人員的加班時(shí)間和月中調(diào)動人員的月考勤計(jì)算存在問題，其余人員的考勤日報(bào)表和晚加班小時(shí)可正確算出。

2、系統(tǒng)在算月考勤報(bào)表(白天等各種出勤情況)時(shí)部分結(jié)構(gòu)和數(shù)據(jù)還有待調(diào)整。

批準(zhǔn)：審核：編制：王小二

第二篇：戶籍管理系統(tǒng)測試報(bào)告

戶籍管理系統(tǒng)測試報(bào)告

2010年12月29日星期三

一、測試概述：

1、測試目的：

本測試報(bào)告是簡單戶籍管理系統(tǒng)的測試報(bào)告，目的在于分析測試結(jié)果，描述系統(tǒng)是否有戶籍管理的功能。

2、測試內(nèi)容：

利用白盒測試黑盒測試相結(jié)合的方式

測試平臺：Windows XP操作系統(tǒng)。

測試工具：Microsoft Visual Basic中文版。

二、測試分析：

1、系統(tǒng)概述：

系統(tǒng)包括查詢管理、戶管理、個(gè)人戶口管理三大部分。實(shí)現(xiàn)的基本功能有：

(1)實(shí)現(xiàn)戶籍的查詢，可分為普通用戶查詢和內(nèi)部管理員的查詢，普通用戶只能 查詢基本信息和修改密碼，如身份證號、出生日期等。

(2)實(shí)現(xiàn)戶籍的修改，包括戶口的修改以及個(gè)人信息的修改。

(3)實(shí)現(xiàn)個(gè)人戶口管理，包括個(gè)人戶口的新建和遷入遷出。

(4)關(guān)于管理，包括個(gè)人戶口注銷和戶口注銷等，同時(shí)需注明注銷原因、證明材 料等。

系統(tǒng)主要流程圖：

2、主要功能測試：

三、總結(jié)

所用的測試用例基本能夠檢測到所有非法輸入，但對于家庭住址等字段，無法檢測其語義的有效性。檢測結(jié)果表示，此軟件能夠進(jìn)行簡單的戶籍管理操作。

第三篇：系統(tǒng)測試報(bào)告范例

系統(tǒng)測試報(bào)告編寫規(guī)范

摘要

測試報(bào)告是把測試的過程和結(jié)果寫成文檔，并對發(fā)現(xiàn)的問題和缺陷進(jìn)行分析，為糾正軟件的存在的質(zhì)量問題提供依據(jù)，同時(shí)為軟件驗(yàn)收和交付打下基礎(chǔ)。本文提供測試報(bào)告模板以及如何編寫的實(shí)例指南。關(guān)鍵字

測試報(bào)告 缺陷

正文

測試報(bào)告是測試階段最后的文檔產(chǎn)出物，優(yōu)秀的測試經(jīng)理應(yīng)該具備良好的文檔編寫能力，一份詳細(xì)的測試報(bào)告包含足夠的信息，包括產(chǎn)品質(zhì)量和測試過程的評價(jià)，測試報(bào)告基于測試中的數(shù)據(jù)采集以及對最終的測試結(jié)果分析。

下面以通用的測試報(bào)告模板為例，詳細(xì)展開對測試報(bào)告編寫的具體描述。

PARTⅠ 首頁

0.1頁面內(nèi)容：

密級

通常，測試報(bào)告供內(nèi)部測試完畢后使用，因此密級為中，如果可供用戶和更多的人閱讀，密級為低，高密級的測試報(bào)告適合內(nèi)部研發(fā)項(xiàng)目以及涉及保密行業(yè)和技術(shù)版權(quán)的項(xiàng)目。

XXXX項(xiàng)目/系統(tǒng)測試報(bào)告

報(bào)告編號

可供索引的內(nèi)部編號或者用戶要求分布提交時(shí)的序列號

部門經(jīng)理 ______項(xiàng)目經(jīng)理______

開發(fā)經(jīng)理______測試經(jīng)理______

XXX公司 XXXX單位（此處包含用戶單位以及研發(fā)此系統(tǒng)的公司）

XXXX年XX月XX日

0.2格式要求：

標(biāo)題一般采用大體字（如一號），加粗，宋體，居中排列

副標(biāo)題采用大體小一號字（如二號）加粗，宋體，居中排列

其他采用四號字，宋體，居中排列

0.3版本控制：

版本 作者 時(shí)間 變更摘要

新建/變更/審核

PARTⅡ 引言部分

1.1編寫目的本測試報(bào)告的具體編寫目的，指出預(yù)期的讀者范圍。

實(shí)例：本測試報(bào)告為XXX項(xiàng)目的測試報(bào)告，目的在于總結(jié)測試階段的測試以及分析測試結(jié)果，描述系統(tǒng)是否符合需求（或達(dá)到XXX功能目標(biāo)）。預(yù)期參考人員包括用戶、測試人員、、開發(fā)人員、項(xiàng)目管理者、其他質(zhì)量管理人員和需要閱讀本報(bào)告的高層經(jīng)理。

提示：通常，用戶對測試結(jié)論部分感興趣，開發(fā)人員希望從缺陷結(jié)果以及分析得到產(chǎn)品開發(fā)質(zhì)量的信息，項(xiàng)目管理者對測試執(zhí)行中成本、資源和時(shí)間予與重視，而高層經(jīng)理希望能夠閱讀到簡單的圖表并且能夠與其他項(xiàng)目進(jìn)行同向比較。此部分可以具體描述為什么類型的人可參考本報(bào)告XXX頁XXX章節(jié)，你的報(bào)告

讀者越多，你的工作越容易被人重視，前提是必須讓閱讀者感到你的報(bào)告是有價(jià)值而且值得浪費(fèi)一點(diǎn)時(shí)間去關(guān)注的。

1.2項(xiàng)目背景

對項(xiàng)目目標(biāo)和目的進(jìn)行簡要說明。必要時(shí)包括簡史，這部分不需要腦力勞動，直接從需求或者招標(biāo)文件中拷貝即可。

1.3系統(tǒng)簡介

如果設(shè)計(jì)說明書有此部分，照抄。注意必要的框架圖和網(wǎng)絡(luò)拓?fù)鋱D能吸引眼球。

1.4術(shù)語和縮寫詞

列出設(shè)計(jì)本系統(tǒng)/項(xiàng)目的專用術(shù)語和縮寫語約定。對于技術(shù)相關(guān)的名詞和與多義詞一定要注明清楚，以便閱讀時(shí)不會產(chǎn)生歧義。

1.5參考資料

1．需求、設(shè)計(jì)、測試用例、手冊以及其他項(xiàng)目文檔都是范圍內(nèi)可參考的東東。

2．測試使用的國家標(biāo)準(zhǔn)、行業(yè)指標(biāo)、公司規(guī)范和質(zhì)量手冊等等

PARTⅢ 測試概要

測試的概要介紹，包括測試的一些聲明、測試范圍、測試目的等等，主要是測試情況簡介。（其他測試經(jīng)理和質(zhì)量人員關(guān)注部分）

2.1測試用例設(shè)計(jì)

簡要介紹測試用例的設(shè)計(jì)方法。例如：等價(jià)類劃分、邊界值、因果圖，以及用這類方法(3-4句)。提示：如果能夠具體對設(shè)計(jì)進(jìn)行說明，在其他開發(fā)人員、測試經(jīng)理閱讀的時(shí)候就容易對你的用例設(shè)計(jì)有個(gè)整體的概念，順便說一句，在這里寫上一些非常規(guī)的設(shè)計(jì)方法也是有利的，至少在沒有看到測試結(jié)論之前就可以了解到測試經(jīng)理的設(shè)計(jì)技術(shù)，重點(diǎn)測試部分一定要保證有兩種以上不同的用例設(shè)計(jì)方法。

2.2測試環(huán)境與配置

簡要介紹測試環(huán)境及其配置。

提示：清單如下，如果系統(tǒng)/項(xiàng)目比較大，則用表格方式列出

數(shù)據(jù)庫服務(wù)器配置

CPU：

內(nèi)存：

硬盤：可用空間大小

操作系統(tǒng)：

應(yīng)用軟件：

機(jī)器網(wǎng)絡(luò)名：

局域網(wǎng)地址：

應(yīng)用服務(wù)器配置

…….客戶端配置

…….對于網(wǎng)絡(luò)設(shè)備和要求也可以使用相應(yīng)的表格，對于三層架構(gòu)的，可以根據(jù)網(wǎng)絡(luò)拓?fù)鋱D列出相關(guān)配置。

2.3測試方法(和工具)

簡要介紹測試中采用的方法(和工具)。

提示：主要是黑盒測試，測試方法可以寫上測試的重點(diǎn)和采用的測試模式，這樣可以一目了然的知道是否

遺漏了重要的測試點(diǎn)和關(guān)鍵塊。工具為可選項(xiàng)，當(dāng)使用到測試工具和相關(guān)工具時(shí)，要說明。注意要注明是自產(chǎn)還是廠商，版本號多少，在測試報(bào)告發(fā)布后要避免大多工具的版權(quán)問題。

PARTⅣ 測試結(jié)果及缺陷分析

整個(gè)測試報(bào)告中這是最激動人心的部分，這部分主要匯總各種數(shù)據(jù)并進(jìn)行度量，度量包括對測試過程的度量和能力評估、對軟件產(chǎn)品的質(zhì)量度量和產(chǎn)品評估。對于不需要過程度量或者相對較小的項(xiàng)目，例如用于驗(yàn)收時(shí)提交用戶的測試報(bào)告、小型項(xiàng)目的測試報(bào)告，可省略過程方面的度量部分；而采用了CMM/ISO或者其他工程標(biāo)準(zhǔn)過程的，需要提供過程改進(jìn)建議和參考的測試報(bào)告－主要用于公司內(nèi)部測試改進(jìn)和缺陷預(yù)防機(jī)制－則過程度量需要列出。

3.1測試執(zhí)行情況與記錄

描述測試資源消耗情況，記錄實(shí)際數(shù)據(jù)。（測試、項(xiàng)目經(jīng)理關(guān)注部分）

3.1.1測試組織

可列出簡單的測試組架構(gòu)圖，包括：

測試組架構(gòu)（如存在分組、用戶參與等情況）

測試經(jīng)理（領(lǐng)導(dǎo)人員）

主要測試人員

參與測試人員

3.1.2測試時(shí)間

列出測試的跨度和工作量，最好區(qū)分測試文檔和活動的時(shí)間。數(shù)據(jù)可供過程度量使用。

例如 XXX子系統(tǒng)/子功能

實(shí)際開始時(shí)間－實(shí)際結(jié)束時(shí)間

總工時(shí)/總工作日

任務(wù) 開始時(shí)間 結(jié)束時(shí)間 總計(jì)

合計(jì)

對于大系統(tǒng)/項(xiàng)目來說最終要統(tǒng)計(jì)資源的總投入，必要時(shí)要增加成本一欄，以便管理者清楚的知道究竟花費(fèi)了多少人力去完成測試。

測試類型 人員成本 工具設(shè)備 其他費(fèi)用

總計(jì)

在數(shù)據(jù)匯總時(shí)可以統(tǒng)計(jì)個(gè)人的平均投入時(shí)間和總體時(shí)間、整體投入平均時(shí)間和總體時(shí)間，還可以算出每一個(gè)功能點(diǎn)所花費(fèi)的時(shí)/人。

用時(shí)人員 編寫用例 執(zhí)行測試 總計(jì)

合計(jì)

這部分用于過程度量的數(shù)據(jù)包括文檔生產(chǎn)率和測試執(zhí)行率。

生產(chǎn)率人員 用例/編寫時(shí)間 用例/執(zhí)行時(shí)間平均

合計(jì)

3.1.3測試版本

給出測試的版本，如果是最終報(bào)告，可能要報(bào)告測試次數(shù)回歸測試多少次。列出表格清單則便于知道那個(gè)子系統(tǒng)/子模塊的測試頻度，對于多次回歸的子系統(tǒng)/子模塊將引起開發(fā)者關(guān)注。

3.2覆蓋分析

3.2.1需求覆蓋

需求覆蓋率是指經(jīng)過測試的需求/功能和需求規(guī)格說明書中所有需求/功能的比值，通常情況下要達(dá)到

100％的目標(biāo)。

需求/功能（或編號）測試類型 是否通過 備注

[Y][P][N][N/A]

根據(jù)測試結(jié)果，按編號給出每一測試需求的通過與否結(jié)論。P表示部分通過，N/A表示不可測試或者用例不適用。實(shí)際上，需求跟蹤矩陣列出了一一對應(yīng)的用例情況以避免遺漏，此表作用為傳達(dá)需求的測試信息以供檢查和審核。

需求覆蓋率計(jì)算 Y項(xiàng)/需求總數(shù) ×100％

3.2.2測試覆蓋

需求/功能（或編號）用例個(gè)數(shù) 執(zhí)行總數(shù) 未執(zhí)行 未/漏測分析和原因

實(shí)際上，測試用例已經(jīng)記載了預(yù)期結(jié)果數(shù)據(jù)，測試缺陷上說明了實(shí)測結(jié)果數(shù)據(jù)和與預(yù)期結(jié)果數(shù)據(jù)的偏差；因此沒有必要對每個(gè)編號在此包含更詳細(xì)的說明的缺陷記錄與偏差，列表的目的僅在于更好的查看測試結(jié)果。

測試覆蓋率計(jì)算 執(zhí)行數(shù)/用例總數(shù) ×100％

3.2缺陷的統(tǒng)計(jì)與分析

缺陷統(tǒng)計(jì)主要涉及到被測系統(tǒng)的質(zhì)量，因此，這部分成為開發(fā)人員、質(zhì)量人員重點(diǎn)關(guān)注的部分。

3.3.1缺陷匯總

被測系統(tǒng) 系統(tǒng)測試 回歸測試 總計(jì)

合計(jì)

按嚴(yán)重程度

嚴(yán)重 一般 微小

按缺陷類型

用戶界面 一致性 功能 算法 接口 文檔 用戶界面 其他

按功能分布

功能一 功能二 功能三 功能四 功能五 功能六 功能七

最好給出缺陷的餅狀圖和柱狀圖以便直觀查看。俗話說一圖勝千言，圖標(biāo)能夠使閱讀者迅速獲得信息，尤其是各層面管理人員沒有時(shí)間去逐項(xiàng)閱讀文章。

圖例

3.3.2缺陷分析

本部分對上述缺陷和其他收集數(shù)據(jù)進(jìn)行綜合分析

缺陷綜合分析

缺陷發(fā)現(xiàn)效率 ＝ 缺陷總數(shù)/執(zhí)行測試用時(shí)

可到具體人員得出平均指標(biāo)

用例質(zhì)量 ＝ 缺陷總數(shù)/測試用例總數(shù) ×100％

缺陷密度 ＝ 缺陷總數(shù)/功能點(diǎn)總數(shù)

缺陷密度可以得出系統(tǒng)各功能或各需求的缺陷分布情況，開發(fā)人員可以在此分析基礎(chǔ)上得出那部分功能/需求缺陷最多，從而在今后開發(fā)注意避免并注意在實(shí)施時(shí)予與關(guān)注，測試經(jīng)驗(yàn)表明，測試缺陷越多的部分，其隱藏的缺陷也越多。

測試曲線圖

描繪被測系統(tǒng)每工作日/周缺陷數(shù)情況，得出缺陷走勢和趨向

重要缺陷摘要

缺陷編號 簡要描述 分析結(jié)果 備注

3.3.3殘留缺陷與未解決問題

殘留缺陷

編號：BUG號

缺陷概要：該缺陷描述的事實(shí)

原因分析：如何引起缺陷，缺陷的后果，描述造成軟件局限性和其他限制性的原因

預(yù)防和改進(jìn)措施：彌補(bǔ)手段和長期策略

未解決問題

功能/測試類型：

測試結(jié)果：與預(yù)期結(jié)果的偏差

缺陷：具體描述

評價(jià)：對這些問題的看法，也就是這些問題如果發(fā)出去了會造成什么樣的影響

PARTⅤ 測試結(jié)論與建議

報(bào)告到了這個(gè)部分就是一個(gè)總結(jié)了，對上述過程、缺陷分析之后該下個(gè)結(jié)論，此部分為項(xiàng)目經(jīng)理、部門經(jīng)理以及高層經(jīng)理關(guān)注，請清晰扼要的下定論。

4.1測試結(jié)論

1． 測試執(zhí)行是否充分（可以增加對安全性、可靠性、可維護(hù)性和功能性描述）

2． 對測試風(fēng)險(xiǎn)的控制措施和成效

3． 測試目標(biāo)是否完成4． 測試是否通過

5． 是否可以進(jìn)入下一階段項(xiàng)目目標(biāo)

4.2建議

1．對系統(tǒng)存在問題的說明，描述測試所揭露的軟件缺陷和不足，以及可能給軟件實(shí)施和運(yùn)行帶來的影響

2．可能存在的潛在缺陷和后續(xù)工作

3．對缺陷修改和產(chǎn)品設(shè)計(jì)的建議

4．對過程改進(jìn)方面的建議

測試報(bào)告的內(nèi)容大同小異，對于一些測試報(bào)告而言，可能將第四和第五部分合并，逐項(xiàng)列出測試項(xiàng)、缺陷、分析和建議，這種方法也比較多見，尤其在第三方評測報(bào)告中，此份報(bào)告模板僅供參考。

第四篇：網(wǎng)上購物系統(tǒng)測試報(bào)告[模版]

網(wǎng)上購物系統(tǒng)測試報(bào)告

M10 計(jì)算機(jī)科學(xué)與技術(shù)(專轉(zhuǎn)本)1021413002

一、題目描述

在互聯(lián)網(wǎng)日益流行的今天，網(wǎng)絡(luò)已經(jīng)變的越來越重要，而在網(wǎng)絡(luò)這個(gè)大家庭里，用戶商城系統(tǒng)則是一個(gè)熱點(diǎn)。它具有信息時(shí)代的快捷方便等特征。事實(shí)上網(wǎng)上購物商城的出現(xiàn)，給消費(fèi)者的消費(fèi)觀念帶來了重要的變化。同時(shí)一個(gè)用戶商城系統(tǒng)是否具有良好的人機(jī)界面，其系統(tǒng)最大限度地實(shí)現(xiàn)易維護(hù)性和易操作性，運(yùn)行穩(wěn)定、安全可靠如何，都是用戶及運(yùn)營者所關(guān)心的。本次測試就本用戶商城系統(tǒng)的用戶管理等安全性進(jìn)行測試。

二、測試分析

本次我進(jìn)行測試的是用戶商城系統(tǒng)的會員管理：用戶在前臺注冊成功后，管理員可以在該功能項(xiàng)中進(jìn)行管理。主要是用戶在購買商品前需要先進(jìn)行登錄，如果您還未注冊會員，需要先進(jìn)行注冊。注冊成功后進(jìn)行登錄，登錄成功后用戶即可購買商品。我所思考的主要是安全性方面，看是否有服務(wù)器注入漏洞，是否有Session對象的使用，以及其他的安全性問題。

三、測試設(shè)計(jì) 3.1測試總體結(jié)構(gòu)

3.2白盒測試用例設(shè)計(jì)

1.用戶在前臺注冊，在對比數(shù)據(jù)庫中沒有相重或不合法的地方后，即提交注冊信息，將新用戶信息寫入數(shù)據(jù)庫。

注冊代碼：

public partial class Register : System.Web.UI.Page {

UserInfoClass uiObj = new UserInfoClass();

public static int G_Int_MemberID;

protected void Page_Load(object sender, EventArgs e)

{

}

protected void btnSave_Click(object sender, EventArgs e)

{

1.if(txtPostCode.Text.Trim()== “" && txtPassword.Text.Trim()==”“)

{

2.Response.Write(”“);

}

else

{

3.bool P_Bl_Sex;

4.if(Convert.ToInt32(ddlSex.SelectedItem.Value.Trim())==1)

{

5.P_Bl_Sex =true;

}

else

{

6.P_Bl_Sex =false;

}

7.G_Int_MemberID = uiObj.AddUInfo(txtName.Text.Trim(), P_Bl_Sex, txtPassword.Text.Trim(), txtTrueName.Text.Trim(), ”“, ”“, txtPhone.Text.Trim(), txtEmail.Text.Trim(), ddlCity.SelectedItem.Text.Trim(), txtAddress.Text.Trim(), txtPostCode.Text.Trim());

8.Session[”Username“] = ”“;

9.Session[”Username“] =txtName.Text.Trim();

10.Response.Write(”“);

}

} } 1）控制流圖

2）環(huán)路復(fù)雜度計(jì)算

由上圖可得，有四條不同的環(huán)路，所以環(huán)路復(fù)雜度為四。

3）基本路徑集設(shè)計(jì)

基本路徑為：

A.1、2、4、5、7、8、9、10 B.1、2、4、6、7、8、9、10 C.1、3、4、5、7、8、9、10 D.1、3、4、6、7、8、9、10 4）測試用例集設(shè)計(jì)

2.用戶登錄，用戶在注冊完后，獲取得屬于自己的合法身份，即可通過獲得的身份進(jìn)行相應(yīng)的權(quán)限操作。同時(shí)也看其是否使用了Session對象對網(wǎng)頁的安全性進(jìn)行進(jìn)一步鞏固，每個(gè)用戶的操作都有時(shí)效限制。

登錄代碼：

protected void btnLoad_Click(object sender, EventArgs e)

{

1.Session[”UID“] = null;

2.Session[”Username“] = null;

3.if(txtName.Text.Trim()== ”“ || txtPassword.Text.Trim()== ”“)

{

4.}

else

{

5.if(txtValid.Text.Trim()== lbValid.Text.Trim())

{

6.int P_Int_IsExists = uiObj.UserExists(txtName.Text.Trim(), txtPassword.Text.Trim());

7.if(P_Int_IsExists == 100)

{

8.DataSet ds = uiObj.ReturnUIDs(txtName.Text.Trim(), txtPassword.Text.Trim(), ”UserInfo“);

9.Session[”UID“] = Convert.ToInt32(ds.Tables[”UserInfo“].Rows[0][0].ToString());

10.Session[”Username“] = ds.Tables[”UserInfo“].Rows[0][1].ToString();

11.Response.Redirect(”index.aspx“);

}

else

{

12.Response.Write(”“);

Response.Write(”“);

}

}

else

{

13.}

} }

Response.Write(”");

1）控制流圖

2）環(huán)路復(fù)雜度計(jì)算

由上圖可得，有四條不同的環(huán)路，所以環(huán)路復(fù)雜度為四。

3）基本路徑集設(shè)計(jì)

基本路徑： A.1、2、3、4 B.1、2、3、5、6、7、8、9、10、11、12 C.1、2、3、5、7、12 D.1、2、3、5、7、8、9、10、11、12 4）測試用例集設(shè)計(jì)

四、測試報(bào)告

五、測試小結(jié)

通過本次測試實(shí)驗(yàn)，我基本了解掌握了基本的白盒測試方法及測試用例分析方法。本次測試是針對一網(wǎng)上購物系統(tǒng)進(jìn)行的，網(wǎng)購系統(tǒng)對安全性的要求是很高的，其安全影響方面頗多，真正的網(wǎng)購系統(tǒng)一旦有漏洞所造成的損失將是巨大的。所以，本次所測系統(tǒng)雖小但影響或是說對我的印象是十分深刻的，深深讓我體會到了測試工作的重要性。測試工作看著雖小，但實(shí)際上他的所負(fù)是極為有用的。一系統(tǒng)的問題及改進(jìn)方向有重大影響與指導(dǎo)，一個(gè)合格的軟件測試工作者，能為日后軟件的維護(hù)、服務(wù)等都可省卻一大筆，為客戶、公司避免過大的損失。這次實(shí)驗(yàn)后也糾正了我的很多思想，我已不再單純的認(rèn)為軟件測試比軟件開發(fā)容易了，在進(jìn)行測試前，首先必須理解業(yè)務(wù)和需求。需求和業(yè)務(wù)理解了，才知道客戶想要系統(tǒng)實(shí)現(xiàn)什么。然后按照需求來進(jìn)行測試，不滿足需求要求的都可以認(rèn)為是BUG。雖然在實(shí)際工作中，拿到一份完整詳細(xì)的需求是很不容易的，但要做好一個(gè)功能測試，前提就是要對需求比較熟悉，各個(gè)業(yè)務(wù)細(xì)節(jié)都很了解，甚至做到比開發(fā)人員還要了解。而且對一個(gè)軟件測試人員最重要的素質(zhì)要求就是要追求完美，不容許哪些缺點(diǎn)。

實(shí)驗(yàn)結(jié)束，給了我對軟件測試這一行業(yè)新的理解，

第五篇：考勤系統(tǒng)管理制度

黃河大酒店員工考勤系統(tǒng)管理制度

為加強(qiáng)對員工考勤系統(tǒng)的管理，實(shí)時(shí)了解和掌握人力資源的科學(xué)利用情況，確保出勤質(zhì)量和工作質(zhì)量，特制定本制度體系：

一、簽到簽離制度

二、休息與排休制度

1、員工每月有四天基本的公休。關(guān)于員工的休息，各部門每月底要以書面形式（一般是考勤表）將各崗位員工的下月度休班情況科學(xué)合理地排列出來。經(jīng)分管領(lǐng)導(dǎo)簽字同意，報(bào)人力資源部備份后執(zhí)行；盡量做到按表休息。

2、員工的正常排休休息不用寫《假期申請單》，可直接休息，部門在考勤表上作相應(yīng)的休息標(biāo)識即可。

3、員工因工作等原因不能依排休次序休息的，提前或拖后休息、調(diào)休等情況，部門或當(dāng)事員工必須事先填寫《假期申請單》（一式三聯(lián)）；經(jīng)部門經(jīng)理和人力資源部審批同意后，方可休息；此舉有利于準(zhǔn)確了解各部門對人力資源的合理使用和調(diào)度情況；監(jiān)控不良情況的發(fā)生；

4、領(lǐng)班、主管、經(jīng)理、總監(jiān)等各級管理人員原則上不允許同時(shí)休息或連休。各崗位員工兩天以上的連休，部門必須上報(bào)分管的高層領(lǐng)導(dǎo)批示通過后，報(bào)人力資源部備案，才可休息；

5、經(jīng)理的休息都必須寫《假期申請單》，上報(bào)分管的高層領(lǐng)導(dǎo)批示通過后，報(bào)人力資源部備案，才可休息；排休的總原則和總要求：

①各個(gè)排休以不影響酒店各項(xiàng)工作的正常運(yùn)作為最重要的前提。若因休息安排不當(dāng)，或延誤工作，或降低服務(wù)標(biāo)準(zhǔn)，或產(chǎn)生任何負(fù)面影響的，一律追究責(zé)任。

②員工的排休由其上一級管理人員決定；員工不可以決定自己的休息，不可以想休就休；每位員工都要有工作的大局意識和集體意識；管理人員在排休時(shí)，也要盡量照顧到員工的意愿和具體情況。

三、請假制度

1、病假：員工休病假須持本酒店指定醫(yī)院簽章的病假單向所在部門申請，經(jīng)批準(zhǔn)后方可休假。部門經(jīng)理級以上管理人員請病假需總經(jīng)理批準(zhǔn)。員工因急診不能上班，應(yīng)由本人或親屬在4小時(shí)內(nèi)電話通知所在部門，病愈上班后8小時(shí)內(nèi)持急診證明補(bǔ)辦請假手續(xù)。

2、事假：事假要提前填寫請假條，寫明事由和請假時(shí)間。事假2天以內(nèi)由部門總監(jiān)批準(zhǔn)；2天以上須填報(bào)《假期申請表》上報(bào)分管領(lǐng)導(dǎo)審批，并交人力資源部備案。

3、產(chǎn)、婚、喪假：

4、員工請假的操作程序

程序：填報(bào)—審批—存檔

1.填報(bào)

（1）員工應(yīng)在休假前一周填寫《假期申請單》。

（2）有關(guān)內(nèi)容應(yīng)填報(bào)準(zhǔn)確、清楚，符合要求。

（3）休假時(shí)間及安排應(yīng)符合《員工手冊》中的有關(guān)規(guī)定。

2.審批

（1）《假期申請單》首先由部門主管、總監(jiān)簽批后報(bào)人力資源部。

（2）人力資源部審核員工假期類別及資料記錄是否符合規(guī)定。

（3）按審批權(quán)限分別由人力資源部、總經(jīng)理簽批。

3.存檔

人力資源部將批準(zhǔn)后的請假單分別存入本人檔案、所在部門及財(cái)務(wù)部。

四、考勤管理制度

1、考勤要求

（1）考勤由各部門指定的考勤員負(fù)責(zé)執(zhí)行。

（2）考勤日期為當(dāng)月1日至最后一天。

（3）《考勤表》應(yīng)填寫部門名稱、考勤月份、員工姓名，并由考勤員簽字，部門主管簽認(rèn)。

（3）在每月1日上午11：00前各部門將上月考勤經(jīng)部門總監(jiān)及分管領(lǐng)導(dǎo)審批簽字后報(bào)人力資源部。

2、考勤注意事項(xiàng)

（1）對于入職、正常離職、自動離職、調(diào)整辭退、開除、急辭等情況，部門要在考勤表

格內(nèi)準(zhǔn)確注明，并將空白表格進(jìn)行封單；

（2）部門考勤員必須在考勤表右側(cè)有關(guān)欄目內(nèi)填寫：病假、事假、工傷、產(chǎn)假、婚假、曠工等。如無相關(guān)欄目，則在考勤表右側(cè)顯著位置上予以注明。并具體表明次數(shù)、時(shí)間。

（2）對病假、工傷須附有酒店指定醫(yī)院蓋章簽認(rèn)的病假單、工傷證明；

（3）如發(fā)現(xiàn)員工一次遲到30分鐘以上或一月遲到累計(jì)3次以上曠工者，除在考勤表上注明

外，部門要按《獎懲手冊》的規(guī)定作出相應(yīng)處理。

（4）對長期病假、工傷、產(chǎn)假的員工也應(yīng)如實(shí)填寫或注明全月病假、工傷、產(chǎn)假的實(shí)際天

數(shù)。

（6）對各部門不同的排班及班次的時(shí)間要在《考勤表》上用簡單明了的符號標(biāo)明，以便查

對。

（7）考勤員必須認(rèn)真對待考勤工作，做到認(rèn)真仔細(xì)、準(zhǔn)確無誤，如有不明之處，主動詢問

部門主管或人力資源部。如因個(gè)人不負(fù)責(zé)任，造成考勤記錄錯誤的，酒店將酌情予以罰款處理。

（8）員工考勤的操作程序

程序：核對—審核—結(jié)算

1.核對

（1）由部門于每月30日將排班表與簽到離表進(jìn)行核對，根據(jù)實(shí)際出勤及遲到早退情況填寫

《員工考勤記錄表》，于每月的2日前交人力資源部。

2.審核

（1）人力資源部經(jīng)理每月3日至5日，根據(jù)各部門《員工考勤表》所填項(xiàng)目對照排班表、假期申請單、補(bǔ)假單等資料作進(jìn)一步復(fù)核。

（2）6日報(bào)人力資源總監(jiān)作最后審核。

3.結(jié)算

（1）每月25日前根據(jù)經(jīng)人力資源總監(jiān)簽署后的考勤記錄做出員工工資單，分別提交人力資

源總監(jiān)、部門總監(jiān)、財(cái)務(wù)總監(jiān)、總經(jīng)理審核后送交財(cái)務(wù)部結(jié)算工資。

（2）上述規(guī)定期限遇休息日依次向后順延。

五、加班及補(bǔ)償制度：

程序：申報(bào)—實(shí)施—補(bǔ)償

1．申報(bào)

（1）部門如確實(shí)由于工作原因而需員工加班的，應(yīng)事先填寫《加班申請單》，報(bào)人力資源部

進(jìn)行審批。

（2）人力資源總監(jiān)進(jìn)行核準(zhǔn)后在《加班申請單》上簽署意見，并將其送還上報(bào)部門。

2．實(shí)施

（1）部門根據(jù)人力資源部核準(zhǔn)后的意見安排員工加班。

（2）各部門在加班作業(yè)時(shí)應(yīng)注意嚴(yán)格控制好加班時(shí)間。

3.補(bǔ)償

由部門經(jīng)理根據(jù)營業(yè)及工作需要對超時(shí)工作的員工進(jìn)行補(bǔ)償：

a）補(bǔ)假：

由部門主管在經(jīng)人力資源部審批后的《加班申請單》上填寫加班時(shí)間，隨附當(dāng)月考勤表交人力資源部，再由人力資源部開具《補(bǔ)假單》下發(fā)至各有關(guān)部門。

b)補(bǔ)薪：

超時(shí)工作時(shí)間盡量在年內(nèi)以補(bǔ)假的形式完成補(bǔ)償，若年內(nèi)不能安排的，由部門提交經(jīng)人力資源部審批后的《加班申請單》，并注明超時(shí)工作時(shí)間及加班事由，向人力資源部提交補(bǔ)薪申請。人力資源部在每月底將補(bǔ)薪金額和名單呈交總經(jīng)理審閱。

員工因工作等原因不能依排休次序休息的，部門必須事先填寫《加班申請單》（一式三聯(lián)）；經(jīng)人力資源部審批同意后，按《超時(shí)工作操作程序》文件辦理。

4、部門對員工的超時(shí)加班延報(bào)、不報(bào)者，休假一律作廢處理。

5、人力資源部每月根據(jù)部門上報(bào)的《加班申請單》及當(dāng)月補(bǔ)休情況開具員工的《補(bǔ)假單》并下發(fā)給部門負(fù)責(zé)人。員工可憑《補(bǔ)假單》填寫《假期申請單》補(bǔ)休。

6、《補(bǔ)假單》經(jīng)員工簽字確認(rèn)后，由所在部門管理人員（或考勤員）統(tǒng)一集中保管，以便于本部門宏觀掌握員工的總體休息情況，作出主動合理的休息安排。

7、《補(bǔ)假單》每月底上交人力資源部。人力資源部將進(jìn)行嚴(yán)格的審核工作。部門員工考勤及休息記錄（如排休表、加班申請單、補(bǔ)假單、假期申請單、考勤表等）必須要與人力資源部的記錄相一致，若因部門延報(bào)、誤報(bào)、不報(bào)而導(dǎo)致的人力資源部沒有備案的，以人力資源部的記錄情況為準(zhǔn)。

8、為了審核工作的方便性和精確度，部門在月底提交的考勤表匯總欄右側(cè)注明月度“累計(jì)應(yīng)補(bǔ)假天數(shù)”可簡寫為“應(yīng)補(bǔ)XX天”。

五、望各部門嚴(yán)格、謹(jǐn)慎、仔細(xì)做好員工的休息與考勤工作。

8、為了審核工作的方便性和精確度，部門在月底提交的考勤表匯總欄右側(cè)注明月度“累計(jì)應(yīng)補(bǔ)假天數(shù)”可簡寫為“應(yīng)補(bǔ)XX天”。