测试总结-面试相关

一、测试概念：

1.1、测试类型

• 接口测试（正常参数、异常参数、db异常、服务依赖异常、系统异常错误返回、并发、幂等异常）
• UI测试（样式、下拉框、键盘遮挡、按钮、快捷键、光标指向）
• 功能测试：正常场景（接口、业务）、异常场景（接口异常、业务异常-并发幂等、操作异常、网络异常）
• 安全测试：sql注入，脚本注入
• 兼容性测试：系统兼容、适配兼容、网络兼容、安装卸载及重装；ios端Android端、系统版本、app版本
• 性能测试：压力测试、
• 探索性测试
  –
• 黑盒测试
• 白盒测试
• 灰盒测试
  –
• 单元测试
• 集成测试
• 系统测试
  –
• 阿尔法测试
• 贝塔测试：贝塔版本，试用版本，后期优化
  –
• 冒烟测试：对系统的基本功能进行简单的测试，这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

1.2、常见的黑盒测试方法

• 等价类划分法：有效等价类、无效等价类
• 边界值法：左右中边界情况、值的边界、值的个数的边界
• 错误推测法：根据经验、直觉。浮点型，输入66这样的数值会溢出等
• 因果图法：多个条件，条件的限制和不同条件的组合，达到不同的结果
• 反推法：从需求反了逻辑

1.3、探索性测试方法

• 恶邻测试法：反复测试缺陷特别多的地方
• 懒汉测试法：做尽量少的实际工作，可以尝试接受所有的默认值，测试程序对默认值的处理情况
• 深巷测试法：软件中最不可能被用到的或者最不吸引用户的特性，有助于提高代码覆盖率
• 通宵测试法：性能测试和压力测试，永远不关闭程序，连续不断的使用某些特性来测试软件
• 长路径测试法：测试离应用程序开始点尽可能远的特性，例如：哪个特性需要点击N次才能被用到，选定该特性，一路点击过去，然后测试它。
• 遍历测试法：通过选定一个目标（例如所有菜单项、所有错误消息或所有对话框），然后使用可以发现的最短路径来访问目标包含的所有对象
• 重复操作测试法：重复执行同样的操作

1.4、白盒测试方法（强度由低到高）

说明：其中语句覆盖是一种最弱的覆盖，判定覆盖和条件覆盖比语句覆盖强，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖，条件组合覆盖是除路径覆盖外最强的，路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖。

• 语句覆盖：就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好。
• 判定覆盖：以判断的结果为准，设计的测试用例保证程序中每个判断的每个取值分支（t or f）至少经历一次
• 条件覆盖：以判定的条件为准，条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支
• 判定条件覆盖：判定-条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件取值组合至少执行一次。
• 条件组合覆盖：在白盒测试法中，选择足够的测试用例，使所有判定中各条件判断结果的所有组合至少出现一次，满足这种覆盖标准成为条件组合覆盖。
• 路径覆盖：是每条可能执行到的路径至少执行一次；

1.6、常见的功能测试

https://www.jianshu.com/p/c166d0890f97
web的测试场景：https://blog.csdn.net/vensers/article/details/79270960

二、设计测试计划

2.1、测试范围

• 功能测试（手机端、管理端）
• 安全测试（接口是否有被刷的风险）
• 接口测试
• 性能测试
• 兼容性测试

2.2、测试策略

• 正常场景：根据上述测试方法进行思考用例
• 异常场景：网络、手机端异常操作、接口异常（404、异常返回）、业务异常（服务依赖、数据一致性、并发、幂等、事务回滚、定时任务的失败降级等）

2.3、核心技术实现

• 系统交互图
• 数据存储：数据库、redis、hbase
• 接口文档

2.4、测试难点

• 数据不好造
• 第三方调用不好模拟

2.5、风险

三、testNg

3.1、注解

