测试知识点

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

答：有黑盒和白盒两种测试种类，黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。
例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。

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

答：测试用例设计工作的关键是对可行的和不可行的都要考虑。
1、输入
2、详细的操作步骤
3、预期输出
4、实际输出

您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

答：性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能，性能测试常常需要和强度测试结合起来，并常常要求同时进行软件和硬件的检测。

性能测试主要的关注对象是响应时间，吞吐量，占用内存大小（辅助存储区），处理精度等。

在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

答：检测时间，系统环境，硬件环境，严重程度，程式版本，确认人，功能模板，问题描述，详细操作步骤，是否会重现。
测试时间、环境、严重程度、影响版本、确认人、功能模块、问题描述、详细步骤、是否稳定复线、个人分析、备注
问题描述和详细操作步骤要尽可能详细。Bug应该尽量用书面语，对于严重程度比较高的缺陷要在相同环境下测试一遍。
在C\S模式下，如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。

你对测试最大的兴趣在哪里？为什么？

答：最大的兴趣就是具有挑战性。
因为我并不知道哪里会出现bug，在找到一个bug后会很高兴。并且测试需要很强的耐心和细心。我可以很容易的找到一些细节问题。

测试活动中，如果发现需要文档不完善或者不准确，怎么处理？

答：要及时的与项目经理进行沟通协调。要在邮件中详细的把不完善不准确的地方描述出来，并提出自己的意见。

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

答：首先，要有一个明确的目标，详细的阅读需求文档说明。
其次，要对整个测试人员、测试时间、测试进度进行一个预估，并预先进行管理。
最后，要对整个测试流程设定一个规范，所有测试人员都按着规范做事，不能随心所欲的测试。

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

答：测试用例完全执行，测试用例覆盖到所有的测试点，并且缺陷的密度达到客户的需求。

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

答：用户安装文档、用户配置文档、用户使用手册、联机指导，模板示例，用户许可协议等。

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

完整性：用户文档中功能的描述要完整的。不能让用户产生疑问。
一致性：用户文档中的功能描述要与实际软件中的功能一致。不能描述过盛。
**易使用性：**用户文档描述的内容要方便用户阅读并且能够让用户很清楚的知道如何操作。
**图表：**有的时候用图表描述会很明了。
什么是系统瓶颈？
系统瓶颈就是软件在一定的并发量、访问量下无法达到用户的需求。
比如说用户需要在10s内完成一个访问，但是每一次都要12s才能完成，这个就是性能瓶颈，有可能是程序本身的问题，也有可能和操作系统、软件相关。

没有产品说明书和需求文档地情况下能够进行黑盒测试吗？

可以。
这个情况下我们就要进行探索性测试，把软件当成用户需求，一步步进行测试。凭借经验判断功能正确与否，有的时候还可以与项目经理、开发人员一起进行交流沟通，从而进行更好的测试。

完全测试程序是可能的吗？

不可能
测试人员对程序进行测试，只能找出程序中的bug，但是并不能保证程序是没有bug的。
完全的测试要花费很多的人力财力，并且测试的数据量过大，很浪费时间。测试的结果还很多，有的都是类似的，没有必要进行相同的测试。所以完全测试是不可能的。

软件测试的风险主要体现在哪里？

主要体现在没法完全测试。有些问题可能隐藏在没有测到的地方。这样子就被忽略了。客户使用的时候并不熟悉软件是如何操作的。可能有的时候会误点点出问题。这样子的话我们就要承担很大的风险了。

你能不能说下你的3-5年的职业规划？

首先，要巩固自己的测试基础知识，在基本知识扎实的情况下提高理解需求文档地能力。
其次，学习自动化测试工具，并将它运用到测试中。
然后，在测试技术达到一定程度后，要学会如何带领一个测试团队。
最后，争取在最快的时间内达到测试经理的水平。

一个缺陷测试报告的组成？

环境（软硬）、模块、人（监督人、开发人）、版本、bug相关（编号、标题、优先级、输入、输出、复现步骤）
缺陷编号、缺陷标题、缺陷描述、缺陷的优先级、缺陷的重要程度、缺陷所述的模块、缺陷所属的版本、缺陷所属的开发人员、输入数据、输出结果、缺陷分析等。

