软件测试常见问题之测试基础篇

软件测试基础概念

1、什么是软件测试？其目的是什么？你怎么看待软件测试？

　　是为了发现错误而执行程序的过程。在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
　　目的是暴露程序中的错误。发现测试对象与预期的差异。具体地不同测试阶段对应不同测试目的。

　　软件测试工作者要站在用户的额角度思考问题，从用户的实际使用环境、习惯着手验证被测对象应用表现。与软件开发的创造性思维不同，软测活动的思维模式则是破坏性的通过构建正常、异常输入去考验被测对象的健壮性。测试工作是一项极其重要的质量保证活动。因为测试部门是软件发布质量把控的出口，又可能是用户意见反馈的入口。

2、软件测试的生命周期？各阶段对应的工作？

　　测试周期是指从测试项目计划建立到BUG提交的整个测试过程，包括软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交五个阶段。软件测试周期与软件生命周期并行，存在于软件生命周期的各个阶段。

　　需求分析阶段：测试人员了解需求、对需求进行分解、分析，得出测试需求。

　　测试计划阶段：根据需求编写测试计划/测试方案。确定测试范围，测试通过的标准，测试的时间、人力、物力、资源、风险等。输出测试计划文档

　　测试设计、测试开发阶段：测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例。输出测试方案文档。

　　测试执行阶段：测试执行阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试。

　　测试评估阶段（BUG提交）：在执行的过程中记录、管理缺陷，测试完成后编写测试报告，进行测试评估。

3、测试计划和测试方案的内容和区别？

　　测试计划确定测试范围，测试通过的标准，测试的时间、人力、物力、资源、风险等；

　　测试方案确定测试的方法、类型；确定用例设计的方法，缺陷管理流程；缺陷严重程度的划分、用例格式等。

　　测试计划一般由测试经理、测试主管或项目测试负责人制定，属于管理文档，解决的是做什么的问题。测试方案由测试工程师设计，属于技术文档，解决的是怎么做的问题。

4、需求评审的内容？参与人员？测试人员为什么要参与需求评审？

　　内容：同步产品对于需求的详细设计,收集大家对于需求的各种反馈。

　　参与人员：产品、设计、研发、运营，测试等其他岗位的人

　　当面同步需求，对于需求的合理性、全面性的反馈。

5、测试用例的设计方法有哪几种，分别对应什么典型业务功能？

　　等价类划分

• • 等价类即是某个测试对象的输入域的集合。是一种常用的黑盒测试方法。它将全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件，从而用少量代表性的测试数据取得较好的测试结果。等价类可分为有效等价类和无效等价类。
  • 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。
  • 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；
  • 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类
  • 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类
  • 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）
  • 实例：三角形等价类划分https://blog.csdn.net/slforeverlove/article/details/48296121
  • 业务：邮件注册功能。
  • 测试用例实际就是各个等价类的排列组合。

　　边界值分析

• • 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 
  • 大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
  • 构造测试数据是要考虑3个点的选择：上点，即边界值点；内点，即与范围内的点；离点，离上点最近的点，当域是开区间时离点在域内，闭区间时离点在域外。
  • 边界值设计法为每一个有效等价类多增了2个上点的用例。为每一个无效等价类选择的是离点的用例。
  • 应用场景与等价类相同

　　判定表驱动分析

• • 在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

  • 判定表通常由四个部分组成。

    1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

    2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

    3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

    4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

　　因果图法

• • 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视。
  • 针对需求规格，将原因及影响对应关系分为两组：输入与输出，输入与输入。每种又分别对应四类
  • 输入与输出：关系主要有恒等、与、或、非。
    1. 恒等：输入a，一定产生对应的e。没有a的输入，就不会产生e的输出。
    2. 与（^）：只有同时有a和b的输入，才能产生对应的e。
    3. 或（v）：输入a或者b，就可以产生对应的e
    4. 非（~）：只有不输入a，才能产生对应的e
  • 输入与输入：异、或、唯一、要求。
    1. 异：即互斥，所有输入条件只能成立一个，可以一个都不成立。
    2. 或：所有输入条件至少成立一个，可以多个条件共存
    3. 唯一：所有输入条件中只能且必须成立一个。
    4. 要求：如果输入条件a发生了，那么b也会发生。

  • 采用因果图法设计测试用例的步骤：

    1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

    2)分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

    3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

    4)把因果图转换为判定表。

    5)把判定表的每一列拿出来作为依据,设计测试用例。

