来到平安，开启我的第一份正式工作：软件测试工程师，转眼间工作已经一年了。这个职位本着自己对它的第一感觉就是在app端点点点，点不通了那就是问题，再报给开发改，然后无限次的循环，直到全部都能点通即可。结果可想而知，我还是太嫩。下面就简单阐述下自己在这一年内所学到的软件测试方法和技巧。
目前一个项目进行到开发团队时，站在QA的角度包括下面这些流程，其中每个阶段都会涉及到测试，但测什么，怎么测，着重点，基本上都有差异。
我在测试阶段都会抱着一种相互矛盾的心理：
1、这里肯定有问题；
2、这里肯定没问题。
其实也可以理解为是在对自己的一种催眠，看到这里可能有些人会觉得是我有问题，哈哈，没关系，接着往下看。
一、需求熟悉
QA介入项目的标准就是产品发起需求评审，这里需要注意一点，尽可能先熟悉需求文档在进行评审。若实在没时间，就先记录下来产品从给需求文档到发起需求评审的时间戳，后面好有证据进行申述（前辈经验）。
需求评审阶段的测试工作，首先这个阶段我的态度就是：这里肯定有问题，还是哪哪都是问题。
1.1 了解背景
比如现在要在某平台上一款理财产品，了解项目立项的背景为了解决什么问题，帮谁解决，需要多久解决，这跟后面定测试计划是有关系的（往下看）。
1）解决什么问题，很明显是为了拓展业务；
2）帮谁解决，换句话说就是具体的销售渠道是什么，自产自销或者与其他平台进行合作；
3）项目周期，一个项目的周期有时候还真不是一板一眼根据实际需求和投入资源权衡评估的，这里面可能人、市场变化等会改变项目的发展趋势。
1.2 明确相关需求文档
所有的需求由产品给出，并且都要以文档的形式输出，注意需求必须明确版本、PRD、视觉、交互等辅助性资料。
1.3 需求分析
百度百科中IEEE软件工程标准词汇表(1997年)中将需求定义为：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
我们把第一句话进行拆分，再结合理财项目进行分析：
①用户。明确面对什么样的用户群，用户群的特征，比如是否有针对性输出不同种类的产品。
②用户的问题/目标。对于用户而言目标很明确，可以买理财，以及能否获得收益。
③解决问题或达到目标的条件和权能。针对上面要达到的目标，那用户如何购买、怎么购买成功、本金和收益是否正常，这就是最基本的条件和功能。
对项目有了个比较清晰的认知后，再结合PRD、交互和视觉进行详细分析，比如购买条件、如何购买、购买流程、支付流程、退款流程、赎回流程、订单状态翻转、资金展示、资金链路等。需求分析中对所有展现在面前的文档持相对怀疑态度，列出自己所有的疑点以及可以改善的地方。
二、需求评审
需求评审主要是产品主导，项目组成员参与，其目的是确定产品方、开发方和测试方对需求的实现方式达到一致同意。产品对介绍需求时，测试需时刻保持怀疑态度，不清楚或者觉得不合理的地方需及时提出。前面想在需求熟悉阶段总结的所有疑点也需在这个阶段提出并得到唯一的解决方案，不可模棱两可。
三、用例编写
3.1 用例编写的目的
结合前面准备的文档以及自己整理的材料，接下来就要准备用例。了解到有些公司并没有写用例的习惯，而是测试人员随机地进行发散性测试，这个我理解就是ET测试。至于有没有必要准备用例，个人认为这需要看项目的本质，如过项目排期特别紧且需求是比较小的，比如就改动了UI、修改文案等不涉及逻辑性的需求，我觉得是可以不用准备用例的。但大部分情况还是很有必要前期准备好用例的，首先是可以加强对需求的掌握，更深地前置发现问题；其次对于后面的测试执行可以更精确制定测试计划，有迹可循；最后对于整个项目组来说，让大家都知道每个角色的工作内容，减少相互猜疑干虚事的可能。
3.2 如何编写用例
对于具体的用例如何编写，前面步骤整理的文档会起到很大的作用。先用思维导图的形式按照大模块—小模块—功能点列出来，这样不容易遗漏，也给后面具体的用例编写提供了思路。至于用例到底要写多少条合适，结合领导的建议以及个人经验总结，P0(准入用例)与全部用例在1:10这个比例上是比较合适的。
对于理财的前端测试，首先画出思维导图，包括基础功能、性能、用户体验。针对每个大模块进行拆分，下面是列出的详细功能点，不一定覆盖到100%，欢迎提出意见。
四、用例评审
用例编写完成后，一定要组织项目组成员进行用例评审，这个步骤一方面是得到项目组的认可咱们测试的范围，一方面是让大家确认是否有遗漏的地方。
需要注意的是讲解方法，不可能是对着用例逐条逐条过，QA自己才需要关注很细的点，扣到字眼上。但用例评审时大家更多关注的是测试具体从哪些方面考虑，这个时候前面准备用例的思维导图发挥了很大的作用。根据思维导图覆盖大模块-小模块-功能点覆盖即可。
这里有个小建议，评审时第一时间抛出准入用例。准入用例是前端开发需要自测的范围，必须要与开发达成一致同意，避免后续开发自测准入时对测试给出的用例持怀疑态度，还有也是对开发提交到测试这边的一个质量保证。
五、准入阶段
准入阶段是开发和测试共同需要执行的，开发执行准入用例后正式提交测试，测试需要对准入用例再次执行一遍，给出结论是否通过。这个过程必须严格执行，若测试随意放过，对后续的SIT系统测试带来很多阻塞问题造成的项目延期等后果只能自己替开发背锅，也会放纵开发后续会随意执行准入用例，带来的不良后果就不只是当前的项目了。
但这里有些特殊情况，若由于环境、数据、前期配置复杂执行准入用例效率很低的情况下，建议跟开发一起过准入。
六、SIT系统测试
项目进行到SIT（System Integration Testing）系统测试阶段，就算是正式交接给测试了，功能、性能、兼容、稳定性都需在这个阶段完成测试。结合前面准备的测试用例，按照用例等级从高到底的顺序优先完成功能部分的测试，接着再是兼容测试、性能/稳定性部分。
在SIT系统测试阶段，需要测试人员必须抱着充分的怀疑态度，不管是实现逻辑、实现结果，甚至是测试人员自己写的测试用例。因为也许开发最后实现方式有变动，或者用例都有错误。
关于执行的时候有些小技巧供大家参考：
1、在执行基础功能用例的时候，可以兼换着设备、网络进行测试，这样可以缩短测试时间，并提早发现兼容问题；
2、测试环境理财的资金链、订单状态翻转往往都不是实时的，可能需要第三方进行处理，而这部分又是最核心的功能。因此优先执行关于订单状态和资金展示的用例，可以一次性多下几笔单，确认每笔订单处理的结果，交由第三方处理并验收；
3、执行时请连上代理，通常都用Charles，对于偶现问题可以尽快找到原因，同时也可以熟悉前端接口调用拿入参和出参与开发沟通。
七、UAT阶段
UAT即为用户验收测试（User Acceptance Testing）阶段，此时项目质量已达到验收标准，验收目的是交给用户对项目进行验收测试，是否能接受此系统。在验收过程中，难免会报出很多问题，其中不乏需求变更。此时可以让产品直接对接用户，收集用户反馈的问题，过滤掉需求变更的问题，再将问题转给测试，测试复现后提交给开发进行修复，修复完成后提交验收包给到用户并反馈问题修复情况。最终以用户输出UAT报告完成UAT验收阶段。
备注：原则上UAT阶段是不允许进行需求变更，但若在可控范围内进行修改文案等不涉及逻辑，且开发能给出明确的影响范围可以酌情处理。若需求变更比较大则整个项目周期不可控，需提出来交给产品和项目经理重新决策。
八、后端发版
UAT完成后，后端需要发版。一般发版都会在半夜（首次发版除外），避免影响线上用户，需要提前准备好验证范围和数据。对于后端发版只需验证Android或ios一个端即可，且只需覆盖涉及到后端逻辑的场景。
九、生产验证
进入生产验证阶段前端代码必须要封版，后端已经发版。生产验证主要覆盖每个场景的正反案例，比如购买理财成功、购买理财不成功（多种原因购买不成功：无权限、金额错误、密码验证错误、中断操作、无网操作等）。但由于数据权限等部分场景无法覆盖，在进入生产验证前必须整理出来并告知项目组，无法覆盖部分交由谁负责验证并输出结论。
生产验证期间后端已经发版，因此对于涉及到后端逻辑部分已经验证通过，这部分场景无需较多关注，可以持相对相信的态度。
十、前端发版
生产验证完成后输出生产验证结论、测试环境和生产环境安全测试报告前端即可发版。对ios发布包、Android加固包需简单过下，保证页面跳转OK，核心流程理财购买成功即可。Android提交市场还需打渠道包，还需随意挑选一两包进行简要回归，确保下载、UI没问题。
十一、上线回归
前端完成发版ios提交到App Store，Android提交到应用市场，待审核通过后开放下载，这时需通过线上下载途径进行回归验证。对于验证范围没有明确标准。个人认为线上回归范围涉及到校验密码的场景需覆盖正反案例，尤其是注意反向案例。
前端发版和上线回归两个阶段测试人员最好进行ET测试，从测试角度转变成用户角度，思考用户会怎么使用。比如新用户不会立即去注册开户，看中了理财想购买，点击之后发现需要登录，然后再进行注册开户的流程。