• @BeforeSuite: 被注释的方法将在所有测试运行前运行
• @AfterSuite:被注释的方法将在所有测试运行后运行
• @BeforeTest: 被注释的方法将在测试运行前运行
• @AfterTest: 被注释的方法将在测试运行后运行
• @BeforeGroups: 被配置的方法将在列表中的gourp前运行。这个方法保证在第一个属于这些组的测试方法调用前立即执行。
• @AfterGroups: 被配置的方法将在列表中的gourp后运行。这个方法保证在最后一个属于这些组的测试方法调用后立即执行。
• @BeforeClass: 被注释的方法将在当前类的第一个测试方法调用前运行。
• @AfterClass: 被注释的方法将在当前类的所有测试方法调用后运行。
• @BeforeMethod: 被注释的方法将在每一个测试方法调用前运行。
• @AfterMethod: 被注释的方法将在每一个测试方法调用后运行。
  属性：
• @alwaysRun 对于每个bufore方法(beforeSuite, beforeTest, beforeTestClass 和 beforeTestMethod, 但是不包括 beforeGroups)
• @dependsOnGroups 这个方法依赖的组列表
• @dependsOnMethods 这个方法依赖的方法列表
• @DataProvider 标记一个方法用于为测试方法提供数据。
  被注释的方法必须返回Object[][], 其中每个Object[]可以指派为这个测试方法的参数列表。从这个DataProvider接收数据@Test方法需要使用一个和当前注释相同名称的dataProvider名称
• @Parameters描述如何传递参数给@Test方法，value 用于填充这个方法的参数的变量列表
• @Test 标记一个类或方法作为测试的一部分

–

• @enabled 这个类的方法是否激活

• @groups 这个类或方法所属的分组列表

• @inheritGroups 如果设置为true，这个方法被属于在类级别被@Test annotation指定的组

• @name 这个DataProvider的名称

• @Factory 标记方法作为一个返回对象的工厂，这些对象将被TestNG用于作为测试类。这个方法必须返回Object[]

• @ alwaysRun 如果设置为true，这个测试方法将总是运行，甚至当它依赖的方法失败时

• @ dataProvider 这个测试方法的data provider的名称

• @ dataProviderClass 用于查找data provider的类。
  如果不指定，将在当前测试方法所在的类或者它的基类上查找data provider。
  如果这个属性被指定, 则data provider方法需要是指定类的static方法。

• @ dependsOnGroups 当前方法依赖的组列表

• @ dependsOnMethods 当前方法依赖的方法列表

• @ description 当前方法的描述

• @ enabled 当前类的方法/方法是否被激活

• @ expectedExceptions 测试方法期望抛出的异常列表。如果没有异常或者抛出的不是列表中的任何一个，当前方法都将标记为失败.

• @ groups 当前类/方法所属的组列表

• @ invocationCount 当前方法被调用的次数

• @ successPercentage 当前方法期望的成功率

• @ sequential 如果设置为true，当前测试类上的所有方法保证按照顺序运行。甚至测试们在parallel="true"的情况下.

• @ 这个属性只能用于类级别，如果用于方法级别将被忽略。

• @ timeOut 当前方法容许花费的最大时间，单位毫秒。

• @ threadPoolSize 当前方法的线程池大小。方法将被多线程调用，次数由invocationCount参数指定
  注意：如果invocationCount没有指定则这个属性将被忽略

五、场景设计测试用例

5.1、登录

• （1）前端基本功能测试点–输入框
  • 用户名密码为空时，是否有相应提示？
  • 密码框是否加密显示？
  • 用户名是否支持中文、特殊字符？
  • 用户名是否有长度限制？
  • 密码是否支持中文，特殊字符？
  • 密码是否有长度限制？
  • 密码是否区分大小写？
  • 页面默认焦点是否定位在用户名的输入框中
  • 首次登录时相应的输入框是否为空？或者如果有默认文案，当点击输入框时默认方案是否消失？
  • 相应的按钮如登录、重置等，是否可用;页面的前进、后退、刷新按钮是否可用？
  • 快捷键Tab,Esc,Enter 等，能否控制使用
