Blog

在一轮测试或者整体测试结束后，测试人员都需要编写测试报告或者缺陷报告来作为这一次测试的总结性文档，以便开发人员、项目经理、测试组人员及QA等其他部门人员了解本次测试结束后的一些相关情况。 有些公司会把缺陷报告和测试报告分开来写，这要看具体公司的一些项目流程上的计划安排。 单独的缺陷报告是统计本次测试所发现的BUG数，包括本轮BUG总数，每个模块的BUG数，几轮测试的BUG趋势图，每个开发人员名下的BUG数等等，那么有些公司也会把缺陷报告里的这些内容写到测试报告里，其实是一样的。 测试报告里除了描述测试报告的目的，背景，时间进度，测试环境外，最重要的是测试过程评估和测试对象质量评估。时间进度描述实际完成测试的测试开始时间，测试结束时间等等，测试环境描述实际完成测试的硬件环境、软件环境和网络环境。 测试过程评估主要描述在该轮测试或者整体测试的过程中，测试人员是怎么进行测试执行的，遇到过什么样的问题，是如何解决的。 测试对象质量评估主要描述测试人员在结束该轮测试后对被测对象的质量评估，比如某个模块的BUG数，某个模块不是很稳定之类。

在项目需求分析结束之后，开发部会进行概要设计、详细设计，而测试部则需要为了后续的测试用例，编写整个项目的测试计划；每个公司的测试计划的模板都不一样，测试流程也不会一样，大型公司的项目周期相对较长，较稳定，故采取计划驱动的方式来编写测试计划会更适合，而中小型公司则更适合敏捷开发，如极限编程； 项目测试计划一般包括几个大点:目的、背景、范围、时间、测试对象、人员进度安排、测试环境、测试方法、测试工具、风险分析等等； 目的：描述该份测试计划文档的目的 背景：描述测试项目的背景 范围：描述测试项目的测试范围，功能点或者模块 时间：描述测试项目的预期测试开始时间和预期测试结束时间 测试对象：描述测试项目的测试对象，如具体是整个项目的使用模块还是具体哪几个功能模块 人员进度安排：描述本次测试项目下，测试人员的安排，如哪个测试人员负责的功能模块和测试任务（如编写测试用例或报告等），还有测试人员时间的进度安排 测试环境：描述本次测试项目的硬件环境、软件环境、网路环境 测试方法：描述本次测试项目所需要用到的测试方法，如黑盒，白盒，灰盒，性能，自动化等等 测试工具：描述本次测试项目在测试过程中会需要用到的测试工具 风险分析：描述在本次测试项目的测试过程中可能会出现的一些风险（如需求变更，人员更换，硬件性能不满足要求，技术人员技术达不到需求等等），并对这些风险做规避措施；

现在的软件公司都在使用着不同种类的缺陷管理工具，如Bugzilla、Bugfree、TD、notes(IBM)等；其实这些工具都是千篇一律，其主要的功能就是将在系统或软件中所发现的BUG有条理的进行管理，方便测试人员和开发人员进行BUG的修复和验证。 和大家分享一下BUG缺陷管理的基本流程： 1. 当开发人员发布软件版本后，测试人员进行冒烟测试，测试通过后则开始进行系统测试或功能测试，这要看软件的计划流程是怎样; 2. 测试人员在测试中发现异常现象，确定为BUG后，将其提交至缺陷管理工具，这时该BUG的状态为new; 3. 测试经理或负责人审核该BUG，确认是问题后，将该BUG状态修改为open，并将该BUG负责人修改为项目开发经理； 4. 项目开发经理将该BUG分配给所属模块的开发人员，该开发人员确认该BUG是否为需要修改的BUG，或不认为是BUG，或该BUG已重复提交，或该BUG可以延后修改，或该BUG不能重现，或该BUG可以没必要修改等等，开发人员将该BUG状态修改为won’t fix/fixed/duplicated/can’t reproduce/rejected等，并将该BUG负责人修改为该BUG提交测试人员 5. 该BUG提交测试人员根据该BUG当前状态进行相应操作，如fixed则进行回归测试，测试通过后，将BUG状态修改为closed;如won’t fixed或duplicated或rejected，经确认后将该BUG状态修改为closed 不同的缺陷管理工具中BUG的状态内容可能会稍有出入，但大体都是一致的，测试人员根据BUG的具体状态进行对应的操作，如回归BUG，确认BUG，重现BUG，关闭BUG等等；

现代社会离不开软件。 国家基础设施和公共建设都是由基于计算机的系统控制，大多数的电子产品都有计算机和控制软件。工业制造和金融系统已经完全计算机化了。娱乐业，包括音乐产业、计算机产业、电影和电视产业，也都是软件密集型的产业。因此，软件工程对于一个国家和整个国际社会的运转都是必不可少的。 现在仍有很多有关软件项目出问题和“软件失败”的报道，除开软件测试遗漏的一些致命性或严重性或严重影响用户体验的问题外，软件工程因不能充分支持现代软件的开始而遭非议。然而，在我看来，这些所谓的软件失败主要源于以下两方面的原因： 1) 不断增长的需求：由于新的软件工程技术可以帮助我们构建更大更复杂的系统，用户的需要因而在发生改变。系统必须更快速地构建并交付；需要更大更复杂的系统；系统必须具备在以前看来不可能实现的功能。现有的软件工程方法已经不能应对新形势，而新的软件工程技术还有待于进一步发展。 2) 期望值太低：不采用软件工程的方法和技术区编写计算机程序相对来讲要容易一些。很多公司因为他们的产品和服务在逐步发展而在软件开发中随波逐流。他们通常不使用软件工程方法，结果导致他们的软件比预计的费用高且不可靠。 因此我们需要更好的软件工程教育和实践来解决此类问题。