作为软件测试人员，最基本的一项技能就是如何把所发现的缺陷（Defect）准确无歧义的表达出来，尤其还是全英文表达时候。 结合以前的一份总结，写下这篇博客。

　　其实从缺陷的描述也可以看出一个软件测试人员的基本功，甚至可以看出软件测试人员在做一些自由测试的时候的投入程度。

　　本文主要以缺陷出现的频率来说明软件测试人员在遇到不同频率的缺陷的时候如何做？

　　缺陷的频率主要有：Always， Usually（>50%）， Sometimes（<50%）， Once

　　对于所有的缺陷，都需要做到的是：

　　1、查看当前测试环境并记录

　　2、记录与该缺陷相关的配置等条件

　　3、记录出现缺陷时候log信息

　　4、描述尽量做到每个步骤最多两个动作，一连串的操作尽量分句说明。

　　5、英语表达尽量用主动句型

　　6、缺陷出现时候的现象一定要描述详细，不要和步骤混在一起描述

　　7、缺陷出现之后若可以继续进行操作，也尽量多做几个步骤，这样更容易发现当前缺陷周围的缺陷

　　8、尽量把缺陷出现时候的相关功能运行情况也都描述详细

　　对于Always和Usually这类容易重现的缺陷，除了以上必须做到的，还需要做到：

　　1、按照缺陷重现的步骤重复做3次以上，这样可以寻找最短的重现路径，可以做到把不必要的过程过滤。（注意：不确定的步骤一定不能过滤）

　　2、同一缺陷现象出现在不同的地方，尽量能够做总结，可以把不同的步骤分别写出。

　　3、缺陷描述以及缺陷出现的各种环境等尽量做到简介且全面，不需要总等到开发人员问。

　　对于Sometimes的缺陷，理论上来说缺陷都能重现出来，所以我们遇到的sometime只是目前还没有找到必然的那个路径。

　　若与开发人员是在一起工作的比较好，遇到这类缺陷的时候，可以和开发人员沟通，简单描述一下，共同推测必然出现的路径。找出更多重现的路径就有可能转为Always或Usually，开发人员解决起来就容易些了。重现不出来，至少也需要把所有遇到缺陷的相关环境都详细描述出来。

　　若与开发人员不在一起工作的，那就尽量把缺陷出现时候的各种log信息作为缺陷附件提交。

　　对于Once的缺陷：偶尔出现一次的缺陷，就是短时间内测试人员自己没有重现出来的，测试时间有限也不可能允许你一直去钻。

　　这样的缺陷，我们测试人员能做到的首先跟开发人员沟通，有时候开发人员看一眼log就知道问题所在甚至推测出必然路径的。否则，我们能做到的就是把上述1-8条把缺陷记录在库，在后续多个版本进行验证（Verify）。

　　作为测试人员，遇到缺陷的时候除了把缺陷描述简洁明了之外，我们更需要做到的是：

　　1、尽量做到及时和开发人员沟通（尤其对需求不确定的情况）

　　2、立刻检查当前状态并做记录（不要间隔时间太长，发现的时候立刻记录，好记忆不如烂笔头）

　　3、如果同样的步骤连续发生好几个缺陷，需要把每个缺陷的频率都标注好

　　4、如果有外部网络或者设备等因素的影响，也尽量把外部环境描述清楚（这样有助于开发人员Fix缺陷）

　　作为测试人员的我们，目标只有一个——软件产品质量好。 我们不但要发现问题还要协助开发人员解决问题。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　什么是外包测试？

　　外包测试是企业把一套成型的产品交给专门的测试组织进行测试，检验产品是否达到用户的使用标准；外包测试的三种服务模式： 现场测试、公司内部测试和设立联合研发中心。外包以优势互补的出发点达到甲乙双方共赢的局面，企业将获得以下收益：降低成本、降低风险、提高质量、提高响应速度和更好的用户使用性。

　　软件测试外包兴起

　　软件测试外包正在给中国软件本地化企业带来新的商机。

　　软件外包测试有两种类型，第一，是对已经本地化的软件进行本地化测试；第二，是对正在开发的源语言（英语为主）提供国际化测试。对第一种类型，国内许多专业软件本地化公司已经积累了许多项目经验；对第二种类型，越来越多的公司正在加入提供软件外包测试服务的行列。

　　从软件测试服务的组织形式分析，对于软件本地化企业有两种常见模式。第一，是在公司内部组建测试实验室和测试部（组），全部测试都在公司完成。这是软件本地化企业最希望的模式，便于人员管理和质量控制，但是需要很多软硬件的先期投入；第二，软件本地化企业组织测试人员到大型软件公司的软件开发现场进行测试。这是大多数软件本地化企业不愿意接受却又实际采用的模式，主要是因为软件开发商保证新项目信息保密安全，便于监控软件测试的进度和质量。

