1、分别介绍单元测试、集成测试、系统测试、验收测试和回归测试？

  • 单元测试

    • 完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确编码。使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的。对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的问题。

  • 集成测试

    • 通过测试发现与模块接口有关的问题。目标是利用通过了单元测试的模块，构造一个在设计中所描述的程序结构。应当避免一次性集成，而采用增量集成。

      • 自顶向下集成：模块的集成顺序是首先集成主模块，然后按照层次结构向下进行集成。隶属于主模块的模块，按照深度优先或者广度优先的方式集成到整个结构中去。
      • 自底向上集成：从底层模块开始进行构造和测试，底层组件较早被完成。因为是自底向上集成的，进行时要求所有隶属于某个顶层的模块总是存在，也就不再需要使用稳定测试桩。

  • 系统测试

    • 是基于系统整体需求说明书的黑盒测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行的环境中进行测试。

  • 回归测试

    • 回归测试是指在代码发生修改之后，重新测试以前的测试用例，进而保证修改的正确性。其目的在于验证以前出现过但已经修复好的缺陷不再重复出现。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否再次出现在新版本的软件上面。

  • 验收测试

    • 验收测试是部署软件之前的最后一个测试，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和验收。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

2、单元测试、集成测试、系统测试、验收测试和回归测试中，最重要的是哪一步？

  • 这些测试步骤分别在软件开发的不同阶段对软件进行测试，而对软件完整功能进行测试的系统测试是最重要的。因为此时单元测试和集成测试已经完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足需求规格的定义。

3、集成测试和系统测试的区别是什么？它们的应用场景主要是什么？

  • 二者的区别

    • 计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，而在概要设计阶段制定集成测试计划和用例。先做系统测试计划用例，后做集成测试计划用例。

    • 用例的粒度：系统测试用例相对接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块和子系统。

    • 执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再执行系统测试。

  • 应用场景

    • 集成测试：完成单元测试后，各模块联调测试。可以是整个产品的集成测试，也可以是大模块的集成测试。集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。测试方法一般选用黑盒测试与白盒测试相结合。

    • 系统测试：针对整个产品的全面测试，既包括各模块的验证性测试和功能性测试，又包括对整个产品的健壮性、安全性、可维护性以及各种性能参数的测试。系统测试需要严格按照《需求规格说明书》进行，测试软件的功能是否有遗漏等。测试方法一般选用黑盒测试。

5、黑盒测试方法和白盒测试方法分别是什么？

  • 黑盒测试

    • 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有功能的情况下，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看做一个不能打开的黑盒子，在完全不考虑内部结构和内部特性的情况下，测试者在程序接口进行测试。它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入并产生正确是输出信息，同时确保外部信息的完整性。

    • 黑盒测试针对软件界面和软件功能进行测试。黑盒测试是穷举输入测试，不仅要考虑所有合法的输入，也要考虑不合法但是可能的输入。

    • 常用的黑盒测试方法有：等价类划分法、边界值分析法、因果图法、场景法、正交试验设计法、错误推测法、判定表驱动分析法、功能图分析法。

  • 白盒测试

    • 白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部如何工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试检查程序内部的逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法。但即使每条路径都测过了，仍然有可能存在错误。因为：

      • 穷举路径测试无法检测出程序本身是否违反了设计规范，即程序本身是否错误。

      • 穷举路径法也不能检查出程序因遗漏路径而出错。

      • 穷举路径法发现不了一些与数据相关的错误。

    • 白盒测试需要遵循以下原则：

      • 保证一个模块中的所有独立路径至少被测试一次。

      • 所有逻辑值均需要测试真和假两种情况。

      • 检查程序的内部数据结构，保证其结构的有效性。

      • 在上下边界及可操作范围内运行所有循环。

    • 常用的白盒测试方法：静态测试、动态测试、语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。（六中覆盖标准发现错误的能力由弱到强）

5、α测试和β测试分别是什么？

  • α测试

    • 是由用户在开发者的场所来进行的，在一个受控的环境中进行。

  • β测试

    • 由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

