如何设计模块测试需求
一个模块的测试需求大体可以分为四大块：UI需求、功能需求、用户场景需求、性能与稳定性需求1、UI需求
指的是，页面操作需求，不涉及到具体的业务，仅仅是页面操作的功能。这里面其实就包含有一些通用的隐性UI需求。
最好的产品是不管是多么小白的用户，拿到产品后能不使用用户手册或不需要旁人的指导下就能上手使用。UI要能指导用户如何去使用或用户能根据返回的提示完成他想要完成的操作。
页面是用户使用感受最直观的体现，一个功能的UI做得好不好，用起来提示容不容易理解，是体现一个产品好不好用的一个关键。基本上每个产品线每个功能模块多多少少都会涉及到UI的改动，交互的设计。
UI需求大体可以从UI限制和UI显示这两大块来考虑 :
UI限制指的是页面上都有哪些限制，如输入框的限制，容量的限制，格式的限制;
UI显示指的是特定条件下UI的展示效果。
https://picx.zhimg.com/80/v2-2628a02a076a53a01e30064dd32e1d79_720w.jpeg
2、功能需求
指的是，我们做一个什么功能，要实现什么样的效果。一般每个功能模块都会有需求文档(或需求矩阵)。若比较规范的产品线会对每个功能模块有一个比较详细的需求规格说明书，需求规格说明书里会明确规定这个功能模块需要实现什么功能，解决什么场景下的什么问题。
举个升级的例子：如升级需求：支持在线升级，支持离线导入升级。
在线升级可以根据升级的流程进行细分：下载升级包、升级过程这两个大过程，
下载升级包又可以细分：从哪里下载，怎么下载(下载的方式);
升级过程又可以细分:升级前判断、升级过程中处理、升级结果检查三个大点。
(以上的细分都是根据升级流程来进行细化，每个功能模块除了关注自己本身的功能，还要关注与其关联的功能或模块。)但程序或客户的环境不可能永远都是这么理想的情况，为了程序健壮性，功能稳定可靠性，我们还需要考虑下可靠性方面的需求，如升级可靠性可以从升级的流程上去细分，分为下载可靠性和升级可靠性。其中下载就会涉及到三个节点：存放升级包的服务器，中间传输网络，要升级的设备。根据这三个节点之间的联系，可靠性又可以分为网络可靠性、设备可靠性、环境可靠性。升级过程也可以分为设备可靠性和环境可靠性。
3、用户场景需求
用户场景，即：用户的使用场景，大致可以从新用户，老用户以及用户业务这三个方面来分析用户场景。
新用户即：所有东西都是新的，需要模拟全新安装，全新部署上架的过程。
老用户即：已经在使用该产品的用户，对这些用户来说他们是更新，是升级。更新和升级就会涉及到用户已经在使用了哪些产品，已经配置了哪些策略。而这些使用和配置就要考虑与当前版本改动的兼容性。
用户业务即：用户会如何来使用这个功能，中间可能会有哪些操作。
(这里需要注意区分用户场景与功能案例，功能案例是从单个模块功能层面考虑，如何使用功能，出现什么问题如何处理。但很多情况下在客户那边，不会单单使用一个功能，它会连着其他功能一起使用。所以用户场景考虑得更多的是整体的使用场景，考虑的是更加全面的操作。)
4、性能与稳定性需求
模块的性能可以根据各自模块的特性进行考虑是否需要进行性能的设计。若是服务器，基本可以从前端性能和后台性能两大块来考虑
页:
[1]
