详细的描述一个测试活动完整的过程

详细的描述一个测试活动完整的过程。

1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后进入项目，开始进行统计和跟踪

2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4. 测试用例完成后，测试和开发需要进行评审。

5. 测试人员搭建环境

6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。

7. 开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。

8. 重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。

9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

一般测试流程：

1.需求分析阶段：只要就是对业务的学习，分析需求点。

2.测试计划阶段：测试组长就要根据SOW(工作说明书)

开始编写《测试计划》，其中包括

人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。

3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《S RS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。

4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。

5.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。

流程：

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→出货。

. 12.软件测试活动的生命周期

测试周期分为计划、设计、实现、执行、总结。其中：

计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；

设计：完成测试方案，从技术层面上对测试进行规划；

实现：进行测试用例和测试规程设计；

执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。

总结：记录测试结果，进行测试分析，完成测试报告。

减少冗余的测试

白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。

在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。减少无价值的测试无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。

如何“偷工减料”有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。

偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见

下表），其它次要部分可以忽略或将来再测试。

“偷工减料”方法的测试优先级：

哪些功能是软件的特色？

哪些功能是用户最常用的？

如果系统可以分块卖的话，哪些功能块在销售时最昂贵？

哪些功能出错将导致用户不满或索赔？

哪些程序是最复杂、最容易出错的？

哪些程序是相对独立，应当提前测试的？

哪些程序最容易扩散错误？

哪些程序是全系统的性能瓶颈所在？

哪些程序是开发者最没有信心的？

测试计划的目的是什么？软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？

答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

大体上来说可分为单元测试,集成测试系统测试验收测试

每个阶段又分为以下五个步骤:

测试计划，测试设计，用例设计，执行结果，测试报告初始测试集中在每个模块上，保证源代码的正确性，，该阶段成为单元测试，主要用白盒测试方法。

接下来是模块集成和集成以便组成完整的软件包。

集成测试集中在证实和程序构成问题上。

主要采用黑盒测试方法，辅之以白盒测试方法。

软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。

单元测试

单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。集成测试

集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。

系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。

验收测试

验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集

回归测试

回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。

针对缺陷采取怎么样的管理措施只是对缺陷的生命周期进行管理和跟踪，Bugzilla或者TD

已经足够了，

1.要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。

2.根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。

3.所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。

4.缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。

5.为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。