首先（项目经理，产品经理，测试经理）确定项目---产品经理提供产品PRD-----需求人员提供需求文档----（开发，经理）经行需求评审
然后，开发和测试同时进行，也就是实现了w模型
开发人员：概要/详情设计---编码----（开发环境）自测----（测试环境）提交测试
测试人员：测试计划----编写测试用例------进行用例评审----冒烟测试-----功能测试---禅道提交bug---对bug进行跟踪记录---回归测试-----验收测试（生产环境）
最后提交，提交材料 ----- 上线
编号、日期、设计和测试人员、优先级、标题、目标、环境、输入苏韩剧/动作、预期结果
1.概述 1.1编写目的 1.2 项目背景 1.3项目质量目标 1.4预期读者 1.5参考资料 2.测试环境 2.1系统架构 2.2软硬件环境要求 2.3测试环境部署图 3.测试规则 3.1测试范围 3.2测试工具 3.3测试人员、角色及职责 4.测试策略 4.1系统框测试 4.2业务流程测试 4.3功能点测试 4.4UI界面测试 4.5性能测试 4.6兼容性测试 4.7安全测试 5.测试进度安排 6.工作汇报
A.Bug的优先级 B.Bug的严重程度 C.开发的接口人员，Bug产生对应的软件版本 D.Bug可能属于的模块。如果不能去顶，可以有开发人员来判度 E.Bug标题，需要尽量给出新的Bug步骤 F.Bug描述，需要经量给出新的Bug步骤 G.Bug附件中能给出相关的日志与截图
测试中，我们经常遇到这样的问题，提交了个bug，开发却回复won‘t fix ，竟然说不是bug
什么bug会让开发认为不是bug？
1、测试人员描述不清晰
体现在步骤描述上有歧义，开发无法按照描述准确的复现步骤，导致可能对问题的描述理解上出现偏差
解决方法：修改bug描述步骤：做到清晰描述、无重复、无冗余，尽量附截图，截图重点位置，用红色标记，截图名字尽量符合截图内容
2、难以复现的bug
有的bug是偶现bug，难以按同样操作步骤复现&有的bug只是在测试环境出现，线上就正常了
解决方法：
难以复现的bug：保存截图和log；尽可能详细的描述进行过的操作，像我们之前测试的棋牌的项目，经常出现卡死，这样的要提供4个玩家的log，因为无法确定是否是其他玩家进行的操作，引起的bug，这种我们就尽量用真人去玩了，更容易发现问题，机器人的话，无法提供机器人log日志
测试环境下出现bug：找研发在测试环境下确认，报告中指出风险
3、有争议的bug
多出现在建议类型的bug，测试人员在测试过程中会对根据经验或者对比竞品提供一些优化的建议，这一类bug特点需求上没有详细给出，肯定开发是没有做的
解决方法：是否需要修改要根据项目的实际需要进行确认，开bug评审会，讨论解决
在时间允许的情况下，项目测试收尾时，对buglist是否修复进行明确处理；时间比较紧产品又认为有修复必要的情况下，可能会延期到下期
4、功能性bug
与需求不符、与原型设计不符。开发对需求没有深入了解可能会忽略或者弄错功能；开发成员之间沟通上的偏差
解决方法：
提bug时把需求、设计相关内容截图，指出依据，避免麻烦
5、当然也会有误提的情况
测试人员对需求理解不明确、出现偏差；环境错误
解决方法：
反复理解需求、确认需求和环境
通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参，响应。
请求接口url是否正确
如果请求的接口url错误，为前端的bug
传参是否正确
如果传参不正确，为前端的bug
请求接口url和传参都正确，查看响应是否正确
如果响应内容不正确，为后端bug
也可以在浏览器控制台输入js代码调试进行分析
如果定位为后端的bug，可以进一步通过以下方法精确定位是哪里出bug
查看报错日志，通过日志分析问题点
查看数据库确认数据的正确性
查看缓存是否正确
A.首先考虑环境问题，看是否能够还原原来的环境
B.遇到问题就提，不能放过一个Bug，再提交前在测试报告中席上复现的概率
C.尽量回想发生问题时的复现步骤，最后再按照组合尝试复现
D.与开发人员配合，让开发人员对相应的代码检查，看是否能通过代码层面检查出问题
按阶段分
单元测试
集层测试
系统测试
验收测试
按是否运行
静态测试
动态测试
按是否查看源代码划分
白盒测试
黑盒测试
功能测试
逻辑功能测试
界面测试
易用性测试
安装测试
兼容性测试
性能测试
一般性测试
稳定性测试
负载测试
压力测试
其他
回归测试
冒烟测试
随机测试
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。 灰盒测试 灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
get delete put post head peach
1.缺陷集群性 2.穷尽测试 3.测试需要尽早的测试 4.对一个测试用例不能重复执行多次，否则软件会对产生免疫 5.测试显示软件存在缺陷
1.Get是不安全的，应为在传输过程中，数据被放在请求的URL中，Post的所有操作对用户来说都不是可见的 2.Get传输的数据小，这主要是应为url长度受到限制，post传输数据较大 3.Get限制Form表单的数据集的值必须为ASCLL字符而Posy支持整个ISO10646字符集 4.Get执行效率却比Post方法好。Get是form提交的默认方法。
原文：https://www.cnblogs.com/PythonDaniu/p/14955351.html