测试路上,温和的坚持着,并且微笑...... 测试路上,我正在为下一个目标努力着,已经有近两年测试工作经验的我,每每看到测试工程师的职场规划,让我深刻的感悟到,要想让自己热爱的测试道路越走越宽,需要实践与理论结合,用理论规范实践,使实践更专业化;信息化时代,更加需要资源共享,思想交流,而我所学也来源于互联网上的前辈们,兄弟姐妹们. 所以在这个繁忙的工作学习里,在这个不断给自己充电的时间里,将自己的所学,所得,所感用博客的方式展现给大家,感谢在测试路上帮助过我的人,也希望能给需要帮助的人尽点微薄之力......

软件测试面试笔试题4

上一篇 / 下一篇  2008-06-19 17:32:09 / 个人分类:面试笔试锦集

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

1、在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
2、各个子功能组合起来,能否达到预期要求的父功能;
3、一个模块的功能是否会对另一个模块的功能产生不利的影响;
4、全局数据结构是否有问题;
5、单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。

16、一个缺陷测试报告的组成

测试软件项目名称,每个要测试软件项目都有唯一的名称,有的公司对项目还有特定的编号。

测试软件版本号,测试周期内,一般需要测试多个软件版本,报告错误时,一定要正确填写产生错误的软件版本号。

测试者名称,便于分清责任,便于管理。

测试日期与时间,便于分析和统计错误报告信息。

测试软件环境,包括操作系统其他必要的软件程序。

测试硬件环境,包括测试计算机和其他测试设备的配置信息。

错误描述,简明的描述错误的特征,便于查询和快速浏览。

错误标识编号 (ID#) ,每个错误都有一个唯一的标识编号,方便查询。

错误类型,根据错误类型,分配给适当的人员处理错误。

错误级别,错误的严重程度和处理的优先级,优先处理高级别的错误。

错误状态,错误状态表明错误是否已经处理和将怎样处理,根据错误状态,采用适当的处理方法。

错误处理者名称,便于分清责任,便于管理。

重现错误的操作步骤,便于重现错误,修复错误和验证错误。

期望的结果,描述满足设计要求的结果。

实际测试结果,描述实际测试后得到的结果。

必要的附图,便于确认错误的表现形式和错误位置。

测试者的建议等注释,便于错误处理者快速和正确处理错误

17、基于WEB信息管理系统测试时应考虑的因素有哪些?

一、功能测试

    1、链接测试 

    2、表单测试

    3、Cookies测试

    4、设计语言测试 

    5、数据库测试

二、性能测试

    1、连接速度测试 

    2、负载测试  

    3、压力测试  

三、可用性测试

    1、导航测试  

    2、图形测试

    3、内容测试

    4、整体界面测试

四、客户端兼容性测试

    1、平台测试   

    2、浏览器测试  

五、安全性测试

18、软件本地化测试比功能测试都有哪些方面需要注意?

 软件本地化测试的测试策略:

1.本地化软件要在各种本地化操作系统上安装并测试。

2.源语言软件安装在另一台相同源语言操作系统上,作为对比测试。

3.重点测试因本地化引起的软件的功能和软件界面的错误。

4.测试本地化软件的翻译质量。

5.手工测试和自动测试相结合

19、软件测试项目从什么时候开始?为什么?

  软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.

20、需求测试注意事项有哪些?

一个良好的需求应当具有一下特点:
完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性:每一项需求都必须准确地陈述其要开发的功能。

一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。

可行性:每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性:需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。

必要性:“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如Use Case或别的来源。

可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性:每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。

另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好(f i n e - g r a i n e d )的方式编写并单独标明,而不是大段大段的叙述。

21、简述一下缺陷的生命周期

    软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期:
1、发现——打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员;
2、打开——修复:开发人员再现、修复缺陷,然后提交测试人员去验证;
3、修复——关闭:测试人员验证修复过的软件,关闭已不存在的缺陷。

但是这是一种理想的状态,在实际的工作中是很难有这样的顺利的,需要考虑的各种情况都还是非常多的。

复杂的软件缺陷生命周期:
1、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,不是代码问题,就是设计需要修改;
2、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,以后修改的,就可以延期;
3、新建一个软件缺陷,这个软件缺陷是(open)状态,进行bug审查,实际没有这个bug,可以将其关闭;
4、新建一个软件缺陷,这个软件缺陷是(open)状态,看是否 清楚可重现,如果不能重现,就是缺少信息,需要返回到(open)状态;如果能够重现,就进行修正,修正后关闭,进行回归测试。
 软件缺陷生命


TAG: 面试笔试锦集

 

评分:0

我来说两句

Open Toolbar