软件测试基础知识点

1.对某软件，你是怎么进行测试的？

答：外观界面、功能、性能、安全性、兼容性，易用性

　　外观界面测试：主要是测试软件界面功能模块的布局是否合理、总体风格是否一致、界面中文字是否正确、命名是否统一，页面是否美观、文字、颜色、图片组合是否完美等；

　　功能测试：测试软件所呈现给用户的全部功能点是否都能正常使用和操做，是否知足软件需求规格说明书的要求

　　易用性测试：测试软件是否易操做，主观性比较强，站在用户的角度体验软件产品好很差用

　　兼容性测试：测试该软件与其余软件的兼容能力，主要考虑软件与浏览器的兼容能力，包括分辨率的兼容

　　安全性测试：测试该软件防止非法入侵的能力

　　性能测试：测试软件在不一样环境的压力下是否能正常运转，很重要的一个指标是系统响应时间，例如多人同时访问某个网页时，网页是否能在规定时间内打开等指标

2.为何要对需求文档进行评审呢？

答：消除歧异，完善需求细节，并达成共识

3.如何评审需求文档？

答：正确性：对照用户的原始需求，检查产品经理制定得软件规格说明数书是否偏离了用户原始需求的意思

　　明确性：检查软件需求规格说明书中的每个需求项是否存在一些含糊其辞的词汇，用因而否清晰，是否有歧义

　　完整性：对照用户的原始需求，检查产品经理制定的软件需求规格说明书是否覆盖了用户所提出来的全部需求项，每一个需求项有没有遗漏用户所提出的一些必要信息

　　优先级：软件需求规格说明书对哪些功能比较重要，哪些功能比较次要是否做了标号和编号

　　一致性：检查软件需求规格说明书里面的内容先后是否一致，确保不冲突，不矛盾

　　限制性：每一个需求项里是否清晰的描述了这个软件能作什么，不能作什么，能输入什么，不能输入什么，能输出什么，不能输出什么

4.软件质量：用户满意，表示软件质量很好，不然很差

5.黑盒测试：是指只测试软件外部的功能特性，而不去测试软件内部的代码结构，黑盒测试也称为功能测试；

　白盒测试：是指只测试代码结构，而不测试软件的外部功能点

6.软件测试分类：

测试类	测试方法	执行者	测试依据	测试内容
单元测试	白盒	开发人员	详细设计文档、概要设计文档	代码及代码的逻辑结构
集成测试	白盒为主， 黑盒为辅	开发人员	详细设计文档、概要设计文档 软件需求规格说明书	模块与模块之间的接口
系统测试	黑盒	测试人员	软件需求规格说明书	软件的外观界面、功能、易用性、兼容性、安全性、性能
验收测试	黑盒	用户	软件需求规格说明书	软件的外观界面、功能、易用性、兼容性、安全性、性能

7.需求文档：就是描述软件要作成一个什么样的产品的说明文档

8.测试工做从何时开始的？

答：我以前作的测试工做，通常都是从拿到需求文档的时候就开始了，主要的工做就是评审需求文档，评审的目的是消除歧义，完善需求细节，并达成共识

9.什么叫8/2原则？

答：是指80%的错误是集中在20%的·模块里，常常出错的模块经修复后还会出错

10.你有写过软件测试计划吗？

答：嗯，有写过。不过咱们写的是本身所负责模块的测试计划，项目的总体测试计划通常由测试经理来写的

11.软件测试计划包括哪些内容？

答：第一个是测试的范围，主要是指的是系统测试的范围以及本轮测试是测试所有的模块仍是说只测试部分的模块，是否须要进行外观界面、功能、易用性、兼容性等测试

第二个是测试环境，指的是测试人员是在什么样的软硬件环境下测试软件

第三个是测试策略，它的主要内容有进行测试的依据、系统测试准入和准出标准、测试工具的选择、测试的重点及方法

