纸杯测试
1、漏不漏水
2、倒开水烫不烫手
3、有没有异味
4、变不变形
5、能不能重复利用
6、有没有毒
7、可存储水量
8、是否可回收
9、好不好用手拿
10、细菌数量
11、底平不平 容不容易倒
12、是否可以盛其他溶液
13、容不容易被捏坏、掉地上会不会坏
1、提交的缺陷开发人员不认可怎么办/h2>
和开发确认对需求的理解有没有歧义，如果理解相同，且确认是缺陷，但是开发不认可，可以找产品经理协商。
2、如何处理不能重现的缺陷/h2>
提交详细的操作步骤，提交日志，如果当时有截图可以一起提交，找开发一起研究
3、如何处理好与开发人员及其他相关人员的关系/h2>
对事不对人，只说关于缺陷的事情，不讨论其他
4、缺陷太多怎么办/h2>
确定缺陷数量，如果超过缺陷数量太多，在关闭版本之前测不完，找测试经理阐述原因，加时间或者是加人。
5、找不到缺陷怎么办/h2>
全面的测试需求文档，保证测试用例以及测试操作覆盖100%需求
6、缺陷得不到及时修复怎么办/h2>
先找开发沟通，看是什么原因，如果是太多bug或者是其他项目太忙，没有时间，可以找产品经理 让他协商一下换人还是加时间
7、如何处理缺陷级别定义之争/h2>
看公司对测试级别定义的文档
8、如何处理缺陷跟踪中的扯皮现象/h2>
把有争议的地方说明，然后让相关人员一起讨论，或者无法确定责任人 可以让开发经理协商处理
缺陷产生原因
- 产品说明书不全，不完整和不准确，修改频繁，沟通不畅和
理解不同； - 软件设计过程中考虑不周到，片面，多变，理解和沟通不足；
- 文档不足，压时间，赶进度，设计和编码错误都会引入缺陷；
- 测试和实施过程中安装环境配置错误等。
缺陷的评价标准
? 软件未实现需求规格说明书（SRS）要求的功能
? 软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标
? 软件出现了需求规格说明书（SRS）指明不应出现的错误
? 软件实现了需求规格说明书（SRS）未提到的功能
? 软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好
致命：1 主要功能完全丧失，系统崩溃死机
严重：2 主要功能部分丧失，次要功能完全丧失，数据不保存
一般：3 次要功能没有完全实现
轻微：4 易用性
优先级跟严重程度是相关的，一般越严重的单子优先级越高
bug生命周期：相关人员，状态、流程（正常流程、异常流程）
状态说明
- 新建：测试人员提交新问题标识的状态。
- 打开：已经确认为是Bug的状态。
- 已修复：为开发人员修改问题后所标志的状态，等待测试验证。
- 重新打开： 测试人员对修改问题进行验证后没有通过所标志的状态或者已经
修改正确的问题又重新出现错误，由测试人员改变。 - 已关闭：为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。
- 拒绝：开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意
见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试
人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。 - 重复：表示该Bug已经被其它测试人员找出来了，或者开发认为原因是相同
的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
文章知识点与官方知识档案匹配，可进一步学习相关知识CS入门技能树Linux进阶新增用户25111 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！