软件测试
验证软件功能是否满足用户的需求
测试和调试的区别
目的不同
测试的任务是发现程序中的缺陷，调试的任务是定位并且解决程序中的问题；
参与角色不同
测试主要由测试人员和开发人员来执行(黑盒测试主要由测试人员来完成，单元测试和集成测试主要是由开发人员来完成)，调试主要是由开发人员完成；
执行阶段不同
测试贯穿整个软件开发的生命周期，调试一般是在开发阶段。
好的测试方案是极可能发现迄今为止尚未发现的错误的测试用例；而成功的测试是发现了迄今为止尚未发现的错误的测试。测试不仅仅是为了找出错误，而是为了分析错误产生的原因，阶段及错误发生的趋势。没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
第一：帮助项目管理者了解当前软件开发过程中的缺陷，以便及时纠错，改进；
第二：帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；
第三：让开发人员知道错误产生的重灾区，加强自测试；
第四：让客户清楚专业的质量保证，提交一份满意答卷。
软件测试的目的和原则
目的：验证软件有或者没有问题
原则：以客户为中心，遵循软件测试的规范，流程，标准和要求
在大多数软件公司会有两部分需求：用户需求，软件需求
IEEE定义，软件需求是用户解决问题或达到目标所需条件或权能；系统或系统部件要满足合同，标准，规范或其他正式规定文档所需具有的条件或权能；是一种上面所述条件的文档说明。包括功能性需求及非功能性需求
软件需求是测试人员进行测试工作的基本依据
简单举例说明一下用户需求和软件需求：
小明周末回家，针对小明饿了，吃饭的问题
用户需求：小明饿了，要吃饭
中间过程：小明的妈妈需要和小明进行反复的沟通交流，确定解决方案–吃啥饭，最后了解到想吃米饭
软件需求：研究买什么样的米，怎么做可以更好吃等等
不是所有的需求都是正确的，如：有一个声控灯，不要从设计人员的角度说一下对这个灯的需求。那么首先你知道这个灯是安装在哪里的吗，安装地点不知道的话就无法去对声控灯进行需求分析。
软件测试的生命周期
需求分析–测试计划–测试设计，测试开发–测试执行–测试评估
软件测试和软件开发的生命周期
需求分析
测试人员了解需求，对需求进行分解，得出测试需求
计划阶段
根据计划编写测试计划或方案
设计阶段
测试人员了解设计，搭建测试用例的框架，根据需求和设计编写一部分测试用例
编码阶段
测试人员不加入到编码阶段，对于已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善，细化测试用例以及调整测试计划和方案
测试阶段
根据测试用例和计划执行测试，在执行过程中记录，管理缺陷，测试完成后编写测试用例
运行维护阶段
测试人员需要参与项目的实施工作，参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人
说了这么多，那么bug到底是什么呢？
当且仅当规格说明是存在的并且正确，程序和规格说明之间的不匹配才是错误；
当没有规格说明书时，当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
bug的合格描述
发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障
问题出现的环境
环境分为硬件环境和软件环境，详细的环境描述有利于故障的重现(如果是web项目，需要描述浏览器版本，客户机操作系统等；如果是app项目，需要描述机型，分辨率，操作系统版本等)
错误重现的步骤
问题出现的最短步骤
预期行为的描述
需要开发人员指导怎样才是正确的，以用户角度来描述型为是怎样的
错误行为的描述
描述错误的现象
其他
比如：故障分类，优先级分类
不要把多个bug放在一起
定义bug的级别
Blocker(崩溃)：阻碍开发和测试工作的问题，造成系统崩溃，死机，死循环，导致数据库丢失，与数据库连接错误，主要功能丧失，基本模块缺失的问题
Critical(严重)：系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试；功能设计与需求严重不符，模块无法启动或调用，程序重启，数据库死锁，重要的以及菜单不能使用
Major(一般)：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性
Minor(次要)：界面性能缺陷，建议类的问题，不影响操作功能的执行，可以优化性能的方案
bug的生命周期
New：发现新的bug
Open：确认是bug
Fixed：修改后的bug标识
Rejectd：如果认为不是bug就拒绝修改
Delay：认为此bug暂时不需要进行修改
Closed：通过回归测试通过，关闭bug
Reopen：经验证bug仍然存在，需要重新打开bug，进行重新修改