　　对于中国软件本地化企业而言，多年来在为大型国际软件公司提供软件本地化服务的过程中，积累了丰富的外包服务技术和管理经验。另外，国内很多专业软件本地化企业已经或准备提供软件外包测试服务。这些都为软件外包测试的发展打下了良好的基础。

　　软件外包测试的兴起意味着更多的机会。通过提供软件测试服务，国内软件本地化企业可以扩展服务业务范围，扩大企业发展规模，完善企业管理等。

　　软件测试将成为具有广阔发展前景的领域。从行业发展的历史看，任何行业的成长和发展，离不开政府政策的鼓励和支持。幸运的是，我国政府已经十分重视并积极行动起来。

　　当然，企业的发展取决于多个因素，技术、管理和市场缺一不可。对于国内软件本地化企业，在从事软件外包测试的过程中与其它纯粹软件测试机构相比，具有天然的客户市场优势，应该好好把握这种优势。

　　浅谈软件外包测试管理

　　软件外包测试管理，就是指指通过计划、组织、控制等途径去满足软件外包测试任务的需求。本文将从软件外包测试服务提供商（简称：外包公司）的角度，探讨软件外包测试项目的管理方法及实践经验。

　　1、计划篇

　　1.1 选择合理的外包测试方式

　　软件外包测试首先要确定采取什么形式实施。目前外包公司提供的服务方式主要分为两种：“现场测试”和“内部测试”。“现场测试”是指外包公司派遣测试人员到发包公司的开发现场或实施现场工作，实施测试业务。而“内部测试”是指在外包公司将发包公司的被测系统或被测产品带回外包公司，组织测试人员实施测试业务。

　　二者表面上看只是工作地点差别，但实际上差别还是较大的。“现场测试”一般适用于软件测试环境非常复杂、被测软件有较高的保密性要求、测试人员需要服从发包公司测试管理的场合。“内部测试”一般适用于发包公司对外包公司管理能力非常信任、被测软件功能相对比较稳定、开发和测试可以独立实施的场合。

　　外包公司需要分析被测试软件的功能特点、测试要求、外包测试的成熟度，以及公司自身的服务能力，与发包公司协商选择合理的外包测试服务方式，降低测试风险，提高测试的质量。

　　1.2 制定切合实际的测试计划

　　大型软件开发商（发包公司）具有成熟的软件外包测试管理能力，他们通常会自己制订出外包测试计划，让外包公司按照他们制订的外包测试计划实施测试，而一些刚开始接触外包业务的开发商，他们自身对外包测试管理能力较弱，他们通常希望外包公司为他们制订出适合他们要求的外包测试计划，供外包公司实施使用。

　　基于第一种情况，发包公司已经制定了详细的测试计划，外包公司需要全面了解和掌握测试计划的内容，根据自身外包测试的经验和被测软件项目的具体特点，提出切合实际的测试计划改进建议，并与发包公司协商，按照改进建议修改原有的测试计划，最终获得双方的正式确认。

　　基于第二种情况，外包公司需要发包公司提供被测软件的需求文档、软件设计规格说明、测试需求等文档，根据开发商的项目进度、外包费用、质量要求，结合公司自身的服务能力，制定切实可行的外包测试计划。根据客户对测试计划的评价和反馈进行更新修改，最终获得双方的正式确认。

专题入口：http://www.51testing.com/zhuanti/waibao.html

　　外包测试：雷声大 雨点急

　　全球软件产业结构调整，软件外包浪潮此起彼伏，我国成为具有全球竞争力的新兴外包服务国家。在软件外包中，软件外包测试占有重要部分。如果两三年前中国软件外包尚处于“雷声大，雨点小”的阶段，如今国内外包测试服务已经呈现“雷声大，雨点急”的热闹光景了。

　　急先锋

　　在国内软件外包测试服务的大军中，从事软件本地化和国际化服务的国际和国内本地化公司占据了较大的市场份额，是承接软件外包测试的主力军。

　　全球本地化“三巨头”之一的保捷环球公司，在2004年积极加大了对中国市场的发展力度，其中国公司扩大了软件测试工程部，成立了亚洲多语言测试中心，凭借良好的专业服务品牌，与分布在全球20多个国家和地区的总部和各分公司紧密协作，在人才聚集、测试环境、规范流程等方面迈上了一个大台阶，呈现良好的发展势头，目前为客户提供包含功能测试、语言测试、本地化测试、文档测试、测试用例设计、修正软件缺陷等多语言、多平台的全系列外包测试服务。

