[原创]软件测试实例指导

文档更新日志
内容	时间
“软件测试生命周期”添加内容；	2022-3-10

声明：

本文操作步骤、截图等均出自本人原著，任何人不得进行转载，谢谢！

前言：

本文重在众多软件测试小伙伴在项目实施测试过程中，遇到的阻塞，包括：需求分析、提单、回归验证；希望给够给予一定帮助及指导！

适用对象：

①软件测试工程师——初中级

②想要转行入门的童鞋

③测试实施过程中，对测试流程不熟悉的童鞋

使用条件：

①项目“生命周期”阶段

②具有一定逻辑能力

③具有一定测试基础

关键词：

需求、用例、提单、回归、报告

注：

本文用到的实例与您即将或正在进行的项目存在业务、逻辑等偏差，请自行判断；

---

生命周期

理解软件生命周期：

所谓“软件生命周期”，即“需求→设计→编码→优化→上线”的过程；

理解软件测试生命周期：

所谓“软件测试生命周期”，即“需求→方案→用例→依照用例执行被测业务系统→提单→回归→版本”的过程；

需求

理解原始（客户）“需求”

所谓“客户需求”，即客户侧根据自己的需求，整理汇总的原始文档，亦叫“需求说明书”（该文档是客户侧编写好之后向软件开发公司呈现），便于向软件研发公司阐述即将进行的“软件产品；

理解开发“需求”

所谓“开发需求”，即研发或开发人员根据对“原始需求”的理解以及结合自身的开发需要，整理汇总的开发文档（该些文档，包含：设计文档、数据库设计文档等等），便于研发或开发人员对即将开发的“软件产品”的理解、思路，以及后续的架构等等；

所谓“测试需求”，即测试人员根据对“原始需求”的理解及结合客户使用的角度，整理汇总的文档，（该些文档，包含：（需求的细化）、测试计划、测试方案、测试用例；以及随着软件的测试过程中产生的验收手册、测试报告），便于测试人员对即将测试的“软件产品”的理解，以及后续的测试思路、场景等。

细剖“需求说明书”

项目初始阶段，作为一名测试工程师，会拿到“需求说明书”，一般是电子文档的形式；毫无疑问，需要通读该文档全文，以便了解以下：

①项目的业务背景（客户群）以及业务逻辑（可以了解即将着手的项目是首次开发还是二次开发，以及该项目是怎么运作、交互的）

②项目的组网架构（其实这个和测试关系不大）

③项目的功能模块有多少、估算测试工作量（以便测试的排期、人员安排）

④项目开发过程中，测试人员需要准备的软、硬件资源（环境是要搭建在windows server还是linux；当然linux众多版本比如centos、suse、ubuntu较windows强大的多；以便测试环境或者现网环境的搭建（亦称“部署”））

⑤项目的风险评估

⑥.......

以下取“需求说明书”中的一小段作为需求实例的分析：

• 1、客户需求

受理工单模块，是用于记录呼救患者求救具体信息，该受理界面包含事件来源、呼救类型、事故类型、事故等级、现场地址，现场地址文本框内的信息提交到地图并进行地图检索......

• 2、测试需求

说明：测试需求，即客户需求的基础之上，从测试人员角度去抓取测试信息

从上面的一段文字表述中可知以下信息：

①该功能模块所处的项目背景是医疗急救行业

②该功能模块，包含多个字段信息

③该功能模块，会调用地图

④......

• 3、需求细化

事件来源——确定其是输入框还是下拉选择，此处以下拉选择为例

呼叫类型——确定其是输入框还是下拉选择，此处以输入框为例

现场地址——确定其是输入框还是地图侧点击位置后写入输入框

• 4、测试点

事件来源——①下拉框点击后是否有效②下拉框点击后是否空白③下拉框中若存在多个可点击项时，是否支持浮动框上下拖动④配置数据库中事件来源对应的字典表，是否能够及时显示或消失

呼叫类型——①输入框是否可点击输入字符②点击呼叫类型字段信息时是否能够自动定位输入框③是否对输入字符的长度、类型等作限制④对敏感字进行自动屏蔽

