上一篇中我们详细讲述了为什么测试是一个技术岗位，测试技术的最高岗位——测试架构师的工作角色、分工以及相关主要的工作内容。想要成为一名合格的测试工程师并不是一件容易的事情，但是想要划水的人生其实也不难。但是想必来到这里的同学一定是不甘于划水的人生，那么我们继续往下看：

软件测试的人生从测试用例开始

说到软件测试，那么我们不得不从测试的基本功测试用例的设计开始。那么首先我们应该知道测试用例是什么，这里我们引用 IEEE Standard 610 (1990) 的测试用例的定义开始：

A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
(IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.

为特定目标开发的一组测试输入，执行条件和预期结果，例如执行特定程序路径或验证是否符合特定要求。
（IEEE标准829-1983）指定测试项目的输入，预测结果和一组执行条件的文档。

软件测试用例的定义描述得非常清楚，测试用例就是一组有测试输入、执行条件和预期结果的集合。那么如何设计这样的一个测试用例呢？

我相信你从任何一个软件测试的大学教材里面都能看到，例如边界值法、等价类法、因果图法、场景法等待。只要一提到等价类方法，我相信很多小伙伴都会想起书本上的三个整型变量组成三角形的例子。这里我们不会和你一起来学习这些基本的方法，讲这些内容的书、文章等太多了。如果你对这些内容不熟悉，那么只能说你欠下的技术栈太多了，需要你自己慢慢还债。

在这本专栏中我想说一下所有的书、文章里面都没有写的，那就是这些科学的方法也不是用来解决所有测试用例设计问题的方法，就如同我们学习数学的时候，如果一道题目中有两个未知数那么我们可以通过二元方程解决，如果有一个未知数，那么我们就要用一元方程来解决一样。

等价类设计测试用例比较适合解决有很多条件组合的输入方面的测试用例的设计，场景法适合对批量任务、定时任务等业务逻辑进行测试用例设计，边界值适合于一个输入框的测试用例设计，同时边界值还可以和正交试验方法进行组合使用，因果图方法比较适合有相互约束的功能的测试用例设计。

无论你是一个测试经理还是一个测试工程师，甚至你是一个测试开发工程师，你也需要知道这些科学的方法，这些科学的方式是软件测试中输入项的有效的设计方法，在工作中使用这些科学的方法设计测试用例，可以使你的测试工作更加得可靠和可信。

选择技术还是选择业务

伴随着工作年限的提供，所有人都在面向于业务或者技术的一个选择。

测试工程师

这上面是完全不同的两条路，一个是走纯业务路线，即测试工程师。测试工程师对自己负责业务很了解，对所有细枝末节的流程都很清楚。在一个团队中，产品经理对每次新 feature 很了解，因为是他设计的，他有可能也对一些和这些新设计的 feature 相关联的一些业务逻辑也很清楚，但是他对上上一次乃至更久之前的迭代的 feature 有可能并不了解。

开发工程师对本次开发的功能很熟悉，并且对和本次迭代的feature有交集的一些内容了解，但是对历史版本的逻辑并不清楚。这里面唯独业务测试工程师对某一个被测试系统所有的 feature 都很了解，这样他才能更好地评估一个系统的质量。随着业务测试工程师的努力，慢慢地会变成测试负责人或者一个对应业务领域的专家。

测试开发工程师

如果要选择测试开发这条路，那么你会走上一个半测试、半开发的路，在这条职业生涯的路上，你会不断地coding，不断重新定义测试。从自动化脚本的撰写到测试框架的设计、开发和维护，从测试执行到测试平台的研发和搭建，然后慢慢走向高级测试开发工程师的道路，推进项目级别的持续集成、持续交付、持续部署的进程，推进工程效率的不断提高。最后会走上测试架构师的角色，这个时候你有可能更加贴合实际，更加的底层。在某一项技术的细节上和开发架构师的知识库和技能库相差无几，但是又多出了很多DevOps相关的内容知识体系，是真个团队的自动化程度的推进者，或者发展成一个测试开发负责人，管理team内部的交付周期，推动过程化测试进程。

该选择那一条路？

随着测试自动化的发展，测试开发工程师和测试工程师最终变成一个矛盾体，测试开发工程师在推动团队内的自动化程度，通过不断地开发、引进和探索，释放大量的业务测试的手工测试工作量。业务测试工程师的很多工作越来越多的交由机器来完成，业务测试工程师会逐渐的变成整个测试进度、测试进程的决策者，辅助测试工具链最终完成测试，并评审最终的测试结果。

但是如今市场已经越来越多地开始意识到了自动化可以给团队交付效率带来的红利，因此现在的一个纯业务测试工程师的工作机会越来越少了，因此我还是建议很多人选择第二条路，无论你现在是中级业务测试工程师还是高级业务测试工程师，都要尝试着去学习测试开发的技术，给自己充电。

测试的技术栈

在掌握测试理论基础之上你还需要知道如下的知识内容：

• HTTP协议等一些相关的通信协议，掌握各种各样的协议截获方法；
• 开发的专业术语：序列化、MVC、NIO等内容；
• 自动化测试框架（这里面包含了WebUI、AppUI和API相关的自动化测试框架）；
• 性能测试工具；
• Linux操作系统相关操作方法；
• 数据库的一些查询方法语句；
• 各种消息、协议的模拟手段；
• 理解持续集成、持续交付、持续集成和DevOps；
• 了解敏捷，懂得精益，会用看板；
• 懂得容器化以及容器编排；
• 会一种coding的技术（有基础的你会什么就深入学习一下对应的，要是都没有建议学习python）。

上面都是很多星星点点的一些知识点，最后要通过 DevOps 类的平台可以流程化你的技术体系，达到一种可以通过端到端交付效果的过程。

总结

今天我们从软件测试工程师基本功测试用例设计开始，讨论了测试职业生涯的两条路，但是就与当今招聘市场的需求，建议大家都多少走到第二条路上。最后介绍了要走上第二条路需要逐渐学习的一些内容，以及对大家的一些建议。