产品经理的测试修养

产品笔记系列：20170104

一、测试准备

测试用例

1.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况

2.测试用例的设计步骤

根据设计规格设计基本功能测试用例—>边界值测试用例—>状态转换测试用例—>错误猜测测试用例—>异常测试用例—>性能测试用例—>压力测试用例

测试文档包括：测试计划文档，测试设计规格文档，测试用例，软件缺陷报告，状态报告

Bug标准

1.Bug记录

一个Bug最基本的记录要求：bug编号、bug严重级别、优先级、bug产生的模块、bug摘要、阐述bug大体的内容、bug对应的版本、bug详细现象描述，包括一些截图、录像等、bug出现时的测试环境、产生的条件即对应操作步骤

2.产品Bug等级

1）致命错误，可能导致本模块以及其他相关模块异常，死机等问题;

2）严重错误，问题局限在本模块，导致模块功能失效或异常退出;

3）一般错误，模块功能部分失效;

4）建议问题，由问题提出人对测试对象的改进意见.

3.修改Bug原则：

1）发现严重错误、致命错误应及时处理，有需要则采用热更新/发包

2）发现一般错误则尽可能在下一版本中处理

3）建议问题可适当靠后，可加在后续的版本需求中

4）在发新版本前发现一般错误、严重错误、致命错误，应解决错误之后再发版本

二、测试流程

1.单元测试：对程序中基本组成单位测试，如一个模块、一个过程等；目的是检验软件基本组成单位的正确性

2.集成测试：在软件系统集成过程中进行的测试，目的在于检测软件单位之间的接口是否正确

3.系统测试：对已经集成好的软件系统进行彻底的测试，以验证程序的正确性和性能满足需求

4.验收测试：以《需求规格说明书》为验收标准，测试时模拟实际用户的运行环境；测试内容为：对功能模块的全面测试

5.回归测试：在软件维护阶段，对软件进行修改之后进行的测试；目的在于验证修改后的程序是否能够正确的运行

二、原则&理论

测试原则

检查程序是否做了“产品需求”中描述的事情，以及有没有做“产品需求”外的事情（需求+错误）

测试理论

1.黑盒测试：已知产品的功能需求，测试验证每个功能是否符合需求

黑盒测试方法包括：等价类划分、边界值分析、错误猜测法、因果图测试、状态图、场景法、大纲法

2.白盒测试：已知产品内部工作过程，测试验证功能内部操作是否符合功能需求

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖

通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试

三、测试要求

1.功能测试

1）功能测试：检查需求描述中的产品交互，能否正确地进行跳转，数据能否正确提交/返回

2）加载测试：检查多媒体元素是否可以正确的加载/显示，页面显示是否正常

3）链接测试：链接是否可正常跳转，是否有的出错信息返回

4）多语言支持：能否正常支持显示语言、表情、特殊符号等

2.界面测试

1）页面实现效果是否与设计效果图一致

2）页面布局是否合理正确，重点内容和热点内容是否突出

3.性能测试

1）性能测试一般从以下3个方面考虑：压力测试、负载测试、强度测试

2）输入条件在边界值、极限值情况下，能够正常运行，并给予正确的反馈

3）数据库测试：数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面

4.安全测试

1）基本的核心功能测试：比如，登录注册、支付等产品关键业务

2）是否存在错误会导致系统崩溃、权限泄露等问题

3）相关开发语言的常见安全性问题检查，例如SQL注入等

5.兼容性测试

1）客户端的兼容性

2）系统版本的兼容性

四、测试方法

1.等价类划分：把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件；等价类划分可有两种不同的情况：有效等价类和无效等价类

2.边界值分析法：使用边界值分析方法设计测试用例，首先应确定边界情况；通常输入和输出等价类的边界，就是应着重测试的边界情况；应当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据

3.错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误、以前产品测试中曾经发现的错误等；还有, 输入数据和输出数据为0的情况

4.因果图方法：考虑输入条件之间的相互组合，可能会产生一些新的情况；可考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例；这就需要利用因果图（逻辑模型），因果图方法最终生成的就是判定表

5.正交表分析法：可能因为大量的参数的组合而引起测试用例数量上的激增；同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性

6.场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

7.状态图法：通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。

8.大纲法：大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。

大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。

五、其他

1.正确认识测试：测试流程的核心是在保障研发效率的前提下提高产品质量

2.关于人肉测试：测试团队更多的职责在于测试边界、极限条件的情况，以及做回归测试

3.测试用例的设计到测试执行，可以采用经典的三轮测试体系与探索性软件测试体系

按照测试用例——用例评审——一轮测试（全面执行测试用例）——二轮测试（针对bug修复的验证以及bug修复可能带来问题的验证）——三轮测试（内网全面回归）——外网回归测试

4.回归测试需要频繁的执行，去检查以往用例是否因为应用迭代而出现新的bug。

在回归测试环节也可以辅助采用测试自动化的方法，但很多时候自动化是不能判队代码出错的问题的，更多是需要监控sdk进行