如何写论文?写好论文?免费论文网提供各类免费论文写作素材!
当前位置:免费论文网 > 工作总结 > 其他工作总结 > 软件测试总结

软件测试总结

来源:免费论文网 | 时间:2016-09-11 09:15:31 | 移动端:软件测试总结

篇一:软件测试总结报告

1 引言

1.1 编写目的

编写该测试总结报告主要有以下几个目的

1.通过对测试结果的分析,得到对软件质量的评价

2.分析测试的过程,产品,资源,信息,为以后制定测试计划提供参考

3.评估测试测试执行和测试计划是否符合

4. 分析系统存在的缺陷,为修复和预防 bug 提供建议

1.2 背景

1.3 用户群

主要读者:***项目管理人员

其他读者:*** 项目相关人员。

1.4 定义

基本功能点测试:等价类划分法、边界值法、错误推测法、场景法

业务流程测试:根据业务逻辑,构建测试数据,执行业务流程,查看执行结果与预期是否一致 界面易用性测试:根据界面测试规范及日常使用习惯,提出软件的非功能实现问题

回归测试:对已修复的问题,根据测试出该错误的用例,重新执行该用例,验证问题是否真正被修复,

以及是否又引起了其它错误

1.5 测试对象

对综合管理系统进行全新测试,主要进行功能测试、系统测试

1.6 测试阶段

第一阶段:对主业务逻辑及功能进行测试

第二阶段:对所有业务逻辑及功能进行深入测试

第三阶段:回归测试

1.7 测试工具

BugFree缺陷管理工具

1.8 参考资料

《***功能描述》

《***数据字典》

《***测试计划》

《***测试用例》

《***项目计划》

2 测试概要

***系统测试从 2012年7月25日到2012年10月12日基本结束,历时近70个工作日。后续还有一些扫尾的工作,又增加一些工作时日。是一项花费大量人力物力的项目。

***通过BugFree缺陷管理工具进行缺陷跟踪管理,在bugfree中有详细的测试用例以及用例执行情况记录

2.1 进度回顾

2.2 测试执行

此次测试严格按照项目计划和测试计划执行,按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略,在测试执行中都有体现,在测试执行过程中,依据测试计划和测试用例,对系统进行了完整的测试、

2.3 测试用例

3 测试环境与方法

3.1 软硬件环境

3.2 测试方法和工具

4 测试结果

4.1 Bug 引入阶段

4.2 Bug 引入原因

5 测试覆盖分析

1.此次测试的重点在在于对功能的测试,特别是V2.0新增功能的测试;

2. ***完成在常见的操作环境下的测试,因此具有良好的兼容性。

3.本次此时的目的除了基本的功能测试外,重点突出对系统易用性的测试,力图使系统更加的人性化,操作更加简单,易懂。

6 测试结果和建议

6.1 测试结论

1. ***的测试工作已基本结束,功能测试目标也已完成,剩下部分报表的设计需要继续完善。

2.本次测试从功能性,易用性,兼容性等多个方面进行测试,力图在满足客户需求的基础上操作更加简捷,人性化。

6.2 改进建议

1.测试过程中遇到的最大问题是需求的不确定性和需求的变更。前期由于开发人员和测试人员对一些需求的理解不一致,或是在需求文档中需求的定义不明确,大家根据自己的理解开展工作,继而在后期工作中产生一些不必要的bug;除此之外,由于在前期,没有对客户的需求进行较为准确的界定,在开发过程中,客户提出一些新的要求,而这些要求和其他功能具有关联性,需求做改动,开发和测试也进行改动,比较显著地例子是在开发中后期要求在一个关联性强的表中增加一个字段,从而引起一系列重复的测试。因此我认为在开发前期要反复确定需求,并制定需求变更标准,避免在开发过程中出现重复,返工的现象。

2.本次测试由于主要是手工测试,因此未能实现对一些功能的进行大量数据操作的测试

3.系统目前比较明显的缺陷是报表打开速度比较慢,这个严重影响了系统的性能,是需要研究改进的部分。

篇二:软件测试小结

软件测试小结

一、 测试基础

测试模型(V模型)

测试的目的:发现程序中错误,是为了证明程序有错,而不是证明程序无错。 测试的原则:

