(软件测试规.docxVIP

软件测试规范软件测试，通过检查，发现软件系统的缺陷。它的目的是验证确保系统按照设计的功能完成，并且在软件和特定硬件集成的环境下，各个模块部分能一起良好的协作运行。 软件测试内容，包括各个模块的功能测试，也称为单元测试。各个模块完成功能测试的基础上，对模块间做集成联调测试，验证子系统间以及模块间的接口调用是否有效、数据流是否正确、业务功能是否完全等。 软件测试的流程软件测试贯穿软件生命周期的整个过程。包括以下几个过程： 由测试组长与编译管理员一起制定 由测试组长制定 测试组长 / 部分测试人员参加 静态测试 测试组长 / 部分测试人员参加 静态测试 根据模板设计测试方案。测试组 成员 根据方案开发必要的测试程序 动态测试。测试组成员 测试报告。测试组长 内部测试结束的里程碑 由原测试组部分成员负责测试计划测试计划通常在总体设计完成后，由测试leader负责制定。测试计划中包括总体的测试需求分析、测试因素考虑、确定必须的测试类型、测试环境、工作分工、日程安排、阶段目标（bug数）、风险及规避办法考虑。测试组成员将按照测试计划执行有关的测试任务，此计划作为测试team对项目组的承诺，应同时发送项目组全体。测试leader需要及时跟踪和督促测试计划的执行，并根据实际情况，对计划进行变更。测试类型单元测试单元测试是对最小开发单元的测试，如java的类。单元测试重点是测试程序的内部处理逻辑，主要使用白盒测试方法，通常由开发人员负责。单元测试结束后，开发人员将程序check到cvs的rm分支，由版本控制工程师做build。集成测试 集成测试是将系统的各个模块组装在一起，确认功能是否正确实现，验证是否满足需求。集成测试由独立测试组织ITO负责，测试过程中发现的问题入QCS 系统进行跟踪。集成测试需要测试的范围包括： 以功能模块为最小单元，确认每个功能模块是否正确实现需求和设计 对模块进行组装，确认组装模块的接口功能是否正确 对整个系统进行集成，以完整的业务流为主线，确认系统的业务功能是否正确实现回归测试回归测试是对某些已经测试过的测试集合重新测试。这些测试集合包括因软件变更（如fix bug、新增功能、系统优化）引起的数据流程发生变化，控制逻辑发生变化，接口发生变化，对变化所对应的测试集合，需要进行回归测试，以确认变化后的功能是否正确。由于软件变化可能造成有关联关系的未修改程序不能正常工作。因此在做回归测试的时候，除了测试直接变更的程序正确性外，必须找出有相关关系的程序，按照数据流、业务流的方式进行回归测试，防止缺陷逃逸。在以下请情况下，需要进行回归测试。 当软件发生变更（如fix bug、新增功能、系统优化） 当系统环境发生变更（如操作系统版本、数据库版本、测试环境、软件配置信息）目标程序被重新build回归测试在集成测试中进行。性能/压力测试 性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。通常性能测试和压力测试会合在一起进行。性能测试的目的为：目的要解答的问题度量最终用户响应时间多长时间可以完成业务流程确定可选择的硬件配置哪种配置可以得到最佳性能监控稳定性多大压力，多长时间内，系统可以稳定工作查找硬件、软件的改良方向如何改良有助于提升性能和稳定性评估新产品你将选择哪种硬件或软件度量系统吞吐量多大的负载压力可以造成系统性能的下降确定瓶颈哪些环节响应时间最慢接口测试在模块组装测试中，很多问题出现在接口部分。单个模块的功能实现了，但组装在一起，就无法正常工作。接口测试要包括两部分的测试： 根据设计文档，构造测试数据，验证接口是否正确 将接口关联的模块组装在一起进行连调测试。接口测试可以同时检查设计文档的正确性。确认测试 产品release前，需要对所有的Feature进行确认，未解决问题中没有1、2级的问题遗留，如有遗留的需求或1、2级问题，需要经过开发测试经理的授权。release前需要经过确认测试。确认测试方案在测试case设计时完成。有时也会放到测试中后期完成。确认测试以Feature为依据，是针对系统基本功能的流程测试。release测试还包括客户文档的测试，保证客户文档与产品一致。确认测试环节是产品从研发到现场的最后一个关卡，在这个阶段发现的任何微小问题都不能错过。确认测试重点在以下几个方面：release包应该是由BM从cvs库中重新打包出来的。保证发布版本与cvs中源代码一致。测试环境是“干净”的