　　　　其中，测试依据：须要指明软件测试依据的标准文档有哪些。其中有两个重要的文档，一个是软件规格说明书，另外一个是测试用例

　　　　测试的准入标准：指系统知足什么条件后才能开始进行系统测试，一般测试的准入标准是指经过冒烟测试

　　　　测试工具选择：须要指明在测试过程当中会使用哪些工具。例如JIRA和Selenium这两款测试工具

　　　　测试的准出标准：也叫测试经过标准。未关闭BUG的数量在不超过多少的状况下。可视为经过测试。

　　　　测试的重点及方法·：在作系统测试的过程中，应当标明要测试的重点模块和区域。测试方法是黑盒测试，也就是手工测试

第四个是测试管理，指的是测试任务的分配、时间进度的安排、测试与开发的沟通方式等内容。

　　　　测试任务的分配：肯定整个测试范围后，测试经理会根据团队中每一个测试人员的特长分配相关任务，主要的两项工做为：一个是测试用例的设计和编写，另外一个是测试用例的执行和操做

　　　　测试进度的安排：根据实际分配的工做任务来指定每一个测试人员进行每项测试工做的起始时间和完成时间

　　　　沟通方式：沟通方式有不少种，经常使用的有面对面的沟通、电子邮箱、以及BUG管理工具

第五个是测试风险：常见的风险有：需求文档理解不透彻、测试时间估计不足及测试执行不到位

　　　　需求文档理解不透彻：会致使测试人员对软件功能模块的理解存在误差而影响判断遇到的问题，从而产生无效BUG

　　　　测试时间估计不足：因为对本身工做量的估计不足而致使在规定时间内没法完成相应任务，会直接影响整个测试工做进度，形成测试计划推迟的风险

　　　　测试执行不到位：有些测试人员存在一些侥幸心理，认为有些功能模块不重要而不去执行。

12.什么是冒烟测试？

答：首先从所有用例中筛选一些基本的功能点进行测试，若是没有问题才进入系统测试中，若是有问题则中止测试，待开发人员修复好后再进入系统测试的用例执行。选取qifenzhiyi到十五分之一之间

13.什么是测试用例，它的基本元素有哪些？

答：测试用例就是用于测试的一个例子。主要有如下基本元素：

用例序号：---编号

测试模块：---软件的某个功能模块

前置条件：---网络正常，须要的数据正确无误
测试环境：---软件环境：操做系统windows，IE/Firefox
---硬件环境：PC台式机：CPU/内存/硬盘
操做步骤：---执行测试操做的每一步的详细描述，相应数据展示
预期结果：---需求规格说明书中明确的需求结果
实际结果：---执行操做后实际得出的结果
是否经过：---实际结果与预期结果是否一致，一致为经过，否：则不经过
备注：---其余要求说明等

 14.测试用例的做用

答：可让测试人员做为测试的标准，并指导测试人员进行测试工做，测试人员能够按照测试用例的操做步骤和具体数据逐一执行测试，以发现问题并提交BUG，最终来改善软件的质量

15.测试人员是依据什么来设计测试用例的？

答：软件需求规格说明书

16.功能测试的用例设计方法：等价类划分法、边界值分析法、错误推测法、正交表分析法、场景法、因果图断定法

等价类划分法：把全部可能输入的数据划分为若干个区域，而后从每一个区域当中取少数有表明性的数据测试便可。把符合需求规格中规定的数据称为有效数据，把不符合需求规格中规定的数据称之为无效等价类；

边界值分析法：取稍高于或稍低于边界的一些数据进行测试，程序在处理边界数据的时候比较容易出错

错误推测法：指的是测试人员凭本身的直觉、测试经验、发散思惟去设计一些测试点，而这些测试点可能致使软件出现错误。主要有：超长混合字符串、全角字符串、数字0、单引号等

