首页>新闻>软件测试>详情
为什么要测试,测试是如何令人更快乐的?(二)
预约试听

发布时间:编辑:佚名

来源:51Testing软件测试网

 

知道测试什么是关键
知道测试什么没有听上去得那么容易,并且有很大一部分是由经验所决定的。许多测试测试得太多。知道要测试什么涉及到要了解什么重要,什么不重要,而要知道这些并不是一件随随便便就能做到的事情。这里有一个技巧,但:
“尽可能采用**高级别的测试,以便于在实现上覆盖范围和灵活性。”——Brian Lonsdorf,《JavaScript. Air 004》
所以,基本上:
不要测试内部的东西,这只会成为你的阻碍。如果你真的觉得你应该测试内部的东西,那么你**分离成一个新的模块,使之成为外部的东西。
不要测试过于指定,或处理它们不必和不应该知道的东西。
不要只是为了获得 100% 的覆盖率而去写测试。如果有人告诉你应该保持 100% 的覆盖率,那么不要废话,揍他。
请记住,测试应该从模块外部的角度开始由外到内。需要注意的是完全覆盖的测试还是有可能的,即代码的所有分支应该都可以实现。如果没有,那么它们基本上是死码,不是吗?除非你需要更好地理解它们是如何工作的,否则就不要测试内部的东西。
想想当一段时间以后,代码重构的时候,会发生什么。实现应该允许在测试不失败的情况下被更改。为什么?因为如果将来的程序员需要改测试的话,那么基本上是重写,而不是重构。并且重写并不安全。对于重构内部应该没有新的测试。
在测试时要务实。测试是项目以及创造价值的一部分,什么都拿来测试没有任何意义,就像实现所有按钮没有意义一样。记住文档方面。如果测试涉及许多实施细节,那么我们就会失去模块的重点。我们就会失去文档的价值。
至于文档,测试你的领域假设。这些都是你工作的问题域的代码解释,这些问题域往往是一些程序员不擅长的地方。用代码的形式文档化这些假设解决了两个问题:自我文档化假设,并证明它们能够如解释那样有效工作。
当你发现 bug 的时候,编写测试。不要只是修复它。去写测试,确保它既是红的,又对齐 bug 所没有意识到的期望。修复 bug,使其呈现绿色。保存。
代码覆盖作为一个具体的数字被高估了,但作为一种工具它还是很有用的。不要为了覆盖范围而力求覆盖。请记住,覆盖范围只能告诉你测试在代码行运行什么,而不会告诉你测试将运行什么组合。不过,这可以成为事情是否朝着正确方向前进的一个很好的风向标。如果重构导致更糟的代码覆盖范围,那么就应该响起警铃,尤其是如果它是重构的话。不要只是为了增加覆盖数值就让自己去编写测试。经过充分测试和编写良好的代码的覆盖数值更大。
编写测试的触发器是当你的代码片段有新的行为的时候。测试应该盯牢这种行为,但不要矫枉过正。
测试库可能比测试终端应用程序更容易,更为重要。毕竟,库会被多个应用程序使用。
如何编写特别棒的测试
知道如何写出好的测试是关键,因为很容易写得不好。事实是,和其他所有一切一样,它需要实践。不过,这里有一些小贴士。
好的测试往往是简单的。它不会尝试一气呵成面面俱到。它的名字反映了它要的目的,并且名称应该精简成一句话。例如,名称不应该是“it works”,而是“it returns 0 for negative values”。
确保测试不要过于指定。 过于指定的测试涉及到太多内部东西,并且不允许重构。
单元测试运行代码时会隔离其他测试,不一定是其他代码的测试。它将代码带出它的上下文,并创建其中一个方面的人工上下文,以便于进行调查。然而,这并不意味着单元测试必须得在隔离其他所有代码的情况下运行,尽管这通常被认为是“纯单元测试”。所有一切都没有必要 mock 和 stub,因为只会导致更复杂的设置,更低的覆盖率和更加脆弱的测试。
在有意义的地方使用 mock 和 stub。你不想对一个真正的 HTTP API 进行测试,那就 stub。如果你正在测试的东西是你自己对该对象的调用,或你想要自己的代码历经某个路径,那么使用使用 mock 和 stub。
测试读起来应该像一个小故事,遵循 AAA 体系: Arrange、Act、Assert。设置东西,做出声明,并且断言声明做了它应该做的。 “小故事”方面要重视小的方面。“3A”中没有一个应该超过 3 行代码以上。在阶段之间留一些空间会更好。应该没有任何分支和循环,你在断言时应该只涉及一个逻辑内容。 (如果一个断言语句就能表达自然是好,但有时你需要更多,那也没关系。)永远不要在测试的两个不同的地方断言,因为这会导致你实际测试的混乱。
测试应该只需要一些领域知识就可读。如果不深入模块的内部运作就很难解释的话,那么要么你**多花一些时间在测试上,那么彻底弃之不顾。
一般情况下,不要测试依赖。对于某些项目,对一些代码所做的假设做一些简单的测试,可能是有意义的,但要谨慎和小心。测试库是库作者的工作。相反,要依靠更新日志进行升级,以及依赖于测试集成而不是库(不用 mock 一切的一个原因)。
编写不需要很长时间运行的低成本测试,因为要时常运行这些测试。如果你可以传递 --watch 参数到你的测试运行中,并且在每次有文件改变时运行它,那么这是一件好事。
**后但并非**不重要的一点是,使用你喜欢的测试框架。如果 JavaScript. 是你的菜,那么我会推荐 AVA,因为它清晰简单,而且没有复杂的配置。不管你选择什么,确保测试框架能和你一起工作,并帮助你编写测试更高效,更快捷。正如编码一样,如果你觉得不好玩,那么可能有什么地方出错了。


教育联展————专业的软件测试咨询服务平台。
详询:王萍老师18988787201
详询:小文老师18988787201
深圳软件测试培训 深圳软件测试培训班
王萍老师 小文老师


课程精选:

中华考试网软件测试培训》
教育软件测试培训频道》
《软件测试培训课程——深圳川石
《深圳川石软件性能测试培训》
《深圳川石企业性能测试(PL&LR)提升班
《持续集成自动化测试UFT Selenium提升班》
《深圳源昊宝安软件测试培训班》
《深圳凌岳软件自动化测试培训班》
《深圳博睿软件安全测试培训》
深圳达内软件测试培训学校》

阅读全文
热门机构推荐
<上一篇:为什么要测试,测试是如何令人更快乐的?(一) >如何成为一名心理咨询师下一篇:
1V1课程咨询 免费试听课程

编辑推荐

Baidu
map