百人计划第五次分享有感。

"回顾，是为更好"

    每次分享说在开始的话，老徐不止一次的强调，自然有他的道理，想想每个人都懂。说来惭愧，我的回顾仅仅到第三次，由于上周瞎忙，导致第三和第四次分享没有及时参加、作业也未能按时完成，不过一定会赶上大家进度的…………

    百人计划第五次分享，老徐没有上场，原因是之前两次分享的内容技术含量较高，为了给大家留足够时间去消化吸收，这里必须竖起大拇指……这次分享主讲人是【阿辉】，分享主题是测试流程。

测试流程

需求分析

把需求转换为功能点

项目影响面分析

做好发布前的准备

做好线上测试

做好总结

努力学习新知识、拓展测试途径

需求分析，如何进行需求分析？

    了解需求、场景分析、竞品分析

    工作中总会碰到这些情况：（1）一大早接到通知，要参加需求评审会（2）紧急项目，已经在开发阶段，需要测试介入（3）紧急项目，已经开发完成，需要测试介入等。遇到这些情况时，每次都是一脸懵逼的参加会议或者紧急展开测试工作。这种情况下，总会导致很多诸如沟通不到位、测试覆盖不全面等的问题。

    正常情况下，产品经理会将需求文档放在公共位置，然后告知参与者某天要评审。此时，作为测试人员，第一点就需要提前对需求文档进行综合分析，对于不理解、不明确的地方进行批注。有了上一步的铺垫，在需求评审前，就已经了解到需求所要做的功能，评审时，便可对功能做进一步了解，同时可以对自己标注的内容进行针对性提问，评审时便可避免存在的风险。注意点：评审时，集中式提问，不要打断产品经理讲话，有问题先记录下来。

    第二点站在用户的角度考虑问题。首先明确此需求是为了满足哪些人群，二用户在什么情况下使用此功能/系统，三用户如何使用此功能/系统，四用户的使用频率，高频还是低频？五为什么这么做，这么做的优势。第五点是我们需要重点考虑的问题。

    工作中，经常会出现上面的情况，然后一脸懵逼的参加会议，这种时候感觉真是差极了。由于不了解需求背景、相关业务以及需求本身，导致真个会议都在了解阶段，然后提不出问题，会后又各种不理解、不明白，又要和产品经理进行沟通，有时候甚至出现需求某处不合理的情况，导致各方人员都要进行沟通，特别耗费时间，效率低。

    老师讲的这几点，真是受益匪浅。目前我的工作中，总是匆匆忙忙，然后又各方沟通，时间成本特别大，一方面是由于对本来业务不熟悉，另一方面是因为项目开始了，才收到通知……以后的工作中，一定要避免此类事情的发生，评审会议前便做好各种准备，养成好的习惯和思维。

需求转换为功能点

1.UI与数据进行分离

    无论app还是web，都要遵循数据和UI分离的原则。那么显示和数据如何进行分离呢？评审结束后，需求文档锁定，将UI和数据进行解耦，优先关注数据的产生和业务处理的正确性，之后关注UI对数据显示的正确性和体验。对于数据的正确性，可使用接口测试进行测试，然后再看显示的正确性。注意：数据分离不是适合所有的功能，是否适合取决于功能、UI对数据的封装程度。

    针对这一点，在日常工作中，也是有用到的。虽然没有专门做接口测试，但都会通过抓包，先查看接口返回的数据是否正常，然后再关注界面显示。针对提出的bug也是如此，会去分析究竟是数据问题还是显示问题，然后提给对应的开发。之前上家公司就不是这样的，可能和测试看不懂log有关，导致开发之间沟通成本加大，一个问题也总是丢来丢去的。我做测试一个多月中发现，这样做比较明确责任，效率较高。

2.功能点划分优先级

    数据创建和更新优先于数据查询；数据查询优先于数据显示。业务逻辑判断也应划分优先级，如一个商城，订单和账务优先级一定是最高的。

    在实际写测试用例的过程中，也总是强调优先级，就拿用例来说，优先级高的开发都要进行自测，自测没问题才可以提测给测试人员。由于自己做测试没多久，总会存在优先级分不清楚的情况，便会导致到处都是重点，然后无从下手。这次通过老师的讲解，似乎明白了如何划分优先级，在之后的实践中多多锻炼。

3.黑盒法拆解功能点

    黑盒测试方法为功能测试常用方法。将测试系统看成黑盒子，分析输入输出，然后根据输入划分功能点，分类可以是枚举也可以是一类输出划分为一类。

    功能输入类型：用户数据的输入（如表单）；系统提供数据（如股票实时交易过程中的价格和成交记录等）；时间变量（如不同时间下数据的不同状态等）；某些功能可以运行的前提条件（某些功能的存在要依赖于其他功能的输入，写用例时候的前提条件，如客服系统，进行聊天时，首先要建立会话，建立会话就是一个前提条件）。

    目前工作都是功能测试，都用的黑盒测试法，实际写用例中也是会考虑各种输入及其前提条件，写用力也是严格按照规范进行书写（自从被批评后）。只是不会总结的如此精确，这次分享真是一目了然，明白了自己日常工作中的做法以及方法。

