1、    什么是兼容性测试？兼容性测试侧重哪些方面？

兼容测试：兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。

兼容的类型：细分为

a)硬件兼容性测试：与整机兼容，与外设兼容

b)软件兼容性测试：操作系统/平台的兼容，数据库兼容，不同浏览器兼容，不同应用软件之间的兼容，软硬件配合的兼容

c)数据兼容性测试

兼容测试的重点：对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容测试。

2、   我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

1、确认当前软硬件配置是否符合软件的推荐标准

2、确认当前的系统是否独立，没有对外提供类似消耗CPU，内存等资源的服务。

3、如果是C/S或B/S结构的软件，检查与服务器的连接是否有问题，或者访问有问题造成。

4、在系统没有负载的情况下，查看应用程序对CPU/内存的访问情况。

5、检查系统是否有中毒的特征；

6、可能的话在另一台相同配置，相同操作系统的机器上运行

3、   测试的策略有哪些？

测试策略可以定义为：项目测试中，描述测试活动的一般方法和目标，其中包括要进行的测试阶段及测试类型。

所以按阶段分：可以分为单元测试，集成测试，系统测试，回归测试等

按测试类型可以分为：黑盒/白盒测试，静态/动态测试，手工/自动化测试，功能/性能测试，安全性测试，可靠性测试，界面测试，强度测试，压力测试，负载测试，容量测试，稳定性测试，兼容性测试，Beta/a测试等

4、   正交表测试用例设计方法的特点是什么？

1、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；

2、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；

3、具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

5、   描述测试用例设计的完整过程？

对需求文档(产品需求文档、软件需求规格说明书等)进行分析需求分析及需求变更的维护工作；

根据需求文档， 得出测试需求(功能测试需求、非功能性测试需求)；

根据测试需求设计测试方案，评审测试方案；

方案评审通过后，设计测试用例，再对测试用例进行评审；

6、   单元测试的策略有哪些？

自顶向下的单元测试策略：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块。其次对第二层进行测试，使用上面已测试的模单元做驱动模块。如此类推，直到测试完所有模块。

自底向上的单元测试策略：先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模块的模块做驱动模块。然后再对上面一层做单元测试，用下面已被测试过的模块做桩模块。一次类推，直到测试完所有模块。

孤立的测试策略：不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块独立进行测试。

7、   你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？

容量测试

测试系统对不同级别数据容量下的工作能力，意在获取系统的最佳数据处理容量和最大处理容量。

稳定性测试

测试系统的长期稳定运行的能力。同疲劳强度测试的区别是，稳定性测试的压力强度较小，一般趋向于客户现场日常状态下的压力强度，当然在时间不能保证稳定性的状态下，需要加大压力强度来测试，此时的压力强度则会高于正常值。

兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。

压力测试

通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大的服务级别的测试。

8、   软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

1.bug ID

2.bug类型

3.严重程度

4.bug标题

5.重现步骤

6.所属项目

7.所属产品模块

8.影响版本      

9.当前指派人

10.当前状态人

11.提交人/提交日期

12.相关需求     

1.认真做好前期的相关需求文档的分析工作

2.设计高质量的测试用例并执行

3.精炼语言，做到言简意赅。

9、   Beta测试与Alpha测试有什么区别？

Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场.

Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试.

10、什么是桩模块？什么是驱动模块？

桩模块：被测模块调用模块

驱动模块： 调用被测模块的模块

11、什么是扇入？什么是扇出？

扇入：被调用次数，扇出：调其它模块数目

12、阐述工作版本的定义？

软件开发过程中，用于内部测试的功能和性能不完善的软件编译版。工作版本既可以是系统的可操作版本，也可以是要在发布产品中演示的部分功能模块。

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

提交->确认->分配->修复->验证->关闭

14、          你认为做好测试计划工作的关键是什么？

总的来说，测试计划由以下几个部分组成：目标和范围，项目估算，风险计划，资源配置，进度安排

跟踪和控制机制

所以，计划工作的关键是做好以下几个任务：

1.认真执行需求文档审查和评审

2.明确测试需求和任务

3.分析测试范围和工作量

4.明确测试资源需求

5.合理安排测试进度

6.测试风险分析

7.制定有效的测试策略

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

也可以用上面的来回答

15、你认为做好测试用例工作的关键是什么？

需求和设计文档的理解程度，对系统的熟悉程度

16、你觉得软件测试通过的标准应该是什么样的？

缺陷密度值达到客户的要求

17、简述集成测试与系统测试关系？

（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；

（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。

18、          一套完整的测试应该由哪些阶段组成？

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估

19、          集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？

集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

集成测试应该考虑以下问题：

（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；

