项目测试流程总结
测试计划做测试需要做好准备工作，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。就需要有一个完善的测试计划。测试计划的内容包括：确定阶段的测试范围和任务、确定测试策略和方法、确定测试周期、确定测试人力资源的分配、确定测试风险分析。
确定阶段的测试范围和任务——描述项目测试中做的测试范围，包括测试软件功能范围、测试种类等。
测试策略——主要分析可能实施的测试方法，考虑可能需要的测试工具。
测试周期——预测完成整个测试所需时间。也可以根据功能模块进行细分，估算每个模块需要完成的时间。
资源分配——分为人力资源、软硬件资源。组建测试项目组，确定测试项目负责人和组员，明确各成员的相关责任。按照不同的任务，能够提交的交付成果详细列出；
测试风险——大多考虑的就是项目开发延期、测试人员不足、用例无法全面覆盖测试点、时间不足、bug无法及时修改导致无法验证、测试人员技术不足导致测试进度拉长；
编写测试计划的目的在于充分考虑执行测试时的各种资源，执行时所能调用的一切资源以及受各种条件限制，可能受到的各种影响。编写完成测试计划后，进行项目内评审。
设计
描述对系统分解后每个功能点逐一的操作描述，包括用什么方法测试、用哪些测试数据、期望测试结果是什么以及对测试环境的设计。以功能点分析为依据进行测试用例的设计，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按操作步骤来执行的测试用例。测试用例需要覆盖所有的测试需求。测试用例一般包括以下几项：编号、功能点、预置条件、测试数据的输入、操作步骤、期望的输出结果、实际运行结果。对有性能测试、负载测试及安全测试需求的，设计专门的测试方法和用例。编写完成测试用例后，组内进行评审。
测试执行
测试用例的设计完成之后，部署测试环境。待开发提交测试版本后，开始进行测试。在满足用户使用的测试环境上，按照测试用例的条件、操作步骤、测试数据对系统进行操作。比较实际结果和测试用例所描述的期望结果是否一致，以确定系统是否能正常运行。
首次拿到测试版本后做一个预测试，目的是判断当前版本是否可测，如果预测试不通过，返给开发重新出新版本，如果通过了，进行第一次的系统测试。
系统测试执行编写的测试用例，做好测试结果记录，发现缺陷提交bug。第一次系统测试完成后，把所有的bug提交给开发人员，由他们进行修改。
在他们修改bug期间，我们可以对测试用例进行一个补充，包括修改或增加。开发修改bug结束后，提交一个新的版本给测试，首先回归我们提交的bug，然后挑选一些优先级别较高的用例来再次进行测试，查看新版本更新是否影响原有功能。发现了问题继续提交缺陷报告，开发再次进行修改，直到缺陷值达到用户要求，测试结束。
验收
在所有测试完成之后，编写测试总结报告，对测试进行总结。测试报告的内容包括：测试资源、测试内容、测试结果、缺陷分析、遗留问题等。
测试资源——包括人力资源的分配、软硬件资源。使用后系统的软硬件环境及分配的人员是否按期完成相关任务，是否有人员或任务的调整等。
测试内容——完成项目测试的具体内容。具体完成了哪些模块的测试，都做了哪些方面的测试。
测试结果——包括每个模块的bug描述、bug数量等。
缺陷分析——根据不同测试方向分析缺陷的分类，描述系统最后达成的效果是否与预期一致，是否可以提供给用户使用。
遗留问题——包含一些不影响用户使用但是因为人力或其他原因不能修复的可接受的缺陷。
验收的同时还要为用户提供一些验收文档，包括用户操作手册、用户安装使用手册等。用户可参照文档对系统进行操作使用。
测试不是耍笔杆子，不是定性分析。如果不能随时进行高强度回归测试，如果眼高手低（而且低1000倍），那么说多少也没有执行力。 八戒你干嘛 发表于 2017-6-23 13:37
测试不是耍笔杆子，不是定性分析。如果不能随时进行高强度回归测试，如果眼高手低（而且低1000倍），那么说 ...
呵呵，您所得对 ，执行力固然很重要，
总结的一些个人拙见，见笑了 八戒你干嘛 发表于 2017-6-23 13:37
测试不是耍笔杆子，不是定性分析。如果不能随时进行高强度回归测试，如果眼高手低（而且低1000倍），那么说 ...
呵呵，您所得对 ，执行力固然很重要，
总结的一些个人拙见，见笑了
页:
[1]
