2022.7.11学习笔记

一，测试计划

1、定义：⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员 安排以及任何偶发事件的⻛险。

2、测试范围：测试的边界，也就是说本次迭代（2周）测试需要干的具体的事，测试范围里面需要明确的指出这么几点： A、本次新迭代需要测试的内容 B、本次迭代是否需要测试性能测试 C、本次迭代是否需要测试系统之前的功能，如果测试，时间是多少？(系统已有功能是每个迭代必须要进行测试的，但是不会给太多的测试时间)。

3、测试策略：在测试范围清晰的定义测试的边界之后，那么测试团队需要考虑的是使用什么样的测试策略来进行测试，也就是说通过什么样的解决思路以及测试技术，能够在有限的资源上完成产品的交付

[测试技术手段：]

a、自动化测试

b、精准测试（开发修改了哪些代码，测试这边很准确的知道修改了哪些代码，以及自动化的验证这些被修改的代码）

c、流量回放（把线上所有的请求在线下执行）

d、混沌工程（Netfix和阿里巴巴）(通过科学试验的手段技术来模拟生产环境中出现故障后的技术解决方案)

4、资源安排：两个维度：

人力资源（已经清晰的知道测试的边界以及测试的范围，思考的是通过几个人，以及多少天来完成这件事）

硬件资源（在测试的过程中是否需要服务器，如果没有服务器，那么就需要采购）

5、进度安排：

①、针对测试的边界（范围），会把任务拆分成很多的story

②、给每个story完成任务的具体时间范围，需要精确到小时（每个任务具体开始的时间和具体结束的时间）

6、发布标准：往往是主观的，大家都是认可的。

7、风险控制：在测试计划里面，关于风险控制，不是非必要的，但是是必须考虑的，所以说的测试风险，指的就是事实上大家可见的问题，不能主观意愿强加到风险以及凭自己的猜想强加的风险。

二，测试计划的注意事项

1、针对本次迭代需要测试的对象，任务必须要拆分，而且拆分后的任务都是可独立的测试 2、针对分配给你的story（任务），测试时间由自己规划

3、一般测试计划是每个人去梳理，最后测试计划去整合。

4、风险控制方面如果存在，需要列的非常详细，以及针对每个风险控制的点，需要给出具体的跟踪人，以及负责人

A、没有服务器、运维工程师

B、你负责测试的模块依赖于别人。（解决方法：自己造数据）

C、关于风险，如果涉及自己，一定要把风险反馈出来，不能由着开发的意思来，也不能说自己能够解决。

5、你负责的任务由于太大，分配了另外一个测试和你共同来测试这部分，此时你会这么做？

A、你的负责人和对方的负责人，明确任务的边界

B、每天早上反馈的时候，反馈下任务进度，各自反馈各自进度。

三，邮箱的测试范围

四，测试计划中测试顺序 1、兼容性测试（派一个人半天即可）

2、系统测试

3、性能测试

五，依赖方清单

六，测试计划细节