　　靠软件本地化起家的本土本地化服务公司的表现可圈可点，这些公司义无反顾地成为外包测试服务“急先锋”。面对潜力巨大的欧美软件外包的高端市场，国内本地化公司凭借多年为这些国际软件巨人提供软件本地化，赢得了客户的信任，也由于多年来遵守国际游戏规则提供服务，积累了丰富的国际项目管理经验，这些都为本地化公司成为测试外包的排头兵提供了有利条件。

　　文思创新公司总经理陈淑宁先生于2004年1月，接受了《经济观察报》记者的采访。针对我国软件产业现状，陈淑宁先生指出，中国软件企业起点低，从整个大型软件的开发流程来看，测试是中国企业相对容易切入的点。从这个角度，中国软件企业可以学习微软等大型软件企业实施大型软件项目的成功经验。2004年文思创新公司被科技部认定为“中国软件欧美出口工程”的试点企业。据了解，文思创新目前从事软件外包测试的员工达到三四百人的规模，并且在上海、武汉、美国和日本成立了分公司。

　　博彦科技在2004年年底，完成了向集团型企业迈进的关键一步。凭借在美国和日本设立的分公司和当地人才，它们可以为美国和日本的客户提供软件测试、软件开发和本地化服务，与2004年被认定为“中国软件欧美出口工程”的首批试点企业。博彦科技已经在日本、美国设有分支机构。据了解博彦科技现有员工达400多人，为了实施人才战略，引进和培养优秀的行业人才，它们启动了“金帆计划”，在未来两年内将达到1600人，到2007年达到3000人，争取成功实现上市。

　　天海宏业的总经理孙永吉在2005年1月13日接受中国青年报记者采访时说“去年我们的软件外包的营销额达到700多万美元，40％以上的市场份额来自美国和日本等海外市场。”。早在2002年6月，天海宏业就开始在美国设立分公司，是中国软件欧美出口工程第一批50家试点企业之一。 在软件测试领域，天海宏业提供多平台、多语言的软件功能测试和软件全球化测试，通过位于美国的项目管理中心、位于北京的运营中心，以及位于亚洲各地的合作伙伴，向跨国 IT 企业提供覆盖多种语言的外包测试服务。

　　三模式

　　从为客户提供外包测试服务的业务模式看，共有三种：现场测试、公司内部测试和设立联合研发中心。

　　现场测试模式是人员外派模式，主要就是供应商把自己的人员派到客户的现场提供服务（On-site），这是在做外包初期经常采用的一种模式。在这种模式中，基本上供应商只提供人员，不控制项目开发的过程，项目实施过程完全由客户控制。现在国内很多提供测试外包服务的公司都在按照这种方式提供服务，这从各种招聘网站大量发布的赴微软、IBM测试的招聘广告的火热程度可见一斑。据天海宏业负责软件测试的副总裁石武太介绍，他们公司大约50%的测试人员外派到国际软件公司在国内的研发中心进行软件测试。

专题入口：http://www.51testing.com/zhuanti/waibao.html

　　人生一场虚空大梦，韶华白首，不过转瞬。惟有天道恒在，往复循环，不曾更改。

　　步入软件测试行业差不多一年了，这一年是收获最多的一年。

　　行业现状：

　　软件测试行业，在国内，很具有中国特色：一方面国内软件行业起步晚，与国际水平相比还是有一定差距；此外国内软件测试行业准入门槛较低，大部分软件测试人员从事着底层的手工测试，加上大部分软件公司不注重软件测试，开发与测试比例配置不够科学，整体来看，先天不足，后天失调。

　　还是要拿12306说事，众所周知，12306上线后由于用户流量压力，饱受诟病，这其中，凸显其不重视测试，未经过严格的性能测试，草草上线。测试不能保障软件质量，软件质量保障要靠架构与开发，而软件测试只是保障软件质量的一种手段。当然，没有经过严格测试的软件是对用户的不负责，甚者会出现严重安全事故。

　　未来，相信软件测试行业会越来越规范，软件公司会越来越重视测试，测试人员会越来越专业，分工也越来越明确，自动化测试将逐步取代部分手工测试。

　　回望过去：

　　最初，入职F公司，我所从事的是手工黑盒测试，主要是接口测试，web功能测试。也就是所说的点点鼠标而已，显得很傻瓜，很枯燥也很乏味。工作的主要内容也只不过是写写TC，执行CASE，生成测试报告。当然，我也知道这种状态不能持续太久，没有掌握到核心技术，也就没有竞争力。还是挺感谢这段经历，若没有这段经历，我还只停留在理论阶段，甚者连test case要素都不知道，那段时间，我享受着枯燥和乏味的同时，也享受着测试带给我的兴奋与快感。兴奋与快感，源自我对测试工作狂热的喜爱。