1测试贯穿各个阶段; ○2测试用例应由输入部分与之对应的输出结果组成; ○3程序员应该避免检查自己的程序; ○4一定要注意测试中的错误集中发生现象; ○5对测试错误结果一定要有一个确认的过程; ○6制定一个严格的测试计划; ○7回归测试的关联性一定要引起充分的注意; ○8妥善保存一切测试过程文档。 ○

测试方法:

1白盒测试 ○

2黑盒测试(包括等价法、边界值法、场景分析法、错误推测法、因果图等) ○

测试流程:

分析测试需求→制定测试计划→设计测试方案→编写测试用例→执行测试用例→验收测试→书写测试报告

测试计划:引言(目的、背景、范围、定义、参考资料)、测试内容(测试功能清单)、测试规则(进入准则,暂停/退出准则、测试方法、测试手段、测试要点、测试工具)、测试环境(硬件环境、软件环境、特定测试环境要求)、项目任务(测试规划,测试设计,测试执行准备,测试执行,测试总结)、实施计划(工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件)、风险管理

二、Linux操作

用户的创建与删除

useradd -g test -d /home/wy -s /bin/bash wy

+ 主要参数

-d:指定用户的家目录

-g:指定用户所属的群组

-m:自动建立用户的登入目录

-s:指定用户所使用的shell

userdel(删除用户帐号)

语法:userdel [-r][用户帐号]

参数:

-r:删除用户登入目录以及目录中所有文件

补充说明:userdel可删除用户帐号与相关的文件。若不加参数,则仅删除用户帐号,而不删除相关文件

文件的属性与权限的修改

+ chgrp:改变档案所属群组

chgrp 群组名档案名

+ chown:改变档案拥有者

chown [-R] 用户名称档案或目录

chown [-R] 用户名称:组名档案或目录

-R:进行递归变更,亦即连同次目录下的所有档案都变更

目录管理

+ cd(变换目录)

cd:本命令用于改变当前的工作目录

cd/tmp 进入/tmp 目录

cd .代表此层目录

cd ..进入上级目录

cd ~ 或cd返回家目录

cd -返回前一个工作目录

+ pwd(显示目前所在的目录)

+ mkdir(创建目录)

-m:配置文件案的权限

-p:递归建立目录

+ touch(创建文件)

touch 文件名

+ cp(复制档案或目录)

+ 几个重要的参数

- i :在覆盖已存在文件时进行询问,若回答y 则覆盖,其他则中止

- p:连同档案的属性一起复制过去

- r :将一个目录下的所有内容复制到另一目录中

+ mv(移动档案与目录,或更名)

+ -f:若目标档案已经存在时,不会询问而是直接覆盖

+ -i:若目标档案已经存在时,会询问是否覆盖,若回答y 则覆盖,其他则中止 + rm(移除档案或目录)

+ -f : 删除时系统不会出现警告信息

+ -i : 在除去档案之前均会询问是否真要移除

+ -r : 递归删除

+ rmdir(删除空的目录)

当目录中没有任何内容时才可以使用此命令删除目录,若目录中尚有内容则无法删除此目录

+ ps(查看进程)

+ -e或-A 显示出正在运行的所有进程

+ -f

+ -l

+ -u

+ -g 显示所有信息 显示较长,较详细的PID的信息 显示指定用户进程 显示指定组进程

+ ps aux 或ps –lA 观察系统的所有进程

管道命令

压缩与打包

+ tar(将多个文件打包成一个大档案

)

+ -c:建立打包档案

+ -v:显示正在处理的文件名

+ -f:文件名,指定要被处理的档名

+ -x:抽取文件

+ -t:查询打包档案的内容

VI编辑命令()

三、测试用例

定义:测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。

特征:

1最有可能抓住错误的; ○

2不是重复的、多余的; ○

3一组相似测试用例中最有效的; ○

4既不是太简单,也不是太复杂。 ○

测试用例设计原则

测试用例的代表性:能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的输入数据、操作和环境设置等;

测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的预期结果;

测试结果的可再现性:即对同样的测试用例,不同的系统的执行结果应当是相同的。

测试用例设计的方法

篇三:手机软件测试的经验总结

手机软件测试总结!!

