| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
zhuzhengy
12年前发布

软件测试工程师工作总结

 

1.、为什么要在一个团队中开展软件测试工作?

因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。

2.测试能给你带来什么样的快乐?
    测试可以给我带来很多快乐,如果测试出一个项目缺少东西,我会很高兴,因为我对自己的工作有了新的认识,也为公司做了效益;如果测试出一个项目没有问题,我也很高兴,因为同事们都在努力,大家都希望为公司做贡献,这就是一个很强大的团队,这是一件多么另人振奋的事情啊!

27、文档测试要注意什么?

文档的读者群、文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性、样例与示例、文档的语言

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人左右 评审人必须是专家 具有系统评审资格

同行评审内容:内容小 一般文档 <  40, 代码 < 500

阶段评审内容: 内容多,主要看重点

同行评审时间:一小部分工作产品完成

阶段评审时间: 通常是设置在关键路径的时间点上!

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.、风险和问题

◆市场的压力◆ 测试时间不够◆ 测试资源的及时到位◆ 测试人员的技能需求◆ 开发进度的变化,需求的变更◆ 开发部门的版本控制◆ 短时间上线。这个是已经定好的,没有参考测试人员的意见。时间短往往不能得到充分的测试,测试策略必须根据可用的时间进行调整。尽快指出这样的问题非常重要,只有这样才能调整时间表,确定快速开发的风险并制定降低风险的策略。◆ 新的设计过程。引入新的设计过程会增加风险,新的设计过程包括新的工具和设计技术。如果采用新的技术,能否像我们预期的那样运转,都存在很大的风险◆ 复杂性。我们应该进行一些分析工作来确定哪个功能最复杂,哪个功能最容易出错,错误会对系统的哪些地方造成重大的影响。◆ 使用频率。软件最常用功能中隐藏的问题可能给用户造成严重的损失。◆ 不可测试的需求。不可测试的需求会对系统的成功造成巨大的威胁。如果测试组在需求阶段就验证了需求的可测试性,对需求进行了评审,那么此类问题会减少很多。

21.、软件都有多少种分类?

  固件、支持软件、系统软件、应用软件

22.、你认为软件测试过程中较常见的困难是什么?如何有效克服这些困难? (根据自己实际测试中遇到的情况来写的)

?Bug的重现问题:有些Bug只是偶尔出现的,根本就不知道具体需要什么条件          才能重现Bug.

?解决方法:将不能重现的Bug,利用截图的方式记录下来。并说明一系列的操作步骤

?Bug的更新:旧的Bug修改好之后,很多时候会引发更多Bug的出现。

?解决方法:对更新的功能模块重点的测试之后,再重新测试和更新的功能密切的模块,会不会产生新的Bug.

?与开发人员的沟通和对业务流程理解的分歧,经常缺少需求文档

?解决方法:根据需求说明书和Bug情况,多多和开发人员进行交流

23.、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

软件测试计划是指导测试过程的纲领性文件,对测试工作的计划和安排包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)

24.、怎样保证你所负责的模块通过了测试

首先是了解用户的需求,设计好的测试用例,严格的进行用例的评审,认真的执行测试用例,对自己提交的Bug进行详细的描述。

反复测试,增强测试的准确性,通过冒烟回归随机测试挖掘缺陷提高测试工作质量,把各个模块整体运行发现未曾出现的错误,完善测试用例

25.、您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?

性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能,性能测试常常需要和强度测试结合起来,并常常要求同时进行软件和硬件的检测。性能测试主要的关注对象是响应时间,吞吐量,占用内存大小(辅助存储区),处理精度等。

26.、怎么编写案例

案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。

27.、怎么才能够全面的测试到每一个点

测试的全面性主要需要在设计测试计划的时候考虑,从测试策略,产品需求等等多个角度考虑从而定义全部的测试点。

28.、常用的测试工具及分类

