测试相关总结

软件测试是为了检验是否满足规定的需求或预期结果与实际结果之间的差别
1.瀑布模型
是其他开发模型的基础，线性执行；当前一个阶段完成后，只需要关注后续的阶段就可以了。

软件测试介入前：1.需求分析：（PM）需求报告文档 2. 设计：(UI设计师) UI设计稿
3.编码：（开发人员）
软件测试：留出足够的排期
缺点：依赖于早期的需求调查，不能适应技术变化和市场变化；产品规划完后可能还没搞清楚产品的规划，研发人员就要受到批评，错误的传递；风险往往后期才暴露；
2.敏捷开发模型

围绕最小化可行产品特性进行规划，循环四个阶段，就可以得到一个可以发布的产品。重复这个过程，做增量式发布，得到了几个Sprint,重复Sprint直到最后构成可发布版本

A.PM Master Team,团队人员经常扮演不同的角色
B.
产品需求列表：从用户故事中筛选出优先项，把他们加入到产品需求列表，会随着sprint的迭代而更改
Sprint代办列表：最优先的用户故事将加入
燃尽图：当燃尽图曲线接近于0的时候，意味此次Sprint即将完工
C.

PM产品需求列表，甄出最优项，交给团队讨论，团队讨论用户故事优先项，决定下次Sprint要研发的项目；根据Sprint制定用户需求列表；研发团队完成Sprint列表中的需求，每日站会用来交流遇到什么问题等，研发出可交付版本；Sprint view,研发团队展示并一起反思

3.软件测试的v模型和w模型特点：a.v模型线性执行，前一个阶段执行完才能执行下一个阶段
b.每个阶段都会形成大量的文档
c.开发周期相对较长，如果返工，时间更长，灵活性较低

实施（系统构建） 交付（验收测试）
特点：a.需求和设计同样要进行测试，对技术要求比较高
b.很多阶段不产生文档，难以进行测试
v模型适用于中小企业的开发，w模型适用于大中型企业的开发

软件测试的流程
1.需求分析
“50%的错误来自于需求的错误，需求分析要注意：没有软件需求文档时，需要测试人员不断的收集原始客户需求；需求不明确的时候，可以将需求追溯至终端客户”
在测试前拿到产品需求文档，进行需求分析及需求评审前先对需求文档进行详细的阅读，对有疑问的地方进行标注。
具体可从以下进行：
a.分析产品功能点 b.产品核心竞争力
2.制订测试用例
工欲善其事，必先利其器；对测试而言，测试用例就是器，做好了才能把好关
a.使用思维导图列举测试大纲，尽量发散，想到什么就写什么，；先放后收，对知识点进行总结和归纳，标记重点测试模块，删除冗余及重复测试点。
b.可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例
c.根据测试大纲制定测试用例，需包含模块名、测试环境、测试优先级、操作步骤、期望结果、实际结果、备注
3.评审测试用例
a.测试作为主导，联合开发、项目经理、PM进行测试用例评审
b.可先讲解测试大纲，让开发、项目经理、PM心中对测试用例有个大概；后再进行详细测试cex用例讲解
4.执行测试
a.根据测试用例执行测试
b.发现问题保留现场，记录测试方法，通知开发解决问题
c.覆盖测试用例之外若有时间可进行探索性测试
5.提交Bug并推动Bug解决
a.在Bug管理工具上提交Bug，详细记录测试步骤
b.根据Bug严重程度划分Bug等级:致命、严重、一般、提示
c.推动开发解决问题，记录问题进展，一般聊天沟通，若问题严重则需通过邮件推动解决
6.回归测试
a.对已修复的Bug进行验证
b.对Bug所在模 块进行基本功能测试；整体进行冒烟测试，确保不会因为修改Bug而引起其他功能出现问题
7.编写并提交测试报告
可使用金字塔原理设计测试报告，先总后分，上级统领下级，下级推导出上级，环环相扣
a.对Bug进行汇总，筛选出各个等级的Bug存活情况
b.制订Bug发现及解决曲线图，一般版本正常应是前期多，后期收敛，存活的是级别较低的Bug
c.总结归纳版本情况，评估发布与否

常见的白盒测试方法

语句覆盖不能准确的判断运算中逻辑关系的错误
判定覆盖一定能满足语句覆盖会忽略条件中取or的关系
条件覆盖是针对中判定中的每个条件都要取一次真假值，但100%的条件覆盖并不能保证100%的判定覆盖
判定-条件覆盖，同时满足100%的条件覆盖和100%的判定覆盖，但判定-条件覆盖会忽略条件中取or（或）的情况
条件组合覆盖不能保证所有的路径都被执行到
路径覆盖

测试类型

单元测试依据代码和注释以及详细设计文档测试，集成测试依据单元测试的模块和概要设计文档测试， 系统测试是根据需求规格说明文档进行的功能、界面、性能、易用性、兼容性、安全性、可靠性测试，回归测试。
冒烟测试一般是开发人员开发完毕送给测试人员测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后序测试；验收测试是部署软件前的最后一个测试，也称为交付测试。

bug的生命周期：发现bug,提交bug,指派bug,确认缺陷，修复bug,回归验证bug,关闭缺陷

性能测试的分类
基准测试：从未做过性能测试，对该系统做一次性能评估作为后序开发调优的参考
负载测试：找到系统的处理极限，为系统调优提供数据
压力测试：在饱和状态下，系统处理会话的能力，以及系统是否会出现错误。

负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

并发测试
配置测试
可靠性测试
失效恢复性测试
大数据量测试