精选后台测试规范V1.0

1、后台测试标准V1.0后台测试标准版本变更记录：版本号拟制/修改人日期更改原因更改内容备注第一章 总那么1、目的本标准是对后台软件测试的一份指导性文件，对软件测试过程中所涉及到的测试类型、测试标准、测试方法、测试流程等进行总体标准，以有效保证软件产品的质量。本标准主要对从事软件系统测试的人员提供指导。本规程的使用者可以是测试人员、也可是开发人员。2、概述所谓后台软件测试，只是一个相对的概念。除了前台展现给用户的东西，都可以算后台软件测试。主要是验证软件系统是否满足软件需求规格说明书中所规定的各个方面的需求而进行的，以黑盒测试方法为主。第二章 测试类型后台软件测试，可分为功能模块测试，集成测试，联

2、调测试，性能测试，高可用性测试等1、功能模块测试功能模块测试，即最小单元测试。关注于功能的具体实现。针对单个模块的代码改动，对功能实现的测试。不一定是最小代码模块，而是从功能角度出发，对最小功能单元进行测试。2、集成测试不同的公司有不同的叫法，这里的集成测试指的系统内集成测试。在 HYPERLINK /s?wd=%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95&tn=44039180_cpr&fenlei=mv6quAkxTZn0IZRqIHckPjm4nH00T1Y3n1I9PHw-mWT3nWcLPvuh0ZwV5Hcvrjm3rH6sPfKWUMw85HfYnjn

3、4nH6sgvPsT6K1TL0qnfK1TL0z5HD0IgF_5y9YIZ0lQzqlpA-bmyt8mh7GuZR8mvqVQL7dugPYpyq8Q1Rsn1n3PHfzn0 t _blank 单元测试的根底上，将各模块按照设计要求组装成为子系统或系统，进行 HYPERLINK /s?wd=%E9%9B%86%E6%88%90%E6%B5%8B%E8%AF%95&tn=44039180_cpr&fenlei=mv6quAkxTZn0IZRqIHckPjm4nH00T1Y3n1I9PHw-mWT3nWcLPvuh0ZwV5Hcvrjm3rH6sPfKWUMw85HfYnjn4nH6sgv

4、PsT6K1TL0qnfK1TL0z5HD0IgF_5y9YIZ0lQzqlpA-bmyt8mh7GuZR8mvqVQL7dugPYpyq8Q1Rsn1n3PHfzn0 t _blank 集成测试。实践说明，一些模块单独测试时都能够正常运行，但却不能保证连接来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。3、联调测试这里的联调测试指的系统间的联调测试。如前后台配合测试等。与集成测试类似。旨在测试跨系统的联通性，数据完整性一致性，接口协议的一致性，极限值的正确性即出入参数类型，长度等的一致性。4、性能测试性能测试指通过负载测试，确定在各种工作负载下系统的

5、性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况，包括cpu，内存，I/O性能，业务处理能力等。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大效劳级别的测试。5、高可用测试高可用测试也叫破坏性测试。旨在测试系统在局部组件异常的情况下的容错能力。通过宕机，插拔网线等方式，监控系统在异常情况下的各方面性能，业务处理能力变化。第三章 测试方法1、黑盒测试方法黑盒测试又称功能测试、数据驱动测试等。被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的情况下，仅依据程序功能的需求标准考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从用户观点出

6、发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它是不是在任何情况下都做的对。完整的“任何情况是无法验证的，为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况。黑盒测试首先是程序通常的功能性测试。常用的有划分等价类，边界值分析法，因果图等。2、白盒测试方法白盒法测试，是以程序的内部逻辑为根底，有选择地执行程序中最有代表性的通路。因此，白盒法也叫逻辑覆盖法。最彻底的逻辑覆盖法，是覆盖程序巾的诲一条通路。但当程序中含有大量循环时，要执行每一条通路是不可能的。因此，我们只能寄希望于程序的覆盖度尽可能高一些。目前常用的一些覆盖标准有：语句覆盖、判定

7、覆盖、条件覆盖、路径覆盖等。3、自动化测试自动化测试也可以认为是一类测试类型。之所以放在测试方法里，是因为自动化测试更多的用于回归测试，覆盖性测试。在数据源一致的前提下，自动化执行case集，比照测试结果，验证程序改动对原有功能的影响。第四章 测试流程1、需求分析，列出功能点了解需求内容，了解需求变更，与需求提出人沟通，明确需求功能点。2、与开发讨论实现方案与开发讨论该需求，明确需求实现方案，由开发输出解决方案。3、Case先行在需求文档和解决方案明确的前提下，根据功能点和代码改动设计测试案例，需覆盖所有功能点，同时需有回归测试案例。涉及外围模块接口的，需有集成测试案例。4、Case评审根据需

8、求改动大小，在小组or部门内做测试案例评审，视需要带上开发人员。5、编译发包部署明确编译范围，不能少编漏编，也不能扩大编译范围。如有全局的结构变动，需做冒烟测试，重编结构相关模块。6、测试执行执行前，检查环境，清理环境和备份原有数据。准备数据，测试数据需和测试案例一一对应。数据记录，将case执行前后的数据，日志，页面等记录下来，为后面测试报告作数据依据。7、测试文档编写文档名称，文档格式需统一。文档中附上需求内容，解决方案。写明测试环境，测试软硬件根底，测试版本号，变更的代码模块。列举测试案例，各个case中需有明确的数据及变更，执行方法，执行结果，执行结论。测试文档的最终要求是新员工拿到测试报告，能明白需求内容，重现文档中case。8、发现bug，提交bug单给开发。原需求单回退给开发如发现bug，需提交bug单给相应开发，不允许私下沟通修改。每次代码提交都需有相应的单子可跟踪。原需求单回退给开发，待bug修复后和bug单一起流转到测试人员。9、Bug回归Bug单到测试人员手中后，需回归此bug。验证bug解决后关闭bug单。10、测试通过