软件测试基本定义

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

测试的流程是什么样的?

参考答案:测试全项目周期流程:需求调研(性能测试需求分析),测试计划,测试用例,测试执行,提交测试报告;单一测试流程:执行用例,提交缺陷,返测缺陷,关闭或者重新打开缺陷;

什么是软件测试。

答:软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估,执行测试用例后需要跟踪故障,以确保开发的产品适合需求。为了发现程序中的错误而执行程序的过程。

软件测试的目的?

测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

软件测试原则和策略

软件测试原则:1、尽早和不断的测试。2、程序员应该避免检查自己的程序,软件测试应该由第三方构造。3、设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件。4、注意测试中的错误集中发生现象。5、对测试错误结果有确认过程。6、制定严格的测试计划,并把测试时间安排的尽量宽松。7、回归测试的关联性,原有功能过滤8、进行版本控制,制定变更测试文档的流程。

测试策略,在一定的软件测试标准、测试规范的指导下,依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合,需在测试计划文档中体现。

做好测试用例设计工作的关键是什么?

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题。

测试用例方法:等价类划分法、边界值分析法、错误推测法、因果图法

测试用例依据是用户需求规格说明书,详细设计说明书。

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

三、1.软件验收测试包括:_正式验收测试,alpha测试,beta测试。

2.系统测试的策略有:功能测试,性能测试,可靠性测试,负载测试,易用性测试,强度测试,安全测试,配置测试,安装测试,卸载测试,文挡测试,故障恢复测试,界面测试,容量测试,兼容性测试,分布测试,可用性测试

(有的可以合在一起,分开写只要写出15就满分哦)

3.设计系统测试计划需要参考的项目文挡有:_软件测试计划,软件需求工件和迭代计划。

4.对面向过程的系统采用的集成策略有:自顶向下,自底向上两种。

5.通过画因果图来写测试用例的步骤为:

(1)根据程序规格说明书描述,分析并确定因(输入条件)和果(输出结果或程序状态的改变),画出因果图。

(2)将得到的因果图转换为判定表。

(3)为判定表中每一列所表示的情况设计一个测试用例

5白盒测试有几种方法

答:总体上分为静态方法和动态方法两大类。

静态:关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

动态:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

6系统测试计划是否需要同行审批,为什么

答:需要,系统测试计划属于项目阶段性关键文档,因此需要评审。

9测试结束的标准是什么?

答:用例全部测试。覆盖率达到标准。缺陷率达到标准。其他指标达到质量标准。

10描述软件测试活动的生命周期?

测试周期分为计划、设计、实现、执行、总结。

计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;

设计:完成测试方案,从技术层面上对测试进行规划;

实现:进行测试用例和测试规程设计;

执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例。

总结:记录测试结果,进行测试分析,完成测试报告。

11软件的缺陷等级应如何划分?Bug

A类—严重错误,包括以下各种错误:

1由于程序所引起的死机,非法退出;2死循环;3数据库发生死锁;4因错误操作导致的程序中断;5功能错误;6与数据库连接错误;7数据通讯错误;8严重的计算错误;9逻辑不清楚,导致的存储查询等错误

B类—较严重错误,包括以下各种错误:

1程序错误;2程序接口错误;3数据库的表、业务规则、缺省值未加完整性等约束条件;C类—一般性错误,包括以下各种错误:

1操作界面错误(包括数据窗口内列名定义、含义是否一致);2打印内容、格式错误;

3简单的输入限制未放在前台进行控制;4删除操作未给出提示;5数据库表中有过多的空字段;

D类—较小错误,包括以下各种错误:

1界面不规范;2辅助说明描述不清楚;3输入输出不规范;4长操作未给用户提示;

5提示窗口文字未采用行业术语;6可输入区域和只读区域没有明显的区分标志

E类—测试建议

16一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

bug编号、bug发现人、bug发现时间、bug状态、bug严重程度、bug所属版本、bug所属模块、bug修改日期、bug简单描述、bug详细描述、bug相关附件、bug初步分析

高质量的BUG记录就是指很容易理解的BUG记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位

针对缺陷采取怎样的管理措施?

1.要更好的管理缺陷,必须引入缺陷管理工具,商用的或者开源的都可。

2.根据缺陷的生命周期,考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。

3.所有发现的缺陷(不管是测试发现的还是走读代码发现的)都必须全部即时的、准确的提交到缺陷管理工具中,这是缺陷提交的管理。

4.缺陷提交后,需要即时的指派给相应的开发人员,提交缺陷的人需要密切注意缺陷的状态,帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个:一个是让缺陷尽快解决;二是方便后面缺陷的分析(保证缺陷相关的信息准确,如龄期等),这是缺陷状态的管理。

相关文档
最新文档