　　随之，我离开了F公司。来到C公司，开始新的接触新的东西，报表测试。

　　报表测试实质是数据测试，报表是根据业务逻辑从数据库筛选或统计指定数据导出来的，所以报表测试最为关键的部分为：

　　1、明确统计对象（需求测试）

　　2、确定统计逻辑（业务测试）

　　3、区分报表类型（统计型、直接展示型）

　　4、测试业务逻辑（数据来源）

　　5、测试存储过程、前端SQL（报表处理过程）

　　6、造数据，检查报表格式，数据，权限是否与需求一致

　　当然，报表测试可以只是黑盒测试。慢慢的我有意识的逐步加强自己数据库与代码方面知识，随着对工作和对测试认识的深入，再加上自己coding能力的提升，我开始做白盒测试，直接定位bug代码。Of course，事情远远没有我想的那么简单。C公司居然十多年来一直处于创业期（尼玛这就是个奇迹），毫不尊重员工的利益（拖欠农民工工资），管理一度十分混乱，当然这些都是题外话；此外，C公司毫无架构概念，数据库设计的不够科学，貌似没有什么数据库字典，数据库的设计只能像秘籍一样口口相传，每个人都很苦逼的刷自己的盘子，然后上线后问题一大堆。我开始明白，C公司就是是矮穷挫公司的行业典范！！！说实话，C公司算是很注重测试，可惜本末倒置，测试人员并不是保障软件质量的关键，开发才是。这段时间，软件测试不仅满足了我猎奇的心理而且带给我诸多惊喜。由于工作需要，频繁接触PL/SQL与java，我开始学习存储过程与JDBC，使用java批量造数据、调用存储过程，使用poi导出数据库数据生成xls文件。在C公司，开发做的也很苦逼，由于不够规范，需求文档不够完善，很多东西都是临上线改的，加班加点。当然，同事们人还都不错，这就足够了。

　　C公司程序猿

　　职业规划：

　　IT行业，主流线路大概这几条：业务、技术、管理。做业务的话一般是需求、售前、市场这些。技术的话就是从手工测试到自动化测试，从功能测试到性能测试，从初级测试工程师到高级测试工程师逐步发展为行业专家。至于管理就是从测试组长成长为测试经理……当然这些需要参照：兴趣爱好、性格、职业。

　　职业规划的两个关键字：架构与布局。架构是根据自己的工作，设计自己的知识层次，用以填充知识。布局就是根据自己的性格爱好，确立自己的发展方向与重点。

　　当然，我希望自己可以成长为行业专家，提供各种解决方案（有点痴人说梦啦）

　　每个人都需要经历一段痛苦，才能沉淀与思考，真正的成熟起来。Anyhow，I have experienced！享受测试所带来的一切。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　什么叫软件测试规范，大的来说是为了保障在软件测试过程中所做的一切是有序、有效、合理等；小的来说可以用“可控”二个字来概括，既然是浅谈软件测试规范，那就从小的开始讲。

　　例如测试负责人跑过来跟项目负责人说，这个产品我已经测试完成了，发现XXX个BUG。好了，我们的项目负责人的可能存在几个疑问了：

　　1、是否按照产品需求的全部测试了？

　　2、测试所用的设备环境是否存在问题？

　　3、测试所使用的方法是否正确有效？

　　4、测试的时间是否超过了预期时间？

　　等等问题开始冒出来了。这里的问题其实就包含了人员技术的可控性、软件测试流程的可控性、设备环境的可控性、时间的可控性等因素。其实整个测试过程中包含了三种因素：人、设备和产品。

　　规范的做法是：测试人员首先需要经过系列的公司测试流程培训、测试方法及技术培训、公司设备维护与管理培训、产品缺陷分类培训、公司各种程序文件的培训等等后，再经过数个项目实际操作考核通过后。依据约束、规范和模板来设计测试计划，再根据测试计划来设计测试用例，依据测试用例进行测试实施测试产品并提交BUG，完成后的测试报告提交这样的一个过程。 针对上面项目负责人的疑问，我们可以回头再去看：

　　针对第1个问题，根据公司测试流程，测试人员首先需要对产品需求进行熟悉后才进行功能和业务流程的提炼，然后通过GB/T所规定测试特性对产品功能进行全面的覆盖；

　　针对第2个问题，根据程序文件对公司设备的维护记录，只有合格的测试设备或软件环境才能给予使用，所以不会存在不合格的测试设备和软件环境；

