标签：研发 获取 经验 异常 了解 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
