?前言
进入新的部门,首先面临的是熟悉业务以及如何设计用例，如果是新人QA的话，很可能会因为面对复杂系统复杂业务而不知如何下手，鉴于一些经验总结，给出如下的一些建议，希望对新人有帮助。
1.先宏观掌控，再细节切入
刚入行的新人，往往很容易犯的一个错误是，没有宏观的去掌控全局而一头陷入功能细节。
在我们拿到一个需求的时候，我们作为QA，首先第一个是需要认真分析需求，可以从如下几个方面思考：
- 产生这个需求的原因
- 该需求实现的功能
- 新功能对现有系统的影响
由此在我们拿到需求后，我们可以引发测试思维上的三点宏观拓展：
- 确认需求是否有偏差，可能由此会发现一些需求问题-----需求BUG
- 确认目前系统的回归范围或者历史数据处理----回归范围/历史数据处理
- 我们要做哪些类型的相关测试----测试类型的宏观覆盖
目前涉及到新功能的测试我们常见的测试类型会涉及到如下：
- 功能测试
- 性能测试
- 安全测试
- 异常测试
- 接口测试
- 兼容性测试
以上这些，是我们需要不断去凭借经验累积和实践的。
2.细节切入，要学会先归类
所有的类型测试都有一套测试思维，这里不一一展开，我们以功能测试为例，进行细节切入的讲解。
招聘业务最常见的测试类型和手段就是功能/手工测试。但是面对一个新的系统，我们如何下手去写用例会让我们一开始有些茫然失措。
每个人写测试用例的思维模式都不一样那如何抽象出思维，形成一套公共的思维模式去实现用例的编写和落地呢？在这里可能还是需要一些测试思维去引导把控。
当然，我觉得最最重要的，还是要学会给功能用例进行归类。
宏观上我们可以进行如下的一些归类
-
系统归类
目的：将大的功能模块切小的完整的功能模块，将不好把控的全局模块一部分一部分去吞掉。
思考的角度：从需求入手，以一个大的功能点或者流程线方式入手
举例：易人才的系统模块划分
-
模块归类：
目的：将模块再进行细节切入，将测试归纳为可落地的测试点
思考角度：将前后端进行测试分层，将测试模块进行归类划分，让整个测试覆盖更为清晰，减少遗漏
举例：在我们拿到一个模块后，我们会进行前后端分层，在功能用例中，我们会以页面为例进行相关划分，若页面夹杂功能较多，独立抽象归纳，直至分层结构清晰
分层到最后一层模块，可进行前后端分割
3.关注测试点，而不仅仅是测试用例
传统的测试用例，我们关注的一个用例可执行一次，需要作为较细的划分。
测试点在传统意义上来说可以说是比较粗略，但是测试点的覆盖全面是整个测试质量保障的核心。
我们往往在设计测试用例的时候，忽略了测试点的设计而直接进入测试用例，这样又会造成一些捡了芝麻丢了西瓜的事件；
同时，在一些较为常见功能的设计中，测试点的列举可以大大提高整个测试的清晰度，特别是在敏捷测试过程中，尤其是在用例设计，用例评审和测试执行的时候。
举例：
但是，针对复杂的功能点，特别涉及到逻辑算法相关的，测试点的覆盖，不能完全满足业务场景的需要，我们可能还是需要再从测试点进行细化。
以上，是需要不断的去用经验积累和不断去反思的~