《软件测试实战-微软技术专家经验总结,pdf》由会员分享，可在线阅读，更多相关《软件测试实战-微软技术专家经验总结,pdf（18页珍藏版）》请在金锄头文库上搜索。
1、为了适应公司新战略的发展，保障停车场安保新项目的正常、顺利开展，特制定安保从业人员的业务技能及个人素质的培训计划软件测试实战:微软技术专家经验总结,pdf微软软件测试质量体系最佳实践培训总结一培训的总体情况这2天培训整体情况感觉挺好的。讲师陆宏杰有丰富的软件开发，软件测试，团队管理经验。并且在自动化测试技术和测试管理方面积累了大量的实际项目的经验。对于各种测试方法的重点，难点和实施技巧有深入的研究。在培训的过程中充分体现出来。讲师是提前收集了大家的问题，然后在讲课的过程中穿插讲解对这些问题的看法和解决办法。讲课的内容很紧凑，讲课比较有技巧，容易理解。特别是针对有管理经验的测试人员。培训第一天主
2、要围绕如何对缺陷进行预防展开，提出开发，测试可以并行进行的想法，后又讲解了缺陷的统计大家一起分析，来体现缺陷统计对实际工作的推进作用。接着又讲到站在测试的角度如何对项目产生影响和起到引导作用。需要测试推进，建立一套质量保证体系，使得项目按照既定的方向和标准前进。后面提到测试计划，需要跟需求和设计严重相关，所以对于需求和设计的评审尤为重要。提到发布指标，是对开发和测试共同有效，2个角色应该站在项目效率的角度来考虑问题。提到测试用例的有效性，提到白盒测试，等开发代码写完的同时，测试也完成了case的编写，开发来执行case。培训第二天主要围绕测试度量体系的建立和测试方法和技巧，最后将了测试管理。测
3、试度量体系构成要素，目前大部分企业缺的是高效的工作流程，数据统计和数据挖掘，缺陷追踪体系，科学的测试管理。高效的工作流程需要工具来支撑。对测试用例的评判，可以通过需求覆盖率，代码覆盖率来分析。测试用例执行率是项目执行情况的一个指标。他们有个bugdriver的角色，开发经理，测试经理共同关注缺陷。对缺陷的等级，分类，和解决优先级进行评审和安排。测试人员验证的详细程度也是代表一个测试人员的功力。手动测试和自动测试的区别，手工测试需要精妙的测试思想，行业和领域专家，自动测试需要比较高的coding水平。手工测试和自动化测试相辅相成，手工测试的人员的思想沉淀，和指导作用，自动化测试人员把这些想法工具
4、化。性能测试的重点，测试人员如何进行分析和定位。好的环境文化滋生出好的创新，但是也要让员工保持积极的态度。需要员工去挖掘，创造，驱动一些可以改进效率事情。测试人员对多元的测试，测试是否存在hardcode。并讲了具体的实例来启发大家。关于团队的管理，提出对于员工的职业发展，应该是协助员工进行发展，协助员工思考自己的长处和优点，并给自己一个目标，想成为哪一方面的第一，例如性能测试第一，缺陷数第一，行业专家，安全专家，工具专家等。主要看个人的兴趣。后又讲了一个bugbash的竞赛。测试的手段，内容不限，看哪个团队能找出最多的缺陷，并评选出最严重bug，最酷bug，最有力度bug等。二培训对目前个人
5、的影响1管理的认识A对团队建设和员工管理的认识目前自己对团队建设的管理比较薄弱，后续将不断改进工作。例如对于缺陷数每个月小于10个的员工进行谈话。对员工的职业发展做协助，协助组员分析目前的兴趣和想做哪方面的第一，也是物尽其用人尽其才的思想。对团队氛围的创造，希望创造一种积极向上的气氛，关键自己也要实时抱持一种积极向上的状态，对表现不佳的人员及时提出意见。同时对于沟通方式进行改进。B对流程管理的认识目前的流程管理存在一定的弊端，例如缺陷的管理，无法真正起到缺陷跟踪体系的作用。2.测试发展方向的认识测试发展方向之前的认识也比较模糊，现在是认为只要能一起协助开发或需求来共同提高项目的效率，在这过程中
6、对于每个出现的问题，大家觉得繁琐的地方多进行思考，并用工具来改进效率，应该就是好的工作。关键是要做个有思想的执行者，而不管是做测试或者其他岗位。3.对测试技术的扩充理论知识并不完全可靠，但是理论知识要拿来灵活应用于实际的测试，例如可以用单元测试的思想来进行系统测试。所谓的黑盒，白盒，也都是纯理论，针对工作应该是结合理论来形成一套自己的测试标准，而不管他应该叫什么。4.对测试管理的激情被激发现在觉得测试管理要做的事情太多了，而且工作中需要改进的地方也很多，希望后续慢慢的改进，并提高整体测试人员的水平，通过给开发定位问题，甚至协助开发解决问题，或者在需求评审和设计评审的时候能够提供有效的意见等等。
7、三通过培训并根据项目组的具体情况，对目前的流程提出一些改进意见1.可以把性能指标的收集进行推广，实现常态化的进行。后续将陆续安排收集测试环境bssp请求脚本的编写，和发起工具的编写。并定期进行性能指标的收集分析。2.开发在修改报告中需要体现各个分支的情况，循环的情况，条件的情况，有效路径的情况。以便测试人员进行各个分支的测试用例的编写。3.目前项目组在需求分析和架构建设这块，还是比较弱。测试人员应该站在可测试和可维护性方面对需求和架构提出自己的建议。4.对缺陷跟踪系统的优化A对缺陷分类的改变，功能问题，性能问题，架构问题，扩展问题，可测性问题，安全问题。这样可以对测试人员的测试方向做引导，而不
8、仅仅是站在功能测试的角度进行。B对缺陷流程的增加，项目经理，测试经理定期对缺陷的等级，解决优先级，缺陷类型进行评审。以便后序工作的安排和数据的有效性。对于未按期关闭的缺陷进行自动统计，并邮件通知。5.后续考虑搭建一个独立的build的环境，测试人员需要研究代码的情况下，可以进行加入调试语句，以便进行分析和定位。这些代码不入库。目的仅仅是为了提高测试人员定位问题和分析问题的能力。并安排相关的培训。不需要完全懂得怎么写，只要知道调试信息怎么加，如何关联查看代码。6.关于测试环境管理的工具化，这块后续也将考虑，看下是否可以在统一部署工具中实现，抽取下需要展现的指标，在界面进行统计和管理。例如各个主机
9、，各个程序目前的版本情况，各个主机的cpu，空间，内存情况查看。自动部署程序的研究等等。文档作者：开发/测试经理：项目经理：错误！未指定书签。(仅供内部使用)_日期：_/_/_日期：_/_/_日期：_/_/_错误！未找到引用源。版权所有不得复制错误！未指定书签。1范围1.1主题内容为保证软件的可靠性和安全性，从技术角度对工程软件测试办法作出规定，包括：xxxxxxxxxx1.2目的提供系统化、规范化、工程化、实用化的测试技术规范，尽早发现故障，减少交付系统联试前软件中的残留差错。1.3适用范围主要适用于系统中各组成部分的软件测试工作，其它软件开发工程中的软件测试工作也可以参照。本办法可用于新开
10、发的或修改、更新的软件测试。本办法的使用对象可以是开发人员、测试人员、交办单位委托的第三方测试人员。2引用标准此处加入引用标准3定义此处加入定义3.1单元此处加入单元3.2单元测试此处加入单元测试3.3计算机软件部件及计算机软件配置项此处加入计算机软件部件及计算机软件配置项3.4软件组件测试几组件接口测试此处加入软件组件测试几组件接口测试3.5组装测试此处加入组装测试3.6确认测试此处加入确认测试3.7系统联试此处加入系统联试3.8正式测试此处加入正式测试4一般要求4.1测试目的a通过测试，发现软件错误；b验证软件是否满足软件设计和合同书所规定的技术要求；c检查软件对误操作的处理能力；d为软件
11、可靠性与安全性的评估提供依据。4.2测试阶段及顺序软件测试工作必须做以下各层测试：a静态分析；b组件测试；c组装测试；d确认测试；e系统联试。4.3测试实施要求4.测试用例设计要求此处加入测试用例设计要求4.测试文档测试工作必须编制软件测试计划和测试分析报告两个文档。软件测试计划中应包括测试说明，也可以将测试说明另外成文。独立测试文档格式参见XK-DN-XX-10-11-13测试分析报告。测试文档管理纳入配置管理。4.测试工作进程此处加入测试工作进程图-14.测试未通过处理此处加入测试未通过处理4.测试记录此处加入测试记录4.4测试工作规程此处加入测试工作规程4.5测试组织此处加入测试组织强度
12、测试和可靠性测试是确认测试的一部分内容，为了强调是对A、B级软件的要求而单独列出。其中内部测试同开发小组进行，正式测试应视软件关键性级别由总公司评测中心或评测站进行。建议A类关键性软件由总公司评测中心或评测站进行正式测试。图-25具体要求5.1静态分析此处加入静态分析5.2组件测试此处加入组件测试5.3组装测试此处加入组装测试5.4确认测试此处加入确认测试5.5系统联试此处加入系统联试5.6可靠性测试此处加入可靠性测试5.7安全性测试此处加入安全性测试5.8回归测试此处加入回归测试5.9软件错误报告此处加入软件错误报告附录代码检查单格式：嵌套的IF正确地缩进了吗？注释准确并有意义吗？使用有意义
13、的标号了吗？代码基本上与开始时的模块模式一致吗？遵循全套的编程标准吗？入口和出口的连接：初始入口和最终出口正确吗？对另一个模块的每一次调用：全部所需的参数传送给每一个被调用的模块吗？被传送的参数值正确地设置了吗？对关键的被调用模块的意外情况有处理吗？程序语言的使用：使用一个或一组最佳的动词了吗？模块中使用完整定义的语言的有限子集吗？使用了适当的跳转语句吗？存贮器使用：每一个域在第一次使用前正确地初始化了吗？规定的域正确吗？每个域有正确的变量类型声明吗？微软的软件测试方法国内近年来关于软件测试的问题和讨论越来越活跃。但从总体上说交流软件测试技术的多，而探讨软件测试方法的少。这里的“技术”指的是具
14、体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法(转载于:写论文网:软件测试实战:微软技术专家经验总结,pdf)”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至
15、由于测试的引入而带来了新的管理上的混乱。这个时候方法论的思考，更有利于发现问题的根源。即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型，企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。两类经
