登录界面测试用例(登录界面测试用例设计维度)

编写测试用例，要看需求。一般登录页面要检查的测试点如下。 1用户名为空2用户名长度过短（长度小于需求）3用户名长度过长（长度大于需求）4用户名长度边界值测试5用户名字母、数字、汉字、特殊字符的输入。6密码为空7密码长度过短（长度小于需求）8密码长度过长（长度大于需求）9密码长度边界值测试10密码 字母、数字、汉字、特殊字符的输入。11重复密码的(6-11)的测试点12重复密码长度小于密码长度13重复密码长度大于密码长度14重复密码长度等于密码长度，但是密码内容不同15密码与重复密码长度相同16输入正确验证码17输入错误验证码 以上测试点仅供参考。具体按需求文档规定。测试用例根据测试点编写

1、测试密码、用户名是否输入正常； 2、测试密码、用户名输入异常时；3、测试点下“记住”时是否记住密码与用户名，假如只记下密码或者用户名又将怎样；4、测试点下“不记住”又记下没，假如记下又怎样；5、测试点下“记住”，当有多个用户名需要记下时是否正常；6、测试如何删除已记下的用户名和密码，删除是否真正删除，删除引起其他异常是什么； ……

关于测试用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据UI写测试用例，我们就真的足够了？不够，真的不够。需求在变，开发文档跟着变，设计文档也在改动，UI也在做变化，那我们的测试用例应该怎么写？ 个人认为，一个好的、有效的测试用例，应该具备以下几个特征：1．覆盖全面。测试的每个路径都涉及到，功能测试、界面测试、有性能要求的做性能测试、有安全要求的做安全测试（网络安全、通信安全..）等。2．测试用例的后期维护时间短。测试用例写出来，不可能一成不变，根据系统的优化，测试用例都应该做相应的修改。针对需要修改的测试用例，我们修改了测试用例的哪些部分？测试前提、测试过程、测试数据、测试结果？如果四个方面都需要做修改，要么就是该功能完全变了，要么就是测试用例写的不够好。在系统做优化的时候，一般只需要修改测试数据就可以3．对内的测试用例与对外的测试用例不一样。某些行业，测试用例需要随着系统一起交付用户使用。对内的测试用例，应该以寻求BUG为主，我们可以把过程写的流畅简单些，但是测试数据一定要充分；对外的测试用例，应该以指导用户参与测试为主，所以过程需要比对内的测试用例详细，但是测试数据可以减少。因为用户主要是想知道，这个系统是否可以使用，他不是真的为了给你找BUG。4．同一个产品的不同项目，许多的测试用例可以公用的。所以，针对不同的项目编写测试用例，有许多我们拿以前的测试用例直接黏贴过来用，减少了许多写测试用例的时间。针对以上几个特征，编写测试用例前，我们应该做哪些工作？我一般会花一些时间去看看需求文档、设计文档、开发文档；有机会就去找市场部的人交谈，在他们抽烟的时候，冒一根不够，就再冒一根，慢慢的问我想知道的问题；最好也和研发部的开发人员了解下情况，这个系统他们怎么看的，打算怎么做，有必要可以说说你的观点。当这些前提你都做了，你完全可以写测试用例了，当然边写还是要边沟通，也许有新的发现呢？如果边写测试用例的时间不够，你没有太多的时间去做这么多的铺垫工作，也没有关系，你可以先把一些通用的测试用例写出来：登陆、增加数据、修改数据、查询数据等，然后把业务要求比较强的测试用例放在最后编写，这样我们既没有浪费时间，也可以按时交测试用例。测试用例写出来，维护怎么办？测试用例的维护，写过测试用例的朋友都知道，大家都去嘟囔修改测试用例很无聊，首先它没有太多的技术含量（这个大家都不喜欢，好多人也认为测试没有技术含量），第二这个过程很繁琐和枯燥。如果想维护简单，在编写测试用例的时候你就应该考虑到这点。各项描述应该怎么写，通俗易懂而且是通用的是首选。举例：方法一：测试前提：系统服务运行正常、，具有xiaoming这个用户，密码为999999测试过程：1.访问系统登录页面http://localhost:8089/index.jsp2.输入用户名：xiaoming输入密码：9999993.点击“登录”测试数据：用户名密码举例：系统用户：xiaoming，密码999999；xiaohong，密码666666用户名与密码不匹配：xiaoming，密码666666；xiaohong，密码999999非系统用户：xiaowang，密码999999；xiaobai，密码666666非法参数：#￥%，密码HH*&56；yong12%……，密码**……（测试结果：使用正确的用户名与密码，可以登录系统；使用错误的用户名和密码，不能登录系统结果分析：方法二：测试前提：系统服务运行正常、具有系统用户数据测试过程：1.访问系统登录页面2.输入用户名和密码3.提交数据测试数据：用户名密码举例：【假设xiaoming，密码999999为系统用户】说明：用户名只能为数字、字母、下划线‘_’，首字不能为下划线密码不能为空格正确格式的用户名：xiaoming、xiao123、xiao_123、123_xiao等错误格式的用户名：xiao%、123_xiao+空格、！@等密码的输入参照用户名的输入规则测试结果：系统用户能够登录系统并具有对应的权限、非系统用户不能登录系统结果分析：参照以上两个测试用例，我们就能很明显的分辨出用例的优劣。第一个测试用例我们至少需要准备xiaoming这一个测试数据、登录界面如果增加了需要输入验证码，我们就要重新修改测试过程，测试数据我们也要做很多修改（就拿用户名可以输入数字、字母、下划线来说，正确的组合就有2*3*3=18种），测试结果，我们登录系统为了做什么？没有权限怎么办？我们应该具有哪些权限？第一个用例就没有做说明，可以说，测试结果的说明是不全面的。第二个测试用例，如果系统增加了需要输入验证码，我们在测试过程的第二步，只需要说明输入用户名、密码、验证码，测试数据我们不需要做变化，在结果分析里，增加说明：用户名、密码、验证码正确，准入，否则拒绝。第二个测试用例，有个不足，就是测试数据不全面。我在编写测试用例时，针对这个测试用例，我有个测试数据的附件。【附件分为两部分，手工测试以及自动化测试，手工测试我会有个详细的数据说明，并不是把所有的数据组合都列出来，而是详细的说明组合的方式方法，一共有多少种（包含边界值法以及特殊值等）；自动化测试的数据说明简单很多，写一个正则表达式搞定】。按照第二个测试用例，我们的工作就不再是苦力了，而是智慧的苦力。我们不再是点点点，慢慢的我们知道哪些是主要关注的，哪些是次要关注的，我们应该怎么去设计数据等等。慢慢的，我们学会了思考，我们也真的进步了。 欢迎大家多提意见，我们一起进步。

