你说的都队——测试总结

测试的目的与目标

　　在此系统进行初步实现之后，开始进行对系统进行测试，找出系统中存在的Bug，通过测试，用提交的Bug报告来为以后软件的改进提供标准和参考，能够在以后的系统改进中找到依据。

测试后的软件各模块基本功能可以顺利进行，尽可能的提高软件的健壮性。

测试方法

• 从是否关心软件内部结构和具体实现的角度划分：黑盒测试和白盒测试；

• 从是否执行程序的角度：静态测试和动态测试；

• 从软件开发的过程按阶段划分有：单元测试、集成测试、确认测试、系统测试、验收测试、回归测试、Alpha测试、Beta测试；

单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块（这里所说的程序模块在Java中一个模块就是一个方法），进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

集成测试 (组装测试、联合测试），通常在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：

• 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

• 一个模块的功能是否会对另一个模块的功能产生不利的影响；

• 各个子功能组合起来，能否达到预期要求的父功能；

• 全局数据结构是否有问题；

• 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

确认测试（Validation Testing），确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

系统测试（System Testing），是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较， 发现软件与系统的定义不符合或与之矛盾的地方。

验收测试（Acceptance Testing），在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

测试用例

由于功能模块较多，测试内容篇幅较长，所以在本论文中只介绍登入系统的测试用例，表6.1是本系统会员登入的测试表，从测试的结果来看与期望结果完全相同。

登录系统测试用例

功能特性	用户登录验证
测试目的	验证是否输入合法的信息
测试数据	用户名称：1111 密码：1111
测试内容	操作描述	数据	期望结果	实际结果	测试状态
1	输入用户姓名，按“登陆”按钮。	用户姓名：1111， 密码为空	显示警告信息“用户名或密码误!”	显示警告信息“用户名或密码误!”	与期望结果相同
2	输入密码，按“登陆”按钮。	用户姓名为空，密码：1111	显示警告信息“用户名或密码误!”	显示警告信息“用户名或密码误!”	与期望结果相同
3	输入用户姓名和密码，按“登陆”按钮。	用户姓名：1， 密 码：1	显示警告信息“用户名或密码误!”	显示警告信息“用户名或密码误”	与期望结果相同
4	输入用户姓名和密码，按“登陆”按钮。	用户名：1111，密 码：1111	正确登入到会员操作界面	正确登入到会员操作界面	与期望结果相同

发布功能

功能特性	发布失物或招领信息
测试目的	验证是否能正常发布失物或招领信息
测试数据	失物信息一则、招领信息一则
测试内容	操作描述	数据	期望结果	实际结果	测试状态
1	登陆后，首页点击“捡到东西了”，不填写任何信息，发表	无	出现错误提示	提示“物品名为必填项”	与期望结果相同
2	点击“捡到东西”，填写符合规定的数据，发表	无	出现发布成功提示	无提示，但发布成功	缺少提示
3	点击“丢东西了”，不填写任何信息，发表	无	出现错误提示	提示“物品名为必填项”	与期望结果相同
4	点击“丢东西了”，填写符合规定的数据，发表	无	出现发布成功提示	无提示，但发布成功	缺少提示

搜索功能

功能特性	搜索网站信息
测试目的	验证是否能进行信息的搜索，以及结果是否正确
测试数据	钱包、饭
测试内容	操作描述	数据	期望结果	实际结果	测试状态
1	搜索框输入“钱包”，点击搜索	“钱包”	出现带“钱包”的数据，“钱包”特殊标注	出现乱码	影响功能的错误
2	搜索框输入“饭”，点击搜索	“饭”	出现带“饭”的数据，“饭”特殊标注	出现乱码	影响功能的错误

在线聊天室测试

功能特性	多用户在线聊天
测试目的	验证是否能正常实现在线聊天功能
测试数据	无
测试内容	操作描述	数据	期望结果	实际结果	测试状态
1	点击“在线交流”按钮	无	打开多人在线聊天室	打开多人在线聊天室	与期望结果相同
2	在文字输入框中输入文字	大家好，我来了！	文字输入框显示相应文字	显示“大家好，我来了！”	与期望结果相同
3	输入文字后，点击“发送”按钮	无	在聊天界面显示之前输入的文字	在聊天界面显示之前输入的文字	与期望结果相同
4	点击“发送”按钮旁边的三角形，修改发送快捷键	无	出现快捷键修改选项	无响应	功能缺失

个人中心测试

功能特性	修改和查看个人信息
测试目的	验证功能是否正常
测试数据	无
测试内容	操作描述	数据	期望结果	实际结果	测试状态
1	登陆后，点击页面上用户名字的按钮	无	进入个人信息页面	进入个人信息页面	与期望结果相同
2	修改个人参数界面，修改参数	电话：13344445555 邮箱: aaa@aaa.com	提示修改成功	提示修改成功	与期望结果相同
3	修改密码	密码： 12345678	提示修改成功，并要求重新登陆	提示修改成功，仍为登录状态	存在逻辑问题
4	进入“帖子信息”	无	显示所有发布的贴子信息	显示所有发布的贴子信息	与期望相同
5	查看登录日志	无	显示所有的登录信息	显示所有的登录信息	与期望相同

后台管理测试

功能特性	管理后台
测试目的	测试管理员是否能进行后台管理操作
测试数据	账号：admin 密码：admin
测试内容	操作描述	数据	期望结果	实际结果	测试状态
1	点击后台登陆，输入账户密码，点击登录	账号：admin 密码：admin	进入后台管理界面	显示登陆成功，进入管理界面	与预期相同
2	测试用户管理界面功能	无	所有功能都能实现	所有功能实现	与预期相同
3	测试物品管理界面功能	无	所有功能都能实现	所有功能实现	与预期相同
4	测试权限管理界面功能	无	所有功能都能实现	所有功能实现	与预期相同
5	测试菜单管理界面功能	无	所有功能都能实现	所有功能实现	与预期相同
6	测试系统设置界面功能	无	所有功能都能实现	所有功能实现	与预期相同

测试结论

把开始的代码写得越好，它出现的错误也就越少，你也就越能相信所做过的测试是彻底的。系统化测试以一种有序方式设法探测潜在的麻烦位置。同样，毛病最可能出现在边界，这可以通过手工的或者程序的方式检查。自动进行测试是最理想的，用得越多越好，因为机器不会犯错误、不会疲劳、不会用臆想某此实际无法工作的东西能行来欺骗自己。回归测试检查一个程序是否能产生与它们过去相同的输出。在做了小改变之后就测试是一种好技术，　能帮助我们将出现问题的范围局部化，因为新问题一般就出现在新代码里面。

测试和排错常常被说成是一个阶段，实际上它们根本不是同一件事。简单地说，排错是在你已经知道程序有问题时要做的事情。而测试则是在你在认为程序能工作的情况下，排错是在你已经知道程序有问题时要做的事情。而测试则是在你在认为程序能工作的情况下，为设法打败它而进行的一整套确定的系统化的试验。

Edsger Dijkstra有一个非常有名的说法：测试能够说明程序中有错误，但却不能说明其中没有错误。他的希望是，程序可以通过某种构造过程正确地做出来，这样就不再会有错误了，因此测试也就不必要了。这确实是个美好生活的目标，但是，对今天的实际程序而言，这仍然还只是一个理想。所以应该集中精力讨论如何测试，如何才能够更快地发现程序错误，如何才可以使得工作更有成效、效率更高。