软件测试全流程解析与用例设计秘诀

袁可佳 2025-11-3 14:09

一、测试流程是什么？
最近这个项目是比较全的因为我去的时候是从头跟进的，当时的话我们是有开项目立项会，然后的话我们组长去写他的一个测试计划，然后他给我们分模块，给项目排期，然后的话设计他的第一轮第二轮第三轮的一个测试，他的一个测试的范围，然后他给我们分到模块之后，我要去想他的测试点、然后的话呢去编写测试用例然后我们也去开评审。开始他的一轮测试，开发那边提交代码之后，我们首先去进行他的一个冒烟测试，对他的一个主要功能先去测一遍，然后第一轮主要就是解决他的一个功能性的严重性的bug 就是崩溃或者是说他有严重性的卡顿，主要就是解决这些问题，第二轮的话这些就全覆盖了第二轮的话主要就是解决他的一个卡顿还有功能上的一些bug，那第三轮的话呢？我们主要就是做他的一个回归测试。

测试流程依次如下：

1、需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team

2、测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager

3、用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester

4、执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)

5、执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)

6、defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester

7、测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.

8、用户体验、软件发布等。

扩展资料：

流程分析：

这个流程唯一的优点，就是能快速的发现并修复问题。

这个流程中，项目经理是核心，项目经理也确实是有多年开发与项目经验的牛人，他喜欢不定期分享上些前沿的技术。

对于测试来说，需求很不明确，测试文档与用例也是可有可无的产物，没有需求文档，或非常简陋，根据需求文档根本无法编写用例。

通用的测试用例，如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用型”用例，以便在测试过程中做参考。

二、如何设计测试用例？
那么在给出上述答案之前，先带大家熟悉一下什么是测试用例？测试用例有什么作用？然后在结合上述抛出的案例抛砖引玉一起讨论如何编写测试用例？
下面就是此文目录截图：

1、什么是测试用例
测试用例：为了特定的目的（证明软件存在某问题）而设计的一组由测试输入、执行条件、预期结果构成的文档
1、测试用例简单来说就是指导如何做测试的文档，该文档主要记录需要验证被测软件的是否满足需求

2、测试用例表现形式常见的有两种，可以以模板形式展示

1）一种是通过Excel直接编写

——大多数项目中都需要按照这种方式设计编写

2）一种是通过xmind直接整理测试点

——时间紧迫，项目没有强制要求时，可以设计测试点的形式编写
——对于业务流程类的测试，也可以整理为测试点进行测试

3、设计及执行人员：测试工程师

4、用例的模板：描述编写用例核心内容，一般项目都有自己的设计用例的模板，常见测试用例模板可参照如下：

2、为什么要写测试用例
为什么要写测试用例，实际中产品出现问题，第一责任人首先想到的是测试为啥没有测到？
产品出现问题了，你为啥没有测出来呢？

当然，除了避免“甩锅和背锅”，其实写测试用例更重要的作用如下：

技术上将需求转化为具体可验证的指标
以文档的形式记录软件可能存在的问题
防止测试过程的活动出现遗漏，提高工作效率
测试工作量的展示
3、如何编写测试用例
既然写测试用例如此重要，那么如何更好的编写测试用例呢？个人认为需要满足如下几点：

常规思考，设身处地的从用户角度出发（比如：实际用户是这么使用的么，会不会遇到异常情况呢？）
测试理论方法的支撑（比如：根据需求设计测试用例时，能用到哪些常见的测试用例设计方法？）
产品的熟悉和经验的积累（比如：已经有过类型项目经验，曾经在某个方面有过问题，当时是如何处理的呢？）
上述的设计用例过程，有个前提，就是对于测试有耐心和毅力，加上日常有意识的思维训练，才会写出全面的用例。

1、常规思考

回归到开篇的问题，对于一个基本的登录页面，按照常规思路能否会想到如下截图的测试点呢？实际，这些测试点都是源于从用户角度出发，结合需求进行细化设计的过程。实际测试中是不是只有这些测试点呢？

2、学习积累

相信大多数测试工程师都能够想到上述基本的测试点，然在实际工作中面对的项目不同，设计测试用例的颗粒度也有不同的要求，如果针对上述登录的模块，更深入一层考虑呢？此时需要对产品的熟悉程度及测试经验的加持，而且这些点的设计是不断学习、熟悉项目、测试积累中得到的。

3、理论支撑

有了常规的思考，有了经验的积累，还需要理论的支撑。测试用例毕竟是通过人去思考设计，这个过程不可避免有疏漏。如何规避？实际就需要测试理论的支撑，个人认为深入思考设计用例不外乎以下两方面：

1）测试用例的设计方法

测试理论中很关键一块就是将需求拆分为具体的测试点，然后根据用例设计方法进行具体的设计，其中拆分需求的关键是熟悉需求，将文档中已有的描述内容，按照用户使用场景、个人测试经验的积累（如果有的话）、把大段的内容拆分成能够直接用用例设计方法的测试点，这样就直接可以通过简明扼要的文字描述转化为Excel的测试用例，在这个过程通俗理解就是拆分细化的过程，直到可以直接写用例验证一个具体的功能点即可。
其中熟知的设计用例方法有：

观察法
等价类、边界值
判定表、因果图
流程图、场景法
错误推测法等
2）测试设计的思路开拓

倘若按照需求将已有的描述信息都已经拆分完毕了，是不是就可以确保测试没有问题了呢？
其实不然，在上述基础上如果还需要再拓展全面测试，还需要借助于软件质量模型的特性，从这些特性出发，给予测试用例设计者更多的思考空间。这样的设计就更加的全面可靠。
常见软件质量模型特性说明：

功能性：功能有没有，好不好用
性能效率：对应系统的资源耗费程度及响应时间
易用性：容易理解、学习、使用
兼容性：能够兼容不同的软硬件平台
可靠性：不易出问题，万一出问题容易恢复
安全性：对于用户的安全保障（外在的人生安全、内在的信息安全等）
可移植性：能否在不同环境条件下无故障运行
可维护性：对于后期的修复维护是否方便快捷
因此，对于上述登录功能，按照上述质量模型的思路指导，就得到如下的测试点：