刚刚发了新人报道，今天正式开始啃“软件测试基础”。本来以为就是背背概念，结果一边写一边发现，光知道“是什么”根本不够。
软件测试的意义：我第一次听说“Bug”的故事
软件测试是可以用来评估软件产品质量、并找出其中错误和缺陷的活动。它的目的是确保软件产品能够按照预期的要求运行，满足用户的需求。
1947年，哈佛大学的Mark II计算机上，工程师们发现了一只飞蛾被夹在继电器中，导致机器故障。他们将这只蛾子取下来，并记录在日志中，称之为“首次发现Bug的实际案例”。虽然“Bug”这个词之前就在工程领域用来指代故障，但这个事件让它与计算机紧密地联系在了一起。
卧槽，原来Bug真的可以是虫子？
软件测试工作流程
软件测试工作流程,通常也被称为软件测试生命周期。指的是一个测试项目从开始到结束所经历的一系列有条不紊的阶段。以前觉得测试就是打开软件到处点，直到学了软件测试生命周期，才发现这玩意儿跟盖房子一样，少一步都得返工。它不仅仅是"找Bug"那么简单，而是一个系统化的过程。
1.需求分析——打地基之前，先搞清楚给谁盖房
测试人员需要仔细研读产品需求文档、业务需求、原型图等。根据需求文档进行分析，了解软件特性，知道该如何进行测试用例的编写以及测试计划的制定，是整个测试流程的第一步。就像给房子打地基，即使是打地基，也需要知道给谁家的房子打，在哪里打地基。 我一开始觉得：这不就是看文档吗，有啥难的？
直到我自己找项目，试着分析一个“登录功能”的需求，才发现还是有些坑的。需求上写：“支持手机号登录”。在学习边界值等价类之前，我第一反应是：那就测正确手机号+密码呗。但后来一想：
- 手机号没注册怎么办？
- 格式不对（少一位、含字母）怎么办？
- 同一个手机号能绑多个账号吗？
- 密码错误有次数限制吗？
原来一个简单的需求，背后能挖出几十个测试点。 这一步如果偷懒，后面用例肯定漏。我现在理解为什么说需求分析是“地基”了——图纸没看懂，盖出来的楼也是歪的。
此阶段的高阶功法：需求规格说明书，有详细的功能描述。
2.测试计划——还没开始写代码，就要想好怎么收尾
测试负责人会根据需求文档制定测试策略，基本包括：
- 范围界定： 明确哪些功能要测，哪些不测（本次版本不涉及）。
- 资源评估： 需要几个人？需要什么测试环境？需要哪些测试工具？
- 时间排期： 评估各项测试任务需要多长时间，确定测试的开始和结束时间。无论做什么事情还是要有计划更好。
- 风险评估： 预判项目中可能存在的风险（如时间不够、需求不明确），并制定应对方案。万一开发delay了，就先测已经提测的部分
测试计划文档也是负责人在本阶段的高级功法，同时测试人员在测试计划评审会议过程中可对计划及时反馈计划文档的不足之处。
3. 测试设计/用例开发——我终于写了一条“废用例”
这是战术制定和弹药准备阶段，是测试前的重要一环，从软件各方面结合研发类文档进行分析，知道测试人员具体该做什么，测试用例就是在此环节进行产出。
- 做什么： 编写测试用例。测试用例是一份详细的步骤说明书，指导测试人员如何执行测试。大部分测试用例模板包括以下信息：测试编号、测试模块、测试标题、前置条件、测试数据、操作步骤、预期结果。
- 关键活动： 准备测试数据和测试用例，有些测试团队会对写好的用例进行同行评审，确保用例的逻辑正确、覆盖全面、没有冗余。
- 关键产出： 测试用例、测试数据、测试分析文档。
- 核心问题： 具体的测试步骤是什么？需要根据软件特性和需求规格说明书来进行确认。 这是我找项目写的测试用例表：
其实根据边界值可以再不断更新几条用例，后面讲了边界值会再更新。
4.测试执行——开发做不好核心功能也要跟着冒烟
到了这里就是咱们测试工程师的主战场了。不过因为公司流程不同，有的公司由运维在测试执行前搭建测试环境，有的要求测试自己搭。
-
冒烟测试： 开发人员提交代码后，测试人员首先进行冒烟测试。即测试软件的核心功能是否可用。如果核心功能跑不通，说明软件质量太差，测试团队会拒绝接收（打回给开发），直到核心功能稳定。冒烟这个比喻，来自硬件维修：一通电就冒烟，说明板子坏了，不用修了。软件也一样：核心功能崩了，后面的用例全是废纸。
-
正式测试： 测试人员按照测试用例逐条执行，实际运行软件。
-
缺陷提交： 当实际结果与预期结果不符时，说明发现了Bug。测试人员需要在缺陷管理工具（如Jira, Tapd, 禅道，我已经学了基础使用的是禅道）中提交Bug，详细描述重现步骤、截图、日志等信息，按照标准格式编写缺陷单，并跟踪解决情况和进度。
-
回归测试： 发现 Bug 后，会经历 提交 -> 开发修复 -> 验证 -> 关闭 的流程更重要的是，测试人员需要进行回归测试。回归测试的目的是检查：开发人员修复旧Bug时，是否不小心把原本正常的功能给改坏了。
-
关键产出： 缺陷报告、测试日志。
-
核心问题： 软件真的有Bug吗？并且要把所有用例执行完毕。
5.测试评估阶段
这里就该大火收汁了，但是汤如果是馊的也不会有人要喝。
测试负责人编写测试报告，并且对整个测试工作和软件质量进行总结。核心内容是：实际测试环境、测试过程数据的总结和分析（通过率等数据）、测试遗留缺陷的处理、软件版本质量的评估、后续测试建议、测试的结论。 这个阶段叫“测试评估”，我觉得更形象的词是“秋后算账”或者“大火收汁”。测试负责人写这个报告，回答两个问题：
- 测完了吗？
- 质量能发吗？
我看了一些帖子，发现最难的不是写报告，而是当质量确实不行的时候，你敢不敢说“不能发”。开发急着上线，产品等着发布，老板盯着数据——这个时候说“不”，需要专业判断，也需要勇气。
测试的终极价值，不是找Bug，而是给最终的决策提供依据。如果质量真的不行，我希望能有底气说出那句话。
这篇“基础”我写了两小时，比预计的长。但收获是：以前看书上的流程，觉得就是一个个步骤；现在自己梳理一遍，才发现每一步背后都有坑，都有自己的思考。作为一个正在学习的新手，可能文章会有做的不够好的地方，也希望大家批评指正，我会虚心接受。