　　针对第3个问题，根据公司测试方法及技术的培训和评审程序文件的约束，测试人员在编写好测试用例后，要交与测试负责人和其它评审组成员进行测试方法的评审，评审通过后才能按照测试方法实施测试；

　　针对第4个问题，一个合格的测试人员，会根据产品的技术特殊性，风险性，工作量进行合理的测试时间评估，以最大可能地减少误差。

　　所以要想保障测试的规范性，就要通过保障人员技术的规范性，方法的规范性，实施的规范性、保障设备环境及其维护管理记录的规范性，软件环境及其维护记录的规范性和保障产品开发的规范性。从而达到“可控”目的。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　摘要：随着软件产业的迅猛发展，软件产品的规模越来越大，复杂度越来越高，但是软件产品质量却变得越来越难以控制。在软件测试过程中，因为多方面的因素，常常会导致一些错误和失效，为了改善测试过程、使测试过程变得更为有效，需要对软件测试过程进行一个补充，那就是对软件测试的有效性进行评价。本文介绍了评价软件测试有效性工作的一般流程，并提出了一系列用于精确度量测试有效性的度量指标。

　　关键词：软件测试；测试的有效性

　　一、引言

　　如同任何产品离不开质量检验一样，软件测试是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审定，在软件生存期中占据着非常突出的重要位置。在软件测试过程中，测试人员非常关心之前的测试过程有没有得到改善，因为如果没有，那么在下一次又将犯一样的错误，继续执行无效的测试。同时由于测试在整个项目研发过程中占用了相当一部分信息服务资源，因此，管理人员也常常在思考测试是否有效，是否值得投入那么多资金。因此，要改善测试过程、使测试过程变得更为有效，必须不断地评价测试结果。

　　二、软件测试及评测的主要方法

　　1、软件测试方法

　　软件测试按阶段可分为单元测试、集成测试、确认测试和系统测试。

　　单元测试用于完成对最小的软件设计单元的验证工作。集成测试是把经过单元测试的模块按软件的结构组合在一起作为一个系统或一个子系统来综合测试，主要是用来发现程序的架构和体系结构设计方面的错误。确认测试是把软件系统作为一个单一的执行实体而进行的需求有效性测试。系统测试（System Testing）：将系统的测试软件系统和其他资源（硬件、人机交互信息资源和数据库等）都综合起来构成完整的计算机应用系统进行测试，是用来确保整个系统的性能、执行强度、安全性和功能都达到了预订要求。

　　根据测试时是否运行被测试的程序，软件测试技术还可分为静态测试方法和动态测试方法。从测试是否针对系统的内部结构和逻辑处理过程，通常可分为：白盒测试与黑盒测试。

　　2、软件测试评测方法

　　测评方法主要有覆盖测评和质量测评。覆盖测评主要是基于需求和代码测试覆盖完全程度的测评。修正的条件／判定覆盖是基于代码覆盖的评测方式，指定判定中每个条件的可能结果至少出现一次，可每个判定本身的可能结果至少出现一次，并且每个条件都显示能单独影响判定结果。质量测评是对被测试系统的可靠性、稳定性以及性能的测评，在此主要讨论软件可靠性的评测方法。

　　3、软件可靠性模型

　　软件可靠性模型按随机性分类法可以分为随机过程类模型和非随机过程类模型。随机过程模型与非随机过程模型相比，非随机过程模型的软件失效具有重复性，重复性是指同一个故障在相同时间间隔内总是重复出现，失效与时间无关，对于随机过程则刚好相反。

　　4、软件可靠性模型的适用性选择

　　软件可靠性模型可以说是多种多样，如何在纷繁复杂的模型集合中找到适合的模型是一个非常复杂的过程。将各种不同的测试策略用于模型的选择标准，在很大程度上会增加模型的适用性。

　　软件错误就是软件设计者在开发软件过程中引入的软件缺陷，当测试人员采用某种测试用例时，都希望能够对软件进行全面、系统地测试，但事实证明这种对于所有数据都遍历一次的想法是不现实的，是根本无法实现的（小型系统除外）。为了解决上述问题，可以在输入空间中有选择的选取一些数据作为输入数据，来提高测试效率。用事先准备好的输入数据进行测试，软件的错误就表现出来了，并且可以通过若干次的反复测试得到相同的结论。对于以这种测试方法得出的失效数据来说，应当采用Nelson模型或其变形模型比较恰当。

　　对于随机的测试方法来说则是按照某种随机的方式从输入域中选取一定的输入数据作为测试用例来对软件进行测试。这种方式的测试过程中，用于测试的数据是随机选择的，所以不像上面的方法那样具有重复性。这种随机测试的方法在测试过程中发现错误后立即修改程序，假设在修改过程中不引进新的错误，那么软件的失效率必然是逐渐降低的，即给定的时间段内，软件的失效数据将会越来越少。

