江苏龙网

  1. 首页 > 生活 > >

产品团队实践单元测试和持续集成的疑问

谢邀。
我的看法是不合适，我觉得你们需要立即做的应该是持续集成，集成后的自动测试，其次才是单元测试。
先至少分出半个人做配置管理和持续集成，然后至少一个人做集成后的自动测试。单元测试不用急，慢慢增加，单元测试想要做好的话，是非常花资源的。如果用功能测试能够覆盖的需求部分，可以用手工和自动测试来覆盖，其他不好测的点，可以让开发在单元测试过程中验证，这样能用把有限的资源充分利用起来。

我的专栏欢迎你的关注。
Python实践之路
觉得有道理的话别忘了点赞让更多人看到。
做了一年的软件功能测试，想转自动化测试。目前在看了一些Python资料，感觉无从下手，求指导？
接口测试？
如何保证接口测试的覆盖率？
做接口测试的流程一般是怎么样的？
接口测试的数据如何回归？
如何写出高效的软件测试用例？
软件测试工程师，2年半工作经验，第一次跳槽，如何快速融入团队？
做测试，写了一周的测试 用例，感觉自己已经是个文员了,怎么办？
【产品团队实践单元测试和持续集成的疑问】 该怎么样才能让所有测试人员迅速学会自动化测试呢？
测试人力不足时，测试技术层面有什么方法可以提高测试效率？
怎么判断哪些功能能实现自动化？

■网友
谢邀。说实话，我不是很清楚你问这个问题的具体顾虑是什么。单元测试一般有开发人员来完成自测，特别你提到了现有团队测试人员的编码能力或许并不突出。那么就在每次开发人员安排单元测试自测好了，当然可以由测试人员去驱动这样的测试，比如提供测试需求，由开发人员编码实现。至于持续集成么，也没看出来不合适的地方。特别是你们还有一个已经运营了6年的产品。交由持续集成来完成自动编译（定时）工作也是可以的，甚至可以把单元测试的代码与 CI系统集成起来，在每次自动编译完成之后进行自动化的单元测试。总之，我认为这些活动并没有什么特别的适不适合的点，完全可以开展，愈早开展愈好。
■网友
对于一款已经运行的产品，同样建议首先实现持续集成，并对新加入的功能实现单元测试（DEV负责）。在此基础上，自动化基于UI的系统测试（QA负责），比如使用SELENIUM之类的工具。如果有条件、有能力，再对之前的代码加入单元测试。
■网友
首先要搞清楚单元测试是什么? 单元测试需要开发人员编写大量的白盒单元测试代码，而且所有场景要覆盖的话需要大量的时间，代码量本身也是功能模块代码量的好几倍。对于你有两名专门的测试人员，给你的建议是单元测试不要做，但是需要做每日构建和冒烟测试，持续集成的，每天都进行版本构建，构建完成后交给测试人员冒烟测试，使整个开发进度可视化。
■网友
1.单元测试，由程序开发者写的，因为写这种测试需要使用某种测试框架来编写代码，要调用API，还要表述底层逻辑—这些都是程序员擅长做的事情。测试人员并非开发人员出生，所以这个有点麻烦2.持续集成，个人认为是一种意识思维，让团队在持续的基础 上收到反馈并进行改进。这种意识是要慢慢培养的。


    推荐阅读


    上一篇：怎样解决亚马逊Kindle电子书商场资源少的问题

    下一篇：有啥好的试客网站求推荐