A股上市公司传智教育(股票代码 003032)旗下技术交流社区北京昌平校区

 找回密码
 加入黑马

QQ登录

只需一步,快速开始

本帖最后由 huawei 于 2018-10-12 17:00 编辑

小白必看:测试人有必要参考的软件测试工作规范

       为了规范测试工作、减少开发与测试之前的沟通成本、保证项目进度、提高软件质量,测试人员有必要参考这份软件测试工作规范。

1.1. 编码规范
  软件程序开发需要遵守编码规范,一是可以减少代码的维护成本,提高开发工作效率;二是有利于开发工作的延续、传承,减小项目风险。
  1.1.1. 合理的注释量
  好的代码应该是自描述的,让人费解的地方加上注释。
  1.1.2. 规范的命名格式
  规范很多,要让别人和一个月的自己看得懂。

1.2. 测试与测试结果
  1.2.1. 单元测试与报告
  单元测试一定要做。深入理解“ test driven development”思想,有条件的话,先写测试代码,后写开发代码。综合使用各种覆盖方法,例如:路径、函数、条件、语句,Code Coverage确保高于80%。
  统一提供单元测试报告。
  1.2.2. 集成测试与报告
  集成测试也一定要做。测试工作要覆盖所有模块和接口。
  统一提供集成测试报告。
  1.2.3. 系统测试
  单元和集成通过后,项目提测并进入系统测试阶段。
  系统测试范围依据项目不同可分为功能和非功能测试。
  1.2.3.1. 模式
  依照Alpha1-到Alpha1n的模式。
  提测版本1冒烟测试通过后即进入第一轮测试(记做Alpha1),执行全用例。测试和开发,不断提交和修复BUG,直至用例执行完成;
  开发修复完所有缺陷,打包发布版本2;
  提测版本2冒烟测试通过后即进入第二轮测试(记做Alpha2),验证缺陷,执行部分用例。测试和开发,不断提交和修复BUG,直至用例执行完成;
  开发修复完所有缺陷,打包发布版本3;
  提测版本3冒烟测试通过后即进入第三轮测试(记做Alpha3),验证缺陷,执行部分用例。测试和开发,不断提交和修复BUG,直至用例执行完成;
  ……
  如此,循环往复,直至缺陷收敛,达到测试退出标准,系统测试完成。
  出具系统测试报告。
  1.2.3.2. 进入标准
  1) 需求说明书规定的功能均已实现;
  2) 主要流程可以走通。
  3) 界面上的功能均已实现,符合设计文档规定的功能。
  1.2.3.3. 暂停标准
  1) 一级错误数大于1、二级错误数大于2;
  2) 软件项目需暂停以进行调整时。
  1.2.3.4. 退出标准
  1) 按照测试计划完成了系统测试;
  2) 达到了测试计划中关于系统测试所规定的覆盖率要求;
  3) 在系统测试中发现的错误已经得到修改,各缺陷修复率达到要求。

