敏捷开发中测试角色的窘境

Posted 2023-02-26 yzsind

敏捷开发中测试角色的窘境

先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇：

------------------------------------------------------------------------------------------------------------------------------

测试妹妹:需求文档在哪里？
码农哥哥:这个...，没有需求文档，产品经理发了我一句话，后来直接和我说了要求，很简单，我和你再讲一下吧。
测试妹妹:好吧，懂了，那我开始测了。

测试妹妹:测试完了，有5个bug，我都提交了，你看看吧。
码农哥哥:好的，还有一个新需求，再和你讲一下。

测试妹妹:终于测完了，全部测试通过了，恭喜啊
码农哥哥:sorry,刚我改动了一个小点，你再重新回归测试一次吧，这次应该OK了。
测试妹妹:终于回归完了，又发现一个问题...

产品经理:客户反馈了一个bug，你赶紧看看
码农哥哥:不可能啊，这个功能我都测过的，我看看
码农哥哥:真晕，线下测试是好，线上有问题，有个配置错了，另外这个客户的数据比较奇怪，测试也没有验证过这种场景
产品经理:XXXXXX，客户已经提故障了！
码农哥哥:下次线上发布一定要叫上测试妹妹仔细回归

码农哥哥:今天晚上12点产品更新，到时要你来回归验证啊
测试妹妹:好吧
测试妹妹:你们发布完了吗？都凌晨2点了，我什么时间可以回归验证啊？
码农哥哥:再等等，还有一个小问题在搞。
测试妹妹:现在好了吗？
码农哥哥:sorry，没搞定，发布要回滚了，今天不需要回归验证了，你先回去吧
测试妹妹:你妹啊！！！

------------------------------------------------------------------------------------------------------------------------------

故事讲完了，以上就是一些项目敏捷开发中很常见的问题。

敏捷开发强调的是快速迭代，通过快速迭代发布并验证产品是否满足用户需求来减少产品风险，而不是像传统软件一个花一年甚至几年才发布。敏捷开发在互联网行业里非常流行，大型网站基本每周都会有发布，甚至一周发布几次，超大型网站的应用都是分布式的，一天都可以发布上百个feature。
互联网的需求变化很快，有些产品也是实验性的，所以更需要快速迭代，这也会导致许多产品在一些小的需求都没有需求说明书或者设计文档，全是靠产品经理与研发同学沟通需求，然后就快速发布上线了。这种模式在传统软件里是不可能，传统软件都会有很强的产品版本概念，并且会对每次升级都要制定详细的设计、开发、删除与发布计划。 

面对互联网这种快速迭代，并且还有时缺少需求与设计文档的背景下，我们测试同学如何跟上节奏。如果按传统模式，测试与研发是不同的人员负责，那么必需要有清晰的需求设计文档，否则测试基本靠感觉。并且产品经理与研发同学还要与测试同学沟通需求，沟通项目计划与资源协同。第二，今天互联网的研发同学普遍比测试同学多很多，有些产品甚至是10:1以上或者是没有测试角色，这样的团队测试同学根本来不及了解需求细节，只能做一些核心主功能验证，对于边界测试没法顾上。总体看起来独立测试角色在敏捷开发里有点力不从心。

经过几十年的发展，测试类型也细分成很多种，有白盒测试、黑盒测试、灰盒测试、单元测试、功能测试、集成测度、性能测试、压力测试、自动化测试、回归测试、灰度测试、安全测试、恢复测试等等概念。 当前业界的测试工具眼花缭乱，有QTP/UTF、LoadRunner、JMeter、Selenium、TestDirector、QACenter、Rational系列等知名产品，也有很多JUnit、TestNG、RobotFramework、gtest等测试框架，还有更多如网络、数据库、硬件等专业领域的测试工具。

这些产品，除了JUnit、JMeter这类程序员可以轻松掌握的轻量级产品框架外，其它产品在敏捷开发中都感觉力不从心，主要原因是大部份产品为测试角色开发的，研发角色有学习成本，并且研发同学更喜欢白盒测试。

