软件测试的流程建议.doc

软件测试的流程建议以及现阶段问题的分析 *简介：以下内容包括测试流程的设计，测试各个要素的说明，现象的比较和问题的分析，质量管理软件的说明，责任的承担问题，测试周期的估计，软件测试工程师的素质要求，文档的重要性以及相应参考文档。* 回归测试流程测试各个要素的说明测试所涉及到的文档，工具，环境，程序都很多，其中的要素也很多，但是整个测试过程中的元素应该是一个有机的整体，而不是分散的个体。测试计划要素：1. 测试各个阶段的安排；2. 可以利用到的资源，如测试程序，测试时间，测试工具，开发文档3. 涉及到的所有文档，以及各个文档程序直接的关系4. 规定了各个文档中描述的规则，要求，目的以及增加和修改案例等流程的标准步骤。5. 对应测试对象，BUG等级的制订。它是整个测试过程必须依据和遵守的文档。测试执行阶段：1 单元测试：测试接口所有API，分正面测试和反面测试，正面测试主要验证函数是否能正常运行，反面测试测试函数的冗错性和健壮性。2 集成测试：测试各个函数接口直接的输入输出关系，以及各个模块是否可以正常运行，是终端各个外设的功能性测试，同样分为正面和反面的测试。3 系统测试：终端整体运行的测试，类似于应用程序的测试，可利用脚本做流程控制。同样需要简单的正反测试。4 压力测试：即负载测试，比如连续运行函数或者该设备，或者该功能，涵盖了以上三种。测试顺序从14，按照过程的重要性分类。回归测试说明：对已发布使用的版本，在维护阶段发现的问题，进行的再测试。测试执行要素：1 测试环境2 测试对象3 测试用例4 测试程序5 测试数据6 测试报告7 测试人员它是测试的重要执行部分。测试用例要素：1 对应的测试程序的描述。2 测试对象，环境的描述。3 用例的版本信息。4 测试内容描述。5 测试项分类。6 每个测试项的测试目的，测试步骤，测试结果等描述信息。7 BUG信息，等级分类等。8 相关性文件链接。9 演示模板，用以新手参考。它是测试操作的重要依据。测试程序要素：1 可执行文件2 源代码3 设计文档4 测试脚本5 操作文档6 版本控制它是观察对应测试对象的程序。对于测试用例和测试程序哪个先作，个人认为应该现写测试用例的描述部分，即各个测试项的目的和方法，测试程序按照测试描述编写，最后测试用例的测试步骤部分按照测试程序的操作文档编写。测试环境要素：1 温度，/包括是否用空调2 地点，/准确位置，经度纬度。3 时间，/标准时间4 辅助工具测试对象要素：1 硬件信息，各个版本号，出厂日期2 软件信息，版本号，发布日期3 开发人员，包括姓名，部门，联系方式测试人员要素1. 人数2. 个人信息3. 状态测试数据要素1 配置参数2 脚本参数3 输出数据/通讯包，显示返回4 打印单据等信息它是测试过程中的I/O。测试报告要素1 测试对象环境等描述。2 测试过程参考用例以及程序描述。3 测试结果描述，BUG等级，分析。4 测试执行的时间周期。它是版本发布的记录，以及维护出现问题反查的依据。针对了各种测试结果，分析，发给对应的开发人员。如果使用CVS来控制版本，需要记录上传的项目标签。测试总结：对整个测试过程的总结和分析，发给项目负责人用于备档。现阶段测试状况与期望的比较#Item现在的状况期望状况测试流程当有版本需要测试的时候，直接找用例和程序进行测试。按照标准的流程步骤，紧而有序的进行对应版本的测试。并填写对应的文档。单元测试有API的测试用例，和程序，但是没有完整的要素，和对应的文档，无法很快了解测试的方式。独立一套的用例和程序，对应完整的要素，测试人员非常容易操作测试并记录测试结果。除了传统的完全人工测试，增加脚本控制的测试，并对用例进行分类和细化。集成测试有测试程序，暂时没看到用例，可能有，同样的各个要素不完整。用脚本文件来控制函数调用关系和流程。完整的文档机制以及测试要素。对测试结果有PC的工具做分析和反查。系统测试没有单独的测试程序来测试，也没有对应的用例。有比较通用的实际应用来做系统测试如EDC，并且提供详细的测试案例，不同于应用的UAT，因为不是测试应用程序的功能，而是底层库的功能。压力测试在单元测试的用例体现出来，没有单独的测试流程。单独的流程，做负荷压力测试。脚本自动化测试，并自动回传测试结果。回归测试不清楚。细化测试流程，需要在实践中进一步的总结和优化。测试文档不完善，似乎就没有详细的测试计划，和测试总结，测四报告没有参阅过。完整的文档机制，控制整个测试的流程。测试程序现在阶段API测试程序（P90），有不少错误，我在重新优化和整理。其他的不知道。与用例紧密对应，每个测试程序的功能要有特点，能够迅速反映出问题。如测试应用交易，可以考虑直接下文件到终端，发对应的包，等等。测试用例主要是开发人员编写。主要是测试人员根据需求和设计的接口编写，开发人员做补充，2者一起审核，并由测试人员发布，升级。测试工具不完善，工具不够针对性，非专业测试工具。开发必要的工具，或下载一些辅助性工具。完善测试环境。测试环境似乎满足测试需求的环境都有，但是不完善。需要相关文档统计和描述所有的测试环境，需要针对性的测试环境，需要可以迅速恢复或搭建一套测试环境的机制。现阶段测试中的问题分析：主要感觉现在的软件测试工作一是不够正规专业，二是测试条件不足，三是测试人员的素质需要加强和提高，四是没有标准化。表面现象是单从一套用例，程序来接手，十分困难，虽然一时间能拿到不少资料，但十分零散，给人的感觉是非常迷茫，很多东西不清楚，如用例的描述，程序的代码，也有很多不一致的地方（请原谅我在这里的抱怨）。而平时的测试工作，测试人员过于被动，而且我们自身的思考性还不够，用例没有描述测试的目的，所以个人觉得改造和完善测试的流程非常有必要进行。质量管理软件BUG跟踪工具我们需要的BUG跟踪工具特点是：1能够对应项目中的 BUG 的产生和修正。2能够实现迅速有效的开发和测试的交流 。 3项目负责人可以对 BUG 的发生和修正即时进行观测，从而把握项目的品质和进度 。 4项目完成后，所有人员可以对 BUG 的比率进行的统计。本身考虑的是Bugzilla，我也下了相关的工具和介绍，但是这个工具对WINDOWS平台的支持不是很好，而且需要配置非常多的软件，如ActivePerl，MySql数据库，Apache服务器，Perl模块，发信模块Mailer。对终端软件的BUG查询管理是乎作用不大。个人不大赞成使用。之前所在的公司曾自开发了一套BUG跟踪工具，非常强大，叫FROGGY错误追踪系统，见（/chinese/product/p_froggy.html），但是没有开源的软件给外部使用。由于我们公司非软件公司，自主开发的能力有限，所以还是以后再花时间寻找更加适合我们的BUG查询管理软件。另外，任何管理软件都涉及到数据库，我们没有数据库服务器(CVS只是版本控制作用)，是否考虑安装免费的数据库服务器？责任界定：主要针对项目维护阶段，在用户使用时发现BUG，问题出现了，责任谁负责。首先我认为出现问题的原因肯定不是一方面的问题。但是归根到底要找人来承担责任，而归属的依据是什么？个人认为中国政治中的宪法有比较好的说明“有法可依，有法必依”。所以首先我们需要相关的规定来做依据，这个依据对于软件的开发和测试来说，最好的参考就是“测试报告和测试案例”。任何问题出现的时候，我们要检验测试报告是否测试出来该问题，测试用例是否有对应问题的测试。如果测试用例有，测试报告与使用的结果不对，然后查问题出现在哪里，为什么不对，查到事情就可以找到对应的人（因为测试用例是双方审核的，测试报告是大家都通过的，所有是公共许可文件）。尽量用文档来做参考，而不是大家在大脑里去回忆事情的过程。这样做到有法可依，而有法必依，就是出现责任必须承担。项目维护阶段的BUG也需要有等级的划分，作为回归测试的参考。软件测试周期根据项目的大小和紧急程度来看，软件测试周期见下表。项目举例P90 monitor底层驱动库前提条件假设没有时间限定，测试环境一切顺利测试准备阶段测试计划的编写，12天。/天数按工作日计算测试程序及文档：在从无到有的开发需要2周，简单修改或移植需要3天。测试用例：从无到用的编写需要1周，修改需要12天。测试对象和测试文档，用例，程序等审核，需要23天。测试执行阶段单元测试：如果没有重大的BUG出现，顺利需要3天。否则一周（23轮测试）/如果有辅助的脚本测试和结果统计的工具，一轮至少减少1天的时间。集成测试：如果没有重大的BUG出现，顺利需要2天。否则一周（23轮测试）系统测试：如果没有重大的BUG出现，顺利需要2天。否则一周（23轮测试）压力测试：如果没有重大的BUG出现，顺利需要1天（做到自动化，很多功能可以放在晚上或者节假日）。否则一周（23轮测试）测试收尾阶段测试报告：1天。测试总结：1天。软件测试工程师的素质要求对我们公司底层软件测试来说，比较好的了解底层软件的结构非常重要。个人认为如果做底层软件的测试，至少需要3个必要的条件。1 独立思考的能力，不能只听开发人员的安排和要求，需要自我思考，和不断提高对底层软件的认识。2 与开发人员的沟通能力，软件测试人员要主动积极地和相关的开发人员进行沟通，参与开发的分析和设计阶段，不是简单地要求开发人员来讲解和安排，但是开发人员给出必须而详细的文档也是十分重要的。3 不断创新的能力，鉴于对软件测试中问题的思考，提出更多的自己的想法和认识，帮助不断优化测试流程和测试技术的同时，反馈好的开发和设计意见，可以更好的提高和保证产品的质量。文档的重要性以及相应参考文档个人认为，文档是控制和管理项目的必要元素，非常重要，如果我们要保证产品的质量和管理品质，做出质量非