　　场景设计

 

• • 用事件触发来控制流程的，对于涉及业务流程的软件系统，使用场景设计法设计是比较恰当的，比状态迁移类多了些异常的东西。
  • 基本流：输入经过每一个正确的流程运转最终达到的额预期结果。
  • 备选流：表示输入经过每一个流程运转时可能产生异常情况，但经过纠正后仍能达到预期的结果。
  • 异常流：表示输入经过每一个流程运转时，产生的异常终止的现象。

 

　　错误推测法

• • 基于经验和直觉推测程序中所有可能存在的各种错误, 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。从而有针对性的设计测试用例的方法。

6、缺陷的级别及管理流程？

• • 缺陷等级一般划分为四个等级，致命、严重、一般、提示。

致命（Uregent）：主流程无法跑通，系统无法运行，崩溃或业务中断，应用模块无法启动或异常退出，主要功能模块无法使用。如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循环报错，无法正常退出。

严重（very high）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误

一般（Medium）：界面、性能缺陷。如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条

提示（Low）：易用性及建议性问题。如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。

• • 缺陷管理流程说明：

1、测试人员填写bug并（Assign）给测试负责人，状态为New；

2、测试负责人（review）缺陷。主要检查报告规范，以及确认bug。若是有效的bug，状态变化为open，并分配给开发人员；若bug无效则指派（Assign）回给测试人员，bug状态依旧为new

3、开发人员根据缺陷描述确认是否时缺陷，若是则进行修复，修改完成并进行单元测试后，将bug的状态变为fixed，在comment中说明修改方法，并指派给缺陷发现人。若不是缺陷或者延期修改的，将bug状态变化为Rejected，同时也在comment中注明原因。

4、测试人员每天查看自己提交的bug的状态变化，应该成为每个测试人员的例行行为；

5、当bug的状态变为fixed时，测试人员打开该bug，开始对该bug进行回归测试；如果该bug回归测试通过，则状态变为closed。否则bug的状态变为reopen（必须说明reopen、closed状态变化原因或者操作过程）；

6、若对（Reject）的缺陷进行再次确认后测试人员认为是缺陷，则需（Reopen）缺陷至开发人员出，并comment原因。

7、如果回归测试通过，可是修改的同时又引入新的bug，则重新提交bug，状态为new。如果需要的时候注明相关联的bug号；

8、只有当所有的bug状态为closed，才可发布版本。

　　注：每当bug状态改变后，必须给出相应的注释和说明，以便查看bug生命周期的变化情况。

7、测试准入和通过的标准？

• 准入标准：

1. 开发人员编码结束，并已完成单元测试
2. 需求说明书规定的功能或开发人员提交的功能说明书的功能均已实现
3. 冒烟测试通过，界面上的功能均实现，符合设计文档规定的功能。
4. 开发人员向测试部提交《测试申请》

• 通过标准：

1. 达到100%需求覆盖
2. 所有1、2级用例被执行，3级用例执行率达到95%，4级用例执行率达到80%
3. 1级、2级缺陷100%修复，3级95%修复，4级60-80%修复
4. 具体缺陷问题需要和用户沟通确认。

8、测试模型有哪些？

• 瀑布模型（传统）：需求分析–设计–编程–测试–维护
• V模型：RAD（Rap Application Development，快速应用开发），由于其模型构图形似字母V，所以又称软件测试的V模型。大体可以划分为以下几个不同的阶段：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。适合开发周期短的项目。

  缺点有：测试介入较晚，滞后于研发，如果发现前期问题，修复成本非常高；不利于需求的变更；用户只能在项目交付时才能拿看到成品

