关于整理测试case

zangcf

怎么写测试case
1，功能性测试：状态跃迁图
起始状态-->作用于上面的事件-->结果状态

2，可靠性测试
极端环境-->
多次重复
高温高热等复杂环境

3，性能测试
产品规划需求决定，比较好量化，而且测试方法也是没有多少歧义的，就是指定测试计划和写测试计划的时候写全了就可以了。

zangcf

到底哪些内容需要我们测试？
起始做任何事情都是有假设的，我们做产品的假设是什么？
对于我们的产品，我们不得不假设
1，Android的这个版本是可靠的
2，上游芯片厂商该方法是可靠地。
3，更深层次，我们系统基于的协议级别的东西，例如tcp/ip是可靠等等。

而且，我们对于这些东西信任度也是有排序的，
例如，我们对协议级别的信任度是99%，对于android信任度是90%，对于芯片厂商的信任度是80%等等。

那么，我们应该测试一些不可靠或者没有把握的东西，那么是哪些东西呢，也就是哪些地方可能会有虫子(BUG)。

zangcf

首先，我们定制和修改的东西最可能有问题。
例如，PCB是我们重新画板子，这个板子可能不稳定，一些部分逻辑被我们修改了，这个逻辑可能有问题。
再次，结构是我们自己做的，那么这个结构可能不可靠，这个结构可能感受硬件的性能等。
再次，软件我们重新编译和修改了，这个修改和编译可能带来问题。
====================
如此看来，我们最好的办法还是全部测试

zangcf

功能测试的状态跃迁图示例：
前置条件，主要硬件软件环境都要写，例如系统预装或者预置什么程序和数据等。
动作，基本就是加于状态上的事件了，这些事件对于我们平板和手机而言，例如如下
1，按了摸个物理按键
2，按了屏幕上某个图标按钮等
3，来电来信息网络长连接等
4，外边环境变化的事件，例如光电磁方向位置等变化。

既然使用状态跃迁图，为何我们还会写多步骤的测试case呢？
哪些情况，我们不去穷举罗列所有的事件和状态的组合呢？

zangcf

穷举case几乎不可行，这样很多就会出现天文数字级别的测试case，所以，我们必须基于设计的解耦原则进行设计测试case。
设计上的弱耦合和使用上的弱耦合，都不做测试状态和测试事件的组合。
例如，调节屏幕背光和进入某个应用，本身关联性不强，这样就没有必要组合进行测试。

zangcf

多步骤执行的划分，哪些case需要划分成多步，而不是一个一个分开写成单步？
逻辑上是一个整体，例如：
某个应用注册账户，可能需要分成三步：
第一步，填写用户名
第二步，填写个人信息
第三步，手机短信验证
这样，这是一个完整的整体，就要放到一个case里面做。

zangcf

系统领域分类，不同划分有重合，但是侧重点不同
1，系统平台状态转换测试：
上图只是一个简单的状态转换
下面就可以清晰的罗列状态的不同和事件的不同了。
开始状态：第一开机，非第一次开机，插入单SIM，插入双SIM卡，插入TF卡，插入耳机，插入电脑充电，插入充电器充电，组合之后有非常多的初始状态

事件：按power按键，按音量加减，插拔充电器，按住几个虚拟按键等，又是有很多种状态组合。
这样，就可以完成写完系统的功能case。

可靠性，就是以最典型的几种状态迁移路径，多几台机器，每台做100次，甚至1000次。
===================================
性能测试，就是测试开机时间，和基站联系时间等具体数据。
===================================
期望中间不能有花屏等，能够顺利进入状态

zangcf

再举一个例子：
摄像子系统：
这是一个基本过程，起始我们可以定制状态和事件，组合出各种使用场景
例如，光照条件拍照，闪关灯的选择，存储卡的条件，如果有网络功能，网络条件等

zangcf

wifi系统：
关闭状态-->打开-->使用-->关闭
系统自动打开
==================
可以添加初始状态和事件有多少？

zangcf

电池和充电系统：
关机状态-->开机状态
关机状态-->充电状态
=================
主要考虑大电流事件，电池能否顶得住
时间事件，放电显示电池电量是否准确