　　大量的软件可靠性模型都证明，如果测试中的失效数据服从指数分布，则失效数的递减方式服从马尔可夫变化过程，J－M模型及其变形模型就是这方面的典型代表。

　　三、有效性评价的执行过程

　　软件测试的有效性评价的执行过程包含七个方面的内容：确定评估目标、确定度量内容、制定度量责任、选择评估方法、确定所需事实、收集评估数据和评估测试有效性。

　　1、确定评估目标

　　定义目标，是为了使度量过程得到指导。前面提到，评价的目标就是为了识别测试无效的方面，以便采取修复措施。因此应该明确地确定评估执行的目标。在测试有效性评价中需要识别的内容包括以下几个方面：

　　1）识别测试弱项。用某些测试方法不能有效地发现系统的缺陷，识别测试弱项就是要识别这些测试方法中存在的问题。

　　2）识别新测试工具的需要。确定当前存在的测试工具不再有效或高效，并将此作为获得新的或改进的测试工具的基础。

　　3）评估项目测试。评价由项目组所执行的较经济地减少项目缺陷的测试的有效性。

　　4）识别良好的测试实践。确定测试过程中的哪些实践是最有效的，以使这些实践活动可以用于所有的项目中。

　　5）识别不好的测试实践。确定项目组所使用的哪些实践是无效的，以便建议其他项目不再使用这些实践。

　　6）识别经济的测试实践。确定哪些特征使得测试最经济，以便可以改善测试的费效比。

　　2、确定度量内容

　　明确了评价目标之后，接下来的工作就是确定度量的内容，即确定达到度量目标所需信息的类别。应用系统的测试中，有五个方面是可度量的：

　　1）涉及方。涉及方是指测试涉及哪些人，其涉及程度如何？

　　2）测试的程度。测试的程度是指指测试覆盖了哪些区域，对这些区域所执行的测试量如何？

　　3）资源。资源是指测试过程消耗了多少信息服务资源，包括人力和计算机资源？

　　4）有效性。有效性是指每资源单元完成的测试是多少？

　　5）评估。评估是指从测试过程收到的结果值是什么？

　　......

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/11/n-828811.html

　　专题摘要：手机测试是一个很大的题目，涉及到硬件测试和软件测试，还有结构的测试但通常我们说的手机测试，一般是指软件测试，这个一方面也说明了软件在手机上的重要性。一方面也说明手机测试的难度。那么，作为一个测试人员，你了解手机测试吗？

　　小编希望从事手机测试的朋友们能从本专题中有所收获。

　　手机测试知识普及

　　浅谈手机软件测试

　　手机软件大多挑战的只是娱乐、生活咨询方面一块，目前国内的手机测试技术也是属于低端级别的手工操作，缺少自动测试工具进行功能和性能测试。无论从实现技术上，流程的规范性与合理性，还是从对测试概念的理解上都存在相当的不足。

　　对于当前背景下的手机测试来说，要做好手机软件测试，主要从以下几个角度进行测试：UI测试，功能模块测试，交叉事件测试，容量性测试，用户手册测试等。

　　http://www.51testing.com/html/78/n-237978.html

　　移动终端软件测试基础知识：http://www.51testing.com/html/77/n-828177.html

　　使用Mobi Ready进行手机软件兼容性测试：http://www.51testing.com/html/55/n-247955.html

　　Android/OPhone单元测试指南：http://www.51testing.com/html/32/n-828232.html

　　小谈手机测试中和网络相关的几个问题：http://www.51testing.com/html/69/n-133269.html

　　手机测试风险分析及其应对措施：http://www.51testing.com/html/81/n-222481.html

　　手机测试的测试条件：http://www.51testing.com/html/78/n-86578.html

专题入口：http://www.51testing.com/zhuanti/mobilephone.html

　　手机测试经验分享

　　手机测试的一点浅见

　　接触手机测试大概有6年时间，感慨颇多，几乎手机所有的问题都碰到过，从硬件到软件，从结构到生产，几乎样样都接触过。一直想总结一下，但是总是没时间（哈哈，这个是借口），今天趁这个机会就简单写写我的感触。

　　http://www.51testing.com/html/69/n-223669.html

　　从一个真实项目入手分析测试有效性：http://www.51testing.com/html/80/n-828180.html

　　“沙盘雷达”自动化测试解决方案初窥：http://www.51testing.com/html/96/n-828396.html

　　'沙盘雷达'系统助力业务质量提升工作：http://www.51testing.com/html/92/n-828392.html

