转自
http://www.pmcaff.com/forum.php?mod=viewthread&tid=4532
如果说范围核实用来验证“对”的事情，质量测试主要工作就是“纠错”，尽可能的使用极端测试用例验证产品是否稳健。理论上试错的事情应该主要由测试部门完成，PM接收的时候只需要抽样就可以了。因为质量测试需要三样条件做为支撑，专业技术能力、丰富经验和大量时间，这三样产品人员往往都不具备，所以即便进行质量测试，也不过是范围核实的加强版而已。
举个例子：假设报名表里有个功能，需要根据用户IP判断所属城市，然后替用户自动选择一个默认城市。这个功能的测试很难通过手动完成，需要测试人员编写测试脚本，随机抽1000个已知IP地址，根据开发部开放的接口，读取这1000个IP的城市ID返回值，并判断正确率。如果这个功能让产品人员测试，限制非常多。通常的做法也就是QQ群里面喊一嗓子，请各地的朋友帮忙看一下而已。
前面说了这么多不合适，不过由于一些公司测试方面的缺失，PM还是需要承担更多的测试工作。有关测试方面工作需要阅读相关专业书籍，这里只能很简单的介绍一下自认为重要的两点。
1.合理编写测试用例。
测试前的一个重要准备工作，就是编写测试用例。测试用例编写的好坏依靠个人经验和公司的历史积累。用例格式类似下表，要把能想到的选择和预期结果都写入，不仅要包含正确数据，更多的是要包含边界数据和错误数据。具体的设计测试用例方法可以查看专业书籍，有等价类划分法、边界值分析法、错误推测法、因果图法等等，不赘述。为一个功能写出三五千条测试用例是件很普遍的事情，所以要求一定要书面化积累，这样下次遇到同样需求可以拿来参考（不是直接拿来用哦！）。
编号 标题 操作 预期结果
1 用户名对话框 输入4个中文汉字 焦点离开对话框后，提示输入正确
2 用户名对话框 输入1个中文汉字 焦点离开对话框后，提示错误提示
3 用户名对话框 输入5个中文汉字 焦点离开对话框后，提示错误提示
2 用户名对话框 输入纯英文用户名 焦点离开对话框后，提示错误信息
3 用户名对话框 输入中文夹杂英文 焦点离开对话框后，提示错误信息
4 .... .... ....
2.分级报错。
A：系统错误（页面无法打开，系统报错提示，死循环）
B：功能性错误（链接失效，非预期结果）
C：一般错误（错字、错图）
D:用户体验（页面变形，错行，页面访问速度，改进性意见）
E：压力测试
如上表所示，一般的页面BUG都归为上面这五类。E类错误不考虑（没条件测），其他错误的危害程度按A-D依次排序。一般PM新人会犯的错误是将验收查到的所有问题及疑似问题统统上报，虽然这样做没什么大错，但是有三个麻烦的地方：1.看到BUG清单一长串，自己先会被吓到。2.会给开发人员排查问题带来很大困扰；3.会被鄙视为“不专业”（其实本来就不是专业的测试嘛^_^）。
正确做法是将手上的BUG列出清单后，先分级。建议类放一边，错误类打上ABCD标签。AB类错误先上报，这个级别解决差不多了，再将新查出来的AB及累积的C类问题上报，等再解决差不多了，最后将所有剩余问题、建议一次性上报。