测试分类
测试流程
产品提出需求后，开立项会进行讨论需求制定需求文档，开发根据需求文档进行编码，测试人员需要根据需求文档进行编写测试计划，以及对应的测试用例编写，用例编写结束后，进行用例评审，开发提交代码后执行冒烟测试，冒烟测试通过后执行过程中出现bug进行提交bug，并对bug进行追踪。bug关闭后我们做测试总结，提交对应的测试报告
测试需求点的提取
从功能、性能、安全性、用户体验、兼容性方面考虑
测试计划
包括：测试项目的背景、测试范围、测试策略、测试环境、测试开始和结束条件、进度安排、测试人员、测试风险管理
由谁来写：一般是由测试经理或者测试组长来写
目的：规范软件测试内容、方法和过程
测试用例
包括：用例编号、所属模块、用例名称、用例级别、预置条件、测试步骤、期望结果、实际结果、执行人、备注
写测试用例的目的：
1、避免测试时，多测，漏测
2、验收时方便回归测试
3、编写的过程时，可以更加方便了解该项目的需求内容
4、对于测试员工的进度上级有一个了解，测试自身也可以对自己的进度有一个了解
5、对于bug的发现更加方便，发现一个bug时，可以寻找类似用例发现是否有同样的bug。
6、可以对于一个项目有更加合理的评价
怎么保证覆盖用户需求
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
bug管理工具 -- 禅道
用于查看bug和管理bug
缺陷报告组成
①缺陷编号
②缺陷标题
③缺陷的发现者
④缺陷发现日期
⑤缺陷所属的模块
⑥发现缺陷的版本
⑦指派给谁处理
⑧缺陷的状态
bug的状态
| 英文 | 中文 |
|---|---|
| No Test | 未执行状态 |
| Pass | 通过状态 |
| Fail | 失败状态 |
| Block | 阻碍状态。 |
| Investigate | 观察中状态。 |
bug的定位 3种方式
①原始类(brute force)
②回溯类(backtracking)
③排除类(causeeliminations)
原始类定位方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是“通过计算机找错”。例如输出存储器、寄存器的内容，在程序安排若干输出语句等，凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免要耗费大量的时间和精力。
回溯法能成功地用于程序的排错。方法是从出现bug征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。
排除法基于归纳和演绎原理，采用“分治”的概念，首先确定所有与bug出现有关的所有数据，设想一个导致bug的原因，用这些数据证明或反驳它;或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击。
开发不认为是bug的时候
- 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
- 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
mysql 左右链接 子查询
子查询：select * from student1 where id = (select id from student2)
其中select * from student1 where id = 是外查询
select id from student2是子查询
所以。我们说子查询是嵌套在外查询内部。而其实它有可能在子查询内部再嵌套子查询。子查询必须出如今圆括号之间。
left join
reight join
左连接是以左表为主，右连接是以右表为主
数据库的事务
原子性、一致性、隔离性、持久性
接口测试 postman
如何做接口测试的
1，首先要看有没有接口文档，如果有文档的时候按接口文档去做，没有的话就去抓包。
2，我们一般使用postman以及jemter.
3，没有接口文档的情况下，要先创建一个线程组，指定并发的线程数量，在指定测试的接口，创建相应的监听器，（如，表格结果，结果树，以及聚合报告信息）通过监听器来进行监听测试是否通过以及接口存在什么问题。
性能指标
吞吐率：我们一般使用单位时间内服务器处理的请求数来描述其并发处理能力。称之为吞吐率（Throughput），单位是 “req/s”。吞吐率特指Web服务器单位时间内处理的请求数。
用户的响应时间：指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。
每秒点击数：某一物理时刻同时向系统提交请求的用户数。
资源利用率：
指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。
内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。
业务成功率：
性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示：
单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量，计算公式如下所示：
Tps：一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
web测试和app测试的区别
1.App的安装卸载：全新安装，升级安装，第三方工具安装，第三方工具卸载，直接卸载删除，消息推送测试，手机授权测试，前后台切换，网络环境（wifi/2G/3G/4G/无网络）。
2.App的中断测试：来电中断，短信中断，蓝牙，闹钟，拔插数据线，手机锁定，手机断电，手机问题（系统死机重启）。
3.兼容性测试：Web项目考虑不同浏览器的兼容，app需要考虑手机不同的操作系统，不同机型，不同屏幕等。
4.网路测试：不同网络与运营商，目前我国有三大运营商如：电信，移动，联通，不同的网络制式，如：GSM,CDMA,3G等，在不好或无网络的情况下的APP行为。
5.操作系统：大量的设备，各种的操作系统，目前使用最多的操作系统有：
Android,ios,windows,blackberry等，它们之间的应用软件互不兼容。
perfdog：app做性能测试的工具，界面非常简单，可以生成测试报告
稳定性测试 monkey命令
关联pc端和app的 ADB
项目版本管理工具 git/SVN
web自动化 python+slenium+unittest+htmlTestrunner+excel
下载浏览器对应的驱动，离自己版本最近的：https://blog.csdn.net/qq_37489565/article/details/89020200
自己写的自动化脚本：https://www.jianshu.com/p/ba1d886f90cf 没有封装的
app自动化 python+appnium+unittest+htmlTestrunner+excel
# 查看当前包名以及activity的名字
# adb shell "dumpsys activity |grep Focuse 低版本
# adb shell dumpsys window | findstr mCurrentFocus 高版本
from appium import webdriver
desired_caps = {}
desired_caps['platformName'] = 'Android'
desired_caps['platformVersion'] = '5.1.1' #安卓版本号
desired_caps['deviceName'] = '127.0.0.1:5554'
desired_caps['appPackage'] = 'com.android.settings'
desired_caps['appActivity'] = '.Settings' #自动进入的页面
desired_caps['unicodeKeyboard'] = True
desired_caps['resetKeyboard'] = True
driver = webdriver.Remote('http://127.0.0.1:4723/wd/hub', desired_caps)
print(driver)
#这个步骤可以连接到手机，界面元素定位方式和web一致