1.3. 工作流程
  1.3.1. 需求与变更
  1.3.1.1. 需求定义

  需求确定后以文档和原型方式提供给测试方。应包含术语解释,功能描述,精确的数据限制等等。
  对开发和测试人员开展统一培训。
  1.3.1.2. 基线
  《产品需求文档》确认、稳定后,应建立基线,它是进一步开发、测试的基础。当基线形成后,项目负责软件配置管理的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本。这个过程可被认为内部的发布。至于对外的正式发布,更是应当从基线了的版本中发布。
  1.3.1.3. 变更管理
  软件工程过程中变更无法避免,这种变更必须严格加以控制和管理,保持修改信息,并把精确、清晰的信息传递到软件工程过程的下一步骤。软件变更管理包括建立控制点和建立报告与审查制度。
  变更管理的主要任务包括:
  1、 分析变更的必要性和合理性,确定是否实施变更;
  2、 记录变更信息,填写变更控制单;
  3、 修改相应的软件配置项(基线),确立新的版本;
  4、 评审后发布新版本。
  1.3.2. 项目提测
  1.3.2.1. 提测时间
  项目提测时间应安排在开发完成,已通过单元和集成测试之后。开发人员有时间,应过一遍冒烟测试用例,以提高冒烟测试通过的成功率。
  1.3.2.2. 提测交付物
  《单元测试报告》
  《集成测试报告》
  《测试环境搭建部署手册》
  “部署程序包”
  “数据库初始化脚本”
  1.3.2.3. 版本控制
  1) 开发团队制定并遵循一定的软件系统版本命名格式,例如:
  “软件系统的版本号由3部分构成,即主版本号+次版本号+修改号。主版本号1位,只有当系统在结构和功能上有重大突破改进后才发生变化;次版本号有2位;修改号8位,采用提交时的日期,当系统进行任何修改后,包括数据库结构发生变化,修改号都要随之改变。例如:Ver3.31.19990317”;
  2) 各子系统的版本号独立;
  3)软件系统,产生新的版本后,老版本的软件系统是否继续保存,取决于以下条件:
  a、老版本的系统如果有客户还在使用,在客户升级以前,必须继续保存。
  b、老版本的系统已经没有客户使用了,并且新版本的系统已经把老系统的文档完整地升级过来,这样可以删除或覆盖老版本的系统资源。
  c、对于要删除或覆盖的老版本系统,可以统一备份起来。
  1.3.2.4. 提测间隔
  项目第一次提测后,后续提测应该安排在软件测试工作一轮完成后,并且已尽力修复完大部分缺陷之后。
  在系统测试期间严重杜绝一个版本只为了修复一个缺陷。
  1.3.2.5. 测试环境
  1.3.2.5.1. 环境分类
  为了保证工作质量、优化工作流程,软件环境最少应该有以下三套:
  开发环境:开发部门开发、调试、集成软件使用。
  系统测试环境:测试部门系统测试使用。
  生产环境:用户使用,运维部门管理。
  为了进一步提高用户体验、提高缺陷修复效率,根据条件也可以增设以下两套环境:
  Beta环境:系统测试通过后,Beta测试使用,运维部门管理。
  线上镜像环境:紧急复现、调试、解决线上问题。
  1.3.2.5.2. 环境管理
  分权
  生产环境对开发和测试只开放查询权限。(需要修改权限时需要经过一定的机制来控制记录,一般只在调试程序时开放修改权限);
  测试环境对开发只开放查询权限。(需要修改权限时要经过确认, 一般只在调试程序时开放修改权限);
  开发环境对测试人员只开放查询权限;
  以上三个环境,都由专人负责升级、维护。
  定期比对
  取生产环境数据库作为标准,对比测试环境。
  提取差异部分(表结构、过程、触发器等)进行分析。若差异部分不是计划内的升级版本所致,则应该删除。这样在下一个计划版本升版后,下下个计划版本没有在测试环境上升版前,测试环境和生产环境就实现了结构上的一致了。
  开发环境,同样与生产环境对比,差异部分先去除最近一次要发布生产的脚本影响,再将剩下的,在开发组内部沟通确认,将没有人负责的删除。这样,可得到相对统一的环境。
  由于开发环境,一般只有一个,所以在多个版本并行开发过程中,数据库管理是相对比较混乱的。在这种情况下,尽量保证测试环境与生产环境的数据库结构的统一。对保证发布质量有较大意义。
  1.3.2.6. 冒烟测试
  冒烟测试出现的场景有两个,一个是在内部提测时;一个是在生产环境上线时。
  冒烟测试通过验证主要功能是否已经实现,有利于粗略的验证提测物是否具有可测性、上线部署后的系统有无重大问题。
  1.3.3. 缺陷处理
  1.3.3.1. 修复时间
  缺陷处理应该有一定的时效性。
  优先级
  说明
  1-紧急
  必须在一个工作日内修复
  2-较高
  必须在三个工作日内修复
  3-一般
  必须在五个工作日内修复
  4-不急
  有时间再修复

1.4. 质量保证
  1.4.1. 评审
  1.4.1.1. 需求评审

  对于产品需求的评估可以分为三个维度:
  价值认同 - 对用户有没有价值,投入产出比怎样;
  需求质量 - 需求是否易于理解,细节有没有说清楚,逻辑是否成立;
  技术可行性 - 能不能做,成本多大规模,有多大风险。
  1.4.1.2. 设计方案评审
  由开发团队自行组织,从流程上,必须要进行的。
  1.4.1.3. 用例评审
  参与方:产品、测试、开发和项目负责人;
  目的:
  1) 减少测试人员执行阶段做无效工作;
  2) 避免三方的需求理解不一致;
  3) 每个测试人员的质量标准与项目要求标准达成一致。
  1.4.2. 交叉测试      1.交叉测试
  每一个测试人员有自己思维的局限性,一种思维测试过之后,软件会对这种测试思维产生抗性,很难再发现新的问题,通过交叉测试,可以把新的测试思维带进来,测试出未发现的bug。防止测试人员工作粗心导致漏测。
  2. 执行监督
  首先达成共识,在共同监督执行的基础上,并安排专人主持监督工作。
  3. 优化改进
  该文档罗列,定义了一系列的软件测试规范,主要目的还是为了保证项目进度、提高软件质量。在该方案执行的过程中,我们本着简洁、高效的原则,不断优化改进,以期拿出最适用药聚汇的软件测试工作规范。
  3.1. 测试演进
  3.2. 缺陷预防
  1) 需求阶段测试开始进入项目;
  2) 进行单元测试-代码静态分析;
  3) 持续集成-每日构建、自动反馈。

精华推荐:


0 个回复

您需要登录后才可以回帖 登录 | 加入黑马