日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | |||||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 | |||
| 13 | 14 | 15 | 16 | 17 | 18 | 19 | |||
| 20 | 21 | 22 | 23 | 24 | 25 | 26 | |||
| 27 | 28 | 29 | 30 | 31 | |||||
搜索标题
最新来客
统计信息
- 访问量: 653
- 日志数: 8
- 建立时间: 2007-01-11
- 更新时间: 2007-12-06
RSS订阅
我的最新日志
-
[ZT]冒烟test与BVT（Build verfication test）有什么不同呢
2007-12-06
冒烟测试是从电路板测试得来的,当电路板做好以后，首先会加电测试，如果电路板没有冒烟再进行其它测试，如果冒烟了就说明这个电路板基本的功能(加电)都没达到,那其他的功能也就没办法测了。软件测试中的冒烟测试，是对软件基本的功能进行测试，目的是确认软件基本的功能正常，保证软件系统能跑的起来,如果基本功能不正常的话,就没有办法进行后续的测试,所以测试人员测试的版本必须首先通过冒烟测试的考验。
BVT（Build verfication test）构建验证测试也叫每日构建(Nightly build),是对每日软件新增的代码进行测试，保证每日软件新增代码不会对关键功能有影响,例如开发人员今天对代码进行了一些修改,下班后就要对这个进行每日构建,看看它是否有语法错误,是否之前实现了的功能现在失效了.
一般都是把BVT和冒烟测试配合起来使用,下班后自动进行每日构建并做“冒烟测试”。每天都对已完成的源程序选取一些重要的测试用例进行BVT测试和冒烟测试，如发现bug,第二天返回给开发人员进行修改.
如果未进行BVT和冒烟测试,测试人员直接测的话,像这种基本功能未实现之类的错误测试出来再返回给开发部进行修改,修改这段时间测试部门就只能等,这样会浪费测试部门很多的时间和资源. -
[ZT][Part]每日构建与自动化测试
2007-12-06
昨天去听IBM的一个工程师讲解他们的RFT，由于去完了基本上就没听到什么内容，只是觉得IBM挺强，几乎把以前所有东西都搭建到Eclipse平台上……下来以后趁他收拾东西的时候问了几个问题。第一就是IBM内部的自动化测试实施率有多少？就是自动化测试占总的测试用例的百分比~得到的结果让我惊讶：15%！原来在IBM也就是15%的用例实现了自动化。那么我又问了一个问题“IBM现在开发一个产品都是每天build一个产品然后每天做一次regression的么？”答案是“看项目需要，有些项目可能还没有自动化环境，有些项目组可能比较先进，但是一个版本出来以后至于是BVT还是Regession那就看项目要求了。”
(原来IBM也这样哦，呵呵)
常常在谈及到自动化测试的时候总会跟每日构建沾上边，让大家总觉得有了自动化测试就能实施每日构建，然后每日回归测试，然后产品就能顺利发布。但是每日构建只是手段不是目的，自动化测试在这里面扮演着辅助的作用。不要觉得每日构建加上自动化测试就无敌了。迷信某种技术带来的后果通常都是走进了死胡同。
（嗯，我也觉得是这样的，总觉得现在的人习惯把自动化提高到一定的程度呀）
-
[ZC][Part]敏捷测试用例设计
2007-12-05
敏捷宣言：
个体和交互比过程和工具更有价值；
能工作的软件比全面的文档更有价值；
顾客的协作比合同谈判更有价值；
及时响应变更比遵循计划更有价值。
(满有趣的，虽然心中有点抗拒，但我觉得从某方面来说是有效的，只是如果能用不太规范的手段来达到规范的结果呢？这是个学问吧)
测试用例的粒度
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。
测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(同意，有时候觉得写case是个很无效的过程，尤其是反复在写一些很熟悉的case（也许反复做这个工作的我就有问题）)
测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。 (这里有我点不赞同，如果不理解需求，如何能写出高效的用例呢？只能说在设计的过程中加深理解)
......
要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing（这是什么？） – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。
不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。 (同意，设计用例不应该是一个阶段，那是否很细致的划分阶段本身就有问题呢？)
-
[ZC][Part]我们为什么要写测试用例？
2007-12-05
在上年的时候，我曾经把测试用例比喻成盾，而把测试比喻成剑。（http://www.testingreflections.com/node/view/3041），我仍然相信测试用例的创建会有两个用途或目的：1） 测试用例被认为是要交付给顾客的产品的一部分。测试用例在这里充当了提高可信度的作用。典型的是UAT（可接受）级别。2） 测试用例只作为内部使用。典型的是系统级别的测试。在这里测试效率是目的。在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。......接下来，在测试执行周期中，我不会写任何测试用例。我只会在版本发布后更新测试计划，详细地写出被测试功能特性的列表，以及对应有哪些功能特性不生效、对应的缺陷ID。在版本发布后，我创建详细的测试用例文档描述怎样调用每个功能特性，输入什么数据等等。看起来像是文档，但是有着不同的目标和用途：目的是让回归测试执行更快速进行。例如，我把数据附加上去，从而减少准备数据的时间；我细化一些琐碎的测试用例，测试人员（新手除外）会添加错误处理的一些细节。我尝试使用测试白板（Testing Dashboard）（这是什么？蛮有兴趣的）去替换正式的包含测试用例执行/通过/失败/未执行等信息的测试报告。有时候，我只是通过非正式的所谓我的感觉之类的东西来沟通进度，而这其实是PM（项目经理）想要知道的，而不是测试用例的数字。 -
[ZC]软件测试成熟度模型TCMM
2007-9-07
在衡量软件企业的是研发和管理能力的是CMM以及后面推出的CMMI，很多公司通过CMM的各个级别的认证，为企业承接项目添加了砝码，而对于软件测试行业来说，还没有出现一个认证机构，测评一个从事软件测试项目的企业具有的能力。其实在几年前，已经推出的TMM（Testing Maturity Model），而我个人认为使用TCMM（Testing Capability Maturity Model）更为合适，TCMM也分为五级。下面我们就看看是如何划分的，来评判一下各位同仁自己所在的公司，所在的级别。TCMM Level 1：Initial（初始级）
测试处于一个混乱的状态，还不能把测试同调试分开，在编码完成后才进行测试工作，测试和调试交叉在一起，目的就是发现软件中的bug。测试的目的是表明程序没有错。软件产品发布后没有质量保证。缺乏测试相应的测试资源、例如专职测试人员和测试工具，测试人员没有经过培训。这种类型的公司属于这个阶段，处于这个阶段的公司在测试中缺乏成熟的测试目标，测试处于可无可有的地位。TCMM Level 2：Phase Definition（阶段定义级）
测试同调试分开且把测试作做为编码后的一个阶段。尽管测试别看做是一个有计划的行为，但是由于测试的不成熟仅在编码后制定测试计划，因为测试完全是针对于源代码的。处于这个级别的公司测试的首要目的就是验证软件符合需求，会采用基本的测试技术和方法，由于测试处于软件生命周期的末尾环节，导致出现很多无法弥补的质量问题。另外，在需求和设计阶段产生的很多问题被引入到编码中，但基于源代码的测试导致产生了很多的问题无法解决。TCMM Level 3：Integration（集成级）
测试不再是编码后的一个阶段，而是把测试贯穿在整个软件生命周期中。就象软件测试领域的V模型，在需求阶段软件测试就介入了，测试是建立在满足用户或客户的需求上，根据需求设计测试用例和作为测试的依据。处于这个级别的公司测试工作由具有独立的部门负责，测试部门与开发部门分开，独立开展工作。测试部门有自己的技术培训并且有测试工具辅助进行测试工作。尽管处于这个阶段的公司认识到了评审在质量控制中的重要性，但是并没有建立起有效的评审制度，还不能在软件生命周期的各个阶段实施评审制度。没有建立起质量控制和质量度量标准。TCMM Level 4：Management and Measurement（管理和度量级）
测试是一个度量和质量控制过程。在软件生命周期中评审作为测试和软件质量控制的一部分，被测试的软件产品标准包括可靠性、可用性和可维护性等。在测试项目中设计的测试用例别保存在测试用例数据库中便于重用和回归测试。使用缺陷管理系统管理软件缺陷并划分缺陷的级别。但是处于这个阶段的公司还没有建立起缺陷预防机制，且缺乏自动地对测试中产生的数据进行收集和分析的手段。TCMM Level 5：Optimization（优化级）
具有缺陷预防和质量控制的能力。建立TCMM4基础上的测试公司已经建立起测试规范和流程，测试是受控的和被管理的。而达到TCMM5的公司，则坚决贯彻落实测试规范和流程且不断地进行测试过程改进，在实践中运用缺陷预防和质量控制措施。整个测试过程是被以往经验所驱动的，且是可信任和可靠的。选择和评估测试工具存在一个既定的流程。测试工具支持测试用例的运行和管理，辅助设计用例和维护测试相关资料，缺陷收集和分析，为缺陷预防和质量控制提供支持。看了上面对于测试能力成熟度模型的分析，我们不难看出，目前我们国内从事软件测试的公司所处的级别，很多公司还处于2级或3级，这虽然与现在软件测试还是一个尚未成熟的行业有关，测试技术和测试工具还在发展之中，各个公司都在摸索阶段，从事测试外包的公司会好一些，这些公司为微软、IBM、Motorala等公司提供测试服务，基本上是按照委托方的要求或带领下进行测试工作，而国内做软件产品和承接软件开项目的公司，虽然有的建立了独立的测试团队，制定了测试规范和测试流程或者评审制度，但是测试工作还是在摸索阶段，大家几乎没有现成的经验可参考，所以目前急需建立软件测试的行业标准，推动测试行业的发展，让测试有依据可查。
-
[ZC][Part] 请问如何提高测试团队的测试效率
2007-9-07
5，加强测试管理：测试任务有更强的计划性，尽量能细化到测试的功能和测试的case这个级别去监控进度；
6，对于集成测试，还要保证开发部送测版本的质量。避免测试终止或者多轮测试版本才能放行的情况。我们这边会用版本送测次数，版本测试失败次数去衡量开发部门送测版本的质量 -
[ZC][Part] 面试题目
2007-9-07
-
[ZC][Part] 一个高效成熟的商业软件开发流程和团队
2007-8-17
......
虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status Meeting（一般那时工作效率较低，适合开会），在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否block住别人的工作了。在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后
......
若有谁check in的代码导致daily build失败则会被要求某些惩罚措施或警告，象微软公司要负责照看当日的每日构建。有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在check in进去可能会导致BVT（Build Verify Test）测试通不过，因为有些代码没有完全完成，而之前的代码能使BVT测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不check in进去，直到全部代码完成能提交BVT测试时再一起check in进去。
每天我们都会做daily build，一般是在凌晨4点进行，那时有个程序会自动从VSS中拉下最新的代码并进行编译。因为我们同美国进行同步开发，因此如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代码check in进去。若有人check in进去的代码导致编译通不过则会在本步骤中被发现。当编译完成之后自动产生安装包，测试部门将会对这些代码进行BVT测试，同时对VSS中开发库打上label，如果发现了什么BUG就能根据这个label知道是哪个时候开始出现这个BUG的。BVT是指Build Verify Test，是对组件中基本功能的测试。这个测试每天都会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。......
5. 测试
在开发人员完成了function Spec后，测试部门开始了测试规划，确定需要测试哪些方面，如何测试及进度安排。测试人员需要写许多测试代码，有些测试代码需要集成进BVT测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，使开发人员容易找出问题所在并改正。产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。通过了每天的BVT测试，还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终release出去。
......在QA增加BUG和开发人员fix BUG的游戏中，BUG的数量曲线图会象股市曲线一样上下波动，但总体趋势一般是前期BUG放量攀升，后期震荡下挫，若到了后期新open的BUG数量一直上升则说明风险在增大，有可能无法控制，也就是说fix了一个BUG导致了多个新的BUG产生。在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快，当在fix bug阶段，代码的修改较多，因此代码数量的增幅会降低，依据代码量可以看出开发的状况处于何种阶段。
需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的verify必须要让测试本模块的测试人员来verify。
.......7. Code Freeze当P5之前的BUG都被修复了，这时离产品发布日期也就不远了，一般是2个星期后就能release产品，这时要对VSS中的代码进行freeze，以保证代码库的稳定性。Code freeze阶段一般会把各开发人员的check in和check out的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中fix的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如QA、build人员、文档编写者等。在code freeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。