• （2）后端基本功能测试点–提交登录时校验

  • 用户名密码为空时，是否有相应提示？

  • 用户名和密码不合标准，是否有提示

  • 密码为一些简单常用字符串时，是否提示修改？如：123456

  • 输入正确的用户名和密码登录成功

  • 输入错误的用户名密码登录失败

  • 用户名正确，密码错误，是否提示输入密码错误？

  • 用户名错误，密码正常，是否提示输入用户名错误？

  • 用户名和密码都错误，是否有相应提示？

  • 如果用户未注册，提示请先注册，然后进行登录

  • 已经注销的用户登录失败，提示信息友好？

  • 登录功能是否需要输入验证码？

    • 验证码有效时间？
    • 验证码输入错误，登录失败，提示信息是否友好？
    • 输入过期的验证能否登录成功？
    • 验证码是否容易识别？
    • 验证码换一张功能是否可用？点击验证码图片是否可以更换验证码？

  • 登录成功或注册成功，是否保存信息

  • 密码存储方式？是否加密？

  • 用户体系：比如系统分普通用户、高级用户，不同用户登录系统后可的权限不同。

• （3）兼容性测试
  • 不同端：手机端、pc端、ipad端
  • 不同系统：ios、Android、Windows
  • app端：不同app版本
  • h5网页：不同浏览器
  • 机型适配：不同屏幕大小、不同分辨率
• （4）安全测试
  • 不登录：浏览器中直接输入登录后的地址，看是否可以直接进入
  • 登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
  • 用户名和密码是否通过加密的方式，发送给Web服务器
  • 用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证
  • 用户名和密码的输入框，应该屏蔽SQL 注入攻击
  • 用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）
  • 错误登陆的次数限制（防止暴力破解）
  • 考虑是否支持多用户在同一机器上登录；
  • 考虑一用户在多台机器上登录
• （5）性能测试
  • 单用户登录系统的响应时间是否符合"3-5-8"原则
  • 用户数在临界点时并发登录是否还能符合"3-5-8"原则
  • 压力：大量并发用户登录，系统的响应时间是多少？系统会出现宕机、内存泄露、cpu饱和、无法登录吗?
  • 稳定性： 系统能否处理并发用户数在临界点以内连续登录N个时的场景？

六、质量体系

两个角度考虑：（1）整个团队流程；（2）测试如何保证

6.1、质量管理

涉及整个项目团队的流程，从运营、产品、视觉、UI、开发、测试

• 流程的规范（各个评审是否到位、人员是否考虑周全）
• 产品设计，是否考虑和准备周全
• 视觉UI、设计要考虑实现、兼容、用户体验、成本
• 开发、保证自测质量、开发的可扩展性
• 测试、确保代码的功能质量、兼容、性能等。要满足需求
• 验收环节
• 用户体验环节

6.2、质量保证

• （1）测试策略：质量是多维度的，功能测试、性能测试、兼容性测试等多种测试类型的结合
• （2）用例质量：采用合适的用例方法，如何进行需求分析，用例评审
• （3）执行质量：如何保证执行深度（界面、关联模块、数据库、日志）与广度（系统测试类型
• （4）缺陷质量：Bug评审，引入合适的Bug流程；缺陷的根据
• （5）过程质量：合理的软件测试流程，测试过程监控
• （6）回归质量：确保原有逻辑的互不影响

七、手机端和pc端测试区别

• 1、用户界面差别：屏幕显示差异，电脑屏幕可以显示更多信息；
• 2、移动端场景复杂化：移动端使用场景比PC端更复杂，如：户外散步运动、地铁公交，办公室等，有时需要进行场景测试；
• 3、使用时间碎片化： 移动端使用时间呈碎片化，能快速使用、快速上网。
• 4、使用操作不一致：pc端：外设–鼠标、键盘、音响；移动端–触屏传感器
• 5、操作系统区别（兼容）：pc端Windows、mac、linux等，移动端：Android、ios等；
• 6、移动端的电池问题：电量问题一直也是移动端需要解决的问题，主要体现在耗电多、手机发热、充电频繁。
• 7、手机基本的通信功能：来电、短信与app的冲突测试