测试流程讲解
- 2. A 测试计划、 测试用例 立项 结束 测试工作总体流程图介绍 B 本地服务器 1 测试 C 本地服务器 2 测试 D 外网测试服务器测试 E 外网正式版测试
- 3. A 测试计划、测试用例 由产品经理讲解《项目需求规格说明书》并依据该文档设计 《测试计划》、《测试用例》 设计审核 进入下一阶段 《测试计划》 根据用户需求报告中关于功能 要求和性能指标的规格说明书, 定义相应的测试需求报告,即 制订黑盒测试的最高标准,以 后所有的测试工作都将围绕着 测试需求来进行,符合测试需 求的应用程序即是合格的,反 之即是不合格的;同时,还要 适当选择测试内容,合理安排 测试人员、测试时间及测试资 源等。 《测试用例》 将测试计划阶段制订的测试需 求分解、细化为若干个可执行 的测试过程 审核通过
- 4. B 本地服务器 1 测试 产生测试用例 依据需求文档编写测试用, 对需求文档中不明确处由 产品经理解答。 提交 BUG 开发人员提供新版本 回归测试 执行测试 根据项目模块划分将 BUG 提交给相应开发人员, 不 明确 BUG 提给开发组长, 由开发组长统一分配。 针对上个测试版本的 BUG 记录进行测试 进入下一阶段 合并代码到测试服务器 2 由开发员人将模块代码 合并到本地服务器 2 ,由 开发组长布置环境 上一阶段
- 5. C 本地服务器 2 测试 对上一版本 BUG 进行测试 查看功能是否正常, 如仍有问题可能为 开发人员遗漏合并 上一阶段 提交 BUG 开发人员提供新版本 回归测试 执行测试 发现 BUG 开发人员在服务器 1 上进行修改,经测试人员验证 通过后合并至服务器 2 针对上个测试版本的 BUG 记录进行测试 进入下一阶段 发布到外网测试服务器 根据项目安排进行交叉测试, 是否交叉测试由测试经理安排
- 11. TD 中优先级介绍 Bug 优先级 (Priority) :指缺陷必须被修复的紧急程度。 5-Urgent :阻止相关开发人员的进一步开发活动,立即进行修复工作;阻止与此密切相关功能的进一步测试 4-Very High :必须修改,发版前必须修正 3-High : 必须修改,不一定马上修改,但需确定在某个特定里程碑结束前须修正 2-Medium : 如果时间允许应该修改 1-Low : 允许不修改
- 12. TD 中严重程度介绍 Bug 严重级别 (Severity , Bug 级别 ) :是指因缺陷引起的故障对软件产品的影响程度。 A-Crash :错误导致了死机、产品失败(“崩溃”)、系统悬挂无法操作 B-Major :功能未实现或导致一个特性不能运行并且不可能有替代方案 C-Minor :错误导致一个特性不能运行但可有一个替代方案 D-Trivial :错误是表面化或微小的(提示信息不太准确友好、错别字、 UI 布局或罕见故障等),对功能几乎没有影响,产品及属性仍可使用 E-Nice to Have (建议): 建设性的意见或建议。
- 13. BUG 的修改顺序 BUG 的修改顺序: 1 、先按优先级修复,再按严重程度修复 2 、优先级相同时先修复严重程度高的 BUG 3 、优先级在 3-high 以上 BUG 需要尽快修改