一、测试用例力度
1、测试用例的本质：是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法思路记录下来，以便指导将来的测试。
基于需求的测试用例设计
- 基于需求的用例场景来设计测试用例是最有效的方法，因为它直接覆盖需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
- 要把测试用例当成活得文档，因为需求是活得，善变的，因此在设计测试用例方面要把敏捷方法“及时响应变更比遵循计划更有价值。
不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要重新回来重新评审和完善测试用例。
2、测试用例的评审
同行评审
- 测试用例有很多评审方法，同行评审是最敏捷的一种。
- “个体和交互比过程和工具更有价值”，这体现了测试用例设计之间思想的碰撞，通过探讨、协作完成测试用例的设计。
用户评审
- 顾客的写作比合同更有价值。
如果测试是对产品的批判，则顾客应该指最终用户或客户代表
如果测试被定义为对开发提供帮助和支持，那么顾客就是程序员
二、软件缺陷
1、定义:缺陷就是软件的问题，最终表现为没有满足用户的需求。
- 软件未达到功能需求说明书的功能。
- 软件中出现了需求说明书中指明不会出现的错误
- 软件的功能超出了需求规格说明书指明的内容
- 软件未达到需求说明书虽未指明而应达到的目标
- 软件测试人员认为软件难以理解、不宜使用、运行速度慢、或者最终用户认为不好。
2、软件缺陷的表现形式：
- 功能、特性没有实现或部分实现
- 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
- 产品结果与所期望的结果不一致。
- 没有达到需求规格说明书所规定的性能指标等
- 运行出错，包括运行中断、系统奔溃、界面混乱等。
- 数据不准确、精度不够、不完整或格式不统一。
- 用户不能接受的其他问题，如存取时间过长，界面不美观。
- 硬件或系统软件存在其他问题。
3、缺陷状态
- 提交（submit）：测试人员体交一个bug给程序员
- 打开(open)：确认体交提交缺陷，等待处理bug
- 拒绝(rejected):拒绝提交的缺陷，不需要修复或不是缺陷、重复缺陷、缺陷无法重现
- 修复(resolved)：缺陷被修复
- 关闭(closed)：确认修复的缺陷被关闭
- 推迟(later)：可以以后解决，但要确定修复日期或版本
4、缺陷程度的划分：
缺陷ID：缺陷的ID，可以根据ID追踪缺陷
缺陷状态：缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷标题：描述缺陷的标题
缺陷严重程度：对软件程度的影响程度，分为致命、较严重、严重、一般、低
5-critical：系统奔溃、异常退出、死循环、严重的计算错误等
4-very hight：频繁死机、系统大部分功能不能用
3-hight：功能点未实现、或不符合用户需求、数据丢失
2-medium：影响一个相对独立的功能、仅仅在特定条件发生、与产品需求定义不一致、断断续续出现问题
1-low:表面性错误（如错别字）
缺陷的优先级：缺陷修复的先后顺序，即那些缺陷优先修复、那些可以稍后修复
缺陷所属模块：缺陷所属的项目和模块，要能准确的定位至模块
系统缺陷：由于程序引起的死机，异常退出；程序死循环；程序错误，不能执行正常工作或重要功能，是系统奔溃或资源不足
数据缺陷：数据计算错误；数据约束错误；数据输入、输出错误；
数据库缺陷：数据库发生死锁；数据库中的表、缺省值未加约束条件；数据库连接错误；数据库中有多余或少字段、空字段；
接口缺陷：数通信错误；程序接口错误；
功能缺陷：功能无法实现；功能实现错误；
安全性缺陷：用户权限未实现；超时限制错误；访问控制错误；加密错误；
兼容性缺陷：与需求规格配置兼容性不符；
性能缺陷：未达到预期的性能目标；性能测试中出错，导致无法继续测试；
界面缺陷：操作界面错误；打印内容格式错误；删除时未给出提示；长时间操作未给出提示；界面不规范；
建议：功能建议；操作建议；
缺陷记录者：体交缺陷的人员姓名
缺陷提交时间：
缺陷处理人：
处理结果描述：
缺陷处理时间：
缺陷验证人：
验证结果描述：
出缺陷详细描述：缺陷重现步骤
缺陷环境描述：
必要的附件：bug截图等资料；