【笔记】软件测试

参考：
[1]《软件测试》by Ron Patton
[2] 软件测试 (一) 软件测试方法大汇总
[3] Testin公开课-互联网测试行业的现状与趋势
[4] 网易云课堂：测试微专业、孙志岗

what：

• 制作软件产品所必须的 幕后决策工作[1]
• 过程中：始终站在用户的角度去判断软件缺陷的影响，尽一切手段 降低成本和提高质量：尽早和不断地测试。
• 对软件进行 ？工程设计、实施和维护的 整个生命周期过程。
• 产出：对软件质量和风险的全面评估。

---

why：

• 第三方进行测试会更客观、有效：
  
  • 对于需求的错误理解较难在程序员自测时被发现。

---

how：

分类

按方法

• 黑盒(功能测试或数据驱动测试)：基于需求和功能性的测试；只需I，关注得到的O。
  
  • 方法有：等价类划分、边界值分析、因—果图、错误推测（异常情况？）
• 白/开/空 盒 (结构测试或逻辑驱动测试)：
  
  • 优：访问代码→可据源码 调整测试程序，有所针对侧重而非盲测。
  • 缺：风险←易形成偏见，测试不客观。
• 灰盒：介于黑盒和白盒之间。

按对象

• 静态：测试不运行的部分→检查审阅
• 动态：通常意义上的测试→运行使用软件

按效率

• 手动：（？测试GUI）胜在测试业务逻辑。
• 自动化：用程序测试程序 。（？测试API）胜在测试底层架构。

按目的

1. 先 功能测试，按阶段分：
   
   • Unit单元测试：验证在最低的功能/参数上程序的准确性；模块高内聚。（开发人员）
   • ？Functional功能测试：验证模块的功能 （测试人员）
   • Integration集成测试：验证几个互相有依赖关系的模块的接口和功能 （？）
   • ？Scenario场景测试：验证几个模块是否能完成一个用户场景 （测试）
   • 系统/产品 测试：对于整个系统功能的测试 （开发方测试小组）
   • Acceptance验收测试：全面考核某功能/特性（需求提出方）
     
     • Alpha 测试：在系统开发接近完成时，模拟实际环境中的全面测试 （最终用户或公司内部用户）
     • Beta 测试：当开发和测试根本完成时，在真实的用户环境中进行测试，也叫公测。定期报告一切真实在或想像的问题给开发。（最终用户）
   • ？A/B test ：数据分析，判断选用的功能分支。
2. 再 非功能测试
   
   • Compatibility兼容性测试：测试软件能否与不同的软件正确协作
   • ？Configuration配置测试：保证软件在其相关的硬件上能够正常运行
   • Security安全性测试
   • Performance性能测试：测试软件的效能，是否提供满意的服务质量
     
     • 压力测试：在超过负载设计的情况下仍能返回正确的结果，没有崩溃。
     • Load负载测试：在负载情况下能否正常工作
   • 用户体验
     
     • Accessibility辅助功能测试：是否向残疾用户提供足够的辅助功能
     • Localization/Globalization本地化/全球化测试
     • Usability可用性测试：是否好用

按策略

• Smoke冒烟测试
  
  • Build Verification Test（BVT）：验证构建是否通过基本测试。
• Regression回归测试：确保 代码经修改后 原有功能没被破坏（对一个新的版本，重新运行以往的测试用例。适合自动化）【在新功能测试之后】
• Sanity粗略的测试， 只需要执行部分的测试用例
• 基于直觉经验的
  
  • Ad hoc探索性测试：抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。【可结合场景，黑盒方法，反馈（+每次使用的数据有别）】
  • ALAC(Act-like-a-customer)测试：基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

---

流程

格式/符号：
黑斜体：测试的一般流程
+ ：扩展的降低bug修复成本的方法或产品成熟度较高的采用方法
子目录：详细、补充

1. 产品/策划 设计产品，需求分析。
   
   1. +同 策划、开发、需求提出方的 需求确认环节：评审 需求文档+（系统或程序的）设计方案。
   2. 测试 (应比产品更)熟悉业务，收集信息，如参考其他同类产品；找某些功能描述不明确的，整理成excel进行确认。
2. 交互 具象化并内敛需求，易于开发实现【类建筑设计】
3. 视觉 风格设计【类建筑效果图】
4. 测试准备阶段：测试-需求分析 > 用例设计+测试计划（>准备 测试环境+测试脚本）
   
   1. 如果是新项目（QA从头开始）：，一般先用例设计。对总体的测试工作量和复杂度有了预期之后，再根据开发计划制定测试计划
   2. 如果是自己熟悉的项目（QA对整个功能和团队都很熟悉了）：一般先测试计划。
5. +评审用例
6. 开发 完成代码和自测
   
   1. +不需等开发完再介入，将一次版本迭代周期的开发内容划分成 低耦合模块 来提测。
7. 用例执行 > 发现-提交-跟进bug
8. 总结质量报告
9. +自动化部署 测试+发布 环境
10. +灰度发布的策略制定及技术支持：在前一阶段开放更新版本的部分用户的反馈修正中 逐步扩大发布范围
11. 最终版本发布+维护
12. 运营 >反馈用户情况给 策划 ，进行下一轮迭代。

---

+？
1. 先接口：保证服务端正常
2. 再联调：服务端和客户端
3. 再功能：测客户端
联调/组装/子系统/部件 测试：
性质 集成
侧重点于 模块间接口的正确性、各模块间的数据流和控制流是否按照设计实现其功能、以及集成后整体功能的正确性。