1.缺陷定义：
在软件中存在的bug
2.出现bug的地方以及找到bug的方式有:
①肉眼看到
②系统资源使用率 cpu 内存 网络 电量…
③服务器端
④访问的方式/数据库的
3.判定bug的依据：
①需求文档 原型图
②不相符合的错误类型
③难以理解，不易使用，运行缓慢
4.bug出现的原因（28原则）
20%来源于代码，80%需求不明确产品需求经常变更
5.产生bug的原因归纳行为：
①需求解释有错误
②用户需求定义错误
③需求记录错误
④设计说明有误
⑤编码说明有误
⑥程序代码有误
⑦数据输入有误
⑧测试错误
⑨问题修改不正确
6.测试流程（*****）
我们一般在项目进行时开立项会（产品经理、项目经理、开发人员、测试人员）的时候进行参与，讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写测试计划，根据模块的颗粒度划分并编写测试用例以及对用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug开发进行修改，修改成功后关闭bug,进行回归测试，在上线前进行测试总结。
《需求文档》/《规格说明使用书》（入职第一天就要要）
《测试计划》 一般由测试组长或者测试经理编写（参与）
《测试用例》 根据模块划分/根据测试功能/性能/自动化进行划分
用例评审会：
a.组内评审（测试人员、测试组长、项目经理、产品经理）
b.组外评审（测试人员、测试组长、项目经理、产品经理、客户）
冒烟测试：对软件的主要功能进行测试
回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
测试总结：一般由测试组长或测试经理编写（参与）
原件测试的258原则
当用户能够在2s以内得到响应，会感觉系统的速度很快
2-5s之间，会感觉系统的响应速度还可以
5-8s之间，系统的响应速度很慢，但是还可以接受
用户超过8s后仍然无法得到响应时，会感觉速度糟透了，或者认为系统已经失去响应，而选择离开这个web站点或者发起二次请求
日常工作：
1.参与需求讨论，制定测试计划，确保测试能顺利执行并完成
2.负责项目的功能性测试，用户体验测试，兼容性测试以及性能测试
3.负责测试用例的编写，编写测试报告和对测试结果的分析
4.与开发人员、产品经理沟通和协作，推动整个项目的顺利进行
5.负责软件开发团队项目进度管理工作
6.熟悉Linux常用命令、熟悉数据库、熟练使用基本的SQL语句
7.熟练使用Loadrunner,Jmeter等至少一种性能测试工具
8.熟练掌握Java/Python/shell等编程语言的一种
9.熟练使用Python+selenlum/appnlum pytest innerHtml
10.持续性监控
7.测试分类（*******）
测试分类：按阶段划分 代码是否执行 程序运行划分 其他
阶段划分
单元测试：单个功能的测试（增删改查 分页 上传 下载）
集成测试：功能模块的测试（多个功能点总结在一起）
系统测试：多个模块合成测试（整个软件的整体测试）
验收测试：客户以及产品经理进行（交付前的测试）
程序是否执行
静态测试：ui界面 业务逻辑
动态测试：链接数据之后
代码是否执行：
黑：纯功能测试
功能测试：
安装和卸载
界面测试
易用测试
兼容性测试
逻辑功能测试
性能测试：
稳定性测试
压力测试
负载测试
白：使用编程脚本进行测试，实现自动化
灰：介于白和黑之间
其他测试：
冒烟测试
回归测试
随机测试
暴力测试
8.测试原则
①测试显示软件存在缺陷
②穷尽测试是不可能的
③测试尽早介入
④缺陷集群性
⑤杀虫剂悖论
⑥测试活动依赖于测试内容
⑦没有错误是好是谬论
9.测试发现bug而开发不认为是bug你怎么办？（*****）
①尝试多种测试环境和多种测试方式来确认是否为bug
②整理bug的复现的步骤和出现的频率
③开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
④与客户经理、测试经理、项目经理进行开确认会来判定是否为bug
⑤测试人员需要将bug整理并写入测试总结中
10.开发流程
瀑布模型
螺旋模型
V型模型（********）
W型模型（*******）
