软件测试面试题(理邦仪器，答案仅供参考）

一．主观判断题（10分）

1．软件测试的目的是尽可能多的找出软件的缺陷。（Y）

2．只要我们做了充分的测试。就能保证软件没有BUG（N）

3．验收测试是由最终用户来实施的。（Y）

4．项目立项前测试人员不需要提交任何工件。（N）

5．单元测试能发现约80%的软件缺陷。（Y）

6．代码评审是检查源代码是否达到模块设计的要求。（Y）

7．负载测试是验证要检验的系统的能力最高能达到什么程度。（N）

8．测试人员要坚持原则，缺陷未修复完坚决不予通过。（N）

  总共十个，还有两个不太记得

二.是个简单的程序回答题

三.三角形测试用例题目：输入三个数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形是一般三角形、等腰三角形还是等边三角形时。用等价类划分方法为该程序设计测试用例。

 

三角形等价类列表

判定类型       有效等价类                                                                    无效等价类

一般三角形    ((a>0) Λ(b>0) Λ(c>0))Λ                                  (a<=0 V b<=0 V c<=0) Λ

                       (((a+b)>c) V ((a+c)>b) V ((b+c)>a))  (1)       (((a+b)<=c) V ((a+c)<=b) V ((b+c)<=a)) (2)

等腰三角形    (1) Λ (a=b V a=c V b=c)(3)                            (2) V (a!=b Λ b!=c Λ a!=c) (4)

等边三角形    (1) Λ (a=b=c )  (5)                                           (2) V (a!=b!=c)(6)

根据上表组成的测试用例：

三角形等价类测试用例

ID 输入数据       覆盖测试用例        输出结果

    a b c  

1   3 4 5       (1)              一般三角形

2   0 4 5       (2)              非(一般)三角形

3   3 0 5       (2)           

4   3 4 0       (2)      

5   1 4 5       (2)           

6   3 8 5       (2)           

7   3 2 1       (2)           

8   3 3 5       (3)               等腰三角形

9   3 4 3  

10  3 4 4  

11  3 4 9       (4)               非等腰三角形

12  3 3 3       (5)               等边三角形

13  -1 0 1      (6)               非等边三角形

 

三角形程序的测试用例：

序号   测试内容            测试数据                               预期结果

1         等边             5,5,5 4,5,5                                 等边

2         等腰             4,4,5 5,4,4                                 等腰

3         任意             3,4,5                                        任意

4         非三角形         9,4,4 4,9,4 4,4,9                            No

5         退化三角形       8,4,4 4,8,4 4,4,8                             No

6         零数据           0,4,5 4,0,5 4,5,0                             No

7         零数据           0,0,0                                          No

8         负数据            -3,4,5 3,-4,5 3,4-5                        运行出错

9         负数据            -3,-4,-5                                    运行出错

10       遗漏数据             3,4                                       运行出错

11       非 整数              3.3,4,5                                   运行出错

12       非数字符             A,4,5                                   （类型不符）

四.loadrunner测试流程

我感觉这题的目的就是要考软件测试流程

一、 新产品或工程管理流程
1、 需求调研
在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。
2、 制定测试计划
进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。
3、 需求Review
开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。
4、 设计Review
在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。
5、 测试设计
在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。每个测试用例必须包括以下几个部分：
（1） 标题和编号
（2） 测试的目标和目的
（3） 输入和使用的数据和操作过程
（4） 期望的输出结果
（5） 其他特殊的环境要求、次序要求、时间要求等
6、开发测试工具和准备测试数据
   在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。
7、测试执行
当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。
8、回归测试
   在测试中发现的任何问题和错误都必须有一个明确的解决方法。一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。
9、测试分析报告
   测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。
10、产品发布
   测试完毕，整理产品发布包和相关文档并发布。对于新产品来说，必要的文档必须包括：
（1） 安装操作手册
（2） 产品白皮书
（3） 管理维护手册
（4） 用户操作手册
（5） 测试报告
11、版本控制
新版本软件发布之后，马上对代码进行质量控制。
（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。
（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。
五.什么是性能测试,负载测试,压力测试,并发性测试

1、性能测试:性能测试用来保证产品发布后系统的性能能够满足用户需求。其中系统性能包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。

2、负载测试:负载测试时通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。

3、压力测试:压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。

4、并发性测试:并发性测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点。并发性测试分为三类：　　
a、应用在客户端性能的测试；
b、应用在网络上性能的测试；
c、应用在服务器上性能的测试；

六.为什么不是所有软件缺陷都能被修复

项目小组需要对每一个软件缺陷进行取舍，根据风险决定哪些要修复，哪些不要,一般来说，不需要修复软件缺陷的原因如下：
1、没有足够的时间。在任何一个项目中，通常是软件功能较多，而代码编写人员和软件测试人员较少，而且在项目进度中没有为编制和测试留出足够的时间。
2、不算真正的软件缺陷。在某些特殊场合，错误理解、测试错误或者说明书变更会把软件缺陷当作附加功能来对待。
3、修复的风险太大。就本人体会，这种情形是比较常见的。软件本身比较脆弱，难以理清头绪。那么在这种情况下，修复一个软件缺陷可能导致其他软件缺陷的出现。在紧迫的发布进度压力之外，修改软件将冒很大的风险。不去理睬未知软件缺陷，以避免出现未知新缺陷的做法也许是安全之道。
4、不值得修复。不常出现的软件缺陷和再不常用功能中出现的软件缺陷可以放过；可以躲过和用户有办法预防或避免的软件缺陷通常不用修复。不过这些的前提是要做好商业风险的决策。

七.用算法写个冒泡排序

  #include<stdio.h>
  void main()
  {
  int a[10];
  int i,j,t;
  printf("输入10个整数：/n");
  for( i = 0; i < 10; i ++ )
  scanf("%d",&a[ i ]); //依次输入10个整数
  for( j = 0; j < 9; j ++ ) //进行9轮排序 即n－1次
  {
  for( i = 0; i < 9-j; i ++) //每轮进行n－1－j 次比较，最多n－1－j 次交换
  if( a[ i ] > a[ i + 1 ] )
  {
  t = a[ i ] ;
  a[ i ] = a[ i + 1 ]; //小的沉底，大的上浮
  a[ i + 1 ] = t;
  }
  }
  printf("排序结果:");
  for( i = 0; i < 10; i ++ ) //依次输出排序结果
  printf("%d/t",a[ i ]);
  printf("/n");
  }