软件测试基础讲义概论.ppt

* * * * * * * * * * * * * * * * * * * * * * * * 确定输入数据的情形： 操作步骤 预期结果 输入正确的用户名和口令（均为6位），点击[OK]按钮 进入系统 输入正确的用户名和口令（均为10位） ，点击[OK]按钮 进入系统 输入正确的用户名和口令（均为6至8位之间），…… 进入系统 用户名为空，…… 提示输入用户名不能进入系统 用户名为空格，…… 提示无效用户名不能进入系统 用户名小于6位，…… 提示用户名太短不能进入系统 …………………… ……………… 确定具体的输入数据： “用户名” “口令” “预期结果” 说明 “user10” “pass10” 进入系统 正确的用户名和口令(6位) “user789” “pass789” 进入系统 正确的用户名和口令(7-9位) “user000010” “pass000010” 进入系统 正确的用户名和口令(10位) “” “pass” 提示输入用户名 不能进入系统 用户名为空 “空格” “pass” 提示无效用户名 不能进入系统 用户名为空格 “user” “userpass” 提示用户名太短 不能进入系统 用户名小于6位 “user0000011” “userpass” 提示用户名太长 不能进入系统 用户名大于10位 ………… ………… ………… ……………… 测试用例设计原则 测试用例的代表性 测试结果的可判定性 测试结果的可再现性 验收测试用例设计要点 出发点： 旨在确认软件符合需求规格的验证活动 范 围： 用户业务需求，但不超出合同范围 复杂度： 结构简单、条理清晰、屏蔽软件内部结构 角 度： 用户使用、根据业务场景组织测试用例和流程 测试用例的评审 覆盖面是否完全 描述是否清晰 测试用例是否正确 无遗漏 清晰易懂 正确准确 测试执行 功能测试的测试执行阶段主要完成以下工作： 配置测试环境，包括基础软硬件环境、被测系统环境和初始化测试数据； 根据事先设计好的业务流程执行业务用例 记录测试结果和测试过程中发现的问题 对测试过程中发现的问题，提交到缺陷跟踪系统中进行跟踪 收集测试过程中的各项信息，分析、控制测试过程 测试启动条件 测试计划和测试用例准备完毕 错误跟踪工具设置完毕 被测试的Build已经可用 测试的软件和硬件环境已经准备就绪 测试结束条件 所有软件缺陷得到处理（最好目标：0 缺陷） 在规定的时间内连续运行软件没有产生死机、系统崩溃和丢失数据的错误 完成了测试计划和测试用例指定的测试工作 软件经过“项目管理组”讨论，认为能达到客户的合理质量期望值 软件到了发布的截止日期 测试的启动与结束条件 缺陷管理 缺陷生命周期 软件缺陷生命周期有很多个阶段。根据不同的缺陷跟踪管理系统，下面的状态名称也会有所不同： 新建（打开）：当测试人员汇报新的缺陷时的缺陷状态。 延后处理：如果这个缺陷跟当前发布的这个版本没有直接关系，或者当前版本无法修复，或者这个缺陷不是很严重，不需要立刻修复，那么项目经理可以把状态设为“延后处理”。 已指派：“指派给”这个值是由项目组长或者项目经理来填，指定给具体的某个开发人员。 已解决/已修复：当开发人员做了某些必要的代码改动，并且确认修改之后，那么他/她就可以把状态改为“已修复”，然后就交给测试组进行回归测试。 缺陷生命周期 无法重现：如果开发人员根据测试人员在缺陷报告里面描述的步骤，都无法重现这个缺陷的时候，那么开放人员可以把这个缺陷标为“无法重现”。测试人员需要检查这个缺陷是否可以重现，并且把更为详细的重现步骤提供给开发人员。 需要更多信息：如果开发人员认为测试人员提供的缺陷重现步骤不够清晰，因而无法重现缺陷的时候，那么他/她可以把状态标记为“需要更多信息”。在这种情况下，测试人员需要提供更为详细的重现步骤，并把缺陷返回给开发小组。 重新打开：如果测试人员不满意这个修复结果，或者说即使在修复之后，依然出现同样的问题，那么测试人员可以把状态标记为“重新打开”，这样的话，开发人员就可以采取相应的行动了。 关闭：如果测试小组已经验证过这个缺陷的修复结果，并且问题是已经得到了解决的，那么测试人员就可以把状态改为“关闭”。 驳回/无效：有些时候，如果这个系统的确是按照规格说明来运行的，而缺陷的产生只是由于误解而引起的，那么开发人员或者小组组长可以把这些缺陷标记为“驳回”或者“无效”。 缺陷严重性等级定义 A类（致命缺陷） 导致对被描述的主要对象的理解错误、不可行、不能运转、对业务和整个系统可能造成重大损失或损害。 B类（严重缺陷） 对被描述的部分对象的理解或