功能测试怎么写

【不在于测试用例该怎么写，而在于想怎么测。】

【对用例的理解表达出来，格式自然出来了】呵呵，偶要顶一下，偶不是完全赞同这两句话。用例的理解跟格式没有必然的联系。

也没有主次轻重之分。【先保证自己对业务流程和业务规则的理解和熟悉，然后可以对这部分先思考一下，哪些地方需要测试，需要怎样的测试？如何来施行这些测试？之后再增加对系统中其他规则、特性和算法的熟悉，继续增加测试的深度和广度。】

——这句说的很对。有这么一个公式， 数据结构+算法=程序。

这里类比一下用例设计，jackei和skinapi版主强调的是用例的“算法”，而文档格式是用例的“结构”。两者的关系是相辅相成，而不是矛盾的（好像在上政治课哈）。

至于说“对用例的理解表达出来，格式自然出来了”，这个境界太高了，不是一般人可以做到的。面对现实的企业应用，做项目的话你会遇到各种各样的情况，要做到“格式自然出来”实在是太……厉害了呵呵。

是这样的：用例格式相当于一个规范，给你一个结构，一个框架（framework），仅此而已，并不因为你的用例模板而能体现用例的好坏。所以， “用例怎么写”其实分两个：用例的“算法”+用例的“结构” （也就是模板）了。

【不在于测试用例该怎么写，而在于想怎么测。】

【对用例的理解表达出来，格式自然出来了】呵呵，偶要顶一下，偶不是完全赞同这两句话。用例的理解跟格式没有必然的联系。

也没有主次轻重之分。【先保证自己对业务流程和业务规则的理解和熟悉，然后可以对这部分先思考一下，哪些地方需要测试，需要怎样的测试？如何来施行这些测试？之后再增加对系统中其他规则、特性和算法的熟悉，继续增加测试的深度和广度。】

——这句说的很对。有这么一个公式， 数据结构+算法=程序。

这里类比一下用例设计，jackei和skinapi版主强调的是用例的“算法”，而文档格式是用例的“结构”。两者的关系是相辅相成，而不是矛盾的（好像在上政治课哈）。

至于说“对用例的理解表达出来，格式自然出来了”，这个境界太高了，不是一般人可以做到的。面对现实的企业应用，做项目的话你会遇到各种各样的情况，要做到“格式自然出来”实在是太……厉害了呵呵。

是这样的：用例格式相当于一个规范，给你一个结构，一个框架（framework），仅此而已，并不因为你的用例模板而能体现用例的好坏。所以， “用例怎么写”其实分两个：用例的“算法”+用例的“结构” （也就是模板）了。

查看原帖>>。

我这边有一些测试时应该注意的一些问题和解决办法，当做抛砖引玉。

1.如何在测试中尽量找出多的问题

页面，流程，功能，数据正确性以及查询可以通过用例测试检查出问题并提交开发人员解决，有些功能须反复测试，如流程，数据正确性

2.性能问题如何测试

性能测试分应用软件性能，数据库性能，服务器性能以及网络性能

某功能的性能测试可以在做其它相关功能测试时同步测试.

软件的整体功能测试有待解决.

3.数据有效性如何测试

数据有效性测试通常是先做一些业务，然后通过查询表及数据库来检查，出错时通常须检查两个方面，一方面要保证存入数据库的位置正确，另一方面要保证查询语句正确.

4.一些隐性的BUG测试

如数据库死锁，软件出现死循环，一些通过数据的测试可以测试出来.

另一方面应付突发问题须有出现问题后的解决方案.

它的一般形式是这样的：

比如对登陆功能的测试用例的编写：

用例编号：DL_001（编号通常会根据功能或模块编写）

功能模块：登陆

测试标题：输入正确的用户名和密码后，能否正常登陆

前提条件：1. 网络正常（也就是你做这条测试前必须要有的前提条件）

操作步骤：

1. 进入登陆页面

2. 输入正确的用户名和密码

3. 点击登陆按钮

期望结果：登陆成功

实际结果：

另外附图另外一个例子：

1. 首先学习软件测试基本知识和软件流程。功能测试最开始最基础的就是分析需求编写测试用例，测试是把握质量的守关人，保证不漏测的第一步就是要编写尽可能全面的测试用例。可以学习用例编写方法、黑盒测试方法，阅读一些书籍，比如：软件测试艺术；此外，了解软件流程也很重要，根据迭代所处阶段测试可以做不同的事情，需求宣讲阶段制定测试计划、分析需求编写测试用例；开发阶段了解实现技术细节准备开发自测用例；提测后按用例测试，每天抛出风险和进度，根据执行质量考虑是否测试多轮，根据质量判断是非可以上线发布；上线后及时根据运营问题；

2. 基础打牢后多实践。测试是讲究经验的职业，从简单需求开始，制定测试计划，编写用例执行，执行过程及时调整计划爆出风险和进度给团队知道非常重要。从简单需求到复杂需求到迭代跟进，除了执行，技术了解和bug跟进分析很重要，了解技术实现可以帮助你设计更全面的用例，更好评估功能质量风险；bug分析也是，往往一个经典的bug分析出来会发现更多隐蔽问题；功能测试完成建议编写测试总结，对测试方案、逻辑实现、发现问题和自己分析过程进行整理；

