不得不说,虽然我觉得按照这个文章来做事没问题的,但是实践中不能得到很好的贯彻,由于项目时间紧,对项目预计过少,都是问题了.
测试真的是一个很重要的环节,在软件开发的流程中,也应该和开发一样,花费相同,甚至更多的时间!
软件开发,都会遇到bug,就算是Microsoft或者apple,都会存在软件出现bug的问题,关键在于测试,解决bug,但是于我来说,我最怕维护公司项目----真的很乱代码!大公司能够不断维护,可能就是代码写得很好,耦合性不强吧,维护起来很方便 ! 这点要注意.
一般测试,凡是我待过的公司,基本上都是黑盒测试,白盒测试要求很高,做的都很少,还有些自动化测试,不过是针对于不复杂的api测试还行.
所以,结合现状,基本都是黑盒测试,那么,一般的步骤,应该是先功能测试,然后在质量测试.功能测试,就是按照需求测试,将需求都测试了没问题,所有的业务逻辑都能够实现;质量测试,就是对产品的性能,抗并发性,稳定性,兼容性等进行测试.
这两次,做了一些项目,时间都是比较紧迫的,感觉测试的时间不够,上线的时候,任然是人心惶惶的感觉.生怕哪里出差错,我觉得这种不应该,而且,我呆的公司,确实都有这个问题.无论这个公司有没有测试人员.
对于cx网站,事前,确实是让一些非技术人员进行了轮回的测试的,小问题倒是解决了许多,但是最终上线的时候,用户真正使用的时候,那些关键的功能,总是会出差错.
对于wdsg,是我一人负责,感觉从逻辑上来说,我是认真的测试了两次的,而且,那个限制金额的小问题,在我调整逻辑之前是对的,后来,逻辑调整了之后,代码有变动,产生了错误.
所以,在外部的时间等限制调节不变的情况下,如何深厚测试的功力?
一. 目前问题
- 测试抓不住重点.一直测试界面,布局的问题,对于功能和逻辑的测试,比较少,功能隐患不能发现[cx网站]
- 测试无条理.若是出现了bug,在修改之后,可能这个问题对了,其他问题被牵扯了不对,但是测试就止步于此了,因为已经验证了正确,导致其他的错误[wdsg]
- 测试的侧重点不分明. 对于多用户或者是常用的功能,测试不够,没有反复模拟[cx网站]
- 测试的场景脱离实际. 有的项目,开发者测试,是正常的,正式上线使用,由于各种状况是不同的,容易出问题[cx网站]
二. 目前问题解决
-
测试文档.这是比较古老的方式了,人为测试.在项目完毕时候,写个测试文档,
对于列出各个测试的功能模块标清楚轻重缓急,哪些是不容错的功能,哪些是普通功能,哪些是最后的那种"修复则已,不修复无妨"的,各个功能点写清楚,模拟测试的流程写清楚,按照着来,清清楚楚,这样,至少就不会出现影响使用的情景.文档格式大概简单可以如下:
测试文档
一 开发环境
(一) 主要功能【后果严重,使用频率高,首要测试,重点,优先】
1. 用户买单功能
输入:输入项目的数据/操作
预期:应该得到的结果
输出:测试后的结果
结果:true/false
后续:解决后是否有附带问题
(二) 次要功能【不影响项目,逻辑运行,不易觉察】
1. 进入链接的人数展示
输入:输入项目的数据/操作
预期:应该得到的结果
输出:测试后的结果
结果:true/false
后续:解决后是否有附带问题
(三) 优化功能【界面调整,图片更换】
1. 数据更改成功后没有提示
输入:输入项目的数据/操作
预期:应该得到的结果
输出:测试后的结果
结果:true/false
后续:解决后是否有附带问题
二 实际环境
(一) 开发环境和实际环境的区别分析
1. 使用的用户量
2. 不同的设备
(二) 不同环境的区别的测试方案
1. 使用的用户量异同测试方案
2. 不同设备异同方案
(三) 备用方案
无论怎么说,测试都是有盲区的,我们要一直假设,当关键性的功能有了问题之后,要怎么办?当然,就是要出台一个备用的方案来预防.
上面的方法,应该是可以解决当前面临的问题了,但是,精益求精,还要有些方面要进行测试.在并发性上,稳定性上,用户的心理上等.都是要慢慢维护的.
三. 其它测试方法及其工具
完善中......
