测试流程分享整理及需借鉴之处

整个测试流程如下：

一、 需求分析

1、 在需求分析前，了解需求，知道我们要做什么功能，在评审时，对有疑问的地方进行针对性提问；

优点：在评审时，进行集中式的提问，而不是打断产品经理的话。评审时，大家很容易产生意见，所以都喜欢插话，打断产品经理的话，这不是一个好习惯，可能会使产品的思路产生中断，评审会议的时间比预期要长。

开评审会议时，建议大家拿笔记录有疑问的地方，集中时间提问，好记性不如烂笔头。

这点，我们公司产品做的比较好，讲完一部分内容，会预留时间给大家答疑解惑。

2、 站在用户角度考虑问题

这个需求是为了满足哪些人的？站在用户的角度我们可以知道几个事情：

a，需求的制定是为了满足哪些人的；

b，用户在什么情况下才会使用这个系统或功能；

c，用户如何去使用我们的系统或功能；

d，用户的使用频率是怎么样的，是高频还是低频；

e，比较关键的一点是，为什么这么做，这么做的优势在哪里？

需求是满足产品经理以为的用户的一个行为习惯或者理念。一个好的产品经理会把一个产品做的非常优秀。

二、 把需求转化为功能点

其实一个很重要的因素是：把显示和数据分离。

现在系统不论APP或是web端都遵循数据和UI分离的原则，作为测试人员，我们也应该有这种思想。

UI和数据分离怎么做呢？

1、 首先，需求评审之后，需求文档锁定了，我们就可以试着将UI与数据进行解耦。优先关注数据的产生与业务处理的正确性，最后再关注UI对数据显示的正确因，还有包括体验。

举例：轮播条，前台通过ajxs请求然后在网页加载轮播条数据，并用js生成一些轮播条。先是数据的正确性，可以利用接口测试进行校验，然后再看显示的准确性。

这种数据与UI的分离不适合所有的产品，至于数据分离合不合适，需要看功能UI对数据的封装程度。

举例：就一般的轮播条而言，如果接口返回一个js数据，但UI却将其分门别类去封装，去展示，变成一个无序的滚动显示，这就与原生的数据会有很大差别，这个时候就很适合前后端的数据分离。

==》显示和数据分离有什么优点？这样做有什么突出的好处？

就刚才的例子，打乱的信息要在前端滚动显示，如何测试？首先可以通过接口测试来检验接口传递的内容是否正确，这样可以保证服务端业务处理是正确的，然后再去测试前端的展示，这样测试得更详细。

2、 给功能点划分优先级

划分原则有：

a， 数据的创建和更新优先于数据查询；

b， 数据的查询优先于数据显示；

PS：业务逻辑判断也有优先级，也要做；

3、 黑盒拆解功能点

我们在做功能测试的时候，应用最多的是黑盒测试法，我们把整个个测试系统当做一个黑盒子，分析它的输入输出，然后再根据输入的分类，再来划分功能点，这种分类可以称为枚举，也可以是一些输出，也归为一类。

功能输入有哪些类型？

a， 用户数据的输入，比如表单；

b， 系统提供的数据，比如像股票实时交易过程中的价格以及成交记录等；

c， 时间变量，有时候虽然系统和用户没有提到，但是这个时间确实存在，而且也不能忽略；

d， 某些功能可以运行的前提条件，有时候有些功能存在的意义必须依赖于其它的输入，但是这个输入并不属于该功能的输入，这个是我们写用例的前提条件，比如说客服系统，我们都用过，客服聊天的时候，我们必须首先建立会话，才能进行聊天，那么这个建立会话就是前提条件。

4、 自顶向下拆解功能

这个要求根据具体的业务情况，比如说一个商城，第一个是订单，第二个是账务这块，那么订单和账务的优先级肯定是最高的。

数据和UI分离以后，我们要对数据和UI的功能进行划分，一般用Xmind进行思维发散。

