测试

移动测试服务

移动设备和系统版本的碎片化,催生了第三方测试服务,BAT也发布了自己的测试服务。

12月10日,百度 MTC 移动云测试中心推出了包括人工、自动、问卷的整合测试服务。

自动化测试的问题:

  • 新的功能需要先编写测试用例,时间比人工测试更长。
  • 版本快速迭代后,积累的测试用例失效。
  • 测试质量取决于编写测试用例的人,对测试人员要求高。

众包测试。

crash 上报服务。

应用性能管理服务,特别是不同网络条件下应用性能的表现。

自动化测试

如果认可测试是必须的话,我们应当去研究怎样才能让测试变得更快,更深入,或者研究 如何才能进一步拓展测试范围,什么样的工具我们能用来支撑测试,完成像数据管理、状 态控制以及日志文件解析等事物。

我们可以为数据生成代码创建一个 GUI,团队成员在测试的时候就可以用这部分代码来生 成数据,而不用一头扎进 DB 里。

另一个例子,通过使用终端自动化架构中的部分内容,将 app 部署在 1-N 设备上,启动 app,执行登录和停止,这样我一下子就能完成手机批量更新。

我也遇到团队将自动化单纯地视为端到端的脚本,包含了一些启动项、一些动作和一些断 言。应破除这些模子。分析测试方法中的瓶颈之处,不要止步于回归测试耗时太长这种层 次的分析,究竟是哪一部分的回归测试耗时过长?别只盯着瓶颈自动化,很多时候这不是 问题的全部。

持续交互模型中文化转型的重要意义

http://www.infoq.com/cn/news/2015/10/continuous-delivery

为了加速业务创新。

“构建高质量的软件应用并将它们快速地推向市场的能力是个‘未知因素’,这个‘未知因素’ 明确了行业领袖,这些领袖有一个共同点,它们的 IT 组织抛弃了传统的方法,转而支持 新的敏捷、协同设计方法、开发和应用交付。” Andi Gutmans, Zend Technologies CEO

为了实现持续交付,组织和企业需要实施各种各样的实践。(自动化)测试是需要正确设 置的重要实践之一。组织内持续交付过程中的测试是棘手的,有大量的纪律约束着,严谨 的并且是一项艰难的工作。在这样一个快速发展的环境下,持续集成CI和持续迭代CD已经 成了一个必需品而不是奢侈品。

微服务架构中的测试策略

Automation tests are company assets

传统上认为测试是一种开销,上线前执行测试来查找错误。

这里则是把测试认为是有价值的公司资产。 资产,财务行业使用的一个词,它是指由企业拥有的资源,这些资源由过去的活动产生,预期在未来会给企业带来经济效益。 所有软件都有两个关键资产:代码和测试。

Testing Strategy

测试金字塔

UNIT TEST

越往上成本越高,应该尽量底部的测试,减少使用上层的测试。

但并不是说完全不用。越往上单个测试体积越大、成本越高,但测试总量越少。

谷歌的比例 70% unit test, 20% integration test, 10% end-to-end tests.

但需要避免: - Inverted pyramid/ice cream cone 倒金字塔,冰淇淋堆,主要依赖端到端测试,很少使用集成测试,更少用单元测试。 - Hourglass. 沙漏。开始使用大量单元测试,之后在应该使用集成测试的地方用了端到端测试。结果底部很多集成测试,顶部很多端到端测试,但几乎没有集成测试。

end-to-end 把产品当作一个整体,也就是模拟真实用户的场景。

Just Say No to More End-to-End Tests

https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

  • Managers and decision-makers like it because tests that simulate real user scenarios can help them easily determine how a failing test would impact the user.
  • Testers like it because they often worry about missing a bug or writing a test that does not verify real-world behavior; writing tests from the user’s perspective often avoids both problems and gives the tester a greater sense of accomplishment.

Analysis

  • Despite numerous problems, the tests ultimately did catch real bugs.

What Went Well

  • Customer-impacting bugs were identified and fixed before they reached the customer.

The True Value of Tests

  • A failing test does not directly benefit the user.
  • A bug fix directly benefits the user. To know the bug exists, ideally you have a test that catches the bug

Building the Right Feedback Loop 正确的反馈回路

  • It’s fast 没有人是完美的,有时候反馈回路需要执行多次。
  • It’s reliable 没有人想花费几个小时 debug 一个测试,最后发现这是一个不可靠的测试。不可靠的测试也会降低对测试的信任度,经常被忽略掉,即使发现真正问题的时候。
  • It isolates failures. 能够隔离故障,找到真正的错误点,而不是大海捞针去寻找出错的地方。

谷歌的比例 70% unit test, 20% integration test, 10% end-to-end tests.

Just like a regular pyramid tends to be the most stable structure in real life, the testing pyramid also tends to be the most stable testing strategy.

那为什么测试没有俘获呢?

unit test

reliable

  1. Capable of being relied on; 可以依赖的
  2. Yielding the same or compatible results in different clinical experiments or statistical trials. 在不同的临床实验或统计学实验中返回相同或相容的结果。

Trustworthy

  1. worthy of being trusted; honest, reliable, or dependable

集成测试是个阴谋

J.B. Rainsberger

在我的理解中,集成测试表示那些测试结果(成功或失败)依赖于超过一个重要行为的实现正确性的测试。

一位开发人员(或团队)发现了某个缺陷似乎只能通过集成测试来找到,因此得出了这样的结论——“最好在各处都提供集成测试”——以便找到这样的缺陷。这个结论“完全错误”。

一个相对较严格的基于数学的检验,察看针对一个中型大小Web应用程序进行集成测试所要花费的代价。开发成本高。

隐含成本,测试等待时间长。

  • Trustworthy yes
  • Cheap no
  • Fast no
  • Reliable no

契约测试

乔恩·布鲁斯·波斯特尔(Jonathan Bruce Postel) IANA(Internet Assigned Numbers Authority, 互联网号码分配局) 创始人。

IANA 是管理国际互联网中使用的IP地址、域名和许多其它参数的机构。

文顿·格雷·瑟夫(英语:Vinton Gray Cerf,1943年6月23日-),昵称为文特·瑟夫(Vint Cerf ),生于美国康涅狄格州纽黑文,计算机科学家,因与罗伯特·卡恩设计了TCP/IP协议和互联网基础架构而被共同称为“互联网之父”。

I REMEMBER IANA https://tools.ietf.org/html/rfc2469

也许他最著名的贡献是RFC 760,介绍了鲁棒性原则,常被称为Postel法则:“在实现中发送行为应该是保守的,而接受行为应该是开放的”(RFC 1122中改写为“你接受什么是自由的,而你发送什么是保守的”)。