测试计划

测试分析的工作流程：
测试是围绕着需求进行
根据需求文件进行分析 ====》梳理需求测试的业务流程 ====》找出改点（本次需求中说明的新增功能或者修改的功能）====》提炼测试点 ====》输出测试用例


编写业务流程相关的测试用例，注意点
1.要注意后台系统的操作，作为测试人员，本质上就是整个软件系统的首批体验者，所以后台系统的功能是要进行验证的，很多功能都是前后台交互的
2.要描述清楚你在操作哪个客户端（比如顾客使用的人人乐微商城移动端，工作人员使用的TSM系统（pc端）、移动端TSM系统，配送人员-人人乐园、社会人员 - 众包物流平台等等）
3.有些实际的（现实生活）的操作不需要真的执行，模拟真实情况已经执行即可

第三方接口：通过调用其他公司接口的方式获取其他公司系统返回的信息数据供我方系统使用


兼容测试（兼容性测试）：确保软件可以在不同的软件或者硬件环境下正常使用
APP兼容：在不同的手机上运行本项目的APP（根据市场调研获取这款APP在线上的用户受众，统计用户人群的手机情况，获取topn机型，根据topn机型进行选择对应的机型进行兼容性测试）

web兼容（浏览器兼容）：在不同的浏览器上运行本项目的网站（主流浏览器：谷歌浏览器、IE浏览器、火狐浏览器、Safari浏览器）

软件的帮助手册，一般由测试人员或测试经理写的。帮助手册是包含在易用性测试里。


358原则：
用户在3秒内得到响应，就会觉得系统响应快
3-5秒内得到响应，感觉系统响应速度还可以
5-8秒内得到响应，感觉系统响应速度很慢，但是还是可以接受的
超过8秒，大部分用户就会认为系统失去了响应，会选择离开系统，或者重新发起请求


软件项目组，开发和测试的比例
开发 ： 测试
4   ： 1
5   ： 1
6   ： 1


特殊情况：
小公司只有10个开发 === 》 说明项目不大，只有0-2个测试人员，一般情况是没有测试人员或者就一个

中型项目：20几个开发，一般批4-6个测试人员
大型项目：50个以上的开发，一般配8-15个以上测试人员

银行类项目：2:1 或者 3:1


**测试人员是在研发部门的



迭代的定义：一次迭代会在系统的原有功能基础上，进行部分功能的添加或者修改

测试总工作量（人/天）：结合迭代周期去计算
例如：1个月的迭代周期 2022-8-13  - 2022-9-13,可用工作日：21天
（5个测试人员的总工作量：21*5 = 105人/天）




收尾阶段（上线准备阶段）：输出测试测试报告、准备生产环境的验收数据（和真实数据接近的数据）、做系统回归、维护自动化脚本
系统回归：在迭代结束前，准备上线之前，需要对系统在本次迭代未修改的其他主体业务流程进行全量回归，确保本次迭代没有影响到原有的业务



安装测试：
1.全量安装：从无到有的安装
2.存量安装：更新，原来已经有安装这个软件

版本号：Vx.y.z
x:主版本号，表示一个大版本，每个大版本设计的功能或者页面更新区别会很大
y：次版本号，表示每个大版本中间的迭代，对一个大版本中的功能进行更新修改，大体是离不开大版本的内容，甚至用户不会有太大的感知
z：修订版本号，修正版本，小优化，在每次开发提交一个新的代码包就会更变一次修正版本号


在工作过程遇到测试风险的解决思路
1，必须及时的上报，且每日上报，及时让领导清楚风险情况，做好风险应对
2，申请延期
3，加班处理，增加测试人力
4，按照优先级处理