测试（Test）一词最早出于古拉丁字，它有“罐”或“容器”的含义。在工业生产和制造业中测试被当作一个常规的生产活动，它常常和产品的质量检验密切相关，测试的含义似乎是明确的：“以检验产品是否满足需求为目标”，其实在计算机软件领域则不然。
软件测试是软件开发中的重中之重，没有一点可以马虎的。“软件测试是为了发现错误而执行程序的过程”。这一测试定义明确指出“寻找错误”是测试的目的。因而，软件测试的目标涵盖了：
1） 测试是一个为了寻找错误而运行程序的过程；
2） 一个好的测试用例是很可能找到至今为止尚未发现的错误的测试；
3） 一个成功的测试用例是指揭示了至今为止尚未发现的错误的测试；
软件测试的目标是设计这样的测试，既能够系统的揭示不同类型的错误，并且耗费最少的时间和最少的工作量。
本文以一个新测试员的身份，就测试工作中如何设计一个好的测试用例做了一番讲述，并顺带谈了自己在这段实习和试用期中工作得到的心得，以求达到一种抛砖引玉的效果。不正之处，敬请指出。
我想先引出《谈 软 件 测 试 的 心 得》一文中给出的一些软件测试人员应具备的素质和测试技巧，我觉得它说得非常好，我也以此为标准不断在工作中去实践，去提高自己的能力和水平：
“
一、软件测试员自身素质培养
（1） 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在测试过程中不管遇到什么样的困难，我相信你一定能克服。
（2） 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。
（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。
（4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。
（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。
（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。
（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。
（8） 设身处地为客户着想，从他们的角度去测试系统。
（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。
（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。
（11） 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。
（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。
（13） 幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。
（14） 到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？
二、浅谈软件测试之技巧
软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。
（1）
（2）
（3）
（4） 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。 非法测试，例如在输入数字的地方输入字母。 跟踪测试，跟踪一条数据的流程,保证数据的正确性。 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
（5） 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。
（6） 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。
（7） 突发事件测试，服务器上可能发生意外情况的测试。
（8） 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。
（9） 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
（10） 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。
（11） 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。
（12） 系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。
（13） 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。
”
在admin系统中，有一个FTP模块，提供上传文件功能。根据需求，它所要实现的功能如下：
1)
2)
3)
4)
5) 省指定文件夹中(Temp)的文件只传送给中央； 中央指定文件夹中(Temp)的文件传给所有的省； 如果发送不成功，有重发机制； 发送出错要写日志，并提供查看日志文件； 有监控程序监控该主模块(FTP模块)的运行状态。
页面操作则是非常简单，跟其他系统提供的上传功能一样：选中要上传的附件，点击粘贴后再点击确定，返回文件上传成功页面。但后台操作远没有如此简单。记得一开始的时候，启动FTP模块，要先杀调该模块的已经启动的进程，由于没有提供进程控制脚本，每次都是查找该FTP模块启动的用户的所有进程，然后把进程杀掉。这里就有一个问题，由于进程无法表明是哪个应用软件，所以就不可避免的出现“误杀”的情况。记得最严重的一次是我的测试组长和我都是使用同一个系统用户admin去操作应用软件FTP和weblogic的进程，当时她想启动weblogic而我则是要杀掉FTP的进程。由于操作用户相同，所以我每次都是把属于该用户的进程杀掉，而我的组长每次都是很奇怪明明刚刚启动的进程怎么又没有了；而我也莫名其妙怎么进程老是不能全部杀尽？就这样我们两个人一个杀一个起忙得不亦乐乎，严重影响测试工作。结果不难想象被我的组长海K一顿，这就启发我：这样的启动FTP模块方式不好，用户易用性不高。于是找来开发人员，要求写出一个启动脚本和一个停止脚本，以后每次启动FTP的时候只需执行脚本就好了，又安全又方便。从这点我们也可以看出，连我们自己本身内部测试用都感到麻烦的东东怎么能拿到用户那边给用户使用呢？所以我们测试也要从软件按照维护人员的角度多考虑考虑我们的系统。
在测试的前段时间里，FTP的运行失败最大的原因是由于权限设置问题而造成的。由于我们运行的是UNIX系统，有严格的权限限制。对于文件的操作更是如此。这对于没有接触过UNIX系统的新手来说是一时半会不会理解过来的。比如，使用root用户创建文件夹，但你却使用user的用户来操作文件夹，显然权限不够，操作被拒绝。这样就无法讲文件夹里的文件及时发送出去并删除，造成数据堵塞，使得上传文件失败。所以在使用该模块的时候一定要注意权限，有两点注意：一是对进入系统的用户赋予相应的权限，unix 或者linux 操作系统对用户处理文件的权限设置比较多，因此运行FTP模块的用户权限不得小于在temp文件夹中创建文件的用户权限；(建议启动weblogic的用户和启动ftp模块的用户为同一用户)。二是对脚本要赋予可执行权限，比如使用UNIX命令chomod。以保证了FTP模块的文件可操作。经过这番折腾，对UNIX的认识是与日俱增，并学会了VIM－Unix 世界里极为普遍的全萤幕文书编辑器，简直太棒了。
接下来FTP运行良好，于是考虑压力测试了。通过和开发同学的讨论，再结合实际使用情况，我们整理了以下的测试计划：
1) 测试原理：
测试对象： 一个集团两个省
测试类型：
1） 持续性的压力测试，每隔定长传送30m 100m 300m的文件；
持续20－30次左右；
2） 突发性的压力测试：在第一次启动时，传送的文件很大 500－600m测试流程：
1）启动测试脚本；
2）观察测试结果；
3）记录测试数据；
4）分析ftp模块性能；
对于持续性的压力测试测试流程：
a）在集团和省服务器上安装测试脚本；
b）同时运行测试脚本；
测试脚本的安装：
1）在/opt/admin/ftp/目录下建立目录ftpTest；
2) 将脚本ftpTest.sh 拷贝至/opt/admin/ftp/下；
3）对该脚本赋予可执行权限；
4） 将ftpTest 目录下放置30-100M 的文件；
5） 在shell中按如下操作
crontab -e
10* * */opt/admin/ftp/ftpTest.sh
6）保存退出；
持续性压力测试我们采用自动测试，利用UNIX环境自动运行机制crontab（程序定时器）来运行脚本。crontab 是用来让使用者在固定时间或固定间隔执行程序之用，换句话说，也就是类似使用者的时程表。而crontab –e
10 * * * */opt/admin/ftp/ftpTest.sh的意思是在每个小时的第10分钟执行ftpTest.sh脚本。脚本实现的功能很简单，就是在定时的时间一到就把ftpTest文件夹里的文件往temp文件夹里拷贝一份，而FTP模块定时监控temp文件夹，发现有文件就往特定点发送文件，完成FTP功能。这样我让它运行几天，观察FTP模块是否工作正常，查看数据是否丢失。此时，我们组长又提出了新的要求，要求每隔10分钟压一次。但是，如何设置crontab每隔10分钟
执行某个程序呢？在查找有关UNIX资料后我找到了答案：
其实很简单
crontab -e
输入
0,10,20,30,40,50 * * * * /opt/admin/ftp/ftpTest.sh
在每个小时的0分，10分，20分，30分，40分和50分就运行ftpTest脚本，呵呵，这样不就每隔10分钟运行一次吗。我把这个方法告诉开发的同学，他也很高兴（本来他以为UNIX是做不到的）。
至于突发性的压力测试，我就采用了手动方法利用ftp工具一次性往UNIX服务器的temp文件夹里上传了大量的数据。然后启动FTP模块，看是否能够正常发送。
在测试这个模块的过程中，也考虑了一些异常情况的测试。如服务器磁盘满了。此时上传附件肯定是不会成功的，但我们要看的是程序对这个异常是怎么处理的，页面又作何处理（主要是查看页面的出错信息提示是否正确）？在这个过程中发现不少有趣的错误提示，都一一跟开发的同学讲了，大家就把该改的地方改了，杜绝隐患。
其实测试工作除了要有一定的知识外，更多的是在工作中积累下来的经验。比如，在检查涉及查询条件的地方时，要注意使用两种方法，一种是不带查询条件的测试，另一种是带查询条件的测试。具体为：在未输入查询条件的情况下进行查询以测试查询记录是否正常；在输入查询条件后进行查询以测试查询到的记录是否满足设定的条件。别小看这个，往往带条件查询时翻页可能会有问题。还有就是问问题，一定要讲究技巧，虽然说新手如初生牛犊不怕虎，但你问人家问题的时候你本身一定要对你想要获取什么信息心中有数。这点我最有感触，记得问过zhaohy一个地址链接问题，她反问我：“你说的是数据库地址还是应用地址？”我一时回答不上来。试问连你自己都不知道的问题别人又如何帮你解答？后来知道原来数据库地址和应用地址是两码事，不能认为数据库地址就是应用地址。因此，在问地址的时候要注意指出是数据库的地址还是应用的地址。还有就是在测试mPIC的时候，由于该系统需要其他系统的协助，比如MISC、portal等。我问过zhanggl最多的问题是为什么portal无缘无故就死了，上不了。但每次问的都不好，到后来他都恼火了“xPortal有很多网元的，你说哪一个啊！ 跟你说了这么多次，你为什么从来就不长记性呢？
”呵呵，这可是他的原话哦（xPortal确实有很多网元，比如WAP、3W、PDA）。经过这么几次后我问问题都会先问我自己，是否已经到了非要问别人不可的时候？你要问的问题已经准备好了吗？慢慢的，我发现我问的问题别人有时候也不是那么容易回答的了。
还有就是平时工作的积累，我来公司工作之前是真的一点都没有接触过测试工作，完全一个fresh man。头个月真的很辛苦，感到压力很大，很担心自己的工作做得不好。要知道，测试工作是一个team work，一个人的工作好坏会影响到整个团队的工作质量。所以我在工作的时候会把不懂的地方记下，再在以后的工作中寻找机会去弄懂。虽然在此后碰壁不少，挨训机会也多，但每次我都会记下我失误的地方，因为这就是我的经验，如同玩游戏一样，死得多经验值也多。有幸在zhaohy麾下当一名小兵，是我成长最快的时候。
