软件测试基础知识点

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，所以软件测试对于软件的质量有明显的改善作用，起到监督和推动作用，能缩短软件开发的周期，加快软件发布的进程