码迷,mamicode.com
首页 > 其他好文 > 详细

话一话 "验收测试“

时间:2018-05-04 20:17:50      阅读:141      评论:0      收藏:0      [点我收藏+]

标签:研发   获取   经验   异常   了解   klist   地方   条件   同事   

2018年03--12投奔了现在的东家,做验收测试,忙于工作,疏于总结,今天梳理一下吧:

----------先说说刚入职的状态:

工作融入的一个过程:
1.熟悉系统:基于系统第1、2期的原因,目前缺少系统的流程图、概要设计和详细设计文档、数据库设计文档;
  但测试相关的资料比较多,用例比较清晰;
2.对团队的融入:基于验收这样一个岗位,和研发团队打交道没那么频繁,需要在工作外多和同事们交流,7成以上是小年轻,也要一些适应,需要更多的了解他们、熟悉他们。

 ----------经过两个版本的迭代,参与验收:

心得:
验收岗位,对这个岗位,它不应和测试岗位独立:

1.参与测试能帮助熟悉产品、挖掘隐藏的验收点。

2.参与测试阶段的工作,将更多问题在测试阶段暴露出来。

因此后期可以把验收流程梳理出来,总结经验,让验收更透明,可替代。

 

验收测试:它所做的是跳出测试工程师角色,以客户使用和体验去感知产品问题:1.保证功能 2.保证友好交互,保证产品上线。

验收要很快理解需求,观全局梳理checklist。

测试用例和验收checklist梳理,有区别的:
测试用例尽可能的覆盖场景,所以要依此罗列测试点,操作步骤,而不只是一句话(需求描述)
测试用例包含的要素:父模块、子模块、前提条件、测试点、测试步骤、预期结果

验收点:1.罗列需求
        2.综合系统考虑影响哪些模块,设计系统类的用例,尽可能的覆盖影响模块;
        3.考虑异常情况
        4.保证系统主流程、主干功能正常。

 

 

 ----------在测试阶段方面

测试人员,怎么样换位思考,更好的做到测试全面,不因测试量大、重复多走失方向呢?
1、个人考虑不全面--集 团队的力量---测试方案评审;
2、交叉测试;
3、有足够的测试时间。

 

 ----------做事方法

做事情前,明确目标--->确认怎么做,再动手:

获取需求---编写用例---用例审核---准备数据---执行用例
回归时,要先确认修改了哪些地方,看测试方案是否有遗漏

 

 ----------目前研发、测试流程的梳理

需求评审----->编写测试用例(梳理冒烟用例----->用例评审----->研发不定期过一下开发进度----->转测试前,开发将冒烟用例的执行结果反馈给测试组----->执行测试(分几轮测试,记录执行过程)----->转验收测试----->上线版本----->简单冒烟测试。

 

 

 

 

 

 

话一话 "验收测试“

标签:研发   获取   经验   异常   了解   klist   地方   条件   同事   

原文地址:https://www.cnblogs.com/ww-xiaowei/p/8992282.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!