• W模型：相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。测试的对象不仅仅是程序，还包括需求和设计

   缺点：需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

• X模型：对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。右上半部分，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。X模型还定位了探索性测试（右下方）。

   解决滞后于开发的问题

• H模型：相对于V模型和W模型，H模型将测试活动完全独立出来，形成了一个独立于研发的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型指出软件测试要尽早准备, 尽早执行。

  缺点：管理型要求高、要求能够很好的定义每个迭代的规模、测试就绪点分析困难

• 敏捷测试模型（scrum）：关注需求变更、轻文档，快速迭代

• 前置测试模型：将开发和测试的生命周期整合在一起,标识了项目生命周期从开始到结束之间的关键活动。如果其中有些活动没有得到很好的执行,那么项目成功的可能性就会因此而有所降低。验收测试和技术测试保持相互独立。

9、如何保证测试覆盖率？测试用例评审方式，如何组织，为什么要评审，评审内容？

• 测试覆盖率：

1. 测试需求分析要全面，要进行测试需求评审，保证其准确性和完整性
2. 针对测试需求进行用例设计时使用种测试用例设计方法：首先进行等价类划分，必须结合边界值分析法，可以使用错误推测法追加一些测试用例其他的设计方法要根据具体情况选用。 
3. 用例设计完后要进行用例评审会议
4. 用例执行过程中要保证用例100%覆盖，要继续对测试用例补充完善，确保提高测试覆盖率。
5. 测试过程中及时更新测试需求和测试用例
6. 要将测试需求、测试用例以及发现的bug关联起来，便于管理和跟踪，建立需求跟踪矩阵，同时也便于查看覆盖率。

• 测试用例评审方式：
  1. 召开评审会议。与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录；
  2. 通过邮件、及时通讯工具与相关人员沟通。
• 如何组织：首先，测试人员提前准备好用例评审的资料，提前定好会议室发出会议邀约并附上用例评审资料；评审过程中，测试人员要做好会议纪要，如果用例有需要补充或修改的地方快速在Xmind上标注清楚，便于会后进行整理补充测试用例。用例评审会议后整理完善测试用例并再次同步
• 目的和内容：
  1、消除产品、开发、测试三方对需求文档理解的偏差

  2、保证每个测试人员的质量标准与项目要求标准达成一致；

  3、为了减少测试人员执行阶段做无效工作；（执行无效case，提交无效问题）

  4、集多人的思想来提高测试的覆盖率。

  内容主要有：需求评审、需求实现流程图评审、测试大纲评审、测试用例检查

 

10、敏捷模型？瀑布模型？

　　详见题8

11、测试报告的内容有哪些？

测试报告的内容可以总结为以下目录：

· 首页：标题（报告名称+测试范围）、日期、版本变化历史等

· 引言：目的、背景、缩略语、参考文献

· 测试概要：测试方法（黑盒白盒）、范围（测试用例设计）、测试环境、工具

· 测试结果与缺陷分析：功能、性能（覆盖分析、缺陷曲线图等）

· 测试结论与建议：项目概况、测试时间 测试情况、结论性能汇总

· 附录：缺陷统计

12、测试过程中如果发现不可重现的缺陷怎么处理？

　　不可重现的原因主要有：测试环境不一致，测试配置不一致、内存泄露、数据接口不一致等

　　解决：1. 测试环境配置充分细致：严格核对要求，充分考虑环境变化。另外可以使用Ghost对硬件或某个分区进行镜像备份。

　　　　    2. 捕获系统日志，分析异常信息：测试人员应养成记录系统错误日志的习惯，保留系统在出错时的真实状态。比如将IE浏览器高级选项设置为“显示每个脚本错误的通知”。

　　　　    3. 监测系统状态，异常及时告警：系统运行监测的一个重要内容是需要及时反馈系统运行异常，并提供异常报告。

