测试分析
确认测试范围
根据测试项目的不同需求，有大致几类测试项目类型：商户/平台功能测试、支付方式接入测试、架构调整类测试、后台优化测试、性能测试、基本功能自动化测试。
测试项目需要按照文档要求进行测试需求分析，并给出对应的输出项。
没有产品接入的项目，需要要求架构师、技术经理给出功能要求，结合测试分析给出测试需求。
a、根据需求或者产品文档中确认项目功能范围。
产品需求由产品评审后给出，测试负责人需要和产品确认项目范围；没有产品文档的也需要产品给出明确的书面需求。
性能测试需要明确测试通过的标准，这部分可以和架构师、技术经理确认完成后制定。
没有产品介入的架构调整类的项目，应由架构师给出测试范围确认。
b、和架构师确认在相关系统层面上的功能需求，以及该功能修改是否涉及影响到其他相关功能。
在架构师完成架构设计后，测试负责人和架构师、技术经理确认功能修改的涉及范围，从实际代码修改的层面上出发帮助减少遗漏的检查项。
根据架构师提供的用例图等，分析功能测试范围。
需要架构师给出项目涉及修改范围文档，帮助测试确认范围。
c、结合实际的业务逻辑分析该功能修改可能影响的功能范围。
测试负责人在充分了解测试项目内容后，结合对现有相关平台系统业务分析，确认是否增加或减少测试范围。正确估计功能修改涉及范围，判断对现有不在项目修改中的其他功能是否有影响。
如果对非项目修改功能有影响，及时与产品及架构师、技术经理确认，明确解决方法。
结合以上三点，确定项目的测试范围，以便确认具体测试项。
输出项：
1、可以先和架构师、技术经理进行确认，再以小组讨论形式和项目测试人员确定测试范围。
2、用列表或者结构图的方式给出项目测试包括的功能测试范围，邮件给到相关架构师及测试人员。
测试需求分析
a、仔细阅读产品文档（需求），从系统角度划分功能模块，理清功能模块间的关系。
功能模块间从属关系，是否有业务操作顺序关系，初步考虑测试执行策略，提高测试执行效率。
功能模块间如果相互影响，需要考虑相关的测试检查项。
该部分分析在测试用例目录描述中说明。需要描述清楚项目功能之间关系。
b、了解功能涉及到的数据表结构关系。
找相关架构师或开发了解项目主要涉及的数据库表结构，需要清楚主要检查数据的内容。其功能涉及到的相关数据表需要告知到相关测试用例设计人员及测试执行人员。
相关数据表需要在测试用例目录描述中说明。
c、分析各功能的主要业务流程。
分析该功能主要业务操作流程，该主要流程在测试用例设计时应作为一个单独的测试用例，其测试用例级别为一级。
该主要流程为一个正常处理流程，即业务角度出发最合理操作流程。其主要目的是验证功能是否被实现。
d、根据判断条件，分析业务的备选流程。
根据业务流程中的判断条件，列出所有的备选流程，明确业务流程的起点和终点，可通过路径覆盖的方式进行分析。备选流程包括非主要流程的正常流程，及异常处理流程。
e、用户角度出发，考虑场景法，分析产品需求，尽可能覆盖用户业务场景。
用户使用场景、方法结合业务以及大数据埋点分析，尽可能贴合最真实用户角度验证。
f、和架构师、技术经理沟通，确认涉及到的数据流变化，从数据变化角度覆盖业务流程。
对功能涉及到的数据状态变化需要明确其数据变化数据库字段如何表现，有哪些状态。对于交易类数据需要检查订单状态，支付订单状态等，这部分可以的话要求架构师给出明确文档说明。
测试用例设计人员需要清楚这部分数据变化，并在测试用例中做检查。并结合以上c、d、e、f列出项目测试功能点，在测试目录描述中说明。
该阶段所有业务流程，数据变化需要得到需求确认。原先需求中没有说明清楚的，确认完后需要要求相关人员修改需求文档，并通知所有相关人员。
输出项：
1、项目测试计划文档，需要给出明确的测试范围、测试项。
2、项目测试计划完成人力、时间安排。
3、确定一级测试用例数量。
4、测试集目录，添加测试分析描述信息。
测试分析基本流程
附测试集目录测试分析描述模板：
SIT：XXX
RA：XXX
测试用例：XXX
测试分析：XXX
功能模块描述
该模块主要功能描述，在某某平台某某业务情况下被使用，与其他什么系统功能有相互调用关系等。
涉及数据库表
该测试集测试功能主要涉及的数据库数据表，及对应数据表说明。
测试需求
主要业务流程、备选流程的描述。
测试用例需要包括的测试项
功能检查、页面要素检查、性能检查、数据库数据值检查等。
测试分析
根据测试分析思路，详细列出测试点，与测试用例对应。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
