软件测试经验与教训-读书笔记

黑体字是我认为的重点(经验共293条 ,暂定每36条收录在一个文章里

1,优秀的软件测试团队不是天生的,而是造就的,是通过大量艰苦工作和有效沟通造就的、在这个过程中,有很多陷阱,这些陷阱会使精心制定的计划出现偏差,使项目不能按进度完成

2,喝红酒的方法(读书的方法)

1)不要直接用瓶子喝(看时带上自己的软件开发、测试经验)

2)不要整瓶喝下去(不要一口气读完,想想自己在工作中怎么应用)

3)不要污染它()

4)不要独贪它

下面为具体的内容:

1、软件测试是项目的前灯

2、测试员的使命决定要做的一切。

3、测试员为很多客户服务

服务的对象:项目经理、程序员、技术支持员、产品经理、管理层、项目相关人员、客户

4、测试员发现的信息会“打扰”客户

发现任何bug,需要提交报告。至于修改与否大家讨论决定(或项目经理决定)

5、迅速找出重要程序问题

这里有个测试顺序的问题:先测试经过变更的部分,再测其他,先测核心部分,先测常见情况,再测罕见情况,先测影响大的部分,再其他,先测最需要的部分,再没有要求的部分。

6、跟着程序员走

为程序员提供支持,尽可能快的测试开发提交的代码,尽可能建立最短最快的环路。理想的情况是让开发修改测试找出的bug而团团转,而不是测试被催着要测试,让程序员而不是测试成为项目的瓶颈。

7、

8、测试员关注失效,客户关注成功

关注失效,才会增加发现bug的速度/几率

9、不会发现所有的程序问题

10、当心完备的测试(测试不可能发现所有的bug)测试时尽量不用全部测试完成的单词。

11、通过测试不能保证质量

测试不是产品质量,质量的高低由程序员决定。

12、永远别做看门人

不要去独立承担发布产品的人,一旦遇上了,要毫不犹豫的立即坚持与其他项目角色一起来分担这种权利

13、当心测试中的不关我事理论

测试不仅仅是对照需求说明文档去测试,其他的也需要考虑,比如易用性等

14、当心成为过程改进小组

要注意跟开发的沟通,注意表达,我们不是在挑对方的毛病,我们是想让我们的系统(产品)更好

15、别指望任何人会了解测试,或测试员需要什么条件才能做好测试

测试的一部分工作是向别人解释什么才是测试。测试好比是预防针,有利于健康但不那么痛苦,同时随着时间会作用衰退,需要一遍又一遍的解释。

第二章 按照测试员的方式思考

测试员并不是“抱怨”,提供的是一种证据。测试运用的是知识,不是靠傲慢和谦卑。

16、测试运用的是认识论(认识论是哲学里的一个分支)

17、研究测试轮有助于更好的测试

推荐三本书:

软件测试经验与教训-读书笔记_第1张图片
软件测试经验与教训-读书笔记_第2张图片

40-如果自己知道自己不聪明,就更难被愚弄

最容易上当的人,是自信不会被愚弄的人。这条可以放到测试工作中来。做到这点并不难。只许仔细看看自己在测试中犯的错误。任何时候都要注意其他测试员所发现的自己本来也可以发现,但是没有发现的问题。

41-如果遗漏一个问题,检查这种遗漏是意外还是策略的必然结果

出现问题首先不慌,不自责。是否忠实的执行了好的测试策略,并只是碰巧没有发现那个特定的问题?如果是i这样,保持原有方针不变。确实存在这样的情况。但是如果遗漏程序错误是因为测试策略关注了错的问题类型,可利用这个机会改进测试策略。

42-困惑是一种测试工具

测试员对于产品技术和一般测试问题了解的越多,自己的困惑越会成为更有力的指南,指出重要问题所在。在测试过程中,如果对产品一无所知,那么至少知道自己在困惑。在这种情况下,困惑可以成为最佳交付内容,即提出也许其他人没有勇气提出的问题。

43-清晰的眼光会发现失效

理解事物,是把新信息吸收到已知信息中,同时修改已知信息以适应新信息的过程。测试员在理解了产品或功能后,会在头脑中形成映射并不再那么努力工作。对测试员来说着可能是个问题。当非常了解产品后,会对产品做出更多的假设,并更少检查这些假设。这种情况要注意三点:

1,第一次接触产品或功能时,要特别注意使自己困惑或烦恼的地方。2,当与团队的新成员一起工作时,与他们一起测试。3,警惕陷入测试惯例。即没有遵循严格的测试脚本,也可能对功能太熟悉以至于以越来越窄的方式进行测试

44-测试员要避免遵循过程,除非过程先跟随自己

===现在发现这个翻译的。。。版本不是很好看。要不要看英文版的书呀====

45-在创建测试过程时,避免“1287”

这个字符是一个测试员编写测试过程(其实是指测试用例),时在一个小字段内输入1287(一个随机输入的字数的个数)个字符,这里指输入非常多的字符。

过于详细没有什么好处。在设计时要包含必要的信息和设计与解释测试所需的细节,但是要让未来的测试员有创造性和判断力的执行,让未来测试员引入变化以使现在的编写过程新鲜、高效。

46-除非重新发明测试,否则不能精通测试

我们提倡要像伟大的机械师和伟大的程序员那样学习测试:把东西分解,琢磨其工作原理,再以新的方式组装到一起。不要把自己限制为只是接受智慧的服务者,而应该让自己成为智慧的创造者。

在学习过程初期,要重新发明不是非常好的测试、想法、手段和文档。这事正常的。要永远使头脑运转,观察其他观察员,研究和不断评估如何筛选自己的想法。如果想要善于做到这一点,就必须实践。

我们这样做很多年了,我们仍然在重新发明,仍然在反思老的想法,我们所尊敬的每个同事都是这样走向精通之路的。

第三章 测试手段

测试员应该做什么,前面讲,是观察和学习。

48---关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段

覆盖率:测试了哪些内容

潜在问题:测试的原因,要测试什么风险

活动:如何测试,eg探索式测试

评估:怎样判定测试通过还是不通过

49---关注测试员的基于人员的测试手段‘

’用户测试:使用该产品的人员进行输入的测试。用户测试可以在开发期间任何时候进行。

α测试:由测试小组执行的内部测试。

β测试:利用不属于开发机构并且是产品的目标市场成员的测试员实施的用户测试

0509-

50-关于测试内容的基于覆盖率的测试手段

等价类分析:等价类是这样的:1)测试的东西是相同的 2)如果其中一个可以捕获到一个程序错误,其他测试用例也可能捕获 3)如果其中一个不能捕获到某个程序错误,其他测试用例可能也不能捕获到,则这些测试用例是等价的。--测试用例的设计

边界测设-等价类是一组取值。如何可以把成员映射到一组数字,则边界值就是累的最大和最小值。在边界测试中,要测试这些值,还要测试相邻类的边界值。这些值比测试类的最小值小,比最大值要大。

53-关注测试是否通过的基于评估的测试手段

你可能感兴趣的:(软件测试经验与教训-读书笔记)