测试的目的是为了保证生产出来的产品满足甚至超出客户的需求。测试的角度要从客户的角度分析客户的显性需求和隐性需求。所以，做好测试，你必须要清楚得掌握客户的需求。要掌握客户的需求，首先你得清楚你的客户是谁？

　　传统的客户定义主要有三种：Customer、User和Operator。customer是和你签订合同的对方；user是使用你的软件的单位 （点）；operator是操作者。一般：user和讨论功能模块，和operator讨论操作场景，和customer签合同。比如你要做个电信软件， 跟你签订合同的customer就是这个电信公司；使用你的软件的user就是各个电信营业厅；操作你的软件的operator就是各营业厅里各个服务 员。

　　CMM里还有一个关于客户的定义：“负责接收产品并且付给开发组织报酬的个人或组织。”

　　那么我们的客户是谁呢？

　　答：

　　软件质量可以从两个角度看，Producer和Customer. 对应到楼主的定，Producer就是楼主的customer；Customer就是楼主的User和Operator。

　　从producer的角度看质量是：Meet the customer’s requirement the first time and every time.

　　从Customer角度看质量是：Fit for use.

　　测试的职责是缩小和弥合两者的差距。用图说明一下：

　　测试部门在SDLC的不同阶段对需求的范围和关注程度是不一样的，是动态的。

　　SDLC 前期，比如需求分析阶段，如果测试介入早，会去和producer和Customer做沟通，关注两者理解的需求是是否一致。这个阶段采用Static testing的方法，比如：Review， walkthrough. 这个阶段发现的问题，解决的成本最低。

　　到SDLC中后期，假设Customer的需求都确定了，PRD和其他需求文档定稿了。测试就会着重关注共同约定的需求，开始测试设计。我们就要确保producer做出来的东西和否和需求吻合。

进入测试已经五个年头了，感觉这个行业还是比较适合自己的，在这个道路上我还有很长的路要走，在此先和大家分享下我的五年测试历程。

　　职业道路选择------认准目标就前进

　　我最开始接触测试这行是在2005年，还算比较早的，但是那时，我对测试的理解就是要找问题，也不会去深究，对测试没有一个完整的概念，以为测试就是不会写代码的人都可以做的。也没有意识去思考测试项目流程是什么，项目的架构是怎样的，要采用哪种数据库、编程语言，采用什么协议，设计思路是怎样的？

　　测试了整整一年后，我也只知道按照不是特别规范的测试用例来执行，加上测试进度很紧，当时测了一轮又一轮。那个时期，国内的测试还比较薄弱，公司普遍都还不是很重视测试，我自己也不知道怎样才算把这个工作做好，在网上查阅了相关的资料，但是关于这方面的资料特别少，自己抽空学习也没啥效果。

　　后来，我觉得测试前景

不错的，很想对测试这个行业有一个整体的认识，另外，我也想多了解下自动化测试工具，希望这些能让我的测试之路走的更远更好，于是我选择了自我充电，参加了上海一个测试培训。

　　在这个过程中，因为学习的欲望很强，很多都是我主动想学的，所以我边学边实践。通过学习，我了解了测试的基本概念、基本流程；测试在整个软件周期中的作用；测试用例的编写，方案的编写；数据库基本应用等。现在回想起来，这段时间是一个学习的美好的回忆。我最大的收获就是明确了以后在测试工作中，我应该关注哪些方面、从哪些方面去思考问题、怎样使我的工作做的更好。

　　心态的作用------一切从工作出发

　　心态好才能工作好，这句话很对，在测试过程中，可能你会做很多重复的活，但是你怎样才能保证你自己工作积极性一直很高，怎样才能在工作中获取自信呢？在工作当中，我是这样做的：

　　1、对不理解或困难的工作，我自己去查找资料或问同事，寻求帮助。

　　2、对自己会做的工作，我在能够完成的同时，我会留出一定的时间，来自己做自由测试，这块很重要，因为很多测试用例覆盖到的地方，基本都测试过，测试是不能穷尽的，可能有些路径或者操作，只有在自由测试中才能找出。

　　……………………

　　查看全文请点击下载：http://www.51testing.com/html/54/n-247254.html

　　对于编程语言的熟悉这一块，以前我们一个测试经理说，一个测试人员，不懂代码就像人残废一样，虽然话有点难听，但是熟悉开发的思路和代码，会让你的测试技术之路走的更宽，更长！

　　在技术领域里，你知识越渊博，越被人喜欢，因为你就是一个活字典！

　　除了专业知识，对软件需求也要深入了解。需求是开发编写软件的源头，不管你是作为普通的测试人员，还是资深的测试人员，都需要对你所测的软件的需求有很好的了解，包括产品需求和测试需求。这个也是一个过程，最开始可以去了解需求的关注项，如：功能，性能，接口，属性，约束条件等。然后由浅入深，理解显性需求和挖掘隐性需求。特别要关注开发实现时，是否考虑到异常输入和输出。

　　开发与测试关系处理--换位思考

