这么多年来,我们一直都在被 “制式的教育” 着⋯

  • 单元测试是保证质量的必要的手段,无论如何是一定要做的。

但有人能说得清楚,单元测试到底能保证什么样的质量吗?是至多只能保证 “某个开发人员代码的质量”?我们是否真正有深度的思考过:保证 “某个开发人员代码的质量” 与 “保证产品的质量” 间的对应关系?

许多人都会说,Ken 你问这些问题,就代表着你不懂单元测试⋯

是的,我是不懂单元测试;我更不懂的是,为何会有开发人员在“完全不明白” 自己苦苦、甚至是熬夜所写出的单元测试用例与产品质量间的关系时,还是愿意傻傻的在那写单元测试用例?!

这么多年来,我们一直都被 “制式的教育” 着⋯

  • 自动化、手工集成测试用例一定要做到如何,如何,产品才能发布。

但,有人能说得清楚,每一次的版本开发中,产品代码 (架构) 上的变化、实际运维环境上的变化与集成测试用例、集成测试环境间的差异吗?

假如,没有人能说得清楚,我们又怎能信任自动化、手工集成测试?!

这么多年来,我们总是被 “制式的教育” 着⋯

  • 使得我们每个人都成为执行敏捷工程实践的高手,但,同时,我们却往往没法回答在产品开发上的一些 “Common Sense” 的问题?!

我们是不是应该要抛弃过往的 “制式教育” 中的单元测试与集成测试?! 而重新的思考 “真正有效”、“真正高效” 的测试方法,测试工具?!

思考着这些测试方法、测试工具其实ㄧ点都不难的;在 2014 年,我也只是想着,不要再写笨重、无用的需求文档、设计文档,但又能保证产品的质量与提升开发的效率,所以,就整合了既有的一些工程实践,创建了 Story 场景树。

所以, 我们要思考的是:

  • 抛弃 “建树不见林” 的单元测试, 并不代表著我们是在舍弃所谓的 “类(Class) 级别的白盒测试”。而是我们要重新的设计一测试方法、测试框架, 可将 “产品关键的业务场景” 以正确且轻量级的方式, 传递到 “类(Class) 级别的白盒测试”上。
  • 抛弃 “自我安慰式” 的集成测试, 并不代表著我们是在舍弃所谓的 “特性/产品间的集成交互测试”。 而是我们要重新的设计一测试方法、测试工具, 可将 “产品运维的环境、场景” 带到 “特性/ 产品间的集成交互测试”。更重要的是, 我们应该是以 ”产品运维的环境、场景” 来设计 “特性/ 产品间的集成交互测试” 的自动化测试用例。

所以, 当单元测试、集成测试不可信任时, 我们应该重新的创建、设计  “真正有效”、“真正高效” 的测试方法,测试工具。而我们要问的问题,应该不是:真正高效的测试方法及工具是什么?而是应该要问:创建高效的测试方法及工具,所需的背后的思维是什么?然后,照着这样的思维,你就能自己去创建、设计出属于你自己所需要的测试工程实践与测试工具。

建议不要只是期望着看到答案,却永远不知道答案是怎么来的;因为,总是只看到答案,学习答案,这样永远也学不完的; 会学得好累、好鬰闷。

自己创建,就相对的要轻松、自主的多了。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据