软件的评审一般由哪些人员参加？其目的是什么？

参加人员：客户、项目经理、开发人员、测试人员
目的：查看软件在未正式投入运行前是否还存在问题。对于不同软硬件平台能否正常运行，是否有与客户理解不一致的地方，同时可以对一些可以改进的地方再多加改进。

**什么是兼容性测试？

兼容性测试是检查软件在不同软件平台，硬件平台上是否可以正常运行的测试。主要查看软件在不同操作系统、浏览器、数据库中是否运行正常。

**？当测试过程发生错误时，有哪几种解决办法？

答：
1）跳转到别的测试过程
2）调用一个能够清除错误的过程
3）退出过程，启用另一个
退出过程和应用程序，重新启动Windows，在失败的地方重新开始测试

怎样做好测试计划？

明确目标、计划、测试点（重难点）、安排（时间、人）、标准、测试技术
答：
1）理解系统。从整个系统的高度了解被测系统必须满足的功能和非功能性需求。利用涉及整个系统的文档，形成对系统的整体了解。
2）及早介入。为了深入了解项目，测试人员应该在系统的开始阶段介入，可以增加对客户需求，客户问题，潜在风险以及最重要的功能方面的理解
3）测试期望。程序员的期望是什么？客户的期望是什么？销售对测试的期望又是什么？测试目标必须是绝对的，以免说不清是否达到目标。
4）吸取教训。把以前工作中学习到的经验教训运用过来，对确定测试策略很有作用。
5）工作量的大小。完成测试需要多少工作量？需要多少人员？
6）技术选择。系统会采取什么技术？系统会采用什么架构？这些信息有助于确定测试策略和测试工具。
7）时间表。系统开发和测试分配的时间有多长？截止日期是什么时候？

测试用例如何设计的？

PRD、开发技术文档、分模块细致、脑图、详细、测试方法
答：在测试用例的设计之前首先要仔细阅读开发的详细设计文档，充分了解产品的详细功能，不清楚的地方与开发人员进行沟通，搞懂每个功能，尽量详细到输入框、按钮等小功能，功能点清楚之后按照功能模块分类进行用例编写。在具体的用例设计中会运用到等价类边界值等黑盒测试方法

** 什么是bug？

答：软件的bug指的是软件中（包括程序和文档）不符合用户需求的问题。
常见的软件bug分为以下三类：
没有实现的功能
完成了用户需求的功能，但是运行时会出现一些功能或性能上的问题
实现了用户不需求的多余功能

***请问功能测试和性能测试的区别是什么？

答：
1）测试目的：
功能测试：检测实际软件的功能是否符合用户需求，测功能是不是全部实现，某个实现是不是有BUG。主要为了发现以下几类错误：
A、是否有不正确或遗漏的功能？
B、功能实现是否满足用户需求和系统设计的隐藏需求？
C、能否正确接收输入？能否正确输出结果？

性能测试：验证软件质量的三个质量特性，可靠性，正确性和效率。主要是测试产品的健壮性
2）测试方式：
功能测试按照系用例，按照系统需求说明书和测试用例，对产品的功能一步步进行测试。找出产品功能是否全部实现
性能测试：一般都使用性能工具对产品的健壮性进行评估。通过创建场景和虚拟用户模拟真实环境，进行压力测试和负载测试。

**什么是兼容性测试?兼容性测试侧重哪些方面?

主要检验的是软件的可移植性，检查软件在不同的硬件平台软件平台上是否可以正常的运行。
细分会有：平台的兼容，网络兼容，数据库兼容，数据格式的兼容等。

白盒测试和黑盒测试的区别？

黑盒测试是功能性测试，一般采用穷举输入测试，不会考虑内部的逻辑和实现。包括兼容性测试，安全性测试，压力测试，性能测试。
白盒测试是结构测试，一般是穷举路径测试，检测内部逻辑驱动结构。 – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定－条件覆盖 – 条件组合覆盖 – 路径覆盖。

静态测试和动态测试有什么区别？

