一、测试概念:
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的冲突测试