5、 停止细分的条件

用Xmind进行细分，细分到一个功能点它本身不在是一种功能的时候，或者是划分到一个业务不可再分的时候，这时就可以停止细分了。

6、 强健壮性测试和弱健壮性测试

7、 手工接口测试

从开发那边获取接口文档，或者使用抓包工具来抓取接口

8、 cookie验证测试

一定要做，主要涉及到登录之类的功能

三、 功能测试之外

1、 兼容性测试

网页端：浏览器兼容、分辨率兼容；IE是个坑，要求高的从IE6到IE11都要兼容；

APP客户端：iOS、Android，不同版本，不同机型都要考虑到；

PC客户端：不同的版本，不同的操作系统；

2、 安装卸载测试

3、 安全性测试

4、 性能测试（并发、负载、压力）

5、 系统的故障恢复测试（系统遇到故障还可以自动恢复的测试）

四、 对项目的影响面进行分析

运用自己对系统的了解程度，和自己本身具备的系统知识，在需求分析的时候，确定哪些需要回归，确定了范围之后，找开发沟通，进一步确定哪些系统或哪些模块会受到影响，再结合自己的分析，做出判断，重新进行回归测试。

一般来说，受影响的功能，都需要用之前所说的通用的测试用例，再加上个性化的用例，进行重新测试；可能受到影响的功能，需要把优先级最高的用例拿出来进行回归测试，一定不会受到影响的，就交给验收测试进行。

五、 做好发布前的准备

1、 数据的初始化脚本是否ok

2、 配置脚本是否ok

3、 发布流程是否ok

4、 发布人员以及生产环节回归测试人员是否就位

5、 应急预案的准备：如果发布失败，如何处理？

六、 做好线上测试

1、 要做生产环境回归所有在测试环境发现过的bug；

2、 回归系统主要的业务流程；

3、 做好探索性测试；

4、 定期定时对线上功能进行回归；

七、 做好总结

很多bug都是开发不断重复同一类错误导致的，为了避免此类情况，测试人员应该维护bug库，系统分析产生bug的原因，并把原因分门别类的统计出来，形成一个文档，并且把这份文档共享给测试人员和开发人员，可以督促开发人员不再犯同样的错误，不再产生同样的bug。

八、 努力学习新的知识，拓宽自己的测试途径

听完此次分享，可借鉴之处：

1、 需求评审之前，让产品经理提前把需求文档发给大家，在评审会议之前预留一定的时间给开发和测试熟悉。

在熟悉需求的情况下参加评审，对需求的理解更加深入，可以发现更深层次的疑问点。

目前产品发送需求文档后，马上开评审会，会上只是产品讲下要做哪些新功能，一般需求评审总时长不超过半个小时，短暂的时间，不一定能发现一些隐藏问题。评审的意义并没实现最大化。

2、 需求评审时，拿笔记录不清楚或有歧义的地方，这点做的不好，因为评审会对我而言是了解需求的过程，基本上提不出什么问题。需求的深入理解，都是在需求拆解成功能点时完成的，这白白浪费了一起探讨交流的机会。

3、 竞品分析这块也基本没做什么功课，目前的测试人手很紧张，每个人的工作任务都很重，每周版本迭代，经常加班变成常事，都没时间去做这个事。都说一个好的测试，也会是一个好的产品经理，后面这块进行改进，多体验竞品，给我们的产品提出更好的改进建议。

4、 学习了如何把需求转化为功能点的具体方法。有些目前工作中想过，但是没去引入。比如功能划分优先级、cookie验证测试、手工接口测试和健壮性测试。

5、 功能以外的测试，比如安全性测试，性能测试，故障恢复测试，这些目前都是开发在做，我们暂时没做，这个也是需要思考的方面。

6、 努力学习新知识，拓宽测试途径，这个目前的百人学习也是为了实现这个目标，其他方面，多关注知乎测试类文章、云测平台等