6、设计测试用例的方法有哪些？

  • 黑盒测试

    • 等价类划分

      • 等价类划分是将系统的输入域划分成若干部分，然后从每个部分选取少量代表性数据进行测试。

      • 有效等价类：对程序来说，有意义的、合理的输入数据——用来测试功能是否正确实现。

      • 无效等价类：对程序来说，无意义的、不合理的输入数据——用来测试程序是否有强大的异常处理能力（健壮性）。

      • 设计流程：首先要确定待测程序的有效输入范围和非法输入范围，比如一个姓名输入框，它的输入范围为：1~20个字符（不包含数字）。

        • 有效等价类：1~20个字符，不包含数字。

        • 无效等价类：空输入、大于20个字符、包含数字的输入。

    • 边界值分析法

      • 边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附近的取值不会出错，那么其他取值出错的可能性也就很小。

      • 边界值分析法是通过优先选择不同等价类间的边界值，覆盖有效等价类和无效等价类，同时还要测试次边界，也就是边界值两边的数据，从而进行更有效的测试，因此该方法要和等价类划分法结合使用。

      • 如密码输入框：8-20位字符（只允许输入：字母、英文字符、数字）

        • 边界值：8位字符、20位字符

        • 次边界：7位字符、9位字符、19位字符、21位字符

    • 正交试验法

      • 正交是从大量试验点中挑出适合的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，它是一种基于正交表的高效率、快速、经济的试验设计方法。

      • 测试思想：

        • 使用最少的抽样数据达到最广的、覆盖率最高的统计结果。

    • 状态迁移法

      • 状态迁移法是抽象出待测系统的若干状态以及状态之间的转换条件和转换路径，然后从状态迁移路径覆盖的角度设计测试用例。该方法的目标是设计足够多的测试用例，覆盖系统的状态、状态——条件的组合、状态迁移路径。

    • 输入域测试法

      • 输入域测试法是针对输入会有各种各样的输入值的一个测试，它主要考虑极端测试、中间范围测试、特殊值测试。

    • 输出域分析法

      • 输出域分析是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，它的目的是达到输出域的等价类和边界值覆盖。

    • 判定表分析法

      • 判定表分析法，是分析和表达多种输入条件下，系统执行不同动作的工具。它可以把复杂的逻辑关系和多种条件组合的情况表达的既具体又准确。

    • 因果图法

      • 因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出之间的因果图可以得到判定表，从而规划出测试用例。

      • 测试思想：

        • 通过画图的方式来表示输入条件（因）和输出条件（果）之间的关系。

      • 设计流程：

        • 步骤1：找出所有的输入条件。

        • 步骤2：找出所有的输出结果。

        • 步骤3：分析，列出输入条件之间所有的组合和限制条件。

        • 步骤4：确定每组输入条件的组合会产生怎样的输出结果，画因果图，填写判定表。

        • 步骤5：编写测试用例，每一列代表一种组合。

    • 错误推测法

      • 错误推测法主要是基于经验和直觉推测出程序中所有可能存在的各种错误，从而可以有针对性的设计测试用例。

    • 异常分析法

      • 异常分析法是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，分析发生错误时，系统对于错误的处理能力和恢复能力，并依此设计测试用例。

  • 白盒测试

    • 静态测试

      • 不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。

    • 动态测试

      • 需要执行代码，通过运行代码找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

    • 逻辑覆盖

      • 语句覆盖——每条语句至少执行一次。

      • 判定覆盖——每个判定的每个分支至少执行一次。

      • 条件覆盖——每个判定的每个条件应取到各种可能的值。

      • 判定/条件覆盖——同时满足判定覆盖和条件覆盖。

      • 条件组合覆盖——每个判定中，各条件的每一种组合至少出现一次。

      • 路径覆盖——使程序中每一条可能的路径都至少执行一次。