对一个测试人员来讲,至少要懂一点GSM标准协议的基础知识,懂软件工程的则更好,能更清楚地预知哪一块容易出问题, 发现问题后,能分析产生问题的原因,这样就不是一种简单的黑盒操作了。

测试方向:

1. 验证各种功能都已正常实现,如:

1)电话簿中新增、编辑、查找、删除、复制、移动、自定义铃声、图片和短片、群组等;

2)各种输入法的切换和相应的字符都能正确输入;

3)照相机、录音机、播放器、FM Radio;

4)短信、彩信、聊天室的输入、发送和接收等;

5)蓝牙传输;

6)附加功能;

7)MMS、Email、WAP等网络服务功能;

8)通话音质、音效及信号强弱等。

9)各种附加功能的验证。

2. 边界值、极限测试,主要包括:

1)时间设置的最大和最小时间点的跳转;

2)电话本中最大记录条数的添加、查找、编辑和删除;

3)各编辑界面,最大字符数的输入、编辑和删除;

4)SMS,MMS最大字符数的输入、浏览、发送和接收;

5)SMS, MMS最大记录条数的浏览、存储、转存和删除;

6)计算器最大值和最小值的运算;

7)通话记录中最大记录条数、最长通话时间、最频繁的接听和挂断等功能的验证;

8)播放器中最大记录数的添加、删除;播放最大时长;录音、录像的最大时长;照相机的最大图片设置和使用,最多照片的存储。

3. 交叉测试,主要包括:

1)各种编辑器中的浏览、编辑、删除等与短信、彩信的接收之间的冲突;与来电的冲突;与低电压的冲突;与闹铃的冲突。

2)输入法之间的切换,各种字符的交叉输入;

3)通话与短信、彩信等编辑、发送和接收之间的冲突;与低电压的冲突;与闹铃的冲突。

4)通话时,蓝牙耳机、手机端和耳机之间的切换使用。

4)多媒体中,播放、录制、收听等与来电的冲突;与低电压的冲突;与闹铃的冲突。

5)来电的图片、铃声、振动等反复更改,再次来电是否与预设相符。

6)蓝牙传输与播放、来电、来短信或彩信、响闹、低电压等之间的冲突处理;

4. 在正向测试过程中,功能如果都已经正确实现,要逆向破坏性的反复操作,以致使软件出现问题为目的,(侧重于压力测试)。

5. 其他,主要包括:

1)耳机的接听、挂断;拔插耳机与手机端之间的切换;

2)蓝牙的接听、挂断;与手机端之间的切换;

3)充电的效率和时长;

4)USB传输及充电;

5)界面显示及提示信息;

6)功能和流程设计是否符合用户使用的习惯;虽不是问题,可提出合理的改善意见和建议。

7)按键。

以上只是一些常识性的测试点,一个优秀的测试人员,首先具备一种极强的责任感,视发现问题为自己的使命;要有很大的耐心,可能发现一个问题,

需要不厌其烦、多次反复操作,才能找到最准确的操作路径(问题发生,一般都是必然的);在验证功能的过程中,要设计自己的思路,想方设法让它出错,始终坚信不是没有问题,只是自己没有发现。

熟能生巧,仅此而已。 测试用例编写和执行,适用于正规的大公司的做法,每一个版本安排一些测试人员仔细过测试用例,主要也是验证其基本功能是否都已正确实现为目的,可避免疏漏,从整体上有一个可靠的数据,可掌控该版本存在多大的风险;对测试生手来讲有用,可以帮助他们打开思路;对熟手是一种束缚和制约;所以,执行测试用例,选择生手;编写用例,要选用有丰富测试经验的熟手。

手机软件测试的经验总结

1.在提交高通前务必要检查文档与实际程序的表现是否相同,比如说,增加了密技功能,在文档中就要有相应的说明。

2.在模拟器上图像处理速度较快,所以不会出现游戏中移动的图像变模糊的现象,但是由于手机的分辨率相对低,所以一般在模拟器显示正常的速度,到了手机就应该让开发人员适当调慢,否则将会出现移动物体变模糊不能清晰辨认的情况。

