对于测试而言，测试之旅充满了有趣的挑战和宝贵的经验教训，良好的测试人懂得通过项目不断总结经验与汲取教训。而成功的产品离不开PD、开发、测试全体项目伙伴的通力合作。但在实际工作中，大家身处的项目往往不随人意，下面我总结下站在测试角度最讨厌的一些点：

1. 要求不明确。

需求是产品开发的基础。需求可以以规范与故事的形式呈现。但无论哪种方式，都应做到尽可能详细并做存档。

在我的职业生涯中，服务于多个公司，每个公司都会存在需求不明确的情况。

需求乃项目的基础，如果模糊不清，则会给开发和测试团队带来了挫败感。对于测试人员来说，如果产品需求设计不清楚，我很难知道要测试什么，最终可能会导致产品缺陷多以致质量差。

2. 不切实际的期望。

测试人员是质量的最后一道保障。每个人-公司、领导者、经理、产品经理、用户、客户和其他利益相关者都期望发布的产品具有高质量。

职业生涯中我有遇到过一种情况是这样的，当时测试团队被要求在2天内对产品进行完全测试并保证最终发布上线!

实际上该产品具有许多新功能以及很多严重的错误需要修复。

这给我和其他测试人员施加了压力，要求我们即便在发现了缺陷之后也要保优先发布。

另外，我之前做过一个项目，项目经理要求该项目需要实现100% 的自动化覆盖率。那就是-所有的测试用例都应该是自动化的。

有多年经验的测试人都知道，并非所有测试用例都可以自动化实现。实际在大家做的项目中，80%的测试用例实现自动化就已经很不错了。

3. 没有自动化测试。

测试有时候是无聊的。如果是手工测试，我们必须一次又一次地继续执行相同的测试用例。这也是我们觉得测试是一件无聊的事情。

而自动化测试是解决此问题的方法，自动化测试可以帮助测试提高效率并快速发现错误。

如果没有自动化测试，则测试同学会成长非常慢。

4. 测试环境不稳定。

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

稳定的测试环境必须保证线下环境和线上环境的配置、DB、代码最大程度上保持一致，并且要保证随时可用（环境拉起、销毁、代码部署等）。

工作过的这几个公司，测试环境稳定性问题始终存在，但是阿里对测试环境的管理和维护是最好的，基本上可以做到随时可用。

详情可以了解我的历史文章《阿里微服务质量保障系列：研发环境知多少》

为什么大家都这么讨厌不稳定的测试环境？

最根本的原因是环境不稳定增加测试噪音。讲个我工作中遇到的问题吧。

之前很多文章都介绍到了，我们公司的产品技术实现架构是微服务，所以不同的业务模块分别有不同的测试团队负责，这也导致上下游质量同学只对负责的业务比较熟悉，对于下游的业务不熟悉的问题。而上游的同学排查问题也第一反应找到应用报错对应的质量同学，因此下游的质量同学在工作中经常遇到上游抛来的各种报错。

我工作中遇到的一个情况是，上游的同学说他们的用例在x日突然都挂了，然后拿来让我定位问题。

我最终比较了用例报错前后的报文差异，发现报错的用例中，上游调用下游的接口时候，少传了一个字段，导致调用报错。我让他查看当前环境部署的代码是否是最新的代码。最后，果不其然是环境部署代码的问题，环境中的代码被别人部署了特定分支。

另一个后果就是，不稳定的环境会导致我们自动化用例发生不预期的报错，也会增加问题定位的时间。

5. 团队之间沟通不畅。

沟通为王。想必大家都同意这句话吧。

团队之间应该有明确地沟通诉求。产品团队应该明确地描述需求，开发人员应讲懂其代码实现逻辑，测试人应该准确地报告缺陷，任何偏差都会产生巨大的影响。

当参与产品开发的不同团队之间沟通不畅时，可能会导致测试出现问题。

作为一名负责任的测试人员，应该尽可能准确评估测试工作，并将这些信息提供给所有项目相关者。

6. 没有职业成长机会。

我相信个人成长是每个人在公司长期坚持的动力。

我为公司工作，同时也是为自己的成长工作。我希望公司发展壮大的同时，也希望自己能够成长。

但事实上，并非所有的测试人员在测试职业中有不断地成长机会，这可能会令人沮丧，并导致测试同学离开公司。而面对这种问题，领导和经理应该通过发放奖励、定期晋升、放权来激励团队。