- 一、前言
- 二、测试工程师
- 三、按测试员的方式思考
- 四、测试手段
- 五、程序错误分析
- 六、测试自动化
- 七、与程序员交互
- 八、管理测试项目
测试我觉得就是细心+全面+深度, 要有测试策略（重点），对时间分配要明晰，测试过程那些是需要关心的重点关心，哪些是需要去推动开发处理的就尽快抛出问题，也就是不捂问题
最好找自己比较熟悉的，比较擅长的领域。因为自己更熟悉，在需求、功能方面更明白，知道每个功能是做什么的，自己在设计用例时候会比较轻松。可以选择我们经常逛的网站，或者经常使用的APP
二、测试工程师1、测试员为很多客户服务 2、迅速找出重要程序问题
- 首先测试经过变更的部分，然后测试没变化的部分
- 首先测试核心功能，然后测试辅助功能
- 首先测试能力，然后测试可靠性
- 首先测试常见情况，然后测试少见情况
- 首先测试常见威胁，然后测试罕见威胁
- 首先测试影响大的问题，然后测试影响小的问题
- 首先测试最需要的部分，然后测试没有要求的部分
3、询问一切，但不不定外露 4、测试员关注失效，客户才能关注成功 5、不会发现所有程序问题 6、测试员不能有产品发布与否的权力
三、按测试员的方式思考1、测试需要推断，并不只是做输出与预期结果的比较 2、优秀测试员会进行技术性、创造性、批判性和实用性的思考 3、为了测试，必须探索 4、当测试复杂产品时：陷入与退出
四、测试手段1、关注测试员的基于人员的测试手段
- 用户测试
- α测试
- β测试
- 强力测试
- 有关领域的专家测试
- 成对测试
- 自用测试
2、关注测试内容的基于覆盖率的测试手段
- 功能测试
- 特性或功能集成测试
- 菜单浏览
- 域测试
- 等价类分析
- 边界测试
- 最佳代表测试
- 输入字段测试大纲或矩阵
- 用各种方法映射和测试编辑字段
- 逻辑测试
- 基于状态的测试
- 路径测试
- 语句与分支覆盖率
- 配置覆盖率
- 基于规格说明的测试
- 基于需求的测试
- 组合测试
3、关注测试原因（针对风险测试）的基于问题的测试手段
- 输入约束
- 输出约束
- 计算约束
- 存储（或数据）的约束
4、关注测试方法的基于活动的测试手段
- 回归测试
- 脚本测试
- 冒烟测试
- 探索式测试
- 游击式测试
- 场景测试
- 安装测试
- 负载测试
- 长序列测试
- 性能测试
5、关注测试是否通过的基于评估的测试手段
- 自检验数据
- 与已保存的结果进行比较
- 与规格说明书或其他权威文档比较
- 基于理念的测试
6、根据自己的看法对测试手段分类
五、程序错误分析1、测试员的程序错误分析会推动改正所报告的错误 2、使自己的错误报告成为一种有效的销售工具 3、看似极端的缺陷是潜在的安全漏洞 4、清楚的报告问题，但不要试图解决问题 5、如果修改出现问题，应与程序员沟通 6、不要坚持要求修改所有程序错误，要量力而行 7、如果决定据理力争，就一定要赢
六、测试自动化1、拓展测试领域，不要不断重复相同的测试
- 负载测试
- 性能基准测试
- 配置测试
- 耐力测试
- 竞争测试
- 组合测试
2、测试自动化要立即见效
- 系统设置与准备
- 辅助诊断
- 会话记录
- 测试生成
1、理解程序员怎样思考 2、获得程序员的信任 3、将关注点放在产品上，而不是人上 4、程序员喜欢谈论自己的工作，应该问他们问题
八、管理测试项目1、建设一种服务文化 2、不要尝试建立一种控制文化 3、轮换测试员的测试对象 4、尽量成对测试 5、如果测试经理要编写产品发布报告，应描述测试工作和结果，而不是自己对该产品的看法