　　在整个项目中，其实开发和测试是一个团队，团队的目标是一致的，提高软件的质量。但是工作当中因为职责的不一样，往往可能会造成分歧。为了更好的配合开发，测试人员要把握好以下几点：

　　1、在提交问题时，表达要清楚，重现步骤和预期结果要清楚。

　　2、如果是概率性出现的问题，最好记录好有用的日志并保持现场，这样能帮助开发更快解决问题，必要时，要协助开发重现问题。

　　3、在提交问题单时，可以先把严重的问题现象，步骤告诉开发，然后再提单。如果问题较多时，先提严重的，小问题最后再提，因为开发也有绩效考核的，开发修改问题的效率高了，这样开发会很乐意和你合作。

　　4、有些有争执的问题或可改可不改的问题，和开发讨论没有结果，但是测试觉得实在是改了更好，可以找上一级或者专家协商确定后，再提单，或者告诉开发兄弟，这个问题可以不用马上改，优先级很低，要改了这个软件更好，更能体现开发的能力等。

　　5、把开发当你朋友。每当我测试到一个很严重的问题时，我会找开发聊，这个问题是怎样产生的，你是怎样解决的？然后会问开发人员，你这样解决之后会不会产生其他的问题？然后会跟开发人员说，以你的能力你肯定能解决这个问题的，相信你！这样会增加开发对你信任，也说明你和他是站在一起的。

刚在51testing上看到一个人发帖，说自己写测试用例没有很好的思路，对于一些复杂的功能点，有没有比较好的测试覆盖方法，比如高级查询等等，非要列出来那么详细的测试用例吗？～～～～看完之后，我就忍不住发言了，作为一个测试人员，设计测试用例那是本职工作，如果我们连写用例的基本耐心都丢弃了，还谈什么测试。那开发总不能说因为写代码很麻烦，而不写吧。很多事情没有捷径，必须要做的事情，那是没有办法去逃避，不然我们就失去了工作的意义了。

　　其实说来，也是由于最近对于测试用例的设计，让我产生了一些反思。如何设计测试用例，如何评审测试用例，最后如何管理测试用例，这都是我们测试工作中必须要去改进的问题。在之前的公司，由于团队工作任务繁忙，我们没有太多的时间去管理和优化测试用例，也因此对用例方面少了太多的思考，而且虽然有对于用例的评审，但一直以来，我认为是做得不够好的，毕竟每次评审下来，感觉效果没有预期的那么好，主要还是没有足够的时间去管理，所以无法引起重视。不过，现在我想我需要花大量的时间来管理用例了，而且要保证有序的进行，最后输出让团队中各个成员都认为满意而且高效的测试用例。对于用例管理的根本问题，我个人认为是分类上，例，就是需如何有效的维护和优化用要前期明确的分类规划，根据分类的优先级一步一步地来完成就可以了，到最后，我们也可以有效把控的测试覆盖度。

　　当前，我们大致可以把测试用例分称三个方面，分别是功能、UI和业务流程，从这三个角度来进行设计。

　　1、从功能的角度，能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计功。不过这里，肯定会让很多人疑惑，其实功能、业务还有UI，都是有关联的，而且很多时候无法分解的。这里后面我会举个例子说明哈，但绝非都是可以分类，只是谈谈如何分解的方法，最重要的就是不要遗漏就行。

　　2、从UI的角度，UI通常是指界面测试，这个应该不难理解，但要想与功能点进行分解，也不是那么容易区分的，所以我们来直观的说明哈。界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。

　　3、从业务的角度，这个相对来说，还比较好理解，业务通常是指一连串的动作所连接起来的流程，这个流程必须有行为和目标，或者说方向。业务通常是一个项目或者产品设计的核心，当下，越来越多的应用业务流程都是非常复杂，所以对于业务的用例设计，就是考验一个测试人员的业务水平如何。

　　下面通过一个证券交易平台上的买入和撤单业务，进行具体说明：

　　业务说明：买入业务包括股票代码、当前价格、买入价格，买入股票数量、确定买入按钮和取消按钮；

　　撤单业务包括选择撤单的未成交业务、撤单成功、撤单失败以及取消撤单按钮；

　　以上只是大致列举了一部分。

　　功能点：买入按钮、取消按钮、选择撤单、撤单按钮和取消撤单按钮等

　　UI界面测试：股票代码、当前价格、买入价格、买入股票数量，所有的文本框；买入成功/失败的提示框；撤单成功/失败的提示框；撤单成功/失败的业务状态等

　　业务测试：买入业务，从输入买入表单的数据，到提交表单，到最后买入的表单显示的位置，以及买入提交但未成交，可以撤单，完成撤单的业务，到撤单成功或者失败等，这一连串的工作组合就是一个业务流程。

　　其实这里就存在一个争议性的问题，对于买入和撤单，既可以作为功能点，也可以作为一个业务逻辑来设计，但从本质上来讲，功能点注重单独的操作，而业务流重的在是一个流程，还需要具体业务去甄别。功能点的设计更主要对这个买入和撤单的按钮本身进行用例设计；而业务则是需要从买入和撤单之前的输入到最后输出这样一个过程来设计。

