COPD——团队项目测试心得

写在前面:

测试结束了,也要和项目说拜拜了~这一学期时间飞快,痛并快乐着,想想人生如果是个软件,那我们用多长时间在做测试呢?恐怕是一辈子。很多人忙着追逐,却很少人能停下来审视自己,那些时常自省的,常能在人生苦旅中走的更顺利,而那些盲目奔跑的,早晚也会栽跟头,不得不看看到底出现了什么问题。人无完人,生命不息,测试不止。

一、项目简介:

  慢阻肺药物治疗主要涉及稳定期的治疗,是慢阻肺治疗核心问题。根据症状的严重程度、气流受限以及急性加重的差异,每例患者的治疗应该个体化。对于大部分患者,他们对于药物的依从性差,不能坚持长期,规律,稳定地维持治疗。而我们的app旨在为稳定期的慢阻肺患者提供病情的监控,提供护理计划并进行提醒,从而从整体上稳定慢阻肺病情的发展,降低急性加重的风险。

  主要用户:慢阻肺稳定期中患者,慢阻肺治疗医师。

二、测试方法:

  此次测试主要采用黑盒测试方法,即把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试程序是否能适当地接收输入数据而产生正确的输出信息。主要针对软件界面和软件功能进行测试。此次测试采用的主要几中黑盒测试方法:

1. 等价类划分测试

2.边界值分析

(为检验边界附近的处理设计专门的测试用例,常常可以取得良好的测试效果。
使用边界值分析方法设计测试用例,首先应确定边界情况。输入等价类与输出等价类的边界,就是着重测试的边界情况。
边界值分析方法的基本思想是:选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中典型值或任意值作为测试数据。
边界值分析方法是一种最有效的黑盒测试方法,但当边界情况和复杂的时候,要找出适当的边界测试用例还需针对问题的输入域、输出域边界,耐心仔细的逐个进行考虑。)
3. 特殊值测试
4. 故障猜测法
  靠经验和直觉猜测程序中可能存在的各种软件故障,有针对地编写检查这些故障的测试用例。这个方法和特殊值测试法也是本次测试中最多使用的方法。
 
(需要了解具体黑盒测试分类的可参考:https://blog.csdn.net/huangjing8203/article/details/72403748)
 
 
三、测试曲线:

  通过此系统性统计可以看出,测试的起始日期并不理想,所谓“在起始一个用例测试,也比在最后测五十个用例的效果要好得多!"。在测试和修改过程中,bug甚至有反而变多的情况,这可以总结为一下两个原因:

1) 测试人员的测试不成功。

2) 回归测试过程中发现开发人员惹了祸!

四、测试建议:

1. 测试人员要和开发人员合理沟通,用合理方式传达出缺陷内容。

2. 开发人员要对测试人员表示判断力上的信任,当有bug出现,先确定自己的问题,而不要和测试人员产生分歧,因为测试人员在99%的情况下都是按照用户角度进行严格测试的,此时测试人员的使用感即在某种程度上代表着用户的直观感受。

3. 测试过程开发人员要紧密配合,及时修复。

4. 测试人员分阶段测试,不要每当开发人员修复一个bug就去测试一次,可以按期测试,比如说一天、两天等等。

五、测试总结:

  由于是第一次进行软件测试,在过程中,有很多的不足,但是整体效果还是可以的。遗憾的是,在这次测试过程中,由于相关知识储备不足以及对测试流程的提前理解不够透彻,导致在测试至修改bug的过程中,出现一些沟通不到位的情况。比如对于一个A bug,开发人员没有明白测试人员的意思,结果修改了B 部分,导致测试人员一脸疑惑,开发人员还白忙一场。

  在测试过程中,测试人员的直觉是很重要的,当然,这不能是单一的直觉,还得以客观事实为出发点。一个好的测试人员能够完成他的工作,离不开开发人员的良好沟通、和谐的合作关系、以及共同去面对并积极解决问题的team work。

  一个软件最后到底能不能交付使用,也许只有20%看开发,剩下的因素中,有效的测试绝对是一个重中之重。如果一个软件仿佛能实现用户的需求,但是在使用的过程中,一会儿闪退一下,一会儿又获取数据失败,想想就糟心!

  想起之前有人说过这样一句话:测试是属于女人的工作,因为它轻松!

  well,现在我只想说:NO! 测试是属于心细的人的工作,在我看来,它不仅不简单,而且不轻松!同时,它对一个人日常经验也有所考验,软件的用户体验差不差?那些地方需要改进?只能说女人的直觉绝对加分!但可别说这是一个轻松的工作!沟通+细心+技术+经验,测试二字大有内涵!

  

写在最后:测试完后,感觉自己测试技术太差了!现在十分期待下学期的软件测试课程!COPD,下学期测试见!

猜你喜欢

转载自www.cnblogs.com/sobermech/p/10221947.html
今日推荐