在一个软件团队里, 不同的人有不同程度的投入, 我们在 猪,鸡和鹦鹉 的故事里已经说明了. 不同的人还要在团队中担负不同的任务:
开发人员 (大部分内容在: 现代软件工程讲义 2 工程师的能力评估和发展)
项目经理 ( 内容在这里)
测试人员 ( 本篇博客 )
团队中的管理人员/PM 负责分析市场, 设想功能, 定义用户到底要什么 – Why & What.
团队中的开发人员/Dev 负责实现功能, 搞清楚怎么才能满足用户的需求 – How.
团队中的测试人员/QA 搞清楚我们的软件是否满足了用户的需求 – Whether.
最后所有成员一块决定产品是否能发布, 什么时候能发布 – When.
测试/Test 和 质量保障/QA (Quality Assurance) 这两个词经常混用, 这两个概念是完全同等, 还是只是有一部分交集, 还是是另一个的真子集, 众说纷纭, 在各自的语境中, 都有意义。对于《现代软件工程》的语境, 我们这样规定:
QA: 运用各种手段, 在软件工程的各个阶段确保软件的质量能帮助软件团队实现目标。
Test (测试) : 特指验证代码的行为是否符合功能规格说明书 (spec) 的规定。
在这样的定义下, Test只是 QA 工作的一部分。
对测试工作的种种误解
一些人对“测试”这一工作还有很多误, 解例如下面的似是而非的观点:
1) 测试在项目的最后进行就可以了。
这是远远不够的。当你在项目后期发现了问题,问题的根源往往是项目早期的一些决定和设计,这时候,再要对其进行修改就比较困难了。这要求测试人员从项目开始就要积极介入,从源头防止问题的发生。有人会说,我是一个小小的测试人员,项目开始的时候我能做什么?这就是小小测试人员努力的方向。
2) 测试就得根据规格说明书(spec)来测,所以是很机械的。
那不一定,即使你的软件产品功能100% 符合spec 的要求,但是用户也可能非常恨你的软件。这时,测试人员就没有尽到责任,因为测试人员要从用户的角度出发,测试软件。
3) 测试人员当然也写代码,但是质量不一定要很高。
开发人员的代码没写好,可以依赖于测试人员来发现问题。但是如果测试人员的代码没写好,我们依赖谁来测试和改错呢?这就要求我们测试人员的代码质量特别高,因为我们是最后一道防线,如果我们的代码和测试工作有漏洞,那么Bug就会跑到用户那里去。
4) 测试只是被动地接受别人的产出, 然后开始自己的工作, 比较被动, 不能发挥创造性。
也许狭义定义下的 测试用例 是要等开发人员的代码, 然后开始测试。 但是整个质量保证工作(QA)需要前瞻性, 主动性, 创造性的工作。Weinberg 说过: “也许没有任何一项测试技术比前瞻性更有价值” (Probably no single testing technique is of more value than foresight.) [1]
各种测试方法
(注意到上图的黑箱子和白箱子了么? 它们里面装的都是测试的宝贝)
[下面的解释大部分来自于 《移山之道》 ]
统一思想要从基本名词解释开始。
1.Bug:缺陷软件的缺陷
Bug可以分为这三个组成部分:症状(Symptom)、程序错误(Fault)、根本原因(Root cause)。
(1)Symptom:即从用户的角度看,软件出了什么问题。
例如,在输入(3 2 1 1)的时候,程序错误退出。
(2)Fault:即从代码的角度看,代码的什么错误导致了软件的问题。
例如,代码在输入为某种情况下访问了非法的内存地址——0X0000000C。
(3)Root Cause:错误根源,即导致代码错误的根本原因。
例如,代码对于id1==id2的情况没有做正确判断,从而引用了未赋初值的变量,产生了以上的情况。
以下是一个完整的例子。
(1)Symptom:用户报告,一个Windows应用程序有时会在启动时报错,程序不能运行。
(2)Fault:有时候一个子窗口的handle为空,导致程序访问了非法内存地址,此为代码错误。
(3)RootCause:代码并没有确保创建子窗口(在CreateSubWindow()内部才做)发生在调用子窗口之前(在OnDraw()时调用),因此子窗口的变量有时会在访问时为空,导致上面提到的代码错误。
2.Test Case:测试用例
测试用例描述了一个完整的测试过程,包括测试环境、输入、期望的结果等。
3.Test Suite:测试用例集合
即一组相关的测试用例。
提示:Suite发音念作“sweet”,不是念作“suit”,一大半的学生都念错。
测试设计有两类方法:Black box(黑箱)、White box(白箱)。
这是每个接触过软件测试的人都会给出的答案。但这只是整个软件测试的入门知识。可以跳过去,直接讨论下面的内容。
问:我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础,还有哪一个更难,哪一个更有前途,等等。据说河曲数码在搞“灰箱测试”,是不是更高级?能不能简单讲一讲?
阿超:大家都有这些问题么?
杂曰:[略去对此问题热烈的争论500字]
阿超:听了大家的争论,看来我们的确得花不少时间统一认识。
所谓黑箱/白箱,是指软件测试设计的方法,不是软件测试的方法!注意“设计”二字。
黑箱:在设计测试的过程中,把软件系统当作一个“黑箱”,无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”,从软件的行为,而不是内部结构出发来设计测试。
白箱:在设计测试的过程中,设计者可以“看到”软件系统的内部结构,并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法,因为把箱子涂成白色,同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。
在实际工作中,我们不应画地为牢,严格只用某一种方法来设计测试方法。在实际的测试中,当然是对系统了解得越多越好。所谓“灰箱”的提法,正是这一反映。有些测试专家甚至希望我们忘记全部的“箱子”和它们的颜色。
问:如果我是一个开发者,我能做“黑箱”么?
答:并不是要禁止懂得程序内部结构的人员来进行黑箱测试设计,只不过是在设计时有意不考虑软件的内部结构。例如:在测试程序内部基本模块的时候(单元测试),通常要求由对程序结构非常了解的程序员来设计,这是因为内部模块的“行为”和程序的外部功能并没有直接的关系,而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“易用性测试”,在设计此类测试的时候,没必要纠缠于程序的内部结构,而是着重于软件的界面和行为。但是软件易用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和“白箱”没有简单的高低之分。
一旦测试用例写出来之后,大可以忘了它们是从哪种颜色的箱子里出来的,用它就可以了。
问:有人说“黑箱”,有人说“黑盒”,到底是“箱子”还是“盒子”?
答:在网上搜索了一下,“黑箱测试”有超过100万个记录,“黑盒测试”只有70多万。所以“箱子”赢了。
问:但是我听九条说他刚进公司实习的时候只能做“黑箱测试”,这是什么意思?
九条:我刚到公司实习的时候,两眼一摸黑,看到啥都是“黑箱”,即使测试用例是由懂得程序结构的开发人员写出来的,我还是只会机械地运行。我是知其然,不知其所以然,箱子当然是黑的。后来看得多了,学了一些东西,能够了解程序的结构和算法,箱子的颜色就变浅了,好像能看到箱子里的东西一样。
以下的测试术语主要是测试软件的功能。在表7-1所列的测试中,测试的范围由小到大,测试者也由内到外——从程序开发人员(单元测试)到测试人员,到一般用户(Alpha/Beta测试)。
表7-1 功能测试分类
测试名称 |
测试内容 |
Unit Test |
单元测试——在最低的功能/参数上验证程序的正确性 |
Functional Test |
功能测试——验证模块的功能 |
Integration Test |
集成测试——验证几个互相有依赖关系的模块的功能 |
Scenario Test |