手把手教你做测试分析
测试分析
什么是测试分析？ 我们了解作为一名 testers，在获取需求后不能立即开始制定测试计划的原因在于：**需求是否合理、是否有价值、是否可测性这些关键问题我们尚未弄清楚之前就开始制定计划是不理智的做法。
在讨论会结束之后立即应当将需求分析纳入日常安排并予以高度重视。那么如何确定需求分析的具体内容呢？为此我们可以参考如下的思维导图来详细阐述这一流程。（细节部分未展开，请完整版的完整思维导图请查看附件）
项目分析
项目需求背景了解
在获取了客户需求之后, 我们需要深入了解其背景. 在深入理解的基础上进行下一步工作会更加高效
项目相关人员
在明确需求背景之后，我们旨在了解一个需求从其产生到最终上线这一整个过程所涉及的相关人员。这些相关人员主要包括但不限于：需求设计师、开发工程师、测试员以及运维支持等。通过这项了解工作，我们可以实现两个主要目的分别是促进团队内部信息的畅通交流以及评估团队成员的专业技能水平。此外，在分析各参与者的投入情况时我们也可以基于其专业经验来判断项目的潜在风险程度如何
项目计划
整个项目进程与我们的测试工作紧密相连，在前期阶段我们就应制定相应的测试计划并对其潜在风险进行全面评估。作为测试人员不应被动等待项目的启动，在任何时候都应密切关注项目的进展情况以及其各个关键节点。因为任何环节的延误都将直接影响到我们的测试工作进度或是压缩总用时长度这一点我们必须予以重视。当遇到一些突发状况时有时也需要主动推动相关进程以确保工作的顺利推进
项目需求的设计和实现
在项目需求分析过程中占据重要地位，在线获取并掌握项目的整体设计方案，并对其中涉及的功能模块及其对应的业务流程和交互界面进行识别。同时明确需要新增或优化的各项功能，并梳理与现有系统对接的数据接口和操作流程，并规划系统中各项功能的具体实现细节。
项目风险分析
测试项目风险包括
- 产品风险：产品需求分析是否满足客户需求
- 设计风险：设计是否合理？是否存在过于简化而无法覆盖特殊场景的风险？是否存在过于复杂导致效率低下甚至无法正常运行的风险
- 开发风险：开发团队投入是否足够？开发人员是否有能力胜任开发工作？代码质量是否较高？
- 测试风险：测试团队投入是否足够？测试人员是否有足够的经验？测试质量是否有有效的跟踪方案？测试环境与生产环境的一致性如何？能否覆盖所有可能的测试场景？
测试策略制定
项目整体测试策略制定
项目在制定测试策略时需基于对项目的整体把控进行规划，在综合考虑人力投入情况及工作量的基础上确定合理的策略范围如测试范围不测试范围等参数的具体划分以及覆盖率自动化率等指标的设定。
通常情况下测试工作侧重于新增或修改的部分同时由于新增或修改可能影响现有功能因此对历史功能也需要进行必要的保障性测试。
在实际操作中我们倾向于对新增或修改的部分进行全面覆盖而对于历史功能则着重进行保障性检验。
当自动化建设较为完善时可以通过自动化案例执行的方式实现回归性测试以提高效率。
在设定自动化率时通常会参考项目的投入产出比例若项目具有持续性则建议加大自动化投入以尽可能提升覆盖率；反之若产品功能更新频繁且不具备持续维护需求则应减少自动化程度以降低维护成本。
从功能角度来看应当优先配置数据类接口类相关场景的案例实现自动化处理而页面类自动化的实施则因维护成本较高而相对可控。
模块测试策略
-
接口类：
a. 参照 interfaces 设计文档并进行交互数据的有效性检查，并对 interfaces 的输入与输出进行验证。
b. 分别对 interfaces 的输入和 output 进行验证。
c. 评估 interfaces 之间的依赖关系。
d. 执行与功能无关的测试。
具体测试策略可参考 https://www.cnblogs.com/daxiong2014/p/4846619.html -
数据模块管理
-
数据库设计方案验证
-
数据处理流程测试
-
系统交互响应测试
具体实施策略建议参考 -
界面类
a.界面展示
b.界面业务功能
c.界面交互
-
是否涉及非功能类测试
考察新增需求是否存在相关性时，请评估其是否涉及性能指标如运行效率、稳定性、数据安全性以及跨平台兼容性等关键要素；若有相关需求，则应制定相应的非功能性测试方案及实施策略
其他
测试环境准备
测试工具安装及使用文档