因为在业务测试中，作为测试人员，熟悉负责的业务是非常重要的，而通过阶段性的梳理总结，可以让你的业务知识系统化的沉淀下来。当被问起这个业务系统的测试重点在哪里？难点如何克服？为什么要这样设计等等问题，可以有条不紊的进行输出。又或者，当你任务需要交接，或者需要别人支援你的业务，你可以自信的把文档丢过去，拍拍胸脯说：看一遍你就知道了。同样大家平时都在做业务，同样并没有多少别的技术层的产出，这也是为什么有人能拿A，有人却只能拿C的原因之*。另外，当你有了多种业务的沉淀之后，你甚至可以提炼出很多通用性的东西，姑且称为“方法论”吧

• 课程内容丰富

  课程覆盖手动、接口、自动化、性能测试等的全流程，由浅入深，确保学员毕业后，可胜任几乎所有测试技术岗位，成为技术实力派。

• 实战项目无缝对接

  课程包含各行业真实企业项目实战应用，老师带领学员边学边练，打造懂技术、懂业务、懂流程的高质量人才，毕业即能拥有实战经验。

• 严管严教确保工作

   拥有完善的教学管理体系，讲师、助教、班主任、工作老师四位一体，通过科学的管理和细心的辅导，确保学习效果，帮你对抗惰性。

• 课程优势

  学员在实战项目的过程中可以搭建完整的Web项目测试知识体系，并完整按照测试流程开展项目实战，实战项目覆盖主流行业，所学即所用。对真实项目中的核心模块进行多方面，多角度的用例设计，涉及订单管理、入库出库管理、客户管理、报表统计等等核心业务功能测试。

优点这么多，如何进行梳理呢？这里我参照常规的服务系统，写一些思路（框架），仅供参考。
1. 测试场景
这部分可以整理出业务系统的测试场景。
可以重点贴出核心的测试场景，附带上全量的测试用例。如果用例有后续迭代，也可以根据时间和内容进行分分类，放在这里。
2. 业务
这里就可以整理有关业务的更多细分领域。