天行健，君子以自强不息

不知道最近几年软件测试在高校中是否有专门的专业或者课程，或者说细分到测试这么细的分支。但是毫无疑问的是，软件测试已经成为软件行业一个越来越重要的分支了，因为高校里面没有专门的专业，甚至可能没有专门的课程进行系统的学习，那么从事这个行业的广大测试同行这部分的基础知识可能就都是通过自学、培训机构得来了。软件测试跟软件开发一样，也是一门系统的科学，包括的范畴也很广泛：测试流程，测试管理，测试工具，测试方法等等。

我打算利用接下来的一段时间，从wiki（维基百科，国内绝大部分用户可能无法访问）转载一些软件测试基础相关的概念，跟大家分享，首先就从软件测试的基本定义和测试用例开始。

Software testing

Software testing is the process of exercising a software to verify that it satisfies its requirements and to detect errors. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test[1] , with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of Software Quality Assurance (S.Q.A.), which encompasses all business process areas, not just testing.[citation needed]

Over its existence, computer software has continued to grow in complexity and size. Every software product has a target audience. For example, a video game software has its audience completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it presumably must assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.

A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed.[2]

Scope
Read more…

看到这个标题，如果你认为我在痴人说梦，那么请一定仔细阅读本文。你还在认为测试和开发是天生的一对冤家，有不可调节的矛盾，是对立的两面么？开发的天职是构建程序，测试则恰恰相反，是从事破坏活动。其实从另外一个角度讲，矛盾的两者又是对立的统一面-共同为了把产品的质量提高。有的时候我们抱怨开发团队不够重视测试团队，请在抱怨的同时进行思考，是否我们的测试团队或者测试人员是不合格的。是否我们具备的测试人员的基本素质了呢。

在产品的开发过程中，需要测试和开发通力合作，互相尊重和理解，下面就具体阐述一下测试人员如何才能赢得开发人员的尊重。

第一，开发人员是一个比较单纯的群体,他们通常衡量一个人价值的方法是你的技术实力,因此好水平的测试人员很容易赢得开发人员的尊重。

第二，测试人员赢得开发人员尊重的方法首先是做好自己的本质工作,即掌握基本的测试方法和测试理论,更多的发现产品的缺陷。

第三，测试人员赢得开发人员过程中注重不但要能发现问题,而且可以重现问题,这是一个比较关键的问题,对于不能每次都重现的问题,也要搞清楚什么条件下问题出现的概率比较大，隔离问题，为进一步重现提供线索。

第四，测试人员不但要能发现问题,而且要在汇报问题的时候准确描述问题发生时的情况,包括配置，版本，设备情况,操作步骤,问题截图，日志等等。

第五，测试人员会使用自动化测试工具,提高测试覆盖率,而自动化测试工具实际是需要编程能力的,如果你熟练掌握这些工具说明和开发人员已经没有太多本质的区别。

第六，测试人员掌握开发人员不掌握的技能,比如性能测试的原理，方法和工具,这些东西在项目前期的技术验证都可以给开发人员提供很大的帮助，在后期的调试或者定位问题也可以给开发提供一些帮助。

第七，测试人员要了解系统架构等开发方面的知识,这些知识不是开发人员所独有的,作为高级测试人员这些知识也是必备的,这些知识的掌握不但可以提高测试人员的知识面,而且缩小了测试人员和开发人员的沟通成本。

第八，测试人员要掌握软件质量保证的知识,测试的高级阶段就是软件质量保证,而软件质量保证会含盖软件开发的全过程,掌握软件质量保证实际从项目的需求阶段就可以参与开发。

第九，掌握开发技术或者开发语言,测试人员如果掌握开发技术,实际上增强了问题查找和定位能力,很多时候,有经验的测试人员可以通过缺陷的表现形式定位出问题发生的原因,这没有什么不可能的,如果你有开发经验,这些问题也许就是你犯过的错误,或者是你长期测试积累出来的经验和教训。

有了这些能力,还怕开发人员不尊重你这个测试人员吗？还在抱怨开发人员不重视测试团队么？

（注，本文思路主要来源于测试同行bbbian，部分内容有删减，原文链接）