（3）各个子功能组合起来，能否达到预期要求的父功能；

（4）全局数据结构是否有问题；

（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

20、          单元测试主要内容是什么？

1，模块接口测试。单元测试的基础，只有在数据能正确流入，流出模块的前提下才有意义。

2，局部数据结构测试 检查局部数据结构是为了保证临时存储在模块内的数据在程序执行中完整，正确。重点是一些执行函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例。

3，边界条件测试 单元测试中最重要的一项任务。因为软件经常在边界上失败，采用边界值分析，可能发现新的错误。

4，模块中所有独立路径的测试 在模块中执行每一条独立执行路径进行测试，单元测试的基本任务保证模块中每条语句执行一次。

5，模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。

21、          如何理解强度测试？

测试系统在高负载，高强度下的工作能力，意在获取系统在极限状态下运行时的各项性能指数，查看其是否在允许的范围内。

注：

1.疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如7x24小时的压力测试。

2. 强度测试总是通常模拟系统在异常的资源配置下运行，如人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态

22、          如何理解压力、负载、性能测试测试？

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试，通常包含了负载测试，压力测试等。

b)        负载测试

通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。

c)         压力测试

压力测试是在强负载下的测试，查看应用系统在峰值使用情况下性能行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力，检测系统能提供的最大的服务级别的测试。压力测试可以看成是强负载下的负载测试。

23、什么是系统瓶颈？

软件系统业务能力起限制，约束，使其不能满足用户特定业务需求的关键因素。

严格的技术角度上讲，所有的系统都会有瓶颈，因为大多数系统的资源配置是不协调的，如cup使用率刚好到达100%时，内存正好耗尽的系统。但是不多见。所以我们要从应用角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，可以认为系统没有瓶颈或者瓶颈不影响用户工作。

测试系统瓶颈主要是实现下面两个目的：

--发现表面的瓶颈。模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。

--发现潜在的瓶颈并解决，保证系统的长期稳定。

24、软件测试人员就是QA吗？

软件测试人员的职责是尽可能的找出软件缺陷，确保缺陷能被修复。

QA（质量保证人员）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。

测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是保证人员的工作对象。

25、          什么是软件测试，软件测试的目的？

软件测试就是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中存在的各种问题—与用户需求、预先的定义不一致的地方。

26、          写出bug报告流转的步骤，每步的责任人及主要完成的工作。

测试人员提交新的Bug入库，错误状态为New。

高级测试员/测试经理验证缺陷，如果缺陷已经提交，拒绝，标记为Declined-Duplicated，

如果确认未提交且是缺陷，分配给开发组。设置状态为Open。如果不是缺陷，则拒绝，设置为Declined状态。

开发经理分配bug至对应的模块开发人员。

开发人员查询状态为Open的缺陷，如果不可以重现则更新报告，反馈给开发经理。可以重现则判断是否可以修复，是则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。

对于不能解决和延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为Fixed的缺陷，然后验证缺陷是否已解决，如解决，置缺陷的状态为Closed，如没有解决,置缺陷状态为Reopen。查询状态为Declined-Duplicated的缺陷，进行关闭，置缺陷的状态为Closed。

27、          画出软件测试的V模型图。  

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

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个已经实现的功能是否符合需求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求。所有内部成分是否经过检查。

黑盒测试要在软件的接口处进行，这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部逻辑和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合太的功能说明。因此黑盒测试又叫功能测试或者数据驱动测试。

白盒测试是对软件的过程性细节做仔细的检查，这种方法是把测试对象看做一个打开的盒子，太允许测试人员利用程序内部的逻辑结构和有关信息，设计或者选择测试用例，对程序所有逻辑路径进行测试。通过不同点检查程序的状态，确定实际状态是否与预期的状态一致。因此，白盒测试又叫逻辑驱动测试或者结构测试。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的，很明确的功能是否正确。通常而言，一个单元测试用于判断某个特定条件下某个特定函数的行为，由程序员自己完成。

集成测试（组装测试，联合测试）是单元测试的逻辑扩展。它的最简单形式：两个已经测试过的单元组合成一个组件，并且测试他们之间的接口。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试，最后，将构成进程的所有模块一起测试。

系统测试：将经过测试的子系统装配成一个完整的系统来测试。目的是对最终软件系统进行全面的测试，确保

最终软件系统满足产品需求并且遵循系统设计。

验收测试：目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试向用户表面系统能够像预定需求那样工作。

29、          测试用例通常包括那些内容？着重阐述编制测试用例的具体做法

标识符 ID

测试项

测试需求

测试环境

测试前提

输入数据

操作步骤:

预期输出

实际输出

测试用例之间的关联

其他元素:

 优先级

所在模块

测试时间

 测试人

