手把手教你做测试分析

测试分析

测试分析是什么？ 我们知道作为一个测试人员，拿到需求之后，不可能上来就做测试设计，因为 需求是否合理？是否有价值？是否可测试？ 这些问题我们没有弄明白之前开始做测试设计是不负责任的

需求分析在需求讨论会结束之后就应该被提上日常并被认真对待，那么需求分析要分析哪些内容呢？我们用下面这个思维导图来说明这个过程（细节部分未展开，完整思维导图请查看附件）

项目分析

项目需求背景了解

首先拿到需求后我们要对需求的背景做具体的了解，我们会考虑需求的来源、需求服务客群、需求目的。
一般需求来源有哪些呢？需求有可能来自于客户定制化的个性化需求，有可能来自于产品经理根据市场调研得到的客户潜在需求，有可能是针对产品痛点提出的解决方案等等。了解到需求来源的合理性是我们要做的第一步。
确定需求来源后，我们要明确需求服务的客群，这有助我们在后续测试过程中测试方案的确定。我们要了解到需求的客群是内部客户还是外部客户，是客户端客户还是管理端，这对我们测试策略的制定也有非常大的意义。
然后我们确认需求实现的目的，需求实现后可以为产品带来新的用户，还是解决已有用户的问题，还是提升客户的体验等。后续也将这个需求目的作为衡量需求质量的重要指标。

项目相关人员

明确需求背景后，我们将要了解一个需求从产生到最终上线整个过程涉及到的相关人员，包括需求设计人员、需求开发人员、需求测试人员、需求运维人员等等，了解需求相关人员的主要目的有两个：第一，有助于在工作过程中的沟通和交流。二：根据需求人员的投入情况，相关参与人员的经验程度也可以作为项目风险程度的重要指标。

项目计划

项目的整个计划过程也和我们测试过程息息相关，我们在前期就应该根据项目的整体计划来制定项目的测试计划并且评估项目在计划上存在的风险等。作为测试人员不能被动的等待项目开展，而是要时时关注项目处于什么节点，项目的进展，因为任何一个环节滞后都可能导致测试环节延迟或者导致测试时间被严重压缩，这是我们要尽量避免的，当项目出现一些突发情况，有时候甚至需要我们去推动事情的进展。

项目需求的设计和实现

这个是项目需求分析的重点，我们根据获取到的项目，了解项目具体的设计方案，了解需求涉及到的新增或者修改的部分，涉及哪些场景、哪些过程、哪些接口、任务、数据库信息等等。

项目风险分析

测试项目风险包括

产品风险：产品需求定位是否满足客户需求
设计风险：设计是否合理，是否过于简单无法覆盖特殊场景，是否过于复杂导致效率低下等
开发风险：开发人员投入是否充足，开发人员是否有经验胜任开发工作，开发写的代码质量是否较高
测试风险：测试人员投入是否充足，测试人员是否有足够经验，测试质量是否有较好的跟踪方案，测试环境与生产环境是否一致，测试场景是否均可测试

测试策略制定

项目整体测试策略制定

项目在制定测试策略时需根据之前对项目的整体把握，根据测试的人力投入情况与测试工作量等情况制定合理的项目的测试策略，如测试范围，不测试范围，测试优先级，测试的覆盖率，自动化率等。
一般而言测试的重点在于项目新增或者修改的内容，其次由于引入的新增或者修改内容可能影响已有功能，所有对历史功能的测试也是必不可少的。正常情况下我们对新增或者修改内容全量覆盖，对历史功能做保障性测试。如果自动化建设的比较好，可以通过自动化案例执行回归性的测试。
测试内容的自动化率的制定一般根据投入和产出来衡量，若一个项目是持续性的，那么一般会加大自动化投入，尽可能的提升自动化覆盖率。但是如果产品功能变化频繁或者产品不是持续维护的，那么一般较少投入自动化。在功能方面，数据类和接口类的案例做自动化较多，而页面自动化由于维护成本较高，投入相对较少些。

模块测试策略

接口类：
a.据接口设计文档，对交互数据做有效性检查，检查接口输入输出
b.接口输入/输出验证
c.接口依赖性测试
d.接口非功能性测试
具体测试策略可参考https://www.cnblogs.com/daxiong2014/p/4846619.html
数据类
a.数据库设计检查
b.数据加工逻辑测试
c.数据交互测试
具体测试策略可参考
https://blog.csdn.net/jie1521836/article/details/81084393
界面类
a.界面展示
b.界面业务功能
c.界面交互

是否涉及非功能类测试

分析新增需求中是否有需求需要进行性能、可靠性、安全、兼容性等测试工作，如果需要则需制定这些非功能性测试的测试方案和策略

其他

测试环境准备
测试工具安装及使用文档

附件

测试分析思维导图