[你问我来答第5期]：自动化测试如何帮助我们？（已结束）

dhrbc

6楼：我想学白盒测试不知从何入手，我以前是做开发的，现在刚转做测试。能否给些建议呢？

回复6楼：

这是一个涉及面很大的问题，但同时又是一个很有典型性的问题，很多的测试工程师都很希望能够通过学习白盒测试来提高自己的技术水平，使自己站在和开发人员同一个维度来发现和分析问题。这里我想通过白盒测试的技术特点和学习白盒测试的途径来简短地讨论一下。大概有以下这么几点：

（1）      原则上，白盒测试人员必须要有良好的开发背景。他们除了拥有开发人员的编码知识外，还必须拥有良好的编码风格。优秀的白盒测试人员应该是一个十分关注细节的人。

（2）      对于不同的语言平台，学习并掌握主流的单元测试框架是第一步。对于JAVA，学习并且能够熟练应用JUnit或者TestNG是必须的。对于C/C++，应该有必要学习C++Test或者Visual Unit。对于.NET项目，可以深入学习Microsoft.VisualStudio.QualityTools.UnitTestFramework框架。另外对于纯C的嵌入式项目，RTRT也是很主流的。

（3）      必须掌握单元测试用例的设计思路和方法，能够熟练应用等价类，边界值等方法来设计组织测试用例。

（4）      深入理解“可测性”问题，能够很好的分析处理“代码隔离”，“不可控”，“打桩失真”，“复杂数据结构初始化”，“间接输入”，“私有成员访问”和“中断输入”等技术细节。

（5）      对于单元测试框架，不仅要做到会用，还必须知道它是设计思想和工作原理。因为在有些比较特殊的项目中你会发现，现有的单元测试框架无法满足你的需求，这种情况下就有必要修改或者开发适合项目的单元测试框架。

（6）      白盒测试入门学习不难，但在实际项目中具体应用就很难。会涉及到很多“可测性”难题，还会涉及到大量的技术细节问题。

我想到的大概就是以上这么几点了，不完整和不妥当的地方还请大家一起补充！

（7）    白盒测试的用例切忌不能以走读被测代码来设计，必须以详细设计作为白盒测试用例设计的依据。很多新手都在这一点上犯过很多错误。

我想到的大概就是以上这么几点了，不完整和不妥当的地方还请大家一起补充！

dhrbc

7楼：白盒测试中的判定/条件覆盖法中说道：需要似的判定中每个条件的所有可能结果至少出现一次，
每个判定本身所有可能的结果也至少出现一次。
请问下，判定中和判定本身存在哪些不同呢？谢谢

回复7楼：

判定/条件覆盖是白盒测试中的一个基本概念，为了说清楚这个概念，我们有必要先明确说明一下什么是“判定”，什么是“条件”，请看下面的语句：

if ( (x>3)&&(y<10)&&(z>100))

其中if语句最终的取值就是所谓的“判定”，而其中的“(x>3)”，“(y<10)”和“(z>100)”就是所谓的“条件”，这里有3个条件。明确了这个概念后，就很自然的可以引出以下三种覆盖：

判定覆盖：使得每一个判定获得每一种可能的结果至少一次。对于上面的例子就是if的TRUE和FALSE分支都必须至少走到一次。

条件覆盖：要使得每个判定中每个条件的可能值至少满足一次。很显然，并不是说满足条件覆盖就一定能满足判定覆盖。

判定/条件覆盖：实际上是将判定覆盖和条件覆盖结合起来的一种方法，即：设计足够的测试用例，使得判定中每个条件的所有可能取值至少满足一次，同时每个判定的可能结果也至少出现一次。

在实际的开发项目中，只有极少数的项目会非常严格地要求做到100%的判定/条件覆盖，通常对于航空航天系统，汽车电子系统以及轨道交通系统等涉及到人身安全的系统会对这方面有近乎苛刻的要求，因为我们知道，对于白盒覆盖率有“越到后期越难”的特点，起初做到85%可能只需很少的代价，但是要从85%升到100%所花费的代价将是巨大的，甚至是不现实的，因为做到后期你会发现代码中将会存在“不可达路径”，这时候还必须通过更新开发代码来解决。

