测试用例

输入店员编号和密码可以正确登录客户端，其中店员编号为数字，位数没有限制，密码必须为六位数字，输入店员编号和密码后需要联网，后台判断编号和密码正确后，能够正确登录!

我最初测试数据迁移时感觉走了不少弯路，于是根据的经历小结一下如自己何去测试数据迁移，和大家交流一下心得体会。

当今软件测试十分盛行时，本人通过项目实践和个人亲身体会浅谈单元测试，本人一直坚持“用代码说话的原则”，同时也希望个人能给出宝贵意见，共同探讨、共同进步，为中国软件事业有更大的发展共同奋斗!

跟测试工程师打交道最多的可能就是测试用例了，先设计出一些测试用例，然后这些测试用例要经过评审，之后要执行这些测试用例，完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢?很多人可能第一时间想到了一些测试管理工具能帮上忙，例如Quality Center，Test Link;又或者是一些保存测试用例的工具，例如Word，Excel。

设计、测试用例，两码事。测试人员设计测试用例的过程跟系统设计的概念没有太大的联系，测试人员可以参与设计，从测试人员的角度提出自己的建议，但不要把自己当做设计人员去设定系统规则。测试的目的,第一验证程序是可以按照需求和设计运行的；第二找出程序不能按照需求和设计运行的问题，并保证这些问题被最终修正。因此不要期望 测试人员设计测试用例的过程 跟 系统设计 划上什么等价关系。

从根本上来讲，设计与测试案例只不过是同一个需求的不同表现形式。设计更多的是从逻辑上表现系统/功能的内部结构，对象间关系，算法或者流程等内容。测试案例则偏重于其设计实现的校验上。我个人觉得，无论是传统的开发模式，或是TDD，都无法脱离或背离需求这个根本。

测试用例，简单的来说是描述对一个功能模块或者业务模块进行测试的步骤及指导，好的测试用例能够让对系统完全不了解的测试人员，都能根据用例进行测试。用途是：通过用例的执行，发现系统存在的问题。通过发现问题，确保项目质量。

1、做测试已快一年了，感觉学到很多、但是很迷茫。迷茫的问题是：会写测试用例了，但是写的测试用例总觉的不全面会有遗漏2、关于幻灯片播放模块不知道该用什么样的思路来写模块，希望我能给些建议

站在用户的角度，以用户的使用逻辑及操作习惯为出发点，结合功能用例的设计方法，使用例设计更符合用户使用逻辑更具有可执行性，从而最大程度上覆盖用户需求。

功能测试用例的书写方式

要在有限的时间内编写完整有效的测试用例，所涉及到整个软件开发测试过程的方方面面，不是一两个知识点或者有些经验就可以定义的。而关键还是要明确需求，尽量减少需求变更，否则后续编写的用例，也只是做无功用罢了。

目前我们设计的测试用例只是表面上的呈现，对测试指导的作用不是很大，我们思想里也认为测试用例编写只是在熟悉系统的过程，在测试时测试用例会被我们撇在一边。个人总结一下原因和改进方法

首先把数目极大的输入数据划分成若干等价类。等价类是指某个输入域的子集合。在子集合中，各个输入数据对于揭露软件中的错误都是等效的，并且合理的假定：测试某等价类的代表值等价于对这一类其他值的测试。因此可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性测试数据，取得较好的测试效果。

翻页功能我们常碰到的一般有以下几个功能：1、首页、上一页、下一页、尾页;2、总页数，当前页数;3、指定跳转页;4、指定每页显示条数.当然，有一些是少于多少页，全部以数字的形式显示，多于多少页后，才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计。

大家在编写测试用例的时候往往把输入数据、操作步骤、输出、结果、以及一些过程信息等都包含很全，但是往往忽略掉对执行该测试的检查点，这些检查点往往是测试用例设计和编写的人的经验或对被测对象的深入的理解基础上，很多检查内容参加我写的测试检查点的文章。

在软件测试中，测试用例的设计是一件很难的事情。你可以拿任何一个公司的两个不同人员就同一功能点所写的测试用例来看，肯定会发现有所不同，这是为什么呢？一是着眼点不一样，二是经验不同，三是思维的问题了。其实你可以看到，有的人写的用例简单明了，有的人写的用例却是复杂冗长，出现这种情况并不奇怪，因为测试用例本身的设计方法与技巧很多都是从经验中来的，有些形成了理论，而有些还形成不了能够指导测试活动的理论。

黑盒测试，常用的有：边界值分析;等价类划分; 错误猜测等。

因为信息的多样性，所以对权限测试前要设计好测试用例，否则直接测试，肯定会有遗漏地方。

我们是不太可能在一个测试用例中包含所有测试需求，因为众多的功能以及不同的路径组合将使这样一个测试用例像大象一般，完全不具有可行性。除非您的软件所包含的功能真的又少又简单，不过如果真的有这么一个软件，恐怕也没有测试和发布的必要了。

随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。