《软件测试流程规范精编版》由会员分享，可在线阅读，更多相关《软件测试流程规范精编版（23页珍藏版）》请在金锄头文库上搜索。
1、测试流程规范 部门 技术部 前言 提高产品的质量首先应当从流程抓起 规范软件产品的开发和测试过程 这是一个软件企业从小作坊的生产方式向集成化规范化大公司迈进的必经之路 流水线 防止人员工作间的内耗 极大的提供工作效率 软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发和测试中 形成软件工程过程 开发 测试流程 软件测试流程定义从需求到最终产品交付的一整套流程 如何去避免风险 共享成功的经验 按照流程进行管理可以使得我们少走弯路 并有效的提高产品质量 提高用户的满意度 目录 软件测试的意义公司软件测试流程规划软件测试的原则软件测试的流程软件测试要点缺陷管理外包管理公司软件测试流程现状
2、针对公司现状如何改变软件测试经验分享 软件测试的意义 验证软件的实现与需求的一致性 发现程序中的缺陷 确保产品功能正确稳定运行 了解和评估软件当前的质量风险 预防同类缺陷发生 软件测试的原则 尽早和不断的进行测试 实践证明单元测试能够尽早的发现问题 减少后期测试的错误量 由开发人员进行单元测试后交付测试组进行集成测试 开发人员应避免检查自己的程序 利用同行评审的方式对代码进行审查 严格执行测试计划 排除测试的随意性 这样才能消除各种无序操作造成的副作用 测试设计决定了测试的有效性和效率 测试工具只能提高测试效率 并不能完全保障测试效果 测试用例的设计要尽可能多的覆盖路径 测试用例编写原则 应由
3、测试输入数据 执行步骤和与之对应的预期输出结果三部分组成 测试原则 程序中的大部分错误往往是在小部分模块中发现的 遵循普遍使用的 二八定律 80 的错误往往是有20 的模块造成的 重点测试经常出错的模块 测试期间要保障测试系统的独立和稳定性 软件测试流程图 软件工程中各阶段的测试任务 软件测试要点 单元测试 概念 单元测试是软件测试的最基本组成 关注的是单元的具体实现 内部的逻辑结构和数据流向 开发人员完成编码后对代码的自检 单元测试要点一 模块接口测试检查模块接口是否正确 参数是否无误 单元测试要点二 数据结构测试检查代码内是否存在不适应或不相容的类型说明 变量初始化或默认值是否有错等 单元
4、测试要点三 边界条件测试检查边界值内合法边界值和边界值外非法边界值是否能够准确处理 单体测试要点四 代码覆盖检查每一条独立执行的路径 条件 分支 保证每条语句至少被执行一次 也就是代码覆盖率100 直接删除多余代码 软件测试要点 单元测试 单体测试要点五 出错处理检查系统处理异常能力 对错误操作是否能够提供足够的定位信息 单元测试用例设计思路为系统运行设计用例 为正向测试设计用例 为逆向测试设计用例 为满足特殊需求设计用例 为代码覆盖设计用例等 软件测试要点 集成测试 集成测试要点一 接口测试按各模块是否可以准确衔接参数传递是否无误 概念 在单元测试的基础上 将所有模块按照设计要求 组装成为子
5、系统或系统 进行集成测试 集成测试要点二 数据测试页面各项数据流向正确 集成测试要点三 逻辑测试系统各种业务逻辑是否正确 软件测试要点 系统测试 系统测试要点一 功能测试按照 项目详细需求说明书 要求产品各项控制是否完整正确 产品主流程序正确 接口正确 基本功能添加 删除 修改 查询 信息显示状况无误 概念 对完成集成测试的产品进行全面详细的测试 包括功能测试 数据测试 逻辑控制测试 易用性等各种测试项目的测试 即有接口关系的产品模块进行组合测试 是所有测试阶段中最注重细节的测试 系统测试要点二 数据测试页面各项数据流向正确 数据计算公式无误 系统测试要点三 逻辑测试系统各种业务逻辑正确 对非
6、常见逻辑增加控制 软件测试要点 系统测试 系统测试要点五 可靠性测试对系统进行误操作系统不崩溃或丢失数据 且有正确提示信息 系统测试要点七 性能测试系统登录时间 系统相应时间 大数据量运行的时间效率是符合设计要求 测试网站服务器能否承受相应并发 系统测试要点四 安全测试验证码验证链接是否可以多次使用是否有时间限制 无权限用户是否可查看未授权数据 用户未登录是否可以通过复制链接的方式进入系统 密码等重要信息是否加密显示 系统测试要点六 兼容性测试 缺陷管理 缺陷的定义缺陷的类型缺陷的状态缺陷处理流程Bugzilla管理工具介绍 软件没有达到产品说明书表明的功能 软件没有达到产品说明书中虽未指出但
7、应当达到的目标 软件与产品需求说明书不一致 软件功能超出需求说明书范围 软件测试人员认为软件难以理解 不易使用 或者最终用户认为该软件使用效果不好 缺陷的定义 缺陷的类型严重由程序引起的非正常退出 死机 数据库死锁或严重的数据通信错误 主要主要功能不符 逻辑错误 程序接口错误 一般简单输入控制错误 轻微数值计算错误 轻微界面错误 提示信息错误 建议 缺陷的状态缺陷状态未解决 已分配 resolved 已解决 重新打开 关闭resolved 已解决 对应决策状态 未修复 已修复 暂时不改 问题重复 无法重现 无效 缺陷处理流程 缺陷处理流程图 Bugzilla管理工具介绍 Bugzilla管理工
8、具介绍 Bugzilla管理工具介绍 外包管理 外包方提供产品及相关文档单体测试报告 详细测试用例和BUG列表 测试组验收验收产品 提交测试报告 我方提供产品控制标准需求分析说明书 概要设计 详细设计等书面文档 公司软件测试流程现状 需求文档缺失 对一些项目没有对需求进行文档化 没有比较详细的需求规格说明书 需求变更只是项目经理口头转述没有文档可查 产品没有版本概念 频繁修改造成了产品的不稳定性 对测试用例和缺陷管理不规范 开发要求不规范 通常未经过单元测试直接交付测试人员进行测试 如何突破现状 需求文档规范化需求变更及时反映到需求规格说明书中 本次变更处标红加粗显示并存档备案 测试环境和正式
9、环境分开 开发人员在本地修改完bug后首先提交至测试环境由测试人员在测试环境中测试 测试环境测试通过后方可发布至正式环境 测试用例规范化 统一使用测试用例管理工具或测试用例模板编写 缺陷管理统一使用缺陷管理工具进行管理 或统一模板进行提交 开发人员完成编码后参考 通用用例 进行单元测试 通用用例只是对常见检查点的总结 可根据项目中各项需求不同进行扩展 完成单元测试后再交付测试组进行集成测试 建议增加一台SVN服务器 设置文档统一存放地址 方便日后查看和统计 软件测试经验分享 所有的测试都应追溯到需求 因为最严重的错误是导致程序无法满足需求的错误 软件开发人员和管理人员首先应该尽早的和不断的进行
10、各种软件质量保证活动 如需求和设计阶段的评审和走查等 在进行各种分析和修复工作中 要充分主意修复工作所产生的影响效果和波及效果 统计表明大约有60 的错误是在设计阶段之前注入的 并且修正一个错误所需的费用随着软件生存期的进展而上升 错误发现的越晚 修复它的费用就越高 而且呈指数增长的趋势 一般情况下 我们在系统分析 系统设计 系统实现阶段的复审和测试工作能够发现和避免80 的缺陷 而此后的系统测试能够帮助我们找出剩余缺陷的80 最后的5 的缺陷可能只有在系统交付使用后用户经过大范围 长时间使用后才会暴露出来 因为软件测试只能保证尽可能多的发现软件缺陷 却无法保证能够发现所有的软件缺陷 对每一个测试结果做全面的检查 这样才有可能找到真正的出错原因 为今后的调试工作奠定基础 结束语 建立规范化的测试流程需要大家的支持 希望通过我们大家共同努力 能够帮助公司建立起一套较完善的测试流程 给公司产品带来更精准更专业的形象 Thankyou
