软件工程第一次读书笔记

一、关于软件测试

因为在小组中主要负责美工和测试，所以就直接跳到第七章《软件测试和VSTS测试工具》一章进行阅读学习。

之前一直以为测试是一件很容易的事，但是看完这一章便不再这样认为了。软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。由此看来软件测试的重要性也是非同一般。那么我们应该怎样进行软件测试呢？

书中介绍的测试的方法也是多种多样的，从设计的方法分类可以分为黑箱，白箱。黑箱，是基于无法了解或者使用系统的内部结构及知识进行的测试。白箱，是基于设计者可以知道软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择而进行的测试。从测试的目的分为功能测试和非功能测试。功能测试是测试软件的一些基本功能，分为单元测试、功能测试、集成测试、场景测试、系统测试和Alpha/Beta测试。非功能性测试用来测试软件的基本功能之外的一些特性，常用的方法有负载测试、效能测试、软件辅助功能测试、本地化/全球化测试、兼容性测试、配置测试、可用性测试和软件安全性测试。从测试的时机和作用分类，可以分为冒烟测试、构建验证测试、验收测试、回归测试、探索性测试、Bug大扫荡和伙伴测试。

提问：

1、对于一个10000行代码左右的软件，我们是否需要使用上述的所有软件测试方法？

2、对于软件工程团队作业级别的软件，一般经常采取的软件测试方法是什么？

3、是否有一些好用的软件测试工具，请老师推荐一下？

4、怎样可以减少软件测试的工作量？

二、关于团队合作

现在正在做团队项目，所以在老师的课件里特意选择这部分来写感想，我比较感兴趣的是绩效管理问题。因为我觉得一个程序员不可能一辈子都当程序员，等他老了，相对于年轻人除了经验上的优势，在体力、精力、记忆力、学习力上都不再有优势，此时更明智的是转型管理者，凭着自己多年项目积累的经验去管理一个团队或者说一个项目。

对于之前的团队人员贡献的判定方法中，我的意见是：首先，我们要清楚公平有利于整个团队的团结合作，有利于保证每个队员的积极性，从而提高整个团队的效率。但是，绝对的公平是没有的,只有相对的公平。因为每人个的能力是不相同的，但是团队分工中的每个角色都是不可或缺的。因此我们出于这样的考虑，在保证相对公平的前提下，我们用两个参数来衡量某个队员的贡献：相对工作量（a%）和完成程度(b%)。我们取相对工作量的满分为40分，完成程度的满分为60分。给出一个简单的公式：个人贡献=a*40+b*60。

对于相对工作量，我们将团队工作总量定为100，根据每个人负责部分的难度和工作强度，为每个人分配一个值，保证所有人的工作量总和为100，然后再以工作量最大的人的工作量为1，其他人相对于他的工作量求相对工作量.

对于完成程度，如果一个人只是完成了自己的本份工作，而没有任何创新或者说超出既定目标的预期，我们定为完成程度为80%。在此标准上，如果做出了创新或者说改进，或者提出了建设性意见，我们最多可以给他100%。反而，如果出现了完成情况不好，拖延时间，态度不认真等行为，我们最低可以给他0%。

我觉得这样的判定方法，一定程度上肯定了团队中各个角色的价值，同时也符合“多劳多得”的价值分配原理。

我的问题是：

1、老师在许多团队做事，甚至在许多团队中作为leader，那么老师在这些经历中，什么样的绩效管理方面老师觉得是比较合理的？

2、在老师所了解的大多数团队中，一般会分为哪些角色？这些角色是否有所谓的地位高低或者说重要性高低？

3、我们知道，对于我们学生现在组成的团队和公司里的团队是不一样，约束性要少很多，老师在管理方面是否有些好建议？