测试测什么？
数据的正确性包括：数据写入和数据提取，数据写入时使用ui界面直接操作，测试涵盖前端操作，接口正确测试，后端逻辑验证。
数据输出时使用数据库语句提取正确数据然后和前端返回显示的数据做比较来验证，验证包括后端数据库语句正确，接口正确返回数据，前端正确显示数据。
学习路线
测试用例编写 -> 单元测试unittest | 接口测试 -> 性能测试Apache ab -> UI自动化测试
测试类型
功能测试、性能测试、压力测试、GUI测试、安装测试、文档测试。
测试阶段分类
单元测试: 测试单个函数是否符合预期功能。
集成测试: 把两个已经测试过的单元组合成一个组件，测试它们之间的接口。API测试属于该阶段。
系统测试: 主要的就是功能测试，测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。测试方法一般都使用黑盒测试.
验收测试：验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务
测试用例
用例编写要素
1 编号
定义测试用例编号，便于查找测试用例，便于测试用例的跟踪，如阶段不同，测试方式(手工|自动化测试)与测试用例的一一对应。
测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性，根据不同的项目使用统一的约定就好，如："模块名称+测试阶段+编号"，login-ST-001。测试阶段见测试阶段.
2 测试标题
应该清楚表达测试用例的用途。
比如，写登录：
"测试登录按钮"只写测试的点，范围太大，不符合一个用例只测试一个点的要求。
"点击登录按钮测试"动词类的写法，不清楚点击按钮是测试按钮的显示动效还是点击后的其他反应，不够细致。
"测试用户登录时输入错误密码时，软件的响应情况"就比较符合整体情况。
3 优先级
方式1：
最高（又称Build Verification tests）也叫冒烟测试用例，一组你运行以确定这个build版本是否可测的测试用例。
高：这种用例运行，能发现重要的错误，或者它能够保证软件的功能是稳定的。俗称大的基本功能的测试用例。
中：检查功能的一些细节，包括边界、配置测试。
低：较少执行的测试用例，并不代表它不重要，而是说不是经常被运行。例如压力测试错误信息等。
方式2：
P0：RD交付给QA前必须测试通过。
P1: 主要的使用场景。
P2：次要的使用场景。
p3：执行过一次后不需要频繁执行的。
优先级设计参考：
保证基本流(基本功能实现)的用例为高级的。
备选流的用例为中级的。
边界值和错误猜测法设计的无效的用例，为低级。
一般来说，如果B/S的链接会跳转到新的页面，这样的用例为高，删除，返回，取消，刷新，更新，翻页等类似的功能的用例为中。
UI中样式，颜色，大小，位置的用例为低。
4 预置条件
就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试
总结
- 一个测试用例只能测试一个点，切记。写法应该和断言的思路相同，一个测试用例只测试一个点。
- 按照标准的格式写，包含8要素。
- 步骤和预期结果都要写上序列号，方便导入testlink或者自动化测试用例的一一对应。
- 写用例可以按照写程序的思路，提取公共模块，写上每个进入该模块的入口，每个入口进入需要测试一遍该用例。
用例管理工具
Google docs
Google docs的Excel适合只有几个人的时候协作使用，方便，轻便，但是一直需要外网，国内也有类似的在线office可以使用。
Excel
excel用例管理字段太少，不利于搜索及扩展定制协作：svn 和 git由于只能保存Excel协作，容易冲突，不推荐使用。
testlink
当人比较多的时候，使用testlink比较方便，可以多人协作，且有历史记录可以和bugtracker集成。但是，响应较慢，且导入导出不太方便，如果不用评审的话还是很好用的。
集成在缺陷管理工具中的
禅道管理用例
缺陷管理
redmine
插件
在开始菜单中打开：Bitnami Redmine Stack Environment命令行工具(product fullname)安装方法见官方文档
进入到apps/htdocs/plugins目录运行bundle install安装缺少的依赖包
cd 然后安装plugin
rake redmine:plugins:migrate RAILS_ENV=production #Redmine 2.x注意:ruby使用gem从官网下载东西时，会有超时出错的问题，这个时候可以使用taobao的ruby镜像来安装
cmd设置如下：
gem sources --remove https://rubygems.org/
gem sources -a https://ruby.taobao.org/总结
bug输入
1.测试的bug尽量写全信息，如当前登录的双方账号，使用的机子，顺便创建一些给开发使用的数据，能贴图时尽量贴图
自动化
直观来说自动化可以测试3种数据：
- 后台API假数据测试正常返回码
- 自动化创建数据，测试UI各种显示
- 前端自动化测试各组件正常响应
完整的自动化测试流程
读取配置文件->读取测试用例->执行测试用例->记录测试结果->生成测试报告
配置文件：IP 域名 接口信息
测试数据：ddt，Excel管理，数据库管理(测试平台管理)
分类：单元测试(unittest,pytest)->集成测试(包括api)>系统测试->ui自动化测试
单元测试
单元测试:python unittest
单元测试覆盖率检测有现成的第三方工具，比如 code climate 、 Coveralls
优先级最高
粒度最细、覆盖面最全
开发实施
集成测试
集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
对测试来说优先级最高
从业务场景的角度切入
系统外部接口100%覆盖
关注系统间的依赖和调用
接口测试
Browser/server
App/server
Client/server
分类
广义的接口：人机界面、硬件接口、软件接口
软件接口：HTTP接口、Web Service接口、基于某种网络协议提供的接口服务
API接口：应用程序编程接口(需要有接口规范)
我们常说的接口，是指程序之间提供服务的软件接口。最常用的接口是指基于TCP/IP传输的HTTP协议的接口。
需要测试的场景
同层之间接口的调用（一个接口调用了其他接口）
各个子系统之间的交互（APP调用服务端的接口）
外部系统与系统间的交互（APP调用第三方的接口）
服务与服务之间的调用
接口测试方法
可以通过编写脚本代码进行测试，如python的unittest
可以通过工具进行测试，postman，filddler
可以手工在浏览器进行测试(firebug)
注意：接口测试并不仅限于HTTP接口，API接口测试不等同于HTTP接口测试。
接口测试流程
服务端没有完成，根据前后端约定的接口文档，前端和测试都可以开始自己的工作。
接口测试设计需考虑因素
- 请求参数的必填项和可选项；
- 请求参数的合法输入和非法输入；
- 请求参数的边界值；
- 请求参数的异常处理，例如：未带入必填项参数等
- 基于业务场景的考虑，例如：登录态、权限、依赖性等
- 涉及到DAO层调用的，考虑数据增删改查的正确性
接口测试常用工具
切换host工具：SwithHosts
抓包工具：Fiddler、Charles、WireShark等，purbsuit（推荐有人说比fildder好用）
调试工具：firebug等
辅助测试工具：Postman、HttpRequester、火狐JsonHandle
第三方工具：SoapUI、 Robot Framework + HttpLibrary等
服务层相互调用：unittest,Mock,HttpLibrary,Database Library
接口Mock方法
很多app都依赖接口返回的数据来完成响应的功能，保证接口返回数据异常时：
- 不会崩溃
- 没有影响如数据不完整
- 有友好提示
在后台api没有开发完全时，使用mock数据调试前端。
Fiddler用作Mock Server
常见的接口异常模拟方法，有修改后台server，代码，数据或者配置，但这种方法不方便，代价大。使用虚拟的数据最好。
基于的FiddlerCore二次开发的Mock工具。
- 支持URL模糊匹配
- 支持文本内容，支持返回指定的图片文件
- 支持网络延迟
总结
单一接口优先测试，覆盖正常情况，不仅要检验返回值，还要检验数据变更是否符合预期，断言通过编程语言实现，并支持数据库查询比较。组合接口通常是模拟到真实的业务场景。
UI测试：
工具：QTP，Robot Framework、watir、selenium、appium等，优先级相对最低，只保证核心功能的自动化覆盖，只关注UI层的问题，通过数据mock的方式减少对后台数据的依赖。
session
session 结构：
{
"id": {
"一些自定义的key": "一些自定义的value"
}
}标准的http的session放在response的header中的set-cookie字段中，也可以依据约定放在body的某个字段中。
持续部署
从手工 SSH 链接几十台机器git pull，部署，重启升级到自动化构建，测试，部署(需要测试,灰度,正式环境,依赖包,环境配置等)。
测试给出的设计意见
1.多语言中英文的宽度，配置文件最好设置为差不多，很多地方的宽度按照中文宽度来，切换到英文显示就会有问题：消息中个人昵称
2.当使用第三方接口时，尽量按照第三方接口数据来设计，如注册登录，尽量使用第三方返回的数据和code来做前端显示提示
3.当发现实际和需求有出入时，可以按照用户体验修改需求，不一定什么都按照需求来修改，不然会在后期真正上线使用的时候反而发现很多问题，测试有必要在前期发现不合理并修改