开发人员谈测试：做好软件测试才能提升应用质量

Posted 2023-04-04 程序员威子

相信在国内一些中小型公司，开发者很少会去写软件测试相关的代码，当然这背后有一些原因在，本文就讲讲ios开发中的软件测试相关的内容。

　　测试的重要性
　　测试很重要！测试很重要！测试很重要！重要的事情说三遍。

　　场景1
　　每次我们写完代码后都需要编译运行，以查看应用程序的表现是否符合预期。
　　假如改动点少、代码量小，那验证成本低一些，假如不符合预期，则说明我们的代码有问题，人工去排查问题花费的时间也少一些。
　　假如改动点很多、受影响的地方较多，我们首先要大概猜测受影响的功能，然后去定位问题、排查问题的成本就很高。

　　场景2
　　你新接手的 SDK 某个子功能需要做一次技术重构。但是你只有在公司内部的代码托管平台上可以看到一些 Readme、接入文档、系统设计文档、技术方案评估文档等一堆文档。可能你会看完再去动手重构。
　　当你重构完了，找了公司某条业务线的 App 接入测试，点了几下发现发生了奔溃。心想，本地测试、debug 都正常可是为什么接入后就 Crash 了？
　　其实想想也好理解，你本地重构只是确保了你开发的那个功能运行正常，你很难确保你写的代码没有影响其他类、其他功能。
　　假如之前的 SDK 针对每个类都有单元测试代码，那你在新功能开发完毕后完整跑一次单元测试代码就好了，保证每个 Unit Test 都通过、分支覆盖率达到约定的线，那么基本上是没问题的。

　　场景3
　　在版本迭代的时候，计划功能 A，从开发、联调、测试、上线共2周时间。
　　老司机做事很自信，这么简单的 UI、动画、交互，代码风骚，参考服务端的「领域驱动」在该 feature 开发阶段落地试验了下。
　　联调、本地测试都通过了，还剩3天时间，本以为测试1天，bug fix 一天，最后一天提交审核。代码跟你开了个玩笑，测试完 n 个 bug（大大超出预期）。
　　为了不影响 App 的发布上架，不得不熬夜修 bug。将所有的测试都通过测试工程师去处理，这个阶段理论上质量应该很稳定，不然该阶段发现代码异常、技术设计有漏洞就来不及了，你需要协调各个团队的资源（可能接口要改动、产品侧要改动），这个阶段造成改动的成本非常大。
　　相信大多数开发者都遇到过上述场景的问题。其实上述这几个问题都有解，那就是“软件测试”。

　　软件测试
　　分类
　　软件测试就是在规定的条件下对应用程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
　　合理应用软件测试技术，就可以规避掉第一部分的3个场景下的问题。
　　软件测试强调开发、测试同步进行，甚至是测试先行，从需求评审阶段就先考虑好软件测试方案，随后才进行技术方案评审、开发编码、单元测试、集成测试、系统测试、回归测试、验收测试等。
　　软件测试从测试范围分为：单元测试、集成测试、系统测试、回归测试、验收测试（有些公司会谈到“冒烟测试“，这个词的精确定义不知道，但是学软件测试课的时候按照范围就只有上述几个分类）。
　　工程师自己负责的是单元测试，测试工程师、QA 负责的是集成测试、系统测试。
　　单元测试（Unit Testing）：又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。「单元」的概念会比较抽象，它不仅仅是我们所编写的某个方法、函数，也可能是某个类、对象等。
　　软件测试从开发模式分为：面向测试驱动开发 TDD （Test-driven development）、面向行为驱动开发 BDD （Behavior-driven development）。

　　TDD
　　TDD 的思想是：先编写测试用例，再快速开发代码，然后在测试用例的保证下，可以方便安全地进行代码重构，提升应用程序的质量。
　　一言以蔽之就是通过测试来推动开发的进行。正是由于这个特点，TDD 被广泛使用于敏捷开发。
　　也就是说 TDD 模式下，首先考虑如何针对功能进行测试，然后去编写代码实现，再不断迭代，在测试用例的保证下，不断进行代码优化。
　　优点：目标明确、架构分层清晰。可保证开发代码不会偏离需求。每个阶段持续测试。
　　缺点：技术方案需要先评审结束、架构需要提前搭建好。假如需求变动，则前面步骤需要重新执行，灵活性较差。