静态测试是指不运行程序本身，仅通过分析程序文档结构，软件执行过程，检测程序的正确性，主要有变量，借口，递归等。
动态方法是指运行程序，检查运行结果与预期结果对比差异，并分析抗压性，健壮性等，这种测试包括三部分：构造测试实例，执行程序，分析程序输出结果。
区别一：静态测试是用于预防的，动态测试是用于矫正的
区别二：多次的静态测试比动态测试要效率和效益高
区别三：静态测试综合测试程序代码
区别四：在相当短的时间里，静态测试的覆盖度能达到100%，而动态测试经常是只能达到50%左右，原因动态测试发现的bug大部分只是在测试实际执行的那部分代码
区别五：动态测试比静态测试更花时间
区别六：静态测试比动态测试更能发现 bug
区别七：静态测试的执行可以在程序编码编译前，动态测试只能在编译后才能执行
区别八：静态测试能发现动态测试所不能发现的一些错误，比如:”Syntax error,code that hard to maintain,code that hard to test,code that does not confirm to coding standard, and ANSI violations”

***什么是loadrunner

是一个自动化负载测试工具，通过模拟上千万用户实施并发负载及实时性能检测，他能预测系统行为并评估系统性能，原理是通过代理方式获得客户端与服务器端的数据流。分为用户动作设计，场景设计，测试数据设计三个部分。

Beta测试与Alpha测试有什么区别?

Beta是用户实际使用的测试，没有开发者在场，Alpha测试是公司内部测试，有开发者监控。

工作版本的定义

一般一个软件在不断的升级优化中会产生不同的版本号，每一次变化较大或有重大特点出现的时候，会升级版本号第一个号，比如1.x，2.x，版本发布后一般会有bug修复的版本，这时候就是1.x,2.x等。

****什么是桩模块？什么是驱动模块？

集成测试前要为被测模块编辑一些模拟其下级功能的子模块的替身，以代替被测模块的借口，接受或者传递数据，这些假模块被称为桩模块。
驱动模块一般为主程序，它接收测试数据并将这些数据传递到被测试模块。

***什么是扇入和扇出？

扇入是指该模块被调用的次数，扇入大，说明该模块的复用性好。
扇出是指该模块调用其他模块的个数，扇出大，说明该模块的业务逻辑复杂。

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

目的，管理，规范。

1. 明确测试的目标，增强测试计划的实用性
2. 坚持“5W”规则，明确内容与过程
3. 采用评审和更新机制，保证测试计划满足实际需求
4. 分别创建测试计划与测试详细规格、测试用例

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

1. 用户认证机制，
2. 加密机制
3. 安全防护策略，安全日志等，
4. 数据备份和恢复
5. 防病毒系统。

单元测试，集成测试，系统测试的区别？

测试方法不同：
单元测试属于白盒测试，集成测试属于灰盒测试，系统测试属于黑盒测试。
考察范围测试重点不同：
单元测试注重单元内部的数据结构，逻辑控制，异常处理。
集成测试注重模块之间的接口及接口之间的数据传递，
系统测试注重满足需求。
基准不同：
单元测试主要的逻辑覆盖，集成测试主要是接口覆盖，系统测试是测试用例对需求规格的覆盖率。

测试与调试的区别

目的不同–测试的任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题
参与角色不同–测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成
执行的阶段不同–测试贯穿整个软件开发生命周期，调试一般在开发阶段

测试人员应该具备的素质

逆向思维。相当于开发盖房子，测试拆房子
案例：手机中有两条通话记录，进行删除。删除为0后，继续删除。
发散性思维：探求多项答案
案例：测试一台自动售票机。正向，逆向，边界，压力，性能，耗电量，断电，外观，没零钱……
对测试感兴趣
性格特征，有好奇心，成就感，敏感，不浮躁 ，善于怀疑，有批判性思维
能力，快速学习能力，沟通能力，文字能力，开发能力
责任感和承受压力的能力
责任感：测试往往是产品的最后一个检验者；测试的工作成效很难衡量，测试用例执行、bug数目的多少都无法说明产品是否能够交给用户使用。所以，责任感是最重要的测试必备素质之一。
压力：来自开发人员、用户、上级、自己的压力。

一个合格的bug描述应当包括：

发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量
问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
错误重现的步骤
描述问题重现的最短步骤。
预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
注意：不要把多个bug放到一起。在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

