测试用例力度、缺陷

一、测试用例力度

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截图等资料；