精选留言(13)

• 
  果然如此

  2019-05-17

  对于自动化测试一直有些疑问，如果每次发布都对所有方法自动化测试： 1. 一定会耗费很多时间； 2. 数据库产生很多测试历史数据； 3. 写测试用例能达到覆盖率高的写代码技巧，如边界测试代码、幂等测试代码如何实现。

  作者回复: 1.自动化测试确实会耗费很多时间 自动化测试代码通常是金字塔结构： 单元测试（小型测试）代码最多，执行也最快，占总比例的70%左右，通常1分钟内 集成测试（中型测试）代码其次，执行比较快，占比20%左右，控制在10分钟以内 端对端测试（大型测试）最少，执行慢，占比10%左右 一般CI里面跑单元测试和集成测试，耗时10-15分钟左右，其实还可以接收。 2. 跑自动化测试，数据库有不同策略 单元测试不访问数据库，完全模拟 集成测试只访问本机数据库，或者模拟的内存数据库，每次创建新数据库，或者使用完清空数据库 端对端测试，每次创建唯一数据（例如增加固定数据+时间戳），连接真实的测试环境，可以不清理数据 3. 高覆盖率的关键在于在写代码就注意让代码方便的被测试。也不必过于追求100%覆盖，70%以上我觉得就不错了。

  

  9
• 
  易林林

  2019-05-16

  在集中办公的时候，很多人喜欢用微信/QQ去聊工作上的事情，一会儿@这个，一会儿@那个，一些重要的信息很快就被淹没了，很难去挑出对自己有用的信息。对于这种情况，我一般很少去理会别人发了什么信息，也不会随时在电脑上开着微信/QQ等着闪亮的出现，要么通过各种管理工具沟通（邮件、Bugfree、Jira等等），要么当面或电话沟通，这样问题才能得到有效的、高效的解决。但在这样做之前，我会在合适的场合说出这样做的原因和相应的解决办法，避免让他人误解。

  展开

  作者回复: 确实，这样的频繁打扰特别影响效率。 不过我在用了Slack之后，还是改变了看法，觉得从沟通的角度看，尤其是异地办公。 沟通很及时，跟当面沟通一样 通过Channel可以对消息进行区分和过滤 通过Thread可以展开讨论以及避免对不想干人员的打扰

  

  8
• 
  宝宝太喜欢极客时间了

  2019-05-16

  老师，对测试这块一直很疑惑，测试脚本、测试用例、测试数据这三者如何配合一起通过CI进行自动化测试？

  作者回复: 是这样的，CI本质上只是一个像流水线传送带，你的代码提交了，流水线传送带开始工作，你可以在传送带上面添加任务。 简单来说，你可以想象成CI的一个任务启动后，给你一个干净的虚机（实际是运行Docker Container），然后帮你把当前代码下载下来，帮助你配置好运行环境，然后你就可以在里面安装任何软件、服务和运行任何脚本。 举例来说，你可以在传送带上增加以下任务： 1. 安装所有的依赖包 2. 运行模拟服务（比如一个内存数据库） 3. 运行单元测试 4. 运行集成测试 如果上面所有任务都成功了，那么这一次的CI任务就成功了，其中一个失败这一次的CI任务就失败了，然后你就要检查什么原因导致的，然后修复再重新执行，保障CI任务成功执行位置。

  

  4
• 
  一路向北

  2019-05-18

  用qq和微信等作为bug管理，与其说是用它来做管理，不如说是用它做驱动。很多问题是在客户那边发现，因此他们第一反馈就是即时通讯工具反馈，我们也就根据这个来解决bug问题。 对于小公司（10来个人）来说，管理一套系统和维护一个流程，总觉得需要付出比较大的代价，是不是这样呢？以前试过禅道，用了一段时间之后也放弃了。需要专门的人员来维护推动。

  展开

  作者回复: QQ作为Bug反馈是没有问题的，但是无法有效对Bug跟踪，另外效率太低。及时是通过QQ报的Bug，也应该重新录入到Bug跟踪系统，进行管理和跟踪。 自己维护一套Bug和任务跟踪系统成本是有点高，建议直接使用在线托管的，Gitlab、GitHub、腾讯、阿里云、Coding、微软都有现成的，小团队的话价钱也不高。

  

  3
