Google软件测试之道笔记与总结

[本文出自天外归云的博客园]

以下内容除了笔记还有总结,有个人理解的成分在内。

第一章笔记与总结

1. 开发人员也承担了质量的重任,质量从来就不仅仅是一些测试人员的问题。头衔有测试字样的人的任务是让那些头衔里没有测试字样的人更好的做测试。

2. 写一段代码就要测试一段代码,不要等着都写完了再写测试。写一段代码就立刻测试这段代码,这件事是由写这段代码的开发来做的。Google测试人员少是因为保证质量是开发的事。如果某个产品出了问题,第一个跳出来的必是导致此问题的开发者,而非漏测该bug的测试人员。

3. 质量更像是一种预防行为,而不是检测。质量是开发过程的问题,而不是测试问题。

4. 开发者对自己开发的代码负责,比专职测试人员更适合做测试工作。

5. 测试人员的存在是为了让开发人员的工作更有效率,测试开发的工作是提高代码可测性,至于编写测试代码是开发的事。测开主要关注开发人员,确认开发人员在测试方面的工作是否到位。

6. 没有集成测试和系统测试,只分小中大型测试。小型的是开发完成的,对某个函数而言,针对单个模块进行。中型测试是测试开发写的自动化测试,关注涉及二个以上模块间的交互行为。大型测试针对三个以上功能模块展开,验证是否满足用户最终需求,属于结果驱动的模块集成测试。非自动化进行的测试叫探索式测试。咱们的checklist走查属于超大型测试了(第四级别的测试)。

第二章笔记与总结

1. TDD是开发者做的,他要针对自己即将编写的代码写测试代码,这就是测试先行。这里要注意,测试先行绝对不是测试人员的工作,而是开发者的工作。

2. 测开者的任务是负责开发出合适的测试框架,给开发人员使用,让他们编写测试代码能够更方便、更轻松。测开要指导开发写测试。测开要针对开发写的代码提出测试意见,指出哪些地方需要写测试,如果不好写测试就是代码写的有问题,得重构,这是必须的。 为什么要重构?就是让你的代码每一个部分都能够有充分的测试来保驾护航,这才是重构的意义。

3. 我们尽量不要做侵入式的修改,这种侵入式的修改多了,而且没有配套的测试保障,一定会引来bug。要对单个功能模块的逻辑非常清楚的前提下,才能够进行重构,在拆解出单元后立刻配套编写充分的单元测试用例不是最好的方法,最好的方法是在拆解单元前把单测写好,然后进行重构,这才是TDD,测试先行。有测试代码保驾护航的代码,才是质量的体现。

4. 每一个重要缺陷的修复,都要有一个测试用例与之对应。我们要尽量尝试把重要缺陷的发现过程写成自动化测试用例。

转载于:https://www.cnblogs.com/LanTianYou/p/11625173.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值