　　Android功耗测试小工具集锦：http://www.51testing.com/html/30/n-828230.html

　　手机软件测试用例设计实践：http://www.51testing.com/html/23/n-237323.html

　　'沙盘雷达'系统测试方法：http://www.51testing.com/html/90/n-828390.html

专题入口：http://www.51testing.com/zhuanti/mobilephone.html

　　今天在梳理软件测试流程，同时检讨测试部门所做的工作，如何才能提高交付的质量，我认为软件测试做起来复杂，但说起来很简单，只四个字：严进严出。系统存在质量时就是因为这四个字没做好：

　　“严进严出”不到位或未提出明确的要求

　　1、先说“严进”，目前造成软件测试问题很多，bug怎么也提不完的首要问题是“严进”没有做到位，需求不清晰、缺少设计文档，版本冒烟不通过，大量连续的补丁都会对测试造成很大的影响，继而影响到版本质量。

　　1）做到“严进”我们有哪些要求？由于哪些因素的影响，我们可以不进行测试或有条件的进行测试任务？

　　（A）没有需求及设计文档或相关说明：功能已经开发完，但没有需求、设计文档或相关邮件进行确认，拒绝启动测试。

　　（B）需求及设计文档提交给测试部：功能已经开放完，但需求、设计文档没有传递到测试部，且没有预留足够的时间供测试人员理解和反馈需求问题，拒绝启动测试。

　　（C）功能未按计划完全实现，且没有明确的计划变更。（例如计划完成10个功能点，提交测试时仅完成8个），拒绝本次测试。

　　（D）进行计划评估时，发现测试资源、时间无法满足质量要求，拒绝启动测试。

　　（E）测试计划、方案未通过评审，拒绝启动测试。

　　（F）测试用例未编写完成，不能启动测试。

　　（G）版本冒烟测试不通过（标准的冒烟测试用例及规范）拒绝进行本次测试。连续（三次？）不通过后，要求进行计划变更，否则拒绝启动测试。

　　（H）Bug 未按Bug review中要求的进行修改，或bug通过率低于80%时，拒绝本次测试。

　　2）做到“严进”我们需要做到哪些？

　　（A）合理的评估测试计划（包括测试资源、测试时间、测试工具使用、相关组配合机制等）。合理指的是切实可行，且相关单位共同认可。

　　（B）完备的测试方案（主要是测试策略、测试点），测试方案紧扣需求及设计，测试场景符合客户场景。

　　（C）测试用例清晰覆盖面广，且不冗余。

　　（D）版本接收严格，不妥协，基本功能、重点功能、计划要求功能未完成时不进行测试或要求进行计划变更。

　　（E）测试评审。

　　（F）内部测试不通过补丁解决问题。

　　2、再说“严出”，现场不断的反馈bug，不论我们解释的原因如何，首先被想到的就是为什么测试没有发现现场的问题，这个和我们的“严出”有很大的关系：

　　1）功能不符合需求、设计文档，则测试不能通过。

　　2）功能存在P1、P2级别bug，P3级别在10以内，则测试不通过。

　　3）补丁超过3个时，需汇总到一起进行验证。

　　4）每次版本、节点测试完成时，都配备测试报告或测试结论说明。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　摘要：市场对软件质量重要性的认识逐渐增强，但是由于还存在部分公司软件项目过程不规范，导致重视编码和轻视测试的现象。本文重点介绍代表性的认识错觉，并作了剖析和相应的解释。

　　关键词：软件测试

　　随着软件规模的不断扩大，软件设计的复杂程度不断提高，软件开发中出现错误或缺陷的机会越来越多，而市场对软件质量重要性的认识逐渐增强，所以，软件测试在软件项目实施过程中的重要性日益突出，但是由于还存在部分公司软件项目过程不规范，导致重视编码和轻视测试的现象，对于软件测试的重要性，测试方法和流程等还存在很多错误的认识。这进一步影响了软件测试活动的发展和真正提高软件测试质量。一下列举了几种有代表性的认识错觉，并作了相应的解释：

　　一、软件测试普遍被认为是在开发后开始执行

　　软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计执行测试。因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。

　　二、软件测试人员承担发布后所有的质量问题

　　这种认识很打击测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。出现软件错误不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自混乱的项目管理。应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。

　　三、公司和软件测试人员都不重视测试

　　软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划对项目实施过程中任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间，人力和资源。

　　四、程序员认为测试与我无关

　　开发和测试是相辅相成的过程，需要软件测试人员，程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试用例。

　　五、软件测试不可能成为软件测试高手

　　项目的成功往往靠个别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就是编写代码。因此，在这种环境下，软件测试很不受重视，软件测试人员的地位和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至程序员还要高。

