软件开发技术基础-长城开发精密技术

文章目录

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）找产品经理（项目经理）一起商讨问题的解决方案