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，下学期测试见！