大家好，欢迎来到IT知识分享网。

更新版：https://weltest.blog.csdn.net/article/details/110529745

视频课程：https://edu.csdn.net/course/detail/23459

目录

前言… 3

软件测试流程… 3

提取测试点… 4

设计测试用例与用例评审… 4

测试类型选择… 5

测试执行与缺陷管理… 7

回归测试与验收测试… 8

测试报告… 8

总结… 8

前言

       随着技术的发展，各种应用程序、各种App应运而生!在早期，这些应用程序只是通过开发人员、产品以及部分用户使用之后，给出相应的修改意见，感觉都OK后就进行上线，在网上或一些app下载平台上就可以直接使用，没有进行过规范的软件测试！这些软件或多或少会存在一些bug，这些bug有可能是功能上、兼容性、性能等各方面的问题！

         为了改善软件质量不高的问题，软件测试这门行业才开始受到重视！软件测试的目的就是为了提高软件质量，给用户更好的体验感！

软件测试流程

         不管开发还是测试都有需求方，通过与需求方进行沟通交流，整合信息，制定成需求说明书！需求说明书：是指用户对于软件的功能、性能、兼容性、UI等各方的需求文本！开发根据需求说明书进行开发和设计程序！但有的公司不会提供需求说明书，大多数公司在这部分是不规范的通过会议的形式以及设计模型作为需求，这样做的目的就是需求不明确，沟通成本太高！

         下面给出个人认为比较严谨或者规范的测试流程图：

提取测试点

       在需求说明书通过评审后，这时候开发、产品、测试有统一的需求文档，基于需求说明书，测试根据需求说明书中的内容，提取测试点，测点提取的准则一般是：一个测试点对应一条测试用例！以确保需求的覆盖率！一般测试人员根据需求说明书，直接进行编写测试用，这样容易造成需求覆盖的不全面！测试点不仅包括需求说明书中指示出的需求点，还包括一些隐性的需求，确保提取的测试点能尽可能多的覆盖需求！

设计测试用例与用例评审

         测试用例是软件测试最小颗粒单元也是测试的关键点之一。不管是测试的菜鸟还是从事测试多年的老鸟，测试用例测试中必不可以的一环！根据公司业务，每个公司的测试用例都不一样，通用的模板核心参数主要有以下几点：用例ID、用例名称、用例描述、执行步骤、预期结果、实际结果、所属功能模块、用例状态、所属版本号、作者、创建日期。有的公司还有优先级、前置条件等，这些属性根据自己公司业务，自己用于完善。测试用例设计要点就是：简单明了、条理清晰！

         下图给出一个简单的测试用例模板，模板中的属性可以根据自己的需求或者业务进行扩展和删除，一般是用例属性在一列展示，我这边给出的一个表格模板：

1.     明确测试要点，统一对需求的理解，确保测试的完备性用例设计完成后，不是就要开始进行测试的下一步，而是要经过用例评审。虽然需求说明书已经给定了，但是产品、开发、测试对统一需求点理解上可能存在差异，那么在实现和测试上就会出现不同的结果，这一部分的目的主要有如下几点：

2.     评审测试用例设计是否充分覆盖功能需求；

3.     确定测试时间节点。

这个阶段参与人员主要是：产品、开发、测试，在大型公司项目负责人也会参与用例评审。

测试类型选择

         用例设计并评审完毕，这时候就要选择不同的测试方法来进行测试实现。大体上一个项目包括的测试类型有如下几种：手工测试、黑盒测试/功能测试、白盒测试、自动化测试、兼容性测试、接口测试、性能测试、渗透测试等。

l  手工测试

主要做一些逻辑比较复杂、使用频率比较少的功能！不过目前大部分公司的app测试，使用手工测试占比在70%左右。

l  自动化测试

主要做一些重复性、使用频次比较高的场合。自动化实现可以根据自己所属技能选着适合语言和工具来实现自动化！目前市场用的比较多的：RF、UFT(QTP)、winrunner、selenium、appium、uiautomator、XCUITEST等。感兴趣的可以自己去了解！设计自动化脚本之前，需要梳理相关业务、设计好测试执行流程、测试数据准备

l  接口测试

接口测试就是校验这个接口返回参数和状态是否正确，接口测试前期需要做如下准备工作：

a.开发人员提供服务接口（接口路径、头文件、请求数据格式等）;

b. 给出测试数据。以登录为例：需要各种组合的用户名和密码;

c.根据前两部可以选着postman、RESTClient、Fiddler、Charles任意一款工具模拟请求。当请求成功发送并返回时！

