本来想介绍下百度文库QA的各个方面的工作，后来发现太过于混杂，所以就暂时只讲一个方面。
以下内容纯属个人经历，如有雷同 or 偏差，纯属巧合。
因为个人工作性质，所以绝大部分是PC、后端测试经历。
一些说明
- 可以用任何方式写测试用例
- Excel、脑图
- 缺点：测试用例很难沉淀
- 可以用任何方式测试项目
- 毕竟项目与项目之间差异还是比较大的。
- 常规功能型项目 vs 迁移类项目
- 时间充足 vs 时间不足
- 等等
- 毕竟项目与项目之间差异还是比较大的。
- 所要达成的目标
- 项目及时、安全上线
- 及时
- 安全
- 项目及时、安全上线
- 有关浏览器
- QA：IE6、8、9、10
- 开发：Chrome、Firefox
- 部分项目只支持 Chrome
常规项目
- 需求评审
- 参与讨论整个项目，包括功能的取舍，开发可能采用的方案。
- 会后要整理项目中不明确的点，拉上产品和开发，弄明确。
- 注意产品逻辑上有冲突的地方。
- 考虑到产品、开发、测试的人数和工作分配，基本上测试人员更收敛，更容易发现这些问题。
- 详细设计评审 / 开发沟通
- 早期比较完整的周期里，是有详细设计评审的，后期的项目除非是复杂、重要的项目，一般没有了。但是也需要和开发沟通。
- 了解开发如何设计、准备怎么开发。与开发讨论可能各个方案可能会产生的问题。
- 测试用例编写
- 使用常见的各种编写测试用例的手段
- 各种异常测试用例设计
- 可能包含准入 case
- 测试用例编写完成之后提供给开发作为自测使用，开发需要保证准入 case 通过
- 测试用例评审
- 早期的大部分项目都有测试用例评审，由文库QA团队参与，对编写的测试用例进行检查。
- 排期制定
- 根据测试用例，预估排期。
- 早期的测试排期按照：一轮+bug修复、二轮+bug修复、回归 来制定。
- 后期的测试排期基本只有一轮+bug修复+回归了。
- 测试环境准备
- 一般提测前一天
- 构建最新的测试环境并调通，保证测试环境可用
- 每人有自己的测试机，完整环境单机部署。
- 如果发现异常（一般可能是有一些环境、配置有变化），调通环境之后，维护环境搭建工具。
- 文库的环境搭建工具是由QA维护。（以后再聊）
- 提测
- 获取提测单
- 上线步骤
- 数据库变动 SQL
- 相关 webserver 配置
- 上线模块与版本号
- 服务起停步骤
- 上线步骤
- 部署测试环境
- 检查环境可用
- 如果不可用，检查环境本身问题
- 如果是上线步骤有误，及时通知开发
- 严重的模块遗漏、步骤错误（错误原因不明），提测打回
- 检查环境可用
- 获取提测单
- 测试
- 执行准入 case
- 严格意义上，准入 case 不通过，直接打回。不过如果是简单错误，类似于笔误之类，可以容忍。
- 需要 QA 自己清楚出问题的原因。
- 执行其他 case
- 检查本项目之外的产品核心功能
- 拿文库来说，就是上传、下载等
- BUG 反馈
- 开发修复 BUG
- 新一轮提测
- 根据情况考虑是否重新搭建新环境或者直接部署最新代码
- 重点检查上一轮 BUG 和 核心 case
- 有关代码 review
- 一般来说不强制要求，不过基本上都应该过一遍。
- 重点核查
- 关键校验
- 数据库相关（安全性、读写库的账号）
- 异常处理
- 延迟处理
- 命令点延迟（消息队列数据持久化延迟）
- 主从延迟
- 根据代码 review 情况优化 case 执行
- 适当增减 case
- 有关性能测试/压力测试
- 非必须项，取决于预估的请求量和对线上的影响
- 请求量预估较大
- 影响核心接口
- 需要评估的项，按需观察
- CPU、内存、带宽、响应时间
- 评估的准确性
- 对性能影响较多
- 线下测试：基本只能预估
- php 进程数、CPU 核数、内存大小与线上差异
- 网络环境与线上差异
- 存储与线上差异，数据库、redis、cache 等读写
- 部署情况与线上差异
- 整机 or Docker
- 线上预览机 or 真实容器测试
- 观察机器性能指标
- 更准确的看到压力情况
- 但仍要注意，如 数据库等相关压力，依然无法准确预估
- 测试过程中对于请求时间过长、redis or cache 过大保持警惕
- 注意提醒开发预判
- 非必须项，取决于预估的请求量和对线上的影响
- 有关安全
- 关键数据获取方式
- 用户数据获取，通过 token 而不是相信传入的 uid
- 关键 id 加密
- Sql 注入、XSS 注入
- 等等
- 关键数据获取方式
- 有关回归
- 严格意义上，在确定开发修复完所有 bug 之后，需要开发合并最新代码，对最新版本的代码进行回归测试。
- 不过具体到执行上，考虑到各种因素，一般只是对整体功能再过一遍。
- PM 检查
- PM 在测试环境，检查各种功能、文案、样式。
- 执行准入 case
- 上线
- 上线流程也一直在变化，早期需要各个角色过上线单，包括经理；之后经过了很多的简化，这里不做赘述。
- 一般上线到单台测试机的时候，会进行单台测试回归。
- 开发、QA和 PM 共同对线上进行功能回归，确保项目功能正常，同时确保线上整体服务稳定。
- 开发发上线完成通报，QA Re 线上测试情况。
- 后续
- 项目上线之后，QA 会对项目进行总结，包括每一轮的 bug 数，千行 bug 率的统计，以及低级 bug 统计和其他问题的说明。
迁移项目
Lighttpd 迁移 Nginx
- 问题
- 配置方式完全不同
- 不同 host 的逻辑
- URL 的 rewrite 规则完全不同
- 数百 rewrite 规则
- 其他
- 类似于 Content-Type、Transfer-Encoding 等 HEADER 项的影响。
- 配置方式完全不同
- 分工
- QA 保证功能： URL rewrite 正常
- OP 保证其他
- 备注
- 实际上，QA 和 OP 对于 nginx 都是新手，大家互相协作，共同查阅资料来处理。
- 实际步骤
- QA 根据旧的 Lighttpd 配置，梳理好所有的 rewrite 规则，然后整理出所有 来源 -> rewrite之后 的 URL 映射。
- 交付映射表给 OP， OP 开始写新的 rewrite 规则。
- QA 写校验脚本
- 对代码简单重写，使之直接输出 rewrite 之后的 URL
- 对新旧两个 webserver 批量执行脚本，获得两份 rewrite 之后的 URL
- 批量比对，批量检查，逐个修复。
- 一些注意
- 有关重定向的写法，需要单独检查。
- 影响 rewrite 规则的，不仅仅是 path 部分，还有 query 部分，写 URL 清单的时候，务必覆盖同一个 rewrite 规则的各种情况。
- 测试机验证核心功能
- 线上单机/小流量验证
- 线上全流量
- 后续还是遗漏了的问题（部分在单机/小流量期间发现）
- 少量奇葩的 rewrite 规则的个别分支 case 遗漏。
- 日志打印方式
- 虽然注意了这个问题，但是还是有一些细小的遗漏，影响了部分的统计
- 因为某些 header 参数问题，影响了 CDN 的处理。（细节忘了）
- 其他
- 对于这种项目的测试，需要有清晰的思路，需要保证哪些，如何进行测试。
- 和其他角色如何进行分工。
一些其他问题
- 测试项目的时候 QA 需要知道的知识
- 产品线的代码架构，未必需要知道细节，但知道有哪些部分，怎么关联，数据怎么传递。
- 线下环境与线上环境的差异
- 检查必要的地方，以确保线下测试可能漏掉的部分
- 例如数据库读写的问题
- 检查必要的地方，以确保线下测试可能漏掉的部分
- 如何看日志，什么时候看哪些日志。
- 除了功能测试之外，还需要关注什么
- 延迟问题
- 安全问题
- 性能问题
- 如何分配时间
- 时间是肯定不够用的
- 应该关注哪些，放弃哪些
- 排期和分工
- 早期，制定排期的时候，一般要求测试时间约为开发时间的 1/3，如果达到 1/2 ，需要汇报原因。
- 然而当测试排期被列入 KPI 的时候，当测试周期被要求在 2天以内的时候，如何安排测试工作、排期就需要重新考虑。
- 同时开发自主上线项目的增多，开发的频率变快，周期变短，也对测试工作造成影响。
- QA 重点保证
- 数据读写的正常
- 没有严重的样式问题（细节问题由 FE 保证和 PM 检查），QA 减少样式检查。
- 增加线上监控工作
- 这种变化也会对其他数据，诸如线上漏测等问题的统计分析造成影响。
- 哪种问题才是“线上漏测”
- QA 人力的问题
- 早期，客户端尚未纳入产品线本身，测试工作也不在文库QA的时候，文库的测试人力，一般也有 4名正式员工 + 4名实习同学左右的人力。
- 后期，当文库、阅读产品线增多，客户端回归之后，产品线 PM 和 开发人力大量增多的时候，除去移动端测试人力，PC 和 Server 的测试人力长期只有 4名。
- 需要考虑人力分配，哪些项目测、哪些项目不测
- 考虑到还有其他工作方向（后续有时间可以聊一聊）
- 测试环境维护
- 竞品分析与数据清理
- Bad case 挖掘
- So，其实很难办。
- 有关项目测试与晋升
- 有关质量部和产品线的关系
- 项目测试，往往看不出成果，所以很多测试能力强的晋升其实要更困难一些
- 如何在测试中提高姿势水平
- 有关 QA 的技能和竞争力
- 很多工作其实 QA 和 开发都可以做，只是分工的问题。
- 当 QA 人力下降到一定程度，对于整个 QA 团队来说，需要重新去思考 QA 的定位。