您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 质量管理 > 正文

软件测试中保障版本的测试质量的方法

发表于:2017-01-09 作者:网络转载 来源:

  我们定位这样一个角色:你是一名功能测试人员,在项目组负责某个子系统(或者说后台服务)的一个版本测试,该版本新增了功能,又修改了原有bug。没有规范的文档,你将如何测试?
  有人是如此测试的:咨询一下开发修改了哪些功能,拿到手上开始根据开发提供的思路跑流程,测试通过,上生产。结果生产上造成很严重的问题,而这个问题产生的根源是开发改动了关联部分公共方法。同时作为测试,根本没有考虑到该版本的功能关联了哪些业务场景,所以也无法发现该问题。项目经理问责测试:作为对该系统测试了两年多的你,为何这么简单的问题都发现不了?测试用例写得这么粗糙。
  这是我眼前的真实存在的一幕。我无法端坐在旁边,看着可怜的测试人员在无力解释,“我也发现了很多问题,你怎么就看不到?”“我们联调协调的很辛苦……”。我很想知道问题在何处?
  思考良久,我知道某个人肯定有问题,但又不全是某一个人的问题。需求没有文档,开发没有设计思路,测试设计缺失,遗漏该功能的测试,最终问题在生产上“华丽丽”地暴露出来。姑且不论需求和开发的问题,我认为测试可以往前多走几步。
  第一,  一定要进行测试设计,站在用户的角度,进行测试设计。时间紧张时设计的粒度可以只到测试场景,预期结果中包括检查的点。有充分的时间还是建议编写规范的测试用例,描述清楚前提条件、操作步、预期结果、优先级等。
  测试场景必须覆盖所有改动的功能点,而且一定要进行全流程测试。保证该功能的修改不会影响整条流程。
  第二,  一定要进行回归测试,这里的回归测试视情况而定,时间足够全量测试,时间不够,一定要对系统核心功能进行回归测试。例如金融行业的交易,回归测试场景必须包括的各类正常场景和重要的异常场景,保证版本上线以后,用户还能继续使用这些核心功能。回归测试需要对系统深入理解,判断用户核心业务场景。
  第三,  版本如何极大低影响性能,需加入负载压力测试、稳定性测试、大数据量测试。
  第四,  沟通,沟通,再沟通。把测试的场景全部列出来,给需求和开发过目,请他们协助判断一下是否有漏测,或者理解有误的地方。对于这种没有文档的项目,系统设计全部留在大家的脑海中,每个人理解可能都不完全一样,通过测试用例去统一大家的思路,保证我们测试的有效性。
  第五,  如果明知道该版本对功能影响范围较大,而市场或者项目经理又催得很紧,一定要告诉他们风险非常大,具体表现在哪些方面。这样他们经过仔细斟酌,如果得不偿失是绝对会支持你的,如果他们能够承担风险,就会考虑上线。
  经过以上这几个步骤,在这种无文档的“敏捷”项目中,测试作为最后一道关卡,一定能够发挥你的价值,成为项目组必不可少的一环。那时的你是不会出现在我开始提到的被问责的场景中的。