32 软件测试：什么样的公司需要专职测试？
你好，我是宝玉，我今天想与你讨论一下，什么样的公司需要专职测试这个问题。
若干年前，网络上对于软件开发是否需要专职测试有过一次讨论，代表文章有：左耳朵耗子老师写的《我们需要专职的QA吗？》，然后邹欣老师对此回复《测试QA的角色和分工》。
从这些年业界发展趋势来看，看起来很多公司都不需要专职测试了，只需要开发兼任测试工作就可以了。比如，Facebook号称自己没有专职测试工程师，Google和Amazon虽然有专职的测试工程师，但都是开发人员对质量负责，开发人员写大量的自动化测试代码。但这样真的可行吗？
在回答这个问题之前，我们还是先来看看，软件测试的主要工作是什么？只有搞清楚软件测试的工作，才能搞清楚这部分工作是否可以由开发来替代，是否需要专职测试。
软件测试的主要工作是什么？
在前面开发篇内容的学习中，我们对开发的工作已经比较了解了：在需求确定后，开发人员开始针对需求进行架构设计，然后编码，最后对发现的Bug进行修复，保障线上稳定运行。
而软件测试也类似，也是从需求开始，在需求确定后要去对需求进行分析，然后做测试设计。
如果说架构设计是对业务需求在技术方面的抽象，那么测试设计更像是对业务需求的具象，把业务需求分解成一个个具体的用户操作步骤，也就是测试用例。然后在开发完成后，按照设计好的测试用例进行逐一的测试验证，将发现的Bug报告给开发人员，并跟踪Bug的修复。
如果对软件测试的工作简单总结一下，就是发现Bug，报告Bug，跟踪Bug。
软件测试怎么发现Bug？
这里面最难的就是发现Bug，尤其是如何尽早、尽可能全面地发现Bug。
举个例子来说，如果现在你需要开发一个用户登录的功能，你在开发完成后会怎么测试？
一个普通的程序员通常只会简单测试一下以下用例：
- 输入正确的用户名、密码，能登录；
- 输入错误的用户名密码，提示错误，不能登录。
而一个有经验的程序员还会测试一下其他情况，例如：
- 用户名或者密码为空，是否提示错误；
- 没有注册的用户名和密码，是否会提示错误。
但如果是一个专业的测试人员来测试，是不是只做上面的测试就够了呢？专业测试还会测试哪些内容呢？
对于专业测试人员来说，上面这些肯定是不够的，还需要有以下这些情况的功能性测试：
- 用户名密码是否大小写敏感；
- 用户名或密码如果是用特殊字符，会不会导致程序异常；
- 用户名或密码如果特别长，是不是会有异常；
- 是不是所有主流浏览器和终端设备都能使用。
这就完了吗？并没有。除了功能性的测试，还需要进行非功能性的测试，也就是像性能、安全性和用户体验等方面的测试。比如以下测试用例：
- 是否可以通过发送数据包反复登录，暴力破解密码；
- 会不会有SQL注入的风险；
- 大量用户同时登录，页面会不会崩溃；
- 用键盘tab、回车键是否可以操作。
当然还会有其他测试用例，这里就不一一列举。为什么专业测试人员和开发人员的测试用例会差这么多？
因为开发人员的重点，是放在如何实现功能上，就拿上面用户登录的例子，开发人员会想着如何能校验用户输入的用户名密码，并给出相应的提示，对于异常流程和场景会相对考虑较少。
而对于测试人员来说，重点是在检测，也就是会考虑所有可能的用户使用场景，正常的、异常的，甚至各种极端情况，例如大量并发访问、黑客恶意破解，所以他们能想到更多、更全面的测试用例。
测试人员设计测试用例，就是要尽可能做到覆盖所有用户操作的可能，但理论上来说这是不可能的，因为组合是有无限多个的。不过从测试的角度看，没有必要每一个可能都去测试，可以通过一些科学的方法来通过有限的测试用例，保证尽可能多的测试覆盖。
有哪些方法呢？我给你举几个例子：
- 等价类划分
就是把所有用户可能输入的数据分类，如果一类数据对于发现Bug的效果是一样的，那么这类数据就是一个等价类，测试的时候只要从里面任意选取一个值就好了。比如一个输入框要求只能输入1-100之间的整数，那么1到100之间都是等价的，0和任意负数也是等价的，101和之上的整数也是等价的。
因为分类是有限的，这样就可以用有限的测试用例实现尽可能多的测试覆盖。
- 边界值分析
边界值是对等价类的补充，因为输入输出的边界是非常容易出错的一个地方。比如说上面输入框的例子，0，1，100，101都是边界值，可以设计用例来测试是否会有可能出错。
- 探索性测试
探索性测试就是根据前面的测试结果，通过有效的策略进行测试。
举例来说，如果你玩过RPG游戏的话，里面通常会有走迷宫的地图，各种分叉，不同的分叉可能有不用的宝箱，如果你想打开所有的宝箱，那么就可以在遇到分叉的时候，每次优先走右边的分叉，除非右边已经去过了。
那么这里“右边的分叉是不是走过了”，就属于已经测试过的结果，策略就是优先走右边的分叉。关于探索性测试的介绍可以参考这篇文章《探索性测试揭秘》。
当然除了以上这几个主要的策略，还有很多其他的策略，比如说：
- 场景设计；
- 因果图；
- 错误推测法。
这里我就不一一介绍，推荐阅读《微软的软件测试之道》，这本书上有很多具体的测试方法的详细介绍。
借助这些方法，测试人员就可以对需求功能设计出完整的、有较高覆盖率的测试用例。
所以，有时候测试人员的工作看起来不过是用鼠标点点测试，但他们在拿到需求后，其实花了很多时间和精力分析需求，然后根据需求设计测试用例，准备测试数据。等到开发人员完成软件开发后，就按照设计好的测试用例逐一测试，这样就可以做到及时发现Bug。
软件测试怎么报告Bug？
在测试的过程中，如果测试人员发现了Bug，就会通过Bug跟踪系统提交Bug给开发人员。Bug跟踪系统其实跟我们在《14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决》中介绍的任务跟踪系统是一样的，它可以方便地提交和跟踪Bug。
测试人员要做的就是创建一个新的Ticket，在Ticket的描述中，详细说明Bug是什么，具体的重现步骤，必要的话还要附上截图、日志等辅助信息。这样开发人员在收到Bug后就能快速定位问题，按照优先级对Bug进行修复。
软件测试怎么跟踪Bug？
Bug的跟踪，并不仅仅是要跟踪开发人员什么时候修复了这个Bug，通常还包括对Bug修复的验证。
开发人员修复完一个Bug后，测试人员首先会验证这个Bug是不是真的被修复了，然后还要对整体功能做一个回归测试，确保不会因为修复Bug而引起其他功能出现问题。
回归测试是指修改了旧代码后重新进行测试，以确认修改没有引入新的错误或导致其他代码产生错误。
回归测试这一步很重要，因为通常开发人员在修复完Bug后，只会验证其修复的Bug，而不会验证其他功能是不是会有影响。但实际上，软件项目中经常会出现修复一个Bug，而导致系统其他功能出现问题的情况。回归测试，则能有效、及时地发现修复Bug导致系统不稳定的情况。
什么样的公司需要专职测试？
了解了测试的主要工作内容之后，我们再回过头来看看今天要讨论的问题：什么样的公司需要专职测试。
如果一个公司不需要专职测试，那么意味着专职测试的工作可以被其他工种替代，比如说由开发人员一起完成软件测试的工作。
想象一下，如果你是一名开发工程师，然后你要兼职做测试，那么你需要额外做好哪些工作？
首先，你在拿到需求后，除了做技术上的设计外，还需要做测试上的设计，借助测试方法设计测试用例。
这样做好处很明显，可以在写程序时，让程序更易于测试，设计时会对需求考虑更全面。缺点也显而易见，你不只要学习编程知识、了解业务，还要学习测试方法。也许对你来说可以做到，但是对于绝大多数开发人员来说，这是一个很高的要求。
然后在开发完成后，要对自己写的程序进行测试。这里可能存在一个问题，也就是如果你在程序实现的时候，漏掉了一个逻辑处理，比如说漏了检测SQL注入，那么你在测试的时候也不会想到要去测试这部分。
测试自己的程序还要克服一个心理障碍，就是要对自己的程序进行破坏性测试，才可能找到潜在的问题，但去“破坏”自己完美的程序，对大多数开发人员来说也是很难接受的一件事。
如果上面两个问题都能克服，你还得再考虑一个问题：如果项目进度比较吃紧，作为开发人员你会压缩哪部分时间？
正常来讲，测试时间必然要被压缩的，因为你首先得保证代码实现。这可能就导致只要项目进度一紧张，测试就被严重压缩了，进而会严重影响质量。
这样看来，完全由开发人员兼职测试，还是很有难度的，不仅对开发人员要求非常高，而且需要开发人员承担所有的开发和测试的压力。
为什么Facebook可以做到没有专职测试呢？
首先Facebook的工程师水平确实是高于业界平均水平的，有能力同时做好开发和部分测试工作；
其次，Facebook的产品周期相对宽松，可以有时间完成自动化测试代码；
Facebook在功能发布之前，先发布新功能到内部环境，几千内部员工先测试，部分充当了测试人员角色；
Facebook的发布和监控也比较完善，有问题能通过监控及时发现，并且可以随时快速回滚或者发布补丁；
最后就是用户对这类社交产品的Bug相对容忍度比较高，想想看如果是波音飞机上的软件能这么做吗？
至于Google和Amazon这些公司，他们也是类似的情况：
- 大量优秀的工程师，可以同时兼任开发和测试；
- 有大量的自动化测试代码覆盖；
- 强大的发布和监控系统；
- 时间进度比较宽松；
- 用户对Bug容忍度较高。
- 对于不能满足上面条件的公司，有专职的测试是更有利于软件项目开发和质量保障的。
大厂不设专职测试的启示
虽然对于大部分公司来说，要做到完全没有专职测试还不现实，但这些大厂不设专职测试的实践还是有值得借鉴和思考的地方。
首先，用自动化测试代替重复性的手工测试是必然趋势。随着自动化测试技术的成熟，写自动化测试代码的成本逐步降低，而自动化测试，尤其是像回归测试这种需要频繁进行的，可以极大提高测试效率。
其次，测试设计是软件测试人员的核心竞争力。无论是自动化测试还是手工测试，测试用例是核心。无效的测试用例，用任何方法去测试，都不会达到良好的测试目的，只有测试用例设计好了，真正做到有效高覆盖，测试才是高质量的。
最后，开发人员和测试人员的更多融合是一种双赢。比如说测试人员可以给开发人员提供测试用例作为测试参考，开发人员可以写更多自动化测试代码，这些方式都能有效保障产品质量。
总结
今天我带你一起分析了什么样的公司需要专职测试。同时也学习了软件测试的一些基本知识，简单来说软件测试的工作，就是发现Bug，报告Bug，跟踪Bug。
要能及时发现Bug，需要针对需求进行分析和测试设计，把需求具象成一个个用户操作步骤的测试用例。通过一些科学的测试方法，像等价类划分、边界值分析、探索性测试，能有效提升测试的覆盖率。
公司是否需要专职测试，还是取决于公司的具体情况，例如是否有大量优秀的工程师可以同时兼任开发和测试，有大量的自动化测试代码覆盖，有强大的发布和监控系统，进度宽松，用户对Bug容忍度较高。
课后思考
你们公司有专职测试吗？你觉得是否应该保留专职测试？为什么？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
- 砍你一刀 👍（11） 💬（1）
老师您好，能发不分享一个比较好的测试用例模板，谢谢
2019-05-17 - 拉欧 👍（9） 💬（1）
对于中国的开发，最大的瓶颈一是时间二是心理，需求都做不过来的时候很难考虑测试的完整性；破坏性测试本身是反程序员思维的，要突破这层心理也要专门的训练才可以
2019-05-14 - 邢爱明 👍（7） 💬（1）
谁来做测试工作，这也是我一直比较疑惑的地方，和大家探讨一下。 我现在是甲方，主要做的是企业管理软件，业务逻辑和流程控制都比较复杂，部分系统是需要一些领域的专业知识。 软件开发的时候，基本采用的是瀑布模式。首先由专门的人员做需求澄清，分析和设计，一般我们称为业务分析师，他们这些人会输出软件的需求规格说明书，包括软件原型、详细说明word文件，然后交给开发团队进行功能设计、开发和交付。 在这种模式下，是否需要专职的软件测试人员，有两种意见。 第一种意见认为不需要测试人员，原因是业务逻辑复杂性，找一个普通的外部测试人员进来，还需要花较长的时间去了解需求，学习如何操作一些专业的应用软件，还需业务分析师花费宝贵的时间去做辅导学习。如果不让测试人员学习，就只能测试一些很简单的功能，对把控整个软件交付的质量作用非常小。解决方案就是让业务分析师兼职做测试工作，因为对需求本身非常清楚，学一点测试基础知识，在付出点加班时间，也是能完成功能测试工作的。 第二种观点是认为需要专职的测试人员，因为上一种方案中，需求分析师大部分做的还是正向测试，即按照自己设计的功能和流程，判断软件交付是否合格。但是对异常场景的测试还是比较少的，会导致软件上线后，在用户实际操作过程和设想的不同的时候，往往会出现一些功能异常，给用户的直接感受就是软件不稳定。所以说希望通过专业的测试人员，多采用一些探索式的测试方法，尽量多地发现软件中存在的缺陷，提升交付质量。 请老师帮忙分析一下，哪种方案更加合理一点？ 我现在的做法比较折中，如果项目级别低、时间紧，预算也不充分，就采用第一种方案。 但如果项目重要度比较高，出了质量问题大家都接受不了，就想办法让项目经理多争取预算，保证有充分的外部测试资源投入。
2019-05-15 - 许童童 👍（5） 💬（1）
如果测试的工资能够给到开发的话，我觉得作为开发，就不需要专职的测试人员了。
2019-05-14 - 易林林 👍（5） 💬（1）
个人认为专职测试是必须的，但他们的主要职责不是测试软件Bug的存在，而是提供系统化的测试解决方案，指导构建完善的自动化测试系统，去引导和培训开发人员完成一系列的测试工作，去监督软件测试的过程和结果，随时提出建设性的意见和建议。最终目标是实现：谁污染谁治理的策略，也就是开发人员要对自己的产出负责，不对测试人员产生心理上的依赖，最大化的从源头上解决问题，以减少问题的传递链路。 另外，向宝玉老师请教下：最近发现一种现象是开发人员面对测试人员的时候，会展现出一种职业选手遇到业余选手的姿态，有傲慢有理所当然，我觉得这是一种不正常的心理状态。您觉得应该怎么去管理？
2019-05-14 - 纯洁的憎恶 👍（5） 💬（1）
我们公司软件开发采用外包团队，IBM是我们最主要的开发商。但是，开发团队从leader到顾问，再到开发工程师几乎都是IBM在市场上招的临时人员，没有IBM正式员工。给我的感觉是这些人工作非常认真负责、执行力强，但是业务能力确实比较普通。比如他们不用软件工程管理工具，更不要提自动化测试、持续集成和敏捷开发了。还有没有专职的测试人员，业务顾问和开发人员一起测试，回滚也是纯手工，耗时耗力经常加班。我觉得IBM的牌子不至于这样吧，于是私下调研了一下，感觉成本因素影响很大。IBM也有很专业的团队，但基本负责内部软件建设，即使提供外部服务价格也要高出一个数量级。
2019-05-14 - Charles 👍（3） 💬（1）
我经历过一个项目刚开始没有专职测试，研发部门和其他业务部门一起做测试，研发部门找到的问题更多的是老师文章中讲的程序员正向思维下的功能bug，而其他业务部门更像是用户，主要走的是正常的使用流程，根本没办法覆盖到特殊的边界类测试，后来招了专职测试才体会到什么叫专业的测试设计，虽然可能不是最好的，但是也比非专职的要好太多了，线上问题明显减少，所以我认为专职测试必须的 另外有一个题外问题，不知道老师是否可以给点建议，创业做软件外包或技术服务的公司目前的市场环境还有出路吗？
2019-05-15 - ikel 👍（2） 💬（2）
我们公司有专门的测试。就是流动性比较大，新人老是向开发咨询问题，测试内部缺失有力的培训。
2019-05-15 - 谭鹏 👍（2） 💬（1）
移动端的测试 都是靠手工操作 而且是程序员 自测 先把测试用例写出来 给测试 。测试看都不看 直接 动手测试
2019-05-15 - 胖虫子 👍（1） 💬（1）
要求测试懂开发，那直接做开发不完了。工资还高不是
2019-11-18 - 小老鼠 👍（1） 💬（1）
我是一名软件测试专家，1997年从事开发、2002年从事软件测试。现在都在说去QE，全栈软件工程师。我认为认为这是错误的，术业有专攻，闻道有先后，这是非常有道理的，让专业人来作专业事。我认为不是去QE，而是如何更友好地让开发与测试有效沟通，比如可让测试去设计测试用例，开发编码完毕去执行。另外现在有许多公司都在快速发布，快速迭代，您说他们时间宽裕吗，No，只是对质量要求不高而已。
2019-08-16 - beiler 👍（1） 💬（1）
老师，最近公司需求，发现手动测试接口效率非常低，我计划做一套自动化测试框架，我之前试用了jmeter，发现写代码太费事，我计划用python写，这样我盯住接口协议即可，不知道老师你们用的接口协议管理软件是什么？是rap2还是swagger，这俩哪个更易于导出json接口，进行自动化测试
2019-06-01 - 和 👍（1） 💬（3）
我的单位，当然不是软件公司喽，但是企业内部也会开发一些业务类软件。可是从需求分析到设计，开发，测试，部署，运维，都是我一个人的工作。请问老师，这样的情况，您觉得如何工作，效果会更好一些呢
2019-05-22 - hua168 👍（1） 💬（1）
老师，现在不是流行，测试驱动开发吗？不是先写测试代码再写实现代码的吗？ 那还完写完再让专门的测试去测？
2019-05-20 - 纯洁的憎恶 👍（1） 💬（1）
看来是否需要专职测试人员，在一定程度上需要视具体业务情境而定。不同的情境会有不同的异常情况和极端情况，需要有针对性的设计出完备的测试用例。而且在bug修复后，也要保证修复本身没有bug。所以测试也是一个系统性的工作，如果取消专职测试人员，不仅对开发业务水平要求更高，还需要项目自身的不确定性低一些。感觉有测试思维的发开人员，更有可能写出健壮的代码。
2019-05-15