软件系统测试工作总结精选2篇.docx
《软件系统测试工作总结精选2篇.docx》由会员分享,可在线阅读,更多相关《软件系统测试工作总结精选2篇.docx(10页珍藏版)》请在冰豆网上搜索。
![软件系统测试工作总结精选2篇.docx](https://file1.bdocx.com/fileroot1/2023-2/25/29e449d5-9bc3-49f0-8b9f-5c7b33677bc0/29e449d5-9bc3-49f0-8b9f-5c7b33677bc01.gif)
软件系统测试工作总结精选2篇
2019软件系统测试工作总结精选2篇
随着手机应用越来越广,APP也越来越多,这需要软件开发师多努力,同时也需要软件测试多次测试。
这里小编给大家带来的是20XX软件系统测试工作总结精选2篇,有兴趣的小伙伴可以进来看看,参考参考!
篇一
1、为什么要在一个团队中开展软件测试工作?
因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。
在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
2、测试能给你带来什么样的快乐?
测试可以给我带来很多快乐,如果测试出一个项目缺少东西,我会很高兴,因为我对自己的工作有了新的认识,也为公司做了效益;如果测试出一个项目没有问题,我也很高兴,因为同事们都在努力,大家都希望为公司做贡献,这就是一个很强大的团队,这是一件多么另人振奋的事情啊!
3、软件测试的目的?
测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷,通过修正种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
4、Alpha测试与beta测试的区别
Alpha测试在系统开发接近完成时对应用系统的测试;测试后仍然会有少量的设计变更。
这种测试一般由程序或测试员完成,不能由最终用户或其它人员完成。
Beta测试当开发和测试根本完成时所做的测试,最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其它人员完成,不能由程序员或测试员完成。
5、简述集成测试的过程
1)构建的确认过程。
2)补丁的确认过程。
3)Z34。
4)测试用例设计过程。
5)测试代码编写过程。
6)Bug的报告过程。
7)每周/每两周的构建过程。
8)点对点的测试过程。
9)组内培训过程。
集成测试过程:
集成测试计划->集成测试设计->集成测试实现->集成测试执行。
6、质量的八大特性是什么?
各种特性的定义?
1)功能性:
软件所实现的功能达到它的设计规范和满足用户需求的程度
2)性能:
在规定条件下,实现软件功能所需的响应时间和计算机资源(CPU、内存、磁盘空间和数据吞吐量)的使用程度
3)可靠性:
在满足一定条件的应用环境中,软件能够正常维持其工作的能力,在出现一些错误操作时,软件可以具有容错性,如果软件意外退出,重新启动后可以恢复最近的软件数据
4)安全性:
为了防止意外或人为的破坏,软件应具备的自身保护能力
5)使用性:
用户在理解、学习和操作软件的过程中的付出的努力的难易程度
6)维护性:
软件在运行维护过程中,如果出现了运行故障或者扩展新功能和性能,软件系统是否具有可分析性和良好的扩展性,重新设计后的软件的稳定性和可测试性
7)移植性:
软件从现有运行平台向另一个运行平台过度的适应程度和平台可替换性
8)重用性:
整个软件或其中一部分能作为软件包而被再利用的程度
7、系统测试计划是否需要同行审批,为什么
需要,系统测试计划属于项目阶段性关键文档,因此需要评审。
8、软件质量应该从哪些方面来评价?
可靠性、安全性、性能、易用性、外观、稳定性
9、系统测试包含哪些方面?
1.恢复测试、2.安全测试、3.强度测试、4.性能测试
10、区别阶段评审的与同行评审
同行评审目的:
发现小规模工作产品的错误,只要是找错误;
阶段评审目的:
评审模块阶段作品的正确性可行性及完整性
同行评审人数:
3-7人人员必须经过同行评审会议的培训,由SQA指导
阶段评审人数:
5人左右评审人必须是专家具有系统评审资格
同行评审内容:
内容小一般文档阶段评审内容:
内容多,主要看重点
同行评审时间:
一小部分工作产品完成
阶段评审时间:
通常是设置在关键路径的时间点上!
11、测试结束的标准是什么?
1.用例全部执行。
2.覆盖率达到标准。
3.缺陷率达到标准。
4.其他指标达到质量标准
12、制定测试计划之前需要了解什么问题?
1)软件测试计划的目的是什么?
是否所有人都知道?
他们同意这个测试计划过程吗?
2)测试的是什么产品?
是新程序还是维护升级的?
是独立程序还是由多个小程序组成的?
3)产品的质量目标是什么?
产品的功能需求和性能指标必须得到所有人的一致认可。
13、请详述设计测试用例的方法?
(只是列出一个测试用例思考的方向,具体设计靠经验)
①黑盒测试用例根据业务需求说明书来设计,分为:
等价划分法边界值分析法错误推测法因果图法逻辑覆盖法
②白盒测试用例通过研究代码与程序结构可以分为以下两种方式:
静态测试:
通过静态的检查程序代码、界面、文档中可能存在的错误的过程。
|-测试代码编写的规范性|-测试界面|-测试相关需求说明和用户手册是否符合实际要求
动态测试:
通过路径和分支测试。
测试用例主要根据以下六种覆盖测试方法设计
|-语句覆盖|-判定覆盖|-条件覆盖|-判定/条件覆盖|-组合覆盖|-路径覆盖
14、比较负载测试,压力测试,容量测试和强度测试的区别
负载测试:
在一定的工作负荷下,系统的负荷及响应时间。
通过逐步增加系统负载,最终确定在满足性能指标的情况下,系统能承受的最大负载量的测试。
强度测试:
又称疲劳强度测试,在系统稳定运行的情况下能够支持的最大并发用户数,持续执行一段时间业务,通过综合分析,确定系统处理最大工作量强度性能的过程。
一定负荷条件下,在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试:
容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。
容量测试是面向数据的,并且目的是显示系统可以处理目标内确定的数据容量。
压力测试:
通过逐步增加系统负载,最终确定在什么负载条件下系统性能将处于崩溃状态,以此获得系统能提供的最大服务级别的测试。
15、测试人员需要何时参加需求分析?
如果条件允许,原则上来说是越早介入需求分析越好。
因为测试人员对需求理解越深刻,对测试工作的开展越有利,可以尽早的确定测试思路,减少与开发人员的交互,减少对需求理解上的偏差。
16、软件的缺陷等级应如何划分?
严重:
1.由于程序所引起的死机,非法退出2.死循环3.数据库发生死锁4.因错误操作导致的程序中断5.功能错误6.与数据库连接错误7.数据通讯错误。
较严重:
1.程序错误2.程序接口错误3.数据库的表、业务规则、缺省值未加完整性等约束条件。
一般性:
1.操作界面错误(包括数据窗口内列名定义、含义是否一致)2.打印内容、格式错误3.简单的输入限制未放在前台进行控制4.删除操作未给出提示5.数据库表中有过多的空字段。
建议:
1.界面不规范2.辅助说明描述不清楚3.输入输出不规范4.长操作未给用户提示5.提示窗口文字未采用行业术语6.可输入区域和只读区域没有明显的区分标志。
17、你自认为测试的优势在哪里?
优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。
18、你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决。
1)如果不是错误则应该主动承认不是缺陷。
2)如果是需求不明确的则应和开发加强沟通补充需求。
3)如果和开发争论不休应该邀请上级判断。
19、您认为做好测试计划工作的关键是什么?
1)明确测试的目标,增强测试计划的实用性
2)坚持“5W”规则,明确内容与过程
3)采用评审和更新机制,保证测试计划满足实际需求
4)分别创建测试计划与测试详细规格、测试用例
20、风险和问题
◆市场的压力
◆测试时间不够
◆测试资源的及时到位
◆测试人员的技能需求
◆开发进度的变化,需求的变更
◆开发部门的版本控制
◆短时间上线。
这个是已经定好的,没有参考测试人员的意见。
时间短往往不能得到充分的测试,测试策略必须根据可用的时间进行调整。
尽快指出这样的问题非常重要,只有这样才能调整时间表,确定快速开发的风险并制定降低风险的策略。
◆新的设计过程。
引入新的设计过程会增加风险,新的设计过程包括新的工具和设计技术。
如果采用新的技术,能否像我们预期的那样运转,都存在很大的风险
◆复杂性。
我们应该进行一些分析工作来确定哪个功能最复杂,哪个功能最容易出错,错误会对系统的哪些地方造成重大的影响。
◆使用频率。
软件最常用功能中隐藏的问题可能给用户造成严重的损失。
◆不可测试的需求。
不可测试的需求会对系统的成功造成巨大的威胁。
如果测试组在需求阶段就验证了需求的可测试性,对需求进行了评审,那么此类问题会减少多。
篇二
随着科技的进步,手机款型可谓日新月异,功能也越来越丰富。
相应的,越来越多的手机应用软件也伴随着手机功能的多样化应运而生。
面对种类众多的手机应用软件,该如何进行测试,测试时又需要重点关注什么呢?
本文档结合本人在产品手机项目测试过程中的经验,浅谈下手机应用软件测试相关知识。
对于产品的手机项目(应用软件),主要是进行系统测试。
而针对手机应用软件的系统测试,我们通常从如下几个角度开展:
功能模块测试,交叉事件测试,压力测试,容量测试,兼容性测试,易用性/用户体验测试等。
1、功能模块测试:
首先应分析功能模块的功能项,测试每个功能项是否能够实现对应的功能。
一般根据测试用例(TestCase)或软件本身的流程就可以完成基本功能测试(相对简单,故障也较容易发现、解决)。
2、交叉事件测试:
又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。
例如通话过程中接收到短信或闹铃触发,应用软件运行过程中插拔充电器等。
执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。
另外,还需要注意各交叉事件的优先级别,检验系统是否能依据各事件的优先级别依次进行处理。
不能因执行优先级别高的事件而导致优先级较低的事件吊死。
交叉事件测试非常重要,一般能发现应用软件中一些潜在的问题。
另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题(这个主要针对手机应用软件支持语言自适应功能),这一点通常会被测试人员忽略。
3、压力测试:
又叫边界值容错测试或极限负载测试。
即测试过程中,已经达到某一软件功能的最大容量、边界值或最大的承载极限,仍然对其进行相关操作。
例如连续进行短信的接收和发送,超过收件箱和SIM卡所能存储的最大条数,仍然进行短消息的接收或发送,以此来检测软件在超常态条件下的表现,进而评估用户能否接受。
对手机可以施加的压力测试类型主要有:
●存储压力:
由于手机采用的是栈式存储,所以当一个存储块满了之后,如果程序员不做相应处理或者处理不好的话,很容易造成其他存储区被擦除,从而在UI上出现问题(比如其他功能无法正常使用,出现异常)。
●边界压力:
边界处理一直是程序员最容易忽略的地方。
●响应能力压力:
有时候某个操作可能处理的时间很长,在处理期间如果测试者再不断地进行其他操作的话,很容易出现问题。
●网络流量压力:
执行较大数据流量的功能的同时,再进行其他功能操作,使得网络流量始终处于很高的状态(如视频通话时再进行短信等其他功能操作),验证各功能是否依然能正常工作,是否存在因网络流量瓶颈而引起某功能异常。
压力测试用手工测试可能很繁锁,可以考虑自动化测试。
遗憾的是,目前还没有较为大量使用的工具,一般都是由开发人员配合开发出的工具,或者高级的测试人员编写出的脚本。
4、容量测试:
即存储空间已满时的测试,包括手机用户可用内存和SIM卡的所有空间被完全使用的测试。
此时再对可编辑的模块进行和存储空间有关的任何操作测试,如果软件在极限容量状态下处理不好,有可能导致死机或严重的花屏等问题的出现。
5、兼容性测试:
也就是不同品牌、款型的手机(针对目前我们产品来说,主要是针对不同品牌、款型的手机上的测试),不同网络,不同品牌和不同容量大小的SIM卡之间的互相兼容的测试。
以短消息为例:
中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息,需要验证显示和回复功能是否正常等。
再比如,应用软件分别在NokiaN80、N93手机上运行,各功能是否均能正常使用,界面是否均显示正常等。
6、易用性/用户体验测试:
易用性(Useability)/用户体验是指在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力,是交互的适应性、功能性和有效性的集中体现。
易用是对终端软件(推而广之是交互类软件)最基本、最重要的要求。
不好用的软件很难吸引用户,更别提提升用户对软件的忠诚度了。
易用性体现在:
所见即所得、一用便知、一学就会,方便快捷的完成预期功能。
易用的软件能让一个新用户快速学习、使用我们的软件,并在使用软件过程中体现我们的贴心服务,超出用户预期的体现是我们追求的目标。