d.根据模拟的的设计请求格式，选则相应的测试工具。目前主流的接口测试主要有：Jmeter、Locust、以及自己编写的一些的脚本。对于刚入门的个人推荐学习Jmeter，Jmeter既可以做接口测试，还可以基于接口做并发测试、压测、负载测试，不过性能和稳定性没有loadrunner好。

写脚本的项目目录一般包括：库文件lib、测试数据文件data、测试用例文件、测试报告、日志文件和主程序。

l  兼容性测试

由于现在设备多样性、浏览器多样性、操作系统多样性，在产品上线前，通常在不同的设备(不同的分辨率)、浏览器、操作系统上操作使用产品，查看应用程序是否正常显示、应用程序功能能否正常响应！兼容性测试目前主要是指移动设备兼容性、操作系统的兼容性、浏览器的兼容性。

兼容性测试方法就是确定一个测试基准，以测试基准作为预期结果，在其他设备、浏览器、操作系统上进行相同的操作，与测试基准一致，说明应用程序在兼容性方面是满足用户或产品需求的。

l  性能测试

性能测试是基于功能、接口完整的情况下，对服务端进行压力测试、负载测试、疲劳测试、并发测试，来发现性能瓶颈。

性能测试主要包括：

1.        需求提取，该部分包括：响应时间、并发用户数、TPS、吞吐量、CPU利用率、内存使用率、在线并发用户数等。

2.        需求策略制定：设计性能测试场景！这里以登录为例：

并发用户数：150、200、250和300；

用户间隔时间：1、2、2和2；

持续运行时间：20、30、30和30。

3.        准备测试数据

这里测试数据和自动化测试所使用的测试数据不一样，这里的测试数据都是有效复合要求的数据，请求使用该数据能响应成功的数据。

4.        选着测试工具

测试工具个人推荐loadrunner激活成功教程版，主要原因是：a.我在使用jmeter的进行长时间压测时多次堆栈溢出，没有loadrunner稳定；b. 其次loadrunner生成的报告也比较规范可选择性比较多。如果对于要求不是很规范的可以选着jmeter，jmeter并发用户数与压测的客户端配置有很大关系，不过适合入门，对于你们的话，公司不要求我推荐你们用这个，能满足基本的性能测试和接口测试。loadrunner内部编程脚本是使用C语言，入门比较高。

5.        选着合适的性能计数器、以及相关的性能分析指标

注意这里的性能计数器是设置在服务端的不是在客户端，如果没有服务端权限，这是需要记录下压测时间节点，给服务端沟通，要出这段时间的服务器的性能指标。

性能分析指标：响应时间、并发用户数、TPS、吞吐量、在线并发用户数

性能计数器链接：http://blog.csdn.net/henni_719/article/details/52024562

6.        进行压力测试，获取测试测试测试数据或报告

7.        编写性能测试报告

l  渗透测试

随着技术的发展，移动支付的发展，安全测试逐渐受到重视。安全测试需要知识面非常广，我个人水平有限，在此不做误人子弟的事！不过目前主流的渗透测试平台主要有：BT5、Kali，这两个平台汇聚安全测试使用最多的工具和命令，感兴趣可以去网上查阅，或者私信我，我给出学文档！

测试执行与缺陷管理

测试执行包括:手动执行测试用例、运行自动化测试脚本、接口测试脚本、性能测试脚本、兼容性测试等。在这过程中如果发现bug，可以选着公司里的bug管理系统记录bug。bug管理系统目前有：bugzilla、mantis、bugtags等。如果没有使用过这些工具，可以使用doc或者excel自己创建一个bug模块。bug的核心属性包括： bugId、bug名称、bug描述、严重等级、优先级、所属功能模块、版本号、开发人员、重现步骤、预期结果、实际结果。

缺陷生命周期流程图：

下文给出一个缺陷报告模板：

回归测试与验收测试

         回归测试根据时间安排，选着合适的回归策略，如果时间充分，那就执行所有的测试用例，如果时间不充足，选着执行核心的测试用例以及bug修复的测试用例。

验收测试，需要产品或者用户根据需求说明书来检查产品功能实现、页面展示、性能是否与需求说明书要求的一致，如果一致，这说明产品符合需求通过验收。

测试报告

测试结束后，需要给出各个阶段的测试产物。如测试需求文档、测试用例、自动化脚本、性能测试脚本、性能测试报告、自动化执行报告、接口脚本及报告等。

总结

         上述给出软件测试的流程，以及每个流程需要做什么？通过该文章需要关注的重点是：测试流程、测试用例的编写、bug的编写和管理这三个核心。至于其中所涉及的测试类型只是在此简单提及，文中所提及的工具和技术可以自己网上查询，如果感兴趣可以，微信：Wel_Test，一起讨论测试的那些事，共同学习共同进步，一起在测试路上同舟共济！个人微信公众号：