软件测试技术测试流程案例.docx
《软件测试技术测试流程案例.docx》由会员分享，可在线阅读，更多相关《软件测试技术测试流程案例.docx（7页珍藏版）》请在冰点文库上搜索。
软件测试技术测试流程案例
案例：
缺陷报告流程
内容：
步骤一：
提交测试报告
测试人员张萍在对办公自动化系统V1.0进行测试过程中，发现了系统中的三个缺陷，并填写了三份缺陷报告，如表4-1、表4-2、表4-3所示，全部提交给了开发组长赵新。
表4-1第1份缺陷报告
缺陷报告
编号：
001
软件名称：
办公自动化系统
编译号：
版本号：
V1.0
测试人员：
张萍
日期：
2004年12月5日
指定处理人：
赵新
硬件平台：
P42.4G512M
操作系统：
Windows2000Server
严重程度：
功能问题（低）
优先级：
P2
缺陷概述：
起草一份通知后，如果不进行其它操作，就保存文档，系统会报错。
详细描述：
1．部门文书起草了一份通知。
2．不进行任何其它操作便点击“退出”按钮。
3．系统提示“是否保存”对话框。
4．在“是否保存”对话框中点击“是”按钮。
5．系统提示“写入状态库错误”的出错信息。
处理结果：
处理日期：
处理人：
在版本修复
修改记录：
返测人：
返测版本：
返测日期：
返测记录：
表4-2第2份缺陷报告
缺陷报告
编号：
002
软件名称：
办公自动化系统
编译号：
版本号：
V1.0
测试人员：
张萍
日期：
2004年12月5日
指定处理人：
赵新
硬件平台：
P42.4G512M
操作系统：
Windows2000Server
严重程度：
功能问题（高）
优先级：
P2
缺陷概述：
会议通知撤销流程有问题。
详细描述：
1.部门文书起草一份“会议通知”后，将其提交给部门经理签字。
2.部门经理开启文档浏览了一下，并未签字，然后关闭文档。
3.这时如果部门文书打开自己的已办事宜，该文档的撤销按钮还在，而且能把文档撤销回自己的代办事宜。
注：
如果一份文档已经被签字，是不应该允许撤销的。
处理结果：
处理日期：
处理人：
在版本修复
修改记录：
返测人：
返测版本：
返测日期：
返测记录：
表4-3第3份缺陷报告
缺陷报告
编号：
003
软件名称：
办公自动化系统
编译号：
版本号：
V1.0
测试人员：
张萍
日期：
2004年12月5日
指定处理人：
赵新
硬件平台：
P42.4G512M
操作系统：
Windows2000Server
严重程度：
界面
优先级：
P1
缺陷概述：
首页中有文字表述错误
详细描述：
首页右下角的LOGO中文字部分“×××公司办公自动化OA系统”表述不正确，“办公自动化”和“OA”属同一个概念。
建议去掉其中一个。
处理结果：
处理日期：
处理人：
在版本修复
修改记录：
返测人：
返测版本：
返测日期：
返测记录：
步骤二：
分配缺陷报告
赵新接到报告后，分别进行如下处理：
对于001和003：
开发组长赵新能够明确，缺陷报告中描述的缺陷确实是系统缺陷，应该立即修改。
于是填写两份缺陷报告中的处理信息后分别提交给相应的开发人员，如表4-4和表4-5所示。
表4-4开发组长对001报告的处理结果
缺陷报告
编号：
001
（以上内容忽略）
处理结果：
请开发人员张月验证该问题，如果确实存在，请修复。
处理日期：
2004年12月6日
处理人：
赵新
在V2.0版本修复
修改记录：
返测人：
返测版本：
返测日期：
返测记录：
表4-5开发组长对003报告的处理结果
缺陷报告
编号：
003
（以上内容忽略）
处理结果：
请开发人员刘明验证并修复此缺陷
处理日期：
2004年12月6日
处理人：
赵新
在V2.0版本修复
修改记录：
返测人：
返测版本：
返测日期：
返测记录：
对于4-2：
开发组长赵新翻阅了最新的需求文档，并与相关的开发人员进行沟通，最后明确得出“该报告中描述的现象不是缺陷，是按照用户最新的需求完成的。
”这一结论，并提交给测试组长，如表4-6所示。
表4-6开发组长对002报告的处理结果
缺陷报告
编号：
002
（以上内容忽略）
处理结果：
该报告中描述的现象不是缺陷，是按照用户最新的需求完成的。
处理日期：
2004年12月6日
处理人：
赵新
在版本修复
修改记录：
返测人：
返测版本：
返测日期：
返测记录：
步骤三：
分析缺陷报告
针对报告002中的问题，测试组长翻阅了相关的需求文档，发现关于“撤销”流程的描述不是十分的严密，在需求中阐述了“如果文档被处理就不允许撤销。
”这样的描述不够细化，让测试人员认为部门经理“浏览文档”的过程即是“处理”，而开发人员认为只有该文档被修改了才能算处理。
于是测试组长召开缺陷分析会议，包括开发组长和需求人员在内，针对所有有争议的缺陷进行讨论。
最后决定重新明确需求，按照用户需求确定问题是否为缺陷。
需求人员通过与用户沟通明确了详细的需求。
最后决定：
1.该报告中描述的问题不是系统缺陷。
2.需求人员修改需求文档，将“撤销”流程细化。
步骤四：
解决缺陷报告
1.相关开发人员修改报告001和003中的缺陷，并填写修改记录。
如表4-7和表4-8所示。
表4-7开发人员填写001报告的修改记录
缺陷报告
编号：
001
（以上内容忽略）
处理结果：
请开发人员张月验证该问题，如果确实存在，请修复。
处理日期：
2004年12月6日
处理人：
赵新
在V2.0版本修复
修改记录：
已经修复
张月
2004.12.7
返测人：
返测版本：
返测日期：
返测记录：
表4-8开发人员填写003报告的修改记录
缺陷报告
编号：
003
（以上内容忽略）
处理结果：
请开发人员刘明修复此缺陷
处理日期：
2004年12月6日
处理人：
赵新
在V2.0版本修复
修改记录：
已经修复
刘明
2004.12.7
返测人：
返测版本：
返测日期：
返测记录：
2.测试组长及时将缺陷报告002进行标记，并存档。
步骤五：
返测缺陷报告
开发人员修改了程序中的错误后，提交了V2.0版本，测试人员对001和003进行返测，并填写返则结果，如果问题依然存在或者引发了新的问题，则继续提交给开发组长，循环前面的步骤，如果验证缺陷已经修复，则提交给测试组长，如表4-9和4-10所示。
表4-9测试人员填写001报告的返测记录
缺陷报告
编号：
001
（以上内容忽略）
返测人：
张萍
返测版本：
V2.0
返测日期：
2004.12.18
返测记录：
该缺陷未被完全修复，不再提示出错信息，但保存文档不成功。
表4-10测试人员填写003报告的返测记录
缺陷报告
编号：
003
（以上内容忽略）
返测人：
张萍
返测版本：
V2.0
返测日期：
2004.12.18
返测记录：
该缺陷已经修复。
步骤六：
关闭缺陷报告
对于修复状态为“已经修复”的缺陷报告，由测试组长存档，对于没有修复的缺陷报告，重新提交给开发组进行修复，重复前面的步骤。
升级会员 