如果测试的工作由研发来完成，这会更符合敏捷开发思想，大大减少沟通成本。但是问题来了，研发同学并不擅长使用各种测试工具，研发同学更多只会完成单元测试。如果能有一个专门面向研发同学的测试工具，岂不是很爽，那一个面向研发同学的测试工具应该是什么样的呢？我先说说程序员自测的一些现状：

1.单元测试：

目前JUnit、TestNG加各种Mock基本还能应付，就是测试代码写起来很多

2.功能测试：

这个很头疼，如果软件有界面，可以通过软件操作来完成核心功能测试，如果没有界面，就自己模拟软件对外API接口规约来模拟测试

3.性能测试：

这个要么使用JMeter这样专业工具来完成，实在不行，要不就自己再单独写一个程序或脚本来压测

4.回归测试：

不好搞，面对各种运行环境，人工回归太不靠谱了，真心需要一个全自动化的工具

5.安全测试：

太专业了，估计搞不定

6.边界测试：

写各种边界值来搞死自己，想到的就试试，没想到的就当不存在了

7.bug管理：

都自己测试了，还提个毛bug啊，自己老老实实把屁股擦干净

从上面看起来，要是交给程序员自测也不靠谱啊，完全是靠感觉，凭经验测试了。

如果有一款 面向程序员自测的专业测试工具，它会是什么样的呢，我列了几点：

1.学习成本低

上手很容易，如果是框架，不要超过JUnit这样的难度吧，如果是产品，那应该有一套简单易用的界面，并且不要冒出很多测试概念，不要动不动就来1GB的安装文件，最好能免安装了。

2.功能测试用例编写简单

编写功能测试用例，不要只是简单的像bug管理那样写一堆文字描述，测试用例应该是可以运行的，编写完后就能直接运行、验证
用例编写的语言应该非常简单易学，或者是直接用程序同样的语言(如JAVA、C、Python等)，不要让我去学习一套新的语言或规范
测试用例的代码应该很短，不要是我的业务程序写了100行代码，结果测试用例写了300行代码，这会很奔溃，可能会导致我花了大量的时间在调试测试用例脚本是否正确，如果测试代码小于程序代码的1/5就挺好。

3.功能测试用例能同样显示测试代码覆盖率等信息

单元测试可以比较简单的看到测试代码覆盖率，查看未测试到的代码。这个很有用，功能自动化测试希望也能看到这个，这样可以确认哪些地方没有测试到位。

4.可重用，可扩展

    有些组件是已经写好的，测试用例应该能直接复用，比如java中一些标准jar包函数，或者是自己产品里封装的组件。这样对于编写测试就更高效了。
扩展性要好，自己也可以封装一些测试组件，供别人使用或者模块公用。

5.可以自动化回归测试

面对各种环境：开发环境、测试环境、预发环境、生产环境A、生产环境B，自动化回归测试太重要了，最好是功能测试用例编写完后可以直接用在回归测试里，不要又单独写一套回测试用例。

6.能自动造测试数据

造测试数据很花时间，有时还需要造各种随机数据，另外各种边界数据也能自动化最好了，靠人想有时不靠谱的

7.能支持UI自动化测试

现在UI测试基本靠人工，Selenium之类的产品IDE比较简陋，语法也需要重新学习，学习成果不低，而且有点地方写起来很难受。需要能有更高效的UI自动化测试支持。

8.调试方便

  编写测试用例脚本要有方便的调试功能，用例运行过程希望能显示详细的输出日志，特别是在用例运行失败的情况下，不然找问题很花时间。

9.免费、开源

你懂的

最近自己团队也在做这方面的探索，希望能设计出一个适合程序员自测的专业测试工具与方案。 
好了，写了这么多点，可能我孤陋寡闻，也不知道是否已经有这样专业的产品，谢谢推荐。