产生争执怎么办（处理人际关系）

遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面
先检查自身，是否bug描述不清楚 沟通
如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的时候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后， 好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。
站在用户角度考虑问题。应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
BUG定级要有理有据
BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度考虑定位级别。
提高自身的技术和业务水平。不光要提出问题, 最好也能提出解决方案或思路，这样才能更让人信服。
开发人员不接受时，不要争吵
可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。

Bug评审

要注意的问题：缺陷的评审应该包括以下两个层面，决定如何处理Bug和分析缺陷产生的原因，找出预防的对策
解释：
决定如何处理Bug。
这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表、产品代表。
（1）测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
（2）开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
（3）产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。 这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。
分析缺陷产生的原因，找出预防的对策。 （原因、预防）
缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其是那些重复 出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不再出现。 例如：有些 Bug出现的原因不是简单的“引用为空”之类，而是开发人员的编码不规范或者编程习惯不好而导致，所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复发现相同的Bug的游戏。

禅道是什么

禅道项目管理软件集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程，是第一款国产的开源项目管理软件。
禅道项目管理软件的主要管理思想是基于敏捷项目管理方式——Scrum。
禅道在遵循其管理方式基础上，又融入了国内研发现状的很多需求， 比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。
禅道还首次创造性的将产品、项目、测试这三者的概念明确分开，产品人员、开发团队、测试人员，这三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，最终通过项目拿到合格的产品

软件的生命周期

软件的生命周期应该为：
问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段
但其与瀑布型生命周期模型及其衍生模型（比如V模型，W模型）相符合，而与迭代为基本特征的生命周期模型是不符合的。
随着新的面向对象的设计方法和技术的成熟，新的情况应当是把迭代加入到阶段当中。

软件测试的生命周期

软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交、Bug评审五个阶段，并行与软件的生命周期。

衡量软件质量的标准

我们需要关注以下几点：
正确性：实现的功能达到设计规范并满足用户需求的程度
可靠性：在规定的时间和条件下，维持其性能水准的程度
易用性：用户掌握软件操作所要付出的时间及努力程度
效率：软件执行某项功能所需的计算机资源和时间的有效程度
可维护性：当环境改变或者软件发生错误时，执行修改或者修复所作的努力地程度
可移植性：从一个系统/环境移到另一个系统/环境的容易程度
负面反馈/所有反馈
客户报告的Bug/所有发现的Bug
修复Bug成本/开发总成本
需求变化量/需求总量
具体的要求如下：
功能性的质量指标
功能的正确性：系统功能和用户的实际需求、已定义的产品规范一致
功能的准确性：系统产生的结果在精度允许的误差范围内
功能的完整性：所有功能及其定义清楚、可用
可用性的质量指标
可操作性：容易使用和操作，包括理解用户界面、适应一些特殊用户的可选项等
通用性：数据显示、网络通信接口和用户界面等都遵守已有的软件标准
一致性：在软件开发整个生命周期内建立和使用相同的标准，保证全局变量、数据类型、出错处理的命名和使用一致
可靠性的质量指标
自我恢复能力：当系统的某个功能失效发生时，系统在当前环境下能实现故障自动转移，重新自动配置、继续执行的能力，软件系统具有自我检测、容错、备份等机制，尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等。
健壮性：各种恶劣环境（大数据量、大用户量）下系统能正常工作。
分布性：软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备。
性能的质量指标
有效性：系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化。
完整性：系统具有良好的安全管理，能防止不安全存取系统、防止数据丢失病毒入侵等。
易存取性：对系统的存取权限设置清楚，存取操作方便，存取操作有记录。
可维护性的质量指标
模块化：指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件。
灵活性：容易为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改。
可测试性：测试软件组件或者集成产品时查找缺陷的简易程度。
可追溯性：对一个特殊需求容易找出相应的代码，反之，也可以根据代码找出特定的需求。
兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能力。
可解释性：相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当，容易理解和定位。
可移植性质量指标
适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运行在其他环境下。
易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
可重用性：一个软件组件除了在最初开发的系统之外应用于其他系统的能力。
互操作性：软件系统与其他系统交换数据和服务的难易程度。
可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性