时常会想自己为什么会选择测试，因为开发功底薄弱，而且测试的门槛较低，加上网络上对测试需求量大的宣传，也就选择了测试。假若自己选择开发，同样的付出，绝对是测试得到的回报更多些。也不曾想去争辩什么，觉得虽然测试地位确实比不了开发，但是自己努力了知足就好。

　　一年的经历，自己也从一个新手成长了很多，不得不说，作为测试很容易获得成就感，成长后就得总结或者思考，老大总是喜欢让我们写总结，每个版本，对于负责的特性进行总结输出文档，通过这样的方式，能对所学的业务进行梳理，但是对于自己所掌握的经验，却感觉有些虚无缥缈了，自己到底学到了么，以前总是喜欢说会XX业务，对XX流程更加熟悉了，现在觉得业务流程都是死的，但是测试思路貌似自己还没有形成雏形，苦思冥想也无法说出个啥，但是每次到新版本分析的时候，却总是能突然冒出其他想法，想对自己的所认知的流程进行梳理总结，希望能获得些什么。

　　分析需求时，以为FRS（原始需求），总体方案，单部件方案为素材，三者可以用继承的关系描述，总体方案是为了实现FRS，而对于目标如何实现，总体方案提供了一个大概思路，再进行单部件分解需求。先看原始需求，将主要功能点罗列，带着这些功能点去阅读总体方案，功能点是否覆盖，最后去阅读单部件方案。分析时候将疑惑的地方进行标注，汇总问题提交给下需求人员，当总体方案与FRS实现不一致处，需要将情况通过邮件方式陈述给一线的。在需求分解阶段，喜欢使用XMind工具，画出思维导图，将需要实现的功能，重点关注的流程都罗列出，这样在写总体方案的时候容易有一个参照，避免需求遗漏。

　　需求分解完毕，开始着手编写测试方案，测试方案的编写维度可以从角色入手，不同的角色会有不同的权限以及操作，比如管理员，权限较大，需要关注其操作是否会带来一些不可恢复的操作，比如类似rm -rf *的操作（残念，当年就干过一次啊，还好备份了），对于普通用户来说，权限的控制一块也是相当重要的。分析完不同角色的权限以及可以进行的操作，就可以考虑场景了，因为做的是解决方案的测试，所以和单部件测试区别还是很大的，只需要考虑端到端的场景。对于FRS上正常的场景必须要实现，对于一些其他场景可以采用交叉覆盖的方式进行验证，但是出现bug的地方，往往不会是基础的场景，这时候就得从总体流程入手，一种场景的流程，在其某个阶段，是否可以存在断层或者分支，人为操作是否可以介入干预，可以那此块就得考虑了。其实对于场景的考虑，也就是对各种影响因素的考虑。觉得最好的流程就是一气呵成，这样能减免很多误操作，但是很多时候，没办法，比如确认支付的场景，就得再三确认。对于场景的设计一块，必须需要关注是否对老功能造成影响，倘若新功能的实现影响了老功能，只能说是太失败了。

　　方案写完就是方案评审了，毕竟一个人的力量总是有限的，再者这也是对流程的再一次梳理的过程。其实对于自己分析的方案是最熟悉的，但是对于使用客户来说，他怎么能清楚这些，这时候就得靠组内成员帮忙看待功能实现了，觉得这是相当必要的过程。在讲解的过程中，自己也得不断的思考，是不是这样就全了，虽然不可能达到全场景覆盖，但是保证基础功能的前提上，尽量考虑多的且很容易触发的场景。比如赠送应用场景，

　　场景一、A赠送B，A购买

　　场景二、A购买后赠送B，

　　场景三、A赠送给A（一般人真心干不出......）

　　场景四、B购买后，A赠送

　　场景五、B被A赠送，后被C赠送

　　............（还有折扣场景）

　　其实用枚举的话，场景还是相当相当多的，但是这也很明显，对于一个场景的结束端，难道就真的这样结束了么，比如场景二，赠送给B了，还可以继续下去赠送给C或者D吧，虽然结果很明显，但是还得要测下的。

　　从后台流程的理解来看，用户本身有着自己的键值，产品也有，两者在交易列表中存储，形成关联关系，假若正常的购买流程purchasetype枚举值为1，就正常存储。若是赠送流程， purchasetype其枚举值是2，后台就根据枚举值进行判断，采取新的存储方式，将被赠送方与产品进行关联，赠送方存储在其他字段，之后拥有所有权的用户去使用，此时就会调用接口进行查询，有关联关系就直接使用，没有那就只好自己掏钱买了。这是理解流程的一种方式，觉得作为一名测试不仅仅需要明白测试结果是否正确，还得明白为何需要这样实现，当累计到一定的程度，就是对系统相当熟悉的时候，就可以开始去想是否有更好的实现方式没。

　　需求评审完后，得到了建议，需要修改的修改，需要确认的确认，之后就是设计用例了，其实评审完需求后，大致的用例也就出来了，照葫画瓢就出来了，在写测试用例的时候，决不能因为是自己测，所以用例写起来就很粗糙了，之前见过一个同事写的用例，根本没办法测，测试步骤和预期结果就一句话，当时就跪了。写用例的时候，最好当做是写给新手的，步骤一定要全，预期结果一定要给出确认结果，在写的时候还喜欢将名称标明确，比如产品A，会写成产品Gray，后续使用也会用产品Gray，测试用例也是体现测试人员功底之处，毕竟这也是展示的部分，最好的测试用例是即使是没看过需求的人也能正确执行。在写预期结果时，喜欢将重要信息或者检查点标明，比如后台的传参，决不能错，当然能将后台流程也描述一下也是不错的。虽然再全的用例也不能覆盖，毕竟不同测试小组，其任务也是不一致的，但是需要关注的重点还得关注。

　　功能测试阶段，这时候真的就是八仙过海了。因为测试的是自己的流程，之前对流程分析过，测试起来还是比较有感觉的，但是在测试的时候，也可以根据个人喜好，采取不同的方式。因为自己在设计用例的时候喜欢将关联性比较强的场景放在一起，这样避免了反复触发流程，但是这带来的麻烦就是，不是端到端全流程，中间倘若去除一部分，流程不能连贯下去。功能测试的时候其实关注点一块，页面展示OK只是最基础的地方，对于后台的传参一定要敏感，对于方案上明确的接口以及枚举值一定要查看，对于和第三方系统对接的部件，信息的传递重要信息，如密码一定要加密，决不能仅仅做一个透传。用例跑完，之后就是到发挥的时候了，考虑其他场景，有欠缺的地方进行补充。

　　对于漏测之处，最好还是能做一个总结，避免类似的场景再次漏掉。

　　对于流程的实现，归纳为三点，数据，接口，逻辑。数据通过接口进行传递，根据数据传递的信息，进行逻辑判断进行不同的处理，后两者都是为数据服务的，以上。

版权声明：本文出自 forstkksk 的51Testing软件测试博客：http://www.51testing.com/?600991

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。