现场地址——①输入框是否可点击输入字符②点击呼叫类型字段信息时是否能够自动定位输入框③是否对输入字符的长度、类型等作限制④对敏感字进行自动屏蔽⑤点击地图中某一位置时是否支持将该地址以文本形式写入输入框⑥地址支持标注填写某地址部分信息后地图自动检索该地址相关的建筑、医院、学校、站点⑦是否支持二次修改

• 5、测试用例

指的注意的是①编写测试用例的时候，务必参照“测试点”，以此避免“遗漏、业务偏差、”等不必要且经常发生的这么一种情况②可以在QC、禅道、Testlink中进行测试用例的编写，亦可在excel中编写后倒入，此处不作细讲

以下展示的是比较规范的测试用例模板，编写用例时可参照：

注：

测试项——通常是指功能模块的名称，可以理解为“大标题”

测试子项——上述“3”中的需求细化，即测试子项

测试用例标题——上述“4”中的的测试点①②.......，一个测试点对应一条测试用例

测试用例编号——可根据自定义需要，对用例进行编号；通常是按照“测试项_测试子项_测试用例数量排序”（即“A_A01_A0101”）这样的样式进行编号

用例级别——可以理解为执行用例的优先顺序（一般根据某个功能优先实现，则这条功能对应的用例优先执行），优先级“高”的为优先执行该条用例；优先级一般三个等级：高中、低

预置条件——可以理解为执行该条用例所需要的前提准备，如用例模板中所示：需要“手工制单”，则需要确保“电脑运行正常”、“网络连接正常”、“坐席已登录该系统”

测试步骤——即执行此用例的动作、操作步骤

预期结果——该结果的参照物是客户侧提供的“需求文档”，即客户侧预期的、期望的功能模块正常运作的结果

备注——（执行用例的笔记，不作详解）

测试结果——执行该条用例时，操作结果与预期结果是否保持一致；一致，则通过；不一致，则不通过，此时进行提单，指派相应的开发/研发人员进行优化

执行人——通常是指执行此用例的测试人员

执行日期——即执行此用例的具体时间

讲了那么多，你一定很想知道”测试用例设计和编写的策略“，点击查看：

测试用例设计和编写的策略_zsyzcsan的博客-CSDN博客

• 6、测试环境的部署

测试环境的部署，可以查看我的这篇文章，“【原创】Linux环境部署（很全、很细）”

【原创】企业级Linux环境部署（很全、很细）_zsyzcsan的博客-CSDN博客https://blog.csdn.net/zsyzcsan/article/details/111628710

其实，测试环境的部署与以上用例的编写属于同步进行的工作，此处编写存在顺序先后

以下是通用的环境部署，但此处不对环境的部署作详解，值得一提的是，若不进行环境变量的配置，则启动某个程序是（比如zookeeper）会出现闪退的情况：

①jdk的安装及环境变量的配置

②tomcat的安装及环境变量的配置

③redis的安装及配置

④zookeeper的安装及环境变量的配置

⑤nginx的安装及配置

最后，一个项目的正常运行，除了相关安装包的正常安装及启动，当然少不了项目工程包

⑥使用ftp工具将工程包上传至~/tomcat/webapps/~路径下

常见报错：

404——客户端的问题

500——服务的问题（最大的可能是配置文件没有修改对，比如服务访问地址、端口号等等）

SQLBAD——数据库脚本存在问题，可以根据详细报错信息，进行定位，常见是少了或多了某张表、少了或多了某个字段

• 7、用例的执行

项目的服务正常访问后，可以对用例进行执行，执行的步骤按照测试用例即可，重点是看“执行结果”和“预期结果”的对比，若一致，则通过，若不一致，则不通过，此时生产一个很熟悉的词“bug”，那么，产生bug，就需要提单

• 8、提单

以下是比较规范的bug单

以下附bug单中某些属性的值：

问题分类

问题原因

问题等级

• 9、回归

开发人员修改了bug，测试人员进行“回归验证”，直到测试通过为止；从bug的发现到解决，必须形成闭环！

• 10、测试报告

测试报告，在项目的后期产生，其主要是项目交付的重要交付物和依据之一，对项目进行简单概括、资源的分配及使用、用例情况汇总、bug单情况汇总（提出时间、问题分类、问题原因、归属模块、问题等级等等）、bug与用例百分比，一以及给出意见和建议

---