第1章：企业级研发测试流程

news2024/11/19 19:28:03

研发流程.png

通过实际（自研互联网）企业的研发流程一览图。

我们发现分为9个阶段，当然每个公司细节并不一样。

所以我希望你能理解这句话：
一切的流程、行为、结果都是围绕“产品质量”这4个字开展活动。而作为测试，你该考虑的是如何满足项目“进度要求”的前提下，达到“产品质量”的最上限！

接下来，我们就详细的说说每个阶段，我们作为测试人员的所作所为！

一、需求阶段

“需求”一定是重点！

什么是需求？
需求即公司决策层，为公司发展，提出关于“产品”的功能idea。

那为了老板的“idea”，我们研发团队都做了哪些事？

产品经理：

和管理层沟通“idea”的细节。
确认“需求列表”实现优先级！（先搞哪个，后搞哪个）
输出“产品说明文档（需求的规则）”、“产品交互文档（需求的页面交互）”，并与管理层再次确认是否与“idea”一致，有无思维上的错位。
进行研发组的“需求评审”会议。

研发人员（前后端）：

听需求，开发leader分配任务。
了解本次需求（新增、变更）以及影响范围，包括需求规格说明书、功能结构及模块划分，根据需求梳理代码实现方案。

测试人员：

听需求，测试leader分配任务。
了解本次需求（新增、变更）以及影响范围，包括需求规格说明书、功能结构及模块划分，根据需求梳理测试点。

作为刚入行的“测试人员”怎么更有效、更有质量的在评审环境及时发现问题，提出问题。
短时间内赢得团队的认同和领导的赏识。
我会在之后的章节专门讲一讲。

二、制定技术方案

制定技术方案，主要实施人员为“开发人员”。
制定技术方案的目的就是为了满足本次迭代“需求”的技术方案框架，满足“实现”与“预期”的功能、性能一致，并且不会对已实现的业务造成影响。
主要包含以下内容：

数据库表设计。
接口设计。
代码的详细设计。（小公司一般不会有，但会让开发进行关于业务逻辑的表述，确保与产品一致）
以上会形成文档，总结在《概要设计》中。

三、UI评审

我们都知道，一个产品肯定界面是要符合用户审美的，而负责这一审美的研发人员就是我们的UI设计师。

UI设计师当然不能随意设计，主要依据的还是《产品交互文档》进行设计，当然要根据个人经验，来进行更细化的交互设计。

四、技术评审

这个还要从第2点说起，听完需求后，也就是从第2点开始，研发就需要着手制定《技术方案》，自研公司的迭代周期大部分是“1个月1迭代”，所以这个“制定技术方案”的时间，基本上需要在1个礼拜内做完，甚至更短的时间。

在我经历的公司内，可能大部分开发人员对于业务的理解并不怎么重视。

所以开发人员在技术评审阶段需要进行两个宣讲内容：

需求串讲。（开发会进行需求的二次宣讲，由产品经理确保在理解上不会有偏差）
技术方案的宣讲。（表设计、接口设计等）

五、任务分配

既然技术评审已经完成，那么就到了开发任务的安排，为了计划更好的进行，所有公司都会有自己的研发管理平台，例如大家熟知的“JIRA”、“禅道”、“Excel”。

你可以理解在这个过程，研发部门需要输出《研发计划》包含最基本的“开发计划、测试计划、上线时间”即可。

这些不仅仅是测试人员理解的“BUG管理工具”，更是迭代的“需求”管理工具，可以很直观的将“产品”、“开发”、“测试”人员的工作联系在一起，通过看板数据来直观确保“计划的正常实施”。

开发：“研发工时”、“提测时间”等数据。
测试：“测试执行工时”、“测试完成时间”等数据。
产品：“版本预计发布时间”。
等等…

六、测试用例评审

测试人员一般对于业务的理解会很准确且积极的和产品沟通，所以不需要进行宣讲，主要是在“需求评审”后，就着手编写“测试用例”。

测试用例主要需要包含两点：

产品文档的“内容的100%覆盖”且确认文档内无“缺胳膊少腿”等不合理的问题。
产品文档以外的测试用例。

刚入行的软件测试人员
怎么做到“产品文档100%覆盖”？
又如何发现“更有质量的文档问题”？
产品文档之外的测试用例，又该设计哪些？我该怎么设计？

这些都是需要依靠“经验”的积累以及“更有效的工作方法”来解决。
你欠缺的仅仅是一个“敲门砖”，我10年的工作经验总结，会讲这个“敲门砖”用一个“很简单”、“很有效”、“可复制”的方法带你入门，而你要做的就是形成“肌肉（脑部）记忆”。

这一方法，我在我招聘的“软件测试培训出来的同事”身上，得到很好的“实验效果”，仅仅一个月，就达到了别人“一年的工作经验效果”，能够独当一面。