一、可以暴力破解用户名或密码没有验证码机制，没有根据用户名限制失败次数，没有根据ip限制失败次数等等。1.通常思路：直接拿密码字典爆破某一个用户名。拿固定的弱口令密码，去跑topxxx的用户名。如果只是用户名限制失败次数，可以使用思路2的方法。在存在返回提示用户名错误或者密码错误的情况下，可以分别爆用户名和密码。2.常见限制：有时候会发现用户名或者密码是密文加密，这时可能是通过前端或者其他方式加密，对于简单的来说base64编码和md5的签名是很好识破的，在爆破的时候可以选择encode和hash。二、session没有清空登出后服务器端的session内容没有清除，因此客户端重新带回登出前的session，也能够达到重新登录。通常思路：在登录退出后，拿退出前的session，重新访问需要登录的界面。

显式功能性需求（Functionalrequirement）的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能，比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。非功能性需求（Non-functionalrequirement），从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。

首先，要明确用户的需求是什么，比如登录页面应该是弹出窗口式的，还是直接在网页里面。对于用户的长度，和密码的强度（是不是必须多少位，大小写，特殊字符混搭等）。还有比如用户对界面的美观是不是有特殊的要求即是否进行UI测试。功能测试：1.什么都不输入，点击提交按钮，看提示信息。2.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。3.输入错误的用户名或者是密码，验证登录失败，并且提示相应的错误信息。4.登陆成功后能否跳转到正确的页面5.用户名和密码，如果太短或者是太长，应该怎么处理6，用户名和密码，中有特殊字符（比如空格）和其他非英文的情况如何处理7，记住用户名的功能8.用户名和密码前后有空格的处理9.密码是否加密10.如果有验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个颜色是否好用11.登录页面中的注册、忘记密码，登出用另一个账号登录等连接是都正确12，输入密码时候，大写键盘开启的时候要有提示信息界面测试（UItest）1.布局是否合理，2.testbox和button的长度，高度是否符合要求3.界面的设计风格是否与UI的设计风格统一4.界面中的文字简洁易懂，没有错别字性能测试1.打开登录页面需要几秒2.输入正确的用户名和密码哦后，登陆成功跳转到新页面，不超过5秒安全性测试1.登录成功后生成的Cookie，是否是httponly2.用户名和密码是都通过加密的方式，发送给WEB服务器3.用户名和密码的验证，应该是用服务端验证，而不是单单是在客户端用javaScript验证4.用户名和密码的输入框，应该屏蔽SQL注入攻击6.错误登录的次数限制（防止暴力破解）8.考虑一用户在多台机器上登录可用性测试1.是否可以用全键盘操作，是否有快捷键2.输入用户名，密码后按回车，是否可以登录3.输入框是否可以用TAB键切换兼容性测试1,主流的浏览器下能否显示正常功能是否正常2.不同的平台是否能正常工作，windows,Mac3.移动设备上是都正常工作，iphone，Andriod4.不同的分辨率本地化测试不同语言环境中，页面显示是否正确软件辅助行测试软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能高对比下能否正常显示（视力不好的人使用）

1、测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。2、测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，接着分析出每个软件功能需求点对应的多个测试需求点，然后再针对每个测试需求点设计测试用例；最后挖掘隐性需求，覆盖非功能测试层面具体到测试用例设计本身的设计，两个关键的点：从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，只有深入理解被测试软件的架构，你才能设计出”有的放矢“的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。

可以不编写测试用例直接进行测试，但这样是有风险的，不能够保证全面覆盖。另外，编写测试用例的其他作用：（1）了解需求的过程在编写用例的过程中，将仔细梳理整体业务流程、充分思考产品需求的细节，找出需求是否存在不合理、有矛盾、不明确等问题，从而推动BA/UX完成更加详细的设计。（2）理清测试思路及测试过程测试用例的编写，实际上是把需求转换为一种可操作步骤的行为。QA也没有那么强大的大脑能够把所有的操作步骤都记在脑海里，写下来不仅能帮我们记住，写下来的这个过程也是梳理测试思路的过程。特别是，当你将当前需求的用例都罗列出来时，也能很清晰规划之后的测试顺序。（3）规划测试数据的准备我们可以看到，在测试实践中，测试数据是与测试步骤分离的。在测试执行前，按照测试用例准备一组或若干组测试数据，特别是一些需要其他人协助准备的测试数据，这十分有助于高效的测试执行工作。（4）记录测试所覆盖的测试内容，同时反应测试进度依照测试用例执行测试，并及时记录每一个测试用例的测试结果，这样项目成员都能够清楚地了解到目前已经完成了哪些测试，这些测试覆盖了哪些需求。那么在一些突发情况下，比如你被调离或离职，别人也能迅速了解测试覆盖内容及测试进度。（5）为后续的测试提供可参考的依据新加入的功能可能会影响已有功能，新的需求是对原来的功能进行优化，新版本要上线等，项目进行过程中有这很多情况，都需要QA进行回归测试，有了测试用例，回归测试就能按部就班进行。（6）是分析缺陷的标准测试用例并不是一写完就再也不用更新了。通过记录的缺陷数据，与测试用例进行对比，分析是否存在漏测情况，即当前测试用例是否能够覆盖该缺陷，若未能覆盖，说明当前测试用例集不完善，应补充相应测试用例；若已有相应测试用例，则表明测试执行过程中存在问题。（7）指导测试过程可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行毫无意义的测试操作；另外测试用例也是知识积累的过程、一个知识传递的过程，能保持一致、稳定的测试质量。

1.测试用例粒度是否合适，是否有点划分很粗、有的很细，优先级是否合理2.用例名称是否简短清晰3.测试目的是否明确、清晰4.测试用例是否覆盖具体的系统需求5.是否针对以前出现过的那些常见错误提供专门的测试用例6.是否覆盖了正面和反面的用例7.是否针对需求不同部分设计使用不同设计方法8.是否包含边界值、等价类、错误推测、场景分析等测试用例方法9.测试用例如果有前提条件，是否有说明10.测试步聚是否完整，是否包含测试数据，对应的期望结果是否明确、唯一？并说明测试结果的重要性等

1、为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题）2、为了避免三方需求理解不一致；3、为了每个测试人员的质量标准与项目要求标准达成一致。

测试思路：初学者来说，一般是按照从上到下、从左到右的先后顺序依次测试，测试第一个控件的时候，保证其他控件是正确的下面以第一个方框为例：第一步：根据需求，划分等价类（1）有效等价类：1-30的整数（2）无效等价类：非整数、小于1的整数、大于30的整数、空第二步：细分等价类有效等价类：1-30之间的整数无效等价类：其中非整数可以包含：字母、汉字、小数、特殊字符；以及小于1的整数、大于30的整数、空等价类表如下：第三步：编写测试用例从每个等价类范围中挑选至少一个代表数据进行测试备注：1、在测试有效等价类时，当测试对象为多个输入框时，会出现测试用例冗余的问题，此时可以优化测试用例来实现2、当测试无效等价类时，需要考虑多个输入框都为无效的情况

等价类划分为有效等价类和无效等价类有效等价类：有意义的、合理的输入数据集合，程序可以接收到有效等价类的数据并正常执行无效等价类：无意义的、不合理的输入数据集合，程序接收到无效等价类的数据，弹出错误提示或者不允许用户输入的数据