紫晴的阅读
QA 该具备什么要的能力? (3)
QA需要具备的第三个能力,是需求分析.需知道RD的工作通常是研究某种技术,并且负责实作某些moduleor功能.他钻的很深,但是全面性可能不够.所谓全面性,是指对于产品整体功能的了解度.通常他只熟悉他所负责的部分,其他部份的操作可能不太熟悉.就算即使是他的部分,若是加上对于环境的影响,或是使用者可能遭遇的问题,他可能也不见得很熟.可是QA不同,他需要测试大部分的功能,或者说他需要组合不同功能来做测
278°/
2014-07-23/2785 人阅读 / 0 人点赞
/ 0 条评论
QA 该具备什么要的能力? (2)
第二个我要提的是程序开发的能力.有人会很好奇,为何QA需要懂开发呢?其实不然,对于你要测试的东西,你怎么能不懂它怎么做出来的呢?若是你能懂软件开发,你会有以下好处:1.你可以用RD听得懂的话,来跟RD沟通.不会让RD你在是讲哪国的外星文2.你可以挑战RD的设计,毕竟多点人一起思考,一定比一个人周密.3.你可以分析debuglog,dump和对照sourcecodes,便可以帮助RD找出可能的roo
265°/
2014-07-22/2657 人阅读 / 0 人点赞
/ 0 条评论
QA 该具备什么要的能力?(1)
每次在面试QA时,很多人都不知道QA是什么,它需要什么样的能力.所以每次我都要很多时间来一一解释.其实这也不能怪面试者,软件测试本来在台湾就不是显学,学校根本就不会教,并且说不定连软件工程的课都没有开,所以大家都不会.其实这另一方面也显示了台湾软件界落后,大多人只知道软件开发里,只有写程序和项目经理两种角色,事实上台湾业界大多也只有这两种.让我们回归正题,首先,对于QA所要具备的能力,我第一要提当
485°/
2014-07-22/4850 人阅读 / 0 人点赞
/ 0 条评论
单元测试=白箱测试？
单元测试=白箱测试?这是很多人的想法.一听到白箱测试,就认为他就是单元测试.或者认为单元测试时,就是要用白箱测试的方法来进行.事情是这样吗?让我们继续看下去:当我们要测试这个程序时Stackpush(Stacks,intkey)你会怎么测试呢?你可能会考虑以下几种状况(1)空的stack,第一次push(2)不是空的stack,然后push东西(3)stack是满的,push个东西看会不会有问题(
351°/
2014-07-21/3500 人阅读 / 0 人点赞
/ 1 条评论
同一个 bug 不要修复两次
NoahSussman曾经写过一篇文章《你应该测试的东西：软件系统测试清单》这份清单里面大部分东西都是有帮助的。然而我觉得它所鼓励的理念，本质上来说有误。它的理念基本上是这样：找出开发者常犯的错误，然后确保你写了测试样例来检查你没有犯了这样的错误。然而这个做法的问题是它本质上是一种“打地鼠”式的调试方式，并没有终结掉那些该死的bug。一个更有效的做法是《EasyProgramming》里提倡的“永
191°/
2014-07-21/1919 人阅读 / 0 人点赞
/ 0 条评论
编写可测试的 JavaScript 代码
Twitter的工程师文化要求进行测试，许多的测试。在进入Twitter之前我还未有过测试JavaScript的经验，所以在这之后我学习到了很多。特别是学到了许多过去我使用、书写和鼓励使用的代码其实是不利于书写可测试的代码的。所以我觉得在此分享我所学习到有价值的，如何书写可测试的JavaScript几条最重要的原则。这里提供的这些示例虽然基于QUnit，但是也应该适用于其他的JavaScript测
218°/
2014-07-18/2180 人阅读 / 0 人点赞
/ 0 条评论
Bug的类型
美国计算机科学家、图灵奖获得者詹姆斯·尼古拉·格雷(JimGray)，在他的著名的论文“Whydocomputersstopandwhatcanbedoneaboutit?”中首次提出了程序bug的类型，比如玻尔bug(Bohrbug)、海森堡bug(Heisenbugs)等用著名科学家名称命名的bug。后来又出现了更多的bug类型。现在，让我们来看看它们都是什么bug
205°/
2014-07-18/2059 人阅读 / 3 人点赞
/ 0 条评论
为什么谷歌要执行严格的代码编写规范
本篇是谷歌是如何做代码审查的的续篇。我们在谷歌所做事情中另外一个让我感到异常有效、有用的制度是严格的编码规范。在到Google工作之前，我一直认为编码规范没有什么用处。我坚信这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率的东西。我是大错特错了。在谷歌，我可以查看任何的代码，进入所有谷歌的代码库，我有权查看它们。事实上，这种权限是很少人能拥有的。但是，让我感到惊讶的却是，如此多的编
191°/
2014-07-16/1911 人阅读 / 0 人点赞
/ 0 条评论
旧式测试已死
（一）看了20%之后写的约在一年前，JamesWhittaker和AlbertoSavoia在GTAC2011上说TestisDead，当时我的理解是，测试工程师这个角色没啥用了。但是看了这本书之后，才发现这样的理解有些偏差。Alberto的说法应该是，在敏捷以及互联网下，传统测试工程师已经没啥用了。这边书前面几章是介绍google的测试现状的，最主要特点是：1.在一个几万人的组织里面，从事测试工
212°/
2014-07-14/2129 人阅读 / 1 人点赞
/ 0 条评论
没有自动化，就没有准时交付
在敏捷开发中,我们都知道要将功能切割,每次做些小功能,然后持续交付价值给客户.因此当你在开发每个小功能时,你会不断进行以下事情:1.从主干checkout程序代码到分支2.开发团队在分支进行开发3.小功能开发完后,将分支程序,merge回主干4.在主干进行测试可是通常这样在第四步时,就会遇到一堆错误.这是因为小功能还没确认是否正确,就和整个系统和起来测试,将导致问题多多.如果有很多小功能要放进来时
264°/
2014-07-14/2640 人阅读 / 0 人点赞
/ 0 条评论