功能测试工具 — QTP;性能测试工具 — LoadRunner;测试管理工具 — TestDirector

白盒测试工具 — NunitJunitC++TestJTestBoundsCheckerLogiscope

29.、软件测试与调试的关系?

1) 测试条件已知,规程可定义,结果可预知2) 测试可以计划,过程可控3) 测试是检验,调试是推理过程4) 测试表明程序失败,调试表明正确5) 测试可不了解设计细节6) 测试由非设计人员完成7) 测试有理论依据8) 测试可自动化

30.、给你一个网站,你如何测试?

1.查找需求说明、网站设计等相关文档,分析测试需求。

2.制定测试计划,确定测试范围和测试策略,一般包括以下几个部分:功能性测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试。

3.设计测试用例:

功能性测试:1链接测试。链接是否正确跳转,是否存在空页面和无效页面,是否有不正确的出错信息返回等。2提交功能的测试。3多媒体元素是否可以正确加载和显示。4多语言支持是否能够正确显示选择的语言等。

界面测试:1页面是否风格统一,美观2页面布局是否合理,重点内容和热点内容是否突出3控件是否正常使用4对于必须但为安装的空间,是否提供自动下载并安装的功能5文字检查

性能测试:压力测试、负载测试、强度测试

数据库测试:要具体决定是否需要开展。数据库一般需要考虑连结性,对数据的存取操作,数据内容的验证等方面。

安全性测试:1基本的登录功能的检查2是否存在溢出错误,导致系统崩溃或者权限泄露3相关开发语言的常见安全性问题检查,例如SQL注入等。4如果需要高级的安全性测试,确定获得专业安全公司的帮助,外包测试,或者获取支持

兼容性测试:根据需求说明的内容,确定支持的平台组合。1浏览器的兼容性2操作系统的兼容性3软件平台的兼容性4数据库的兼容性

4.开展测试,并记录缺陷。合理的安排调整测试进度,提前获取测试所需的资源,建立管理体系(例如,需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容)。

5.定期评审,对测试进行评估和总结,调整测试的内容。

 

31.、您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

有使用过LoadRunner,该工具能够录制测试人员的操作步骤,然后对这个操作步骤模拟出多个用户来播放出来。1.Visural User Genertor创建脚本,选择协议,录制操作,编辑操作。2.中央控制器(Controller)调度虚拟用户。创建场景,选择脚本,建立虚拟用户,设计shedual,设置ip spoofer3.运行脚本。分析shedual4.分析测试结果。

32.、怎样做好测试计划

1.理解系统。从整个系统的高度了解被测系统必须满足的功能和非功能性需求。利用涉及整个系统的文档,形成对系统的整体了解。

2.及早介入。为了深入了解项目,测试人员应该在系统的开始阶段介入,可以增加对客户需求,客户问题,潜在风险,以及最重要的功能方面的理解

3.测试期望。程序员的期望是什么?客户的期望是什么?销售对测试的期望又是什么?测试目标必须是绝对的,以免说不清楚是否达到目标。

4.吸取教训。把以前工作中学习到的经验教训运用过来,对确定测试策略很有作用。

5.工作量大小。完成测试需要多少工作量?需要多少人员?

6.技术选择。系统会采取什么技术?系统会采用什么架构?这些信息有助于确定测试策略和测试工具。

7.时间表。系统开发和测试分配的时间有多长?截止日期是什么时候?

33.、您是否了解以往所工作的企业的软件测试过程?如果了解,请试述在这个过程中都有哪些工作要做?分别由哪些不同的角色来完成这些工作?

软件测试部门配合系统分析人员软件需求分析讨论,并根据需求说明书制定《项目测试计划》,编写测试用例,建立测试环境。软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试,负责软件问题解决过程跟踪,负责软件开发文档开发工作的规范化及管理开发部门的产品文档,制作用户手册及操作手册,负责产品的上线测试,监督软件开发过程的执行,提高产品质量。需求人员连同系统分析人员&测试人员开会讨论需求。系统分析人员写出需求分析说明,并连同系统分析人员&测试人员&需求人员开会讨论可行性。系统分析人员写出详细设计说明书,程式人员编码,给出系统流程图。交与测试人员,测试人员给出Bug统计表。