国内原版的软件测试专著本来就不多，关于性能测试的就更少了，现在随着行业内对软件测试特别是性能测试的重视，软件测试需求人才需求也在不断扩大。除了亲自动手实践之外，理论方面的学习只能靠阅读各种书籍了，现在测试人员又有福音了，又一本优秀的国内软件测试方面的著作面世了，这就是6月刚刚出版的《软件性能测试与LoadRunner实战》，作者于涌是一位经验丰富的资深测试专家，有多年的开发经验，我们也是老朋友了。同时圈子里的几位测试大拿段念（网名关河），51的朴老师，测试时代的贺老师，还有Zee老弟都给予了非常中肯的评价。别的不多说了，首先看看这本书的介绍：

http://www.china-pub.com/39876

【内容简介】
本书在介绍软件性能测试概念的基础上，结合实际测试案例的剖析，重点讲解了LoadRunner工具的使用技巧和实战技术。.
全书分为4个部分。在“基础篇”中，介绍了使用LoadRunner工具进行软件性能测试的基本应用，如性能测试流程、性能测试场景和脚本的调试等技术。在“实战篇”中，分别对数据库、邮件协议以及LoadRunner .NET插件等应用进行了详细的讲解。在“提高篇”中，讲解了一个完整的GIS测试案例，把前面的知识整体贯穿起来，培养读者具有大型项目测试的能力。附录部分，提供了性能测试中经常用到的非常重要的模板文件和规范化的软件测试相关文档。..
本书图文并茂，通俗易懂，适合性能测试设计人员、性能测试开发人员、性能测试分析人员、项目经理、测试组长参考学习。…

【媒体评论】
LoadRunner是性能测试领域中应用较为普遍的商业测试工具，具有强大的功能，也比较容易入门。但大部分LoadRunner的初学者在掌握了简单的录制/回放技术后，想要进一步使用LoadRunner完成复杂任务的时候，都会发现自己对LoadRunner中复杂的参数设置、脚本语言的高级用法等不能很快掌握。而目前市面上又缺乏一本系统介绍LoadRunner进阶用法的书。
本书的出现恰逢其时，在本书的第一部分中，作者介绍了LoadRunner的基本使用，包括协议的选择、脚本的参数化、关联和脚本调试技术；在本书的第二部分中，则突出了LoadRunner的高级应用，在这部分内容的编排上，作者独具匠心地提炼出了使用LoadRunner过程中遇到的具有代表性的问题，并针对具体的问题给出了解决思路和示例代码。因此，本书既可以作为读者进一步了解LoadRunner的学习教材，也可以被当成LoadRunner应用的速查手册，读者可以直接在书中找到自己想要解决问题的答案。
另外，贯穿在本书中的还有不少作者在实际工作中得到的真知灼见，和处理具体问题的技巧，这些都会帮助读者提高测试技能。
——段念 Google（谷歌）TestLeader
Read more…

推荐两样东西，一篇文章和一个软件

推荐的软件就是RocketDock，http://rocketdock.com/

重点的推荐的这篇文章，讲的是开发中很重要的一个过程：每日构建（daily build）（对，贾罗德，你没看错，就是从你那里看到的 ^_^），下面是文章关键部分。
另外，之前也有一篇原创的关于日构建的，可以参考：每日构建与冒烟测试

原文地址
每日构建（daily build）是你的朋友
作者： 周思博 (Joel Spolsky)
译： Chen Bin
2001年1月27日

……
一个好的办法是每日构建（daily builds）。 每日构建意味着自动地，每天，完整地构建整个代码树、（译者按：“代码树”，原文为source tree，意思是将整个项目源代码的目录，子目录，文件的位置尽可能事先固定下来，这样在开发过程中各个模块间，各个文件间的相对位置都不会混乱。源代码树指的就是一个项目所有的已经组织好的代码文件。通常代码树应该用版本控制软件管理起来。虽然这个概念很基本，但是据我的观察，国内还是有软件公司在这方面做的不够好的，所以有必要解释一下。）

自动地 － 因为你设定代码每天在固定的时间构建。在Unix环境下使用cron，在windows下使用“任务计划”。

每天 － 或者更频繁. 当然每天构建的次数越多越好啦。但是有时候构建次数还是有上限的，原因和版本控制有关系，等会儿我会谈到的。

完整地 －很可能你的代码有多个版本。多语言版本，多操作系统版本，或者高端低端版本。每日构建（daily build）需要构建所有这些版本。并且每个文件都需要从头编译，而不是使用编译器的不完美的增量编译功能。

