我的测试生活感悟

第第页我的测试生活感悟我的测试生活感悟

发表于：2023-11-18来源：未知：领测软件测试网采编点击数：标签：软件测试

1.真的是万事开头难，但我觉得更难的是，每天都坚持做同一件事情。在不被强迫的情况下(如：上班、吃饭、睡觉...)，在可自由支配的时间里，现在我每天坚持做的貌似只有GoogleReader。希望我的测试感悟系列也能坚持下来。2.在做模块的接口测试过程中

1.真的是万事开头难，但我觉得更难的是，每天都坚持做同一件事情。在不被强迫的情况下(如：上班、吃饭、睡觉...)，在可自由支配的时间里，现在我每天坚持做的貌似只有GoogleReader。希望我的（测试）感悟系列也能坚持下来。

2.在做模块的接口测试过程中，发现开发所犯的错误大多是一些低级的，深刻领悟到：复制粘贴是代码最大的隐患!

3.最近发现一个（BUG），是（开发）解析xml错了，导致有的节点内容未读上来。就这样一个（BUG）描述，根本看不出它对产品有多大的影响，也许最了解的人，就是（开发）自己了。

4.写的模块接口测试案例多了，渐渐发现了一些自己的代码风格，也许以后可以开专题来讲解一下。测试代码和产品代码是有很大区别的，测试代码其实是有通用的一些模式的，不然就不会出现XUnit之类的东西。可以说XUnit也是一种风格约束。我总结出来的自己的测试代码都会分成以下几个部分：

*Caller

对开发接口函数调用的包装，使得案例有一个统一的入口调用开发的函数。开发接口函数变动，只需要变动我们的Caller。(封装变化)

*Checker

对接口函数调用的验证方式的封装。对被测函数的返回值检查是最基本的，更多的时候，返回值并不能告诉你一切，返回值告诉你它做了什么，但它没有证明给你看它确实做到了

*DataDefine

测试数据是必不可缺的，我将测试数据单独抽离出来，方便管理和组织。

*TestFixtureBases

TestFixture的基类，这是我喜欢使用的方式，定义某一类案例的基类，它们做同样的SetUp和TearDown，共享同样的函数调用。

*TestCases

最终到了测试案例这一分类，如果我们把上面的四个分类都做好了，就会发现，测试案例都可以使用一种非常简洁的方式来表达。在我看来，一个测试案例代码，五行左右代码是最优美的。

*(附加)CommonSpec

有时候，为了让测试案例更加容易理解，我还喜欢使用BDD的方式表述测试案例。因此，我个人可能还会有一个分类叫CommonSpec，定义的一些自然语言相关的函数。可能这个并不一定适合每个人。

5.上周五去听了一个关于软件架构师的课程，总结一下大约有如下几点收获：

*架构师首先要明白真正需要解决的问题是什么。例子：老太太买梨

*一个优秀的架构师，必须有一套自己明确的方法论。

*政治-经济-技术，架构师容易只看到技术上的问题，其实有时技术问题并不是最大的问题。

*架构师是参谋长，也是辅导员。有了自己的架构设计，还要将自己的架构设计描述清楚，并推动设计方案的实施。

*(概念部分)架构师的定义，分类，架构设计的过程等等。

ArtOfUnitTesting

今天把《ArtOfUnitTesting》的前四个章节读完了，以自己的亲身经历，使用简洁清晰的语言，为我们展现了单元测试的艺术。

1.怎么定义一个好的测试案例呢?好的测试案例应该是在N年后还能运行良好并易于维护的。

2.TOOD-TestabledObject-OriendedDesign。也提到了这个颇有争议的问题，许多人认为，增加代码的可测性的同时，会使得代码变得更加丑陋。而不认为是这样，认为这样的修改是另外一种面向对象，同样的也是优美的，这就是TOOD。

3.为了代码的可测性增加的一些代码，常常不希望编译到最后的产品中。可以有很多办法，比如用宏判断，如果使用的是.NE，还有一种办法，就是在相应的函数或类上面使用这个Attribute：[Conditional(DEBUG)]

4.Action-DrivenTesting与Result-DrivenTesting，两种不同的测试流派，一种检测行为本身，一种检查最后结果。不能说一定谁优谁劣，但作为（单元测试），更多的应该是Action-DrivenTesting，因为这样可以隔离一些其他外部的不稳定因素，当你的案例失败时，能够更加准备的定位问题所在。(事实上，集成测试就是Result-DrivenTesting，一个很大的困惑就是集成测试案例失败了，通常是很难马上定位到原因的。)

5.Stubs和Mocks的区别，这两个东西看起来几乎是一样的，事实上也确实很相似。但是，他们的区别也同样明显：Stubs不会导致案例失败，而Mocks会。换成我的理解就是，Stubs是一些假的东西，它能模拟一些我们想要的结果，而Mock呢，它就是一间谍(TestSpy)，告诉我们被测代码做了些什么，于是，我们通过Mock对象来进行检查。

6.OneMockPerTest，一个测试案例中，通常的模式是N个Stub对应1个Mock。如果一个测试案例有多于一个的Mock对象，说明你的案例感情不够专一。而一个测试案例，是可以有多个Stub对象的，他们共同协作模拟一些特定的虚拟场景，然后通过Mock对象，验证我们的被测对象是否对此做出了反应。

淘宝的接口测试白皮书

今天晚上回来后看到淘宝测试团队发出来的《接口测试白皮书》，一口气将它读完，写的还是相当不错的，有非常多值得借鉴和学习的地方。

1.在工作的流程上，各个测试角色是可以互补的，接口测试的设计、（用例）可以跟功能和性能测试共享，从而构建出整个产品各个环节的测试案例覆盖程度。

这一点之前感触并不深，现在看来，同一产品的不同测试团队，像共享（bug）一样，将所有人的案例都组织在一起，一起共享是一件非常值得去做的事情。

2.我们的客户是调用接口的人，不是开发接口的人。

说的好!之前一直以为是为开发服务，看来是上面的话总结的比较好，为调用接口的人服务。

3.测试用例设计出来以后应该经过评审，并将评审结果以某种形式记录下来，作为测试实施的最终方案。评审最好由以下这些人员共同参与：需求方、设计人员、开发人员、功能测试人员、接口（测试人员）