oracle 9i Statspack测试报告
测试环境：
OS:window Xp
DBracle9.2.0.1
一、Statspack 的安装
1、从sqlplus登陆数据库
SQL>conn / as sysdba
2、创建一个Statspack表空间，要求80M以上或者使用已经存在的表空间，但必须有80M 以上的空闲空间
SQL>create tablespace statspack datafile '
3、执行安装脚本，在Oracle_Home\dbms\admin下：
SQL>@D:\oracle\rdbms\admin\spcreate.sql
注：创建过程中会提示输入perfstat的密码、默认表空间和默认临时表空间。perfstat密码任意设置，默认表空间为上一步创建的表空间：staspack，默认临时表空间为temp。
4、检查当前用户是否为perfstat:
SQL>show user
USER 为"perfstat"
注：如果不是perfstat,则手动用perfstsat登陆。
SQL>conn perfstat/****（上一步设置的perfstat的密码）
二、如果安装过程出错，怎么纠正
1、必须先用SYS用户登陆数据库
SQL>conn / as sysdba
2、先删除之前创建的对象，然后再重新创建
SQL>@D:\oracle\rdbms\admin\spdrop.sql
SQL>@D:\oracle\rdbms\admin\spcreate.sql
三、手工采样生成报告
1、手工抓取快照，必须2次或更过：
SQL>exec statspack.snap;
---间隔一段时间
SQL>exec statspack.snap;
2、生成报告
SQL>@D:\oracle\rdbms\admin\spreport.sql
输入begin_snap 的值:1
输入end_snap 的值:100
输入report_name 的值:\report.txt
---以上输入内容根据自己的需要输入。begin_snap开始快照点，end_snap 终止快找点，
report_name报告名(最好包括目录和文件名，便于以后查看生成报告)
3、根据report_name输入的报告地址，用文本编辑器等打开生成的报告，具体情况具体分析。
四、系统自动采样数据
1、修改spauto.sql内容，定义定时任务，定义采样数据的时间间隔：bms_job.submit(:jobno,’statspack.snap;’,trunc(sysdate+1/24,”HH”),’trunc(sysdate+1/24,”HH”),T RUE,:instno);
一天24小时，1440分钟，则：
每小时一次：1/24 (建议使用)
每30分钟一次：1/48
每10分钟一次：1/144
每5分钟一次：1/288
2、运行自动执行脚本
SQL>@D:\oracle\rdbms\admin\spauto.sql
3、运行生成报告脚本
SQL>@D:\oracle\rdbms\admin\spreport.sql
五、删除系统自动采job
1、检查任务中是否有这个任务，并记下该job的ID
SQL>select job,interval from user_jobs; ；
2、根据查到的job_id删除任务
SQL>conn perfstat/oracle
SQL>exec dbms_job.remove(job_id)；
3、删除历史数据
SQL>delete from stats$snapshot where snap_id
4、删除全部数据
SQL>@D:\oracle\rdbms\admin\sptrunc.sql
六、Statspack报告说明
1 . 数据库总体信息
2 . 每秒每事务的资源消耗情况
3 . 实例的各组件的命中率
4 . 共享池总体情况
5 . 前5个等待事件
6 . DB所有等待事件
7 . 后台进程等待事件
8 . 根据BufferGets进行排序的SQL
9 . 按物理IO进行排序的SQL
10 . 按执行次数排序的SQL
11 . 按分析次数排序的SQL
12 . 实例的当前活动的统计数据
13 . tablespaceIO统计数据
14 . 表空间文件IO统计数据
15 . buffer池统计数据
16 . 实例恢复统计数据
17 . Buffer池的参考数据
18 . Buffer等待统计数据
19 . PGA总体统计数据1
20 . PGA总体统计数据2
21 . PGA内存参考数据
22 . 回滚段统计
23 . 回滚段存储统计
24 . undo段总体情况
25 . undo段统计
26 . 锁存器的当前情况
27 . 锁存器睡眠等待统计
28 . 锁存器失败情况(对系统影响不大)
29 . 数据字典cache性能统计(由oracle自己管理，可以忽略)
30 . 库cache性能统计
31 . 共享池性能统计(遗漏，没有总结)
32 . SGA区总体情况
33 . SGA各组件的活动情况
34 . 系统配置参数
以下是生成报告的各部分信息的解释(只列出了每一部分的头部和描述)：
STA TSPACK report for
---------------------------------------------------------------------
---------------------1. DB的总体信息---------------------------------
---------------------------------------------------------------------
（数据库和实例的名字）
DB Name DB Id Instance Inst Num Release Cluster Host
-------------------------- -------- ----------- ------- ------------
MYDB 2125240762 mydb 1 9.2.0.1.0 NO VCS-SERVER1
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ ------- --------- -------------------
Begin Snap: 1 09-Aug-04 19:28:12 32 2.7
End Snap: 2 09-Aug-04 19:33:06 32 3.0
Elapsed: 4.90 (mins) (本次报告的间隔时间)
Cache Sizes (end) （当前缓冲区主要部件的配置）
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,536M Std Block Size: 8K
Shared Pool Size: 112M Log Buffer: 16,000K
---------------------------------------------------------------------
---------------2.每秒每事务的资源消耗情况----------------------------
---------------------------------------------------------------------
Load Profile （加载配置文件）
------------------ Per Second (每秒) Per Transaction(每事务) -------
Redo size: 38,498.93 6,733.30 –每秒/每事务产生的redo大小
Logical reads: 593.28 103.76 –每秒/每事务逻辑读
Block changes: 77.60 13.57 –每秒/每事务修改的块数
Physical reads: 2.65 0.46 -- 每秒/每事务物理读
Physical writes: 8.17 1.43 —每秒/每事务物理写
User calls: 38.32 6.70
Parses: 6.52 1.14 --SQL分析的次数
Hard parses: 0.05 0.01 –SQL硬分析的次数
Sorts: 0.73 0.13--
Logons: 0.01 0.00
Executes: 39.64 6.93
Transactions: 5.72
% Blocks changed per Read: 13.08 Recursive Call %: 24.84
Rollback per transaction %: 0.00 Rows per Sort: 138.04
说明：
Redo Size——Per Second：每秒产生的日志大小(单位字节)可标志数据库任务的繁重与否Redo Size——Per Transaction：平均每个事务的日志生成量（单位字节）
Logical Reads——Per Second(逻辑读)：平均每秒产生的逻辑读,单位是block
Logical Reads——Per Transaction：平均每个事务产生的逻辑读,单位是block
Block Changes——Per Second：每秒block变化数量，数据库事务带来改变的块数量Block Changes——Per Transaction：平均每个事务所导致的改变的块数
Physical Reads——Per Second：平均每秒数据库从磁盘读取的block数,单位是block Physical Reads——Per Transaction：平均每个事务从磁盘读取的block数,单位是block Physical Write——Per Second：平均每秒写磁盘的block数
Physical Write——Per Transaction：平均每个事务写磁盘的block数
User Calls——Per Second：每秒用户call次数
User Calls——Per Transaction：每事务用户call次数
Parses——Per Second：每秒解析次数，近似反应了每秒语句的执行次数Parses——Per Transaction：每事务产生的解析次数
Hard Parses——Per Second：每秒产生的硬解析次数
Hard Parses——Per Transaction：每事务产生的硬解析次数
Sorts——Per Second：每秒产生的排序次数
Sorts——Per Transaction：#5#每事务产生的排序次数
Transactions——Per Second：每秒产生的事务数
Executes——Per Second：每秒执行次数
Execute——Per Transaction：每个事务执行次数
Logons——Per Second ：每秒钟有多少次logon
硬分析：就是之前不存在此SQL，是第一次解析。如果SQL重用度很高，则硬解析应保持很低。
% Blocks changed per Read：表示逻辑读用于只读而不是修改的块的比例。发生变化的块数/读次数，即每次Read有百分之多少的block发生了变化。变化的块
Recursive Call %:递归操作占所有操作的比率
Rollback per transaction %: 事务的回滚率
Rows per Sort: 每次排序所涉及到的行数
---------------------------------------------------------------------
----------------3.实例的各组件的命中率------------------------------
---------------------------------------------------------------------
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.55 In-memory Sort %: 100.00
Library Hit %: 99.33 Soft Parse %: 99.16
Execute to Parse %: 83.56 Latch Hit %: 99.99
Parse CPU to Parse Elapsd %: % Non-Parse CPU:
说明：
Buffer Nowait %：即Buffer Nowait Ratio，在缓冲区中获取buffer 的未等待比率。
Redo Nowait：写日志的不等待比率,太低可调整log_buffer(增加)和_log_io_size(减小，默认为1/3*log_buffer/log_block_size,使得_log_io_size 为合适的值，比如128k/log_block_size)。Buffer Hit：即Data Buffer Hit Ratio，数据块在数据缓冲区中的命中率，通常应该在90%以上，否则考虑加大db_block_buffers(9i 以上可是db_cache_size)。
In-memory Sort %：即In Memory Sort Ratio，如果过低说明有大量的排序在临时表空间中进行，可尝试增加sort_area_size ，很多时候也需要检查一下是否存在不良SQL。
Library Hit %：即Library Hit Ratio，主要代表着sql在共享区的命中率，通常在98%以上
Soft Parse %：即Soft Parse Ratio，近似当作sql在共享区的命中率，通常高代表使用了绑定变量,太低需要调整应用使用绑定变量，或者参考cursor_sharing = force。
Execute to Parse %:是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多，如果过低可以考虑设置session_cached_cursors > 0
Latch Hit ：内部结构维护锁命中率，高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多，可参考_spin_count 参数设置。
Soft Parse %:软分析：即在共享池中重复使用的SQL，系统应保持较高的软分析率，否则说
明系统的SQL没有绑定变量。
Non-Parse CPU：查询实际运行时间/(查询实际运行时间+sql解析时间)，该值大于95％比较好，太低表示解析消耗时间过长。
Parse CPU to Parse Elapsd %: 用于分析每个CPU 花费的秒数，应该处于较高比例。如果=100%,说明CPU没有等待。
---------------------------------------------------------------------
---------------------4.共享池总体情况-------------------------------
---------------------------------------------------------------------
Shared Pool Statistics Begin End
Memory Usage %: 89.91 90.55
% SQL with executions>1: 32.14 32.67
% Memory for SQL w/exec>1: 31.30 33.38
说明：
Memory Usage %: 正在使用的共享池的%,这个值应保持在75%~90%,如果这个值太低浪费内存，如果太高内存不足，会使共享池外部的组件老化，如果SQL语句被再次执行，则就会发生硬分析。
% SQL with executions>1:共享池中执行次数大于1的sql的比率（若太小可能是没有使用绑定变量）
% Memory for SQL w/exec>1: 频繁使用的SQL语句消耗内存多少的比例。即Percent of Memory for SQl with Execution，执行次数大于1的sql消耗内存/(所有sql消耗内存)
---------------------------------------------------------------------
------------------------5.前5个等待事件-----------------------------
---------------------------------------------------------------------
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
---------------------------------------------------------------------
log file sync 1,682 2 32.30
db file sequential read 623 3 46.70
db file parallel write 7,780 114,321 3.97
db file scattered read 8,560 70,945 2.46
buffer busy waits 12,303 40,058 1.39
---------------------------------------------------------------------
说明：
log file sync:当一个用户的会话提交时，会话的重写信息需要刷新到重做日志文件中，这个用户会话将发送LGWR将日志缓冲写到重做日志文件，当LGWR已经完成写入操作时，它将发送这个用户会话。当commit发生时，会产生log file sync.减少commit频率，加快redo 的写速度来改善此等待。另外也需要考察IO子系统的配置是否存在问题，例如可以考虑将
redo log file 与数据文件分开存放，并将redo log file放到raw device上面。
db file sequential read：和索引扫描有关，查看IO统计，解决IO冲突；加大db_block_buffers；修改应用，减少IO。
db file scattered read：当ORACLE全表扫描时,一次需读多个数据块，此时使用这一等待事件。i n i t .o r a中的db▁ file▁mutiblock▁read▁count定义了多数据块读取时，一次能读取的最大块数。一般此参数定义为4—16，与数据库大小无关。但值越大DB▁BLOCK▁SlZE应越小。如果db file scattered read所占比例较大,必须减少IO的代价（如使用更快的磁盘,均衡IO分布），或减少全表扫描的次数（优化SQL语句）。
(多blocks读;解决方法是修改db_file_multiblock_read_count;让表cache;
用下列语句查找IO过量的session:
SELECT sid,total_waits, time_waited
FROM v$session_event
WHERE event='db file scattered read'
and total_waits>0
ORDER BY 3,2;
buffer busy waits：有两个原因会引起buffer busy waits, 1.其他的session在将数据读到block 中，2.其他的session对block加了锁，与请求的锁不兼容。如果buffer busy waits等待的时间过长的话，我们要去查询是哪一部分(查看report.txt中buffer busy waits statistics的统计): SELECT count, file#, name
FROM x$kcbfwait, v$datafile
WHERE indx + 1 = file#
ORDER BY count；
SELECT p1 "File", p2 "Block", p3 "Reason"
FROM v$session_wait
WHERE event='buffer busy waits'；
SELECT distinct owner, segment_name, segment_type
FROM dba_extents
WHERE file_id= &FILE_ID
and &BLOCK_NUMBER between block_id and block_id+blocks-1；
Wait Time:等待时间包括日志缓冲的写入和发送操作。
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
global cache cr request 147,324 698 19.66
buffer busy global CR 7,435 682 19.22
global cache null to x 85,665 613 17.27
CPU time 574 16.17
buffer busy global cache 8,012 221 6.22
从owi方面看起来是符合之前讲的主要issue为buffer busy waits及RAC相关的wait的。
分析：
目前MLB21上的主要等待事件为buffer busy wait，等待类别为data block，实际上因data block 而触发的buffer busy wait等待事件下面两类：1、一种是高并发会话在对相同的对象执行DML，同时db_block_size尺寸较大(因同一个块包含更多的行)
从抓取到的二条TOP合此类型(UPDA TE&INSERT)，较为合适的方法就是增大PCTFREE。
2、另外就是多个session并发请求相同的数据块，但因该数据块不在buffer_cache中而必须从磁盘读取，处理这种情况，oracle会只让其中一个sesion进行磁盘读取，此时其它session 等待块从磁盘上读取进buffer_cache而抛出buffer busy wait等待事件。
这种情况也存在于当前环境中，从抓取到的第3条语句，表现为执行较为频繁且伴随有db file sequential read等待事件，可以先试着先优化TOP N逻辑读的SQL。
再比对一下，发现导致buffer busy wait的SQL语句与导致cluster wait的SQL语句一模一样。于是问题清晰了，当前DB环境的block_size为16k，RAC环境下的OLTP再加上那几个超频繁被执行update、insert的大表操作下，显得有些惨不忍睹，当前那几个表的pctfree为10，准备加大到30左右，index的pctfree低于50会导致索引走范围扫描，且快速全局扫描会较慢。上面提到的第2种buffer busy waits会造成少量的db file scattered read(即oracle允许其中一个session去磁盘读取数据块，当然，这个动作也有可能是db file sequential read)和大量的db file sequential read(即其他session会对读进来后的数据块进行逻辑读取)，需要去调优statspack 中的TOP N的逻辑读。
---------------------------------------------------------------------
-------------------------6.DB所有等待事件---------------------------
---------------------------------------------------------------------
Wait Events for DB: MYDB Instance: mydb Snaps: 1 -2
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
下面是非后台进程的等待事件：
这一部分很重要，它指出了oracle在等待资源时话了多少时间。忽略那些等待时间占总时间比例少的等待event,把剩余的等待时间加到一起，计算每个event占总时间的比例。
A vg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
----------------------------------------------------------------------------------------------------------------
db file sequential read 623 0 3 5 0.4
log file sync 1,682 0 2 1 1.0
control file parallel write 95 0 1 6 0.1
direct path read 727 0 3,462 48 0.0
db file parallel write 190 95 0 2 0.1
log file parallel write 1,674 1,664 0 0 1.0
db file scattered read 25 0 0 2 0.0
log file switch completion 60 0 2,029 338 0.0
control file sequential read 78 0 0 0 0.0
LGWR wait for redo copy 13 0 0 0 0.0
SQL*Net break/reset to clien 4 0 0 0 0.0
buffer busy waits 2 0 0 0 0.0
library cache pin 1 0 0 0 0.0
enqueue 706 2 1,759 25 0.0
latch free 1 0 0 0 0.0
SQL*Net message from client 10,830 0 4,364 403 6.4
SQL*Net more data from clien 1,596 0 0 0 0.9
SQL*Net message to client 10,830 0 0 0 6.4
---------------------------------------------------------------------
db file sequential read：表示ORACLE顺序读数据块，一般出现在读索引。如果db file sequential read等待很长，必须减少IO的代价（如使用更快的磁盘，均衡IO分布），或增加缓冲区
log file sync:任何时候一个事物提交时，它将通知LGWR将LOG▁BUFFER写入日志文件，如果此部分占用时间较长，应减少COMMIT的次数，此外应使用性能更好的IO系统，另一个相关的事件是”log buffer parallel write” ，也与IO系统或CPU资源太少有关。
buffer busy waits：多个进程访问（修改）缓冲区中同一数据块时出现此等待事件。当表没有free lists而对表并行插入时，或回滚段个数太少时，会出现此事件，V$WA|TSTA T及STA TSPACK报告可辅助找出原因。
latch free：(通过下列语句找到子糟糕的latch(查看report.txt中latch的统计和分析部分）) SELECT latch#, name, gets, misses, sleeps
FROM v$latch
WHERE sleeps>0
ORDER BY sleeps;
direct path read:直接读到process private buffer,与oracle buffer无关。与OS的IO系统有关，如果有问题，可以尝试关闭文件系统的direct IO选项.
log file switch completion:因为会话还没有滚动到下一个日志，日志文件switch（检查点未完成）将等待下一个日志切换。因为日志的检查点没有完成，log switch就不能执行。Enqueue:一般为应用程序使用的锁，例如SEELECT ... FOR UPDA TE。如果此部分占用的时间较大，需分析应用系统，尤其是长时间占有锁资源的代码。要分析每个锁的等待时间不太可能，虽然V$LOCK记录了每种所等待的次数。
(普通的锁（LOCAL LOCK）)
SELECT ksqsttyp "Lock",
ksqstget "Gets",
ksqstwat "Waits"
FROM X$KSQST where KSQSTW A T>0;
library cache pin:这个latch发生在一个session要使用shared pool中一个对象时，其他session 将这个对象以不兼容的模式pin.一般发生在一个对象或语句有比较严重的冲突。
SELECT p1 "Handle"
FROM v$session_wait
WHERE event='library cache pin'
SELECT address, to_char(hash_value,'9999999999999'), version_count, sql_text
FROM v$sqlarea
WHERE version_count>10
ORDER BY version_count;
SQL*Net message from client: 进程等待从client发送数据，可以忽略.
---------------------------------------------------------------------
-----------------------7.后台进程等待事件----------------------------
---------------------------------------------------------------------
Background Wait Events for DB: MYDB Instance: mydb Snaps: 1 -2
-> ordered by wait time desc, waits desc (idle events last)
A vg
Total Wait wait Waits
Event Waits Timeouts Time(s) (ms) /txn
---------------------------------------------------------------------
control file parallel write 95 0 1 6 0.1
db file parallel write 190 95 0 2 0.1
log file parallel write 1,674 1,664 0 0 1.0
control file sequential read 36 0 0 0 0.0
LGWR wait for redo copy 13 0 0 0 0.0
rdbms ipc message 5,352 3,687 1,148 214 3.2
smon timer 1 1 281 ### 0.0
---------------------------------------------------------------------
----------------8.根据BufferGets进行排序的SQL-----------------------
---------------------------------------------------------------------
SQL ordered by Gets for DB: MYDB Instance: mydb Snaps: 1 -2
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash V alue
--------- ---------- ----------- ----- ------ ------ ----------
74,380 20 3,719.0 42.6 0.00 5.03 1027916473
select count(*) from https://www.doczj.com/doc/4b3067029.html,erbaseinfo
10,920 1,291 8.5 6.3 0.00 0.71 1385081364
insert into Refence_tabvalues(1, 2, 3, 4, 5,6)
…………………………省略部分内容………………………………………………
--------------------------------------------------------------------
说明：
Top SQL with High Buffer Gets:这类sql进行了大量的block的读，要检查该sql是否用到了索引，或者说表上是否存在合理的索引，对于必须全表扫描的大表可以考虑recycle buffer ,对于频繁进行全表扫描的小表可以考虑keep buffer，还有一种需要注意的情况就是如果通过索引获取数据比例占表数据比例过大，比如20%(举例数据)，就能导致buffer gets过大。如果需要在有序表中获取低于40%的数据，或者在无序表中获取低于7%的数据，那么可以考虑使用索引代替全表扫表。
---------------------------------------------------------------------
-------------------9.按物理IO进行排序的SQL--------------------------
---------------------------------------------------------------------
SQL ordered by Reads for DB: MYDB Instance: mydb Snaps: 1 -2
-> End Disk Reads Threshold: 1000
CPU Elapsd
Phy Reads Executions Reads per Exec %Total Time (s) Time (s) Hash V alue
-------- ---------- ------------ ------ ------ -------- ---------
246 1,962 0.1 31.5 0.00 1.72 2431777133
select * from destinfo where sub_isdn= 1
149 20 7.5 19.1 0.00 5.03 1027916473
select count(*) from https://www.doczj.com/doc/4b3067029.html,erbaseinfo
…………………………省略部分内容………………………………………………
--------------------------------------------------------------------
说明：
如果发现系统的IO有限制，则可检查上述的SQL语句。Top SQL with High Execution Count：这类sql是需要重点关注的，也许这些sql本身一次执行并没有消耗大量的时间或者空间，但由于频繁的执行对系统影响极大，所以只要有优化的可能到要对这些sql进行优化。还有另外一些情况，就是某些程序中可能大量频繁地使用dual表来获取一些信息(比如时间的计算等)，尽可能的使这类sql转化为应用本地能解决的函数，或者还存在一些由于设计上的缺陷导致不必要的查询，都要在设计的角度避免这些查询。
---------------------------------------------------------------------
----------------------10.按执行次数排序的SQL------------------------
---------------------------------------------------------------------
SQL ordered by Executions for DB: MYDB Instance: mydb Snaps: 1 -2
-> End Executions Threshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec(s) Exec (s) Hash V alue
---------- ---------------- ----------- ---- ------ --------
2,907 904 0.3 0.00 0.00 1077832894
select * from userinfo where sub_isdn= 1
2,435 2,435 1.0 0.00 0.00 2271041384
select * from msginfo where msg_id= 1
…………………………省略部分内容………………………………………………
---------------------------------------------------------------------
说明：
对于频繁执行的SQL语句，应注意跟踪。
---------------------------------------------------------------------
--------------------11.按分析次数排序的SQL-------------------------
---------------------------------------------------------------------
SQL ordered by Parse Calls for DB: MYDB Instance: mydb Snaps: 1 -2
-> End Parse Calls Threshold: 1000
% Total
Parse Calls Executions Parses Hash V alue
------------ ------------ -------- ---------- 1,291 1,291 67.38 1385081364
insert into Refence_tabvalues(1, :p2, :p3, :p4, :p5,:p6)
118 118 6.16 2500993063
select ISDN,pass from smReq where isDel = '0'
…………………………省略部分内容………………………………………………
---------------------------------------------------------------------
----------------12.实例的当前活动的统计数据--------------------------
---------------------------------------------------------------------
Instance Activity Stats for DB: MYDB Instance: mydb Snaps: 1 -2
（实例活动统计）
Statistic Total per Second per Trans
--------- -------- ---------- ------------
CR blocks created 8 0.0 0.0
DBWR buffers scanned 0 0.0 0.0
DBWR checkpoint buffers written 2,402 8.2 1.4
DBWR checkpoints 0 0.0 0.0
DBWR free buffers found 0 0.0 0.0
DBWR lru scans 0 0.0 0.0
DBWR make free requests 0 0.0 0.0
DBWR revisited being-written buff 0 0.0 0.0
DBWR summed scan depth 0 0.0 0.0
…………………………省略部分内容………………………………………………
--------------------------------------------------------------------
说明：
可通过是面详细数据计算各种命中率等。
如：soft parse= (1-hard parse/total parse)*100%= (1-16/1916)*100%=99.16%就是报表开头的soft parse值。
parse time cpu :分析（parsing）SQL是一个开销很大的，它可以通过SQL语句的重用来避免。在预编译程序中，可通过增加MAXOPENCURSORS参数减少这部分开销。V$SQL的PARSE▁CALLS和EXECUTIONS可用来找出经常parse的语句。
CPU used by this session：有很多因素会引起cpu过载，
1、比较parse time cpu和CPU used by session, 如果比例高的话
a、SQL重用比例低，有一些效率不高的语句(过多的buffer get)，通过以下语句查询SELECT address, hash_value,
buffer_gets, executions, buffer_gets/executions "Gets/Exec",
sql_text
FROM v$sqlarea
WHERE buffer_gets > 50000 and executions>0
ORDER BY 3;
b、寻找CPU使用过量的session
SELECT v.sid, substr(https://www.doczj.com/doc/4b3067029.html,,1,30) "Statistic", v.value
FROM v$statname s , v$sesstat v
WHERE https://www.doczj.com/doc/4b3067029.html, = 'CPU used by this session'
and v.statistic#=s.statistic#
and v.value>0
ORDER BY 3;
recursive cpu usage：如果处理大量的PLSQL此成分可能很高，这里不深入讨论此问题产生的原因，但你需要找出你所有的PLSQL，包括存储过程。找出CPU开销最大的PLSQL过程并对其优化。如果PLSQL中的主要工作是完成过程处理而非执行SQL，高开销的recursive cpu usage可能是需要优化的成分。
---------------------------------------------------------------------
--------------------13.tablespace IO统计数据-------------------------
---------------------------------------------------------------------
Tablespace IO Stats for DB: MYDB Instance: mydb Snaps: 1 -2
->ordered by IOs (Reads + Writes) desc
Tablespace
---------------------------------------------------------------------
A v A v A v A v Buffer A v Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
----- ------- ------ ------ ------- ------- ---- -------------------
USERS 444 2 5.0 1.3 874 3 0 0.0
SHTMSG 131 0 1.9 1.0 1,005 3 1 0.0
UNDOTBS 0 0 0.0 353 1 1 0 0.0
IDEX 73 0 3.7 1.0 147 1 0 0.0
SYSTEM 0 0 0.0 1 1 0 0 0.0
---------------------------------------------------------------------
Table Space I/O：表示各表空间在IO上的分布，若出现严重不均衡，则要重新考虑对象的存储规划和表空间中数据文件的磁盘规划
---------------------------------------------------------------------
---------------------14.表空间文件IO统计数据-----------------------
---------------------------------------------------------------------
File IO Stats for DB: MYDB Instance: mydb Snaps: 1 -2
->ordered by Tablespace, File
Tablespace Filename
---------------------------------------------------------------------
A v A v A v A v Buffer A v Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
---- ------- ------ ----- -------- ------- -------- --------------
IDEX /dev/lvidex 73 0 3.7 1.0 147 1 0
SHTMSG /dev/lvshtmsg 131 0 1.9 1.0 1,005 3 1 0.0
SYSTEM /dev/lvsystem 0 0 11 0 0
UNDOTBS/dev/lvundotbs0 0 3 5 3 1 1 0.0
USERS /dev/lvusers444 2 5.0 1.3 874 3 0
--------------------------------------------------------------------- Datafile I/O：表示各数据文件的IO分布，若不均衡则需要重新考虑对象的存储规划。
---------------------------------------------------------------------
--------------------15.buffer池统计数据-----------------------------
---------------------------------------------------------------------
Buffer Pool Statistics for DB: MYDB Instance: mydb Snaps: 1 -2
-> Standard block size Pools D: default, K: keep, R: recycle
-> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
Free Write Buffer
Number of Cache Buffer Physical Physical Buffer Complete Busy
P Buffers Hit % Gets Reads Writes Waits Waits Waits
--- ---------- ----- ----------- ----------- ---------- ------- -------- ------
D 190,560 99.7 258,404 780 2,390 0 0 2
---------------------------------------------------------------------
----------------------16.实例恢复统计数据----------------------------
---------------------------------------------------------------------
Instance Recovery Stats for DB: MYDB Instance: mydb Snaps: 1 -2
-> B: Begin snapshot, E: End snapshot
Targt Estd Log File Log Ckpt Log Ckpt
MTTR MTTR Recovery Actual Target Size Timeout Interval
(s) (s) Estd IOs Redo Blks Redo Blks Redo Blks Redo Blks Redo Blks
- ----- ----- ---------- --------- --------- --------- --------- -------
B 161 28 11145 100666 100000 450000 207466 100000
E 161 28 11608 100043 100000 450000 199928 100000
---------------------------------------------------------------------
---------------------17.Buffer池的参考数据--------------------------
---------------------------------------------------------------------
Buffer Pool Advisory for DB: MYDB Instance: mydb End Snap: 2
-> Only rows with estimated physical reads >0 are displayed
-> ordered by Block Size, Buffers For Estimate
Size for Size Buffers for Est Physical Estimated
P Estimate (M) Factr Estimate Read Factor Physical Reads
--- ----------- ----- ---------------- ------------- ------------------
D 160 .1 19,850 1.92 81,500,147
D 320 .2 39,700 1.69 71,754,201
D 480 .3 59,550 1.57 66,774,777
D 640 .4 79,400 1.49 63,154,327
D 800 .5 99,250 1.40 59,432,741
D 960 .6 119,100 1.22 52,009,931
D 1,120 .7 138,950 1.08 46,041,143
D 1,280 .8 158,800 1.04 44,306,471
D 1,440 .9 178,650 1.01 42,974,849
D 1,536 1.0 190,560 1.00 42,478,849
D 1,600 1.0 198,500 0.99 42,032,350
D 1,760 1.1 218,350 0.97 41,128,356
D 1,920 1.3 238,200 0.94 39,877,785
D 2,080 1.4 258,050 0.92 39,058,138
D 2,240 1.5 277,900 0.91 38,475,363
D 2,400 1.6 297,750 0.88 37,173,210
D 2,560 1.7 317,600 0.85 35,983,344
D 2,720 1.8 337,450 0.83 35,325,000
D 2,880 1.9 357,300 0.81 34,595,023
D 3,040 2.0 377,150 0.79 33,731,234
D 3,200 2.1 397,000 0.77 32,711,726
---------------------------------------------------------------------
---------------------18.Buffer等待统计数据--------------------------
---------------------------------------------------------------------
Buffer wait Statistics for DB: MYDB Instance: mydb Snaps: 1 -2
-> ordered by wait time desc, waits desc
Tot Wait A vg
Class Waits Time (s) Time (ms)
------------------ ----------- ---------- ---------------------------
data block 1 0 0
undo block 1 0 0
--------------------------------------------------------------------
-----------------19.PGA总体统计数据1------------------------------
---------------------------------------------------------------------
PGA Aggr Target Stats for DB: MYDB Instance: mydb Snaps: 1 -2
-> B: Begin snap E: End snap (rows dentified with B or E contain data
which is absolute i.e. not diffed over the interval)
-> PGA cache hit % - percentage of W/A (WorkArea) data processed only in-memory -> Auto PGA Target - actual workarea memory target
-> W/A PGA Used - amount of memory used for all Workareas (manual + auto)
-> %PGA W/A Mem - percentage of PGA memory allocated to workareas
-> %Auto W/A Mem - percentage of workarea memory controlled by Auto Mem Mgmt -> %Man W/A Mem - percentage of workarea memory under manual control
PGA Cache Hit % W/A MB Processed Extra W/A MB Read/Written
--------------- ---------------- - ------------------------
100.0 7 0
%PGA %Auto %Man
PGA Aggr Auto PGA PGA Mem W/A PGA W/A W/A W/A Global Mem
Target(M) Target(M) Alloc(M) Used(M) Mem Mem Mem Bound(K)
- --------- --------- ---------- ---------- ------ ------ ------ ----------
B 200 174 27.1 0.0 .0 .0 .0 10,240
E 200 174 27.1 0.0 .0 .0 .0 10,240
---------------------------------------------------------------------
-------------------20.PGA统计数据2---------------------------------
---------------------------------------------------------------------
PGA Aggr Target Histogram(柱状图) for DB: MYDB Instance: mydb Snaps: 1 -2 -> Optimal Executions are purely in-memory operations
Low High
Optimal Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs
------- ------- -------------- ------------- ----------- ------------
8K 16K 98 98 0 0
16K 32K 12 12 0 0
32K 64K 2 2 0 0
64K 128K 3 3 0 0
2M 4M 2 2 0 0
--------------------------------------------------------------------
----------------------21.PGA内存参考数据---------------------------
---------------------------------------------------------------------
PGA Memory Advisory for DB: MYDB Instance: mydb End Snap: 2
-> When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0
Estd Extra Estd PGA Estd PGA
PGA Target Size W/A MB W/A MB Read/ Cache Overalloc
Est (MB) Factr Processed Written to Disk Hit % Count
--------- ------- ---------------- --------------- -------- ----------
25 0.1 6,180.6 3,466.6 64.0 0
50 0.3 6,180.6 3,459.1 64.0 0
100 0.5 6,180.6 861.1 88.0 0
150 0.8 6,180.6 861.1 88.0 0
200 1.0 6,180.6 861.1 88.0 0
240 1.2 6,180.6 861.1 88.0 0
280 1.4 6,180.6 861.1 88.0 0
320 1.6 6,180.6 861.1 88.0 0
360 1.8 6,180.6 861.1 88.0 0
400 2.0 6,180.6 861.1 88.0 0
600 3.0 6,180.6 861.1 88.0 0
800 4.0 6,180.6 861.1 88.0 0
1,200 6.0 6,180.6 861.1 88.0 0
1,600 8.0 6,180.6 629.9 91.0 0
---------------------------------------------------------------------
---------------------22.回滚段统计-----------------------------------
---------------------------------------------------------------------
Rollback Segment Stats for DB: MYDB Instance: mydb Snaps: 1 -2
->A high value for "Pct Waits" suggests more rollback segments may be required ->RBS stats may not be accurate between begin and end snaps when using Auto Undo managment, as RBS may be dynamically created and dropped as needed
Trans Table Pct Undo Bytes
RBS No Gets Waits Written Wraps Shrinks Extends
------ -------------- ------- --------------- ------- -------- --------
0 2.0 0.00 0 0 0 0
1 345.0 0.00 388,926 1 0 0
2 458.0 0.00 519,636 1 0 0
3 397.0 0.00 348,516 1 0 0
4 330.0 0.00 319,184 0 0 0
5 467.0 0.00 561,34
6 0 0 0
6 403.0 0.00 387,552 0 0 0
7 431.0 0.00 711,298 0 0 0
8 444.0 0.00 348,148 1 0 0
9 393.0 0.00 376,176 1 0 0
10 334.0 0.00 320,640 0 0 0
---------------------------------------------------------------------
-------------------23.回滚段存储统计---------------------------------
---------------------------------------------------------------------
Rollback Segment Storage for DB: MYDB Instance: mydb Snaps: 1 -2 ->Optimal Size should be larger than A vg Active
RBS No Segment Size A vg Active Optimal Size Maximum Size
----- ------------- ------------------------------------------
0 385,024 0 385,024
1 24,240,128 953,52
2 38,920,192
2 29,483,008 1,012,839 50,520,064
3 29,483,008 999,571 50,454,528
4 27,385,856 943,570 38,920,192
5 28,434,432 965,310 117,563,392
6 30,531,584 1,036,116 84,008,960
7 27,385,856 918,922 151,183,360
8 28,434,432 1,009,932 50,520,064
9 29,483,008 1,036,116 50,454,528
10 25,288,704 953,522 37,871,616
--------------------------------------------------------------------
------------------24.undo段总体情况---------------------------------
---------------------------------------------------------------------
Undo Segment Summary for DB: MYDB Instance: mydb Snaps: 1 -2 -> Undo segment block stats:
-> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed -> eS - expired Stolen, eR - expired Released, eU - expired reUsed
Undo Undo Num Max Qry Max Tx Snapshot Out of uS/uR/uU/ TS# Blocks Trans Len (s) Concurcy Too Old Space eS/eR/eU
--- - ---------- --------- ------- --------- ------- ------ -------------
1 2,970 ########## 357
2 0 0 0/0/0/0/0/0
--------------------------------------------------------------------
---------------------25.undo段统计----------------------------------
---------------------------------------------------------------------
Undo Segment Stats for DB: MYDB Instance: mydb Snaps: 1 -2
-> ordered by Time desc
Undo Num Max Qry Max Tx Snap Out of uS/uR/uU/
End Time Blocks Trans Len (s) Concy Too Old Space eS/eR/eU
---------- ---------- ------- ------ ------- ------ ------ -------------
09-Aug 19:42 1,306 ######## 16 2 0 0 0/0/0/0/0/0
09-Aug 19:32 1,664 ######## 357 2 0 0 0/0/0/0/0/0
---------------------------------------------------------------------
------------------26.锁存器的当前情况--------------------------------
---------------------------------------------------------------------
Latch Activity for DB: MYDB Instance: mydb Snaps: 1 -2
->"Get Requests", "Pct Get Miss" and "A vg Slps/Miss" are statistics for willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests ->"Pct Misses" for both should be very close to 0.0
Pct A vg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
------------------- ------------ ----- ------ ------ ------------ ------
Consistent RBA 1,673 0.0 0 0
SQL memory manager latch 1 0.0 0 96 0.0
SQL memory manager worka 6,565 0.0 0 0
active checkpoint queue 192 0.0 0 0
cache buffer handles 452 0.0 0 0
cache buffers chains 366,694 0.0 0.0 0 1,707 0.0
cache buffers lru chain 3,980 0.0 0 552 0.0
channel handle pool latc 4 0.0 0 0
channel operations paren 199 0.0 0 0
checkpoint queue latch 13,445 0.1 0.0 0 2,741 0.0
child cursor hash table 201 0.0 0 0
dml lock allocation 8,361 0.0 0 0
dummy allocation 4 0.0 0 0
enqueue hash chains 12,371 0.0 0.0 0 0
enqueues 2,662 0.0 0 0
event group latch 2 0.0 0 0
file number translation 14 0.0 0 0
hash table column usage 7 0.0 0 0
job_queue_processes para 5 0.0 0 0
ktm global data 1 0.0 0 0
lgwr LWN SCN 1,674 0.0 0 0
library cache 80,405 0.0 0.1 0 0
library cache load lock 46 0.0 0 0
library cache pin 28,408 0.0 0 0
library cache pin alloca 7,888 0.0 0 0
list of block allocation 8 0.0 0 0
messages 12,581 0.0 0.0 0 0
mostly latch-free SCN 1,733 2.4 0.0 0 0
multiblock read objects 54 0.0 0 0
ncodef allocation latch 5 0.0 0 0
post/wait queue 3,346 0.0 0 1,681 0.0
process allocation 2 0.0 0 2 0.0
process group creation 4 0.0 0 0
redo allocation 15,281
---------------------------------------------------------------------
------------------27 .锁存器睡眠等待统计-----------------------------
---------------------------------------------------------------------
Latch Sleep breakdown for DB: ALEPH0 Instance: aleph0 Snaps: 3 -5
-> ordered by misses desc
latch对oracle性能有比较大的影响
通过下列语句查询有问题的latch：
SELECT latch#, name, gets, misses, sleeps
FROM v$latch
WHERE sleeps>0
ORDER BY sleeps；
通过下列语句查询具体latch类型为LA TCH_NUMBER_WANTED的情况（如果没有的话，说明这类latch只有一个，即仅存在
于v$latch中），如果有几个latch占了大部分的sleep时间，说明有问题（注意addr）SELECT addr, latch#, gets, misses, sleeps
FROM v$latch_children
WHERE sleeps>0
and latch# = &LA TCH_NUMBER_WANTED
ORDER BY sleeps ；
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
------------------- -------------- ----------- ----------- ------------
library cache 5,166,288 27,612 6,374 23969/1758/1
482/403/0
在soft parsing和hard parsing时都会大量使用此latch，如有可能应修改应用程序，减少竞争。在init.ora中设置cursor▁sharing为force可减少soft parsing和hard parsing需要的library cache。此外定义session▁cached▁cursors也能减少同一session中soft parsing对library cache 的竞争。此外还可以定义cursor▁space▁for▁time=true。
从oracle7.2开始，library cache latches有child latch。多使用绑定变量，可以提高性能cache buffers chains 19,043,430 7,399 2,948 6053/920/82/
344/0
block的竞争会引起这个latch的问题，每个cache buffers chains latch覆盖一部分buffer cache,如果一两个child latches在V$LA TCH_CHILDREN比较突出,查询相应的buffer block SELECT File# , dbablk, class, state
FROM x$bh
超市仓库管理系统测试报告 1．引言 1.1 编写目的 测试计划 ?为对项目进行测试，且保证测试质量与进度，我们编写了此测试计划 分析报告 ?根据测试计划报告，对软件进行测试，详细记录测试过程，以对软件的质量进行测评，为软件设计人员提供BUG依据，故做产生测试分析 报告 1.2 项目背景 为一个超市设计并开发一套库存管理系统。 能兼容现行的手工帐册，要求能够设置期初库存，输入入库单和出库单，在每个结算月能够生成分类库存统计报表 当某种商品的库存少于安全库存时将给出警示，提醒尽快采购该商品 在每年的年终还能进行盘存处理，以纠正实际库存和电脑库存的差别2．任务概述 2.1 目标 本文档的目标是详细描述对超市仓库管理系统进行系统测试的测试过程。本文档所测试的功能均来自于需求文档 2.2 运行环境 操作系统：Windows XP及以上的版本 必装软件：SQL Server 2005及以上的版本 2.3 需求概述 本次测试主要针对本小组开发的仓库管理系统进行系统测试，主要包括功能测试、界面测试、负载测试、文档测试 在仓库管理系统需求规格说明书中列出的系统功能和性能都需要完成测试，在测试工作期间发现的所有缺陷都需要改正并确认
3．计划 3.1 测试方案 采用黑盒测试方法，整个过程采用自底向上，逐个集成的办法，依次进行单元测试，组装测试，测试用例的设计应包括合理的和不合理的输入条件 3.2 测试项目 测试1：名称：系统登录测试 目的：测试系统操作界面 内容：帐号口令输入、合理性检查、合法性检查，系统操作界面 显示控制 测试 2：名称：入库测试 目的：测试入库功能 内容：货物编号输入，入库对话显示控制，入库登记测试 3：名称：库存测试 目的：测试库存功能 内容：库存显示的合理性 测试 4：名称：出库测试 目的：测试出库操作功能 内容：出库管理界面显示控制，出库浏览，出库记录测试 5：名称：查询测试 目的：测试查询功能 内容：查询对话框显示控制，输入数据合理性检验、提交，查 询结果显示 测试 6：名称：报表测试 目的：测试结算库存报表功能 内容：输入数据提交，报表结果显示 测试 7：名称：新增商品信息测试 目的：测试新增商品功能 内容：输入数据合理性检验、提交，新增结果显示 测试 8：名称：新增仓库信息测试 目的：测试新增仓库功能 内容：输入数据合理性检验、提交，新增结果显示
技术资料 [项目名称] 系统测试报告 1测试内容及方法 1.1测试内容 本次测试严格按照《软件系统测试计划》进行，包括单元测试、集成测试、系统测试、用户接受度测试等内容。 1.2测试方法 正确性测试策略、健壮性测试策略、接口测试策略、错误处理测试策略、安全性测试策略、界面测试策略 1.3测试工作环境 1.3.1硬件环境 服务端 数据服务器： 处理器：Inter(R) Xeon(R) CPU E5410 @2.33GHz×2 操作系统：Windows Server 2003 Enterprise Edition SP2 内存空间：8G 硬盘空间：500G×2，RAID0 应用服务器： 处理器：Inter(R) Xeon(R) CPU E5410 @2.33GHz×2 操作系统：Windows Server 2003 Enterprise Edition SP2 内存空间：8G 硬盘空间：500G×2，RAID0 客户端 处理器：Inter(R) Core?2 Quad CPU Q6600 @2.4GHz
操作系统：Windows Server 2003 R2 Enterprise Edition SP2 内存空间：2G 硬盘空间：200G 1.3.2软件环境 操作系统：Windows Server 2003 R2 Enterprise Edition SP2 客户端浏览器：Internet Explorer 6.0/7.0 GIS软件：ArcGIS Server 9.3 WEB服务：IIS6.0 2缺陷及处理约定 2.1缺陷及其处理 2.1.1缺陷严重级别分类 严重程度修改紧急 程度 评定准则实例 高必须立即 修改 系统崩溃、不稳定、 重要功能未实现 1、造成系统崩溃、死机并且不能通过其它方法实现功能； 2、系统不稳定，常规操作造成程序非法退出、死循环、通讯中断或异 常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能。 3、用户需求中的重要功能未实现，包括：业务流程、主要功能、安全 认证等。 中必须修改系统运行基本正 常，次要功能未实 现 1、操作界面错误（包括数据窗口内列名定义、含义不一致）。 2、数据状态变化时，页面未及时刷新。 3、添加数据后，页面中的内容显示不正确或不完整。 4、修改信息后，数据保存失败。 5、删除信息时，系统未给出提示信息。 6、查询信息出错或未按照查询条件显示相应信息。 7、由于未对非法字符、非法操作做限制，导致系统报错等，如：文本 框输入长度未做限制；查询时，开始时间、结束时间未做约束等。 8、兼容性差导致系统运行不正常，如：使用不同浏览器导致系统部分 功能异常；使用不同版本的操作系统导致系统部分功能异常。 低可延期修 改 界面友好性、易用 性、交互性等不够 良好 1、界面风格不统一。 2、界面上存在文字错误。 3、辅助说明、提示信息等描述不清楚。 4、需要长时间处理的任务，没有及时反馈给用户任务的处理状态。 5、建议类问题。
商品仓库管理系统测试报告 一．引言 1．背景 本测试计划从属于商品存储配送物流管理系统。用户为中、小规模超市、商场、 公司。执行本测试前，已完成软件计划，需求分析，设计及编码工作。 2．参考文档 需求分析文档，概要设计文档，详细设计文档，测试计划文档，程序清单。 二．软件说明 1．本软件的主要功能为： (1)对商品入库和出库详细情况进行登记 (2)对商品出库安排车辆信息进行登记 (3)对库存信息进行高级查询 (4)对运输信息进行查询 (5)对客户信息进行登记 (6)对客户信息进行查询 (7)按照要求自动生成统计清单 (8)按照要求对所需清单进行打印 (9)实现数据库的断开、连接、备份 (10)对使用者进行管理 2．条件与限制： ⑴考虑到本软件面向的用户群比较广泛，在设计时应注意使软件具有较强的可 移植性； ⑵因本软件管理的某些信息属商业机密，必须注意信息的安全防范，同时应以 标准的数据格式来实现，以方便数据共享； 三．测试步骤 本次测试采用黑盒法。主要依据需求分析文档和测试计划文档，以需求分析文 档中的功能模块为单位，对提交的成型系统进行测试。综合使用等价类划分法 和其它方法。 详细测试步骤如下： 表1 单元测试
四.单元测试（各类函数） 利用Visual Studio2005中自带的单元测试功能进行单元测试，测试各个类 中的函数。按要求输入，测试与预期的结果是否吻合，如果不吻合则单元测试 结果将显示失败或者出错提示，若成功则单元测试结果将显示“通过”，如下。 1.测试loginform类下的函数Tloginform.loginClick(Sender: TObj ect); loginform 函数声明如下： var sqlstr:string; quanxian:string; begin sqlstr:='select*from users where users=:users and passwords=:passwords';函 数预期实现的功能：依据用户输入的用户名和密码判断用户的类型。 输入：在unit1.pas的Tloginform.loginClick(Sender:TObject);函数的首行添 入如下代码： try ADOQuery1.SQL.Add(sqlstr); adoquery1.Parameters.ParamByName('users').Value:=edit1.Text; //必 须确定属性字段 adoquery1.Parameters.ParamByName('passwords').Value:=edit2.Text;
xxxxxxxxxxxxxxx 系统测试报告 xxxxxxxxxxx公司 20xx年xx月
版本修订记录
目录 1引言 (1) 1.1编写目的 (1) 1.2项目背景 (1) 1.3术语解释 (1) 1.4参考资料 (1) 2测试概要 (2) 2.1系统简介 (2) 2.2测试计划描述 (2) 2.3测试环境 (2) 3测试结果及分析 (4) 3.1测试执行情况 (4) 3.2功能测试报告 (4) 3.2.1xxxx模块测试报告单 (4) 3.2.2xxxxx模块测试报告单 (5) 3.2.3xxxxxxxx模块测试报告单 (5) 3.2.4xxxxxxx模块测试报告单 (5) 3.2.5xxxxx模块测试报告单 (5) 3.3系统性能测试报告 (6) 3.4不间断运行测试报告 (6) 3.5易用性测试报告 (7) 3.6安全性测试报告 (8) 3.7可靠性测试报告 (8) 3.8可维护性测试报告 (10) 4测试结论与建议 (11) 4.1测试人员对需求的理解 (11) 4.2测试准备和测试执行过程 (11) 4.3测试结果分析 (11) 4.4建议 (11)
1引言 1.1编写目的 本测试报告为xxxxxx软件项目的系统测试报告，目的在于对系统开发和实施后的的结果进行测试以及测试结果分析，发现系统中存在的问题，描述系统是否符合项目需求说明书中规定的功能和性能要求。 预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。 1.2项目背景 项目名称：xxxxxxx系统 开发方： xxxxxxxxxx公司 1.3术语解释 系统测试：按照需求规格说明对系统整体功能进行的测试。 功能测试：测试软件各个功能模块是否正确，逻辑是否正确。 系统测试分析：对测试的结果进行分析，形成报告，便于交流和保存。 1.4参考资料 1)GB/T 8566—2001 《信息技术软件生存期过程》(原计算机软件开发规范) 2)GB/T 8567—1988 《计算机软件产品开发文件编制指南》 3)GB/T 11457—1995 《软件工程术语》 4)GB/T 12504—1990 《计算机软件质量保证计划规范》 5)GB/T 12505—1990 《计算机软件配置管理计划规范》
成功经理人https://www.doczj.com/doc/4b3067029.html,/ 提供大量企业管理资源下载以知识铺就成功之道，用智慧编织美好人生.
X公司ERP项目 系统测试报告 文档作者: 创建日期: 确认日期: 控制编码: 当前版本: 审批签字: X公司项目经理： A公司项目经理： 文档控制 拷贝数量:
更改记录 查阅 分发 目录
文档控制........................................................................................................... i i 更改记录.................................................................................................... i ii 目录.................................................................................................................. i ii 计划测试概览 (1) 计划测试概述 (2) 测试说明 (3) 测试范围 (3) 计划测试方法 (3) 测试业务 (4) 计划测试顺序 (5) 计划-Test Script 1 - 主计划名称的定义 (6) 计划-Test Script 2 - 主计划条目的录入 (7) 计划-Test Script 3 - 从销售定单载入主计划 (8) 计划-Test Script 4 - 从预测载入主计划 (9) 计划-Test Script 5 - MRP计划名称的定义 (10) 计划-Test Script 7 - MRP计划的运行 (11) 计划-Test Script 8 - 车间任务的下达 (12) 计划-Test Script 9 - 请购的下达 (13) 计划-Test Script 10 - 请购单和车间任务的自动维护 (14) 计划-Test Script 11 –计划查询 (15) 计划-Test Script 12 –标准报表运行 (17) 采购测试概览 (19) 测试说明 (20) 采购测试顺序 (20) 采购-Test Script 1 –供应商输入和维护 (21) 采购-Test Script 2 –报价单输入和维护 (22) 采购-Test Script 3 –请购单输入和维护 (23)
2016—2017学年第一学期期末考试 《面向对象程序设计（Java）*》实践考核项目设计说明书 项目名称：仓库管理系统 专业：计算机科学与技术 学号： 姓名： 任课教师：巩晨静 2016年12月3日
项目及要求 （一）考核内容：Java应用程序开发 （二）考核要求： 1．设计开发一个Java应用程序，设计题目自拟； 2．要求学生熟练运用Java程序设计的基本知识和技能； 3．要求学生掌握面向对象程序开发的基本思路和方法，熟悉软件开发过程；4．要求学生利用面向对象的编程思想以及组件开发原理来完成系统的设计；5．要求学生利用所学的基本知识和技能，进行应用程序设计，并体现自己的创新； 6．要求学生独立完成，严禁拷贝与抄袭； 7．按照软件工程的思想，完成项目的需求分析、项目的功能框架、用户界面的设计、各功能模块的调试和运行等工作； 8．重视设计说明书文档的书写。 9．上交要求。要求学生上交设计说明书一份(Word格式)电子及打印文档（A4纸）各一份，源程序打包上传BB平台。
目录
仓库管理系统设计说明书 第一章项目选题说明 管理信息系统（MIS）的应用已深入到社会的各行各业，它是信息、软件与科学管理相结合的产物。MIS的开发过程不仅是一个编写应用程序的过程，而且是一个以软件工程的思想为指导，从可行性研究开始，经过系统分析、系统设计、系统实施到等主要阶段的规范开发过程。 我们实现的是网络数据库管理系统，我们选择的是仓库管理系统，仓库作为一种资源的集散地,在企业的整个供应链中起着至关重要的作用，如果不能保证正确的库存控制及发货，将会导致管理费用的增加，服务质量难以得到保证，从而影响企业的竞争力，传统简单的，静态管理已经无法保证企业各种资源的搞笑利用。如今的仓库作业和库存控制作业已经十分复杂多样化，仅靠人工记忆和手工录入，不但费时费力，而且容易出错，给企业带来巨大的损失。所以要实施先进的自动化系统，实现企业内部的信息管理，共享交流，才能让企业在竞争激烈的21世纪取得先机。仓库管理系统就是对货物和信息及金钱进行规划和实行交流控制。它将入库、出库、库存形成一个统一的中体，使企业处于全面受控状态，压缩投资规模，加快资金周转。在实时反映的基础上，修正企业在日常生产经营过程中各个环节上的偏差，降低产品成本和货物的积压。 仓库管理系统是通过入库业务、出库业务、实时库存管理等功能综合运用的管理系统，对货物全程进行有效的控制和跟踪，实现完善的企业仓库信息管理。仓库管理系统的投入，将使仓库的管理更加正规化，为产品的出入库管理部门和销售部门提供了方便，降低了仓库的损耗。企业可以通过该系统对售出的产品进行跟踪服务，同时避免可过去销售人员按以往惯例亲自前往用户处去核实货物情况的麻烦，提高了办事小效率，节省了费用，而且还避免了不必要的业务纠纷，维护了企业长期与用户建立的良好信誉。
商品仓库管理系统测试报告 引言 1 ?背景本测试计划从属于商品存储配送物流管理系统。用户为中、小规模超市、商场、公司。执行本测试前，已完成软件计划，需求分析，设计及编码工作 2 ?参考文档 需求分析文档，概要设计文档，详细设计文档，测试计划文档，程序清单 二. 软件说明 1 ?本软件的主要功能为： (1)对商品入库和出库详细情况进行登记 (2)对商品出库安排车辆信息进行登记 (3)对库存信息进行高级查询 (4)对运输信息进行查询 (5)对客户信息进行登记 (6)对客户信息进行查询 (7)按照要求自动生成统计清单 (8)按照要求对所需清单进行打印 (9)实现数据库的断开、连接、备份 (10)对使用者进行管理 2 ?条件与限制： ⑴考虑到本软件面向的用户群比较广泛，在设计时应注意使软件具有较强的可移植性； ⑵因本软件管理的某些信息属商业机密，必须注意信息的安全防范，同时应以标准的数据格式来实现，以方便数据共享； 三. 测试步骤 本次测试采用黑盒法。主要依据需求分析文档和测试计划文档，以需求分析文档中的功能模块为单位，对提交的成型系统进行测试。综合使用等价类划分法和其它方法。 详细测试步骤如下： 四■单元测试(各类函数) 利用Visual Studio 2005中自带的单元测试功能进行单元测试，测试各个类中的函数。按要求输入，测试与预期的结果是否吻合，如果不吻合则单元测试结果将显示失败或者出错提示，若成功则单元测试结果将显示“通过”，如下。 表1单元测试
1.测试logi nform 类下的函数Tlogi nform.logi nClick(Se nder: TObject); log inform 函数声明如下： var sqlstr:stri ng; qua nxia n: stri ng; begi n sqlstr:='select * from users where users=:users and passwords=:password 函数预期实现的功能：依据用户输入的用户名和密码判断用户的类型。 输入：在unitl.pas的Tloginform.loginClick(Sender: TObject);函数的首行添入如下代码：try ADOQueryl.SQL.Add(sqlstr); adoquery1.Parameters.ParamByName('users').Value:=edit1.Text; // 必须确定属性字段 adoquery1.Parameters.ParamByName('passwords').Value:=edit2.Text; ADOQueryl.Ope n; if (ADOQueryl.RecordCou nt = 0) the n begi n messagedig(请输入正确的用户名和密码’,mtE rror,[mbok],0 ); exit; end; except on e:era ngeerror do showmessage用户名或密码错误'); end; beg in if (LeftStr(edit1.Text,2)='YB') the n menuman gerform.Show else
XXX项目软件测试报告 编制： 审核： 批准：
目录 1概述..................................................... 错误!未定义书签。2测试概要................................................. 错误!未定义书签。 进度回顾.......................................... 错误!未定义书签。 测试环境.......................................... 错误!未定义书签。 软硬件环境.................................. 错误!未定义书签。 网络拓扑.................................... 错误!未定义书签。3测试结论................................................. 错误!未定义书签。 测试记录.......................................... 错误!未定义书签。 缺陷修改记录...................................... 错误!未定义书签。 功能性............................................ 错误!未定义书签。 易用性............................................ 错误!未定义书签。 可靠性............................................ 错误!未定义书签。 兼容性............................................ 错误!未定义书签。 安全性............................................ 错误!未定义书签。4缺陷分析................................................. 错误!未定义书签。 缺陷收敛趋势...................................... 错误!未定义书签。 缺陷统计分析...................................... 错误!未定义书签。5遗留问题分析............................................. 错误!未定义书签。 遗留问题统计...................................... 错误!未定义书签。
《C++程序设计》课程设计报告 课程名称： C++程序设计 题目：商场电器库存管理系统 学生姓名：谷诗慧 学号： 201017030135 专业班级：网工10101班 指导教师：周慧灿 设计时间： 2011年上学期第17-19周 指导老师意见: 评定等级: 教师签名:
目录 一、课题简介 (3) 二、设计方案 (3) 三、具体设计 (3) 一）系统设计 (3) 1.系统功能模块 (3) 2．系统登录模块 (3) 3.商场电器管理信息 (5) 二）程序源代码 (12) 四、系统测试 (24) 一）测试过程中遇到的问题记录 (24) 二）测试结果 (26) 五、总结 (30) 参考文献 (30)
一、课题简介 本课题是关于如何管理商场商品，实现包括入库、出库、查询、报损等四方面的功能，把复杂工作简单化，提高工作效率，有条不紊的管理商场电器。 二、设计方案 一）商品入库 1.输入商品的基本信息； 二）商品出库 1是否已入库该商品； 2出库该商品； 三）查询统计 1.输入要查询的项目； 2.判断是否有与之相匹配的商品； 3.输出商品基本信息； 四）商品报损 1.输入待报损商品名称； 2.报损； 三、具体设计 一）系统设计 1.系统功能模块 通过对相关资料的查阅和对课题的认真分析，得出系统功能模块图如图1所示。系统主要由主函数、入库管理、出库管理、查询统计管理、报损管理、退出系统等几个功能模块组成。具体流程图如图1所示。 2．系统登录模块 系统登陆模块主要完成系统登陆和系统退出功能。其详细流程图如图2所示。 1.显示欢迎语； 2.输入管理员名字和密码； 3.验证用户名和密码； 4.进入主菜单
《仓库管理系统》测试报告说明书 1.需求分析 本次测试对象为在Android 4.0平台上运行的仓库管理程序,该程序主要实现内容有用户注册、用户登录、添加商品信息、添加客户信息、添加供应商信息、添加入库信息、添加出库信息。 1. 仓库管理系统用户注册界面：通过点击注册，分别输入用户名、职工号、密码和确认密码，点击确认提交来注册用户； 2. 仓库管理系统登录界面：通过输入用户名和密码，点击登陆来登陆用户；
品信息界面； 4. 仓库管理系统添加商品信息界面：分别输入商品名称、商品规格、计量单位，点击保存；
客户信息界面； 6. 仓库管理系统添加客户信息界面：分别输入公司名称、联系人、联系地址、城市名称、地区名称、邮政编码、联系电话、传真号码、公司主页，点击保存； 7. 仓库管理系统基本信息界面：通过点击供应商信息和点击添加供应商，编辑添加供应商信息界面；
8. 仓库管理系统添加供应商信息界面：分别输入公司名称、联系人、联系地址、城市名称、地区名称、邮政编码、联系电话、传真号码、公司主页，点击保存； 9. 仓库管理系统库存管理界面：通过点击商品入库和点击添加入库，编辑添加入库界面；
10.仓库管理系统添加入库界面：分别点击选择公司名称和商品名称，分别输入联系人、商品规格、联系电话、计量单位、进货单位、进货数量，点击选择进货日期，最后点击保存； 11.仓库管理系统库存管理界面：通过点击商品出库和点击添加出库，编辑添加入库界面；
12. 仓库管理系统添加出库界面：分别点击选择公司名称和商品名称，分别输入联系人、商品规格、联系电话、计量单位、进货单位、进货数量，点击选择进货日期，最后点击保存； 单元测试需求 1. 仓库管理系统界面 a) 检查用户是否能正常注册 b) 检查用户是否能正常登录 c) 检查是否能成功添加客户信息 d) 检查是否能成功添加入库信息 集成测试需求 1.检查用户是否能正常注册 2.检查用户是否能正常登录 3.检查是否能成功添加商品信息 4.检查是否能成功添加客户信息 5.检查是否能成功添加供应商信息 6.检查是否能成功添加入库信息 7.检查是否能成功添加出库信息
医院药品管理系统系统设计报告 院 (系) 专业 班级 组长 组员 2011年 11 月 3 日 系统设计说明书
1引言 在我国，随着医药卫生体系改革的深入，医药连锁经营的推行，越来越多的医药经营企业意识到提高企业管理水平的重要性，也迫切要求加快管理信息化的进程。 经调查可知，该医院医药经营企业的物流管理以及相应的财务处理、信息处理，长期以来一直采用手工操作，随着产业结构调整、全新的市场竞争环境，企业管理和运营效率已经成为企业成败的关键所在，手工方式的弊端毕现无疑。这就要求医药管理摆脱过去人手操作的繁琐，以充分满足医药经营企业各个环节对人流、物流、资金流、信息流进行统一系统的管理。 药品信息管理系统是指利用软硬件技术、网络通信技术等现代化手段，对药品的进货、出货、库存、价格及账务进行精确快速的管理，大大降低了管理中的复杂性以及出错率、减轻手工劳动的强度，提高顾客的满意度，从而为医院的整体运行提供全面的，自动化管理及各种服务的信息系统。 1.1目标 本文档的目的旨在推动软件工程的规范化，使设计人员遵循统一的详细设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。详细设计的详细程度，应达到可以编写程序的水平。 1.2范围 本阶段的设计任务：各子系统的公用模块实现设计、专用模块实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其它详细设计等。 1.3术语说明 第1页共13页
2整体说明 2.1简介 本系统名称为医院管理系统——库房系统管理子系统。目的是实现库房系统管理员对库房系统监控管理的功能和用户的查询和交易。实现方式为开发一个工作人员管理界面，通过识别不同用户的授权，可以查看不同药品的库存情况，价格以及买卖数量的全部信息。此系统为一个内部系统，医院内部管理人员通过管理库存系统实现整个医院系统的协调运行。该系统主要由基本信息、业务管理、业务查询、用户管理和系统管理5部分组成。 ●基本信息：药品情况、客户情况、供应商情况。 ●业务管理：药品采购、药品销售、库存盘点、销售退货、客户回款。 ●业务查询：基本信息、入库明细、销售明细、回款信息。 ●用户管理：增加用户、用户维护。 ●系统管理：系统退出。 2.2系统约束 1、范围约束 因为项目的范围可能会随着项目的进展而发生变化，从而与时间和成本等约束条件之间产生冲突，因此面对项目的范围约束，主要是根据项目的商业利润核心做好项目范围的变更管理。既要避免无原则的变更项目的范围，也要根据时间与成本的约束，在取得项目干系人的一致意见的情况下，合理的按程序变更项目的范围。 2、时间约束 在考虑时间约束时，一方面要研究因为项目范围的变化对项目时间的影响，另一方面要研究，因为项目历时的变化，对项目成本产生的影响。并及时跟踪项目的进展情况， 2
仓库管理系统学习报告 第一部分 前言 分享这几天在跟进魏总手下项目中的学习心得，在第一部分是总体概述，第二部分为学习内容，第三部分为后期学习展望。第四部分为EXCEL表格，为大宗商品的属性字段总结。 我跟进的项目是天物大宗钢材WMS仓储管理系统的一期项目。项目共有三期：一期为重庆中钢5号库的线材库WMS系统；二期为上海的板材库WMS系统，以及表现层的PC端B/S架构的主页，移动端IOS客户端及安卓客户端；三期为唐山的散货库WMS系统。每期项目的周期约一个月。由我方（甲方）提出业务流程，审核需求，以及完成部分测试工作。由厦门锐特信息（乙方）在其公司现有的信息系统上进行二次开发，测试，部署和培训工作。 我从一期项目的最后一周开始跟进，由魏总手下的项目经理王啸南带。计划继续跟进上海的二期项目，至少跟进完二期项目的前半部分，魏总这边也给予了极大的支持。这样可以对企业的信息管理系统有一套整体的理解和把握，对我们后期需要实施的布料信息管理系统也有极大的借鉴帮助作用。 第二部分根据一期项目的文档和资料自己进行的整理和总结，其中第1部分总结了重庆中钢5号库的入库业务流程，此仓库包括入库，
出库，库存操作三个业务。 第三部分是根据这段时间的学习体会对我们后期的布料仓储信息化管理提出的思考。 第四部分为我协助整理的5号库所需存储的大宗商品的信息属性，为EXCEL展现形式。里面详细的展现了所有商品的属性字段。数据表为树状结构，如钢铁类一共分三级。第一级为行业大类；第二级为品种，如热轧，冷轧等；第三级为明细品类，为最小单位。后期我们确定了需要做的布匹大类，具体品种和细分明细后，也需要详细的总结出一张这种树状结构的数据表。值得一提的是，布料的非标性要远远大于钢铁等大宗商品，顾属性字段得是我们后期花力气做的一件事。
魔方宝系统 软件功能测试报告2017年10月
1.测试环境 2.问题统计 （说明：该报告为阶段性测试的统计报告，该报表统计的bug数量为：本发布阶段内第一份申请单 提交日期为起，直至填写报告这天为止的BUG数量,如果以前版本中有问题延期至本发布阶段来修正， 那么该缺陷也需要统计进来；如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的） 2.1按BUG犬态统计（表格后面可以附上柱形图,以示更直观） 表按状态统计 3.测试综述 本轮测试持续将近 周，到目前为止（如果是功能测试则是指本轮次，如果是功能+验证测试 则是指本发布阶段）发现的BU（数据量________个，其中，重新开启：________ 个，未解决：_____ 个，已解决：____ 。（如果是功能+验证测试，则还需说明本轮次新发现的bug情况，如：本轮测试新发现的问题 有多少个？其中严重的有多少个？）从测试的角度给出该轮测试是否通过，是否需要做回归测试，或验证测试。 4.问题与建议
主要是在本发布阶段针对开发经理要求不测试且最终确实未测试，但是测试人员从质量的角度认为 需要测试的功能点做简要说明 总结项目测试过程，以及和开发人员交互过程中存在的问题，经验，也可以提出自己的一些改进建 议等 5.其他 （如果对应的测试申请单中既有功能测试类型，又有验证测试类型，那么只出功能测试报告即可, 同时该项 必填，需要在此附上本发布阶段的遗留问题清单以及本发布阶段新发现的重大 bug 清单；遗留 问题清单中如果不属本发布阶段测试范围的须在备注中说明） 5.1 5.2 5.3 质量风险［可选］ 遗留问题列表（本发布阶段发现的，以及前发布阶段延期至本阶段来修正的缺陷 ) 表10遗留冋题列表 重大bug 列表（指本阶段新发现的重大BUG 青单） 表11重大bug 列表
仓库管理系统c语言程序设计报告
————————————————————————————————作者：————————————————————————————————日期：
信息科学与工程学院 课程设计报告 班级：通信一班 姓名（学号）： 实验项目名称： c语言程序设计 实验室(中心)：信息科学与工程学院信息技术实验 室 指导教师：李益才 实验完成时间： 2013 年 6 月 28 日
序号项目标准 评分 1 系统演示（功能） （50%） 按要求完成系统功能且界面友好容错能力强（45-50） 按要求完成系统功能界面一般有较好的容错能力 （40-44） 基本完成系统功能有一定的容错能力（35-39） 基本完成系统功能（30-34分） 未完成系统功能或他人代做或抄袭（15） 2 课程设计说明书 （50%） 课程设计书各项目认真填写，具有清晰的设计思路及 软件测试结果分析（45-50） 课程设计书各项目认真填写，具有较为清晰的设计思 路并对软件测试结果进行了较为清晰的分析（40-44） 课程设计书各项目认真填写，设计思路正确（35-39） 课程设计书进行为较为认真的填写（30-34） 课程设计书有未完成项或各项填写不属实或他人代做 或抄袭（15） 教师签字总分 一、题目 仓库管理系统 二、功能描述 该系统将输入进系统的仓库中物品的基本信息（包括货号、名称、单价、库存数量、品牌）进行处理，可以进行： （1）、按物品价格降序输出、按库存数量升序排列。 （2）、修改制定物品的信息。 （3）、删除指定物品的信息。
（4）、在指定物品前或后再插入一个物品的信息。 （5）、统计同一种品牌的数量。 三、概要设计 系统功能模块图 四、详细设计数 据 按 序 输 出 修 改 特 定 物 品 的 信 息 删 除 特 定 物 品 的 信 息 插 入 物 品 信 息 统 计 指 定 品 牌 物 品 的 数 量 数 据 文 件 载 入 数 据 文 件 输 入 磁 盘 物品信息输入 退 出 系 统进入系统
魔方宝系统 软件功能测试报告 2017年10月
1.测试环境 2.问题统计 （说明：该报告为阶段性测试的统计报告，该报表统计的bug数量为：本发布阶段内第一份申请单提交日期为起，直至填写报告这天为止的BUG数量,如果以前版本中有问题延期至本发布阶段来修正，那么该缺陷也需要统计进来；如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的） 2.1按BUG状态统计(表格后面可以附上柱形图,以示更直观) 表3 按bug状态统计 3.测试综述 本轮测试持续将近_______周，到目前为止(如果是功能测试则是指本轮次，如果是功能+验证测试则是指本发布阶段)发现的BUG数据量____个，其中，重新开启：____个，未解决：____个，已解决：____个。（如果是功能+验证测试，则还需说明本轮次新发现的bug情况，如：本轮测试新发现的问题有多少个？其中严重的有多少个？）从测试的角度给出该轮测试是否通过，是否需要做回归测试，或验证测试。 4.问题与建议
总结项目测试过程，以及和开发人员交互过程中存在的问题，经验，也可以提出自己的一些改进建议等 5.其他 （如果对应的测试申请单中既有功能测试类型，又有验证测试类型，那么只出功能测试报告即可，同时该项必填，需要在此附上本发布阶段的遗留问题清单以及本发布阶段新发现的重大bug清单；遗留问题清单中如果不属本发布阶段测试范围的须在备注中说明） 5.1遗留问题列表(本发布阶段发现的，以及前发布阶段延期至本阶段来修正的缺陷) 表10 遗留问题列表 5.2重大bug列表(指本阶段新发现的重大BUG清单) 5.3质量风险[可选] 主要是在本发布阶段针对开发经理要求不测试且最终确实未测试,但是测试人员从质量的角度认为需要测试的功能点做简要说明
库存管理系统 专业：计算机科学与技术 班级：计科三<3>班 学号： 090601380 编写：▁▁XX▁▁2012年05 月25日审核：▁▁▁▁▁▁▁▁年▁▁月▁▁日批准：▁▁▁▁▁▁▁▁年▁▁月▁▁日 南京理工大学紫金学院
目录 1.1引言 1.1.1背景简介 (3) 1.1.2 读者对象 (3) 1.1.3参考文档 (3) 1.1.4名词与术语 (3) 1.2系统概述 1.2.1系统目标 (4) 1.2.2环境与工具 (4) 1.2.3系统功能性描述 (4) 1.3功能需求 1.3.1功能总图及其DFD图 (5) 1.3.2 系统初始化模块 (6) 1.3.3 物料出入库管理模块 (7) 1.3.4 库存物料定期盘点模块 (9) 1.3.5 数据查询模块 (10) 1.3.6 预警报告模块（含白盒和黑盒） (11) 1.3.7 月底结存模块 (14) 1.3.8 系统安全管理模块 (16) 1.4其他需求 1.4.1安全性需求 (17) 1.4.2可用性需求 (18)
1.1引言 企业信息化随着经济的发展已成为企业建设的成败关键，而生产和库存管理是企业信息化建设不可缺少的环节，库存管理系统的实现，将极大地提高生产管理人员和库存管理人员的工作效率，确保管理数据的及时、准确，实现生产数据和库存数据的规范化管理，为管理者提供直观的显示，为公司创造很大的经济效益，对推进物流信息化、规范化建设具有重要的作用和意义。 1.1.1编写目的 通过对用户需求的要求，以及该组织机构的分析，我们先后画出了DFD图、E-R图、关系模型、以及测试用例。通过对我们所做的需求分析和解决方案的整合，形成了此文档，其主要目的能够使用户更加明确、清晰的了解该系统的功用和特点。 1.1.2 读者对象 企业部门经理，仓库管理人员，系统管理人员以及相关人员。 1.1.3参考文档 本项目已经核准的计划任务书、合同。 1.1.4名词与术语 1)库存(inventory)：是仓库中实际储存的货物。可以分两类：一类是生产库存，即直 接消耗物资的基层企业、事业的库存物资，它是为了保证企业、事业单位所消耗的 物资能够不间断地供应而储存的；一类是流通库存，即生产企业的成品库存，生产 主管部门的库存和各级物资主管部门的库存。此外，还有特殊形式的国家储备物资，它们主要是为了保证及时、齐备地将物资供应或销售给基层企业、事业单位的供销 库存。 2)经济效益（economic benefit）：是通过商品和劳动的对外交换所取得的社会劳动节 约，即以尽量少的劳动耗费取得尽量多的经营成果，或者以同等的劳动耗费取得更 多的经营成果。经济效益是资金占用、成本支出与有用生产成果之间的比较。所谓 经济效益好，就是资金占用少，成本支出少，有用成果多。提高经济效益对于社会 等具有十分重要的意义。 3)管理(manage)：是社会组织中，为了实现预期的目标，以人为中心进行的协调活动。 它包括4个含义：1.管理是为了实现组织未来目标的活动；2.管理的工作本质是协 调；3.管理工作存在于组织中；4.管理工作的重点是对人进行管理。管理就是制定，执行，检查和改进。制定就是制定计划（或规定、规范、标准、法规等）；执行就 是按照计划去做，即实施；检查就是将执行的过程或结果与计划进行对比，总结出 经验，找出差距；改进首先是推广通过检查总结出的经验，将经验转变为长效机制 或新的规定；再次是针对检查发现的问题进行纠正，制定纠正、预防措施。 4)采购入库单(Purchase Storage Lists)：采购入库单一般指采购原材料验收入库时， 所填制的入库单据；企业一般指商品进货入库时，填制的入库单。采购入库单是企 业入库单据的主要部分，因此在本系统中，采购入库单也是日常业务的主要原始单 据之一 5)销售出库单(Sales Storehouse)：销售出库单是指产成品销售出库时，所填制的出 库单据。销售出库单也是企业出库单据的主要部分，因此在本系统中，销售出库单 也是进行日常业务处理和记帐的主要原始单据之一。
公司名称 QR-D-022 系统测试报告
1.引言 1.1编写目的 说明编写软件测试报告的目的 如：找出缺陷原因。对软件质量作出评价。 1.2背景 该项目的来源： 该项目的委托单位： 该项目的主管部门： 1.3定义 列出本测试计划中所用到的专门术语的定义和缩写词的原意。 如无特殊术语时本款可写为“无”。 1.4参考资料 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：a. 本项目的计划任务书、合同或批文；b. 项目开发计划；c. 需求规格说明书；d. 概要设计说明书；e. 详细设计说明书；f. 用户操作手册；g. 本测试计划中引用的其它资料、采用的软件开发标准或规范。 2.测试方法 列出系统测试所采用的方法，如功能测试、数据库测试、安装测试、安全性测试等。 3.测试机构和人员 本次测试由负责，测试人员有：。
4.测试结果 测试记录中错误点的比率： 此项内容参照测试计划中的评价内容填写。 详细测试记录见附件：《测试记录表》。 在此表中列出所有测试的功能名称，并在“是否通过”栏中对逐项功能标明是否通过，若通过，标识“√”，若不通过，标识为“×”。 5.测试记录分析统计。 可按《测试记录统计表》模板进行。 可用圆饼图显示各功能点的问题所占的比重。 6.评价 6.1软件能力 对软件的测试结果与功能需求作比较，如软件能力基本达到《需求规格说明书》规定的能力要求，但部分有计算错误，见1.7测试结果。 6.2缺陷和限制 对软件测试结果中的缺陷（或称为错误）加以总结，如×××功能在××操作中发现较大的问题，下一步准备改进，其它尚有部分错误。
武汉理工大学华夏学院 课程设计报告书 课程名称：.net课程设计 题目：超市库存系统的设计与实现 系名：信息工程系 专业班级： 姓名： 学号： 成绩： 指导教师: 2013 年 6 月 14 日
课程设计任务书 学生姓名：刘顺莉专业班级：软件1101 指导教师：苏永红工作单位： 设计题目：超市库存系统的设计与实现 初始条件: VS2005+SQLServer2005 要求完成的主要任务: 主要任务： 运用C#语言、VS2005+SQLServer2005开发环境设计一个超市库存系统，实现用户注册、用户登录、超市货物的分类、查询、增加商品信息、修改商品信息、删除商品信息、增加货物种类、修改货物种类和删除货物种类的功能，并要求相关信息能自动存储到数据库。 具体要求为： (1) 系统需求明确，要求使用.net技术、网页与数据库连接技术。 (2) 主页要求有用户登录显示，实现信息的查询、添加、删除等基本功能。 (3) 课程设计报告不能雷同，雷同者全部以0分记载。每个人需要检查设计的系统，设计报告文档，并提交纸质版的课程报告和电子版的系统设计资料，电子版资料包括：源程序，系统运行效果截图，电子版的资料以班为单位刻成光盘后由班长统一提交。 设计报告撰写格式要求： 1设计题目与要求 2 设计思想 3系统结构 4 数据结构的说明和模块的算法流程图 5 系统详细设计，内容包括各个模块的设计，数据库的设计，数据库连接设计。 6调试过程和运行结果及结果分析（其中包括网站各个模块的运行结果和结果数据 分析） 7 自我评价与总结 8 附录：程序清单，注意加注释（包括关键字、方法、变量等），在每个模块前加注释；时间安排 6月8日布置课程设计任务；分配题目后，查阅资料、准备程序； 6月 9～6月13 日上机调试程序、书写课程设计报告； 6月14 日提交课程设计报告及相关文档。 指导教师签字：2013年6月6日 系主任签字：2013年6月6日