zhtking120

专家，你好
    我想问下，从事自动化也有半年多~也参加过自动化框架的开发，但总是觉得不是太适合公司。
所以请请教下专家，怎么样开发出一个适合自己公司的自动化框架

风之雨

我也想问一下
我们一直用ruby watir 做自动化，请问你您对此有什么看法，或者意见和建议？

风之雨

ui自动化和接口自动化 那个能更好的测试系统，ui测试对环境要求很高，前端编码及软件本身要求较高，面对这样的困境，有什么好的意见和建议吗？

ChinaTNT

请问专家，自动化的框架设计，思路是什么？

Nicol.test

你好
  我目前从事手工测试方面的，现在刚刚开始自学自动化测试工具winrunner,请专家给点意见，自学过程中学习注意些什么？或者有什么好的学习方法？谢谢

zhongchao402

茹老师 您好！
   我最近在学习QTP自动化测试工具，我想问下怎么将自动化工具合理运用到web项目的测试中,应用过程中应该注意哪些关键因素

charlen

回复 27# kekia

1.在手工测试用例和自动化测试用例之间的比例没有比较确定的值,主要是根据项目的实际情况来定,依我个人意见我不建议说一开始自动测试用例实现多高的比例,首先你要去尝试自动化在你的项目中是否可行,如果可行是否有相对成熟的框架来支撑.如果想实现大面积的自动化,你必须保证你的脚本能够实现完全的无人职守.否则,带来的维护成本远远高于你手工执行用例的成本.

2.在自动化测试程度相对成熟的团对中,自动化测试应该是个辅助的角色,辅助用例设计者将其转换成自动化用例,然后通过编写脚本来实现自动化测试.当然我说的是相对比较初级的阶段.高级你可以参与用例的设计以提高自动化测试覆盖率.

dhrbc

8楼：1.在自动化测试中经常用到的的测试框架有哪些？能否介绍一下？

回复8楼：

1.“自动化”测试本身分为多个层面，在每个层面，“自动化”一词将具有不同的内涵，下面将简单与大家分享一下各个层面的“自动化”测试内涵以及在各层面常用的自动化测试框架。

首先，在单元测试阶段，有所谓的单元测试自动化，可能有人会说单元测试不都是写完单元测试代码后再以自动化的方式运行的吗。这个观点非常正确，所以单元测试阶段的“自动化”内涵就不是简单地指测试执行的自动化了，而是指单元测试用例生成的自动化以及测试数据的表格化，在单元测试阶段，很多测试用例都是数据驱动的，这个为测试用例的自动生成和数据表格化提供了很大的应用空间。以C/C++为例，单元测试阶段比较好的测试工具有C++Test和Visual Unit，以JAVA为例有JTest等，这些工具都可以基于被测试代码自动生成相应的单元测试框架，并可以很好的应用数据驱动编写组织测试用例。

其次是软件集成测试，这里又可以细分为两个不同的层面。先看传统意义上的软件集成测试，这个非常类似于单元测试，但关注点主要是在软件模块之间的调用接口，对于我们做测试而言，两者最大的区别在于集成测试代码不允许打桩，必须调用真实的底层代码，单元测试代码必须打桩，以上这点就决定了集成测试“自动化”的内涵将与单元测试非常相似。但是很显然，集成测试对于测试框架的要求就非常高了，也就是说我们的测试框架必须可以顺利装载我们自己的并且相互依赖的软件模块，做到被测软件模块Runnable。很不辛，据我所知还没有哪个测试框架能够很普适的应用于不同软件项目的集成测试，所以对于软件集成测试的自动化，通常的做法是借鉴单元测试框架（比如JUnit，TestNG等）的设计思想，自行开发适合于特定软件的测试框架。前段实际我就负责过一个这样的项目，自行开发集成测试框架，该框架的主要功能是根据软件架构设计依次分层加载被测模块，执行驱动代码并参数化测试输入，参数化判断测试结果，测试用例执行后的现场恢复和提供整个测试过程的log信息等等。软件集成测试的另一个层面就是目前比较流行的持续集成（Continuous Integration），严格意义上讲，持续集成属于软件开发实践的范畴，不属于测试的范畴，但是又和软件测试的自动化有着不可分割的关系，也就是说持续集成具有自动化测试的很多特征。我们可以使用持续集成框架/系统在非工作时间自动完成Sourcecode update和Daily Build，之后自动执行代码的静态检查，然后自动开始运行单元测试用例并统计白盒覆盖率，进一步地可以自动运行被测软件并执行基于GUI的自动化功能测试，最后将整个过程的Log以及相关的多份测试报告以邮件的形式通知各个干系人。这里我推荐可以在自己的开发项目中试用一下Husdon持续集成框架。

