##前言
培训目标:让新员工在进行测试用例和执行测试前,充分做好前期的准备工作
培训对象:刚入职的新同学
##一、QA的职责和测前工作
在测试工作伊始,QA应该搞清楚软件测试工作的目的是什么!!
新人:“==*发现我们产品里面的所有BUG*==”
个人见解:“**==`保证项目质量`==**”,不仅仅是功能、还要考虑性能、安全、稳定性等方面可能会引起的潜在质量问题。
##1.1 测试前期准备工作
即便面对的是一个很小的项目,测试需要考虑的问题也是方方面面的,包括架构设计、操作
系统、环境部署&配置、了解项目需求及业务流程、用户的并发容量等等。
作为一名QA小白,如何才能发现尽可能快的了解业务,尽可能多的发现缺陷呢?
###1.1.1 向有经验的QA学习
百度外卖是一家运作比较规范的互联网公司,有独立的QA部门、规范的项目测试流程、测试技术有一定的积累,那么,当你入职时将会安排一枚经验丰富的同学作为你工作上的业务导师,为你讲解相关测试技术、项目测试流程、产品业务相关的文档目录,在导师的指导下逐步熟悉测试的相关工作。其实,在很多运作规范的互联网公司,已经把上述的师父带徒弟的方式固化到了流程中。
###1.1.2 走读缺陷问题
一般来说,Bug中最关键的几个部分包括:
* 第一部分是发现缺陷的环境,前提条件等;
* 第二部分是缺陷的基本描述;
* 第三部分是开发人员对缺陷的解决方法。
通过对上述缺陷的三个部分作仔细分析,不知不觉你已经吸收了其他QA的工作经验,并掌握了软件产品常见的基本问题,这是迅速提高测试经验的好方法。
###1.1.3 走读相关产品的历史测试用例
走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。通过走读测试用例,你可以掌握应该从哪些功能点着手未来的测试工作;你可以了解如何根据被测试的功能点开展测试用例的设计工作,包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。
总之,走读其他软件QA设计的优秀测试用例,是提高自身用例设计水平的好方法。
###1.1.4 学习产品相关的业务知识
软件QA不仅要掌握软件测试技术相关知识,对产品相关的业务知识也要学习。这很好理解,如果从事财务软件的测试工作,一定要学习财务知识;如果从事通讯产品测试工作,那么相关的通讯理论知识也是必须的;如果从事银行软件的测试,银行的业务流程也是不可或缺的知识点。因此,在学习软件测试技术的同时,千万不要忽略产品相关业务知识的学习。
###1.1.5 识别测试需求
识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档,那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出,来设计测试用例。如果开发人员没有提供软件需求文档,下面给出几个有效的方法:
** 1.主动获取需求 **
开发人员通常不会更好地考虑QA,因此,需要QA与相关的RD保持沟通,了解实现的主要功能是什么,并记录得收集到的信息。一般来说,开发人员即便没有提供相关需求文档,也会保存一些简单的过程文档,主动向开发人员索要这些文档,可以作为测试的参考。
** 2.加入开发小组的邮件群组 **
QA需要通晓被测试项目,但是,项目在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程,QA会对产品的变更了如指掌。通常,QA应该加入到相关的需求HI群组中。当开发人员通过hi讨论问题、通知召开技术会议的时候,QA可以及时知晓。
###1.1.6、善于发声和沟通
1、 需求评审时,多发表自己对需求、对产品的看法;
2、 用例评审时,一定要思路清晰,有条不紊的评审用例,因为测试用例的评审是以我们为主导的;
3、 测试过程中与开发确认问题时,需要积极沟通,协助开发定位问题;
4、 与开发沟通时,尽量从这个问题对用户的影响程度方面来说,这样更具有说服力。
##1.2 测试前期准备工作bad case
###1.2.1、测前沟通不充分
重要节点时间没有沟通确认,导致测试计划安排不当,加班测试or项目delay
###1.2.2、联调有缺陷
###1.2.3、评审不到位
###1.2.4、心态不正确
比如测试计划、测试方案、测试用例,能提前的,尽量提前做出来,否则到了测试执行阶段,就会手忙脚乱,觉得:啊,我用例还没写,但开发已提交测试了,怎么办?先测吧,后面再来补用例。一般这种情况下,当时想的需要补充的用例,基本上都没有补,
##二、敏捷项目流程
###2.1 百度外卖 - 基于工作衔接的项目流程图

###2.2百度外卖-研发流程及角色分工

##三、工作经验和心路历程
###第一阶段 学习+验证
对于新来的同学,需要投入较多时间了解业务需求和测试套路,往往踏不下心来。感觉业务测试是件没完没了地事情,并且单调重复、枯燥乏味,没有激情、没有成就感。这是很正常的现象,刚进入一个新的岗位,总有一个适应过程。
在这一阶段,新人需要做的事情是,先了解所测项目,熟悉他的每一个功能,弄清楚每一个功能的正确效果应该是什么?然后才开始尝试着去找一些肤浅的问题。这一阶段的感觉是:"测试实际上就是验证产品每个功能的有效性"。这一阶段虽然不太出成绩,但却很重要,因为这是以后工作的基础。
###第二阶段 与开发对立的误区
当熟悉了所测产品的功能,并且找到测试的套路后,就开始较深入地测试了。在这一阶段,新人会逐渐发现一些严重的BUG。这是他进入状态的必然过程。此时,我们可能会对测试产生了更进一步的认识:"测试,就是要找出产品的缺陷,是证明当前产品不可用的一种行为"。
###第三阶段 与开发主动配合
随着测试经验的积累,对工作的认识也逐步深入。我们会发现,RD和QA之间,本质上是一个合作的过程,目标本是一致的。都是为了尽量减少发布产品中的错误,达到用户可接受的程度。
###第四阶段 责任感+验证
当经历了产品的几个生命周期之后,从不断的“需求、开发、测试、发版/上线”循环过程中逐渐认识到,测试实际上是降低产品风险的一种行为。逐步认识到,QA介入的环节越早,风险也就越小。