大多数软件测试工作中，常见的问题原因分为以下几类：
不同版本的数据兼容
这是最常见的问题，一般新版本的迭代不仅仅是代码层面的，还有数据库的改动，而对于线上原有的数据来说改动了数据库有可能会受到影响。
比如：如果数据库增加了一个字段，那么新数据肯定会通过新的程序给这个字段赋值，而原有的数据这个字段往往是空的，这时读取该数据就会发生问题。
当然这只是一个最简单的情况，这种情况在测试环境可以用历史数据进行测试从而发现该问题。但往往还有更多复杂的情况，有时候是需要手动造数据库的数据来模拟数据兼容的问题。这个就是测试比较容易忽视，也最容易发生问题的一个点。
测试环境和正式环境的不同
测试环境和正式环境的不同也是一种经常发生的事情；
不同分2种情况：
硬件方面的，一般正式环境的服务器都比测试环境来的好，所以硬件上不太可能一致，虽然这个差异影响比较小，但也不排除会影响程序的运行。
软件方面的，包括程序语言的版本，服务器系统的版本，甚至服务器的权限控制都会影响到程序的运行。如果说不同版本的数据兼容问题可以在测试环境预判并测试，那这种情况可能只能做到提醒开发和运维人员了，硬件方面没办法，软件方面尽量做到一致，以减少测试环境和正式环境的差异，让正式环境上的程序跑的更加稳定。
服务器的配置
这个不同于上面说的程序语言版本，而是在代码层面的配置：
配置文件，包括代码的相对路径，某个功能的开关，又或者是服务器ip的配置等等。而这些都是相对于测试环境配置的，如果发布的时候将配置文件覆盖也会导致正式环境出问题。
服务器上配置的crontab脚本，很多程序是需要通过crontab脚本定时执行，而crontab又是需要在服务器上配置的，自动配置不方便控制及维护。所以大多数还是需要人为去配置的，这个配置如果漏了或者配置错也会导致出问题。
例如：正式环境多台服务器有一台服务器代码未更新，导致问题时隐时现。数据库的主备数据不一致，当切换主备数据库后会出问题。
所以好的测试不能只把目光放在代码层面的测试，而是要从更高的视角去看整个项目在上线发布的时候存在的各种风险。有些可以通过测试而发现出来，而更多的还是要提醒开发和运维人员去规避这些上线的风险，我想这才是好的测试人员应该做到的事情。
软件bug管理的目的
1）保证信息的一致性；
2）保证缺陷得到有效的跟踪和解决，缩短沟通时间，解决问题更高效；
3）获取正确的Bug信息，利于缺陷分析、产品度量，使项目情况可视化加强。
缺陷的严重程度(Severity)
是站在用户的角度，指Bug出现后对用户和系统的影响程度。
软件缺陷的严重性指软件缺陷对软件质量的破坏程度，即软件缺陷的存在对软件的功能和性能产生怎样的影响，我们可以简单地将软件缺陷的严重性划分为4个等级：致命、严重、一般、提示。
1）致命缺陷：例如软件的意外退出甚至操作系统崩溃，造成数据丢失。
2）严重缺陷：系统无法满足基本的商业要求且没有便捷可用的工作区。性能、功能或使用方面严重不达标，例如由于单功能失效引起多个功能失效。
3）一般缺陷：系统能够满足商业要求。有快捷方便的工作区可供使用。性能、功能或使用方面并不是严重不达标，例如软件单个功能失效。
4）提示：微小修改，希望提出建议，最好能够修正，但不是必需的。在发布准确性或实用性方面不会产生重大影响
软件bug（缺陷）的相关属性
1、缺陷发现人
在提交缺陷的时候，测试人员一般是测试的发现人，便于统计分析测试人员的能力，方便公司进行绩效考核。
2、缺陷发现时间
缺陷发现时间是一个统计的计数点，或者数据点，便于企业负责人选择合适的产品发布时间。
3、软件缺陷的状态
1）New：缺陷的初始状态（发现问题，提交问题，提交问题后，这个缺陷就处于New的状态）
2）Open：开发人员开始修改缺陷（测试人员提交问题，开发人员接受并开始修改问题）
3）Fixed：开发人员修改缺陷完毕
4）Closed：回归测试通过（测试人员进行回归测试，回归测试通过，该问题改为Close状态）
5）Reopen：回归测试失败（测试人员进行回归测试，回归测试不通过，该问题改为Reopen状态）
6）Postpone：推迟修改
7）Rejected：开发人员认为不是程序问题，拒绝缺陷
8）Duplicate：与已经提交的Defect重复
9）Abandon：被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态
比较理想的缺陷流程：从new状态——>open——>fixed——>closed状态。
4、缺陷的类型
1）从质量特性角度考虑有功能、性能、安全性、易用性、可靠性缺陷；
2）从功能性角度考虑有：错误（Errors）、遗漏（Missing）、多余的（Extra）、可优化的（Improvement/Enhancement/Suggestion）缺陷；
3）从缺陷产生的原因考虑有：需求规格说明书SRS、设计问题、编码问题、需求变更、设计变更、配置问题、测试问题。
更多缺陷管理推荐阅读：
缺陷分析中缺陷预防的作用 学会使用缺陷管理系统进行缺陷分析
bug管理工具能满足软件开发者的哪些需求？
如何做好一个软件项目的缺陷管理?
软件开发过程中bug是怎么产生的？bug管理的流程有哪些？
软件开发管理中如何做缺陷跟踪？缺陷跟踪管理流程及注意事项
好用的Bug管理工具该具备哪些功能？
缺陷管理工具在软件项目中作用是什么？
Bug管理系统的使用及管理流程要注意的重点
怎么进行测试缺陷分析？常见的缺陷分析方法有哪些？
缺陷管理方法之几种常见的软件缺陷预防方法
sales@spasvo.com