最后就是功能测试层面，这也就是我们平时讨论最多的传统意义上的自动化测试了。这个层面的自动化测试框架非常多。QTP本身就为此类框架的设计与开发提供了很好的平台，比较优秀的还有基于TDD的RobotFramework和Web GUI自动化的Ruby+Watir/FireWatir等等。其实每个框架都有很多内容可以讨论，限于篇幅，这里不再进一步展开了。

另外还想提一下的是STAF/STAX这个高层次的测试框架，个人觉得很有发展潜力，可以很好的应用于网络环境的自动化配置和测试。

dhrbc

8楼：2.测试组如何规划测试部门的自动化测试框架才比较合理？能否给一些建议？

回复8楼：

2. 测试框架很大一部分是在大量开展自动化测试的基础上积累提炼出来的，所以测试框架的需求是来源于对测试需求的理解和提炼，测试框架的开发是为测试服务的。说的直白一点，就是测试过程中我们需要的常用功能都由测试框架来提供。所以对于测试部门该如何来规划测试框架的问题，我的理解就是该如何更好地提炼被测项目中测试的通用需求，然后以软件开发的标准流程来实现测试框架的设计与开发。

dhrbc

8楼：3.能够给我们分享一下，您多年测试框架的成功经验，谢谢！！！

回复8楼：

3.测试框架的成功我个人认为最关键的核心在于项目中框架的适用性以及在软件架构发生变化时框架的快速适应能力。另外就是测试框架对于测试需求的把握程度。能够很好的实现以上两点我相信这样的框架设计一定是成功的。

dhrbc

10楼：同问 ， 我也想了解下白盒测试， 范围 手段 工具 .....

回复10楼：

请参考6楼的回复，谢谢！

dhrbc

12楼：想入门白盒测试，如何做呢

回复12楼：

请参考6楼的回复，谢谢！

dhrbc

13楼：我想咨询一下，性能测试，我做过1个WEB产品的性能测试，当然算是比较简单的，但是对BS架构产品如何测试有了些了解，目前遇到的问题是，要对一个CS架构的金融产品进行测试，客户端占内存200MB左右，有服务器，数据库服务器，通讯服务器，请问如何测试，应该从哪个方面准备测试知识，哪些指标比较重要？

回复13楼：

就性能测试而言，无论是B/S架构还是C/S架构，对于负载的发起都是基于通信协议层面的，所以测试工具的选型取决于所选测试工具对于被测试系统（客户端和服务器）通信协议的支持。Loadrunner可以支持绝大部分的通信协议，通常你必须了解被测系统的通信协议，然后用Loadrunner选择对应的协议进行试录制。通常Socket协议在C/S架构中用的比较普遍。另外，据我所知，有些公司对于C/S架构应用的性能测试完全采用自己开发Load Generator并集成性能监控程序来进行的。至于说那些指标比较重要，这个我觉得很大程度上取决于系统的性能需求以及应用环境。

pzj228