3. 进行下去后会更加深入了解被测对象，从而可以做更多深入测试。比如稳定性测试，性能专项测试，接口测试等；团队合作下去可能会发现一些流程上的问题，可以思考如何优化流程让合作更高效，以及沉淀文档和规则；迭代跟进后会有一些质量效率问题，需要思考如何优化：自动化、精准测试、重复工作脚本化、工具化；根据每个迭代总结和测试数据分析也需要思考哪些数据待提高：漏测情况、bug发现情况；用户反馈问题多了，可以思考如何专题解决、如何快速定位……将这些工作完成并记录沉淀下来形成方法论，多做分享扩大自己影响面；

4. 团队扩展后就需要思考如何培养新人，如何开展团队工作，帮助大家一起进步、高效工作；

项目支持是基本，在这基础上多发现问题多实践多思考，扩大自己影响。

？ 概述：对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。测试目标 确保测试的业务功能正常，其中包导航性质菜单，数据输入，处理和检索等功能。

测试的范围 1、界面里面常用功能按钮：增、删、查、保存、取消等。2、下拉列表、单选、复选、3、文本框技术 利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：1、在使用有效数据时得到预期的结果。

2、在使用无效数据时显示相应的错误消息或警告消息。3、各业务规则都得到了正确的应用。

开始标准 测试执行完成标准 1、完全实现需求中定义的功能2、在功能实现的基础上实现正确的业务流程需要考虑的特殊事项 ？ 方案：给出具体的针对性的测试方案，为今后设计用例或在测试过程提供一个大纲性质的方案。下拉列表 1、条目内容的检查，对照需求说明察看条目内容和实际内容是否一一对应。

2、条目的功能能否实现，逐一执行列表框中每个条目的功能。3、在列表框中能否输入数据，检查能否输入或则粘贴数据向组合列表框内。

4、能及时获取得到新增加的数据并显示。文本框的 1、边界值和等价类测试用例方法。

2、可以采用随机测试进行测试用例的补充。3、输入符合规定的数据。

4、输入已经存在的内容。5、输入超常字符。

6、输入特殊字集。7、输入空白，或则空格。

复选框的测试 1、多个复选框被选中。2、多个复选框可以被部分选中。

3、多个复选框可以不被选中4、逐一执行每个复选框的功能单选框的测试 1、单选按钮是否只能同时选中选中一个。2、个单选按钮的功能是否正确完成3、是否有默认被选中的选项命令按钮的测试 1、对各类按钮的测试。

2、功能是否实现。3、提示信息是否正确。

4、描述、图标功能是否一致。错误处理 1、对于不符合业务背景的输入数据是否有相应的处理方法。

2、单击按钮正确响应操作。3、对非法的输入或操作给出足够的提示说明。

4、错误说明应当清楚，命了，恰当，让用户明白错误出处。5、对于无法恢复的操作必须提供确认信息，给用户放弃选择的机会。

我是做软件测试工作的，仁者见仁智者见智，水平有限，就你提出的问题作一个简单的回答吧，一是期望对你的问题有所帮助，二也是对我自己的提高。

1、我对你的第一个问题表示质疑，你认为测试是保证软件质量吗？能保证吗？

测试只能提高软件质量，做不到保证，bug是永远存在的，测试工作可以让这

量减少、降低严重问题的存在；软件过程才可能保证它的质量，不是软件测

试，所以这一点我要明确出来。一个软件的质量好坏不依赖于测试者，测试

再高明，软件设计本身的水平面要品质不高，巧妇也有无米之炊的无奈。

2、测试的原本目标就是发现缺陷，挑毛病，工作性质和开发人员相反，但目标

是一致的，都是为了使软件更完美、更稳定。

3、盖房子的时候，先打地基，地基如果有毛病（如不够深、不平），那以后房

盖起来了住个几年，你会发现楼上的梁会发裂，渗水，然后越来越让人担

忧。这时你要修复怎么办，再怎么补都不放心，因为地基有缺陷啊！这个道

和第三个问题是一模一样的，修复的代价太大太大了！在测试中有一个规

则，问题越早解决代价越小，单元测试发现的问题解决只要1块钱，等到集成

测试再解决，要10块钱，你认为比例有多大？需求分析系统设计是源头，重

中之重，这个比例我认为要在上面我举例中增加80%，就是说它会导致你在编

码阶段多付出8块钱。前期可能不觉得，越到后期将发现非常头痛，这也是我

的经验之谈，没有太多的科学性哦。

4、对于测试员，首先是效率减低；对于项目而言，成本增加了。瞧病就错了

诊，影响大么？将导致后面的百分之八十的事情白做了，百分之二在长远

目标中有后期帮助，同时证明另外百分之八十步入歧途。这就要在测试设计

的时候要仔细全面，但是这种事情多少都避免不了，早一点发现并改变，也

是很重要的，另外多布置一些小结会议，有利到测试的工作方向和目标。

usfo，希望我的回答对你稍有帮助哦。