正交表分析法：能够有效的减小用例设计个数的方法，就是在测试有多个输入项时，测试人员能够测试其中一个输入项的时候能够默认其余的输入项都是正确的

场景法：用户可能给到一个场景或简单的业务流程或一段简单的文字需求描述，此时测试人员须要根据本身已有的业务流程或已有的场景和需求，充分发挥对用户实际业务的场景的想象

因果图断定法：咱们输入的条件可能有不少种，每一种条件之间的组合均可能造成一个新的结果，咱们把其中的条件和结果经过图形的方法表现出来，最后经过断定表进行展示

17.用例设计思路：首先分析需求规格，再进行基本功能的测试点分析

18.从哪几个方面来对测试用例进行评审？

第一：测试用例是否依据软件需求规格说明书来写的

第二：测试用例中的执行步骤、输入数据是否清晰、简洁、正确；对于重复度高的执行步骤，是否进行了简化

第三：每一个测试用例是否都有明确的预期结果

第四：测试用例中是否存在多余用例

第五：测试用例是否覆盖了需求规格中全部的功能点，必需要测试什么功能、若是有些功能的用例没有设计到会形成什么后果

19.您是怎么设计测试用例的？

答：嗯，我以为设计一个功能模块的测试用例主要是基于如下的几个方面：

　　首先最主要的仍是要参考软件需求规格说明书，而后尽量挖掘出更多的需求细节进行用例设计

　　第二：能够凭借本身的一些测试经验和常识来设计

　　第三：能够参考其余同事曾写过的测试用例

　　第四：能够经过网上的一些资料做为补充

20.如何保证测试用例的质量（怎么样的用例才算得上是一个好的用例）

答：第一：要确保测试用例是针对需求规格来写的，确保测试点能覆盖到全部的需求点

　　第二：要保证操做步骤、具体数据、预期结果的清晰性、间洁性、明确性；以确保测试用例的可操做性和可复用性

　　第三：确保有足够多的异常测试用例（若有效等值类之外的测试点），同时要确保没有多余的重复的用例

　　第四：就是要对测试用例进行评审

21.若是没有需求文档，你是如何设计测试用例的？

答：首先我会大致的测试一下软件，如边界值、输入数据类型等需求不明确的问题反馈给本身的上司或产品经理，待产品经理给出相应的标准后在进行设计

　　第二：若是在测试软件过程当中发现有些功能模块的需求很是不明确，已经影响到用户对产品功能的正确使用，对于此类的重大问题，我会及时反馈

　　第三：我会经过参加项目的各类讨论会、会经过以往的测试用例、以往所提的bug中、以往的用户手册和过程帮助文档；或去咨询产品人员的方式尽量的去了解相关的需求信息，以此为基础设计测试用例并测试软件

　　第四：能够对找照软件的功能直接设计用例，而后提交给测试组

22.B/S结构和C/S结构

答：B/S结构是Browser/Server，即浏览器/服务器，是使用浏览器访问服务器的模式

　　C/S结构是Client/Server，即客户端/服务器，在客户的电脑上要安装一个软件，而后使用客户端的软件去访问服务器的模式

23.网页的兼容性测试你是怎么作的？

答：对于网页兼容性这一块，

　　第一：考虑各类浏览器对前台页面的兼容性测试

　　第二：考虑分辨率的兼容性

　　第三：考虑其返回页面的相应时间

 24.回归测试：开发人员把bug修复好后，测试人员从新验证下bug是否被开发人员修复好

25.一个完整的bug包括哪些内容？

答：bug编号、软件名称和版本号、测试环境、bug等级、bug的概要、bug的具体描述、bug处理的优先级、bug提交人、bug发现的时间、bug的处理人、bug的状态（new，open，fixed已修复，reopen，rejected，close）、必要的附件、其余备注

26.你和开发人员就bug发生了争议你是怎么处理的？

答：首先的话我会对事不对人，不能由于bug而激化了双方的矛盾