以下是每日构建（daily build）能带来的好处：
Read more…

Refer from Jackei’s blog post in 2005
Havn’t write posts about testing for a long time and now have moved to Linux OS so can’t input Chinese.

原文出处：http://blog.51testing.com/index.php?op=ViewArticle&articleId=1463&blogId=130

做IT的苦，做IT职业中的测试更苦，你先别看这个职业有没有前途，先看看进入这个职业所要忍受的痛苦。没有正点吃饭的，没有正点睡觉的，N个发布基线的压力，N种不信任你的眼神…。

只知道进入这一行的有很多是新虫，新虫子总是很澎湃的投入工作，不过我更愿意看到这些新虫子投入到大公司工作，这是个反话。在大公司里做测试根本就不要想有分工明确、人力和辅助资源丰富、培训机会多多、工资优厚这
些条件，我告诉你在大的公司里有一句箴言“人干什么都要靠自己，千万别指望别人”。

不过我愿意吃苦，现在我的心理跟当初刚进大公司有了不同，我发现我还是处在技术第一线，我发现了我以前做测试就象是小孩在玩游戏，说真的没用过Unix真不知道windows的烂，呵呵。现在我测试的东西是标准的
MVC，前台windows的，中间层第一层CORBA，使用Oracle的数据库，我每天都在Unix上测试几组的移动业务，前台是个摆设只有我想验证前台的操作功能是否正确的时候才回去点击几下，在这里我想跟
所有的测试朋友说：

$不要相信前台抛出的Message对话框，除非某些信息你真的想得都得不到。

Read more…

假期马上结束了，这阵子一直比较忙，所以测试知识问答系列中断了一段时间，现在补上。
另外，很多朋友问我这些问题从哪里收集来的？其实细心的朋友应该能从我的博客圈子里面找到，这就是从著名的Rob（巨牛的一个人的网站）的个人博客转载来的，Rob有着超乎常人的丰富的项目经历和知识背景，而且他的博客上有超过上百个页面的知识问答，我这里仅仅摘抄一部分个人认为比较经典的部分，有兴趣的朋友可以去这个地址详细访问：

http://www.softwaretestengineer.com/free2/index.html

http://www.softwaretestengineer.com/free/index.html

Q: Which of these tools should I learn?

A: Learn ALL you can! Learn all the tools that you are able to master! Ideally, this will include some of the most popular software tools, i.e. LabView, LoadRunner, Rational Tools, WinRunner, etc. You want to pay special attention to LoadRunner and the Rational Toolset.
Read more…

Q: What is the purpose of test strategy?

A: Reason number 1: The number one reason of writing a test strategy document is to “have” a signed, sealed, and delivered, FDA (or FAA) approved document, where the document includes a written testing methodology, test plan, and test cases.

Reason number 2: Having a test strategy does satisfy one important step in the software testing process.

Reason number 3: The test strategy document tells us how the software product will be tested.

Reason number 4: The creation of a test strategy document presents an opportunity to review the test plan with the project team.

Reason number 5: The test strategy document describes the roles, responsibilities, and the resources required for the test and schedule constraints.

Reason number 6: When we create a test strategy document, we have to put into writing any testing issues requiring resolution (and usually this means additional negotiation at the project management level).

Reason number 7: The test strategy is decided first, before lower level decisions are made on the test plan, test design, and other testing issues.

Read more…

这个题目来源于上周六在广州软件测试交流会的一个主题，pent老弟介绍了他的一个简单但是非常有效的架构。说这个架构简单是因为结果非常简单，除了任务定制，调度之外，没有其他多余的功能，说有效或者强大是因为他实现了一个强大的自动化测试回归机制，系统虽小，该有的功能都有的。这个架构分四个部分：
每日构建（daily build）-》部署（deploy）-》冒烟测试（smoke test）-》结果报告

四个部分是是一个完整的整体，对于有些项目来说，其他中的第二个步骤部署可能不一定是必须的。
先说每日构建，这对于一个产品的研发特别是协同开发的产品来说，是特别重要的一个缓解，而且在很多公司已经形成一个良好的机制，每天下班时间，系统自动根据配置管理进行每日构建，大大节省了研发的时间。
Read more…