话一话【 "验收测试“】

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

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

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

 --【经过两个版本的迭代，参与验收心得】：

验收岗位，它不应和测试岗位独立

1.参与测试能帮助熟悉产品、了解细节和需求的变更，挖掘隐藏的验收点。

2.梳理验收checklist，用于测试阶段，测试组可过一遍checklist用例，并将执行结果反馈给我们。

3.评审验收checklist，使得验收目标和测试目标达成一致。

 

 

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

验收要很快理解需求，观全局梳理checklist（我经常是在web和app 两条产品线之间切换验收?）

 

--【测试用例和验收checklist，我们不一样?】：

测试用例尽可能的详细，比如查询功能点的细化，测试步骤描述清晰，预期结果怎样。
测试用例包含的要素：父模块、子模块、测试点、前提条件、测试步骤、预期结果等。

验收点：

        1.罗列变更清单 ，综合系统考虑影响哪些模块
        2.设计系统类的用例，一条用例尽可能多的覆盖影响模块；
        3.保证系统主流程、主干功能正常
        4.数据正确性的对比，异常情况的处理

 

 

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

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

 

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

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

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

 

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

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

 

 

 

 

 

 



转载于:https://www.cnblogs.com/ww-xiaowei/p/8992282.html