目录
一、需求
1、需求评审
为什么要需求评审?原因有下面几点:
①、熟悉业务,由产品或者业务讲解需求,好做到心中有数,不至于到开发测试阶段暴露出由于业务不熟悉导致的问题;
②、多方协定,在正式进入开发阶段之前,测试、开发、产品就某些需求的不确定点进行确认,达成一致,避免后续的问题;
③、评估工作量,实现难度,以及大概的资源投入;
④、明确开发测试边界、目标和范围,做什么不做什么;
2、需求文档
①、尽可能的详细,需要从需求中提取相应的功能点和测试点;
②、功能点和测试点选取适当的粒度,这样可以较容易的观察到测试结果和需求的偏离度;
③、一般来说,系统越大,业务越复杂,需求的偏离度判定比小系统更容易些;
二、系统架构
除了需求,了解熟悉整个系统的技术架构,也是必须的一点。比如整个系统的架构组成,各自的特点,采用了什么通信服务框架,数据库类型,前后端框架等等,这样可以更方便定位缺陷,
以及根据系统架构选择合适的自动化测试框架、性能测试策略等。
特征:一般来说,系统的稳定性越好,那么它的可适应性就越差,其带来的影响是每次架构变更的成本上升以及开发团队重新建设抑或测试团队整体方向上的变化。
这几年开始流行和大规模应用的分布式架构、微服务等,都是从系统的可用性和伸缩扩展性来考虑,以降低各方面的变更带来的成本。
三、流程管理
测试过程结果的记录应该在一定程度上取决于流程的记录完整程度。
如果涉及到流程更改,也应对不同的观察对象(