　　第二：多是我写得bug开发人员看不懂，耐心的和开发人员描述清楚，并带有充足的依据和理由

　　第三：若是写清楚了，但开发人员仍是不肯意修改的话，能够找一个合适的时间、心平气和的和开发人员沟通，说明bug的产品质量可能产生的不良影响，沟经过程不能意气用事

　　第四：经沟通后，若是开发人员仍是不肯意修改，能够向测试经理汇报，或由测试经理召开bug评审大会

27.如何提一个高质量的bug？

答：第一：写清楚bug的概要，要使开发人员一看到bug概要的时候就知道这个bug单提的是什么bug

　　第二：bug的具体描述，也就是bug的重现步骤，bug记录的细节越详细越好

　　第三：能附上相应的截图和日志

　　第四：所测的版本号和测试的环境要写清楚

28.若是你发了一个bug，但以后也没有重现过了，你怎么办？

答：首先我会截图，并收集日志，以保留好测试现场；

若是说这个bug只出现过一次，后面就没有出现过，那么我会千方百计让这个bug重现；

万一没有重现，我仍是会提交bug给开发人员，有截图和日志也一并附上，若是开发人员要求重现，那后期就继续观察，若是最终没有重现，则把此问题反映给测试经理，汇同开发人员进行评审和商量

29.一份软件测试报告都包含哪些内容？

答：测试报告是一份描述软件的测试环境、测试依据、测试过程、测试范围、测试结果分析、系统存在的风险以及测试结论；

　　测试过程：测试人员、测试时间、测试地点、测试的版本等信息点。

　　测试环境：软件和硬件环境

　　功能点测试范围：具体所测模块及分布在该模块上的全部功能点

　　测试结果分析：bug的问题汇总、bug的分布状况

　　系统存在的风险：系统中遗留的bug会对软件形成什么的风险

　　测试结论：在报告的最后给出一个是否能上线的结论

30.软件测试工做结束的标准是什么？

答：第一：已经按照测试计划中的安排完成了全部的测试工做

　   第二：测试用例已经所有执行完毕，并进行了归整

　　第三：每一个测试人员手上的bug都处于关闭状态或者是被清理完成

　　第四：回归测试所有执行完成，已没有发现能够影响产品上线的bug，软件产品具有了上线标准

　　第五：每一个测试人员所负责的测试报告已完成，并提交给了测试经理

31.软件的测试流程是怎么样的？（说一下测试流程）

答：有如下几个阶段：需求评审，测试计划制定，测试用例设计，用例评审、环境搭建、测试执行（提交bug，回归测试）、写测试报告

32.你如何理解测试这分工做？（谈谈对软件测试的理解）

答：软件测试的主要任务是发现软件中的bug，因此软件测试对于软件的质量有明显的改善做用，起到监督和推进做用，能缩短软件开发的周期，加快软件发布的进程

32.bug的处理流程：

（1）首先是测试人员发现了一个bug并且在bug缺陷管理工具里没有相同的bug，就须要填写相
关的bug信息，并提交给测试经理
（2）若是这个bug不是一个真正的bug, 测试经理须要close这个bug

（3）测试经理须要审查bug的各类信息都完备，若是有信息不完整，他须要把状态改
成”feedback（反馈）” 并从新发给提交者

（4）若是这个bug是一个真正存在的bug, 测试经理须要把这个bug分配给相关的开发团队的项
目经理, 而且把bug状态改为Assigned（分配）

（5） 项目经理审查bug,而且分配给相应的开发人员去改正。

（6）开发人员收到bug之后，对相关的bug进行改正，而且从新分配给提交bug的测试人员而且
把状态改为”Fixed（修复）”

（7）测试人员须要对这个bug进行从新测试，保证相关的缺陷已经改正，测试人员能够reopen （从新打开）这个bug，若是缺陷依然存在，从新分配给相关的开发人员，bug若是缺陷已经改 正，则关闭这个bug。