更新版：软件测试菜鸟入门
改版前链接：https://weltest.blog.csdn.net/article/details/79847217
前言
随着技术的发展，各种应用程序、各种App应运而生!在早期，这些应用程序只是通过开发人员、产品以及部分用户使用之后，给出相应的修改意见，感觉都OK后就进行上线，在网上或一些app下载平台上就可以直接使用，没有进行过规范的软件测试！这些软件或多或少会存在一些bug，这些bug有可能是功能上、兼容性、性能等各方面的问题！为了改善软件质量不高的问题，软件测试这门行业才开始受到重视！软件测试的目的就是为了提高软件质量，给用户更好的体验感！
作为一个系统，在应用中看到的一个简单的按钮，其实在系统中可能是一条线或者是一张网。在如此复杂的系统，不经过系统的软件测试，用户使用应用发现问题的可能性是极高的，这些问题有些可能是致命的，直接影响用户体验。特别在当下行业极度细化，应用竞争极其残酷的条件下，给用户不好的体验感，会造成用户的流逝，让项目整体垮塌也是很有可能的。
当下的软件测试也不在只是点点点就能保证应用正常的，当下的软件测试人员要具有系统思维，站在系统的角度对系统进行划分了解，确保应用中对应的功能点的数据流的各个节点都能正常，且接口数据正确。而且随着当前网络安全越来越受到企业重视，软件测试生命周期中也需要对应用系统进行一些安全扫描及安全编码，确保应用系统的安全性。
与此同时，软件测试人员不在是发现bug，然后把bug提给相关开发人员，让开发定位，软件测试人员，还需具备问题定位及问题分析的建议，指出产生问题的明确原因，让开发有针对性排查，特别是当下系统很复杂的情况，模糊或者不规范的bug记录，会造成开发定位问题难，耗时久的情况。所以当下社会，给软件测试人员提出了更高的标准，测试人员应该更专业化、职业化、标准化！
那么作为软件测试入门人员，第一步往往是如何工作，给你一个项目的你应该第一步干什么，第二步干什么…，那么在第一模块说下软件测试流程，让你知道软件测试的1、2、3、4、5。
软件测试流程
当你以一个测试新人进入一个刚开始的项目，你第一步是要知道我们要开发出来个什么东西？那可以通过哪些途径帮助我们知道我们做的什么呢？
不同的团队有不同的方法来描述，常用有三种方式：用户故事、产品规格说明书、原型图，我把这三种统称为“需求说明书”。那何为需求说明书呢？这里我给出个人理解的需求说明书：是指用户对于软件的功能、性能、兼容性、UI等各方的需求描述！
下面给出个人认为比较严谨或者规范的测试流程图：
测试点提取
在需求说明书通过评审后，这时候开发、产品、测试有统一的需求文档，基于需求说明书，测试根据需求说明书中的内容，提取测试点，测点提取的准则一般是：一个测试点对应一条测试用例！以确保需求的覆盖率！一般测试人员根据需求说明书，直接进行编写测试用，这样容易造成需求覆盖的不全面！测试点不仅包括需求说明书中指示出的需求点，还包括一些隐性的需求，确保提取的测试点能尽可能多的覆盖需求！
测试设计与评审
测试用例是软件测试最小颗粒单元也是测试的关键点之一。不管是测试的菜鸟还是从事测试多年的老鸟，测试用例测试中必不可以的一环！根据公司业务，每个公司的测试用例都不一样，通用的模板核心参数主要有以下几点：用例、用例名称、用例描述、执行步骤、预期结果、实际结果、所属功能模块、用例状态、所属版本号、作者、创建日期。有的公司还有优先级、前置条件等，这些属性根据自己公司业务，自己用于完善。目前测试设计可以使用不同的工具，但测试设计的要点就是：简单明了、条理清晰！
下图给出一个简单的测试用例模板，模板中的属性可以根据自己的需求或者业务进行扩展和删除，一般是用例属性在一列展示，我这边给出的一个表格模板：
| 用例ID | 名称 | 优先级 | |||
|---|---|---|---|---|---|
| 用例描述 | |||||
| 版本号 | 系统信息 | 作者 | |||
| 用例状态 | 开发人员 | 创建日期 | |||
| 操作步骤 | 预期结果 | 实际结果 | |||
| Step_1 | |||||
| … | |||||
| Step_N | |||||
测试设计完成后，不是就要开始进行测试的下一步，而是要经过测试评审。虽然需求说明书已经给定了，但是产品、开发、测试对统一需求点理解上可能存在差异，那么在实现和测试上就会出现不同的结果，这一部分的目的主要有如下几点：
- 明确测试要点，统一对需求的理解，确保测试的完备性
- 评审测试用例设计是否充分覆盖功能需求；
- 确定测试时间节点；
这个阶段参与人员主要是：产品、开发、测试，在大型公司项目负责人也会参与用例评审。
不同类别测试选择
测试设计并评审完毕，这时候就要选择不同的测试方法来进行测试实现。大体上一个项目包括的测试类型有如下几种：手工测试、黑盒测试/功能测试、白盒测试、自动化测试、兼容性测试、接口测试、性能测试、渗透测试等。
手工测试
主要做一些逻辑比较复杂、使用频率比较少的功能！不过目前大部分公司的app测试，使用手工测试占比在70%左右，目前大多数人员对测试人员的认知还停留在“点点点”，其实手工测试主要做一些探索测试对核心功能进行验证。
自动化测试
主要做一些重复性、使用频次比较高的场合。自动化实现可以根据自己所属技能选着适合语言和工具来实现自动化！目前市场用的比较多的：RF、UFT(QTP)、winrunner、selenium、appium、uiautomator、XCUITEST等。感兴趣的可以自己去了解！设计自动化脚本之前，需要梳理相关业务、设计好测试执行流程、测试数据准备
接口测试
接口测试就是校验这个接口返回参数和状态是否正确，接口测试前期需要做如下准备工作：
- 开发人员提供服务接口（接口路径、头文件、请求数据格式等）;
- 给出测试数据。以登录为例：需要各种组合的用户名和密码;
- 根据前两部可以选择postman、RESTClient、Fiddler、Charles任意一款工具模拟请求。
- 根据模拟的的设计请求格式，选则相应的测试工具。目前主流的接口测试主要有：Jmeter、Locust、以及自己编写的一些的脚本。对于刚入门的个人推荐学习Jmeter，Jmeter既可以做接口测试，还可以基于接口做并发测试、压测、负载测试，不过性能和稳定性没有loadrunner好。
写脚本的项目目录一般包括：库文件lib、测试数据文件data、测试用例文件、测试报告、日志文件和主程序。
兼容性测试
由于现在设备多样性、浏览器多样性、操作系统多样性，在产品上线前，通常在不同的设备(不同的分辨率)、浏览器、操作系统上操作使用产品，查看应用程序是否正常显示、应用程序功能能否正常响应！兼容性测试目前主要是指移动设备兼容性、操作系统的兼容性、浏览器的兼容性。
兼容性测试方法就是确定一个测试基准，以测试基准作为预期结果，在其他设备、浏览器、操作系统上进行相同的操作，与测试基准一致，说明应用程序在兼容性方面是满足用户或产品需求的。
性能测试
性能测试是基于功能、接口完整的情况下，对服务端进行压力测试、负载测试、疲劳测试、并发测试，来发现性能瓶颈。性能测试主要包括：
-
需求提取，该部分包括：响应时间、并发用户数、TPS、吞吐量、CPU利用率、内存使用率、在线并发用户数等。
-
需求策略制定：设计性能测试场景！这里以登录为例：
并发用户数 用户数增加间隔 压测时长 150 1 20分钟 200 2 30分钟 250 2 30分钟 300 3 30分钟 -
准备测试数据这里测试数据和自动化测试所使用的测试数据不一样，这里的测试数据都是有效且复合要求的数据，请求使用该数据能响应成功的数据。如果设计数据库，还需要关注数据库的分区情况，构造的测试数据不能出现数据倾斜、测试数据模型数量级要进行生产数据分析构建。
-
选着测试工具
测试工具个人推荐loadrunner破解版，主要原因是：
- 我在使用jmeter的进行长时间压测时多次堆栈溢出，没有loadrunner稳定；
- 其次loadrunner生成的报告也比较规范可选择性比较多。如果对于要求不是很规范的可以选着jmeter，jmeter并发用户数与压测的客户端配置有很大关系，不过适合入门，对于你们的话，公司不要求我推荐你们用这个，能满足基本的性能测试和接口测试。loadrunner内部编程脚本是使用C语言，入门比较高。
-
选着合适的性能计数器、以及相关的性能分析指标
注意这里的性能计数器是设置在服务端的不是在客户端，如果没有服务端权限，这是需要记录下压测时间节点，给服务端沟通，要出这段时间的服务器的性能指标。
性能分析指标：响应时间、并发用户数、TPS、吞吐量、在线并发用户数
性能计数器链接：http://blog.csdn.net/henni_719/article/details/52024562
-
进行压力测试，收集性能监控指标数据用于性能分析
-
编写性能测试报告
安全测试
随着技术的发展，移动支付的发展，安全测试逐渐受到重视。安全测试需要知识面非常广，我个人水平有限，在此不做误人子弟的事！不过目前主流的渗透测试平台主要有：Kali，这个平台汇聚安全测试使用最多的工具和命令！常用的WEB扫描攻击可以了解：burp suite、paro、owasp zap等。
测试执行与缺陷管理
测试执行包括:手动执行测试用例、运行自动化测试脚本、接口测试脚本、性能测试脚本、兼容性测试等。在这过程中如果发现bug，可以选着公司里的bug管理系统记录bug。bug管理系统目前有：bugzilla、mantis、bugtags等。如果没有使用过这些工具，可以使用doc或者excel自己创建一个bug模块。bug的核心属性包括： bugId、bug名称、bug描述、严重等级、优先级、所属功能模块、版本号、开发人员、重现步骤、预期结果、实际结果。
bug的状态流转包括：新建、已解决、已关闭、重现打开。下文给出一个缺陷报告模板：
| bugID | 名称 | 优先级 | |||
|---|---|---|---|---|---|
| bug描述 | |||||
| 版本号 | 系统信息 | 作者 | |||
| 严重等级 | 所属功能模块 | ||||
| bug状态 | 开发人员 | 创建日期 | |||
| 重现步骤 | 预期结果 | 实际结果 | |||
| Step_1 | |||||
| … | |||||
| Step_N |
回归测试与验收测试
回归测试
由于系统很大，一次测试周期很长，如果当前版本进行多次测试，不可能没一轮测试，都执行所有的测试用例。在没一轮次之前，需要对开发分支代码进行变动分析，确定本次测试范围，选取代码变动影响的功能模块进行重点验证，对于未影响的功能模块，只进行简单抽测即可。
系统测试
测试结束后，需要给出各个阶段的测试产物。如测试需求文档、测试用例、自动化脚本、性能测试脚本、性能测试报告、自动化执行报告、接口脚本及报告等。
验收测试
需要产品经理或者用户根据需求说明书（或合同）来检查产品功能实现、页面展示、性能是否与需求说明书要求的一致，如果一致，这说明产品符合需求通过验收，产出验收测试报告
总结
上述给出软件测试的流程，以及每个流程需要做什么？通过该文章需要关注的重点是：测试流程、测试用例的编写、bug的编写和管理这三个核心。至于其中所涉及的测试类型只是在此简单提及，文中所提及的工具和技术可以自己网上查询，如果感兴趣可以，可以加微信：Wel_Test，一起讨论测试的那些事，共同学习共同进步，一起在测试路上同舟共济！
来源：
