无规矩不成方圆，做好项目就是做正确的事情，而正确地处理事情才能更好地提高效率。测试部门在接到一个新的项目后，需要按照以下五个流程逐步开展测试工作，该流程在实际的工作中，可根据实际情况进行补充和完善。
在测试人员开展工作之后，需要借助产品人员和开发人员提供的文档，形式的文档可以给测试工作带来依据。具体参考文档包括：产品需求说明书、产品设计原型、数据库设计方案、开发部门代码规范说明、开发人员（前端和后台）任务分配表等。
测试工作的基本流程图如下图所示：
根据项目需要，目前主要进行的有功能测试和性能测试。现阶段以功能测试为主，而功能测试目前使用最多的测试方法有等价类划分法、边界值分析法和错误推测法。这三种都属于最常用、最典型、也是最重要的黑盒测试方法。 其他的方法还会涉及到因果图法、判定表法、正交分析法、场景法等。
选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。
在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。
示例：针对“用户登录”功能，基于等价类划分和边界值分析方法，我们设计的测试用例包括：
1. 输入已注册的用户名和正确的密码，验证是否登录成功；
2. 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3. 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4. 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
6. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登 录成功；
7. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登 录失败，并且提示信息正确。
如果再加上错误推测法（因人而异），会再增加以下的测试用例：
1. 用户名和密码是否大小写敏感；
2. 页面上的密码框是否加密显示；
3. 后台系统创建的用户第一次登录成功时，是否提示修改密码；
4. 忘记用户名和忘记密码的功能是否可用；
5. 前端页面是否根据设计要求限制用户名和密码长度；
6. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
7. 刷新页面是否会刷新验证码；
8. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
9. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
10. 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
11. 页面默认焦点是否定位在用户名的输入框中；
12. 快捷键 Tab 和 Enter 等，是否可以正常使用。
一个质量过硬的软件系统，除了显式功能性需求以外，其他的非功能性需求即隐式功能性需求也是极其关键的。显式功能性需求的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能。比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。
示例：我们来继续完善“用户登录”的测试用例。
在安全性方面补充的测试用例包括：
1. 用户密码后台存储是否加密；
2. 用户密码在网络传输过程中是否加密；
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4. 不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
5. 密码输入框是否不支持复制和粘贴；
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7. 用户名和密码的输入框中分别输入典型的“SQL 注入***”字符串，验证系统的返回页面；
8. 用户名和密码的输入框中分别输入典型的“XSS 跨站脚本***”字符串，验证系统行为是否被篡 改；
9. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
站在性能压力测试的角度测试用例包括:
1. 单用户登录的响应时间是否小于 3 秒；
2. 单用户登录时，后台请求数量是否过多；
3. 高并发场景下用户登录的响应时间是否小于 5 秒；
4. 高并发场景下服务端的监控指标是否符合预期；
5. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
站在兼容性测试角度测试用例补充包括：
1. 不同浏览器下，验证登录页面的显示以及功能正确性；
2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。
对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。但软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所以测试部门需要兼顾缺陷风险和研发成本之间的平衡。
根据缺陷的定义，将缺陷分为如下4类:
指对文档的静态检查过程中发现的缺陷。检查活动包括同行评审、产品审计等。评审的缺陷要根据被评审对象的类型来确定，被评审的对象包括最终出产出物和中间过程产出物。比如产品需求文档、原型设计文档、测试计划、测试用例等。
指对代码进行同行评审、审计或代码走查过程中发现的缺陷。
指由测试活动发现的测试对象的缺陷，被测对象一般是指可运行的代码、系统，不包括静态测试发现的问题。
又叫做不符合项问题，是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是测试人员、项目经理等。
根据所提交bug的严重性，本规范定义以下五个级别。
A类：严重错误，包括以下各种错误：
（1）由于程序所引起的死机，非法退出。
（2）死循环
（3）数据库发生死锁
（4）因错误操作导致的程序中断
（5）功能错误
（6）与数据库连接错误
（7）数据通讯错误
B类：较严重错误，包括以下各种错误：
（1）程序错误
（2）程序接口错误
（3）数据库的表、业务规则、缺省值未加完整性等约束条件
C类：一般性错误，包括以下各种错误：
（1）操作界面错误（包括数据窗口内列名定义、含义是否一致）
（2）打印内容、格式错误
（3）简单的输入限制未放在前台进行控制
（4）删除操作未给出提示
（5）数据库表中有过多的空字段
D类：较小错误，包括以下各种错误：
（1）界面不规范
（2）辅助说明描述不清楚
（3）输入输出不规范
（4）长操作未给用户提示
（5）提示窗口文字未采用行业术语
（6）可输入区域和只读区域没有明显的区分标志
E类：测试建议
根据所提交bug的优先级，本规范定义以下五个级别。
1. Highest ：表示问题必须马上解决，否则系统根本无法达到预定的需求。
2. High：表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
3. Medium：表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
4. Low：表示计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
5. Lowest：即问题在系统发布以前必须确认解决或确认可以不予解决。
功能测试的通过准则一般有：
（1）单元功能同设计需求一致；
（2）规定的路径覆盖率及覆盖类达到要求，且执行正确；
（3）所规定的黑盒测试手段被使用，且执行正确；
（4）对残留错误有合法解释或被认可暂留；
（5）虽然路径覆盖率不能达到，但其他各测试的错误查出率趋产0或稳定(时间的长短视情况而定)。
各类软件测试合格须符合以下标准。
A类错误 | B类错误 | C类错误 | D类错误 | E类建议 |
无 | 无 | <1% | <5% | 暂不作要求 |
以上比例为错误占总测试模块的比例。
软件产品未经测试合格，不允许上线发布。
更多精彩都在洋哥视频课程学习地址：http://edu.51cto.com/lecturer/5811414.html
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
