前言

测试用例和测试点是相辅相成的，测试点是属于思路性质的，测试用例是属于在实际的工作中具体怎么进行测试的一个依据。一般情况下，用例编写时，我建议把用例中有公用的部分，提取出来写到一块，有特性的部分，单独去写。

这样用例的结构大概是这样的一个效果：通用部分+特性部分+其他特性。主要内容也可以分为：正常+异常点。坚决要避免的是照着需求文档，一个功能一个功能的写。也就是需求文档有个按钮，我写个按钮，有个输入框我写个输入框。我们在写用例时，要考虑的方面有很多，下面详细的说明一下，我这里有两个思路，可以供大家参考。

A角度：

正常、异常、排列组合-正常\异常\关联功能、对应功能的测试特性、核心点、业务端-APP/web端特性、性能、安全等。

下面以登陆页面(用户名输入框、密码输入框、登陆按钮)为例详细说明

正常条件就不解释了，就是正常用户名和密码点击登陆按钮。

异常里面包含常见的测试点，比如输入框的长度、特殊符号、为空等异常场景。

另外排列组合了，比如：正确的用户名和错误的密码，点击登陆后的效果，或者都是错误的，登陆后的效果。或者跟注册模块的管理，使用确的用户密码登陆后的跳转页面。

再说一下这个登陆页面的测试特性，首先登陆一般都会限制错误重试次数，如果次数超过限制一般都会提高验证的难度，比较常见的就是拉勾。连续输入多次密码错误，会有滑块验证码等。

就是安全性，这方面可以考虑对输入框，进行XSS的测试，也就是在输入框中输入JS代码，比如：alert(1),如果能够执行，那么就是存在XSS注入风险，如果用户写的是复杂的、恶意的JS代码就可以执行了。

再从核心点这方面来说，这是登陆页面，那登陆功能就是他的核心点，能让正常的用户登陆成功，让登陆失败的用户有一个清晰的认识哪里需要改正，都是这个地方的关键点，对应到测试点上就是登陆失败的错误提示文案，要清晰，比如在用户名或者密码错误输错超过3次后，就要限制用户登陆尝试，要及时的告诉用户，而不是在用户无意中操作了3次后，直接限制。

最后一点就是关于对应端的特性了，一般情况下，在不同的APP端进行登陆后，都会有一个手机登陆状态，也就是你在A手机登陆，B手机再登陆会自动踢掉A手机的登陆。或者APP端一般登陆都有一个有效期，比如说30天，会被自动登出。这些都算是端的特性。

性能方面这里考虑2种瞬间并发压测登陆接口，以及长期稳定性的压测。

当然安全测试里面还有SQL注入等类型，因为工作中接触不多，就不再详细的解释了。而安全测试中-越权测试一般在一些有多个角色或者不同身份的系统做的会比较多。

比如A、B角色都能够查看自己账号余额，如果通过fiddler抓包后，修改B账号的header里面的sessionid或者其他的代表B身份信息为A账号的，能够查看到A账号的账号余额，那么这里就认为存在越权bug。

B角度：

5W1H-(when\where\why\what\who+how)也就是时间、地点、人物、原因、怎么做、做什么。

这种的一般都是针对一些不是常规的功能，比如面试题中：电梯、水杯、地铁线路、红包等之类。

以面试题中比较常见的电梯为例，这里以单台电梯为例。

从时间角度需要考虑的点：坐电梯用多久，等电梯用多久。什么时间段可以做电梯。

从地点角度需要考虑的点：电梯开门到一半是否可以进去，从哪一层电梯可以坐到那一层，最下面一层是否可以往下坐电梯，最上面一层是否可以往上做电梯。在电梯里面不按按钮，电梯是否会上下动，如果有其他楼层的人按向上或者向下，电梯是否会直接走到对应的楼层。

从人物角度：可以站几个人，如果坐着是否可以，如果放货的货梯，乘人是否可以。客梯是否可以放货物，如果载重为1000KG，限乘10人，但是有超重的，是否有提示。或者有不超重的，是否可以继续上人。在电梯里面如果多人混乘的情况下，从1楼上电梯，一开始有几个人没有按按钮，其他人按的位置是顶层，往上走，这个时候，如果有人按地下室，是否电梯会往下走。如果电梯现在已经经过2楼，按2楼是否会打开门，按3楼是否会打开。按1楼的话，按钮有反应吗。如果在电梯外面的人，也做同样的事情，这些情况下，分别的解决方案是啥。

从原因角度：这个暂时没想到。

从怎么做角度：在电梯停稳后，进入电梯，在没有停稳时进入电梯，进入电梯有人蹦跳是否会紧急制动，在电梯内所有的电梯按钮都点，多次点击。或者是1楼超载后，在2楼下去人，再上来人不超载，电梯会不会报警。

当然还有其他更好的手段，也欢迎大家提出建议，但是面试有的一些测试题，或者工作中有些任务是一些算法相关的逻辑题，如果从常规的角度进行思考问题，就会出现跑偏的情况，这种时候，需要大家去按照正常的逻辑思维方式去解题，而不是按照前面的介绍的思路。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。