　　　　    4. 测试数据翔实，易于追溯：软件测试开始前，必须制定完整的测试用例，辅以详细的测试数据，并明确测试数据的操作步骤和每一步的预期结果，这样，当软件出现问题，方便重现和定位。

13、测试流程是什么？

　　即测试周期，详见第二题

14、测试方法有哪些？

　　黑盒测试：只关注输入和输出，不关注内部逻辑，是基于需求规格说明书的功能测试。主要验证被测对象的质量及外部特性（功能、性能、界面）。

　　白盒测试：只关注代码的内部逻辑结构，是结构测试、逻辑驱动测试，是基于程序代码内部构成的测试。单元测试中就常使用白盒测试。

　　灰盒测试：关注模块之间的数据交互，介于白盒、黑盒之间。同时兼顾被测对象的外部特性和内部结构。如关注日志的集成测试、性能测试和自动化测试

　　基于风险的测试：指评估测试的优先级。在测试中，首先应该做的是高优先级的测试，如果时间精力不够，低优先级就可以暂时不做。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题，影响也不是很大，可以考虑不做测试。

　　基于模型测试：指用语言将一个系统的行为描述出来，从而定义出它可能的形态以及形态之间的转换关系，即状态转换图。

15、测试类型有哪些？

　　功能测试：也叫黑盒测试，主要验证软件业务需求实现与否的一项测试活动。其意义是便于用户理解。

主要检查被测对象是否存在以下3种错误：1、是否有不正确、遗漏或多余的功能。2、是否满足用户需求和系统设计的隐藏需求。3、是都对输入做出正确的响应，输出结构能否正确展示。

　　性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行。

其意义是因为现实情况中资源总是有限的。目的是验证系统是否具有宣称的能力

通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

主要关注cpu、内存、读写（响应速度、并发数、业务成功率和资源占用情况）

　　界面测试：界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。

　　另外有兼容性测试、安全测试、可靠性测试、可用性测试、移植测试、维护测试、确认测试、回归测试等

16、α测试和β测试的区别？

　　两者都属于验收测试，以用户为主、有用户参与

　　α测试：在开发环境下进行，测试环境受控，开发在场

　　β测试：在实际使用环境下（生产环境）进行，测试环境不受控、开发不在场

17、什么是敏捷测试？什么是探索性测试？

　　敏捷测试：是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈

　　探索性测试：强调测试过程中要有更多的发散思维，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。是用户故事测试和自动化回归集的重要补充。由于没有测试脚本，可以使你的测试超出各种明显已经测试过的场景。探索测试将学习，测试设计和测试执行整合在一起，形成一种测试方法。探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。其基本过程如（环节间无绝对顺序）：

识别软件系统的目的;

识别软件系统提供的功能;

识别软件系统潜在的不稳定的区域;

在探索软件系统的过程中记录关于软件的消息和问题;

创建一个测试纲要，使用它来执行测试。

18、V模型和W模型的区别？

　　v模型：测试往往被加在开发过程的后半部分，测试对象只有程序本身，前期面向程序，后期面向用户。适合工程量小、人力投入少的情况

　　w模型：测试和开发是同时进行的，测试对象除程序外还有需求、设计等。

19、何为上线？之前工作中上线是怎么做的？

　　上线：软件具备正式运行生产的所有必要条件，并且完成发布工作

　　流程：上线前准备：1、确定上线策略（上线顺序、修复数据策略、旧数据分析）

　　　　　　　　　　　2、写上线申请邮件（数据配置、上线注意点）

　　　　　　　　　　　3、配置线上环境数据

上线：一般上线的权限只有几个人有，所以上线的人员是固定的，上代码时需要先将线上环境的job停掉，我们也是用jenkins进行自动化部署，只是需要人为的打版号、标签，部署版本，停Djob任务，上线完全之后，启动Djob任务等。

上线后：1、灰度测试

　　　　2、监控线上数据