34.、系统测试阶段低级缺陷较多怎么办?

公司有预测试这个流程,会在开展测试活动之前对主要功能点的正常流程做一个测试,以判断这个版本是不是可测试版本,如果低级缺陷比较多,严重阻碍测试执行的话,我们会打回开发部,不执行测试。

35.、缺陷流落到客户那里怎么办?

我们公司会尽可能的避免这种情况的出现,让软件缺陷在内部得到解决,万一版本上线了才发现有问题,我们也会及时派技术人员在最短的时间内做出修改,把客户的损失降到最低。

36.、代码会审是什么?

对代码的一个评审的过程,发现一些最基本的错误,方式是静态的代码走读方式,在一些大型软件的设计过程中,还是必不可少的。

37.、请问功能测试和性能测试的区别是什么?(只总结了两个方面,有其他的自己补充)

①测试目的:

?功能测试:检查实际软件的功能是否符合用户的需求,测功能是不是全部实现,某个实现是不是有BUG。主要为了发现以下几类错误:A、是否有不正确或遗漏的功能?B、功能实现是否满足用户需求和系统设计的隐藏需求? C、能否正确接收输入?能否正确输出结果?

?性能测试:验证软件质量的三个质量特性,可靠性,正确性和效率。主要是测试产品的健壮性

②测试方式:

   ?功能测试:按照系统需求说明书和测试用例,对产品的功能一步步进行测试。找出产品功能是否全部实现

   ?性能测试:一般都使用性能工具对产品的健壮性进行评估。通过创建场景和虚拟用户来模拟真是环境,进行压力测试和负载测试。

38.、状态为已修改的缺陷 实际没有修改怎么办?

加强项目质量管理,提高项目执行能力。如果测试人员发现了这样的问题,首先要弄清楚是什么原因导致这种情况,最终还是要督促开发人员,修改掉这些问题。如果是不能重现的问题或者是老版本中遗留下来的问题不能修改的 要做好标示。

39.、性能测试什么时候开始最合适

一般在功能测试最后阶段执行 因为功能走通了 性能才有意义 总之性能测试要根据用户实际性能指标来操作 是一个很重要的测试活动 要根据软件的属性以及它的实际情况来制定策略

40.、回归测试中 未解决的缺陷如何处理

实际项目中 也会因为种种原因 出现最后一轮测试结束了 还有一些缺陷没有解决 那么对于问题的不同 我们有不同的解决方式:严重性问题:必须解决,不允许上线;功能性问题:可以考虑在后续版本中解决;一般性问题:可以不解决或者升级的时候解决。

41.、集成测试通常都有那些策略?

1)在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;

2)各个子功能组合起来,能否达到预期要求的父功能;

3)一个模块的功能是否会对另一个模块的功能产生不利的影响;

4)全局数据结构是否有问题;

5)单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。

42.软件测试的对象

答:软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。

需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应成为软件测试的对象。

43.什么是UML

答:Unified Modeling Language

它是一种用于描述,构造软件系统以及商业建模的语言。简单的理解就是它可以以一种直观的方式表示出一个系统的各项内容。

 

44.、什么是测试策略

  测试策略描述测试工程的总体方法和目标 主要包括以下三个方面:

  1 确定的测试技术和工具

  2 制定测试启动 停止 完成标准

  3 风险分析和应对方案

其目的 是为我们更好的写出高质量的用例 提供支撑

45. 软件测试按过程分为三个步骤

     单元测试:单元测试又称模块测试,是针对软件设计的最小单位 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

     集成测试:在运行(可能是不完整)的应用中保证软件单元被结合后能正常操作的测试执行的阶段

     系统测试:当应用作为整体运行时的测试执行阶段

