软件Bug与测试解析
第一章
问题一：
书上说，软件的行为和用户的期望值不一样，就叫Bug。是否是Bug，取决于用户、开发者的不同角度。 我想知道是不是有的Bug不用处理呢？ 百度百科上面说，Bug是指在软件运行中因为程序本身有错误而造成的功能不正常、体验不佳、死机、数据丢失、非正常中断等现象。这里的Bug指的都是一些会对用户使用软件造成负面影响的现象，而书上的Bug则范围较广，将与用户期望值不一样的都称作Bug（其中还包括一些可能有些用户需要的功能）。我的困惑是如果以后我们遇到这样的可能是“好的”Bug，我们应该及时处理还是先弄清楚大部分用户对这个Bug的看法，再做处理呢？
第二章
问题一：
书上告诉了我们怎样才算一个好的单元测试（应该准确、快速地保证程序基本模块的正确性），并告诉我们验证单元测试好坏的一系列标准，其中提到了单元测试应该覆盖所有代码路径。一些资料也说到，在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标。于是，我想知道代码覆盖率对于单元测试的重要程度。然而，有些博客上说，由于在做单元测试时，常使用代码覆盖率作为指标，测试人员费劲心思设计案例覆盖代码，但是有时候，即使代码覆盖率达到了100%，也可能会出现Bug。书上也说到100%的代码覆盖率并不等同于100%的正确性。我的困惑是我们在写单元测试的时候，是否还应该将代码覆盖率放在最首要的位置？
问题二：
书上说，VSTS提供了方便的效能分析工具，让我们能很快地找到程序的效能瓶颈，从而能有的放矢，改进程序。书上的例子看来，提高程序的效能主要是要提高程序的运行速度。我们在效能分析时，只需要关注程序的运行速度吗？有的博客上说效能分析和效率分析的差别不大，效能分析到底指的是什么呢？
第十六章
问题一：
书上说，大部分成功的创新者都不是先行者，同时也说到，创新者第一个想出了这些美妙的想法。书上举了搜索引擎Google和音乐播放器iPod的例子，并且把它们都归为成功的创新者。根据我自己的想法，只有真正的先行者才能被称作为创新者，我想是不是应该把这些后来居上的领导者称为改进者呢？但是，百度百科也并没有说创新者一定得是先行者。所以我想知道是不是最开始做一件事的一个小群体都能被称为创新者呢？
问题二：
书上将产品进行了四象限分类，并告诉我们对于各个产品，不能平均投资，要在第一象限投入足够的力量。其他三个象限的重要性应该怎样排序呢？我猜测在其他三个象限中，第四个象限相对比较重要，因为我认为第四个象限可能会给我们的产品带来突破性的进展。我还想知道一般这四个象限所被投入的时间各占多少呢？
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
