测试的原则

• 所有测试活动都应追溯到用户需求。
• 应尽早不断的测试避免测试和开发成本
• 用户需求（原始需求）-->评审-->需求规格说明说-->测试需求
  • 没有完美的测试和完美的软件，只有未被发现的缺陷，没有不存在问题的软件
• 应充分注意测试中的集群现象：
  • 二八定律（又名80/20定律、Pareto帕累托法则（定律）也叫巴莱特定律、最省力的法则不平衡原则等）。（重点突出）
  • 应该避免程序员自己检查程序，尽量避免测试的随意性。
  • 测试的good enough：不要做不充足的测试，也不要做过多的测试，以合适的代价来降低相应的成本
• 兼顾合理的输入和不合理的输入数据
  • 设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况程序修改后要回归测试。
  • 制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试
• 测试用例的基本概念
  • 测试用例的概念：为了实施测试而向被测系统提供一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
  • 解决要测什么、怎么测和如何衡量的问题
  • 测试用例可以分为：场景测试用例（简称“测试用例”）和基本测试用例（简称“公用测试用例”）
• 测试用例的优点：
  • 组织性、有计划、规划、规范
  • 有科学依据或经验支撑
  • 避免重复、冗余，降低成本、提高效率
  • 功能覆盖
  • 可持续复用
  • 跟踪
  • 测试确认
• 缺点
  • 测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多。（耗时）
• 软件测试用例的作用
  • 执行测试的有效依据(文档而非口头或主观)
  • 追溯测试的有效依据(回归、缺陷分析)
  • 衡量测试工作量的有效依据
  • 衡量测试人员工作量和工作质量的依据
  • 评估测试覆盖力度的依据
  • 验证需求和寻找缺陷的重要手段
  • 为新版本或其他项目参考和累积测试经验
• 准备编写测试用例
  • 收集资料
  • 需求文档
  • 设计文档
  • 遗留系统相关文档
  • 与相关人员讨论
  • 探索性测试
    • 把软件当产品说明书来对待，分步骤地逐项探索软件特性，记录软件执行情况，详细描述功能。
  • 可以通过探索性测试来获得更多的需求。
  • 可用于重现和分析缺陷、研究缺陷和程序其他模块的相关性
  • 是测试用例有利的补充
  • 具体问题具体分析
• 何时编写、修改测试用例
  • 需求、设计缺失或不完整:
    • 需求、设计缺失或不完整:
  • 需求、设计完整:
    • 熟悉需求、设计之后,编码之前
    • 软件代码、需求、设计变更后测试用例需要变更
    • 执行用例过程中或执行之后需要适时调整、修改
• 测试用例的更新与维护
  • 需要更新和维护的原因
  • 需求变更，功能变化，测试用例也需要更新
  • 测试用例需要细化和不断完善，是个循序渐进的过程
  • 通过测试实践检验测试用例并添加、修改、删除测试用例
  • 测试用例要经过正式、有效的评审
  • 利用测试工具来管理测试用例
• 设计测试用例所需要的素质
  • 测试用例的方法
  • 考虑问题的全面性
  • 业务知识的深刻性
  • 逆向思维能力
  • 丰富的测试经验