46.       软件测试员和组长的职责分工

普通测试员:

    创作相关的测试计划和测试案例

    识别可自动测试的区域

    参与组内的测试计划和测试案例以及测试脚本分析工作

    手动或自动测试

    按照需求规格说明查证并验证各项功能

    发现并报告bug,跟踪其状态

    初步评估bug对产品其他部分的影响

 

 测试组长:

    确定测试的策略

    参与对整个产品的完整测试计划的制定

    参与并管理测试

    评估bug对用户的影响

    跟踪关键bug状态

    管理测试工作和对象的资源

    参与面试新人

    交流状态和存在问题,并驱动问题的解决

    促进组内的交流

47.  什么是bug

   软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题。

   常见的软件Bug分为以下三类:

    没有实现的功能

    完成了用户需求的功能,但是运行时会出现一些功能或性能上的问题

    实现了用户不需要的多余的功能

 

48.什么是CMM

             CMMCapability Maturity Model,即能力成熟度模型

   它是一个分 5 级的、可以描述结构完善程度的模型,用它来说明所交付的软件的效能。 

     49. 您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么?

         尽量能有面对面的沟通,如果做不到,那么尽量能直接通过电话沟通,如果只能通过Email等非及时沟通工具的话,强调必须对特性的理解深刻以及能表达清楚。

       一是真诚,二是团队精神,三是在专业上有共同语言,当然也可以通过直接指出一些小问题,而不是进入BUG Tracking System来增加对方的好感。

     50. 你们以前的测试流程是怎样的?

         明确需求——测试计划——制定测试策略和测试用例——搭建测试环境、执行测试用例、提交缺陷报告——对测试过程和版本质量评估得出测试总结报告——最后验收测试

      51. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试:把测试对象当成一个黑盒子,测试人员完全不考虑逻辑结构和内部特性,只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。

白盒测试:把测试对象当成一个透明的盒子,允许测试人员利用程序内部逻辑结构及相关信息,设计或选择测试用例,对程式所有逻辑路径进行测试。

单元测试:白盒测试的一种,对软件设计中的单元模块进行测试。

集成测试:在单元测试的基础上,对单元模块之间的连接和组装进行测试。

系统测试:在所有都考虑的情况下,对系统进行测试。

验收测试:第三方进行的确认软件满足需求的测试。

52. 您以往的工作中是否曾开展过测试用例的评审工作?如果有,请描述测试用例评审的过程和评审的内容。

 

53. 软件本地化测试和功能测试都有那些方面要注意?

     本地化就是将软件版本语言进行更改,比如将英文的windows改成中文的windows就是本地化。

     本地化测试过程中的测试工作集中在:

    受本地化影响的方面,如 UI 和内容

    区域性或区域设置特定的、语言特定的和地区特定的方面

    基本功能测试

    在本地化环境中运行的安装和升级测试

    根据产品的目标地区计划应用程序和硬件兼容性测试。

   54. 什么是软件质量?

    高质量的软件是适当的、无错误的,能在预算内按时交货,满足需求/或期望,并且是可维护的。所以,质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的影响。对一个软件开发项目来说,客户”的范围很广,包括最终用户、客户所接受的测试者、与客户合同有关的官员、客户管理、开发机构的管理者/会计/测试人员/销售人员、未来的软件维护工程师、股票持有者、杂志专栏记者,等等。每一类客户对质量”都有自己的倾向性 会计部门判断质量会从其收益来考虑,而最终用户则重视友好的用户界面和没有错误。

 

 55 为什么软件会有毛病?

     1.交流错误或者没有进行交流,需求不明确

     2. 软件的复杂性  编程错误 

    3. 需求变更   客户恐怕不明白改变需求的影响,也许是知道但依然需要变更 ── 会导致重新设计、重订工程进度表、对其他项目的影响、已完成的工作需要重做或者放弃、对硬件需求的影响等等。如果在项目中出现许多小的改变或一个大的改变,在项目各部分中出现已知或未知的相关的问题,可能会相互影响并导致出现问题。而且,不断地变更也会增加软件的复杂性,可能会导致错误的出现。这样就会影响技术人员的积极性。在一些快速变化的商业环境里,持续变更需求的影响是致命的。在这种情况下,管理者必须知道它的危险性。质量保障和测试工程师必须与此相适应,并安排持续的广泛的测试,以克服不可避免产生的问题。

  4. 时间压力

     因为有许多猜测成分,软件开发项目的进度很难安排得理想。当最后期限快到的时候,压力逐渐增大,错误随之产生

 5. 自负心理、 代码文档质量差、 软件开发工具

 56.  什么是验证、评价、预排 、检查?