　　全文链接：https://zhuanlan.zhihu.com/p/79417003

　　实例：https://zhuanlan.zhihu.com/p/37584401

20、测试用例的内容、优先级定义、以及如何编写？

　　内容：

+ 用例编号（用例id）
+ 一般使用 系统-测试级别-模块-001 --- 例子：CRM-ST-客户管理-新增客户-001
+ 测试标题（用例标题）---- 验证XXXX 通过/不通过---肯定的语气
+ 测试项（所属模块）
+ 用例属性（测试类型）--一般为功能测试
+ 重要级别（优先级）---- 1-4级或者 极高-高-中-低

　　优先级定义：

+ 极高---- 冒烟（主业务流程）
+ 高 ---- 流程类，稍重要的流程
+ 中 ---- 一般流程，界面中比较常用的可能
+ 低 ---- 界面中异常情况，或者很少出现的

　　如何编写：

1、划分功能模块

2、正向功能验证：正常操作功能是否实现

3、单个功能项验证：正向+异常

4、功能之间交互验证：模块之间的数据传递

5、隐形需求：熟悉业务

+ 只要是涉及到输入框的首先考虑输入为空的情况
+ 一条用例只测试一个功能点
+ 测试正常和异常的遵循二八原则
+ 操作步骤和预期结果一一对应
+ 如果条件有多个，在实际测试某一个的时候，默认其他条件都满足
+ 在对一个模块编写用例时，首先先对模块整体的业务走一条冒烟
+ 对一个界面编写用例时，可以先给页面一个界面的用例----针对有界面原型的
+ 优先级为高的在这个模块一般只占5%左右

21、如何测试一个水杯？

寻找水杯是否有说明书，如果有需要充分阅读并理解水杯说明书，按说明书描述，测试到所有需求点
按测试关注点划分主要分为以下几个方面：

1. 功能测试：
   主要关注水杯基本功能
   1.1 水杯是否可以正常装水
   1.2 水杯是否可以正常喝水
   1.3 水杯是否有盖子，盖子是否可以正常盖住
   1.4 水杯是否有保温功能，保温功能是否正常保温
   1.5 水杯是否会漏水，盖住盖子拧紧后是否会漏水
2. 界面测试：
   主要关注水杯外观、颜色、设计等方面
   2.1 外观是否完整
   2.2 外观是否舒适
   2.3 颜色搭配及使用是否让人感到舒适
   2.2 杯子外观大小是否适中
   2.3 杯子是否有图案，图案是否易磨损
3. 易用性测试：
   主要关注水杯使用是否方便
   3.1 水杯喝水时否方便
   3.2 水杯拿起放下是否方便，这里会衍生到水杯形状的测试
   3.3 水杯装水是否方便
   3.4 水杯携带是否方方便
   3.5 水杯是否有防滑功能
   3.6 水杯装有低温或者高温水时，是否会让手感到不适
4. 性能测试：
   4.1 水杯装满水时，是否会露出来
   4.2 水杯最大使用次数
   4.3 水杯的保温性是否达到要求
   4.4 水杯的耐寒性是否达到要求
   4.5 水杯的耐热性是否达到要求
   4.6 水杯掉落时时，是否可以正常使用
   4.7 水杯长时间放置时，是否会发生泄露
5. 兼容性测试：
   主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等
6. 可移植性测试：
   主要关注水杯放置环境等
   6.1 将水杯放在常温环境中，使用是否正常
   6.2 将水杯放在零下的环境中，使用是否正常
   6.3 将水杯放在高于正常温度的环境中，使用是否正常
7. 安全性测试：
   主要关注水杯外观和各种异常条件下是否释放有毒物质等
   7.1 当水杯装满热水时，水杯是否会烫手
   7.2 当水杯装上水后，是否会产生有毒物质
   7.3 把水杯放在零下环境时，是否会产生有毒物质
   7.4 把水杯放在高温环境时，是否会产生有毒物质

22、拆分需求注意事项？