7、软件质量的六个特征是什么？

  • 功能特征

    • 与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能，即用户要求的功能是否全部实现了。

  • 可靠特征

    • 在规定的一段时间和条件下，软件所能维持其性能水平的程度。

  • 易用特征

    • 对于一个软件，用户在使用时所作努力的程度。

  • 效率特征

    • 在规定条件下，软件实现某种功能时使用计算机资源的有效程度。

  • 可维护特征

    • 在一个可运行软件中，为了满足需求，进行相应修改所需做的努力程度。

  • 可移植特征

    • 从一个计算机系统或环境迁移到另一个环境的难易程度。

8、测试和开发需要怎么结合才能让软件的质量得到更好的保障？

  • 测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发成本。
    图片说明

  • 在V模型中，测试过程被加在开发过程的后半部分，单元测试用来检测代码的开发是否符合详细设计的要求；集成测试用来检测此前测试过的各组成部分是否能够完好的结合到一起，并满足概要设计的要求；系统测试用来检测已集成在一起的产品是否符合系统规格说明书的要求；验收测试用来检测产品是否满足用户最终的需求。

  • V模型的缺陷在于，仅仅把测试过程作为需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求分析阶段的缺陷很可能到后期验收测试的时候才被发现，此时弥补将耗费大量资源。

图片说明

  • 相对于V模型，W模型增加了软件个开发阶段中应同步进行的验证和确认活动。W模型由两个V模型组成，分别代表开发和测试过程，如上图所示。

  • W模型强调：测试伴随整个软件的开发周期，而且测试的对象不仅仅是程序，还有需求、设计等同样要进行测试，即测试和开发是同步进行的。W模型有利于尽早的全面的发现问题。

9、测试的相关流程是什么？

  • 根据W模型可以知道，测试的规范流程如下：

    • 需求测试

    • 概要设计测试

    • 详细设计测试

    • 单元测试

    • 集成测试

    • 系统测试

    • 验收测试

10、如何编写测试用例？

  • 测试人员尽早介入，彻底清楚理解需求是写好测试用例的基础。

  • 如果以前有类似的需求，可以参考类似需求的测试用例，然后还有查看类似需求出现的bug情况。

  • 清楚输入、输出的可能性，以及各种输入之间的关系，理解清楚需求的逻辑，通过等价类、边界值、判定表等方法找到大部分测试用例。

  • 找到需求相关的一些特性，补充测试用例。

  • 根据自己的经验，分析可能遗漏的测试场景。

  • 多总结类似功能点的测试点，才能写出质量高的测试用例。

  • 书写格式要清晰。

11、常见测试用例的边界？

  • 对16-bit的整数而言，32767和-32768是边界。

  • 屏幕上，光标在最左上和最右下的位置。

  • 报表的第一行和最后一行。

  • 数组元素的第一个和最后一个。

  • 循环的第0次、第一次和倒数第二次、最后一次。

12、简单用户界登录界面怎样测试？

  • 功能测试

    • 输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。

    • 输入错误的用户名或者密码，验证登录会失败，并且提示相应的错误信息。

    • 登陆成功能否跳转正确的页面。

    • 用户名或密码，如果太长或太短应该怎么处理。

    • 用户名和密码中有特殊字符（如空格），和其他非英文的情况。

    • 检查是否能够选择不同登录方式进行登录，如手机号登录、微信登录和扫码登录等。

    • 记住用户名的功能。

    • 登录失败后，不能记录密码的功能。

    • 用户名和密码前后有空格的处理。

    • 密码是否非明文显示，使用星号圆点等符号代替。

    • 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜***盲患者），刷新或换一个按钮是否好用。

    • 登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确。

    • 输入密码的时候，大写键盘开启的时候是否有提示信息。

    • 什么都不输入，点击提交按钮，检查提示信息。

  • 界面测试

    • 布局是否合理，testbox和按钮是否整齐。

    • testbox和按钮的长度、高度是否符合要求。

    • 界面的设计风格是否与UI的设计风格统一。

    • 界面中的文字简洁易懂，没有错别字。

  • 性能测试

    • 打开登录页面，需要的时间是否在需求规定的时间内。

    • 输入正确的用户名和密码，检查登录成功后跳转到新页面的时间是否在需求规定的时间内。

    • 模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

  • 安全性测试

    • 登录成功后生成的cookie，是否是httponly（否则容易被脚本盗取）。

    • 用户名和密码是否通过加密方式，发送给Web服务器。

    • 用户名和密码的验证，应该使用服务器端验证，而不单单是在客户端用JavaScript验证。

    • 用户名和密码的输入框，应该屏蔽SQL注入攻击。

    • 用户名和密码的输入框，应该禁止输入脚本，防止XSS攻击。

    • 防止暴力破解，检测是否有错误登录的次数限制。

    • 是否支持多用户在同一机器上登录。

    • 同一用户是否能在多个机器上登录。

  • 可用性测试

    • 是否可以全用键盘操作，是否有快捷键。

    • 输入用户名、密码后，是否可以按回车登录。

    • 用户名和密码输入框是否可以用Tab键切换。

  • 兼容性测试

    • 不同浏览器下是否能显示正常和功能正常（IE6,7,8,9,Firefox,Chrome,Safari等）。

    • 同种浏览器的不同版本下，是否能显示正常和功能正常。

    • 不同的平台是否能正常工作，Windows、Linux、Mac等。

    • 移动设备上是否能正常工作，iPhone、Android等。

      • 不同分辨率下是否显示正常。

  • 本地化测试

    • 不同语言环境下，页面的显示是否正确。