ü  验证 (verification) 涉及了回顾和会议,以评估文档、计划、代码、需求和说明书。可以通过检查表、调查表、排练、和检查会来进行。

ü  评价 (validation) 则指在检察完成之后的实际测试。术语“IV”和“V”分别代表验证和评价。

ü  “预排”是一个非正式的会议,用来进行评估和信息交流。通常不需要或者只需很少一点准备。

ü  检查比预排更正式一点,通常有 3-8 个人参加会议,包括一个仲裁者 (moderator)、读者 (可以是作者或者任何评论者)、一个记录员作记录。典型的检查对象是一个文件,例如需求说明或者测试计划,目的在于发现问题和查找遗漏,而不是去对任何东西进行实际的修改。会议的参加者应当有准备,应当通读文件,大多数的问题会在准备的过程中被发现。检查会的结果应写成书面报告。对检查会进行全面准备是困难而艰苦的工作,但它是保证质量最有用的方法。在检查过程中,最有经验的雇员的作用就向‘大哥哥’一样,他们的技能也许不大显眼,但对任何软件开发机构是最重要的,这是因为预防错误要比发现错误在费用方面更加有效。

 

 

57.  介绍一下整体项目流程。

  我们公司的测试流程是围绕着测试的五个阶段展开的,测试计划、设计测试、执行测试、评估测试、验收测试。只是在不同的阶段有自己的一套做法。在接到项目单后,我们会召开一个项目开工会,要求各部门的相关人员都参与,会议我们主要是了解一下项目的背景、目的和资料。确定开始时间和结束时间和项目参与人员,测试部和开发商量好开发转系统测试时间,然后就进入计划阶段,开发和测试都有自己的计划,我们测试计划由测试经理编写,测试计划中主要是制定可采用的测试策略和范围,评估项目风险和规避措施,制定时间进度表,合理的分配人力、物力资源。之后进入设计阶段,设计阶段我们会参考开发的需求说明书、详细设计、概要设计去设计测试用例。接到开发的新版本就进入了测试执行阶段,首先是搭建测试环境,对软件实施预测试主要是验证系统的正常功能是否可用,然后就是系统测试,执行用例并提交缺陷报告,至于系统测试的轮次则要根据项目的复杂度和版本质量决定的。后期我们进入测试评估阶段对软件测试的过程和版本质量进行评估得出测试总结报告,最后我们进入测试验收阶段,我们会出用户手册、操作指引等文档,我们公司在每个阶段的输出都有一个评审阶段,保证输出有效,从而使测试顺利进行。

 

58.       在实际项目中你是如何做测试计划的

做测试计划前必须先了解项目的背景、目的等资料,然后合理划分测试范围,制定可采用的测试策略,评估项目中可能存在的风险和规避措施,制定好时间进度表,合理分配项目的人力、物力资源。

59.        你是如何制定时间进度表的

  首先确定三个大的时间段 项目开始时间 项目结束时间 开发转系统测试时间,在根据测试各个阶段的工作量和项目资源制定计划、设计、执行、评估、验收阶段的时间。设计和执行的时间一般较多。

