一、需求分析、评审
（1）需求分析
对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。
①如何做需求分析？
通读需求，对需求有个大致的了解，比如：
软件有哪些模块、每个模块的大致功能
哪些需求是新增、哪些需求是在原有需求上做了修改
将需求分成多个模块（包括子模块）
根据每个模块的需求规格说明书，详细阅读，并挖掘出测试点
②分析方法
（2）需求评审
二、制定测试计划
测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档。
测试计划一般都是由测试经理或者是该项目的测试负责人。
测试计划内容：
三、编写测试用例（测什么，怎么测，如何衡量）
（1）参考文档
需求规格说明书
用户操作手册
开发文档
（2）内容
（3）测试用例的作用
便于理清测试思路，确保需覆盖测试的功能点无遗漏
在执行测试之前，可以充分考虑各个测试点
便于测试工作量的评估
写了多少用例
执行了多少用例
便于提前准备测试数据
便于把控测试工作进度
便于回归测试
便于测试工作的组织，提高测试效率，降低测试交接成本
用例由经验丰富的编写用例
工作交接
（4）注意事项
四、测试用例评审
用例评审内容：
1、测试用例是否按照公司定义的模板进行编写的。
2、测试用例的本身的描述是否清晰，是否存在二义性。
3、测试用例内容是否正确，是否与需求目标一致。
4、测试用例的期望结果是否确定、唯一的。
5、操作步骤应与描述是否一致。
6、测试用例是否覆盖了所有的需求。
7、测试设计是否存在冗余性。
8、测试用例是否具有可执行性。
9、是否从用户层面来设计用户使用场景和业务流程的测试用例。
10、场景测试用例是否覆盖最复杂的业务流程。
11、用例设计是否包含了正面、反面的用例。
12、对于由系统自动生成的输出项是否注明了生成规则。
13、测试用例应包含对中间和后台数据的检查。
14、测试用例应有正确的名称、编号、执行的优先级。
15、测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等。
16、每个测试用例步骤应<=15 Step。
测试用例的粒度合理，不要太大也不要太小；太大无法体现工作量，执行起来也不方便；太小显得冗余。
17、非功能测试需求或不可测试需求是否在用例中列出并说明
五、执行测试
（1）测试执行过程
（2）怎样执行好用例？
1、精确定位BUG，即逐个排除环境问题、操作问题，确认BUG确实存在，排除自己疏忽或操作不正确造成的“假缺陷”。能够判断缺陷是否是假缺陷；还要能够分别，该缺陷是哪个模块造成的，以便提交给正确的开发处理
2、能够清晰描述出所遇到问题的情况，并且将在不同状况下是否会遇到同样的问题，准确描述给开发。
3、规范bug报告内容，逻辑清晰，简单明了，不对bug做评价。及时和开发做沟通，了解修改BUG的进度。
4、需求没有明确说明的缺陷，跟产品经理进行确认，不要跟开发争辩。
5、某一缺陷优先级、严重性等，开发和测试无法说服对方，向上反馈或找产品经理确认
6、不要为了引起开发人员的重视而夸大缺陷
7、小的缺陷也要报告
8、及时报告缺陷
9、不可重现的bug（偶发性缺陷）也要报告
缺陷发现的时间：越精确越好，以便开发通过日志来分析原因
描述清楚缺陷发现时的环境
使用的数据
使用的操作系统
浏览器
网络情况
服务器当时的使用情况
描述清楚操作步骤，包括截图
六、提交和定位缺陷
（1）产生的原因
（2）缺陷判断规则：
①软件未达到产品说明书标明的功能；
②软件出现了产品说明书指明不会出现的错误；
③软件功能超出产品说明书指明范围；
软件不能画蛇添足，要严格按照需求进行开发
④软件未达到产品说明书虽未指出但应达到的目标；
根据生活常识就应该遵守，这种情况下需求没说，也必须满足
⑤软件测试员从用户的角度认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
只要觉得自己有根据有合适的理由，都可以提出一个缺陷。
（3）缺陷报告内容
（4）提交缺陷的注意事项
1、精准定位
2、缺陷描述清晰明了，一定要有截图
3、不可夸大缺陷
4、小缺陷也要报告
5、不可重复的缺陷也要提交
6、要及时提交缺陷
7、缺陷严重程度等不确认时可同项目经理、产品相关人员进行沟通。突出沟通的重要
（5）高质量的缺陷报告应要确保大家都能看得明白，根据缺陷报告，能够知道缺陷内容、能够重现该缺陷，它应该有以下特征：
缺陷描述清晰，明了，一定要有截图；要描述测试时的环境，用的浏览器，操作系统，网络情况；要有测试数据；要有预期结果和实际结果；缺陷优先级和严重程度合理；精准定位缺陷，尽量避免提交给错误的开发。
七、跟踪缺陷
当测试人员发现bug以后，此时bug的状态是新建，如果不知道该模块是谁开发的，则提交给开发经理，由开发经理指派给对应的开发，如果知道是谁开发的，直接将将该bug提交给相应的开发人员，如果开发人员不认为是个bug，则将bug打回给测试，并进行相关的说明，如果开发认为是个bug，会将bug的状态改为已确认，如果开发在修复这个bug的时候，会将bug的状态改为修复中，当修复完成以后，会将bug的状态改为已修复，并且指派给测试，此时测试人员进行回归测试，如果确实已经修复完成了，则将bug的状态改为关闭，如果没有修复，则重新指派给相应的开发，状态改为重新打开。基本上保证所有的bug的最终状态是关闭或者是延期。
八、编写测试报告和总结报告
迭代测试
一个产品先开发出初始版本（V1.0），然后再以固定的周期，在该版本的基础上的添加新的功能，或者完善已有的功能，从而生成一个新的版本
将每个小周期称为依次迭代
每次迭代的过程也是一个传统的开发和测试流程
功能发布
总结
软件测试-工作流程（需求分析评审 测试计划 测试用例 用例评审 执行测试 跟踪定位bug 测试报告 缺陷报告）
如果觉得《软件测试-工作流程（需求分析评审 测试计划 测试用例 用例评审 执行测试 跟踪定》对你有帮助，请点赞、收藏，并留下你的观点哦！
