D_yingying的博客

测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。打开思维后，设计测试用例是想到一条就说一条，如果没有正确的引导，说出来的测试用例一定是有限的且数量不容乐观的。针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载。（WIFI、5G、4G、3G、2G）（引导的作用，帮助大家按照分类来设计测试用例）传输1KB到远程服务器需要300ms的时间（慢）界面测试：协议界面、注册界面、激活界面、登陆界面。

描述bug的基本要素:问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果（包括但不限于，这些只是必须的）bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序猿。反省自己:是不是在测试的时候出现了误操作、bug描述是不是没有写清楚。bug评审需要有三个代表:测试代表、开发代表、产品代表。功能正常只是测试的一部分，还需要考虑用户的使用感受。入职之后，公司/团队会提供“bug级别描述文档”2)分析缺陷产生的原因，找出预防的对策。测试小白:更多的是提出问题(bug)

同时，对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施，显著减少总体测试时间，加快项目进度。需求的开始是软件生命的起点，中间会经历需求的计划、设计程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的重点。缺点:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。:测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。规范的流程是在时代的演变下逐渐成型，并不是一开始就是规范的流程。引入的目的是减少各阶段遗留的风险问题，避免把问题留到后面的阶段。