13、对以下系统设计测试用例：多个摄像头，抓拍车牌，识别车牌，将车牌上传到网上，网上展示。

  • 功能

    • 每个摄像头都能抓拍车牌。

    • 每个摄像头抓拍的车牌都能够交给系统正常处理。

    • 系统能够正确识别车牌。

    • 系统能够将识别出的车牌上传。

    • 上传至网络的车牌能够正常进行展示。

  • 功能测试

    • 使用正常的车牌，保持车牌静止，检查每个摄像头是否能够抓拍车牌。

    • 使用正常的车牌，让车牌进行告诉移动，检查每个摄像头是否能够抓拍车牌。

    • 使用类似车牌的有字的纸板，检查摄像头是否进行抓拍。

    • 在多种情况下，检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时停电、断网后是否能够正常将数据交给系统。

    • 使用抓拍到的正常车牌，在提交给系统之后，检查系统是否能够正常识别车牌。

    • 使用非车牌的其他图片，交给系统处理，检查系统是否能够识别？

    • 在多种情况下，检查系统是否能够将正常识别出来的车牌进行上传，如临时停电、断网后是否能够正常的将数据上传。

    • 构造非车牌的其他数据，检查系统是否能够将异常内容上传。

    • 检查上传至网络的车牌是否能够正常展示出来。

    • 检查上传至网络的非车牌的异常内容是否能够展示出来。

  • 性能测试

    • 同时向一个摄像头展示多个静止的车牌，检查摄像头是否能够抓拍到多个车牌。

    • 同时向一个摄像头展示多个高速移动的车牌，检查摄像头是否能够抓拍到多个车牌。

    • 检查系统识别车牌的时间是否在需求规定的时间内。

    • 模拟大量抓拍图像交给系统处理，检查系统能否在一定压力下正常识别车牌。

    • 模拟大量车牌同时上传，检查系统能否在一定压力上传成功。

  • 安全性测试

    • 检查是否能够通过给车牌加装饰等方法，使摄像头无法抓拍到车牌或者使系统无法正常识别车牌。

14、对朋友圈点赞功能进行测试。

  • 功能测试

    • 是否可以正常点赞或取消。

    • 点赞之后，共同好友是否可见。

    • 点赞之后，能否正常显示点赞人的昵称和头像。

    • 点赞的显示是否正确，一行几个。

    • 点赞之后，能否进行评论。

    • 点赞之后，其他共同好友的点赞和评论是否会提示或通知。

  • 性能测试

    • 弱网情况下，点赞状态是否能即时更新显示。

    • 模拟大量用户同时点赞，检查是否能够正常显示。

  • 兼容性测试

    • 在不同平台的手机上，如iPhone、Android等，点赞之后是否能够正常显示。

    • 在同一手机上的不同微信版本上，点赞之后是否能够正常显示。