需求是一个整体，整体拆成模块，模块拆成小需求，小需求拆成功能点，需求点。测试时，分成整体测试，功能点测试，需求点测试。对于每个需求点根据等价类、边界值划分等去分析。一个需求就分成了一个树结构。一层一层的对应。

总体来说主要注意事项如下：

1. 了解业务背景（做这个需求的目的是什么）
2. 理解业务需求:需求的大致逻辑
3. 关注功能需求:为了实现业务需求，软件应有的功能。
   有的是需求文档明确写出来的；有的是需求文档中未提及的，未提及到的则需要我们根据自身的软件测试经验来进行补充并想产品确认----这个过程，可以用写思维导图体现
4. 测试需求:为了实现本期所有功能以及兼容旧用户使用，所进行一系列测试活动。
   包含本期所有的功能需求、以及涉及到可能影响的功能模块（主要包括上下游模块和公用方法模块）、旧数据的兼容、非功能性测试（兼容、性能）–编写测试子任务

相关题目：给定一句话的需求：“世上无难事，庸人自扰之”，如何拆分测试点来设计测试用例（要求列出测试点）

23、项目组成员包括哪些？

项目经理{开发经理{UI，开发工程师，系统架构师}，测试经理{测试设计、测试工程师}}

24、回归测试?回归几轮？

回归测试是对已被测试过的程序在修复缺陷后进行的重复测试，目的是验证修复缺陷有没有引发新的缺陷或问题。简单来说就是看有没有引入新bug。回归策略有选择性回归（一般指针对bug进行回归，在开始几轮时候，bug比较多，包括基于风险、 基于操作、基于缺陷）和完全回归（一般在最后一轮回归的时候，执行所有用例）。

-一般回归3轮（如果3轮还未回归还未修复完bug，再继续回归）

25、什么情况下使用自动化测试？

1. 需求变更有计划性，更新频率不高或不会大幅度改版，每次迭代都需要进行验证；
2. 项目周期长（几年）；
3. 脚本重复利用率高；
4. 代码、环境可量化；
5. 一个项目可以区分出某部分手动、某部分自动：

比如：基础性代码、接口，比较独立的API、没有业务依赖，适合自动；

有角度依赖、较复杂的业务逻辑，场景多、类型不一致、因子数多、重度需要人交互，适合手动；

 6. 版本稳定后才进行自动化

26、scrum模型中的一些特殊术语？

scrum模型中主要有产品负责人（Product Owner）、ScrumMaster、团队（Team）。

它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。

Product Backlog：在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。

Sprint Backlog：Sprint Backlog 是Sprint规划会上产出的一个工作成果. 当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum team和Product Owner 协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。

Sprint Planning Meeting（Sprint规划会）、Daily Scrum Meeting（每日站会）、Sprint Review Meeting（Sprint评审会）

https://blog.csdn.net/m0_37561295/article/details/79549499

27、把你熟悉的一个游戏简单分析如何进行测试？

 

28、如何搭建测试环境？

1. 安装好Linux操作系统
2. 在Linux下安装JDK
3. JDK安好后安装tomcat
4. 安装MySQL和相关数据库、安装测试相关平台、系统

https://www.cnblogs.com/kiki925/p/13490603.html

29、app和web的测试环境有什么区别？　

web项目，b/s架构，基于浏览器的；web测试只要更新了服务器端，客户端就会同步会更新

app项目，c/s结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍

 

30、系统项目的构成？

　　前端、UI界面、客户端、后端、系统服务端代码、WEB服务器（Apache）、应用服务器（Tomcat轻量级的应用服务器）、数据库服务器

31、如何构造测试数据？构造测试数据的方式有哪些（接口测试内容）？

1、通过charles工具拦截请求之后，修改响应数据，构造许多数据，模拟mock查看列表及翻页展示

2、如果有数据库权限，可以与开发同学协调，让开发同学帮忙编写sql语句进行数据添加(当然如果有数据关联，需要查看下关联的表结构及关系)。

