青山青水
范文一：软件测试和软件测试面试题
什么是软件测试
为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格技术评审。但由于人们能力的局限性，审查不能发现所有的错误。而且在编码阶段还会引进大量的错误。这些错误和缺陷如果遗留到软件交付投入运行之时，终将会暴露出来。但到那时，不仅改正这些错误的代价更高，而且往往造成很恶劣的后果。
软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。如果给软件测试下定义，可以这样讲：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入一些数据而得到其预期的结果），并利用这些测试用例去运行程序，以发现程序错误的过程。
软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。编码与单元测试属于软件生存期中的同一个阶段。在结束这个阶段之后，对软件系统还要进行各种终合测试，这是软件生存期的另一个阶段，即测试阶段，通常由专门的测试人员承担这项工作。
大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终目的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。
软件测试的目的
基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露出软件中陷藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立用户对软件质量的信心。
因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。如果站在用户的角度替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。在选取测试用例时，考虑那些易于发现程序错误的数据。
下面这些规则也可以看作是测试的目的或定义：
1. 测试是为了发现程序中的错误而执行程序的过程；
2. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
3. 成功的测试是发现了至今为止尚未发现的错误的测试。
从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。
由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。
术语、名词定义
1. 黑盒测试：黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构。测试者把被
测程序看成一个黑盒,不用关心程序的内部结构。黑盒测试是在程序接口处进行测试，它只检查程序功能是否能正常使用，程序是否能接收输入数据产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试是基于用户角度进行的测试。
2. 白盒测试：软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。测试者需要了解待测试程序代码的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
3. 灰盒测试：可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间, 对软件内部有所了解, 但不见得到了如指掌的程度, 却可以结合这些了解做些比黑盒多点的测试。
4. 文档测试：文档测试涵盖面很大，在软件的各个版本中均有所使用。随着软件版本的变化，文档测试的测试内容也有所变化。在需求分析以及原型架构阶段，文档测试主要目标是： Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。
文档测试主要检查文档的正确性、完整性和可理解性。正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。完整性是指文档不可以漏掉关键性内容。可理解性是指在文档中描述的语言要简明易懂，不能让别的开发人员拿到文档时看不懂文档的内容。
5. 命名规范测试：命名规范测试用于测试项目中的文件命名、代码以及版本号等书写是否符合规范。文件命名规范以及版本号命名规范可以参看第四部分里软件命名规范的详细信息；各种语言的命名规范可以参考语言自身的规范，如NoahWeb的可以参考 http://docs.noahweb.net附录中的《NoahWeb各类资源命名规范》。
6. 需求完整性测试：需求完整性测试主要存在于需求探索阶段，在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试，确认需求是否明确。另外，需求完整性测试也承担着一部分澄清需求的任务。
7. 链接完整性测试：在原型架构阶段，链接完整性的测试是非常有必要的。该项测试任务主要是检查假页面中各种链接是否完整，是否指向目标位置，属于检查性的测试。
8. 页面完整性测试：页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整，页面质量是否达标，属于检查性测试。
9. UI合理性测试：UI合理性测试也就是人机交互界面的合理性，UI合理性测试的内容很多，具体测试内容如下：
o 提示、菜单、帮助的格式是否一致；
o 提示、菜单、帮助中的术语是否一致；
o 各个控件之间的对齐方式是否一致；
o 输入界面和输出界面在外观、布局、交互方式上是否一致；
o 功能类似的相关界面在外观、布局、交互方式上是否一致；
o 同一层次的文字在同一种提示场合（一般情况、特殊字体、警告等）在文字大小、字体、颜色、对齐方式方面是否一致，字体大小 是否与界面的大小比例协调；
o 多个连续界面依次出现的情况下，界面的外观、操作方式是否一致；
o 系统是否拒绝客户的错误输入并做出提示；
o 系统是否在用户完成操作时给出操作成功的提示；
o 用户界面是否存在空白空间，没有空白空间的界面是杂乱无章的，易用性差；
o 各个控件的间隔是否一致，垂直和水平方向上是否对齐；
o 是否允许动作的可逆性，返回原有操做；
10. 数据和数据库完整性测试：因为在开发阶段开发人员随时都有可能根据需要来修改数据库，所以对数据和数据库完整性测试在软件项目的任何阶段也是非常必要的。该项测试内容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名规范，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。
11. 功能测试：功能测试在软件项目的任何阶段中都是重要的。实现功能，满足客户需求是软件本身最大的使命。功能测试在任何阶段下基本上都作为测试工作的第一项出现。该项测试任务主要为了测试已实现的功能是否满足需求，是否正确，是否有价值以及是否完整。在黑盒和白盒测试状态下，该测试均会被使用。
功能测试中测试人员往往会忽略掉一些细节问题，比如：一个功能的实现必须要经过6步操作才能完成，而且需要加入20条信息才能看得出测试结果，有的测试人员为了节省时间虽然做完了6步操作，但是没有加入足量的信息，,使得测试不全面,正是因为这样而导致一些隐藏的BUG没有被测试出来。所以说在功能测试中要按部
就班的把所有要进行的测试功能每一步都执行一遍，应该添加的数据都添加完整，以避免遗漏掉BUG没有测试出来。
12. 压力测试：压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度等等）并描绘性能的变化。但是如果有许多输入，或者需要在大的范围内改变输入，那么你可以借助一个自动化的压力测试工具来完成此测试。
13. 安全性测试：安全性测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据和页面的安全。测试人员可以学习一些黑客技术，来对系统进行攻击。 另外，对操作权限的测试也包含在安全性测试中。具体测试内容如下：
o 执行添加、删除、修改等动作中是否做过登录检测。
o 退出系统之后的操作是否可以完成。
o 所有插入表单操作中输入特殊字符是否可以正常输正常存储，特殊字符为：！?#￥%……—*（）~——-+=[]{}、|；：?”？/《》，。
o 在带有参数的回显数据的动作中更改参数，把参数改为特殊字符并加入操作语句看是否出错。
o 测试表单中有没有做标签检测，标签检测是否完整。
o 在插入表单中加入特殊的HTML代码，例如：表单中的字本是否移动？。
14. 页面脚本测试：页面中时常使用到JavaScript脚本，为了降低页面的出错率，则必须对页面脚本进行测试。其主要内容包括：相关页面中的脚本是否正常运行，JavaScript脚本是否有错误页面。
15. 提示文本测试：提示文本测试从严格意义上来讲应该属于UI合理性测试的一部分，该项测试主要针对各个页面中使用到的大量提示文档进行测试，主要包括：表达不明确的位置是否有提示文本、提示文本的弹出是否正常、提示信息含义是否明确易懂。
16. 浏览器测试：由于B/S结构项目是基于浏览器运行的，所以需要对浏览器进行必要的测试。该测试任务主要是软件对各种浏览器（IE5.5、IE6.0、 FireFox浏览器 ）的支持是否正常，在IE浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。
17. 安装测试：在软件项目的后期阶段，会对做好的软件进行打包把软件做成安装程序，以便用户可以正确的安装使用，所以需要对做好的安装文件进行安装功能方面的测试。该测试的主要任务是：检查软件是否能够正常安装使用、是否可以完全卸载此软件的所有功能和页面。
18. 自定义测试：在常规测试时可能表中的测试项不能满足测试要求，如果有特殊测试项请测试人员自己定义修改测试的类型。
软件命名规范
1. 软件版本阶段说明
o Base版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
o Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
o Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
o RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
o Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。
2. 版本命名规范
软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：
1.1.1.051021_beta。
版本号定修改规则：
o 主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
o 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
o 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
o 日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
o 希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
3. 文件命名规范
文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta。
如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告1.1.1.051021_beta_b1.xls
当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi2.xls
4. 版本号的阶段标识
软件的每个版本中包括11个阶段，详细阶段描述如下：
阶段名称 阶段标识
需求控制 a
设计阶段 b
编码阶段 c
单元测试 d
单元测试修改 e
集成测试 f
集成测试修改 g
系统测试 h
系统测试修改 i
验收测试 j
验收测试修改 k
5.
测试任务描述
在软件的开发过程中每个版本都会经历四次测试任务，分别为：单元测试、集成测试、系统测试、验收测试，在这四次测试任务中，每次测试都有不同的测试方向和重点。
1. 单元测试：单元测试是软件开发过程中要进行的最基本的测试，属于白盒测试范围，一般情况下是在开发人员完成了某个单独模块的编码之后做的测试。它的目的是检查软件编码的正确性以及一些规范性测试，站在开发人员的角度上来查找软件所存在的BUG并记录下产生BUG的原因，以便开发人员进行修改。这样可以在很大程度上减少集成以后而出现的BUG。
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试会推迟对整个系统进行合并这种真正有意思的工作启
动的时间。
这种开发步骤中，真实意义上的进步被软件合并后的外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。现实的开发中，没有单元测试的软件常常会导致这样的结果，软件甚至无法运行。更进一步的结果是大量的时间将被花费在本应该在单元测试里就完成的简单Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会延长软件集成为一个系统的时间， 而且当这个系统投入使用时也无法确保它能够可靠运行。
单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试应该是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行，也就是说每个版本的开发都需要经过单元测试，这样可以在以后的开发阶段减少很多不必要的麻烦。
单元测试的重点测试内容包括：源代码测试、命名规范测试、需求完整性测试、页面完整性测试、提示文本测试、页面脚本测试等。
2. 集成测试：集成测试也属于白盒测试范围，是在单元测试的基础上将软件的多个模块或者系统前后台合并之后进行的测试，也可以算是对单元测试修改进行的复审测试。在集成测试中可以弥补单元测试中没有测试到的BUG，也可以检查出单元测试没法测试的功能，比如前后台的集成之后的关联功能，对于这些有关联性功能的测试，单元测试中是无能为力的，必须依靠集成测试来保证功能的完整性和正确性。和系统测试相比较集成测试从程序结构出发，目的性、针对性更强，发现问题的效率高，较容易测试特殊的处理流程中存在的BUG。
集成测试的重点测试内容包括：链接完整性测试、页面完整性测试、数据和数据库完整性测试、功能测试、压力测试、安全性测试、页面脚本测试、提示文本测试等。
3. 系统测试：系统测试属于黑盒测试范围，是在系统集成测试修改完BUG之后进行的测试。从软件工程和测试的分类来看：集成测试在系统测试之前就必须要进行完毕，只有集成测试完成了，才能保证相应的系统测试进行。也就是说，集成测试是系统测试的基础。
系统测试是针对整个产品的全面测试，既包含各模块的验证性测试和功能合理性测试，又包括对整个产品的可靠性、健壮性、安全性、UI合理性及各种性能参数的测试。
系统测试的重点测试内容包括：链接完整性测试、UI合理性测试、命名规范测试、功能测试、压力测试、页面完整性测试、安装测试、提示文本测试、游览器测试等。
4. 验收测试：验收测试属于黑盒测试范围，是对系统测试修改后的复审，这方面和集成测试有些类似，首先确认系统测试中的BUG已经按要求修改完成，然后检测一下功能是否符合用户的需求、文档是否完整、有没有前面测试中遗漏没有测试出来的BUG。要说明的一点是，此处的验收测试并非客户验收测试，这里没有客户参与测试，只有测试人员参与测试。验收测试是开发结束或进入下一版本的标志性测试。
验收测试的重点测试内容包括：链接完整性测试、UI合理性测试、功能测试、压力测试、页面完整性测试、提示文本测试、浏览器测试、安装测试。
测试工作流程图
软件在开发过程中共有五个版本，分别是Base版、Alpha版、Beta版、RC版、Release版，每个版本的开发中都需要经过上述四次测试，但是每个版本中各阶段的测试重点是不一样的，详细的测试流程和重点请看下面各版本流程图：
1. Base版各个测试阶段流程图
测试提交文档
测试文档使用方法
在测试的过程中测试人员会用到三张表，第一张表是“测试任务表”，这张表中记录的是软件在每个版本的每个阶段中需要做的具体测试任务，如果测试中不确定需要做哪些测试，在这张表中可以查询各个阶段中所要进行的测试项。
还有两张表是需要在相应测试阶段来添写的测试文档，分别是“白盒缺陷测试报告”和“黑盒测试缺陷报告”两张表。单元测试和集成测试属于白盒测试范围，需要添写白盒缺陷测试报告；系统测试和验收测试属于黑盒测试范围，需要添写黑盒测试缺陷报告。
测试人员测试完成之后，需要把所添写的缺陷测试报告按时提交给项目经理，由项目经理来安排具体人员进行修改和审核。
测试文档下载
? 测试任务表
? 白盒缺陷测试报告
? 黑盒缺陷测试报告
注：
在每次的测试中测试人员需要按表中的要求进行添写测试报告，然后由项目经理来分配给开发人员处理，开发人员修改完BUG之后再交由项目经理来分配给测试人进行修改后的复审，检查前面测试出来的BUG是否已经修改完成，在此要特别说明的一点是：为了让测试报告更方便查看，如果在复审过程中查出还有BUG没有修改完或是根本没有修改，则在复审描述中说明原因，然后把此处标注成新的BUG索引项指到新的BUG编号上，详细情况请看下面截图：
测试方法和方式
测试方式主要以手工测试为主，在条件允许的情况下使用自动化测试工具进行测试。
说明：黑盒测试是依据用户能看到的规格说明，即针对命令、信息、报表等用户界面及体现他们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试。主要由客户或系统使用者完成执行黑盒测试。
黑盒测试覆盖范围:
? 测试用例覆盖：测试的每一个用例都被测试过。
? 输入覆盖：测试过程中所输入的数据或资料必须一再的试验，如在程序安装过程中输入用户名时，测试者必须反复
输入不同长度的中文、英文或数字等来做测试。
? 输出覆盖：测试过程中程序所产生的行为、反映及数据必须都一再的试验，如不同情况的对话窗口的内容、运算结
果数据等都必须反复地测试审核。
通过测试的标准
一般有“基于测试用例”和“基于缺陷密度”两种评比准则，在这里我们采用前者。
准则如下：
1. 功能性测试用例通过率达到100％；
2. 非功能性测试用例通过率达到95％；
备选通过办法：
根据实际情况由项目经理和测试负责人以及用户等共同讨论确定本阶段是否结束。
实施建议
对于系统的一些实施建议：
o
o 对系统测试人员进行必要的培训，提高他们的测试效率。 项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”
的测试。
范文二：软件测试面试题1
问题一：为什么要在一个团队中开展软件测试工作？
任何软件在开发过程中都会留下缺陷，带有缺陷的软件产品如果提交出去，可能会给公司带来不可估量的损失，我们必须在客户之前发现尽可能多的问题，从而保障客户满意。而发现问题的这个过程称之为测试。
问题二：简述你在以前的工作中做过哪些事情，比较熟悉什么。
此问题每个人都不一样。我自己的答案如下。
我主要的工作是系统测试和自动化测试，也曾少量涉及性能测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
问题三：你所了解的的软件测试类型都有哪些，简单介绍一下。
1. 基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者Sanity Check。
2. 功能测试。主要是依据需求或者需求分析文档，对所发布的版本进行测试，看看是否满足需求，是否出现了不必要的功能。
3. 单元测试。是开发人员进行的测试之一，一般是开发人员对很小的模块，比如函数进行测试，一般来说，开发人员还需要开发相应的测试桩来进行此类测试。
4. 集成测试。在大型的开发过程中，软件是模块化进行开发的，将不同的模块揉合在一起的话，需要进行的测试就是集成测试。
5. 系统测试。当软件提交给测试组后，是对整个系统的所有功能进行测试，一般来说，功能测试是系统测试的一个部分。
6. 压力测试。主要是在很大性能的情况下，这个性能已经接近了系统的极限，看看系统运转的情况。
7. 负载测试。主要是用各种不同的性能去检测系统，采集各个数据在这些性能情况下的数据。
8. 黑盒测试。指系统对你来说是完全不透明的，只给你留下了输入和最终输出，这个是功能测试的方法之一。
9. 灰盒测试。指在了解部分系统内部工作机制的情况下，对于系统进行的覆盖
性测试。
10. 白盒测试。主要是在单元测试和集成测试的情况下，开发人员已知代码，对这一段的代码进行全路径的覆盖测试。
11. 界面测试。主要是看用户界面的友好性和易用性，是否有文字或者排版错误，是否有输入限制等等。
12. 回归测试。一般是系统发现BUG，开发人员修改后，和BUG直接相关以及可能相关的功能进行的测试。
13. 安装和卸载的测试。
14. 恢复测试。主要是一个系统在发生了灾难的情况下，从错误中是否容易恢复。
15. 兼容性测试。一个系统在不同的语言，操作系统下的系统测试。
16. 安全测试。系统在遇到攻击或者类似情况下的表现。
17. Alpha测试。系统在给最终用户前，测试人员在实验室中模拟最终用户的测试。
18. Beta测试。由部分最终用户通过使用来进行的测试。
19. 比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
20. 验收测试。一般是最终用户在接受产品前，依据自己所提出的要求进行的测试，很多情况下，验收测试可能委托第三方机构完成。
问题四：测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件。
包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。
问题五：你认为做好测试计划工作的关键是什么？
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2. 坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3. 采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术
问题六：常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1. 等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错
误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
问题七：您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
问题八：详细的描述一个测试活动完整的过程。
1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪
2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4. 测试用例完成后，测试和开发需要进行评审。
5. 测试人员搭建环境
6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。
7. 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
8. 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
问题九：以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。
问题十：您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。
测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
问题十一：您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
主要是保障在大量用户的情况下，服务能正常使用。
问题十二：在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
1. 在传统的BugZilla中，BUG描述应该包括以下的信息
2. 和BUG产生对应的软件版本
3. 开发的接口人员
4. BUG的优先级
5. BUG的严重程度
6. BUG可能属于的模块，如果不能确认，可以用开发人员来判断
7. BUG标题，需要清晰的描述现象
8. BUG描述，需要尽量给出重新Bug的步骤
9. BUG附件中能给出相关的日志和截图。
高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
问题十二：BUG管理工具的跟踪过程
用BugZilla为例子
测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配
开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。 如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。
问题十二：您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。
问题十三：在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？
某次性能测试覆盖不足，造成系统崩溃。
问题十四：你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定
了。
我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现
bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。
问题十五：你的测试职业发展目标是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经
验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。
问题十六：你自认为测试的优势在哪里？
有韧性
有能力面对挑战
有信心做好每一件事情
有比较好的教育背景
从以前的经理处都得到了很好的评价表明我做的很好
问题十七：当开发人员说不是BUG时，你如何应付？
如果确实是自己理解错误，则承认错误，没什么大不了
如果是需求不明，请项目经理补充清楚
如果双方理解不一致，且都不能互相说服，则请项目经理判断。
问题十八：你为什么想离开目前的职务？
问题十九：你对我们公司了解有多少？
问题二十：你找工作时，最重要的考虑因素为何？
工作的性质和内容是否能让我发挥所长，并不断成长。
问题二十一：为什么我们应该录取你？
您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。
问题二十二：请谈谈你个人的最大特色。
我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。
问题二十三：一个测试工程师应具备那些素质和技能？
问题二十四：集成测试通常都有那些策略？
自上而下，自下而上，平面集成
问题二十五：测试结束的标准是什么？
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。
如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。
问题二十六：软件验收测试除了alpha,beta测试以外,还有哪一种?
第三方验收测试
问题二十七：为什么选择测试这行？
最开始么，公司安排的，然后么，干一行爱一行，发现测试中间还是有很多东西需要学习的，再就是测试中有很多东西值得改进和研究。
问题二十六：为什么值得他们公司雇用？
用自己的经验和其他同事一起发现更多的问题，同时不同行业的观点可以互相借鉴。
问题二十七：如果我雇用你，你能给部门带来什么贡献？ 分享我的测试经验和测试技能，提高测试部门技术水平
范文三：软件测试英文面试题
软件测试工程师面试英语
1. What types of documents would you need for QA, QC, and Testing?
2. What did you include in a test plan?
3. Describe any bug you remember.
4. What is the purpose of the testing?
5. What do you like (not like) in this job?
6. What is quality assurance?
7. What is the difference between QA and testing?
8. How do you scope, organize, and execute a test project?
9. What is the role of QA in a development project?
10. What is the role of QA in a company that produces software?
11. Define quality for me as you understand it
12. Describe to me the difference between validation and verification.
13. Describe to me what you see as a process. Not a particular process, just the basics of having a process.
14. Describe to me when you would consider employing a failure mode and effect analysis.
15. Describe to me the Software Development Life Cycle as you would define it.
16. What are the properties of a good requirement?
17. How do you differentiate the roles of Quality Assurance Manager and Project Manager?
18. Tell me about any quality efforts you have overseen or implemented. Describe some of the challenges you faced and how you overcame them.
19. How do you deal with environments that are hostile to quality change efforts?
20. In general, how do you see automation fitting into the overall process of testing?
21. How do you promote the concept of phase containment and defect prevention?
22. If you come onboard, give me a general idea of what your first overall tasks will be as far as starting a quality effort.
23. What kinds of testing have you done?
24. Have you ever created a test plan?
25. Have you ever written test cases or did you just execute those written by others?
26. What did your base your test cases?
27. How do you determine what to test?
28. How do you decide when you have ‘tested enough?’
29. How do you test if you have minimal or no documentation about the product?
30. Describe me to the basic elements you put in a defect report?
31. How do you perform regression testing?
32. At what stage of the life cycle does testing begin in your opinion?
33. How do you analyze your test results? What metrics do you try to provide?
34. Realising you won’t be able to test everything - how do you decide what to test first?
35. Where do you get your expected results?
36. If automating - what is your process for determining what to automate and in what order?
37. In the past, I have been asked to verbally start mapping out a test plan for a common situation, such as an ATM. The interviewer might say, “Just thinking out loud, if you were tasked to test an ATM, what items might you test plan include?” These type questions are not meant to be answered conclusively, but it is a good way for the interviewer to see how you approach the task.
38. If you’re given a program that will average student grades, what kinds of inputs would you use?
39. Tell me about the best bug you
ever found.
40. What made you pick testing over another career?
41. What is the exact difference between Integration & System testing, give me examples with your project.
42. How did you go about testing a project?
43. When should testing start in a project? Why?
44. How do you go about testing a web application?
45. Difference between Black & White box testing
46. What is Configuration management? Tools used?
47. What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?)
48. Would you like to work in a team or alone, why?
49. Give me 5 strong & weak points of yours
50. Why do you want to join our company?
51. When should testing be stopped?
52. What sort of things would you put down in a bug report?
53. Who in the company is responsible for Quality?
54. Who defines quality?
55. What is an equivalence class?
56. Is a “A fast database retrieval rate” a testable requirement?
57. Should we test every possible combination/scenario for a program?
58. What criteria do you use when determining when to automate a test or leave it manual?
59. When do you start developing your automation tests?
60. Discuss what test metrics you feel are important to publish an organization?
61. In case anybody cares, here are the questions that I will be asking:
62. Describe the role that QA plays in the software lifecycle.
63. What should Development require of QA?
64. What should QA require of Development?
65. How would you define a “bug?”
66. Give me an example of the best and worst experiences you’ve had with QA.
67. How does unit testing play a role in the development/software lifecycle?
68. Explain some techniques for developing software components with respect to testability.
69. Describe a past experience with implementing a test harness in the development of software.
70. Have you ever worked with QA in developing test tools? Explain the participation Development should have with QA in leveraging such test tools for QA use.
71. Give me some examples of how you have participated in Integration Testing.
72. How would you describe the involvement you have had with the bug-fix cycle between Development and QA?
73. What is unit testing?
74. Describe your personal software development process.
75. How do you know when your code has met specifications?
76. How do you know your code has met specifications when there are no specifications?
77. Describe your experiences with code analyzers.
78. How do you feel about cyclomatic complexity?
79. Who should test your code?
80. How do you survive chaos?
81. What processes/methodologies are you familiar with?
82. What type of documents would you need for QA/QC/Testing?
83. How can you use technology to solve problem?
84. What type of metrics would you use?
85. How to find that tools work well with your existing system?
86. What automated tools are you familiar with?
87. How well you work with a team?
88. How would you ensure 100% coverage of testing?
89. How wou
ld you build a test team?
90. What problem you have right now or in the past? How you solved it?
91. What will you do during the first day of job?
92. What would you like to do five years from now?
93. Tell me about the worst boss you’ve ever had.
94. What are your greatest weaknesses?
95. What are your strengths?
96. What is a successful product?
97. What do you like about Windows?
98. What is good code?
99. Who is Kent Beck, Dr Grace Hopper, Dennis Ritchie?
100. What are basic, core, practises for a QA specialist?
101. What do you like about QA?
102. What has not worked well in your previous QA experience and what would you change?
103. How you will begin to improve the QA process?
104. What is the difference between QA and QC?
105. What is UML and how to use it for testing?
106. What is CMM and CMMI? What is the difference?
107. What do you like about computers?
108. Do you have a favourite QA book? More than one? Which ones? And why.
109. What is the responsibility of programmers vs QA?
110. What are the properties of a good requirement?
111. Ho to do test if we have minimal or no documentation about the product?
112. What are all the basic elements in a defect report?
范文四：软件测试常见面试题
1．软件测试的目的是尽可能多的找出软件的缺陷。 （Y） 2．Beta 测试是验收测试的一种。 （Y） 3．验收测试是由最终用户来实施的。 （N） 4．项目立项前测试人员不需要提交任何工件。 （Y） 5．单元测试能发现约 80%的软件缺陷。 （Y） 6．代码评审是检查源代码是否达到模块设计的要求。 （N） 7．自底向上集成需要测试员编写驱动程序。 （Y） 8．负载测试是验证要检验的系统的能力最高能达到什么程度。 （N） 9．测试人员要坚持原则，缺陷未修复完坚决不予通过。 （N） 10．代码评审员一般由测试员担任。 （N） 11．我们可以人为的使得软件不存在配置问题。 （N） 12．集成测试计划在需求分析阶段末提交。 （N）二、选折 1．软件验收测试的合格通过准则是： （ABCD） A． 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。 B． 所有测试项没有残余一级、二级和三级错误。 C． 立项审批表、需求分析文档、设计文档和编码实现一致。 D． 验收测试工件齐全。 2．软件测试计划评审会需要哪些人员参加？（ABCD） A．项目经理 B．SQA 负责人 C．配置负责人 D．测试组 3．下列关于 alpha 测试的描述中正确的是： （AD） A．alpha 测试需要用户代表参加 B．alpha 测试不需要用户代表参加 C．alpha 测试是系统测试的一种 D．alpha 测试是验收测试的一种 4．测试设计员的职责有： （BC） A．制定测试计划 B．设计测试用例 C．设计测试过程、脚本 D．评估测试活动 5．软件实施活动的进入准则是： （ABC） A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化 D．项目阶段成果已经被基线化 三、添空 1.软件验收测试包括：正式验收测试，alpha 测试，beta 测试。 2.系统测试的策略有：功能测试，性能测试，可靠性测试，负载测试，易用性测试，强度测 试，安全测试，配置测试，安装测试，卸载测试，文挡测试，故障恢复测试，界面测试，容 量测试，兼容性测试，分布测试，可用性测试， （有的可以合在一起，分开写只要写出 15 就满分哦） 3.设计系统测试计划需要参考的项目文挡有：软件测试计划，软件需求工件和迭代计划。 4.对面向过程的系统采用的集成策略有：自顶向下，自底向上两种。 5.（这题出的有问题哦，详细的 5 步骤为~~）通过画因果图来写测试用例的步骤为： （1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类） ，哪些是结 果（即输出条件） ，并给每个原因和结果赋予一个标识符。 （2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什 么关系? 根据这些关系，画出因果图。 （3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。 为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。 （4）把因果图转换成判定表。 （5）把判定表的每一列拿出来作为依据，设计测试用例。四、简答（资料是搜集整理的，感谢前辈的解题）无 1.区别阶段评审的与同行评审 同行评审目的:发现小规模工作产品的错误,只要是找错误; 阶段评审目的:评审模块 阶段作品的正确性 可行性 及完整性 同行评审人数:3-7 人 人员必须经过同行评审会议的培训,由 SQA 指导 阶段评审人数:5 人左右 评审人必须是专家 具有系统评审资格 同行评审内容:内容小 一般文档 常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设 计工作中的应用。 1. 等价类划分 常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中, 各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就 等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等 价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试 结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生 在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设 计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边 界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试 数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例 的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情 况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前 产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情 况。 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。 可选择这些情况 下的例子作为测试用例. 4. 因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入 条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之 间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生 多个动作的形式来考虑设计测试用例. 这就需要利用因果图 （逻辑模型） 因果图方法最终 . 生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用 例并没有明显的优先级上的差距， 而测试人员又无法完成这么多数量的测试， 就可以通过正 交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法 指根据用户场景来模拟用户的操作步骤， 这个比较类似因果图， 但是可能执行的深度和 可行性更好。您认为做好测试用例设计工作的关键是什么？ 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。 不可能做到完 全测试，以最少的用例在合理的时间内发现最多的问题详细的描述一个测试活动完整的过程。 1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求 文档的评审， 评审的内容包括： 需求描述不清楚的地方和可能有明显冲突或者无法实现的功 能的地方。 项目经理通过综合开发人员， 测试人员以及客户的意见， 完成项目计划。 然后 sqa 进入项目，开始进行统计和跟踪 2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包 括是否有遗漏或者双方理解不同的地方。 测试人员完成测试计划文档， 测试计划包括的内容 上面有描述。 3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计 文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。 4. 测试用例完成后，测试和开发需要进行评审。 5. 测试人员搭建环境 6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试， 发现 bug 后提交给 bugzilla。 7. 开发提交第二个版本，包括 bug fix 以及增加了部分功能，测试人员进行测试。 8. 重复上面的工作，一般是3-4个版本后 bug 数量减少，达到出货的要求。 9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。 以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完 整过程。 曾经做过一套网管系统的性能测试， 主要测试该软件在同时管理大量终端的情况下， 在 响应时间，cpu/磁盘/内存等参数是否满足要求。 也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况 下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是否满足设计要求。您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理， 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。 测试网管系统中，使用的 mimic 来模拟终端，能够大量的节省成本。 测试软交换系统的时候，使用的 prolab 来模拟终端并发送呼叫软交换，他完成了同时 数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的 ip 包并发送给软交 换系统，同时对软交换系统的回应进行处理，决定下一步动作。您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？ 主要是保障在大量用户的情况下，服务能正常使用。在您以往的工作中，一条软件缺陷（或者叫 bug）记录都包含了哪些内容？如何提交高质量 的软件缺陷（bug）记录？ 1. 在传统的 bugzilla 中，bug 描述应该包括以下的信息 2. 和 bug 产生对应的软件版本 3. 开发的接口人员 4. bug 的优先级 5. bug 的严重程度 6. bug 可能属于的模块，如果不能确认，可以用开发人员来判断 7. bug 标题，需要清晰的描述现象 8. bug 描述，需要尽量给出重新 bug 的步骤 9. bug 附件中能给出相关的日志和截图。 高质量的 bug 记录就是指很容易理解的 bug 记录，所以，对于描述的要求高，能提供的 信息多且准确，很好的帮助开发人员定位。
范文五：软件测试面试题大全
面试必问题及答案
1.怎么做好文档测试?
答：仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例,检查文档的编写是否满足文档编写的目的,内容是否齐全，正确，完善.标记是否正确.
软件测试分哪2种方法？分别适合什么情况？
答：软件测试分2种：白盒测试和黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定
2.白盒测试有几种方法?
答：总体上分为静态方法和动态方法两大类。
静态：关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义 动态：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
3.系统测试计划是否需要同行审批，为什么?
答：需要，系统测试计划属于项目阶段性关键文档，因此需要评审。
4.Alpha测试与beta的区别?
答：Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
Beta测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
5.比较负载测试，容量测试和强度测试的区别?
答：负载测试：在一定的工作负荷下，系统的负荷及响应时间。
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：容量测试目的是通过测试预先分 析出反映软件 系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状 态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试 还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
6.测试结束的标准是什么？
答：用例全部测试。
覆盖率达到标准。
缺陷率达到标准。
其他指标达到质量标准
7.描述软件测试活动的生命周期？
答：测试周期分为计划、设计、实现、执行、总结。其中：
计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；
设计：完成测试方案，从技术层面上对测试进行规划；
实现：进行测试用例和测试规程设计；
执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。 总结：记录测试结果，进行测试分析，完成测试报告。
8.软件的缺陷等级应如何划分？
答：A类—严重错误，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误
B类—较严重错误，包括以下各种错误： 1． 程序错误 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般性错误，包括以下各种错误： 1． 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制 4． 删除操作未给出提示 5． 数据库表中有过多的空字段
D类—较小错误，包括以下各种错误： 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区分标志
9. 当开发人员说不是BUG时,你如何应付？
答：开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要 不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？ 程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不 要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场， 让问题得到最后的确认。
10．你为什么想离开目前的职务？
答：因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的 感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。
11．您认为做好测试用例设计工作的关键是什么？
答：白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
12. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
答：黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序 的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计 或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测 试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某
个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这 一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进 程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试） 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。 验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
面试十大必考题目
面试时，有几个问题是公司面试人员常常会提出的，针对这些问题好好准备，在面试时也就不会哑口无言，无言以对了，下面就面试十大必考题做出分析,也许对HR经理也是一个小参考：
（1） 为什么想进本公司？
这通常是面试官最先问到的问题。此时面试官就开始评断录用与否了，建议大家先判断自己去应徵的工作性质，是专业能力导向呢，或是需要沟通能力，其实现在市场多以服务为方向，所以口才被视为基本能力之一，所以在此时就要好好表现自己的口才，而口才较差者就务必表现出自己的专业能力即诚意，弥补口才不足的部分。
回答这个问题时，一定要积极正面，如想要使自己能有更好的发展空间，希望能在相关领域中有所发展，希望能在公司多多学习等等﹔此时可以稍稍夸一下面试公司，但切记一定要诚恳，不然可是会画蛇添足，得不偿失哦！对于社会新鲜人
的建议则是，由于之前没有工作经验，所以建议你可以坦承的说出自己的动机，不过用语还是要思考一下
（2） 喜欢这份工作的哪一点？
相信其实大家心中一定都有答案了吧！每个人的价值观不同，自然评断的标准也会不同，但是，在回答面试官这个问题时可不能太直接就把自己心理的话说出来，尤其是薪资方面的问题，不过一些无伤大雅的回答是不错的考虑，如交通方便，工作性质及内容颇能符合自己的兴趣等等都是不错的答案，不过如果这时自己能仔细思考出这份工作的与众不同之处，相信在面试上会大大加分。
（3） 自己的优缺点为何？
有许多面试官都喜欢问这个问题，目的是在于检视人才是否适当，求职者的诚恳度等等，在这之前应该好好分析自己，将自己的优点与缺点列张单子，在其中挑选亦是缺点亦是优点的部分，在回答问题时，以优点作为主要诉求，强调可以为公司带来利益的优点，如积极，肯学习是最普遍的回答，而缺点部分则建议选择一些无伤大雅的小缺点，或是上述那些模嶙两可的优缺点作为回答，这样才不会使面试官太过针对缺点做发挥，造成面试上的困难。
（4） 对公司的了解有多少？
这时准备的功夫就派上用场，将你之前所吸收的信息发挥出来吧！至少也要知道公司的产品是哪些，提供哪些服务等等，不然面试官一问当场傻在那儿就糗大了，所以一定要事前准备！
（5） 对工作的期望与目标何在？
这是面试者用来评断求职者是否对自己有一定程度的期望、对这份工作是否了解的问题。对于工作有确实学习目标的人通常学习较快，对于新工作自然较容易进入状况，这时建议你，最好针对工作的性质找出一个确实的答案，如业务员的工作可以这样回答：“我的目标是能成为一个超级业务员，将公司的产品广泛的推销出去，达到最好的业绩成效；为了达到这个目标，我一定会努力学习，而我相信以我认真负责的态度，一定可以达到这个目标。”其他类的工作也可以比照这个方式来回答，只要在目标方面稍微修改一下就可以了。
（6） 为什么要离职?
回答这个问题时一定要小心，就算在前一个工作受到在大的委屈，对公司有多少的怨言，都千万不要表现出来，尤其要避免对公司本身主管的批评，避免面试官的负面情绪及印象；建议此时最好的回答方式是将问题归咎在自己身上，例如觉得工作没有学习发展的空间，自己想在面试工作的相关产业中多加学习，或是前一份工作与自己的生涯规划不合等等，回答的答案最好是积极正面的。
（7） 选择这份工作的原因为何？
这是面试官用来测试应聘者对工作理解度的问题，藉以了解求职者只是基于对工作的憧憬或是确实的兴趣来应徵这份工作，此时之前所强调的事先研究功夫又再
度派上用场，建议你的回答应以个人的兴趣配合工作内容特质，表现出高度的诚意，这样才可以为自己铺下迈向成功之路。
（8） 你认为相关产业的发展为何？
这也是事前准备的功夫，多阅读一些相关的报章杂志，做一些思考，表现出自己对此相关产业的的认识，如果是同业转职者，可强调以自己的经验为基础所做的个人见解，但若是初次接触此一行业，建议采取较为保守的方式，以目前资讯所提供的资料为主作答，表现出高度兴趣及诚意为最高指导原则。
（9） 你希望的待遇为多少？
这是一个非常敏感的问题，其实在目前，一般大型企业在招聘时就会事先说明基本底薪等等薪资待遇为何，而一般中小型企业有许多仍以个人能力，面试评价做作为议薪的标准，所以建议求职者可以利用现在网络科技查询薪资定位的相关资料，配合个人的价值观，经验，能力等等条件，做出最基本的薪资底限，这时建议无工作经验者应采取保守的态度为准，以客观资料作为最主要考量重点，“依公司规定”的回答是不被建议的，这样不但表示出自己对于工作的自信程度不高，在薪资无法符合个人要求时更会造成许多困扰。
（10）在工作中学习到了些什么？
这是针对转职者提出的问题，建议此时可以配合面试工作的特点作为主要依据来回答，如业务工作需要与人沟通，便可举出之前工作与人沟通的例子，经历了哪些困难，学习到哪些经验，把握这些要点做陈述，就可以轻易过关了
软件测试笔试题
一.测试用例设计题：
1.输入三个数据a，b，c，输入三个数构成三角形，测试a，b，c构成三角形，计算其面积（设计测试用例时面积不用实际计算出来，用X代替面积）
1）int a，b，c
2）1>a;b，c
3)int area
2.根据中国象棋中的棋子 “马”的走向路径，画出因果图并形成判定表。
二.逻辑题
1.有3个黑帽子，2个白帽子，让三个人并排站成一排，给这三个人每个人都戴上帽子（最后一个人能看到前面两个人戴的帽子的颜色和样子，中间那个人能够看到自己的左右两个人的帽子的颜色和样子，最前面的那个人什么也看不到），如果问最后那个人自己戴的什么颜色的帽子，他说不知道，那就继续问下一个人。 其实他们三个戴的都是黑色的帽子，最前面那个人知道自己戴的是什么颜色的帽子，为什么？
2.猴子身边有100根香蕉，离猴子家有50米，猴子把香蕉拿回家一次只能拿50根（多一根就会累死），猴子每走1米就吃掉一根，请问猴子到家能拿多少根香蕉？
三.其它
1.软件测试用例设计的关键是什么？
2.软件测试结束的标准是什么？ 逻辑题：
A B C 结论
白 白 白 只有2个白帽子，条件不符合
白 白 黑 如果C第一个说知道那就是C看到AB全为白（会说自己是黑，只有2个白帽子，剩下肯定黑），所以此条件在C说不知道时排除 白 黑 黑
白 黑 白 如果B第一个说知道那就是B看到AC全为白（会说自己是黑，只有2个白帽子，剩下肯定黑），所以此条件在B说不知道时排除 黑 黑 黑
黑 白 白
黑 白 黑
黑 黑 白
好像也不能肯定，但A黑的几率比较大，剩下80%几率黑
第2题：猴子带50根跑25米处放下，吃剩下25根
再回去带50根跑到25米的地方，还剩下25根
2次加起来50根再一起带回去，到家剩下25根
逻辑题 1
从起点先带50个香蕉往前走17米，吃掉17个香蕉。留下16个香蕉在17米处，带17个香蕉返回起点。(n)
从起点再带50个香蕉往前走17米，到17米处，吃掉17个香蕉，不用返回。此时共剩香蕉49个。(j)
从17米处带49个香蕉回家，走33米到家，又吃掉33个香蕉，仅剩16个香蕉带回家。(z)
猴子返回时也要吃香蕉的
X+Y=50;100-3X
转载请注明出处范文大全网 » 软件测试和软件测试面试题