• 
  谢禾急文

  2019-06-16

  看到这篇文章，我想到了我之前的一个想法，就是通过用一个工具记录我自己开发过程中遇到的所有bug，通过记录、分析、反思这些bug，能够有助于提升我的编程能力，有助于避免犯同样的错误。我觉得你上面说的那些工具，能够满足我的需求。如果有一个网站，能够提供bug记录、分享、解答的工能，是不是能够满足某些用户的需求(好像stackoverflow就是这样的工具)。

  作者回复: 我觉得是有帮助，但这个问题的关键在于分析反思Bug。 自己对自己Bug的反思才是价值最大的，其他人看过之后不一定能有那么大的共鸣，因为一个Bug都有复杂的业务背景，是很难被记录，缺少上下文也很难理解。 StackOverflow是很有价值的，因为它是从问题切入，而问题是有很多共性的，很容易引起共鸣。

  

  2
• 
  宝宝太喜欢极客时间了

  2019-05-17

  老师，测试用例英文test case为什么叫测试用例而不叫测试例呢？有没有test use case一说？

  作者回复: 抱歉这个问题我真不知道，test case的翻译也算是约定俗成的吧。 test use case我也没见过🤦‍♂️

  共 2 条评论

  2
• 
  邢爱明

  2019-05-16

  自动化测试，个人理解最大的困难是开发人员的心理和认知，理解测试工作不只是测试人员的职责，开发人员应对软件的交付质量负起更大的职责。

  作者回复: 像开发写自动化测试这样的事，一方面要提高开发人员的认知，另一方面还必须要有一些规章制度强制要求执行。

  

  2
• 
  calvins

  2020-04-07

  受教了，很多测试都明白，就是没有执行力，这篇分享了很多测试相关工具，很nice，可以更多的了解，丰富知识广度。

  作者回复: 对的，学习就是这样，知道并不难，但是真用起来就是另一回事了，建议把这门课的知识在日常项目中一点点用起来，体会一下其优点和局限性，什么场景下该应用哪些知识，这样才真的算掌握了。

  

  1
• 
  成

  2019-05-16

  服务端通过编写单元测试没啥问题，app方面好像少不了人工测试，现在测试人员主要覆盖app测试，并且每个迭代测试时间比较长，上线后问题还不少。app测试如何更好引入自动化测试？

  作者回复: 可以试试App的自动化测试框架，比如说appuim、katalon。

  

  1
• 
  yu

  2019-05-16

  程式碼就像程序員的名片，要對寫出來的代碼負責，最好的負責方式就是寫測試代碼，讓每次代碼變動，都不會影響到其他代碼的運行，避免所謂的改 A 壞 B，節省迂迴的時間浪費。也為 CI/CD 做好準備，無論目前有沒有。 程序員不想寫測試在我們公司的原因大多是，不知道怎麼開始寫，不知道重點應該測試什麼。先寫測試的開發模式讓他們覺得不習慣，但這些都是過程，培養良好的撰寫測試代碼習慣後，開發品質更有保證，提升開發效率，提升個人能力，我想都是有幫助的。 程序難免有 Bug ，透過追蹤軟件，良好的管控 Bug 數量與修復進度，並且補足測試。

  展开

  作者回复: 👍謝謝你的精彩分享

  

  1
• 
  ifelse

  2022-07-04

  如果想要最大化工具的价值，及时发现问题，还要考虑将测试工具的应用自动化，加入到你的持续集成流程中去。--记下来

  

  
• 
  小老鼠

  2019-10-02

  1、软件测试不仅仅是发现Bug，另外更重要的是预防Bug，还有为领导者作决策。2、DevOps 中测试还可以左移(预防)和右移(在生产环境中测试)。3、测试工具不是银弹，作为一名优秀的测试工程师，主力应该在分析与设计测试用例。

  作者回复: 👍赞总结。 帮你补充一条： 4. 自动化测试很重要

  共 2 条评论

  
• 
  จุ๊บ🇸

  2019-06-27

  目前java 主流的测试工具有哪些，比较稳定的，测试web及测试接口

  作者回复: 一般都是自己写框架，基于TestNG + Selenium，应该也有很多其他的选择，但是抱歉我对Java了解不多，建议可以问问其他人或者通过搜索引擎搜索一下。

  共 2 条评论

  