朱少民《软件测试的理念与创新.docxVIP

朱少民： 我们从四个方面跟大家交流： 1、软件测试基本理念 2、日常测试工作理念 3、面临的新挑战 4、测试创新-新理念 从我个人来讲，这个理念非常重要，你先有一个理念，相当于“出发点”，一个员工工作做得好不好，态度很重要，态度决定一切，态度非常积极的话，遇到一点困难、遇到一些挫折，也不会气馁，困难挫折反而是财富，将来会做得更好。 你发现BUG确实不是很重要，你要把BUG找出来进行分析，BUG产生的原因，将来不产生BUG更重要。 一个理念对我们来讲很重要，一个人有什么样的理念，决定你用什么样的测试方法、用什么样的测试策略，希望大家建立一个正确的理念，把测试做得更好，个人也会进步更快。 你对软件测试的基本看法，软件测试究竟干嘛的。问题可能大家都知道，但是要经常问自己，软件测试究竟起什么作用，至少软件测试不是目的，肯定是一个手段。大家一定要想到，我们不是为了做软件测试而做软件测试，肯定为了质量。一个基本观点或者一个基本认识决定你怎么做软件测试。 软件测试跟质量息息相关，软件测试是质量保证手段，为了提高质量而进行的重要工作。我们对质量的态度也很关键，你对质量的态度决定你怎么做软件测试。 上午我们从段先生这里听到，对缺陷不要太在意，你要有一个适当的态度，以前有一个BUG或者说缺陷，可能会很害怕，你不需要害怕。就像英特尔要做芯片，一旦生产的时候出现一个BUG，问题就很严重，但是在互联网好一点，如果出现问题了，及时打一个补丁，问题马上可以修正，快的话几分钟，慢的话一两天也能修正，这跟传统软件确实不一样，以前买windows产品，都是用软件包的，直接通过发行渠道发行下去，如果发现问题，要重新生产、重新制作，再到发行渠道，这个过程很长，而这是互联网有利的地方。 这不是说我们把质量的要求降低了，而是侧重点不一样，我们讲有些BUG不能容忍，而现在强调客户体验，这包括腾讯老总，包括淘宝老总，他们都非常重视，对客户体验非常强调。 就像史蒂文乔布斯的Ipod，为什么这个产品做得这么好，就是客户体验做得好，他们做的产品不多，Ipod、Ipad、Iphone，现在股票几百美元，市值也超过微软，就是怎么把客户体验做好，把客户体验权重放的很高。 第三点，测试工作当中有一些基本理念和基本认识，做某一项测试工作，写一个测试计划，或者写一个测试文档，你也应该想达到一个什么样的目标，这个目标是比较重要的。你有什么样的目标也是由你的理念决定。 不同的认识就有不同的理念，对一个东西认识不对了，就可能产生一个不对的理念，有一个正确的认识，就可能有一个正确的理念。你对于一个软件测试或者说软件质量或者说软件开发，甚至产品发布或者客户需求都有一个正确认识，你就会产生一个正确理念。 软件测试概念，一起复习一下，因为软件测试概念也是在不断发展的，最初讲软件测试为了验证程序有没有问题。 “测试是为了发现错误额执行程序的过程”，核心就是发现缺陷，在七十年代或者八十年代，大家普遍都是这样一个认识。 过了十年或者二十年，大家对软件测试有一个更全面或者更深刻理解，你不仅仅为了发现程序里面的问题，应该对整个软件测试或者说系统运行的时候有一个完整评价，对质量评估。有时候发现十几个问题，但是你概括起来是其中一个问题，就像对这个界面设计不合理，或者逻辑不清楚，这样客户体验就不好，虽然你发现了十个BUG，你得到的一个评估结论是客户体验不好，或者说用户界面设计不好，这样对产品质量作出一个结论或者说做出一个评估，这比你发现一个缺陷更重要。从现在的角度从敏捷测试来讲有更新的理念或者认识。 软件测试简单理解就是一个质量检验，就像在传统企业大家知道，一个产品出来，不管是手机还是电脑，都要通过质量检验，刚开始质量不稳定的时候，每个产品都要检验，等这个产品比较稳定的时候，不需要对每个产品进行检验，会做抽样检验。 一个批次的产品出去，必须经过检验，没有检验不能出去。检验相当于个产品质量控制，次的产品或者差的产品不能出去，出去的产品都是保证质量的。 把软件测试扩展，就像我们经常把QA质量保证结合起来，在许多企业不叫测试部，而是叫QA部或者质量部，你不仅仅是一个质量检验，应该有一个质量保证，质量保证应该比质量检验更上一个层次。如果从传统概念来讲，你要对一个过程有控制，保证生产或者开发这个软件产品过程是没有问题的。 你们觉得软件测试有哪些基本理念？同学： 为了满足客户或者说用户需求而产生的工作，包括验证BUG或者检测，以客户为中心。朱少民： 你认为最基本理念以用户为中心？同学： 是。朱少民： 最关键的是以用户为中心，一切从客户角度出发，因为测试是质量保证最重要手段，测试根源在于客户真实需求，你要真正抓住客户需求，刚才讲的客户体验，现在不是没有信息的社会，而是信息太多了，网站太多了，现在团购网就有一千多家，每一个用户有多少时间好好品位网站，他很快了解你的网站，这个体验如何立刻抓住用户的心，就像吸引客户眼球。 客户体验不好，人家立刻去别的网站，这跟以前客户端软件不一样，要下载、安装，而现在不需要安装、卸载，只要用浏览器就可以，一切从客户角度出发，想客户所想，这是我们做测试的基本。 还有几个基本理念，“客户至上、质量第一”、“尽早测试”、“全程测试、持续测试”、“测试总是有风险”。 有一个人提问，他测一个东西不知道怎么保证质量，怎么保证不出问题，段先生也讲我不能保证任何软件上去没有问题，这也是我们头疼的问题，所以你要意识到测试总是有风险。 “尽可能实施自动化测试”，从我理解来讲，大概就是这五个基本理念，这五个理念在今天也是能用的，可能以前就有。 “尽早测试”，大家都知道这个理念，为什么要尽早测试，“缺陷发现得越早，BUG修复越容易，成本约低”，在需求里面存在一个问题，你在需求的时候没有修正，在设计的时候，基于对用户错误的理解，出的问题更大。如果一个需求问题你写出代码，通过功能界面操作发现问题，如果要返工也是更难的，因为代码已经写出来了，设计要改，需求要改，代码也要改，在需求的时候发现问题，就在需求的时候改掉。 “对需求，设计理念更深，质量更有保证”。从成本来讲，你发现的越早，成本会越小，另外本身对于测试也有帮助，更早介入需求，对设计进行验证，肯定要对设计和需求有更多了解或者更深入，反过来把测试计划写的更好，能更好的进行测试，最终你的产品质量有更好的保证。 “全程测试和持续测试”。测试是不间断的，任何时候都要进行，我们刚才看到对软件测试的概念，发现程序里面的错误，需求设计做完之后，把代码写出来，程序可以运行，发现程序里面的问题，上世纪七八十年代，大家对测试主要基于这样一个概念，代码写完之后，程序写好了，让程序人员做。今天也有很多公司这么做，或者不是很规范、不是很成熟的小企业这么做，没有专职测试人员，开发人员把这个东西写好了，交给他，前几天我去一个公司，只有几十个人，他有四个人既做技术支持、又做测试，开发人员说程序可以运行了，然后甩给他做测试，这是真正传统意义上质量控制。 我们希望从开始对于需求设计进行验证，在写需求文档的时候，这时候可能出现问题，即使进行需求讨论，也会产生问题，这时候就会发现问题，你可以对这个需求提出来。 “软件的任何部分（需求、设计、代码和文档等）都会产生缺陷。” 测试人员可以扮演客户代言，这个产品做完之后，跟以前的功能有没有冲突，这样对需求设计都可以进行验证。 “持续集成、持续测试，保证正在开发的软件任何时候都是可以工作的，随时Demo，随时收集产品经理或者客户的反馈，发现问题，不断提高质量。” 这样一方面保证工作很好的进行，另外一方面对开发提出很高的要求，这样对产品质量有更高的提高。 “测试总是有风险的”（软件测试需要承担一定的风险）我们不能保证产品出去一点问题没有，但我们为什么还要做测试，有时候为了一个产品能不能发布，可能有一个BUG非常严重，这时候不能发布，我们要Fix。可能产品出去以后还会被客户发现BUG，也许比不能发布的那个BUG还要严重，因为这个BUG没有发现。 当时我们为了这一个BUG，就不能出去了，结果推迟几天发布，是不是合算，是不是值得，有时候产品明天要发布了，这时候发现一个BUG，这个BUG我们觉得也比较严重，当然不是非常致命的，但也是比较严重的BUG，那我们不能发布了，让开发人员修正，重新构建一个包，再出去。 出去以后，也许客户发现比这个BUG更严重的，其实有BUG也可以出去的。测试就是这样，测试总是有风险的，没有一家公司讲我的产品出去以后保证没有BUG，就像上天的嫦娥一号、嫦娥二号，也会有问题，可能概率很小，万分之一出现问题的概率，否则干嘛我们还有远洋船在厦门有监控的东西，就怕它可能有问题，所以我们在太平洋上有监测船监控嫦娥一号、嫦娥二号，不能保证飞上天的嫦娥二号没有问题。 及时对那样非常重要的产品也会有问题，对于普通应用问题肯定多得多。 “软件测试要将风险降到最低”。软件测试不能保证一点问题没有，所以我们要将风险降到最低，我们时间比较紧，要把最重要功能验证一遍，基本功能验证，保证出去的基本功能没有问题，即使时间再短或者产品发布再紧急，也要保证这一点，我们至少不能出大问题，捅一个大篓子，我们要控制风险。软件测试也是这样，从风险角度来讲，软件测试就是把风险降到最低，我们不能保证没有风险，但是我们已经把风险降到最低了。 “测试任务或访问的优先级设定/选择显得重要”。我们不能保证100%测试，或者我们不能进行永无止境的测试，因为我们测试时间也是有限的，这时候会想怎么把最重要的测试做了，因为测试是有风险的。先肯定要做最重要的，然后做重要的，然后做次要的，有了这个概念，对你的测试执行，包括测试计划或者设置任务安排都是有很好的考量，这样就知道，虽然时间短，也是能完成的。 就像老板跟你讲，这个东西两天之内给我测完。你不能讲我不干，这两天肯定测不完，我有几千条case测完肯定不可能。你如果这样回答老板，老板也不高兴。老板讲你不管加班还是怎样，都要把它测试完，相对来讲你还得完成任务，老板还不高兴。 怎么让老板高兴，然后你又比较轻松的完成任务，一个是把风险告诉老板，这两天我们可以完成主要基本功能测试，这样你的测试相对比较轻松的做完，老板也觉得你还是比较聪明的，知道怎么把事情做好。 你制定测试策略的时候也是有艺术性的，就像刚才的例子一样，并不是一定要做到哪一点，你应该有选择，如果没有风险，就谈不上策略，有足够人力、足够时间、足够资源来完成任务，那还要什么策略，因为你总是有时间把它做完。 “制定测试策略，策略具有艺术性”。你在有限的人手时，必须采取一定策略，付出成本最小，但是获得的回报最大。 “尽可能实施自动化测试”。“电脑本身就是自动化工具”。作为软件实施工程师，要有这样的手段，自动化测试很正常，当初为什么有电脑，电脑叫这个名字，就是代替部分人脑工作，把这个事情自动执行。就像以前做1+1、1+2，现在想起来很简单，有一个计算器就可以做，当时就是做不了。现在在汽车或者各个行业生产线控制都有电脑，电脑本身就是做这个事情，我们搞计算机软件硬件，开发软件测试，自然会想到我们的事情为什么不能让电脑自动做呢。 “自动化测试的益处不言而喻”、“质量和技术上的诉求”。对质量和技术要求我们怎么做，你必须用自动化做，性能测试比较有名的，假如你让一千个人去访问淘宝，我不能把淘宝员工都找来做测试，曾经讲过一个笑话，你可以把几十个人或者几百个人拉过来，然后在机器前有一个人专门指挥大家操作，这是一个笑话。这个角度来讲，性能测试或者什么测试，必须要有工具来做，没法用手工做。 另外有些地方你没办法手工做，比如说后台、服务器端测试，根本不知道后台在跑什么，你用眼睛看肯定是看不到的，数据传输或者在跑数据，你不知道跑什么东西，你没有工具监控或者没有工具发送数据、获得数据，或者对整个通信进行监控，在技术上也没法实现。 另外质量上的要求也是明显的，如果你对产品做了测试以后，你的老板问你，你做了哪些测试，你究竟有没有地方没测试到，是不是把所有地方都测试到了，你怎么回答，你有工具的话，可以看测试覆盖率报告，上面告诉里面有一百个代码或者说里面有一百个类，覆盖了八十个类，这样看的清楚哪些测试到，哪些没测试到，一目了然。没有测试到，我们要分析没有用的代码或者废的代码，永远测试不到的代码。 这个角度来讲，质量和技术要求我们尽可能实现自动化测试。另外从自动化测试还有一个好处，我们让测试工作更有趣味性。 日常工作中，我们有哪些基本想法？有哪些理念左右你的日常工作。 技术理念是实用主义还是求新的，有的人觉得够用就行了，有的讲以前用C语言，然后用C+，然后用JAVA，可能他最终还是不成功，可能你把C语言用好了，可能就像现在讲的非常牛。有的公司强调创新，可能是业务创新或者商务创新，不强调技术创新，他觉得我没必要花很多钱让员工在技术创新，技术上就让别人创新，创新好了，经过一段时间淘汰，成熟了我们拿来用，如果不成熟，死掉就它死吧，这样我们更省事、更省钱，不需要走弯路。 在技术里面也是有的，包括以前IBM的RUP，软件测试统一过程，也强调以价格为中心，一个软件产品做得好不好或者最终是不是一个好的产品，首先要把价格设计好，他宁愿在价格设计上花很多时间做这个事情，他觉得这是值得的。现在敏捷方法里面觉得我不可能花太多时间，可能每个迭代都是固定的，可能一个月迭代一次，价格简单点，不断完善它，后来发现性能有问题或者说安全性有问题，那就不断重构。 有的公司有技术崇拜，我们只用JAVA平台，公司只用技术，思科不提倡技术崇拜， 对我们有用的就用。有的只欣赏一种，这也是一个理念。 刚才测试理念跟我们好像关系不大，其实都有关系的，技术也是根本，我们讲测试人员为什么有时候被开发人员看不起，可能我们没有技术。老板经常想，开发人员能做测试的活，测试的人走了，可以让开发人员走，如果开发走了，测试能不能做开发的活，如果你也能做，那就没问题，就像微软和Google一样的，测试开发至少工作有区别的，责任是不一样的。万一谁走了，一个测试人员也可以做开发的事，或者换开发的职位做，这也是可以的，至少能平等兑换，或者在敏捷测试、持续测试，你也能跟开发对话沟通。如果不能跟开发对话，就谈不上很好的合作和交流。 除了刚才讲的技术理念之外，管理上也是一样，“顾客第一，重视顾客体验”。“忠于流程还是屈服于现实”。“团队是根本，关心团队，精诚合作”。“区分目的/手段，始终不要迷失”。软件测试人员对你的价值是不是重要，一个公司工作做得好，是靠流程还是靠团队，团队是不是最根本，这都是我们一些理念，在日常当中我们的管理理念，管理理念更多的是测试经理人理念，如果一个测试经理觉得团队是根本，他肯定每时每刻都想着员工，他在团队里面每个成员，加班辛苦了，他会走过去沟通一下。最近一段时间，我们团队员工都在加班，比较辛苦，没办法，这是我们业务需求，这时候测试经理就会想，我是不是把他的家人请到公司开座谈会，让他理解为什么要加班，给他送一些礼物，让他的家人有感动，或者了解他的爱人或者他的男朋友、女朋友、老公、老婆。为什么在加班，为什么每天回家这么迟，他要想着员工，如果不做这个事情，他的团队成员回家了，有可能就会受气。 测试计划与设计。“常常说计划赶不上变化，还要不要计划？” 是否我们不做测试计划，我们做测试计划干嘛，就是为了写一个测试计划，为了幸福CMM检查还是应付公司其它方面检查，我们有测试计划。“测试计划是走过场，只是文档，还是对测试执行具有实质性指导和控制的过程？” “需要科学、有效率的方法来完成测试用例的设计？”，你的用例设计是不是很好的写，还是一般写出来的，有的是看到功能描述就写一下，把功能点搬过来就变成测试用例。这可能不是真正的测试用例，你要真正发现程序里面的问题，哪些地方出问题，自然会想到边界的地方会出问题，有些地方有组合，组合的地方是不是容易产生问题，计划也是一样的，如果你觉得计划对我们有帮助，你一定会把这个计划写好，计划在平时执行过程当中拿出来看看，是不是按照计划走，或者以前制定的计划是不是有问题，要进行修改，这样计划是有作用的，计划就会写好，计划也确实对你有帮助，否则可能浪费时间，写出一个计划也是没有用。 “测试计划和设计只是测试团队自己的事？”，有的人觉得是团队自己的事，团队自己不断努力做，好像跟开发、产品经理没有什么关系，这个想法是不对的。你要很好的理解产品需求、产品特性，要不断跟开发、产品经理或者项目经理交流，甚至包括客户，甚至可以让客户看看你的测试计划有没有问题。你对测试计划或者设计的认识或者理念对你本身工作肯定有直接影响。 自动化测试理念。“首先是代替手工测试”。有些重复的工作，让计算机自己做更好，因为比较单调。“其次，超越手工认识”。我们希望比手工测试做得更好。“向自动化测试要效益（ROI）”。是不是比手工测试合算，有时候做自动化测试做得很累，觉得好像做得挺好，但是效率并不是很高，还没有手工测试轻松，这样做自动化测试有没有意义，当然性能测试不得不用自动化做。 就像用户界面，应用层的测试，合算不合算，有的觉得不合算，不做UR的测试，UR测试还是让手工做，包括微软等其他一些公司，把一些简单测试外包出去，自己就不做这部分，因为变化最大的肯定是界面这一块，而且这块自动化测试也比较难做。 一定要想到投入产出，你要投入的小、产出的大，如果投入的大、产出的小，就是为了做自动化测试而做，这样也没有太大意义。 “让自动化测试无处不在”。不仅仅做功能测试的时候做自动化测试，是不是其他每个地方都可以做自动化测试，比如说环境部属，或者测试用例是不是可以自动生成，自动化测试不仅仅帮助你完成功能测试或者具体一个测试执行工作，许多工作都可以想到让机器来帮你做。 “构造服务DEV&QA自动化测试框架”。自动化测试不仅仅为测试人员服务，你做好这样的工具或者框架，也可以为开发服务，在有的公司，许多测试让开发人员做，只不过测试工具或者测试框架由开发人员提供，这又是另外一种理念。 你要想到，做好一个测试工具，有时候对开发反而有更多的帮助，比如说安全性测试，你每一个输入的地方都要进行验证，开发写完代码，我来进行扫描验证，要我有这样一个工具，如果开发写好代码，你扫描，结果有50个地方没有过去，当然发现了50个BUG也挺高兴，一下发现这么多问题，如果把工具改给开发人员，开发人员Check in代码之前或者写好代码之前，自己检查一遍，自己发现问题，自己修正，到你这里，再扫描一下，可能一个问题都没有，你看哪一个更好。 当然把你做好的工具给开发用，让他先扫描，有问题他自己先解决，到你这里来就没有问题，当然这样更好。自动化测试不是完全为测试人员自己服务，这完全可以为开发人员服务。 软件测试面临哪些新挑战？以后可能没有操作系统，可能只有浏览器，也许这一天会到来。总的来讲，我们测试的挑战越来越多，大家觉得有什么样的挑战？我曾经听有的朋友讲过，每个礼拜都要发布一次，当然做互联网，因为竞争太厉害、压力太大，要产品做好，可能要花一年时间，把主要功能做好，一年以后发布出去，这时候市场可能被别人抢了，因为你没有出来，人家先用了，一旦用习惯了，不一定用你的，特别是一些社区网站，一旦有用户数据，或者用户已经把很多数据放在上面了，QQ也是一样的，许多数据都在上面，你的朋友ID号都在上面，你再搬到一个MSN肯定比较困难，这时候你一定要快。 那我先做两个功能上去，大家能用就行了，以后再加一个功能，不断加，先让用户用起来，而且这个好处就像敏捷方法一样。如果一年以后做了一个产品，结果去发布，用户觉得不好用，就不用了，你的损失大不大，因为辛辛苦苦做了一年，投入几百万甚至几千万，做了一个产品以后，用户不喜欢，是不是傻眼了。如果你做一个月就把这个东西推出去，用户觉得不喜欢，你损失的可能就一个月，第二个月可以改变界面风格，或者改变功能，改变用户体验，第二个月又做出一个东西出来给用户用，用户觉得很喜欢，在这个基础上不断改进提高。 你对BUG的容忍程度是不是比以前高一些，你觉得质量不是特别高的时候，或者没有做到足够的测试，原来做测试五天，现在做三天就出去了，你自然会想BUG多一点，就要打补丁包，不然客户发一个问题了，马上就过来，就想马上要把问题修正，今晚就要上服务器，测试人员很苦的，开发人员改好以后进行测试，开发人员很容易，发现问题改一下，测试人员是不是仅仅验证BUG就行了？肯定不行。因为你要做回归测试，因为改了这个BUG，对别的地方没有影响，当然你可能不需要做，多数开发人员不能讲没有影响，特别有的地方改动大一点，如果有的地方确实改动很小或者确实比较独立，他跟你讲不会影响别的地方。 特别有些老的代码或者开发人员写的代码不够好，这种关联性比较大的，他改了以后，自己也没有把握，甚至你最好把所有功能测试一下。当然发布的计划是什么，今晚就要上服务器，要把所有东西测试一遍，还要一个礼拜时间，这是带给我们的挑战，特别是互联网应用带给我们的挑战越来越大。 新的挑战-外部。 1、软件（开发）技术日新月异； 2、需求不清楚或者变化频繁 3、越来越多的企业引入敏捷方法 4、系统越来越庞大、复杂 5、竞争激烈，对质量有更高的要求 现在宽带进每个家庭，上网的人数比以前多了，淘宝在中国这么红，至少是上网的人多，或者有支付宝保证，否则以前上网买东西，第一是不敢买，另外以前上网的人也少，现在大家都上网。 包括手机上用淘宝很方便，像Iphone有这样的应用，完全不需要用电脑，直接在手机上应用，很方便。但是许多需求是不清楚的，你要面向互联网用户，需求确实不稳定，以前我们做市政府项目或者做省电力局项目或者水利厅项目，那些项目是比较稳定的，知道他要干嘛。 新的挑战-内部。 1、如何确定有效的测试方法？ 2、如何适应敏捷方法？ 3、如何提高自动化测试的效率？ 你做了测试，或者说测试方法写出来，你的老板会问你，是不是最有效的方法，就像我们刚才讲的，如果测试一定要讲要五天，那实际上我们只有三天时间，你有没有有效的方法做。 有的公司用敏捷方法也不是由你决定或者由我决定，可能哪天你的老板高兴了，觉得要用敏捷方法，大家都在用敏捷方法，我们也要用，也许不是互联网企业，可能是传统企业，也会受到潮流影响。在我们国家这种一窝蜂顺潮流现象更严重一点，看到别人用敏捷，我们也用敏捷，看到人家上CMM，我们也上，可能不一定适合用敏捷方法。 思维方式的创新。面对这些挑战，我们要创新，要想办法应付，创新也是一个很大的话题，至少思维方式要创新，有时候你的想法少，也不是你太笨或者别人很聪明，可能是你的思维方式不对。 “创新无处不在，而不是创举”。“创新换个角度看问题，思考的着眼点不同”。 怎么把一个测试计划写好，怎么做好测试用例，怎么做好测试报告，都是有创新的，什么是创新，很简单的，你换一个角度看问题，人家从这个方向看，你要走过来，从那个方向看。你要从不同的角度，当然不完全是物理角度，还有思维角度，你的视点不一样，就像看一个楼一样，从底下看觉得楼很高，如果坐在飞机上看这个楼，不会觉得很高。 “测试方法、资源和元素等的转换”。以前用这种方法测，现在能不能换另外一种方法测，原来是张三测的，今天能不能让李四来测，创新不一定是非常大的创新。 “跳出圈子思考（think out of box），旧的思维习惯、规矩、环境可能是创新最大的障碍。” 为什么没有创新，可能觉得别人是这样做的，或者公司流程就是这样的，大家都知道Gmeet（音）是一个性能测试工具，现在许多人用Gmeet（音）做功能测试，为什么能做性能测试，也不就是因为根据不同协议，发送数据包，然后获得响应。如果让你侧一个FTP服务器，或者HTTP服务器，是不是要给它发送数据包，或者你要进行一个API测试，是不是也要发送一个请求，这些请求也是可以获得的。 人家用Gmeet（音）做性能测试，我也可以做性能测试，同时也可以做功能测试，不要受到原来的限制，大家都是用Gmmet（音）做性能测试，我也做性能测试，可能手头有一个项目可能适合用Gmeet（音）做功能测试，但是你不知道用什么方法，也许这个Gmeet（音）工具就在你眼前。 “没有最好，只有更好，持续创新”。确实是没有止境，工具也是没有止境的，就像有一个测试框架，测Web，它也是有问题的，有些地方不好处理，现在有新的框架，设法弥补它的不足。人家已经做了一个工具，它虽然很笨重或者说是一个很重量级的工具，多数情况下不需要这样的重量级工具，有时候需要轻量级工具或者更好用的工具，你不要认为它完全是最好的，你完全可以做一个超过它的工具。 “组织、团队创新文化的培育，如开放、多样性”。公司里面搞一些创新活动、搞一些奖励。 创新无处不在 1、测试具体操作和方法的创新 2、测试技术的创新 3、测试流程的创新 4、测试理念的创新 测试技术的创新，现在大家可以看到，基于模型的测试或者说模糊测试、探索性测试，这些都会有一些新的方法出来，针对你自己的应用或者说具体领域，看有没有更好的方法。 测试流程也可以创新，然后你测试理念是不是在变化。以前我们讲测试就是为了发现程序里面的缺陷，现在我们对测试的认识是不是还是这样。 报告缺陷的过程是否可优化，例如建立缺陷模板？现在很少用word或者Excel做报告缺陷，我们肯定用一个系统在做，我们公司自己开发一个系统。在一个项目里面或者说负责一个模块，比如说做淘宝网站的时候，有的人负责log in模块，有的人负责搜索模块、查询模块，有的人负责定单模块。可能你老报一个模块的缺陷BUG，经常有些东西要重复填，比如模块信息、版本信息、浏览器信息，你一天报BUG比较多，这些信息重复填是不是浪费时间，或者你的效率比较低。 这时候你能够建立一个模板出来用，效率比较高一些，你只需要填一些操作步骤或者说期望结果，大部分不用填了，因为模板可以自动生成，这样也是一个创新。 测试环境部署可以一键就完成？你能不能更快，按一个键，这些事都做完，是否可以做到这个程度，如果能够做到这点会更好一些。 做测试一定要有测试环境，特别是做性能测试的时候，我们想模拟真实环境，你做性能测试，如果和真实环境越接近，你的结果越准确、越可靠，如果环境不对，那就不可靠，你要建立一个相对比较真实的环境，可能需要许多服务器，不一定要用虚拟机，不一定都要买机器了。除了买机器花钱以外，买完之后还要占空间，还要用电，还不环保。 现在这种数据中心虚拟机很多，确实不需要用很多物理机器，可以把一台物理机器的内存加的很大，然后产生七八台逻辑的机器。有时候要想，在你的数据中心，服务器实际运行环境如果用的是物理机器，你要做性能测试，是否可以用虚拟机，这时候要想一想，你即使想用，也得跟你的架构师或者开发人员，包括运维人员，要跟系统工程师讨论一下，用虚拟机的环境是不是跟他相当的、是不是一致的，如果他不认可，那不行，如果做性能测试，可能还要用物理机器，如果他有一种替代方法或者说折算方法，其他可对比的方法，那也是可以的。 “新人进步慢，是否可以采用一帮一的导师制？”有的新人是不是进步很慢，很慢的原因在哪里，可能考虑师傅带徒弟，新人进步慢或者说新人不好，是不是可以不招新人？几乎不可能，也许你有办法，用外包，至少你可以往这个方向想，不一定招新人，甚至挖过来的，找猎头公司，只招老人，不招新人，各个公司都不一样，像IBM公司就不用老人，只招毕业生，因为毕业生相对是空白的，没有养成一些坏习惯，或者说没有别人一些理念，招进来之后完全变成IBM文化的人，我不仅希望有中文的，也有希望有印度、南美过来的人，思考角度差异化，这样更容易创新。 你要不断换角度思考，如果有这个问题，能不能换一个问题，虽然这个例子不是很恰当，但是新人进步比较慢，是不是可以不招新人或者换一种方式。 能否最小化回归测试用例范围？“基于经验判断，选择受改动影响的用例”？我们节奏很快，一个礼拜发布一个版本，或者两三天就要出去一个东西，这时候回归测试给我们带来的压力最大，我们经常讲，修正几个问题或者说做几个新功能，开发压力没有这么大，把几个BUG FIX就可以了，不管别的了，别的要我们来管，要我们进行回归测试，因为回归测试可能更重要的是讲你原来好的功能，正在用的功能，如果客户不能用了，对客户的影响更大。因为新功能客户用的少或者说不用，老功能用习惯了，可能对客户影响更大。 新功能出现问题，甚至可以关掉，不用了，但是老功能就不行，新功能出问题，可以不断用，回归测试确实很重要，同时回归测试也是对我们测试人员挑战最大的。 我们有什么办法，以前有一种是基于经验判断，根据经验来讨论，做一个改动，可能影响哪些地方，可能哪些地方不会受影响，我们对有影响的地方做一些测试。另外一种我可能判断不出来影响，不知道你这个改动对哪些地方有影响，可能是对新功能的或者说是改动BUG，但是我知道哪些功能对客户最重要，这些先进行测试。 “基于80/20原则，选择主要功能相关的用例。”从这个角度来讲，基于这个原则，可以减少很多回归测试工作量，完全可以做到这一点，两天或者一个礼拜可以发布一个产品。 “基于缺陷数据，选择哪些缺陷关联的用例？”，有的测试用例从来没有发现BUG，比如说一百个测试用例，发现BUG的测试用例比较少，那些是比较好的测试用例。 是不是不还有一些更好的方法？基于经验也是比较危险的，这种经验判断错了就非常危险，8020原则，完成20%最常用功能，但是80%里面不是用户最常用的，但也是用户比较重要的功能，用户用的比较少，但是出现大问题，也是影响比较大的。 同学： 我是淘宝测试的，测搜索的，我们一个星期发布两到五个版本，基本上每天都要发布版本。我们在这里第一个和第二个都用到了，另外是用Def（音），改了哪些代码，根据那些代码来看对哪些地方有影响，我们死死盯住改动的地方，因为每次改动的比较少，不是重构的，通过这种方式来决定我们要回归多少东西。朱少民： 改动的地方影响别的地方怎么办？同学： 在测试的时候，平时把所有代码都看一下，了解一下架构，这一块跟其他模块耦合性比较小，如果另外有影响的时候，我要测试相关模块，这个模块要看一下有没有问题，谢谢。同学： 我支付宝的，我用的方法差不多，这块代码改动的话，是否其他地方有调用，用这个方法评估我应该回归哪些点。朱少民： 你怎么知道其他地方有没有调用？同学： 可以查到的。朱少民： 平时维护一个类的关系图，有吗？同学： 支付宝曾经提出过一个想法，类似于平时测试维护一些东西，主要是类的上下文关系，这样可以辅助我们更好的判断影响范围，在每一个改动里面。同学： 我们每周要发布之前，都有一个核心回归，这个产品主要功能，这些功能会有用例库，我们用自动化跑，避免分析不到、遗漏的点。同学： 如果用配合测试的话，代码的影响面需要研发人员给我们测试来提供比如更改的某个功能，应该他来分析更改对于整块代码来说影响面多大，到底牵涉到哪些模块，这样对于黑合测试来说重要一点，百合测试的话，可以自己测试的。 同学： 你说让开发告诉你哪些地方改动，他一般基于自我保护，他会说你全部测一下，希望你多测一点，而我们自己看的时候，要全部测，肯定没有时间测，开发告诉你，不是很靠谱，希望你多测。 朱少民： Def我们肯定会用的，知道代码做了哪些改动，另外一个是你要知道这位同学讲的，你要知道代码之间的关系，最好有一个类的关系图，或者方法调用之间关系图，你要维护一个举证或者说一个表。 一方面要知道这个表或者说这个举证所维护的类或者方法的关系图，或者函数级的更好一点。你如果不知道这个关系图的话，代码改动的地方我们比较容易知道的，至少可以让开发跟我们一起看一下代码改动哪些地方，即使不用Def的话我们也应该知道，我们最怕回归测试是什么，他改动的地方影响另外一些地方，那些地方出问题我们不能把握，这样一个关系非常重要。 第二个，我们能不能建立测试用例和代码之间的关系，如果你测试用例不多，那也是可以做的，如果你有几万个测试用例，那就比较麻烦，我们看测试用例经过哪些方法、哪些类，你反过来改了哪些方法、哪些类，受到影响的方法和类，就知道测试用例和它哪些有关系的，这样选出来的用例最小，而且相对来讲最可靠、最优化，这才是又一个创新的地方。 光知道原理不够，还要去实现，现在有些工具也可以帮你做事情，现在有代码覆盖率，运行艾玛或者其它一些工具，当你运行测试用例的时候，它会自动给你产生覆盖情况，如果测试用例是自动化的话，那给更方便了，每运行一个测试用例，产生一个覆盖率表，很容易建立测试用例和代码之间的关系。如果你再有一个代码类关系图，或者说方法关系图，以后的回归测试可以做得非常有效、非常快。 新的理念： 1、敏捷测试 2、流程是次要的，团队才是根本。 你用敏捷方法，相当于整个过程迭代快，测试也要快，你的敏捷测试基于许多东西实现，但是你的测试也要敏捷，也要更快，或者足够快，刚才淘宝同学讲，每个礼拜两到五次发布，如何跟上发布节奏，你的功能测试或者性能测试都要跟得上。 流程是次要的，让你一个礼拜发五次的话，最基本流程是需要的，根本流程不能破坏，万一破坏更容易出问题，有时候太快太急，如果没有章法，更容易出乱子，同时流程不是最重要的，最重要的需要我们团队更强。 “