先确定QQ本版(web或者2010等等)，登录两个QQ，相互为对方好友，然后设置其中一个状态并让状态转换(包括好友中显示，群组中状态显示等等)，查看是否为预期效果。 这里面重要的弄清楚有哪些状态，并这些状态的含义和其他状态的根本区别在哪里，如果这些弄清楚了，状态转换图就比较好画了 如果是各种设置均要测试的话，那么先将界面上的功能点全列出来，然后保证功能点全面的前提下，针对每个功能点编写测试用例，这样保证不会漏掉功能，对于相关功能点的，可以在所有功能点测试用例编写完成后，将关联很紧密的进行合并处理，保证测试用例不重复

概括了8个方面，这些都是要重点考虑的： 1. 正确的用户名和密码，包括是合法的字符和合法长度2. 错误的用户名，包括用户名含有非法字符、长度过长、长度过短3. 正确的用户名和错误的密码，包括非法字符、长度过长或过短4. 用户名和密码都为空5. 正确的用户名，密码为空6. 任意的用户名和密码，包括正确的或错误的，也可以为空7. 检查UI友好性检查登录界面设计是否合理，符合UI规范标准界面符合习惯、美观，按钮对齐，输入框对齐，无错别字，字体大小协调，文字描述准确 8. 检查安全性(SQL注入等)