后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
我要游戏策划
查看: 2818|回复: 11
请问各位高手应该从几个方面去寻找一款游戏的BUG
游戏类型：&　　设计类型：&
小弟明天去一家公司做游戏测试 各位高人能给一点意见吗 谢谢
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
游戏测试不是用来找BUG的吧。。。BUG很多方面是不可预知的。
游戏测试主要是体验，反馈的。找BUG当然也是，但是怎么可能一下子摸出来?
你说哪个游戏测试后没BUG的，多数还是玩家反馈。
最简单就是等别人报告有BUG，然后你去测试出来，汇报程序。
我也是新人，而且未入行，这是听别人说的。
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
……楼上的……那个别人在误导你吧……
楼主可以百度了解一下测试用例……虽然做过测试工作不过感觉自己也缺乏一个系统的概念，做时比较乱
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
2楼。。。你这种说法来看的话测试和QA都是混饭的了，或者就是这个研发有点闭门造车。如果作为程序和策划连可能出现bug的地方都不去顾及，那么这个人不会把工作做得好的
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
2楼你很勇敢
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
我公司的那个测试真是想打他，游戏没玩几个，正常设置的地方跟我反馈是BUG。可惜主管喜欢，说他办事认真，知道为公司省钱
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
LS的,你没发现,你说的最后那句话是很多做管理或老板都喜欢的?|
Re: Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
小明啊: Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
游戏测试不是用来找BUG的吧。。。BUG很多方面是不可预知的。
游戏测试主要是体验，反馈的。找BUG当然也是，...
听谁说的？抽他吧……
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
测试找BUG是主要的，体验反馈也是需要的，只不过体验应该有专门的部门，不知道LZ那公司有没
Re:请问各位高手应该从几个方面去寻找一款游戏的BUG
看以前的bug记录，看什么方面最容易出错。
看论坛，有什么报过的错误。
仔细核对文档，核查细节
玩家与玩家之间的交互很容易出问题
玩家的数据的转移时容易出问题，比如寄，给，交易，存放等。下次自动登录
现在的位置:
& 综合 & 正文
空间满问题，请各位高手帮忙啊！
原贴：/linux/dosc1/47/linux-323341.htm
空间满问题，请各位高手帮忙啊！
我的/usr分区空间满，结果出了问题。现在我即使已经移走了很多文件，空间占用率仍然是100％，而且ftp也不能用了，好痛苦啊！请各位大侠帮忙啊。 以下为df -k的输出结果： Filesystem
Used Available Use% Mounted on /dev/hda5
% / /dev/hda1
21% /boot /dev/hda3
% /home none
0% /dev/shm /dev/hda2
0 100% /usr /dev/hda7
/usr明明有空间，为什么总是100％。。。。。55
空间满问题，请各位高手帮忙啊！
1)虽然你移走一些文件，但是仍然有应用程序在产生新文件 2)是否inode满了
空间满问题，请各位高手帮忙啊！
空间满问题，请各位高手帮忙啊！
--& 第一种可能是不会的，因为你看used比总数少很多的，但是available死活都是0，我觉得可能是第二个原因。请问应该如何解决？ Filesystem
Mounted on
空间满问题，请各位高手帮忙啊！
没有人帮忙么？ 自己顶一下先。
空间满问题，请各位高手帮忙啊！
用 df -i 就可知道是否 inode 用光了，不用靠猜的...
Linux 每? file system 的 %5 空?是保留? root 使用的， 你自己算算
x 95% 是否差不多
要解?的?，先 du -hs /usr/* 抓出最吃空?的目?(如 /usr/mydir)，再加一?硬?(如 hdb5)，?之?移?去。 ?入?人模式，再跑： mkidr /mnt/tmp mount /dev/hdb5 /mnt/tmp mv /usr/mydir/* /mnt/tmp echo '/dev/hdb5 /usr/mydir ext3 defaults 1 2' &;&; /etc/fstab reboot
空间满问题，请各位高手帮忙啊！
好文，收藏之
空间满问题，请各位高手帮忙啊！
强人！！！
空间满问题，请各位高手帮忙啊！
如果是ext3，那log也会占空间的。重启一下试试。
空间满问题，请各位高手帮忙啊！
log也另行使用i-node么？
空间满问题，请各位高手帮忙啊！
不知道，不过前几天我的一块盘满了，删了好多文件也不行。当时是用来做服务器的，不能重启。有个兄弟说用sync试试，我试了，还是不行。没办法，只能用别的机器来用。过了几天重启一下，就多出来很多空间。
空间满问题，请各位高手帮忙啊！
log 一般不?放在 /usr 吧？
不管是 log ?是其它 file or directory ， 只要不是 hard-link ，都一定?消耗 i-node 。 在 ext2/ext3 的 fs type 下，其 inode ?量是有限的，一般在 mkfs 或 tune2fs 下指定/?更，但?是很不方?。 若 i-node 需求量大的?，?改用用 reiserfs 吧... ???效能及空?使用率上，均比 ext2/ext3 要好得多!
空间满问题，请各位高手帮忙啊！
我可能说的不太对，应该是ext3的journal吧。它好象是占文件系统的5%的。我也没具体看过。楼主可能试试。
空间满问题，请各位高手帮忙啊！
sync 只是? data ? cache/Memory ?? disk 而已， ? i-node 及 block 的使用??...
?有?器可?"永不??"的吧？ 除了?硬?，"??"也是一?很正?的理由啊... ?然，事先的??工作要做的?全一?。 ????子可看得出："??比??更重要!" ?痛??、?痛??，是最糟糕的管理模式。
p.s. 若你的 kernel 能支援 LVM ，那更是方便...
空间满问题，请各位高手帮忙啊！
空间满问题，请各位高手帮忙啊！
哦，对，q1208c兄说得，purge已经找到了***，ext3fs的日志确实要占用inode；而像xfs和ReizerFS不一样，他们是逻辑日志。 http://www-/developerWorks/cn/linux/filesystem/ext2/index.shtml http://www-/developerWorks/cn/linux/filesystem/l-fs9/index.shtml
编辑了：Reiserfs对一些小文件不分配inode。而是将这些文件打包，存放在同一个磁盘分块中。原来如此。
空间满问题，请各位高手帮忙啊！
文章?宗明??明了：--& ?在 usage 上?不?反映出?啦...
空间满问题，请各位高手帮忙啊！
谢谢网中人兄台。
空间满问题，请各位高手帮忙啊！
也多?你?大家引? IBM workshop 的那份文件。很值得"?"?哦... 然後?下面?些概念好好了解一下，比方?： block group, supblock, block group descriptor, inode, block, directory entries...
其中，df 是? block group descriptor 那?提取??的，而日?索引?是? super block ?取。 因此我才?日?不反映在 usage ... 希望大家知其然也知其所以然。
最後，一起共勉吧!Linux 很深澳，但也很多?趣!
空间满问题，请各位高手帮忙啊！
感觉各位高手的帮助，我在网上搜了一下，找到一篇和我的问题有点类似的文章，贴出来大家一起讨论一下吧
Bug#3055: filesystem corruption caused by process accounting
--------------------------------------------------------------------------------
To: linux-kernel@vger.rutgers.edu
Subject: Bug#3055: filesystem corruption caused by process accounting
From: Winfried Truemper &truemper@MI.Uni-Koeln.DE&;
Date: Sat, 18 May :33 +0200 (MET DST)
Cc: torvalds@cs.Helsinki.FI
Old-return-path: &iwj10@cus.cam.ac.uk&;
Reply-to: Winfried Truemper &truemper@MI.Uni-Koeln.DE&;, debian-
--------------------------------------------------------------------------------
Package: acct Architecture: i386 Version: 6.1-0
Short: If the "log-file" used by the Linux process accounting exceeds the free disk space, it is not possible to cleanly free up the space used by this file. This is companioned with a several 100-line long (=broken) output of "pstree".
This may not be a bug in Debian or a bug in "accton" but (likely) a bug in the kernel. [What relates to Debian: I suggest printing a big warning when turning process accounting on.]
Long: I'm running a quite large Linux-Box where the size of the file `/var/account/pacct' easily exceeds the avaiable space in `/var' (in my case, there are usally 56MB free).
The first time the problem occured was when trying out "userfs" and I thought it was related to this software but indeed it was only triggered by it (the included "ftpfs" calls "ftp" many times so the log-file of the process-accounting grows fast).
The second time the problem ("0 bytes free on /var") came up, I was not using "userfs" and I got the same symptons:
I deleted the file `/var/account/pacct' but the space did not
free up (around 50MB). `/var' remains "full" (0 bytes free
even for root).
And even worse, the space freed up by deleting huge files in
/var/log was consumed by a rate of several dozen kb/s. Bummer!
I was able to "umount" the filesystem containg `var' after
switching of process accounting which results in massive
filesystem-corruption. ("fsck" thought the filesystem was
clean so I had to convince it with '-f').
The third time it happend I thought to be smart and switched of process-accounting _before_ deleting the file but it didn't make any difference (and that's the current state of my machine).
Two related bugs:
- the output of "pstree" is totally messed up
- wtmp is broken (this one is easy and may be a result of the
full `/var'-partition).
Output of "pstree":
init-+-afpd
|-2*[getty]
|-inetd-+-3*[in.rshd---rimapd]
`-in.telnetd---bash
|-init-+-afpd
|-inetd-+-in.rshd---rimapd
`-in.telnetd---bash
|-init-+-afpd
The "recursion" (or how to call it) is 19 levels deep. The output of "ps" is not affected.
Here are the version-numbers of all (?) programms involved:
bash&; uname -a Linux ElFi 1.3.90 #1 Wed Apr 17 21:26:33 MET DST
Linux ElFi 1.99.2 #2-pre-2.0 Mon May 13 03:38:44 MET DST
bash&; mount -V mount: mount-2.5i bash&; ac -V ac: GNU Accounting Utilities (beta release 6.1)
bash&; rm --version GNU fileutils 3.12 bash&; mv --version GNU fileutils 3.12
bash&; tune2fs -V
bash&; tune2fs -V tune2fs 1.02, 16-Jan-96 for EXT2 FS 0.5b, 95/08/09 bash&; fsck -V Parallelizing fsck version 1.02 (16-Jan-96) bash&; fsck.ext2 -V e2fsck 1.02, 16-Jan-96 for EXT2 FS 0.5b, 95/08/09
bash&; pstree -V pstree from psmisc version 11
Here's a log of what I did:
bash&; cd account/ bash&; dir total 58123 -rw-r--r--
Apr 19 20:15 pacct -rw-r--r--
737100 Apr 19 06:15 pacct.0 -rw-r--r--
131146 Apr 18 06:17 pacct.1.gz -rw-r--r--
1027577 Apr 17 06:18 pacct.2.gz -rw-r--r--
1018483 Apr 16 06:15 pacct.3.gz -rw-r--r--
41218 Apr 15 06:15 pacct.4.gz -rw-r--r--
42538 Apr 14 06:15 pacct.5.gz -rw-r--r--
160368 Apr 13 06:15 pacct.6.gz bash&; rm pacct bash&; touch pacct bash&; dir total 3106 -rw-r--r--
0 Apr 19 20:15 pacct -rw-r--r--
737100 Apr 19 06:15 pacct.0 -rw-r--r--
131146 Apr 18 06:17 pacct.1.gz -rw-r--r--
1027577 Apr 17 06:18 pacct.2.gz -rw-r--r--
1018483 Apr 16 06:15 pacct.3.gz -rw-r--r--
41218 Apr 15 06:15 pacct.4.gz -rw-r--r--
42538 Apr 14 06:15 pacct.5.gz -rw-r--r--
160368 Apr 13 06:15 pacct.6.gz bash&; df Filesystem
1024-blocks
Used Available Capacity Mounted on /dev/sda2
/ /dev/sda5
/tmp /dev/sda6
/var /dev/sda3
/var/local/dos /dev/sda7
/usr /dev/sdb2
/homes/elfi /dev/sdb3
/tftpboot /dev/sdb4
61% /usr/local/wais /dev/sdc3
/vol/mi/www /dev/sdc2
/vol/mi/www/spinner_cache /dev/sdc8
/vol/mi/www/logs/spinner /dev/sdc9
/vol/mi/www/logs/counter calvados:/homes/calvados
/homes/calvados calvados:/var/local/public
/var/local/public sun1:/homes/sun1
/homes/sun1 sun1:/ElFi
/usr/local/mi2stn/sun1/ElFi sun1:/elfi
/usr/local/mi2stn/sun1/elfi sunkaw:/homes/sunkaw
/homes/sunkaw osi:/afs
bash&; tune2fs -l /dev/sda6 tune2fs 1.02, 16-Jan-96 for EXT2 FS 0.5b, 95/08/09 Filesystem magic number:
0xEF53 Filesystem state:
not clean Errors behavior:
Continue Inode count:
24576 Block count:
98288 Reserved block count:
4914 Free blocks:
0 Free inodes:
21955 First block:
1 Block size:
1024 Fragment size:
1024 Blocks per group:
8192 Fragments per group:
8192 Inodes per group:
2048 Last mount time:
Wed Apr 17 21:56:05 1996 Last write time:
Fri Apr 19 20:26:01 1996 Mount count:
7 Maximum mount count:
20 Last checked:
Wed Apr 10 09:27:27 1996 Check interval:
0 Reserved blocks uid:
0 (user root) Reserved blocks gid:
0 (group root)
[switched to a text-console, killed nearly everything and unmounted /var]
root@ElFi:~&; fsck /dev/sda6
[fsck says' its ok !]
root@ElFi:~&; fsck -f /dev/sda6
[do a `cat /proc/kcore' to have the same effect which I had]
9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -90064 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -9 -90 101 -9 -9 -9 -9 -90110 -9 -9 -9 -9 -9 -9 -9.
FIXED Free blocks count wrong for group 0 (0, counted=54).
FIXED Free blocks count wrong for group 1 (0, counted=4542).
FIXED Free blocks count wrong for group 2 (0, counted=6241).
FIXED Free blocks count wrong for group 3 (0, counted=6202).
FIXED Free blocks count wrong for group 4 (0, counted=6944).
FIXED Free blocks count wrong for group 5 (16, counted=4253).
FIXED Free blocks count wrong for group 6 (1, counted=7155).
FIXED Free blocks count wrong for group 7 (0, counted=6194).
FIXED Free blocks count wrong for group 8 (31, counted=6584).
FIXED Free blocks count wrong for group 9 (7, counted=4004).
FIXED Free blocks count wrong for group 10 (0, counted=2886).
FIXED Free blocks count wrong for group 11 (0, counted=12).
FIXED Free blocks count wrong (55, counted=55071).
/dev/sda6: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sda6:
files (4.6% non-contiguous),
blocks root@ElFi:~&;
[the nightmare ends here, phew!]
--------------------------------------------------------------------------------
Prev by Date: Xterminals, NFS, and tftp: need advice
Next by Date: Unanswered dpkg problem...
Previous by thread: Re: Xterminals, NFS, and tftp: need advice
Next by thread: Unanswered dpkg problem...
Index(es):
&&&&推荐文章:
【上篇】【下篇】