编制人

审评人

版本号

测试阶段

测试类型

30、          集成测试通常都有那些策略？

自顶向下测试

自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：

第一：先深度：按照结构，用一条主控制路径将所有模块组合起来；

第二：先宽度：逐层组合所有下属模块，在每一层水平地

步骤一：用主控模块作为测试驱动程序，其直接下属模块用承接模块来代替；

步骤二：根据所选择的集成测试法（先深度或先宽度），每次用实际模块代替下属的承接模块

步骤三：在组合每个实际模块时都要进行测试；

步骤四：完成一组测试后再用一个实际模块代替另一个承接模块；

步骤五：可以进行回归测试（即重新再做所有的或者部分已做过的测试），以保证不引入新的错误。

自底向上测试

自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。自底向上集成测试的步骤大致如下：

步骤一： 按照概要设计规格说明，明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划。，可以排出各活动之间的时间序列关系，处于同一层次的测试活动可以 同时进行，而不会相互影响。

步骤二： 在步骤一的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。

步骤三： 将各软件模块集成为子系统（或分系统）。检测各自子系统是否能正常工作。同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。

步骤四： 将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。

方案点评： 自底向上的集成测试方案是工程实践中最常用的测试方法。相关技术也较为成熟。它的优点很明显： 管理方便、测试人员能较好地锁定软件故障所在位置。但它对于某些开发模式不适用，如使用XP开发方法，它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试。尽管如此，自底向上的集成测试方法仍不失为一个可供参考的集成测试方案。

核心系统测试

核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。其步骤如下：

步骤一： 对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动模块和桩模块；

步骤二： 对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。在核心系统规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块。

步骤三： 按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后，即可进行外围软件部件的集成。

步骤四： 在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块级集成测试。

步骤五： 按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。

方案点评： 该集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。

高频集成测试

高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。使用高频集成测试需要具备一定的条件： 可以持续获得一个稳定的增量，并且该增量内部已被验证没有问题； 大部分有意义的功能增加可以在一个相对稳定的时间间隔（如每个工作日）内获得； 测试包和代码的开发工作必须是并行进行的，并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本； 必须借助于使用自动化工具来完成。高频集成一个显著的特点就是集成次数频繁，显然，人工的方法是不胜任的。

高频集成测试一般采用如下步骤来完成：

步骤一： 选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化，也有一些商业集成测试工具可供选择。

步骤二： 设置版本控制工具，以确保集成测试自动化工具所获得的版本是最新版本。如使用CVS进行版本控制。

步骤三： 测试人员和开发人员负责编写对应程序代码的测试脚本。

步骤四： 设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。

步骤五： 测试人员监督代码开发人员及时关闭不合格项。

按照步骤三至步骤五不断循环，直至形成最终软件产品。

方案点评： 该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。

以上我们介绍了几种常见的集成测试方案，一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。

31、阶段评审与项目评审有什么区别？标记

阶段评审 对项目各阶段评审：对阶段成果和工作

项目评审 对项目总体评审：对工作和产品

32、          测试产品与测试项目的区别是什么？

习惯上把开发完成进行商业化，几乎不进行代码修改就可以售给用户使用的软件称为软件产品。

把针对一个或几个特定的用户而开发的软件称为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。

区别：

1.质量不同，产品的质量要求高一些，修复发布后产品的缺陷成本较高，甚至带来很多负面的影响。而项目通常面向某一个用户，虽然质量越高越好，但是一般只要满足用户要求就可以。

2.测试资源投入多少不同。软件产品通常是研发中心来开发，进度压力要小些，同时由于质量要求高，因此会投入较多的人力，物力资源。

33、          和用户共同测试（UAT测试）的注意点有哪些？

软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是拿不报酬，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。

实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“用户”满意并欣然支付酬劳才是我们的目标。因此用户测试要注意下面的事项：

（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。

（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。

（3）永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。

和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。

34、          您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

35、          软件测试报告应该包含哪些内容？

编写目的 :这部分描述文档内容简要

输入文档:：说明编写此报告的输入文档（包括：信息、数据、结果等）

测试进度：记录测试类型，测试活动的起始和结束时间

测试版本：记录实际测试活动中所测试的版本

测试环境：描述实际测试活动中使用的测试环境，并附测试环境网络拓扑图

测试过程所完成的测试类型：描述实际测试活动中所进行的各种测试活动及工作内容

测试工作量：记录测试过程中各类人员的工作量投入

测试结果分析：

代码覆盖率分析

代码覆盖率分析

测试需求覆盖情况

用例执行情况分析

系统性能指标分析

测试问题回顾：描述测试工作结束后，遗留的问题和问题未能解决的原因；描述在测试工作中遇到的问题，如沟通情况，测试环境情况，典型的测试技术和解决方案

