测试经验总结

1 / 38 测试经验总结 测试工作经验总结 功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上 介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。 要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面 来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些 bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写 sql 语句对结果进行验证。 2 / 38 了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。 测试用例的编写经验 1 步骤和数据的分离 将输入的各种数据已参数的形式表达在操作步骤中，而不需要为每一种输入数据创建一个测试用例。 例如： atm 存款 好的测试用例，在执行的步骤 (Step)的表达上应该是尽可能和数据相分离。举例来讲，有一个 ATM 机取款的功能，可能有以下几个场景： 1. 密码正确的登录 2. 密码错误的登录 3. 密码输入三次错误，卡被锁定 3 / 38 4. 取少于余额的款项 5. 尝试取大于余额的 款项 6. 尝试取等于余额的款项 (考虑手续费 ) 6. 取款额度大于当次的限制 7. 取款额度大于当天的限制 7. 取款次数大于限制次数 等等 不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下 (此处只列出了操作的步骤，略去了系统的交互中的反馈结果 )： 1. 插入卡 -A:输入密码 -B:按 “ 确定 ” 键 -重复 A-B 2. A:选择取款功能 -B:填写取款金额 -C:点击 “ 确定取4 / 38 款 ” 的按钮 -D:取现金 -重复 A-D 因此，我们只需要写出 两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢 ? 2 单独的测试基础数据准备工作 将测试基础数据提前准备好，写到你单独的测试数据准备文档中， 而不是分散到 所有使用到它的 case 中才去描述。 3 测试用例的前后置条件 除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。集中的把 这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。 顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要 3 种操作系统和 3 种浏览器的组合等，我们可以把他放在 Test Set 这个 Level 上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。 5 / 38 1.测试人员和用户的联系与区别 黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。 八个字归纳：用户是用，测试是测。 用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。 应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户 培训。 2.带着问题去测试 阿猪工作守则第一条：带着问题去测试 6 / 38 测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的 bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。 3.测试期间提问题和交流的时机 什么时候应该提问题？ 我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？ 培训 培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的 过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致7 / 38 和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。 阿猪工作守则第二条：培训时脑子灵活转动，多想多问 以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。 计划评审 提出对于软件不理解、安排的任务不明白的地方。 测试期间 这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排，因此， 8 / 38 影响测试流程和进度的问题 ,马上问！ 不影响流程的问题，记下来统一问！ 不必要的问题，不问！ 好处：避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制 坏处：脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸 张等资源 阿猪工作守则第三条：先做事，后学习 在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。 要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期 培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的 “ 带着问题去测9 / 38 试 ” 的方法。 但有一点需要注意：不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。 测试中期评审测试问题 答疑解惑的时间。 测试报告评审 对一些结论有疑惑和不解的地方，提！ 4.记笔记 一个老生常谈的话题。 阿猪工作守则第四条：好记性不如烂笔头 测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方，测试时再去问，这就不好了。 10 / 38 养成一个良好 的习惯，会使以后的工作更加顺利。 5.在公司和学校的学习的区别 学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。 学校 公司 备注 内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了 时间上 大块时间的连续学习 相对邻散 在公司一般不会拿出大块时间来学习和讲解 形式上 老师授课自学 培训交流测试过程中自学 个人觉得，一个高效的测试流程应该如下： a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档； 11 / 38 这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不 能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具说明文档，囫囵吞枣的方法在这里就显得很有效。 如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。 b.利用培训时间消化吸收的知识 c.软件上手 几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。 d.细测 主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框都要深究，别放过任何情况。这时会遇到一些错误或不理解的地方，明显的如报错就提到12 / 38 开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现： 50的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。 阿猪工作守则第五条：软件不是一次能测透的 Rome is not built in one day. 工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。 综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。 一口吃不成一个胖子，看我这么瘦又这么能吃就知道了 要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。这样一般来说除了 ljl 这种全能性人物13 / 38 外都会造成最后自己的问题留了一堆，别人的也没搞懂。 新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。 评价自己是否可以转入下个模块的几 个因素：自我提问与别人提问、测试进度 如果大多数相关人员对于自己负责模块的问题都能解答，搞定！ NEXT转入下个模块。 否则，还是再回头想想思路和遗漏的地方。当然，要综合考虑测试进度。请组长对自己提几个软件的问题，他会很乐意的。 e.小结 一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试 . f.性能测试 性能测试不仅是测试性能，同时也加深自己对软件应用的理14 / 38 解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。 g.安装盘测试 安装盘程序测试，简单过一下软件功能有无错误。 安装盘 程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。这个阶段要积极与开发负责人和 GJ 沟通，确保最后的胜利。 h.测试总结 测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供 捷径。 5.小结 ? 用户用软件，测试测软件 培训时多想多问 ? 15 / 38 好记性不如烂笔头 ? 带着问题去测试，在测试中解决问题 ? ? 先做事，后学习，争取双赢 软件不是一次能测透的 ? 项目测试经验总结 说明：以下项目测试经验是我在原来公司工作中的实际经验，拿出来和大家一起交流。我相信之前的项目测试工作中有不少可以改进的地方，还希望大家多多交流。 项目测试经验 Judy Shen 本文是对我近几年测试工作经验的总结，并以简报的方式在研发中心内进行分享及交流。 1 测试团队介绍 16 / 38 在介绍我们之前项目测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。 我们的测试团队属于质量改进中心下的测试部，它和研发团队属于两个不同的中心。测试团队有 6 个人，从图一可以看出来，一个人可以参与多个处于不同阶段的 项目测试工作。 图一 测试团队组织架构 参与项目的测试人员以测试组的形式进入项目，测试组和需求组、开发组并列。每个测试组有一个测试组长负责项目测试工作。项目经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的项目测试工作，项目测试组的工作汇报均需要抄送给测试部经理。如图二所示： 图二 项目组织架构 上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。这里的测试外包模式是指，测 试组不进入项目，而是由项目组17 / 38 将测试工 作以一个项目的方式分包给测试部，由测试部根据项目组提供的信息，进行计划、执行测试，并按照项目要求提交测试成果给项目组。 这个模式还在探索中 ，如图三所示，测试部经理直接负责项目的测试工作，测试组的工作情况抄送给项目经理。这种模式需要进行独立核算，包括成本估算、预算、结算等。但是这种模式的整体思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。后面提到的内容，如果没有特殊说明，都是在旧的模式下进行的。 图三 项目组织架构 我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是 测试专家，他同时也是业务专家。有一些测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和研究没有跟上，结果不是设计18 / 38 出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起项目来辛苦异常，个个苦不堪言！ 有着样的说法： “ 软件测试人员要两条腿走路，左腿是测试技术，右腿是业务知识。只有两条腿的健壮差不多，走路才稳当。 ” 出 于这种思想的考虑，在原来的测试团队，我们每个人都有两个学习、研究方向，一个是技术方向，一个是业务方向。例如： ? 技术方向： ? 功能自动化测试 ? 性能测试 ? 单元测试 ? 测试管理 ? 业务方向： 19 / 38 ? 物流业务 ? 智能交通 ? 知识管理 但这种方式在工作开展上有 些困难。如果公司认为测试人员应该绝大部分时间用在项目测试工作上，那么测试团队既要研究测试技术，又要挤出时间学习业务知识，在操作上是比较困难的。在我们以前的测试团队的工作中，有一部分工作时间是用来进行部门建设的，部门建设工作中包括前面说到的技术研究、业务学习，还有就是部门搭建所需要进行的一些工作。当时公司允许我们团队有 30%的工作量投入部门建设上。将部门建设工作分开，主要是用于统计部门成本和测试成本用的。 前面说到了测试人员是以测试组身份进入项目开展测试工作的，但不是每个成员上去都从事同样的工作。在进入项目组工作时，每个测试人员所充当的角色是不同的，项目的测试角色划分为以下四种，如表一所示。在实际工作中因为测试人员数量有限，所以经常是一个人担任多个角色。 20 / 38 角色 职责 测试管理员 负责测试项目的管理 测试过程问题的处理与反馈 系统 /性能测试组织和计划 测试过程状态报告 测试设计员 测试需求的描述 系统 /性能测试用例的设计 测试工具、方法的引入 21 / 38 测试执行员 根据需要开发测试脚本 按照测试用例、测试脚本执行测试 项目测试工作指导 测试监督与度量员 测试度量 测试过程问题的汇总与反馈 开发产品的质量抽检与评定 表一 测试角色划分 了解了原来测试团队的分工之后，下面介绍一下测试团队的工作内容。原来的测试团队承接的工作内容包括： ? 承担系统测试、用户测试、性能测试； 22 / 38 ? 进行测试技术研究及培训 其中，测试技术研究，属于提高团队工作技能的工作，在整个部门范围内进行，这里属于部门建设工作；对于项目中的测试人员有可能需要进行，如果项目采用新的测试技术或者测试工具，那么就需要项目测试组成员研究测试技术了，这部分属于项目测试工作。 培训，是指把内部研究的成果在团队内使用，在适当的时机在公司内传播。我们测试团队 在 XX 年开展了 21 次内部培训，7 次公司级培训。因为每个人各有研究重点，所以我们每个人都是团队内部培训的讲师。 说到测试工程师的工作内容，那么就涉及到测试工程师该做的和不该做的。当然这和公司对测试人员定位有关，这里仅指以前的组织。要说该做的，那么我们需要先明确为什么我们要测试？这是因为存在 “ 系统错误很多、系统不是客户想要的东西、系统实现没有遵照系统需求 ” 等这样的背景。在这样的背景下，产生了测试，但 是又因为开发人员自己测试自己的东西，难免测试不全面，所以产生了测试工程师这个角色。因此，测试人员他该做的，就是测试软件产品和用户23 / 38 需求不一致的地方，并尽可能多的发现缺陷，能够向项目经理汇报软件质量状态。但是在实际工作中，测试人员经常主动或被动的去做了一些不该做的事情。例如说，测试人员认为自己或者测试能够保证软件的质量，以及有意识或无意识的接受了决定软件是否发布的这个权利。 为什么测试无法保证软件的 质量，是因为项目的质量，需要项目组的所有成员共同努力，才能达到质量保证的目的。单纯靠测试工程师的力量，是无法实现软件质量保证的目的。 为什么测试人员不适合承担决定软件是否发布的权利，是因为软件的发布，是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后，由项目经理做出是否发布的决定。在这个过程中，测试工程师可以提供测试数据、系统当前质量状态报告给与会者参考。 当然，我知道这两点会有很多人不认同，但是没有关系的。我接触的同行中对两点经常有争论。但是，有一些质量大师等权威人士还是全部或部分赞同这两个观点的，如：菲利普 .克劳士比曾在他的书中提到软件质量的保证需要全员努力，需要过程的控制的，而不是某个英雄可以保证软件质量的等。 24 / 38 2 项目测试工作 做了背景介绍后，下面我介绍之前项目如何开展测试工作的。 因为测试过程是整个测试工作的一个纲要，所以首先得从测试过程讲起。 测试过程 测试过程，我们包括四个环节：测试计划、测试设计、测试执行、测试分析。 图四 测试过程 测试计划 测试计划主要是进行描述测试需求、分析制定测试计划工作。在制定测试计划时，经常有人认 为测试计划是在整个项目计划制定之后才开始进行测试计划的，事实上并不是这样的。测试计划和项目计划是互相影响的。举个例子。假设项25 / 38 目有进行性能测试的需求，但是测试工具又需要学习，那么我们在测试计划中就需要预留这部分的时间，还有，测试用例的评审，也需要预留时间。或者，如果某部分比较复杂，可能测试需要的时间会较多，或者需要测试的次数会比较多，那么可能要求开发组先安排这个核心模块的开发，这样需要调整开发计划的顺序。所以，测试计划和项目计划是互相影响的。在测试计划环节还包括测试需求的描述，主要是确认需求是可测试的，并将需 求细化为具体的可测试点，保证测试设计时可以根据测试需求编写测试用例，而避免遗漏测试点。我们的测试需求需要得到业务分析人员的评审，测试计划要得到项目经理的审批认可。 对于测试计划，还需要说明的是，在具体的每个测试阶段工作计划中，我们需要定义本阶段测试需要进行的次数。每一轮测试是一个完整的测试周期，按照这里介绍的测试过程进行。通常我们是一天一轮测试，最多是两天一轮测试。通过这种方式，减少了测试和开发之间的空挡时间，即测试等开发，开发等测试。例子如图五所示： 图五 测试迭代例子 肯定会有人疑问，如果一个系统很庞大的话，怎么能在一两天内完成测试呢？是的，如果系统比较大的话，确实没法在26 / 38 一两天内完成所有测试点的全面测试，有可能需要一周或更长的时间，但是这样的话，就出现了测试、开发互相等待的情况了。所以，在我们制定的测试阶段计划时，需要指明本次测试的测试重点，测试范围。我可以这一轮测试进行 A、 B模块基本功能测试，第二轮测试进行 C、 D 模块基本功能测试，第三轮测试，进行主要业务流程测试，第四轮 测试，关注负面测试。在我之前的实践中，发现这种方法还是比较有效的。可能大家也注意到了，这个例子是另一个项目的。没错，在今天提到的移动的这个项目中我们没有按照这种策略进行测试，弄得当时我们测试小组工作很累，很被动，经常是开发说测试我们就要马上开始测试，而缺乏计划。实施这种方法后，测试的计划性就比较强，测试不用总是被打扰。 测试设计 测试设计，主要是根据需求、设计文档进行的测试用例设计工作。如何从需求导出测试用例并设计测试用例，是整个测试过程中很重要的一部分工作，关系到测试执行效果。但是在刚开始时，系统没有界面，所以我们只能根据系统用例搭建测试用例的初步框架，能写多少写多少。随着对系统的理解深入，加上后面也开发了系统原型，我们就可以不断完善测试用例。即使是在测试阶段，我们仍不断修改测试用例。27 / 38 测试用例我们分为两种，一种是内部测试用例，项目组内部使用；一种是验收测试用例，偏重于业务，供客 户使用。项目组内部用的测试用例例子如图六所示： 图六 测试用例例子 从图中大家也可以感觉到项目组内部使用的测试用例在维护上比较不方便。因为我们的需求并没有做到很细，加上需求本身就是变化的，所以我们的测试需求经常修改，一旦测试需求新增、修改、删除时，测试用例要相应进行调整。这就造成了 1)定位测试用例比较不方便， 2)测试用例编号修改不方便， 3)阅读、执行测试用例不方便。所以，我在 XX 年底开始准备在团队内自主开发一个测试用例管理系统。 测试执行 在测试执行阶段，主要进行测试的执行工作。如果项目有需要编写或录制测试脚本的话，那么也在这个阶段进行。测试执行结果是在原有测试用例的副本上编写实际执行结果而形成。在东南融通，它是把这个活动单独为 “ 测试实施 ” 环节。 28 / 38 测试分析 手机测试经验总结 VPM 主要是激励团队成员测试和学习，而不是自己去执行用例。当被委派为一个项目的测试经理时， VPM 应该清楚项目计划和转折点、软件发布时间表、产品定义特征列表。 1、作为 VPM 应具备以下几方面能力： 、用不同的方式看待问题 、制定计划，满足项目上市时间 (来自 : 海达 范文 网 :测试经验总结 ) 、依据质量、时间、成本对 PR 进行判断和决定 、增进沟通，总结不同项目的经验 、和团队的密切合作 2、测试工作点： 29 / 38 、测试软件机制 、分析问题 、对产品进行认证并得到相应证书 、评估对于返修率、最终用户和运营商抱怨的影响 若做欧洲市场的产品，一定要做 CE 认证。 FCC 认证在 Latam市场是必须的， CTA 认证在中国是必须的。 一、 相关测试知识学习 1、软件测试包括测试计划、测试设计、测试执行、 测试评估这几个阶段； 测试计划： 了解软件当前状态及客户对软件的需求； 了解产品规格书：按键定义及菜单树； 30 / 38 管控和跟催软件方案商的版本发布时间； 测试设计：根据客户需求和产品规格说明书来编写测试用例； 测试执行：测试策略包括基本功能测试、 UI 测试、冲突测试、压力测试、兼容性测试、验收测试 测试评估：进行三次全面测试，由方案商发出软件和报告，TMC 和 SZ Team 同时测试并反馈给方案商，如此反复数次，方案商改善结果并商讨最终结论。 2、场测 在硬件成熟、软件基本成熟的情况下做场地测试，主要测试这几项：寻网时间、呼通率数据、通话质量、 Wap 测试、 FM测试、信息、紧急呼叫、基本功能测试。 3、说明书测试 31 / 38 验证说明书基本功能是否正确，是否清晰易懂、排版规范、无错别字等。 4、认证分类 按照销售地区分为国内认证和国外认证，国内认证是 CTA 认证，国外认证是 CE 认证和 FCC 认证。 CTA 认证需要拿到国家无委颁发的入网证书、受理中心颁发的许可证书、 3C 认证颁发 的 3C 证书。 软件测试心得体会 软件测试工作是一个系统而复杂的 工程，软件测试的目的就是确保软件的质量、确认软件以正确的方式做了你所期望的事情，所以工作的主要任务是发现软件的错误、有效定义和实现软件成分由底层到高层的组装过程、验证软件是否满足规格书要求和系统定义文档所规定的技术要求、为软件质量模型的建立提供依据。 而且软件的测试不仅是要确保软件的质量，还要给开发人员提供信息，以方便其为风险评估做相应的准备，以及为其提32 / 38 供分析依据，重要的是要贯穿在整个软件开发的 过程中，保证整个软件开发的过程是高质量的。 软件测试对测试工程师来讲，要求具备较强的专业知识，严谨细心耐心的测试态度，良好的反向思维、发散思维能力、沟通能力等等。 以下是就自己的个人 工作经历谈一些浅见： 1. 标准文档的制定： 任何一个公司要让自己的产品面市，都要有自己的一 套完整的品质标准，这个标准一定是在符合国标及客户 标准的基础上形成的企业标准，系统而全面地描述一款 产品的功能、性能、可靠性、健壮性、安规要求等一系 列的产品标准，并根据客户特定要求相应调整。 测试仪器的作业指导书 (SOP)及保养说明等。定义仪器 33 / 38 的使用步骤、操作指南和保养细则等。 2. 测试资料的归档： 标准媒体文件、测试报告、 BUG LIST 库、认证测 试文档归纳总结 (认证公司培训 资料、认证过程中出现并改善 的问题 )、测试工程师经验分享、常见问题解答 FAQ 等。 3. 功能测试： 这是软件测试工作中最核心和最基本的一项测试，该测 试的主要内容是检查软件是否符合需求定义，并通过构 造正常的操作来检查的动作是否正确；在这个测试里， 正确性是最最重要的软件质量要素。 34 / 38 功能测试按照可见性可以分为两类：显性功能和隐性功 能。 显性功能：指在菜单里可以看得到的功能。 隐性功能：指在菜单里看不到的功能。 例如，电话本的显性功能有增加、编辑、删除、拨打等， 这 些功能可以在电话本的菜单里面看得到，姓名列表排 序则属于一个隐性功能，因为在电话本的菜单里没有这 样一个子菜单，但它却是一个实实在在的功能。 如以下这些隐性功能都测试中都 需重点关注： a. 电话本上下页切换，是否有遗漏联系人信息？ b. 是否支持手机内存、 SIM 卡电话本的同时下载？还是 35 / 38 支持从一种介质里下载？ c. 断电后再上电，系统设置的时间是否有记忆功能？ d. GPS 信号正常时，导航地图中时间是否有更新？ e. TFT 屏在 Power of