软件测试的过程

软件测试的基本过程

（1）测试人员进行测试需求分析。
（2）测试负责人编写测试计划。
（3）测试人员根据测试需求分析设计和编写测试用例。
（4）测试人员搭建测试环境、创建测试数据、执行测试用例、提交缺陷报告并进行跟踪、记录测试事件。
（5）进行测试评估和总结。每一分步工作完成后都进行评审。

测试人员在软件开发过程的任务

尽可能早的找出系统中的Bug；
避免软件开发过程中缺陷的出现；
衡量软件的品质，保证系统的质量；
关注用户的需求，并保证系统符合用户需求。

如何进行测试需求分析

（1）收集各类文档，仔细阅读文档，提出问题，分析问题或沟通解决，整理需求信息。
（2）编写测试需求分析说明书：功能分解，编写检查点和测试点。
（3）需求评审。

什么是入口准则和出口准则

入口准则是进行一项测试工作前需要准备好的前提条件。

出口准则是一项测试工作可以结束的前提条件。

测试从什么时候开始

软件测试应该在需求分析阶段就介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都测试，并且软件缺陷存在放大趋势，缺陷发现的越晚，修复它所花费的成本就越大。

测试策略与测试范围

测试策略主要指如何进行某种测试（如功能测试、性能测试、兼容性测试、可用性测试、易用性测试等），用于说明测试方法以及如何使用测试方法。测试范围有时候等价于测试策略，有时候可以表示要进行测试的某个软件部位。

测试计划

包含了产品概述、测试区域/测试策略/测试范围/测试目标（测试项、被测特征）、测试配置/测试资源、测试周期、进度安排（测试任务、人员安排）、测试方法/途径、测试交流、风险分析等内容。目的是指导测试过程，规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的责任人以及与计划相关的风险。

如何判断是不是软件缺陷

（1）软件未达到产品说明书标明的功能；
（2）软件出现了产品说明书指明不会出现的错误；
（3）软件功能超出产品说明书指明范围；
（4）软件未达到产品说明书虽未指出但应达到的目标；
（5）软件测试员具体问题具体分析，认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

缺陷产生的原因

需求频繁变更、沟通不良、不了解客户的需求、实现新功能或很酷的功能、追求新技术、项目期限的压力、需求分析或设计投入的时间和精力不够、产品的复杂度、开发人员疲劳、压力过大或受到干扰、缺乏足够的知识、技能和经验、缺乏动力等。

最主要的原因：需求方面的原因

如何确定一个缺陷

根据缺陷的判断原则来甄别发现的问题是不是一个缺陷，发现缺陷后，应该做好分离和再现（3次），然后才能提交。

如何处理无法重现的缺陷

首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。其次，对于寻找难以再现的缺陷要合理地安排时间，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。最后，在测试过程中对未再现缺陷予以关注。

缺陷报告的准则与内容

准则：

Correct（准确）：每个组成部分的描述准确，不会引起误解；
Clear（清晰）：每个组成部分的描述清晰，易于理解；
Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
Consistent（一致）：按照一致的格式书写全部缺陷报告。

内容：

缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息）
预处理
复现步骤
预期结果
实际结果
严重程度
优先级
测试环境
测试版本
测试执行人
注释

缺陷的生命周期

软件测试人员提交缺陷报告；
测试负责人审核后将缺陷报告分配给相关的开发人员修改；
缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测返测通过的缺陷报告由负责人关闭；
返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

测试结束的标志

全部测试用例都执行完成。
未修改bug都被确认或置为应有状态，暂缓修改的问题都有详尽的解释。
测试报告编写完成。
测试收尾工作结束。
测试总结完成。
项目处于试运行或上线阶段
在测试计划中定义结束标准，如计划中规定：系统在一定性能下平稳运行72小时，本版本中没有严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上；实际测试达到上述要求，然后由开发经理，测试经理，项目经理共同签字，认同测试结束，版本即可发布。

回归测试

回归测试:(regressiontesting)有两类：用例回归和错误回归；
用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会不会重新发现问题。
错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。