软件测试理论知识（总结）

1.软件的生命周期

市场调研-可行性分析-项目立项-需求分析-系统设计-系统开发-（系统调试）-系统测试-验收（验证）测试-发布上线-维护升级

2.什么叫做软件测试，以及为什么要做软件测试？

软件测试：就是对照或者验证和用户要求不一致的地方，即缺陷性能测试
就是满足用户提出的要求
目的：1、满足用户需求；2、提高用户对软件产品的满意度；3、提高对产品的自信；4、对产品经验的积累，让产品更加完善；5、为产品上线/部署/发布提供依据。
（软件测试就是尽可能的在软件开发中找出软件的缺陷，及我们所说的bug。
软件测试的目的就是让软件个缺陷尽早的被发现和改正，从而达到需求的要求，减少后期维护成本。
完成软件测试，首先要拟定软件测试计划，提交测试计划，再搭建测试环境，然后就是进行软件测试，最后做测试总结）

3.软件测试的流程

软件测试流程：需求分析-梳理功能点（可行性分析）、测试计划阶段(测试计划）、测试设计阶段（测试方案、编写测试用例）、测试执行阶段（测试用例）、测试结果阶段（测试报告）

4.之前在公司，你们只编写测试和执行用例吗？

回答要点【说一下其他的内容，体现你在公司的价值】
（1）和产品、研发一起开会，需求评审。
（2）对整个测试工作输出测试的相关文档，比如测试计划，测试用例，提交并跟踪缺陷。
（3）在完成测试工作以后，还要输出相应的测试报告，反馈给业务部门。
（4）最后还要协助运营同事解答客户反馈的问题，有时候会编写操作说明书。
（5）功能测试完毕之后，项目时间充足，编写一些自动化测试脚本，以及测试工具；

5.之前你做过哪些方面的测试

《1》功能测试：主要是保证功能正常实现，通过场景、等价、边界等方法验证软件的功能是否满足用户的需求。
《2》ui、界面：主要是通过查看排版，文字描述等方面，对界面验证是否满足需求；
《3》易用性测试：主要验证软件是否满足用户常规的操作，然后每一个步骤是否都有相应的提示；
《4》兼容测试：web系统，从不同浏览器，分别率下测试兼容；app系统，从主流手机，型号，分辨率进行测试；
《5》安全测试：权限是否正常；账号和密码复杂度是否有验证；登录次数是否有限制；传输数据的时候是否加密；（是否防止sql注入，是否防止跨站点工具xss）等情况；
《6》接口测试：主要测试的是接口的功能是否满足接口文档，我通常使用jmeter和postman按照接口文档测试接口是否正常；
《7》性能测试：主要是从系统的响应时间，并发，吞吐量，系统资源耗用等情况来测试系统的性能。
《8》app专项测试：adb命令对手机app进行测试，比如monkey命令；弱网、断点测试；

6.测试的分类（了解）

黑盒测试：不需要关注代码，当作一个黑盒，不需要关注里面是怎么实现的，直接测试整体；
白盒测试：代码层次进行测试，这个通常是研发自己测试；
灰盒测试：涉及部分代码，比如性能和自动化；

7.之前你们有没有做过交叉测试，有什么目的

交互测试:是对一个对象如何向其他对象发送消息(调用方法)的测试。

8.什么是回归测试？以及回归测试的目的与策略

回归测试（Regression Testing）：软件在测试或其他活动中发现的缺陷经过修改后进行的测试。
目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。
（回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。）
策略：

• 完全重复测试：
  重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性。
• 选择性重复测试：
  即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序。

选择性重复测试：
①覆盖修改法：即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
②周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
③指标达成方法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。

9.你们做过几轮回归测试？每轮都做些什么？

我们一般做2到3轮都是可以的；根据时间而定；

1. 第一轮针对每个模块测试完毕之后，主要是整个系统全部回归测试，主要是看每个模块的整理关联运行情况；
2. 第二轮回归测试的时候，主要针对修改了问题的模块以及影响的功能和主流程重点做部分回归；
3. 第三轮回归的时候，在上线之前对全部模块，全部的整体功能在做一次测试，确保上线之前没有问题；

10.缺陷包含的内容

• id：禅道自己创建：001

• 所属的模块：登录模块；

• 版本号：v1.0

• 指派人：xxx

• 缺陷标题：xxxx模块，xxx功能没有实现；xx页面，无法打开；

• 严重程度：严重

• 优先级：非常紧急

• 重现步骤：

  1. 输入网址www.xxxx.xxx
  2. 页面显示无法访问；

• 缺陷状态：激活状态

• 缺陷属性（要素）：标题、所属模块、所属版本、描述（操作步骤）、预期结果、实际结果

• 解决人员、优先级、重要程度、缺陷的状态、发现日期

• 优先级：紧急、高、中、低

• 重要程度：致命、重要、一般、建议

• 缺陷的状态：已激活、已修改、关闭、拒绝、挂起

• 缺陷生命周期：新建-打开-接受-处理完成-测试通过-关闭

11.一个登录模块怎么测试？

1. 功能方面：
   正确的账号，密码是否能正常登录；
   错误的账号，密码，是否能登录
   账号，密码为空，有特殊符号等情况是否等登录。
2. 界面、易用方面：排版，文字描述是否正确，是否方便客户使用。
3. 安全方面：
   登录次数是否验证，账号密码复杂度是否有验证；
   传输是否明文传输，是要加密的；
   账号的权限是否正常；是否sql注入，是否xss攻击；
4. 兼容测试：考虑在不同浏览器，不同的分辨下进行测试；
5. 性能方面的测试：支持多少人并发登录，登录之后响应时间是否正常。

12.开发不认可这个bug怎么办

（1）【演示】当面演示bug是怎么产生。
（2）【沟通】按照需求文档作为依据，和研发沟通，说明判断bug的原因，然后可以听研发的意见，看能否达成意见统一；
（3）【上级反映】：如果还是不能说服研发，和产品经理（项目经理）反馈，如果产品经理确定是bug，上禅道，要求研发必须修改；

13.如果没有需求规格说明书，应该如何测试

1. 找开发要开发文档，比如详细设计文件，来参考做测试；
2. 参考同行业的竞品进行测试；
3. 如果有些功能是集成以前版本的功能，那找以前版本的需求来进行测试；
4. 站在用户的角度，根据自己对产品背景的理解来做测试。
   比如：一个web系统我们可以从功能，界面，易用性，兼容性，接口等几个方面来测试；
   APP的话，我们可以从功能，界面，易用性，兼容性来测试，同时APP还要考虑APP前后台切换，交互性测试，弱网等。

14.请问测试用例怎么评审的

《1》【开会】：首先一般测试经理组织评审会议，我们通常是上午，经理发一个信息，通知全体测试人员开一个小会，进行用例评审。
《2》【评审方向】：主要评审编写的用例对需求是否100%覆盖；描述的标题，步骤等是否准确；还有预期结果和实际结果描述是否完整。
《3》【评审结果】：输出一个文档，对每个人用例提出一些意见；有助于用例的完善和更新；

15.你常用的测试用例编写方法

（1）边界值分析：边界值，就是有明显输入限制的功能，就使用边界值的方法设计测试用例；
（2）等价类划分：功能明显的类型的输入，这个时候才用等价类设计方法，设计出有效的等价，和无效等价；
（3）场景法：通过功能模块主流程，各个备选流程，把每个流程都梳理出来；
（4）状态迁移法：针对每个状态，设计测试用例；
（5）判定表法：是分析和表达多逻辑条件下执行不同操作的情况的工具；
（6）正交试验法：组合实验法。

16.如何编写测试用例

测试用例属性（要素）：1.用例ID；2.用例标题；3.所属版本；4.所属模块；5.前置条件； 6.操作步骤；7.预期结果；8.编写者；9.用例等级；10.编写时间；11.测试结果；12.需求来源

17.软件测试原则

测试的基本原则：1、测试是上下文相关的，2、不可穷尽测试；3、测试应尽早介入；4、杀虫剂悖论；5、缺陷集群性（二八原则）；6、测试证明存在缺陷；7、无错谬误；

18.软件测试分为那几个主要阶段，并简要谈谈各阶段的测试内容及方法

• 软件测试阶段：单元测试（一般由开发）、集成测试、系统测试、验证（验收测试）、回归测试
• 单元测试：单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作；单元测试的目的是检测软件模块对《详细设计说明书》LLD的符合程度。
• 集成测试：集成测试是对单元之间及单元与第三方接口之间的测试，目的是验证接口是否与设计相符，是否与需求相符。（即检测软件模块对《概要设计说明书》的符合程度）
• 系统测试:系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方。
• 验收测试：交付用户部署前，进行验收测试。以用户为主，验收组：项目组成员、用户代表或者系统的其它利益相关者。根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。
• 回归测试（Regression Testing）：软件在测试或其他活动中发现的缺陷经过修改后进行的测试。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。
  回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。

19.你了解哪些测试类型，并简要说明一下

• 按测试策略分类：
  1、静态与动态测试2、黑盒与白盒测试 3、手工和自动测试 4、冒烟测试 5、回归测试；
• 按测试阶段分类：
  单元测试、集成测试、系统测试；
• 其他常见测试方法：
  1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测试 12、恢复测试

20.请写出一个标准的缺陷跟踪处理过程

测试基础知识考试题目（答案）

21.软件生命周期以及测试工程师在期中承担的具体工作

软件生命周期：市场调研-可行性分析-项目立项-需求分析-系统设计-系统开发-（系统调试）-系统测试-验收（验证）测试-发布上线-维护升级

22.验收测试包括哪些内容

按实施组织分：α测试、β测试、UAT测试

• α测试即为非正式验收测试；由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。
• α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始
• β测试是给用户进行测试；β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，即发放一部分给用户进行测试，并要求用户报告异常情况、提出批评意见，然后软件开发公司再对β版本进行改错和完善。β测试也是黑盒测试UAT测试：也就是用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。

23.如何测试一个水杯

• 测试流程：
  需求评审（了解软件，找到功能点(测试点）)-编写测试用例-为保证测试用例覆盖率达到100%，完整度，需要开用例评审-测试执行（测试用例）-提交bug-跟踪bug-回归测试（验证bug）是否修复）-测试结果（测试报告）

• 需求评审：

  • 评审发起人：产品经理
  • 评审参与人：相关的开发人员，相关的测试人员，SQA
  • 以上人员都是必须参加的，这里相关人员是指与需要评审的需求相关的人员，除了以上人员其它的研发人员也可以参加。

• 评审的形式：会议

  • 一般评审有几种方式：自审，内审，外审，较为严谨的做法就是外审，召开评审会议。

• 评审之前的准备：

  • 在评审之前，产品经理会事先发邮件的形式，通知相关人员会议主题，会议时间，会议地点等，并且会抄送给各部门的主管予以知会。
  • 临近评审之时，产品经理会再次发消息知会参会人员，以确定参会人员数量，这时一般产品经理会提前到达会议室做好准备。

• 评审之时：

  • 需求评审之时产品经理作为主讲人，会针对需求文档进行详细的讲解和说明，那这时，开发人员和测试人员做什么呢？
  • 开发人员：对产品经理给出的需求，考虑如何用程序语言实现功能，主要是考虑可行性。
  • 测试人员：对产品经理给出的需求，理解需求，针对有疑问的需求提出见解。
  • 产品经理针对开发人员和测试人员提出的问题，作出解答，如果当场不能确定的，需要做好批注，形成需求问题列表。

• 评审之后：

  • 需求评审后，产品经理将最终确定出来的需求文档，以邮件的形式发送给团队所有成员。如果评审后的需求文档改动过大，需要再次发起会议，再次评审。

缺陷管理流程：

缺陷从提交到关闭的步骤如下：

1. 测试工程师提交缺陷。开始测试后，如果在测试过程中发现了Bug，测试工程师会在Bug 管理系统中提交相关Bug的记录。
2. 测试经理审核Bug。测试工程师提交Bug 后，测试经理会对Bug 进行审核，以确定该Bug 是不是真实有效，避免提交无效或重复Bug 的现象。如果提交的Bug 是一个无效或重复的Bug，那么测试经理会将流程驳回，反之则通过Bug 的审核。
3. 开发经理审核Bug。测试经理通过审核后，Bug 的流程会传递到开发经理，开发经理同样对Bug 进行审核，以确定该Bug 是否有效。如果确定是Bug，开发经理则将Bug 指派给相关开发工程师，由相关开发工程师对Bug 进行修复;如果开发经理认为不是Bug，Bug 流程则会被驳回给测试经理，此时处于一个比较尴尬的局面，即开发经理与测试经理对缺陷的看法不一致，此时需要进一步沟通或启动相关评审来确定该Bug 是否真的是一个缺陷。如果确定真的是Bug，则分配给相关开发工程师进行修改;如果确定不是Bug，该Bug 将会被标识为无效Bug。
4. 开发工程师修复Bug。当开发经理确定是一个真实的Bug 时，相关开发工程师则需要对Bug 进行修复。
5. 测试工程师验证Bug修复情况。当开发工程师修改Bug 后，测试工程师需要对修改的Bug 进行验证，以确定该Bug 是否修复，同时需要确定的是修改该Bug 是否引起了新的Bug。当Bug 被正确地修改后，就可以关闭该Bug，否则该Bug 将会被重新开启。