　　BDD
　　BDD 即行为驱动开发，是敏捷开发技术之一，通过自然语言定义系统行为，以功能使用者的角度，编写需求场景，且这些行为描述可以直接形成需求文档，同时也是测试标准。
　　BDD 的思想是跳出单一的函数，针对的是行为而展开的测试。BDD 关心的是业务领域、行为方式，而不是具体的函数、方法，通过对行为的描述来验证功能的可用性。
　　BDD 使用 DSL （Domin Specific Language）领域特定语言来描述测试用例，这样编写的测试用例非常易读，看起来跟文档一样易读，BDD 的代码结构是 Given->When->Then。
　　优点：各团队的成员可以集中在一起，设计基于行为的计测试用例。

　　对比
　　根据特点也就是找到了各自的使用场景，TDD 主要针对开发中的最小单元进行测试，适合单元测试。而 BDD 针对的是行为，所以测试范围可以再大一些，在集成测试、系统测试中都可以使用。
　　TDD 编写的测试用例一般针对的是开发中的最小单元（比如某个类、函数、方法）而展开，适合单元测试。
　　BDD 编写的测试用例针对的是行为，测试范围更大一些，适合集成测试、系统测试阶段。

如何做好功能测试，提升测试质量和效率？（测试人员必知）

近些年，随着对于客户体验、管理水平、业务发展要求的提升，业务越来越复杂，迭代周期越来越快，如何做好提高功能测试质量？是很多技术负责人或者测试人员面对的问题。

下面针对自己经验，分享一下功能测试精髓。

一、功能测试面临的问题

1、测试关联度复杂

IT系统规模越来越大、集中度高、架构复杂、耦合度增强，使得业务和技术复杂度越来越高，测试设计和测试实施难度大，IT系统质量保障压力持续加大。

2、测试周期越来越短

业务需求提出到 IT 实现的周期越来越短，预留给测试的时间越来越短。面对复杂系统测试，如何压缩测试周期，提升测试效率，对测试部门管理能力和实施效率要求越来越高。

3、测试组织与协同难

测试规模越来越大、关联性越来越强，使得测试组织和协调难度大，特别是期测试外包引入后，如何有效管控，保持“大而不乱”地高效、高质量地推动测试进程，确保测试项目成功。

4、测试人员成就感低

测试人员临时抽调，团队临时组建，无归属感，成就感差; 测试团队压力大，整天忙碌，但成效差。

5、测试质量标难统一

各部门、各角色对测试标准的理解不一致，操作流程和方法运用也各不同，测试交付质量不稳定，测试交付风险依然不可控。

二、测试范围和涉及技能

三、如何做好功能测试？

做好功能测试，需要对测试过程进行全面了解和熟悉。测试过程包括需求评审、用例编写、用例评审、测试计划归档、测试执行、bug提交、bug评审、输出测试报告以及项目总结。

做好测试就是管理好测试过程，为什么要管理测试过程呢？是因为测试过程有很多不够人性的地方。比如测试人员如何去评审需求呢？用例编写有哪些方法呢？怎么快速去完成测试任务呢？bug提交又该把握什么准则呢？编写文档提交文档又有哪些注意事项呢？等等，应用测试过程管理工具就是更好的解决方案，例如：

• 需求评审，应该总结如何去保证需求的明确性和可测试性；
• 用例编写，需要总结用例编写方法、注意事项等等；
• 用例评审，应该去总结如何保证用例的简洁、明确、可操作等等；
• 测试计划归档，需要总结如何去作计划，计划归档需要检查什么内容等；
• 测试执行，需要总结针对每一个功能模块，用什么方式执行才是最全面有效的，不容易出现漏测问题，另外，还需要总结测试执行过程中需要参考的文档以及工具，让测试更加高效；
• bug提交，则需要总结如何写出一个清晰简洁的bug，方便测试和开发人员共同查阅；
• bug评审，则需要总结评审前测试人员需要做什么准备，在评审会上如何给出测试人员的意见；
• 输出测试报告，需要明确测试报告的内容以及输出方式；
• 项目总结，需要总结项目测试过程中做的好和不好的地方，好的地方需要发扬，而不好的地方需要改进，如何改进。