一套标准化的测试流程能够让软件的每次版本迭代都能保持稳定，每次的手动测试过程其实都是重复性劳动，这个过程很容易让人感到疲累。
前言
在软件的开发过程中，如果有新需求或者旧的功能发生变更，都需要对变更后的功能进行测试。在我们的 App 以及几个 Web 项目中，目前的测试主要依靠的是下面几种方式：
- 开发工程师实现功能后的自测。
- 功能发布到生产环境后对新功能的简单测试。
- 用户正常使用软件发现问题。
在我看来，上面的测试步骤有如下几个问题：
- 测试的覆盖面不够高。按照上面的步骤进行测试，可以暴露出一些常规的问题。但由于测试没有一份指南参考，因此每次可能都会遗漏一些特殊的情况没有测试到。
- 一些功能的改动可能会对之前既有的功能造成影响。比如在我们的
App中，给每个用户增加了一个商友名，与真实姓名区分开，这个修改点看似很小，但是实际上是非常大的，因为涉及的功能很多，而在之后的测试中，所有这些受影响的功能都需要同步进行测试。
而对于上面的两个问题，在引入系统性的软件测试流程后，就能在一定程度上进行弥补。
选择合适的测试方法
系统性的软件测试包含的内容比较多，按照设计方法可以分成 黑盒测试 和 白盒测试，按照测试类型可以分成 手动测试 和 自动测试，按照目的还能分成 功能测试、非功能测试、性能测试 等。
由于缺少专业的测试工程师，如果引入完整的软件测试流程，那工作量是很大的。因此可以挑选几个适合现有 App 的测试方法，下面是我认为其中几个比较合适的方法：
- 编写测试用例：增加测试的覆盖度，可以按照 [模块] - [功能] 的粒度来编写测试用例。
- 回归测试：对于一个新版本的
App，每次都重新进行一遍以前的测试用例，可以及时发现新功能对既有功能是否有影响。 - 增加探索式测试。这个就是依靠测试人员的感觉来进行，随机性的对
App的功能进行测试，有时测试用例编写的可能不是很完善，这个操作可以发现一些测试用例没有覆盖到的情况。
目前的选择的测试方法优先以 手动测试 为主，后期待测试用例完善之后，可以考虑增加 自动化测试（工作量比较大）。
另外补充一点，如果盲目的引入软件测试这套流程，可能会导致过程过于冗余繁琐，并且会增加开发和测试的负担。因此是否需要引入或者如何引入，还需要视具体情况而定。
软件测试学习
关于 软件测试概念 的介绍可以参考这篇文章：软件测试 (一) 软件测试方法大汇总。
关于 设计测试用例 的方法可以参考这篇文章：使用模板快速编写测试用例 - 美团技术团队。
关于 自动化测试 的搭建方法可以参考这篇文章：如何从零开始搭建公司自动化测试框架？
如果想 系统性的学习软件测试的知识，可以看看这篇专栏： 软件测试52讲