Chinaunix首页 | 论坛 | 博客
  • 博客访问: 166791
  • 博文数量: 48
  • 博客积分: 1410
  • 博客等级: 上尉
  • 技术积分: 640
  • 用 户 组: 普通用户
  • 注册时间: 2008-12-22 15:54
文章分类
文章存档

2011年(2)

2010年(13)

2009年(30)

2008年(3)

我的朋友

分类: 项目管理

2009-09-06 10:01:57

1.您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?
2.您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(如功能测试、性能测试……)
3.解释下什么是黑盒测试,白盒测试,回归测试,压力测试,a测试,b测试?
4.单元测试、集成测试、系统测试的侧重点是什么?
5.你了解的自动化测试工具有那些?都有什么特点?
6.有一段程序,接收输入3个整数作为三角形的边,然后判断三角形是否有效三角形, 请设计此程序的测试用例。
7.有两个表
表一 AA
种类T     库存总量S
A         997    
B         1234
表二 BB
种类T     出库数量S
A         105
A         213
B         116
B         211
B         303
用一条SQL语句求出A,B各剩下多少?
8. 您是否熟悉一些主流的软件工程方法论和思想,如RUP、CMM、CMMI、XP、PSP、TSP。如果熟悉,您是否可以谈一下对这些方法论和思想的认识?
 
 
几个常见软件测试面试题链接:
 
 
 
 
 
 
 
1.白箱测试和黑箱测试是什么?什么是回归测试? 
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试包括两部分:函数本身的测试、其他代码的测试。 

2.单元测试、集成测试、系统测试的侧重点是什么? 
单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。 
集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求,组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。 
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。 

3.设计用例的方法、依据有那些? 
白盒测试:逻辑覆盖法,主要包括语句覆盖,判断覆盖,条件覆盖,判断-条件覆盖,路径覆盖 
黑盒测试:等价划分类,边界值分析,错误推测法。 

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

7.一个缺陷测试报告的组成 
缺陷的标题,缺陷的基本信息,复现缺陷的操作步骤,缺陷的实际结果描述,期望的正确结果描述,注释文字和截取的缺陷图象。 

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

9.软件本地化测试比功能测试都有哪些方面需要注意? 
软件本地化测试的目的: 
软件本地化测试的测试策略:1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上,作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。 

11.需求测试注意事项有哪些? 
一个良好的需求应当具有一下特点: 
完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。 
正确性:每一项需求都必须准确地陈述其要开发的功能。 
一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。 
可行性:每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。 
无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。 
健壮性:需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。 
必要性:“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如Use Case或别的来源。 
可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。 
可修改性:每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。 
可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好(f i n e - g r a i n e d )的方式编写并单独标明,而不是大段大段的叙述。 

13.测试分析测试用例注意(事项)? 
阅读(706) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~