3.有些游戏使用了很多的图片资源,当在两个界面之间(例如在主菜单界面和帮助界面之间,主界面菜单是由许多图片组成的,帮助界面是一个html文件的浏览显示),连续按若干次使其在两个界面之间连续切换,会出现图像重叠现象,其原因是手机的CPU处理速度跟不上刷新速度,而且主界面的图片资源一直没有释放,导致图像的残留。一般可模拟Grinder把这些类似的问题测出来。

4.是否正确处理来电。如果没有适当正确的来电处理,有些来电会使游戏画面变乱,有些直接退出,甚至死机。Brew程序员往往会在来电处理后的恢复中忘了对游戏音乐的处理,比如说原先选择了关闭音乐的,来电处理后音乐又自动开始播放了。有时候需要模拟两个或以上的连续的来电以发掘程序深层的逻辑错误,这些错误大多是来电处理后的恢复过程的错误。另外短信,电量不足等一些事件警告的出现也有可能导致程序出错,也要作出相应的处理。 5.注意确保说明和帮助的完整清晰,检查提示信息,确保在游戏中出现的文字的正确拼写,没有错别字。要尽量用敬称“您”而不用“你”。

6.标题,菜单等的文字显示要尽量用小字体,尽量缩短文字,能用简短文字说明清楚的就不要用长句,例如“按2,4键可以左右移动图片”就可改成“按2,4键左右移动图片”,或者甚至改成“按2,4键移动图片”。因为不同的手机显示屏幕宽度不一样,在一款手机上显示正确不代表在其他款式都能正确显示,然而用小字体,短句子就能适应大多数手机的屏幕宽度。

7.线程的处理,有些游戏设有多个线程,如果没有处理好线程的调用释放问题的话,就很可能出现线程争用的问题。例如一个宠物游戏,宠物死亡后,会调用一个新的线程循环播放哀吊音乐,有些程序员由于粗心大意忘记了释放这个线程,当重新开始游戏时,就会出现这个线程播放的音乐与游戏过程的背景音乐交替播放的情况。

8.文件处理。当涉及文件读写操作的时候,要特别注意测试文件操作带来的内存问题。比如说,有些游戏需要用文件记录游戏最高分或分值等,要注意测试第一次运行程序时的退出操作(此时没有最高分记录或其他分值记录),程序是否申请了文件指针或文件资源而没有释放。如果是的话,则会导致退出时的内存错误。另外对于Brew,应用程序的文件包中不得包含零字节的文件,每个文件至少有一个字节,同时还要求不能包含无用的文件或文件夹,目的是节省手机上有限的存储资源。

9.颜色的搭配,有些背景色跟文字或图片的颜色搭配在模拟器可以较清晰的显示出来,但是到了手机由于其分辨率问题就不那么明显了。颜色搭配要以清晰美观为基础,还要适当考虑游戏的种类,用户心理等问题。

10.用模拟器模拟网络不通的情况。目的是测试软件的网络连接,网络资源请求,缓冲区存储等模块的性能,看看内存是否有正确释放等。可以通过断开网络连接的方法模拟手机网络不通的情况,具体就是把本地连接的状态设成禁用或者直接拔掉网络连接线。

11.数据请求或传输等需时较多的过程要确保有提示界面,最好有动画显示数据在传输过程中,请用户耐心等待。另外要注意在这个过程中对重复按键予以忽略,因为等待时间过长或响应迟钝时,用户趋向于重复按手机按钮。

12.不要忽略了对后台数据正确性的测试。输入特殊字符或异常字符,看后台有没有相应的容错处理(当然这些也可由手机端处理)。多个客户端同时发出请求,测试后台的多线程处理能力,看能同时处理多少用户的同时请求,平均响应时间是多少,是否在可接受范围内。

13.来电,短信,电量不足等一些事件警告的出现也有可能导致程序出错,也要作出相应的处理。有些网络程序由于设置了数据通讯时不处理来电,这时候就要在低电量情况下测试,用电量不足的警告事件来触发程序的suspend和resume处理事件,看是否做了恰当的处理。

以上经验同样适合开发人员参考,以便尽量避免类似问题的出现。


软件测试总结》由:免费论文网互联网用户整理提供;
链接地址:http://www.csmayi.cn/show/40534.html
转载请保留,谢谢!
相关文章