60.        测试计划都包括那些项

项目基本信息 、总体测试策略、项目风险分析和规避措施、项目资源分配 (人力、物力、软硬件环境)、项目时间进度表、 系统优先级

61.        测试用例如何设计

     根据开发的需求说明书 、详细设计说明、和概要设计说明书设计测试用例遇见那里不明确的可以直接和开发人员沟通讨论。

    设计的时候我们会综合运用黑盒测试法,如运用等价类划分、边界值分析、错误推测法等。

62.        如何保证用例覆盖到罕见缺陷

1.预留足够的时间理解需求说明在设计用例

2.采用评审和更新机制,保证每一步的输出都是有效的,从而保证测试顺利进行。

3.对覆盖不全面的或是没有覆盖到的,在版本间歇期追加测试用例

63.  缺陷处理流程!

1.      测试员提交新的缺陷入库设置状态为 New

2.      由高级测试人员验证缺陷,如果是缺陷则提交给项目经理设置为(Open)分配给开发部修改,并将修改后的缺陷设置为(Fixed,如果不是缺陷则直接拒绝(Decline

3.      对于不能够立即解决的缺陷一般要开会议讨论则设置状态为“延期“(Derlend

4.      最后由测试员从新检查修改后的缺陷。不是则直接关闭(Closed

63.        测试用例包括那些项

     基本信息、用例编号、严重级别、缺陷描述、操作步骤

64.        开发人员修复缺陷后,如何保证不影响其他功能

重新执行用例、看是否出现错误结果。并对周围的一些相关功能点追加新的测试用例。

65          测试总结报告包括那些项

   主要有对测试过程和版本质量的评估,并有一些质量建议。还有一些数据,如用例总数,执行数量等。

65.        针对逻辑性较强的功能点你该如何设计测试用例???

66.        测试工作进行到一半是,发现时间不够,你如何处理

1.可以加班加点,加派测试人员并征用有经验的技术员

2.可以挑选优先级别高的用例先执行。

67. 怎样保证你所负责的模块通过了测试

1.        设计好的用例详细划分用例严重级别,先执行优先级别高的用例,保证规定的功能都正常工作。

2.      保证用例的覆盖率和用例的质量,最后能够符合用户需求说明书。并通过了内部评审。

67.        开发与测试的关系?

   测试是依托于开发的  测试同时也可以指导开发。

   开发和测试密切联系、相互依赖,开发为测试提供产品,测试负责检查开发的产品,测试和开发有共同的目的就是提高和改善软件质量

 

68.        如果你是测试组长你如何对项目及组员进行管理

1.强调合作和讨论,一切以圆满完成项目为出发点

2.合理分配项目资源和技术人员,明确职责合理分工。

3.表扬和惩罚制度

4.保护测试员

 

                                    

             

网站测试总结

1.功能测试
   
对于网站的测试而言,每一个独立的功能模块需要单独的测试用例的设计导出,主要依据为《需求规格说明书》及《详细设计说明书》,对于应用程序模块需要设计者提供基本路径测试法的测试用例。
链接测试
    链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面:
1
测试所有链接是否按指示的那样确实链接到了该链接的页面;
2
测试所链接的页面是否存在;
3
)保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。
   
链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试
Xenu------
主要测试链接的正确性的工具
可惜的是对于动态生成的页面的测试会出现一些错误。
表单测试
    当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
   
测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息
    B/S
结构实现的功能可能主要的就在这里,提交数据,处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能,编写可重复使用的脚本代码,可以在测试、回归测试时运行以便减轻测试人员工作量。
   
我们对UM子系统中各个功能模块中的各项功能进行逐一的测试,主要测试方法为:边界值测试、等价类测试,以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入,以确保测试输入的全面性。
Cookies测试
    Cookies
通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息
   
如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作而且对这些信息已经加密。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。
设计
语言测试
    Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如JavaJavaScript ActiveXVBScriptPerl等也要进行验证。
数据库测试
    Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL信息进行处理。
   
在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试
   
功能测试用到的测试工具有:黑盒自动化测试工具AutoRunner测试管理工具TestCenter
2
性能测试
   
网站的性能测试对于网站的运行而言异常重要,但是目前对于网站的性能测试做的不够,我们在进行系统设计时也没有一个很好的基准可以参考,因而建立网站的性能测试的一整套的测试方案将是至关重要的。
   
网站的性能测试主要从三个方面进行:连接速度测试、负荷测试(Load)和压力测试Stress.连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试,压力测试更像是恶意测试,压力测试倾向应该是致使整个系统崩溃。压力测试的区域包括表单、登陆和其他信息传输页面等。

  3. 可用性测试(导航、界面、内容、图形、)

  4.  兼容性测试(平台测试和浏览器的测试)

5. 安全性测试(有无安全漏洞、socket的信息完整性、用户名密码是否有效等)

实际测试题参考

1、测试项目:杯子
需求测试: 查看杯子使用说明书
界面测试: 查看杯子外观
功能度:用水杯装水看漏不漏;水能不能被喝到
安全性:杯子有没有毒或细菌
可靠性:杯子从不同高度落下的损坏程度
可移植性:杯子再不同的地方、温度等环境下是否都可以正常使用
兼容性:杯子是否能够容纳果汁、白水、酒精、汽油等
易用性:杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档:使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试:将杯子盛上水(案例一)放24 小时检查泄漏时间和情况;盛上汽油(案例二)放24 小时检查泄漏时间和情况等
压力测试:用根针并在针上面不断加重量,看压强多大时会穿透
跌落测试:    杯子加包装( 有填充物), 在多高的情况摔下不破损
震动测试: 杯子加包装( 有填充物), 六面震动, 检查产品是否能应对恶劣的铁路\ 公路\ 航空运输
测试数据:测试数据具体编写此处略(最讨厌写测试数据了)。其中应用到:场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出:
该期望输出需查阅国标、行标以及使用用户的需求

2、测试项目:电梯
需求测试:查看电梯使用说明书、安全说明书等
界面测试:查看电梯外观
功能测试:测试电梯能否实现正常的上升和下降功能.电梯的按钮是否都可以用;
        
电梯门的打开,关闭是否正常;报警装置是否可用,报警电话是否可用;
        
通风状况如何.突然停电时的情况;是否有手机信号;
比如说上升途中的响应。电梯本来在1楼,如果有人按18楼,那么电梯在上升到5楼的时候,有人按了10楼,这时候是否会在10楼先停下来;
电梯下降到10层时显示满员,此时若8层有人等待电梯,是否在8层停;
可靠性:门关上的一刹那出现障碍物,同时按关门和开门按钮,点击当前楼层号码,多 次点击同一楼层的号码等等;同时按上键和下键会怎样;
易用性:电梯的按钮的设计符合一般人使用的习惯吗.
用户文档:使用手册是否对电梯的用法、限制、使用条件等有详细描述
压力测试:看电梯的最大限度的承受重量.在负载过重时报警装置是否有提醒.是否有超时的反应;在一定时间内不断的让电梯上升,下降.最大负载下平稳运行的最长时间。

3测试题目:桌子

需求测试:查看国家相关标准。

功能:桌子是办公,或者放置用的,首先考虑桌子的面积大小是否适度.
界面:桌子的版面是否平滑,桌子有没有凹凸不平的地方

安全:桌子肯定有它的支撑点,若支撑点不稳,容易摔坏物品,使用起来也不方便.
易用:桌子的移动性好不.它的重量是否合适

可靠性:将桌子推倒后,再检查桌子是否很容易被损坏.
性能:将很重的物品放在桌子上,看它最大承受的重量是多少......

 

 

 

 本文由用户 zhuzhengy 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1340764241686.html
软件测试