测试量化数据分析：

测试汇总信息

缺陷数据分析

缺陷总体数据统计

缺陷分级统计

缺陷来源分析

遗留缺陷与典型缺陷分析

测试结论及产品质量分析

缺陷清单

36、          软件验收测试除了alpha ,beta测试以外,还有哪一种?

正式验收测试

37、          需求测试注意事项有哪些？

²  完整性：每一项需求都必须将所有要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

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

²  一致性：指与其它软件需求或高层需求不相矛盾

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

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

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

²  必要性：可理解为每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。

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

²  可修改性：每项需求只应在SRS中出现一次。这样更改时容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。

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

²  分配优先级：应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度

38、简述软件系统中用户文档的测试要点？

　（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位

　（2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。

　（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。

　（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到，主要是测试文档内容的全面性。

　（5）一致性。按照文档描述的操作执行后，检查软件返回的实际结果是否与文档描述的相同。

　（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。

　（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。

　（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。

　（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。

　（10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。

39、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？

用户手册

安装和设置指导

联机帮助

指南、向导

样例、示例和模板

授权/注册登记表

最终用户许可协议

40、软件的构造号与版本号之间的区别？BVT(BuildVerificationTest)标记

参考答案：版本控制命名格式: 主版本号.子版本号[.修正版本号[.编译版本号 ]]

Major.Minor [.Revision[.Build]]

         应根据下面的约定使用这些部分：

Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。

Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。

Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。

Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。

BVT(BuildVerificationTest)：

作为Build的一部分，主要是通过对基本功能、特别是关键功能的测试，保证新增代码没有导致功能失效，保证版本的持续稳定。实现BVT方式是有以下几种：1、测试人员手工验证关键功能实现的正确性。特点：这是传统开发方法中，通常采用的方式。无需维护测试脚本的成本，在测试人力资源充足，测试人员熟悉业务、并对系统操作熟练情况下效率很高，比较灵活快速。缺点：人力成本较高；对测试人员能力有一定要求；测试人员面对重复的工作，容易产生疲倦懈怠，从而影响测试质量。

2、借助基于GUI的自动化功能测试工具来完成，将各基本功能操作录制成测试脚本，每次回放测试脚本验证功能实现的正确性。特点：能够模拟用户操作完成自动的测试，从UI入口到业务实现，每一层的代码实现都经过验证；节约人力成本；降低测试人员重复劳动的工作量，机器不会疲倦；缺点：对于UI变动比较频繁的系统来说，这种方式的维护成本很高，实施起来非常困难。另外，在项目周期较短且后续无延续性或继承的情况下，也不推荐使用此方式。

3、由开发人员通过自动化测试工具完成业务层的BVT测试。特点：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定。可以结合DailyBuild，做为Build的一部分，自动实现并输入BVT报告。缺点：仅对业务规则实现的正确性进行了测试，对表现层无法测试到，对于诸如：前台页面控件各种事件响应、页面元素变化等方面的问题无法保证。

41、引入测试管理的含义？标记

风险分析，进度控制、角色分配、质量控制

42、软件的安全性应从哪几个方面去测试？

用户认证机制：如数字证书、智能卡、双重认证、安全电子交易协议

加密机制

安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描

数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理

防病毒系统

开发及环境搭建类面试题

43、简述DNS、活动目录、域的概念。

DNS:域名解析服务。将网络域名解析成ip地址。

活动目录：微软提供的目录服务的一种。它存储有关网络上的对象信息，并使管理员和用户更方便的查找和使用这类信息。

域：网络系统的一个安全边界，在一个域当中，计算机和用户共享一系列的安全信息。

44、描述TCP/IP协议的层次结构，以及每一层中重要协议。

           

45、说出4种以上常用的操作系统及其主要的应用范围（微软的操作系统除外）。

Linux(RedHat Debian, ubantu):主要用于搭建各类服务器

MAC OS：苹果机的操作系统，用于图像处理和一些软件开发平台

Unix（AIX：IBM服务器的专用操作系统）

Solaris:Sun操作系统；NetBSD

46、TCP/UDP有哪些区别？

参考答案：TCP-有连接,所以握手过程会消耗资源,过程为可靠连接,不会丢失数据,适合大数据量交换

UDP-非可靠连接,会丢包,没有校验,速度快,无须握手过程

47、ISO模型？HUB、Switch、Router是ISO的第几层设备？

参考答案：从底向上：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层

HUB：1层（物理层）；Switch：2层（数据链路层）；Router：3层（网络层）

48、Window上查看MAC以及启动和关闭的服务是什么？   

ipconfig/all

net start 服务名

net stop 服务名