基础篇—软件测试

1.软件测试的生命周期（软件测试的流程）

需求分析-测试计划-测试设计/开发-测试执行-测试报告（总结）

1.1需求分析

分析，验证需求的正确性和合理性；细化需求，从需求中提取测试点；为编写测试用例做准备

1.2测试计划

测试人员、测试时间、测试工具、测试数据、测试目的、测试范围

1.3测试设计/开发

开发/编写测试用例

1.4测试执行

软件测试、执行测试用例、发现bug，提交bug、验证bug

1.5测试报告（总结）

进行测试总结和分析、测试范围和测试的功能模块、测试写了多少测试用例、执行了多少、剩余了多少、发现了多少bug、开发修改了多少bug、剩余bug的解决方案（有风险）

2.如何描述一个bug

bug管理系统：记录bug的状态（禅道、JIRA、tapd）
（1）问题出现的版本：版本的标识也有利于统计和分析每个版本的质量；开发人员需要知道出现问题的版本，才能够获取对应版本的代码来修改故障
（2）测试环境：详细的环境描述有利于故障的定位；分硬件环境和软件环境；如果是web项目，需要描述浏览器版本、客体机、操作系统等；如果是APP项目，需要描述机型、分辨率、操作系统版本等
（3）测试数据：问题出现的数据
（4）测试步骤：描述问题出现的最短步骤
（5）错误结果：描述错误的现象
（6）预期结果：给开发人员正确的指导，以用户的角度描述程序的行为
（7）附件、截图、错误日志等

3.bug的级别

3.1崩溃

系统已经无法运行，严重阻碍了测试和开发工作（造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题）

3.2严重

系统可以运行，但是不稳定，继续运行，会造成严重的问题

3.3一般

不影响系统的稳定运行，次要的功能没有实现或者有错误

3.4次要

建议性的bug，系统的基本功能都已实现，只是影响用户的体验

4.bug的生命周期

（1）New：新发现的Bug，未经评审决定是否指派给开发人员进行修改
（2）Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员
（3） Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
（4）Rejected：如果认为不是Bug，则拒绝修改
（5）Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
（6） Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug
（7） Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改

5.如果因为一个bug和开发人员产生冲突怎么办

（1）先检查自身，看是否把bug的描述清楚
（2）尝试站在用户角度去考虑问题，让开发人员了解到bug肯对用户造成困扰。去说服开发人员
（3）作为测试人员，不断提高自己的水平，包括技术水平和业务水平，不光要提出问题，最好也能给出解决方案
（4）bug定级要有理有据
（5）找产品经理（项目经理）一起商讨问题的解决方案