软件测试工程师手把手教你如何制定测试计划

lsekfe

　一 、产品概述
　　1、产品背景
　　目标是为了让测试人员了解下业务背景，并站着用户的角度去思考，去测试。
　　2、产品目标
　　测试分析的时候需要对此项进行关注，依据此处内容提炼测试需求。比如需要满足多少人同时使用该功能，对应出来的性能目标就是：要求并发量啥的。
　　二、项目整体分析
　　1、测试需求功能点罗列
　　主要是用来针对测试需求和产品需求之间的一个对应。
　　2、系统整体的设计图或者架构图
　　了解整体的一个设计框架，方便测试软件对整个业务的一个把控和测试设计。
　　三、功能性测试需求分析
　　整个部分是针对项目整体分析中—测试需求功能点罗列部分的功能 进行的一个逐条分析，设计测试。
　　1、测试需求
　　把自己针对当前产品需求对应的测试需求在此说明。
　　1）测试需求。根据所测的功能点进行分析、分解，从而得出 的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等
　　2）待测试软件的特性。不同的软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不相同。除了需要确保要求实现的功能正确，银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。
　　2、交互图
　　系统之间的交互图，如：UM时序图
　　3、流程图
　　当前功能的业务流程图：
　　1） 常用的或规定的业务流程
　　2） 各业务流程分支的遍历
　　3） 明确规定不可使用的业务流程
　　4） 没有明确规定但是应该不可以执行的业务流程
　　5） 其他异常或不符合规定的操作
　　4、 测试策略
　　根据当前的需求制定出来的一个执行方案：接口还是功能或者性能。
　　5、测试用例
　　针对当前的测试需求而设计的测试用例。不是完全的具体测试用例，只是对该测试需求的一个测试方向的描述。
　　例如:登录功能
　　其中一个测试用例：用户名的长度是6~20个字符。
　　而不是：输入6个字符–结果通过。。
　　是列出从哪些角度去分析覆盖这些测试需求，非具体的测试输入输出。
　　四、非功能性测试需求分析
　　该部分主要是针对不同的测试方案进行的一个具体的分析。
　　1、 性能需求
　　2、安全需求
　　五、测试资源
　　主要是对当前测试的项目所涉及到的测试环境，人员，时间等资源的一个说明。

　1、测试环境
　　2、测试人员
　　3、测试时间
　　六、测试方案
　　主要是指定和说明当前测试所要遵循的一个规定：执行策略，设计策略，以及回归策略等
　　1、执行策略
　　执行几轮，每轮怎么执行，测试用例执行的优先级等。
　　2、设计策略
　　测试方法是什么？功能 接口 性能 安全以及测试用例的覆盖率等的说明。
　　3、回归策略
　　说明当前项目影响到的业务，是否需要回归，回归的内容有哪些，何时去回归等等。
　　七、测试缺陷管理
　　BUG管理,对缺陷的说明管理等相关信息，缺陷工具，优先级，缺陷内容要求等。
　　如：优先级：根据缺陷的严重程度以及影响范围定义缺陷的优先级。
　　1-紧急（A）：主要功能完全丧失、数据受到破坏的Bug、生产环境发现的影响业务流程的bug；
　　导致APP闪退、app无法正常启动或登录等Bug；
　　菜单或者按钮没有实现本来的功能或者不起作用的Bug。
　　2-高（B）：影响其他功能模块的运作；次要功能没有完全实现；
　　主要功能已实现但是实现存在明显错误；
　　严重的性能问题；界面布局严重错乱；
　　3-中（C）：影响小且不影响其他功能的Bug；
　　4-低（D）：页面样式有出入但不是很严重；提示语、易用性等建议性问题。
　　八、测试流程管理
　　主要是对测试过程的一个规定，比如 准入，准出，产出等
　　1、 准入准则
　　冒烟通过标准：主流程无阻断性bug，新增主要功能无阻断问题。
　　2、 结束准则
　　测试通过标准：

3、 文档规范
　　最终要产出的文档，如：测试计划，测试方案，测试用例，测试报告等。
　　九、风险预警
　　过程中可能存在的风险或者困难啥的，主要是通过需求和设计的了解中知道，在后面的测试过程中可能存在的。