boweiqiang的博客

软件难用，不是：我们做的不好。而是：用户不会用。

一个好的测试工程师，是将问题扼杀在摇篮里，还是事后写工具发现问题？

每个模块都这么配置的话，生成的报告是各自独立的，即会生成3个报告，那么怎么把各个模块的代码覆盖率统计在一起，生成一个聚合的报告呢？jacoco在prepare-agent阶段会生成一个属性指向jacoco的runtime agent，默认这个属性叫argLine，我们需要在maven-surefire-plugin的配置中，引用这个属性（当然我们也可以自定义这个属性的名字，那么就需要在maven-surefire-plugin的配置中引用我们自定义的属性名）

在经历过的创业公司中，我经常看到下面这些情况：兢兢业业，认真负责的测试，很容易被认为是一个“事多”的人 审时度势，得过且过的测试，虽然人缘颇好，但因为经常背线上的锅，也是颇多怨词何为事多？就是有一些产品和开发看来没必要提的bug，但仍然被测试提了。什么样的bug是没必要提的bug，这里面恐怕颇多争议，我们来举几个例子：bug1：如果老师没有使用授课系统上课，但是布置了作业，进入到查...

先来看一个段子：我的答案：无论怎么测试都不能保证系统100%没有问题再看看朋友群里的讨论：你看，每个人都有不同的视角，无论你的测试方案多周密，总有人会说有测试点没有覆盖到。这说明两个问题：引入更多的人进行测试是有收益的 测试用例是无穷的，你永远无法穷举所有的场景上述两点其是有矛盾的，为了追求覆盖更多的场景，我们需要加大投入，引入更多的人，设计更...

创业公司希望：快，抢占市场互联网公司讲究：快速行动，不要光想不做，要勇于实践。在工作当中，有些领导经常会将「创新」、「快速」....这些词挂在嘴边，听起来这些词显得非常光荣正确伟大。但这些词有可能正在将很多创业公司导向一个危险之地。问题是真的快了吗？快有没有带来价值？做出来的东西用户不想用，线上问题频出，开发人员面临无数次的推翻重做，频繁的变动导致产品，开发，测试三方理解不一致，遗...

经历过几家创业公司，发现大部分测试和开发人员，包括项目经理，对于bug状态与解决方案竟然傻傻分不清楚，导致bug管理与统计上的混乱，在费尽了我的三寸不烂之舌团队成员解释之后，索性将这个问题做个整理写下来，希望对这些基本概念有所普及，现在大部分测试人员只关心学习高大尚的自动化测试，性能测试技术，却对一些基本概念的理解却是模糊不清，甚是让我感到担忧，希望本文对于入行测试的初学者，以及已经走在成长路上的......

引发问题：“设计如此”和“不予修复”的bug都是决定了不修的，那么用“设计如此”不就行了吗？不予修复：代表是bug，但是决定不予处理的问题 （白话：确实是个问题，但我就是这么任性，就是不修，不仅现在不修，就是以后也不打算修）例如：某些非常轻微的bug，但不影响功能使用的，或虽然对功能有影响但是仍然通过其他途径解决的，可以解决为不予修复“不予修复”与“设计如此”的区别：不予修复的前提...

测试的目的是保障质量，质量是效率的前提（非常重要）从发展的角度看公司对质量和效率的重视程度公司在初创阶段更注重效率：试错阶段，可以犯错误，100件事，犯错99次，1次成功即可 依赖个人和团队的能力公司在发展阶段会越来越重视质量：开始控制流程，减少犯错 从依赖个人能力到依赖有效的管理，减少个人犯错的影响 需求评审 Design review Code review ...

前几天读到一篇文章：为什么中国的 996 干不过美国的 955 （文未有链接）看过后有些感触，也进行了一些思考，由此引申到软件工程的质量控制，下面把自己的一些相法记录下来文中提到的一些观点，我是比较认同的关于工作的杠杆率，即单位工作时间产出的价值：业务如果靠销售驱动，杠杆率最低，运营其次，产品最高。所以你去看销售驱动的公司，往往有很多人，但是人均产值很低，比如地产，软件...