码迷,mamicode.com
首页 > 其他好文 > 详细

《Google软件测试之道》心得笔记

时间:2018-03-05 14:36:34      阅读:214      评论:0      收藏:0      [点我收藏+]

标签:编写测试用例   log   自己   数据持久化   大众   目标   foo   缺陷   注释   

  • Google软件测试介绍

  1. 把开发和测试融合在一起——开发和测试必须同时展开
  2. 开发人员自己要对自己写的代码负责,比专职的测试人员更适合做测试工作。
  3. 测试开发工程师SET
  4. 对于Google拥有很少量的测试人员的情况下,还可以取得不错的成果,核心原因在于Google从来不会再一次产品发布中包含大量的功能,实际上,做法恰恰相反,在一个产品的基本核心功能实现之后,就立即对外发布使用,然后从用户那里得到真实的反馈。
  • 软件测试开发工程师(SET)

  • Google的四大主要开发语言:C++、Java、Python、Js
  • 一个产品如果在概念上还没有完全确定成型时就去关心质量,这就是优先级混乱的表现。许多来源于Google百分之二十努力的产品原型,在其以后的dogfood或beta版本发布时,还要经历重新设计,原始代码保留的概率几乎为零。很明显,在试验初期阶段强调测试是一件非常愚蠢的事情。
  • 项目的技术负责人和发起人要做的第一件事就是设计文档。最早期的项目设计文档,主要包括项目的目标、背景、团队成员、系统设计。这是一个动态的文档,随着项目的演化也在不断地保持更新。
  • 单元测试、代码级别测试、白盒测试、集成测试、系统测试、端到端测试
  • UI界面的自动化测试——来模拟用户操作,像“单击向后按钮……回到之前页面……”
  • 模糊测试:发送随机的输入数据给被测应用系统
  • 小型测试:小型测试是所有测试类型里范畴最小的,一般集中精力在函数级别的独立操作与调用上。对于小型测试的执行频率更加频繁,并且很快就会发现问题,并且要减少依赖。
  • 中型测试:中型测试是验证两个或多个模块应用之间的交互,和小型测试相比,中型测试有着更大的范畴且运行所需要的时间也更久。在Google之外,中型测试经常被称为“集成测试”。对于中型测试,鼓励使用模拟技术(mock)来解决外部服务的依赖问题。
  • 大型测试:在Google之外通常被称为“系统测试”或“端到端测试”,大型测试在一个较高的层次上运行,验证系统作为一个整体是如何工作的。这涉及应用系统的一个或所有子系统,从前端界面到后端数据储存。
  • 大型测试优缺点:
  1. 测试最根本最重要的:在考虑外部系统的情况下应用系统是如何工作的;
  2. 由于对外部系统有依赖,因此它们是非确定性的;
  3. 很宽的测试范畴意味着如果测试运行失败,寻找精准失败根源就会比较困难;
  4. 测试数据的准备工作会非常耗时;
  5. 大型测试是较高层次的操作,如果想要走到特定的代码路径区域是不切实际的,而是一部分却是小型测试的专长。
  • 中型测试的优缺点:
  1. 由于不需要使用mock技术,且不受运行时刻的限制,因此该测试是从大型测试到小型测试之间的一个过渡;
  2. 因为它们运行速度相对较快,所以可以频繁地运行它们;
  3. 它们可以在标准的开发环境中运行,因此开发人员也可以很容易运行它们;
  4. 它们依赖外部系统;由于对外部系统有依赖,因此它们本身就有不确定性;
  5. 它们的运行速度没有小型测试快
  • 小型测试的优缺点:
  1. 为了更容易地被测试到,代码赢清晰干净、函数规模较小且重点集中。为了方便模拟,系统之间的接口需要有良好的定义;
  2. 由于它们可以很快运行完毕,因此在有代码变更发生的时候就可以立刻运行,从而可以较早地发现缺陷并提供及时的反馈;
  3. 在所有的环境下它们都可以可靠地运行;
  4. 它们有较小的测试范畴,这样可以很容易地边做场景与错误条件的测试,例如一个空指针;
  5. 它们有特定的范畴,可以很容易地隔离错误;
  6. 不要做模块之间的集成测试,这是其他类型的测试要做的事情(中型测试);
  7. 有时候对子系统的模拟是有难度的;
  8. 使用mock或fake环境,可以不与真实的环境同步。
  • 关于测试类别的总结:

小型测试是为了验证一个代码单元的功能;中型测试验证两个或多个横块之间的交互;大型测试是为了验证整个系统作为一个整体是如何工作的。小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告;大中型测试带来整体产品质量和数据验证。对于测试的占比,总体上有一个经验法则:即70/20/10原则:70%的小型测试,20%的中型测试,10%的大型测试。

  • 测试运行要求:
  1. 每个测试和其他测试之间都是独立的,使它们就能够以任意顺序来执行;
  2. 测试不做任何数据持久化方面的工作,在这些测试用例离开测试环境的时候,要保证测试环境的状态与测试用例开始执行之前的状态是一样的;
  3. 在测试执行系统中,让每个测试用例获取一个未使用的端口,并让被测系统动态地绑定到这个端口上留在测试执行之前,为每一个测试用例在临时目录下创建目录和文件,并使用独一无二的目录名;
  4. 每个测试运行在自己的数据库实例之上,使用与环境隔离的目录和端口。
  • 依赖于自动化测试去验证产品功能。
  • 如何优化每次代码变更后触发的测试执行次数。
  • Google寻找SET期望:对测试有强烈兴趣和天资的开发人员。一个通用且有效的招募优秀SET的方法是:给候选者和其他开发角色一样的编程问题,并考察他们在处理质量问题与测试方面的方法。
  • 注意垃圾收集、类型安全、编译和运行时刻的不同关注点。
  • 普通的候选人可以做到:
  1. 在通过编写代码解决问题的过程中很少遇到问题。在编码时,函数重写没有麻烦,很少出现基本语法错误,也不会混淆不同语言的语法和关键词;
  2. 在理解指针方面没有明显的错误,或者没有分配不必要的内存;
  3. 在代码开始的地方做一些输入验证,避免由于取值到空指针等引起比较麻烦的程序崩溃;
  4. 理解运行时刻效率或陈旭代码的所消耗的时间;
  5. 在被指出代码中有小问题时,可以修正;
  6. 写的代码干净易读;
  7. 在输入为一个A或null的时候,走查代码确保能正常工作;
  8. 会比较有条理地或体系化地提供特定的字符串而不是随机的字符串;
  9. 专注于产生有意义的测试数据,考虑如何去运行大型测试和使用真实环境的数据做测试。
  • 更优秀的候选人:
  1. 考虑使用64位整型int64作为计数器变量和返回值,为了以后的兼容性和避免用户使用非常长的字符串而导致溢出;
  2. 在代码注释中对条件假设和常量做解释说明;
  3. 在有很多不同的数据输入时可以走查代码,修复所发现的错误;
  4. 在被要求停止之前,不停地尝试优化解决方案;
  5. 在并发线程中调用这个函数,去查看在串扰、死锁和内存泄漏方面是否存在问题;
  6. 构建长时间持续运行的测试场景;
  7. 在构建测试用例、测试数据的产生方法、验证和执行上保持浓厚的兴趣。
  • 软件测试工程师(TE)

  • Google的关于TE职责的一般性描述:
  1. 测试计划和风险分析;
  2. 评审需求、设计、代码和测试;
  3. 探索式测试;用户场景;
  4. 编写测试用例;
  5. 执行测试用例;
  6. 众包(大众一块进行测试);
  7. 使用统计、用户反馈。
  • 期望的测试计划具有的一些特性:
  1. 及时地更新;
  2. 描述了软件的目标和卖点;
  3. 描述了软件的结构、各种组件和功能特性对的名称;
  4. 描述了软件的功能和操作简介;
  5. 应该描述必测点;
  6. 应该能在测试中提供有用的信息,从而帮助确定进展以及覆盖率上的不足。
  • 风险:影响风险的因素很多,试图精确地、定量地计算风险比环节风险还要麻烦。在Google,我们确定了两个要素:失败频率和影响。风险是一个定性的相对值。
  • 风险缓解:
  1. 我们可以围绕风险大的能力点编写用户故事,并从中确定低风险的使用场景,然后反馈到开发团队,请他们有针对性地增加约束;
  2. 可以编写回归测试用例,以确保问题在重现时可以被捕捉到;
  3. 可以编写和运行引发故障的测试用例,来推动开发实现恢复和回滚的特性;
  4. 可以插入监听代码,以便更早地检测到故障;
  5. 可以插入代码监听软件,发现新旧版本间的行为变化以发现回归问题。
  • 需要按照风险顺序进行测试。颜色标识
  • 测试计划这个任务的时间是以小时到天为单位来计算的。
  • 一个孤立的数字意义很小。

《Google软件测试之道》心得笔记

标签:编写测试用例   log   自己   数据持久化   大众   目标   foo   缺陷   注释   

原文地址:https://www.cnblogs.com/sunshine-blog/p/8485173.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!