　　由于软件系统越来越精密，越来越复杂，软件及系统的质量测试正在成为IT行业中一个新亮点，软件测试行业未来发展前景良好。对软件测试工作的发展方向有以下几点分析：

　　1、BUG预防和早期检测，因为现在把重点放在产品交付的质量上来，预防实践和静态分析仪这样的检测工具将成为主流。

　　2、仿真工具变的很普通，使得仿造计算机环境变得容易起来。在开发过程的早期就可以进行意外和错误流程的测试。代码稳定后，在用真实环境验证仿真是否准确无误。庞大的测试用例管理系统将成为昔日的东西，大量的测试用例生成了却没有使用。

　　3、有用的方法，比如需求覆盖，模型覆盖，代码覆盖将驱动项目开发。机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作，测试小组需要比以往更少的测试人员，留下来的测试人员将是经过更多高度培训过的。

　　4、测试人员的角色更换，测试中界限模糊，在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊，一个既是通过程序破坏事物的测试员又是创建程序用于破坏事物的程序员的专业出现了，关于如何称呼这个新的专业，新闻圈内的人们在进行着无休止的争论。测试于开发界限模糊，测试人员与开发人员一前一后，共同创造可测试的，高质量的代码，测试人员帮助开发人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写出更清晰，可测性更高的代码，使得测试人员的工作更易完成。

　　5、顾客反馈与测试合为一体，交付的产品质量更高。测试人员进行根本原因的分析，我们会问比如我们怎么会遗漏了这个BUG呢？或者我们将来如何防止这类BUG？这些问题，我们的工作就是使顾客满意。复杂的相互关联的计算机世界使得了测试安全这一类新的问题让测试人员不断努力工作，但这没有关系因为这些挑战使测试人员精力充沛。

　　6、测试人员获得尊重测试人员将不再是在最后时刻才被叫来对产品狂轰烂炸，他们将在整个软件开发过程中提供一个可见的，重要的，增值服务。人们意识到，测试是有益的，有趣的甚至富有乐趣。软件测试人员开始扬眉吐气，而且，由于破坏事物至少可以带来创建事物一样的乐趣，人们开始在开发和测试角色之间转换，所有的人将学到更多如何得到良好代码的知识。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　田野，翻滚的麦浪，装满秋的色彩；果园，瓜果的飘香，炫耀着秋的丰硕；盈盈笑语那是秋语将喜悦抛洒。十月，金色，果香，溢满殷实，脑海中满是那句“一年好景君须记，最是橙黄橘绿时”。

　　当时光之快车，日月之风轮，悄无声息地驶入十月的时候，春的颜色、夏的颜色、秋的颜色，一同融进了十月，送来了久等的《51测试天地》第27期。

　　不同的人都会拥有不同的秋天与收获，但每一份收获都凝结着同样的希望和汗水。《51测试天地》第二十七期同样凝结着所有测试朋友们的关注和支持，您可以从中体味精英们成长的酸甜苦辣，引以共勉；也可以从中学习高精尖深的测试方法和技巧，自我提升；还可以从中了解软件测试行业的最新动态，与时俱进。

　　进入测试领域多年的你是否在工作上有些迷茫，不知道后面的职业道路怎么走，感觉很多测试技能，经验都没得到很好的总结和思考？在工作中是否有接触过测试思维导图？思维导图如何作用于测试工作呢？精彩内容期待您的关注。

　　每每打开邮箱，看到广大测试朋友们为《51测试天地》投稿，令我感动，感谢你们对51Testing的信任。我看到了大家对《51测试天地》的期待，对测试人生的感悟，对测试技术的追求。我想说的是，我们会认真对待您的来稿，不论稿件是否合用，都欢迎您常来看看，常来聊聊。

　　真挚的希望每一位业界的朋友能从《51测试天地》中得到一份收获。

下载地址：http://www.51testing.com/html/32/n-827732.html

　　精彩目录：

　　● 层级分量测试方法，专项测试利器................................5

　　● 异地开发机构实现同步测试最佳实践 ............................17

　　● 基于虚拟机用户体验的性能测试.................................29

　　● 基于基本测试路径的Web服务自动化测试工具的设计与实现 .........35

　　● 遐想-构建标准配置服务为中心的测试性能服务....................44

　　● 基于业务流转的MUSA操作剖面构造方法改进.......................50

　　● javaScript测试框架jasmine介绍（二）..........................59

　　● shell脚本监控远程服务是否关掉................................69

　　● 软件测试新人如何得到测试工作 ................................73

　　● 关于渗透测试.................................................76

下载地址：http://www.51testing.com/html/32/n-827732.html