　　以上也只是大概的一个简单的说明，具体的操作还得根据自己的实际流程来执行，毕竟测试用例的管理是一个长期的积累和沉淀的过程，好的方法都是总结出来的。对于测试来说，用例是基础，对于回归测试、自动化、性能等等都是根本，管理好测试用例，也就是提高测试的工作质量。

　　软件测试基础——维护型测试的过程，包括：特点，测试目标，方法，测试设计，测试准备，测试执行等。测试周期短，聚焦变更，重视测试可重复性等都是典型维护型项目的特征。

　　软件测试基础——测试的质量属性。包括，功能性，可靠性，高效性，可用性，可维护性。

　　软件测试基础——测试等级，包括模块测试，系统测试，FAT，UAT，PAT，SIT，试点测试等。

　　软件测试基础——性能测试，包括：测试关注重点、性能测试分类、性能测试技术、测试工具、故障定位等。

　　软件测试基础——测试计划，包括测试基础、测试策略、测试组织、移交等

　　软件测试基础——测试设计方法，包括边界值法、因果图法、等价类法、算法测试等。

　　第一步：评定开发方案和状态

　　这第一步是创建W＆T计划的先决条件，W＆T计划用于评估执行的软件解决方案。在这一步，测试员可质疑开发方案的完整性和正确性。并且基于项目计划的完整和延伸定义，测试员要估计出测试这个执行的软件解决方案所需要的资源数量。

　　第二步：形成测试计划

　　形成测试计划应该要符合软件开发过程的模式，所有计划的结构应该是一样的，内容则要基于测试员对开发中的项目的感知程度。

　　第三步：测试软件的需求说明

　　不完整的，不正确的，或不一致的要求都会导致软件开发失败。 在需求收集阶段，不正确说明软件需求，会明显的增加开发费用。 测试员通过查证，一定要保证需求说明的是正确的，完整的，并且不会有冲突。

　　第四步：测试软件的设计

　　这一步测试员首先要能过查证技术测试软件的外部和内部设计，测试设计是否能完成需求说明的目标和这些设计能否在指定的硬件上起作用。

　　第五步：软件开发过程中的测试

　 　根据内部设计文档选择的软件开发方法将会决定测试员测试需要的类型和范围。因为软件构建变得更加自动化，所以这一阶段要求相对少的测试，不过，如果软件 采用瀑布型的开发模式，容易产生错误，这些错误应该被发现。经验表明，在构建阶段发现问题会比在动态测试过程发现问题节省很多成本

　　第六步：执行和记录错误

　　这个阶段包括在动态状态测试代码，在测试计划中指定的步骤，方法，工具会被用于验证可执行代码是否符合规定的软件需求和设计的结构化规范

　　第七步：可接受性测试

　　可接受性测试能让使用者在操作他们的日常工作所需功能时评估软件的适用性和可用性。这样能测试出使用者认为软件应该实现什么功能，与需求文档的中说明的软件应该实现什么功能形成对照

　　第八步：报告测试结果

　　测试报告是一个持续的过程，可口头表达也可记录下来。 缺陷和涉及的问题要向相应的小组报告，并且报告要易于理解，这一点很重要。这样就能以最低的可能成本修正问题

　　第九步：软件安装测试

　　一旦测试小组已确认该软件是供生产使用，在生产环境中，软件的执行能力将被进行测试。这将测试操作软件的界面，相关软件和操作程序。

　　第十步：测试软件变化

　　当进行到第十步，是软件被安装使用后的维护过程。相关概念随着整个执行过程而改变，任何时候需求改变了，测试计划也要相应改变，并且这些改变对于整个软件的影响也要测试和评估。

　　第十一步：评估测试效率

　　测试改进最好通过在测试任务的最后阶段评估测试效率完成。这个评估首先应该由测试员完成，同时也要包括开发人员，软件使用者和专业质量担保人（如果有这些人员的话）。

web测试20种界测试思路

 1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

       2.相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

       3.检查按钮的功能是否正确：如update、cancel、delete、save等功能是否正确。

        4.字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。

        5.字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型，会否报错。

        6.标点符号检查：输入内容包括各种标点符号，特别是空格、各种引号、回车键。看系统处理是否正确。

        7.中文字符处理：在可以输入中文的系统输入中文，看会否出现乱码或出错。

        8.检查带出信息的完整性：在查看信息和update信息时，查看所填写的信息是不是全部带出，带出信息和添加的是否一致。

        9.信息重复：在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。

        10.检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错;然后选择一个和多个信息，进行删除，看是否正确处理。

        11.检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。

        12.检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。

        13.重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

        14.检查多次使用back键的情况：在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。

        15. search检查：在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。

        16.输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。

        17.上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

        18.必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加* 

        19.快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

        20.回车键检查：在输入结束后直接按回车键，看系统处理如何，会否报错。