3、通过UI自动化脚本，录制或循环运行，进行数据添加。

当然Mock方式还是最简单和有效验证的方式。

比如：有些字段返回错误，返回异常的字段类型，空的校验等等，客户端是否有崩溃，异常产生。

接口端的测试只能保证数据格式和字段是否正确，那么Mock+Selenium/Appium则可以配合进行，验证我们客户端的展示是否正确。

一般创建测试数据的方法分为手动创建和采用程序的自动化创建两种方法

https://blog.csdn.net/zhusongziye/article/details/79078936

32、如何确认测试数据的正确性？

　　

33、你们测试是否与开发共用一个环境？如果是，如何保证测试结果不受影响？

测试环境的目的是为了使测试结果更加真实有效，应该与开发环境分隔开，使用独立的客户机、服务器和配置管理工具。原则上开发人员是不能碰测试环境和线上环境的，只能看不能动，如果随便哪个人发布了一个包或者修改了代码，那就乱了，因此测试环境涉及到权限管理，对于开发人员来说应该是只读权限。

如果测试和开发一定要共用一个环境的话尽量做好版本管理和权限控制

https://testerhome.com/topics/23393

 

34、什么是接口测试？为什么要做接口测试？怎么做接口测试？

 

35、接口是否通过测试怎么判断你？

36、接口测试用例怎么设计？

37、接口自动化是什么？

38、发现缺陷后怎么定位？

先查数据库，然后查看接口信息，查看前端调试信息，查看相关服务业务处理信息。

ps：夹板思路：先夹大黑盒,再夹小黑盒,逐渐缩小问题发生范围, 也就是三层 前端 服务 数据来夹. 就是大夹板是最大的黑盒 也就是 只管前端 和 数据库落地 的输入和输出,如果这个大夹板没问题,输入也对,落地数据也对,那就基本说明,整个处理链路是通的.

https://testerhome.com/articles/16966

39、提交的bug研发不认怎么办？

在确保缺陷提交流程是已经得到开发认可的前提下，先从自身入手：

• 再次验证所提的 bug 确实是 bug，确保自身对需求的理解无误；
• 检查bug的描述是否会产生歧义；
• 检查是否是环境或数据的问题，在开发处无法复现。

然后与开发确认：

• 了解开发为什么不认可，需求不明确？
• 接收到的需求是否一致？或者理解错误？
• 与开发讨论，讲清楚你的理由，该问题可能对用户造成的影响。

如果还是没有解决的话找权威裁决：

• 这种争议问题一般集中在需求有歧义不明确、或用户体验的地方（数据问题、逻辑问题一般不会有争议）。可以先找产品经理确认。产品经理通过对影响的确认评估是否需要修改。如果对此依然有疑虑，应该表明自己的观点，由产品经理或项目经理决定。

 

40、怎么提交一个高质量的缺陷记录？（缺陷报告有哪些内容？）

在编写缺陷记录前检查问题是否可重现（如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次）。

尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。

若问题是已隔离，可重现的，则应对其进行归纳。（同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？）

检查该问题是否是回归错误。

在缺陷报告的第一行写上错误的总结。（已发现的错误对客户有何影响）

缺陷报告初稿完成后进行精简、消除歧义、（集中剔除那些没有关系的步骤或词语，隐含的或模糊的说明、对没有任何关系的细节的描述或者那些在重现错误过程中不需要的步骤。同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。）

缺陷报告的内容有：+测试的结果

  +针对本次测试的一个总结---所用的人力，物力，项目介绍
  + 本次用例情况
  + 缺陷的情况
  + 本次测试的遗留问题

 

41、各类工具的工作原理是什么？工具都可以用来干什么?为什么要用？

42、禅道如何提交缺陷的？缺陷都有哪些状态？除了管理缺陷以外还能做些什么？

43、Jmeter：接口测试，具体怎么操作的，有哪些控件？

44、Jmeter：依赖性接口如何测试？