测试技术—项目团队自动化

发表于:2014-4-18 11:19

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:郝强    来源:51Testing软件测试网原创

分享:
  1.  似曾相识的项目
  做了多年的软件开发软件测试项目,发现貌似大多数项目过程都是极其曲折,而且多数失败的项目极其类似,虽然实践过多种软件项目管理的方法学,但貌似大家都被工期,成本以及人员的能力限制着,除了疯狂的加班,以及救火队员式的服务着我们的项目,最终历经九九八十一难后项目上线了,大家也觉得可以松口气了,但发现上线后要保证线上应用稳定,也不是一件容易的事,貌似这事就没有尽头了。
  我在之前的项目中就曾遇到过许许多多的问题,现简单列举一下:
  1.版本控制混乱,尤其是多个产品线共同存在时,特别是多分支的版本库。
  2.测试人员可支配的测试时间极少,人员也严重不足,一个项目基本就一两个人,多数的时候上线前只有不到一天的测试时间。
  3.手工多环境部署,重复劳动多,经常出现少配置这项参数,或那项参数的问题。
  4.大家都苦不堪言,团队凝聚力差,核心人员渐渐流失。
  上述我只列举了几个比较重要且是核心问题,具体细节上的问题更多,再这就不在一一列举。对于上述问题,我一直也在项目中思索如何解决这问题。
  2.  理想与现实离的不远
  2.1 一个成功的项目状态
  某年某月的某一天,在某个项目中,经过大家共同的努力, 那些似曾相识的糟糕的状态已经一去不复返,同时大家还积累一些方法与实践,通过努力,项目达到了如下的状态:
  1.版本控制有序。
  2.测试方面有了有效的自动化测试,手工人员可以关注在更重要的测试任务里。
  3.部署团队实现一键部署,多个环境共同一套部署脚本。
  4.任一环境出现失败,均有邮件告警。
  5.收到告警邮件时,有人立马响应并解决问题,形成了交付的生态圈。
  6.整个开发,测试,部署,运维是相辅相成并且做为整体的自动化呈现的。
  7.貌似即使有加班,大家也感觉很兴奋。
    ......
   查看全文请点击下载:http://www.51testing.com/html/15/n-860515.html
  2.4  测试过程
  对于测试过程自动化的考虑,我们首先要求项目团队在开发过程即要考虑系统的可测试性,要保证尽可能高的单元测试覆盖率,尤其是敏捷项目实行的测试驱动开发。另外,对于CS结构的应用来讲,尽可能使用标准控件,以减少后期实现自动化测试时对非标准控制要做过多编程或处理。对于BS结构应用来讲,在没有特殊要求的情况,尽可能不使用浏览器插件。
  在项目初始阶段,测试经理需要与项目经理沟通,要把握和实施好质量内嵌原则。其原则要从多个层次(即单元测试、组件测试和验收测试)上写自动化测试,并将其作为部署流水线的一部分来执行。每次应用程序的代码、配置或环境以及运行时所需软件发生变化时,都要执行一次该测试。同时手工测试也是质量内嵌的关键组成部分。当然质量内嵌还意味着,你需要不断地改进你的自动化测试策略。
  实施自动化测试,要先尽可能的先自动化接口部分。因为这部分功能的自动化测试更容易实现。针对于每次构建过程,有构建被触发时,要能够触发自动化冒烟测试,这部分也是需要你优先考虑自动化的部分。因为你要验证每次发布是否有效,如果有效才能执行更大量的测试。针对于UI及回归测试的自动化实现,是放在最后考虑的,因为这部分很可能是变动最频繁和需要花人力去经常维护的。当然,创建回归测试套件的价值在于保证系统当前的功能正确,将这部分自动化放在最后考虑不是说其不重要,实际上它是同等重要的,只是优先级较低。
    ......
   查看全文请点击下载:http://www.51testing.com/html/15/n-860515.html
  
  版权声明:51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号