4.自顶向下拆解功能

    数据和UI进行分离后，就要对数据和UI进行划分，一般使用xmind进行思维发散。

    由点到面，由全局到局部的方法便是自顶向下。

5.停止拆分的条件

    用xmind进行细分，细分到一个功能点本身不在是一种功能或者一个业务不可再分的时候，可以停止细分

    由于刚做测试没多久，对于很多工具都不熟悉，做测试一个多月中，表示还没有用过xmind，也是由于每次需求都很急，自己又没有用过，然后久而久之就没有用了，此处应该反思……后续开始学习使用。但是每次也是用了从全局到局部的方法进行拆分，将大的功能拆分成一个个小的功能点，然后书写测试用例。

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

7.手工的接口测试

    从开发那边获取接口、接口的文档，或者操作中去抓包。

    不得不说，由于目前工作没有专门做接口测试，用的最多的就是抓包，然后查看数据的正确性。

8.COOKIE验证测试

    牵扯到登录的一定要做。

功能测试之外

1.兼容性测试：web（浏览器、分辨率等，IE6-IE11都要兼容，较坑）app（安卓、IOS不同版本等）PC（不同版本，不同PC端等）

2.安装卸载测试

3.安全性测试

4.性能测试：并发、负载、稳定性、压力等

5.故障恢复测试：系统碰到故障，自动恢复的测试

项目的影响面分析

    主要测试对系统造成影响的改造；自动化回归测试

    项目对系统有哪些影响，利用自己对系统的了解程度以及自己本身的系统知识，在需求分析的时候，明确确定哪些是需要进行回归的，圈定范围后，去和开发沟通，可以了解哪些模块会受到影响，再结合自己分析做出判断：（1）受影响的功能，一般都需要拉出之前的用例（包括通用用例和个性化用例）进行重新测试；（2）可能受到影响的，拉出一些优先级高的用例进行回归；（3）一定不会受到影响，交给验收进行测试。

    工作中，在方案评审的时候，公司严格要求开发将相关接口列举出来（这一点值得赞扬），顺便在评审会上进行讲解，其他人员进行补充。故在写测试用例的时候，便会考虑到相关接口的测试，会将之前的测试用例拉出来，测试的时候也都会进行测试。

做好发布前的准备

    数据化初始化脚本是否ok？配置的脚本是否ok？发布流程是否ok？发布人、生产环境回归的测试人员是否ok？发布失败的情况下，应急预案是怎么样的？

    由于现在公司流程不是那么健全，故还没有这么多的准备，经常是严重问题解决完，各方评估后可以上线，便进行上线了。由于每次上线各方人员（开发、测试、产品）都在，一旦发现上线失败，便会查明原因，重新上线。

做好线上测试

1.有限条件下，在线上回归测试环境发现的bug

2.回归系统主要业务流程

3.做好探索性测试

4.定期定时对线上功能进行回溯

    针对线上测试，1、2点都毋庸置疑，做的很好，但对于第3点，工作中基本没做过，缘由是自己不怎么理解探索性测试，也没有去了解过，这里需要反思……第4点，目前是需求上线后两周都会进行跟踪，但再到后面就不会去跟踪了，这里也存在不足，需要改进……

做好总结

    很多bug因为开发不断重复同一个错误导致，为了避免此类事情的发生，测试人员要维护bug库，系统的分析bug产生的原因，并且将原因分门别类的统计出来，形成文档，在测试和开发间共享，督促其不再发生同样的错误

    针对bug的总结，表示目前很欠缺，没有做过……基本每次都是和那么几个开发对接，对于他们的习惯都比较清楚，对于负责的模块也较清楚，故很多时候有些问题，看到后便知道是什么情况，但由于没有总结过，所以每次都要告知开发，也是比较麻烦……公司虽然没有要求，但之后自己应该做好总结。

努力学习新知识、拓展测试途径

    阿辉分享完之后，整体看了下分享的内容，觉得对于我这个初涉测试的人来说作用很大，在很多方面给了我指引和方法，有很多值得学习的地方。

    针对不懂得地方，也在组里进行了讨论，忽然间感觉这种学习方式挺好的，虽然不是实际存在的团队，但是也会每天互相监督，互相学习，共同成长，忽然明白了老徐的初衷……感谢组里回答我疑问的小伙伴，真的学到好多之前没有接触到的知识。

    虽然每天没有太多的时间学习，但是每天坚持学一点点，久而久之也就很多了……由于之前四次的分享，实际只参加了两次，还有两次的课程没有赶上，之前感觉总是在完成任务，到这次，第五次，我才真正感觉到这样的好处，感受到组长的用心良苦，我想我找到正确的姿势了，原谅这个迟到的正确的姿势…………

    补充：附上昨晚讨论相关，愿对大家也有帮助：

    1.关于时间变量

2.关于历史遗留问题

    案底留存，很是赞同，以为之前就出现过口头达成一致后，开发忘记此事，进而导致后来各种甩锅的情形……