新人进入公司后，一般会让新人接手产品测试的工作。回忆我当时的测试方法，现在想起来只能呵呵一笑，其实做任何事情，都是有方法的，不是想到要测试什么就测试什么，所以，我们需要学习一些测试的方法了。
那么，测试的方法可以分为多个维度展开：
1.功能测试
2.UI测试
3.业务场景测试
4.数据测试
对于PM来说，测试工作分为两个阶段，
第一，PM设计完原型后，需要跟进UI、前端、开发，确保最终的产品不会和自己设计的原型偏差太大；另外，还有一个原因，由于不是每个PM的能力都很强，那么自己在设计原型的时候，有些功能点是思考不到位的，比如，原型设计完成之后，交付给UI、开发的时候，会因为某些功能点不能实现或者是某些功能的逻辑有缺陷等等问题，导致逻辑需要重新梳理、功能页面需要重新设计、页面缺失等返工现象。
第二，功能开发完成后，不是每个开发都是细心且有耐心的，有很多开发的同学其实不怎么喜欢测试自己的功能，所以PM需要“帮助”开发同事提高其代码质量，一般小公司很少会有专门的测试人员，所以，大多数的情况下，需要PM去充当测试人员的角色，那么测试的工作不仅仅是简单的功能测试、逻辑测试了，接下来，我就详细的说明，测试的方法和测试的重点。
作为一个“专业”的测试人员，需要在测试前准备的工作有：
第一，要清楚当前需要测试的功能模块、系统版本
第二，拿出自己的PRD、原型设计文档
第三，搞清楚产品主要支持在什么系统、平台和设备上运行，比如说，我目前主要是做后台管理系统的，是B/S架构，那么我需要准备几种主流的浏览器，由于设备有限，我一般只用自己的笔记本电脑测试，其实资源充足的话，可以找领导要两个不同尺寸的显示屏
第四，产品有接入哪些外部产品，如果需要其他产品提供数据，那么就要清楚是直接提供的数据库视图还是提供API方式，如果我负责项目是需要和七八的厂商的系统进行对接，这一块的测试工作都是可以独立出来进行了
第五，什么时间、多长时间用来进行测试工作，这个在测试之前一定要安排好自己的工作，不能花费大量的时间在测试上，毕竟你还有很多工作呢
第六，测试的优先级如何排列，考虑功能的重要性、紧急性
第七，测试的风险如何判断
第八，发布和更新的流程如何
测试重点：（我暂时整理了一些，后期会扩充进去）
考虑时间、资源等因素，首先，一个产品能不能用其实比一个产品好不好看或者是用起来爽不爽更重要。
那么在测试的时候，我们需要知道，当前的功能能不能正常的使用，模拟用户在使用的过程中，能不能正常走完其对应的业务流程。所以，功能测试我写在了前面。
功能测试的主要的测试方向：
第一，准备好测试用例
从用户场景测试：自己做的产品，我们一定有自己的理解，而用户实际上是如何使用的？在什么样的情景下使用？都是我们需要慢慢的通过与用户的交流，产品的数据积累，用户研究得来的，测试的时候当然也不能漏掉。
第二，模拟用户的操作行为
在不该返回的时候返回、不耐心多次点击按钮、输入错误数据、不理解如何使用、没按照产品规则进行设置、随便乱点......
细化下来可以有：
1-页面是否缺失
-页面链接检查，每一个链接是否有对应的界面，其中链接的方式包括：文字、按钮、图片、视频
2-按钮功能
-检查按钮功能是否正确
-检查删除功能，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理
-检查多次点击返回按钮的情况
3-相关性检查
-删除/增加一项会不会对其他项产生影响，如果产生影响，是否正确，一般涉及最多的是信息管理模块和业务处理模块之间的更新，信息维护之间的更新
4-字符校验
-字符串长度检查、字符类型检查
-标点符号检查（特别是中英文的符合，一定要区分开，比如说“冒号、句号）
-中文字符处理，乱码或出错
-某些特殊字符的格式（比如说：日期、时间、价格、百分比）
5-信息完整性、唯一性
-检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致
-信息重复，在一些需要命名，且名字唯一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的前后输入空格，看系统是否处理
-检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型
-检查修改重名，修改时把不能重名的项改为已存在的内容，看会否处理，报错，同时看会否报和自己重名的错
6-选择操作
-选择一个或多个时又如何处理
7-表单操作
-重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理
-表单上面的按钮，比如说：确认、取消、关闭弹窗，其对应的操作是否正确
8-查询操作
-如果可以输入多个search条件，同时可以添加合理和不合理的条件，看系统是否处理正确
-在有search功能的地方输入系统存在和不存在的内容，看结果是否正确
9-编辑框操作
-输入信息的位置，输入信息时，光标的位置
-必填项检查，必填项是否有提示信息
10-上传和下载
-上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息
11-按键操作
-快捷键检查，是否支持常用快捷键检查?
-回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。?
第三，出错时的提醒和消息
这时就完全从用户和测试者本身的角度来思考问题了，错误提醒和消息是经常出现问题的地方。
错误提醒的UI是否易于接受？错误信息内容是否易于理解？错误信息格式是否一致？错误提醒有没有用？信息内容是否合适？错误是否符合惯例和标准？错误信息本身是否正确？产品是否能获得错误和崩溃信息？是否所有的错误都测试过？用户处理完错误信息后，将处于什么状态？是否在用户应该接受错误信息时，却没有错误信息弹出？
错误信息的确会影响用户体验。然而，错误始终是不可避免的，就像我们永远写不出没有任何Bug的程序一样。
虽然最理想的状态是避免用户遇见错误信息，但这几乎不可能。
对于出错情况的设计、实现和确认很可能与预期相反，但只要测试时善于发现这些意料外的Bug，改进它们就更有头绪了。
第四，兼容问题：跨平台的注意事项
web端来说，主要是前端代码的兼容问题了
第五，网络中断或其它原因打断时的情况
功能测试完成之后，需要我们对产品的UI进行一个测试工作了，毕竟长的丑的产品，谁会喜欢用呢，那么针对UI这部分，主要就是PM（小公司）需要拿出在设计原型之前找UI定义的UI设计规范文档了。
UI测试的重点：
第一，前端有无遵守设计规范
第二，考虑到用户体验方面，PM之前无考虑到的交互，需要再补充
一般情况下，在测试的时候，发现bug，需要记录在bug跟踪的软件里，需要让指定的人知道bug、修复bug，我们在登记bug的时候，也需要清楚的知道bug的优先级，让开发人员有序的进行修复的工作。
对于领导来说，他们需要一个总结性的测试报告，让他们知道当前项目的进展如何，那么我们需要提供一份“测试报告”，定期的以邮件的形式抄送给相关的领导。
测试方法，还在更新中.......