您好，以下是我的几个问题：
1、若一个公司测试报告没有通过标准，而且客户需求也没有明确要软件质量达到一个什么程度的时候，在测试报告上如何判断软件是否通过。
2、假如是外包测试，属于第三方的外包，是软件使用方外包你过去测试，而开发方是另外，测试环境中的程序等不能由测试控制，如何把握和监督版本的维护。
3、还是以上的外包形式，假如被测软件还存在bug，测试没有明确软件已可以实施，但客户已对软件进行实施，作为测试人员如何应对。
4、你觉得目前测试行业，那种测试类型的人更吃香。
5、你觉得测试没有开发经验，不做白盒的是否有前途。
6、如果测试已有几年经验，有一点编码能力，但是没有开发经验，你觉得要想做更高级的，该从何找突破口！

问题有点多，不过真系想知道专家的意见，多涨见识，谢谢！

karllin

请教几个问题：
1、一个产品已经在使用中，目前是对其进行新功能的叠加或旧功能的改进。此时同时有多个团队在其进行开发，那么手工用例的复用性怎么维护比较好？（由于功能需求的变化很快，有可能1个月，一个原先的功能就被颠覆了，而且有多个测试在对同一模块的不同开发项目进行测试）。
2、在快速开发上线的情况下，如果手工用例和自动化用例相结合，那么怎么来控制投入的成本，避免测试成为项目的时间瓶颈？
3、在敏捷开发的情况下，自动化怎么提前跟进？
4、自动化代码集成测试成为日版本测试的话，采用什么样的机制可以降低人工维护成本呢？

1316016

您好：
我的问题是：

1.如何确保自动化后的Case的质量？
背景介绍：
  当前，我们开发了许多自动化的脚本，现在已经可以与手动的Case关联，并且所有脚本逻辑已被QA review过了，但是当我们进入集成测试阶段，手动测试的TL总是以某某理由，不信任自动化脚本， 仍然要求手动测试，结果，自动测试仍旧没有取代手动测试的effert。
问题：
请问您在实现了自动化之后，又做了哪些事情，保证自动测试Pass的case确实是没有问题的。

2. 关于自动化团队绩效的问题
背景介绍：
我们现在有一个独立的自动化团队，主要任务是编写自动化脚本。但是，被自动化的case比例迟迟无法上升。原因有两个：a. 团队人力有限，我们现在三个专职自动化工程师（QA有15~20个人）。b. 每个release，新增加的手动case数量远大于自动化的Case，我们自动化的比例不升反降。再有问题一造成的负面结果，外界也觉得自动化的投入没有收益。结果，我们辛苦工作了一年，团队在年中时差点解散，这次加薪也很少，郁闷....
问题：
如何体现自动化团队的价值？

zhengxm_16

想问个问题：对于后台程序的测试（那种没有界面的后台处理程序）作自动化测试的时候，怎么选择自动测试工具，如果有现成的工具的话？如果没有比较成熟的工具，自己订制的话，怎么打造自己的自动化测试架构？最好给一个曾经实践过思路。

dhrbc

14楼：茹炳晟：
你好，我想知道你对自动化测试的发展有什么看法。

回复14楼：

这是个非常大的问题，我想这里我只谈以下几点：

1.自动化测试是技术的趋势，但不是行业的趋势。因为有很多小公司和外包项目的公司（这类公司很多）完全没有必要，也没有资源去实现自动化测试。

2.自动化测试不可能也没有必要完全取代手动测试。在将来的很长一段时间里，自动化测试将与手工测试和谐并存，相互取长补短。

3.自动化测试不能“创造性”地发现软件系统的缺陷，这就限定了自动化测试的应用范畴只能是重复性测试和功能回归测试。

4.永远不要为了自动化而自动化，测试工程师必须非常明确测试的核心价值是发现缺陷，而不是发现缺陷的手段。

5.业内切忌不要“神化”自动化测试，对于自动化测试盲目跟风。在开展自动化测试之前必须进行大量的项目可行性分析，成本分析和工具调研，不要以为买了工具就可以开展自动化测试了，工具提供的只是功能，而企业需要的是解决方案。

6.自动化测试是一个长期积累的过程，是一个循序渐进的过程。企业如果从短期的投入产出比来看，自动化测试将不具有任何优势。